目录

一、消息队列（RocketMQ / Kafka）

二、ACK 容器服务

一、消息队列（RocketMQ / Kafka）

阿里云对应产品大致是：

• 云消息队列 RocketMQ 版
• 云消息队列 Kafka 版（兼容 Apache Kafka）

---

1、消息队列是干什么的

没有 MQ 时，下单服务可能要同步调用库存、积分、短信、物流……
一个慢、一个挂，整条链路都堵。

有了 MQ：

下单服务 ──发送消息──> 消息队列

                                                ├─> 库存服务（慢慢扣）

                                                ├─> 积分服务

                                                └─> 短信服务

MQ 像邮局/传送带：

1. 解耦：彼此不直接依赖
2. 异步：主流程先返回，旁路事后做
3. 削峰填谷：大促流量先堆在队列里，下游按能力消化

---

2、三个核心词

概念	描述
Producer（生产者）	发消息的人（如下单服务）
Topic	消息分类频道（如 order_created）
Consumer / Consumer Group	收消息的人或一组人；同组内常负载均衡消费

RocketMQ 里还有 Tag（Topic 下的小标签，便于过滤）。
Kafka 里强调 Partition（分区）（并行与顺序的基本单位）。

---

3、RocketMQ vs Kafka：怎么选

维度	RocketMQ	Kafka
定位	业务消息、金融级可靠	高吞吐流式/日志管道
最擅长	订单、交易、解耦、事务/顺序/延时	日志采集、大数据、流计算
吞吐	高	非常高
业务特性	事务消息、顺序、延时/定时、Tag 过滤、死信更贴业务	分区模型、生态（Flink 等）强
国内业务落地	电商/互联网很常见	数据平台很常见
一句话	办业务	搬大量数据流

企业选型口诀：

• 订单、支付、积分、通知、微服务解耦 → 优先 RocketMQ
• 日志汇聚、埋点、对接 Flink/大数据、超高吞吐流水 → 优先 Kafka
• 很多公司：两个都用，各司其职

---

4、企业级铁律

1. 能异步的别同步死扛；但核心同步链路（如支付扣款）别乱改成“只发消息不管结果”
2. 消费要幂等：同一条消息可能重复投递，业务不能重复扣款
3. 失败要有重试 + 死信/人工补偿，别 silently 丢
4. Topic 按业务域划分，权限与监控分开
5. 生产与测试实例隔离，别共用 Topic
6. 关注堆积：队列堆高说明消费者慢或挂了，要告警
7. 顺序只在需要时用（按订单号分区/消息组），全局强顺序会牺牲吞吐
8. 和 RDS 事务想清楚：本地库成功 vs 消息发送，常用事务消息或本地消息表

---

5、内容了解

（1）四种经典场景

场景	例子
异步解耦	下单成功 → 发短信/加积分
削峰填谷	秒杀流量先进 MQ，库存服务匀速消费
最终一致性	订单库已提交，下游靠消息同步状态
事件驱动	用户注册 → 多个系统各自订阅处理

不适合硬套 MQ：强实时、强一致、必须同步拿到结果的短链路（除非再加查询/回调设计）。

---

（2）RocketMQ 企业要点

实例与资源：

• 创建实例（注意版本 4.x / 5.x 差异以控制台为准）
• 建 Topic、Group
• 同 VPC 内网访问；权限用 RAM

消息类型（业务很爱用）：

类型	用途
普通消息	最常用解耦
顺序消息	同一订单：创建→支付→发货 按序（常用订单 ID 作 key/消息组）
延时/定时消息	30 分钟未支付关单
事务消息	本地事务与发消息最终一致
死信	多次失败后进死信，人工/补偿处理

消费模式：

• 集群消费：组内一台消费一条（常见，负载均衡）
• 广播消费：组内每台都收到（如本地缓存刷新）

官方：什么是 RocketMQ · 顺序消息

---

（3）Kafka 企业要点

核心模型：

Topic

   ├─ Partition 0 （有序）

   ├─ Partition 1

   └─ Partition 2

Consumer Group 内多个消费者分摊分区

要点：

• 分区内有序，不是全局有序
• 吞吐靠多分片并行
• 适合持续流：日志、点击流、CDC、进湖进仓
• 与 SLS / Flink / 大数据 生态搭配多

