Dubbo on 牛哥聊技术

微服务通信用 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——而不是反过来。 **

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

理解 Java SPI：JDBC、SLF4J、Spring Boot 背后的机制

Tue, 22 Aug 2017 15:30:00 +0800

一个看似平淡的问题

写过 Java 的人都用过 JDBC：

1
2


Class.forName("com.mysql.cj.jdbc.Driver"); // 早期写法
Connection conn = DriverManager.getConnection(url);

但不少人没想过——DriverManager 怎么知道要去加载 MySQL 的驱动？ 它代码里又没写 import com.mysql...。

你换成 PostgreSQL 时，只要 pom 里依赖换一下，DriverManager 就自动识别了 PG 的驱动——没改一行 Java 代码。

这背后的机制叫 SPI（Service Provider Interface）。它是 JDK 留给框架开发者的"扩展点"，让框架定义接口、第三方提供实现、运行时自动发现并加载。

理解 SPI 是看懂 JDBC、Servlet、SLF4J、Spring Boot 自动装配、Dubbo 等所有"自动加载实现"框架的钥匙。

一、SPI 在做什么

API 与 SPI 的对比：

	API（Application Programming Interface）	SPI（Service Provider Interface）
调用方向	应用调框架	框架调应用
谁定义接口	框架	框架
谁实现接口	框架	应用 / 第三方
例子	Math.max() / List.add()	JDBC Driver / SLF4J Logger 实现 / 编解码器

最简洁的理解：API 是『你调我』，SPI 是『我调你』。

二、JDK 原生 SPI：ServiceLoader

JDK 提供的最朴素 SPI 工具——java.util.ServiceLoader。三步：

1. 框架定义接口

1
2
3
4
5


package org.example.payment;
public interface PaymentChannel {
 String getName();
 boolean charge(String userId, BigDecimal amount);
}

2. 应用/第三方写实现

1
2
3
4
5


package com.alipay.spi;
public class AlipayChannel implements PaymentChannel {
 @Override public String getName() { return "alipay"; }
 @Override public boolean charge(String u, BigDecimal a) { ... }
}

3. 在 META-INF/services 下声明

文件名：META-INF/services/org.example.payment.PaymentChannel

文件内容：

1
2


com.alipay.spi.AlipayChannel
com.wechat.spi.WechatChannel

框架加载所有实现

1
2
3
4


ServiceLoader<PaymentChannel> loader = ServiceLoader.load(PaymentChannel.class);
for (PaymentChannel c : loader) {
 System.out.println("found: " + c.getName());
}

只要 classpath 里有对应实现的 jar，就自动被发现——这就是 JDBC 不需要写 Class.forName 也能加载驱动的秘密。

三、JDBC 4.0 后的 SPI 实践

JDBC 4.0 之前，每次都要 Class.forName("com.mysql.jdbc.Driver")——靠类初始化触发驱动注册：

1
2
3
4


// MySQL Driver 类内部
static {
 DriverManager.registerDriver(new Driver());
}

JDBC 4.0 之后，MySQL 驱动 jar 里加了：

1
2


META-INF/services/java.sql.Driver
└─ com.mysql.cj.jdbc.Driver

DriverManager 启动时用 ServiceLoader 自动找所有 Driver 实现，Class.forName 这行代码就成了历史遗物。

四、ServiceLoader 的几个限制

1. 加载所有实现，不能选择性加载

ServiceLoader.load() 会实例化所有实现——10 个支付通道都用不上你只想要支付宝？没办法，全部都会被 new 出来。

2. 实现必须有无参构造器

1
2


public AlipayChannel(String appId) { ... } // ❌ 不行
public AlipayChannel() { ... } // ✓

需要参数？只能后续 setter 注入。

3. 没有"按 key 取实现"的能力

业务里通常是"知道用户选了 alipay，加载支付宝实现"。ServiceLoader 只能一股脑把所有实现都返回，再让你自己按 getName() 过滤。

4. 不支持 IoC 注入

实现里如果想 @Autowired 其他 Bean？不行——ServiceLoader 不知道 Spring 容器存在。

5. 类加载器问题

线程上下文 ClassLoader 是个老大难——容器化部署、OSGi 等场景下 ServiceLoader.load() 看不到某些 jar 的实现。

五、Dubbo SPI：JDK SPI 的强化版

Dubbo 团队觉得 JDK SPI 不够用，自己写了一套 SPI——位置一样在 META-INF/services / META-INF/dubbo 下，但能力翻倍。

文件格式：`key = 实现类`

1
2
3
4


# META-INF/dubbo/org.apache.dubbo.rpc.Protocol
dubbo = org.apache.dubbo.rpc.protocol.dubbo.DubboProtocol
http = org.apache.dubbo.rpc.protocol.http.HttpProtocol
hessian = org.apache.dubbo.rpc.protocol.hessian.HessianProtocol

按 key 取实现

1
2


ExtensionLoader<Protocol> loader = ExtensionLoader.getExtensionLoader(Protocol.class);
Protocol dubbo = loader.getExtension("dubbo"); // ★ 按 key 加载

不需要把所有实现都 new 一遍。

自适应扩展（Adaptive）

最强大的特性——根据运行时 URL 参数自动选择实现：

1
2
3
4
5


@Adaptive
public interface Protocol {
 Exporter export(Invoker invoker) throws RpcException;
 Invoker refer(Class type, URL url);
}

调用时根据 url.protocol 决定具体走哪个实现，业务代码完全不感知。这是 Dubbo 路由、协议适配、序列化适配等很多机制的底座。

依赖注入

