支付账户子系统三大功能模块实现

　　本文为第三方支付技术与监督，其中一章节，如需查看全文，请点击：《第三方支付技术与监督》全文

　　支付账户子系统主要由三个部分组成，预处理模块、业务接人模块和业务处理模块。

　　预处理的主要功能是参数作内存化,同时保证在操作人员修改参数时,系统能实时更新内存中参数的信息,提高系统的运行效率。业务接入的主要功能是基于交易类型的路由,通过业务接人调用相应的业务服务组件。一个业务处理由一个服务层的服务提供,业务处理主要有账户管理、账户交易两个子功能。账户管理是基础的工作，包括账户开户、账户锁定/解锁等一系列服务。账户交易是账户服务的核心,包括账户消费、退货、提现等一系列的服务。

　　账户系统涉及的业务类型较多,不同的业务类型交叉复杂,使用传统架构对设计人员能力经验要求很高,要求详细设计必须事无巨细,尽可能地考虑各种正常情况,还要考虑各种非正常的情况,这降低了项目的可控性,成本、工期人员及质量都很难保障,在测试、部署及运行维护都有不可预知的困难。基于消息的MDP模式,把不同业务进行分流,把高耦合的各个流程解耦,提高各个子流程的独立性,使复杂问题简单化,不但能够满足系统的需要,提高项目可控性,保证系统的维护性、健壮性,部署、测试及运行维护还更加简单高效。

　　1.消息发布订阅模式的预处理方式

　　为了加快系统的响应速度,需把一些常用的参数内存化管理,这样各子模块在需要这些信息时，可以不用从数据库查询数据,只要从内存中读取参数信息就可以了。预处理不仅在系统初始启动时需要加载参数配置信息,而且在系统运行过程中当参数配置信息发生变化时各个子模块需要实时加载更新的参数配置信息,这个问题虽然有很多解决方案，但是都不够完美,实时性、扩展性都不强。而采用消息的发布订阅模式，当系统参数配置变更时,配置信息变更模块作为消息的生产者实时地把这些修改的参数信息通知消息服务器,消息服务器负责把这些信息分发到需要更新配置的系统各个模块中,保证参数配置信息能实时保持一致,不出现脏数据、失效数据,而且方便子系统的灵活扩展。例如，创建“参数修改"的主题,接收配置参数修改的消息,再分发给各消息监听子模块,如充值服务、消费服务等,随后各子服务模块实时更新内存化参数。

　　2.点对点模式的业务接入

　　业务接人的主要功能是将各交易路由至各系统服务层的某个服务,为后续的服务处理做准备。支付账户子系统的交易分为管理类交易与账户类交易。账户管理类主要包括账户开户、账户锁定/解锁等交易;账户交易类主要包括账户消费、充值等交易。系统为每个交易提供一个全局交易代码,比如账户开户的全局交易代码是A0000,账户锁定的全局交易代码是B0000。全局交易代码在整个系统里是唯一的。

　　业务接人模块负责接入交易,把交易的外部形式(表单数据或定长报文)进行格式解析，转换成系统规范的内部形式(如JSON对象),再根据交易代码,路由到对应的服务中。

　　一个交易与一个交易代码对应,一个交易代码路由到下层的一个服务中。

　　通常情况下,面对如此多的业务,在开发过程中需要写很多的开关来控制业务的分流,即使在采用了目前主流框架Spring+struts的情况下,解决了分流问题，也不能解决业务处理灵活部署和监控的问题,增加了Web服务器的开销,在大用户量的情况下,必然成为系统的瓶颈。消息队列的架构既可以方便地对业务进行分流，也能够把业务处理模块灵活部署;既可以集中部署,也可以分布部署;既便于监控,也有利于后期维护升级。各个业务处理模块作为消息的消费者通过消息选择订阅自己感兴趣的消息,实现了业务分流,同时作为消费又可以灵活部署,易于监控。例如,系统初上线时,用户较少,把各个业务处理模块部署在一起,能够满足运营的需要,但是随着业务的拓展,用户数增加,集中部署就成为系统的瓶颈,这个时候就可以采用分散部署,把占用资源较高的模块独立部署，提高效率。此外,这种从集中式部署到分布式部署,不会明显影响前端业务受理的子系统,保证系统可以在线升级和维护。

　　在接人层,系统根据不同的交易类型,可将账户开户、密码修改、账户充值、账户消费等交易的消息分发至不同的消息队列。在服务层,通过基于MDP的异步消息的接收来监听各自对应的消息,进行业务处理,如注册服务监听账户开户请求的消息队列,负责消息的处理。

