百度正式开源其RPC框架brpc

嘉宾｜戈君

编辑｜Gary

百度开源的这款 RPC 框架 brpc，背后有什么门道？

写在前面

9 月 14 日，百度正式在 GitHub 上基于 Apache 2.0 协议开源了其 RPC 框架 brpc。brpc 是一个基于 protobuf 接口的 RPC 框架，在百度内部称为“baidu-rpc”，它囊括了百度内部所有 RPC 协议，并支持多种第三方协议，从目前的性能测试数据来看，brpc 的性能领跑于其他同类 RPC 产品。

brpc 开发于 2014 年，主要使用的语言是 C++ 和 Java，是百度内部使用最为广泛的 RPC 框架，它经受了高并发高负载的生产环境验证，并支撑了百度内部大约 75 万个同时在线的实例。据 InfoQ 了解，百度内部曾有多款 RPC 框架，甚至在 2014 年时还开源过另外一款 RPC 框架 sofa-pbrpc。那 brpc 是在什么样的背景下诞生的？它有什么样的优势？又为何要开源？就这些问题，InfoQ 记者采访了 brpc 负责人戈君。

GitHub 地址：https://github.com/brpc/brpc

InfoQ：谈谈 brpc 的一些基本情况？什么时候开始研发的？经过了怎么样的迭代和升级？目前在内部应用情况如何？

戈君：brpc 于 2014 年创建，在百度内部称为“baidu-rpc”。到目前为止，brpc 一共进行了 3000 次左右的改动，现在仍在持续优化中，百度内的 wiki 上可以查询到每次改动的描述。brpc 的主要语言是 C++ 和 Java，对其他语言的支持主要是通过包装 C++ 版本，比如 brpc 的 Python 版包含 C++ 版的大部分功能。

brpc 目前支撑百度内部大约 75 万个同时在线的实例（不含 client），超过 500 种服务（去年的统计，现在已不统计这类数据）。Hadoop、Table、Mola（另一种广泛使用的存储）、高性能计算、模型训练、大量的在线检索服务都使用了 brpc。brpc 第一次统一了百度内分布式系统和业务线的通信框架。

InfoQ：为什么百度当时要研发 brpc？

戈君：我们在实践中意识到，RPC 作为最基础的通信组件，当时的百度已经不领先了。我当时的经理刘炀曾是 Google 的工程师，非常重视基础架构的建设，也愿意在这个方向投入资源。

我们在内部会更加深入地讨论这些问题。“好用”有时看起来很主观，但其实还是有据可循的，它的关键点是能不能真正地提高用户的效率：开发、调试、维护都要考虑到，如果用户效率真的被提高了，用户会想着你的，靠吹嘘或政令推广的东西得不了人心。我们创建 brpc 的初衷是解决百度业务所面临的实际挑战，同时也希望成为百度同学最喜爱的工具，哪怕离开百度也会怀念 brpc。我们希望在提供了一个好用框架的同时，也展现了一种工作方法：注释怎么写，日志怎么打，ChangeLog 怎么写，版本怎么发布，文档怎么组织，甚至对未来不在百度的同学的工作也有帮助，所以从这点来说 brpc 从一开始就是拥抱开源的。事实上，我们在口碑上做得还不错，brpc 的 wiki 可能是百度内被点赞最多的内容之一。

InfoQ：与其他的一些开源的 RPC 框架相比，brpc 的优势是什么？

戈君：brpc 主打的是深度和易用性。一方面我们没有精力像 gRPC 那样摊大饼，什么都做。另一方面我们也注意到 gRPC（包括更早的 Thrift）的深度和易用性并不够。技术方面的东西就是这样，看示例程序，文档非常牛逼，但实战中可能就是另一回事了，为什么各个公司都要造自己的轮子，一个隐藏原因就是表面高大上的东西在一些细节上让你无法忍受。

RPC 真正的痛点是什么？是可靠性、易用性和定位问题的便利性。服务中不要出现不可解释的长尾，程序的可变项要尽量少，各种诡异问题要有工具支持快速排查。而这些在目前开源的 RPC 框架中做的并不好，它们大多看着很牛，但就是无法在自己组织中推广开来。回到前面那三点，brpc 是如何做的呢？

• 可靠性。这一方面是代码质量问题，通过为 brpc 团队设立很高的招聘门槛，以及在团队中深入的技术讨论，我们确保了稳固的代码基础。另一个问题是长尾问题，这是设计问题，brpc 其实包含了很多模块，其中的 bthread 是一个 M:N 线程库，就是为了更好地提高并发避免阻塞。brpc 中的读和写都是 wait-free 的，这是最高程度的并发。技术细节请点击以下链接查看。https://github.com/brpc/brpc/blob/master/docs/cn/bthread.md

  https://github.com/brpc/brpc/blob/master/docs/cn/io.md

