首席架构师揭秘蚂蚁金服互联网IT运维体系实践

简介:

0?wx_fmt=jpeg

 ◆ 

导 读


本文来自蚂蚁金服首席技术架构师,基础技术部负责人胡喜。从2010年支撑双十一最高交易峰值2万笔/分钟到2015年双十一的8.59万笔/秒,蚂蚁金服的技术架构和运维体系一直都在不断摸索和实践。本文就“互联网IT运维体系”这一主题,和朋友们分享蚂蚁金服在该领域的实践经验。


从2010年支撑双十一最高交易峰值2万笔/分钟到2015年双十一的8.59万笔/秒,蚂蚁金服在技术架构和运维体系方面不断摸索实践所取得的成果。在这个过程中,以持续技术演进和创新来支撑互联网金融业务的飞速发展,服务互联网金融生态伙伴,助力更多中小型金融机构成功向新金融转型发展和创新,是蚂蚁金服在技术持续发展道路上所坚持的愿景。 


蚂蚁金服长期致力于技术运维体系建设,有效保障历年双11的平稳运行,在大促当天业务量年年翻倍的基础上,持续保持系统可靠安全、无资金差错和顺畅的用户体验。兹通过本文就“互联网IT运维体系”这一主题,和各位致力于金融业IT信息化建设的同行朋友们分享蚂蚁金服在该领域的一些实践经验,以抛砖引玉互通有无。


 ◆ 

蚂蚁金服整体运维体系构成


蚂蚁金服的运维体系由三个主要版块构成:运维架构、运维平台、组织机制 。如下图所示:
0?wx_fmt=jpeg

通过一系列相互支持的分层元素的有机结合,形成一个完整的运维体系,来保障互联网金融业务的连续性。


(1)运维架构:奠定了架构基础,作用于IaaS层,目的在于通过一定的架构设计,使得基础设施能够达到高扩展性和具备快速容灾的能力;目前蚂蚁金服整体运维架构,采用的是自研的“异地多活架构”,与传统的“两地三中心”部署架构有所不同。


(2)运维平台:是互联网金融运维的重点设施。为了具备高效、安全、智能的系统运维能力,提高运维效率和保障系统稳定,蚂蚁金服基于运维平台化、数据化的设计理念,集合大数据计算和云计算的能力,形成了可控的金融级运维能力。其中包括金融安全风险控制能力、金融级业务连续性自动化保障能力等,并整体上形成了蚂蚁金融云PaaS解决方案。


(3)组织机制:作为运维体系的重要组成,组织机制保障了在运维过程中能够充分发挥运维架构和运维平台的强大合成能力,达成系统持续可用的最佳状态。

下面将结合双11大促的具体应用场景从三方面进行介绍:


  1. “异地多活”的运维架构

  2.   金融级业务连续性与自动化保障

  3.   业务连续性能力的组织机制保障    


 ◆ 

“异地多活”的运维架构


蚂蚁金服的运维架构定义了基础设施和应用系统等在IDC上的部署架构。随着蚂蚁金服业务的快速发展,传统以IDC为基础运维单元的“两地三中心”运维架构已经很难满足需求。当前蚂蚁金服已经演化形成“异地多活”的运维架构,以单元化机房(后面简称为LDC)为基础运维单元,以满足快速发展的互联网金融业务对基础设施扩展和容灾的高时效性、金融级安全性要求。


传统运维架构的部署模式,主要面临以下三个问题:


1、基于IDC的运维部署管理模式,在系统规模越来越大、复杂度越来越高的情况下,无论是网络、DB还是应用层面,其伸缩性能力无法持续提升,很难匹配各个层面的容量增长,将无法满足业务快速发展的要求。


如:“在应用服务器完成扩容之后,发现DB连接数和事务数又成为了瓶颈;等DB完成扩容,又发现网络带宽已经不够,需要对网络带宽进行扩容”;“当应用扩展到一定程度,DB的连接数成为突出瓶颈,对于传统的所有应用连接到一个DB分库上的架构部署模式,这个问题十分棘手”以上所面临的挑战,推进蚂蚁金服的运维架构向可按更小单元维度扩展的更优可伸缩方案演化。


