深度剖析：支付宝和银行的本质差异决定了OceanBase不适用于银行

分布式架构已成为银行在不断探索和小心实践的架构模式，未来，银行能不能像阿里一样采用全分布式架构？

社区专家 Linux2 的这篇文章揭示了银行和支付宝在业务应用场景上的本质区别，以及OceanBase技术应用于银行业务的局限性。将帮助你更清晰地理解相关问题。

何种架构才是银行的正确选择？我们从三个方面来分析论证。

一，分布式与集中式数据库的分别

在业务体系上，支付宝和银行在业务逻辑、监管方式、数据要求上完全不同；业务决定技术，这也造成了不同的技术路径。需要强调的是，尽管两种不同的技术路径，但技术原理却是相同的。分布式和集中式数据库各有优缺点，也就各有不同的适用环境。 

2002年，麻省理工学院MIT的教授在数学上证明了CAP理论。在分布式计算（存储）的架构里，由于网络引起的时延是必然的（Partition Network Toleration），因此对于一个操作在数据一致性（C=Consistency）和数据可用性（A=Availability）方面必须取舍一个。 

许多互联网的业务类型（电商、搜索引擎等等），可以接受最终的数据弱一致性，因此分布式计算模式加数据可用的高扩展架构成为Web2.0公司的平台基础。而对于金融业需要数据实时强一致性的业务，采用关系型商业数据库来满足ACID（代表Atomicity原子性、Consistency一致性、Isolation隔离性、Durability持久性，是实现实时强一致性的基础）也是历史的正确选择。

分布式计算、集中式计算不是谁替代谁，而是各有不同的用点，适合不同的业务场景需求。互联网应用确实将分布式计算带到了新的台阶，但是并没有突破计算机科学的CAP基本原理，因此有时候需要牺牲数据一致性换得处理能力的线形可扩展性。而银行业务需要注重数据的实时强一致性采用集中处理，在一个统一的唯一数据视图上进行横向和竖向的扩展来满足业务的吞吐量要求。所以银行的架构是集中和分布的综合体。

选择完整性/可用性（C/A）保证数据的强一致性事务处理交易，是银行在过去的三十几年的业务发展过程中要求遵循的基本架构及编程原则。采用数据库、交易管理中间件从系统级提供的数据强一致性，简化业务应用的编程使其致力于业务功能的实现是银行过去的最佳实践。因此，集中式计算体系依然至关重要。在支付宝交易中，这种保持数据弱一致性非事务处理交易，采用分布式计算则是最经济的选择。同理，与银行核心交易无关的外围业务也可以采用分布式架构，未来银行的架构一定是一种集中式和分布式混合体系。

二，平台型轻应用和纵向重度应用——支付宝和银行的本质

从两者本质上看，阿里有着互联网企业的重要特征：业务逻辑是平台型的轻应用，即商家卖货，消费者买货，阿里本身不涉及货；支付宝也是消费者和商家之间的买卖并行交易，支付宝本质是交易工具，本身不靠资金的多少生存。

而以商业银行为代表的金融体系则是靠资金来生存发展的，它的业务逻辑则是典型的重应用：比如银行业务从资产负债表的构成就主要分为三类：存款、借款、债券等负债业务，储备、投资、信贷、放款等资产业务，以及支付结算、基金托管、银行卡、担保、理财等中间业务。

因此，银行一定要做集中式处理，这不是简单的金额加减问题，要涉及到客户账，分户账，会计总账等系列后台逻辑数据的变更，所有的账务系统要有相应的规则统一管理。借和贷必须在一个逻辑处理事务单元实时完成并保证ACID。

而阿里的支付借和贷之间是脱钩的，个人支付宝帐户的扣款和商户的支付异步进行。支付往往滞后帐户扣款。因此仅仅是银行交易的一半途径且不遵循复杂的会计体系原则。

因此，两者的业务应用场景在本质是有区别的：支付宝只是做了支付这一步，而银行在支付的背后，需要有整个帐务逻辑和金融风险管控。后者要求每一步操作，不论是查询还是交易都必须有可跟踪的、有时间戳的日志。如果在银行帐务系统的处理上采用网上购物这种数据弱一致性非事务处理交易架构，错账、乱帐的风险会提高，由此产生金融风险、法律纠纷的风险提高。记得在银行未实现数据大集中之前，银行业务对帐的时间就很长，帐务出现差错，要追帐，查帐，纠错的压力也就相应而来。

