蚂蚁金服 Service Mesh 大规模落地系列 - 质量篇

时间 2021-05-25

原文原文链接

本文为《蚂蚁金服 Service Mesh 大规模落地系列》最后一篇 - 质量篇，该系列从核心、RPC、消息、无线网关、控制面、安全、运维、测试等模块对 Service Mesh 双十一大规模落地实践进行详细解析。文末包含往期系列文章。跨域

前言

Service Mesh 在蚂蚁金服内部已经大规模落地，经历刚刚双十一的检阅，将现有的体系快速演进至 Service Mesh 架构，无异于给飞机换发动机。本主题主要分享在蚂蚁金服当前的体量下，咱们如何作到给飞机换发动机，还确保不出问题。同时在mesh对外客户输出一样有高质量的保障。安全

本文结合蚂蚁金服 Mesh 化落地质量保障落地的思考，给你们带来以下三个方面的一些质量保障的分享：架构

Mesh 化质量保障体系；
Mesh 化测试技术；
Mesh 化双十一大规模落地的性能保障；

质量保障体系

首先给你们介绍下咱们的质量保障体系。并发

测试保障体系框架

咱们从测试环境、测试用例、基础功能测试原子镜像能力、测试工具平台、测试场景组合调度、测试方案制定、线上巡检监控、灰度发布三板斧、交付验证、性能、自动化测试等多个方面进行系统性测试保障。经过内外部的质量数据度量和双十一大促来检阅咱们的质量能力。运维

Mesh 测试技术

在开始介绍测试技术以前，咱们先了解一下什么是 Service Mesh 以及 Service Mesh 是如何工做的，在蚂蚁金服的技术架构中是以什么形式存在，发挥着怎样的做用。ide

简单的说 Service Mesh 存在两个面，一个面叫数据面（好比 MOSN），就是处理应用数据请求的一个独立代理模块，脱离于应用，为应用提供请求代理及一些复杂通讯逻辑处理，另一个叫控制面（好比 SOFAMesh），管理应用配置及业务规则等（好比业务开关/服务路由规则），经过下发配置“指挥”数据面去执行，知足不一样阶段实现不一样的业务支持。函数

Mesh 框架简图微服务

咱们先简单介绍下经典微服务请求路由。工具

经典微服务模式请求路由

经典微服务模式下 Docker 镜像化服务在一个 Pod 通常只有一个业务应用容器在运行，这种状况下测试框架只要关心业务应用便可。

经典微服务测试架构

Mesh 测试架构改进

Mesh 测试架构在经典微服务测试架构上也作了新的演进。MOSN 做为 Sidecar 与业务容器共存在一个 Pod，资源与业务应用容器共享，每一个业务逻辑都须要经过 MOSN 去处理，于是只关心业务应用确定不够，须要再扩展支持到 MOSN 这类 Sidecar 的测试验证。在 MOSN 中集成了控制面 xds client，与控制面 pilot 创建通讯，用于接收 pilot 下发的配置信息。在蚂蚁金服技术架构存在三地五中心/同城双活等容灾能力，于是产生了 LDC，一个集群多个 zone 状况，控制面 pilot下发是能够配置集群+zone+应用+ip 组合粒度，要验证这个多 zone 下发规则准确性，那就须要建立多个 xds client（或者 MOSN）。另外 Sidecar 是不能直接访问的，经过测试应用暴露出接口，给上层测试。

Mesh 化测试架构

构建高仿真测试环境

那么，咱们测试环境要作到足够仿真，面临哪些挑战呢？首先看下咱们自研的 MOSN 具有的能力和技术复杂性。

MOSN 能力大图

应对 MOSN 测试场景复杂性，咱们搭建了一套高仿真测试环境，这里以 MOSN 中的 RPC 功能为例，阐述这套环境的构成要素及环境部署架构。

集成测试环境构成要素

这里能够举一个 RPC 路由的例子来详细讲述。咱们知道，业务在作跨 IDC 路由时，主要经过跨域 VIP 实现，这就须要业务在本身的代码中设置 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，这种配置是不合法的，就会出现问题，这时候测试环境就须要跨 zone、跨 LDC 的测试环境。咱们在多数复杂产品测试里都会遇到，极度复杂测试场景没法 100% 分析充分。通常对于这种场景，咱们能够借助于线上流量回放的能力，将线上的真实流量复制到线下，做为咱们测试场景的补充。这也须要很是仿真的测试环境作 MOSN 的流量回放支撑。

兼容性测试

MOSN 兼容性验证

