4月27日，首届“全球信息系统稳定性峰会”在北京召开。会上，中国信息通信研究院（以下简称“中国信通院”） 公布了首批信息系统稳定性保障能力评估结果、分布式系统稳定性实验室成员单位、信息系统平稳运行优秀案例。蚂蚁集团当选为实验室成员单位，其支付平台凭借在系统稳定和安全等方面的技术与实践，获得“系统平稳运行优秀案例”颁证。
作为实验室成员单位，蚂蚁集团积极参与编写了系统稳定性相关的标准及研究报告，此次峰会上，蚂蚁集团数字科技事业群技术副总经理石世群也做了《支付宝系统双十一稳定性保障经验分享》的主题演讲，分享蚂蚁集团金融级分布式架构SOFAStack在系统稳定性保障领域的探索和实践经验。
以下为演讲整理全文：
大家好，我是蚂蚁集团数字科技的石世群。今天我将在线介绍支付宝双11稳定性保障的相关内容。
系统的稳定性保障，是一个复杂的系统工程。从2004年到2021年，支付宝经历了一系列的技术架构升级和迭代，从单元化架构走向弹性上云，进而演化到云原生、绿色计算，这个过程既要考虑容量稳定性，也要考虑成本和效率。
我们做了简单的总结，大概经历三个阶段：
第一阶段，主要解决容量的问题。通过LDC、弹性能力和OceanBase，解决了容量理论上无限伸缩的能力。同时，通过全链路压测技术很好的对全链路容量进行验证；第二阶段，当支付的容量能力达标后，进一步考虑的就是如何通过技术创新去提升整体架构的稳定和效率。典型的场景有2个，一个是云原生，云原生架构的核心理念是将基础设施和业务进行剥离，从而释放基础设施的红利，大幅提升创新速度和效率，比较典型的案例就是ServiceMesh在蚂蚁的落地。另一个就是我们对于智能监控运维体系，通过数据智能的方式，提升系统应急响应恢复的反应速度。第三阶段，绿色减排。连续几年，我们在保持峰值稳步增长的情况下，提出了大促0成本新增。2021年双11，我们的主要方向就聚焦在绿色减排上，通过离在线混部、分时调度、智能AI容量等创新技术，实现节约64万度电和394吨碳减排。接下来，我给大家介绍一下支付宝双11大促的关键技术。
单元化部署异地多活逻辑单元架构，蚂蚁内部也叫LDC，全称是Logical Data Center（逻辑数据中心），是对IDC（Internet Data Center，互联网数据中心）的一种逻辑划分，也是支付宝系统实践“单元化部署”所采用的方案。
保障信息系统的稳定性，核心要解决两方面问题：
第一个，单点瓶颈。任何一个互联网系统发展到一定规模时，都会不可避免地触及到单点瓶颈。从单服务器、单应用，到单数据库、单机房，进而到多机房部署、多地部署（异地多活），这个过程就是在不断突破单点瓶颈；
第二个，保障异地容灾能力，这样才能满足金融级稳定性要求。
多地多机房部署，是互联网系统发展的必然方向， 这里面要解决很多关键问题，包括流量调配、数据拆分、延时等，当然这些问题都可以通过技术和方案来解决，而承载这些方案的是一个部署架构。尽管可采用的部署方案不止一个，但无论是纯理论研究，还是一些先行系统的架构实践，都把“单元化部署”列为最佳方案。
所谓单元，是指一个能完成所有业务操作的自包含集合，在这个集合中包含了所有业务所需的所有服务，以及分配给这个单元的数据。一个单元，是一个五脏俱全的缩小版整站，它是全能的，因为部署了所有应用；但它不是全量的，因为只能操作一部分数据。
支付宝内部通过将单元分成RZone、GZone、CZone三类，来解决流量调配、数据拆分、延时的问题：
RZone（Region Zone）：最符合理论上单元定义的zone，每个RZone都是自包含的，拥有自己的数据，能完成所有业务。GZone（Global Zone）：全局单元，部署了不可拆分的数据和服务，这些数据或服务可能会被RZone依赖。GZone在全局只有一组，数据仅有一份。CZone（City Zone）：以城市为单位部署的单元，同样部署了不可拆分的数据和服务，也会被RZone依赖。但跟GZone不同的是，CZone中的数据或服务会被RZone频繁访问，每一笔业务至少会访问一次；而GZone被RZone访问的频率则低的多。CZone是为了解决异地延迟问题而特别设计的。基于LDC架构，支付宝实现了真正的异地多活架构，实现了金融级99.99%可用性，以及理论上的无线容量能力，顺利支撑了大促数十万级的能力，同时也为后续的弹性架构奠定了很好的基础。
弹性架构刚才我们讲到了LDC逻辑单元架构，它是理论上具备了无限容量的可能性，但是现实往往是不太可行的，有以下两个方面的原因：
一方面，公司内部自己掌控的资源是有限的，随着支付笔数的快速增长，自持的资源会遇到瓶颈；另一方面，双11大促毕竟是少数时候，如果长时间拥有这么多资源，对于成本来讲也是不经济的，这并没有充分释放云计算的红利。
蚂蚁支付宝在LDC架构的基础上，进一步升级了弹性架构，实现了按照业务粒度的弹性能力，把一部分单元转变成弹性单元，在高峰期时弹到云上去，从而实现快速扩容能力。当大促结束时，再把这些单元弹回到日常机房，这样就可以保障资源的更有效利用。所有的弹性逻辑都是在基础设施层面全部做了封装，对业务实现了无感的弹性。我们在2016年双11大促，有效支撑了每秒十几万级支付峰值，跟自己持有资源的模式相比，成本实现大幅度降低50%以上。
服务网格接下来看服务网格ServiceMesh，这也是非常关键的一个技术。
为什么需要ServiceMesh？还得从微服务讲起。微服务存在的问题，很多跟服务治理相关，包括组件之间相互依赖、服务管控难、平台运管等问题，我们通过轻量级网络代理，负责微服务间的通讯等工作，以sidecar形式部署在容器的独立进程中，并通过一系列的基础设施和业务解耦，高效实现了基础设施的升级。在大促期间，基础设施的迭代提效10倍以上。
其次，通过ServiceMesh可以实现灵活流量控制，所有的限流、熔断由ServiceMesh接管，不需要业务改造，节约了大量的预案研发成本和SDK的接入成本。目前ServiceMesh已经覆盖了支付宝100%核心支付链路，具有百万级别的容器规模，峰值千万QPS。
线上全链路压测技术的演进压测是极其重要的容量验证手段，我们刚才讲到的所有方法，都是不断在提升容量扩展的能力。但是也非常需要一个非常好的手段去验证容量是否符合预期，线上的全链路压测技术就变得非常关键。
传统的压测技术有很多问题，主要体现在传统的局部单链路压测不完整，它是以单业务压测为主，数据库层面不好压测，网络层面也不好压，无法有效模拟真实业务的情况。此外，传统线下压测、仿真压测、线上单机引流压测的准确度不高，也没有准确评估资源情况。
对于整个线上全链路压测来说，我们主要有以下几个要点：
核心链路分析，建立用户端到端的行为模型。通过大数据技术，基于大促的用户行为和后端链路，构建端到端的流量模型，用来验证全链路压测的充分度压测环境复用生产。通过数据访问代理，把压测数据导到链路上去，不影响正常业务数据，结果是很可靠的。压测性能分析诊断。压测过程中，如果遇到问题，可以快速定位问题，并诊断给出优化建议。典型的包括网络诊断（网络质量、带宽）、应用诊断（内存、CPU热点、线程）、数据库诊断（慢SQL、CPU、内存）、基础设施（容器、进程）以及全链路诊断（诊断 分布式链路中的瓶颈点）。基于过去这么多年的积累，我们在全链路压测上的仿真度超过了99%，最近几年的双11大促都是0 重大故障，0资损。智能监控技术尽管前面做了很多事情，但是对于一个复杂的业务来讲，线上系统不可避免会出现问题，所以怎么快速发现问题、快速应急、快速恢复起来就变得非常重要。
面对大促峰值的情况下，监控碰到的挑战也是巨大的。在大促日志规模流量下，每秒日志量可能达到几百G，清洗流量可能每分钟达到几十个T，怎样有效处理这些日志非常关键。
蚂蚁自研的时序数据库引擎Ceresdb，通过优化采集技术和流式计算引擎，可以基本做到秒级监控，实现1分钟发现、5分钟定位、10分钟恢复，确保线上时间的快速应急和响应。
1分钟发现：故障在1分钟内被发现，干系人被引入故障处置流程。5分钟定位：在5分钟内响应故障出现原因，并制定止血方案。10分钟恢复：10分钟执行完毕止血方案，故障恢复。2021双11节能减排2021年双11，我们从关注峰值、关注流量，重点转向了绿色计算，既考虑成本也考虑效率，确保技术可持续性。我们通过一系列包括在离线混合部署技术、云原生分时调度和 AI弹性容量等创新技术手段，实现了整体资源各种调度，规模化应用绿色计算，节约了64万度电，碳减排394吨。
前面讲了很多保障系统稳定性的技术能力和方法，但对于每个组织来说，从头打造这些能力和体系，需要花费很长的周期，也需要做很多复杂的工作，为了更好帮助各行各业实现数字化升级和转型，蚂蚁集团也在积极大力推动相关能力的科技开放。
原生分布式数据库OceanBase接下来，我们来看一个重要的产品——OceanBase。OceanBase内部经过9年双11的验证，有非常多应用经验，也很成熟稳定。OceanBase作为原生分布式数据库，具有无线扩展、永远在线的能力，保障数据不丢失，30秒内实现自动容灾恢复。OceanBase适用于各种大型场景以及对业务连续性要求高的行业，对于强一致性、高可用、高HTAP性能要求的行业也非常适用，目前在金融、政府、运营商、交通、能源等行业已经有很多成功实施的经验。
金融级分布式架构SOFAStack同时，我们也对外开放了SOFAStack云原生科技产品，把单元化架构、服务网格Service Mesh、全链路压测、监控应急体系通通打包在一起，将蚂蚁十多年技术能力经过产品化，实现成为成熟的商业化产品和服务。目前已经服务几百家客户的核心业务系统，我们希望通过这些努力，能够帮助各行各业更好实现数字化升级和转型。
今天我就分享到这里，感谢大家！