2、对单元进行标准化建设的过程,即是对整体运维架构进行标准化的过程。单元标准化,需要保障每个单元的内部设施必须完全一致,标准化、可管理、可复制,而如何屏蔽各个IDC自身的基础设施差异性,是其中的一大挑战,这对整体运维管理提出了更高的要求。


3、传统IDC架构只能实现“两地三中心”的容灾架构,该架构模式下,异地容灾系统一般是“冷”的,其备份系统的功能完备性和切换时长均很难保障和控制,投入了大量建设成本,但可能会陷入“有而不敢用”的怪圈。在飞速发展的互联网金融应用场景下,要求运维架构上突破“两地三中心”的传统模式,向N+1“多活”的灾备方案演进,进一步提升故障恢复的体系性能力。


针对以上挑战和需求,蚂蚁金服提出了“LDC”架构,其核心思想是:把数据水平拆分的思路,向上提升到接入层、终端层,从接入层开始,把原来部署在一个IDC中的系统集群,进一步分成多个更细粒度的部署单元。该部署单元有以下三个特性:


1. 每个单元对外是封闭的,在一个单元内的系统调用链路和各类存储访问是局部化在本单元内的;


2. 每个单元的实时数据是独立不共享的;会员或配置类信息等对延时性要求不高的数据全局共享;


3. 单元间的通信统一管控,尽量以异步化消息进行通信;同步调用则通过单元间代理方案实现。


该架构解决了以下四个关键问题:


1. 由于尽量减少了跨单元交互和使用异步化,使得异地部署成为可能。整个系统的水平可伸缩性大大提高,不再依赖同城IDC;


2. 可以实现N+1的异地灾备策略,大大缩减灾备成本,同时确保灾备设施真实可用;


3. 整个系统已无单点存在,大大提升了整体的高可用性;同城和异地部署的多个单元可用作互备的容灾设施,通过运维管控平台进行快速切换,有机会实现100%的持续可用率;


4. 该架构下业务级别的流量入口和出口形成了统一的可管控、可路由的控制点,整体系统的可管控能力得到很大提升。基于该架构,线上压测、流量管控、灰度发布等以前难以实现的运维管控模式,现在能够十分轻松地实现。


2013年蚂蚁金服完成了同城LDC的落地,并顺利通过了2013年大促的考验。2015年在同城LDC架构的基础上,进一步升级完成“异地多活架构”并成功支撑了2015年大促的全天平稳运行。


“异地多活架构”是指基于LDC的扩展能力,在不同地域的IDC中部署LDC单元,并且每个LDC单元都是“活”的,是真正承接线上真实业务流量的,在发生故障时,可以进行LDC单元之间的快速切换。


这比传统的“两地三中心”架构有更好的业务连续性保障。“异地多活架构”下,一个LDC对应的灾备LDC是一个“活”的LDC,日常就在承接真实业务流量,其稳定性和业务的正确性是一直被确保的。


以下是蚂蚁金服“异地多活架构”示意图:


0?wx_fmt=png


除了具备更快速的故障应急隔离和恢复能力之外,基于LDC架构,蚂蚁金服还具备了“蓝绿发布”和“灰度发布”的可靠变更验证能力。在单个LDC单元内部,又分成A /B两个逻辑组,A/ B组部署的系统链路是完全相同的。日常情况下,调用请求按照对等概率随机路由到A组或B组 。当开启蓝绿发布模式时,上层路由组件会调整路由计算策略,隔离A组与B组之间的调用,A组内应用访问封闭在A组内,而不会去访问B组。


以上粗略概况介绍了蚂蚁金服的底层运维架构,对应于IaaS层次,重点阐述了从传统IDC部署架构模式到基于LDC的“异地多活”架构的升级演进。下面将基于运维架构,介绍运维平台的部分,即金融云PaaS层次。

  

 ◆ 

