技术选型:为什么最终选了 Spring Cloud Alibaba + Dubbo 3

Tue, 09 Jun 2026 00:00:00 +0000

技术选型:为什么最终选了 Spring Cloud Alibaba + Dubbo 3

Java Web 微服务系列 · 第 4 篇 · 技术选型阅读时长:约 45 分钟本文写于 2026 年 6 月配套版本:Spring Cloud Alibaba 2022.0.0.0 / Spring Cloud 2022.0.x / Spring Boot 3.x / Dubbo 3.2.x

引子:第一次技术评审会上我翻的车

2019 年我第一次主导微服务架构的技术评审,信心满满地写了一份**《微服务技术选型方案 v1.0》**——30 多页 PPT,封面是 Spring Cloud 全家桶,封底是 Netflix OSS 矩阵。

会上 CTO 第一个问题:"Netflix OSS 不是 2018 年就进维护模式了吗?你为什么还在用 Zuul、Hystrix、Ribbon?这些组件再过一年就只剩 EOL 公告了。"

我答不上来。

第二个问题是 DBA 提的:“Hystrix 停更,你打算用什么做熔断降级?Resilience4j 吗?它和 Spring Cloud 的集成做完了吗?限流规则怎么持久化?”

第三个问题是测试主管:“你选 Feign 做内部调用,Mock 怎么做?WireMock 集成测过了吗?”

第四个问题是 SRE 主管:“Dubbo 在你们方案里完全没提。咱们的核心交易系统跑了 3 年 Dubbo,你打算全部改成 Feign?业务改造的工时你估过吗?为什么不能内部用 Dubbo、对外用 REST?”

会议开了 2 小时,30 多页 PPT 被翻烂了 3 个问题,最后 CTO 说:"这周重写,先把选型原则列出来,再选技术。别上来就写 PPT。"

这是 2019 年我交的第一笔"学费"。本文把那次踩过的坑,以及后来慢慢悟出来的技术选型方法论,完整地写出来。本文 8000+ 字,一次性把"为什么是 Spring Cloud Alibaba + Dubbo 3 + 对外 RESTful"讲透——给所有在做技术选型的同行参考。

一、核心原则:好的技术选型长什么样

技术选型不是"哪个最火选哪个",也不是"哪个最难选哪个"。我把这些年踩过的坑总结成5 条铁律——前 3 条是"必选条件",后 2 条是"加分项"。

1.1 业务匹配 > 技术先进

再先进的技术,解决不了你的业务问题,就是垃圾。

🛑 误区警示:技术先进性陷阱

“Kubernetes 是未来,Service Mesh 是未来,ServiceComb 是 Apache 顶级项目……所以我们要上!”

错。先进 ≠ 适用。某电商公司花 200 万引入 Service Mesh,结果团队没人懂 Envoy 配置,生产事故频发,最终回滚到 Spring Cloud。这就是"为了先进而先进"的代价。

判断方法:这个技术是解决了我们当前 3-6 个月内的具体痛点,还是为未来 2-3 年画饼?

1.2 团队能力 > 流行度

没有银弹,只有适合团队的技术。

一个 5 人的小团队,上 Istio + Envoy + Spring Cloud 全家桶 + 6 个中间件,就是灾难——没人能 hold 住,出了问题没人能 debug。

判断方法:你团队里有没有人能讲清楚这个技术的核心原理 + 至少 2 个常见坑?如果 5 个人的团队只有 1 个人懂,这就是高风险。

1.3 社区活跃 > 文档齐全

文档可以补,社区活跃不能补。

GitHub Stars > 30k: 主流框架级别(Spring Cloud、Spring Cloud Alibaba 都满足)
最近 6 个月有 release: 框架还活着
Issue 响应时间 < 7 天: 出了问题能找人问
中文社区活跃: 国内公司尤其重要(Stack Overflow 答案少,需要 Gitee/思否/掘金)

反面教材:Spring Cloud Netflix OSS 在 2018 年底宣布进维护模式——Netflix 不再用它,但 Spring Cloud 还在集成它的代码。结果 Hystrix 2020 年 EOL、Zuul 1.x 2022 年 EOL、Archaius 2021 年 EOL,大量历史项目不得不重写。

1.4 避免重复造轮子

💡 原理:开源的本质是"复用别人的代码,自己的代码让别人复用"

你的业务代码、领域模型、核心算法才是真正值钱的部分。注册中心、配置中心、熔断限流、消息队列,业界有成熟方案就别自己写。

自己写一个 ZK 注册中心 3 个月,业界用 Nacos 1 周就搞定。省下的人力写业务逻辑,产出高 10 倍。

例外:如果某组件在性能/合规/功能上有硬性要求,自己造轮子是合理的。但要先确认"真的没有现成方案满足",不要"为了 KPI 自研"。

1.5 留有演进空间

今天选的方案,3 年后大概率要换。技术选型要选"进可攻退可守“的:

进可攻:框架能跟得上社区演进(Spring Cloud 版本升级、Spring Boot 升级)
退可守:万一被淘汰,业务代码能"低代价"迁移到其他方案

判断方法:框架是不是"被绑定"在某个厂商?Dubbo 当年绑定阿里,2014-2017 几乎停止维护,吓得所有公司都迁移到 Spring Cloud。Spring Cloud Alibaba 现在由阿里持续投入,但核心组件(Nacos/Sentinel/Seata)都是 ASF/Apache 项目,真到那一天迁移成本低。

📌 实践:5 条铁律的检查清单

在做最终决策前,把这 5 条打印出来,逐条回答:

☐ 这个技术解决了我们当前 3-6 个月的具体痛点吗?

☐ 团队里有 ≥ 2 人能讲清楚它的核心原理 + 2 个常见坑吗?

☐ GitHub Stars > 30k 且最近 6 个月有 release吗?

☐ 我们能用开源方案避免自研吗?

☐ 3 年后业务代码能低代价迁移吗?

5 条全 Yes,放心选。4 Yes 1 No,谨慎评估。3 Yes 2 No,立即否决。

二、主流方案横评:4 个候选的 PK

明确原则后,我们把当时(2024 年,本文写于 2026 年但内部评估在 2024)市面上 4 个主流的 Java 微服务技术栈摆到台面上,9 个维度对比。

2.1 4 个候选方案

方案 A:Spring Cloud Netflix OSS(纯 Netflix 系)

注册中心:Eureka
配置中心:Spring Cloud Config + Git
熔断降级:Hystrix(已 EOL)
网关:Zuul 1.x(已 EOL)
客户端负载均衡:Ribbon(已 EOL)
内部调用:Feign + Ribbon

方案 B:Spring Cloud Consul 系

注册中心 + 配置中心:Consul
熔断:Resilience4j
网关:Spring Cloud Gateway
内部调用:OpenFeign

方案 C:纯 Dubbo 系(非 Spring Cloud)

