Question

我试图解决的问题是后端微服务通信之间的延迟。场景。客户端向服务A发出请求，然后服务A调用服务B调用服务C，然后返回对B的响应，该响应转到A并返回到客户端。

Request: Client -> A -> B -> C
Response: C -> B -> A -> Client

微服务公开了一个使用HTTP访问的REST接口。其中提交请求的服务之间的每个新HTTP连接都是额外的开销。我正在寻找减少这种开销的方法，而无需在混合中引入另一种传输机制（即尽可能地坚持使用HTTP和REST）。一些答案建议使用Apache Thrift，但我想避免这种情况。其他可能的解决方案是使用消息队列，我也想避免使用它。（为了降低运营复杂性）。

有没有人使用HTTP连接池或HTTP / 2进行微服务通信？系统部署在AWS上，其中服务组由ELB提供。

Answer 1

HTTP / 1.0工作模式是为每个请求打开一个连接，并在每次响应后关闭连接。

应避免使用远程客户端和微服务中的客户端（例如A中呼叫B的客户端和B中呼叫C的客户端）的HTTP / 1.0，因为为每个请求打开连接的成本可能会导致大部分等待时间。

HTTP / 1.1工作模式是打开一个连接，然后让它保持打开状态，直到对等方明确请求关闭它。这允许连接被重用于多个请求，并且它是一个巨大的胜利，因为它减少了延迟，它使用更少的资源，并且通常它更有效。

幸运的是，现在微服务中的远程客户端（例如浏览器）和客户端都支持HTTP / 1.1，甚至HTTP / 2.

当然浏览器有连接池，你可以在微服务中使用的任何体面的HTTP客户端也有连接池。

远程客户端和微服务客户端应至少使用带有连接池的HTTP / 1.1。

关于HTTP / 2，虽然我是浏览器到服务器使用的HTTP / 2的重要推动者，但对于数据中心内的REST微服务调用，我会对您感兴趣的参数进行基准测试，用于HTTP / 1.1和HTTP / 2，然后看看他们的票价。在大多数情况下，我希望HTTP / 2与HTTP / 1.1相当，如果不是稍微好一点。

我使用HTTP / 2（免责声明，我是Jetty提交者）的方式是offload TLS from remote clients using HAProxy，然后在微服务A之间使用明文HTTP / 2， B和C使用Jetty's HttpClient with HTTP/2 transport。

我不确定AWS ELB在撰写本文时是否已经支持HTTP / 2，但如果没有，请务必向亚马逊发送消息，要求支持它（许多其他人已经这样做了）。正如我所说，或者你可以使用HAProxy。

对于微服务之间的通信，无论远程客户端使用何种协议，都可以使用HTTP / 2。通过使用Jetty的HttpClient，您可以非常轻松地在HTTP / 1.1和HTTP / 2传输之间切换，因此这为您提供了最大的灵活性。

Answer 2

如果延迟确实是您的问题，那么您可能不应该在组件之间使用服务调用。相反，您应该最小化控制传递到带外资源的次数，并在进程中进行调用，这要快得多。

但是，在大多数情况下，服务“包装器”（通道构造，序列化，编组等）产生的开销可以忽略不计，并且仍然在业务流程的足够的延迟容差范围内。受到支持。

所以你应该问问自己：

在业务流程方面，延迟真的是一个问题吗？根据我的经验，只有工程师关心延迟。您的企业客户没有。
如果延迟是个问题，那么延迟最终是否会归因于拨打服务的成本？电话花了很长时间还有其他原因吗？
如果是服务，那么您应该将服务代码作为程序集而不是带外使用。

Answer 3

微服务通信之间的延迟是低延迟应用程序的一个问题，但是可以通过微服务和整体组件之间的混合来最大程度地减少呼叫次数

新兴的C ++微服务框架最适合低延迟应用程序 https://github.com/CppMicroServices/CppMicroServices

REST微服务之间的通信：延迟

3 个答案: