我试图解决的问题是后端微服务通信之间的延迟。场景。客户端向服务A发出请求，然后服务A调用服务B，该服务B在返回到B的响应之前调用服务C，该响应转到A并返回到客户端。
Request: Client -> A -> B -> C
Response: C -> B -> A -> Client
微服务公开了使用HTTP访问的REST接口。其中提交请求的服务之间的每个新HTTP连接都是额外的开销。我正在寻找减少这种开销的方法，而无需在混合中引入另一种传输机制（即尽可能地坚持使用HTTP和REST）。一些答案建议使用Apache Thrift，但我想避免这种情况。其他可能的解决方案是使用消息队列，我也想避免使用它。 （为了降低运营复杂性）。
有没有人使用HTTP连接池或HTTP / 2进行微服务通信？系统部署在AWS上，其中服务组由ELB提供。
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，但如果没有，请务必向亚马逊发送消息，要求支持它（许多其他人已经这样做了）。正如我所说，或者您可以使用HAProxy。
对于微服务之间的通信，无论远程客户端使用何种协议，都可以使用HTTP / 2。通过使用Jetty的HttpClient，您可以非常轻松地在HTTP / 1.1和HTTP / 2传输之间切换，因此这为您提供了最大的灵活性。
如果延迟确实是您的问题，那么您可能不应该在组件之间使用服务调用。相反，您应该最小化控制传递到带外资源的次数，并在进程中进行调用，这要快得多。
但是，在大多数情况下，服务“包装器”（通道构造，序列化，编组等）所产生的开销可以忽略不计，并且仍然在支持的业务流程的适当延迟容差范围内。
所以你应该问自己：
为了让其他人遇到这个问题，除了使用HTTP/2，SSL/TLS Offloading，Co-location之外，请考虑使用Caching。这不仅提高了性能，还降低了对下游服务的依赖性。另外，请考虑表现良好的数据格式。
微服务通信之间的延迟是低延迟应用程序的问题，但是微服务和整体之间的混合可以最小化呼叫次数
新兴的C ++微服务框架最适合低延迟应用程序https://github.com/CppMicroServices/CppMicroServices