三：OceanBase技术在金融业的适用分析

近几年，关于OceanBase数据库技术撑起双十一交易量的一系列媒体报道曾经引发热议，甚至有些报道中把它和异地多活也联系到了一起。那么这个承载电商海量交易的数据库能否为大规模银行联机事务处理系统带来帮助？甚至如某些宣传所说把事务处理推向异地多活？

（媒体报道截图）

经过多年对该技术发展的跟踪关注，以及对当前技术架构的剖析，还须认识到从它的架构特征来说是不适合承载银行大规模联机事务处理的。尤其不适用于随机更新交易需要数据实时强一致性的银行业务。银行业务需要实时帐务信息及会计规则、监管规则管控信息的统一视图。

单点更新架构的局限对电商业务负载和银行交易负载影响不同

OceanBase发布的文档表明，尽管OceanBase的分布式集群架构由多台服务器组成，但更新服务器（UpdateServer）是集群中唯一能够接受写入的模块，主要用于存储增量数据。同一时刻只有一台机器作为主更新服务器提供写服务，OceanBase的文档指出“单台更新服务器的处理能力总是有一定的限制。因此，更新服务器的硬件配置较高，如内存较大、网卡及CPU较好。”由此可以看到，执行更新服务的这个单点不但没有超越依靠追加硬件资源提升数据更新性能的纵向扩展路线，而且它还不能像DataSharing并行处理技术那样，在单台服务器硬件达到升级瓶颈时，通过横向扩展继续提升处理容量。 

从业务负载特征上分析，OceanBase设计的出发点是满足查询交易占绝大多数，更新交易比例偏低的电商业务需求。因此它的设计思路就是把查询负载分发到多个静态数据服务器（ChunkServer），而把更新负载引导到单一的动态数据服务器（UpdateServer），这的确能够把写少读多的电商交易量支撑到相当业务规模，甚至满足金融行业的部分需求，例如历史数据查询。然而在银行联机事务处理中：即使通过柜面系统做一个账户余额查询的操作，往往后台系统也需要在数据库里记录下这个操作历史。这样高密度的数据库写入操作会使得OceanBase利用单点实现更新操作，且不支持横向扩展的架构问题严重地暴露出来。 

一致性和高可用性难以兼得

OceanBase发布的技术文档表明：“当主 UpdateServer发生故障时：如果不要求强一致性，OceanBase内部可以自动做主备切换；如果要求强一致性，OceanBase内部不做自动切换，等确认数据没有丢失后再强制把某个备UpdateServer设置为主。”

显然这里一致性和数据服务的高可用性已经产生了冲突。这对银行业务意味着很大的风险，绝大多数银行关键业务系统既要求强一致性，又要求高可用性。一般都建立本地高可用环境，在单点故障时自动切换，保障业务连续运行，因此OceanBase的自动主备切换以牺牲一致性为代价不可取。

银行交易必须同时满足一致性和可用性。唯有确保交易数据的实时强一致性，否则造成金融风险后果是不堪设想的。银行系统由于需要承担社会民生稳定不可或缺的金融基本服务，因此其系统的设计比起电商的交易系统而言更加的复杂，在业务监管方面要接受银监会、外管局、公安局等多个部门的监管，业务必定要合规。例如，某部门列出一个黑名单，银行在每个关键点（比如存取款业务）都要检查，更何况这些年对反欺诈、反洗钱等的监管要求。所以说，即便是交易量同等规模，支付宝的复杂度远远比不上银行的复杂度。

综上所述，不难看出何种架构才是银行的正确选择。

本文出自社区活动“银行重要系统升级换代如何进行架构规划与设计”，针对问题“未来核心银行的架构发展趋势：集中式（主）+分布式辅 VS.全分布式 VS .分布式（主）+集中式（辅）？”的讨论。

欢迎点击阅读原文参与活动，分享观点

长按二维码关注“AIX专家俱乐部”公众号