金融级业务连续性与自动化保障


在2015年双十一当天,蚂蚁金服的支付峰值达到8.59万笔/秒,其中业务上关于支付工具和支付场景的规则达数百种,涉及的安全规则达上万种。不难想象,为了支持这些业务规模,需要管控的运维设备规模和程序代码变更频次的规模将是十分巨大的。(蚂蚁金服的十几个业务部门共计数百个业务,每周发一个版本,双11大促准备期间的频率更高)。


按照传统的方式很难高效、高质量地管理规模如此庞大的复杂系统,解决方案便是通过运维平台的建设,通过提供更高效、更安全、更智能的运维能力赋能于运维工作,从而支撑业务的快速稳定发展。


1. 高效 : 通过运维工作的平台化来提高运维效率。如系统监控平台、变更管控平台、动态资源管控平台、调度中心、注册中心等。


2. 安全: 基于自动业务验证平台和大数据运算规则,保障系统运行的稳定性与正确性。如数据核对中心、依赖管控平台、容量检测管控平台等。


3. 智能:基于大数据的分析和规则计算,进行智能化的运维管控。如自动故障分析处理系统、容量自动探测扩容系统等。


下面通过大促中的2个场景,也是日常运维过程中常见的两个场景(集群容量管理和故障应急处理),来整体介绍运维平台这三个特性的具体体现。


场景一(自动化容量管理):通过自动化的全链路压测、自动化的容量模型计算、自动化链路收集、自动化的扩容来实现日常的系统容量管理。


大致的步骤如下:


(1) 首先,通过“全业务路径压测”的方式,探测系统的容量瓶颈点。基于 LDC架构,在全链路压测之前,为每个LDC单元创建“影子LDC”,其数据与提供线上服务的LDC单元天然隔离,但充分利用了真实服务器集群的容量能力,可以有效的对线上实际容量进行探测验证。


(2) 通过基于大数据分析的监控系统,动态收集系统的运行时性能指标。


(3) 根据业务链路和容量模型,进行容量的瓶颈点分析。


(4) 弹性伸缩,进行扩容/缩容:对于内部系统,会计算出最后实际需要扩容的容量,通过PaaS平台,一键进入扩容流程,经过审核后,自动进行系统弹性扩容。如果是合作伙伴的瓶颈,会进行流量控制,并且通知合作伙伴扩容。


在本场景中,通过应用大数据和智能决策技术,能够高效、安全完成弹性容量管理工作,实现精益化运维。


场景二(自动故障处理):当故障发生时,监控系统通过对系统指标的监控,判定出受影响的业务和相关系统链路;通过大数据计算找到故障根因;结合变更和应急预案,直接提示应急方案,直至最后联动到应急平台,自动执行应急预案。


大致步骤如下:


(1)通过业务指标监控,快速发现有错误的业务;


(2)根据各个维度指标的计算,判定业务SLA的损失量是否达到需要启动应急预案的级别;


(3)根据业务管控策略配置,自动通知(旺旺、短信、电话等方式)相关人员上线进行应急处理;


(4)运维平台根据业务链路上系统依赖情况的梳理,绘制系统依赖图;根据系统链路图、错误数据、系统响应时间等数据,智能判断出错误源头,并根据变更管控信息,判断是否由于变更操作(线上发布、数据变更、网络变更、动态开关推送等)引起;


(5)根据变更信息和故障设备的应急策略,智能决策应急方案,发起人工介入审核应急处理流程,或者自动启动应急预案处理故障。


通过运维平台的建设,能够高效、高质量地完成复杂的应急工作,并为知识积累提供载体,使运维质量和效率不再依赖于个人的经验和智慧,使所有运维人员都可以胜任高效的日常运维。


 ◆ 

业务连续性能力的组织机制保障


在组织机制保障,蚂蚁金服构建了三道信息科技风险管理防线。

0?wx_fmt=jpeg

