Dubbo vs gRPC vs Feign 对比#

面试官问候选人小李："你们公司内部服务间调用用的什么框架？"

小李："Dubbo。"面试官："为什么选 Dubbo 不选 gRPC？"

小李说："因为团队熟悉..."面试官追问："那如果现在让你重新选型，你会怎么选？"

小李开始犹豫。

【面试官心理】 这道题我用来试探候选人的技术视野和选型能力。能从架构、性能、团队、生态等多个维度分析选型的候选人，说明他有技术决策能力。这种候选人在我这里是 P7 的潜力股。

#一、三大框架定位 🔴

#1.1 定位对比

graph TD
    A[RPC 框架选型] --> B{Dubbo}
    A --> C[gRPC]
    A --> D[Feign]

    B --> E[Java 为主<br/>高性能<br/>强治理能力]
    C --> F[跨语言<br/>云原生<br/>HTTP/2+Protobuf]
    D --> G[Spring Cloud<br/>声明式<br/>绑定 Ribbon]

    E --> H[阿里/内部服务]
    F --> I[跨语言<br/>微服务间调用]
    G --> J[Spring Cloud 生态]

#1.2 ❌ 错误示范

候选人原话："Feign 就是 Dubbo 的替代品，都可以用。"

问题诊断：

• 混淆了 HTTP 客户端和 RPC 框架的概念
• Feign 本质是 HTTP 调用，不是 RPC
• 性能差距巨大（HTTP vs TCP 二进制）

【面试官心理】 技术选型不是"哪个火用哪个"，而是根据业务场景、团队能力、技术生态综合决策。能说清楚选型原因的候选人，才是真正有技术判断力的人。

#二、Dubbo：Java 生态的 RPC 王者 🔴

#2.1 核心优势

Dubbo 是阿里巴巴开源的高性能 RPC 框架，在 Java 生态中无可匹敌：

graph TD
    subgraph Dubbo["Dubbo 核心能力"]
        A[多协议<br/>dubbo/http/grpc]
        B[服务治理<br/>路由/负载均衡]
        C[注册中心<br/>ZooKeeper/Nacos]
        D[配置中心<br/>动态配置]
        E[元数据中心<br/>接口元数据]
    end

为什么 Dubbo 快：

1. TCP 自定义协议：Dubbo 协议头只有 16 字节，比 HTTP 头小得多
2. Kryo 序列化：比 Protobuf 略快（但不支持跨语言）
3. Netty NIO：异步 IO，高并发下性能优异
4. 连接池复用：长连接，避免 TCP 连接建立开销

#2.2 Dubbo 3.0 的性能

Dubbo 3.0 在性能上有质的飞跃：

#2.3 适用场景

• Java 内部服务调用：高性能、低延迟
• 需要强治理能力：路由、限流、熔断
• Spring Cloud Alibaba 生态：无缝集成 Nacos/Sentinel
• 超大规模集群：应用级服务发现降低注册压力

#三、gRPC：跨语言的云原生首选 🟡

#3.1 核心优势

gRPC 是 Google 主推的跨语言 RPC 框架，云原生时代的标配：

IDL 驱动开发：

syntax = "proto3";

service OrderService {
    rpc GetOrder(GetOrderRequest) returns (Order);
    rpc StreamOrders(GetOrdersRequest) returns (stream Order);
}

message Order {
    string id = 1;
    double amount = 2;
}

#3.2 为什么 gRPC 适合跨语言

gRPC 的好处：

1. 强类型契约：.proto 文件是服务契约，任何语言都可以解析
2. 代码生成：protoc 插件为每种语言生成强类型客户端/服务端
3. 版本兼容：通过字段编号管理，API 演进不影响旧客户端

#3.3 适用场景

• 跨语言调用：Go/Python/Node.js 客户端调用 Java 服务
• 微服务间通信：Kubernetes 环境下的服务网格
• 移动端调用：移动端和后端的通信
• 对性能要求极高：HTTP/2 + Protobuf 的组合性能优异

