银行建中台跟阿里建中台有什么不同？

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

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

本人最近有幸参加了一次单位组织的阿里培训班，现场感受了“云栖大会”精英们对技术的理解。培训前后又读了子柳老师的《淘宝技术十年》和钟华老师的《企业 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 的强一致性。

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

近年来，一个名叫 Fintech 的名词悄然兴起。互联网科技与传统金融行业的结合越来越深入，传统银行的互联网转型也迫在眉睫。作为投行交易系统定海神针的市场数据平台，有着怎样的技术背景？其架构设计又是怎样的？请在 InfoQ 后台回复关键词：银行，获取金融市场数据平台架构设计之道的干货文章。

注：请在公众号对话框回复关键词，留言区回复收不到链接哦~