RPC 项目

厨子2026/10/6大约 6 分钟

项目是什么，用来解决什么问题

这是一个用 C++ 从零搭建的 RPC 框架。RPC（远程过程调用）解决的是：业务功能部署在不同进程或机器上时，一个服务怎样调用另一个服务，并拿到处理结果。

以“业务服务查询商品信息”为例：商品数据由另一个服务提供，调用方不仅要把查询参数发过去，还要找到服务地址、约定数据格式、接收返回结果。如果商品服务有多个实例，还要决定这次请求交给谁；如果通信失败，也不能让调用方一直等下去。

只写一个 Socket 收发程序，只解决了“数据能传过去”。这个项目进一步把远程调用中反复出现的问题整理成可复用的框架：

服务在哪里，应该调用哪一个？ 用 ZooKeeper 做服务注册与发现，结合本地服务列表缓存，以及随机、轮询、权重等负载均衡策略选择实例。注册中心提供服务地址，不代替业务服务处理请求。
双方怎样读懂请求和结果？ 通过 JSON、Protobuf 完成序列化与反序列化，把参数和返回值转换成可传输的数据；网络模块负责发送、接收，再交给对应的处理逻辑。
并发、失败和传输成本怎样处理？ 把多线程与异步处理、重试和过载保护纳入调用链路，并接入压缩、加解密模块，练习吞吐、等待时间、资源占用之间的取舍。

你要做出的，不是一个只能展示“客户端发送、服务端打印”的通信 Demo，而是一个覆盖服务发现、请求传输和结果返回，并能继续扩展的 C++ 框架作品。项目的学习重点，是把一次远程调用背后的机制亲手串起来，并说明每个模块为什么存在。

技术栈不只是简历上的关键词；在这个项目里，每一项都对应调用链路上的实际问题。

技术与机制	在项目中承担的职责
C++、模块化接口设计	组织客户端、服务端与公共模块，让网络、编解码、服务发现等能力各自负责明确的工作。
网络编程、多线程与异步处理	完成请求和结果的网络收发，组织并发任务与异步处理流程。
JSON、Protobuf	编码请求参数与返回值，在通信两端还原数据；比较不同序列化方式的使用成本。
ZooKeeper、服务列表缓存	管理服务注册信息，发现可调用的实例，减少反复查询服务列表的开销。
随机、轮询、权重负载均衡	在多个服务实例之间分配请求，理解不同选择策略的适用场景。
Zlib、Zstd	压缩和解压传输数据，分析减少传输字节与增加 CPU 开销之间的取舍。
OpenSSL	接入数据加解密能力，理解安全处理在通信链路中的位置与接口边界。
重试、过载保护	处理部分失败和请求压力，讨论重试次数、重复执行风险及资源保护，而不是无限重试。

项目采用模块化组织方式：先打通基础调用，再逐步接入服务发现、负载均衡及压缩加密。这样既能看清完整链路，也能针对一个模块调试和验证，不必一开始就陷入所有功能交织的代码里。

完成实现并亲手验证之后，你应当能够获得以下几类能力，而不只是“了解过 RPC”。

搭建一个可演示的远程调用作品。 启动服务端和客户端，注册服务、发起调用、接收结果；增加服务实例，观察请求如何分配，把关键模块放到同一条链路上验证。
把网络、并发和分布式知识连起来。 讲清参数怎样编码、服务地址从哪里来、请求由谁处理、结果怎样返回，以及并发任务怎样协作。不再把序列化、负载均衡和服务发现当成互不相关的名词。
建立模块设计与排障思路。 区分“没发现服务”“数据编解码失败”“网络收发异常”和“服务处理失败”，沿调用链路逐段定位；说明为什么要拆模块，接口之间怎样衔接。
学会讨论工程取舍，而不是只说“高性能”。 设计对比实验，观察序列化、压缩和并发处理对耗时、数据大小与资源占用的影响；理解压缩并非总能加速，重试也不等于请求一定成功或只执行一次。
形成能深挖的项目经历。 围绕“我负责什么、为什么这样设计、遇到什么问题、怎样验证”整理自己的实现。面试时能够回答：为什么要服务发现？服务列表缓存如何更新？不同负载均衡策略有什么区别？失败后为什么不能盲目重试？

这个项目适合已经掌握 C++ 基础、愿意动手调试网络与多线程代码的同学。建议先完成一条最小调用链路，再分模块扩展；每增加一项能力，都用运行结果检验它，而不是只把依赖库加进工程。

最终收获，是一套自己能实现、能演示、也能讲清设计理由的 RPC 框架。 让简历中的“网络编程、并发编程、分布式系统”有一个具体作品作为支撑。