除此之外,蚂蚁金服还根据互联网金融的人员、组织特征,构建了多层次的组织机制保障体系,以保障整体架构规划实施、制度规范能够很好地在一线团队落地,保障从规划到执行的高质量落地;并且一线团队的实际问题可以反馈到上层架构组织和管理层,反作用于运维架构和运维平台的持续优化发展,进一步推进系统架构和运维水平向更高级别演进发展。

  

 ◆ 

未来是云时代


随着业务和运维架构平台的不断发展,除了本身平台能力朝着更高效、更安全、更智能方向提升之外,还尝试把运维平台和人员组织进行“云”化,能够快速支持蚂蚁金服集团内部业务发展,为业务团队快速具备DevOps运维能力赋能。


蚂蚁金服在精粹提炼多年技术沉淀的过程中,研发了“蚂蚁金融云”技术平台。该平台深度浓缩了蚂蚁金服对未来金融系统IT运维发展方向的沉淀总结。整个平台体系从应用运行时、弹性服务、基础服务、交付管理等几个方面,对整体从研发到运维的技术平台进行整合。


该平台不仅为研发人员提供了一套标准研发模型,也为运维人员提供了一套标准运维模型,这套基于金融云技术的体系,使得架构更替对研发人员更透明,也屏蔽了很多技术复杂性,让整体架构更容易管控和进行可靠运维,大大提高了对创新业务的快速支撑能力。


这一技术平台的强大支撑,在蚂蚁的理财业务、保险业务、芝麻信用、网商银行等多个创新区域得到了验证。通过基于“蚂蚁金融云”的运维体系,帮助我们在快速创新的过程中不断降低成本。随着蚂蚁金服“互联网推进器”计划的推出和实施,蚂蚁金服希望在5年内助力1000家中小型金融机构向新金融转型升级。


互联网金融IT系统的运维建设之路,后续期待和各位同行更多的交流和一起大力推进发展。


原文发布时间为:2016-08-25

本文来自云栖社区合作伙伴“大数据文摘”,了解相关信息可以关注“BigDataDigest”微信公众号