咱们经过一个例子来详细阐述：老版本的 RPC 中咱们支持 TR 协议，后续的新版支持 BOLT 协议，应用升级过程当中，存在同时提供 TR 协议和 BOLT 协议服务的状况，以下图：

应用升级过程当中，相同接口提供不一样协议的服务

首先，应用向 MOSN 发布服务订阅的请求，MOSN 向配置中心订阅，配置中心返回给 MOSN 两个地址，分别支持 TR 和 BOLT，MOSN 从两个地址中选出一个返回给应用 APP。

这里兼容性风险是：MOSN 返回给 APP 的地址是直接取配置中心返回的第一条数据，这里多是 TR 也多是 BOLT。

若是 MOSN 返回给应用的地址是支持 BOLT 协议的服务端，那么后续应用发起服调用时，会直接以 BOLT 协议请求 MOSN，MOSN 选址时，会以轮询的方式两个服务提供方，若是调用到 Server1，就会出现协议不支持的报错。
所以咱们针对各类兼容性具体场景都要作好分析和相应的测试。

MOSN 的鲁棒测试（稳定性、健壮性）

从 MOSN 的视角来看，其外部依赖以下：

MOSN 外部依赖图

除了验证 MOSN 自身的功能外，咱们还经过故障注入的方式，对 MOSN 的外部依赖作了专项测试。经过这种方式，咱们发现了一些上述功能测试未覆盖的场景，这里以应用和 MOSN 之间的 12199 端口举例。

应用 APP 接入 MOSN 后，原先应用对外提供的 12200 端口改由 MOSN 去监听，应用的端口修改成 12199，MOSN 会向应用的 12199 端口发送心跳，检测应用是否存活。

若是应用运行过程当中出现问题，MOSN 能够经过心跳的方式及时感知到。

MOSN 与 APP 心跳断连处理示意图

如图所示，若是 MOSN 感知到心跳异常后，会向配置中心取消服务注册，同时关闭对外提供的 12200 端口服务。这样作的目的是防止服务端出现问题后，仍收到客户端的服务调用，致使请求失败。

测试该场景，咱们经过自动化故障注入系统 drop 掉 APP 返回给 MOSN 的响应数据，人为制造应用 APP 异常的场景。经过这种方式，自动对比指望结果，判断是否异常，后自动进行故障恢复，继续下一个故障注入测试。

Service Mesh 双十一大规模落地的性能保障

Mesh 在落地过程当中首先遇到的问题就是，蚂蚁金服如此大致量下，如何不出性能问题。MOSN 从能力上集成了中间件多种能力，所以线下压测比较复杂，在线上全链路压测开始以前，线下咱们基于中间件的压测能力作了一轮自身的压测，上线后从业务角度再作全链路压测，问题就会少不少，蚂蚁全链路压测部分，是很是成熟的技术，各类材料也介绍过屡次，相信你们都已经很是熟悉。蚂蚁金服中间件线下压测部分介绍比较少，所以我总结概括给你们介绍下，以下图：

举个控制面 gc 压测分析的例子：

CRD 下发能力是控制面核心，加密通讯也是基于 CRD 下发开关触发，而下发的关键性能点在于如下几个因素：

pilot 支持的 client 并发数；
另外对配置下发实时性比较高，于是配置下发到 client 的耗时也是重要指标；

在压测过程当中，没有足够资源来建立那么多 xds client，于是开发了 mock client（简化版 xds client），只保留核心通讯模块，单 pod 能够支持万级的 client 模拟。在持续压测一段时间，咱们发现内存频繁在 GC，致使耗时很高，pprof 分析内存。

MessageToStruct 和 FromJsonMap 最占内存，都是在对数据进行转换，MessageToStruct 以前有过同类优化，所以很快解决，可是 CRD 数据转换的核心 FromJsonMap，须要将数据转成 K8s 能识别的 yaml 信息。咱们进行了改造，将一部份内存进行重用，并优化转换函数，耗时降低了好几倍，降到了毫秒级别。

总结

本文分享了 MOSN 落地过程当中，咱们的测试开发技术。Service Mesh 在蚂蚁金服还将持续演进，咱们的质量防控体系还需持续建设，咱们面临的挑战还很大。热烈欢迎有兴趣的同窗加入蚂蚁金服中间件质量团队。

关于做者：

张伟（花名：柑橘）蚂蚁金服中间件质量团队负责人，关注领域：中间件测试开发技术。
王斌（花名：西经）蚂蚁金服 Service Mesh 质量主要负责人，主要 Focus 领域：MOSN。
吕超才（花名：柏翘）蚂蚁金服 Service Mesh 控制面质量负责人，主要 Focus 领域：SOFAMesh。