云上注意：实例规格、磁盘、分区数、副本与监控（堆积、ISR、磁盘水位）。

---

（4）最小业务代码思维（RocketMQ 风格）

生产者（下单成功后）：

保存订单到 RDS

发送消息到 Topic: ORDER_CREATED

        body: { orderId, userId, amount }

        tag: CREATED

        keys: orderId （方便排查）

消费者（积分服务）：

收到消息

if 已处理过该 orderId: 直接成功返回         # 幂等

else 给用户加积分并记录处理流水

确认消费成功（ACK）

失败则重试；超过次数进死信

幂等常用手段：处理前查“消费流水表 / Redis SETNX”。

---

（5）和 RDS / Redis / 监控 / 日志怎么配合

用户下单
  → ALB → 订单 ECS
  → 写 RDS（订单）
  → 删/更新 Redis 缓存（如有）
  → 发 RocketMQ：ORDER_CREATED
        ├─ 库存服务消费
        ├─ 积分服务消费
        └─ 短信服务消费

堆积/失败 → 云监控告警
消息内容/业务日志 → SLS（带 orderId / msgId）

事务注意：

• 只写库不发消息 → 下游永远不知道
• 只发消息库失败 → 下游空忙
• 企业常用：RocketMQ 事务消息 或 本地消息表 保证最终一致

---

（6）可靠性与堆积治理

问题	处理
重复消费	业务幂等
消费失败	重试 → 死信 → 告警/人工
堆积飙升	扩消费者、查慢逻辑、是否被大消息拖死
顺序错乱	检查是否误用并发无序消费；key/消息组是否正确
消息堆积占满	限流生产、扩容、过期策略（按产品能力）

监控最少盯：

• 发送成功率 / 消费 TPS
• 堆积量（最重要）
• 死信数量
• 实例磁盘/水位（Kafka 尤其要看）

---

（7）Topic 设计规范

推荐：

业务域 + 环境 + 事件
order_prod_OrderCreated
user_prod_UserRegistered

或公司统一命名：order.prod.created

规范：

• 环境隔离（prod/test 分实例或分前缀）
• 消息体版本化（version 字段），方便演进
• 消息尽量小；大文件放 OSS，MQ 只传 URL/ID
• 关键字段放 header/属性，便于过滤与检索

---

6、选型场景速查

需求	选
电商下单后通知多个系统	RocketMQ
未支付超时关单	RocketMQ 延时消息
同一订单状态严格按序	RocketMQ 顺序消息
本地事务与发消息一致	RocketMQ 事务消息
Nginx/App 日志海量入湖	Kafka（或 SLS 直接采）
Flink 实时计算输入	Kafka 很常见
只要微服务解耦、国内业务队	多数从 RocketMQ 起步

---

小结

RocketMQ 偏业务可靠消息；Kafka 偏海量数据流。
企业里用 MQ 做异步解耦和削峰，消费务必幂等，失败进重试/死信，堆积要监控，并与 RDS 最终一致性设计配套。

二、ACK 容器服务

官方参考：什么是 ACK · 网络规划 · ALB Ingress

1、ACK 是什么

ACK（Alibaba Cloud Container Service for Kubernetes） = 阿里云托管的 Kubernetes 平台。

	传统 ECS 部署	ACK
应用形态	一台机装一个/几个服务	应用打成镜像，以 Pod 跑
扩缩容	手工或 ESS 加机器	按副本数扩 Pod，还可自动伸缩
发布	停机换包，易抖	滚动更新、灰度更自然
你管什么	每台机环境易漂移	管镜像与 YAML；集群控制面可托管

一句话：

ECS 是租服务器；ACK 是用 Kubernetes 编排一群容器来跑应用。

---

2、先分清：集群类型怎么选

类型	大白话	适合
ACK 托管版（推荐）	控制面阿里云管，你管节点与应用	绝大多数生产
ACK 托管 Pro	托管增强：SLA、规模、能力更强	核心生产
ACK Serverless（ASK）	少管甚至不管节点，按 Pod 弹性	Serverless、突发
ACK 专有版	控制面也在你账号里	强管控/特殊合规（运维更重）

入门与多数企业：托管版 / Pro。

---

3、Kubernetes 最小词表（够用就行）

