新版统一支付技术解决方案

新版统一支付技术解决方案

目录

第1章.项目理解 ........................................................................ 错误!未指定书签。

1.1.需求分析.......................................................................... 错误!未指定书签。第2章.总结架构 ........................................................................ 错误!未指定书签。

2.1.系统伸缩性...................................................................... 错误!未指定书签。

2.2.逻辑架构.......................................................................... 错误!未指定书签。

2.3.技术架构.......................................................................... 错误!未指定书签。第3章.核心组件 ........................................................................ 错误!未指定书签。

3.1.层...................................................................................... 错误!未指定书签。

3.1.1.负载均衡.................................................................. 错误!未指定书签。

3.1.2.管理及缓存.............................................................. 错误!未指定书签。

3.2.应用层.............................................................................. 错误!未指定书签。

3.2.1.服务框架.................................................................. 错误!未指定书签。

3.2.2.注册中心.................................................................. 错误!未指定书签。

3.2.3.消息框架.................................................................. 错误!未指定书签。

3.2.

4.数据缓存.................................................................. 错误!未指定书签。

3.3.数据访问层...................................................................... 错误!未指定书签。

3.3.1................................................................................... 错误!未指定书签。

3.4.管理层.............................................................................. 错误!未指定书签。

3.4.1.系统监控告警.......................................................... 错误!未指定书签。

3.4.2.网络管理.................................................................. 错误!未指定书签。第4章.关键技术 ........................................................................ 错误!未指定书签。

4.1.系统扩展.......................................................................... 错误!未指定书签。

4.2.缓存访问接口.................................................................. 错误!未指定书签。

4.3.前后端事务一致性.......................................................... 错误!未指定书签。第5章.软件部署 ........................................................................ 错误!未指定书签。

5.1.部署结构.......................................................................... 错误!未指定书签。

5.1.1.简单式基本型.......................................................... 错误!未指定书签。

5.1.2.分布式扩展型.......................................................... 错误!未指定书签。

5.2.部署方式.......................................................................... 错误!未指定书签。

5.2.1.手工化部署.............................................................. 错误!未指定书签。

5.2.2.自动化部署.............................................................. 错误!未指定书签。

5.2.3.服务化部署.............................................................. 错误!未指定书签。

第1章.项目理解

1.1.需求分析

统一支付做为各个使用系统的关键功能模块，承担着极其重要的交易角色，同时支付做为一个独立的产品，与任何业务系统无关，其中包括的功能有支付、退款、查询、对帐、报表等等，由于各个业务子系统接入支付的请求数量很大，对支付模块本身的设计、性能、响应、数据一致性、容错性、稳定性及可用性等提出了巨大的挑战。

第2章.总结架构

本解决方案假设业务管理子系统以千万级请求访问为基础，通过使用通行证以及认证的管理来实现各个应用的统一管理。本项目是基于互联网模式来设计，抛弃传统企业设计的厚重，大集中的理念，而采取互联网的轻薄，分布式的理念，分层分块，各个层次和组件各司其职、彼此协作，用层次化搭建的方式构建能力平台，形成当前适用，将来可扩展的模式。

考虑到本系统需要极大的访问量以及系统的未来可伸缩性，下面分别从展现层，应用层，数据层来阐述系统伸缩性的实现，从而实现互联网应用的3大特点：大并发、可伸缩、高可用。

2.1.系统伸缩性

所谓伸缩性就是在系统负荷大的时候，能够通过增加服务器/虚拟机来缓解压力；同样的，当不需要多台机器的时候，可以减少服务器的数量来。而这些改变，最终用户是透明的。

1、可伸缩性－前端

系统需要对外提供统一的访问入口，采用能很好的实现高可用、可扩展以及负载均衡的要求。提供负载均衡的能力，提供健康检查，故障转移，提高系统的可用性。采用这样的架构以后很容易对现有系统进行扩展，只要在后端添加或者减少服务器，只要更改配置文件，并能实现无缝配置变更。在本项目中建议采用由充当的职责，实现的的架构模式。

对的管理，在集群服务器不多时，可采用复制的方式进行扩展，因为广播式复制到其他服务器有一定延时，会带来一定网络开销；在服务器数据较多以及需要水平扩展的模式下，需要有新的管理模式：从服务器中被保存在缓存服务器中，所有的服务器对统一从存有的缓存服务器进行读写，分离了和服务器之间的对应关系，从而实现服务器的线性扩展。

2、伸缩性－应用层

应用层采用无状态分布式模式，借助服务框架实现展现层和应用层的前后端分离，另外应用层自身可根据业务的划分，分解为多个模块，实现把调用分解到各个服务器上，从而降低每台服务器的调用压力。

