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

《新版统一支付技术解决方案.doc》由会员分享，可在线阅读，更多相关《新版统一支付技术解决方案.doc（33页珍藏版）》请在三一办公上搜索。

1、新版统一支付技术解决方案文档标识：当前版本：0.1当前状态：草稿发布日期：2015/10/10发布修改历史日期版本作者修改内容评审号变更号目 录第1章. 项目理解61.1. 需求分析6第2章. 总结架构72.1. 系统伸缩性72.2. 逻辑架构82.3. 技术架构10第3章. 核心组件113.1. 层113.1.1. 负载均衡113.1.2. 管理及缓存153.2. 应用层163.2.1. 服务框架163.2.2. 注册中心213.2.3. 消息框架223.2.4. 数据缓存283.3. 数据访问层293.3.1. 293.4. 管理层303.4.1. 系统监控告警303.4.2. 网络管理3

2、1第4章. 关键技术324.1. 系统扩展324.2. 缓存访问接口324.3. 前后端事务一致性32第5章. 软件部署335.1. 部署结构335.1.1. 简单式基本型335.1.2. 分布式扩展型335.2. 部署方式335.2.1. 手工化部署335.2.2. 自动化部署335.2.3. 服务化部署33第1章. 项目理解1.1. 需求分析统一支付做为各个使用系统的关键功能模块，承担着极其重要的交易角色，同时支付做为一个独立的产品，与任何业务系统无关，其中包括的功能有支付、退款、查询、对帐、报表等等，由于各个业务子系统接入支付的请求数量很大，对支付模块本身的设计、性能、响应、数据一致性、

3、容错性、稳定性及可用性等提出了巨大的挑战。第2章. 总结架构本解决方案假设业务管理子系统以千万级请求访问为基础，通过使用通行证以及认证的管理来实现各个应用的统一管理。本项目是基于互联网模式来设计，抛弃传统企业设计的厚重，大集中的理念，而采取互联网的轻薄，分布式的理念，分层分块，各个层次和组件各司其职、彼此协作，用层次化搭建的方式构建能力平台，形成当前适用，将来可扩展的模式。考虑到本系统需要极大的访问量以及系统的未来可伸缩性，下面分别从展现层，应用层，数据层来阐述系统伸缩性的实现，从而实现互联网应用的3大特点：大并发、可伸缩、高可用。2.1. 系统伸缩性所谓伸缩性就是在系统负荷大的时候，能够通过

4、增加服务器/虚拟机来缓解压力；同样的，当不需要多台机器的时候，可以减少服务器的数量来。而这些改变，最终用户是透明的。1、 可伸缩性前端系统需要对外提供统一的访问入口，采用能很好的实现高可用、可扩展以及负载均衡的要求。提供负载均衡的能力，提供健康检查，故障转移，提高系统的可用性。采用这样的架构以后很容易对现有系统进行扩展，只要在后端添加或者减少服务器，只要更改配置文件，并能实现无缝配置变更。在本项目中建议采用由充当的职责，实现的的架构模式。对的管理，在集群服务器不多时，可采用复制的方式进行扩展，因为广播式复制到其他服务器有一定延时，会带来一定网络开销；在服务器数据较多以及需要水平扩展的模式下，需

5、要有新的管理模式：从服务器中被保存在缓存服务器中，所有的服务器对统一从存有的缓存服务器进行读写，分离了和服务器之间的对应关系，从而实现服务器的线性扩展。2、 伸缩性应用层应用层采用无状态分布式模式，借助服务框架实现展现层和应用层的前后端分离，另外应用层自身可根据业务的划分，分解为多个模块，实现把调用分解到各个服务器上，从而降低每台服务器的调用压力。前端在调用后端服务的时候，先查询注册服务器，得到后端服务的节点、接口信息等，并把配置信息缓存在前端应用中，减少查询服务的次数，提高访问的性能。在注册服务器修改了服务节点和接口等信息，可以采用观察者模式，对各个客户端缓存的信息进行强制刷新。【基于服务框

