文/神州信息金融科技分布式架构专家 薛春雨
提及2020年金融科技热词,“分布式转型”实属其一。金融行业迫切需要分布式技术,以应对业务转变,满足发展需求。而金融行业在进行分布式转型时,除了要关注应用层的分布式(以微服务的形式体现)外,数据层的分布式也是重要的组成部分,本文将把目光聚焦到数据的分布式。
分布式的核心理念是把大的拆分为小的,然后用多个物理节点去承载,但所有的加在一起在逻辑上还是完整的一份。具体到数据层面也是一样,但具体的数据拆分又分为“垂直切分”和“水平切分”两种大的类型,所谓的垂直切分更多的是将不同业务功能所使用的“表”拆分到不同的数据库中,一般更多的是跟微服务配合起来使用,如下图所示:
<图1 数据垂直切分>
而水平切分则是把“表中的数据”按照一定的策略进行拆分,所以其主要是解决表数据量大的问题,如下图所示:
<图2 数据水平切分>
本文的数据分布式是针对“数据水平切分”的方式来谈的。
数据分布式的发端与尝试
追溯数据分布式的最早使用,就不得不提当年建行的南北中心,当时建行把全国的数据分为南北两个中心,然后每个中心的业务系统只访问各自中心的数据,如果出现跨南北中心的转账的话,就在行里模拟银联转账的方式通过消息队列进行处理。但从数据的视角来看,其已经是将全行的数据按地域的维度拆分为两部分,所以说,其应该算是数据分布式的最早应用。
2014年,国内第一家民营银行——微众银行正式成立,由于其主要处理互联网线上业务,并且有腾讯的引流,所以其必然要面对大数据量的挑战,所以在系统建设的时候,微众银行采用了单元化的设计理念,将行内所有数据按客户号拆分为多份,每一份用独立的数据库承载,并且每个分库的数据只能被固定的应用所访问,如下图所示,其中上述的固定应用+具体的分库组成一个DCN,也就是一个单元体。在这种架构体系下,所有的服务请求进来后,都首先访问“GNS”,由其告知该到哪个DCN中执行,所以“GNS”在整体架构中的位置就非常重要,对其的稳定性、可靠性、性能,以及映射关系有变化后的数据一致性等,都提出了很高的要求。
<图3 数据分布式的单元体模式体现>
由于各个单元体完全隔离,涉及到多个单元体的交易的逻辑处理就会变得更复杂。例如最常用的“转账”的处理逻辑基本如下:
<图4 单元体模式下的转账流程示意图>
上图中红色相关字体描述部分都是跟该架构有着密切的关系。在金融业务场景中还有一类业务,就是其交易访问中是不带客户号的,例如,查询一个月内的新开账户,由于其不带客户号,也就无法通过GNS把请求下发到具体的DCN,并且这种业务所查询的数据,一般都是覆盖所有分库的。所以,微众银行的处理思路是:把这种业务当做分析统计类的业务,通过把所有分库的数据归集在一起,针对这种业务就直接查询“归集库”(见图3中的灰色部分)。据了解,微众银行已经逐渐将这里的“归集库”用TiDB数据库进行替换。
这种“单元化”的思路,更像是一个全行级的架构,究其根本,其实是数据分布式的一种解决方案,只是在整体架构级来解决的。但架构只负责数据的拆分及提供路由支持(通过GNS体现),其他的问题全部交由业务或者系统架构来处理(“归集库”就是一个体现),所以才会造成了业务实现和系统架构都会比较复杂。但不可否认的是微众银行确实是国内在数据分布式领域的第一次大规模的应用,虽然我们现在来看这个架构还是有一些值得商榷的地方,但在2015年,行业内分布式才刚刚起步的时候,这种设计理念已经是朝分布式方向的一次大胆尝试,也间接推动了国内金融行业分布式的发展,是数据分布式领域一个重要的里程碑。
数据分布式的落地探索
在数据分布式的探索过程中,各种解决方案百花齐放。其中,比较主流的实现方式有如下几种:
1、分布式数据访问组件
“单元化”是从整体架构的视角解决问题的,但同样的是进行“数据水平切分”,另一种典型思路是在应用架构内部解决。传统的系统实现基本都是应用直接访问数据库,这种方案的初期,业务开发人员一方面要实现业务逻辑,同时还要考虑应该访问哪个具体的分库,所以代码非常复杂,对人员的能力要求也比较高。因此,思路调整成将 “数据的分布式存储及访问”的功能从业务代码中剥离出来,实现对业务代码的低侵入甚至无侵入。“分布式数据访问组件”在这样的背景下逐步发展,随着这种模式的不断发展,其功能不仅可以保证最典型的包含分片键的SQL的处理,逐渐对不包含分片键的比较复杂的SQL的支持度也越来越高,当然对业务的侵入度也越来越小。这种模式下数据的访问模式基本如下图,其中深蓝色部分就是“分布式数据访问组件”位置:
<图5 分布式数据访问组件模式>
“组件”模式可以简单理解为是对传统的数据访问组件进行升级,以实现数据分布式的访问的能力,但其实内部的复杂度也比较高,对业务系统访问数据库的整体链路没有产生影响,也没有增加额外的网络开销,并且对原有的数据库DBA资源及运维体系也基本没有影响,所以算是一种非常轻量、高效的实现方式。
2、分布式数据访问中间件
为了减少对业务逻辑的侵入,逐渐形成了“分布式数据访问组件”的模式,但由于其嵌入在业务系统内部,所以,在运行期间仍需要占用应用的运行资源,对一些比较复杂SQL的处理还是受一定的限制,因此中间件的模式逐渐衍生,把“分布式数据访问组件”实现的功能从应用系统中剥离出来,独立部署。这种模式看似简单,但独立出来后就需要考虑应用跟中间件的通讯(包含以什么协议,对业务几乎没影响),并且内部对复杂SQL的处理复杂度非常高。基于该模式大致的运行机制如下:
<图6 分布式数据中间件模式>
“中间件”模式最大的优点就是在应用系统之外,可以独立多节点部署,可以被多个应用系统使用,并且由于其运行资源独立还可以进行比较复杂的SQL处理,理论上比“组件”模式SQL的支持度要高。但同样由于是独立部署,在调用链路中就增加了一来回网络交互,按基本的网络情况来计算,需要0.5ms的额外开销,虽然只有0.5ms的消耗,但一般一个命中索引的信息查询,也基本上就是0.5～1ms,所以,如果从单个SQL的总耗时来看,基本要翻倍。用银行的活期存入来说,相同SQL数量的前提下,假如之前的单笔响应时间是40ms,如果按照中间件模式的话,基本就要到70～80ms了。虽然分布式强调的是在大数据量的基础上整体处理能力的提升,但具体到单笔交易的响应时间如果影响太大,一般客户还是不太容易接受的。
3、基于MySQL的分布式数据库
中间件模式,理论上后端使用的数据库可以是各种常用的数据库,但一般更多的是跟MySQL进行对接,“分布式数据中间件”跟“MySQL数据库”整合在一起的方案应运而生,使之变成一个分布式数据库的产品独立销售,其不仅具备“分布式数据中间件”的能力,同时还提供完整的MySQL数据库的集群管理能力,以及配套的各种完备的工具,同时由于跟MySQL数据库紧密整合,在一些功能的实现机制上,可以跟MySQL进行比较深的定制,这也是其相对通用的中间件模式的一个优势。但是整体来看,其在本质上跟中间件模式并没有太大区别。具体如下:
<图7 基于MySQL的分布式数据库模式>
这种模式最大的优势就在于其以一个完整的数据库对外提供服务,尤其是相对中间件模式+MySQL数据库的方式,该模式不仅提供了数据分布式的能力,而且还提供了比较专业的MySQL的集群及运维管理能力。但这种模式跟中间件模式一样都要面对至少一来回(跟不同的厂商的实现机制有关)的额外网络开销,在SQL支持度方面理论上两种无太大差异。
4、基于全新数据库理论体系的NewSQL数据库
前面提到的各种方式都有一个前提条件,就是基于现有成熟的关系型数据库。但这种模式完全是一个原生的分布式实现,其将分布式的理念直接应用到数据库内部的计算及存储机制上,使其天生就具备分布式的基因。下图是TiDB的架构,可以看出在实现机制上其跟传统的数据库有着非常大的区别。
<图8 TiDB的整体架构>
基于这种模式,应用系统可以完全把其当做一个数据库来看待,但其内部同样需要进行分布式数据的计算,以及分布式数据的存储等。具体如下图:
<图9 基于NewSQL数据库的模式>
基于全新数据库理论体系的NewSQL数据库模式无疑是最先进的模式,由于其采用全新的设计理念,但让使用者又可以按照之前传统的方式来使用,所以,在一些细节层面跟传统模式还是有一定差异的,所以在使用的过程中还是需要深入理解,否则在使用的时候还会出现一些问题。另外,这种模式毕竟是一种新生事物,所以其发展还是需要时间来不断完善,至少在现阶段对金融行业的支持仍有不少需要继续提升的地方,但这也符合事物发展的规律。还有一点就是这种原生的分布式实现,其实是有一个潜在的前提,就是对网络以及磁盘的存储等方面要求都是比较高的,但是随着硬件领域的快速发展,这些问题迟早都会被低成本的解决掉。其实,影响这种模式落地还有一个方面,就是其毕竟是新的事务,银行如果要使用的话,就必须有对应的DBA资源,以及比较成熟的、完备的运维管理体系。比较庆幸的是,相关数据库厂商也在积极推进相关生态圈及知识体系的建设工作。
如何选择数据分布式的实现方式
以上多种数据分布式的实现方式,主要差别是实现的位置不同,“单元化”模式是在整体架构的入口实现的,“组件”模式是在应用架构中实现的,“中间件”模式是在应用和数据库之间实现的,后面两种都是直接在数据库层面实现的。但不管是在哪个层级实现,大部分的思路都是把数据分布式的问题集中解决,对业务系统尽可能透明,在SQL支持度方面尽可能跟直接访问传统的关系型数据库保持一致。但是分布式的设计理念注定了其解决的主要矛盾是大数据量的关系型数据的问题,所以相对传统的关系型数据库,其有些SQL在分布式体系下实现的难度还是比较高的,这跟在哪层实现没有必然关系,即使是在数据库层面实现的,同样对跨多个物理节点的数据表的关联查询、排序等都是非常消耗资源的。所以,在分布式体系下一定是有取舍的,在使用该项技术时在思想层面也需要与时俱进,大的原则一定是扬长避短。
另外,还需要根据业务场景进行结合,而不是坐而论道要求其100%的完美。就拿银行核心系统为例,一般比较大的表也就是客户、账户、交易流水等相关的表,所以,只需要将涉及这些表的交易进行梳理,然后对常用的重要的交易按照分布式理念进行重新设计即可,通常情况下对这几个表的操作,主要就是存款、取款、转账,以及客户、账户信息、交易流水查询等,这些交易几乎占到了这几个表所有交易的90%甚至更多。但这些交易基本都是具体到某个客户或者账户的,所以,即使是轻量级的“分布式数据访问组件”模式都可以又快又好的支持这种场景。就跟我们买一些其他产品一样,要求他的功能非常丰富,但买回来后发现用到的只有不到10%的功能。
未来,数据分布式何去何从?上面谈到多种模式,其实没有绝对的孰好孰劣,但从长远的发展趋势来看,NewSQL的模式一定是未来的方向,并且目前NewSQL还在往HTAP发展,其可以同时支持OLTP和OLAP的交易,对相关行业系统建设的整体架构也会带来比较大的改变。另外,其不仅是原生的分布式,也是云原生的重要组成部分,跟整个行业的发展方向也是一致的,但在当下,其还有不少功能需要不断完善,尤其是对金融场景的支持方面。另外,对于“组件”模式,由于其嵌入在应用内部轻量化的实现,并且性能最高,对SQL的支持度也基本满足常用的需求,所以在一些单个系统的建设方面也是非常方便的,其不需要单独采购一个分布式数据库,甚至整个数据库运维体系都需要整体升级。所以,笔者比较看好这两种模式,并且认为即使NewSQL逐渐成熟了,“组件”模式也会长期存在。
|
|