前端在调用后端服务的时候，先查询注册服务器，得到后端服务的节点、接口信息等，并把配置信息缓存在前端应用中，减少查询服务的次数，提高访问的性能。在注册服务器修改了服务节点和接口等信息，可以采用观察者模式，对各个客户端缓存的信息进行强制刷新。

数据层

【基于服务框架的分布式部署方式】

这里展现的是一种前后端分离模式的部署，前端是多台，后端是后台应用，通过服务框架对外提供统一的，有2个重要的组件：

1) 配置管理：（图中服务注册），前端订阅配置服务信息，后端注册自身的服务信息，

从而前后端感知，并通过某种客户端调用机制（轮询，分标示等）调用后端服务。 2) 缓存服务：（图中数据缓存），这里缓存存放的是根据业务查询出来的数据副本，通

过缓存，极大的提升系统的响应速度，减少后端服务器的配备。

3、 伸缩性－数据库层

考虑到系统请求巨大，对应的数据量很大，对于交易记录表采取表拆分模式，即创建若干个一样的表，只是名字有所区别，当一张表存储到了一定的业务量，就重新创建新的表来存入数据，从而支撑系统随着业务量增长来扩展。

之前提到的只是表拆分，对于极大数据量还可以进行数据库拆分的模式，数据库的伸缩有几种方式，还可以组合使用，一般来说有读写分离，垂直分库，水平分库等。从可实施步骤可以遵循如下步骤： + → + 读写分离 + → + 垂直分库 + ，从而实现在保证性能的前提下，极大数据的支撑。

这里需要对数据访问层进行功能扩展，支持分表访问，数据分库读写，数据合并，数据路由等功能。

2.2. 逻辑架构

支持大规模访问和支持线性扩展的系统逻辑架构如下图：

其特点如下： 1、 总体分为5层

1) 负载均衡层：使用作为负载均衡的能力

2) 服务器层：由服务器和服务器组成，实现前端的展示和架构的无状态性。 3) 应用服务器层：由应用服务器和配置中心组成，承载后端的业务逻辑和支持前

后端分离模式。

4) 缓存层：这里主要是数据缓存，存储静态数据和常用数据，并由业务逻辑维持

缓存数据和数据库中数据的一致性。

5) 数据层：由数据访问层和数据库，文件系统，文档数据库组成。其中对于关系

数据库的读写支持分库分表的模式。

2、 前后端分离模式：分为前端和后端应用，通过配置中心来获取后端服务的位置和接

口信息。并允许前端和后端添加或减少服务器，由配置中心把更新的信息推送到前端的调用方。

3、 双节点，保证高可靠：对于关键节点，包括负载均衡器，缓存，数据缓存，配置中

心以及数据库均采用双机模式。 4、 三级缓存：

1) 缓存：存储静态页面和图片，加快用户访问速度。

2) 缓存：存储在缓存服务器中，并采取主从互备模式保证高可用，剥离了和服务

器的对应关系从而使得前端能线性扩展。

3) 数据缓存：采用内存服务器，支持高速读写，支持参数数据和常用数据存储在

内存中，并通过业务逻辑的控制，把多次对数据库的读写改为在内存中读写，最后在把最终结果写回到数据库中，尽可能在内存中操作，降低对数据库的压力。

5、 支持数据分库分表：定制化数据库访问层，支持多数据库路由寻址，数据查询合并

等功能，也支持库内分表增删改查的能力。考虑到本子系统总体数据量并不大，而是单表数据库巨大，可采取对巨大表拆分的方式，加快对数据的增删改查的处理能力，也支持表的持续拆分，实现数据量的扩充。

2.3.技术架构

从技术层面来看，系统分为前端展现和后端逻辑两大部分，后端逻辑包括业务逻辑，服务框架、数据访问层部分：

1、前端展现：采用轻量级框架，提供基于的设计方式。

2、后端逻辑

1)业务逻辑：业务逻辑实现的主体，在上图范例中展现3个业务模块。调用方式

有如下3种：

(1)自己实现所有逻辑：逻辑处理在业务逻辑内完成，只是调用数据访问层实

现数据的持久。

(2)调用本地组件：业务组件和业务逻辑在同一的虚拟机中，通过统一接口实

现调用。

(3)调用远程组件：业务组件和业务逻辑分布在不同的虚拟机，出于性能考虑

还可以部署在多台虚拟机上，通过服务框架实现远程调用，而对上层应用

屏蔽实现的差异性

2)服务框架：实现了分布式服务框架实现各服务与服务间的高性能和透明化的远

程调用，实现的服务治理。

3)数据访问层，提供对底层资源的访问，包括关系数据库，文档数据库和对文件

系统的访问。

第3章.核心组件

3.1.层

3.1.1.负载均衡

3.1.1.1.功能

负载均衡服务器采用最新的1.8.0 稳定版，并对之前版本的进行了增强。增强主要包括：动态管理、负载调度算法、请求的保持等。对于详细功能的介绍请参照相关资料。

