Spring Cloud on 牛哥聊技术

Nacos 配置中心与服务发现的实战要点

Thu, 20 Jun 2024 15:30:00 +0800

为什么 Nacos 装起来容易，用对很难

Nacos 是当下国内最流行的"配置中心 + 注册中心"二合一组件——几乎所有用 Spring Cloud Alibaba 的项目都默认上它。

但用过的人会发现一些尴尬的事情：

团队所有项目的配置全堆在一个 namespace 里，环境/项目/团队划分混乱
一个微服务有十几个配置文件，谁也说不清哪个配置覆盖了哪个
修改一个配置后有些实例生效，有些没生效——监听机制写错了
重启 Nacos 后配置没了或者注册的服务全没了——存储模式选错了
灰度发布想"只让一台实例生效新配置"，根本做不到

Nacos 装起来 5 分钟，用对要几个月经验。本文把生产环境的关键决策点讲清楚——namespace 怎么划、配置怎么组织、监听怎么写对、服务发现怎么用稳。

一、Nacos 的核心模型

flowchart TB
 Namespace["Namespace
(环境隔离)"]
 Group["Group
(逻辑分组)"]
 DataId["Data ID
(具体配置)"]

 Namespace --> Group
 Group --> DataId

 DataId -.读取.-> Client[应用实例]
 DataId -.推送变更.-> Client

三层模型：

Namespace：最高层级隔离——通常对应环境（dev/test/prod）
Group：第二层逻辑分组——通常对应项目或微服务
Data ID：最具体的配置文件——application-{profile}.yaml

这个三层结构怎么划分，是 Nacos 用得好不好的最大决定因素。

二、Namespace / Group / DataId 的划分原则

不要这样划

1
2
3
4


namespace: public（默认）
group: DEFAULT_GROUP
data id: my-service-dev.yaml, my-service-test.yaml, my-service-prod.yaml
my-other-service-dev.yaml, ...

所有配置堆在 default 命名空间和 default 组里——搜起来一团乱，多团队协作时互相覆盖也不会知道。

推荐划法：环境隔离 + 服务分组

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


namespace = 环境
 ├─ dev
 ├─ test
 ├─ pre (预发布)
 └─ prod

group = 服务名 / 项目名
 ├─ user-service
 ├─ order-service
 └─ shared-config (跨服务共享)

data id = application-{type}.yaml
 ├─ application-base.yaml (业务基础配置)
 ├─ application-rocketmq.yaml (中间件配置)
 └─ application-feature.yaml (功能开关)

关键决策：

Namespace 用环境——上线管控的核心边界。线上账号只给 prod namespace 权限，dev 不该看到 prod
Group 用服务名——同一个微服务的所有 Data ID 集中在一个 Group 里
Data ID 按职责拆分——业务配置、中间件配置、功能开关分开放，单个文件不会膨胀

跨服务共享配置怎么办

很多配置不是单一服务的——比如所有服务都要连同一个 Redis：

1
2


group = shared-config
data id = application-redis.yaml, application-mq.yaml

每个服务在 bootstrap.yml 里多 import 一份共享配置：

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


spring:
 cloud:
 nacos:
 config:
 server-addr: ${NACOS_ADDR}
 namespace: ${ENV}
 group: user-service  # 自己的 group
 extension-configs:
 - data-id: application-redis.yaml
 group: shared-config
 refresh: true
 - data-id: application-mq.yaml
 group: shared-config
 refresh: true

三、配置文件的优先级和加载顺序

Spring Cloud Nacos 默认按这个优先级加载（从低到高）：

${spring.application.name}.${file-extension} 默认共享
${spring.application.name}-${profile}.${file-extension}（profile 独占）
extension-configs（按数组顺序，越后越高）
shared-configs（按数组顺序，越后越高）
命令行参数 / 环境变量

搞清楚这个优先级是排查"为什么我改了配置不生效"的前提——很可能你改的是低优先级，被高优先级覆盖了。

打开 Spring Boot Actuator 的 /actuator/configprops 或者 /actuator/env 能直观看到每个 key 来自哪个 PropertySource。

四、配置变更的监听：写错就完蛋

默认行为：自动刷新被 `@Value` 注入的字段

1
2
3
4
5


spring:
 cloud:
 nacos:
 config:
 refresh: true

1
2
3
4
5
6


@RestController
@RefreshScope // ★ 关键
public class FeatureController {
 @Value("${feature.enabled}")
 private boolean enabled;
}

@RefreshScope 让 Bean 在配置变更后重新创建，注入的 @Value 拿到新值。

容易踩的坑

坑 1：@RefreshScope 没加，配置不生效

新人最常踩——以为配 refresh: true 就够了。实际上还要在使用配置的 Bean 上加 @RefreshScope。

坑 2：@RefreshScope 不能加在 @Configuration 上

会导致整个 Configuration 重建，下面声明的所有 Bean 全部重建——副作用极大，可能引起内存泄漏（旧 Bean 没释放）。

坑 3：@ConfigurationProperties 默认就刷新

不需要 @RefreshScope：

1
2
3
4
5
6
7


@Component
@ConfigurationProperties(prefix = "feature")
public class FeatureConfig {
 private boolean enabled;
 private int threshold;
 // getters / setters
}

这是更推荐的姿势——比 @Value 类型安全、便于测试、自动刷新。

坑 4：手动监听用 @NacosConfigListener 已废弃

老博客经常推荐 @NacosConfigListener，但它属于早期 SDK 风格，Spring Cloud 集成下基本不该用。手动监听用：

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


@Autowired NacosConfigManager configManager;

@PostConstruct
public void listen() throws Exception {
 configManager.getConfigService().addListener(
 "application-feature.yaml", "user-service",
 new Listener() {
 public Executor getExecutor() { return null; }
 public void receiveConfigInfo(String content) {
 log.info("config changed: {}", content);
 // 自定义解析逻辑
 }
 });
}

但 99% 场景用 @ConfigurationProperties + @RefreshScope 就够了。

五、灰度发布：Nacos 自身能做到什么程度

很多人以为"灰度发布配置"是 Nacos 的标准能力——Nacos 开源版其实没有灰度配置。

Nacos 开源版：配置变更会推到所有订阅了这个 Data ID 的实例，没有"只推一台"的能力
Nacos 商业版（阿里云 MSE Nacos）：才有"配置灰度发布"功能，可以指定按 IP / 标签推送

如果用开源版又想做配置灰度，三种思路：

拆 namespace：灰度环境用单独的 namespace（最干净）
拆 group：同 namespace 不同 group，灰度实例订阅 xxx-gray group
配置里写规则：配置内容里写"哪些实例生效"，业务代码读自己 IP 来判断（最灵活但侵入大）

生产推荐方案 1：直接搞一个 pre namespace 给灰度环境，和 prod 完全隔离。

六、服务发现：被低估的复杂度

临时实例 vs 永久实例

Nacos 注册的服务有两种"实例类型"：

临时实例（默认）：客户端用心跳维持，断了 30 秒后自动剔除——适合业务微服务
永久实例：服务端永久持有，下线要主动调 API——适合有固定地址的传统服务（数据库、第三方系统）

1
2
3
4
5


spring:
 cloud:
 nacos:
 discovery:
 ephemeral: true # 临时实例

注意：1.x 时代两者可以混在同一服务，2.x 之后同一 service 必须全是临时或全是永久——升级时要核对。

心跳与剔除

版本差异（重要）：下面"5 秒心跳 / 15 秒不健康 / 30 秒剔除"是 Nacos 1.x（HTTP 短连接） 的行为；Nacos 2.x 起默认改为 gRPC 长连接 + keepalive——客户端不再定时发 HTTP 心跳，连接断开即被识别下线，整体响应时延显著缩短（亚秒级）。如果你用的是 2.x（2024 年起的主流版本），心跳模型已经不适用。

Nacos 1.x 行为：临时实例每 5 秒发心跳，15 秒没心跳变"不健康"，30 秒后剔除——这意味着实例突然 kill 后最长有 30 秒不可用窗口。

Nacos 2.x 行为：客户端与 server 维持 gRPC 长连接，server 通过连接状态判断实例存活；连接异常断开（进程崩溃、网络隔离）会立即触发下线事件，避免 30 秒窗口。

解决（不论版本都建议）：

客户端配置健康检查 + 重试（OpenFeign / Ribbon / Spring Cloud LoadBalancer）
实例下线前先调用 Nacos NamingService.deregisterInstance 优雅注销——通常用 Spring Boot 的 ApplicationListener<ContextClosedEvent>

七、生产部署：踩过的坑

1. 数据存储：默认嵌入式不能上生产

Nacos 单机默认用嵌入式 Derby 数据库——重启数据可能丢，集群模式根本无法工作。生产必须切到 MySQL：

1
2
3
4
5
6
7


# Nacos 1.x / 2.x 老 key（仍兼容）
spring.datasource.platform=mysql
# Nacos 2.2+ 自身基于较新 Spring Boot，server 端推荐改用：spring.sql.init.platform=mysql
db.num=1
db.url.0=jdbc:mysql://nacos-mysql:3306/nacos?characterEncoding=utf8&...
db.user=nacos
db.password=...

2. 集群模式：至少 3 节点

Nacos 是双协议架构——配置中心和永久实例走 JRaft（CP），默认服务发现的临时实例走自研的 Distro（AP）协议 。两类数据落到同一个集群、用不同的一致性模型。至少 3 节点保证高可用——单节点是写测试代码用的，生产部署单节点没有任何高可用保证，强烈不建议。

这个差异在调试时很重要：Distro 是 AP，节点挂掉时部分实例信息可能短暂不一致——这是设计如此，不是 bug。

flowchart LR
 LB[负载均衡 / SLB]
 LB --> N1[Nacos 1]
 LB --> N2[Nacos 2]
 LB --> N3[Nacos 3]
 N1 <--> MySQL[(MySQL 主从)]
 N2 <--> MySQL
 N3 <--> MySQL

3. 安全：默认是裸奔的

Nacos 默认没有鉴权——任何能访问端口的人都能改你的配置。生产必须开启：

1
2
3


nacos.core.auth.enabled=true
nacos.core.auth.server.identity.key=...
nacos.core.auth.server.identity.value=...

并给不同环境账号、不同 namespace 设置不同权限（开源版控制台里能配）。

4. JVM 参数

生产 Nacos 的 JVM 参数默认是 -Xms2g -Xmx2g，对大流量场景明显不够。配置数 ≥ 10000、连接客户端 ≥ 1000 时建议升到 4G 以上。

5. 不要在容器里跑临时数据

K8s 部署 Nacos 时，所有数据必须挂 PV，否则 Pod 重启数据全丢。MySQL 走外部，但 Nacos 自己的 logs / data 目录也要挂。

八、客户端容错：Nacos 挂了应用还能跑吗

Nacos 故障时（虽然概率小），客户端默认还能从本地 snapshot 文件读取上次拉到的配置——不会立刻挂：

1

~/nacos/config/snapshot/{namespace}/{group}/{dataId}

但有几个细节：

新增实例在 Nacos 故障时拉不到任何配置——直接启动失败
服务发现故障时正在运行的实例还能用上次缓存的服务列表，但新启动的实例发现不了任何服务

所以生产环境永远要保证：

Nacos 集群必须多节点 + 跨可用区
应用启动时用本地 fallback 配置（spring.cloud.nacos.config.import-check.enabled=false）
重要服务的服务发现要有降级机制

九、监控与排查

1. 看配置历史

Nacos 控制台保留每次变更的历史，改错了能直接 rollback。这是 Nacos 区别于"配置写在 yaml 里 + git" 模式的核心价值——不需要发版本就能改配置，但同时有审计。

2. 看订阅者

Nacos 控制台 → 配置详情 → “订阅者列表”，能看到当前哪些实例订阅了这个配置——调试"为什么我的应用没收到推送"的第一步。

3. 应用侧日志

1

DEBUG com.alibaba.nacos.client = DEBUG

打开后能看到拉配置、心跳、推送等所有交互的细节。

十、生产配置 Checklist

部署前对照这份清单：

Namespace 按环境划分
Group 按服务划分
Data ID 按职责拆分（业务/中间件/开关）
共享配置走 shared-configs
使用 @ConfigurationProperties 而非 @Value
@RefreshScope 不加在 @Configuration 上
数据存储改 MySQL（不要嵌入式 Derby）
集群模式 ≥ 3 节点
鉴权开启 + 多账号权限隔离
JVM 内存 ≥ 4G
K8s 部署挂 PV
应用启动有 fallback 配置
Actuator 监控接入
业务配置变更走审批流程

小结

把全文压一句：

Nacos 的真正价值不在『配置存哪里』，而在『配置变更能可控、可审计、能秒级生效』——但要让它真正可靠，命名空间、监听机制、集群部署一个都不能省。

记住几条工程纪律：

环境分 namespace，服务分 group，配置按职责拆 Data ID
优先 @ConfigurationProperties，少用 @Value + @RefreshScope
生产必上 MySQL + 3 节点 + 鉴权
永远要有本地 fallback——配置中心是单点故障源

把 Nacos 用对，是国内 Spring Cloud 项目走得远的基础设施之一。

Spring Cloud 微服务之间如何避免循环依赖

Thu, 11 Apr 2024 16:00:00 +0800

一个隐性而致命的问题

微服务团队成长到一定规模后，几乎都会遇到服务之间的循环依赖：

1

订单服务 → 用户服务 → 订单服务

朴素的解决思路：“只是调用关系而已，能跑就行”——但这种循环会带来一系列问题：

启动顺序混乱：A 启动时要连 B 的健康检查，B 启动时要连 A 的——谁先启动？
故障爆炸式扩散：A 挂 → B 挂 → A 挂——单点故障变成集群故障
测试灾难：要起 A 必须先起 B、起 B 必须先起 A
架构腐化：循环让"职责边界"完全消失——任何修改都要全链条考虑
死锁/雪崩风险：链路超时、回调嵌套、连接池耗尽
重构寸步难行：想拆分服务时所有循环都拦着

循环依赖不是技术问题，是架构问题。本文从识别、分析、解决三个层面讲清楚。

一、循环依赖的几种典型形态

1. 直接循环（A ↔ B）

flowchart LR
 A[订单服务] -->|查用户信息| B[用户服务]
 B -->|查用户最近订单| A

最常见的——双方都要对方的数据。

2. 间接循环（A → B → C → A）

flowchart LR
 A[订单服务] --> B[支付服务]
 B --> C[风控服务]
 C --> A

链路一长就难发现——往往是新增功能时引入的。

3. 通过事件的"软循环"

flowchart LR
 A[订单] -->|OrderCreated 事件| MQ
 MQ --> B[积分服务]
 B -->|RPC 查订单状态| A

虽然是异步，但积分服务回头查订单服务——本质上还是循环。

4. 启动期循环

A 启动时要从 B 拉某个全局配置，B 启动时也要从 A 拉某个配置——启动期死锁。

二、为什么循环依赖会出现

业务视角看是"一不小心引入"——但本质原因通常是：

1. 实体边界没分清

订单和用户都是核心实体——从用户视角"查我的订单"、从订单视角"查谁下的单"——两个视角看起来都合理，于是双向都建了 RPC。

2. 共享数据没有归属

“用户最近一笔订单”——这个数据算用户属性还是订单属性？没人 say 清楚归谁，最后就两边都查。

3. 微服务过细

把"用户登录"和"用户资料"拆成两个服务——结果它们成天互相调用。过度拆分是循环的温床。

4. 业务驱动反向调用

最常见的——“产品要订单详情页面也展示用户头像”：

1

订单服务（主）→ 用户服务 ✓ 正常依赖

下一个版本，“用户主页要展示最近订单”：

1

用户服务（主）→ 订单服务 ❌ 反向依赖来了

业务一推动就改，没人检查依赖图——循环就此诞生。

三、识别：怎么发现循环

1. 静态扫描

整理所有服务间的 OpenFeign / RestTemplate 调用：

1

grep -r "@FeignClient" --include="*.java"

输出每个服务依赖哪些服务，画个有向图——用 Graphviz 或简单的脚本。

2. 链路追踪

SkyWalking / Zipkin / Jaeger 在生产里聚合调用拓扑——自动看到 A 调 B、B 调 A。

3. 服务注册中心

Nacos / Consul 看每个服务的调用方列表——能看到反向依赖。

4. 在 CI 加检查

1
2
3


# 每次 PR 检查依赖图，新增反向调用直接 fail
- name: Check service dependencies
 run: ./scripts/check-deps.sh

把检查变成机制——比每次 review 时人工排查靠谱。

四、解决方案

方案 1：合并服务（最直接）

如果 A 和 B 长期互相调用——它们可能就该是一个服务。微服务不是越细越好——业务边界不清的两个服务合并回去是合理的。

判断标准：

数据强一致需求
改动通常一起来
链路上 80% 都是双向调用

方案 2：抽出共享层

A 和 B 都依赖某段共享逻辑/数据——抽到 C：

1
2


重构前：A ↔ B
重构后：A → C ← B

例如"用户基础信息"抽到 user-base 服务——A 和 B 都查 C，互不依赖。

方案 3：事件驱动 + 数据冗余

最优雅但工程量大——A 改了数据后发事件，B 订阅事件维护自己一份冗余：

flowchart LR
 A -->|UserUpdated 事件| MQ
 MQ --> B[B 维护用户冗余表]
 User --> B
 B -.无需调 A.-> B

B 不再实时调 A 取数据——读自己的本地冗余。代价是数据有微小延迟，但循环彻底消除。

方案 4：依赖反转

A 调 B 是为了"通知 B 一件事"——改成 B 主动监听：

1
2


重构前：A → B（通知 B 用户状态变化）
重构后：A 发事件 → B 订阅

依赖方向倒过来——A 不再依赖 B。

方案 5：API Gateway / BFF 聚合

页面需要 A + B 的数据——不应该让 B 调 A，应该让 BFF（Backend For Frontend）调 A 和 B 聚合：

flowchart LR
 Frontend --> BFF
 BFF --> A
 BFF --> B

A 和 B 的依赖被 BFF 拆开——它们之间不再相互依赖。

方案 6：批量查询代替单次

如果 B 调 A 是为了"批量查 1000 个用户的订单"——让 A 提供批量接口，B 拿到 ID 列表后批量请求一次：

1
2


之前：B 循环 1000 次调 A
之后：B 一次性发 1000 个 ID 给 A

调用次数大幅降低 → 即使保留依赖，影响也小。

五、典型场景的具体解法

场景 1：订单展示要用户头像，用户主页要展示订单数

重构前	重构后
订单服务 ↔ 用户服务（互相调用）	BFF 聚合：BFF → 订单服务、BFF → 用户服务
	订单服务里冗余存 user_name + avatar_url

场景 2：积分服务通过事件加积分，但要查订单金额

重构前	重构后
订单 → 发事件 → 积分 → RPC 查订单	订单发事件时事件载荷里就带金额

场景 3：风控决策要查多个上下文

重构前	重构后
风控服务 ↔ 订单 ↔ 用户 ↔ 风控	调用方主动把上下文打包传给风控

六、架构层面的纪律

1. 严格的"上下游"层级

把服务分层——只允许上层调下层，下层永不调上层：

flowchart TD
 BFF[BFF / API 层]
 BFF --> Domain[业务领域服务]
 Domain --> Foundation[基础服务
用户/账户/支付]
 Foundation --> Infra[基础设施
消息/存储/索引]

任何"下层调上层"PR 直接 reject。

2. 共享数据归属唯一

每个数据的"主人"只有一个服务——其他服务要用，要么调主人，要么订阅事件维护冗余。

3. 增量加 PR 时强制依赖检查

1
2
3


# 检查是否引入新的 cross-tier 依赖
- name: Check architecture
 run: archunit-test

ArchUnit 这种工具能在测试里强制架构规则——机制保证大于人为约束。

4. 定期审视依赖图

每个迭代结束 review 一次依赖图——发现"上次没有的反向依赖"立刻处理。

七、Spring Cloud 特有的注意点

1. OpenFeign 自调本服务的隐患

服务内部代码注入指向"本服务名"的 FeignClient：

1
2
3
4
5
6
7
8


@FeignClient(name = "user-service")
public interface UserClient { ... }

// 用户服务里
@Service
class UserService {
 @Autowired private UserClient userClient; // 指向本服务
}

这种用法不会立刻报错——Feign 通过注册中心负载均衡转发，请求会落到本服务的某个实例（可能是自己也可能是同名其他实例）。但它是个反模式：

普通自调虽不立刻失败，但会绕一跳网络、多一段 trace、丢失本地事务上下文
若调用链最终回到调用方所在的同一个接口（A 通过 LB 调到 A 自己，又走相同方法），就会形成无限递归 → 栈溢出 / 连接池耗尽
调用链路在 trace 里突然多一段，排查困难

结论：本服务的内部能力直接走 Bean 调用，不要通过 FeignClient 绕一圈。要复用接口契约可以把 Client 接口和 Controller 实现拆出 SPI 模块共享。

2. Eureka / Nacos 服务发现的循环

A 启动时连不上 B，B 启动时连不上 A——注册中心会等到双方都活着才允许调用。但如果配置了"启动期健康检查"，就会双方互等。

解决：启动期检查只用基础设施（DB、Redis），不要互相检查。

3. 配置中心的循环

A 服务启动时要从配置中心拉 B 的地址——但配置中心要先注册到 A 才能正常工作？这种设计是错的。配置中心应该是最底层无依赖的服务。

八、一份"循环依赖"治理清单

发现循环后按这个流程处理：

明确循环类型——直接 / 间接 / 软 / 启动期
画出当前依赖图
判断业务边界——是不是该合并服务？
如果不合并——选方案：抽共享层 / 事件 + 冗余 / 依赖反转 / BFF
设计冗余数据的同步机制——保证最终一致
测试覆盖——确保循环消除后业务不退化
加 ArchUnit 检查防止回退

九、一些反例

反例 1：为了"性能"双向冗余

A 存 B 的数据、B 存 A 的数据——两边都要同步对方的变化。最终变成"两个真相"——数据不一致。冗余应该单向。

反例 2：用 MQ 假装解耦

1
2


A → MQ → B
B → MQ → A

虽然走 MQ 不直接调用，但本质还是循环——只是把同步等待换成异步等待。问题没解决。

反例 3：用注释"承认循环"

1
2


// TODO: 这里是循环依赖，暂时无法避免
@Autowired private UserClient userClient;

写注释承认问题等于不解决——技术债越堆越多。循环依赖应作为架构债务专项跟踪，原则上不允许长期存在。

小结

把全文压一句：

服务间循环依赖不是『可以容忍的小毛病』——它是架构腐化的早期信号，会慢慢腐蚀整个系统。发现一个解决一个。

工程纪律：

服务分层，禁止上下层逆向调
数据归属唯一，跨域用事件 + 冗余
共享逻辑下沉到独立服务
页面聚合走 BFF
CI 自动检查，不靠人工
循环依赖出现立刻处理，不容忍

把这套做对，微服务才能真正"独立、可演进、可扩展"——而不是变成"分布式单体"。

微服务通信用 OpenFeign 还是 Dubbo

Mon, 19 Jul 2021 16:00:00 +0800

一句话先把问题摆出来

服务之间应该用 HTTP 还是 RPC 通信？

这是任何一个 Java 微服务团队都绕不过去的选择。社区里两套生态各有铁粉：

Spring Cloud + OpenFeign：基于 HTTP/REST，整套 Spring 全家桶最自然的延伸
Apache Dubbo：阿里开源的 RPC 框架，国内大厂的事实标准

新人选型时常常陷入一个误区——纠结于"谁性能好"。但只看 QPS 这件事会让你错过更重要的因素：协议哲学、生态契合度、运维成本、组织能力。

本文把这两套方案的差异、各自优劣、以及不同场景下的选型建议讲清楚。

协议层：HTTP 与 RPC 的本质差异

OpenFeign：HTTP 客户端的"声明式"

Feign 的本质是对 HTTP 客户端的封装。你定义一个接口，加几个注解，Feign 用动态代理把方法调用翻译成 HTTP 请求：

1
2
3
4
5
6
7
8


@FeignClient(name = "order-service")
public interface OrderClient {
 @GetMapping("/orders/{id}")
 OrderVO getById(@PathVariable Long id);

 @PostMapping("/orders")
 OrderVO create(@RequestBody OrderCreateDTO dto);
}

调用方写起来像调本地方法：

1

OrderVO order = orderClient.getById(1001L);

但底层走的是标准 HTTP——序列化通常是 JSON，传输是文本，每次请求都有完整的 HTTP 头开销。所以 Feign 的本质就是一个"会的协议"被打包成"省心的姿势"。

Dubbo：原生 RPC

Dubbo 是为 RPC 而生的。客户端和服务端都是 Java，直接通过自定义的二进制协议（Dubbo 协议、Triple 协议等）传输 Java 对象。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


// 服务端
@DubboService
public class OrderServiceImpl implements OrderService {
 @Override public OrderVO getById(Long id) { ... }
}

// 调用端
@DubboReference
private OrderService orderService;

OrderVO order = orderService.getById(1001L);

注意——两端共享同一个接口（Java interface），通过注册中心拉到地址后建立长连接。没有 URL，没有 HTTP 头，序列化默认是 Hessian 或 Kryo（紧凑二进制）。

性能差距：到底差多少

实测数据（同机房、千兆内网、相同业务复杂度）：

指标	OpenFeign + Spring Cloud	Dubbo（默认 dubbo 协议）
单次 RTT	5-15 ms	1-3 ms
序列化大小	JSON，相对大	Hessian/Kryo，2-5 倍小
单连接 QPS	数千	数万
CPU 序列化开销	较高	较低

Dubbo 在性能上确实有显著优势——但请注意三点：

上述差距在"调用频率高、链路深"时才显著放大；多数业务一次接口调用 50-100ms，5ms 和 1ms 的差距完全淹没在业务里
Feign 改用 HTTP/2 + Protobuf 就能逼近 RPC 性能（Spring 6 / Spring Cloud 2022+ 支持）
性能问题大多在数据库、外部 API、缓存上，通信协议很少是瓶颈

不建议把『性能』当成选 Dubbo 的唯一理由。 如果你不能拿出一个真实的、被 Profiler 证实的、序列化耗时占主导的瓶颈，那性能差距对你来说几乎没意义。

生态契合度：谁配谁更顺手

维度	Spring Cloud + Feign	Dubbo
注册中心	Eureka / Nacos / Consul	Zookeeper / Nacos
配置中心	Spring Cloud Config / Nacos	Apollo / Nacos
网关	Spring Cloud Gateway	通常前置 Nginx + 业务网关
熔断	Resilience4j / Sentinel	Sentinel（原生集成）
链路追踪	Sleuth + Zipkin	Skywalking / 自建 Filter
服务治理	基础	强（路由、灰度、限流、调度都内置）
跨语言	天然 ✓（HTTP）	△（Triple 协议支持，gRPC 互通）
调试工具	Postman / curl 直接打	Telnet / Dubbo Admin

Spring Cloud 的强项是全家桶生态完整，Feign 只是其中一环；Dubbo 的强项是服务治理特性原生且强大——做到 Spring Cloud 同等治理能力，需要拼接一堆组件。

跨语言：被低估的因素

这是很多团队选型时最被低估的因素。

Feign 走 HTTP/REST：只要对方能发 HTTP 请求，谁都能调。Python、Go、Node 团队对接你的服务零门槛
Dubbo 默认是 Java-only：跨语言要切到 Triple 协议（基于 gRPC），配置和工具链都比 HTTP 复杂

如果你的组织是多语言团队——前端 Node、数据团队 Python、运营内部系统是 PHP——选 Feign 几乎没有疑问。强行用 Dubbo 让其他语言对接，会成为长期摩擦。

如果你的组织清一色 Java，跨语言不是问题，那 Dubbo 的劣势就消失了。

调试与可观测性

Feign 优势

HTTP 接口能直接用 Postman / curl 调试
浏览器开发工具能看请求响应
Nginx / 网关日志能直接读
Tcpdump / Wireshark 抓包能看明文

Dubbo 劣势

二进制协议要专用工具（Dubbo Admin、Telnet 命令）
Mock 和压测要起 Java 客户端
排查 “客户端发了什么” 比 HTTP 麻烦得多

1
2
3
4
5
6
7


# Feign 接口随时打：
curl http://order-service/orders/1001

# Dubbo 类似的事要用 telnet：
telnet 192.168.1.10 20880
ls com.xx.OrderService
invoke com.xx.OrderService.getById(1001)

可观测性是长期运维的核心痛点——调试方便程度对开发体验的影响远超 5ms 的性能差距。

学习曲线与团队上手成本

因素	Feign	Dubbo
新人上手	几乎零门槛（懂 HTTP 即可）	中等（注解 + 注册中心 + 协议）
大团队培训	简单	中等
调试体验	优	中
扩展定制	需懂 OkHttp / RestTemplate	需懂 Filter / Invoker SPI

新人入职第一周能用的是 Feign，三周后才能驾驭 Dubbo——团队规模一大，这个差距会成倍放大。

服务治理深度：Dubbo 的硬实力

如果说性能是 Dubbo 被高估的优势，那服务治理才是它真正的护城河。

Dubbo 原生支持的能力清单（Spring Cloud 多数都要拼装实现）：

多版本并行：@DubboReference(version = "1.0.0") 直接路由到指定版本服务
基于条件的路由规则：根据 Header / 参数 / 客户端 IP 路由到不同实例（灰度发布利器）
应用级 / 接口级粒度的治理
管理后台 Dubbo Admin 可视化调整路由、权重、限流，无需改代码
服务分组：环境/业务隔离

这些在 Spring Cloud 体系里要靠 Gateway + 自定义 Filter + Sentinel + Service Mesh 拼出来——能做，但维护成本高。

如果你做的是复杂的内部多团队协作系统（金融、电商核心链路），Dubbo 的治理能力会显著省心。

选型决策树

flowchart TD
 Start([选 Feign 还是 Dubbo?])
 Multi{多语言团队?}
 Start --> Multi
 Multi -->|是| Feign1[Feign / REST]
 Multi -->|否，纯 Java| Scale{服务规模?}
 Scale -->|小型，< 20 服务| Feign2[Feign / REST]
 Scale -->|中大型| Gov{是否需要复杂治理?
多版本/灰度/路由}
 Gov -->|不需要| Feign3[Feign 也够用]
 Gov -->|需要| Perf{对单次 RPC 性能敏感?}
 Perf -->|敏感| Dubbo1[Dubbo]
 Perf -->|不敏感| Choice[基于团队熟悉度选]

一些被反复争论的话题

争论 1：Spring Cloud 已经够强，Dubbo 没必要

部分对——如果你的业务复杂度还没碰到治理瓶颈，Spring Cloud 完全够。但有些治理特性（多版本、规则路由）原生 Spring Cloud 真的拼不出 Dubbo 那么顺手。

争论 2：Dubbo 把简单事情复杂化

部分对——Dubbo 的概念多（Provider/Consumer/Registry/Monitor，加上 Filter/Invoker/Cluster），新人确实一脸懵；但一旦上手，业务代码就和 Feign 一样简洁。

争论 3：现在该用 gRPC

gRPC 是个好选择，性能接近 Dubbo，跨语言天然支持。但生态在 Java 圈子相对薄弱——和 Spring 集成、注册中心选型、可观测性都要自己组装。Triple 协议（Dubbo 3）就是兼容 gRPC 的，意图是把"跨语言 + Dubbo 治理"一并拿下。

争论 4：直接用 Service Mesh

Mesh 把通信和治理下沉到 Sidecar，应用层只用最朴素的 HTTP/gRPC。理论上是终极方案，但运维 K8s + Istio 的复杂度让多数中小团队望而却步。

实战建议

我自己在团队里推的一份简版规则：

新启动的中小项目：直接 Spring Cloud + Feign。生态完整、上手快、调试方便，性能问题先不要担心
已有 Spring Cloud 体系的成熟团队：继续用 Feign，需要更高性能时点对点改 gRPC，不要整体迁 Dubbo
大量内部 Java 服务、纯 Java 技术栈、强治理需求：Dubbo（或 Dubbo 3）。多版本、灰度路由这些原生能力会省心
有跨语言需求：Feign / gRPC，不要 Dubbo（除非用 Triple）
绝不要"大力出奇迹"全家桶迁移：从 Spring Cloud 全部迁到 Dubbo 是高成本低收益的事，点对点重构才是务实做法

1
2
3
4
5
6


// 一个混合栈的例子：核心高频接口走 Dubbo，对外业务走 Feign
@FeignClient(name = "user-service")
public interface UserClient { ... } // 对外 / 跨语言

@DubboReference(version = "1.0.0")
private InventoryService inventory; // 内部高频

混合用没什么问题，只要团队两套都熟。

小结

把全文压成一句话：

OpenFeign 让通信变简单，Dubbo 让治理变强大。多数项目应当从 Feign 开始，治理瓶颈真正出现时再选择性引入 Dubbo——而不是反过来。

性能、生态、跨语言、调试、团队成本是五个真正影响选型的维度。别让"哪个性能好"这个伪问题误导你——通信协议很少是系统瓶颈，能让团队走得远的选择，永远是简单、可调试、生态完整的那一个。