建设银行的分布式架构探索：既放眼未来也兼顾当下

当前，国内大多数商业银行均采用大型主机构建核心业务系统，无论是基于大型机的集中式架构还是基于小型机的集中式架构，它的优势是技术成熟度高，运行比较稳定。

的确，这种传统封闭式架构一向以稳定可靠著称，但也面临着一些问题。例如，成本高昂无比，且核心技术均掌握在少数厂商手里，不利于银行自主可控的快速业务创新。

而x86平台、Linux系统经过近十年的发展，技术已经非常成熟，各种高可用方案也足以满足银行对安全性的高要求。同时随着竞争加剧，产品创新不断提速，开放平台相比专用系统，可以更加灵活地支撑互联网金融业务的发展。

中国建设银行的分布式架构探索

中国建设银行就进行了基于x86分布式架构的探索，对渠道类业务、查询类业务和大数据业务开始向分布式架构演进。

中国建设银行信息技术管理部总经理金磐石

中国建设银行信息技术管理部总经理金磐石在刚刚过去的金融峰会上表示，“首先建行通过业务分析，对于能够从集中式架构分离的，对数据一致要求不高的业务进行拆分。比如原来的客户信息管理的业务功能是集中在大型机，通过业务分析和组件化设计，定义了独立客户信息组件。我们把它从大型机上核心业务中分离出来，把它挪到分布式架构中。”

建行的分布式架构探索还用在其客户渠道的分库分表上，实施分库分表的高可用应用改造，从容支持应对电子渠道持续增长、数亿级的交易量和数据量。金磐石说，“比如我们的客户渠道，网银、手机银行是承担着大量交易，我们通过将一个公共数据库，把它拓展为多个同构的公共库，使数据分布存放成为可能。很简单根据客户ID取模对数据库进行垂直拆分，这样有效减少了高并发对数据库带来的访问的压力。通过这种应用改造，将同一个客户的缓存、限额包括过程流水都放在同一个数据库上，这样减少跨库的失误来保障客户体验。”

对银行核心账户交易，建行并探索数据强一致性过渡到数据最终满足一致的可能性。通过分阶段失误提交，异常错误检测和补偿这种机制来逐步将银行帐务系统转移到分布式架构中。

分布式架构是灵丹妙药吗？

的确，由于银行传统封闭架构自身在成本、可扩展、人力等方面的缺陷，再加上开源软件这两年的飞速发展、x86平台技术的日趋成熟，以及现有竞争环境和银行的需求，促使了一部分银行，或者是银行IT系统的某一部分开始从集中式架构迁移到开放平台。

但分布式架构是不是就是银行苦苦寻找的架构转型的灵丹妙药或最终目标吗？

“谈到分布式架构，实际是绕不开加州大学Eric Brewer教授提出的CAP理论，分布式系统不可能同时满足C、A和P三项需求。最多同时满足两个，其中C就是一致性，分布式系统中所有数据备份在同一时刻是否相同。A是可用性，就是要确保客户访问数据时得到及时的响应。P，就是代表分区容忍性，就是集群中的某些节点无法联系，集群整体是否还能继续服务。现在分布式架构分区容忍性是分布式系统基本特征，所以通常只能在一致性和可用性之间进行取舍，要么要一致性，要么要可用性。”金磐石说。

分布式的架构更强调方案细颗粒度的设计，需要业务及技术人员的深入理解和密切协同，由于更强调对底层核心技术的掌控能力，所以对人员的技能会提出更高的要求。

就像早前几年淘宝双十一出现的超售情况，其因为架构设计本身牺牲了实时强一致性来换取可用性，这就是分布式架构带来的负面的效果，这也可能是分布式架构目前没有在银行大范围使用的主要原因，金磐石说。

虽然建行成立专门团队着力推进分布式架构演进，“但稳定运行始终是高压线，现在国家对银行稳定运行要求是非常大的。超过半个事件，事件报银监会算四级事故，超过两个小时要报国务院，安全稳定运行是我们的高压线。在这种情况下做到我们分布式架构的转型，按这个方向做难度是非常大的。”

所以建行按照系统业务特点，分类分批来推进分布式架构的改造，逐渐实现混合型的架构到分布式架构的演进。当然，建行意识到这么大的架构转型绝对不是一日之工，就像金磐石所说的既要放眼未来也要兼顾当下。探索落地性过渡方案，改变原有业务逻辑，通过代码转换来实现大型机应用下移。