云原生的理念正如火如荼，然而真正大规模落地的公司依然屈指可数，蚂蚁作为国内比较早进行尝试的公司，经过了 2 年多的探索，沉淀出了一套切实可行的方案并最终通过了双十一的考验。
一、为什么需要 Service Mesh?
我们为什么需要Service Mesh，它对业务的价值在哪里，我们总结了三点：
1. 微服务治理与业务逻辑解耦。
2. 异构系统的统一治理。
3. 金融级的网络安全。
下面分别进行阐述。
1. 微服务治理与业务逻辑解耦
在 Service Mesh 之前，传统微服务体系的玩法都是由中间件团队提供一个 SDK 给业务应用使用，在 SDK 中会实现各种服务治理的能力，如：服务发现、负载均衡、熔断限流、服务路由等。
在运行时，SDK 和业务应用的代码其实是混合在一个进程中运行的，耦合度非常高，这就带来了一系列的问题：
升级成本高。每次升级都需要业务应用修改 SDK 版本号，重新发布。以蚂蚁为例，以往每年我们在中间件版本升级上就需要耗费数千人日。
版本碎片化严重。由于升级成本高，但中间件还是会持续向前发展，久而久之，就会导致线上 SDK 版本各不统一、能力参差不齐，造成很难统一治理。
中间件演进困难。由于版本碎片化严重，所以中间件向前演进过程中就需要在代码中去兼容各种各样的老版本逻辑，就像是戴着『枷锁』前行，无法实现快速迭代。
有了 Service Mesh 之后，我们就可以把 SDK 中的大部分能力从应用中剥离出来，拆解为独立进程，以 Sidecar 的模式运行。通过将服务治理能力下沉到基础设施，可以让业务更加专注于业务逻辑，而中间件团队则更加专注于各种通用能力建设，真正实现独立演进，透明升级，提升整体效率。
2. 异构系统统一治理
随着新技术的发展，在同一家公司中往往也会出现使用各种不同语言、不同框架的应用和服务。以蚂蚁为例，内部业务也是百花齐放，有前端、搜索推荐、人工智能、安全等各种业务，它们使用到的技术栈也非常多样化，除了Java 以外，还有 NodeJS、Golang、Python、C++ 等，为了能够统一管控这些服务，我们要为每种语言、每种框架都重新开发一套完整的 SDK，维护成本非常高，而且对我们的人员结构也带来了很大的挑战。
有了 Service Mesh 之后，通过将主体的服务治理能力下沉到基础设施，多语言的支持就轻松很多了，只需要提供一个非常轻量的 SDK、甚至很多情况都不需要一个单独的 SDK，就可以方便地实现多语言、多协议的统一流量控制、监控等治理需求。
3. 金融级网络安全
当前很多公司的微服务体系建设都建立在『内网可信』的假设之上，然而这个假设在当前大规模上云的背景下可能不再合适，尤其是涉及到一些金融场景的时候。
通过 Service Mesh，我们可以更方便地实现应用的身份标识和访问控制，辅之以数据加密，就能实现全链路可信，从而使得服务可以运行于零信任网络中，提升整体安全水位。
二、蚂蚁 Service Mesh 大规模落地实践
正因为 Service Mesh 带来了上述种种的好处，所以我们从 2018 年初就开始了技术探索并进行了小规模的落地试点，然而初期在和业务团队推广时，却面临了灵魂拷问：
1. 需要业务改代码吗？业务团队日常面临着非常繁重的业务压力，没有太多精力做技术改造。
2. 升级过程不要影响我业务。对公司业务而言，稳定肯定是第一位的，新的架构不能对业务产生影响
3. 其它你随便。言下之意就是只要我们能确保改造成本够低，稳定性够好，那业务团队还是愿意配合我们一起去落地 Service Mesh 的。
这就让我想起了著名的产品价值公式：
[图片上传失败...(image-b86c79-1611307219203)]
由此公式可知：
『新体验 - 旧体验』就是前述提到的 Service Mesh 所带来的种种好处，这部分价值需要被最大化
『迁移成本』就是业务在迁移至 Service Mesh 新架构过程中的种种成本，这部分成本需要被最小化，主要包括
接入成本：已有的系统如何接入 Service Mesh？是否要做业务改造？
是否平滑迁移：生产环境已经运行着众多的业务系统，是否能平滑地迁移到 Service Mesh 架构下？
稳定性：Service Mesh 是一套全新的架构体系，业务迁移上去之后如何确保稳定性？
接下来我们就来看一下蚂蚁是怎么做的。
接入成本
由于蚂蚁的服务统一使用了 SOFA 框架，所以为了最小化业务的接入成本，我们的方案是修改 SOFA SDK 的逻辑，从而能够自动识别运行模式，当发现运行环境启用了 Service Mesh，就会自动和 Sidecar 对接，如果没有启用 Service Mesh，则继续以非 Service Mesh 的方式运行。对业务方而言，只需要升级一次 SDK，就完成了接入，不需要改业务代码。
我们再来看一下 SDK 是怎么和 Sidecar 对接的，首先来看服务发现的过程：
1.假设服务端运行在1.2.3.4这台机器上，监听20880端口，首先服务端会向自己的 Sidecar 发起服务注册请求，告知 Sidecar 需要注册的服务以及 IP + 端口(1.2.3.4:20880)
2.服务端的 Sidecar 会向注册中心发起服务注册请求，告知需要注册的服务以及 IP + 端口，不过这里需要注意的是注册上去的并不是业务应用的端口(20880)，而是Sidecar自己监听的一个端口(例如：20881)
3.调用端向自己的 Sidecar 发起服务订阅请求，告知需要订阅的服务信息
4.调用端的 Sidecar 向调用端推送服务地址，这里需要注意的是推送的IP是本机，端口是调用端的 Sidecar 监听的端口(例如：20882)
5.调用端的 Sidecar 会向注册中心发起服务订阅请求，告知需要订阅的服务信息
6.注册中心向调用端的 Sidecar 推送服务地址(1.2.3.4:20881)
再来看一下服务通信过程：
1.调用端拿到的『服务端』地址是127.0.0.1:20882，所以就会向这个地址发起服务调用
2.调用端的 Sidecar 接收到请求后，通过解析请求头，可以得知具体要调用的服务信息，然后获取之前从服务注册中心返回的地址后就可以发起真实的调用(1.2.3.4:20881)
3.服务端的 Sidecar 接收到请求后，经过一系列处理，最终会把请求发送给服务端(127.0.0.1:20880)
通过上面的过程，就完成了 SDK 和 Sidecar 的对接。可能会有人问，为啥不采用 iptables 的方案呢？主要的原因是一方面 iptables 在规则配置较多时，性能下滑严重，另一个更为重要的方面是它的管控性和可观测性不好，出了问题比较难排查。
平滑迁移
蚂蚁的生产环境运行着非常多的业务系统，有着复杂的上下游依赖关系，有些是非常核心的应用，稍有抖动就会产生故障，所以对于像 Service Mesh 这样一个大的架构改造，平滑迁移是一个必选项，同时还需要支持可灰度和可回滚。
得益于我们在架构体系中保留的注册中心，平滑迁移方案也是比较简单直白的：
1.初始状态
以下图为例，初始有一个服务提供者，有一个服务调用者。
2.透明迁移调用方
在我们的方案中，对于先迁移调用方还是先迁移服务方没有任何要求，这里假设调用方希望先迁移到 Service Mesh 上，那么只要在调用方开启 Sidecar 的注入即可，SDK 会自动识别到当前启用了 Service Mesh，就会和Sidecar 做服务的订阅和通信，然后 Sidecar 会订阅服务并和真正的服务方通信，而服务方则完全不感知调用方是否迁移了。所以调用方可以采用灰度的方式一台一台开启 Sidecar，如果有问题直接回滚即可。
3.透明迁移服务方
假设服务方希望先迁移到 Service Mesh 上，那么只要在服务方开启 Sidecar 的注入即可，SDK 会自动识别到当前启用了 Service Mesh，就会和 Sidecar 做服务的注册和通信，然后 Sidecar 会把自己作为服务提供方注册到注册中心，调用方依然从注册中心订阅服务，完全不感知服务方是否迁移了。所以服务方可以采用灰度的方式一台一台开启 Sidecar，如果有问题直接回滚即可。
4.终态
最后就达到了终态，调用方和服务方都平滑地迁移到了 Service Mesh 上，如下图所示。
稳定性
通过 Service Mesh 架构的引入，我们初步实现了应用和基础设施的解耦，大大加快了基础设施的迭代速度，不过这对稳定性意味着什么？
在 SDK 的模式下，中间件同学在发布 SDK 后，业务应用会逐步升级，并且会按照开发、测试、预发、灰度、生产等环境逐步推进并进行完整的功能验证，从一定程度上来说，其实是有大量的业务同学在帮中间件的产品做测试，并且是分环境小规模逐步升级，所以风险非常小。
然而，在 Service Mesh 的架构下，业务应用和基础设施解耦了，这个使迭代速度大大加快，但是也意味着我们无法再用以前的这套模式来确保稳定性，我们不仅需要在研发阶段保证产品质量，更要在线上变更时控制风险。
考虑到蚂蚁的集群规模，线上变更往往涉及到几十万个容器，如何保证这么大规模下升级的稳定性呢？我们给出的方案是：无人值守变更。
在了解无人值守变更之前，我们先来看下无人驾驶，下面这副图定义了无人驾驶的成熟度级别，从L0 - L5。L0 就对应着我们现在大部分的驾驶模式，汽车本身没有任何自动化能力，需要由驾驶员来完全控制，而 L5 呢就是最高级别，能够实现真正的无人驾驶。像我们熟知的 Tesla，它的自动驾驶就处于L2 – L3 之间，具备了在一定场景下的自动驾驶能力。
我们也参照了这套体系定义了无人值守变更的级别，如下图所示：
L0：纯人肉变更，黑屏操作，没有任何工具辅助
L1：有了一些工具，不过并没有体系化串联起来，需要人编排不同的工具来完成一个变更，确保人工灰度
L2：具备了初步的自动化能力，系统能够自己编排将整个变更流程串起来，具备强制灰度的能力，所以相比于 L1 级别，人的手解放了，一次变更只需要提交一个工单即可
L3：系统具备了观测能力，在变更过程中，如果发现有异常会通知用户并且阻断变更，所以相比于 L2 级别，人的眼睛也解放了，我们不需要时刻盯着变更过程，不过电话还得开着，一旦有问题需要及时上线处理
L4：就更进一步了，系统具备了决策能力，当发现变更有问题的时候，系统可以自动处理实现自愈，所以相比于 L3 级别，人的大脑也解放了，变更可以放在半夜进行，有问题系统会按照预定义的方案自动处理，实在解决不了才需要电话通知人上线处理
L5：就是终极状态了，提交完变更后，人就可以离开了，系统会自动执行并且确保没有问题
目前我们自评已经做到了 L3 级别，主要体现在：
1. 系统自动编排分批策略，实现强制灰度
2. 引入了变更防御，增加了前置、后置校验，当问题发生时，能够及时阻断变更
变更防御流程如下图所示：
提交变更工单以后，系统会对变更进行分批，按照机房、应用、单元等维度开启分批变更
在每个批次变更开始前首先会进行前置校验，比如检查当前时间是否是业务高峰期，是否是故障期间，检查系统容量等
前置校验如果不通过，则变更终止并通知变更的同学，如果通过，则会开始 Mosn 的升级或接入流程
变更完成后会进行后置校验，比如会检查业务监控，像交易、支付成功率是否下跌等，还会检查服务健康度，比如RT、错误率是否有异常，同时也会检查上下游的系统，还会和告警关联，检查变更期间是否有故障产生等
后置校验如果不通过，则变更终止并通知变更的同学，如果通过，则会开始下一批次的变更流程
整体架构
我们再来看一下蚂蚁 SOFAMesh 的整体架构，这里的『双模微服务』是指传统的基于SDK 的微服务和 Service Mesh 微服务双剑合璧，从而可以实现：
互联互通：两个体系中的应用可以相互访问
平滑迁移：应用可以在两个体系中平滑迁移，对于上下游依赖可以实现透明无感知
灵活演进：在互联互通和平滑迁移实现之后，我们就可以根据实际情况进行灵活的应用改造和架构演进
在控制面上，我们引入了 Pilot 实现配置的下发（如服务路由规则），在服务发现上仍然保留了独立的注册中心来实现平滑迁移和规模化落地。
在数据面上，我们使用了自研的 Mosn，不仅支持 SOFA 应用，同时也支持 Dubbo 和 Spring Cloud 应用。
在部署模式上，我们不仅支持容器/k8s，同时也支持虚拟机场景。
落地规模和业务价值
目前 Service Mesh 覆盖了蚂蚁数千个应用，实现了核心链路全覆盖，生产运行的 Pod 数量有几十万，双十一当天处理的 QPS 达到了几千万，平均处理响应时间 <0.2 ms，取得了不错的技术成果。
在业务价值上，通过 Service Mesh 架构，我们初步实现了基础设施和业务应用的解耦，基础设施的升级能力从 1 ~ 2 次/年提升为 1 ~ 2 次/月，不仅大大加快了迭代速度，同时节省了全站每年数千人日的升级成本；借助于 Mosn 的流量调拨实现了分时调度的场景，仅用了 3m40s 就完成了 2w+ 容器的切换，节省下 3.6w+ 物理核，实现了双大促不加机器；在安全可信方面，实现了身份认证、服务鉴权和通信加密，从而使得服务可以运行于零信任网络中，提升了整体安全水位；在服务治理方面，快速上线了自适应限流、全局限流、单机压测、业务单元隔离等能力，大大提升了精细化服务治理水平，给业务也带来了很大的价值。
三、展望未来
目前，我们已经能非常清楚地看到整个行业正在经历从云托管(Cloud Hosted)到云就绪(Cloud Ready)直至云原生(Cloud Native)的过程。
不过这里希望强调的一点是，我们并不是为了技术而技术，技术的发展本质上还是为了业务发展。云原生也是一样，其根本还是在于提升效率，降低成本，所以云原生本身不是目的，而是手段。
我们通过 Service Mesh 的大规模落地，也是向着云原生走出了坚实的一步，验证了可行性，同时也确实看到了基础设施下沉后无论是对业务还是对基础设施团队都带来了研发和运维效率的提升。
目前 Mosn 主要提供了 RPC 和 MQ 的能力，然而还有大量的基础设施逻辑作为 SDK 嵌在业务系统中，离真正解耦基础设施与业务还有很大距离，所以未来我们会将更多的能力下沉到 Mosn 中（如事务、缓存、配置、任务调度等），实现 Service Mesh 到 Mesh 的演进。对业务应用而言，以后都会通过标准化的接口来和 Mosn 交互，不需要再引入各种很重的 SDK，从而使 Mosn 从单纯的流量代理演化成为下一代的中间件运行时。
通过这种方式能进一步降低业务应用和基础设施的耦合，使得业务应用更轻量化。如图所示，从最早的单体应用演化到微服务，实现了业务团队之间的解耦，但是并没有解开业务团队和基础设施团队之间的耦合，未来的方向就如第三幅图所示，我们希望业务应用朝着纯业务逻辑(Micrologic)这个方向前进，把非业务逻辑都下沉到 Sidecar 中，从而可以真正实现业务和基础设施的独立演进，提升整体效率。
另一个趋势是 Serverless，目前受限于应用体积、启动速度等因素，Serverless 主要的应用场景还是在 Function 上。
不过我们始终认为 Serverless 不会只局限在 Function 场景，它的弹性、免运维、按需使用等特性对普通的业务应用而言，价值显然是更大的。
所以当业务应用演进到 Micrologic + Sidecar 后，一方面业务应用自身的体积会变小、启动速度会加快，另一方面基础设施也能做更多的优化（比如提前和数据库建连、提前准备好缓存数据等），从而使得普通业务应用也能融入到 Serverless 体系中，真正享受到 Serverless 带来的效率、成本等方面的红利。
有疑问加站长微信联系（非本文作者）
