当今互联网时代，不管规模大小，但凡要上新一代核心系统前都会遇到是否应该建设分布式核心的技术辩论。可以说，正是因为互联网技术、互联网思维的突飞猛进，在一定程度上推动着中国金融体系自我改变，也使得中国的信息技术开始走到世界的台前。10年前银行核心系统还是外国的好，现在国内的银行核心系统在技术平台和业务模型各方面都已经优于海外产品。
回到本文主题，在我们仅千万级客户的银行核心系统选型中，是否也应该加入当前的互联网技术狂欢大潮，上一套全新的分布式核心应用？首先我们来对比分析不同应用架构模式的特点。
一、传统主从架构
如上图所示，早期应用系统大多采用热备方式，平时都在一台超高性能的主机上运行所有核心模块，当发生故障时再由另一台备用主机接替服务。这种架构下，通常要求单台服务器具有支撑峰值业务量4倍 的性能水平，否则就将银行的正常业务开展将面临严重威胁。基本上在6年前建成的核心系统较多采用此架构。
二、集群架构
随着Java的广泛应用，国内银行逐渐接受基于JAVA的核心应用，即使不是基于JAVA开发的核心产品，已大多已经具备集群化部署、服务化设计的架构思想。
如上图所示，核心各模块仍然在同一个应用内，采用并置式集群部署，这样一来通过增加应用服务器数量即可扩展处理能力。数据库层面也大多采用集群部署（例如ORACLE RAC），使得数据库的并行处理能力和冗余性都得到提升。这种架构在解决性能可伸缩性的同时，技术复杂度并没有显著增加，每次交易请求处理链上的各模块、各业务处理逻辑在实践上仍倾向于在一个服务器本地完成，以保证事物的简单性，使得在部署大量应用服务器的同时，不会导致事物不一致问题。这很符合传统银行对交易实时一致性的严格要求。
三、分布式架构
近段时间互联网化非常流行，银行核心系统的互联网架构长成什么样呢？目前从技术平台上来看，“互联网化”的重点并非是把银行核心放在互联网、云端运行，而是参考先进的互联网分布式架构的一系列设计思路，设计适合银行的核心系统架构。
在技术上，当前新型分布式核心系统架构主要着力于服务分层、服务分区、关联服务调用解耦以及数据库分库分表等方面，换句话说相对于把所有模块、服务都一揽子打包成一个应用然后再复制N套做成集群的架构模式，这一代的架构重点在于对核心内部服务进一步层次化、细粒化，然后按层次、模块分别打包成独立的小应用，每一小应用作为一个独立的部署单元，分离后的小应用之间可通过远程请求方式或共享服务组件方式完成跨应用调用。
如上图所示，核心系统内部服务走向微粒化、单一化、标准化，并根据粒度进行分层，上层完成对下层的服务组合。在设计服务时，不需关注所依赖的服务是否在本地，统一通过注册中心（或多级注册中心）完成服务寻址并调用。实际银行在实施时，由于银行自身的访问压力不足以需要复杂的多级、多片式服务分布部署，因此仍然会因对事务的一致性严格要求，在进行应用分包时尽可能包含所有依赖的服务，使其整个依赖链都在同一应用内部，这就使得分布式系统平台退化到了具备分组服务控制能力的集群应用架构，这一退化不仅规避了事物一致性问题，更重要的是后期运维成本也并没有实质增加。
综上，在技术平台上，核心系统架构可以做得非常复杂，然而于我们来说并没有什么实际用处，理性的选择就是积极地设计更先进、更完善的平台，谨慎地规划决策目标应用和部署架构。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。