实战：基于 BRPC+Etcd 打造轻量级 RPC 服务——从注册到调用的核心架构与基础实现

引言

在微服务架构成为主流的今天，服务间高效、可靠的通信是系统稳定性的基石。传统 HTTP/REST 接口虽通用性强，但在高并发、低延迟场景下性能瓶颈明显；而 gRPC 虽性能优异，但对协议兼容性和开发复杂度要求较高。BRPC（Baidu RPC） 作为百度开源的高性能 RPC 框架，支持多协议（如 bRPC、HTTP、gRPC）、多语言（C++/Java/Python），并内置负载均衡、连接池等企业级特性；Etcd 则是云原生领域的分布式键值存储，凭借强一致性、高可用性和 Watch 机制，成为服务注册与发现的理想选择。本文将聚焦"从注册到调用"的完整流程，通过实战代码解析如何基于 BRPC+Etcd 构建轻量级 RPC 服务。

一、核心概念与技术选型背景

1. BRPC 的关键能力

多协议支持 ：默认使用自研的 bRPC 协议（基于 TCP 的二进制协议），性能接近裸 TCP，同时兼容 HTTP/gRPC；
高性能内核：采用 Reactor 模式 + IO 多路复用（epoll/kqueue），支持百万级 QPS；内置连接池、流式传输、熔断降级等机制；
灵活扩展：支持同步/异步调用、自定义拦截器（Interceptor）、多线程模型（ThreadPool）。

2. Etcd 的核心价值

强一致性：基于 Raft 共识算法，保证分布式环境下数据的一致性；
动态监听：通过 Watch 机制实时感知服务实例的上下线，无需轮询；
轻量级存储：键值对结构适合存储服务元数据（如 IP:Port、权重、标签）。

3. 应用场景

本方案适用于 内部微服务通信 （如电商订单服务调用库存服务）、边缘计算节点注册 （如 IoT 设备向云端注册）、混合云部署（跨机房服务发现）等需要低延迟、高可靠的服务治理场景。

二、从注册到调用的完整流程设计

整体流程分为四个阶段：

服务提供者启动：向 Etcd 注册自身服务信息（如服务名、IP:Port、元数据）；
服务消费者启动：从 Etcd 订阅目标服务的实例列表，并监听变更；
客户端调用：通过 BRPC 客户端负载均衡（如随机/轮询）选择实例发起请求；
服务端处理：BRPC 服务端接收请求，执行业务逻辑并返回响应。

三、详细代码实现与分析（核心部分）

1. 环境准备与依赖

语言：C++（BRPC 原生支持最佳）；
工具链：g++ 9+、CMake 3.10+、BRPC 源码编译（https://github.com/apache/incubator-brpc）、Etcd 3.5+（本地或 Docker 部署）。

2. 服务提供者：注册到 Etcd

服务提供者需要完成两件事：启动 BRPC 服务端监听端口，并将服务信息写入 Etcd。

复制代码

// provider.cpp
#include <brpc/server.h>
#include <butil/logging.h>
#include <etcd/Client.hpp> // 使用 etcd-cpp-apiv3 客户端库
#include "echo_service.pb.h" // 假设已定义 EchoService 的 protobuf

// 1. 定义业务逻辑：实现 EchoService 的接口
class EchoServiceImpl : public example::EchoService {
public:
    void Echo(google::protobuf::RpcController* controller,
              const example::EchoRequest* request,
              example::EchoResponse* response,
              google::protobuf::Closure* done) override {
        LOG(INFO) << "Received request: " << request->message();
        response->set_message("Echo: " + request->message());
        if (done) done->Run(); // 异步回调通知完成
    }
};

int main(int argc, char* argv[]) {
    // 2. 启动 BRPC 服务端
    brpc::Server server;
    EchoServiceImpl echo_service;
    if (server.AddService(&echo_service, brpc::SERVER_DOESNT_OWN_SERVICE) != 0) {
        LOG(ERROR) << "Failed to add service";
        return -1;
    }

    // 监听端口 8000（BRPC 默认协议）
    brpc::ServerOptions options;
    options.idle_timeout_sec = 10; // 连接空闲超时
    if (server.Start(8000, &options) != 0) {
        LOG(ERROR) << "Failed to start server on port 8000";
        return -1;
    }

    // 3. 注册服务到 Etcd
    etcd::Client etcd_client("http://127.0.0.1:2379"); // Etcd 地址
    std::string service_name = "echo_service";
    std::string instance_key = "/services/" + service_name + "/127.0.0.1:8000"; // 唯一键
    std::string instance_value = R"({"ip":"127.0.0.1","port":8000,"weight":100,"tags":["v1"]})"; // JSON 格式元数据

    // 写入 Etcd（TTL 可选，这里设置 30 秒自动过期，实际生产环境建议用租约续期）
    auto put_resp = etcd_client.Put(instance_key, instance_value);
    if (!put_resp.is_ok()) {
        LOG(ERROR) << "Failed to register to etcd: " << put_resp.error_message();
    } else {
        LOG(INFO) << "Service registered to etcd: " << instance_key;
    }

    // 4. 保持服务运行（实际需结合租约续期或信号处理）
    server.RunUntilAskedToQuit();
    return 0;
}

