蚂蚁金服一站式、高可用架构实践与输出应用

做者：梁耀斌，花名追源，来自“追本溯源”，目前主要负责蚂蚁金融科技输出产品架构，关注 ToB 的数字化转型领域；2013 年加入到阿里技术保障部架构工具团队，从淘宝的异地多活架构的实施，到阿里集团的高可用架构和容灾体系建设，也曾经管理大规模的物理机集群和统一调度，对系统高可用和资源调度有比较深刻的了解，但愿可以把基础技术普适到更多须要的企业。

背景

本文采编于蚂蚁金服高级技术专家梁耀斌（追源）在 InfoQ 主办的 QCon 2019 全球软件开发大会广州站的现场分享《蚂蚁金服一站式、高可用架构实践与输出应用》，具体内容参考以下：

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

mPaaS 是什么？

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

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

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

ToB 和 ToC 的区别

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

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

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

1. 这个解决方案须要多少台物理机？容器？规模有多大？成本可否再降下去？
2. 咱们有 OpenStack，产品能够部署到咱们的虚拟机平台上？
3. 大家的产品有 hdfs，是否可使用咱们已有的 hdfs 产品？
4. 咱们有本身的运维平台，能够经过咱们的运维平台管理大家的产品？

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

1. 高可用和成本的折中

客户的业务和自身环境的数字化有着不一样的成熟度，对产品的高可用要求也有不一样的见解，高可用不是客户考虑的惟一要素，须要结合成本看投资回报率。

2. 兼容不一样的基础设施 不一样客户有不一样的基础设施，在系统架构设计时须要兼容不一样的基础环境。

3. 不一样主体之间的协同

客户的需求多样化，咱们不能把全部的需求都知足和实现，须要和合做伙伴以及企业客户一块儿协同。在这个背景下，高可用的设计有着很大不一样的视角。

挑战一 ：高可用和成本

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

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

Global 作厚作实

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

1. 产品的变动准入强管控

• 全部产品的变化都须要架构评审，包括新产品的入驻和后续依赖变动，确保架构合理性；

• 代码质量，自动化回归策略复用已有的能力，按照高要求严格执行。

2. 依赖管理

在对外输出的场景下，内部产品研发流程有个很是关键的不一样点，即在“交付环节”，咱们须要在客户现场从 0 到 1 创建起来整套系统，而内部产品更可能是在已有系统上升级；要保证交付时系统拉起正常，咱们必须对系统各个组件的启动依赖和运行依赖进行管理，按照依赖顺序进行系统拉起；系统的依赖关系必须保证合理，不能有循环依赖。

3. 完备的验证流程

除了自动化回归外，咱们须要在 Global 层进行交付验证，高可用故障模拟验证，容量规划验证等等，让绝大部分的问题都在 Global 层暴露，简化客户环境执行的步骤，只须要部署并完成自动化回归验证。

Local 快速反应

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

1. 规避关键风险

虽然极端状况出现几率不大，可是出现一次对咱们的信任影响很大；要保证极端状况下的系统和数据恢复能力，机房级容灾和数据备份管理是两个最为重要的产品能力，须要重点建设。

2. 快速识别风险

巡检系统按期扫描可以提早识别风险；监控的覆盖率须要持续建设，保证问题可以迅速暴露；出现异常后，故障定位模块可以帮助快速定位问题；在 ToB 输出领域，系统的架构和依赖相对稳定，故障定位比域内更加容易达到效果。

3. 快速恢复

变动的强管控把全部变动收敛，预案系统和故障场景结合，出现问题后，可以快速找到恢复方案，一键恢复。

4. 常态化的红蓝军对抗演练

Local 的高可用能力要有机制验证和保持：持续进行红蓝军演练，保证工具和系统的能力。

高可用和成本

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

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

Local 站点高可用能力

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

产品维度高可用能力

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

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

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

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

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

开放的路还须要继续探索，咱们会按这几个方面来推动：

1. 内部建设支撑核心功能的工程能力

好比咱们的产品核心功能支持 OpenStack 和 VMware，从研发，测试，交付，高可用，安全验证全流程都须要有环境来保障，不一样技术层的组合会有不少，这对工程能力是巨大的挑战。

2. 统一标准

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

3. 赋能

• 系统和工具走开源路线
• 把咱们的核心能力和边界定义清楚
• 提供核心能力的回归验证工具
• 给合做方提供方便接入的验证环境
• 经过赋能外部的合做伙伴或者客户来共同建设，逐渐加强咱们内部的核心能力，造成正向的反馈。

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

当咱们面向不一样的合做伙伴，面向不一样的客户时，随之而来的问题就是怎么作协同？

不一样企业的数字化成熟度不一样，有些没有 SRE 团队，没有应急响应机制，即便有，职能和保障机制不尽相同；面对这样的环境，咱们必须创建成熟简明的流程和机制，而且造成产品，让合做伙伴或者客户尽可能闭环，减小和咱们之间的“RPC通讯”，这须要对咱们的产品化能力有很高的要求。

1. 定义服务流程

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

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

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

最后

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

1. 高可用能力的成本

咱们须要自身建设厚实的高可用能力，给客户提供不一样阶段不一样成本的高可用能力选项

2. 兼容不一样的基础设施

建设支撑核心能力的强大研发中台，经过开放协同更多的资源来知足客户的需求，再不断反馈提高咱们的中台能力

3. 如何处理好协同

定义好不一样角色的协同流程，并造成系统和产品，赋能合做伙伴和客户，提高自主管理能力

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

往期阅读

《开篇 | 蚂蚁金服 mPaaS 服务端核心组件体系概述》

《蚂蚁金服 mPaaS 服务端核心组件：亿级并发下的移动端到端网络接入架构解析》

《mPaaS 核心组件：支付宝如何为移动端产品构建舆情分析体系？》

《mPaaS 服务端核心组件：移动分析服务 MAS 架构解析》

《蚂蚁金服面对亿级并发场景的组件体系设计》

《自动化日志收集及分析在支付宝 App 内的演进》

关注咱们公众号，得到第一手 mPaaS 技术实践干货

钉钉群：经过钉钉搜索群号“23124039”

期待你的加入～