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）；
Envoy
在开源PaaS Rainbond中，提供了“基于envoy的7层网络治理插件”，Envoy本身可以原生运行于Rainbond插件体系之中，用户也可以选择和实现其他插件，Rainbond运行时本身提供了完善的基础服务。例如Rainbond根据Istio的成熟程度，采用部分集成的策略，进行了Mixer集成（智能控制策略）和Citadel集成（安全通信集成）。
其中由Lyft开源的Envoy是为云原生应用设计的代理，在服务旁运行，以平台无关的方式提供必要的特性，所有到服务的流量都通过Enovy代理。
总结来说，在从一体化架构向微服务架构的转型让我们可以相对独立、大规模地部署应用，而在容器环境中，Sidecar模式可以很好地兼容，帮助我们降低微服务架构复杂性，更好地实现服务发现、流量管理、负载均衡、路由。
- END -
关于Rainbond
Rainbond是一款以应用为中心的开源PaaS，由好雨基于Docker、Kubernetes等容器技术自主研发，可作为公有云或私有云环境下的应用交付平台、DevOps平台、自动化运维平台和行业云平台，或作为企业级的混合云多云管理工具、Kubernetes容器管理工具或Service Mesh微服务架构治理工具。- Rainbond项目网站
- 注册或使用Demo账号/密码登录：rainbond-demo/rainbond-demo
- Github
- 码云
- 文档
- 微信群: 添加微信“zqg5258423”并接受邀请入群