这是 SOFA 的故事，或者也会是你的故事

“你能不能跟我讲讲 SOFA 的故事？”

“SOFA 的故事很特别也很日常 ，跟你说说 SOFA 的故事，或者也会是你的故事。”

初心：技术应该是要解决实际问题的

蚂蚁金服不是为了作技术自己而作技术，而但愿用技术来解决社会当下和将来的问题。若是说用金字塔结构来描绘数字金融的社会价值，在塔顶的就是数字金融能在全球范围内带来更多平等的机会。

程立（蚂蚁金服 CTO）强调：“对蚂蚁金服或者阿里巴巴来讲，首先咱们是很是的理想主义和愿景驱动，当肯定能够给全世界带来更多平等的机会时，这必定指引咱们的方向。可是咱们也是一个很是现实主义的公司，当遇到具体问题的时候，会看怎么可以很好的绕过当下的障碍，从而走到要走向的将来。在遇到具体的现实问题的时候，也不会采起很是僵硬的方式。具体问题确定是要具体分析的，可是咱们的愿景不会变，也不会把所谓的价值观变成教条。商业上的可持续发展，对咱们来讲很是重要，若是咱们商业上都不能可持续发展，就走不到将来。”

技术创新都是被逼出来的

蚂蚁金服自研 SOFA 一样如此。SOFA 走的是一条跟传统金融行业不一样的分布式架构之路。要基于不可靠的硬件系统实现金融级的性能和可靠性，要应对支付宝这样的超大规模互联网金融应用，有不少难题要解决。蚂蚁金服构建了一整套处理金融级交易的分布式架构与平台，在金融级的一致性要求和海量并发处理能力上达到了很好的平衡，并在快速容灾恢复、弹性伸缩能力、多地多活高可用保证能力和按需供给的精细化资源调度能力方面沉淀了丰富的实践经验。

中间件，是与操做系统和数据库并列的传统基础软件三驾马车之一，也是难度极高的软件工程。传统中间件的概念，诞生于上一个“分布式”计算的年代，也就是小规模局域网中的服务器/客户端计算模式，在操做系统之上、应用软件之下的“中间层”软件。早期中间件的出现，是为了解决日益复杂的PC服务器、网络甚至不一样地理位置机房之间等异构硬件环境中，支撑应用软件的挑战。与操做系统和数据库不一样，中间件并无一个明确的定义，一般来讲包括消息、数据、远程过程调用、对象请求代理、事务、构件等几个部分。

随着互联网的快速发展，特别是云计算在近十年的蓬勃进展，企业的IT环境发生了深入的变化：从过去基于局域网和城域网、单一城市地理范围的分布式计算环境（传统企业），向基于互联网和光纤网络、全国甚至全球地理范围的超大规模分布式计算环境演进（互联网企业）。在这个过程当中，软件也向大规模互联网服务和云服务演化，不管是操做系统仍是数据库都发生了深入的变化，中间件也在这个过程不断演进和扩大本身的边界。

中间件的发展表明着技术架构的升级和变迁，而这与企业组织模型和业务实践息息相关。理论上，中间件向下屏蔽异构的硬件、软件、网络等计算资源，向上提供应用开发、运行、维护等全生命周期的统一计算环境与管理，属于承上启上的中间链接层，对企业来讲着重要的价值。根据康威定律，软件和系统架构设计，和企业的组织结构、业务流程和沟通方式息息相关，所以，随着企业业务规模的超大规模和快速迭代发展，中间件质量和能力的高低就直接决定了企业技术架构的命运。特别是随着数字商业的兴起，过去不能被业务感知、不能为最终用户带来直接价值的中间件，也成为了数字业务的一部分。

蚂蚁金服是一家旨在为世界带来平等金融服务的科技企业，做为原生的数字企业和数字商业表明，蚂蚁金服从2004年成立支付宝开始，在过去十多年的时间里走出了一条自研的、面向超大规模互联网金融应用的、金融级中间件技术体系。特别是自2008年双十一以来，在每一年双十一超大规模流量的冲击上，蚂蚁金服不断突破现有技术的极限，在金融领域达到了史无前例的技术成就，特别是历时十年自研的中间件技术能够知足2017年双十一25.6万笔/秒的支付峰值、全天14.8亿笔的支付，而2010年双十一的支付峰值为2万笔/分钟、全天1280万笔支付。在过去几年内，蚂蚁金服自研的中间件技术所支持的支付峰值翻了750倍、全天支付笔数翻了115倍、交易更覆盖全球225个国家和地区。

极限业务场景催生了极限的IT体系。蚂蚁金服的金融核心技术部负责人赵尊奎（花名：妙才）说，他常常接待外部的金融机构负责人来参观和了解蚂蚁金服的IT体系，“看过的都表示不敢想象”。今天，蚂蚁金服的软件工程成就，已经把双十一极限挑战变成了新常态，而这套支撑蚂蚁分布式实践的架构体系，称之为SOFA（Scalable Open Financial Architecture，简称 SOFA）。

SOFA 的诞生

SOFA 的关键词包括：无限伸缩能力、一致性、秒级容灾和极低成本而且作到极致，从而定义了新的“金融级分布式架构”。

SOFA 的缘起

程立，花名鲁肃，摩羯座，工号3896。2004年，支付宝刚刚有本身独立的系统，基础平台还得靠外包团队提供技术支持。而2004年2月，程立还在上海交大攻读博士，一个偶然机会让他接触到阿里巴巴，并之外包架构师的身份协助支付宝网站的建设。一年合做下来，程立决定放弃博士学位，并于2005年2月正式加入支付宝。程立以严谨务实、逻辑严密，被蚂蚁技术团队的同事视做“神同样的存在”。

