《蚂蚁金服 Service Mesh 大规模落地系列》将会从核心、RPC、消息、无线网关、控制面、安全、运维、测试等模块对 Service Mesh 双十一大规模落地实践进行详细解析，文末包含往期系列文章。本文为该系列文章的第三篇 - 运维篇。
引言
Service Mesh 是蚂蚁金服下一代架构的核心，也是蚂蚁金服内部向云原生演进的重要一环。本文为 Service Mesh 系列文章的运维篇，作者：黄家琦 （花名：嘉祁），蚂蚁金服运维专家，Service Mesh SRE，主要关注云原生基础设施、中间件及 Service Mesh 的稳定性，同时也是 Pythoner，sofa-bolt-python 作者。本文将主要分享大规模服务网格在蚂蚁金服当前体量下落地到支撑蚂蚁金服双十一大促过程中，运维角度所面临的挑战与演进，包括云原生化的选择与问题，对资源模型的挑战，大规模下运维设施的演进，以及周边技术风险能力的建设。Service Mesh 在2019年得到了大规模的应用与落地，截止目前，蚂蚁金服的 Service Mesh 数据平面 MOSN 已接入应用数百个，接入容器数量达数十万，是目前已知的全世界最大的 Service Mesh 集群。同时，在刚刚结束的双十一大促中，Service Mesh 的表现也十分亮眼，RPC 峰值 QPS 达到了几千万，消息峰值 TPS 达到了几百万，且引入 Service Mesh 后的平均 RT 增长幅度控制在 0.2 ms 以内。
拥抱云原生
Service Mesh 在软件形态上，是将中间件的能力从框架中剥离成独立软件。而在具体部署上，保守的做法是以独立进程的方式与业务进程共同存在于业务容器内。我们在蚂蚁金服内部的做法，则从开始，就选择了拥抱云原生。
Sidecar 模式
业务容器内独立进程的好处在于与传统的部署模式兼容，易于快速上线；但独立进程强侵入业务容器，对于镜像化的容器更难于管理。而云原生化，则可以将 Service Mesh 本身的运维与业务容器解耦开来，实现中间件运维能力的下沉。在业务镜像内，仅仅保留长期稳定的 Service Mesh 相关 JVM 参数，从而仅通过少量环境变量完成与 Service Mesh 的联结。同时考虑到面向容器的运维模式的演进，接入 Service Mesh 还同时要求业务完成镜像化，为进一步的云原生演进打下基础。
||优|劣|
|独立进程|·兼容传统的部署模式
·改造成本低
·快速上线|·侵入业务容器
·镜像化难于运维|
|Sidecar|·面向终态
·运维解耦|·依赖 K8s 基础设施
·运维环境改造成本高
·应用需要镜像化改造|