注册中心:ZooKeeper / Nacos
内部调用:Dubbo RPC
网关:Dubbo 自带 / Sentinel
配置中心:Disconf / Apollo / Nacos

方案 D:Spring Cloud Alibaba(SCA)+ Dubbo 3 混合(本文最终选)

注册中心 + 配置中心:Nacos
熔断限流:Sentinel
分布式事务:Seata
消息:RocketMQ
内部调用:Dubbo 3(Triple 协议)
对外网关:Spring Cloud Gateway
客户端 REST:Spring MVC + OpenFeign

2.2 9 维度对比表

维度	A. Netflix OSS	B. Spring Cloud Consul	C. 纯 Dubbo	D. SCA + Dubbo 3
注册中心	Eureka(2.x 已停更)	Consul(强一致,运维重)	ZooKeeper(运维重)	Nacos 2.x(AP/可切 CP,运维轻)
配置中心	Spring Cloud Config(界面弱)	Consul KV(无版本管理)	Apollo/Nacos 二选一	Nacos 内置(带版本/灰度/监听)
熔断降级	Hystrix(EOL)	Resilience4j(社区小)	Sentinel(需独立集成)	Sentinel(Alibaba 原生,控制台完善)
API 网关	Zuul 1.x(EOL)	Spring Cloud Gateway	需自选/自研	Spring Cloud Gateway(响应式)
内部调用协议	HTTP/JSON(Feign)	HTTP/JSON(Feign)	Dubbo 协议(二进制)	Triple(gRPC/HTTP2,跨语言)
分布式事务	无官方方案	无官方方案	无官方方案	Seata(AT/TCC/SAGA/XA)
消息队列	需自选(Kafka/RabbitMQ)	同左	同左	RocketMQ(原生集成,事务消息)
社区活跃度	停止维护	中等	高	高(国内主流,中文资料丰富)
国内生产案例	大量遗留项目	中型公司	阿里系老项目	阿里、滴滴、字节(部分)、小米等头部

🎯 避坑点:为什么 A 方案直接被否

Netflix OSS 在 2018 年宣布进维护模式,2020-2022 年多个核心组件 EOL:

Hystrix:EOL 2020 年

Ribbon:EOL 2022 年

Zuul 1.x:EOL 2022 年

Archaius:EOL 2021 年

这意味着所有基于 Netflix OSS 的项目都要做技术债清理。还在用 A 方案的项目,3-5 年内必须迁移。

2.3 4 个候选的优缺点总结

方案 A(Spring Cloud Netflix OSS)

✅ 优点:文档多、入门快、很多老项目在用
❌ 缺点:多个核心组件已 EOL,长期不可持续
❌ 致命伤:Netflix 自己都不用这套了
结论:不选

方案 B(Spring Cloud Consul)

✅ 优点:Consul 自带服务发现 + 配置中心 + 健康检查,组件少
❌ 缺点:Consul 是 Go 写的,JVM 团队排查问题需要跨语言;Resilience4j 社区相对小
⚠️ 适用:中等规模、对 Consul 运维有经验的团队
结论:备选

方案 C(纯 Dubbo 系)

✅ 优点:内部 RPC 性能强(Dubbo 协议);社区活跃
❌ 缺点:Spring Cloud 生态对接需要自己包装;前端/移动端调用 Dubbo 不方便(Dubbo 接口没有 Swagger 文档)
⚠️ 适用:已有 Dubbo 基础且外部调用走独立 REST 服务的项目
结论:部分选(只取其内部 RPC 优势)

方案 D(SCA + Dubbo 3 混合)

✅ 优点:Nacos/Sentinel/Seata/RocketMQ 全家桶,国内生态成熟,Dubbo 3 Triple 协议兼顾性能与跨语言
⚠️ 缺点:组件多,学习曲线较陡;Seata 分布式事务对业务侵入较高
✅ 结论:选

💡 原理:为什么是"混合"而不是单一技术栈

“微服务全家桶"听上去很美好,但实际工程中:

内部 RPC:性能敏感,Dubbo 3 Triple 协议(基于 HTTP/2)比 Feign + JSON 快 3-5 倍

对外 REST:生态好、易调试、跨语言、Swagger/Knife4j 文档友好

强制只用一种,要么内部性能差(全 Feign),要么对外不友好(全 Dubbo)

混合是工程最优解——各取所长,代价是要多维护一套调用框架。

三、为什么最终选了 Spring Cloud Alibaba

5 个核心理由,从业务匹配到社区生态,逐条拆解。

3.1 组件全家桶,开箱即用

Spring Cloud Alibaba 提供完整闭环:

关注点	组件	对标 Netflix
注册中心	Nacos	Eureka
配置中心	Nacos(同一集群)	Spring Cloud Config
熔断限流	Sentinel	Hystrix
分布式事务	Seata	(无对标)
消息队列	RocketMQ	(无对标)
分布式追踪	SkyWalking(可选)	Sleuth + Zipkin
API 网关	Spring Cloud Gateway	Zuul/Gateway
内部 RPC	Dubbo 3(选配)	Feign + Ribbon

一套打天下,不需要像方案 B 那样东拼西凑。

3.2 国内生态成熟,中文资料丰富

Nacos:阿里开源,GitHub Stars 30k+,中文文档齐全
Sentinel:阿里开源,GitHub Stars 22k+,控制台直接用
Seata:阿里开源,GitHub Stars 26k+,国内金融/电商大量案例
RocketMQ:阿里开源,Apache 顶级项目,GitHub Stars 21k+
Dubbo:阿里开源,Apache 顶级项目,GitHub Stars 40k+

📌 实践:中文资料的价值

出了问题去 Stack Overflow 一搜,纯 Netflix 系有 90% 答案,纯 Dubbo 系有 70%,Spring Cloud Alibaba 只有 50%。但 SCA 在思否、掘金、博客园、CSDN 的中文资料比英文还多——这是国内做技术的隐形优势。

3.3 与 Dubbo 兼容,内部 RPC 高性能

这是关键。Spring Cloud Alibaba 官方支持 Dubbo 作为 RPC 框架,通过 Nacos 做注册中心,Dubbo 服务和 Spring Cloud 服务可以互相发现。

这意味着:

内部调用:走 Dubbo 3 Triple 协议(基于 HTTP/2,性能接近 gRPC)
对外调用:走 Spring MVC + OpenFeign(RESTful)
注册中心统一:全部注册到 Nacos,服务治理统一

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


<!-- Spring Cloud Alibaba + Dubbo 3 同时引入,自动适配 -->
<dependency>
 <groupId>com.alibaba.cloud</groupId>
 <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>
<dependency>
 <groupId>org.apache.dubbo</groupId>
 <artifactId>dubbo-spring-boot-3-starter</artifactId>
 <version>3.2.10</version>
</dependency>

3.4 二次封装好,踩坑成本低

