Table of contents
Open Table of contents
TL;DR
一个完整的微服务集群，从来不只是“一堆 RPC 服务实例”。至少要同时看见四层：平台层负责调度和运行，流量层负责入口和东西向治理，业务层承载真正的领域逻辑，状态层保存持久数据与异步事件；可观测性、配置、密钥、发布流水线则是横切支撑层。少看任何一层，架构判断都会失真。
先给结论：完整集群到底包含什么
如果你问“一个完整的微服务集群包含什么”，最实用的答案不是背产品名，而是先分层。
| 层次 | 核心职责 | 典型组件 |
|---|---|---|
| 平台层 | 调度、运行、收敛工作负载 | Kubernetes control plane、worker nodes、kubelet、container runtime、CNI/CSI |
| 流量层 | 处理入口流量和服务间流量治理 | Load Balancer、Ingress / API Gateway、Service Mesh data plane、Service discovery |
| 业务层 | 执行真正的业务语义 | user-service、order-service、payment-service、消费者、定时任务 |
| 状态层 | 保存状态、缓存、消息、文件 | PostgreSQL、Redis、Kafka、对象存储、搜索引擎 |
| 横切支撑层 | 观测、配置、发布、安全 | Metrics/Logs/Traces、Secret、Config、CI/CD、备份恢复、证书 |
最关键的结论：
- “各种 RPC 服务实例”只覆盖了业务层
data plane / control plane主要用来描述平台层和流量层- 只盯着服务实例，不看状态层和支撑层，是最常见的架构盲区
为什么不能把“微服务集群”理解成“一堆服务”
因为服务实例只是业务逻辑的执行载体，不是整个系统。
只看服务实例，会漏掉四类决定生死的问题：
| 漏掉的层 | 你会误判什么 |
|---|---|
| 平台层 | 以为“服务挂了就重启进程”足够，忽略调度、节点故障、期望状态收敛 |
| 流量层 | 以为服务只要监听端口就能通信，忽略入口、服务发现、超时重试、mTLS、灰度 |
| 状态层 | 以为服务无状态就等于系统无状态，忽略数据库、缓存、消息队列才是真正的数据重心 |
| 横切支撑层 | 以为日志和监控是锦上添花，忽略它们决定了系统是否可运维 |
这也是为什么“我已经有 20 个微服务了”不等于“我有一个完整可运维的微服务平台”。
第一层：平台层负责“让工作负载在集群里持续活着”
如果你用 Kubernetes，那么平台层的核心是：
kube-apiserveretcdkube-schedulerkube-controller-manager- nodes /
kubelet - container runtime
Kubernetes 官方文档明确把 cluster 拆成 control plane 和 nodes；controllers 持续把 current state 拉向 desired state（确定，见 Cluster Architecture / Controllers）。
平台层解决的是：
- Pod 放哪台机器
- 挂了怎么重建
- 镜像怎么启动
- 网络和存储插件怎么挂接
- 副本数、滚动更新、探针、驱逐怎么落地
一句话： 平台层不关心“订单怎么下”，它只关心“承载订单服务的工作负载能不能持续存在”。
第二层：流量层负责“让请求进得来、到得对、控得住”
流量层通常再分成两个方向：
| 方向 | 处理什么流量 | 典型组件 |
|---|---|---|
| North-South | 外部用户到集群 | Load Balancer、Ingress、API Gateway、边缘 Envoy/Nginx |
| East-West | 服务到服务 | Service、Mesh sidecar / waypoint、L4/L7 LB、mTLS、重试熔断 |
这层解决的是：
- 用户请求怎么进集群
- 服务实例变了，调用方怎么还能稳定访问
- gRPC / HTTP / WebSocket 流量怎么被正确代理
- 谁负责重试、超时、熔断、鉴权、灰度
容易犯的错： 把流量层和业务层混在一起，把网关写成“超级业务服务”，或者把业务服务误叫 data plane。
第三层：业务层才是“你真正写的微服务”
业务层就是你平时说的那些服务实例：
user-serviceorder-servicepayment-serviceinventory-servicenotification-service- 各种 async consumer / worker / cron job
这些东西的共同点不是“都用 RPC”，而是：
- 它们承载领域逻辑
- 它们直接对业务语义负责
- 它们的扩缩容依据通常是业务吞吐、CPU、队列长度、延迟目标
这层回答的是：
- 订单怎么创建
- 支付怎么扣款
- 库存怎么冻结
- 消息怎么发送
而不是：
- Pod 该调度到哪台 node
- HTTP 请求该按哪个 header 灰度
- 证书该怎么轮换
第四层：状态层才是大多数业务系统真正的“重心”
很多人学微服务只盯服务，不盯状态，这是幼稚病。
一个完整系统里，状态层通常包括：
| 类型 | 典型系统 | 作用 |
|---|---|---|
| 关系数据库 | PostgreSQL / MySQL | 持久业务数据、事务边界 |
| 缓存 | Redis | 降低读延迟、做热点缓存、短期状态 |
| 消息队列 / 事件流 | Kafka / RabbitMQ / NATS | 异步解耦、削峰、事件传播 |
| 对象存储 | S3 / OSS / MinIO | 文件、图片、归档数据 |
| 搜索引擎 | Elasticsearch / OpenSearch | 搜索和分析 |
一句话：
业务层负责“算”，状态层负责“记”。
一个没有数据库、缓存、消息系统的“微服务集群”，通常只是 demo，不是生产系统。
横切支撑层不是第五等公民，而是运维生死线
严格说它不是单独业务层，而是横跨全系统：
- Metrics / Logs / Traces
- Alerting
- Secret / Config
- CI/CD
- 镜像仓库
- 证书和身份
- 备份与恢复
为什么把它单独点出来？因为很多团队默认“先把服务写完，监控以后再说”，最后得到的是能跑但不可运维的系统。
如果没有这些东西：
- 出问题你不知道哪里坏了
- 密钥没法统一轮换
- 发布没有回滚手段
- 数据恢复靠祈祷
一个典型微服务集群的全景图
外部用户 / App / Browser
|
Load Balancer / DNS
|
Ingress / API Gateway
|
+---------------+----------------+
| |
user-service order-service
| |
+-------------+------------------+
|
service-to-service RPC
(direct or via service mesh)
|
+-----------+-----------+
| |
PostgreSQL Redis
|
Kafka / Object Storage / Search
旁边一直存在但不在业务热路径里：
- Kubernetes control plane
- 调度器 / 控制器 / kubelet / runtime
- 可观测性、配置、密钥、CI/CD、备份恢复这张图真正想表达什么
- 用户请求看到的只是入口和业务服务
- 平台层在背后维持工作负载存在
- 流量层在中间决定请求如何到达正确实例
- 状态层决定系统有没有真正的数据基础
- 支撑层决定系统能不能长期运行
Kubernetes、Service Mesh、RPC 服务实例分别落在哪层
| 对象 | 它属于哪层 | 为什么 |
|---|---|---|
| Kubernetes control plane | 平台层 | 负责调度、对象存储、控制循环 |
| Worker nodes / kubelet / runtime | 平台层 | 执行容器与节点级生命周期 |
| API Gateway / Ingress / Envoy edge | 流量层 | 处理入口流量和路由治理 |
| Mesh sidecar / waypoint / kube-proxy | 流量层 | 处理服务间通信与服务访问语义 |
user-service / order-service | 业务层 | 执行业务逻辑 |
| PostgreSQL / Redis / Kafka | 状态层 | 承载数据、缓存、事件 |
| Prometheus / Loki / Tempo / OTel Collector | 横切支撑层 | 负责观测与排障 |
所以你之前那个问题“完整集群是不是包含 data plane、control plane、各种 RPC 服务实例”，更准确的回答是：
是，但那只是其中一部分。
完整集群至少还包含平台执行层、状态层，以及一整套横切支撑设施。
与常见错误理解的对比
| 错误理解 | 为什么错 | 正确说法 |
|---|---|---|
| 微服务集群 = 一堆服务实例 | 漏掉平台、流量、状态、支撑设施 | 服务实例只是业务层 |
| 有 Kubernetes 就等于平台齐了 | K8s 只覆盖平台层核心，不自动替你解决流量治理、数据和运维体系 | 还需要网关、状态系统、观测等 |
| 有 API Gateway 就是完整架构 | Gateway 只解决一部分 north-south 流量问题 | 不能替代平台层和状态层 |
| 无状态服务多就代表系统简单 | 数据最终都沉到状态层 | 真复杂度往往在数据库、缓存、消息链路 |
| 监控以后再补 | 生产系统没有观测就等于盲飞 | 支撑层是基础设施，不是装饰 |
Pitfalls
1. 只画服务框，不画状态系统
架构图只写 user-service -> order-service -> payment-service，数据库和队列一句带过。这种图对真实复杂度几乎没有解释力。
避免方式： 任何微服务架构图都把数据库、缓存、消息队列单独画出来。
2. 把 Kubernetes 当“完整微服务平台”
Kubernetes 很重要，但它主要解决平台层问题。它不会自动替你解决 API 设计、服务边界、灰度策略、数据一致性和业务可观测性。
避免方式： 把 K8s 看成底座，不要把底座当整栋楼。
3. 把流量治理层和业务层写在一个进程里
网关里塞鉴权、聚合、转码、灰度、限流、业务编排，最后变成“超级边车”或“超级网关”，复杂度反而比服务内部更高。
避免方式： 流量层只承载横切流量能力；业务语义继续留在业务层。
4. 忽略横切支撑层
日志、指标、trace、配置、密钥、CI/CD 都不在核心请求路径上，但它们决定了系统是否可运维。
避免方式： 把它们当系统组成部分，而不是“上线后再说”的附属工程。
5. 把“外部托管数据库”当成“不属于系统”
即使 PostgreSQL 是云厂商托管的，它依然是你系统的状态层核心组成。托管不等于不重要。
避免方式： 组件是否自建和组件是否属于系统，是两回事。
6. 误以为“服务多”就等于“微服务成熟”
20 个服务但没有稳定入口、没有统一观测、没有发布规范、没有状态治理，只是 20 个孤岛进程，不是成熟的微服务平台。
避免方式： 先看层次是否完整，再看服务数量。
Checklist
- 画系统时至少分出平台层、流量层、业务层、状态层
- 业务服务之外，显式标出数据库、缓存、消息队列、对象存储
- 区分 north-south 和 east-west 流量，不要只画入口网关
- 把 Kubernetes control plane 和业务服务实例分开描述
- 把可观测性、配置、密钥、发布流水线视为系统组成部分
- 不要把“是否托管”混同于“是否属于系统”
- 如果某层缺失，就别急着说“这是完整的微服务集群”
信息来源
- Kubernetes 官方文档：Cluster Architecture（确定）
- Kubernetes 官方文档：Controllers（确定）
- Kubernetes 官方文档：Service（确定）
- Istio 官方文档：Architecture（确定）
- Envoy 官方文档：What is Envoy（确定）
- 本文对“平台层 / 流量层 / 业务层 / 状态层 / 横切支撑层”的五层归纳，属于基于上述官方职责边界做的工程抽象，不是单一官方标准命名（确定：这是明确标注的工程归纳）