8 步搞定 brpc C 高性能 RPC 框架从零编译到生产部署的完整指南【免费下载链接】brpcbrpc is an Industrial-grade RPC framework using C Language, which is often used in high performance system such as Search, Storage, Machine learning, Advertisement, Recommendation etc. brpc means better RPC.项目地址: https://gitcode.com/GitHub_Trending/brpc/brpcbrpcbetter RPC是百度开源的 C RPC 框架解决服务间通信、负载均衡与高并发处理问题广泛用于搜索、广告、存储等高性能系统。读完本文你能在 8 步内完成本地编译、跑通 echo 示例并掌握生产部署的关键配置。先认识 brpc它到底帮你做了什么一句话你把业务逻辑写进 Service剩下的连接管理、负载均衡、超时重试、监控诊断都交给 brpc。它适合这类场景一个端口同时提供 protobuf、HTTP/HTTPS、Thrift 等多种协议的服务访问 Redis、Memcached、MySQL 等且要求线程安全、比官方 client 更好用用 braft 风格的工业级 RAFT 搭建高可用集群通过内置 HTTP 页面随时查看服务的状态、变量、连接数甚至做 CPU/堆内存分析。下图展示了 brpc 一次 RPC 请求在客户端与服务端内部的完整流转路径不同颜色代表不同线程理解了这张图后面编译、调试时你心里就有底出了问题先判断卡在哪一段——通道选择、网络收发还是 Service 处理。最短上手路径6 条命令先看到跑起来了别急着研究所有选项先按下面这条最短命令链走一遍以 Ubuntu 为例10 分钟内就能看到 echo 客户端收到响应。先安装编译 brpc 所需的全部基础依赖sudo apt-get install -y git g make libssl-dev libgflags-dev \ libprotobuf-dev libprotoc-dev protobuf-compiler libleveldb-dev克隆源码并进入目录git clone https://gitcode.com/GitHub_Trending/brpc/brpc cd brpc用官方脚本 config_brpc.sh 生成 Makefile这里指向系统默认的头文件与库路径sh config_brpc.sh --headers/usr/include --libs/usr/lib并行编译框架本体产物是静态库libbrpc.a与共享库make -j$(nproc)编译并运行 echo 示例验证框架真的能收发消息cd example/echo_c make ./echo_server ./echo_client看到类似这样的输出说明你的 brpc 环境已经通了I0908 13:42:11.123456 12345 client.cpp:84] Received response from 127.0.0.1:xxxxx后面的内容都是在这条路径上做选择和加料选哪种编译方式、依赖版本怎么定、上生产前还要调什么。环境与依赖版本区间和常见坑一次讲清编译顺利的前提是依赖版本落在支持区间内。下表来自官方构建文档 docs/cn/getting_started.md组件支持版本作用GCC5.0–11.2推荐 8.2首选编译器默认启用 C14Clang3.5备选编译器glibc2.12–2.25系统 C 库protobuf3.0–5.29消息序列化不再兼容 2.xgflags2.1–2.2.2命令行参数解析leveldb任意稳定版rpcz 记录 RPC 调用链openssl0.97–1.1HTTPS 支持gperftools (tcmalloc)1.7–2.5可选内存分配器与 profilergtest任意稳定版可选运行单元测试几个高频坑提前避掉能省很多排查时间提示1.8.0 之后的 brpc 使用了 proto3 语法如果系统里装的是 protobuf 2.x链接阶段就会报一堆undefined reference。升级 protobuf 到 3.x 再编。注意CentOS 用户先sudo yum install epel-release否则大部分依赖包默认不可用。提示跑测试需要单独编译 gtestapt 装的libgtest-dev默认不编译若/usr/src/gtest不存在试试/usr/src/googletest/googletest。依赖就绪后就到了选择编译方式的分岔口。场景分流按你的使用方式选编译路径场景 A长期跑生产——脚本编译 静态链接生产环境的核心诉求是部署简单、没有运行时依赖。brpc 默认静态链接 gflags、protobuf、leveldb编译出的二进制拷到哪台机器都能直接跑这是官方推荐的生产姿势。配置时建议加上两个选项分别减小体积、接入 glog 日志sh config_brpc.sh --headers/usr/include --libs/usr/lib \ --nodebugsymbols --with-glog make -j$(nproc)如果你所在的组织有多个服务共享同一套 brpc也可以改用动态链接来节省磁盘make clean LINK_SO1 make场景 B边开发边调试——CMake 编译开发阶段更在意的是改代码后快速重编以及让 IDE 能正确补全跳转。CMake 路径更贴合这个诉求而且能顺手生成compile_commands.json给 VSCode/Emacs 的 LSP 用cmake -B build \ -DCMAKE_EXPORT_COMPILE_COMMANDSON \ -DWITH_DEBUG_SYMBOLSON cmake --build build -j6几个常用开关换 Clang设置环境变量CCclang CXXclang后重新 cmake换 glog-DWITH_GLOGON想要更小的产物删掉build/CMakeCache.txt后用-DWITH_DEBUG_SYMBOLSOFF重新 cmake。两条路径最终产出的库是一样的差异只在工具链与调试体验按需选其一即可。验证与自测怎么确认它真的正常跑通示例只是能动下面两步能帮你确认够健康。1. 用内置服务给服务端做个体检。brpc 的 Server 自带一套 HTTP 监控页面源码见 src/brpc/文档见 docs/cn/builtin_service.mdecho 服务默认监听 8000 端口直接在浏览器或终端访问即可curl http://127.0.0.1:8000/status curl http://127.0.0.1:8000/vars/status能看到 QPS、连接数、错误码分布/vars列出全部内部计数器。能返回数据说明服务的网络栈与统计体系都工作正常2. 跑一遍官方单元测试。仓库自带 test/ 目录与 run_tests.sh 脚本编译后一条命令执行全部用例cd test make sh run_tests.sh成功的标志测试输出无 FAILrun_tests.sh正常退出此前./echo_client能持续收到Received response from ...日志。两者都满足这套编译环境就可以放心用于开发。生产级调优线程、内存与监控服务上线后真正拉开差距的是这几个旋钮。1. 工作线程数。通过ServerOptions.num_threads设置默认等于 CPU 核数含超线程。注意它只是一个提示值进程内所有 Server 和 Channel 共享线程池实际 worker 数取所有配置中的最大值而非总和所以不用担心多 Server 场景下线程暴涨。2. 并发上限。ServerOptions.max_concurrency限制全局并发0 为不限还可以用method_max_concurrency对单个方法限流配合 自适应限流 能防止雪崩。3. 内存分配器。brpc 默认不链接 tcmalloc。tcmalloc 通常比 ptmalloc 更快但版本之间表现差异很大——某些版本会因内部自旋锁显著拖慢多线程性能。如果你启用了它却觉得性能不如预期先把它摘掉对比一下再考虑换版本。4. 实例级监控。规模化部署时可以启动 tools/trackme_server/ 提供的追踪服务各实例带-trackme_server127.0.0.1:8000参数启动后会自动上报心跳方便聚合发现所有 brpc 实例./tools/trackme_server/trackme_server ./your_service -trackme_server127.0.0.1:80005. 运行时剖析。不重启服务就能拿火焰图给启动命令加上 profiler 参数需链接libtcmalloc_and_profiler.a然后访问内置/cpu页面效果如下——哪个函数吃了 CPU 一目了然文档docs/cn/cpu_profiler.md调优之后别忘了回到验证与自测一节用内置服务确认指标符合预期。故障速查现象 → 原因 → 解法编译和运行 brpc 时最容易撞上下面几类问题按现象 → 可能原因 → 解法快速定位现象链接期报undefined reference to google::protobuf::xxx→ 可能原因系统装的是 protobuf 2.x或 gflags/leveldb 版本过旧头文件与库版本不一致。 → 解法升级到 protobuf 3.x 再重新编译仍不行时清理旧安装、统一版本后从头走一遍环境与依赖。现象程序启动即卡死栈停在 main 之前的 tcmalloc 代码里→ 可能原因tcmalloc 与 brpc 用了不同版本/版本的 GCC 编译全局初始化顺序不兼容。 → 解法用和编译 brpc 完全相同的编译器重新编译 gperftools若不需要 profiler直接摘掉 tcmalloc 链接与-DBRPC_ENABLE_CPU_PROFILER宏。 → 提示tcmalloc 不像 ptmalloc 那样及时归还内存出现在毫不相关的位置崩溃的怪异内存问题时也先怀疑它。现象MacOS 编译报找不到 OpenSSL→ 可能原因Monterey 之后 brew 安装路径从/usr/local/opt迁到了/opt/homebrew/Cellar。 → 解法先brew link openssl --force无效则改指路径重新配置sh config_brpc.sh --headers/opt/homebrew/include --libs/opt/homebrew/lib \ --ccclang --cxxclang现象安装 gtest 后/usr/src/gtest不存在→ 可能原因新版发行版把源码放到了别处。 → 解法尝试/usr/src/googletest/googletest在该目录下执行sudo cmake . sudo make。现象加了 tcmalloc 后吞吐反而下降→ 可能原因个别 tcmalloc 版本如 2.1 的自旋锁在多线程场景下性能劣化。 → 解法摘掉 tcmalloc 对比基线再换 1.7 / 2.5 等版本实测挑选。下一步把第一个 brpc 服务跑进你的项目现在你可以做三件事回到 example/ 挑一个离你业务最近的示例Redis、MySQL、Thrift、流式 RPC 都有现成代码照着改深入阅读 docs/cn/getting_started.md 的 macOS/Docker 章节或 docs/cn/server.md 学习异步 Service 写法需要扩展协议时从 docs/cn/new_protocol.md 开始。建议直接从example/echo_c复制一份作为你服务的骨架——编译通过的那一刻brpc 就已经在你的项目里开始工作了。【免费下载链接】brpcbrpc is an Industrial-grade RPC framework using C Language, which is often used in high performance system such as Search, Storage, Machine learning, Advertisement, Recommendation etc. brpc means better RPC.项目地址: https://gitcode.com/GitHub_Trending/brpc/brpc创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
8 步搞定 brpc C 高性能 RPC 框架从零编译到生产部署的完整指南【免费下载链接】brpcbrpc is an Industrial-grade RPC framework using C Language, which is often used in high performance system such as Search, Storage, Machine learning, Advertisement, Recommendation etc. brpc means better RPC.项目地址: https://gitcode.com/GitHub_Trending/brpc/brpcbrpcbetter RPC是百度开源的 C RPC 框架解决服务间通信、负载均衡与高并发处理问题广泛用于搜索、广告、存储等高性能系统。读完本文你能在 8 步内完成本地编译、跑通 echo 示例并掌握生产部署的关键配置。先认识 brpc它到底帮你做了什么一句话你把业务逻辑写进 Service剩下的连接管理、负载均衡、超时重试、监控诊断都交给 brpc。它适合这类场景一个端口同时提供 protobuf、HTTP/HTTPS、Thrift 等多种协议的服务访问 Redis、Memcached、MySQL 等且要求线程安全、比官方 client 更好用用 braft 风格的工业级 RAFT 搭建高可用集群通过内置 HTTP 页面随时查看服务的状态、变量、连接数甚至做 CPU/堆内存分析。下图展示了 brpc 一次 RPC 请求在客户端与服务端内部的完整流转路径不同颜色代表不同线程理解了这张图后面编译、调试时你心里就有底出了问题先判断卡在哪一段——通道选择、网络收发还是 Service 处理。最短上手路径6 条命令先看到跑起来了别急着研究所有选项先按下面这条最短命令链走一遍以 Ubuntu 为例10 分钟内就能看到 echo 客户端收到响应。先安装编译 brpc 所需的全部基础依赖sudo apt-get install -y git g make libssl-dev libgflags-dev \ libprotobuf-dev libprotoc-dev protobuf-compiler libleveldb-dev克隆源码并进入目录git clone https://gitcode.com/GitHub_Trending/brpc/brpc cd brpc用官方脚本 config_brpc.sh 生成 Makefile这里指向系统默认的头文件与库路径sh config_brpc.sh --headers/usr/include --libs/usr/lib并行编译框架本体产物是静态库libbrpc.a与共享库make -j$(nproc)编译并运行 echo 示例验证框架真的能收发消息cd example/echo_c make ./echo_server ./echo_client看到类似这样的输出说明你的 brpc 环境已经通了I0908 13:42:11.123456 12345 client.cpp:84] Received response from 127.0.0.1:xxxxx后面的内容都是在这条路径上做选择和加料选哪种编译方式、依赖版本怎么定、上生产前还要调什么。环境与依赖版本区间和常见坑一次讲清编译顺利的前提是依赖版本落在支持区间内。下表来自官方构建文档 docs/cn/getting_started.md组件支持版本作用GCC5.0–11.2推荐 8.2首选编译器默认启用 C14Clang3.5备选编译器glibc2.12–2.25系统 C 库protobuf3.0–5.29消息序列化不再兼容 2.xgflags2.1–2.2.2命令行参数解析leveldb任意稳定版rpcz 记录 RPC 调用链openssl0.97–1.1HTTPS 支持gperftools (tcmalloc)1.7–2.5可选内存分配器与 profilergtest任意稳定版可选运行单元测试几个高频坑提前避掉能省很多排查时间提示1.8.0 之后的 brpc 使用了 proto3 语法如果系统里装的是 protobuf 2.x链接阶段就会报一堆undefined reference。升级 protobuf 到 3.x 再编。注意CentOS 用户先sudo yum install epel-release否则大部分依赖包默认不可用。提示跑测试需要单独编译 gtestapt 装的libgtest-dev默认不编译若/usr/src/gtest不存在试试/usr/src/googletest/googletest。依赖就绪后就到了选择编译方式的分岔口。场景分流按你的使用方式选编译路径场景 A长期跑生产——脚本编译 静态链接生产环境的核心诉求是部署简单、没有运行时依赖。brpc 默认静态链接 gflags、protobuf、leveldb编译出的二进制拷到哪台机器都能直接跑这是官方推荐的生产姿势。配置时建议加上两个选项分别减小体积、接入 glog 日志sh config_brpc.sh --headers/usr/include --libs/usr/lib \ --nodebugsymbols --with-glog make -j$(nproc)如果你所在的组织有多个服务共享同一套 brpc也可以改用动态链接来节省磁盘make clean LINK_SO1 make场景 B边开发边调试——CMake 编译开发阶段更在意的是改代码后快速重编以及让 IDE 能正确补全跳转。CMake 路径更贴合这个诉求而且能顺手生成compile_commands.json给 VSCode/Emacs 的 LSP 用cmake -B build \ -DCMAKE_EXPORT_COMPILE_COMMANDSON \ -DWITH_DEBUG_SYMBOLSON cmake --build build -j6几个常用开关换 Clang设置环境变量CCclang CXXclang后重新 cmake换 glog-DWITH_GLOGON想要更小的产物删掉build/CMakeCache.txt后用-DWITH_DEBUG_SYMBOLSOFF重新 cmake。两条路径最终产出的库是一样的差异只在工具链与调试体验按需选其一即可。验证与自测怎么确认它真的正常跑通示例只是能动下面两步能帮你确认够健康。1. 用内置服务给服务端做个体检。brpc 的 Server 自带一套 HTTP 监控页面源码见 src/brpc/文档见 docs/cn/builtin_service.mdecho 服务默认监听 8000 端口直接在浏览器或终端访问即可curl http://127.0.0.1:8000/status curl http://127.0.0.1:8000/vars/status能看到 QPS、连接数、错误码分布/vars列出全部内部计数器。能返回数据说明服务的网络栈与统计体系都工作正常2. 跑一遍官方单元测试。仓库自带 test/ 目录与 run_tests.sh 脚本编译后一条命令执行全部用例cd test make sh run_tests.sh成功的标志测试输出无 FAILrun_tests.sh正常退出此前./echo_client能持续收到Received response from ...日志。两者都满足这套编译环境就可以放心用于开发。生产级调优线程、内存与监控服务上线后真正拉开差距的是这几个旋钮。1. 工作线程数。通过ServerOptions.num_threads设置默认等于 CPU 核数含超线程。注意它只是一个提示值进程内所有 Server 和 Channel 共享线程池实际 worker 数取所有配置中的最大值而非总和所以不用担心多 Server 场景下线程暴涨。2. 并发上限。ServerOptions.max_concurrency限制全局并发0 为不限还可以用method_max_concurrency对单个方法限流配合 自适应限流 能防止雪崩。3. 内存分配器。brpc 默认不链接 tcmalloc。tcmalloc 通常比 ptmalloc 更快但版本之间表现差异很大——某些版本会因内部自旋锁显著拖慢多线程性能。如果你启用了它却觉得性能不如预期先把它摘掉对比一下再考虑换版本。4. 实例级监控。规模化部署时可以启动 tools/trackme_server/ 提供的追踪服务各实例带-trackme_server127.0.0.1:8000参数启动后会自动上报心跳方便聚合发现所有 brpc 实例./tools/trackme_server/trackme_server ./your_service -trackme_server127.0.0.1:80005. 运行时剖析。不重启服务就能拿火焰图给启动命令加上 profiler 参数需链接libtcmalloc_and_profiler.a然后访问内置/cpu页面效果如下——哪个函数吃了 CPU 一目了然文档docs/cn/cpu_profiler.md调优之后别忘了回到验证与自测一节用内置服务确认指标符合预期。故障速查现象 → 原因 → 解法编译和运行 brpc 时最容易撞上下面几类问题按现象 → 可能原因 → 解法快速定位现象链接期报undefined reference to google::protobuf::xxx→ 可能原因系统装的是 protobuf 2.x或 gflags/leveldb 版本过旧头文件与库版本不一致。 → 解法升级到 protobuf 3.x 再重新编译仍不行时清理旧安装、统一版本后从头走一遍环境与依赖。现象程序启动即卡死栈停在 main 之前的 tcmalloc 代码里→ 可能原因tcmalloc 与 brpc 用了不同版本/版本的 GCC 编译全局初始化顺序不兼容。 → 解法用和编译 brpc 完全相同的编译器重新编译 gperftools若不需要 profiler直接摘掉 tcmalloc 链接与-DBRPC_ENABLE_CPU_PROFILER宏。 → 提示tcmalloc 不像 ptmalloc 那样及时归还内存出现在毫不相关的位置崩溃的怪异内存问题时也先怀疑它。现象MacOS 编译报找不到 OpenSSL→ 可能原因Monterey 之后 brew 安装路径从/usr/local/opt迁到了/opt/homebrew/Cellar。 → 解法先brew link openssl --force无效则改指路径重新配置sh config_brpc.sh --headers/opt/homebrew/include --libs/opt/homebrew/lib \ --ccclang --cxxclang现象安装 gtest 后/usr/src/gtest不存在→ 可能原因新版发行版把源码放到了别处。 → 解法尝试/usr/src/googletest/googletest在该目录下执行sudo cmake . sudo make。现象加了 tcmalloc 后吞吐反而下降→ 可能原因个别 tcmalloc 版本如 2.1 的自旋锁在多线程场景下性能劣化。 → 解法摘掉 tcmalloc 对比基线再换 1.7 / 2.5 等版本实测挑选。下一步把第一个 brpc 服务跑进你的项目现在你可以做三件事回到 example/ 挑一个离你业务最近的示例Redis、MySQL、Thrift、流式 RPC 都有现成代码照着改深入阅读 docs/cn/getting_started.md 的 macOS/Docker 章节或 docs/cn/server.md 学习异步 Service 写法需要扩展协议时从 docs/cn/new_protocol.md 开始。建议直接从example/echo_c复制一份作为你服务的骨架——编译通过的那一刻brpc 就已经在你的项目里开始工作了。【免费下载链接】brpcbrpc is an Industrial-grade RPC framework using C Language, which is often used in high performance system such as Search, Storage, Machine learning, Advertisement, Recommendation etc. brpc means better RPC.项目地址: https://gitcode.com/GitHub_Trending/brpc/brpc创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
