http - REST 微服务之间的通信 : Latency

Question

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

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

微服务公开了一个使用 HTTP 访问的 REST 接口(interface)。其中，服务之间提交请求的每个新 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 ，然后使用 Jetty's HttpClient with HTTP/2 transport 在微服务 A、B 和 C 之间使用明文 HTTP/2 .

在撰写本文时，我不确定 AWS ELB 是否已经支持 HTTP/2，但如果不支持，请务必向 Amazon 发送消息，要求支持它(许多其他公司已经这样做了)。正如我所说，您也可以使用 HAProxy。

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