Spring Cloud Alibaba 不只是"组件打包”,还做了深度封装:

Nacos 集成:Spring Boot 风格的 bootstrap.yml 配置,自动注册
Sentinel 集成:注解 @SentinelResource 一行代码接入限流
Seata 集成:@GlobalTransactional 注解开启全局事务
RocketMQ 集成:@RocketMQMessageListener 注解消费消息

对比自己集成:Netflix 体系里 Hystrix 集成 Spring Cloud 需要自己写降级逻辑、Sentinel 已经内置了所有模式。

3.5 商业化平滑,演进路径清晰

纯开源是底线,商业化是加分项。Spring Cloud Alibaba 的核心组件都是 ASF/Apache 顶级项目或独立开源项目,不绑定阿里云。但在需要时:

Nacos → 阿里云 MSE(Nacos 商业版):零代码迁移
Sentinel → 阿里云 AHAS:控制台更强大
Seata → 阿里云 GTS:金融级分布式事务
RocketMQ → 阿里云 RocketMQ 商业版:运维托管

演进路径:开源版 → 商业版 → 阿里云原生——这套路径在阿里内部被验证过,适合"先小规模验证,再大规模上云"的渐进式策略。

🛑 误区警示:不要被"开源+商业版"绑定

万一阿里云商业版涨价,或者你想换腾讯云/AWS,核心代码仍然是 Apache 开源,你可以自建或迁移到其他云。这和"Spring Cloud 绑定 Pivotal/VMware"是同一逻辑——底层开源是退路,商业版是快车道。

四、SCA 核心组件拆解

SCA 的 6 大核心组件逐一拆解。每个组件给出:是什么 / 解决什么问题 / 核心特性 / 版本注意事项。

4.1 Nacos:注册中心 + 配置中心二合一

是什么:阿里开源的动态服务发现、配置管理和服务管理平台。GitHub Stars 30k+。

解决什么问题:

服务注册与发现:服务启动时注册到 Nacos,调用方从 Nacos 拉取服务列表
动态配置:配置变更实时推送到所有客户端,无需重启
健康检查:自动剔除不健康实例

核心特性:

AP/CP 模式可切换:默认 AP(可用性优先,类似 Eureka),集群模式可切 CP(强一致,类似 ZooKeeper)
配置灰度:支持 Beta 发布(指定 IP 生效)、灰度比例、配置版本回滚
Namespace + Group + DataId:三段命名空间,适合多环境/多租户

版本注意:

Nacos 2.x 必须用 Nacos 2.x 客户端(1.x 客户端与 2.x 服务端不兼容!)
Spring Cloud Alibaba 2022.0.0.0 内置 Nacos Client 2.3.x
Nacos 集群至少 3 节点(避免脑裂),生产环境强烈不建议单机模式

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


# bootstrap.yml 关键配置
spring:
 application:
 name: order-service
 cloud:
 nacos:
 discovery:
 server-addr: nacos-cluster:8848
 namespace: prod  # namespace 隔离
 group: ORDER_GROUP  # 业务分组
 config:
 server-addr: nacos-cluster:8848
 file-extension: yaml
 refresh-enabled: true # 开启配置自动刷新

4.2 Sentinel:流量治理的瑞士军刀

是什么:阿里开源的流量控制、熔断降级、系统负载保护组件。GitHub Stars 22k+。

解决什么问题:

限流:QPS 限流、并发线程数限流、关联限流(订单限流连带支付限流)
熔断:慢调用比例、异常比例、异常数三种熔断策略
热点参数限流:同一接口不同参数分别限流(如 /order/query?id=100 和 /order/query?id=200 单独计数)
系统自适应限流:根据 CPU、Load、入口 QPS 动态调整限流阈值
授权规则:黑白名单(只允许特定 IP 访问)

对比 Hystrix:

Hystrix 已 EOL,Sentinel 是事实标准
Sentinel 控制台开箱即用(Hystrix Dashboard 早已不维护)
Sentinel 支持秒级规则推送(Hystrix 是分钟级)

版本注意:

Sentinel 1.8.x 配套 SCA 2022.0.0.0
Sentinel Dashboard 必须独立部署,Sentinel Client 启动时连接 Dashboard 拉取规则

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


// 注解式限流
@SentinelResource(value = "createOrder",
 blockHandler = "handleBlock",
 fallback = "handleFallback")
public Order createOrder(OrderRequest req) {
 // 业务逻辑
 return orderRepository.save(req.toEntity());
}

public Order handleBlock(OrderRequest req, BlockException ex) {
 throw new BusinessException("系统繁忙,请稍后重试");
}

public Order handleFallback(OrderRequest req, Throwable ex) {
 log.warn("订单创建降级", ex);
 return Order.deferred(req);
}

4.3 Seata:分布式事务的标准答案

是什么:阿里开源的分布式事务解决方案,提供 AT、TCC、SAGA、XA 四种模式。GitHub Stars 26k+。

解决什么问题:

跨服务的数据一致性问题(下单扣库存 + 创建订单 + 扣账户余额)
4 种事务模式,适配不同业务场景

4 种模式对比:

模式	一致性	性能	业务侵入	适用场景
AT	最终一致	高	低(自动回滚)	80% 业务,推荐首选
TCC	最终一致	高	高(3 个方法)	高并发/金融
SAGA	最终一致	中	中(补偿逻辑)	长事务/跨多服务
XA	强一致	低	低(数据库原生)	强监管行业

版本注意:

Seata Server 必须独立部署(1.6+ 性能优化明显)
Seata AT 模式依赖 undo_log 表(在每个业务库创建,Seata 自动管理)
业务库需要开启 binlog(MySQL)或 WAL(PostgreSQL)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


// @GlobalTransactional 一行开启全局事务
@GlobalTransactional(name = "create-order", rollbackFor = Exception.class)
public OrderResult createOrder(OrderRequest req) {
 // 1. 创建订单
 Order order = orderService.create(req);
 // 2. 扣库存(Dubbo 调用)
 inventoryService.deduct(req.getSkuId(), req.getQuantity());
 // 3. 扣账户余额(Dubbo 调用)
 accountService.debit(req.getUserId(), order.getAmount());
 return OrderResult.success(order);
}
// 任一环节抛异常,Seata 自动回滚所有操作

🎯 避坑点:Seata 选模式的决策树

业务是否涉及钱?→ TCC(可控性强)

事务链路是否**≤ 3 个服务**?→ AT(最简单)

事务链路**> 3 个服务**?→ SAGA(避免长时间锁资源)

强监管行业(银行/证券)?→ XA(强一致)

80% 业务选 AT 即可,别上来就用 TCC(侵入高,3 个方法要写)。

4.4 RocketMQ:消息中间件的工业级选择

是什么:阿里开源,Apache 顶级项目,低延迟、高可靠、高吞吐的消息队列。GitHub Stars 21k+。

解决什么问题:

异步解耦:订单创建后异步发短信、发优惠券
削峰填谷:秒杀时把请求先入队列,后台慢慢处理
事务消息:下单+扣库存分布式事务的"本地消息表"替代方案
顺序消息:同一订单的消息严格按顺序处理
定时消息:延迟投递(15 分钟未支付取消订单)

核心特性:

事务消息:生产端先发 prepared 消息,本地事务 commit 后发 commit,失败发 rollback,RocketMQ 自动清理 prepared 消息
严格顺序:同一队列的消息严格 FIFO
百万级 TPS:实测单集群 100 万+ TPS
金融级可靠性:同步双写 + 异步刷盘,数据不丢

对比 Kafka:

Kafka 优势:超高吞吐 + 生态成熟(大数据领域标配)
RocketMQ 优势:事务消息 + 顺序消息 + 定时消息(业务领域更友好)
选型建议:业务消息(订单/支付/通知)选 RocketMQ,日志/大数据管道选 Kafka

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


// 事务消息示例
@RocketMQTransactionListener(txProducerGroup = "order-tx-group")
public class OrderTransactionListener implements RocketMQLocalTransactionListener {
 @Override
 public RocketMQLocalTransactionState executeLocalTransaction(Message msg, Object arg) {
 try {
 // 本地事务:创建订单
 orderService.create((OrderRequest) arg);
 return RocketMQLocalTransactionState.COMMIT;
 } catch (Exception e) {
 return RocketMQLocalTransactionState.ROLLBACK;
 }
 }
 // 回查机制:RocketMQ 定期询问未确认的消息
 @Override
 public RocketMQLocalTransactionState checkLocalTransaction(Message msg) {
 // 根据 msg 查询订单是否创建成功
 return orderService.exists(msg.getKeys()) 
 ? COMMIT : ROLLBACK;
 }
}

4.5 Spring Cloud Gateway:对外 API 网关

是什么:Spring Cloud 官方推出的 响应式 API 网关,基于 Spring WebFlux + Reactor Netty。性能是 Zuul 1.x 的 1.6 倍。

解决什么问题:

统一入口:所有外部请求先到 Gateway,做鉴权/限流/路由
动态路由:根据请求路径/Header/参数动态转发到不同服务
过滤器链:鉴权 → 限流 → 日志 → 灰度 → 转发
跨域处理:统一 CORS 配置
协议转换:HTTP/JSON → Dubbo/HTTP2 内部协议

核心特性:

断言(Predicates):基于 Path、Header、Cookie、Method、Query 的路由匹配
过滤器(Filter):GlobalFilter(全局) + GatewayFilter(路由级)
限流集成:内置 RequestRateLimiter GatewayFilter,直接对接 Redis 限流

注意:

Gateway 基于 WebFlux 响应式,不能和 Spring MVC 混用!
如果你的服务用了 Spring MVC,把 Gateway 单独部署,别和业务服务一起
Gateway 是单线程事件循环,CPU 密集型操作(比如压缩)要谨慎

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


