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项目网站

• 试用Rainbond公有云

  • 注册或使用Demo帐号/密码登陆：rainbond-demo/rainbond-demo
• Github
• 码云
• 文档
• 微信群: 添加微信“zqg5258423”并接受邀请入群