WingZhang 2019-06-14
其中, mPaaS(Mobile PaaS)是源自于支付宝客户端的移动开发平台,为企业提供了移动开发、测试、运营及运维提供云到端的一站式解决方案,能有效降低技术门槛、减少研发成本、提升开发效率,协助企业快速搭建稳定高质量的移动客户端 App。
mPaaS 能够提供 Native、H5、支付宝小程序三大开发框架;100+ 的 UI 控件;以及包括扫码,本地缓存,客户端埋点等 20+ 功能性 SDK,可以让开发者快速接入搭建 App 所需要的基础能力。
客户端开发和移动中台能力都是针对 App 本身,一个完整的 App 需要通过服务端来获取更高阶的能力。除了客户端框架和基础组件之外,云端基础服务(如 API 网关、SYNC 数据同步、PUSH 通知等)提供了接口管理、流量管控、用户鉴权、H5 离线包、热修复包、性能分析等运营运维能力,构建了一个高稳定、高可靠以及高效率的后台连接服务。
1
ToB 和 ToC 的区别
每当我们向外部的客户介绍蚂蚁输出的技术能力时,往往会总结出三大优势:
很显然,通过一次次的“战役”,蚂蚁金服目前的技术架构体系逐步从众多高并发业务场景中获得锤炼,完成了对高可用、高性能的架构特性打磨。系统的高可用性已成为互联网企业系统架构的基础要求之一,以支付宝为例,在每年的双十一期间,其每秒可支撑的交易量可达数十万笔,可以见得系统可用性的重要性。但系统可用,并不代表足够兼容。当我们逐步将技术能力打包对外输出,尝试在不同的业务场景中落地时,经常会听到这样的声音:
在 ToB 的业务场景中,除了强调“高可用”特性以外,“成本”和“兼容性”同时也是重中之重。随之而来的,这对我们在进行高可用架构的设计和复用方面提出了三大挑战:
2
挑战一:高可用和成本
在介绍高可用和成本之前,首先要看看 ToB 的研发流程,我们会把整个生命周期分成两个部分:
在 ToB 的研发流程体系中,要保证产品高可用能力,客户的现场不会出问题,我们需要在 Global 做更多更厚实的工作:
虽然在 Global 层做了很多工作,但不能保证客户环境不出问题;对于客户的环境,我们把高可用能力建设从这几个角度来建设:
要考虑高可用的成本,首先我们要对高可用能力进行量化,我们从两个不同维度来看:
Local 站点的能力通过变更管理,监控发现,容灾能力,自愈能力,故障数据分析等多个因素来确定高可用能力,给客户设定不同的等级,从低层级到高等级之间演进的路径是什么,付出的成本有多少。
产品维度的高可用能力评估主要从 Global 研发流程出发进行不同维度的量化分析,目的是提供让产品能力持续提升的量化指标。
以容灾能力为例,不同的容灾架构可以规避不同范围的灾难,但也需要付出不同的成本,我们的客户更多是选择同城双活的架构,这个架构有比较好的性价比。
3
挑战二:兼容不同的基础设施
开篇的时候我们已提到,面对客户不同的基础设施,蚂蚁在输出金融科技能力的过程中必须要承认的是,我们很难充分满足不同的业务需求和场景挑战。在这个背景下,我们需要逐步建设开放的能力,把已有的技术能力向合作伙伴和客户开放。
下图以底座支撑移动开发平台 mPaaS 输出为例,箭头右侧是客户对整个技术栈的每一层的开放需求:
开放的路还需要继续探索,我们会按这几个方面来推进:
通过向外部的合作伙伴或者客户输出工程能力来共同建设,逐渐增强我们内部的核心能力,形成正向的反馈。
4
挑战三:不同主体之间的协同
当我们面向不同的合作伙伴,面向不同的客户提供能力时,随之而来的问题就是怎么做协同?
不同企业的数字化成熟度不同,有些没有 SRE 团队,没有应急响应机制,即使有,职能和保障机制不尽相同;面对这样的环境,我们必须建立成熟简明的流程和机制,并且形成产品,让合作伙伴或者客户尽量闭环,减少和我们之间的“RPC通信”,这需要对我们的产品化能力有很高的要求。
5
总结
总结一下,蚂蚁在 ToB 的科技输出时,高可用领域面临有几个挑战:
在“互联网技术应用的 30年”,“产业互联网”的大潮下,帮助企业做数字化转型面临非常不一样的挑战。很显然,一套设计优异的系统架构往往不是一味追求前沿技术,而需要贴合实际业务场景和具体发展状态,打造清晰、合理的架构,确保业务高可用的同时,又具备持续扩容、发展的弹性。由于篇幅有限,今天我们提出了部分问题并结合已有的实践经验进行总结,欢迎大家指正和交流,也欢迎大家一同来分享高可用架构演进的实战经验。
end:如果你觉得本文对你有帮助的话,记得点赞转发,你的支持就是我更新动力。