本文来自蚂蚁金融梁耀斌老师的分享。

背景

今天，我主要来介绍蚂蚁金融智能科技对外输出时，在高可用领域面临了怎样的架构挑战与解决方案。在具体内容展开之前，我们先认识下蚂蚁金服智能科技团队目前对外输出的技术产品体系，通过“BASIC”便可基本概括五大产品方向：Blockchain (区块链)、Artificial-Intelligence（人工智能）、Security（安全）、 IoT（物联网）和 Cloud Computing（云计算）。有了对产品发展方向的理解，对于我们理解后续的内容有较大的帮助。

mPaaS 是什么？

其中，mPaaS（Mobile PaaS）是源自于支付宝客户端的移动开发平台，为企业提供了移动开发、测试、运营及运维提供云到端的一站式解决方案，能有效降低技术门槛、减少研发成本、提升开发效率，协助企业快速搭建稳定高质量的移动客户端 App。

mPaaS 能够提供 Native、H5、支付宝小程序三大开发框架；100+ 的 UI 控件；以及包括扫码，本地缓存，客户端埋点等 20+ 功能性 SDK，可以让开发者快速接入搭建 App 所需要的基础能力。

客户端开发和移动中台能力都是针对 App 本身，一个完整的 App 需要通过服务端来获取更高阶的能力。除了客户端框架和基础组件之外，云端基础服务（如 API 网关、SYNC 数据同步、PUSH 通知等）提供了接口管理、流量管控、用户鉴权、H5 离线包、热修复包、性能分析等运营运维能力，构建了一个高稳定、高可靠以及高效率的后台连接服务。

ToB 和 ToC 的区别

每当我们向外部的客户介绍蚂蚁输出的技术能力时，往往会总结出三大优势：

超 10 亿用户的超级 App 技术架构体系
成功应对“双十一”及“新春红包”交易峰值的冲击
源于蚂蚁金服 10 多年的技术发展与沉淀

很显然，通过一次次的“战役”，蚂蚁金服目前的技术架构体系逐步从众多高并发业务场景中获得锤炼，完成了对高可用、高性能的架构特性打磨。系统的高可用性已成为互联网企业系统架构的基础要求之一，以支付宝为例，在每年的双十一期间，其每秒可支撑的交易量可达数十万笔，可以见得系统可用性的重要性。但系统可用，并不代表足够兼容。当我们逐步将技术能力打包对外输出，尝试在不同的业务场景中落地时，经常会听到这样的声音：

这个解决方案需要多少台物理机？容器？规模有多大？成本能否再降下去？
我们有 OpenStack，产品可以部署到我们的虚拟机平台上？
你们的产品有 hdfs，是否可以使用我们已有的 hdfs 产品？
我们有自己的运维平台，可以通过我们的运维平台管理你们的产品？

在 ToB 的业务场景中，除了强调“高可用”特性以外，“成本”和“兼容性”同时也是重中之重。随之而来的，这对我们在进行高可用架构的设计和复用方面提出了三大挑战：

高可用和成本的折中
客户的业务和自身环境的数字化有着不同的成熟度，对产品的高可用要求也有不同的看法，高可用不是客户考虑的唯一要素，需要结合成本看投资回报率。
兼容不同的基础设施
不同客户有不同的基础设施，在系统架构设计时需要兼容不同的基础环境。
不同主体之间的协同
客户的需求多样化，我们不能把所有的需求都满足和实现，需要和合作伙伴以及企业客户一起协同。在这个背景下，高可用的设计有着很大不同的视角。

挑战一：高可用和成本

在介绍高可用和成本之前，首先要看看 ToB 的研发流程，我们会把整个生命周期分成两个部分：

Global 层包括传统的开发，测试和版本发布流程。这里的发布不是互联网产品的 Deploy，而是产品的 Release。
其次，ToB 的 Deploy 和原有的模式有很大区别，体现在我们要管理客户非常多的环境，有很多 Local 的环境，如图所示。

Global 做厚做实

在 ToB 的研发流程体系中，要保证产品高可用能力，客户的现场不会出问题，我们需要在 Global 做更多更厚实的工作：

产品的变更准入强管控
所有产品的变化都需要架构评审，包括新产品的入驻和后续依赖变更，确保架构合理性；
代码质量，自动化回归策略复用已有的能力，按照高要求严格执行。
依赖管理
在对外输出的场景下，内部产品研发流程有个非常关键的不同点，即在“交付环节”，我们需要在客户现场从 0 到 1 建立起来整套系统，而内部产品更多是在已有系统上升级；要保证交付时系统拉起正常，我们必须对系统各个组件的启动依赖和运行依赖进行管理，按照依赖顺序进行系统拉起；系统的依赖关系必须保证合理，不能有循环依赖。
完备的验证流程
除了自动化回归外，我们需要在 Global 层进行交付验证，高可用故障模拟验证，容量规划验证等等，让绝大部分的问题都在 Global 层暴露，简化客户环境执行的步骤，只需要部署并完成自动化回归验证。