代码分析（重点）：

BRPC 服务端启动 ：通过 brpc::Server 类管理监听端口，AddService 将业务实现类（EchoServiceImpl）注册到框架，Start 方法绑定端口（如 8000）。关键参数 SERVER_DOESNT_OWN_SERVICE 表示服务实例由用户管理生命周期。
Etcd 注册逻辑 ：使用 etcd-cpp-apiv3 客户端库（需提前安装），向 Etcd 的 /services/echo_service/127.0.0.1:8000 键写入 JSON 格式的实例信息（包含 IP、端口、权重等元数据）。生产环境中建议使用 Etcd 租约（Lease） 机制（通过 etcd_client.GrantLease(30) 获取租约 ID，再通过 Put 的 WithLease 参数绑定），避免服务崩溃后注册信息未及时删除。
元数据设计 ：JSON 格式存储扩展字段（如 tags 用于灰度发布），实际可替换为 Protobuf 二进制格式提升序列化效率。

3. 服务消费者：从 Etcd 发现并调用服务

消费者需要先从 Etcd 获取服务实例列表，再通过 BRPC 客户端发起调用。

复制代码

// consumer.cpp
#include <brpc/channel.h>
#include <brpc/controller.h>
#include <butil/logging.h>
#include <etcd/Client.hpp>
#include "echo_service.pb.h"

int main(int argc, char* argv[]) {
    // 1. 从 Etcd 发现服务实例
    etcd::Client etcd_client("http://127.0.0.1:2379");
    std::string service_name = "echo_service";
    std::string prefix = "/services/" + service_name + "/"; // 服务前缀

    // 查询所有匹配前缀的键（即所有实例）
    auto get_resp = etcd_client.Get(prefix, etcd::GetOptions().WithPrefix());
    if (!get_resp.is_ok()) {
        LOG(ERROR) << "Failed to discover services: " << get_resp.error_message();
        return -1;
    }

    std::vector<std::string> instances;
    for (const auto& kv : get_resp.value().kvs()) {
        instances.push_back(kv.value()); // 获取实例的 JSON 信息（实际应解析 IP:Port）
    }
    if (instances.empty()) {
        LOG(ERROR) << "No available instances for service: " << service_name;
        return -1;
    }

    // 2. 初始化 BRPC Channel（客户端通信通道）
    brpc::Channel channel;
    brpc::ChannelOptions channel_options;
    channel_options.protocol = "brpc"; // 使用 bRPC 协议（高性能）
    channel_options.timeout_ms = 1000; // 超时时间
    if (channel.Init(instances[0].c_str(), "", &channel_options) != 0) { // 简化为首个实例（实际应负载均衡）
        LOG(ERROR) << "Failed to init channel to instance: " << instances[0];
        return -1;
    }

    // 3. 创建客户端存根（Stub）并调用远程方法
    example::EchoService_Stub stub(&channel);
    brpc::Controller cntl;
    example::EchoRequest request;
    example::EchoResponse response;

    request.set_message("Hello, BRPC+Etcd!"); // 设置请求参数
    stub.Echo(&cntl, &request, &response, nullptr); // 同步调用

    if (cntl.Failed()) {
        LOG(ERROR) << "RPC failed: " << cntl.ErrorText();
    } else {
        LOG(INFO) << "RPC succeeded, response: " << response.message(); // 输出响应
    }

    return 0;
}

代码分析（重点）：

服务发现逻辑 ：通过 Etcd 的 Get 方法查询指定前缀（如 /services/echo_service/）下的所有键值对，获取所有实例的元数据（示例中简化为直接使用第一个实例，实际应解析 IP:Port 并结合负载均衡策略）。
BRPC 客户端配置 ：brpc::Channel 是客户端的核心组件，负责管理与服务端的连接（包括连接池、重试、负载均衡）。关键参数 protocol 指定使用 bRPC 协议（与提供者一致），timeout_ms 设置超时时间（避免长时间阻塞）。
远程调用过程 ：通过生成的 Protobuf 存根类（EchoService_Stub）调用 Echo 方法，传入 Controller（控制请求状态）、Request（输入参数）、Response（输出结果）。同步调用通过 cntl.Failed() 判断是否成功，失败时可通过 cntl.ErrorText() 获取错误详情。

四、未来发展趋势

协议优化：BRPC 将进一步支持 HTTP/3（QUIC 协议）降低弱网延迟，Etcd v4 计划增强 Watch 性能（减少事件延迟）；
服务网格集成：与 Istio/Linkerd 结合，通过 Sidecar 模式实现更细粒度的流量管理（如金丝雀发布）；
Serverless 适配：针对 FaaS 场景优化注册中心的轻量化（如基于 DNS 的临时服务发现）；
多语言生态：BRPC 对 Java/Python 的支持将更完善，降低多语言微服务通信成本。