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