全部产品

服务网格最佳实践之控制面质量

更新时间:2020-09-30 18:07:34

最近几年,云原生概念越来越火,蚂蚁集团历来热衷于技术创新,积极在云原生领域实践 Service Mesh 理念,结合现有技术架构,将一些通用能力(通信/数据/安全等)抽离出来,沉淀出了 MOSN。同时,依托于 Istio 的能力,扩展出了 Service Mesh 控制面,为 MOSN 提供上层的管控能力。本文主要介绍 Service Mesh 控制面在蚂蚁集团落地过程中,我们如何提供可靠的质量保障。主要内容分为下面几个方面:


Service Mesh 组成

Service Mesh 组成图

数据面-控制面 (1).png

说明

  • 数据面:称为 MOSN,是处理应用数据请求的一个独立代理模块,脱离于应用,为应用提供请求代理及一些复杂通信逻辑处理。
  • 控制面:称为 SOFAMesh,管理应用配置及业务规则等(例如业务开关/服务路由规则),通过下发配置,“指挥”数据面去执行,满足不同阶段不同实现的业务支持。

控制面与经典微服务的差异

  • 经典微服务形态

经典微服务形态 (1).png

  • Service Mesh 融入形态

serviceMesh融入态 (1).png

说明
2 者区别主要为下述几个方面:

  • Service Mesh 在数据面 Pod 中额外增加了 Mosn。
  • Service Mesh 取消了 Config Server,由 Service Mesh 控制面处理 Mosn 推送的配置数据。而经典微服务通过 Config Server 来推送配置数据。

Service Mesh 控制面落地

Service Mesh 控制面,在 Kubenates 基础上对上层提供 CRD/RBAC 等操作能力;并在开源 Istio 的 Enovy 基础上,通过 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

TLS 加密通信

TLS 加密通信实现过程:

  1. 在开启 TLS 开关后,MOSN 通过 UDS(Unified Diagnostic Services) 向控制面的 Citadel Agent 获取 TLS 证书信息。
  2. TLS 证书由蚂蚁集团自身安全证书服务 KMS 授权给控制面 Citadel 服务,Citadel 会做一些证书检测等处理。
  3. 将校验通过的证书同步给 Citadel Agent,依次循环实现证书流转更新。

TLS 加密通信过程示例

TLS加密.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

代码质量管控

新工程新代码,在快速迭代同时,还需要保证代码质量。控制面几乎全部由 Go 语言开发,不像标准开发语言 Java 一样有非常丰富的组件支持,因而在度量时没有丰富的质量指标。

借助蚂蚁集团效能团队的 Ant Code 服务,蚂蚁团队配置了适合 ServiceMesh 控制面的流水线,目前可以支持安全扫描/规范扫描/代码覆盖率等,也支持 Code Review,只有研发/质量 Review 通过,才能合并代码,而且在合并时会自动触发执行 UT(Unit Test),避免异常代码合入。

镜像统一化打包,Review 通过和 UT 通过之后,会自动构建测试镜像包,提升测试包质量,示例如下。

代码质量

在 Ant Code 基础上,蚂蚁团队开发了自定义组件,动态管控代码覆盖率,不断提升代码研发质量,加强研发自测意识。

代码质量管控2 (1).png

稳定性要求

CRD 下发能力是控制面核心,TLS 加密通信也是基于 CRD 下发开关触发,而下发的关键性能点在于以下几个因素:

  • Pilot 支持的 Client 并发数。
  • 下发到 Client 的耗时:因为对配置下发实时性要求比较高。

在压测过程中,由于没有足够资源用来创建很多 xds Client,因而开发了 Mock Client(简化版 xds Client),只保留核心通信模块,单 Pod 可以支持万级的 Client 模拟。在持续压测一段时间后,蚂蚁团队发现内存频繁在 GC,导致耗时很高。

PProf 内存分析图

内存分析图

说明

  • MessageToStruct 和 FromJsonMap 最占内存,都是在对数据进行转换。
  • MessageToStruct 之前有过同类优化,因此可以很快解决。
  • FromJsonMap:是 CRD 数据转换的核心 ,需要将数据转成 K8S 能识别的 yaml 信息。蚂蚁团队对此进行了改造,将一部分内存进行重用,并优化转换函数,耗时下降了好几倍,降到了毫秒级别。

运维管控

控制面服务基于 K8S 开发,以 Deployment 和 Daemonset 形式发布上线,每次发布都会影响到整个集群,需要一定风险把控手段。

依靠 Ant code 的代码 Review 机制,蚂蚁团队建立了研发/质量/ SRE 三方评审机制,管控变更范围。评审完成后自动部署到对应集群,通过监控秒级巡检,发现问题可以及时告警,共同保障了线上生产质量。


未来规划

规划 (1).png