新一代银行核心系统是否有考虑分布式部署架构？

对分布式的不同理解，会产生不同的答案。
银行核心系统并适合部署于真正意义上的分布式架构。
在分布式架构中，包括几个环节：分布式应用，分布式存储，分布式数据库，其中重中之重是分布式数据库。
分布式事务数据库采用多种模式实现数据的分散存储，将数据库压力分散到不同服务器上。与集中式数据库相比，分布式数据库可以均衡交易负载，并采用高并发的架构提升系统的交易处理能力，而其统一的资源管理机制也使得数据库的性能扩展不再是设备的替换式升级，而是通过增加存储或计算节点来实现弹性升级。目前，分布式事务数据库在互联网应用场景下的探索取得了良好的成效和大量的实战经验，积累了很多成熟的技术应用经验。
但是，相比于传统数据库架构，特别是对于银行核心系统事务的高一致性要求，分布式事务数据库架构更加复杂，组成部件更多。通常，分布式事务数据库可分为中间件层、数据存储层和控制调度层。中间件层负责将数据按既定规则分发到多个数据存储节点上，并保证跨存储节点分布式事务的一致性；数据存储层用于数据的实际存储，执行原子SQL 操作和本地事务控制；控制调度层主要负责数据导入导出，备份恢复功能，以及对数据库集群的统一维护和管理。
2000年加州大学伯克利分校Eric教授提出原理：在一个分布式系统中，一致性、可用性、容错性三者不可兼得，简称CAP理论。而银行核心系统却是对事务的一致性有着100%要求的系统，因此并不适合分布式。
• ACID 是事务的四个基本特性：
• 原子性(Atomicity)
• 一致性(Consistency)
• 隔离性(Isolation)
• 持久性(Durability)
因此，我们的观点是：应该根据业务的特性选择合适的架构，而不是为分布式而分布式。分布式架构适用的是对一致性异常高容忍的互联网海量应用，对于银行核心而言：这两个场景都不存在。以某资产6万亿的股份制银行为例，日常核心交易量在6千万左右，采用Power 880，日常负载小于20%，对于常规的城商行，其体量和交易量估计是该数据的1/10，不必也无需牺牲一致性、增加复杂性，增加维护成本。

核心系统目前APP基本都是负载均衡的，很容易实现分布式部署。DB限于当前技术没办法完美实现分布式，目前第三代分布式数据库比如Oceanbase,TiDB还都处于探索中，完美的分布式部署一定要数据库支持分布式事物，确保强一致性。使用传统的oracle数据库，现阶段各行发展趋势主要是通过ADG实现读写分离，extend RAC实现双活。

目前，在城商行和民营银行均有分布式核心系统部署上线