6、架的分布式部署方式】这里展现的是一种前后端分离模式的部署，前端是多台，后端是后台应用，通过服务框架对外提供统一的，有2个重要的组件：1) 配置管理：（图中服务注册），前端订阅配置服务信息，后端注册自身的服务信息，从而前后端感知，并通过某种客户端调用机制（轮询，分标示等）调用后端服务。2) 缓存服务：（图中数据缓存），这里缓存存放的是根据业务查询出来的数据副本，通过缓存，极大的提升系统的响应速度，减少后端服务器的配备。3、 伸缩性数据库层考虑到系统请求巨大，对应的数据量很大，对于交易记录表采取表拆分模式，即创建若干个一样的表，只是名字有所区别，当一张表存储到了一定的业务量，就重新创建新的表来存入

7、数据，从而支撑系统随着业务量增长来扩展。之前提到的只是表拆分，对于极大数据量还可以进行数据库拆分的模式，数据库的伸缩有几种方式，还可以组合使用，一般来说有读写分离，垂直分库，水平分库等。从可实施步骤可以遵循如下步骤： + + 读写分离 + + 垂直分库 + ，从而实现在保证性能的前提下，极大数据的支撑。这里需要对数据访问层进行功能扩展，支持分表访问，数据分库读写，数据合并，数据路由等功能。2.2. 逻辑架构支持大规模访问和支持线性扩展的系统逻辑架构如下图：其特点如下：1、 总体分为5层1) 负载均衡层：使用作为负载均衡的能力2) 服务器层：由服务器和服务器组成，实现前端的展示和架构的无状态性。

8、3) 应用服务器层：由应用服务器和配置中心组成，承载后端的业务逻辑和支持前后端分离模式。4) 缓存层：这里主要是数据缓存，存储静态数据和常用数据，并由业务逻辑维持缓存数据和数据库中数据的一致性。5) 数据层：由数据访问层和数据库，文件系统，文档数据库组成。其中对于关系数据库的读写支持分库分表的模式。2、 前后端分离模式：分为前端和后端应用，通过配置中心来获取后端服务的位置和接口信息。并允许前端和后端添加或减少服务器，由配置中心把更新的信息推送到前端的调用方。3、 双节点，保证高可靠：对于关键节点，包括负载均衡器，缓存，数据缓存，配置中心以及数据库均采用双机模式。4、 三级缓存：1) 缓存：存储

9、静态页面和图片，加快用户访问速度。2) 缓存：存储在缓存服务器中，并采取主从互备模式保证高可用，剥离了和服务器的对应关系从而使得前端能线性扩展。3) 数据缓存：采用内存服务器，支持高速读写，支持参数数据和常用数据存储在内存中，并通过业务逻辑的控制，把多次对数据库的读写改为在内存中读写，最后在把最终结果写回到数据库中，尽可能在内存中操作，降低对数据库的压力。5、 支持数据分库分表：定制化数据库访问层，支持多数据库路由寻址，数据查询合并等功能，也支持库内分表增删改查的能力。考虑到本子系统总体数据量并不大，而是单表数据库巨大，可采取对巨大表拆分的方式，加快对数据的增删改查的处理能力，也支持表的持续拆

10、分，实现数据量的扩充。2.3. 技术架构从技术层面来看，系统分为前端展现和后端逻辑两大部分，后端逻辑包括业务逻辑，服务框架、数据访问层部分：1、 前端展现：采用轻量级框架，提供基于的设计方式。2、 后端逻辑1) 业务逻辑：业务逻辑实现的主体，在上图范例中展现3个业务模块。调用方式有如下3种：(1) 自己实现所有逻辑：逻辑处理在业务逻辑内完成，只是调用数据访问层实现数据的持久。(2) 调用本地组件：业务组件和业务逻辑在同一的虚拟机中，通过统一接口实现调用。(3) 调用远程组件：业务组件和业务逻辑分布在不同的虚拟机，出于性能考虑还可以部署在多台虚拟机上，通过服务框架实现远程调用，而对上层应用屏蔽实

11、现的差异性2) 服务框架：实现了分布式服务框架实现各服务与服务间的高性能和透明化的远程调用，实现的服务治理。3) 数据访问层，提供对底层资源的访问，包括关系数据库，文档数据库和对文件系统的访问。第3章. 核心组件3.1. 层3.1.1. 负载均衡3.1.1.1. 功能 负载均衡服务器采用最新的 1.8.0 稳定版，并对之前版本的进行了增强。增强主要包括：动态管理、负载调度算法、请求的保持等。对于详细功能的介绍请参照相关资料。1动态管理通过共享内存实现配置数据与内存数据的交换，从而实现动态更新服务配置信息的功能，在服务不重新启动或重新加载前提下，实现修改工作进程内存配置数据，修改后的配置数据将会