相关实践学习
简单用户画像分析
本场景主要介绍基于海量日志数据进行简单用户画像分析为背景,如何通过使用DataWorks完成数据采集 、加工数据、配置数据质量监控和数据可视化展现等任务。
SaaS 模式云数据仓库必修课
本课程由阿里云开发者社区和阿里云大数据团队共同出品,是SaaS模式云原生数据仓库领导者MaxCompute核心课程。本课程由阿里云资深产品和技术专家们从概念到方法,从场景到实践,体系化的将阿里巴巴飞天大数据平台10多年的经过验证的方法与实践深入浅出的讲给开发者们。帮助大数据开发者快速了解并掌握SaaS模式的云原生的数据仓库,助力开发者学习了解先进的技术栈,并能在实际业务中敏捷的进行大数据分析,赋能企业业务。 通过本课程可以了解SaaS模式云原生数据仓库领导者MaxCompute核心功能及典型适用场景,可应用MaxCompute实现数仓搭建,快速进行大数据分析。适合大数据工程师、大数据分析师 大量数据需要处理、存储和管理,需要搭建数据仓库?学它! 没有足够人员和经验来运维大数据平台,不想自建IDC买机器,需要免运维的大数据平台?会SQL就等于会大数据?学它! 想知道大数据用得对不对,想用更少的钱得到持续演进的数仓能力?获得极致弹性的计算资源和更好的性能,以及持续保护数据安全的生产环境?学它! 想要获得灵活的分析能力,快速洞察数据规律特征?想要兼得数据湖的灵活性与数据仓库的成长性?学它! 出品人:阿里云大数据产品及研发团队专家 产品 MaxCompute 官网 https://www.aliyun.com/product/odps 
相关文章
|
14天前
|
存储 自然语言处理 前端开发
软考实践之分层架构思想的理论和应用实践
软考实践之分层架构思想的理论和应用实践
31 0
|
15天前
|
弹性计算 运维 监控
多云基础设施的统一纳管与运维实践分享
阿里云弹性计算团队十三位产品专家和技术专家共同分享云上运维深度实践,详细阐述如何利用CloudOps工具实现运维提效、弹性降本。
|
16天前
|
运维 云计算 Docker
深入理解与实践:基于Docker的微服务架构优化策略
本文旨在为软件开发和运维人员提供一个全面的指南,探讨如何通过Docker容器技术优化微服务架构。我们不仅深入分析了Docker在微服务环境中的关键作用,还提出了一系列实践策略,以提高部署效率、增强系统稳定性,并确保服务的可伸缩性和安全性。通过具体案例分析和比较传统部署方式的局限性,本文展示了Docker如何成为微服务架构优化不可或缺的工具,旨在帮助读者构建一个更加灵活、高效和可靠的服务环境。
16 1
|
16天前
|
敏捷开发 弹性计算 架构师
浅谈微服务架构下的数据库设计与实践
在当今快速发展的软件工程领域,微服务架构因其高度的模块化和灵活性而受到广泛欢迎。然而,随之而来的是对数据库设计和管理提出了新的挑战。本文将探讨在微服务架构下,如何有效地设计和实践数据库以支持服务的独立性、数据的一致性和系统的扩展性。我们将从微服务的数据库隔离策略谈起,深入分析数据库的分库分表、事务管理、数据一致性解决方案等关键技术,并通过实例说明如何在实际项目中应用这些原则和技术。本文旨在为软件开发者和架构师提供一份指南,帮助他们在微服务架构的环境下,更好地进行数据库设计和管理。
13 1
|
20天前
|
前端开发 JavaScript 测试技术
探讨前后端分离架构在Web应用开发中的优势与实践
本文将深入探讨前后端分离架构在Web应用开发中的优势与实践。通过明确前后端分离的定义和原理,分析其在提高开发效率、降低耦合性、增强可维护性等方面的优势。同时,为读者提供了一些实践指导,包括如何选择适合的前后端分离框架、如何合理划分前后端职责等,旨在帮助开发者更好地应用这一架构并取得良好的开发效果。
|
22天前
|
存储 SQL 搜索推荐
业务系统架构实践总结
作者从2015年起至2022年,在业务平台(结算、订购、资金)、集团财务平台(应收应付、账务核算、财资、财务分析、预算)、本地生活财务平台(发票、结算、预算、核算、稽核)所经历的业务系统研发实践的一个总结。
|
25天前
|
消息中间件 负载均衡 监控
微服务架构:从概念到实践
微服务架构是一种面向服务的架构风格,旨在将复杂的应用程序拆分成更小、更可管理的部分。本文将介绍微服务架构的概念和原则,并提供一些实践经验和最佳实践。
|
1月前
|
负载均衡 持续交付 微服务
微服务架构的概念与实践
随着互联网应用的快速发展,传统的单体式架构已经无法满足业务需求。微服务架构作为一种全新的解决方案,正在逐渐流行起来。本文将介绍微服务架构的基本概念、特点以及实践技巧,帮助读者更好地理解和应用这一架构模式。
|
1月前
|
前端开发 UED
微前端架构的崛起:概念与实践
微前端架构是一种新兴的前端架构模式,与传统的单体式前端架构有所不同。本文将介绍微前端架构的基本概念和具体实践,讨论其优势和劣势,以及如何在项目中应用微前端架构。
16 0
|
1月前
|
人工智能 运维 架构师
数美科技首席架构师陈建:基于云上弹性的高可用实时风控架构实践
2023年10月31日-11月2日,2023云栖大会在中国杭州·云栖小镇举行,北京数美时代科技有限公司首席架构师陈建在【CloudOps云上运维专场】发表了题为《基于云上弹性的高可用实时风控架构实践》的主题演讲,从在线实时风控架构及高可用解决方案等方向做了分享。

热门文章

最新文章