数据面质量
服务网格（Service Mesh） 包含了控制面和数据面，其中，数据面为自研的 MOSN。本文介绍 Service Mesh 数据面 MOSN 在蚂蚁集团的落地过程中，如何进行质量保障，以及如何确保从现有的微服务体系平滑演进至 Service Mesh 架构。
MOSN 简介
经典微服务架构和 Service Mesh 架构的差别主要包括：
经典微服务体系：基于 SDK 实现服务的注册和发现。
Service Mesh 体系：基于数据面 MOSN 实现服务的注册和发现，且服务调用也通过 MOSN 来完成。
经典微服务架构
Service Mesh 微服务架构
在 ServiceMesh 体系下，原先的 SDK 逻辑下沉至数据面 MOSN 中，会带来如下优点：
基础能力下沉后，基础能力的升级不再依赖应用的改造和发布，降低应用打扰率。
基础能力升级后，可快速迭代并铺开，对应用无感。
蚂蚁集团自研数据面 MOSN 具备的能力：
落地面临的问题
MOSN 具备丰富的能力，在落地过程中，也面临下述几个问题：
在质量保障上有哪些挑战？
如何应对质保挑战？
在质量保障上有哪些挑战？
新产品：蚂蚁团队并没有采用社区方案 Envoy 或 Linkerd，而是选择自研数据面 MOSN。从底层的网络模型，到上层的业务模块，全部需要研发重新编码来实现，并作为基础设施，去替代线上运行稳定的 SDK。这种线上变更的风险很高。
非标语言：这套自研的数据面 MOSN，采用的是 Golang 语言。蚂蚁集团内部的技术栈主要是 Java，相应的研发流程也是围绕着 Java 来构建。这套新引入的技术栈，需要新的流程平台来支撑。
大促：从蚂蚁集团内部着手基础设施升级开始到双十一来临，时间短，任务重。完成核心链路应用的全部 Mesh 化，涉及应用数量达 100 多个，涉及 Pod 达数十万多个，还需要经受住双十一大促考验。
线上稳定性：在升级过程中，要求对业务无损，大规模升级完成后，业务能正常运行。
输出站点：包括蚂蚁集团、网商银行和公有云。但是，3 个站点所依赖的基础设施和所要求的能力，存在差异，这些不同能力要求会造成代码分支碎片化。因此需要考虑下述 2 个问题。
如何同时保障多站点输出的质量？
如何管理好这些碎片化分支？
如何应对质保挑战？
规范研发流程
在推进 Mesh 化落地时，蚂蚁集团内部的研发效能部开始推出 ANT CODE 研发平台，其支持 Golang 语言，提供自定义流水线编排能力和部分原生插件。基于该平台，蚂蚁团队对研发过程做了如下规范：
git-flow 分支管控
代码管理需要一个清晰的流程和规范，蚂蚁团队引入了 Vincent Driessen 提出的代码管理解决方案。详情请参见 A Successful Git Branching Model。
代码审查（CR）：从现有的质量保障手段来看，Code Review（CR） 是低成本发现问题的有效方式，基于 ANT CODE 平台，蚂蚁团队定义了下述 CR 规范。
交付流水线：以 MOSN 持续交付流水线为例，图示如下。
流水线卡点
上述任一步骤执行失败，整个流水线将会失败，代码将无法合并。
卡点规则在工程根目录的 YAML 配置文件中。通过自定义插件统一收口这些卡点规则，精简了工程根目录的 YAML 配置文件，也使得规则的变更只需更新插件的内存配置即可。
集成测试
为了验证 MOSN，蚂蚁团队搭建了一套完整的测试环境。这里以 MOSN 中的 RPC 功能为例，阐述这套环境的构成要素及环境部署架构。
集成测试环境构成要素
集成测试环境优缺点：
优点：
MOSN 中的路由能力，完全兼容原先 SDK 中的能力，且在其基础上不断优化，如通过路由缓存提升性能等。
依托于这套环境做集成测试，可完成自动化脚本编写，并在迭代中持续集成。
缺点：这套测试环境，并不能发现所有的问题，有一些问题会遗留到线上，并给业务带来干扰。
下文以 RPC 路由为例，阐述对线下集成测试的一些思考。
业务在做跨 IDC 路由时，主要通过 ANTVIP 实现，这就需要业务在自己的代码中设置 VIP 地址，格式如下：
<sofa:reference interface="com.alipay.APPNAME.facade.SampleService" id="sampleRpcService">
<sofa:binding.tr>
<sofa:vip url="APPNAME-pool.zone.alipay.net:12200"/>
</sofa:binding.tr>
</sofa:reference>但运行中，有部分应用，因为历史原因，配置了不合法的 URL，如：
<sofa:reference interface="com.alipay.APPNAME.facade.SampleService" id="sampleRpcService">
<sofa:binding.tr>
<sofa:vip url="http://APPNAME-pool.zone.alipay.net:12200?_TIMEOUT=3000"/>
</sofa:binding.tr>
</sofa:reference>上述 VIP URL 指定了 12200 端口，却又同时指定了 http，这种配置是不合法的。 因为历史原因，这种场景在原先的 CE（Cloud Engine） 中做了兼容，而在 MOSN 中未继续这种兼容。
这类历史遗留问题，在多数产品里都会遇到，可以归为测试场景分析遗漏。一般对于这种场景，可以借助于线上流量回放的能力，将线上的真实流量复制到线下，作为测试场景的补充。但现有的流量回放能力，并不能直接用于 MOSN，原因在于 RPC 的路由寻址与部署结构有关，线上的流量并不能够在线下直接运行，因此需要一套新的流量回放解决方案。目前，这部分能力还在建设中。
专项测试
除了上述功能测试之外，蚂蚁团队还引入了如下专项测试：
兼容性测试
性能测试
故障注入测试
兼容性测试
MOSN 兼容性验证图
发现的问题：通过兼容性测试，发现问题主要集中在 接入/未接入MOSN 这个场景中。
例如，在线下验证过程中，接入了 MOSN 的客户端调用未接入 MOSN 的服务端会偶发失败，服务端会有如下协议解析报错：
[SocketAcceptorIoProcessor-1.1]Error com.taobao.remoting -Decode meetexception
java.io.IOException:Invalid protocol header:1经分析，原因在于老版本 RPC 支持 TR 协议，后续的新版支持 BOLT 协议，应用升级过程中，存在同时提供 TR 协议和 BOLT 协议服务的情况，即相同接口提供不同协议的服务，示例如下：
配图说明：
应用向 MOSN 发布服务订阅的请求，MOSN 向配置中心订阅，配置中心返回给 MOSN 两个地址，分别支持 TR 和 BOLT，MOSN 从两个地址中选出一个返回给应用 APP。
MOSN 返回给 APP 的地址是直接取配置中心返回的第一条数据，有下述 2 种可能：
地址是支持 BOLT 协议的服务端：后续应用发起服调用时，会直接以 BOLT 协议请求 MOSN，MOSN 选址时，会轮询两个服务提供方，如果调用到 Server1，就出现了上述协议不支持的报错。
地址是支持 TR 协议的服务端：因 BOLT 对 TR 做了兼容，因而不会出现上述问题。
修复方案：最终的修复方案是，MOSN 收到配置中心的地址列表后，会做一层过滤，只要服务端列表中包含 TR 协议的，则全部降级到 TR 协议。
性能测试
为了验证业务接入 MOSN 后的性能影响，蚂蚁团队将业务的性能压测环境应用接入 MOSN，并使用业务的压测流量做验证。下述为业务接入 MOSN 后的性能对比图：
故障注入测试
从 MOSN 的视角来看，其外部依赖如下：
除了验证 MOSN 自身的功能外，蚂蚁团队还通过故障注入的方式，对 MOSN 的外部依赖做了专项测试。通过这种方式发现了一些上述功能测试未覆盖的场景。
下文以应用和 MOSN 之间的 12199 端口为例，进行说明。
MOSN 与 APP 心跳断连处理示意图
配图说明：
应用 APP 接入 MOSN 后，原先应用对外提供的 12200 端口改由 MOSN 去监听，应用的端口修改为 12199，MOSN 会向应用的 12199 端口发送心跳，检测应用是否存活。
如果应用运行过程中出现问题，MOSN 可以通过心跳的方式及时感知到。
如果 MOSN 感知到心跳异常后，会向配置中心取消服务注册，同时关闭对外提供的 12200 端口服务。这样做的目的是防止服务端出现问题后，仍收到客户端的服务调用，导致请求失败。
为了验证该场景，蚂蚁团队在线下测试环境中，通过 iptables 命令 drop 掉 APP 返回给 MOSN 的响应数据，人为制造应用 APP 异常的场景。通过这种方式，蚂蚁团队也发现了一些其它不符合预期的 bug，并修复完成。
快速迭代
从项目立项到双十一，留给整个项目组的时间并不充裕，为了确保双十一能够平稳过度，蚂蚁团队采取的策略是：在质量可控范围内，通过快速迭代，让 MOSN 在线上能够获得充分的时间做验证。这离不开上述基础测试能力的建设，同时也依赖蚂蚁集团线上变更三板斧原则。
线上压测及演练
MOSN 全部上线之后，跟随着业务一起，由业务的 SRE（Site Reliability Engineer ） 触发多轮的线上压测，以此发现更多的问题。线上演练，主要是针对 MOSN 自身的应急预案的演练，如线上 MOSN 日志降级等。
监控及巡检
在 Mesh 化之前，线上的监控主要是整个 POD 级别的监控；Mesh 化之后，在监控团队的配合下，线上监控支持了 MOSN 的独立监控，以及 POD 中 Sidecar 与 APP 容器的监控。
巡检是对监控的补充，部分信息无法通过监控直接获取，如 MOSN 版本的一致性。通过巡检可以发现，哪些 POD 的 MOSN 版本还没有升级到最新，是否存在有问题的版本还在线上运行的情况等。
未来如何完善产品？
通过双十一，Service Mesh 更多是在性能和线上稳定性方面给出了证明，但技术风险底盘依然不够稳固。接下来，除了建设新功能外，蚂蚁团队还会在技术风险领域做更多的建设。在质量这块，主要包括：
在这个过程中，蚂蚁团队期望能够引入一些新的测试技术，能够有一些新的质量创新，以便把 Service Mesh 做的越来越好。