HSF vs Dubbo：阿里巴巴 RPC 框架深度对比#

HSF#

HSF 使用基于 Netty 构建的私有、非标准二进制协议。主要特征：

• 序列化：Hessian2 是默认且占主导地位的选择
• 连接模型：消费方与提供方之间的长连接池
• 传输层：TBRemoting，基于 Netty 的内部抽象层
• 可扩展性：实际上是封闭的——本质上只有 HSF 协议一种
• 网关需求：由于协议是非标准的，外部访问需要 HSF 专用网关

Dubbo#

Dubbo 采取了根本不同的方式，采用基于 SPI 的协议扩展机制：

• 内置协议：dubbo://、rest://、gRPC、Triple、Hessian、Thrift、Redis
• Triple 协议：Dubbo 3.x 的原生协议，基于 HTTP/2，支持 Protobuf，专为跨语言互操作和云原生环境设计
• 序列化：Protobuf（Dubbo 3.x 推荐）、Hessian2（纯 Java），以及 JSON、Kryo、FST 等
• 连接模型：多种策略——单连接、多路复用、重连策略
• 可扩展性：通过 Dubbo 的 SPI 机制完全可插拔；可以接入自定义协议实现

核心差异#

HSF 是封闭且垂直整合的——一种协议、一种序列化格式、一种传输层。这简化了阿里内部的运维，但限制了灵活性。Dubbo 是开放且水平可扩展的——可以根据场景选择协议和序列化方式，包括 HSF 无法覆盖的跨语言场景。

HSF#

HSF 的注册栈与阿里内部基础设施深度耦合：

这套能力强大但不可移植。HSF 无法脱离阿里周边基础设施独立运行。

Dubbo#

Dubbo 暴露了注册中心抽象，提供多种内置实现：

• ZooKeeper——经典选择，经过大规模生产验证
• Nacos——阿里巴巴的开源方案，整合了服务发现和配置管理
• Redis、Consul、Etcd——适合已投资于这些生态的团队
• Kubernetes API——在 K8s 集群中实现原生服务发现，无需独立注册中心

核心差异#

HSF 的注册模型是一个基础设施底盘——与 ConfigServer、Diamond 和 VipServer 不可分离。Dubbo 的模型是一个可插拔组件——一行配置即可从 ZooKeeper 切换为 Nacos 或 Consul。Dubbo 开箱即用，随处可部署；HSF 只能在阿里内部运行。

HSF#

HSF 直接集成了 Sentinel（阿里巴巴的流量控制框架）：

• 基于QPS的提供方限流
• 基于线程池的限流，防止资源耗尽
• 基于错误率或慢调用阈值的熔断
• 热点参数限流——识别并限流具有特定参数值的请求
• 基于系统负载指标（CPU、负载均值、RT）的自适应过载保护
• SwitchCenter：手动”熔断开关”用于紧急降级——运维人员可以实时切换服务端点的开/关状态
• 内建丰富的监控和指标采集

Dubbo#

Dubbo 支持多种集成选项：

• Sentinel——与 HSF 使用的相同流量控制库，作为 Dubbo 扩展可用
• Hystrix——Netflix 的熔断器（现已进入维护模式，但仍在使用）
• Resilience4j——轻量级、函数式编程友好的替代方案

Dubbo 的方式赋予团队选择自由，但开箱体验不如 HSF 的深度 Sentinel 集成，尤其是在指标仪表盘和运维工具方面。

核心差异#

HSF 提供了更紧密、更具主见的韧性栈，可观测性更丰富。Dubbo 提供灵活性——可以选择熔断器库——但集成不够无缝，需要更多手动配置。

HSF 对 Dubbo 3.0 的贡献#

1. 应用级服务发现——从接口级注册（在大规模下会导致注册中心膨胀）迁移到应用级注册
2. Triple 协议——下一代协议，支持 HTTP/2、流式传输和 Protobuf
3. 流量路由（Router Chain）——灵活的链式路由规则，支持金丝雀发布、A/B 测试和同机房路由
4. Reactor 线程模型——基于 Netty 事件循环的异步非阻塞 IO 线程模型

这一贡献意味着 Dubbo 3.x 不仅仅是 Dubbo 2.x 的迭代——它吸收了 HSF 在阿里规模下十余年生产环境锤炼的经验。

服务粒度#

• 按调用方类型拆分：不同的消费方角色（内部、合作伙伴、公共）应面向不同的服务接口，避免无关关注点耦合
• 版本管理：对于不兼容的 API 变更，使用 Dubbo 的 version 标签而非修改接口名。消费方显式声明期望的版本

协议选择#

序列化#

• Dubbo 3.x：优先选择 Protobuf——更小的传输体积、Schema 演进、原生跨语言支持
• 纯 Java（Dubbo 2.x 或 HSF）：Hessian2 仍是可靠的默认选择
• 避免在生产环境使用 Java 原生序列化——跨版本脆弱且存在安全隐患

线程池隔离#

通过配置不同的线程池，将核心业务服务与辅助服务分离。这防止非关键流量的激增饿死关键路径：

1
<dubbo:protocol name="dubbo" dispatcher="message" threadpool="fixed" threads="200" />

为每个服务组分配独立的端口和线程池，使一个池中的”吵闹邻居”不会影响另一个。

超时配置#

• 黄金法则：消费方超时必须小于提供方超时。如果消费方在提供方完成之前放弃，提供方做了无用功，而消费方也得不到结果。
• 重试：默认设置 retries="0"（Dubbo 默认的 2 对大多数非幂等操作过于激进）。仅对幂等读操作显式启用重试。

1
<dubbo:consumer timeout="3000" retries="0" />
2
<dubbo:provider timeout="5000" />

负载均衡#

同机房路由#

优先选择同区域提供方以最小化延迟，跨区域故障转移作为后备。在 Dubbo 3.x 中，这通过 Router Chain 实现：

1
dubbo:
2
  consumer:
3
    router:
4
      zone-aware:
5
        enabled: true
6
        prefer-same-zone: true

Sentinel 集成#

• 提供方：应用 QPS 限制和线程池限制以防止过载
• 消费方：添加熔断，使故障的提供方不会导致上游级联失败
• 定义降级规则：熔断开启时怎么办——回退到缓存响应、返回默认值或快速失败

异步调用#

• 使用 CompletableFuture 进行异步 RPC 调用——这是标准的 Java 惯用法，与响应式框架组合良好
• 不要滥用 Dubbo 底层 NIO 传输来实现业务级异步编排。传输层的非阻塞是为了 IO 效率，而非应用级并发建模。应在 API 层使用 Future 或响应式流来建模异步工作流。

启动顺序#

在消费方引用上设置 check="false" 以消除启动顺序依赖。如果不设置，消费方在提供方之前启动时会初始化失败。设置 check="false" 后，消费方可以成功启动并延迟连接提供方：

1
<dubbo:reference id="orderService" interface="com.example.OrderService" check="false" />

升级到 Dubbo 3.x#

如果你仍在使用 Dubbo 2.x，迁移到 3.x 将带来：

• 应用级服务发现：大幅降低大规模下注册中心的内存压力
• Triple 协议：开启跨语言服务的大门
• 流量路由：细粒度的金丝雀发布和 A/B 测试
• 性能提升：来自 HSF 内核的 Reactor 线程模型