Sidecar模式初识

Sidecar设计模式正在收到越来越多的关注和采用。作为Service Mesh的重要要素，Sidecar模式对于构建高度高度可伸缩、有弹性、安全且可便于监控的微服务架构系统至关重要。而Service Mesh也已经被证明，正在改变企业IT的“游戏规则”，它降低了与微服务架构相关的复杂性，并提供了负载平衡、服务发现、流量管理、电路中断、遥测、故障注入等功能特性。

什么是Sidecar模式？

Sidecar模式是一种将应用功能从应用本身剥离出来作为单独进程的方式。该模式允许我们向应用无侵入添加多种功能，避免了为满足第三方组件需求而向应用添加额外的配置代码。

就像边车加装在摩托车上一样，在软件架构中，sidecar附加到主应用，或者叫父应用上，以扩展/增强功能特性，同时Sidecar与主应用是松耦合的。

举个例子，假设现在有6个相互通信的微服务，每个微服务都需要具有可观察性、监控、日志记录、配置、断路器等功能，而所有这些功能都是在微服务中使用一些第三方库实现的。

这样一组服务的实际情况可能会非常复杂，增加了应用的整体复杂性，尤其是当每个微服务用不同的语言编写、使用不同的基于.net、Java、Python等语言的第三方库……

Sidecar模式的好处

• 通过将公用基础设施相关功能抽象到不同的层来降低微服务的代码复杂性
• 由于我们不需要在每个微服务中编写配置代码，因此减少了微服务架构中的代码重复
• P应用和底层平台之间实现了松耦合

Sidecar模式如何工作

Service Mesh层可以位于应用程序侧的Sidecar容器中，同一sidecar的多个副本可以附在每个应用旁。

来自单个服务的所有传入和传出网络流量均通过Sidecar代理，完成微服务之间的流量管理、遥测数据收集以及策略的执行等等。从某种意义上来说，服务对于网络是无感知的，只知道所附加的sidecar代理。这就是Sidecar模式工作的本质，它将网络依赖抽象成了Sidecar。

在Service Mesh中，我们需要了解Data Plane和Control Plane两个概念——

• Data Plane的作用是处理网格内服务间的通信，并完成服务发现、负载均衡、流量管理、健康检查等功能；数据平面的作用是处理网格内服务之间的通信，并负责实现服务发现、负载平衡、流量管理、健康检查等功能；
• Control Plane的作用是管理和配置Sidecar来执行策略并收集遥测（telemetry）

例子

一些例子如下：

Web-server容器可以与一个sidecar容易共同部署，该sidecar容器从文件系统中读取由Web-server容器生成的web-server日志，并将日志/stream发送到原称服务器（remote server）。Sidecar容器通过处理web-server日志来作为web-server容器的补充。当然，可能会有人说，为什么web-server不自己处理自己的日志？答案在于以下几点：

• 隔离（separation of concerns）：让每个容器都能够关注核心问题。比如web-server提供网页服务，而sidecar则处理web-server的日志，这有助于在解决问题时不与其他问题的处理发生冲突；
• 单一责任原则（single responsibility principle）：容器发生变化需要一个明确的理由。换句更容易理解的话来说，每个容器都应该是能够处理好“一件”事情的，而根据这一原则，我们应该让不同的容器分别展开工作，应该让它们处理的问题足够独立；
• 内聚性/可重用性（Cohesiveness/Reusability）：使用sidecar容器处理日志，这个容器按道理应该可以应用的其他地方重用；

以上例子正如下图所示：

另一个例子是在web-server容器与sidecar容器共同部署时，将文件系统与git存储库同步。（我们需要注意Git同步容器的重用醒）如下图所示，应用容器知识链接到本地机器的Redis服务器上：