Local 快速反应

虽然在 Global 层做了很多工作，但不能保证客户环境不出问题；对于客户的环境，我们把高可用能力建设从这几个角度来建设：

规避关键风险
虽然极端情况出现概率不大，但是出现一次对我们的信任影响很大；要保证极端情况下的系统和数据恢复能力，机房级容灾和数据备份管理是两个最为重要的产品能力，需要重点建设。
快速识别风险
巡检系统定期扫描能够提前识别风险；监控的覆盖率需要持续建设，保证问题能够迅速暴露；出现异常后，故障定位模块能够帮助快速定位问题；在 ToB 输出领域，系统的架构和依赖相对稳定，故障定位比域内更加容易达到效果。
快速恢复
变更的强管控把所有变更收敛，预案系统和故障场景结合，出现问题后，能够快速找到恢复方案，一键恢复。
常态化的红蓝军对抗演练
Local 的高可用能力要有机制验证和保持：持续进行红蓝军演练，保证工具和系统的能力。

高可用和成本

要考虑高可用的成本，首先我们要对高可用能力进行量化，我们从两个不同维度来看：

Local 站点的高可用能力（图的右侧）
产品的高可用能力（图的左侧）。

Local 站点高可用能力

Local 站点的能力通过变更管理，监控发现，容灾能力，自愈能力，故障数据分析等多个因素来确定高可用能力，给客户设定不同的等级，从低层级到高等级之间演进的路径是什么，付出的成本有多少。

产品维度高可用能力

产品维度的高可用能力评估主要从 Global 研发流程出发进行不同维度的量化分析，目的是提供让产品能力持续提升的量化指标。

以容灾能力为例，不同的容灾架构可以规避不同范围的灾难，但也需要付出不同的成本，我们的客户更多是选择同城双活的架构，这个架构有比较好的性价比。

挑战二：兼容不同的基础设施

开篇的时候我们已提到，面对客户不同的基础设施，蚂蚁在输出金融科技能力的过程中必须要承认的是，我们很难充分满足不同的业务需求和场景挑战。在这个背景下，我们需要逐步建设开放的能力，把已有的技术能力向合作伙伴和客户开放。

下图以底座支撑移动开发平台 mPaaS 输出为例，箭头右侧是客户对整个技术栈的每一层的开放需求：

开放的路还需要继续探索，我们会按这几个方面来推进：

内部建设支撑核心功能的工程能力
比如我们的产品核心功能支持 OpenStack 和 VMware，从研发，测试，交付，高可用，安全验证全流程都需要有环境来保障，不同技术层的组合会有很多，这对工程能力是巨大的挑战。
统一标准

技术栈尽量贴合开源，特别在各个产品的 API 方面。
拥抱云原生，云原生这个事实标准帮助技术快速传播，同时也让生态有了统一的概念和语言，加速了技术的应用和普及。

对外输出

系统和工具走开源路线
把我们的核心能力和边界定义清楚
提供核心能力的回归验证工具
给合作方提供方便接入的验证环境

通过向外部的合作伙伴或者客户输出工程能力来共同建设，逐渐增强我们内部的核心能力，形成正向的反馈。

挑战三：不同主体之间的协同

当我们面向不同的合作伙伴，面向不同的客户提供能力时，随之而来的问题就是怎么做协同？

不同企业的数字化成熟度不同，有些没有 SRE 团队，没有应急响应机制，即使有，职能和保障机制不尽相同；面对这样的环境，我们必须建立成熟简明的流程和机制，并且形成产品，让合作伙伴或者客户尽量闭环，减少和我们之间的“RPC通信”，这需要对我们的产品化能力有很高的要求。

定义服务流程
对有不同需求的服务对象提供不同服务能力，明确不同服务能力的流程和实施路径。

服务中台建设服务中台主要从 4 个方面来提升服务能力，赋能合作伙伴和客户有自主管理的能力：

Local 的高可用能力产品
提升服务效率提升的工具
服务渠道的管理
服务流程的透明化

总结

总结一下，蚂蚁在 ToB 的科技输出时，高可用领域面临有几个挑战：

