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

• mPaaS 是什么？

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

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

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

1

ToB 和 ToC 的区别

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

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

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

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

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

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

2

挑战一：高可用和成本

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

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

• Global 做厚做实

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

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

• Local 快速反应

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

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

• 高可用和成本

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

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

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

• 产品维度高可用能力

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

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

3

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

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

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

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

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

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

1. 对外输出

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

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

4

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

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

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

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

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

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

5

总结

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

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

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

end：如果你觉得本文对你有帮助的话，记得点赞转发，你的支持就是我更新动力。