12、立即生效。下图为动态配置管理流程图。2调度负载在内部按照后端应用类别对承载应用的服务器（ ）进行分组，接收到的请求后，从请求的信息中分辨所请求的后端应用类别，然后从对应的后端分组中选择合适的后端来响应请求。负载调度的流程如下图：3保持 通过指令来建立请求与后端 之间的对应关系，解决请求过程中丢失的问题。4 管理通过功能，可以实现功能，解决用户网络与后台服务器网络提供商不同而访问太慢的问题，并可以缓解后台服务器的访问压力。工作流程如下：否否是是收到请求计算判断是否已经缓存判断缓存是否过期读取缓存文件头向后台发出请求缓存收到的数据读取缓存数据回复请求 缓存处理示意图对于缓存的时间，在中定义缓存时候

13、就必须指定统一失效时间然后在的中，针对不同的返回状态，指定统一失效时间在后台服务器返回的数据中，可能会包含缓存失效时间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），通过的集中管理，通过水平添加服务器的方式，控制在每台服务器在4005

14、00的并发，并支持线性扩展。3.1.1.4. 高可用能很好的实现高可用、可扩展以及负载均衡的要求。提供负载均衡的能力，提供健康检查，故障转移，提高系统的可用性。采用这样的架构以后很容易对现有系统进行扩展，只要在后端添加或者减少，只要更改配置文件，并能实现无缝配置变更。在本项目中建议采用由充当的职责，实现的的架构模式，通过暴露虚拟（配置绑定域名）的形式对内容网站进行访问。3.1.2. 管理及缓存3.1.2.1. 功能因为协议的无状态性，需要在上下文中保持状态，因此就产生了以及的管理问题，管理根据实际情况有集群复制、模式等，由于应用服务器复制的成本开销太大，所以超过5台以上的应用服务器集群，不建议

15、使用复制策略，推荐使用模式管理3.1.2.2. 组成 ，无状态共享模式，一种大规模开发模式，不是放在各自的应用服务器内存中，而是存在统一的缓存服务器，应用服务器均可共享，可实现服务器的线性扩展，解决传统集群不能超过5台的限制。（复制，性能降低）可以采用或者构筑中的服务器，缓存用来减少磁盘，加快访问速度，3.1.2.3. 性能由于数据存在于内存中，同时控制好数据量，性能很大程度上依赖于硬件设备3.1.2.4. 高可用服务器（或者）可考虑双机热备或多机集群负载，多台设备之间保持心跳，提高可用性的同时，又能软负载均衡。3.2. 应用层3.2.1. 服务框架分布式服务框架实现各服务与服务间的高性能和透

16、明化的远程调用，实现的服务治理。服务框架通过对基于长连接的框架抽象封装，提供端对端的、能进行软负载容错的远程通讯，同时基于注册中心服务，使服务使用者能动态查找服务的提供者，使地址透明，达到服务的统一管理和平滑伸缩扩展的能力。3.2.1.1. 功能结构示意图高可用1. 监控中心宕掉不影响使用，只是丢失部分采样数据。2. 注册中心对等集群，任意一台宕掉后，将自动切换到另一台。注册中心全部宕掉后，服务提供者和服务使用者仍能通过本地缓存通讯。3. 服务提供者无状态，任意一台宕掉后，不影响使用。服务提供者全部宕掉后，服务使用者应用将无法使用，并无限次重连等待服务提供者恢复。4. 注册中心、服务提供者、服

17、务使用者三者之间均为长连接，监控中心除外。注册中心通过长连接感知服务提供者的存在，服务提供者宕机，注册中心将立即推送事件通知消费者。注册中心和监控中心全部宕机，不影响已运行的提供者和消费者，消费者在本地缓存了提供者列表。注册中心和监控中心都是可选的，服务使用者可以直连服务提供者。高性能1. 注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，压力较小。2. 监控中心负责统计各服务调用次数，调用时间等，统计先在内存汇总后每分钟一次发送到监控中心服务器，并以报表展示，消耗很小。3. 服务提供者向注册中心注册其提供的服务，并汇报调用时间到