高可用能力的成本
我们需要自身建设厚实的高可用能力，给客户提供不同阶段不同成本的高可用能力选项
兼容不同的基础设施
建设支撑核心能力的强大研发中台，通过开放协同更多的资源来满足客户的需求，再不断反馈提升我们的中台能力
如何处理好协同
定义好不同角色的协同流程，并形成系统和产品，赋能合作伙伴和客户，提升自主管理能力

在“互联网技术应用的 30年”，“产业互联网”的大潮下，帮助企业做数字化转型面临非常不一样的挑战。很显然，一套设计优异的系统架构往往不是一味追求前沿技术，而需要贴合实际业务场景和具体发展状态，打造清晰、合理的架构，确保业务高可用的同时，又具备持续扩容、发展的弹性。由于篇幅有限，今天我们提出了部分问题并结合已有的实践经验进行总结，欢迎大家指正和交流，也欢迎大家一同来分享高可用架构演进的实战经验。

=>更多文章请参考：《中国互联网业务研发体系架构指南》https://blog.csdn.net/Ture010Love/article/details/104381157

=>更多TOP权威案例及行业标准资料请关注微信公众号：

【稳定性day7】mPaaS - 蚂蚁金服高可用的产品化之路相关推荐

从网络接入层到 Service Mesh，蚂蚁金服网络代理的演进之路
详细阅读本文大约需要15分钟,先花150s听听是否对本文感兴趣吧~ 本文作者:肖涵(涵畅) 上篇文章<诗和远方:蚂蚁金服 Service Mesh 深度实践 | QCon 实录>中,介绍了 ...
蚂蚁金服缘何自研Service Mesh？
2018年,微服务方兴未艾,Service Mesh(服务网格)又快速崛起.有观点认为,2018年可被称之为"Service Mesh元年",在未来两年中,Service Mesh ...
从BAT到ATM，蚂蚁金服的逻辑和风险
文章经授权转载自凤毛麟角(ID:fengmaolj) 近日,互联网双巨头腾讯和阿里巴巴都挺热闹.腾讯大战抖音热度颇高,阿里巴巴这厢最热闹的当属蚂蚁金服,蚂蚁金服宣布获得140亿美元的全世界最大单笔私募 ...
世界领先！详解蚂蚁金服自研数据库OceanBase的高可用及容灾方案
小蚂蚁说: 关于蚂蚁金服自研的金融级分布式关系型数据库OceanBase的故事相信大家已经不再陌生了(新来的同学可以移步<厉害了,蚂蚁金服!创造了中国自己的数据库OceanBase>了解更 ...
阿里移动|《蚂蚁金服移动端高可用技术实践》
摘要:对于移动技术而言,2017年是继往开来之年.一方面是移动技术领域进入深水区,另一方面移动技术边界和内涵被不断重塑.阿里巴巴希望进一步推动移动应用研发事实标准落地,从而赋能整个行业开发者.在201 ...
蚂蚁金服资深技术专家经国：云原生时代微服务的高可用架构设计
经国蚂蚁金服数字金融线担任技术风险架构师读完需要 15 分钟速读仅需 5 分钟经国,蚂蚁金服资深技术专家,毕业于浙江大学. 2014 年加入蚂蚁金服,先后负责过支付宝的单元化.弹性.去 ORA ...
【稳定性day0】稳定性治理的三种思想—亚马逊、Netflix与蚂蚁金服
1.领域名词解释稳定性(Reliability).可用性(Availability).可维护性(Maintainability),是三个有关联的概念.合称RAM,较为容易混淆,因此本需要特别说明一下 ...
开篇 | 蚂蚁金服 mPaaS 服务端核心组件体系概述
mPaaS 是源自于支付宝客户端 App 的移动开发平台,为企业提供了移动开发.测试.运营及运维提供云到端的一站式解决方案,mPaaS 能有效降低技术门槛.减少研发成本.提升开发效率,协助企业快速搭建 ...
蚂蚁金服对研发高要求的领域建模能力是指什么？
作者 | 骑着金牛往前走出品 | 独自慎思 0 前言最近,由于工作需要,我接触了网商银行的一个项目.项目里对应的业务模型设计,是我工作这三年来见过的所有模型里最复杂的.于是,利用五一这个短暂的假期 ...
蚂蚁金服mPaaS 3.0发布助力客户智能化构建超级App生态
1月4日,蚂蚁金融科技宣布蚂蚁金服移动开发平台mPaaS(mobile Platform-as-a-Service)升级到3.0版本,"新版本以智能技术助力客户构建自己的超级 App,企业可 ...

【稳定性day7】mPaaS - 蚂蚁金服高可用的产品化之路

背景