Sidecar

其中,对于服务网格创建的通信层应该位于架构的位置,Aspen Mesh的Andrew Jenkins就提出了三种可能的选择,即:

  • 作为一个Lib库,让每个微服务可导入。

  • 部署在节点的代理服务中,为所在节点的全部容器提供服务。

  • 与应用容器相并行,运作在一个独立的sidecar容器内。

其中,基于sidecar模式是目前最流行的服务网格模式,以至于在某种程度上讲,它已经成等同于服务网格的模式。

服务网格中的每个应用微服务容器都有一个对应匹配的代理容器。服务到服务的通信所需的所有逻辑请求都从微服务中抽象出来,放到了sidecar中处理。通过将所有网络和通信代码放到一个单独的容器中,使其成为基础设施的一部分,并使开发人员不必将如上的内容视为应用程序的一部分而投入精力处理。从本质上说,抽象后剩下的也是一个微服务,但它可以非常专注于其业务逻辑。在微服务所运行的复杂环境中,它不需要知道如何与其他的任何微服务实现通信的问题,它只需要知道如何与sidecar通信,然后由sidecar负责余下的工作。