Pegasus rpc调研

2021-12-06

最近pegasus考虑做rpc替换,因此对业内上一些rpc进行调研。我认为rpc选型需要满足以下几点:

  1. 应用广泛。我们不希望选取了一个比较小众的rpc,过了一段时间之后,由于种种原因其不再维护,这样再切换的成本比较高。

  2. 性能高。Pegasus作为一款KV存储,在公司内部定位就是快,即低延时。

  3. 支持各种不同语言。Pegasus有各种语言的客户端,需要该rpc这些不同语言都有所支持。

鉴于第1点,我们将调研范围锁定在了thrift、grpc、brpc和dubbo之间。

Dubbo

dubbo目前主力支持golang和java,另外也支持Erlang。对cpp都不支持,显然不符合我们的需求。

Grpc

我在这里将grpc放入考虑范围主要是因为:

  1. grpc业内名气大、应用范围广

  2. 鉴于Google的技术口碑,很多公司对grpc的发展十分看好,这其中就包括TiDB。

但是grpc的性能实在太差了,基本是在各个测评中处于被吊打的位置,甚至在brpc的benchmark中,grpc几乎在所有test case中垫底。

并且在调研的过程中,我们就发现TiDB就有篇文章在考虑将grpc替换掉。另外Pegasus与TiDB不同,Pegasus对于延迟的敏感要明显强于TiDB,所以grpc过低的性能表现对我们来说是致命的。

另外grpc和thrift不兼容,如果引入grpc可能会带来兼容性问题。

因此建议忽略grpc。

Brpc

brpc有如下几个优点:

  1. 应用广。在百度内部就有数百万实例在使用,外部也有些产品在使用,比如字节跳动的bytegraph

  2. 性能高。详细可以看官方benchmark,总结来说,brpc相对于thrift和grpc,性能明显要高很多。

  3. 兼容性好。brpc本身不绑定协议,可以使用很多种不同的协议。这意味着我们可以继续沿用thrift进行序列化,不用担心与老版本的兼容性问题。

  4. 支持的语言足够多。当前支持Java、C++和Python。虽然对Pegasus来说缺少golang的支持,但是根据上一条,golang客户端可以继续沿用原有实现方式。

  5. 对长尾友好。brpc的底线认为RPC必须能够处理长尾,这一点对以性能为卖点的KV存储非常重要。

  6. 文档丰富,便于理解与调优,易用性高(关于易用性,brpc可以通过浏览器或者curl查看server内部状态,分析在线服务的cpu热点,内存分配等)。

  7. 百度开源了基于brpc的braft,如果后续Pegasus想要替换一致性协议,使用brpc可以更好的支持braft。

brpc存在的问题:

  1. 之前Doris使用的brpc,经常导致线上机器coredump,需要去深入了解下具体情况。

不过总体来看,brpc还是很值得推荐的。

Thrift

thrift有如下优点:

  1. 支持丰富的语言。支持高达28种语言,包括C++/Java/Python/golang等

  2. 目前我们的序列化使用的是thrift,如果rpc也使用thrift的话,与老集群的兼容性会比较好。

  3. 使用广泛,很多互联网公司都使用了thrift。

缺点:

  1. 性能不如brpc

  2. 官方文档缺失。这一点对于用户不太友好

因此相较于thrift,还是更推荐brpc。