百度正式开始其PRC框架brpc，性能远超gRPC

未分类

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

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

GitHub地址：https://github.com/baidu/sofa-pbrpc

基础测试说明：https://github.com/brpc/brpc/blob/master/docs/cn/benchmark.md

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

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

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

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

戈君：因为我的经理刘炀曾是谷歌的工程师，经常和我回忆Google的内部项目Stubby是多么好用（Stubby是Google内部的RPC框架，gRPC就是源于Stubby）。这一半是开玩笑，一半也是我们在实践中意识到，RPC作为最基础的通信组件，当时的百度已经不领先了。

我们在内部会更加深入地讨论这些问题。“好用”有时看起来很主观，但其实还是有据可循的，就是能不能真正地提高用户的效率：开发、调试、维护都要考虑到，如果用户效率真的被提高了，用户其实会想着你的，靠吹嘘或政令推广的东西进不了人心。

我们创建brpc的初衷是要让百度的同学在离开百度后还会怀念brpc，就像谷歌员工会想起Stubby那样，我们希望在提供了一个好用框架的同时，也展现了一种工作方法：注释怎么写，日志怎么打，changelog怎么写，版本怎么发布，文档怎么组织，希望对未来不在百度的同学的工作也有帮助，所以从这点来说brpc从一开始就是拥抱开源的。事实上，我们在口碑上做得还不错，brpc的wiki是百度内被点赞最多的内容之一。

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

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

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

• 可靠性。这一方面是代码质量问题，这个问题我们认为是基础，就略过不说了，brpc团队的招聘门槛非常高，成员至少要达到在Google、Facebook等公司工程团队游刃有余的水平才行。另一个问题是长尾问题，这大都是设计问题，brpc其实包含了很多模块，其中的bthread是一个M:N线程库，就是为了更好地提高并发避免阻塞，具体分析在开放出来的文档里有，具体点击以下链接查看。
  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，brpc也内置一个Locality-aware负载均衡算法，监控和运维是NOAH。brpc区分了名字服务和负载均衡，前者指发现哪些server可访问，后者指如何从所有可访问server中选一台出来访问，都可以定制。

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

戈君：sofa-pbrpc是大搜团队中一些在腾讯Poppy团队（腾讯还搞搜索那会儿弄的）工作过的同学开发的RPC框架，属于sofa编程框架的一部分，在大搜有一些应用。前面提到的Kylin、UB框架，以及brpc都是基础架构部开发的，这个部门还开发百度内几乎所有主要的分布式系统。

我其实挺理解大搜团队自己做RPC框架的逻辑，他们应用规模足够大，基础架构部的一些事情又不是特别靠谱。sofa-pbrpc在2013到2014年时其实是想定位成全百度的标准RPC框架的，如果它足够好，我觉得真可以。我们当时的职业经历并不是做这种编程框架，对RPC也并没有特别的兴趣。但当时我们还是认真地考虑了这个事情，认真阅读了sofa-pbrpc的代码，得出了结论：它离我们想要的RPC还差的很远。所以我们决定自己来。

无需讳言，brpc在诞生之初和sofa-pbrpc在百度内部是有竞争关系的，但这个问题在2015年就不明显了，2016年几乎消失，用户都用脚投了票，包括大搜内部其实brpc的渗透率也不低了。类似的评判每个读者都可以自己去做，对比下brpc和sofa-pbrpc的文档质量，接口设计，易用程度，扩展能力等等。sofa-pbrpc这几年在内部文档，代码上都有借鉴brpc的痕迹，有些"借鉴"甚至没打招呼，直接出现在了开源代码里，我觉得是不太合适的。

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

并发模型是性能中最关键的问题，brpc在这点上走的比较深，读和写都是wait-free的，这是最高程度的并发。开源文档中概括了性能上的设计， "RPC in depth"这一节下的文档会谈的更细点。这里我不赘述，还请直接阅读文档：

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

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

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