18、监控中心。4. 服务使用者向注册中心获取服务提供者地址列表，并根据负载算法直接调用提供者，同时汇报调用时间到监控中心，这样调用没有时间损耗。高扩展1. 注册中心为对等集群，可动态增加机器部署实例，所有客户端将自动发现新的注册中心。2. 服务提供者无状态，可动态增加机器部署实例，注册中心将推送新的服务提供者信息给消费者。3. 当服务集群规模进一步扩大，带动治理结构进一步升级，需要实现动态部署，进行流动计算，现有分布式服务架构不会带来阻力。3.2.1.2. 系统架构服务框架是一个面向服务的体系结构（ ：）：架构图l 暴露服务方称之为“服务提供者”，是一个服务实现的实体，它接受和执行来自服务消费者的

19、请求。它将自己的服务和接口描叙注册到服务注册中心，以便服务使用者可以发现和访问该服务。l 调用远程服务方称之为“服务消费者”,是一个应用程序、一个软件模块或需要一个服务的另一个服务。它发起对服务注册中心的服务订阅，通过传输绑定服务，并且执行服务功能。服务使用者根据接口契约来执行服务。l 服务注册与发现的中心目录服务称之为“服务注册中心”，是“服务提供者”，“服务消费者”的支持者。它包含一个可用服务的存储库，保存“服务提供者”的服务注册信息，并允许感兴趣的“服务消费者”对服务进行订阅。 实际注册中心实际也扮演了服务提供者的角色，因为它提供的是对服务l 服务请求者定位服务查询服务注册中心来找到满足

20、其标准的服务。l 为了使服务可访问需要注册服务，把服务描述信息注册到服务中心，以便使“服务消费者”可以发现和调用它。3.2.1.3. 功能架构 分布式服务框架包括分布式调用、集群容错、配置管理、容器、服务注册、服务代理几个部分，实现高性能的服务调用和处理。高性能通讯及多协议集成l 高性能通讯：提供对多种基于长连接的框架抽象封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式。l 多协议：服务框架支持不同服务不同协议和同一服务使用多协议暴露。比如：不同服务在性能上适用不同协议进行传输，比如大数据用短连接协议，小数据大并发用长连接协议。服务动态寻址与路由基于注册中心目录服务，使服务

21、消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。不再需要写死服务提供方地址，注册中心基于接口名查询服务提供者的地址，并且能够平滑添加或删除服务提供者。透明化的远程方法调用，就像调用本地方法一样调用远程方法，只需简单配置，没有任何侵入。l 连接控制：连接控制允许设置服务器端接受的最大连接数，客户端服务使用的连接数。l 回声测试：回声测试用于检测服务是否可用，回声测试按照正常请求流程执行，能够测试整个调用是否通畅，可用于监控。l 延迟连接：延迟连接，用于减少长连接数，当有调用发起时，再创建长连接。负载均衡与容错提供基于接口方法的透明远程过程调用，包括多协议支持，以及软

22、负载均衡，失败容错，地址路由，动态配置等集群支持。软负载均衡可在内网替代F5等硬件负载均衡器。注册中心注册中心采用实现，是一个高可用的分布式数据管理与系统协调框架，基于对算法的实现，使该框架保证了分布式环境中数据的强一致性，从而解决了分布式数据一致性的问题。3.2.1.4. 性能服务框架是把系统进行拆分的基础设置，服务框架基于进行设计，性能比普通的有了极大的提高，已经在生产系统中部署，下面是测试的部分结果：机器配置：机器地址机器配置说明服务注册中心192.168.141206：2G*2内存：8G为虚拟机服务提供者192.168.141.207192.168.141.206：2G*2内存：8G为

23、虚拟机单个服务提供端时部署在207上，多个时206,207上不使用容器方式分别部署。服务消费端192.168.140.194：2G内存：8G操作系统为 20031、 采用4个场景：1) 场景1：每次从服务提供者处返回一个大小为1的字符串，并发用户为100时，处理能力最高，每秒处理的事务数达到5889；2) 场景2：每次从服务提供者处返回一个大小为10的字符串，并发用户为40时，处理能力最高，每秒处理的事务数达到1070；3) 场景3：每次从服务提供者处返回一个大小为1的对象，并发用户为120时，处理能力最高，每秒处理的事务数达到6196；4) 场景4：每次从服务提供者处返回一个大小为10的对象

