微服务组件选型与能力归属：REST、Dubbo、gRPC、MQ、Gateway、Spring Cloud与Mesh
组件选型不是比较谁“性能最高”，而是明确业务通信语义、团队语言、契约、延迟、可靠性、运维能力和迁移成本。更重要的是能力归属：如果Gateway、Feign、Service Mesh和业务代码同时做负载均衡、重试、超时和熔断，一次逻辑请求会产生不可预测的物理尝试。
本页把通信协议、服务发现、入口、客户端治理、代理治理和业务正确性放在同一张图中，给出存量JDK 8/Boot 2与Java 17+/Boot 3的选型路径。
一、学习目标
- 根据同步查询、命令和异步事件选择REST、Dubbo、gRPC或MQ。
- 区分南北向Gateway与东西向Service Mesh。
- 区分客户端发现、平台Service发现和代理发现。
- 为负载、Deadline、重试、熔断、认证、mTLS和幂等指定Owner。
- 识别双层负载、多层重试和超时倒挂。
- 为JDK 8存量和Java 17+/Boot 3新系统制定演进路线。
二、一次请求的能力分层
flowchart TD
A["公网客户端"] --> B["CDN、WAF、Ingress或Nginx"]
B --> C["API Gateway"]
C --> D["REST、Dubbo或gRPC调用方"]
D --> E["Service Mesh代理或Kubernetes数据面"]
E --> F["Provider业务服务"]
F --> G["数据库、缓存和MQ"]| 层 | 最适合负责 | 不应负责 |
|---|---|---|
| WAF/Ingress | TLS入口、基础路由、攻击防护 | 订单状态机 |
| API Gateway | 用户认证、API配额、协议聚合、南北向路由 | 所有内部事务 |
| RPC/HTTP Client | 序列化、连接、Deadline、一次实例选择 | 全局流量入口 |
| Service Mesh | 工作负载mTLS、通用东西向路由与遥测 | 用户退款权限和幂等 |
| Provider | 业务校验、幂等、事务、领域错误 | 信任客户端自报身份 |
| MQ | 持久异步解耦、削峰、重放 | 立即返回同步查询结果 |
三、REST、Dubbo、gRPC、MQ怎样选
| 维度 | REST/HTTP JSON | Dubbo | gRPC | MQ事件 |
|---|---|---|---|---|
| 交互 | 同步请求响应 | 同步RPC为主 | 同步与四类流 | 异步生产消费 |
| 契约 | OpenAPI/JSON | Java接口、IDL/序列化 | Protobuf IDL | Event Schema |
| 跨语言 | 很强 | Java生态最自然 | 很强 | 取决于Schema与客户端 |
| 浏览器友好 | 强 | 弱 | 原生浏览器有边界 | 不直接面向浏览器 |
| 流式 | SSE/WebSocket等另行设计 | 依版本/协议 | 原生HTTP/2流 | 持久事件流 |
| 离线堆积 | 不适合 | 不适合 | 连接断开需自建恢复 | 核心能力 |
| 典型场景 | 外部API、普通内部查询 | Java内部高治理RPC | 多语言强契约、流式采集 | 通知、CDC、削峰、最终一致 |
3.1 REST
优先用于公网/合作方API、CRUD和可调试的内部HTTP。优势是生态成熟、代理友好；代价是JSON体积、弱类型消费者和行为契约需要额外治理。使用OpenAPI、稳定错误码、Idempotency-Key和版本兼容。
3.2 Dubbo
适合Java服务间调用、已有Dubbo治理体系、接口级/应用级发现和丰富Cluster策略。它不是“比HTTP快所以必选”；团队要能维护注册发现、序列化兼容、线程模型和SPI扩展。写接口通常Failfast并业务幂等，不能盲目Failover重试。
3.3 gRPC
适合多语言强类型契约、低开销二进制和流式采集。要治理Protobuf兼容、HTTP/2长连接负载、流控、Deadline和Resolver。浏览器、调试工具、L7代理和团队经验也要评估。
3.4 MQ
适合不需要立即结果、需要持久缓冲、削峰、广播和最终一致的动作。它引入延迟、重复、乱序、堆积和Schema演进，消费者必须幂等。不能为了“解耦”把用户必须立即知道结果的查询强行改成消息。
四、通信方式决策流程
flowchart TD
A["业务动作"] --> B{"调用方是否必须立即得到结果"}
B -- "否" --> C{"是否需要持久堆积、重放或广播"}
C -- "是" --> D["选择MQ并设计幂等、顺序和补偿"]
C -- "否" --> E["评估异步任务或流式连接"]
B -- "是" --> F{"是否公网、浏览器或合作方API"}
F -- "是" --> G["REST/OpenAPI"]
F -- "否" --> H{"是否多语言强IDL或双向流"}
H -- "是" --> I["gRPC/Protobuf"]
H -- "否" --> J{"是否已有成熟Java Dubbo体系"}
J -- "是" --> K["Dubbo"]
J -- "否" --> G一次业务可组合：创建订单REST同步返回受理结果，Outbox发送OrderCreated事件，内部库存可用Dubbo/gRPC查询。不要强求全系统只允许一种协议。
五、服务发现与负载均衡归属
| 模式 | 地址快照 | 谁选实例 | 例子 |
|---|---|---|---|
| 客户端发现 | 客户端内存 | Feign/Dubbo/gRPC客户端 | Nacos、Consul API、Dubbo Registry |
| 平台四层 | EndpointSlice/节点规则 | kube-proxy/eBPF按连接 | ClusterIP Service |
| DNS客户端发现 | DNS缓存 | 客户端Resolver | Headless Service |
| 代理发现 | 代理Cluster/EDS | Envoy/Sidecar | Service Mesh |
架构必须选清主要实例选择层。Feign先选Pod后又访问ClusterIP，或者gRPC只解析ClusterIP却期待按RPC均衡，都会形成边界混乱。双层负载不是一定错误，但必须明确每层目标和观测。
六、Gateway与Service Mesh区别
| 维度 | API Gateway | Service Mesh |
|---|---|---|
| 流量 | 南北向为主 | 东西向为主 |
| 身份 | 用户、App、合作方 | 工作负载身份 |
| 路由 | 外部API、聚合、协议转换 | 服务版本、Endpoint、Locality |
| 安全 | OAuth2/JWT、API Key、配额 | mTLS、服务间授权 |
| 业务感知 | 可做有限API编排 | 应尽量通用 |
常见组合：公网经过Ingress/WAF到Gateway，Gateway调用内部服务时也经过Mesh。用户认证放Gateway并由服务端再次执行资源授权；Mesh mTLS证明“哪个工作负载”，不能证明“哪个用户能退款”。
七、能力所有权矩阵
| 能力 | 推荐主要Owner | 其他层职责 |
|---|---|---|
| 用户认证 | Gateway + Provider安全框架 | Mesh只保证工作负载身份 |
| 工作负载mTLS | Mesh/基础设施 | 应用不重复手写证书轮换 |
| 端到端Deadline | 业务入口与调用SDK | 代理尊重剩余预算 |
| 实例负载 | 客户端或Mesh或平台中明确一层 | 其他层避免无意义二次选择 |
| 重试 | 最了解错误语义的一层 | 其他层关闭或共享预算 |
| 熔断 | 靠近调用依赖的一层 | Gateway只保护入口聚合 |
| 限流 | 各层保护各自资源 | 阈值、身份和指标不能重复 |
| 幂等 | Provider业务与事实库 | Gateway/Mesh不能替代 |
| 分布式事务 | 业务服务、消息与协调器 | 代理不参与业务提交 |
| 观测 | OTel/Micrometer/Mesh协作 | 统一语义并去重 |
八、最危险的重复治理
flowchart TD
A["一次用户请求"] --> B["Gateway最多2次"]
B --> C["Mesh最多2次"]
C --> D["Feign最多3次"]
D --> E["最坏12次物理Attempt"]
E --> F["下游过载和重复副作用"]治理方法：
- 列出每层Connect、Read、Per-try和总超时。
- 入口建立Deadline，每层只使用剩余预算。
- 把逻辑请求数和物理Attempt分别监控。
- 写操作默认不做透明重试，除非有幂等与事实查询。
- 为额外Attempt设置全局Retry Budget。
九、常见技术栈方案
9.1 JDK 8 / Boot 2.7存量Spring Cloud
可能存在Eureka、Ribbon、Hystrix、Zuul、Sleuth。不要一次替换全部：先补超时、幂等、指标和契约测试，再逐项迁移到LoadBalancer、Resilience4j/Sentinel、Gateway和标准Tracing。JDK 8兼容版本必须按项目BOM确认。
9.2 Java 17+ / Boot 3.x新系统
常见组合：Nacos/Consul/Kubernetes发现，OpenFeign/HTTP Interface/RestClient或WebClient，Spring Cloud LoadBalancer，Gateway，Sentinel或Resilience4j，Micrometer Observation/Tracing与OpenTelemetry。选择与具体Boot版本匹配的Spring Cloud发行列，不能混用Boot 2教程依赖。
9.3 云原生多语言
Kubernetes Service负责稳定寻址，gRPC/REST负责契约，Mesh负责mTLS和通用流量治理，Gateway负责外部API，MQ负责异步事件。减少每种语言重复SDK，但业务幂等和状态机仍在服务内。
十、商业场景选型
| 场景 | 推荐组合 | 原因 |
|---|---|---|
| 移动端查询订单 | REST + Gateway | 浏览器/客户端友好、认证与缓存成熟 |
| Java订单调用库存 | Dubbo或REST/Feign | 根据现有治理与团队栈选择 |
| 多语言实时采集 | gRPC双向流 + 断点协议 | 强IDL、流控和长连接 |
| 支付后同步积分/ES | Outbox + MQ | 不阻塞支付，失败可重放 |
| 外部医院接口 | REST + 独立Bulkhead | 合作方兼容和故障隔离 |
| 内部多语言零信任 | REST/gRPC + Mesh mTLS | 统一工作负载身份与遥测 |
十一、JDK 8 Demo：计算多层Attempt并检查预算
public class AttemptBudgetDemo {
static int attempts(int gateway, int mesh, int client) {
return Math.multiplyExact(Math.multiplyExact(gateway, mesh), client);
}
public static void main(String[] args) {
int physical = attempts(2, 2, 3);
int retryBudget = 2;
System.out.println("physicalAttempts=" + physical);
System.out.println("withinBudget=" + (physical - 1 <= retryBudget));
}
}输出应为12次且超过额外2次预算。生产还要按时间窗口、目标服务和并发控制Retry Budget。
十二、迁移步骤
- 盘点当前调用图、协议、实例选择层和治理配置。
- 建立契约测试、Attempt指标和端到端Deadline基线。
- 明确每项能力Owner并关闭重复治理。
- 先迁移低风险只读调用，灰度比较成功率和P99。
- 写调用验证幂等、结果查询与回滚窗口。
- 旧组件退出前确认流量为零、历史消息和灾备版本已迁移。
十三、生产Runbook
13.1 一次请求下游收到多次
按traceId和幂等键汇总Attempt，逐层检查Gateway、Mesh、Feign/Dubbo/gRPC和业务循环重试。确认超时发生在提交前还是响应丢失，先用事实查询止住重复副作用，再统一重试Owner。
13.2 扩容后流量不均
确认客户端看到Pod列表还是ClusterIP，查看Subchannel/TCP连接和HTTP/2复用，检查SessionAffinity、Mesh EDS和拓扑策略。扩容只增加新连接候选，不迁移旧连接。
13.3 401、403或mTLS错误混在一起
区分用户认证、资源授权和工作负载TLS。Gateway 401不等于Mesh证书失败，Mesh身份通过也不等于用户有业务权限。
十四、常见误区
| 误区 | 后果 |
|---|---|
| gRPC一定比REST更适合所有内部调用 | 调试、浏览器和团队成本被忽略 |
| MQ更解耦所以全部异步 | 需要立即结果的流程复杂化 |
| 上Mesh后删除业务治理 | 幂等、事务和领域降级缺失 |
| Gateway和Mesh二选一 | 南北向与东西向职责不同 |
| 每层都重试更可靠 | Attempt乘法放大 |
| 组件越多能力越强 | 所有权不清导致冲突和不可观测 |
十五、面试主线
先按同步/异步、外部/内部、多语言/Java和流式需求选通信协议；再明确服务发现和实例选择层；区分Gateway用户入口与Mesh工作负载治理；用能力所有权矩阵消除重复负载、重试和熔断；最后结合JDK 8存量迁移与Java 17+/Boot 3新栈说明落地。
标准回答见微服务组件选型面试题。
十六、关联知识点
本章小结
最好的架构不是组件最多，而是每项能力只有清晰的主要Owner，并且业务语义、故障窗口和观测证据可解释。REST、Dubbo、gRPC和MQ可以组合；Gateway、Spring Cloud、Kubernetes和Mesh也可以组合，但必须消除无计划的重复治理。