山下烽火,云上江湖:蚂蚁SOFAStack是怎样炼成的?

SOFAStack:山下烽火 , 云上江湖
有人说 , 历史是由懒汉推动的 。
科技的演进史 , 其实就是人类不断偷懒的过程 。 我们懒得浪费体力 , 于是有了蒸汽机;我们懒得动笔演算 , 于是有了电子计算机;我们懒得随身携带现钞 , 于是有了线上交易和无接触支付……程序和信息成为这个时代的基底 , 服务和应用围绕着我们的指尖打转 。
我们从网络上索取一切 , 海量的数据和代码在赛博空间里奔流不息 。
突然有一天 , 构筑代码世界的工人们也犯懒了 。 为首的懒汉开始思考 , 能不能把一些通用的代码模块打包起来 , 供给上层随时取用 , 这样就省下了重复造轮子的力气 , 让敲代码也成为一种模块化的工作?
这一偷懒 , 就偷出了一个新概念:中间件 。
无人探索的道路
对普通人来说 , 中间件是一个很遥远的词汇 。
从技术层面来讲 , 中间件是介于基础设施和业务系统之间的特殊软件 。 程序员们别出心裁地构思了各种比喻:有人说它是建筑工地上的预制件 , 让工人不必从头开始搅拌水泥;有人说它是整合货源的中间商 , 让商家免于一次次询价比价的操劳……
基础设施和业务系统之间 , 有很多通信和集成方面的要求 , 让每个业务系统都去做一遍是很浪费人力的 。 蚂蚁集团高级产品专家马振雄这么说 , 大家都有这样的诉求 。
时势造英雄 , SOFAStack在蚂蚁集团应运而生 。
它诞生得悄无声息 , 初衷只是为了解救支付宝 。 那还是青涩年代的支付宝 , 没有琳琅满目的蚂蚁森林、花呗和健康码 , 用4个一就能概括它的全部:一个简单的应用 , 装在一台应用服务器上 , 使用一个数据库 , 服务一个大客户——淘宝 。
简单、轻快、便捷 , 这个系统支撑了支付宝从2004年到2006年早期的发展 。 但是随着交易量的攀升、业务的复杂化 , 支付宝很快遭遇了成长中的阵痛 。
从刚开始几十个人 , 后来几百人 , 到现在几千人的技术团队 , 在不同规模下的研发方式和组织方式都是不一样的 。 蚂蚁集团高级技术专家黄挺说 , 人一多 , 你发现不同的人写的代码会不一样 , 冲突也越来越多 。
概而言之 , 研发效率出现了问题 。
如果说从前的支付宝是一间平房 , 如今则要发展成一座城市 。 而每搭建一座建筑 , 工人都必须从头开始烧制砖块、搅拌水泥——没有挖掘机 , 没有液压锤 , 一切从手无寸铁开始 , 对以建设城市为己任的团队来说 , 这是完全不可接受的 。
举个例子 , 当时支付宝的一个电子钱包系统iWallet , 每次启动需要五六分钟 , 足够开发人员下楼抽一支烟 。 如果发现错误 , 就得修改后重新启动 , 开发人员每天深陷在代码编译和重启的死循环之中 。
究其原因 , 就是因为iWallet系统包含了几十个工程 , 有十多个团队并行开发 。 支付宝原本的系统无法支撑这么复杂的业务逻辑 , 也难以让那么多工程师在一起并行工作 , 大家把它称为monolithic——庞大的单体系统 。
支付宝的诉求显而易见:第一 , 希望成百上千个项目并行进行 , 每个工程师可以不受干扰地工作;第二 , 当业务逻辑增加的时候 , 系统的复杂度不要成指数级上升 。
它需要一套能够力挽狂澜的中间件 。
山下烽火,云上江湖:蚂蚁SOFAStack是怎样炼成的?
2006年 , 契机来临 。 技术团队在这一年开了一连串的会 , 会议的核心议题只有一个:决定支付宝未来的技术架构 。 团队内部分成两派:第一派提议向银行老大哥学习 , 走集中式架构的老路;第二派则认为分布式架构才能支撑未来的交易支付系统 , 而且不是客户端/服务器时代那种小规模架构 , 是互联网时代的超大规模分布式架构 。


推荐阅读