　　通过监控功能,可以对各种类型的交易队列进行监控,发现哪些交易在目前的系统中并发量比较大，是系统的瓶颈,有针对性地对此类交易进行处理。当请求队列过长,系统将暂时关闭自己的服务人口。这样不仅达到了服务进程的流量控制目的,而且能够防止因为某个组件的失败导致系统阻塞的蔓延。此外，当出现外部渠道通信故障或者响应效率低下时，要确保消息队列的畅通,可以进行必要的数据持久化。在系统中所有的服务都是分隔独立的,而且服务调用都是异步执行的,从而避免某个模块的出错导致整个系统的瘫瘓。另外还提供一种安全机制保证每个服务的执行时间不会过长，任何一个服务的出错,最多导致一个报文数据的丢失,这种出错由超时处理机制来发现并进行必要的冲正处理。

　　在消息的发送时,系统支持使用优先级策略保证重要的交易优先处理。一方面系统针对不同的交易设置不同的优先级,如账户注册的消息发送的优先级高于账户查询,账户消费消息发送的优先级高于账户开户。另一方面还可以根据特定的交易中不同特点设置不同的优先级别,例如在账户开户交易中,优质客户的账户开户比普通客户的账户开户的优先级高;在账户消费交易中,大额交易订单的账户消费比普通订单的账户消费的优先级高,大客户的账户消费比普通客户的优先级高。通过设置优先级,系统不仅支持了个性化的服务,提升了用户的满意度,而且保证了重要业务的处理速度。

　　3.基于异步消息的账户业务处理

　　账户子系统的业务处理涉及大用户量高并发的访问请求,单机很难满足需求,即使在多机分散部署的情况下,还存在一些额外的开销，比如数据传递路由选择,需要写代码进行路由选择,灵活性不够,同时维护升级影响比较大,即使增加一台服务器，也会影响到其他在用的系统运行。

　　消息服务器可以集群部署,提供高并发的特性,而且可以支持消息生产者、消费者的灵活扩展和部署。集群采用具有均衡负载功能代理Broker的集群方式,同时必须保证数据的安全,数据不能丟失,采用数据库作为持久化的存储介质,通过数据库集群解决Bro-ker集群数据存储的单点故障问题。账户消费是整个系统的核心，整个系统交易的一半以上都是账户的消费请求。而在账户消费这个业务之中,承担消息消费角色的消费者起到很大的作用,不仅需要提供接收消息的服务,而且还需要确认消息，因此可以使用消息预取机制提高消息的处理效率。

　　业务的处理主要由服务层的服务完成,交易路由到服务层后,便可以针对特定的业务进行处理。账户子系统提供的服务主要分为两类,账户基本信息管理和账户交易。一般情况下,在处理业务时大致可分为身份认证、风险认证.核心处理和账务处理四个过程。

　　各个过程紧密关联,需要数据交互,在消息总线架构中,数据以消息的形式传输,消息驱动可很好地解决处理过程的并行与串行。在所有业务处理服务中,账户消费服务最为典型，账户消费的序列下所示。

　　(1)身份认证

　　用户在账户消费时需要验证身份,用户输人用户名、密码等信息,用户身份认证之后，为了保证交易的安全性，还可以进一步进行手机验证,确保用户的真实性。此时系统需要向用户发送手机短信。采用异步消息队列的机制,向短信系统发送短信验证码消息,短信系统监听,并接收消息。这样不但加快了系统的处理时间,而且很好地解决了异构系统的整合问题。

　　(2)风险控制

　　风险控制功能主要为系统提供用户和商户的风险控制与风险案例生成。支付系统的风险业务主要来自于用户和商户。风险控制主要包含防钓鱼、黑白名单管理、交易限额管理、异常交易控制和可疑交易管理等。在处理风险时，调用系统的风险服务,使用基于MDP的异步消息队列机制,可以不影响账户子系统的实时交易处理。

　　(3)核心业务处理

　　核心业务处理采用基于MDP方式监听消息。

　　(4)账务处理

　　核心交易处理系统在受理外部交易后，会对非管理类交易进行实时记账处理。通过实时的记账和财务处理可及时地反映外部机构资金及账户的变动情况。核心交易处理系统在财务处理时,调用账户系统的记账接口,接口使用JMS消息队列的机制,不影响核心系统的实时交易处理。如出现记账的差错,则通过日终对账进行处理。