一、前言
大规模分布式系统的稳定性建设，是确保业务服务不受硬件、人为等风险因素影响而中断的核心工作，随着业务规模增大和复杂度的提升，系统稳定性的重要程度和难度也随之增大。在蚂蚁集团业务发展过程中，业务复杂度、用户规模以及业务重要性都逐步增大，相应的稳定性建设也伴随着业务的发展进行了不断地建设和提升。
本文将从分布式系统稳定性建设发展过程出发，针对过程的关键技术和思路演进进行简单介绍。
二、发展历程
稳定性建设最终以服务业务稳定运行为最终目的，因此稳定性的建设发展也随着业务特点和规模变化而演进。
第一阶段：（2011年之前）分布式系统转型，解决集群一致性问题
这个阶段支付宝最主要的业务就是淘宝平台里的担保交易功能，通过担保交易中间账户，解决买家和卖家之间的信任问题。在这个阶段，我们的应用架构开始走向分布式SOA架构，对交易、支付、账务、收银台等核心系统做服务化改造，在这个大的背景之下，业务开始变的越来越复杂，系统越来越多，分布式体系复杂性引入的问题需要一套高可用方案来解决，其中最主要的两大问题，一是如何做到分布式数据一致性，二是如何做好分布式环境下的系统监控。解决第一个问题主要依靠的技术是分布式事务，支付宝基于两阶段事务原理自研了相应的分布式事务框架和微服务框架，构建了一套稳定的分布式事务体系。解决第二个问题，支付宝构建了第一代监控系统，摆脱了黑屏命令行监控。从稳定的应用架构和系统化的监控报警平台开始奠定了后续高可用架构的基础。
第二阶段：（2011-2014） 单机房百万核，去IOE，解决存储单点扩展和稳定性问题
支付宝除了支撑淘宝以外，逐渐以第三方支付工具的身份变成一个互联网平台，系统支撑的流量激增，随着双11“引爆”全网，我们的系统容量面临了前所未有的压力，使用大量的服务器支撑高并发的同时，也带来了数倍的成本和诸多的不可控因素，这个时候阿里巴巴提出了去IOE战略（不再使用IBM小型机、oracle数据库、EMC高端存储，转向自主掌控的技术），双11和去IOE两者结合到一起，倒逼着我们在高可用架构上做出大量改进。首先是核心系统的可扩展性，读多写少的会员核心完成了读写分离、缓存化，资金事务处理为主的交易、支付、账务系统相继完成水平拆分，在拆分的过程中，开始使用廉价的服务器、SSD存储等代替小型机和高端存储，获得了更高的运行效率，解决了应用级的可扩展性问题。但另一方面，廉价服务器本身的稳定性有所下降，数量又比之前大幅增加，这就需要我们的核心系统具备在单数据库宕机的情况下快速恢复的能力，我们称之为failover能力，每个核心系统都基于数据中间件研发了一套适配自己业务的应用层failover能力，可以在一个数据库故障的情况下切换到一个空的数据库上延续主要业务实现在5分钟之内的快速恢复，用高可用技术手段弥补了稳定性的下降。就这样，核心系统级别的稳定性和可扩展性问题被解决，奠定了这一代高可用架构的基石，支付宝可以很好地应对大流量带来的高并发和稳定性风险。
第三阶段：（2014-2018）异地多活，解决机房扩展及容灾
金融级产品对稳定性有极高的要求，需要加速实现金融级异地多活的高可用架构。这一代高可用架构的核心技术就是内部称之为LDC（Logical Data Center）的异地多活架构，同时蚂蚁自研的OceanBase解决了数据上的容灾问题，与LDC相结合实现两地三中心和三地五中心的异地多活高可用架构。另一方面，双11的峰值和日常业务峰值差别越来越大，如果都靠新建数据中心来支撑会造成巨大的成本浪费，因此基于LDC架构实现了机房级别弹性扩展能力。
第四阶段：（2018-至今）混合云千万核，智能化风险防控体系，全面精细化业务风险防控
随着蚂蚁的各项业务发展，商家服务全面开放、大促活动常态化，业务形态多种多样，我们也意识到，只靠解决双11和机房容灾层面的“大问题”，已经不能满足业务的诉求，我们需要把高可用当成一个业务来做，从风险视角构建一套架构体系从根源上杜绝风险。
经过分析，我们认为高可用的风险主要分为三类：第一类，外部环境的剧烈变化，如活动带来的流量突增、机房故障等；第二类，内部节点的异常，如数据库宕机，服务器宕机等；第三类，人为变更的风险，如代码发布，配置推送等。对于这三类风险，一方面需要提升依赖研发运维人员的日常工作中进行相应的保障涉及，因此我们构建了高可用白皮书，总结了专家经验和设计案例提供给相关同学学习查阅，并进行应用和业务的高可用度量；另一方面基于业务故障指标驱动及风险影响因子分析，建设了如变更防控体系、容量风险体系、应急定位体系等风险防控体系，并引入数据智能化手段进行精细的风险识别，构建仿真环境以模拟故障及验证问题。经过多年建设，整体故障数据呈现逐年下降的趋势。
经过几代稳定性架构演进，逐步演进为当前蚂蚁应对分布式系统风险的完整体系，以下针对体系关键技术进行简单介绍。
三、系统风险巡检
经过多年系统稳定性建设，我们发现仅仅依赖通用平台能力兜底无法解决稳定性上的全部问题，特别是精确到每一个具体的业务和应用问题时，需要研发运维工程师在设计设施过程中基于对于业务和系统的理解，在技术方案设计和实现过程针对稳定性问题进行必要的考量，利用基础设施相关技术对风险进行识别、规避和兜底，才能更好的进行稳定性方面的保障。
因此基于多年技术专家的经验沉淀，蚂蚁针对性的面对研发运维同学总结和整理了一套基于研发运维过程中的方法论指导，使得相关同学在思路和方法上有更深入的理解。同时，对于通用的设计风险，通过巡检平台和高可用度量平台对于每个业务和应用的通用风险或防御能力制定扫描规则以发现并提醒研发进行优化。
高可用白皮书
高可用白皮书主要以研发运维过程视角进行整理，包含相应的设计思路、技术方案、基础平台使用和经典案例总结。
设计&编码
可观察设计：系统设计过程需考虑可观察能力，包括必备的日志、监控配置，以便及时发现问题。
冗余防御：鉴于服务、硬件的不稳定，对于依赖的系统和硬件需要进行必要的防御编程。包含分布式冗余，依赖异常的捕获和降级处置。
容量性能：能够达到业务需要的伸缩能力，尽可能提升性能降低耗时，避免无效依赖。
变更灰度：代码设计具备变更灰度的能力，根据不同业务和需求设计不同等级的灰度方案，包含兼容性考虑，用户级别灰度、流量级别灰度等能力，具备回滚能力。
压测演练能力：系统具备支持压测、演练的能力，包含压测数据构造、压测隔离能力等建设。
发布&变更
变更三板斧标准：任何变更需要满足可监控、可灰度、可回滚方案设计，变更过程能够发现问题、灰度降低影响面、能够快速回滚止血。
变更防御接入：变更接入通用的变更防御体系，以复用通用的防御能力。
线上运维
应急自愈：配置合理监控报警，报警及时处理，指定合理的值班安排，配合全局业务应急处理，必要的通过自愈建设提升处理效率。
容量保障：提前评估业务量级和容量风险，定期监控容量水位，进行定期压测验证，配置合理的限流保护。
预案演练：应急预案进行定期演练，定期进行容灾能力演练。
高可用度量及巡检
基于高可用白皮书沉淀的专家经验，部分规则转换为高可用风险点，通过构建应用和业务巡检能力对系统进行巡检扫描，最终在根据风险级别、应用级别产出高可用度量分。研发运维工程师根据对应的优化建议，参考高可用白皮书即可进行相应的优化处置。目前我们构建了高可用度量和巡检产品，通过应用运行数据采集和巡检规则沉淀实现风险扫描和披露，当前已经沉淀1.3万个风险巡检规则，每天运行1000多万次系统扫描。
四、稳定性解决方案
在解决分布式系统扩展性、性能、容灾等稳定性问题过程，基础设施结合业务同学通过技术建设和创新，提供了一系列的稳定性技术方案，以下针对过程中部分技术方案进行简单介绍。
异地多活部署架构
LDC（Logical Data Center）作为蚂蚁核心的部署架构，主要解决机房扩展性、机房容灾以及大促机房快速弹性问题，当前已服务了蚂蚁业务多年，支撑了多年大促峰值挑战。
LDC架构将系统集群按照用户id为维度，创建多个逻辑单元，每个逻辑单元承载指定用户范围的流量，同时系统数据也按照相同的范围将数据库部署到对应的逻辑单元中，这样每个逻辑单元形成一个可以独立运行的最小规模。随后运维工程师将每个逻辑单元可以独立部署到任意物理机房，甚至是异地机房，当机房需要扩展或迁移时，只需要将对应的逻辑单元进行拆分或迁移即可，以此实现蚂蚁异地多活架构部署体系。
为了解决机房故障的快速恢复问题，基于该体系提供了灵活的流量调度能力，蚂蚁构建了应对单机房故障的同城、异地容灾能力。即针对每个逻辑单元设置一个对应的同城灾备单元和一个异地的灾备单元，当某个逻辑单元对应的机房故障时，通过调度将流量调整到其他逻辑单元以临时提供服务。这个过程关键挑战是应用是无状态的能够提供无差别服务，但数据灾备恢复难度较大，这就依托与OceanBase的多节点一致性能力来实现数据的秒级灾备切换。
另外，双十一、新春红包大促等活动，峰值远大于日常容量要求，如果日常即准备满足大促的容量则会带来大量的资源浪费，同样基于ldc的流量调度能力，构建了机房级别的弹性能力，能够在大促前将流量弹回到新的机房，而在大促结束后快速回收该机房。
精细化流量调度
支付业务对稳定性要求较高，在针对该业务保障过程，为提升支付相应效率、提升服务间调用稳定、降低资源消耗，进行了合并部署技术的探索和实施。合并部署技术将相关性较高的上下游多个应用通过容器技术部署到一台物理机，针对同一台物理机优先服务路由来降低网络带来的延迟消耗，在此基础上，进一步通过进程间通信技术降低服务延迟、通过容器资源超卖来提升资源利用率。通过合并部署技术在当年双十一大促活动中整体支付耗时从198ms下降到111ms，下降43%，整体节约成本800多台虚拟机。
另外，由于蚂蚁业务复杂度高，对于底层系统可能同时承载高等级和低等级的不同业务，而不同级别业务也会相互影响，而采用合并部署模式会带来额外的复杂度，因此基于云原生的容器技术和mosn路由调度技术，实现了轻量的路由模式，针对流量进行亲和路由，将高等级和低等级业务流量进行虚拟的隔离。
其他技术
在整个发展历程中，还诞生了诸多为了提升稳定性的技术能力，例如业务方面的支付异步化、防抖设计，基础设施的分布式事务解决方案、分布式定时调度、一致性消息等技术，这里不逐一罗列。当前LDC、流量调度等技术解决方案也在筹备通过开源等方式进行开放共享。
五、平台风险产品体系
蚂蚁技术风险基于故障驱动，构建了一系列风险防御体系，过程中针对复杂的业务和应用，通过采用数据化和智能化手段提升风险防御的全面性和准确性。如下针对部分能力介绍。
智能变更防御
我们发现60%以上的故障都是人为变更导致的，而仅靠研发人员自身能力和意识来避免故障产生还是容易产生遗漏，因此我们决定构建变更核心系统，将变更作为一项重要的业务来进行系统化构建。变更系统构建变更防御切面，针对全部变更执行过程对接变更统一决策，实现系统化的三板斧（可监控/可灰度/可回滚）要求。变更核心架构上定义了统一的标准变更三元组（变更情景、变更动作、变更对象），并针对每次变更构建智能化的防控微服务来检测全量风险。当前基于这套架构已经演进了3年+，沉淀了智能分批监控、错误码检测、跨链路检测、变更资损检测、变更窗口检测等多种防御微服务，包含6000多个防御规则，每天256万次自动化的防御风险校验，自从有了这套架构，每年变更故障下降50%左右。
通用应急定位
由于蚂蚁集团分布式系统规模庞大，一笔业务可能经过数十个系统，依赖基础设施也非常复杂，涉及相关人员很多，当出现业务失败时，如何快速定位到具体的问题节点并协调相关人员助力就成为重要命题。因此我们基于钉钉群机器人进行顶层入口信息快速汇聚（chatops），在检测故障后在钉钉群自动提示、展示故障信息、展示辅助定位信息、组织相关人员进行相应的应急处理及善后。
同时，基于云原生sidecar能力，构建了业务调用过程的根因错误、变更信息、业务信息的实时定位图数据，在故障时提供定位辅助信息，以便于相关人员快速定位问题，提升定位速度降低故障影响。另外，对于日常场景暂未出现瞬时故障的常态问题，通过对于实时定位数据的离线数据汇聚和计算，构建日常常态错误治理反馈闭环，并针对通用技术错误实现自愈处理。
智能弹性容量
经典的弹性伸缩无法满足蚂蚁的业务要求，主要原因之一经典弹性在线资源使用和利用率是无法通过简单的线性折算出来，之二是弹性伸缩变更风险高，无技术风险控制手段，特别是缩容无风控手段，异常会直接引发故障，之三是经典在线的扩缩容速度是需要十分钟以上，扩缩容无法满足快速弹性的诉求。
经过多年的摸索和落地实践，蚂蚁弹性容量基于技术风险防控体系+云原生统一资源调度+数据智能，三者组充分结合，实现在稳定性和成本优化中取最大值。基于大数据和机器学习，K8S，ServiceMesh和技术风险防控技术，建设了适合蚂蚁的全局在线资源利用率无风险精确管理和全局容量异常自适应体系。主要的核心技术有多阶段伸缩、预测式伸缩、云原生分时调度技术。
多阶段伸缩(Auto Scaling)，建设基于K8S多阶段扩容(切流，保活等)，无损渐进式缩容的HPA技术，实现循环控制业务应用日常无损弹性伸缩，目前覆盖蚂蚁95%以上应用。
预测式伸缩（Predictive Scaling)和容量异常识别和自愈(Capacity Selfcure)，利用ML技术在流量发生变化之前自动扩展计算容量，通过大数据中台和时序流量预测算法（Transformer，DeepAr）工程能力建设了一套新的预测式扩缩容技术，能够满足业务弹性，缓慢等场景，通过Burst&Baseline异常检测算法和实时计算能力，满足业务流量发生尖刺异常时自动快速恢复容量，目前已经实现70%以上的扩缩容是系统提单，大幅提升研发和SRE效率。
云原生分时调度（TimeShare）指将一份资源在不同的时间段提供给不同的应用使用，类似于潮汐车道。基于Service Mesh，ElasticHeap JVM，HPA，K8S，大数据分时画像等构建了日常分时调度技术，目前仅使用一份资源同时支持早上蚂蚁森林业务,下午基金尾盘高峰，晚上淘宝支付高峰等多个业务。