Apache bRPC 1.18.0 介绍与选型指南

一、信息基准

1.1 查询基准

• 查询日期：2026-10-18。
• 版本依据：Apache bRPC 官方 GitHub 仓库 releases feed 显示最新正式版为 Apache bRPC 1.18.0（发布时间 2026-09-22），前一版本 1.17.0 发布于 2026-05-28、1.16.0 发布于 2026-01-25。bRPC 为 C++ 主体的框架，其发布物直接通过 GitHub 官方 releases 分发，官方 Apache 发行目录未设独立版本目录，版本判定以官方仓库 releases 记录为准。

1.2 官方来源清单

二、软件概述

2.1 项目定位

本文介绍的软件版本为 Apache bRPC 1.18.0（2026-09-22 发布）。Apache bRPC 是百度开源、现属 Apache 软件基金会顶级项目（TLP）的工业级 C++ RPC 框架。官方描述其设计目标为：仅需将内存数据结构的一份副本与少量代码交给框架，即可获得具备完整协议处理、负载均衡、服务发现等能力的服务。bRPC 在百度内部大规模生产使用，同时对外支撑了多个知名开源项目的基础通信（如 Apache Doris 内部节点间通信即采用 bRPC）。

2.2 发展沿革

bRPC 前身为百度内部广泛使用的工业级 RPC 库，2018 年以 brpc 名称开源，2019 年进入 Apache 孵化器，2022 年毕业为 Apache 顶级项目。项目沿 1.x 主线持续演进，从 1.12.1（2025-01）到 1.18.0（2026-09）保持约每四到五个月一个 minor 版本的稳定节奏。

2.3 许可与生态

• 开源许可：Apache License 2.0（源码仓库 LICENSE 文件实查确认）。
• 开发语言：C++ 为主体，另提供 brpc-java 等周边客户端实现。
• 代码托管：https://github.com/apache/brpc，GitHub 页面实查 stars 数约 17,632（2026-10-18）。
• 核心依赖：gflags（全局选项）、protobuf（消息序列化与服务接口）、leveldb（rpcz 调用追踪），另可选用 glog 与 thrift 协议支持。

三、核心架构与概念

3.1 Server、Service 与 Channel 编程模型

• Server：服务端载体，一个 Server 实例可监听单个端口并同时服务多种协议，通过内置协议分析器自动识别到达报文的协议类型（baidu_std、HTTP/1.1、HTTP/2、gRPC、Redis、Memcached 等），实现多协议端口复用。
• Service：基于 protobuf service 定义实现的服务单元，注册进 Server 后即获得协议无关的多协议接入能力。
• Channel：客户端统一入口，代表到一组服务器的逻辑连接；单次 RPC 通过 Controller 传递超时、重试、日志等上下文参数，支持同步、半同步、异步三种调用方式。
• ParallelChannel / ComboChannel：将多个子 Channel 按并行或组合拓扑编排，实现一次请求并行扇出到多个子服务的编程模式。

3.2 bthread 用户态线程库

bthread 是 bRPC 内建的 M:N 用户态线程库（与 Go 的 goroutine 同类）：用户线程被映射到少量内核线程上，栈空间轻量、切换开销低，配合 work stealing 调度让高并发回调不阻塞 worker。官方文档将其定位为「使用户能以同步写法获得异步性能」的核心机制：RPC 回调在 bthread 中执行，业务代码可像写同步程序一样串行书写，由框架在等待点自动让出。

3.3 负载均衡与命名服务

• 命名服务（NamingService）：将服务列表抽象为可枚举的 URL 形式（如 bns://、file://、list://、http://），客户端启动时拉取并动态更新服务器列表。
• 负载均衡（LoadBalancer）：内建轮询（rr）、随机（random）、最小并发（la）、一致性哈希（c_murmurhash、c_md5）等算法，按 URL 配置选择。
• 高可用组合：连接级自动重连、失败重试、备份请求（backup request，超时前向第二台副本发起并发请求取先回者）、异常服务器自动隔离与熔断，多策略叠加可从单机故障中快速恢复。

3.4 内置服务与可观测性

每个 bRPC 服务端默认内嵌一组 HTTP 管理端点：/status（服务状态）、/vars（自定义与框架指标）、/rpcz（单条 RPC 全链路追踪）、/connections（连接明细）、/hotspots（CPU 与锁热点剖析）、/memory（内存观测）等，配合 /flags 动态调整 gflags 参数，构成无需外接组件的轻量运维平面。

3.5 持久化选项与协议生态

bRPC 支持的通信协议覆盖面在同类框架中属于显著特点：除自有 baidu_std 协议（protobuf 序列化）外，原生支持 HTTP/1.1、HTTP/2（h2c/h2）、gRPC、Redis 协议、Memcached 协议、MongoDB 协议、RTMP 流媒体协议，并可经编译开关启用 Thrift 协议兼容，客户端与服务端均可按协议自动协商。

四、功能特性

