ServiceMesh概述

0 Service Mesh 的价值

sidecar(边车模式)是一种分布式架构的设计模式。如上图所示，边车就是加装在摩托车旁来达到拓展功能的目的，比如行驶更加稳定，可以拉更多的人和货物，坐在边车上的人可以给驾驶员指路等。边车模式通过给应用服务加装一个“边车”来达到控制和逻辑的分离的目的。

比如日志记录、监控、流量控制、服务注册、服务发现、服务限流、服务熔断等在业务服务中不需要实现的控制面功能，可以交给“边车”，业务服务只需要专注实现业务逻辑即可。如上图那样，应用服务你只管开好你的车，打仗的事情就交给边车上的代理就好。这与分布式和微服务架构完美契合，真正的实现了控制和逻辑的分离与解耦。

比如：RPC 框架由中间件事业部统一开发与维护，以 SDK 形式提供给集团内的其他事业部使用。由于 SDK 与应用逻辑是耦合在同一个进程中的，当 SDK 向前演进所增加的特性并不是某些业务方所需要的时，这些业务方就没有动力配合中间件事业部去同步升级自己应用中的 SDK 版本，使得 SDK 在整个集团存在多个版本甚至变成长尾而形成包袱。

当微服务框架是单一编程语言独大、不能同步支持好其他多个主流编程语言时（比如 C++、Go、Node.js 等）, 就会出现非独大编程语言的 SDK 在特性上严重滞后于独大编程语言的，最终影响使用非独大编程语言的业务方以自己最为熟悉的编程语言去发展和探索业务。编程语言独大所带来的好处是多数人的技术栈是一样的而提高了技术层面的协作效率，但却无法收获编程语言多样性所带来的其他好处。即便同步地对多个编程语言的 SDK 进行维护，同样的特性需要用不同的编程语言去实现其成本着实很高。

在 Service Mesh 的形态下，RPC 框架中容易变更的内容被剥离到了 sidecar 进程，之前的胖 SDK 瘦身为只保留了功能恒定的协议编解码能力。如此一来，与 RPC 框架演进相关的逻辑几乎集中在 sidecar 进程中，这就完全可以做到让使用 RPC 框架的业务方无感知地对之进行升级与维护。最终的结果是，业务与 RPC 框架可以做到独立发展与升级，完全消除了之前胖 SDK 所导致的两者相互制约发展的不利局面。这一解耦所带来的好处是，使用 RPC 框架的业务团队可以更加聚焦于业务开发本身，这正是发挥技术价值应达到的境界。

不难看出，Service Mesh 很好地解决了以往 RPC 框架多语言 SDK 的问题。虽然在 Service Mesh 下仍然需要 SDK，但由于 SDK 中的功能是相当稳定的，不存在应付频繁变更所带来的长期维护成本问题。由于 sidecar 是以进程的形式存在的，因此完全不关心使用 RPC 框架的业务逻辑是用什么编程语言实现的，只需实现一次而没有让人感到无聊的多语言特性对齐问题，将 RPC 框架技术团队的人力释放出来做更有价值的事。

也因为 sidecar 是以独立进程的形式存在，当出现因为公司收购所面临的母子公司技术栈不一致问题时，可以将 sidecar 部署在两个技术栈的衔接处，由 sidecar 通过协议转换等形式完成两个异构服务框架的连接，为异构服务框架的渐进式融合发展提供了可能，很好地缓解了短期高强度技术改造所面临的技术风险和对业务发展的拖累。

服务框架易变的功能剥离到了 sidecar 后，意味全网的服务流量治理能力可以通过 sidecar 进行收口——sidecar 自身的版本全网一致、流量规则与执行策略一致、监控口径一致，等等。诸多的“一致”将实现全网服务治理的体系化监管控，使得 Service Mesh 成为微服务软件架构拆分手法下完成横向连接与约束的强有力技术手段。

如果用一句话来描述 Service Mesh 的话，那就是“层次化、规范化、体系化、无侵入的分布式服务（或应用）治理技术”。

1 istlo

Istio是Google、IBM和Lyft联合开源的微服务Service Mesh框架，旨在解决大量微服务的发现、连接、管理、监控以及安全等问题。

Istio是对Service Mesh的产品化实践，帮助微服务实现了分层解耦，此时的sidecar具有一下功能：

（1）服务发现(discovery)

（2）负载均衡(load balancing)

（3）故障恢复(failure recovery)

（4）服务度量(metrics)

（5）服务监控(monitoring)

（6）A/B测试(A/B testing)

（7）灰度发布(canary rollouts)

（8）限流限速(rate limiting)

（9）访问控制(access control)

（10）身份认证(end-to-end authentication)

逻辑上Istio分为数据平面(data pane)和控制平面(control pane)：

数据平面用于有一些智能代理组成，微服务之间的网络通信，
控制平面负责对智能代理进行管理和配置。
主要由以下组件构成
数据平面，有一个核心组件：

Envoy (proxy)

Envoy的核心职责是高效转发，更具体的，它具备这样一些能力：

（1）服务发现

（2）负载均衡

（3）安全传输

（4）多协议支持，例如HTTP/2，gRPC

（5）断路器(Circuit breakers)

（6）健康检查

（7）百分比分流路由

（8）故障注入(Fault injection)

（9）系统度量

控制平面，有四个核心组件：

Mixer

Mixer的一些核心能力是：

（1）跨平台，作为其他组件的adapter，实现Istio跨平台的能力；

（2）和Envoy通讯，实时各种策略

（3）和Envoy通讯，收集各种数据

Mixer的设计核心在于“插件化”，这种模型使得Istio能够适配各种复杂的主机环境，以及后端基础设施。

Pilot

Pilot作为非常重要的控制平面组件，其核心能力是：

（1）为Envoy提供服务发现能力；

（2）为Envoy提供各种智能路由管理能力，例如A/B测试，灰度发布；

（3）为Envoy提供各种弹性管理能力，例如超时，重试，断路策略；

Pilot的设计核心在于“标准化”，它会将各种流控的控制命令转化为Envoy能够识别的配置，并在运行时，将这些指令扩散到所有的Envoy。Pilot将这些能力抽象成通用配置的好处是，所有符合这种标准的Envoy都能够接入到Pilot来。

潜台词是，任何第三方可以实现自己的proxy，只要符合相关的API标准，都可以和Pilot集成。

Citadel

Citadel组件，它提供终端用户身份认证，以及服务到服务的访问控制。总之，这是一个和安全相关的组件。

Galley

Gally组件，它是一个配置获取、校验、处理、分发的组件，它的设计核心在于“解耦”，它将“从底层平台（例如：K8S）获取用户配置”与Istio解耦开来。

5 与传统的微服务架构对比

优点

1 微服务治理与业务逻辑解耦
2 异构系统的统一治理
3 3大技术优势
可观察性
流量控制
安全

缺点

1 增加了复杂度
整体链路的复杂
操作运维的复杂度
2 需要更专业的运维技能
3 延迟问题
4平台的适配

参考

1 https://www.jianshu.com/p/27a742e349f7
2 https://segmentfault.com/a/1190000021222019
3 微服务：Service mesh 学习资源 https://www.jianshu.com/p/1678e8a84b2b
4 Service Mesh 的本质、价值和应用探索 https://baijiahao.baidu.com/s?id=1623506534600159805&wfr=spider&for=pc