• 易用性。有种设计是什么选择都做成选项丢给用户，号称功能都有，但一旦出问题，则是用户“配置错了”。而且这样用户还非常依赖开发团队，没有开发团队的支持基本用不了，开发团队有足够的理由扩充团队。这么做其实非常不负责任，用户面对海量的选项也很难受。brpc 对于增加选项非常谨慎，框架能自己做判断的绝不扔给用户，所有用户选项都有最合理的默认值，不设也能用。我们认为这对用户体验来说非常重要。

• 定位问题的便利性。这点其它开源框架目前做的都不好，正常使用是可以的，但出问题就麻烦了。这个问题在百度内部其实也很严重，brpc 之前用户排查问题都要拉 RPC 同学一起排查，RPC 框架对用户是个黑盒，用户根本不知道里面发生了什么。按我们的经验，基本每天都有几个用户在群里问 server 卡顿，client 超时之类的问题，排查问题是常态，人手必然不够。时间长了用户就觉得你这个框架各种问题，人还拽的不行很少回他们消息。brpc 的解决办法是给 server 内加入各种 HTTP 接口的内置服务，通过这些服务，用户可以很快看到 server 的延时、错误、连接、跟踪某个 RPC、CPU 热点、内存分配、锁竞争等信息，用户还可以使用 bvar 来自定义各类统计信息，并在百度的运维平台 NOAH 上汇总。这样大部分问题用户可以自助解决。其实我们去看也是看这些，只是会更加专业。内置服务的具体说明可以看这里：https://github.com/brpc/brpc/blob/master/docs/cn/builtin_service.md

InfoQ：作为公司内部的 RPC 框架，在服务治理方面有什么考虑？

戈君：百度内部 RPC 使用非常广泛，基本都是 RPC 调用，一些产品线还会通过 local RPC 隔离工程框架和策略代码。这么多年下来，服务周边的系统也比较全面了：编译是 BCLOUD，发布是 Agile，服务注册和发现是 BNS，认证是 Giano，监控和运维是 NOAH。在百度内部，brpc 和这些系统做了比较紧密的绑定，用户体验是一站式的。虽然在开源版本中，这些结合大都删掉了，但用户可以根据自己组织中的基础设施来进行定制：交互协议，名字服务，负载均衡算法都可以定制。对于其中一些特别通用的，我们希望用户反馈到开源版本中来以方便所有人。

InfoQ：之前百度还开源过 sofa-pbrpc，brpc 与它的区别是什么？

戈君：sofa-pbrpc 也是百度开发的一个比较早期的 RPC 框架，属于 sofa 编程框架的一部分，在搜索有应用。brpc 相比 sofa-pbrpc 有如下优点：

• 对协议的抽象更一般化，并统一了全百度的通信架构。bprc 能容纳非常多的协议，基于 Protobuf 的，基于 HTTP 的，百度内的 nshead/mcpack，开源的 Redis/Memcached，甚至 RTMP/FLV/HLS 直播协议，brpc 能逐渐地嵌入现有系统，而不需要彻底重构，但 sofa-pbrpc 则不具备扩展协议的能力。类似的，sofa-pbrpc 也无法定制负载均衡算法，brpc 默认提供 round-robin、随机、一致性哈希，Locality-aware（局部性感知）四种算法，用户还能定制。

• 多线程质量更好。多线程编程是非常困难的，看起来简单的 RPC 遍布多线程陷阱，比如处理超时的代码可能在 RPC 还没发出去时就运行了；发送函数还没结束，处理回复的回调就被运行了；一个回复还在被处理另一个回复回来了，诸如此类。另外，一个异步 RPC 的回调里发起一个同步 RPC 会发生什么，带着锁做同步 RPC 会发生什么。这些问题我们都不能在 sofa-pbrpc 中找到满意的答案。

• 完备的调试和运维支持。解决这个问题的本质还在可扩展性，你如何让用户参与进来定制他们感兴趣的指标，为此我们设计了 bvar，让用户能用比原子变量代价还小的方式自由地定制各种指标，用户能在浏览器上看到指标的变化曲线，或在运维平台 NOAH 看到汇总的监控数据。brpc 还加入了大量内置服务方便用户调试程序，查看连接，在线修改 gflags，追踪 RPC，分析 CPU 热点，内存分配，锁竞争等一应俱全。

