gRPC与REST对比及选型#

全维度对比#

选型决策树#

                    ┌── 对外暴露给前端/第三方？
                    │       是 → REST
                    │       否 ↓
                    ├── 需要完整服务治理（Java 体系）？
                    │       是 → Dubbo (Triple 协议)
                    │       否 ↓
                    ├── 需要跨语言 + 高性能 + 流式？
                    │       是 → gRPC
                    │       否 ↓
                    └── 简单内部通信 → REST 也够用

典型架构#

              Internet
                 │
         ┌───── API Gateway ─────┐  (REST / GraphQL 对外)
         │                       │
    ┌────┴────┐            ┌─────┴────┐
    │ BFF 层  │            │ BFF 层   │
    └────┬────┘            └─────┬────┘
         │ gRPC                  │ gRPC
    ┌────┴────┐  gRPC   ┌──────┴─────┐
    │ 订单服务 │ ←────→  │ 库存服务    │
    └─────────┘          └────────────┘
         │ gRPC
    ┌────┴────┐
    │ 支付服务 │
    └─────────┘

混合使用最佳实践#

1. Gateway 层：REST/GraphQL 对外
2. 服务间同步调用：gRPC（性能敏感）或 Dubbo（Java 全家桶）
3. 服务间异步通信：消息队列（Kafka/RocketMQ）
4. 数据同步：gRPC Streaming 或 CDC

何时不用 gRPC#

• 前端直接调用（浏览器限制）
• 调试频繁需要可读性（curl 不方便）
• 团队不熟悉 Protobuf
• 简单 CRUD 无性能瓶颈

选型的核心原则是：对外 REST，内部 gRPC，Java 全家桶考虑 Dubbo。REST 的优势是浏览器原生支持、可读性强、生态成熟；劣势是 HTTP/1.1 性能低、JSON 文本序列化开销大、不支持流式。gRPC 基于 HTTP/2 多路复用和 Protobuf 二进制编码，性能高几倍，且有 .proto IDL 强类型约束，天然跨语言，适合内部服务高频通信。Dubbo 的优势是服务治理一体化（注册/路由/负载/监控内置），在 Java 体系内开发体验最好；新版 Triple 协议也兼容 gRPC。实际项目中我们 Gateway 对外暴露 REST API，内部微服务之间用 gRPC 同步通信、Kafka 异步解耦。需要注意 gRPC 在浏览器端需要 gRPC-Web 加 Envoy 代理，且调试不如 REST 方便，可以配合 grpcurl 或 Postman 的 gRPC 支持。

追问方向：

• “为什么不全用 gRPC？”→ 浏览器不原生支持、调试不方便、简单场景 overkill
• “Dubbo Triple 和 gRPC 什么关系？”→ Triple 协议兼容 gRPC，但额外提供 Dubbo 的服务治理能力
• “GraphQL 呢？”→ 解决前端灵活查询需求，和 gRPC 不是竞争关系（一个对外一个对内）

易错点：

• ❌ “gRPC 比 REST 好所以全用 gRPC”——对外 API 仍需 REST，考虑兼容性和可读性
• ❌ “REST 性能一定差”——HTTP/2+JSON 也能接受，瓶颈往往在业务逻辑和 DB
• ❌ “Dubbo 过时了”——Dubbo 3.x Triple 协议是 gRPC 超集，仍然活跃