资讯详情

资讯详情

brpc 高性能 RPC 编译与部署完全指南:5 分钟跑通,再上生产的 8 个关键动作

brpc 高性能 RPC 编译与部署完全指南:5 分钟跑通,再上生产的 8 个关键动作【免费下载链接】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/brpcbrpc 是百度的工业级 C 高性能 RPC 框架:一个端口同时服务 HTTP、baidu_std、thrift 等多种协议,默认把依赖全静态链接进二进制,运维不用再追着一台台机器装依赖。这篇文章按5 分钟跑通 demo → 日常开发选路线 → 生产加固三段场景来写,编译命令、依赖版本、死锁排查全都落在具体操作上,帮你省掉翻源码和反复试错的时间。 5 分钟跑通 echo demo:先证明框架能用在你把 brpc 塞进任何业务之前,先花 5 分钟把官方 echo 示例跑起来——服务端收包、原样返回,客户端打印结果。这一步的价值不在于功能本身,而在于它把依赖装没装齐、编译器版本对不对、头文件路径通不通这些环境问题一次性暴露出来。后面再遇到诡异报错,你可以先怀疑代码,而不是怀疑环境。3 条命令装齐 Ubuntu 依赖brpc 的硬依赖就三个:gflags(命令行参数)、protobuf(序列化)、leveldb(rpcz 追踪用)。另外加 openssl,不然 https 相关功能编译不过。sudo apt-get install -y git g make libssl-dev libgflags-dev \ libprotobuf-dev libprotoc-dev protobuf-compiler libleveldb-dev # 静态链接 leveldb 需要 snappy;要跑 profiler 再加 gperftools sudo apt-get install -y libsnappy-dev libgoogle-perftools-devCentOS/Fedora 系要先sudo yum install epel-release,否则一堆包默认装不上,然后把上面的包名换成openssl-devel gflags-devel protobuf-devel protobuf-compiler leveldb-devel。拉源码,用 config_brpc.sh 生成构建配置这一步是生产路线的核心:config_brpc.sh 会替你定位依赖的头文件和库文件,生成好编译配置,你只管 make。--headers和--libs可以传多个路径,脚本会递归搜索,依赖散落在不同目录时也不用挨个挪。git clone https://gitcode.com/GitHub_Trending/brpc/brpc cd brpc sh config_brpc.sh --headers/usr/include --libs/usr/lib make -j$(nproc)编译器想换 Clang 就追加--cxxclang --ccclang;产物想瘦身加--nodebugsymbols;要用 glog 打日志就加--with-glog。GCC 建议 8.2 以上,protobuf 官方文档写明支持 3.0-5.29,1.8.0 起不再兼容 2.x,老系统上装的是 2.x 的话这就是你编译挂掉的第一个嫌疑。起服务发请求,再瞄一眼内置监控面示例在 example/echo_c,make 会直接把 brpc 静态库链进可执行文件,零运行时依赖——这正是 brpc 的部署哲学。cd example/echo_c make ./echo_server ./echo_client客户端打印出回显内容,说明链路通了。再顺手 curl 一下服务端口,brpc 自带一套 HTTP 内置服务(status、vars、connections、rpcz、各 profiler),开发阶段排查问题全靠它,细节在 docs/cn/builtin_service.md。 日常开发:两条编译路线怎么选框架跑通了,接下来是每天要面对的问题:同一套源码,交付走哪条线、调试走哪条线。brpc 给了两条,不是二选一,而是各管各的场景,别混着切。维度生产路线(config_brpc.sh make)开发路线(CMake)入口命令sh config_brpc.sh --headers... --libs... makecmake -B build cmake --build build -j6换 Clang--cxxclang --ccclang环境变量CCclang CXXclang去调试符号--nodebugsymbols删build/CMakeCache.txt后加-DWITH_DEBUG_SYMBOLSOFF开 glog--with-glog-DWITH_GLOGON开 thrift--with-thrift-DWITH_THRIFTON适合场景产物要上线、容器镜像、团队统一构建自己写代码、要 LSP 补全、跑单测开发路线有两个选项值得专门记一下。-DCMAKE_EXPORT_COMPILE_COMMANDSON会生成compile_commands.json,VSCode 的 clangd 有了它才知道你的编译参数,补全和跳转才算真能用;-DBUILD_UNIT_TESTSON则会在构建目标里带上 test/ 目录下的单测,make test直接跑,比生产路线的cd test make sh run_tests.sh省一步手动配置。两条路线的产物验证标准完全一样:编译 echo 示例,起服务,发请求,看回显。区别只在产物形态——生产路线默认静态链接 brpc,想换共享库就make clean后LINK_SO1 make;CMake 路线则删缓存加-DLINK_SOON重来。 编译失败和运行异常:先查这三个高频坑症状:程序在main()之前就卡死,线程栈全停在 tcmalloc 内部,重启无效,现象像死锁;根因:链接的 tcmalloc 是用另一个版本的 GCC 编译的,和当前 brpc 的工具链 ABI 不匹配;一行修复:用编译 brpc 的同一个 GCC 重编一遍 tcmalloc 再链接。 另外提醒一句:tcmalloc 不会像 ptmalloc 那样及时把内存还给系统,遇到在无关地方崩的怪内存问题时,先摘掉 tcmalloc 再判断是不是真 bug。tcmalloc 这事 brpc 文档里反复强调:框架默认不链 tcmalloc,是用户主动加的。2.1 和 1.7/2.5 的多线程性能表现甚至完全不同,版本选错等于白优化。第二个高频坑是 protobuf 符号缺失,典型报错是undefined reference to google::protobuf::...。根因基本就两种:要么系统里 protobuf 太老(2.x 直接不兼容,见上文版本要求),要么头文件找着一套版本、链接器链着另一套版本。修法不是装个新 protobuf就完事,config_brpc.sh的--headers/--libs里如果同时给了新旧两套路径,它可能各取所需拼出一个 Frankenstein。先find / -name libprotobuf*把机器上的 protobuf 找干净,再收敛到单一目录。第三个坑是 gtest 找不到:Ubuntu 的libgtest-dev只给源码不给库,装完还得进/usr/src/gtest自己 cmake make 一遍,产物挪进/usr/lib才算数;新版系统源码在/usr/src/googletest/googletest。跳过这一步,run_tests.sh会全军覆没。 生产加固:静态链接、内置监控与实例追踪到这一步,代码和编译都没问题了,剩下的是让服务上线后看得见、管得住。brpc 的设计思路是:监控能力随服务一起交付,不需要你外接一套 agent。链接方式优势适用场景切换命令静态链接(默认)产物零依赖,机器上不用装任何东西生产环境、容器镜像无需操作动态链接多个服务共享一份 so,省磁盘开发机、同机房多服务脚本路线LINK_SO1 make;CMake 路线-DLINK_SOON上线前有三件事值得做。把内置服务盯上。服务起来后,/status看全局、/vars看自定义计数器、/rpcz回放具体 RPC 的入参出参;开 profiler 的话 CPU 热点直接在浏览器里出图(基于 tcmalloc 的 cpu/heap profiler 需要链libtcmalloc_and_profiler.a)。对外服务必须隐藏内置服务。这些 HTTP 端点能改 gflags、能看连接表,直接裸奔到公网是事故。官方把安全模式单独写在 docs/cn/server.md 里,经过 nginx 转发流量的场景同样要处理,别以为只挡了业务端口就安全了。多实例环境挂个 trackme_server。在某台机器上跑起 tools/trackme_server,业务进程带-trackme_serverIP:PORT启动,它周期性收各实例的 ping 并打日志,你从日志聚合出实例地址后就能批量调它们的内置服务——实例飘移、重启过没、端口活没活,一套日志就能对账。继续往下挖这套静态链接 内置监控的组合跑顺之后,真正拉开差距的是这些方向,按落地收益排序推荐两条路径:把指标接进告警:bvar 是 brpc 的原子计数器体系,/vars里看到的指标都来自它,自己写业务计数器也是同一套 API,从 docs/cn/bvar.md 入手,配合 docs/cn/builtin_service.md 把 QPS、延迟、连接数变成可告警的序列。用自带工具做流量验证:上线前的压测和流量回放不需要第三方工具,docs/cn/rpc_press.md 的压测工具和 docs/cn/rpc_replay.md 的回放工具能直接对着你的服务跑,比 curl 循环靠谱得多。环境细节以官方 docs/cn/getting_started.md 为准,各版本依赖的兼容区间(protobuf、tcmalloc、libunwind 等)都列在那里,升级前查一遍能省很多排查时间。【免费下载链接】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),仅供参考
觉得有用,分享给同行:

为您的企业打造数字门面

稳重轻奢商务风格,端正雅致视觉,长效耐看不易过时。

立即咨询 →