支付系统高可用架构设计-渠道网关高可用

沈凯  |  2016. 12. 07   |  阅读 2872 次
服务端

前言

原谅我是标题党,其实今天主要来是聊一聊支付系统中渠道网关系统部分的高可用,请忽略前半部分的“支付系统高可用架构设计”,这个范围太大,整个系统比较复杂,涉及到高可用的地方太多了,估计要讲清楚可以写一本书了,所以今天只是聊一聊直接与第三方支付平台或者银行产生交互的部分系统,也就是渠道网关系统的高可用设计。

支付渠道网关系统真的高可用吗?

如果只是从系统技术角度考虑,要做到高可用,可以将与第三方支付平台或者银行对接的支付渠道系统按不同渠道拆分独立的部署单元进行分布式部署,并做好HA,把使用到的数据库,中间件都做好HA。还不够?比如机房着火了?好吧,那就再做一个异地容灾方案,这样基本上就可以了。但是,还是会出现意想不到的情况,比如某天某个银行和你产生了仇恨,不给你提供服务了,或者就是银行发生宕机了,那怎么办?

然后就会有出现以下视频:

产品角度的高可用不容忽视

从产品角度来看,如果遇到上述情况----当遇到不可抗拒力量而导致第三方服务不可用,就是需要做一个备用的产品方案,比如实现一个与A银行功能一样的B银行支付渠道,这样在A银行不可用时候,可以切换到B银行。是不是很简单,但是确实很重要,谁知道哪天A银行就真不可用了呢?这时候,系统做得再好,单一渠道还是会面临这样的风险。

一个比较复杂的情况

上面提到的一个产品方案是一个简单的情况,具体实现中比较复杂的是出款渠道的设计,不仅要考虑单一出款功能的备用渠道高可用,还要考虑接口的高可用。接口的高可用,这边也是指的业务方面,不是技术上说的接口不可访问。这里需要一些业务知识,对于出款有如下情况:

  • 第三方平台已经帮你封装好接口
  • 需要自己根据情况调用不同接口

出现以上两种情况,具体与合作的第三方有关,要解决业务场景中的出款需求,可以走的接口根据不同第三方(银行)不同会有单笔代发、批量代发、行内转账、跨行转账等不同接口。 特别是遇到需要调用转账接口时候来实现出款业务场景时候,就需要考虑如下的一种情况:

上图所示,在设计这样的渠道时候,需要根据业务来调整接口,以保证接口的高可用。如业务需求要满足用户入账时效性,那么要考虑到金额和当前时间来调用不同接口以保证业务需求。如:小明在工作日晚上11点提现了3万元,考虑到时效性以及方便性(超级网银不需要提供支行信息)需要路由到调用超级网银接口可能是最合理的。为了解决这些问题,需要在系统上做一些改造。

第一代渠道路由系统-保证渠道高可用

终于可以说一些技术了,前面说了一堆的业务上的东西,接下来就要靠技术手段来解决这个需求。为了解决单一类型渠道问题,我们在渠道管理系统中加入了路由模块,然后把路由规则写入到本地数据库,这样做以最快速的方法解决了问题,但与渠道管理系统的耦合还是比较大。而且使用简单的js引擎来动态执行存入数据库的规则,可用性较差。于是就诞生了第二代的渠道路由系统,基于Drools规则引擎开发,将路由模块拆离渠道管理系统,并独立部署。

第二代渠道路由系统-解耦业务系统

主要通过http接口,让渠道管理系统调用路由系统的接口,来获取相应路由规则的决策结果(路由到哪个渠道)。通过该系统,解耦了路由决策功能,让这部分独立于渠道管理系统,并通过Drools规则引擎来强化复杂规则的配置,诞生了真正意义上的一个规则引擎系统。看起来完美,但是上线运行一段时间后,悲剧发生了,规则引擎系统(渠道路由系统)部署的机器都宕机了,因为jvm参数设置的问题,导致多机集群同时应用宕机。这些导致了很严重影响,因为渠道管理系统是通过http接口来调用路由系统的,而现在这一步出现故障了,导致所有用到路由功能的支付都不可用了。这显然能看出渠道管理系统对于路由系统还是强依赖的,虽然系统被拆离出去了,但是对于接口的依赖还存在。为了解决当接口不可用时,影响渠道无法正常使用的问题,我们研发了第三代渠道路由系统。主要是通过zookeeper来做服务发现以及解决路由系统不可用时,如何保证渠道还能正常路由使用。

第三代渠道路由系统-从特殊到一般

  • 服务发现能力:通过路由客户端+路由服务端模式来管理路由规则的自动注册和管理
  • 客户端缓存能力:客户端缓存规则解决即时服务端或zookeeper宕机情况下也能保证渠道可用

在具备以上两个能力后,路由系统也从特定功能推广到了更广泛的用途,渠道路由只是该系统的一个用途,这个系统也就可以成为大搜车的规则配置系统了。例如:一些业务系统的业务规则配置也都可以通过该系统来实现。

下一代规则系统scrule(souche rule)计划

目前该系统已经在大搜车支付服务中使用,考虑到将来对于多语言的支持,在下一个版本中底层引擎将提供更多版本引擎,如对Groovy脚本,Ruby脚本等的支持。

总结

本文从产品角度出发提供了一种解决支付渠道高可用的解决方案,并通过该方案如何设计一个高可用且与业务系统耦合性低的系统,并推广该系统功能从解决特殊问题到解决一般性问题的演进。具体对于规则系统的设计细节将在后续文章中写出,并在系统更成熟的时候,考虑开源该系统。

分享到

   
设计中的格式塔原则