24、，并发用户为100时，处理能力最高，每秒处理的事务数达到1024。2、 结论测试和生产系统还是有差别，但测试数据可以作为参考的依据，根据以上的测试，每台应用服务器并发500毫无问题，对于2000的并发要求，只需要采取4台即可，因为调用不保留状态，所以支持线性扩展。3.2.1.5. 高可用服务框架，在做远程调用不依赖于注册中心，客户端初始化将所有的服务提供者，下载到客户端的内存，在做调用就可以进行集群负载策略。客户端通过代理进行执行远程方法，所有在代理层需要有作为远程调用的执行引擎，由来链路每一次远程的执行调用。在中有简易集群机制来选择每一次调用所采取的集群负载策略，可以在中进负载以及参数配置的

25、优化处理。3.2.2. 注册中心分布式服务框架的注册中心采用的是来实现的，基于的特点，注册中心在整个系统中承担了配置参数的统一入口，是大型系统中不可或缺的关键组成部分。3.2.2.1. 功能数据发布与订阅（配置中心） 发布与订阅模型，即所谓的配置中心，顾名思义就是发布者将数据发布到节点上，供订阅者动态获取数据，实现配置信息的集中式管理和动态更新。例如全局的配置信息，服务式服务框架的服务地址列表等就非常适合使用。 应用中用到的一些配置信息放到上进行集中管理。这类场景通常是这样：应用在启动的时候会主动来获取一次配置，同时，在节点上注册一个，这样一来，以后每次配置有更新的时候，都会实时通知到订阅的客

26、户端，从来达到获取最新配置信息的目的。 分布式搜索服务中，索引的元信息和服务器集群机器的节点状态存放在的一些指定节点，供各个客户端订阅使用。 注意：在上面提到的应用场景中，有个默认前提是：数据量很小，但是数据更新可能会比较快的场景。 命名服务( ) 命名服务也是分布式系统中比较常见的一类场景。在分布式系统中，通过使用命名服务，客户端应用能够根据指定名字来获取资源或服务的地址，提供者等信息。被命名的实体通常可以是集群中的机器，提供的服务地址，远程对象等 分布式通知/协调 中特有注册与异步通知机制，能够很好的实现分布式环境下不同系统之间的通知与协调，实现对数据变更的实时处理。使用来进行分布式通知和

27、协调能够大大降低系统之间的耦合. 3.2.3. 消息框架3.2.3.1. 功能高性能1k大小的消息，1台消息服务器，1台消息发送端，可以达到3000。一台消息接收，可以达到1500。实时性顺序性保证消息的顺序发送和接收高可靠性l 消息在客户端发送消息，并不是请求直接发送到服务端，而是先存储在本地文件中。通过发送线程，读取文件，进行消息异步发送。l 对于网络中断，服务服务器宕机，依然正常使用，不影响客户端的消息发送。l 当消息本地存储文件达到限制的时候，自动删除最早文件，抛弃最早消息，保证发送的健壮性高可用性用主备单个节点故障，不影响系统正常运行可扩展性可以对系统进行横向和纵向扩展，横向扩展可以

28、向现有的服务环里面增加节点，纵向扩展可以增加服务环3.2.3.2. 整体架构1整体结构图特点：（现有版本还未实现该功能）l 消息服务集群处理，可以对系统进行横向扩展。l 消息服务器，在启动的时候，把自己的服务注册到配置中心，从而使客户端能够发现消息服务器。l 消息客户端，在启动的时候，连接配置中心，找到可用的消息服务，对消息服务进行长连接。l 客户端根据消息哈希值，找对应的消息服务器，因此分担单个消息服务器的压力。提升整个系统的吞吐量。l 消息服务，分为主从配备，当客户端在失效备援后连接到备份服务 器时，备份服务器开始激活并开始工作。2类结构设计说明： 实现了一个消息发送和接收的框架，自定义的

