• 极客专栏正式上线!欢迎访问 https://www.jikewenku.com/topic.html
  • 极客专栏正式上线!欢迎访问 https://www.jikewenku.com/topic.html

支付系统如何进行分布式改造?

技术杂谈 勤劳的小蚂蚁 3个月前 (02-07) 80次浏览 已收录 0个评论 扫描二维码

→ 传统支付系统面临的挑战 ←

随着近年来移动支付的兴起,如条码支付、声波支付、NFC 近场支付等……移动支付已经渗透到我们生活的每一个角落。

这就给传统的支付系统提出了新的挑战,用户量激增,系统容量和性能跟不上了,传统的架构往往以 IOE 技术为主,采用 scale up 方式以更强的硬件提升系统性能和容量,扩容成本将是巨大的。

分布式架构在容量、性能、稳定性、成本方面都具有巨大的优势。在高可用方面,核心思想之一是“解决一切单点”,单点容易出现故障,性能方面也可能成为瓶颈,因此需要将单点改造拆分成多个点。

→ 分布式改造之垂直拆分 

垂直拆分就是将原来一个整体的系统按业务模块拆分成多个系统,系统内部数据是自包含的,不会与别的系统共用数据库,系统与系统之间的交互通过暴露和调用服务来实现。

那么如何按照业务来拆分呢?
首先来看一下一笔支付过程是如何进行的:


  • 商户发起收单请求,经过 API 网关,调到产品层的“在线收单”产品
  • 调用收银台选择支付方式,也可能直接进入支付环节,创建交易流水
  • 进行支付处理,通过金融交换从银行扣客户帐,记录帐务流水,入商户帐,记录账务流水
  • 对交易按照费率进行收费,记录收费的帐务流水。此时会异步触发营销和风控策略
  • 日终会异步进行会计记帐(也有同步记会计帐的)、业会核对、清结算和对帐处理

从这个过程可以大概推演出支付系统的一般应用架构:

图:支付系统的应用架构

应用架构定义一个大型软件系统由哪些应用子系统构成,以及应用之间是如何分工和协作的。
从架构上来说,分为四层:

图:支付系统的分层

渠道层:商户和客户的交易请求的入口。包括以下系统:商户网站、用户网站、无线接入、API 网关。
产品层:通过基础服务层提供的服务组装成具体业务场景功能,对客户、商户运营等人员提供服务。
公共服务层:将各个产品都需要使用的些服务抽像成公共服务。一般会划分:收银台、交易支付、计费等系统。比如说产品层可以通过组装各种交易类型和收费规则形成不同的产品。
基础业务层:支付系统的核心,资金和客户信息的处理都在这里。一般会划分三大子系统:帐务核心、会计核心、会员核心。

▷其它支撑系统

网关:负责与银行、银联等金融机构进行资金交换,与外部合作伙伴接入,如渠道拓展商、行业客户等。
运营支撑:贯穿于四个层的是运营支撑域。一般会划分运营支撑、安全、风控、营销子系统。
垂直拆分本质上是服务化改造,除了上面讲的按业务拆分,还需要一套分布式服务框架的支撑。

分布式改造之水平拆分 ←

前面讲的垂直拆分只是把系统按业务模块划分到不同的子系统,数据库也分到了不同系统,但没有解决单表大数据量的问题,而水平切分就是要把一个表按照某种规则把数据划分到不同表或数据库里。简单的说就是做分库分表。

对数据模型进行分类,分为“流水型数据”、“状态型数据”和“配置型数据”。

  • 流水型数据:像流水一样不断增长的数据,各条数据间是独立的。如支付订单、交易流水、帐务流水(入帐/出帐)、会计流水等。
  • 状态型数据:代表一个对象当前的状态的数据。如会员信息、客户信息、帐户信息、会计帐。

  • 配置型数据:系统中用作为配置的数据。如产品、手续费率、分支机构信息、支付路由规则、会计科目等。

