遍布百度技术架构的通信rpc框架开源了，叫板谷歌?

在百度中使用的最常见的RPC框架，拥有60万个实例和500多种服务，在百度之内称为“百度rpc”。

什么是RPC？

互联网上的大多数机器通过TCP/IP通信。然而，TCP/IP仅保证可靠的数据传输。我们需要抽象更多来构建服务：

• 数据传输的格式是什么？不同的机器和网络可能有不同的字节顺序，直接发送内存中的数据是不合适的。数据中的字段逐渐添加，修改或删除，新服务如何与较旧的服务进行交流？

• TCP连接可以重用于多个请求以减少开销吗？多个请求可以通过一个TCP连接同时发送吗？

• 如何与许多机器的集群对话？

• 当连接断开时应该怎么办？如果服务器没有响应怎么办？

• RPC通过将网络通信抽象为“客户端访问服务器功能”来解决上述问题：客户端向服务器发送请求，等待服务器接收到->进程->响应请求，然后根据结果执行操作。

让我们看看问题如何解决。

• RPC需要由protobuf完成序列化。用户以protobuf :: Message，RPC格式填写请求，并在protobuf :: Message中从响应中获取结果。protobuf具有良好的前向和后向兼容性，用户可以逐步更改字段和构建服务。对于http服务，json用于广泛的序列化。

• 连接的建立和重新使用对于用户来说是透明的，但是用户可以选择不同的连接类型：简单的，合并的，单一的。

• 机器由命名服务发现，可以由DNS，ZooKeeper等实现。在百度里面，使用BNS（百度命名服务）。brpc也提供了“list：//”和“file：//”。用户指定负载均衡算法为所有机器的每个请求选择一台机器，包括：循环，随机，一致的哈希（murmurhash3或md5）和本地化感知。

• 当连接断开时，RPC重试。当服务器在给定的时间内没有响应时，客户端会失败并出现超时错误。

我在哪里可以使用RPC？

几乎所有的网络通信。RPC无法做到一切，否则我们不需要TCP/IP层。但是在大多数网络通信中，RPC满足要求并隔离底层细节。

RPC常见疑问：

• 我的数据是二进制的，使用protobuf将会很慢。首先，这可能是一个错误的感觉，你将不得不测试它并用分析器证明它。第二，许多协议支持携带二进制数据以及protobuf请求并绕过序列化。

• 我正在发送无法由RPC处理的流数据。实际上，RPC中的许多协议可以处理流数据，包括http中的ProgressiveReader，h2中的流，流rpc和作为专用流协议的RTMP。

什么是brpc？

在百度中使用的RPC框架遍布百度，其中有600000多个实例（不包括客户端）和500多种服务，在百度中称为“百度rpc”。现在只有C++实施被开源了。

你可以使用：

• 构建可以在多个协议（在同一端口）上进行通话或者访问各种服务的服务器。

1. http/ https，h2 / h2c（兼容grpc）。在brpc中使用http比libcurl更友好。

2. redis和memcached，线程安全，比官方客户更友善和更好。

3. rtmp/flv/hls，用于构建实时流服务。

4. hadoop_rpc（尚未开放）

5. 通过openucx支持rdma（即将开放）

6. 百度使用的各种协议：baidu_std，streaming_rpc，hulu_pbrpc，sofa_pbrpc，nova_pbrpc，public_pbrpc，ubrpc和基于nshead的协议。

7. 使用HTTP+json访问基于protobuf的协议，可能来自另一种语言。

8. 使用RAFT协商一致的算法构建分布式服务（将在快速启动时启用）。

• 创建丰富的处理模式。

1. 服务可以同步或异步处理请求。

2. 同步或异步访问服务，甚至半同步访问。

3. 使用组合通道以声明方式简化复杂的客户端模式，包括分片和并行访问。

• 通过http调试服务，并运行cpu，堆和contention profilers.。

• 获得更好的延迟和吞吐量。

• 使用你企业中使用的协议快速扩展brpc，或自定义组件，包括命名服务（dns，zk，etcd），负载均衡（rr，random，一致散列）

brpc的优点：

更友善的API

只有3个（主要）用户头：服务器，通道，控制器，分别对应于服务器端，客户端和参数集。你不必担心“如何初始化XXXManager”，“如何将所有这些组件层叠在一起”，“XXXController和XXXContext之间的关系是什么”。所有你需要做的很简单：

• 建立服务？包括brpc / server.h并遵循评论或示例。

• 访问服务？包括brpc / channel.h并遵循评论或示例。

• 调整参数？结帐brpc / controller.h。请注意，该类由服务器和通道共享。方法分为客户端，服务器端和双方三部分。

我们试图简单地做简单的事情。以命名服务为例。在较旧的RPC实现中，你可能需要复制一堆模糊的代码才能使其工作，但是在brpc访问中，BNS表示为Init（“bns：// node-name”...，DNS is“http：//域名“和本地机器列表是”file：///home/work/server.list“。没有任何解释，你知道这是什么意思。

使服务更可靠

brpc广泛应用于百度，从：

• map-reduce服务和表存储

• 高性能计算和模型培训

• 各种索引和排名服务器

已经证明了。brpc特别注意开发和维护效率，你可以查看Web浏览器中的服务器内部状态或卷，你可以在线分析cpu使用情况，堆分配和锁定服务争用，可以通过bvar测量统计信息，in /vars.

更好的延迟和吞吐量

虽然几乎所有的RPC实现都声称它们是“高性能”的，但数字可能只是数字。在不同场景中真正的高绩效是困难的。为了统一百度之内的通信，brpc在性能上比其他实现更深入。

• 读取和解析来自不同客户端的请求完全并行化，用户不需要区分“IO线程”和“处理线程”。其他实现可能具有“IO线程”和“处理线程”以及散列文件描述符（fd）到IO线程中。当IO线程处理其中一个fds时，线程中的其他fds将无法处理。如果一个消息很大，其他fds会显着延迟。虽然不同的IO线程并行运行，但是你不会有许多IO线程，因为除了从fds读取/解析之外，它们不需要太多的操作。如果有10个IO线程，则fd可能会影响所有fds的10％，这对于工业在线服务是不可接受的（需要99.99％的可用性）。当fds不均匀地分布在IO线程（不幸的是常见的），或者服务是多租户（在云服务中常见）时，问题会更糟。在brpc中，从不同的fds读取并行化，甚至处理来自一个fd的不同消息也被并行化。解析大的消息不会阻止来自同一个fd的其他消息，更不用说其他fds。

• 写入一个fd和多个fds是高并发的。当多个线程写入相同的fd（通用于多路复用连接）时，第一个线程直接写入就绪，其他线程以等待方式提交写请求。一对fd可以通过几个高度对抗的线程每秒写入5000000个16字节的消息。

• 最小的锁。高QPS服务可以利用机器上的所有CPU电源。例如，创建用于处理请求的bthread，设置超时，根据响应查找RPC上下文，记录性能计数器都是高并发的。即使服务运行在五十万以上QPS，用户也看到RPC框架引起的contentions（通过contention profiler）。

• 服务器根据负载调整线程号。传统实现根据延迟设置线程数以避免限制吞吐量。brpc为每个请求创建一个新的bthread，并在请求完成时结束bthread，根据加载自动调整线程号。

百度brpc开源库：https://github.com/brpc/brpc

检查基准测试以比较brpc和其他实现：https://github.com/brpc/brpc/blob/master/docs/cn/benchmark.md