gRPC遭抛弃!Storj为何使用DRPC替代gRPC?

21-05-27 banq

在2016年,Google推出了gRPC,从而全面席卷了系统编程社区。gRPC代表带有G(远程过程调用)的东西;这是一种用于轻松定义两个不同的远程服务之间的接口的机制。似乎每个人都在使用它。Wikipedia,Square,Netflix,IBM,Docker,Cockroach Labs,Cisco,Spotify,Dropbox等都使用gRPC。

在Storj,我们是分散式云存储的先驱。到2018年初,我们建立并扩展了150 PB的分散式存储网络。当然,就像每个良好的伸缩性故事一样,到我们达到150 PB时,我们发现了一些需要重新处理的基本体系结构问题。我们在2018年3月做出了冒险的决定,以彻底重新实现Go来解决这些体系结构问题。

在Go中从头开始构建新的分散式存储平台,我们考虑使用gRPC简化对等远程过程调用中的开发过程,我们感到失望的是,谷歌没有发布带有proto2的标准RPC实现。有了以前对协议缓冲区的强烈丰富的经验,我们很兴奋地跳入了开发新的protobuf RPC领域。

快进到2019年下半年,我们拥有17万行Go,一个超过4 PB的beta网络,真正的活跃用户,事实证明我们为自己打造的gRPC并不全是看上去很美的玫瑰花。

因此,我们重写了gRPC并迁移了实时网络。DRPC是一种开放源代码的直接替代产品,可以处理Go行中不足3000行的gRPC中所需的一切(很可能是您所需的一切)。现在,它为我们数以万计的服务器和无数客户的完整网络提供了动力。

在这里查看DRPC!

 

gRPC需要改进的地方

当我们开始查看对象存储产品以发现提高性能的机会时,我们发现我们在与gRPC的斗争中花费了大量时间。gRPC是整体的,不是很模块化。它具有很多功能膨胀。gRPC具有蠕变,膨胀的功能,并且正试图解决太多问题。它过于复杂,并且已成为功能的垃圾场。

  • 功能膨胀

您是否知道有40种不同的调用选项?有26个服务器选项。您有13个通话选项。gRPC非常庞大。导致我们远离gRPC的一个主要问题是,gRPC及其依赖项的添加量巨大,它占我们自己(相当大)二进制文件的五分之一以上。

另一方面,DRPC的核心在3000行以下!审核和理解它是一项合理的任务。

  • 资源利用率高

我们的一个存储节点中有81%的堆使用是gRPC,而基于protobuf的协议具有幸运的功能,可以避免复杂的字符串解析和传统的较旧协议(例如HTTP)的开销,否则如果您使用gRPC,您就必须处理HTTP / 2以及可能出现的所有遗留边缘情况。 

  •  不透明度

gRPC的代码行至少是DRPC的10倍,并且可以肯定地说某些API已经有机地增长了并且很难推理。同时,DRPC被实现为轻量级,简单明了,易于调试。

 

DRPC发布

我们需要一个精简的RPC工具,该工具可以做的事情要少一些,但是却做得很好。因此,我们建立了自己的框架DRPC,该框架仅3,000行代码,几乎不需要依赖,并且可以大大改善系统中的许多重要功能。

DRPC是我们针对gRPC弱点的解决方案。它是gRPC的直接替代品,因此,如果您当前正在使用gRPC,则迁移到DRPC(“ D”并不代表什么特别的东西)就像换出协议缓冲区生成管道以进行启动一样容易。并运行。我们甚至还提供了一个示例,说明如何将实时服务迁移到DRPC。

DRPC保留了gRPC的许多关键功能。它支持单一和双向流请求,它具有HTTP / JSON网关,它支持每个请求的边信道信息(如跟踪)的元数据,它减少了内存使用,并支持分层和中间件。

 

DRPC已经是我们在Github上排名第二高的存储库,在许多开发人员社交媒体的“水坑”中被投票最多,并且引起了无数讨论和兴趣。我们在RedditLobste.rs甚至在我们的Github存储库的“问题”选项卡中进行了许多激动人心的讨论。

人们似乎对DRPC感到兴奋-我们有志愿者帮助提供文档和其他语言绑定,并且自发布以来的几天里,我们想出了如何添加Twirp兼容性,Websocket兼容性,改进有关Javascript和浏览器交互的人体工程学,优化的代码以减少内存分配并进一步提高速度(有时最多减少90%的分配,而在某些微基准测试中则快7倍),以及许多其他事情。一位贡献者刚刚成功地使她的NodeJS绑定可用于Go流程,反之亦然。

至此,我们已经在数以万计的服务器上使用了多年的生产DRPC,因此您也可以使用它。

 

3
猜你喜欢