c++从零实现rpc框架的核心是将本地函数调用转为网络调用：1. 用宏定义接口协议生成请求/响应结构体和方法名；2. 用flatbuffers或简易二进制序列化；3. 基于tcp长度前缀包+唯一id实现请求响应匹配；4. 用模板代理类封装调用，自动序列化、发收、反序列化。
用 C++ 从零实现一个简单的 RPC 框架，核心在于“把本地函数调用变成网络调用”——客户端像调用普通函数一样写代码，背后自动序列化、发请求、等响应、反序列化、返回结果。不依赖 gRPC/Thrift，纯手写，重点在理解原理，而非工程完备性。
1. 定义接口协议（IDL 简化版）
RPC 的前提是双方约定好“调什么、传什么、回什么”。不用写完整 IDL 编译器，可用结构体 + 函数签名宏模拟：
#define RPC_METHOD(name, req_type, resp_type) \
struct name##_req { req_type }; \
struct name##_resp { resp_type }; \
static constexpr const char* name##_method_name = #name;
例如：
RPC_METHOD(Add, int a; int b;, int result;); // 自动生成 Add_req（含 a/b）、Add_resp（含 result）、方法名字符串
这样既避免解析文本 IDL，又能统一生成请求/响应类型和元信息。
立即学习“C++免费学习笔记（深入）”；
2. 序列化：用 flatbuffers 或简易二进制编码
不推荐手写 JSON（性能差、无 schema）、也不必立刻上 Protocol Buffers。FlatBuffers 轻量、零拷贝、C++ 原生支持，适合教学级实现：
- 用 .fbs 文件定义消息（如
AddRequest,AddResponse） - 用
flatc生成 C++ 头文件 - 客户端打包：
auto buf = CreateAddRequest(builder, a, b); - 服务端解析：
auto req = GetAddRequest(buf.data());
若想更极简：自己写 4 字节长度 + 紧凑二进制（如 a(int32), b(int32) 直接 memcpy），但需手动处理大小端和对齐——仅用于学习，不用于生产。
3. 网络通信：基于 TCP 的请求-响应模型
用阻塞 socket 或 epoll 实现即可，关键点是“每个请求带唯一 ID”，避免响应错乱：
- 客户端发送：[len:4][id:4][method_name_len:2][method_name][payload]
- 服务端收到后，查表找到对应函数指针（如
std::map<:string std::function void>></:string>） - 执行函数，将结果序列化后，原样带上相同 id 回传
- 客户端用 id 匹配等待中的请求（可用
std::unordered_map<int std::promise>></int>）
注意：TCP 是字节流，必须自定义包边界（用长度前缀最稳妥）。
4. 服务端分发与客户端代理（核心胶水）
让调用看起来“像本地函数”，靠模板 + 宏生成代理类：
template <typename Req, typename Resp>
class RpcStub {
public:
template <typename... Args>
Resp call(const char* method, Args&&... args) {
Req req{std::forward<Args>(args)...};
auto payload = serialize(req);
auto resp_buf = send_recv(method, payload);
return deserialize<Resp>(resp_buf);
}
};
<p>// 使用时：
RpcStub<Add_req, Add_resp> stub;
auto resp = stub.call("Add", 3, 5); // 自动构造 req、发包、收包、解析
更进一步可结合 CRTP 或虚函数做统一 Service 接口，但简单场景模板足矣。
基本上就这些——协议定义、序列化、网络收发、代理封装。不复杂但容易忽略细节：ID 唯一性、包粘包处理、错误传播（比如网络超时要转成 exception）、线程安全（多个 client 共享 socket 需加锁）。先跑通一个 Add 函数，再逐步支持异步、服务发现、重试，就是完整的路了。
