RPC Framework

项目做了什么

客户端不直接依赖服务端地址，而是通过服务名找到可用节点。Protobuf 负责消息定义与序列化，muduo 提供 Reactor 网络模型，Zookeeper 保存服务注册信息并通过 Watcher 感知节点变化。

项目还包含连接池和一致性哈希，让调用方可以复用 TCP 长连接，并把请求稳定地分配到服务节点。

一次调用经过哪些层

Caller
  │
  ├─ RpcChannel：根据服务名选择节点
  ├─ ConnectionPool：复用 TCP 长连接
  ├─ Protobuf：序列化请求与响应
  ├─ Zookeeper：注册、发现、Watcher 更新
  └─ Provider：反序列化并分发到具体方法
  │
  └─ Response

这条链路把业务方法和传输细节分离开来：业务只描述服务和方法，框架负责寻址、编码、连接和回包。

技术取舍

• TCP + 自定义消息头：在 Protobuf 二进制数据外增加长度和类型信息，处理粘包与拆包。
• 临时节点 + Watcher：服务进程退出或会话断开后，注册信息可以随连接状态清理，客户端收到变化后刷新本地节点列表。
• 连接池 + 一致性哈希：减少重复建连，并让节点变化时的请求迁移范围更可控。

实验记录

最新测试包含 100 个并发线程、每线程 1,000 次调用，共 100,000 次请求，两种环境均为 0 次失败。Ubuntu 原生环境约 16952 QPS，Docker Compose 环境约 16633 QPS。

该结果只描述当前实现、配置和测试环境，不作为跨机器性能结论。后续优化清单已经记录服务就绪等待、请求超时重试、连接失效检测、连接池动态扩缩容、协议版本和集成测试。