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

分布式架构已经成为银行不断探索和认真实践的架构模式。未来银行能否采用阿里那样的全分布式架构？

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

银行选择什么样的结构才是正确的选择？我们从三个方面进行分析论证。

首先，分布式数据库和集中式数据库的区别

在业务系统上，支付宝和银行在业务逻辑、监管方式、数据要求上完全不同；业务决定技术，也导致不同的技术路径。需要强调的是，虽然有两种不同的技术路径，但是技术原理是一样的。分布式数据库和集中式数据库各有优缺点，因此适用环境不同。

2002年，麻省理工学院教授用数学方法证明了CAP理论。在分布式计算(存储)的体系结构中，由网络引起的延迟是不可避免的(分区网络容忍)，因此对于一个操作，需要在数据一致性(C =一致性)和数据可用性(A =可用性)之间进行选择。

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

分布式计算和集中式计算并不互相替代，但它们有不同的使用点，适合不同的业务场景。互联网应用将分布式计算带到了一个新的高度，但它并没有突破计算机科学中CAP的基本原理，因此有时需要牺牲数据一致性来换取处理能力的线性可扩展性。但银行业务需要注重数据的实时性和强一致性，采用集中处理，在统一、独特的数据视图上进行横向和纵向扩展，以满足业务的吞吐量需求。因此，银行的结构是集权和分权的结合。

选择完整性/可用性(C/A)来保证数据的强一致性是银行在过去三十年的业务发展过程中应该遵循的基本框架和编程原则。采用数据库和事务管理中间件，从系统层面提供一致性强的数据，简化业务应用的编程，使其致力于业务功能的实现，是银行过去的最佳做法。因此，集中式计算系统仍然非常重要。在支付宝交易中，分布式计算是维护弱数据一致性的非交易交易最经济的选择。同样，与银行核心交易无关的外围业务也可以采用分布式架构，未来银行的架构必须是集中式和分布式的混合系统。

第二，基于平台的轻应用和垂直重应用——支付宝和银行的精髓

从两者的本质来看，阿里有互联网企业的重要特征:商业逻辑是基于平台的轻应用，即商家卖商品，消费者买商品，阿里本身不涉及商品；支付宝也是消费者和商家之间的平行交易。支付宝本质上是一个交易工具，不依赖资金量生存。

以商业银行为代表的金融体系是依靠资金来生存和发展的，其业务逻辑是典型的再应用:比如银行业务主要从资产负债表的构成上分为三类:存款、贷款、债券等负债业务，准备金、投资、信贷、贷款等资产业务，支付结算、资金托管、银行卡、担保、理财等中间业务。

所以银行一定要做集中处理，不是简单的加减金额的问题，而是涉及到客户账户、子账户、总账等一系列后台逻辑数据的变更，所有的会计系统都要有相应的规则进行统一管理。借贷必须在一个逻辑交易单元中实时完成，并确保ACID。

但阿里的支付贷款和贷款是解耦的，个人支付宝账户的扣款和商户的支付是异步进行的。付款经常落后于账户扣除额。因此，它只是银行交易的一半，不遵循复杂的会计制度原则。

所以两者的业务应用场景在本质上是不同的:支付宝只是迈出了支付的一步，而银行需要支付背后的整个会计逻辑和财务风险控制。后者要求操作的每一步，无论是查询还是事务，都必须有一个可追踪的时间戳日志。如果在银行会计系统的处理中采用网购这种数据一致性较弱的非交易交易结构，错账乱账的风险会增加，财务风险和法律纠纷的风险也会增加。记得在银行实现数据集中化之前，银行查账需要很长时间，追账查账改错的压力也随之而来。

三.海洋基础技术在金融行业的应用分析

近年来，一系列关于OceanBase数据库技术支持双十一交易量的媒体报道引起了热烈的讨论，甚至有报道将其与异地多活动联系起来。那么，这个承载着电子商务海量交易的数据库能给大型银行的网上交易处理带来帮助吗？甚至像某些宣传者说的，把交易推到异地多住？

经过多年来对这项技术发展的跟踪和关注，以及对目前技术架构的分析，我们必须认识到，就其架构特点而言，它并不适合进行银行的大规模网上交易处理。特别是对于随机更新交易需要数据实时性和强一致性的银行业务，不太适合。银行业需要实时的会计信息，需要会计规则和监管规则控制信息的统一视图。

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

OceanBase发布的文档显示，虽然OceanBase的分布式集群架构由多个服务器组成，但UpdateServer是集群中唯一可以接受写入的模块，主要用于存储增量数据。同时，只有一台机器作为主更新服务器来提供写服务。OceanBase的文件指出，“单个更新服务器的处理能力总是有限的。所以更新服务器的硬件配置更高，比如内存更大，网卡和CPU更好。”由此可以看出，这种执行更新服务的单点，不仅没有超出依靠额外硬件资源提高数据更新性能的纵向扩展路线，而且在单台服务器硬件达到数据共享并行处理技术那样的升级瓶颈时，也无法通过横向扩展继续提高处理能力。

从业务负载特征分析，OceanBase设计的出发点是满足绝大多数查询交易和更新交易比例较低的电子商务业务需求。所以它的设计思路是将查询负载分配到多个ChunkServer，将更新负载引导到单个动态UpdateServer，确实可以将写少读多的电子商务交易量支持到相当的业务规模，甚至可以满足金融行业的一些需求，比如历史数据查询。但是，在银行网上交易处理中，即使通过柜台系统进行账户余额查询操作，后台系统也往往需要将操作历史记录在数据库中。这样的高密度数据库写操作，会让OceanBase使用单点实现更新操作，严重暴露出不支持横向扩展的架构问题。

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

OceanBase发布的技术文档指出:“当主更新服务器出现故障时:如果不要求强一致性，OceanBase可以自动在主备之间切换；如果需要强一致性，OceanBase内部不会进行自动切换，确认数据没有丢失后，会强制设置一个备份更新服务器作为主服务器。”

显然，数据服务的一致性和高可用性之间存在冲突。这意味着银行业务的风险很大，银行的大多数关键业务系统都需要很强的一致性和高可用性。通常，建立本地高可用性环境，在单点故障的情况下自动切换，以确保服务的持续运行。因此，OceanBase的自动主备切换并不是以牺牲一致性为代价的。

银行交易必须同时满足一致性和可用性。只有保证交易数据的实时性和强一致性，金融风险的后果是不可想象的。由于银行系统需要承担民生稳定不可或缺的基础金融服务，其系统设计比电子商务的交易系统更加复杂。在业务监管方面，必须接受银监会、外汇局、公安局等部门的监管，业务必须合规。比如一个部门列了黑名单，银行要检查每一个关键点(比如存取款业务)，更不用说近年来反欺诈反洗钱的监管要求了。所以，即使交易量是同一个规模，支付宝的复杂度也远小于银行。

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

本论文来源于社区活动“重要银行系统升级如何进行架构规划设计”，针对问题“核心银行未来架构发展趋势:集中式(主)+分布式辅助vs .全分布式vs .分布式(主)+集中式(辅助)？”讨论。