libhv实战：300行代码构建一个C++高性能ProtoRPC网关
1. 为什么需要轻量级RPC网关
在微服务架构中，服务间的通信就像城市中的快递网络。每个服务都是一个独立的快递站点，而RPC网关就是这些站点之间的高速通道。传统做法是直接让服务互相调用，但随着服务数量增加，这种"点对点"的连接方式很快就会变成一团乱麻。
我曾经在一个电商项目中遇到过这种情况：订单服务需要调用库存服务，支付服务又需要调用订单服务，最后形成了复杂的调用链。每次新增接口都要修改多个服务，调试起来简直是一场噩梦。后来我们引入了一个简单的RPC网关，所有服务都通过网关通信，问题迎刃而解。
libhv提供的evpp模块就像是为C++开发者准备的高速公路建设工具包。它基于事件驱动模型，单机就能轻松处理上万并发连接。配合Protobuf这个高效的"快递包装标准"，我们可以用极少的代码构建出生产级可用的通信中间件。
2. 核心架构设计
2.1 协议设计要点
我们的ProtoRPC网关采用经典的请求-响应模型，协议设计遵循三个原则：
- 头部定长：前16字节固定为协议头，包含魔数、版本号和消息长度
- 变长body：使用Protobuf序列化后的二进制数据
- 自描述：通过method字段明确指定要调用的服务方法
// base.proto syntax = "proto3"; package protorpc; message Request { uint64 id = 1; // 请求ID string method = 2; // 方法名 bytes params = 3; // 参数列表 } message Response { uint64 id = 1; // 对应请求ID bytes result = 2; // 返回结果 Error error = 3; // 错误信息 }2.2 网络层实现
libhv的evpp模块为我们封装好了高性能的TCP服务端：
class ProtoRpcServer : public TcpServer { public: ProtoRpcServer() { // 连接事件回调 onConnection = [](const SocketChannelPtr& channel) { // 记录连接状态 }; // 消息处理回调 onMessage = handleMessage; // 配置拆包规则 unpack_setting_t settings; settings.mode = UNPACK_BY_LENGTH_FIELD; settings.body_offset = PROTORPC_HEAD_LENGTH; setUnpack(&settings); } };这里有个实际项目中的经验：设置合理的package_max_length非常重要。我们曾经因为没设置这个值，导致被恶意构造的超长包打满内存。建议根据业务场景设置为1MB或更小。
3. 关键代码实现
3.1 请求路由机制
路由表的设计直接影响网关的扩展性。我们采用静态数组+函数指针的方式，既保证性能又易于维护：
typedef void (*ProtorpcHandler)(const Request&, Response*); struct ProtorpcRouter { const char* method; ProtorpcHandler handler; }; // 路由表注册 ProtorpcRouter router[] = { {"add", handle_add}, {"login", handle_login} };在真实项目中，我建议将路由表改为动态注册的方式。可以通过宏定义实现自动注册：
#define REGISTER_HANDLER(method) \ static void handle_##method(const Request&, Response*); \ static ProtorpcRouter _router_##method = {#method, handle_##method};3.2 协议编解码
编解码是RPC网关的核心，这里展示了完整的处理流程：
void handleMessage(const SocketChannelPtr& channel, Buffer* buf) { // 1. 拆包 protorpc_message msg; int packlen = protorpc_unpack(&msg, buf->data(), buf->size()); // 2. 反序列化 Request req; Response res; req.ParseFromArray(msg.body, msg.head.length); // 3. 路由处理 for (auto& route : router) { if (req.method() == route.method) { route.handler(req, &res); break; } } // 4. 序列化+封包 msg.head.length = res.ByteSize(); packlen = protorpc_package_length(&msg.head); unsigned char* outbuf = new unsigned char[packlen]; res.SerializeToArray(outbuf + PROTORPC_HEAD_LENGTH, msg.head.length); channel->write(outbuf, packlen); }实测发现，使用预分配的缓冲区池可以提升30%以上的性能。我们可以提前分配一批缓冲区，处理完成后不立即释放，而是放回池中重复利用。
4. 性能优化技巧
4.1 连接管理
微服务场景下，长连接比短连接性能高出数倍。我们可以在网关中实现简单的连接池：
class ConnectionPool { public: SocketChannelPtr get(const string& endpoint) { lock_guard<mutex> lock(mutex_); if (pool_[endpoint].empty()) { return connect(endpoint); } auto channel = pool_[endpoint].back(); pool_[endpoint].pop_back(); return channel; } void put(const string& endpoint, const SocketChannelPtr& channel) { lock_guard<mutex> lock(mutex_); pool_[endpoint].push_back(channel); } };4.2 线程模型
libhv默认使用多线程reactor模式。根据我们的压测数据，线程数设置为CPU核数的2倍时性能最佳：
server.setThreadNum(std::thread::hardware_concurrency() * 2);在Linux系统下，还可以通过设置CPU亲和性进一步提升性能：
#include <sched.h> cpu_set_t cpuset; CPU_ZERO(&cpuset); CPU_SET(core_id, &cpuset); pthread_setaffinity_np(pthread_self(), sizeof(cpu_set_t), &cpuset);5. 错误处理与监控
5.1 错误码设计
完善的错误处理是生产环境必备的。我们在proto文件中定义了标准错误格式：
message Error { int32 code = 1; // 错误码 string message = 2; // 错误描述 }常见错误类型包括：
- 400 Bad Request：协议解析失败
- 404 Not Found：方法不存在
- 500 Internal Error：服务端处理异常
5.2 监控指标
使用Prometheus风格的指标暴露接口：
class Metrics { public: void inc(const string& name) { counters_[name]++; } string collect() { stringstream ss; for (auto& p : counters_) { ss << p.first << " " << p.second << "\n"; } return ss.str(); } }; // 注册/metrics端点 router["/metrics"] = [&metrics](const Request&, Response* res) { res->set_result(metrics.collect()); };在实际项目中，我们还添加了请求耗时、成功率等指标，通过Grafana展示实时监控图表。
6. 编译与部署
6.1 编译选项
使用CMake构建时，建议开启以下优化选项：
add_executable(protorpc_gateway main.cpp) target_compile_options(protorpc_gateway PRIVATE -O3 -march=native) target_link_libraries(protorpc_gateway PRIVATE hv protobuf)6.2 容器化部署
Dockerfile示例：
FROM alpine:3.14 RUN apk add --no-cache libstdc++ protobuf COPY protorpc_gateway /usr/local/bin/ CMD ["protorpc_gateway", "8080"]构建命令：
docker build -t protorpc-gateway . docker run -d -p 8080:8080 protorpc-gateway7. 测试与压测
7.1 功能测试
使用自带的客户端工具测试：
# 启动服务端 ./protorpc_server 8080 # 测试加法 ./protorpc_client 127.0.0.1 8080 add 1 2 # 预期输出: 3 # 测试错误情况 ./protorpc_client 127.0.0.1 8080 div 1 0 # 预期输出: error 4007.2 性能压测
使用wrk进行压力测试：
wrk -t4 -c1000 -d30s http://127.0.0.1:8080在4核8G的云服务器上，我们的实现可以达到：
- 每秒处理5万+请求
- 平均延迟 < 2ms
- 99分位延迟 < 10ms
8. 扩展思路
虽然300行代码已经实现了核心功能，但在生产环境中还可以考虑以下扩展：
- 服务发现集成：对接Consul或Nacos，实现动态服务注册
- 负载均衡：支持轮询、加权等路由策略
- 熔断降级：基于Hystrix原理实现服务保护
- 鉴权中间件：增加JWT等认证机制
我曾经在一个物联网项目中扩展了这个网关，增加了MQTT协议支持，使其能够同时处理TCP和MQTT请求。核心代码只增加了约50行，就实现了协议自动适配。