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

Question

我试图解决的问题是后端微服务通信之间的延迟.场景.客户端向服务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提供.

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做到这一点(声明,我是一个码头的提交)将使用HAProxy的远程客户端卸载TLS,然后用明文HTTP微服务A,B和C之间/ 2使用Jetty的HttpClient有HTTP/2传输.

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

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