怎样对城商银行业务系统平台服务器进行集中整合？

在业务体系上，互联网电商和银行在业务逻辑、监管方式、数据要求上完全不同；业务决定技术，这也造成了不同的技术路径。分布式和集中式数据库各有优缺点，各自在不同的适合领域里发挥平台优势。

2002年，麻省理工学院MIT的教授在数学上证明了CAP理论。在分布式计算（存储）的架构里，由于网络引起的时延是必然的（Partition Network Toleration），因此对于一个操作在数据一致性（C=Consistency）和数据可用性（A=Availability）方面必须取舍一个。许多互联网的业务类型（电商、搜索引擎等等），可以接受最终的数据弱一致性，因此分布式计算模式加数据可用的高扩展架构成为Web2.0公司的平台基础。而对于金融业需要数据实时强一致性的业务，采用关系型商业数据库来满足ACID（代表Atomicity原子性、Consistency一致性、Isolation隔离性、Durability持久性，是实现实时强一致性的基础）也是历史的正确选择。

不同的业务可以选择不同的架构，各有各的优点，各有各的道，没有哪一种架构可以放之四海皆准。一般来说，前端应用采用分布式来架构更经济些（如用PowerLinux整合前端应用），后端数据库服务器则是整个系统平台的“心脏”，更需要平台可靠性、可扩展性和安全性的品质保障（如用LinuxOne整合后端数据库应用）。

首先来说说，x86服务器是否适合作为银行系统的核心数据库服务器平台？如前面所讨论，银行交易必须同时满足一致性和可用性，唯有确保交易数据的实时强一致性，否则造成金融风险后果是不堪设想的。因此，到目前为止，国内还没有听说过哪家大、中、小行勇敢的把核心数据库搬到分布式架构去尝鲜，这个风险不是某行长随便拍板就可以担当的了的。话说回来，x86服务器在业界内很少作为核心数据库服务器是有原因的，比如x86服务器单机整体故障率每年2%，x86服务器的可靠性低是核心数据库服务器的最大隐忧；再如，数据库一般属于I/O比较繁重的负载类型，而x86服务器另外一个致命的瓶颈在于I/O处理能力不强，导致 CPU利用率上不去的根本原因。正因为如此，这么多年来，小型机和IBM 大型机（包括IBM LinuxOne）凭借平台自身的卓越性能、以及硬件平台的稳定性、可靠性、可扩展性和安全性，风行银行系统长盛不衰的原因。

再说说数据库层的扩展性，从硬件部署角度看，一般分为横向扩展和纵向扩展，比如对于Oracle数据库，横向扩展可以用Oracle RAC，但是现实问题是，Oracle RAC的节点达到3个以上，整体性能急剧下降，且多个节点之间的通讯的性能消耗和延迟也很大，这也是市面上3节点（包括）以上的Oracle Rac架构不常见的原因。因此，数据库服务器虽然可以横向扩展，但是横向扩展能力毕竟有限，因此在选择平台也需要重点考虑系统平台的单机可扩展能力。

除了扩展性之外，银行系统在数据库平台选型时，一般还要关注硬件平台的可靠性、I/O吞吐能力、可扩展性和安全性。举个例子来说，众多用户选择IBM高端服务器LinuxOne用来整合众多数据库服务器，也主要是考虑硬件平台的优势。顺便掰扯一下，IBM LinuxOne是Linux系统平台的王者，有了IBM LinuxOne以后，再也没有人敢说Linux系统的硬件平台不够稳定和可靠，IBM LinuxOne秉承大型机50年的经典硬件设计，可以运行Linux系统，全面支持OpenStack、KVM等开源技术，CPU最多可以扩展到141颗，内存可扩展到10TB，服务器内部系统I/O总线带宽高达832GB/Sec，安全认证达到EAL5+（民用计算机最高认证），并且价格也跟普通的高端小型机相差不多（真是物美价廉）。再提一下，在LinuxOne服务器上运行z/VM系统（虚拟化的鼻祖，是PowerVM和VMware的爸爸），可以非常方便的实现在线动态横向或纵向扩展，且LinuxOne内部的通信是通过内存交换，特别适合Oracle RAC节点之间的通信，不仅可以很好的缩短交易的响应时间和增加网络吞吐，还可以多一种稳定的心跳途径避开HA“脑裂”。