蚂蚁超大规模分布式系统稳定性体系实践

本文涉及的产品
性能测试 PTS,5000VUM额度
简介: 大规模分布式系统的稳定性建设,是确保业务服务不受硬件、人为等风险因素影响而中断的核心工作,随着业务规模增大和复杂度的提升,系统稳定性的重要程度和难度也随之增大。在蚂蚁集团业务发展过程中,业务复杂度、用户规模以及业务重要性都逐步增大,相应的稳定性建设也伴随着业务的发展进行了不断地建设和提升。

图片.png

一、前言


大规模分布式系统的稳定性建设,是确保业务服务不受硬件、人为等风险因素影响而中断的核心工作,随着业务规模增大和复杂度的提升,系统稳定性的重要程度和难度也随之增大。在蚂蚁集团业务发展过程中,业务复杂度、用户规模以及业务重要性都逐步增大,相应的稳定性建设也伴随着业务的发展进行了不断地建设和提升。


本文将从分布式系统稳定性建设发展过程出发,针对过程的关键技术和思路演进进行简单介绍。


二、发展历程


稳定性建设最终以服务业务稳定运行为最终目的,因此稳定性的建设发展也随着业务特点和规模变化而演进。

第一阶段:(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和机房容灾层面的“大问题”,已经不能满足业务的诉求,我们需要把高可用当成一个业务来做,从风险视角构建一套架构体系从根源上杜绝风险。


经过分析,我们认为高可用的风险主要分为三类:第一类,外部环境的剧烈变化,如活动带来的流量突增、机房故障等;第二类,内部节点的异常,如数据库宕机,服务器宕机等;第三类,人为变更的风险,如代码发布,配置推送等。对于这三类风险,一方面需要提升依赖研发运维人员的日常工作中进行相应的保障涉及,因此我们构建了高可用白皮书,总结了专家经验和设计案例提供给相关同学学习查阅,并进行应用和业务的高可用度量;另一方面基于业务故障指标驱动及风险影响因子分析,建设了如变更防控体系、容量风险体系、应急定位体系等风险防控体系,并引入数据智能化手段进行精细的风险识别,构建仿真环境以模拟故障及验证问题。经过多年建设,整体故障数据呈现逐年下降的趋势。


经过几代稳定性架构演进,逐步演进为当前蚂蚁应对分布式系统风险的完整体系,以下针对体系关键技术进行简单介绍。


图片.png


三、系统风险巡检


经过多年系统稳定性建设,我们发现仅仅依赖通用平台能力兜底无法解决稳定性上的全部问题,特别是精确到每一个具体的业务和应用问题时,需要研发运维工程师在设计设施过程中基于对于业务和系统的理解,在技术方案设计和实现过程针对稳定性问题进行必要的考量,利用基础设施相关技术对风险进行识别、规避和兜底,才能更好的进行稳定性方面的保障。


因此基于多年技术专家的经验沉淀,蚂蚁针对性的面对研发运维同学总结和整理了一套基于研发运维过程中的方法论指导,使得相关同学在思路和方法上有更深入的理解。同时,对于通用的设计风险,通过巡检平台和高可用度量平台对于每个业务和应用的通用风险或防御能力制定扫描规则以发现并提醒研发进行优化。


image.gif图片.png

高可用白皮书


高可用白皮书主要以研发运维过程视角进行整理,包含相应的设计思路、技术方案、基础平台使用和经典案例总结。

设计&编码

可观察设计:系统设计过程需考虑可观察能力,包括必备的日志、监控配置,以便及时发现问题。

冗余防御:鉴于服务、硬件的不稳定,对于依赖的系统和硬件需要进行必要的防御编程。包含分布式冗余,依赖异常的捕获和降级处置。

容量性能:能够达到业务需要的伸缩能力,尽可能提升性能降低耗时,避免无效依赖。

变更灰度:代码设计具备变更灰度的能力,根据不同业务和需求设计不同等级的灰度方案,包含兼容性考虑,用户级别灰度、流量级别灰度等能力,具备回滚能力。

压测演练能力:系统具备支持压测、演练的能力,包含压测数据构造、压测隔离能力等建设。

发布&变更

变更三板斧标准:任何变更需要满足可监控、可灰度、可回滚方案设计,变更过程能够发现问题、灰度降低影响面、能够快速回滚止血。

变更防御接入:变更接入通用的变更防御体系,以复用通用的防御能力。

线上运维

应急自愈:配置合理监控报警,报警及时处理,指定合理的值班安排,配合全局业务应急处理,必要的通过自愈建设提升处理效率。

容量保障:提前评估业务量级和容量风险,定期监控容量水位,进行定期压测验证,配置合理的限流保护。

预案演练:应急预案进行定期演练,定期进行容灾能力演练。


高可用度量及巡检


基于高可用白皮书沉淀的专家经验,部分规则转换为高可用风险点,通过构建应用和业务巡检能力对系统进行巡检扫描,最终在根据风险级别、应用级别产出高可用度量分。研发运维工程师根据对应的优化建议,参考高可用白皮书即可进行相应的优化处置。目前我们构建了高可用度量和巡检产品,通过应用运行数据采集和巡检规则沉淀实现风险扫描和披露,当前已经沉淀1.3万个风险巡检规则,每天运行1000多万次系统扫描。


image.gif图片.png


四、稳定性解决方案


在解决分布式系统扩展性、性能、容灾等稳定性问题过程,基础设施结合业务同学通过技术建设和创新,提供了一系列的稳定性技术方案,以下针对过程中部分技术方案进行简单介绍。


异地多活部署架构


LDC(Logical Data Center)作为蚂蚁核心的部署架构,主要解决机房扩展性、机房容灾以及大促机房快速弹性问题,当前已服务了蚂蚁业务多年,支撑了多年大促峰值挑战。


LDC架构将系统集群按照用户id为维度,创建多个逻辑单元,每个逻辑单元承载指定用户范围的流量,同时系统数据也按照相同的范围将数据库部署到对应的逻辑单元中,这样每个逻辑单元形成一个可以独立运行的最小规模。随后运维工程师将每个逻辑单元可以独立部署到任意物理机房,甚至是异地机房,当机房需要扩展或迁移时,只需要将对应的逻辑单元进行拆分或迁移即可,以此实现蚂蚁异地多活架构部署体系。


为了解决机房故障的快速恢复问题,基于该体系提供了灵活的流量调度能力,蚂蚁构建了应对单机房故障的同城、异地容灾能力。即针对每个逻辑单元设置一个对应的同城灾备单元和一个异地的灾备单元,当某个逻辑单元对应的机房故障时,通过调度将流量调整到其他逻辑单元以临时提供服务。这个过程关键挑战是应用是无状态的能够提供无差别服务,但数据灾备恢复难度较大,这就依托与OceanBase的多节点一致性能力来实现数据的秒级灾备切换。


另外,双十一、新春红包大促等活动,峰值远大于日常容量要求,如果日常即准备满足大促的容量则会带来大量的资源浪费,同样基于ldc的流量调度能力,构建了机房级别的弹性能力,能够在大促前将流量弹回到新的机房,而在大促结束后快速回收该机房。

image.gif

图片.png


精细化流量调度


支付业务对稳定性要求较高,在针对该业务保障过程,为提升支付相应效率、提升服务间调用稳定、降低资源消耗,进行了合并部署技术的探索和实施。合并部署技术将相关性较高的上下游多个应用通过容器技术部署到一台物理机,针对同一台物理机优先服务路由来降低网络带来的延迟消耗,在此基础上,进一步通过进程间通信技术降低服务延迟、通过容器资源超卖来提升资源利用率。通过合并部署技术在当年双十一大促活动中整体支付耗时从198ms下降到111ms,下降43%,整体节约成本800多台虚拟机。


另外,由于蚂蚁业务复杂度高,对于底层系统可能同时承载高等级和低等级的不同业务,而不同级别业务也会相互影响,而采用合并部署模式会带来额外的复杂度,因此基于云原生的容器技术和mosn路由调度技术,实现了轻量的路由模式,针对流量进行亲和路由,将高等级和低等级业务流量进行虚拟的隔离。

图片.png

其他技术


在整个发展历程中,还诞生了诸多为了提升稳定性的技术能力,例如业务方面的支付异步化、防抖设计,基础设施的分布式事务解决方案、分布式定时调度、一致性消息等技术,这里不逐一罗列。当前LDC、流量调度等技术解决方案也在筹备通过开源等方式进行开放共享。


五、平台风险产品体系


蚂蚁技术风险基于故障驱动,构建了一系列风险防御体系,过程中针对复杂的业务和应用,通过采用数据化和智能化手段提升风险防御的全面性和准确性。如下针对部分能力介绍。


智能变更防御


我们发现60%以上的故障都是人为变更导致的,而仅靠研发人员自身能力和意识来避免故障产生还是容易产生遗漏,因此我们决定构建变更核心系统,将变更作为一项重要的业务来进行系统化构建。变更系统构建变更防御切面,针对全部变更执行过程对接变更统一决策,实现系统化的三板斧(可监控/可灰度/可回滚)要求。变更核心架构上定义了统一的标准变更三元组(变更情景、变更动作、变更对象),并针对每次变更构建智能化的防控微服务来检测全量风险。当前基于这套架构已经演进了3年+,沉淀了智能分批监控、错误码检测、跨链路检测、变更资损检测、变更窗口检测等多种防御微服务,包含6000多个防御规则,每天256万次自动化的防御风险校验,自从有了这套架构,每年变更故障下降50%左右。


图片.pngimage.gif


通用应急定位


由于蚂蚁集团分布式系统规模庞大,一笔业务可能经过数十个系统,依赖基础设施也非常复杂,涉及相关人员很多,当出现业务失败时,如何快速定位到具体的问题节点并协调相关人员助力就成为重要命题。因此我们基于钉钉群机器人进行顶层入口信息快速汇聚(chatops),在检测故障后在钉钉群自动提示、展示故障信息、展示辅助定位信息、组织相关人员进行相应的应急处理及善后。


图片.png


同时,基于云原生sidecar能力,构建了业务调用过程的根因错误、变更信息、业务信息的实时定位图数据,在故障时提供定位辅助信息,以便于相关人员快速定位问题,提升定位速度降低故障影响。另外,对于日常场景暂未出现瞬时故障的常态问题,通过对于实时定位数据的离线数据汇聚和计算,构建日常常态错误治理反馈闭环,并针对通用技术错误实现自愈处理。


图片.png


智能弹性容量


经典的弹性伸缩无法满足蚂蚁的业务要求,主要原因之一经典弹性在线资源使用和利用率是无法通过简单的线性折算出来,之二是弹性伸缩变更风险高,无技术风险控制手段,特别是缩容无风控手段,异常会直接引发故障,之三是经典在线的扩缩容速度是需要十分钟以上,扩缩容无法满足快速弹性的诉求。


经过多年的摸索和落地实践,蚂蚁弹性容量基于技术风险防控体系+云原生统一资源调度+数据智能,三者组充分结合,实现在稳定性和成本优化中取最大值。基于大数据和机器学习,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,大数据分时画像等构建了日常分时调度技术,目前仅使用一份资源同时支持早上蚂蚁森林业务,下午基金尾盘高峰,晚上淘宝支付高峰等多个业务。


图片.png

结语


随着企业数字化的进程的加速,越来越多的企业都需要践行“稳定性优先战略”,蚂蚁集团在稳定性建设领域多年成熟经验实践,正在积极和行业生态伙伴、中国信通院等组织推进行业标准建设,本文中涉及的各项核心技术会通过开源的方式贡献给社区,同时,蚂蚁集团正在逐步构建商业化的技术风险产品矩阵TRaaS(Technological Risk-defense as a Service),把蚂蚁沉淀十多年的分布式架构和平台技术升级、优化为更加成熟、智能的技术产品,赋能用户实现主动的风险发现和自我恢复的能力,助力业务高质量增长。

相关实践学习
通过性能测试PTS对云服务器ECS进行规格选择与性能压测
本文为您介绍如何利用性能测试PTS对云服务器ECS进行规格选择与性能压测。
相关文章
|
2天前
|
运维 Kubernetes 调度
阿里云容器服务 ACK One 分布式云容器企业落地实践
阿里云容器服务ACK提供强大的产品能力,支持弹性、调度、可观测、成本治理和安全合规。针对拥有IDC或三方资源的企业,ACK One分布式云容器平台能够有效解决资源管理、多云多集群管理及边缘计算等挑战,实现云上云下统一管理,提升业务效率与稳定性。
|
9天前
|
机器学习/深度学习 存储 运维
分布式机器学习系统:设计原理、优化策略与实践经验
本文详细探讨了分布式机器学习系统的发展现状与挑战,重点分析了数据并行、模型并行等核心训练范式,以及参数服务器、优化器等关键组件的设计与实现。文章还深入讨论了混合精度训练、梯度累积、ZeRO优化器等高级特性,旨在提供一套全面的技术解决方案,以应对超大规模模型训练中的计算、存储及通信挑战。
33 4
|
12天前
|
NoSQL Java 数据处理
基于Redis海量数据场景分布式ID架构实践
【11月更文挑战第30天】在现代分布式系统中,生成全局唯一的ID是一个常见且重要的需求。在微服务架构中,各个服务可能需要生成唯一标识符,如用户ID、订单ID等。传统的自增ID已经无法满足在集群环境下保持唯一性的要求,而分布式ID解决方案能够确保即使在多个实例间也能生成全局唯一的标识符。本文将深入探讨如何利用Redis实现分布式ID生成,并通过Java语言展示多个示例,同时分析每个实践方案的优缺点。
27 8
|
3月前
|
运维 Kubernetes 调度
阿里云容器服务 ACK One 分布式云容器企业落地实践
3年前的云栖大会,我们发布分布式云容器平台ACK One,随着3年的发展,很高兴看到ACK One在混合云,分布式云领域帮助到越来越多的客户,今天给大家汇报下ACK One 3年来的发展演进,以及如何帮助客户解决分布式领域多云多集群管理的挑战。
阿里云容器服务 ACK One 分布式云容器企业落地实践
|
4月前
|
存储 分布式计算 Hadoop
【揭秘Hadoop背后的秘密!】HDFS读写流程大曝光:从理论到实践,带你深入了解Hadoop分布式文件系统!
【8月更文挑战第24天】Hadoop分布式文件系统(HDFS)是Hadoop生态系统的关键组件,专为大规模数据集提供高效率存储及访问。本文深入解析HDFS数据读写流程并附带示例代码。HDFS采用NameNode和DataNode架构,前者负责元数据管理,后者承担数据块存储任务。文章通过Java示例演示了如何利用Hadoop API实现数据的写入与读取,有助于理解HDFS的工作原理及其在大数据处理中的应用价值。
114 1
|
4月前
|
机器学习/深度学习 人工智能 负载均衡
【AI大模型】分布式训练:深入探索与实践优化
在人工智能的浩瀚宇宙中,AI大模型以其惊人的性能和广泛的应用前景,正引领着技术创新的浪潮。然而,随着模型参数的指数级增长,传统的单机训练方式已难以满足需求。分布式训练作为应对这一挑战的关键技术,正逐渐成为AI研发中的标配。
209 5
|
4月前
|
存储 Kubernetes 监控
深入浅出分布式事务:理论与实践
在数字化时代的浪潮中,分布式系统如同星辰大海般浩瀚而深邃。本文将带你航行于这片星辰大海,探索分布式事务的奥秘。我们将从事务的基本概念出发,逐步深入到分布式事务的核心机制,最后通过一个实战案例,让你亲自体验分布式事务的魅力。让我们一起揭开分布式事务的神秘面纱,领略其背后的科学与艺术。
94 1
|
4月前
|
Go API 数据库
[go 面试] 分布式事务框架选择与实践
[go 面试] 分布式事务框架选择与实践
|
4月前
|
UED 存储 数据管理
深度解析 Uno Platform 离线状态处理技巧:从网络检测到本地存储同步,全方位提升跨平台应用在无网环境下的用户体验与数据管理策略
【8月更文挑战第31天】处理离线状态下的用户体验是现代应用开发的关键。本文通过在线笔记应用案例,介绍如何使用 Uno Platform 优雅地应对离线状态。首先,利用 `NetworkInformation` 类检测网络状态;其次,使用 SQLite 实现离线存储;然后,在网络恢复时同步数据;最后,通过 UI 反馈提升用户体验。
105 0
|
4月前
|
机器学习/深度学习 TensorFlow 数据处理
分布式训练在TensorFlow中的全面应用指南:掌握多机多卡配置与实践技巧,让大规模数据集训练变得轻而易举,大幅提升模型训练效率与性能
【8月更文挑战第31天】本文详细介绍了如何在Tensorflow中实现多机多卡的分布式训练,涵盖环境配置、模型定义、数据处理及训练执行等关键环节。通过具体示例代码,展示了使用`MultiWorkerMirroredStrategy`进行分布式训练的过程,帮助读者更好地应对大规模数据集与复杂模型带来的挑战,提升训练效率。
96 0