29、客户端层，简化配置，可以进行扩展，实现各种不同类型的。并且优化消息堆积处理策略处理。是消息发送的接口，是消息接收接口，都是对外使用接口。2个接口都依赖，创建不同类型的实现子类。消息的实现分为剥离出2层，抽象的一层由实现，具体不同的实现从中继承，实现抽象方法，完成了扩展。类中实现了消息实现的公用功能，如，依赖的消息存储（保存、读取消息），获取配置等。在框架中实现了一个实现了接口，用户可以直接使用进行消息的发送。实现了消息接收。让用户可以继承重载方法，进行消息接收的处理。3消息发送结构图功能：1. 对于客户端的消息发送请求，不是直接发送到服务器的，而是先保存在文件中。2. 消息保存在文件中，数据文

30、件一直增加，顺序在文件后面添加数据，避免随机写。3. 存储的文件，分为数据文件和操作日志文件，对应一次操作，分别记录2个文件。4. 索引建立在内存中，取数据是先通过内存中的索引获取数据位置，进行访问（该步骤存在随机读操作，但是由于索引在内存中，只会有一次读操作）5. 存在专门的发送线程，负责对消息服务器的数据发送。6. 发送数据的线程，发送的模式可为同步阻塞模式发送，批量发送。7. 发送的数据是从文件中获取，读取的数据是按顺序读取的，把数据交付给发送线程，在由发送线程负责把数据发送至消息服务器。 8. 当发送数据失败时候，反复进行重试发送，否则不会发送下一条数据9. 当消息发送成功后，从文件中

31、删除此消息。 4消息接收结构图功能：1.客户端创建的时候，创建的，同时绑定队列，建立监听。2.连接到消息服务器后，请求消息，服务端就会发送消息送到消费端。3.如果配置了消息缓存，消息会批量发送到客户端进行缓存。4.消息接收到后，给服务器回复5.在指定接收的消息个数，或者是每隔一个时间段，进行消息数据接收的提交确认。现阶段的消息只支持消息队列模式，在这种模式中消息被发送到队列中。通常消息会被持久化以保证可靠的传送。消息系统会将队列中的消息传送给接收者 （或）。当接收者处理消息完成后，它会发出完成的通知给消息系统。得到通知的消息就会从队列中删除，因此该消息不会被再次传送。如果在收到消息前消息服务器

32、发生故障导致系统崩溃，当系统恢复时， 该消息会被再次传送给接收者。这种模式允许一个队列有多个接收者。但是一个消息最多只传送给一个接收者。一个队列的消息发送者（或) 与接收者是完全独立的。它们不知道彼此的存在。如：图书订单系统是一个典型的消息队列的用例。每一个订单都被包装为一个消息传送到订单队列中。假定有多个图书订购的终 端向订单队列发关订单消息。当一个消息到达队列时它被持久化以防止系统崩溃时订单的丢失。再假定有多个订单处理中心 分布在不同的机器上接收这个订单队列的消息。消息系统将每一个消息发送给其中一个（并且只发送一个）接收者（即一个订单处理模块）。 这样不同的订单可能会被不同的处理模块处理，

33、但一个订单只会被处理一次。3.2.3.3. 性能压力测试场景：分别在204，215，207，205虚拟机上部署5，10，15，20，25，30个客户端进行发送，每个客户端发送30万次消息，在232，227，250，244上部署5，10，15，20，25，30个客户端进行相对应的接收，发送客户端均发送30万次消息，每个消息大小1。查看客户端与消息服务每秒钟消费的消息数量。结论：消息服务基于以上配置，测试得出40个客户端连接时消息服务的运行状态是最佳的，传送消息的速度是最快的。疲劳测试场景：根据前面场景测试出消息服务最大支持40个左右的客户端连接接收与发送消息的速度是最佳的状态，那么在疲劳中将用该

34、测试场景进行测试，测试步骤如下：分别在204，215，207，205虚拟机上共部署24个客户端进行发送（配置文件中10000，由于在之前的测试出现消息发送出去，文件尚未删除的情况，为了方便测试人员及开发人员查找问题，所以该配置值比较大，在实际的应用中应根据业务需要来配置，详细配置操作手册可见），在232，227，250，244上共部署24个客户端进行相对应的接收，每个消息大小1，查看消息服务的状态，客户端的状态，以及每秒钟消费的消息数量。内存结论：运行时间达90个小时，客户端运行稳定，服务端的使用率有比较大的起伏是原因是消息发送客户端在发送的过程中有休眠的状态，当没有消息传送时的使用率就会下降

