微服务通信：HTTP vs RPC答案

【问题标题】：Microservices communication: HTTP vs RPC微服务通信：HTTP vs RPC
【发布时间】：2020-06-12 12:51:51
【问题描述】：

RPC 标准的创建考虑了分布式计算，但在当今的微服务世界中，我们几乎不使用 RPC 进行服务之间的通信，而主要使用 HTTP。

我想了解原因。

我可以想到诸如序列化（不够快）、消息传输的可靠性、没有多线程、缺乏异步通信等限制，考虑到当今的可扩展性要求，RPC 可能具有并且可能会出现某种瓶颈。

但是当我在网络上搜索这些限制时，我的印象是，这些限制在今天可能不是一个大问题，而且有些框架/lib 可以解决所有或部分这些限制。

所以，我想了解 RPC 在微服务通信中不太流行的确切原因，尽管它们比 HTTP 更早。

【问题讨论】：

gRPC 已充分用于微服务间的通信，可能主要是 ppl 使用的浏览器，它们通过 DNS 和网关设置完成，事情仍然坚持 HTTP，gRPC 在 HTTP2 的底层运行，我的团队在将 HTTP 上运行的其他服务与 gRPC 集成时遇到了一个巨大的麻烦，要知道引擎盖下发生了什么真的很麻烦
@TusharMahajan 感谢您的回复。在您的设置中，您是否认为 RPC 通信是可扩展的，并且除了集成 HTTP 和 RPC 之外，您是否注意到 RPC 通信的任何其他操作瓶颈，这可能会导致需要大量流量的企业应用程序出现问题。
我觉得可扩展性没有任何问题，对于高流量，它支持流和一元 API，因此没有这样的问题。只有通过反向代理层的 HTTP 到 HTTP/2 通信让我们很头疼
@TusharMahajan 您选择 RPC 的任何具体原因？我假设如果您知道您的某些组件（可能是第 3 方）正在使用 HTTP，那么如果您选择 HTTP 和另外一件事，那么集成会容易得多，如何为新添加的节点管理服务发现？
只是速度是一个问题，基于 HTTP2 的内部微服务通信比 HTTP1 快得多，SSL 保护也有点像。

标签： http microservices communication rpc

【解决方案1】：

任何通过 Internet 或复杂网络进行的通信如果放弃使用 HTTP，都会遇到各种挂断……HTTP 协调代理、网关、隧道的行为，定义错误和状态……你re gona 最终不得不自己实现。对于组织之间的任何通信，您都需要一种标准的实现方式。您还会遇到操作系统和语言的类型和版本之间的兼容性问题。对于内部系统，人们使用界面描述语言来缓解操作系统/语言问题，但这增加了复杂性并且仅在组织内有效。即使您要使用自己的自定义实现.. 也有很多多余的工作没有很多回报。但是微服务的理念是它们应该可以被各种系统重用，所以这和微服务的理念不太兼容。

现在，您可以在 HTTP 之上添加 RPC。这被使用了，尽管它提出了一个关于设计的更普遍的问题。在 SOA（面向服务的架构）之前，有一段时间人们使用分布式对象架构。分布式对象使用 RMI（远程方法调用），只是对象的 RPC。这种方法被 SOA 和最终 REST 抛弃有几个原因 -

A) 很难支持分布式对象的事务，因为对象需要管理复杂的状态，但没有定义的交互方式发生。分布式对象之间经常存在紧密耦合。除其他外，SOA 将事物解耦，这使得事务更容易。

B) 最终转向 REST，服务是无状态的，所有的逻辑/状态管理都留给客户端。这进一步降低了服务的复杂性，并使它们更加正交。但这与在服务器上进行处理的 RPC 不同，而 REST 则在客户端上进行。

C) 再次集成问题。使用 HTTP 可以缓解这种情况，但并非完全如此，因为 RPC 需要客户端实现 RPC 接口，这会增加复杂性。

D) RPC 最初的想法是接口应该对程序员是透明的，但在地理分布的系统中，由于网络延迟，无法保持透明性。因此，与发送常规 HTTP 请求相比，您得到的改进并没有那么大。

所以要回答这个问题...除非在非常特殊的情况下，例如如果您正在为高性能集群设计中间件并且您不想要开销，否则在没有 HTTP 的情况下使用 RPC 通常没有太多好处发送 HTTP 请求。但即便如此，它也必须是一个特殊的用例，因为您通常只需要为此重用现有的中间件。

【讨论】：