1．动态管理

通过共享内存实现配置数据与内存数据的交换，从而实现动态更新服务配置信息的功能，在服务不重新启动或重新加载前提下，实现修改工作进程内存配置数据，修改后的配置数据将会立即生效。下图为动态配置管理流程图。

2．调度负载

在内部按照后端应用类别对承载应用的服务器（）进行分组，接收到的请求后，从请求的信息中分辨所请求的后端应用类别，然后从对应的后端分组中选择合适的后端来响应请求。负载调度的流程如下图：

3．保持

通过指令来建立请求与后端之间的对应关系，解决请求过程中丢失的问题。

4．管理

通过功能，可以实现功能，解决用户网络与后台服务器网络提供商不同而访问太慢的问题，并可以缓解后台服务器的访问压力。工作流程如下：

缓存处理示意图

对于缓存的时间，在中定义缓存时候就必须指定统一失效时间

然后在的中，针对不同的返回状态，指定统一失效时间

在后台服务器返回的数据中，可能会包含缓存失效时间否

否

是是

收到请求

计算

判断是否

已经缓存判断缓存

是否过期

读取缓存文件头

向后台发出请求

缓存收到的数据读取缓存数据

回复请求

3.1.1.2.架构

下图为架构示意图。

从上图可以看出，当1向1发出请求时，主要完成以下操作：

1.在接收到请求后根据请求的确定承载1的一组服务器；

2.通过负载调度模块从“1”服务器组中选择合适的服务器（如：2服务器）；

3.向2服务器发出请求；

4.将2服务器的返回结果返回给1。

3.1.1.3.性能

从数据显示，采用，支持的并发可在30,000以上，足以胜任100,000每分钟的并发支持（每秒1700），通过的集中管理，通过水平添加服务器的方式，控制在每台服务器在400～500的并发，并支持线性扩展。

3.1.1.

4.高可用

能很好的实现高可用、可扩展以及负载均衡的要求。提供负载均衡的能力，提供健康检查，故障转移，提高系统的可用性。采用这样的架构以后很容易对现有系统进行扩展，只要在后端添加或者减少，只要更改配置文件，并能实现无缝配置变更。在本项目中建议采用由充当的职责，实现的的架构模式，通过暴露虚拟（配置绑定域名）的形式对内容网站进行访问。

3.1.2.管理及缓存

3.1.2.1.功能

因为协议的无状态性，需要在上下文中保持状态，因此就产生了以及的管理问题，管理根据实际情况有集群复制、模式等，由于应用服务器复制的成本开销太大，所以超过5台以上的应用服务器集群，不建议使用复制策略，推荐使用模式管理

3.1.2.2.组成

，无状态共享模式，一种大规模开发模式，

不是放在各自的应用服务器内存中，而是存在统一的缓存服务器，应用服务器均可共享，可实现服务器的线性扩展，解决传统集群不能超过5台的限制。（复制，性能降低）

可以采用或者构筑中的服务器，缓存用来减少磁盘，加快访问速度，

3.1.2.3.性能

由于数据存在于内存中，同时控制好数据量，性能很大程度上依赖于硬件设备

3.1.2.

4.高可用

服务器（或者）可考虑双机热备或多机集群负载，多台设备之间

保持心跳，提高可用性的同时，又能软负载均衡。

3.2.应用层

3.2.1.服务框架

分布式服务框架实现各服务与服务间的高性能和透明化的远程调用，实现的服务治理。

服务框架通过对基于长连接的框架抽象封装，提供端对端的、能进行软负载容错的远程通讯，同时基于注册中心服务，使服务使用者能动态查找服务的提供者，使地址透明，达到服务的统一管理和平滑伸缩扩展的能力。

3.2.1.1.功能

结构示意图

高可用

1.监控中心宕掉不影响使用，只是丢失部分采样数据。

2.注册中心对等集群，任意一台宕掉后，将自动切换到另一台。注册中心全部宕掉后，服

务提供者和服务使用者仍能通过本地缓存通讯。

3.服务提供者无状态，任意一台宕掉后，不影响使用。服务提供者全部宕掉后，服务使用

者应用将无法使用，并无限次重连等待服务提供者恢复。

4.注册中心、服务提供者、服务使用者三者之间均为长连接，监控中心除外。注册中心通

过长连接感知服务提供者的存在，服务提供者宕机，注册中心将立即推送事件通知消费者。注册中心和监控中心全部宕机，不影响已运行的提供者和消费者，消费者在本地缓存了提供者列表。注册中心和监控中心都是可选的，服务使用者可以直连服务提供者。

高性能

1.注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动

时与注册中心交互，注册中心不转发请求，压力较小。

2.监控中心负责统计各服务调用次数，调用时间等，统计先在内存汇总后每分钟一次发送

到监控中心服务器，并以报表展示，消耗很小。