▲ 蚂蚁金服CTO 程立

做为曾经的支付宝首席架构师、支付宝第一代架构设计者，以及支付宝史上最大危机——2008年1月1月停机发布17小时——的救火大队长，能够说若是说没有程立，就没有如今的支付宝。在蚂蚁金服入门手册《拾念》中，记载了支付宝史上最惊心动魄的17小时：2008年元旦，支付宝宣布要停机8小时发布“财务三期”，但各类意外接连出现，当时“财务携款潜逃”、“湿抹布致使服务器宕机”的传言满天飞、没有包裹送的快递小哥发帖跪求支付宝快点回来，程立在关键时刻敲了近两个小时的代码，最终结束了17小时的停机发布。

程立讲述了SOFA的诞生历史：最先的支付宝系统，是由还不太会大系统开发的人员实现的，像程立刚从学校出来就作支付宝第一代架构，所以第一代系统很是简单——就是一个简单的应用，装在一台应用服务器上，使用一个数据库，服务一个大客户淘宝。一个简单的系统，支撑了支付宝从2004年到2006年早期的发展。支付宝早期的系统架构虽然简单，但好处是特别快，产品经理但愿怎么改、立刻改一下代码就能实现了，好比说支付宝红包，从需求提出到上线就四天的时间，可是到后面，这样一个简单系统没法支撑更多的交易量，也不能支撑更加复杂的业务。

从2006年末开始酝酿，那时候支付宝面临最大的一个问题是业务变得愈来愈复杂，而工程师数量愈来愈多，原来的系统被称为monolithic——即庞大的单体系统的意思。这个系统慢慢变得没法装载更多更复杂的业务逻辑，也不能让那么多工程师在一块儿并行的工做。当时，支付宝但愿能够成百上千个项目并行进行，并且每一个工程师能够不受干扰的工做，而当业务逻辑增长的时候，系统的复杂度不要成指数级上升。

因此，在2006年的时候，支付宝技术团队要作对将来的技术架构作一个选择，当时有两派意见：一派意见是向银行老大哥学习，老大哥已经走了十几年，这条路必定是安全的；另外一派意见是走一条新的路，即用分布式的架构去支撑将来的交易支付系统，而这条路在当时尚未人走过。这里的分布式架构，并非客户端/服务器时代的面向企业级的小规模分布式架构，而是在互联网时代的超大规模分布式架构。通过差很少大概一年左右的讨论和思考以后，支付宝团队作了一个决定，要走一条过去没有人走过的路，因而启动了支付宝第二代架构的建设，即支付宝技术系统的服务化。2007年开始，支付宝启动了对交易系统、商户系统、会员系统、支付清算系统的改造。

就在那一年，支付宝到大连招聘遇到了胡喜（花名：阿玺），他以前已经在前一家公司研究SOA以及OSGi相关技术，因而就加入支付宝团队，帮助程立作下一代架构的转变。胡喜回忆，他在2007年加入支付宝团队的时候，研发人员都比较痛苦。当时的支付宝使用的是阿里巴巴的统一技术框架WebX。WebX是阿里自研发的一套基于JavaServlet API的通用Web框架，在阿里巴巴集团内部普遍使用，2010年末向社会开放源码。WebX比较偏向于先后端融合的架构，能快速搭建一个网站，可是没有考虑到业务发展到必定程度后的复杂度，怎么更好的搭建后台。例如，当时支付宝的一个电子钱包系统叫iWallet，每次系统启动就得五六分钟，开发人员出去抽根烟，回来后若是发现错误又得修改后从新启动，开发人员天天不是在代码编译的过程中，就是重启的过程中，一个系统包含了几十个工程，十几个团队并行开发，项目并发也致使了不少的合并冲突和耗时，整个研发效率低下致使很难进行下去。因而，从那开始就着手研究解决支付宝整个架构的变化。

▲ 蚂蚁金服副总裁、副CTO 胡喜

程立给当时要作的这套分布式架构起了一个“SOFA”的名字，其背后有两个含义：一是按照当时的技术趋势，要作面向服务的架构，即ServiceOriented Architecture，但加入了金融业务，因此是Service Oriented Fabric Architecture；二是但愿可以像沙发同样，让工程师能够很是爽地工做。因此当时出于这么简单的考虑，就开始打造SOFA。所谓SOA和服务化改造，就是把企业的IT系统以“服务”的方式从新组织起来，再经过“服务总线”链接起来造成可插拔式的企业IT架构，这个架构就是SOA。这里要注意的是，SOA实际上是一套面向传统企业IT的架构思想，并且在SOA早期则只有理论框架而无具体的成功实践。

第一代的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 设备的过程。

“整个过程能够说一路狂奔。”杨冰后来回忆整个过程。“‘萝卜’就这么几个，坑那么多，根本就填不过来的状态。每一个中间件产品连‘一个萝卜一个坑’都作不到，不少‘萝卜’是放在两个三个坑里面的状态，你就想有多挑战了。其次，每年都是翻一番的业务指标倒逼。整个团队的状态基本上是一年大促结束后，春节一过就开始密集准备下一年大促，一眨眼的功夫离双十一就没几个月了，不少系统的技术改造可能要到六、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在技术上已经成为常态化工做，知足交易业务已经成为了最基本的要求，因此咱们要看到更远的将来、准备迎接更强的挑战。”杨冰的话，从一个侧面解释了蚂蚁金服技术团队对开拓更辽阔数字金融世界边界的期待。

“谢谢分享，你会一直作技术吗？”

“会的。”

长按关注，获取最新分布式架构干货

欢迎你们共同打造 SOFAStack https://github.com/alipay