这是一个创建于 2332 天前的主题，其中的信息可能已经有所发展或是发生改变。
以前一直用 grpc，最近重新看了一下百度的 brpc，对比了一下优缺点。
brpc 优点，支持 status,lb,bvar,sessionlocal，threadlocal,logging,redis,http 等。 感觉这些是一个工程应用必须有的，比如状态监控，负载均衡，日志，常用的传输协议支持。
brpc 缺点，上手难度大，文档写的二流，很多功能要边猜边验证，支持的语言就要是 c++。
grpc 优点，支持的语言非常全，文档写的非常完善。
grpc 缺点，各种传输协议不支持（ http/2，reids ）之类的，日志要自己造，没有状态监控的 status。
 |
1
xkeyideal 2019 年 9 月 4 日  1
说缺点之前，请先查点资料或者有实践经验再说，grpc 不支持 http2 ？我只能说你菜的抠脚。
还有，任何东西都有缺点，没有银弹，任何代码都不想写，框架啥的都帮你搞定，可能么？ |
 |
2
jetyang 2019 年 9 月 4 日 1
grpc 有 nginx 插件，负载均衡不是问题，ssl 证书也可以放在 nginx 下，很爽的。status code 确实没有，只能靠分析异常日志判断错误原因。其它的（ logging、redis、http、threadlocal。。。）看不懂
|
 |
3
janxin 2019 年 9 月 4 日
brpc 和 gRPC 不是不冲突吗？ B 站不是用 brpc 的生态+gRPC 吗...
|
 |
4
hellodudu86 2019 年 9 月 4 日
楼主你也说了，grpc 支持的语言非常全，对一个 rpc 库来说这难道不是最实在的吗？
|
 |
5
momocraft 2019 年 9 月 4 日
不是都叫 RPC 就可比较
|
 |
6
StarkWhite 2019 年 9 月 4 日
看到标题第一反应是 brpc 是你写的，然后来这里发帖推广，看来我也患了 apijson ptsd 了 /笑哭
|
|
7
StarkWhite 2019 年 9 月 4 日
Facebook 也出了个 RPC 框架，叫 Thrift，可以一起对比啊
|
 |
8
qq316107934 2019 年 9 月 4 日 1
把我看懵了，gprc 不是可以 over http/2 么： https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2.md
状态监控，日志在不同语言下都有不同的包去做实现，grpc 这样其实框架侵入少，是好事。至于 redis 和 http，貌似和这个没啥关系呀... 如果你想用 http 不是应该用 protobuf 么 |
 |
9
luozic 2019 年 9 月 4 日 via iPhone
传输协议和服务治理是不同范围的东西。
|
 |
10
tempdban 2019 年 9 月 4 日 via Android
前员工答题，brpc 是可以直接走 http 输出 json 或 html 的
|
|
11
tempdban 2019 年 9 月 4 日 via Android
尤其那个 bvar 用灵活了甚至可以直接显示心跳图。
|
 |
14
iPhoneXI 2019 年 9 月 4 日 via Android
@StarkWhite 老牌 RPC 框架了
|
 |
16
mv0x OP @qq316107934 如果仅仅是 rpc，这一块两者差不多，如果要加上服务治理，brpc 确实好用。在 c++里面，如果自己去集成 http(libcurl),redis，mongdb 之类的，其实不是不能实现，但是人家集成了，用起来确实方便很多，没必要自己去找依赖，造轮子。
|
|
17
qq316107934 2019 年 9 月 4 日
@mv0x #16 哦哦，没注意到限定使用场景是 C++，我接触的还是 golang/python 偏多，仅供参考。
|
 |
18
baixiangcpp 2019 年 9 月 4 日
brpc 文档二流吗？明明真香
|
 |
19
swulling 2019 年 9 月 4 日
brpc 的问题是生态没起来，语言太限定了。厂内用的也是越来越少
|
|
20
swulling 2019 年 9 月 4 日
毕竟 c++写的项目书越来越少
|
 |
21
leon0318 2019 年 9 月 5 日 via Android
确实 brpc 是真的优秀，百度的技术在国内还是牛逼
|
 |
22
tomwei7 2019 年 9 月 5 日 1
目前正在使用 brpc，brpc 在一些地方确实给人了一些小惊喜，比如内置的调试页面等等一些小工具确实都不错，方便了开发。但是作为一个 rpc 框架最重要的应该是能够和已有的系统结合以及良好的扩展性，brpc 在这个方面做的就很差，比如缺少多语言支持，没有 Middleware 之类的功能，内置的 bvar 监控没办法和 Prometheus 结合（ bvar 支持导出 Prometheus 格式的数据但是没有 label 支持，基本不可用），rpc 框架应该是个架子，而不是一个已经装满的架子
|
Select Language