3.服务提供者向注册中心注册其提供的服务，并汇报调用时间到监控中心。

4.服务使用者向注册中心获取服务提供者地址列表，并根据负载算法直接调用提供者，同

时汇报调用时间到监控中心，这样调用没有时间损耗。

高扩展

1.注册中心为对等集群，可动态增加机器部署实例，所有客户端将自动发现新的注册中心。

2.服务提供者无状态，可动态增加机器部署实例，注册中心将推送新的服务提供者信息给

消费者。

3.当服务集群规模进一步扩大，带动治理结构进一步升级，需要实现动态部署，进行流动

计算，现有分布式服务架构不会带来阻力。

3.2.1.2.系统架构

服务框架是一个面向服务的体系结构（：）：

Registry

架构图

●暴露服务方称之为“服务提供者”，是一个服务实现的实体，它接受和执行来自服

务消费者的请求。它将自己的服务和接口描叙注册到服务注册中心，以便服务使用

者可以发现和访问该服务。

●调用远程服务方称之为“服务消费者”,是一个应用程序、一个软件模块或需要一

个服务的另一个服务。它发起对服务注册中心的服务订阅，通过传输绑定服务，并

且执行服务功能。服务使用者根据接口契约来执行服务。

●服务注册与发现的中心目录服务称之为“服务注册中心”，是“服务提供者”，“服

务消费者”的支持者。它包含一个可用服务的存储库，保存“服务提供者”的服务

注册信息，并允许感兴趣的“服务消费者”对服务进行订阅。实际注册中心实际

也扮演了服务提供者的角色，因为它提供的是对服务

●服务请求者定位服务．查询服务注册中心来找到满足其标准的服务。

●为了使服务可访问．需要注册服务，把服务描述信息注册到服务中心，以便使“服

务消费者”可以发现和调用它。

3.2.1.3.功能架构

分布式服务框架包括分布式调用、集群容错、配置管理、容器、服务注册、服务代理几个部分，实现高性能的服务调用和处理。

高性能通讯及多协议集成

●高性能通讯：提供对多种基于长连接的框架抽象封装，包括多种线程模型，序列化，以

及“请求-响应”模式的信息交换方式。

●多协议：服务框架支持不同服务不同协议和同一服务使用多协议暴露。比如：不同服务

在性能上适用不同协议进行传输，比如大数据用短连接协议，小数据大并发用长连接协议。

服务动态寻址与路由

基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。不再需要写死服务提供方地址，注册中心基于接口名查询服务提供者的地址，并且能够平滑添加或删除服务提供者。透明化的远程方法调用，就像调用本地方法一样调用远程方法，只需简单配置，没有任何侵入。

●连接控制：连接控制允许设置服务器端接受的最大连接数，客户端服务使用的连接数。

●回声测试：回声测试用于检测服务是否可用，回声测试按照正常请求流程执行，能够测

试整个调用是否通畅，可用于监控。

●延迟连接：延迟连接，用于减少长连接数，当有调用发起时，再创建长连接。

负载均衡与容错

提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持。软负载均衡可在内网替代F5等硬件负载均衡器。

注册中心

注册中心采用实现，是一个高可用的分布式数据管理与系统协调框架，基于对算法的实现，使该框架保证了分布式环境中数据的强一致性，从而解决了分布式数据一致性的问题。

3.2.1.

4.性能

服务框架是把系统进行拆分的基础设置，服务框架基于进行设计，性能比普通的有了极大的提高，已经在生产系统中部署，下面是测试的部分结果：

机器配置：

1)场景1：每次从服务提供者处返回一个大小为1的字符串，并发用户为100时，处

理能力最高，每秒处理的事务数达到5889；

2)场景2：每次从服务提供者处返回一个大小为10的字符串，并发用户为40时，处

理能力最高，每秒处理的事务数达到1070；

3)场景3：每次从服务提供者处返回一个大小为1的对象，并发用户为120时，处理

能力最高，每秒处理的事务数达到6196；

4)场景4：每次从服务提供者处返回一个大小为10的对象，并发用户为100时，处

理能力最高，每秒处理的事务数达到1024。

2、结论

测试和生产系统还是有差别，但测试数据可以作为参考的依据，根据以上的测试，每台应用服务器并发500毫无问题，对于2000的并发要求，只需要采取4台即可，因为调用不保留状态，所以支持线性扩展。

3.2.1.5.高可用

服务框架，在做远程调用不依赖于注册中心，客户端初始化将所有的服务提供者，下载到客户端的内存，在做调用就可以进行集群负载策略。

客户端通过代理进行执行远程方法，所有在代理层需要有作为远程调用的执行引擎，由来链路每一次远程的执行调用。在中有简易集群机制来选择每一次调用所采取的集群负载策略，可以在中进负载以及参数配置的优化处理。