# Gateway 路由配置示例
spring:
 cloud:
 gateway:
 routes:
 - id: order-service
 uri: lb://order-service  # lb = load balancer
 predicates:
 - Path=/api/order/**
 - Method=GET,POST
 filters:
 - StripPrefix=2  # 去掉 /api 前缀
 - name: RequestRateLimiter
 args:
 redis-rate-limiter.replenishRate: 100
 redis-rate-limiter.burstCapacity: 200
 - name: Hystrix  # 配合熔断(已 EOL,改 Sentinel)
 args:
 fallbackUri: forward:/fallback

4.6 Spring Cloud Alibaba 不直接包含的"配件”

这几个组件不是 SCA 直接提供,但在微服务里同样重要,顺手列一下:

SkyWalking / Zipkin:分布式链路追踪
XXL-JOB / Elastic-Job:分布式定时任务
ELK / Loki:日志收集与分析
Prometheus + Grafana:监控告警

💡 原理:微服务是"组件组合",不是"全家桶"

Spring Cloud Alibaba 解决服务治理的 80% 问题,剩下的 20%(监控、日志、定时任务)由独立组件补齐。不要追求"一套打天下"——每个组件在自己的领域做到极致,组合起来才是最优解。

五、内部调用:Dubbo 3 实战

这是本文最硬核的一节。Dubbo 3 不只是"Dubbo 2 升级版",它在协议、服务发现、跨语言、可观测性上做了全面重构。这里重点讲Triple 协议——这是 Dubbo 3 相比 2.7 最大的变化。

5.1 为什么内部用 Dubbo 不走 OpenFeign

性能对比(单次调用,本地环境,JDK 17):

方案	序列化	协议	延迟(P50)	延迟(P99)	TPS
OpenFeign + JSON	Jackson	HTTP/1.1 JSON	2.5ms	8ms	6000
OpenFeign + Protobuf	Protobuf	HTTP/1.1	1.8ms	6ms	8500
Dubbo 3 Triple	Protobuf	HTTP/2	0.8ms	2.5ms	18000
Dubbo 2.x (Hessian)	Hessian2	Dubbo TCP	0.6ms	2ms	22000

📌 实践:什么时候该用 Dubbo,什么时候该用 Feign

Dubbo 3 Triple:内部服务调用,QPS > 1000,延迟敏感

OpenFeign:跨语言调用、对外 REST、低 QPS 业务(< 100)、管理后台

混合使用:本文架构,内部 Dubbo + 对外 Feign

Dubbo 3 Triple 协议 vs Dubbo 2.x 经典协议:

Triple:基于 HTTP/2 + Protobuf,跨语言友好(Go/Python/Node.js 都能调)
经典:基于 Dubbo 自定义协议 + Hessian,性能更强但只支持 Java

🎯 避坑点:Triple 不是为了取代 gRPC

Triple 协议设计时参考了 gRPC,在 gRPC 之上做了扩展(支持自定义负载均衡、跨集群路由)。如果你的系统已经用了 gRPC,不需要为了 Dubbo 3 而迁。

但如果你从零开始,Triple 比 gRPC 多了"服务治理"能力(内置路由、限流、熔断),这是 gRPC 需要配合 Istio 才能做到的。

5.2 Triple 协议原理

Triple 协议的核心设计:

协议层:基于 HTTP/2,支持多路复用、流控
序列化:默认 Protobuf(也可选 JSON、Hessian)
服务定义:IDL(.proto 文件)或 Java Interface
通信模式:Unary(一元)、Server Streaming、Client Streaming、Bidirectional Streaming(完整 gRPC 兼容)
服务发现:通过 Nacos 拉取服务列表,默认 dubbo 协议头

5.2.1 协议栈分层

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


┌─────────────────────────────────────┐
│ 业务接口(Java Interface) │
├─────────────────────────────────────┤
│ Stub / Proxy(Dubbo 生成) │
├─────────────────────────────────────┤
│ Triple 协议(基于 HTTP/2 + Protobuf)│
├─────────────────────────────────────┤
│ Netty 4.x 传输层 │
├─────────────────────────────────────┤
│ TCP │
└─────────────────────────────────────┘

5.2.2 Triple 与 gRPC 的兼容性

关键:Triple 协议和 gRPC 协议在网络层完全兼容。这意味着:

Go/Python/Node.js 客户端可以用标准 gRPC 调 Dubbo 3 服务
Java 端既可以用 Dubbo 3 Client,也可以用 grpc-java Client
同一端口(默认 50051)既服务 gRPC,也服务 Triple

💡 原理:为什么能"完全兼容"

gRPC 的协议规范是公开的(grpc/grpc-proto)。Triple 在协议层严格遵循 gRPC 规范,只是在服务元数据(服务名、版本、分组)做了扩展,所以 gRPC 客户端能"假装是 Triple 服务"去调,服务端也能识别"gRPC 风格的请求"。

5.3 实战:定义一个 Triple 服务

步骤 1:定义接口

1
2
3
4
5
6


@DubboService // 暴露服务
public interface InventoryService {
 // Java 接口,标注 IDL 信息
 boolean deduct(String skuId, int quantity);
 Inventory query(String skuId);
}

步骤 2:实现服务

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


@DubboService(version = "1.0.0", group = "inventory")
public class InventoryServiceImpl implements InventoryService {
 @Autowired
 private InventoryRepository repo;
 
 @Override
 public boolean deduct(String skuId, int quantity) {
 Inventory inv = repo.findBySkuId(skuId)
 .orElseThrow(() -> new NotFoundException(skuId));
 if (inv.getStock() < quantity) {
 return false;
 }
 inv.setStock(inv.getStock() - quantity);
 repo.save(inv);
 return true;
 }
 
 @Override
 public Inventory query(String skuId) {
 return repo.findBySkuId(skuId)
 .orElseThrow(() -> new NotFoundException(skuId));
 }
}

步骤 3:引用服务

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


@RestController
public class OrderController {
 @DubboReference(version = "1.0.0", group = "inventory")
 private InventoryService inventoryService; // 像本地 Bean 一样用
 
 @PostMapping("/order")
 public OrderResult create(@RequestBody OrderRequest req) {
 // 内部调用 Dubbo,走 Triple 协议
 boolean ok = inventoryService.deduct(req.getSkuId(), req.getQuantity());
 if (!ok) {
 return OrderResult.fail("库存不足");
 }
 // ...
 }
}

5.4 与 Nacos 注册中心互通

核心配置(Nacos 作为注册中心 + 配置中心,Dubbo 服务注册到同一 Nacos):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


# application.yml
dubbo:
 application:
 name: inventory-service
 registry:
 address: nacos://nacos-cluster:8848
 protocol:
 name: tri  # Triple 协议
 port: 50051
 provider:
 timeout: 3000
 retries: 2
 consumer:
 timeout: 3000
 retries: 2
 check: false
 cloud:
 subscribed-services: inventory-service  # 订阅哪些服务

spring:
 cloud:
 nacos:
 discovery:
 server-addr: nacos-cluster:8848
 namespace: prod

关键点:

dubbo.registry.address 配 Nacos 地址,服务自动注册到 Nacos
Spring Cloud 的服务(用 @SpringBootApplication + @EnableDiscoveryClient)和 Dubbo 服务同时注册到 Nacos
Spring Cloud 服务能发现 Dubbo 服务,Dubbo 服务也能发现 Spring Cloud 服务——只要都是注册到同一 Nacos

5.5 Dubbo 2.7 升级 3.x 的关键差异

如果你是 Dubbo 2.7 老项目,升级 3.x 要注意:

维度	Dubbo 2.7.x	Dubbo 3.x
协议	默认 Dubbo 协议(Hessian)	默认 Triple 协议(HTTP/2 + Protobuf)
注册中心	ZK 主流	Nacos 主流
服务发现	接口级(Interface)	应用级(Application)——按应用名发现,支持大规模集群
跨语言	不支持	支持(gRPC 兼容)
路由策略	条件路由、脚本路由	条件路由 + 标签路由 + 动态配置
可观测性	弱	内置 Micrometer 集成
K8s 集成	不支持	原生支持(基于 Service/DNS)
性能	强	略弱(因为 HTTP/2 开销)但更通用

🎯 避坑点:Dubbo 2.7 → 3.x 升级的最大坑

服务发现模型变了——从"接口级"变成"应用级"。

Dubbo 2.7 同一应用的不同接口都注册成独立服务。Dubbo 3 同一应用的所有接口共享一个应用实例,按 service:version:group 区分。

这意味着:

Nacos 上的服务数会减少(从 N 多个 → N 个)

客户端的负载均衡策略要重配

跨集群路由配置要重新梳理

建议:先在测试环境全量验证,再灰度上线——别一上来就生产升级。

六、对外暴露:RESTful 实战

6.1 为什么对外走 RESTful,不走 Dubbo

维度	Dubbo	RESTful
跨语言	需 SDK(只支持 Java)	HTTP 标准,任意语言可调
调试难度	难(需 Dubbo 工具)	易(curl/Postman/浏览器)
文档工具	无(手写)	Swagger / Knife4j 自动生成
API 治理	弱(无标准)	强(OpenAPI 规范)
前端友好度	差(需后端代理)	好(直接 fetch/axios)
第三方对接	难	易(标准 HTTP)
性能	强	中(JSON 序列化开销)
适合场景	内部服务	外部接口

结论:对外一律 REST,内部一律 Dubbo。这是 5.1 节"性能对比表"的延伸——对外流量不追求极致性能(单次 2ms vs 0.8ms 用户感知不到),但追求生态与可调试性。

6.2 三件套组合:Spring MVC + OpenFeign + Spring Cloud Gateway

组合架构:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


外部 APP
 │
 ▼
┌──────────────────┐
│ Spring Cloud │ ← 对外 API 网关(统一鉴权/限流/路由)
│ Gateway │
└────────┬─────────┘
 │
 ▼
┌──────────────────┐
│ 业务服务 │ ← Spring MVC 暴露 REST API
│ (Order/User/...) │
│ @RestController │
└────────┬─────────┘
 │
 │ (内部调用,可能跨服务)
 ▼
┌──────────────────┐
│ Dubbo 3 Triple │ ← 内部 RPC
│ (Inventory/...) │
└──────────────────┘

关键设计:

Controller 层用 Spring MVC(@RestController),不直接用 Dubbo
服务间调用用 Dubbo 3(@DubboReference)
第三方/前端调用走 Gateway → Controller
OpenFeign 只用于特殊场景(比如跨业务线的服务调用,对方没有 Dubbo 服务)

6.3 实战:订单服务的完整 API

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


@RestController
@RequestMapping("/api/v1/order")
@Tag(name = "订单服务", description = "订单的创建、查询、取消") // Knife4j 注解
public class OrderController {
 
 @Autowired
 private OrderApplicationService orderService; // 应用层服务
 
 @PostMapping
 @Operation(summary = "创建订单")
 public Result<OrderDTO> create(@RequestBody @Valid OrderRequest req) {
 return Result.success(orderService.create(req));
 }
 
 @GetMapping("/{orderId}")
 @Operation(summary = "查询订单详情")
 public Result<OrderDTO> getById(@PathVariable Long orderId) {
 return Result.success(orderService.getById(orderId));
 }
 
 @PostMapping("/{orderId}/cancel")
 @Operation(summary = "取消订单")
 public Result<Void> cancel(@PathVariable Long orderId, @RequestParam String reason) {
 orderService.cancel(orderId, reason);
 return Result.success();
 }
}

Swagger/Knife4j 自动生成文档:

访问 http://gateway-host:8080/doc.html 查看 API 文档
前端/测试团队可以直接在线调试

6.4 OpenFeign 的应用场景

OpenFeign 在 SCA + Dubbo 3 架构里,主要用于"非 Dubbo 服务"的调用:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


// 场景:调用一个外部团队的 REST 服务(对方没有 Dubbo)
@FeignClient(name = "external-erp", url = "https://erp.internal/api")
public interface ErpClient {
 @PostMapping("/sync")
 ErpSyncResult sync(@RequestBody ErpSyncRequest req);
}

// 场景:前端 BFF 层聚合多个内部服务
@FeignClient(name = "inventory-service", path = "/api/v1/inventory")
public interface InventoryFeignClient {
 @GetMapping("/{skuId}")
 InventoryDTO getBySkuId(@PathVariable String skuId);
}

OpenFeign vs Dubbo 3 的选型决策:

场景	推荐方案
内部服务调用(高 QPS、延迟敏感)	Dubbo 3 Triple
内部服务调用(低 QPS、跨业务线)	OpenFeign
外部服务调用(对方无 Dubbo)	OpenFeign
前端 BFF 层聚合	OpenFeign
后台管理类接口	OpenFeign

七、实战:一个接口的完整链路

用一个真实例子,把所有组件串起来:用户下单。

7.1 场景描述

流程:

APP 发起 POST /api/v1/order 请求
Gateway 鉴权 + 限流
OrderController 接收请求
OrderService 调用 InventoryService(Dubbo)扣库存
OrderService 调用 AccountService(Dubbo)扣账户余额
Seata 全局事务保证数据一致
创建订单,落 MySQL
发送 RocketMQ 消息(异步发券 + 短信)
返回结果给 APP

7.2 完整代码骨架

Controller 层:

1
2
3
4
5
6
7


@PostMapping
@GlobalTransactional(name = "create-order-tx", rollbackFor = Exception.class)
@SentinelResource(value = "createOrder", blockHandler = "handleBlock")
public Result<OrderDTO> create(@RequestBody @Valid OrderRequest req, 
 @RequestHeader("X-User-Id") Long userId) {
 return Result.success(orderService.create(userId, req));
}

ApplicationService 层(组合领域服务):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39


@Service
public class OrderApplicationService {
 
 @DubboReference(version = "1.0.0", group = "inventory")
 private InventoryService inventoryService;
 
 @DubboReference(version = "1.0.0", group = "account")
 private AccountService accountService;
 
 @Autowired
 private OrderRepository orderRepository;
 
 @Autowired
 private RocketMQTemplate rocketMQTemplate;
 
 public OrderDTO create(Long userId, OrderRequest req) {
 // 1. 扣库存(Dubbo Triple 协议)
 boolean deducted = inventoryService.deduct(req.getSkuId(), req.getQuantity());
 if (!deducted) {
 throw new BusinessException("库存不足");
 }
 
 // 2. 扣账户余额(Dubbo Triple 协议)
 accountService.debit(userId, req.getAmount());
 
 // 3. 创建订单(本服务数据库)
 Order order = Order.create(userId, req);
 orderRepository.save(order);
 
 // 4. 发送异步消息(RocketMQ 事务消息)
 rocketMQTemplate.sendMessageInTransaction(
 "order-topic", 
 MessageBuilder.withPayload(order).build(),
 order
 );
 
 return OrderDTO.from(order);
 }
}

7.3 全链路追踪

SkyWalking 配置(看一个请求的完整链路):

1
2
3
4
5
6


# agent/config/agent.config
agent.service_name=order-service
collector.backend_service=skywalking-oap:11800
# 自动追踪 Dubbo + HTTP 调用
plugin.dubbo.trace_internal=true
plugin.spring.webflux.trace_internal=true

SkyWalking Dashboard 看到的链路:

1
2
3
4
5
6
7
8


[Gateway 鉴权] 3ms
 └─ [OrderController] 25ms
 ├─ [OrderService.create] 18ms
 │ ├─ [Dubbo: InventoryService.deduct] 6ms ← 内部 Dubbo 调用
 │ ├─ [Dubbo: AccountService.debit] 5ms
 │ ├─ [MySQL: insert order] 3ms
 │ └─ [RocketMQ: sendMessage] 2ms
 └─ [Seata: branch register] 2ms

任何一环慢,都能秒级定位——这才是微服务可观测性的价值。

7.4 故障场景演练

场景:库存服务宕机

OrderController 收到请求
Dubbo 调用 InventoryService.deduct(),3 秒超时
抛 RpcException: Timeout
@GlobalTransactional 触发回滚,账户扣款被回滚,订单未创建
业务侧返回"系统繁忙,请稍后重试"
Sentinel 触发熔断,后续 30 秒内直接拒绝请求(避免雪崩)
RocketMQ 消息未发送,无副作用

整套流程在 3 秒内完成——没有库存数据不一致,没有脏消息,没有雪崩。

八、总结:选型决策树与避坑清单

8.1 选型决策树

graph TD
 A[启动技术选型] --> B{业务规模?}
 B -->|日活<10万| C[单体 + Spring Boot]
 B -->|10万~100万| D{团队规模?}
 B -->|日活>100万| E{自研 vs 云?}
 
 D -->|<10人| F[Spring Cloud + Alibaba]
 D -->|>10人| G{有 Dubbo 基础?}
 
 G -->|有| H[SCA + Dubbo 3 混合]
 G -->|无| F
 
 E -->|自研为主| H
 E -->|全面上云| I[云原生全家桶 MSE/AHAS]
 
 style H fill:#457b9d,color:#fff
 style F fill:#a8dadc

结论:

< 10 万日活:单体 Spring Boot + MySQL,别上微服务
10-100 万日活:Spring Cloud Alibaba 套件足够
> 100 万日活:SCA + Dubbo 3 混合架构(本文方案)
超大规模(> 1000 万日活):上云原生 + Service Mesh

8.2 6 条避坑点

🛑 误区警示:这些坑别踩

盲目追新——Spring Cloud 还在用 2020.x 版本,公司新项目就上 2023.0.x,踩了一堆兼容性 bug。新版本至少观察 6 个月再上生产

混用多种 RPC 框架——服务 A 用 Dubbo、服务 B 用 Feign、服务 C 用 gRPC,团队没人能讲清楚。统一一套,要么 Dubbo,要么 Spring Cloud OpenFeign

Sentinel 规则没接 Dashboard——本地写了 @SentinelResource 但没接控制台,所有规则硬编码。生产前必须接 Dashboard,规则要可动态调整

Seata AT 模式没开 binlog——MySQL 没开 binlog,Seata AT 模式直接报错,临时改 TCC 又没时间。架构阶段就要确认 binlog 配置

Dubbo 2.7 升级 3.x 没灰度——直接全量升,服务发现模型变了,新模型在测试环境没压测过,生产雪崩。先灰度 10% 流量,观察 1 周再全量

Spring Cloud Gateway 跟 Spring MVC 混用——Gateway 是 WebFlux 响应式,跟业务模块的 Spring MVC 一起启动,Bean 冲突,启动直接报错。Gateway 单独部署,不和业务服务同进程

8.3 版本兼容性矩阵(2026.06 当前主流)

Spring Boot	Spring Cloud	Spring Cloud Alibaba	Nacos	Sentinel	Seata	Dubbo	备注
3.2.x	2023.0.x	2023.0.0.0	2.3.x+	1.8.6+	1.7+	3.2.x	最新版
3.1.x	2022.0.4	2022.0.0.0-RC1	2.3.x	1.8.6	1.6+	3.2.x	次主流
3.0.x	2022.0.x	2022.0.0.0	2.2.x+	1.8.6	1.6+	3.1.x	本文基线
2.7.x	2021.0.x	2021.0.x	1.4.x	1.8.4	1.5+	2.7.x	老项目在用

📌 实践:版本升级的"先小后大"原则

先升小版本(如 3.0.5 → 3.0.10),观察 1 周

再升次版本(3.0 → 3.1),灰度 10% 流量

最后升大版本(3.x → 4.x),至少 6 个月观察期

永远不要跨大版本直接升——除非你已经放弃了兼容性的执念,愿意重写。

九、常见问题 FAQ

Q1:Spring Cloud Alibaba 和"阿里云微服务引擎(MSE)“是什么关系?

A:MSE 是 SCA 核心组件的阿里云商业版。

Nacos 开源版 → MSE 商业版
Sentinel 开源版 → AHAS(应用高可用服务)
Seata 开源版 → GTS(全局事务服务)
Spring Cloud Gateway 开源版 → 云原生 API 网关

关系:核心代码同源,商业版加运维、监控、扩缩容能力。

小规模(< 50 服务):用开源版自建——成本低,够用
中规模(50-500 服务):核心组件商业版,周边组件开源——平衡
大规模(> 500 服务):全面上云原生——专业的事交给专业的

如果不想用阿里云,SCA 的核心组件都是 ASF/Apache 项目,可以在腾讯云、AWS、Azure 上自建或用对应商业服务。

Q2:Dubbo 3 和 OpenFeign 能不能在一个项目里混用?

A:完全可以,本文架构就是混用。

混用原则:

Dubbo 3 Triple:所有内部服务间的高 QPS 调用——性能优先
OpenFeign:跨业务线服务、第三方服务、前端 BFF 聚合——生态优先
不要在同一服务的同一调用链上混用——选择了一种就坚持到底

实战配比:Dubbo 80% + OpenFeign 20% 是健康的比例。

Q3:升级到 Spring Cloud Alibaba 2022.0.0.0(Spring Boot 3.x)的最大坑是什么?

A:javax → jakarta 命名空间切换。

Spring Boot 3.x 把 javax.servlet.* 全部改成 jakarta.servlet.*——所有第三方库必须升级。

MyBatis:升级到 3.5.x+
Hibernate Validator:升级到 8.x+
Servlet 容器:Spring Boot 3.x 内置 Tomcat 10+
所有 @Resource、@PostConstruct 等 不受影响(javax.annotation 仍兼容)

最稳的升级路径:

先升 Spring Boot 2.7 → 3.0(只改 spring-boot-starter 版本)
再升 javax.* → jakarta.*(用 IDE 全局替换)
最后升 Spring Cloud + SCA 到 2022.0.0.0

预计工作量:3 个月(50 个微服务规模)。别在双 11 前升。

Q4:Nacos 配置中心的数据怎么加密?

A:Nacos 1.4+ 支持配置加密。

1
2
3
4


# nacos 控制台 → 配置管理 → 新建配置
# DataId: order-service.yaml
# 加密配置:配置内容用 jasypt 或 nacos-aes 加密
# 客户端解密:配置 spring.cloud.nacos.config.ext-config

更推荐的方式:敏感配置放 KMS(密钥管理服务),不直接放 Nacos。

阿里云 KMS、腾讯云 KMS、AWS KMS
业务服务启动时从 KMS 拉取敏感配置,缓存在内存
Nacos 只放非敏感配置(超时时间、开关、限流阈值等)

Q5:Sentinel 集群限流怎么做?

A:Sentinel 集群限流依赖 Token Server。

单机限流只能保护单实例,但总流量超限时无法保护。集群限流把限流决策放到中心化 Token Server:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


┌─────────┐ ┌─────────┐ ┌─────────┐
│ 实例 1 │ │ 实例 2 │ │ 实例 3 │
│ (Token │ │ (Token │ │ (Token │
│ Client) │ │ Client) │ │ Client) │
└────┬────┘ └────┬────┘ └────┬────┘
 │ │ │
 └────────────┼────────────┘
 ▼
 ┌────────────────┐
 │ Token Server │ ← 集群限流中心
 │ (Cluster) │
 └────────────────┘

生产配置:3 个 Token Server 节点 + Nacos 配置规则。所有 Sentinel Client 启动时连接 Token Server 拉取令牌。

注意:集群限流增加 1-2ms 延迟,延迟敏感场景要权衡。

Q6:Seata 在分库分表下能用吗?

A:能用,有限制。

AT 模式:支持分库分表——每个分片都是独立的数据源,Seata 会在每个分片创建 undo_log 表
TCC 模式:天然支持——分库分表对 TCC 是透明的
SAGA 模式:支持——补偿逻辑在分库分表上正常执行

注意:

ShardingJDBC + Seata 集成需要特殊配置:每个分片数据源都要注册到 Seata
全局锁在分库分表下是跨分片锁,性能会下降
建议:核心交易用 AT + 简单分片(< 16 个),复杂分片场景用 TCC

Q7:Spring Cloud Gateway 怎么实现"按 IP 限流”?

A:Sentinel 支持按 IP 限流。

1
2
3
4
5
6
7
8
9


@Bean
public GlobalFilter ipFilter() {
 return (exchange, chain) -> {
 String ip = exchange.getRequest().getRemoteAddress().getAddress().getHostAddress();
 // 调 Sentinel API 限流
 Entry entry = SphU.entry("ip-rate-limit", 1, ip);
 return chain.filter(exchange).doFinally(s -> entry.exit());
 };
}

生产更推荐:用 Sentinel 控制台配 IP 黑白名单,不用写代码。

Q8:微服务怎么和单元化(第 1 篇的异地多活)结合?

A:这是 Java Web 微服务系列后续的重点。

简短回答:

Dubbo 3 标签路由:Dubbo 内置"按机房标签路由",结合 Nacos 的 cluster-name 元数据,自动隔离跨机房调用
Sentinel 集群限流:按机房分别限流,避免单机房过载拖垮全网
Seata:跨机房分布式事务强烈不推荐——跨机房延迟 30-100ms,事务延迟会飙升到秒级
消息:RocketMQ 跨机房用 同城双写 + 异地灾备,业务层做幂等消费

详细方案见系列第 7 篇「异地多活下的微服务治理」。

十、系列预告 + 推荐阅读

10.1 系列预告

这是 Java Web 微服务系列 的第 4 篇。后续计划覆盖:

序号	主题	状态
第 1 篇	异地多活(高可用终极形态)	✅ 已发布
第 2 篇	微服务拆分与领域建模	🔜 计划中
第 3 篇	服务治理:注册中心、配置中心、限流熔断	🔜 计划中
第 4 篇	技术选型(本文)	✅ 本文
第 5 篇	Nacos 实战:集群搭建 + 配置灰度	🔜 计划中
第 6 篇	Sentinel 实战:限流规则 + 熔断降级	🔜 计划中
第 7 篇	Seata 实战:AT/TCC 模式选型	🔜 计划中
第 8 篇	Dubbo 3 实战:Triple + 标签路由	🔜 计划中
第 9 篇	异地多活下的微服务治理	🔜 计划中
第 10 篇	全链路压测 + 混沌工程	🔜 计划中

💡 学习路径建议

入门:本文 + Nacos 官方文档

进阶:Dubbo 3 官方文档(https://dubbo.apache.org)

实战:研究 SCA 各组件 GitHub 仓库的 spring-cloud-alibaba-examples

深潜:动手搭一套完整 PoC(推荐 5 个服务:Order/Inventory/Account/Pay/Notify)

10.2 推荐阅读

官方文档:

书籍:

《Spring Cloud Alibaba 微服务原理与实战》(谭勇德)—— 国内最系统的 SCA 实战书
《深入理解 Apache Dubbo 与实战》(诣极、林琳)—— Dubbo 原理 + 实战
《数据密集型应用系统设计》(DDIA, Martin Kleppmann)—— 分布式系统圣经

开源项目(学习用)：

mall-swarm:macrozheng 开源,微服务电商完整 demo
Spring Cloud Alibaba Examples:官方 example 集合
Nepxion Discovery:分布式链路追踪 + 灰度发布

博客:

阿里中间件团队博客:Nacos/Sentinel/Seata 源码解析
美团技术团队:分布式服务治理实践
InfoQ 中文站:SCA 系列实战文章

📌 工程实践:技术选型不是一次性决策

本文写于 2026 年 6 月,但技术选型是 3-5 年的事。今天选的方案,2029 年大概率要再选一次。

选型时考虑的不是"哪个最对",而是"哪个能让我 3 年后再选一次"。留有演进空间比"一次选对"更重要。

参考文章

本文完。下篇预告:第 5 篇 · Nacos 实战:集群搭建 + 配置灰度。

Dubbo 3 on Liangweidong's blog

技术选型:为什么最终选了 Spring Cloud Alibaba + Dubbo 3

技术选型:为什么最终选了 Spring Cloud Alibaba + Dubbo 3

引子:第一次技术评审会上我翻的车

一、核心原则:好的技术选型长什么样

1.1 业务匹配 > 技术先进

1.2 团队能力 > 流行度

1.3 社区活跃 > 文档齐全

1.4 避免重复造轮子

1.5 留有演进空间

二、主流方案横评:4 个候选的 PK

2.1 4 个候选方案

2.2 9 维度对比表

2.3 4 个候选的优缺点总结

三、为什么最终选了 Spring Cloud Alibaba

3.1 组件全家桶,开箱即用

3.2 国内生态成熟,中文资料丰富

3.3 与 Dubbo 兼容,内部 RPC 高性能

3.4 二次封装好,踩坑成本低

3.5 商业化平滑,演进路径清晰

四、SCA 核心组件拆解

4.1 Nacos:注册中心 + 配置中心二合一

4.2 Sentinel:流量治理的瑞士军刀

4.3 Seata:分布式事务的标准答案

4.4 RocketMQ:消息中间件的工业级选择

4.5 Spring Cloud Gateway:对外 API 网关

4.6 Spring Cloud Alibaba 不直接包含的"配件”

五、内部调用:Dubbo 3 实战

5.1 为什么内部用 Dubbo 不走 OpenFeign

5.2 Triple 协议原理

5.2.1 协议栈分层

5.2.2 Triple 与 gRPC 的兼容性

5.3 实战:定义一个 Triple 服务

5.4 与 Nacos 注册中心互通

5.5 Dubbo 2.7 升级 3.x 的关键差异

六、对外暴露:RESTful 实战

6.1 为什么对外走 RESTful,不走 Dubbo

6.2 三件套组合:Spring MVC + OpenFeign + Spring Cloud Gateway

6.3 实战:订单服务的完整 API

6.4 OpenFeign 的应用场景

七、实战:一个接口的完整链路

7.1 场景描述

7.2 完整代码骨架

7.3 全链路追踪

7.4 故障场景演练

八、总结:选型决策树与避坑清单

8.1 选型决策树

8.2 6 条避坑点

8.3 版本兼容性矩阵(2026.06 当前主流)

九、常见问题 FAQ

Q1:Spring Cloud Alibaba 和"阿里云微服务引擎(MSE)“是什么关系?

Q2:Dubbo 3 和 OpenFeign 能不能在一个项目里混用?

Q3:升级到 Spring Cloud Alibaba 2022.0.0.0(Spring Boot 3.x)的最大坑是什么?

Q4:Nacos 配置中心的数据怎么加密?

Q5:Sentinel 集群限流怎么做?

Q6:Seata 在分库分表下能用吗?

Q7:Spring Cloud Gateway 怎么实现"按 IP 限流”?

Q8:微服务怎么和单元化(第 1 篇的异地多活)结合?

十、系列预告 + 推荐阅读

10.1 系列预告

10.2 推荐阅读

参考文章