为什么有会员信息还有客户信息?
会员往往是注册在支付平台的用户,一个人可以注册多个会员,但是一个自然人只可能有一个客户信息。无论一个客户注册多少个会员,实名认证后都只有一个客户信息。

流水型数据会不断产生,且各条数据间是独立的,天然适合进行分库分表。
状态型数据读写比相当,每一次写操作必须基于前一个正确的状态,可以评估一下数据量的大小,数据量如果大或者要实现单元化架构,也需要进行分库分表,提高并发处理能力,同时方便隔离故障影响。

配置型数据,读多写少,强依赖读,弱依赖写,不要求严格的读一致性,且配置型数据一般数据量不会很大,不需要进行分库分表设计。

分库分表按照什么规则来拆分呢?
通常不会按实体 id 进行 hash 取模的方式来拆分。因为希望同一个用户的数据能够在同一个数据库中,尽量避免产生分布式事务。业界普遍的做法是通过用户维度来进行拆分。由于不同实体 id 的值不同,且不能保证每个实体和请求中都包含用户 id,所以简单的用实体 id 或用户 id 进行 hash 取模将不能保证同一个用户的数据都落在同一个分片。

一种推荐做法是,在用户创建的时候给该用户随机或一定规则(如地区)生成一个两位的分片号 00~99(两位意味着可以分成百库百表,通常够用了),那么在生成与该用户相关的所有实体的 id 的时候,都约定把这个分片号拼接到这个 id 中。
分布式数据访问框架中进行路由选择时,就可以取 id 中的分片号进行路由,而不依赖于用户 id。且在排查问题的时候也非常方便定位数据的存储位置。

下面是一个参考的 id 生成规则示例:

所以数据水平拆分除了需要一个强大的分库分表数据访问中间件,还需要一个分布式序列生成器。当然这个生成器也可以是集成在分库分表数据访问中间件中的一个功能。

那么如果一笔交易涉及多个用户按谁的 id 来拆分呢?比如一笔转账或支付,涉及转出方/转入方或支付方/收款商户。这种情况一般可以按资金转出方来拆分。

→ 分布式改造后带来的问题如何应对 ←

▷分布式事务产生

由于按用户维度进行了分库分表,可能存在跨数据库的事务,比如说,转账交易中转出方和转入方的账户不在同一个数据库中,这就产生了分布式事务。通常不会用 XA 协议来解决,因为 XA 协议锁资源性能太差,通常是通过 TCC 柔性事务来解决。

▷跨表查询如何解决

由于分库分表后,不能进行跨库的连表查询,原来的一些很常见的查询操作变得很麻烦。对于不是以用户为维度的汇总查询也非常麻烦。比如说支付交易流水是按发起方用户(支付方)进行拆分的,用户需要查询自己的账单很容易。但是商户要查询账单就比较麻烦了,要去所有的库里遍历、汇总、分页。也非常耗系统资源。所以一般会做一些数据冗余,例如专门实现一个账单系统,通过消息队列异步将用户的交易流水同步过来,T+1 跑批再按商户维度进行拆分,并生成商户账单。查询帐单都从帐单系统中查询。

还可以通过异构索引来查询和做 OLAP 分析,异构索引就是将数据同步到 ElasticSearch,利用 ES 的强大索引能力来做查询和分析,为了使业务更容易使用,可以利用数据访问代理层来屏蔽底层是路由到数据库还是路由到 ES。

▷如何进行数据同步

企业都有做大数据分析的需求,需要将数据同步大数据平台,如 Hadoop。分库分表之后,数据同步会比较复杂,毕竟之前是单表同步到 Hadoop 比较简单,但是 100 张表同步到 Hadoop 里会复杂一些。这时就需要设计一套专门的数据模型管理平台,数据模型、分库分表规则等由这个平台来管理,当需要使用数据的时候通过(应用/逻辑表)维度订阅数据即可,不用单独订阅物理表。不仅是数据同步,凡是有业务需要用到各种数据,都可以通过这个平台来订阅,帮助企业数据业务快速发展。

