RPC 概览
本节提供与 Kumo 系统相关的 RPC 框架概览，重点是场景驱动选择，而非深入协议分析。每个框架从三个维度进行比较：生态与使用场景、性能，以及集成与运维复杂度。
目标是根据实际业务或后端需求快速选择。对高 QPS 的宣传应谨慎对待，因为典型服务器的 CPU 负载限制和单线程能力使极端数值不现实。
生态与使用场景
| 框架 | 层级 | 优势 | 典型使用 / 场景 |
|---|---|---|---|
| gRPC | 业务层 | 多语言生态，广泛采用 | 业务层、流水线编排、多语言客户端 |
| httplib | 业务层 | 头文件库，轻量 | 快速原型、临时服务、验证用途 |
| brpc | 后端 | 成熟、高吞吐，支持 Raft | 后端服务、Raft 共识、高可靠性 |
| krpc | 后端 | Kumo 增强版 brpc，运维更便利 | 内部后端首选 |
| ACL | 后端 | 高质量 C++ 库 | 高性能后端服务，IO 密集型任务 |
| Thrift | 传统 | 性能适中 | 传统互操作，生态衰退 |
| Seastar | 极限 IO | NUMA 感知，高吞吐 | 极限 IO 服务，需专门运维 |
业务层偏向 gRPC 以支持多语言集成和流水线控制。后端层偏向 brpc/krpc 以获得吞吐和运维可靠性。极限 IO 框架如 Seastar 需要专业环境和运维支持。
性能指标
| 框架 | 单机典型 QPS | CPU 负载 | 说明 |
|---|---|---|---|
| gRPC | 3k–10k | 30–50% | 适合流水线编排；实际业务可达 |
| httplib | <1k | <20% | 仅适合轻量测试或原型 |
| brpc | 10k–30k | 40–70% | Raft 必需；需要运维经验 |
| krpc | 10k–30k | 40–70% | 优化 brpc，内部运维更便利 |
| ACL | 10k–30k | 40–70% | 高质量 C++ 后端服务 |
| Thrift | 5k–15k | 40–60% | 仅支持传统需求 |
| Seastar | 50k–100k+（纯 IO） | 50–70% | 极限 IO；需专门运维 |
CPU 负载超过 70% 风险高。多数宣称“百万 QPS”是理论值。业务层通常不会超过单机 10k QPS；后端可目标 30k QPS；极限 IO 场景需专业运维经验。
集成与运维复杂度
| 框架 | 语言支持 | 集成难度 | 运维说明 |
|---|---|---|---|
| gRPC | 多语言 | 中等 | 多个 C++ 库；kmpkg 简化集成 |
| httplib | C++ | 很低 | 头文件库，集成极简 |
| brpc | C++ | 中等 | 需运维经验；支持 Raft |
| krpc | C++ | 中等 | Kumo 增强版 brpc；内部运维更轻松 |
| ACL | C++ | 中低 | 高质量库；不适合多语言业务层 |
| Thrift | 多语言 | 中等 | 生态衰退；主要用于遗留系统 |
| Seastar | C++ | 高 | 运维复杂；NUMA 感知；需专用环境，成本高 |
业务层框架优先生态集成而非吞吐极限。后端框架需可靠应对高 CPU 和吞吐。极限 IO 框架如 Seastar 对协议栈管理要求专业运维。
总结
RPC 生态多样，选择应场景驱动：
- 业务层：使用 gRPC 支持多语言客户端和流水线编排。轻量替代如 httplib 仅适合快速原型。
- 后端层：brpc 或 krpc 提供高吞吐、成熟运维及 Raft 支持。ACL 可用于高性能 C++ 后端任务。
- 极限 IO：Seastar 仅适用于专门、高吞吐 IO 服务，需专业运维支持。
由于生态限制，实际实现选择较固定。特殊需求可能需要定制实现。