目录一、消息队列RocketMQ / Kafka二、ACK 容器服务一、消息队列RocketMQ / Kafka阿里云对应产品大致是云消息队列 RocketMQ 版云消息队列 Kafka 版兼容 Apache Kafka1、消息队列是干什么的没有 MQ 时下单服务可能要同步调用库存、积分、短信、物流……一个慢、一个挂整条链路都堵。有了 MQ下单服务 ──发送消息── 消息队列├─ 库存服务慢慢扣├─ 积分服务└─ 短信服务MQ 像邮局/传送带解耦彼此不直接依赖异步主流程先返回旁路事后做削峰填谷大促流量先堆在队列里下游按能力消化2、三个核心词概念描述Producer生产者发消息的人如下单服务Topic消息分类频道如order_createdConsumer / Consumer Group收消息的人或一组人同组内常负载均衡消费RocketMQ 里还有 TagTopic 下的小标签便于过滤。Kafka 里强调 Partition分区并行与顺序的基本单位。3、RocketMQ vs Kafka怎么选维度RocketMQKafka定位业务消息、金融级可靠高吞吐流式/日志管道最擅长订单、交易、解耦、事务/顺序/延时日志采集、大数据、流计算吞吐高非常高业务特性事务消息、顺序、延时/定时、Tag 过滤、死信更贴业务分区模型、生态Flink 等强国内业务落地电商/互联网很常见数据平台很常见一句话办业务搬大量数据流企业选型口诀订单、支付、积分、通知、微服务解耦 → 优先 RocketMQ日志汇聚、埋点、对接 Flink/大数据、超高吞吐流水 → 优先 Kafka很多公司两个都用各司其职4、企业级铁律能异步的别同步死扛但核心同步链路如支付扣款别乱改成“只发消息不管结果”消费要幂等同一条消息可能重复投递业务不能重复扣款失败要有重试 死信/人工补偿别 silently 丢Topic 按业务域划分权限与监控分开生产与测试实例隔离别共用 Topic关注堆积队列堆高说明消费者慢或挂了要告警顺序只在需要时用按订单号分区/消息组全局强顺序会牺牲吞吐和 RDS 事务想清楚本地库成功 vs 消息发送常用事务消息或本地消息表5、内容了解1四种经典场景场景例子异步解耦下单成功 → 发短信/加积分削峰填谷秒杀流量先进 MQ库存服务匀速消费最终一致性订单库已提交下游靠消息同步状态事件驱动用户注册 → 多个系统各自订阅处理不适合硬套 MQ强实时、强一致、必须同步拿到结果的短链路除非再加查询/回调设计。2RocketMQ 企业要点实例与资源创建实例注意版本 4.x / 5.x 差异以控制台为准建 Topic、Group同 VPC 内网访问权限用 RAM消息类型业务很爱用类型用途普通消息最常用解耦顺序消息同一订单创建→支付→发货 按序常用订单 ID 作 key/消息组延时/定时消息30 分钟未支付关单事务消息本地事务与发消息最终一致死信多次失败后进死信人工/补偿处理消费模式集群消费组内一台消费一条常见负载均衡广播消费组内每台都收到如本地缓存刷新官方什么是 RocketMQ · 顺序消息3Kafka 企业要点核心模型Topic├─ Partition 0 有序├─ Partition 1└─ Partition 2Consumer Group 内多个消费者分摊分区要点分区内有序不是全局有序吞吐靠多分片并行适合持续流日志、点击流、CDC、进湖进仓与 SLS / Flink / 大数据 生态搭配多云上注意实例规格、磁盘、分区数、副本与监控堆积、ISR、磁盘水位。4最小业务代码思维RocketMQ 风格生产者下单成功后保存订单到 RDS发送消息到 Topic: ORDER_CREATEDbody: { orderId, userId, amount }tag: CREATEDkeys: orderId 方便排查消费者积分服务收到消息if 已处理过该 orderId: 直接成功返回 # 幂等else 给用户加积分并记录处理流水确认消费成功ACK失败则重试超过次数进死信幂等常用手段处理前查“消费流水表 / Redis SETNX”。5和 RDS / Redis / 监控 / 日志怎么配合用户下单→ ALB → 订单 ECS→ 写 RDS订单→ 删/更新 Redis 缓存如有→ 发 RocketMQORDER_CREATED├─ 库存服务消费├─ 积分服务消费└─ 短信服务消费堆积/失败 → 云监控告警消息内容/业务日志 → SLS带 orderId / msgId事务注意只写库不发消息 → 下游永远不知道只发消息库失败 → 下游空忙企业常用RocketMQ 事务消息 或 本地消息表 保证最终一致6可靠性与堆积治理问题处理重复消费业务幂等消费失败重试 → 死信 → 告警/人工堆积飙升扩消费者、查慢逻辑、是否被大消息拖死顺序错乱检查是否误用并发无序消费key/消息组是否正确消息堆积占满限流生产、扩容、过期策略按产品能力监控最少盯发送成功率 / 消费 TPS堆积量最重要死信数量实例磁盘/水位Kafka 尤其要看7Topic 设计规范推荐业务域 环境 事件order_prod_OrderCreateduser_prod_UserRegistered或公司统一命名order.prod.created规范环境隔离prod/test 分实例或分前缀消息体版本化version字段方便演进消息尽量小大文件放 OSSMQ 只传 URL/ID关键字段放 header/属性便于过滤与检索6、选型场景速查需求选电商下单后通知多个系统RocketMQ未支付超时关单RocketMQ 延时消息同一订单状态严格按序RocketMQ 顺序消息本地事务与发消息一致RocketMQ 事务消息Nginx/App 日志海量入湖Kafka或 SLS 直接采Flink 实时计算输入Kafka 很常见只要微服务解耦、国内业务队多数从 RocketMQ 起步小结RocketMQ 偏业务可靠消息Kafka 偏海量数据流。企业里用 MQ 做异步解耦和削峰消费务必幂等失败进重试/死信堆积要监控并与 RDS 最终一致性设计配套。二、ACK 容器服务官方参考什么是 ACK · 网络规划 · ALB Ingress1、ACK 是什么ACKAlibaba Cloud Container Service for Kubernetes 阿里云托管的 Kubernetes 平台。传统 ECS 部署ACK应用形态一台机装一个/几个服务应用打成镜像以 Pod 跑扩缩容手工或 ESS 加机器按副本数扩 Pod还可自动伸缩发布停机换包易抖滚动更新、灰度更自然你管什么每台机环境易漂移管镜像与 YAML集群控制面可托管一句话ECS 是租服务器ACK 是用 Kubernetes 编排一群容器来跑应用。2、先分清集群类型怎么选类型大白话适合ACK 托管版推荐控制面阿里云管你管节点与应用绝大多数生产ACK 托管 Pro托管增强SLA、规模、能力更强核心生产ACK ServerlessASK少管甚至不管节点按 Pod 弹性Serverless、突发ACK 专有版控制面也在你账号里强管控/特殊合规运维更重入门与多数企业托管版 / Pro。3、Kubernetes 最小词表够用就行概念大白话镜像应用打包好的“安装包”含代码与依赖Pod最小运行单位通常一个主容器Deployment无状态应用的期望副本与发布方式Service一组 Pod 的稳定访问入口集群内 VIPIngress七层路由域名/路径 → Service常接 ALB/MSENamespace命名空间隔离如prod/testConfigMap / Secret配置与密钥PVC / StorageClass持久存储声明云盘/NAS 等Node / 节点池跑 Pod 的 ECS 及一批节点的统一管理流量路径用户 → ALB/MSE Ingress → Service → Pod多副本4、企业级铁律生产用托管 Pro 多可用区节点别单 AZ创建前规划网段VPC、Pod、ServiceCNI 选定后不能改生产倾向 Terway性能与 NetworkPolicy 更好Flannel 偏简单场景无状态进 Deployment有状态谨慎用 StatefulSet 云盘/NAS配置进 ConfigMap密钥进 Secret或接入 KMS镜像放 ACR生产用固定版本 Tag忌长期latest日志采到 SLS指标进 Prometheus/云监控资源设 requests/limits防一台吃光节点微服务治理可接 MSE你前面学过的灰度、限流RBAC RAM谁能动集群、谁只能看要分开5、内容了解1建集群前的网络规划最易翻车ACK 建在你的 VPC 上要提前规划网段用途VPC / 交换机节点 ECS 所在建议 ≥2 个 AZPod CIDR容器 IP 段与 VPC、现有网段不冲突Service CIDRService ClusterIP 段也不冲突规模建议官方思路简化小集群也可但生产节点建议 ≥2 AZ核心业务、多地域要用多 VPC/多集群 CEN 等互联CNITerwayPod 直挂 VPC/ENI性能好支持 NetworkPolicy → 生产常用Flannel简单功能较少参考ACK 网络规划2创建企业规范集群清单项建议类型托管 Pro地域与 RDS/Redis/OSS 同地域VPC已有生产 VPC交换机≥2 AZCNITerway生产节点池多 AZ系统盘 ESSD容器目录挂数据盘NAT节点需拉镜像/出网时配置组件按需装ALB Ingress、日志、监控、MSE 相关标签envprodteamorder节点池 ≈ 一批规格相近的 ECS可独立扩缩、升级。3部署一个无状态应用最小 YAMLapiVersion: apps/v1 kind: Deployment metadata: name: demo-api namespace: prod spec: replicas: 2 selector: matchLabels: app: demo-api template: metadata: labels: app: demo-api spec: containers: - name: api image: registry.cn-hangzhou.aliyuncs.com/your-ns/demo-api:1.0.0 ports: - containerPort: 8080 resources: requests: cpu: 100m memory: 128Mi limits: cpu: 500m memory: 512Mi readinessProbe: httpGet: path: /health port: 8080 initialDelaySeconds: 5 periodSeconds: 10 --- apiVersion: v1 kind: Service metadata: name: demo-api namespace: prod spec: selector: app: demo-api ports: - port: 80 targetPort: 8080要点replicas: 2至少双副本健康检查readinessProbe否则 Ingress/Service 会打到未就绪 Pod镜像带版本号4怎么对外暴露Service Ingress方式用途ClusterIP仅集群内访问默认LoadBalancer直接绑云负载均衡Ingress推荐 Web域名/路径统一入口Ingress 选型ACK 常见类型适合ALB Ingress七层、高性能、托管Web/API 生产常用MSE Ingress微服务治理强灰度、限流等接你学的 MSENginx Ingress灵活但要自己运维组件路径示例https://api.example.com/orders → Service demo-api → Pods域名 CNAME 到 ALB/网关地址。5配置、密钥、存储ConfigMap非敏感配置功能开关、非密连接参数Secret密码、Token生产更好接 KMS/密钥管理云盘 PVC单 Pod 独占适合数据库类很多情况更推荐云 RDS而不是容器里跑主库NAS多 Pod 共享文件OSS大对象容器里常挂工具访问或只存 URL有状态跨 AZ云盘要注意同 AZ 挂载官方推荐WaitForFirstConsumer等拓扑友好配置。NAS Network Attached Storage网络附属存储。在阿里云上一般指文件存储 NAS一块可被多台机器同时挂载的共享网盘/共享文件系统。存储像什么特点云盘ECS 磁盘插在一台服务器上的硬盘通常一台机用块存储OSS对象仓库/网盘 API按对象上传下载不是传统“盘符路径”NAS公司共享文件夹多台 ECS/ACK 同时挂载用路径读写文件需要多台机器共同读写同一批文件时常用 NAS。典型用途多台 Web 机共享上传目录、静态资源ACK 多个 Pod 共享配置/文件RWX传统应用依赖本地文件系统/data/xxx又要上云多机部署场景更合适系统盘、单机数据库数据云盘图片/视频/备份、海量对象、CDNOSS多机共享、要“文件路径”语义NASNAS 云上的共享文件盘多机一起挂、一起用文件。6弹性与发布能力作用手工改 replicas最简单扩容HPA按 CPU/QPS 自动加减 Pod节点池伸缩 / Cluster AutoscalerPod 多了自动加节点滚动更新Deployment 默认逐步替换灰度Ingress 权重 / MSE 全链路灰度对比之前的 ESSESS以 ECS 台数 弹性ACK HPA以 Pod 副本 弹性更贴容器7可观测与治理应用日志 → Logtail/LoongCollector → SLS指标 → Prometheus / 云监控链路 → ARMS / Tracing入口 → ALB 或 MSE Ingress注册配置 → MSE NacosSpring Cloud/Dubbo消息 → RocketMQ / Kafka数据 → RDS / Redis / OSS排障顺序建议Ingress/Service 是否通、Pod Ready 吗云监控/PrometheusCPU、重启次数SLS用request_id查错误再kubectl/控制台看事件与日志8和 ECS 架构对照以前用户 → ALB → ECSESS→ RDS/Redis/MQ容器化后用户 → ALB/MSE Ingress → Service → Pod×N在 ACK 节点上↓RDS/Redis/MQ/OSS还是托管服务通常不塞进容器硬扛原则有状态中间件优先继续用云产品RDS/Redis/MQ应用无状态容器化。6、常见坑坑说明网段冲突 / CNI 选错后期极难改创建前规划单副本上生产节点或 Pod 一挂就中断不设资源限制互相挤兑节点僵死用latest镜像回滚困难、环境不可复现把 MySQL 随便跑集群里当生产主库运维与高可用远不如 RDS新节点无日志采集镜像/DaemonSet 未覆盖Service 通了外网不通Ingress/安全组/DNS 未配好小结ACK 托管 Kubernetes应用镜像化、多副本、Ingress 入口、弹性按 Pod。网络先规划生产用托管多 AZ Terway中间件继续用 RDS/Redis/MQ可观测接 SLS/监控微服务治理可接 MSE。