▷分库分表后批处理任务怎么处理

批处理任务,比如有日终对账、清算、生成账单等,原来在一个数据库中的时候,由一个应用 Server 去数据库中捞取流水就可以了。但是分库分表后流水都落在很多库里,一个 Server 去每个库里遍历显然不是一个很好的办法,且不能充分利用机器资源,提高批处理效率,甚至由于处理的数据量太大在日终低峰期内根本无法完成任务。

前面提到各条流水数据之间没有关联的,完全可以并发的进行处理,每个 Server 捞取一个分片的数据进行处理。那么就需要有一个很好的调度系统来协调,可以采用三层调度的方式。

图:三层调度示意图

  • 第一层 split:把任务按照分片规则拆分成多个 Load 任务,并发送到集群中的 Server 去执行。
  • 第二层 load:每个 load 任务捞取一个分片的数据,逐条创建 execute 任务,并发送到集群中的 Server 去执行。注意:捞取数据要进行流量控制以免数据量太大把集群打满。
  • 第三层 execute:执行具体的一条数据的逻辑。

三层架构并不是说一定都需要三层,可以根据业务逻辑来定制只有两层也可以。

▷如何进行数据扩容?

通常可以采用“预分配”的方式来做,即一开始就按一个比较长期的容量来规划分片数,比如百库百表。但实际上一开始并没有这么大的量,所以实际只有两个数据库 Server,在这两个 Server 上分别建 50 个 schema,逻辑上仍然是 100 个分库,物理上只有 2 个数据库 Server。
当容量不够的时候,为了保证数据的均衡,通常会采用成倍扩容的方式,再加两台数据库 Server,然后分别迁移 25 个 schema 到这两个数据库 Server 上,数据也搬过来。

由于数据同步有延时,全量数据同步完成后,两边的 schema 都禁写,待增量数据同步完成后打开新的 schema 写,会产生短暂的部分用户交易失败,重试一下即可,在低峰期做迁移,产生小范围失败一般是可以接受的。由于逻辑分片数没有变化,扩容成本比较低。通常不会用改变分片规则的方式来扩容,因为改变分片规则需要进行数据重新分布,成本和风险巨大。

▷如何进行容灾?

  • 同城容灾:通常可以同城多机房部署应用,数据库只有一个机房处于 Active 状态,所有机房的应用都连这个机房的数据库,另一个机房的数据库为备库,进行主备复制,当备机房发生灾难时业务不会中断,但业务会跌一半,当主机房发生灾难时,数据库切换备库,会有短暂的业务中断。
  • 异地冷备:应用也是异地多机房部署,由于异地网络延时不可忽略,异地备机房是处于 standby 状态,正常是没有流量的,冷备机房采用数据库主备同步的方式同步数据,这种方式灾备切换时间长,成本投入高。
  • 异地多活:应用采用异地多机房单元化部署架构,每个机房的应用都是可以提供服务的,单元内是自包含部署全量应用,每个单元服务多个分片的用户。由于异地网络延时是不可忽略的,数据层的容灾方案也是分“流水型”、“状态型”、“配置型”数据采用不同的容灾策略。

分布式改造后整个系统架构已经是服务化了,原来通常可以通过查本地日志来定位问题。


丨极客文库, 版权所有丨如未注明 , 均为原创丨
本网站采用知识共享署名-非商业性使用-相同方式共享 3.0 中国大陆许可协议进行授权
转载请注明原文链接:支付系统如何进行分布式改造?
喜欢 (0)
[247507792@qq.com]
分享 (0)
勤劳的小蚂蚁
关于作者:
温馨提示:本文来源于网络,转载文章皆标明了出处,如果您发现侵权文章,请及时向站长反馈删除。

您必须 登录 才能发表评论!

  • 精品技术教程
  • 编程资源分享
  • 问答交流社区
  • 极客文库知识库

客服QQ


QQ:2248886839


工作时间:09:00-23:00