无需讳言，brpc 在诞生之初和 sofa-pbrpc 在百度内部是有竞争关系的，但就像其他地方一样，这种竞争带来了活力。类似的，brpc 和其他已经开源的 RPC 框架也是良性的竞争关系，在比拼谁能真正提高用户效率的过程中共同进步。每个用户都可以去对比代码、文档质量，接口设计，易用程度，扩展能力等，投出自己的一票。

InfoQ：谈谈 brpc 的整体架构？

戈君：技术栈无外乎是从传输层垒到应用层，就略过不讲了，具体可以去看下开源出来的文档。brpc 在架构上强调“在不牺牲易用性的前提下增强可扩展性”，比如 brpc 支持非常多的协议，在百度内部一个 brpc server 同端口可以支持二十几种协议，这对于服务的平滑迁移就非常好用。

Client 端的协议也非常多，用户用 brpc 和 bthread 用得很爽，所以希望我们最好能统一所有的客户端，像对 Redis 和 Memcached 的客户端支持也是在这个背景下做的，这两个客户端比官方 Client 好用多了，感兴趣的读者可以去尝试一下。但这么多协议的配置非常简单，填个字符串就行了，比如 HTTP 就是把 ChannelOptions.protocol 设为“http”，Redis 就是“redis”。Server 端甚至不用设，它会自动判断每个 client 的协议，怎么做到的开源文档里也有，具体见这个链接：

https://github.com/brpc/brpc/blob/master/docs/cn/new_protocol.md

名字服务、负载均衡也都可以定制。但为了对用户负责，我们也不鼓励“太自由”的定制，比如一点点需求的变化就要搞个新的，这时更需要想清楚本质区别是什么。这个事情我们在百度内的支持群里每天都在做，我们是开放的"乙方"，但我们也是严厉的"乙方"。

InfoQ：brpc 的性能如何？这么高的性能是怎么做到的？

戈君：性能是我们非常看中的一点，它和用户体验也是紧密联系的。好用但性能不行，或不好用但性能很牛，用户会很难受，我们不希望用户纠结。从另一个角度来看，在推广初期，我们要说服产品线用 brpc 靠什么？最直观的就是性能提升。而且这儿的性能不能停留在 benchmark 的图片上，而是能在真实应用中体现出来。开放出来的案例文档中或多或少都包含了性能提升，具体如下：

百度地图 API 入口：

https://github.com/brpc/brpc/blob/master/docs/cn/case_apicontrol.md

联盟 DSP：

https://github.com/brpc/brpc/blob/master/docs/cn/case_baidu_dsp.md

ELF 学习框架：

https://github.com/brpc/brpc/blob/master/docs/cn/case_elf.md

云平台代理服务：

https://github.com/brpc/brpc/blob/master/docs/cn/case_ubrpc.md

和其他 RPC 框架（包含 thrift、gRPC）的性能对比可以见:

https://github.com/brpc/brpc/blob/master/docs/cn/benchmark.md

开源文档中概括了性能上的设计， "RPC in depth"这一节下的文档会谈的更细点。这里我不赘述，还请直接阅读文档：

https://github.com/brpc/brpc#better-latency-and-throughput

InfoQ：为什么要将 brpc 开源？接下来在开源项目的迭代方面有什么计划吗？

戈君：因为马上还有不少依赖 RPC 的百度系统要开源啊。RPC 作为最基础的组件，开源不仅仅是为了自身，也是为其它开源项目铺路，比如说我们马上还会开源基于 brpc 的 RAFT 库，搭建高可用分布式系统非常方便；以及使用 brpc 的 bigflow，让流式计算变得很顺手。这些年百度对开源的认识也在不断加深，开源看似曝光了百度的核心技术，但带来的生态影响力更重要。从 Apollo、PaddlePaddle 开始，百度真的开始拥抱开源了。brpc 的开源版和内部版很接近，只是去掉了对百度内部独有的一些基础设施的支持，我们在内网写的深入分析 RPC 技术细节的文档也都一并开源了，后续也会及时推送改动，请大家放心。这是一个活项目，不会拉个开源分支就不管了。

嘉宾介绍

戈君，百度主任架构师，brpc 主要作者，在系统编程，数据结构，设计和实现大规模分布式系统方面有广泛的实践。

强相关会议推荐

就像戈君所说，百度在 2017 年会认真拥抱开源，诸多核心技术开始对外分享，例如即将到来的 QCon 上海站里，百度安全事业部首席架构师武广柱将分享如何将机器学习应用于风控，详解图关联分析在数据挖掘和风控中的核心应用。

此次大会上还设置了软件性能和基础设施技术等话题共 100+ 场技术分享，更多详情欢迎点击“阅读原文”了解！

今日荐文

点击下方图片即可阅读

程序员该如何面对职场挫折？