银行业务中台和阿里中台的异曲同工之妙

      阿里的“大中台”现在可以算是互联网架构中的一个标志了,通过多年的业务沉降,将核心业务能力逐渐抽象,成为公用性的中台,以实现互联网领域的快速响应机制。银行是传统行业中非常重视信息化的,而且起步早,信息化程度高,但是由于技术的高速发展,互联网思维的冲击使得银行纷纷面临必须转型的困境,既包括业务转型,也包括技术转型。互联网架构是银行很想学习的,但是二者之间差异较大,这在转型过程中是需要注意的。

 

      本人是业务架构设计人员,虽在单位做了六年企业级业务架构设计,但是技术方面能力有限,不足以完整比较互联网架构和银行架构,仅从“中台化”这个角度,谈谈银行如果建中台可能和阿里中台有什么不同。

 

一、阿里中台简介

 

      本人最近有幸参加了一次单位组织的阿里培训班,现场感受了“云栖大会”精英们对技术的理解。培训前后又读了子柳老师的《淘宝技术十年》和钟华老师的《企业 IT 架构转型之道:阿里巴巴中台战略思想和架构实战》,算是对阿里的中台概念有个粗浅了解。阿里的中台是个累积的过程,从 2009 年建立共享事业部开始,几经曲折,但是一直在积累,直到 2015 年正式发展成中台战略。可见,这是个演化过程,这也符合一般对架构的认知,大型架构、好的架构都不是一蹴而就的设计,是根据实践不断磨合调整得来的。

 

      目前的阿里中台大约有十几个共享业务单元,包括用户中心、商品中心、交易中心等。淘宝、天猫、聚划算等 25 个大型业务应用都是由中台的共享业务单元支持的,共享业务单元则由阿里云平台支持。共享业务单元的划分原则其实不是可以简单掌握的,要综合考量设计、运营和工程因素,尽可能遵循“高内聚、低耦合”、“数据完整”、“业务可运营”和“渐进”的原则。阿里在划分中台时非常重视其业务价值和基于业务的设计,而且有业务架构岗位,每个共享单元都有业务架构师。但总体来讲,其业务架构仍然是领域性的。这点在本人与阿里专家的交流过程中,他们也认为阿里仍然缺少更高一层的抽象,但是显然这一层比较难于设计和维护。

 

      阿里系统要解决的核心问题是高并发、可扩展,因此,业务通过中台进行共享支持后,基础设施必须能够消解这种压力。阿里采用去中心(也就是去 ESB)的 HSF 分布式服务框架,以支持服务的点对点调用,解决 ESB 可能产生的瓶颈问题;采用微服务设计方式,提高变化响应;自研设计了分布式数据层框架 TDDL(Taobao Distributed Data Layer)以及分布式数据库 DRDS;研发了支持分布式事务处理的 AliWare TXC;支持高效故障定位和运维监控的鹰眼平台;实现了限流和优雅降级设计,以及做保障的全链路压测平台、业务一致性平台。这是一套完整的基础设施,提供针对电商业务特点的支持。

 

      总结起来,阿里中台是其自身在业务不断发展的过程中演进和磨合出的架构,其架构即体现了电商的业务特色,也包含了完整的技术支持体系。由于其灵活支持和快速响应能力,成为了互联网架构的优秀实践案例和设计标杆。

 

二、银行的中台可能会怎么建?

 

      银行在与互联网企业的竞争中倍感压力,在金融科技的浪潮下纷纷推进数字化转型工作,这个过程中,自然想要学学互联网企业,特别是阿里这类头部企业的经验。阿里的中台提高了服务的复用能力和开发效率,银行是否能参考构建一个通用框架呢?要注意哪些区别呢?

 

      银行如果尝试构建金融行业通用框架,首先要解决的是流程问题。电商的中台其实更容易抽象些,阿里的十几个共享业务中心其实非常具有行业通用性,电商的在流程方面比较容易接受改变,在阿里提供大中台支持的前提下,无论是阿里内部还是输出给其他同业客户,流程方面都会比较容易接受改进,电商领域是在比较接近的流程下,寻找能力上、服务上的特色。

 

      但银行却不是这样,银行的能力是高度同质化的,但是流程却各不相同,因为流程的背后是组织结构和部门利益,各个银行之间部门设置和职责边界都是有差别的,按照康威定律,这种差别会直接体现在系统结构上。银行都想谈转型,但真能为此大动干戈、大幅调整组织结构的很少,就是采购商用软件,也通常是按照自己的部门结构进行本地化改造,将组织烙印深深地打在系统上。

 

      这种差别下,银行的中台沉降过程可能会更多地面向功能沉降,在流程与能力解耦的原则下,将流程分离成微服务架构层,但是剥离可通用的能力作为中台服务层,而不一定适合像阿里那样构建为业务中台,因为吸收变化的点不同。

参考的架构图如下:

 

 

      银行多是以产品驱动的,这点在设计上其实并不是一定要随着“以客户为中心”这种导向而改变,因为产品即服务、服务即产品,并不需要太纠结。

 

      产品通常意味着会驱动后台的一系列服务和功能。在 ESB 下,这是不同服务间的信息流转,其实阿里去掉 ESB 并不意味着银行也都要去掉 ESB,这要看实际需要,如果没有那么大的并发量、没有那么严重的堵塞要担心,也就没必要非干掉 ESB,尤其是在银行自己已经使用熟练的情况下,毕竟微服务架构下是否一定排除 ESB 也是有不同声音的。消息队列下,其实一个产品就意味着相关服务的一组订阅发布。

 

      然后可以将银行的产品按较大的流程环节进行微服务切分,这种流程可能会在不同的银行有差别,有些业务 A 银行有预处理过程,B 银行却没有;有些流程,A 银行一个部门搞定,B 银行却要两三个部门协作。这些差异可能是内部文化的原因,也可能是规模的差异。而一个银行自己也可能会随着规模的变化、业务重点的变化而调整,其实“能力”变化不大,但是流程却可能变化较大。所以,将流程环节设计成一个微服务层,便于快速变化。

 

      再将可以相对稳定的业务功能,比如示例中的久期计算、缺口计算之类的较为通用,和评级计算、EVA 这些相对有变化,但不需要非得和流程搅在一起的功能,可以考虑沉降为中台服务。服务尽可能无状态,以方便迁移和改造。

 

      数据则是企业级后台。微服务的处理结果准实时更新至企业级数据库,中台服务可以在企业级数据库中查询准实时数据,实时数据则可由调用方提供。

 

      上述过程是以通用框架为目标进行描述,但如果是银行自主研发,自研自用,一样也可以参考。

 

      银行学习互联网架构还应注意,阿里中台是按照 BASE 原则的最终一致性设计的,而银行传统上是采用 ACID 的强一致性。

 

      上述建议是围绕中台化开展的讨论,银行学习互联网架构,还应注意一个非常重要的差别,但是这个不在技术范畴内,这就是企业的组织结构和内部文化。阿里的中台是与其组织结构和企业文化共同成长的,如果想要移植其设计并且具有阿里的效果,那首先自己的内部要过关,技术也是有其生长土壤的。阿里对业务架构的重视,也恰恰是很多银行需要认真思考的。

你可能感兴趣的:(架构沉思录,成神之路,业务中台)