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 模式可以很好地兼容, 帮助我们降低微服务架构复杂性, 更好地实现服务发现, 流量管理, 负载均衡, 路由.
来源: http://www.tuicool.com/articles/ZJFveqB