概念	大白话
镜像	应用打包好的“安装包”（含代码与依赖）
Pod	最小运行单位（通常一个主容器）
Deployment	无状态应用的期望副本与发布方式
Service	一组 Pod 的稳定访问入口（集群内 VIP）
Ingress	七层路由（域名/路径 → Service），常接 ALB/MSE
Namespace	命名空间隔离（如 prod / test）
ConfigMap / Secret	配置与密钥
PVC / StorageClass	持久存储声明（云盘/NAS 等）
Node / 节点池	跑 Pod 的 ECS 及一批节点的统一管理

流量路径：用户 → ALB/MSE Ingress → Service → Pod（多副本）

---

4、企业级铁律

1. 生产用托管 Pro + 多可用区节点，别单 AZ
2. 创建前规划网段（VPC、Pod、Service），CNI 选定后不能改
3. 生产倾向 Terway（性能与 NetworkPolicy 更好；Flannel 偏简单场景）
4. 无状态进 Deployment；有状态谨慎用 StatefulSet + 云盘/NAS
5. 配置进 ConfigMap，密钥进 Secret（或接入 KMS）
6. 镜像放 ACR，生产用固定版本 Tag，忌长期 latest
7. 日志采到 SLS，指标进 Prometheus/云监控
8. 资源设 requests/limits，防一台吃光节点
9. 微服务治理可接 MSE（你前面学过的灰度、限流）
10. RBAC + RAM：谁能动集群、谁只能看，要分开

---

5、内容了解

（1）建集群前的网络规划（最易翻车）

ACK 建在你的 VPC 上，要提前规划：

网段	用途
VPC / 交换机	节点 ECS 所在（建议 ≥2 个 AZ）
Pod CIDR	容器 IP 段（与 VPC、现有网段不冲突）
Service CIDR	Service ClusterIP 段（也不冲突）

规模建议（官方思路简化）：

• 小集群也可，但生产节点建议 ≥2 AZ
• 核心业务、多地域要用多 VPC/多集群 + CEN 等互联

CNI：

• Terway：Pod 直挂 VPC/ENI，性能好，支持 NetworkPolicy → 生产常用
• Flannel：简单，功能较少

参考：ACK 网络规划

---

（2）创建企业规范集群（清单）

项	建议
类型	托管 Pro
地域	与 RDS/Redis/OSS 同地域
VPC	已有生产 VPC
交换机	≥2 AZ
CNI	Terway（生产）
节点池	多 AZ；系统盘 ESSD；容器目录挂数据盘
NAT	节点需拉镜像/出网时配置
组件	按需装：ALB Ingress、日志、监控、MSE 相关
标签	env=prod team=order

节点池 ≈ 一批规格相近的 ECS，可独立扩缩、升级。

---

（3）部署一个无状态应用（最小 YAML）

apiVersion: 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	微服务治理强（灰度、限流等，接你学的 MSE）
Nginx 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），又要上云多机部署

场景	更合适
系统盘、单机数据库数据	云盘
图片/视频/备份、海量对象、CDN	OSS
多机共享、要“文件路径”语义	NAS

NAS = 云上的共享文件盘；多机一起挂、一起用文件。

---

（6）弹性与发布

能力	作用
手工改 replicas	最简单扩容
HPA	按 CPU/QPS 自动加减 Pod
节点池伸缩 / Cluster Autoscaler	Pod 多了自动加节点
滚动更新	Deployment 默认逐步替换
灰度	Ingress 权重 / MSE 全链路灰度

对比之前的 ESS：

• ESS：以 ECS 台数 弹性
• ACK HPA：以 Pod 副本 弹性（更贴容器）

---

（7）可观测与治理

应用日志 → Logtail/LoongCollector → SLS

指标 → Prometheus / 云监控

链路 → ARMS / Tracing

入口 → ALB 或 MSE Ingress

注册配置 → MSE Nacos（Spring Cloud/Dubbo）

消息 → RocketMQ / Kafka

数据 → RDS / Redis / OSS

排障顺序建议：

1. Ingress/Service 是否通、Pod Ready 吗
2. 云监控/Prometheus：CPU、重启次数
3. SLS：用 request_id 查错误
4. 再 kubectl/控制台看事件与日志

---

（8）和 ECS 架构对照

以前：
用户 → ALB → ECS（ESS）→ 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。