控制面质量
最近几年，云原生概念越来越火，蚂蚁集团历来热衷于技术创新，积极在云原生领域实践 Service Mesh 理念，结合现有技术架构，将一些通用能力（通信/数据/安全等）抽离出来，沉淀出了 MOSN。同时，依托于 Istio 的能力，扩展出了 Service Mesh 控制面，为 MOSN 提供上层的管控能力。本文主要介绍 Service Mesh 控制面在蚂蚁集团落地过程中，我们如何提供可靠的质量保障。
主要内容分为下面几个方面：
Service Mesh 组成
Service Mesh 组成图
Service Mesh 组成说明：
数据面：称为 MOSN，是处理应用数据请求的一个独立代理模块，脱离于应用，为应用提供请求代理及一些复杂通信逻辑处理。
控制面：称为 SOFAMesh，管理应用配置及业务规则等（例如业务开关、服务路由规则），通过下发配置，“指挥”数据面去执行，满足不同阶段不同实现的业务支持。
控制面与经典微服务的差异
经典微服务形态
Service Mesh 融入形态
2 者区别主要为下述几个方面：
Service Mesh 在数据面 Pod 中额外增加了 Mosn。
Service Mesh 取消了 Config Server，由 Service Mesh 控制面处理 Mosn 推送的配置数据。而经典微服务通过 Config Server 来推送配置数据。
Service Mesh 控制面落地
Service Mesh 控制面，在 Kubenates 基础上对上层提供 CRD/RBAC 等操作能力；并在开源 Istio 的 Envoy 基础上，通过 xDS 协议扩展业务信息，支持将 “服务路由规则/配置开关” 等下发到 MOSN，让 MOSN 去执行，以满足不同业务需求。在双十一活动中，控制面落地了下述 2 个能力：
CRD 配置下发：CRD 指 Custom Resource Definitions，是 K8s 原生支持的自定义资源语义。
TLS 加密通信：TLS 指 Transport Layer Security。
CRD 配置下发
蚂蚁集团扩展出了 ScopeConfig 来限定 CR（Custom Resource） 生效的范围，支持机房/集群/应用/IP 等级别设置，在 ScopeConfig 基础上增加了一些 PilocyConfig CRD（策略/规则/开关等），这样可以实现线上灰度可控/降级回滚能力及一些 A/B TEST。
TLS 加密通信
TLS 加密通信实现过程：
在开启 TLS 开关后，MOSN 通过 UDS（Unified Diagnostic Services） 向控制面的 Citadel Agent 获取 TLS 证书信息。
TLS 证书由蚂蚁集团自身安全证书服务 KMS 授权给控制面 Citadel 服务，Citadel 会做一些证书检测等处理。
将校验通过的证书同步给 Citadel Agent，依次循环实现证书流转更新。
TLS 加密通信过程示例
挑战及应对
测试架构改进
标准模式下， 在一个 Pod 中，Docker 镜像化服务一般只有一个业务应用容器在运行，这种情况下测试框架只要关心业务应用即可。
Service Mesh 是一种非标准模式。MOSN 作为 Sidecar，与业务容器共存于一个 Pod 中，资源与业务应用容器共享。每个业务逻辑都需要通过 MOSN 去处理，因而不能只关心业务，需要将测试验证扩展到 MOSN。
MOSN 集成了控制面 xds Client，与控制面 Pilot 建立通信，用于接收 Pilot 下发的配置信息。蚂蚁集团技术架构有 “三地五中心/同城双活”等容灾能力，因而产生了 LDC、一个集群多个 Zone 等情况。
控制面 Pilot 下发，配置粒度可以为集群 + Zone + 应用 + IP，要验证这种多 Zone 下发规则的准确性，需要创建多个 xds Client（或者 MOSN）。
Sidecar 不能直接访问，需要通过测试应用暴露出接口，给上层测试。
代码质量管控
新工程新代码，在快速迭代同时，还需要保证代码质量。控制面几乎全部由 Go 语言开发，不像标准开发语言 Java 一样有非常丰富的组件支持，因而在度量时没有丰富的质量指标。
借助蚂蚁集团效能团队的 Ant Code 服务，蚂蚁团队配置了适合 ServiceMesh 控制面的流水线，目前可以支持安全扫描/规范扫描/代码覆盖率等，也支持 Code Review，只有研发/质量 Review 通过，才能合并代码，而且在合并时会自动触发执行 UT（Unit Test），避免异常代码合入。
镜像统一化打包，Review 通过和 UT 通过之后，会自动构建测试镜像包，提升测试包质量，示例如下。
在 Ant Code 基础上，蚂蚁团队开发了自定义组件，动态管控代码覆盖率，不断提升代码研发质量，加强研发自测意识。
稳定性要求
CRD 下发能力是控制面核心，TLS 加密通信也是基于 CRD 下发开关触发，而下发的关键性能点在于以下几个因素：
Pilot 支持的 Client 并发数。
下发到 Client 的耗时：因为对配置下发实时性要求比较高。
在压测过程中，由于没有足够资源用来创建很多 XDS Client，因而开发了 Mock Client（简化版 XDS Client），只保留核心通信模块，单 Pod 可以支持万级的 Client 模拟。在持续压测一段时间后，蚂蚁团队发现内存频繁在 GC，导致耗时很高。
PProf 内存分析图
PProf内存分析图说明：
MessageToStruct 和 FromJsonMap 最占内存，都是在对数据进行转换。
MessageToStruct 之前有过同类优化，因此可以很快解决。
FromJsonMap：是 CRD 数据转换的核心 ，需要将数据转成 K8s 能识别的 YAML 信息。蚂蚁团队对此进行改造，将一部分内存进行重用，并优化转换函数，耗时下降好几倍，降到毫秒级别。
运维管控
控制面服务基于 K8s 开发，以 Deployment 和 Daemonset 形式发布上线，每次发布都会影响到整个集群，需要一定风险把控手段。
依靠 Ant code 的代码 Review 机制，蚂蚁团队建立了研发、质量、SRE 三方评审机制，管控变更范围。评审完成后自动部署到对应集群，通过监控秒级巡检，发现问题可以及时告警，共同保障了线上生产质量。
未来规划
