[网络协议]Why Service Mesh

什么是Service Mesh

官方介绍

A service mesh is a dedicated infrastructure layer for handling service-to-service communication. It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application. In practice, the service mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware.

翻译过来：服务网格是一个专门处理服务通讯的基础设施层。它的职责是在由云原生应用组成服务的复杂拓扑结构下进行可靠的请求传送。在实践中，它是一组和应用服务部署在一起的轻量级的网络代理，并且对应用服务透明。

Service Mesh是2016年Buoyant CEO William Morgan 提出的服务网格的概念，同时William Morgan也是Service Mesh的先行者和布道者。

个人理解

服务网格是一个专门处理服务通讯的基础设施层。它通过在业务 Pod 中注入 Sidecar 容器，接管业务容器的通信流量，同时 Sidecar 容器与网格平台的控制平面对接，基于控制平面下发的策略，对代理流量实施治理和管控，将原有服务框架的治理能力下层到 Sidecar 容器中，从而实现了基础框架能力的下沉，与业务系统解耦。

为什么我们要Service Mesh

以RPC的场景来切入

在没有Service Mesh之前，在RPC这层和业务的结合相当紧密，对于一些RPC层面的需求，比如流量调度，流量镜像，灰度引流等，是需要在RPC层面进行升级开发支持，这时需要业务方来升级对应的中间件版本，这给我们带来了一些困扰和挑战。

1. 线上客户端框架版本不统一
2. 业务和框架耦合，升级成本高
3. 机器逐年增加，如果不增加机器如何度过双十一？
4. 在基础框架准备完成后，如何推动老用户升级？
5. 流量切换，灰度引流，蓝绿，AB等新的诉求

Service Mesh的核心价值

服务网格的特点

服务网格有如下几个特点：

• 应用程序间通讯的中间层
• 轻量级网络代理
• 应用程序无感知
• 解耦应用程序的重试/超时、监控、追踪和服务发现

目前两款流行的服务网格开源软件 Linkerd 和 Istio 都可以直接在 Kubernetes 中集成，其中 Linkerd 是 CNCF 成员项目，并在 2021 年 7 月毕业。Istio 在 2018年7月31日宣布 1.0，并在 2020 年 7 月将商标捐献给 Open Usage Commons。

Service Mesh如何工作？

Istio是开源社区认可度、活跃度最高的产品，我们以Istio为例来了解Service Mesh的工作原理

Istio核心架构

从上图来看，Istio主要由数据平面和控制平面组成。

数据平面

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

• 服务发现
• 负载均衡
• 安全传输
• 多协议支持，例如HTTP/2，gRPC
• 断路器(Circuit breakers)
• 健康检查
• 百分比分流路由
• 故障注入(Fault injection)
• 系统度量

控制平面

Mixer

Mixer的一些核心能力是：

• 跨平台，作为其他组件的adapter，实现Istio跨平台的能力；
• 和Envoy通讯，实时各种策略
• 和Envoy通讯，收集各种数据

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

Pilot

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

• 为Envoy提供服务发现能力
• 为Envoy提供各种智能路由管理能力，例如A/B测试，灰度发布
• 为Envoy提供各种弹性管理能力，例如超时，重试，断路策略

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

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

Citadel

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

Galley

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

Sidecar 模式

Sidecar 模式是 Istio 开源之初就在使用的模式，这种模式将应用程序的功能划分为单独的进程运行在同一个最小调度单元中，比如 Kubernetes 的 Pod 中。这种架构分为两个部分：控制平面和数据平面，控制平面是一个单体应用 Istiod，数据平面是由注入在每个 Pod 中的 Envoy 代理组成。你可以在 Sidecar 中添加更多功能，而不需要修改应用程序代码。这也是服务网格最大的一个卖点之一，将原先的应用程序 SDK 中的功能转移到了 Sidecar 中，这样开发者就可以专注于业务逻辑，而 sidecar 就交由运维来处理。

Proxyless模式

Proxyless模式是 Istio 1.11 版本中支持的实验特性，可以直接将 gRPC服务添加到 Istio 中，不需要再向 Pod 中注入 Envoy 代理。这样做可以极大的提升应用性能，降低网络延迟。有人说这种做法又回答了原始的基于 SDK 的微服务模式，其实非也，它依然使用了 Envoy 的 xDS API，但是因为不再需要向应用程序中注入 Sidecar 代理，因此可以减少应用程序性能的损耗。

Istio是服务网格的标准吗？

iptables 的流量劫持机制

• 需要借助于 conntrack模块实现连接跟踪，在连接数较多的情况下，会造成较大的消耗
• iptables 属于常用模块，全局生效，不能显式的禁止相关联的修改，可管控性比较差
• iptables 重定向流量本质上是通过 loopback 交换数据，outbond流量将两次穿越协议栈，在大并发场景下会损失转发性能

全量配置下发策略

Istio 下发 xDS使用的是全量下发策略，也就是网格里的所有 sidecar，内存里都会有整个网格内所有的服务发现数据，理由是用户很难梳理清楚服务间依赖关系并且提供给 Istio。

Service Mesh在蚂蚁金服大规模落地

蚂蚁金服应该是国内最早吃到Service Mesh蛋糕的公司，蚂蚁金服fork了Istio的代码，在兼容Istio的基础上研发了SOFAMesh和SOFAMosn，并本着拥抱开源，社区共建的原则在2019年开源。经过几年的发展，MOSN已经经受住了双11的考验。

流量劫持方案往往是和公司内部的 Naming Service 以及服务注册发现机制相结合的，不会一昧地追求零侵入式方案。

Service Mesh未来展望

如何成长为Apache顶级项目Committer

• 了解Apache基金会组织结构关系
  
• 关注某个社区的邮件
  
• 个人经验