#3.4 gRPC 的局限性

• 治理能力弱：没有注册中心、路由、限流
• 调试困难：二进制协议，需要工具解析
• Spring 集成不完善：需要额外适配

#四、Feign：Spring Cloud 的声明式 HTTP 客户端 🟡

#4.1 核心优势

Feign 的核心理念是声明式调用：你定义一个接口，Feign 帮你实现网络调用：

@FeignClient(name = "order-service", fallback = OrderClientFallback.class)
public interface OrderClient {

    @RequestMapping(method = RequestMethod.GET, path = "/orders/{id}")
    Order getOrder(@PathVariable("id") String id);

    @RequestMapping(method = RequestMethod.POST, path = "/orders")
    Order createOrder(@RequestBody CreateOrderRequest request);
}

#4.2 Feign vs Dubbo

#4.3 ❌ 错误示范

候选人原话："Feign 是 RPC 框架，性能和 Dubbo 差不多。"

问题诊断：

• 混淆了 HTTP 调用和 RPC 调用的本质
• Feign 本质是 HTTP 客户端，有 HTTP 头的开销
• 在高并发场景下，Feign 的性能只有 Dubbo 的 1/5

面试官内心 OS：这个候选人显然没有做过性能对比测试，只是在网上看过一些文章。

#4.4 适用场景

• Spring Cloud 生态内部：和 Ribbon/Eureka/Hystrix 集成
• HTTP 接口调用：对性能要求不高的场景
• 快速开发：声明式调用，开发效率高

#五、三维对比 🔴

#5.1 综合对比表

#5.2 性能测试数据

基于单核 2.5GHz CPU、1GB 内存的测试结果：

#5.3 选型决策树

graph TD
    A[RPC 选型] --> B{Spring Cloud 生态？}
    B -->|是| C{对性能要求高？}
    C -->|否| D[Feign<br/>开发效率高]
    C -->|是| E{需要跨语言？}
    E -->|是| F[gRPC<br/>跨语言+高性能]
    E -->|否| G[Dubbo 3.0<br/>Java 高性能]
    B -->|否| H{需要跨语言？}
    H -->|是| F
    H -->|否| G

#六、工程选型建议 🟡

#6.1 按业务场景选型

#6.2 按团队能力选型

#6.3 按性能需求选型

#七、生产避坑

#7.1 常见翻车点

1. Dubbo + Feign 混用：团队里有人用 Dubbo，有人用 Feign，导致地址发现不一致
2. gRPC 版本不兼容：不同语言的 gRPC 库版本不同，兼容性有问题
3. Feign 超时配置不合理：默认超时太长，导致错误延迟暴露
4. Dubbo 协议选择错误：Dubbo 2.7 默认用 dubbo://，Dubbo 3.0 建议用 Triple

#7.2 迁移注意事项

Feign -> Dubbo 迁移：

// Feign
@FeignClient(name = "order-service")
public interface OrderClient {
    @RequestMapping(method = RequestMethod.GET, path = "/orders/{id}")
    Order getOrder(@PathVariable("id") String id);
}

// Dubbo
@DubboReference
private OrderService orderService;

// Dubbo 只需要接口和 Spring 注入，不需要注解配置

Dubbo -> gRPC 迁移：

// Dubbo
@DubboService
public class OrderServiceImpl implements OrderService {
    public Order getOrder(String id) { ... }
}

// gRPC
public class OrderServiceImpl extends OrderServiceGrpc.OrderServiceImplBase {
    public void getOrder(GetOrderRequest request,
                         StreamObserver<Order> responseObserver) {
        Order order = orderRepository.findById(request.getOrderId());
        responseObserver.onNext(order);
        responseObserver.onCompleted();
    }
}

【面试官心理】 技术选型是考察架构能力的关键问题。能从性能、跨语言、治理能力、团队能力、生态集成等多个维度分析选型的候选人，说明他有全局视野。这种候选人在我这里是 P7 的潜力股。