35、，内存消耗比较正常，总发送消息的数量达到了10亿，每秒钟发送的消息个数达到了6000左右。3.2.3.4. 高可用经过多轮单元测试、集成测试、压力测试、疲劳测试等的考验，该模块依然坚挺，表现出其高可用性3.2.4. 数据缓存功能组成性能简单介绍我们采用2种缓存服务器作为系统的缓存解决方案：1) ：用作缓存服务器。通过在内存中开辟一块区域来维持一个大的表，并允许多个通过网络形成一个大的，用户不必关心数据存放在哪，只调用相关接口就可，内存的数据通过算法进行淘汰出内存。同时可以通过删除和设置失效时间来淘汰存放在内存的数据，特别适合互联网应用巨大访问量的情况，并支持线性扩展。2) ：用作数据缓存服务器

36、。是一个高性能的数据库。 在部分场合可以对关系数据库起到很好的补充作用，支持更多的数据结构，如：、 、等数据类型，方便业务逻辑的处理。性能参数1) 分别 数据设置100,000个值时间:1311742123 耗时:16.8817设置100,000个值结束时间:1311742138 耗时:15.25742) 分别测试和 数据速度：数组获取100000个值时间:1311742398 耗时:253.9285逐个获取100000个值时间:1311742414 耗时:16.339数组获取100000个值结束时间:1311742415 耗时:0.8022逐个获取100000个值结束时间:131174242

37、8 耗时:13.38内存计算服务器考虑到千万级别用户在线，假设每个用户赋予10k的空间容量，即10,000,000*10K = 100,000M = 100G ，所以服务器考虑采用128g的内存，其中8g留给系统，100g给 缓存，预留20g。数据缓存，考虑到接口系统有2的并发，30分钟失效等参数考虑，每条数据以10k计算，需要2k*30*60*1k = 36000M=36G，另外把参数信息以及常用数据也存储在数据缓存，降低访问数据库的压力，所以数据缓存也需要128G，同样8G留给系统，预留20G，100G留给数据缓存。1、 双节点互备对于缓存和数据缓存采取双机模式，互为备份。采取“双写单读”

38、模式，通过业务逻辑控制并考虑数据的一致性，即写缓存同时往2台服务器写，而读取是采取某个策略从1台服务器读取。这是考虑到互联网应用通常是少量的写，大量的读取模式。3.3. 数据访问层3.3.1.3.3.1.1. 功能位于数据库和持久层之间，它直接与数据库建立通道，对上面应用服务层屏蔽底层数据库的复杂性，对上层应用完全透明，对于应用程序来说，访问的就是“一个”数据库1. 数据库主备和动态切换2. 读写分离3. 基于规范，很容易扩展支持实现规范的数据源4. 读写次数 , 并发度流程控制，动态变更5. 可分析的日志打印 , 日志流控，动态变更6. 提供对大数据量的处理能力 多数据源管理 数据路由(垂直

39、水平等) 数据合并7. 提供事务处理能力 多库事务(互联网) 支持(企业应用) 支持分布式事务3.3.1.2. 组成3.3.1.3. 性能可以接1000+个数据库的，为应用提供数据服务3.4. 管理层3.4.1. 系统监控告警l 业务流程类的监控，通过日志、定时任务、脚本、等实现l 业务系统健康检查（接入）3.4.2. 网络管理l 不涉及第4章. 关键技术4.1. 系统扩展l 传统模式应用集群复制隔离l 模式共享服务器4.2. 缓存访问接口l 缓存服务器：使用搭建缓存服务器，访问接口采用协议l 静态资源缓存服务器：使用缓存服务器，标准的协议访问l 常用数据缓存：，标准的方法访问方式l 数据库缓存：与具体的数据库缓存策略有关4.3. 前后端事务一致性l 主要是后端事务，集中在能力层，采用框架的声明式事务管理，成熟可靠第5章. 软件部署5.1. 部署结构5.1.1. 简单式基本型5.1.2. 分布式扩展型5.2. 部署方式5.2.1. 手工化部署5.2.2. 自动化部署5.2.3. 服务化部署