银行建中台跟阿里建中台有什么不同？
付晓岩
讲述：杜力大小：2.03M时长：04:26
银行在与互联网企业的竞争中倍感压力，在金融科技的浪潮下纷纷推进数字化转型工作，这个过程中，自然想要学学互联网企业，特别是阿里这类头部企业的经验。阿里的中台提高了服务的复用能力和开发效率，银行是否能参考构建一个通用框架呢？要注意哪些区别呢？
银行如果尝试构建金融行业通用框架，首先要解决的是流程问题。电商的中台其实更容易抽象些，阿里的十几个共享业务中心其实非常具有行业通用性，电商在流程方面比较容易接受改变，在阿里提供大中台支持的前提下，无论是阿里内部还是输出给其他同业客户，流程方面都会比较容易接受改进，电商领域是在比较接近的流程下，寻找能力上、服务上的特色。
但银行却不是这样，银行的能力是高度同质化的，但是流程却各不相同，因为流程的背后是组织结构和部门利益，各个银行之间部门设置和职责边界都是有差别的，按照康威定律，这种差别会直接体现在系统结构上。银行都想谈转型，但真能为此大动干戈、大幅调整组织结构的很少，就是采购商用软件，也通常是按照自己的部门结构进行本地化改造，将组织烙印深深地打在系统上。
这种差别下，银行的中台沉降过程可能会更多地面向功能沉降，在流程与能力解耦的原则下，将流程分离成微服务架构层，但是剥离可通用的能力作为中台服务层，而不一定适合像阿里那样构建为业务中台，因为吸收变化的点不同。参考的架构图如下：
银行多是以产品驱动的，这点在设计上其实并不是一定要随着“以客户为中心”这种导向而改变，因为产品即服务、服务即产品，并不需要太纠结。
产品通常意味着会驱动后台的一系列服务和功能。在 ESB 下，这是不同服务间的信息流转，其实阿里去掉 ESB 并不意味着银行也都要去掉 ESB，这要看实际需要，如果没有那么大的并发量、没有那么严重的堵塞要担心，也就没必要非干掉 ESB，尤其是在银行自己已经使用熟练的情况下，毕竟微服务架构下是否一定排除 ESB 也是有不同声音的。消息队列下，其实一个产品就意味着相关服务的一组订阅发布。
然后可以将银行的产品按较大的流程环节进行微服务切分，这种流程可能会在不同的银行有差别，有些业务 A 银行有预处理过程，B 银行却没有；有些流程，A 银行一个部门搞定，B 银行却要两三个部门协作。这些差异可能是内部文化的原因，也可能是规模的差异。而一个银行自己也可能会随着规模的变化、业务重点的变化而调整，其实“能力”变化不大，但是流程却可能变化较大。所以，将流程环节设计成一个微服务层，便于快速变化。
再将可以相对稳定的业务功能，比如示例中的久期计算、缺口计算之类的较为通用，和评级计算、EVA 这些相对有变化，但不需要非得和流程搅在一起的功能，可以考虑沉降为中台服务。服务尽可能无状态，以方便迁移和改造。
数据则是企业级后台。微服务的处理结果准实时更新至企业级数据库，中台服务可以在企业级数据库中查询准实时数据，实时数据则可由调用方提供。
上述过程是以通用框架为目标进行描述，但如果是银行自主研发，自研自用，一样也可以参考。
银行学习互联网架构还应注意，阿里中台是按照 BASE 原则的最终一致性设计的，而银行传统上是采用 ACID 的强一致性。
上述建议是围绕中台化开展的讨论，银行学习互联网架构，还应注意一个非常重要的差别，但是这个不在技术范畴内，这就是企业的组织结构和内部文化。阿里的中台是与其组织结构和企业文化共同成长的，如果想要移植其设计并且具有阿里的效果，那首先自己的内部要过关，技术也是有其生长土壤的。阿里对业务架构的重视，也恰恰是很多银行需要认真思考的。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(1)
- 最新
- 精选
星星说到底还是要先抽象出合理的业务架构模型8
收起评论