文档

数据面质量

更新时间:
一键部署

服务网格(Service Mesh) 包含了控制面和数据面,其中,数据面为自研的 MOSN。本文介绍 Service Mesh 数据面 MOSN 在蚂蚁集团的落地过程中,如何进行质量保障,以及如何确保从现有的微服务体系平滑演进至 Service Mesh 架构。

MOSN 简介

经典微服务架构和 Service Mesh 架构的差别主要包括:

  • 经典微服务体系:基于 SDK 实现服务的注册和发现。

  • Service Mesh 体系:基于数据面 MOSN 实现服务的注册和发现,且服务调用也通过 MOSN 来完成。

经典微服务架构

经典微服务架构.png

Service Mesh 微服务架构

serviceMesh微服务架构.png

在 ServiceMesh 体系下,原先的 SDK 逻辑下沉至数据面 MOSN 中,会带来如下优点:

  • 基础能力下沉后,基础能力的升级不再依赖应用的改造和发布,降低应用打扰率。

  • 基础能力升级后,可快速迭代并铺开,对应用无感。

蚂蚁集团自研数据面 MOSN 具备的能力:

MOSN能力大图

落地面临的问题

MOSN 具备丰富的能力,在落地过程中,也面临下述几个问题:

  • 在质量保障上有哪些挑战?

  • 如何应对质保挑战?

在质量保障上有哪些挑战?

落地挑战 (1).png
  • 新产品:蚂蚁团队并没有采用社区方案 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

    git-flow管控
  • 代码审查(CR):从现有的质量保障手段来看,Code Review(CR) 是低成本发现问题的有效方式,基于 ANT CODE 平台,蚂蚁团队定义了下述 CR 规范。CR规范

  • 交付流水线:以 MOSN 持续交付流水线为例,图示如下。MOSN 持续交付流水线

  • 流水线卡点

    质量卡点.png
    • 上述任一步骤执行失败,整个流水线将会失败,代码将无法合并。

    • 卡点规则在工程根目录的 YAML 配置文件中。通过自定义插件统一收口这些卡点规则,精简了工程根目录的 YAML 配置文件,也使得规则的变更只需更新插件的内存配置即可。

集成测试

为了验证 MOSN,蚂蚁团队搭建了一套完整的测试环境。这里以 MOSN 中的 RPC 功能为例,阐述这套环境的构成要素及环境部署架构。

集成测试环境构成要素

集成测试环境构成要素 (1).png

集成测试环境优缺点

  • 优点:

    • 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 的客户端调用未接入 MOSN 的服务端会偶发失败,服务端会有如下协议解析报错:

[SocketAcceptorIoProcessor-1.1]Error com.taobao.remoting -Decode meetexception
java.io.IOException:Invalid protocol header:1

经分析,原因在于老版本 RPC 支持 TR 协议,后续的新版支持 BOLT 协议,应用升级过程中,存在同时提供 TR 协议和 BOLT 协议服务的情况,即相同接口提供不同协议的服务,示例如下:

bolt-tr协议.png

配图说明:

  • 应用向 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 性能对比 (1).png

故障注入测试

从 MOSN 的视角来看,其外部依赖如下:MOSN 外部依赖图(包含端口号)

除了验证 MOSN 自身的功能外,蚂蚁团队还通过故障注入的方式,对 MOSN 的外部依赖做了专项测试。通过这种方式发现了一些上述功能测试未覆盖的场景。

下文以应用和 MOSN 之间的 12199 端口为例,进行说明。

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

mosn心跳.png

配图说明:

  • 应用 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 做的越来越好。

参考资料

  • 本页导读 (0)
文档反馈