最好的架构模式演进,应该是随着业务需求(需要解决的问题)引入的,而不是为技术而技术。核心系统的服务下移,实际上从开放式核心建设时期就开始了,如额度管理、押品管理、商业汇票(承兑、贴现、转贴)、国际结算、贷款核算等相关的服务、随着银行系统专业化的发展,而逐渐从核心系统剥离,形成所谓的瘦核心。事实上,不论是基于IBM主机的单体核心,还是开放式瘦核心,并没有遇到什么特别无法解决的业务问题。目前方兴未艾的云原生、分布式架构的核心建设,主要驱动因素还是在技术安全部分,在这一点上,与互联网行业面临业务爆炸式增长后,不得不依靠新技术来解决业务问题不可同日而语。
淘宝架构模式演进对商业银行的启示
《淘宝技术这十年》一书,对淘宝技术的演进路径做了较全面的介绍,书中可以非常清晰的看到淘宝不同业务发展阶段所面对的不同业务问题,以及由业务推动的淘宝技术演进。以下将书中的发展历程简要整理,并与商业银行同时期架构进行简单对比:
约2003--2004年,淘宝初创。当时面临的业务形态是日均PV不足百万,采用技术架构为LAMP架构(Linux+Apache+MySQL+PHP)--全站采用单体PHP应用,单台MySQL承载所有数据。其时,需要解决的业务问题是:快速验证商业模式,"能用"比"好用"重要。其技术架构示意如下(图片引用自书中原图):
与之对应,这一阶段多数商业银行已经完成大集中,其架构模式与淘宝一样,都是单体架构,只是