• 多协议单端口复用：服务端一个端口同时兼容私有协议与 HTTP、gRPC、Redis 等公有协议，降低端口规划与网关改造成本。
• 高并发低延迟：bthread 协程调度加上连接多路复用（单连接并发多请求），官方基准文档提供与同类框架的对比数据，具体数值以官方 benchmark 页为准。
• 完整客户端治理：命名服务发现、多种负载均衡、超时重试、备份请求、熔断隔离、链路追踪开箱即用。
• HTTP 服务框架：可作为 HTTP 服务框架使用（流式传输、分块响应、压缩），方便构建管理界面与轻量 API。
• 流式 RPC：支持双向流式消息传输，适配推送与长交互场景。
• 富观测性：CPU 热点、内存、连接、指标、RPC 追踪全部内建，利于线上问题定位。
• 跨协议调试工具：自带 client 工具与协议打包工具（如 redis 工具、http 工具），便于不写代码验证服务。

五、快速上手

以下步骤引自官方入门文档 Getting Started（https://brpc.apache.org/docs/getting_started/），全部为官方文档示例，未做本地实测。官方支持环境为 Ubuntu/LinuxMint/WSL、Fedora/CentOS（自建依赖）、macOS 等。

5.1 安装构建依赖（Ubuntu 官方命令）

brpc 依赖 gflags、protobuf、leveldb 三个核心库，官方给出的 Ubuntu 依赖安装命令：

sudo apt-get install -y git g++ make libssl-dev libgflags-dev \
    libprotobuf-dev libprotoc-dev protobuf-compiler libleveldb-dev

如需运行单元测试，官方还要求安装并预编译 libgtest-dev。

5.2 以 CMake 构建框架与示例

官方 modern 构建方式：

git clone https://github.com/apache/brpc.git
cd brpc
cmake -B build && cmake --build build -j6

官方说明的常用开关：--cxx=clang++ 切换 clang 编译器、--with-glog 启用 glog 日志、--with-thrift 启用 Thrift 协议支持（需先安装 thrift）、--nodebugsymbols 去除调试符号以减小二进制。

5.3 运行官方回显示例

cd example/echo_c++
cmake -B build && cmake --build build -j4
./build/echo_server

示例默认静态链接依赖；官方说明如需动态链接共享库版本，删除 build/CMakeCache.txt 后加 -DLINK_SO=ON 重新构建。

5.4 客户端最小调用骨架

按官方文档（https://brpc.apache.org/docs/client/）给出的编程模式：

#include <brpc/channel.h>
int main() {
    brpc::Channel channel;
    brpc::ChannelOptions options;
    options.protocol = brpc::PROTOCOL_BAIDU_STD;
    options.connection_type = "";
    options.connect_timeout_ms = 1000;
    options.timeout_ms = 1000;  // 单次 RPC 总超时
    options.max_retry = 3;
    if (channel.Init("127.0.0.1:8000", &options) != 0) {
        return -1;
    }
    example::EchoService_Stub stub(&channel);
    brpc::Controller cntl;
    example::EchoRequest req, res;
    req.set_message("hello");
    stub.Echo(&cntl, &req, &res, nullptr);
    return cntl.Failed() ? -1 : 0;
}

六、适用场景与限制

6.1 适用场景

• C++ 高并发低延迟微服务与中间件通信：搜索、推荐、存储引擎、实时风控等延迟敏感系统。
• 需要在同一端口兼容多协议（私有 protobuf 协议 + HTTP 管理面 + gRPC 接入）的混合网关场景。
• 大数据/OLAP 系统节点间 RPC：Apache Doris 等开源系统已在生产采用 bRPC 作为节点通信层。
• 需要轻量内建可观测面（追踪、热点、指标）而暂不引入完整 APM 的团队。

6.2 已知限制

• 主力能力为 C++，其他语言需依赖协议互通（HTTP/gRPC）或社区维护的语言实现，Java/Go 一等公民程度不及 gRPC。
• 编译链接较重：依赖 gflags/protobuf/leveldb 的版本组合，官方建议静态链接自包含产物，跨项目集成需统一依赖版本。
• baidu_std 为框架私有协议，跨团队异构系统若不统一协议选型会引入兼容成本（官方支持 gRPC/HTTP 缓解）。
• 官方文档以中英文混合社区维护为主，相比 gRPC 的全球多语言生态，第三方资料与培训资源相对少。

七、同类选型对比

7.1 对比对象与数据来源

对比对象选取同为通用 RPC 框架的 Google gRPC、Apache Thrift、TarsCloud Tars。所有数据于 2026-10-18 联网实查：版本与发布时间取自各项目 GitHub releases feed，stars 取自各官方仓库页面，许可证取自各仓库 LICENSE 文件。

7.2 量化对比表

补充说明：Tars 主仓库最近一次 release 为 2023-11-06 的 v3.0.20，社区活跃度如实标注为低，选型时建议评估其维护风险。

7.3 选型建议

一句话建议：C++ 技术栈、追求单机极致性能与内建治理闭环、或正在构建 Doris 类分布式系统时选 Apache bRPC（当前 1.18.0）；多语言团队、云原生生态与标准化优先选 gRPC；跨 20+ 语言复用紧凑二进制序列化选 Apache Thrift；需要整套微服务管控平台且接受其低活跃风险时再考虑 Tars。

八、参考链接