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

Question

我要解决的问题是后端微服务通信之间的延迟。设想。客户端向服务 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、B 和 C 之间使用明文 HTTP/2 987654323@.

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

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

Answer 2

如果延迟对您来说确实是个问题，那么您可能不应该在组件之间使用服务调用。相反，您应该尽量减少将控制传递给带外资源的次数，并在进程内进行调用，这样会快得多。

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

所以你应该问自己：

1. 就业务流程而言，延迟对您来说真的是个问题吗？根据我的经验，只有工程师才关心延迟。您的企业客户不会。
2. 如果延迟是一个问题，那么延迟是否可以明确归因于进行服务调用的成本？通话时间过长还有其他原因吗？
3. 如果是服务，那么您应该考虑将服务代码作为程序集使用，而不是带外使用。

Answer 3

为了其他遇到此问题的人的利益，除了使用HTTP/2、SSL/TLS Offloading、Co-location，请考虑在可能的情况下使用Caching。这不仅提高了性能，而且减少了对下游服务的依赖。另外，请考虑性能良好的数据格式。

Answer 4

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

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