第一代的 SOFA 其实就解决两个问题:一是当要把系统变成分布式的时候,怎么有一个像「胶水」的机制也就是连接器,可以把分布式系统连接成一个整体;二是希望每一个服务本身是组件化,所以当时第一代 SOFA 里采用了 OSGi(一套 Java 模块化规范,允许应用程序使用精炼、可重用和可协作的组件构建),这样每个工程师可以专注于各自的组件,最后又能够把这些组件拼装在一起成为「服务」,再把「服务」拼装在一起成为整个大系统。这一整套框架,就是第一代 SOFA 框架。
|
有了第一代 SOFA 技术架构之后,支付宝团队就开始做非常关键的业务服务改造。首先是把支付宝所有用户的核心账务系统变成一个业务服务,从而可以和其它业务组装起来。但是把账务拆出来以后,遇到一个更难的问题:怎么解决分布式服务一致性的问题,也就是分布式事务问题。而在解决这个问题的时候,当时支付宝团队冒了很大的风险,在启动这个项目的时候还并不清楚怎么解决最好,而当时可以参考的行业技术趋势就是 SOA 以及业界提出的几个 SOA 框架。
SOA 业界那时候提出两个 SOA 事务的标准:一个是基于 Atomic Transaction(原子性交易),叫 WS-Atomic Transaction;另一个是基于业务流程编排的事务,叫 WS-BusinessActivity;开源社区通过 JBoss 的 TransactionServer 实现了这两个参考标准下的事务。当时,支付宝的技术团队就在想,能否用 JBoss 开源技术与这两个标准去构建支付宝的核心交易和账务?然而,项目开始后的不久,也就三个月左右的时间,当项目进行到一半的时候,发现这两个当时业界的标准和开源实现却根本不可能支持一个实际的应用。
原因很简单,一个最简单的核心交易系统和核心账务系统,进行最简单的一个事务,也要经过十几次的消息传递,其中任何一次消息传递如果中断,那么这个事务就失败了,而且失败以后,当时业界的 SOA 标准并没有提出该怎么恢复失败的事务,同时任何一次交易都经过十几次的消息传递的话,也导致整性能非常低。这样一个系统如果最后发布的话,其实是不能支持支付宝当时的交易量。所以当项目进行到一半的时候,团队就放弃了业界标准及其开源实现,必须找到自己的一条路。
当年,关于分布式事务的一致性,业界另一条路径是基于两阶段事务标准(Prepare 阶段与 Commit 阶段)和开源分布式实现 XA,但当时已经知道 PayPal 曾经走过这条路,结果是导致系统宕机一周,最后系统全部回滚。
所以那个时候,支付宝技术团队就考虑能否自己提个标准,这样一来就简单了:首先是要解决分布式一致性问题,必须要分布式的提交协议,这个协议如果在数据库层实现,效率会非常低下,因为数据库层不懂任何的业务逻辑,只能以一种通用的方式去实现,从而导致无法对上层的业务逻辑层进行优化,所以就想到把提交协议放在服务层。
「那个时候,我们大的想法很简单,既然支付宝系统已经拆成了一个个非常小规模的服务,那么就让这个服务本身具备事务的属性,叫事务性服务。这样一个个小的事务性服务就像一个个小石头一样,可以装到一个大的杯子里,然后再设计一个分布式的提交协议,把这一个个小的事务绑定成一个大的业务事务。而这个服务也不仅是微服务,而其实是一个微交易,把每一个服务变成一个交易,再通过一个编排的框架,把每个交易变成一个大的整体服务。」程立用比较形象的语言解释了现在被称为蚂蚁金服黑科技的分布式事务 XTS (eXtended Transaction Service) 的由来。
有了这个思路,当时支付宝技术团队就开始去做了。克服的第一个难点是把已经有的交易服务、账务服务等,变成一个个交易型服务,这个难点当时就突破了;第二个难点是要实现一个可扩展(Scalable)的框架,去编排海量的事务,那就是 XTS。大概在 2008 年 1 月份,SOFA 项目就上线了,上线以后至今不断打磨,一直到现在还支撑蚂蚁金服整个的业务交易。
SOFA 的演进过程
从第一代到眼下的第五代,SOFA 的演进过程其实是支付宝从最早的一个大型的业务与 IT 交织在一起的单体系统,一边拆金融业务系统(即后来的业务中台)、一边拆底层 IT 系统(即后来的数据中台、计算中台)的过程,在拆分的过程中还要解决新出现的可扩展性、一致性问题等各种问题,同时不断应付每年都能击穿系统极限的双十一,还要把数据从原有系统一点一点「倒腾」到新系统里、同时管理新增的海量数据,这样一个极为复杂的过程是怎么进行的?有趣的是,这个过程的附加值之一,就是在无意中完成了去「IOE」,因为从单体系统拆分到互联网分布式系统,本身就是用 PC 服务器机房代替昂贵 IOE 设备的过程。
「整个过程可以说一路狂奔。」杨冰后来回忆整个过程。「『萝卜』就这么几个,坑那么多,根本就填不过来的状态。每个中间件产品连『一个萝卜一个坑』都做不到,很多『萝卜』是放在两个三个坑里面的状态,你就想有多挑战了。其次,每一年都是翻一番的业务指标倒逼。整个团队的状态基本上是一年大促结束后,春节一过就开始密集准备下一年大促,一眨眼的功夫离双十一就没几个月了,很多系统的技术改造可能要到 6、7 月份准备好,再全部升级上去,业务还在不断变化,不停有新的想法冒出来,每年就是这么个状态,基本都是开发飞机就把发动机给升级上去了。」
程立回忆,SOFA 早期的开发是完全违背项目管理逻辑,在项目推进的过程中既有研发平台又有研发上层的业务系统,相当于把很多风险都导在一个项目里面一起做,SOFA 第一代项目就是靠团队齐心协力,每天都会遇到新问题、每天都要去解决各种问题,但大家背后有必胜信念而且非常拥抱变化,敢于在项目的中后期把前期架构决定全部推翻掉,再用一套新的架构替代。「所以到 2008 年那次账务三期的发布,那次原定发布 8 个小时,后来我们发布了 17 个小时,说明在项目发布过程中,还是有很多问题没有解决,但最后我们硬生生把这个项目给发布下去,而且成功了,现在回想起来,其实是有一点后怕的。」程立笑说。
2008 年之后,支付宝技术团队开始确定一个原则,即所有的发布不得停机,必须要确保项目发布没有风险。其次,要结束所有的研究型项目,技术研究要把技术问题解决了,再用到商业系统里面去。而且从 2008 年开始,每个新技术都不会首先用到最核心的系统里,而是会在相对边缘的业务系统里经过充分考验以后,再用到核心系统里。
在 SOFA 初期,可以看到做交易和账务这两个项目的时候,业务系统开发人员与技术平台的开发人员是不分的,无论是程立还是胡喜,都是一会儿写业务交易的代码,一会儿写下面的技术平台代码,工程师团队也没有严格区分。后来开始建立中间件团队,杨冰基本上也是那个时候加入,分配一部分人专门研究底层技术,另一部分人专门写上面的应用系统架构,慢慢开始变得越来越正规了,包括对于新技术上线过程的灰度和控制,也会做得更好。
杨冰回忆他在 2009 年以刚毕业的研究生身份加入支付宝团队的时候,当时服务化拆分的过程是程立、胡喜亲自参与,一边对 WebX 系统做服务化拆分,一边胡喜写了 SOFA 框架的原型,杨冰与后面加入的小伙伴就帮助不断完善 SOFA。「当时我们还很初级,基本上是程立和胡喜带着我们去实现他们构想出来完整一套思想。当时虽然服务化和 SOA 的概念很火,但业界的实践远没有现在这么丰富,很多实现机制都是摸着石头过河。业务服务化拆分又是另外一条主线,当时主要是程立、胡喜、倪行军(花名苗人凤,支付宝第一代首席架构师,蚂蚁金服支付宝事业群总裁)参与,这几个人都是既写框架代码和组件代码,又参与业务代码拆分。当时支付宝所有的业务都在演进,支付宝架构团队一方面在业务逻辑拆分和技术架构拆分的过程中熟悉支付宝的业务,一方面在熟悉业务的基础上思考如何从中抽象出可复用的代码、数据和框架,以更好的支持未来的业务。所以当时就是一边在做业务和技术的人肉拆分,一边又把拆分的部分挪到新的框架中去承载。整个过程不是设计好了再搞,而是一边做一边搞。」
XTS 框架都是在那样一个过程当中写出来的。因为在原先集中式架构是不会出现事务一致性的问题,拆分以后就出现了这样的问题。当问题出现以后,就一边拆一边解这个问题。当然,解决的时候也不是人为介入,而是构想出技术化的方案,甚至沉淀出来一套技术。那个时候,支付宝系统里的 Oracle 数据库还在用,小型机等高端传统设备都在用,支付宝的业务系统包括会员、交易等被拆分出来后,就直接跑在 X86 架构上,这不仅是物理形态和部署形态上的差异,更是由单体应用的开发模式变成 SOA 化的分布式开发模式,这就是从 WebX 到 SOFA 的演进过程。账务系统是最后一个从支付宝拆分下来的系统,随着账务系统的拆分成功,IOE 设备也彻底从支付宝系统里下线。
在整个支付宝架构的改造以及 SOFA 的发展过程中,关于中间件的基本构成和思想是有业界参照的,比如消息中间件、数据中间件、事务中间件等,但 SOFA 技术团队要做面向超大规模互联网金融交易的分布化改造,而其中的黑科技诸如单元化,则是被业务倒逼出来,完全没有业界参考的实践,「我们找到的一些论文,一些概念,一些类似的做法,但当时支付宝的体量已经很大了,没有人确定这事儿真的能做成,而且是在金融这个高危的业务场景下」。
「套用蚂蚁金服前 CEO 彭蕾的话,她曾提到过大家做的很多事情就是怎么把马云的决定变成一个正确的决定,而我们在整个中间件工程实现过程中,也是类似的情况。比如 SOFA3 时代的合并部署,当时胡喜提出这个概念的时候,内部争论非常大,大家都觉得这件事情不靠谱,而且很难做、非常复杂,阻力非常大。最难的事情,是说服团队。但最后大家还是为能做成这件事情,并为公司节省下这多成本而感到骄傲」杨冰回忆。
为了解决新的挑战,蚂蚁金服的中间件技术团队想了各种办法。杨冰为单元化架构当中 RPC 调用设计的路由逻辑:对于各种业务系统,有的可以升级、有的可以改造、有的不行,那么在 RPC 远程服务调用时就会有五六种分支去决定到底是本地优先、还是要跨机房、还是要根据业务的分库分表做路由等等。这个逻辑极其复杂,在于既有同构机房、又有异构机房,而异构机房又要把通讯收敛到一个代理,所以又会有代理的存在,导致非常复杂。而为了收管没法升级的系统,甚至该系统的负责人都已经不在的情况,就用一个类似于 Service Mesh 技术代理,去「伪装」这个服务。「整个架构是很漂亮的,但是工程实现中的每一个细节都很复杂,所有的设计都充满了架构的平衡的智慧。我们在实现整个过程以后,再慢慢把完全没有必要的三四个路由逻辑去掉,变成比较规整的模式。基本是这样的过程,因为不能把支付宝停下来。」
负责过 SOFA 体系中消息中间件的王磊(花名:文若)回忆,阿里从 2008 年开始办双十一,第一年只是试一下,所以没有很大规模的宣传,甚至连内部很多人都不知道。从 2009 年是开始支付宝和淘宝一起参与双十一,当时宣传淘宝商城里面所有的商品都是半价,但是因为 2008 年时候对双十一的力量并没有清楚的认识,到 2009 年那一年的时候就突然出现了各种问题。王磊当时负责消息中间件,内部叫做 Message Broker,属于消息队列:消息从上游应用通过消息中间件传递给下游的系统,包括当时还在使用的 Oracle 数据库。「当时正在看这个活动的过程,甚至我们自己也在买东西的时候,突然 DBA 跑过来说要赶快对消息进行限流,因为下游的数据库马上就要撑不住了,数据库的日志空间马上就要耗光了,如果耗光就会导致数据库宕机,再启动起来就是几个小时以后的事情。当时我们小组是三个人,以前从来没有快速对消息进行限流,最后就只能人工登录上游应用的服务器上,然后在服务器上敲命令做流量控制,一条一条的敲下去,最后保住了下游系统没有被冲垮。那个时候很遗憾,因为不是靠消息中间件去限流,实际上是把上游发消息的应用『杀』死了。后来,经过这件事情以后,我们就下定决心要做一件事情,就是叫做一键限流,在中间件层面对于消息中心的一键限流能力,就是从那天开始建设的。」这样的故事还有很多。「整个过程就像打怪升级,看到一个干掉一个。」王磊的实践,代表了整个 SOFA 团队的工作状态,也代表了 SOFA 与其它互联网分布式中间件的最大不同——沉淀了支付宝/蚂蚁金服十多年来,整个业务与 IT 体系的最佳共享实践。
就是这样,SOFA 的演进伴随着支付宝整个架构的演进而发展,程立回忆,第一代 SOFA 比较简单,只是搭了一个框架和模型让系统可以运行,到后期系统运行中做了大量的优化,包括要解决通讯的性能、最高效的容灾、异地容灾架构的建设、单元化改造、LDC 逻辑数据中心项目等,所有这些慢慢就沉淀在 SOFA 里面。而 SOFA 则逐渐从解决分布式服务和分布式交易的问题,变成一个真正解决金融级系统构建的基础架构问题,所以现在把 SOFA 改名,从原来的 Service Oriented FabricArchitecture 改为 Scalable Open Financial Architecture:这个框架是可以真正解决金融级系统的异地多活的容灾和扩展问题,而且 SOFA 的可扩展能力不仅是处理更多的交易,还可容纳更多的业务,能够让几千位工程师甚至未来上万个工程师一起协同工作的可扩展架构;Open 的意思是希望这个框架相对可以让业务应用非常容易使用,又能与经典架构系统有机融合,SOFA 框架未来不但可以编排蚂蚁金服工程师自己写的业务逻辑,而且可以编排合作伙伴的业务逻辑,成为一个完整的编排框架;Financial 则意味着 SOFA 必须是具备金融级属性,能真正实现金融级的一致性、可用性和稳定性。
SOFA 的设计哲学
SOFA 从第一代发展到第五代,是一个异常复杂而庞大的过程,程立总结 SOFA 的研发方法论和经验时表示:在整个研发方法和流程上,蚂蚁金服相对于来说是以互联网的方式去做金融,因为蚂蚁金服本身就是一个金融系统,在要求非常严格的同时,也希望有互联网的迭代速度,在这个过程中沉淀下来的经验。
首先,注重架构的治理。蚂蚁金服一直有一个架构师团队,既有总架构师团队,同时又把各个分域的架构师集合在一起,始终保持蚂蚁金服的架构在一张图上。蚂蚁金服架构的迭代演进也非常清晰,从一代、二代、三代、四代到现在的第五代架构,都有非常清晰的演进阶段,这是从治理层面进行顶层设计的结果。
第二,关注技术的风险。蚂蚁金服研发任何系统,要比其它互联网公司多付出可能 10% 的努力,去保证系统风险的可控,所以蚂蚁金服技术风险管控是嵌到流程里面、控制在整个研发生命周期里面,从而实现了非常好的控制。当然,蚂蚁金服的研发效能团队也会把控,让研发人员尽量简单、尽量智能化。
第三,系统优化是在高度分布化的前提下实现的。蚂蚁金服是比较少有的、几千人工作在一条业务流程上面,最核心支付流程从前端到后端分了很多层、每层里面有很多功能,在这个过程中能够保证非常好的分布和集成效率以及质量,就变得非常关键。所以从整个项目管理的需求、分析、分解,到每个团队去实现,最后再做高效的集成、迭代发布,有非常多经验沉淀在研发部署运维平台上。蚂蚁金服的研发部署运维平台经过多代的变化,有段时间也引进了 IBM 等供应商的整套方法和工具,用了两年左右时间后发现完全不适合蚂蚁金服工作方式和速度,所以转向自研的平台,并不断轻量化。但也不是外界的开源模式,因为也不适用于蚂蚁金服的情况。
第四,蚂蚁金服中间件团队的另一个共识,Design for failure,即假定在任何情况下底层都有不可靠的风险存在。对金融 IT 系统来说,任何的底层硬件临时故障或网络抖动都有可能被放大到资金损失或整体服务稳定性层面。对于支付宝这样体量的互联网应用,从设计之初就把高可靠、高可用、高性能的能力要转到中间件层和数据库层去保证。下面的 IaaS 必须要简单,就是允许底层硬件可以挂掉,挂掉以后由中间件和数据库层负责。为什么会这么做?这是由业务的容忍程度决定的,没法沉到底下的 IaaS 层,但也没有必要让每个写业务代码的人都自己编写一套代码,所以就沉淀到中间件层。
中间件会被所有人用到、会影响所有的系统,像蚂蚁金服现在有几千个系统和上万个微服务、几千号研发人员,怎么能使在中间件层做的每一项工作都能使整体架构都能平滑升级,而不要让业务系统受影响,怎么建立跟其他开发人员之间的连接,如何平衡效率和运维,这是中间件的挑战。
被问到 SOFA 跟别的微服务平台有什么不同,杨冰举了个例子「如果有两套架构在顶层设计的时候,一套将平衡倾向了「成本最优」,一套则倾向了「风险最小」,在实现过程中就会有千百次设计决策会依据这个大原则做出「架构平衡」,到最后出来的架构会完全不同,就像 CAP 理论中的平衡一样,什么样的业务决定着会孵化出什么样的技术,技术最终还是为业务服务的。
总结
创新都是被逼出来的,蚂蚁金服自研 SOFA 同样如此。SOFA 走的是一条跟传统金融行业不同的分布式架构之路。要基于不可靠的硬件系统实现金融级的性能和可靠性,要应对支付宝这样的超大规模互联网金融应用,有很多难题要解决。蚂蚁金服构建了一整套处理金融级交易的分布式架构与平台,在金融级的一致性要求和海量并发处理能力上达到了很好的平衡,并在快速容灾恢复、弹性伸缩能力、多地多活高可用保证能力和按需供给的精细化资源调度能力方面沉淀了丰富的实践经验。
随着 2015 年科技开放战略的启动,蚂蚁金服技术的团队面对的不仅仅是内部业务,还有更加复杂多变的外部业务场景和技术挑战。以前,技术团队是一个被被业务倒逼的支持型组织,现在已经逐步向一个驱动业务的学习型组织和创新型组织转变。「昨天的最好表现是今天最低的要求,由于双 11 在技术上已经成为常态化工作,满足交易业务已经成为了最基本的要求,所以我们要看到更远的未来、准备迎接更强的挑战。」杨冰的话,从一个侧面解释了蚂蚁金服技术团队对开拓更辽阔数字金融世界边界的期待。