Dubbo SPI 加载实现时会自动注入它依赖的其他 SPI 实现——有简化版 IoC：

1
2
3
4


public class DubboProtocol implements Protocol {
 private Codec codec; // 自动按类型注入
 public void setCodec(Codec codec) { this.codec = codec; }
}

IOC + AOP

加上 Wrapper 机制，能在所有实现外包一层"拦截器"——这就是 Dubbo 链式 Filter 的原理。

	JDK SPI	Dubbo SPI
按 key 加载	✗	✓
懒加载实现	✗	✓
依赖注入	✗	✓
AOP 包装	✗	✓
自适应扩展	✗	✓

六、Spring Factories：Spring 自己的 SPI

Spring Boot 也实现了类似的 SPI——spring.factories：

1
2
3
4
5
6


# META-INF/spring.factories
org.springframework.boot.autoconfigure.EnableAutoConfiguration=\
 com.example.MyAutoConfiguration

org.springframework.boot.env.EnvironmentPostProcessor=\
 com.example.MyEnvProcessor

Spring Boot 启动时会扫描所有 jar 的 spring.factories，按 key 加载对应类——这就是 starter 自动装配的本质。

Spring Boot 2.7 后逐步迁移到 META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports ，理由是按"接口名 = 文件名"的方式更清晰。

总结这几套 SPI 的演进：

flowchart LR
 JDK["JDK ServiceLoader
(全加载, 无 key)"]
 Spring["Spring Factories
(按 key 配置)"]
 Dubbo["Dubbo SPI
(IoC + AOP + 自适应)"]

 JDK --> Spring --> Dubbo

七、写一个自己的 SPI 框架（极简版）

理解 SPI 最快的方式是自己写一个。来个最小可工作版本：

 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


public class MySpi {
 private static final Map<Class<?>, Map<String, Object>> CACHE = new HashMap<>();

 public static <T> T load(Class<T> type, String name) {
 Map<String, Object> map = CACHE.computeIfAbsent(type, MySpi::loadAll);
 return (T) map.get(name);
 }

 private static Map<String, Object> loadAll(Class<?> type) {
 Map<String, Object> map = new HashMap<>();
 try {
 String path = "META-INF/myspi/" + type.getName();
 Enumeration<URL> urls = MySpi.class.getClassLoader().getResources(path);
 while (urls.hasMoreElements()) {
 try (BufferedReader br = new BufferedReader(
 new InputStreamReader(urls.nextElement().openStream()))) {
 String line;
 while ((line = br.readLine()) != null) {
 // 格式：key=class
 String[] kv = line.split("=", 2);
 Class<?> impl = Class.forName(kv[1].trim());
 map.put(kv[0].trim(), impl.getDeclaredConstructor().newInstance());
 }
 }
 }
 } catch (Exception e) {
 throw new RuntimeException(e);
 }
 return map;
 }
}

使用：

1
2
3


# META-INF/myspi/org.example.PaymentChannel
alipay = com.alipay.AlipayChannel
wechat = com.wechat.WechatChannel

1
2


PaymentChannel c = MySpi.load(PaymentChannel.class, "alipay");
c.charge(...);

加上"懒加载 + IoC + AOP"就是 Dubbo 那一套——核心思想都是"配置文件声明 + ClassLoader 加载"。

八、SPI 的常见踩坑

1. 文件路径写错

META-INF/services/全限定接口名——文件名要完整包名，不是简单名字。少一个 org.example. 就什么都加载不到。

2. 文件 BOM

UTF-8 with BOM 在某些 JDK 版本里会被读成"乱码包名"。用纯 UTF-8 不带 BOM 保存。

3. 实现类必须 public 无参构造器

AbstractXxxFactory 这种抽象类、private 构造器、没有无参构造器都加载失败。

4. 类加载器隔离

容器化部署时，框架代码可能用不同的 ClassLoader——ServiceLoader.load(Class) 默认用调用线程的 ContextClassLoader，复杂场景要显式指定。

5. SPI 失败静默

ServiceLoader 加载失败默认抛出 ServiceConfigurationError，但异常往往被框架吞了。生产排查时需要打开 SPI 加载的 DEBUG 日志。

九、什么场景该自己用 SPI

不要为了"看起来高级"而用 SPI——只有真正需要"框架代码不知道实现，但运行时能加载"时才值得：

✅ 适合 SPI 的场景：

写一个插件式框架——核心库定义接口，第三方提供实现
写一个SDK——支持多种序列化、多种存储后端
写一个多通道适配器——支付、消息推送、对象存储

❌ 不适合 SPI 的场景：

业务逻辑分发——直接用 Map<String, Strategy> 注入更清晰
简单的策略模式——枚举 + 工厂方法更简单
编译时已知所有实现——用接口注入就够了

记住一条："SPI 是给框架开发者的工具"——业务开发用 Spring 的 Map<String, T> 注入或者一个普通工厂类就够了。

小结

把全文压一句：

SPI 把"框架 → 实现"的依赖反转过来——框架定义接口，运行时由配置文件决定加载哪些实现。

理解 SPI 的几个层次：

JDK ServiceLoader：最朴素，全加载
Spring Factories：按 key 配置，能自动装配
Dubbo SPI：加上 IoC、AOP、自适应——可扩展性的天花板

工程上记住：

写框架/SDK 时考虑 SPI
业务里别滥用，简单策略用 Map 注入更清爽
文件路径、命名、字符编码三个坑特别多

把 SPI 看懂，你看 JDBC、Servlet、SLF4J、Spring Boot 自动装配的底层原理时会突然有种『原来都是这一套』的顿悟感。