新版统一支付技术解决方案Word格式文档下载.docx

新版统一支付技术解决方案Word格式文档下载.docx

《新版统一支付技术解决方案Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《新版统一支付技术解决方案Word格式文档下载.docx（27页珍藏版）》请在冰豆网上搜索。

1.1.需求分析6

第2章.总结架构7

2.1.系统伸缩性7

2.2.逻辑架构8

2.3.技术架构10

第3章.核心组件11

3.1.层11

3.1.1.负载均衡11

3.1.2.管理及缓存15

3.2.应用层16

3.2.1.服务框架16

3.2.2.注册中心21

3.2.3.消息框架22

3.2.4.数据缓存28

3.3.数据访问层29

3.3.1.29

3.4.管理层30

3.4.1.系统监控告警30

3.4.2.网络管理31

第4章.关键技术32

4.1.系统扩展32

4.2.缓存访问接口32

4.3.前后端事务一致性32

第5章.软件部署33

5.1.部署结构33

5.1.1.简单式基本型33

5.1.2.分布式扩展型33

5.2.部署方式33

5.2.1.手工化部署33

5.2.2.自动化部署33

5.2.3.服务化部署33

第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.高可用

服务器