gRPC遭抛弃！Storj为何使用DRPC替代gRPC？

在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上排名第二高的存储库，在许多开发人员社交媒体的“水坑”中被投票最多，并且引起了无数讨论和兴趣。我们在Reddit，Lobste.rs甚至在我们的Github存储库的“问题”选项卡中进行了许多激动人心的讨论。

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

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