今天开始对百度的这块开源项目进行学习，之前一直有听说，但是没有去尝试使用，下面就自己对brpc的学习心得进行一个总结。

1、brpc的简介

brpc又称为baidu-rpc，是百度开发一款“远过程调用”网络框架。目前该项目已在github上开源：https://github.com/brpc/brpc

从开源的github上看，确实是很有水准的一款rpc，不仅是文档内容及其丰富，其中也提到了，brpc被广泛用于百度公司内部的各种核心业务上，据github上的overview.md资料，包括：高性能计算和模型训练和各种索引和排序服务，且有超过100万以上个实例是基于brpc工作的。

所以说brpc还是很有探究的必要的，本人打算从以下几个方面开始探究brpc。
理论->编译安装->测试用例->心跳包实例->多连接实例->memcached实例

2、rpc的理解

说到对rpc的理解，其实之前有很多博客都有说明，顾名思义，rpc，远程调用访问。一种用来处理远程机器之前通信问题的一种解决方案，rpc的出发点是屏蔽掉网络协议层的繁琐协议，能给给用户暴露最直接的远程调用API。

要具体的理解rpc，首先得讲一下关于过程这个概念。
过程不用理解的很复杂，过程是一个概念词，你可以认为一个功能模块时一个过程，一个进程是一个过程，一个函数执行就是一个过程。那么远程的过程调用实际就是调用远程的函数，可以这么理解。

我们在操作系统课上学习过，函数之间的调用有这么几种情况

（1）同一个进程，同一个线程内部函数调用

这个是我们最常见的函数调用，一个线程内部函数嵌套的使用，那么函数是如何调用的呢，根据操作系统的基本知识，我们知道，编译器编译的过程中会将函数调用处给出函数执行的入口地址，通过该如何地址，在线程的地址空间中找到对应要调用执行的函数。本质上还是本地调用。

（2）不同进程之间的函数调用

不同进程之间的函数调用实际是不同进程之间的通信问题，也就是IPC。IPC通信有很多种方法，比较常见的是管道，共享内存，消息队列等这些。本质上这种函数调用仍然是本地调用，因为他们访问的还是同一个机器，在同一个内存访问空间上。

（3）不同机器上跨网络的函数调用

这种就是远程调用，传统的使用远程调用都是使用socket，用户自己编写socket，然后客户端和服务端遵循某种数据流协议，进行通信，完成调用函数的功能。

rpc从某种程度上来看，也是这样的，这种远程的调用，显然会增加大量的代码开发中的工作量，因为本来一个函数调用的功能，他们需要做网络协议，数据序列化的这些逻辑，开发的难度会不断提升。

所以基于这样的问题，rpc被提出来了，一种远程调用访问协议，让开发者不需要懂网络编程、不需要懂协议解析，就像写本地调用代码一样做开发就好了。

3.常见的rpc框架

目前有很多rpc框架的开源，如下所示：

google：grpc
facebook：thrift
baidu：brpc

这些不同框架基本出发点都是和上述描述的一致，让程序开发者能更高开发网络工程，而不去考虑复杂的网络协议，数据序列化这些逻辑。

4.brpc的特性

brpc也是一种rpc，它的底层网络协议是TCP协议，它的数据的序列化是使用googl开源的protobuf，一种轻量级，简便的序列化工具。
主要具有以下的特性：

基于protobuf接口的RPC框架，也提供json等其他数据格式的支持
囊括baidu内部所有RPC协议，支持多种第三方协议
模块化设计，层次清晰，很容易添加自定义协议
全面的服务发现、负载均衡、组合访问支持
可视化的内置服务和调试工具
性能上领跑目前其他所有RPC产品

已经支持的协议：

baidu_std（默认）
hulu-pbrpc协议
nova-pbrpc协议
public/pbrpc协议
sofa-pbrpc协议
UB协议
ubrpc协议
HTTP协议
HTTPS协议
凤巢ITP协议
memcache协议
redis协议
mongo协议
hadoop rpc协议

5.性能对比

在github开源的文档中，给出了brpc和其他目前开源的rpc的性能评估的结果图，从结果上看，brpc的性能还是非常优越的。
以下的这些性能对比的结果都来自于git上公布的结果。

（1）同机单client→单server在不同请求包大小下的QPS（越高越好）

上图是一个Client端向一个Server端发送的数据随着数据包大小变化而导致QPS变化的关系图。我们看到：

brpc随着请求包大小变大，QPS会下降得很明显。
thrift随着请求包大小变大，QPS下降不明显。
grpc随着请求包大小变大，在小于8KB的场景下变化不明显。但是8KB以上时，QPS明显下降。
在数据包大小<512B时，brpc的QPS接近grpc的5倍，接近thrift的3倍多。
在数据包大小<8KB时，brpc的QPS还是比grpc和thrift高。
在数据包大小>8KB时，brpc的QPS比thrift低，但是比grpc高。

（2）跨机多client→单server的QPS（越高越好）

上图是多个Client向一个Server发请求时，Client端数量和Server的QPS数量之间的关系图。我们可以看到：

随着Client数量增加，grpc和thrif的QPS没有明显增加。这意味着请求增多，grpc和thrift就需要更多的Server端来消化。
随着Client数量增多，brpc的QPS迅速增加。这意味着请求增多，brpc的Server端不需要像grpc或者thrift方案那样增加太多。

（3）同机单client→单server在不同线程数下的QPS（越高越好）

上图反映出Server开启的线程数和QPS之间的关系。随着服务器性能越来越好，CPU核心数也越来越多，我们可以开启更多的线程数来增加服务的处理能力，所以这个关系图很有意义。

grpc随着线程数增加，QPS变化不明显。这意味着给grpc开启更多的线程数对QPS没有明显贡献。
thrift在线程数<=8时，QPS比grpc和brpc都高。但是在达到8个线程之后，QPS基本没有变化，这就意味着thrift开启超过8个线程就对QPS没有明显贡献了。
brpc随着线程数增加，QPS变化明显。虽然在8个线程及以下时，QPS不如thrift，但是之后随着线程数增加，QPS增加也快速增加。这说明brpc对线程的利用率是非常高的。这也意味着让brpc的服务部署在更多核心的机器上时，QPS会有更大的收益。

brpc为什么会有此特性。这儿就需要介绍一下其使用的bthread库。据公开的资料介绍，其特点是：

用户可以延续同步的编程模式，能在数百纳秒内建立bthread，可以用多种原语同步。
bthread所有接口可在pthread中被调用并有合理的行为，使用bthread的代码可以在pthread中正常执行。

能充分利用多核。better cache locality, supporting NUMA is a plus.除了看QPS，我们还要看处理延时。如果一个服务虽然QPS很高，但是每个请求都延迟很久处理，就会导致服务的平均响应时间变大。

（4）跨机多client→单server在固定QPS下的延时CDF（越左越好，越直越好）

X轴是延时（微秒），Y轴是小于X轴延时的请求比例。这意味着变化曲线越靠近左边（延时短），越直（请求比例变化小）越好。

（5）总结

1.brpc的延时要优于thrift和grpc。
2.thrift同样优秀，但是grpc表现最差。

参考：
https://blog.csdn.net/breaksoftware/article/details/81564405
https://blog.csdn.net/okiwilldoit/article/details/82144578
https://github.com/brpc/brpc