系统集成概念二

二、系统集成方法

（1）文件传输（共享）

文件共享传输的方式是一种简单直观的办法。它的典型交互场景如下：

在这种场景下，烟草物流系统产生包含需要提供信息的文件，然后再由相关集成系统来通过访问文件获取信息。集成部分主要作用是将文件根据应用的不同需要做格式的转换。采用文件传输的方式，需要关注文件的格式，考虑到不同应用系统传递消息的具体样式不一致，烟草物流系统应用产生的文件不一定能够给相关集成应用。一些常见的方法是传递XML或者JSON格式的文本，在一些UNIX系统里面也可以通过纯TXT文本传递信息的。

文件共享传输方式的缺点：

1、无法避免物流系统与其他系统同时修改该文件，即在物流应用产生文件的时候无法保证集成应用不去修改；

2、通信问题，即文件产生后怎么通知集成应用的问题；

3、集成系统之间信息不同步。

文件共享传输方式的优势：

1、在信息交换不是很频繁，而且对于信息的及时性要求不太高的情况下，文件传输方式简单直接。

2、可以采用一些timerjob的方式来产生和消费文件。保证两者不产生冲突和他们正确的执行顺序。

3、对于集成的系统来说它比较完美的屏蔽了集成的细节。每个系统只要关注符合标准格式的文件内容，具体实现和数据交换他们都不需要关心。

（2）共享数据库

将数据库作为相对独立提供服务的一部分。对于其他集成系统的对接比较容易，这种集成的方式如下图：

本地图片无法显示

添加描述

共享数据库的优势：

可以保证数据的一致性。共享数据库里所有的数据都是统一存储在公共的数据库里，可以保证数据的同步和一致性。对于任何一个系统产生的数据或者变化，另外一个系统马上可以看到。

共享数据库的缺点：

1、对于多个应用来说，这个共享数据库需要能够适应他们所有的场景。不同的应用考量的点是不一样的，要能适应所有的需求对于数据库这一部分就显得尤其的困难。

2、性能方面。不同的应用可能会同时访问相同的数据导致数据访问冲突，因此也会带来如死锁等问题。所以说，共享数据库方案出现问题的根源在于用一种统一的数据模型来解决各种不同的应用需求是并不现实的。

（3）RPC（远程过程调用）

远程过程调用的方法典型的如Java的RMI。典型的应用场景如下：

本地图片无法显示

添加描述

以典型的javaRMI为例，当需要访问远程方法的时候，需要定义访问的接口，然后通过相关工具生成skeleton和stub。然后一端通过stub给另外一端发送消息。在物流系统本地的代码中访问stub看起来还是和调用本地方法一样，这些细节都由stub给屏蔽了。其他的技术如COM，CORBA，.netRemoting都采用了RPC的思路。RPC的这种思路能够很好的集成应用开发。

RPC机制也会带来一定的问题，比如说javaRMI或者.netremoting都局限于一个平台，如果物流系统是用java做的，那么要和相关系统通过RMI集成，对应系统也必须是java做的。另外，集成系统间是一种紧耦合。RPC调用是用的一种类似于系统api的同步调用，当一端发出调用请求的时候会在那里等待返回的结果。如果另外一个系统出现故障也会对调用方产生很大影响。而且用RPC调用的时候默认期望消息是按照发送的顺序给接收方的。但是由于各种环境的影响会使得接收的结果乱序，这样也可能会导致系统执行出现问题。所以从可靠性来说还是存在着一定的不足。

(4)消息队列

消息队列的集成方式如下图：

本地图片无法显示

添加描述

所有应用之间要通信的消息都通过消息队列来传输，由消息队列来保证数据传输的异步性、稳定性等。总的来说，所有数据通过一条可靠的链路来进行通信。

消息队列集成方式的特征

1、更好的应用解耦：采用文件传输或者共享数据库的方式需要知道文件或者数据库的位置。对于RPC的方式来说需要知道对方的IP地址才能进行方法调用。且开发运行平台也有依赖。消息队列则是双方规定好通信的消息格式，各自都只要发消息给消息队列就可以了。可以保证不同开发语言开发的系统之间的通信。

2、消息的可靠性：所有系统之间提交的消息有消息队列里的messagerouter来投递。根据一个发送方指定的地址并转发到另外一个地方。同时，消息队列也根据不同的需要将消息进行持久化，这样保证消息在投递的过程中不会被丢失。

3、系统可靠性：集成系统中有一方出现故障，不影响系统之间的通信，保证了有效信息的传递。保证了系统的异步执行，从某种角度来说也提升了系统性能。消息队列算是一种兼顾了性能、可靠性和松耦合的一种理想集成方式。目前实现消息队列的产品有很多，比如微软的MSMQ，开源产品ActiveMQ，RabbitMQ，ZeroMQ等。

（5）系统接口标准

采用SOA体系架构，通过服务总线技术实现数据交换以及实现各业务子系统间、外部业务系统之间的信息共享和集成，因此SOA体系标准就是我们采用的接口核心标准。主要包括：

[1]服务目录标准：服务目录API接口格式参考国家以及关于服务目录的元数据指导规范，对于W3CUDDIv2API结构规范，采取UDDIv2的API的模型，定义UDDI的查询和发布服务接口，定制基于Java和SOAP的访问接口。除了基于SOAP1.2的WebService接口方式，对于基于消息的接口采用JMS或者MQ的方式。

[2]交换标准：基于服务的交换，采用HTTP/HTTPS作为传输协议，而其消息体存放基于SOAP1.2协议的SOAP消息格式。SOAP的消息体包括服务数据以及服务操作，服务数据和服务操作采用WSDL进行描述。

[3]Web服务标准：用WSDL描述业务服务，将WSDL发布到UDDI用以设计/创建服务，SOAP/HTTP服务遵循WS-IBasicProfile1.0，利用J2EESessionEJBs实现新的业务服务，根据需求提供SOAP/HTTPorJMSandRMI/IIOP接口。

[4]业务流程标准：使用没有扩展的标准的BPEL4WS，对于业务流程以SOAP服务形式进行访问，业务流程之间的调用通过SOAP。

[5]数据交换安全：与外部系统对接需考虑外部访问的安全性，通过IP白名单、SSL认证等方式保证集成互访的合法性与安全性。

[6]数据交换标准：制定适合双方系统统一的数据交换数据标准，支持对增量的数据自动进行数据同步，避免人工重复录入的工作。

(6)接口规范性设计

营销管理系统平台中的接口众多，依赖关系复杂，通过接口交换的数据与接口调用必须遵循统一的接口模型进行设计。接口模型除了遵循工程统一的数据标准和接口规范标准，实现接口规范定义的功能外，需要从数据管理、完整性管理、接口安全、接口的访问效率、性能以及可扩展性多个方面设计接口规格。

（7）接口定义约定

客户端与系统平台以及系统平台间的接口消息协议采用基于HTTP协议的REST风格接口实现，协议栈如图所示：

系统在http协议中传输的应用数据采用具有自解释、自包含特征的JSON数据格式，通过配置数据对象的序列化和反序列化的实现组件来实现通信数据包的编码和解码。

在接口协议中，包含接口的版本信息，通过协议版本约束服务功能规范，支持服务平台间接口协作的升级和扩展。一个服务提供者可通过版本区别同时支持多个版本的客户端，从而使得组件服务的提供者和使用者根据实际的需要，独立演进，降低系统升级的复杂度，保证系统具备灵活的扩展和持续演进的能力。

（8）业务消息约定

请求消息URI中的参数采用UTF-8编码并经过URLEncode编码。

应答消息根节点为“response”，每个响应包含固定的两个属性节点：“status”和“message”。它们分别表示操作的返回值和返回消息描述，其他的同级子节点为业务返回对象属性，根据业务类型的不同，有不同的属性名称。

当客户端支持数据压缩传输时，需要在请求的消息头的“Accept-Encoding”字段中指定压缩方式(gzip)，如消息可以被压缩传输则平台将应答的数据报文进行压缩作为应答数据返回，Content-Length为压缩后的数据长度。

（9）响应码规则约定

响应结果码在响应消息的“status”属性中，相应的解释信息在响应消息的“message”属性中。解释消息为终端用户可读的消息，终端应用不需要解析可直接呈现给最终用户。响应结果码为6位数字串。根据响应类型，包括以下几类响应码。

l 0：成功；

l 1XXXXX：系统错误；

l 2XXXXX：输入参数不合法错误；

l 3XXXXX：应用级返回码，定义应用级的异常返回；

l 4XXXXX正常的应用级返回码，定义特定场景的应用级返回说明。

（10）数据管理

1、业务数据检查：接口应提供业务数据检查功能，即对接收的数据进行合法性检查，对非法数据和错误数据则拒绝接收，以防止外来数据非法入侵，减轻应用支撑平台系统主机处理负荷。

对于接口，其业务数据检查的主要内容有以下几个方面：

l 数据格式的合法性：如接收到非预期格式的数据。包括接收的数据长度，类型，开始结束标志等。

l 数据来源的合法性：如接收到非授权接口的数据。

l 业务类型的合法性：如接收到接口指定业务类型外的接入请求。

l 对于业务数据检查中解析出非法数据应提供以下几种处理方式：

l 事件报警：在出现异常情况时自动报警，以便系统管理员及时进行处理。

l 分析原因：在出现异常情况时，可自动分析其出错原因。如是数据来源非法和业务类型非法，本地记录并做后续管理，如是数据格式非法，分析网络传输原因或对端数据处理原因，并做相应处理。

l 统计分析：定期对所有的非法记录做统计分析，分析非法数据的各种来源是否具有恶意，并做相应处理。

2、数据压缩/解压：接口根据具体的需求应提供数据压缩/解压功能，以减轻网络传输压力，提高传输效率，从而使整个系统能够快速响应并发请求，高效率运行。

在使用数据压缩/解压功能时，应具体分析每一类业务的传输过程、处理过程、传输的网络介质、处理的主机系统和该类业务的并发量、峰值及对于所有业务的比例关系等，从而确定该类业务是否需要压缩/解压处理。对于传输文件的业务，必须压缩后传输，以减轻网络压力，提高传输速度。

在接口中所使用的压缩工具必须基于通用无损压缩技术，压缩算法的模型和编码必须符合标准且高效，压缩算法的工具函数必须是面向流的函数，并且提供校验检查功能。

（11）完整性管理

根据业务处理和接口服务的特点，应用系统的业务主要为实时请求业务和批量传输业务。两类业务的特点分别如下：

1、实时请求业务：

[1]采用基于事务处理机制实现

[2]业务传输以数据包的方式进行

[3]对传输和处理的实时性要求很高

[4]对数据的一致性和完整性有很高的要求

[5]应保证高效地处理大量并发的请求

2、批量传输业务：

[1]业务传输主要是数据文件的形式

[2]业务接收点可并发处理大量传输，可适应高峰期的传输和处理

[3]要求传输的可靠性高

根据上述特点，完整性管理对于实时交易业务，要保证交易的完整性；对于批量传输业务，要保证数据传输的完整性。

(12)接口双方责任

1、消息发送方：遵循本接口规范中规定的验证规则，对接口数据提供相关的验证功能，保证数据的完整性、准确性；消息发起的平台支持超时重发机制，重发次数和重发间隔可配置。提供接口元数据信息，包括接口数据结构、实体间依赖关系、计算关系、关联关系及接口数据传输过程中的各类管理规则等信息；提供对敏感数据的加密功能；及时解决接口数据提供过程中数据提供方一侧出现的问题；

2、消息响应方：遵循本接口规范中规定的验证规则，对接收的数据进行验证，保证数据的完整性、准确性。

及时按照消息发送方提供的变更说明进行本系统的相关改造。

及时响应并解决接口数据接收过程中出现的问题。

3、异常处理：对接口流程调用过程中发生的异常情况，如流程异常、数据异常、会话传输异常、重发异常等，进行相应的异常处理，包括：

l 对产生异常的记录生成异常记录文件。

l 针对可以回收处理的异常记录，进行自动或者人工的回收处理。

l 记录有关异常事件的日志，包含异常类别、发生时间、异常描述等信息。

l 当接口调用异常时，根据预先配置的规则进行相关异常处理，并进行自动告警。

（13）接口的可扩展性规划与设计

各个系统间的通信接口版本信息限定了各个系统平台间交互的数据协议类型、特定版本发布的系统接口功能特征、特定功能的访问参数等接口规格。通过接口协议的版本划分，为客户端升级、其他被集成系统的升级、以及系统的部署提供了较高的自由度和灵活性。

系统可根据接口请求中包含的接口协议版本实现对接口的向下兼容。系统平台可根据系统的集群策略，按协议版本分别部署，也可多版本并存部署。由于系统平台可同时支持多版本的外部系统及客户端应用访问系统，特别是新版本客户端发布时，不要求用户强制升级，也可降低强制升级安装包发布的几率。从而支持系统的客户端与系统平台分离的持续演进。

（14）接口安全性设计

为了保证系统平台的安全运行，各种集成的外部系统都应该保证其接入的安全性。接口的安全是平台系统安全的一个重要组成部分。保证接口的自身安全，通过接口实现技术上的安全控制，做到对安全事件的“可知、可控、可预测”，是实现系统安全的一个重要基础。根据接口连接特点与业务特色，制定专门的安全技术实施策略，保证接口的数据传输和数据处理的安全性。

系统应在接口的接入点的网络边界实施接口安全控制。接口的安全控制在逻辑上包括：安全评估、访问控制、入侵检测、口令认证、安全审计、防(毒)恶意代码、加密等内容。

1、安全评估：安全管理人员利用网络扫描器定期(每周)/不定期(当发现新的安全漏洞时)地进行接口的漏洞扫描与风险评估。扫描对象包括接口通信服务器本身以及与之关联的交换机、防火墙等，要求通过扫描器的扫描和评估，发现能被入侵者利用的网络漏洞，并给出检测到漏洞的全面信息，包括位置、详细描述和建议改进方案，以便及时完善安全策略，降低安全风险。

安全管理人员利用系统扫描器对接口通信服务器操作系统定期(每周)/不定期(当发现新的安全漏洞时)地进行安全漏洞扫描和风险评估。在接口通信服务器操作系统上，通过依附于服务器上的扫描器代理侦测服务器内部的漏洞，包括缺少安全补丁、词典中可猜中的口令、不适当的用户权限、不正确的系统登录权限、操作系统内部是否有黑客程序驻留，安全服务配置等。系统扫描器的应用除了实现操作系统级的安全扫描和风险评估之外还需要实现文件基线控制。

接口的配置文件包括接口服务间相互协调作业的配置文件、系统平台与接口对端系统之间协调作业的配置文件，对接口服务应用的配置文件进行严格控制，并且配置文件中不应出现口令明文，对系统权限配置限制到能满足要求的最小权限，关键配置文件加密保存。为了防止对配置文件的非法修改或删除，要求对配置文件进行文件级的基线控制。

2、访问控制：访问控制主要通过防火墙控制接口对端系统与应用支撑平台之间的相互访问，避免系统间非正常访问，保证接口交互信息的可用性、完整性和保密性。访问控制除了保证接口本身的安全之外，还进一步保证应用支撑平台的安全。

为了有效抵御威胁，应采用异构的双防火墙结构，提高对防火墙安全访问控制机制的破坏难度。双防火墙在选型上采用异构方式，即采用不同生产厂家不同品牌的完全异构防火墙。同时，双防火墙中的至少一个应具有与实时入侵检测系统可进行互动的能力。当发生攻击事件或不正当访问时，实时入侵检测系统检测到相关信息，及时通知防火墙，防火墙能够自动进行动态配置，在定义的时间段内自动阻断源地址的正常访问。

系统对接口被集成系统只开放应用定义的特定端口。

采用防火墙的地址翻译功能，隐藏系统内部网络，向代理系统提供翻译后的接口通信服务器地址及端口，禁止接口对端系统对其它地址及端口的访问。

对通过/未通过防火墙的所有访问记录日志。

3、入侵检测：接口安全机制应具有入侵检测(IDS)功能，实时监控可疑连接和非法访问等安全事件。一旦发现对网络或主机的入侵行为，应报警并采取相应安全措施，包括自动阻断通信连接或者执行用户自定义的安全策略。

实施基于网络和主机的入侵检测。检测攻击行为和非法访问行为，自动中断其连接，并通知防火墙在指定时间段内阻断源地址的访问，记录日志并按不同级别报警，对重要系统文件实施自动恢复策略。

4、口令认证：对于需经接口安全控制系统对相关集成系统进行业务操作的请求，实行一次性口令认证。

为保证接口的自身安全，对接口通信服务器和其它设备的操作和管理要求采用强口令的认证机制，即采用动态的口令认证机制。

5、安全审计：为了保证接口的安全，要求对接口通信服务器的系统日志、接口应用服务器的应用日志进行实时收集、整理和统计分析，采用不同的介质存档。

6、防恶意代码或病毒：由于Internet为客户提WEB服务，因此，对于Internet接口要在网络分界点建立一个功能强大的防恶意代码系统，该系统能实时地进行基于网络的恶意代码过滤。建立集中的防恶意代码系统控制管理中心。

7、加密：为了提高接口通信信息的保密性，同时保证应用支撑平台的安全性，可以对系统平台与接口集成系统间的相关通信实施链路加密、网络加密或应用加密，保证无关人员以及无关应用不能通过网络链路监听获得关键业务信息，充分保证业务信息的安全。

三、系统集成方案

1.整体开发项目采用微服务的技术架构，各微服务中心之间的接口调用采用RPC调用，消息传输格式为json。

2.整体开发项目对外提供的能力，如对各销售渠道前端产品提供的商品、订单、库存等能力服务，通过API网关封装为HTTP接口，消息传输格式为json。

3.整体开发项目也可以集成的外部第三方平台及能力，如天猫&京东等合作商城、仓储WMS、物流TMS等，通过集成平台进行集成，由集成平台屏蔽外部接口的版本变更或不同外部平台供应商接口的差异。集成平台对外接口为HTTP，对内根据业务场景不同，可采用RPC、HTTP或消息队列MQ等不同的接口方式。对外消息传输格式采用第三方平台的消息格式类型，如XML或SOAP等，对内消息格式尽量转换为json。

4.跟外部第三方平台的集成根据业务场景也会采用文件传输的方式，如跟第三方物流运单、结算单、对账单等的数据交换，数据提供方生成文件放入指定的文件目录，数据消费方下载文件进行处理。

5.统一工作台提供的部分页面功能由各微服务中心提供或来至BI数据分析，采用页面挂载方式集成，点击页面跳转至页面功能提供方，系统间通过统一工作台提供的SSO解决单点登录和权限控制。部分页面功能也可由统一工作台进行页面开发，微服务中心或BI系统提供HTTP接口能力。

6.整体开发项目跟BI系统的数据对接方式为BI系统通过ETL工具对新企业的读库进行数据抽取。

（1）系统集成特征

本期项目系统平台不是孤立的，跟其他周边系统形成紧密的业务集成关系。

1．新系统通过接口方式对销售渠道包括自营网站商城（PC、APP、H5、小程序）、ARS语音下单及第三方在线商城提供商品、用户、会员、订单、库存等服务，支撑各销售渠道的销售业务。

2．履约方面，新企业通过接口方式跟仓储系统WMS、物流配送TMS进行库存、配送发货等业务握手完成订单履约。

3．支付方面，通过接口方式跟各支付渠道包括银行网关、第三方发卡方、第三方支付平台（支付宝、微信等）进行支付对接。通过跟电子发票系统对接完成发票生成。

4．跟其他消息服务如SMS短信、邮件系统、Push推送平台等完成对用户的消息发送。

5．跟企业管理平台，暂时分析无直接业务对接关系，需调研后确认。

6．其他。

（2）架构集成方案

在本项目建设过程中，需要和外围系统对接实现集成服务。

1、采用微服务的技术架构，各微服务中心之间的接口调用采用RPC调用，消息传输格式为json。

2、对外提供的能力，如对各销售渠道前端产品提供的商品、订单、库存等能力服务，通过API网关封装为HTTP接口，消息传输格式为json。

3、需要集成的外部第三方平台及能力，如物流平台、外呼平台等，通过集成平台进行集成，由集成平台屏蔽外部接口的版本变更或不同外部平台供应商接口的差异。集成平台对外接口为HTTP，对内根据业务场景不同，可采用RPC、HTTP或消息队列MQ等不同的接口方式。对外消息传输格式采用第三方平台的消息格式类型，如XML或SOAP等，对内消息格式尽量转换为json。

4、跟外部第三方平台的集成根据业务场景也会采用文件传输的方式，如跟第三方物流公司运单、结算单、对账单等的数据交换，数据提供方生成文件放入指定的文件目录，数据消费方下载文件进行处理。

5、统一工作台提供的部分页面功能由各微服务中心提供或来至BI数据分析，采用页面挂载方式集成，点击页面跳转至页面功能提供方，系统间通过统一工作台提供的SSO解决单点登录和权限控制。部分页面功能也可由统一工作台进行页面开发，微服务中心或BI系统提供HTTP接口能力。

6、跟BI系统的数据对接方式为BI系统通过ETL工具对系统的读库进行数据抽取。

（3）系统接口方案

1、接口原则

接口提供方提供接口方案，包括接口形式、传输协议及消息格式，接口调用方进行接口适配。为便于统一监控和接口管理，原则上建议内部接口采用RPC，外部接口采用HTTP，对实时性要求不高或下游接口可异步处理的接口调用采用MQ。

2、接口方式

1) 消息接口

同步请求/应答方式：客户端向服务器端发送服务请求，客户端阻塞等待服务器端返回处理结果。

异步请求/应答方式：客户端向服务器端发送服务请求，与同步方式不同的是，在此方式下，服务器端处理请求时，客户端继续运行；当服务器端处理结束时返回处理结果。

会话方式：客户端与服务器端建立连接后，可以多次发送或接收数据，同时存储信息的上下文关系。

2)文件接口

3)消息队列

广播通知方式：由服务器端主动向客户端以单个或批量方式发出未经客户端请求的广播或通知消息，客户端可在适当的时候检查是否收到消息并定义收到消息后所采取的动作。

事件订阅方式：客户端可事先向服务器端订阅自定义的事件，当这些事件发生时，服务器端通知客户端事件发生，客户端可采取相应处理。事件订阅方式使客户端拥有了个性化的事件触发功能，方便客户端及时响应所订阅的事件。

3、消息接口消息格式

json

xml

SOAP

以上接口消息格式尽量采用json。

（4）系统接口监控方案

TraceInsight负责链路追踪，针对现有的分布式系统开发，实现了从web或service入口到数据库类中间件调用全链路记录，支持采样统计，并记录链路中各阶段的性能指标，定时发送追踪数据到数据中心供监控分析及告警。

•追踪数据支持分模块、时间、接口与类实时查询。

•追踪记录每次调用的依赖关系、持续事件甚至参数和异常。

应用监控提供了有关Web应用程序在性能方面的实时监控信息，帮助开发、运维团队快速分析程序性能瓶颈以及应用潜在的问题。应用监控总共分为"拓扑"，"web事务"，"数据库"，"缓存"和"JVMs"五个类别，并且支持选择固定时间段查看数据统计。

通过应用的追踪数据，可以计算出应用间调用关系，应用与数据库中间件的拓扑结构，如下所示，其中EU（EnderUser）代指用户，每个节点代表一个应用或者数据库、中间件，连接2个节点的线条代指调用关系与调用次数。

web事务展示了Web应用的事务详情，以接口维度展示调用明细，访问应用的web请求的响应时间分析，耗时前五的API性能趋势，总体吞吐量统计，慢事务追踪。

Web事务明细：平均响应时间、响应时间占比、吞吐量分别展示了每个事务接口在可选的固定时间段内的平均响应时间75%分位数、每个接口占用总体调用时间的百分比，与每个接口的每分钟调用次数。

响应时间Top5：展示了可选的固定时间段内将调用时间75%分位数排列后前五的事物接口与性能趋势。

吞吐量Top5：展示了事务接口可选的固定时间段内每分钟被请求的次数与趋势的前五位。

慢事务追踪Top10：展示了一可选的固定时间段内响应时间超过250ms并且排列前十的事务接口的发生次数与平均响应时间等信息。

数据库事物展示了数据库事物详情，以Web应用中DAO方法维度（mybatis）统计调用明细，耗时前五的查询性能趋势，总体吞吐量，与慢数据库追踪。

数据库明细：平均响应时间、吞吐量分别展示了一小时内（可选）每个查询方法的平均执行时间75%分位数、每个查询的每分钟调用次数。

响应时间Top5：展示了最近一小时内（可选）数据库查询时间75%分位数排列后前五的数据库事物与性能趋势。

吞吐量Top5：展示了最近一小时内（可选）每分钟被请求数据库查询排列前五位的次数与趋势。

慢数据库追踪Top10：慢事物列表展示了一小时内（可选）响应时间超过250ms并且排列前十的数据库请求次数与平均响应时间等信息。

缓存事务主要包括redis调用明细，耗时前五的查询性能趋势，总体吞吐量统计分析。

缓存明细：平均响应时间、吞吐量分别展示了一小时内（可选）每次redis查询的平均执行时间75%分位数、每个查询的每分钟调用次数。

响应时间Top5：展示了最近一小时内（可选）数据库查询时间75%分位数排列后前五的redis查询与性能趋势。

吞吐量Top5：展示了最近一小时内（可选）每分钟被请求redis查询排列前五位的次数与趋势。

JVMs主要包括Web应用的各个模块的各个Java容器实例状态

Heapmemoryusage：JVM堆内存使用情况。

NonHeapmemoryusag：JVM非堆内存使用情况。

PS-Eden-Space，PS-Old-Gen，PS-Survivor-Space：分别表示jvm堆内存中伊甸园，老年代区，幸存者区。

GCMarkSweep，GCScavenge：分别表示JVMfullGC和增量GC次数。

Classcount：展示JVM从启动开始加载和卸载的类的个数。

Thread：JVM加载线程。

浏览器监控为浏览器端、移动端H5性能监控产品。它提供了直接面向用户的浏览器应用的性能追踪，包括响应加载时间，页面错误，异步调用，地理追踪等等。

浏览器监控总共分为"访问域名"，"访问页面"，"定位分析"，"Ajax接口"，"脚本错误"，"浏览器性能"，"摘要"，"地理"八个维度。

访问域名

一个应用可以配置多个子域名，BI的访问域名性能监控根据域名的维度统计性能数据，主要包括页面加载性能趋势、响应时间趋势、吞吐量与慢加载。

白屏时间：从准备加载页面到浏览器开始显示内容的时间。

首屏时间：指用户看到第一屏，即整个网页顶部大小为当前窗口的区域，显示完整的时间。

网页加载：从接收到页面文档第一个字节到接收到最后一个字节的时间。

资源加载时间：页面内js、css、image等资源加载时间。

慢加载追踪：加载时间超过8000ms的访问。

从Ajax维度，统计每条Ajax请求的平均响应时间，时间百分比，吞吐量，并且从响应时间TOP5，吞吐量TOP5，发送数据，接收数据四个方面统计请求性能趋势。

（5）系统平台集成能力

系统接口服务规范化管理：发布基于Webservice的常用业务接口；具备系统接口服务的管理工具，可查看、维护、测试接口的WSDL文件。

我公司系统平台的构件可区分为客户端构件和服务端构件，对于服务端构件，可以通过“发布”功能，发布为标准的WebService服务接口。

同时，系统平台提供“常用业务接口”功能，可以查看当前系统里所有的WebService服务接口，并可以联查每个WebService服务的WSDL描述信息。

平台预置常用业务数据接口：平台预置常用业务数据的接口，包括：凭证信息、应收单、应付单、预算数。

在本项目产品中，所有的业务数据接口，是以数据交换包的形式体现的，系统预制了大量的常用业务数据接口，包括凭证接口、审计接口、应收应付、主数据等，如下图所示：

Portal支持：平台已具有成熟的Portal集成框架，能与业务流程无缝集成。

本项目企业信息门户平台是参考国外先进门户解决方案，结合国内应用实际设计研发而成的一套企业门户系统，即是一套门户开发框架，也是一套门户应用系统。

本项目企业信息门户平台包含门户管理、站点管理、内容管理、门户应用4大部分，提供了多站点管理、数据连接服务、部件与展现服务、开发与扩展工具、展现布局设计、个性化设置、单点登录、文档管理、信息集成、审批中心、全文搜索、社区服务等几十种服务和工具，提供企业信息门户、企业集成门户、企业业务门户等多种门户方案，通过简单配置即可快速实现各类门户应用。

本项目企业信息门户平台具有优秀的跨系统信息集成能力，通过一套信息集成与展现模型，把与异构系统的接口屏蔽在数据连接层面，通过预置各种常见数据连接器及信息描述规范，能够快速实现系统集成；本项目企业信息门户平台具有高度可扩展性，系统对门户展现、通讯、事件等进行了统一封装，内置各种配置管理工具和开发工具，通过这些工具，可快速实现系统功能扩展；本项目企业信息门户平台还具有强大的内容管理能力，对企业的各种结构化和非结构化信息都能够进行良好的支持，能够为这些信息提供的统一呈现和检索服务。

ESB支持：平台提供企业服务总线的实现，能进行不同接口协议的适配、数据映射、转换，可靠的消息传输。

我公司企业服务总线（Ent企业riseServiceBus，简称ESB）是一款基于SOA架构的服务集成平台。实现了可构建基于面向服务的、松耦合的、灵活拆分的信息交换平台，完成了动态链接、智能路由、信息流转等服务总线核心功能，并提供了协议转换、安全控制等基础服务。同时，企业服务总线通过服务配置管理中心完成对总线服务的部署与管理，通过服务注册中心实现对总线服务的注册与定位，并通过监控中心获得总线服务性能的实时监控，为用户快速便捷的完成SOA整合环境下总线的搭建工作提供了架构支持。

主要功能特征如下：

支持如FILE、HTTP/SOAP、TCP/IP、FTP、JMS、POPS、SMTP等多种协议的适配器，具有强大的数据转换能力：

l 支持消息格式转换

l 支持数据映射

l 支持数据合并与拆分

l 支持各种表达式的定制

l 支持数据转换逻辑的扩展

l 提供强大的消息路由功能

l 支持硬编码实现的静态路由

l 基于消息内容的、可配置的动态路由

l 服务注册的动态服务绑定和调用

通过与服务注册信息的集成，在服务请求过程中实时查询服务注册和更新情况，完成服务的动态绑定和调用。

可视化的集成配置工具

l 支持适配器规则配置、组件流程编排、数据映射设置、消息格式转换、路由规则配置

l 支持建模、开发、部署、测试、调试及监控等面向服务的全生命周期管理

l 提供完备的系统容错与监控处理机制

l 支持集群部署与负载均衡

分布式部署支持：平台支持多套系统间的拓扑结构的定义及维护；支持服务器集群部署及扩展。

系统部署架构设计需要考虑企业组织架构、管理要素、网络状况等因素，建议对于涉密网单位用户，根据业务需求采取企业集中部署和以院级单位为中心的二级集中部署方式；对于非涉密网单位用户采取企业集中部署方式，为综合管理提供统一服务。

分布式部署网络拓扑结构中各个站点相互连接，实现涉密网和非涉密网的文件服务器、工作站和电缆等的连接。现在最主要的拓扑结构有总线型拓扑、星型拓扑、环型拓扑、树形拓扑（由总线型演变而来）以及它们的混合型。把这三种最基本的拓扑结构混合起来运用自然就是混合型了。

平台、主数据、应用系统部署在服务器物理单元；

涉密网以院级为单位进行二级集中部署；

非密网在企业非密中心集中部署；

密网、非密网数据通过数据安全交换集中到企业；

安全方面同设置了镜像库，保障数据写入的安全性；

系统支持分布式部署服务器集群，集群能将很多服务器集中起来一起进行同一种服务，在客户端看来就象是只有一个服务器。集群可以利用多个计算机进行并行计算从而获得很高的计算速度，也可以用多个计算机做备份，从而使得任何一个机器坏了整个系统还是能正常运行。

集群系统可解决所有的服务器硬件故障，当某一台服务器出现任何故障，如：硬盘、内存、CPU、主板、I/O板以及电源故障，运行在这台服务器上的应用就会切换到其它的服务器上。

集群系统可解决软件系统问题，在计算机系统中，用户所使用的是应用程序和数据，而应用系统运行在操作系统之上，操作系统又运行在服务器上。这样，只要应用系统、操作系统、服务器三者中的任何一个出现故障，系统实际上就停止了向客户端提供服务，比如我们常见的软件死机，就是这种情况之一，尽管服务器硬件完好，但服务器仍旧不能向客户端提供服务。而集群的最大优势在于对故障服务器的监控是基于应用的，也就是说，只要服务器的应用停止运行，其它的相关服务器就会接管这个应用，而不必理会应用停止运行的原因是什么。

集群系统可以解决人为失误造成的应用系统停止工作的情况，例如，当管理员对某台服务器操作不当导致该服务器停机，因此运行在这台服务器上的应用系统也就停止了运行。由于集群是对应用进行监控，因此其它的相关服务器就会接管这个应用。

四、集成关键技术

一、基于SOA架构

SOA（ServiceOrientedArchitecture，缩写SOA），即面向服务的体系架构，它提供了一种构建IT组织的标准和方法，并通过建立可组合、可重用的服务体系来减少IT业务冗余并加快项目开发的进程。SOA允许一个企业高效地平衡现有的资源和财产，这种体系能够使得IT部门效率更高、开发周期更短、项目分发更快，在帮助IT技术和业务整合方面有着深远的意义。

企业服务总线（Ent企业riseServiceBus，缩写ESB），是面向服务架构的骨干，在完成服务的接入，服务间的通信和交互基础上，还提供安全性、可靠性、高性能的服务能力保障。采用SOA架构，基于ESB总线进行企业应用集成，应用系统之间的交互通过总线进行，这样可以降低应用系统、各个组件及相关技术的耦合度，消除应用系统点对点集成瓶颈，降低集成开发难度，提高复用，增进系统开发和运行效率，便于业务系统灵活重构，快速适应业务及流程变化需要。

基于SOA架构的应用集成开发方法，与传统的软件开发方法略有不同，角色分工更加明确。就整个项目开发周期来讲，首先由业务分析员进企业务及流程定义，然后由架构师和设计人员利用SOA方法将业务和复杂系统进行分割，抽象出对应的业务服务及流程服务；再由开发人员使用不同的开发技术，基于选定的SOA基础架构，进行组件和服务的开发实现、服务的组装与合成，并打包部署和运行调试；最后移交管理人员对服务和业务流程的运行系统进行监控和管理，SOA系统运行中，还可能会涉及操作人员参与业务流程的处理和使用。

二、基于WebService技术

从表面上看，WebService就是一个应用程序，它向外界暴露出一个能够通过Web进行调用的API。这就是说，你能够用编程的方法通过Web调用来实现某个功能的应用程序。例如，创建一个WebService，它的作用是查询某某员工的基本信息。它接受该员工的编号作为查询字符串，返回该员工的具体信息。你可以在浏览器的地址栏中直接输入HTTPGET请求来调用罗列该员工基本信息的ASP页面，这就可以算作是体验WebService了。

从深层次上看，WebService是一种新的Web应用程序分支，它们是自包含、自描述、模块化的应用，可以在网络(通常为Web)中被描述、发布、查找以及通过Web来调用。

WebService便是基于网络的、分布式的模块化组件，它执行特定的任务，遵守具体的技术规范，这些规范使得WebService能与其他兼容的组件进行互操作。它可以使用标准的互联网协议，像超文本传输协议HTTP和XML，将功能体现在互联网和企业内部网上。WebService平台是一套标准，它定义了应用程序如何在Web上实现互操作性。可以用任何语言在任何平台上写WebService。

WebService平台需要一套协议来实现分布式应用程序的创建。任何平台都有它的数据表示方法和类型系统。要实现互操作性，WebService平台必须提供一套标准的类型系统，用于沟通不同平台、编程语言和组件模型中的不同类型系统。目前这些协议有：

三、XML和XSD

可扩展的标记语言XML是WebService平台中表示数据的基本格式。除了易于建立和易于分析外，XML主要的优点在于它既与平台无关，又与厂商无关。XML是由万维网协会(W3C)创建，W3C制定的XMLSchemaXSD定义了一套标准的数据类型，并给出了一种语言来扩展这套数据类型。

WebService平台是用XSD来作为数据类型系统的。当你用某种语言如java来构造一个WebService时，为了符合WebService标准，所有你使用的数据类型都必须被转换为XSD类型。如想让它使用在不同平台和不同软件的不同组织间传递，还需要用某种东西将它包装起来。这种东西就是一种协议，如SOAP。

四、SOAP

SOAP即简单对象访问协议(SimpleObjectAccessProtocol)，它是用于交换XML编码信息的轻量级协议。它有三个主要方面：XML-envelope为描述信息内容和如何处理内容定义了框架，将程序对象编码成为XML对象的规则，执行远程过程调用(RPC)的约定。SOAP可以运行在任何其他传输协议上。如可以使用SMTP，即因特网电子邮件协议来传递SOAP消息，在传输层之间的头是不同的，但XML有效负载保持相同。

WebService希望实现不同的系统之间能够用“软件-软件对话”的方式相互调用，打破了软件应用、网站和各种设备之间的格格不入的状态，实现“基于Web无缝集成”的目标。

五、WSDL

WebService描述语言WSDL就是用机器能阅读的方式提供的一个正式描述文档而基于XML的语言，用于描述WebService及其函数、参数和返回值。因为是基于XML的，所以WSDL既是机器可阅读的，又是人可阅读的。

六、UDDI

UDDI的目的是为电子商务建立标准；UDDI是一套基于Web的、分布式的、为WebService提供的、信息注册中心的实现标准规范，同时也包含一组使企业能将自身提供的WebService注册，以使别的企业能够发现的访问协议的实现标准。

七、WS-Security技术

WS-Security定义了一个用于携带安全性相关数据的SOAP标头元素。如果使用XML签名，标头可以包含由XML签名定义的信息，其中包括消息的签名方法、使用的密钥以及得出的签名值。同样，如果消息中的某个元素被加密，则WS-Security标头中还可以包含加密信息（例如由XML加密定义的加密信息）。WS-Security并不指定签名或加密的格式，而是指定如何在SOAP消息中嵌入由其他规范定义的安全性信息。WS-Security主要是一个用于基于XML的安全性元数据容器的规范。

八、非对称加密技术

1976年，美国学者Dime和Henman为解决信息公开传送和密钥管理问题，提出一种新的密钥交换协议，允许在不安全的媒体上的通讯双方交换信息，安全地达成一致的密钥，这就是“公开密钥系统”。相对于“对称加密算法”这种方法也叫做“非对称加密算法”。

与对称加密算法不同，非对称加密算法需要两个密钥：公开密钥（Publickey）和私有密钥（Privatekey）。公开密钥与私有密钥是一对，如果用公开密钥对数据进行加密，只有用对应的私有密钥才能解密；如果用私有密钥对数据进行加密，那么只有用对应的公开密钥才能解密。因为加密和解密使用的是两个不同的密钥，所以这种算法叫作非对称加密算法。

贸易方利用该非对称加密算法实现机密信息交换的基本过程是：贸易方甲生成一对密钥并将其中的一把作为公用密钥向其他贸易方公开；得到该公用密钥的贸易方乙使用该密钥对机密信息进行加密后再发送给贸易方甲；贸易方甲再用自己保存的另一把专用密钥对加密后的信息进行解密。贸易方甲只能用其专用密钥解密由其公用密钥加密后的任何信息。

非对称加密算法的保密性比较好，它消除了最终用户交换密钥的需要，但加密和解密花费时间长、速度慢，它不适合于对文件加密而只适用于对少量数据进行加密。

在微软的WindowNT的安全性体系结构中，公开密钥系统主要用于对私有密钥的加密过程。每个用户如果想要对数据进行加密，都需要生成一对自己的密钥对（Keypair）。密钥对中的公开密钥和非对称加密解密算法是公开的，但私有密钥则应该由密钥的主人妥善保管。

使用公开密钥对文件进行加密传输的实际过程包括四步：

1.发送方生成一个自己的私有密钥并用接收方的公开密钥对自己的私有密钥进行加密，然后通过网络传输到接收方；

2.发送方对需要传输的文件用自己的私有密钥进行加密，然后通过网络把加密后的文件传输到接收方；

3.接收方用自己的公开密钥进行解密后得到发送方的私有密钥；

4.接受方用发送方的私有密钥对文件进行解密得到文件的明文形式。

因为只有接收方才拥有自己的公开密钥，所以即使其他人得到了经过加密的发送方的私有密钥，也因为无法进行解密而保证了私有密钥的安全性，从而也保证了传输文件的安全性。实际上，上述在文件传输过程中实现了两个加密解密过程：文件本身的加密和解密与私有密钥的加密解密，这分别通过私有密钥和公开密钥来实现。

五、系统集成策略

1、统一的标准规范设计

项目标准规范体系是由一定范围内的具有内在联系的标准组成的科学的有机整体，它包括现有的、正在制定的和应着手制定的各类标准，是促进一定范围内的标准组成趋向科学化和合理化的手段，通常用标准体系框架和明细表的方式来表达。

标准一旦制定，将对整个企业产生广泛的影响，并且将持续较长一段时间，项目标准和规范的建设是一项复杂而艰巨的任务，它的工作量很大，并且需要协调的方面很多。因此在建设的过程中要必须遵循以下原则：

一、大局着眼，急用先行

全面分析项目需求，结合项目信息化化标准体系，从信息化建设的高度着眼，完善信息化标准体系框架，本着急用先行的原则制定编制计划和标准经费概算，明确在本项目中需要完成的标准以及需要引用的标准，配合本项目的实施进度。

二、结构合理、前瞻性强

标准体系是支撑本项目实施质量的标准规范框架，其设计过程必须充分考虑标准之间的互补关系，以合理的结构，全面地体现本项目的建设需要，以规范本项目的建设并完善我国的信息化标准体系。同时，信息化建设日新月异，标准体系设计必须有一定的前瞻性，充分考虑未来企业的发展趋势。

三、充分利用现有标准

标准体系设计要充分继承现有客户端现有标准，对于现有标准可以满足项目需求的，要尽量引用，减少标准的新编任务。

四、统一标准，保障安全

统一标准，保障安全是项目建设必须坚持的重要原则之一。

五、切实可行，准确实用

标准和规范必须根据实际情况而制订和修改，这样才能使标准符合实际。标准的制订和修订要求准确实用，使执行者易于理解和执行，具有较强的可操作性。

六、遵循电子政务的国家标准、企业标准、国际标准

标准和规范的制订应遵照、继承和贯彻国家标准、企业标准，避免重复建设，参考国际标准和国外先进标准。标准和规范的采用顺序是：先国家标准，后企业标准，最后是国际标准。

七、前瞻性强，易于扩展

由于项目建设是一个跨部门、复杂的系统，各个业务部门都有其特点，因此标准的制订和采用应具有前瞻性并成熟可用，满足易于扩展的需求，使之能适应企业的变化。

八、统一组织，各级参与

标准和规范建设涉及面广，不是一个单位、一个部门所能解决的。因此，在标准的制订过程中必须调动各部门的积极性，吸收尽可能多的单位参与。特别是业务处理规范和业务数据标准的制订，必须有各业务部门的业务人员的参与。在标准和规范的执行过程中，也需要各级业务部门的配合。在统一采集数据的基础上，建立系统的、分层次的管理指标规范。

系统性能设计

一、客户端快速访问响应设计

在设计原则中一种常见主题是适度原则。例如，任何页面似乎都有多个项并且请求多个连接。重要的是，页面设计者首先考虑的是每个页面项的实用价值，然后才是它们的大小和复杂度。页面设计者可以控制页面项的大小和复杂度，并且必须确保项的商业价值、大小和复杂度对每个因素向总下载时间所贡献的时间进行调整。页面设计者还能影响连接的数量和类型，并且必须了解他们做出的选择如何影响下载时间。

同样，还要考虑到准备页面的人们很少像最终用户那样查看自己的作品。考虑到效率，客户端设计者和开发者大多将自己置于靠近他们工作的Web服务器附近。大多数人设法与服务器处于同一个LAN。相比之下，Web站点访问者大多却处于很远的地方，并可能用速度相当慢的拨号连接。他们认为，Web设计者可能看不到响应时间的显著差别。但是站点访问者却能看到经过深思熟虑的组装所能带来的益处。可以考虑把这种方法当成一种策略—让开发者在开发调试过程中多使用目标用户使用的典型连接来查看页面。

Web页面中有很多公共组件和特征，我们对它们进行处理，以缩短下载时间。虽然并不是所有的事都行的通，而且有些组件或特征可能不在页面设计者的控制之下。但是，每个对站点性能感兴趣的人仍应该了解这些因素以及与它们相关的折衷办法。主要包括项的数量、大小和复杂度、连接数量、被访问的服务器数量、空白的使用、装入顺序、数据安全性。

1、管理项的数量、大小和复杂度

页面项的数量、大小和复杂度是促成页面大小、页面复杂度以及页面下载所需时间的唯一重要因素。十分简单，拥有少量简单项的页面装入最快并能赢得最满意的访问者。

（1）管理项的数量

要想统计出精确的项数是不可能的。在选择所需项之后，使用有助于缩短下载时间的技巧：

发送作为浏览器或客户端热点图的菜单，而不是带有单独图形元素的表格。因为传输表格本身就很慢，特别是那些带有图形元素的表格。

将项结合起来，这样Web服务器只需用较少的机器周期就能检索和传输内容了。

避免使用鼠标滑过时产生效果的GIF格式的图片。使用动态改变外观的GIF鼠标滑过效果图似乎很有趣，不过为实现这种操作效果，需要下载额外的GIF图片。不使用鼠标滑过效果的GIF图片可以减少页面中项的总和。

虽然大多人为减少项的数量削弱了界面的一些功能，但还是有其它的技巧存在。

（2）管理项的大小

根据功能或信息内容，平衡每项的大小。大些的项的装入总是要花费更多时间，但它不是提供更多的信息或更佳的功能所必需的。

（3）管理项的复杂度

页面的复杂度影响页面呈现的速度。在选择具有增加复杂度特性的项时，请考虑所涉及的延迟。决定页面复杂度的因素包括大表格、动态计算大小的表格单元、Java脚本和Java小应用程序。动画GIF、图像颜色管理和图像抖动也造成了延迟。延迟因浏览器的不同而不同，还因浏览器中级别的不同而不同；幸好有了新的级别，它们将趋于更快，但并不总是如此。

粗制滥造或描述蹩脚且不完整的项会造成浏览器到套接字通信挂起。一些表可能太复杂了，浏览器资源全部用来对它们进行操作，不能够再为它的套接字连接服务了。虽然时间在流逝，但处于运行状态的任何事都没有完成。出现挂起情况时，粗制滥造的项或许已经在浏览器中并正在被处理。服务器和网络也会挂起，但是浏览器的挂起几乎总可以再生。这种挂起会造成丢失连接，就需要资源再次连接，从而使全部装入时间增加并让访问者更加不满。

HTML文件的数量和大小是页面复杂度的指示器。虽然HTML编码超出了小组的分析范围，但我们的确知道像GZIP之类的实用程序能够压缩HTML文件。我们曾经看到GZIP将一个HTML文件的大小缩小至原有的80%到90%。一个较小的HTML文件能减少下载时间并使浏览器得以立刻开始呈现页面。

2、控制连接数量

从Web服务器到达Web浏览器的信息通过TCP/IP套接字连接。在页面信息能够流动之前，两端的连接必须是打开的。每个连接为建立和断开花费了时间，而且有些连接本来就需要比别的连接多花费些时间。请为每个所需连接的考虑以下因素：

（1）、如果必须传输多个项，持久的连接可减少连接设置开销

（2）、安全连接需要更多时间来建立

（3）、Web站点可以在传输完一项后，对保持打开套接字连接或关闭进行控制。如果一个Web站点关闭了连接，浏览器必须为每一项建立一个新的连接。在装入页面时，这种连接开销会显著扩大访问者感觉到的延迟。大多数浏览器试图在它们这一端保持连接的打开状态，但两端必须都同意让连接保持在打开状态。是否保持连接开启的选项通常取决于Web服务器端，服务器上有个配置选项，这个选项决定了在浏览器有持久连接能力时，服务器是否支持持久连接的使用。

（4）、如果运行一个海量网站，还是不要保持持久连接，因为这种连接会造成所有端口或其它受限的服务器资源（如线程）都被占用。可以在服务器端分配额外资源，从而支持持久连接。

（5）、我们的目标是每页只有四个连接。随着服务器和HTTP服务器软件的发展，它们打破了使资源受限制的局限。当服务器端的连接保持打开状态时，站点访问者会受益。

3、控制被访问的服务器数量

在数全齐美的情况下，少数简单的项将驻留在同一个服务器，产生可能的最快下载时间。但是，在真实世界中，页面项经常驻留在多个服务器。这些项可能来自一个站点的服务器或来自跨越多个站点的服务器。每当用户访问另一个服务器，浏览器必须连接通向新服务器的套接字。如果所有浏览器的连接正保持打开状态，为连接到新服务器，浏览器必须断开一个现有的连接。通常情况下，浏览器先请求第一个服务器中的附加项，接着必须重新建立连接。如果可能，把来自单个服务器的项组织起来，避免中断和重新打开连接这个时间开销。当您必须使用多个服务器的时候，把来自同一服务器的请求合并起来，以便利用打开的连接。

尽可能使用直接链接，避免中间页面这一开销。重定向是专用于—当一组新的页面从原有的书签中装入时，将浏览器指向它。

使用浏览器内存高速缓存，可以减少带有对同一项多次请求的页面的下载时间。例如，设计者使用空白GIF来定位页面项。与其对空白GIF连续请求，不如先请求一个空白GIF，再请求其它项比较好。这就允许服务器时间用来将GIF装入浏览器高速缓存，这样GIF就能满足后续请求了。因为从高速缓存中检索GIF比为每个请求返回服务器要快些。

4、控制空白的使用

与其必需添加服务器，不如合理的控制空白更有助于达到可接受的下载时间，甚至更快。

页面设计者经常使用空白帮助他们使页面表现更形象。没有额外的空白，浏览器也可以工作的很好。在将页面放到产品Web服务器上之前，可以考虑使用可用的实用程序消除HTML源码中额外的空白。

避免在需要加密的页面使用额外的空白。虽然明文中额外空白可以在拨号线路中被很好压缩，但加密的空白却不能被很好的压缩，因为这已不再是一个重复字符符号的字符串。加密后，每个重复空白块通常以独特的字节字符串表示，这就使它们不大可能被调制解调器压缩。每个额外字节的传输也占用资源，而对站点访问者没有任何好处。

5、管理装入顺序

设计者可以确定对页面项请求的顺序，以这种方法优化下载时间。其目的是：指定并发操作使页面得以平稳下载的顺序。提前请求项，特别是大项和那些导航需要的项，从而避免在装入过程结束时产生延迟。理想情况是，浏览器应该及时识别项，让它和服务器的连接保持忙状态。

6、了解数据安全性的影响

SSL（私密性）握手和加密会消耗两端的时间。因为私密性为每一项增加了阻力，所以准确设计加密页面很重要。在您设计加密页面时，所有被推荐的设计方法的影响要加倍考虑。

加密页面上的HTML项没有很好的压缩，因为HTML被转化成长数字序列，它们在拨号调制解调器压缩方案下运行的效果不大好。这样，在加密页面上避免使用不必要的空白就更加重要。

显然，私有信息必须保持私有。权衡之计在于，分配私有信息给私有页面，而公有信息给公有页面：不要混淆私有和公有数据。不要将为私有信息请求的开销浪费在公有信息上。

数据检索处理响应设计

科学运用表分区

数据库大表优化

表分区技术是在超大型数据库(VLDB)中将大表及其索引通过分区（patition）的形式分割为若干较小、可管理的小块，并且每一分区可进一步划分为更小的子分区（subpartition）。而这种分区对于应用来说是透明的，通过对表进行分区，可以获得以下的好处：

1、减少数据损坏的可能性。

2、各分区可以独立备份和恢复，增强了数据库的可管理性。

3、可以控制分区在硬盘上的分布，以均衡IO，改善了数据库的性能。

表分区类型

表分区主要以下类型：

1、范围分区：将表按某一字段或若干个字段的取值范围分区。

2、hash分区：将表按某一字段的值均匀地分布到若干个指定的分区。

3、复合分区：结合了前面两种分区类型的优点，首先通过值范围将表进行分区，然后以hash模式将数据进一步均匀分配至物理存储位置。

分区键的选择

分区键的选择：让查询很快定位，但尽量避免数据库操作集中；使大数据表拆分成“小表”，并使数据库操作平均分散到表分区中。

分区在单节点数据库上，提高查询定位的速度，不提供查询并行性。

三、并发性能设计

为了有效支撑大用户并发访问的要求，本项目主要从采用高效率的WEB架构、数据访问性能优化、系统采用集群、CPU和并行查询方式的利用和负载均衡等方面保证项目的并发性能要求。

1、采用高效率的WEB架构

本项目采用面向服务的架构（ServiceOrientedArchitecture–SOA）架构，SOA是解决应用系统互联互通的一种新架构和新思想，SOA采用了很多业界所共同遵守的标准或规范，能够将应用程序的不同功能单元通过服务之间定义良好的接口和契约联系起来。支撑SOA的企业服务总线ESB是传统中间件技术与XML、Web服务等技术相互结合的产物，能有效实现系统应用不同消息和信息的准确、高效和安全传递，能有效提高系统的并发响应能力。

2、数据访问性能优化

在数据库处理中，资源花销最大的是建立数据库连接，而且用户还会有一个较长的连接等待时间。本项目将复用现有的Connection，也就是使用ConnectionPool对象机制优化数据访问性能。当一个用户访问时，直接在连接缓冲池中取得一个数据库连接，而不需重新连接数据库，因此可以大大地提高系统的响应速度。

3、CPU和并行查询方式的利用

本项目将充分利用CPU和并行查询方式提高系统的并发响应能力。

（1）、尽量利用多个CPU处理器来执行事务处理和查询

CPU的快速发展使得数据库越来越重视对多CPU的并行技术的应用，一个数据库的访问工作可以用多个CPU相互配合来完成，加上分布式计算已经相当普遍，只要可能，应该将数据库服务器和应用程序的CPU请求分开，或将CPU请求从一个服务器移到另一个服务器。对于多CPU系统尽量采用并行查询方式进行数据库操作。

（2）、使用并行查询方式进行数据查询

使用并行查询方式不仅可以在多个CPU间分配SQL语句的请求处理，当所查询的数据处于不同的磁盘时，一个个独立的进程可以同时进行数据读取。

（3）、使用优秀工具进行大数据量的装载

使用该方法进行数据装载时，程序创建格式化数据块直接写入数据文件中，不要求数据库内核的其他I/O。

4、系统采用集群和负载均衡

本项目的应用服务器将采用集群和负载均衡技术实现对系统访问的连续运行以及系统之间的业务分流，减少单个服务器的运行压力，提高系统整体的并发响应能力。

三、并发性能设计

为了有效支撑大用户并发访问的要求，本项目主要从采用高效率的WEB架构、数据访问性能优化、系统采用集群、CPU和并行查询方式的利用和负载均衡等方面保证项目的并发性能要求。

1、采用高效率的WEB架构

本项目采用面向服务的架构（ServiceOrientedArchitecture–SOA）架构，SOA是解决应用系统互联互通的一种新架构和新思想，SOA采用了很多业界所共同遵守的标准或规范，能够将应用程序的不同功能单元通过服务之间定义良好的接口和契约联系起来。支撑SOA的企业服务总线ESB是传统中间件技术与XML、Web服务等技术相互结合的产物，能有效实现系统应用不同消息和信息的准确、高效和安全传递，能有效提高系统的并发响应能力。

2、数据访问性能优化

在数据库处理中，资源花销最大的是建立数据库连接，而且用户还会有一个较长的连接等待时间。本项目将复用现有的Connection，也就是使用ConnectionPool对象机制优化数据访问性能。当一个用户访问时，直接在连接缓冲池中取得一个数据库连接，而不需重新连接数据库，因此可以大大地提高系统的响应速度。

3、CPU和并行查询方式的利用

本项目将充分利用CPU和并行查询方式提高系统的并发响应能力。

（1）、尽量利用多个CPU处理器来执行事务处理和查询

CPU的快速发展使得数据库越来越重视对多CPU的并行技术的应用，一个数据库的访问工作可以用多个CPU相互配合来完成，加上分布式计算已经相当普遍，只要可能，应该将数据库服务器和应用程序的CPU请求分开，或将CPU请求从一个服务器移到另一个服务器。对于多CPU系统尽量采用并行查询方式进行数据库操作。

（2）、使用并行查询方式进行数据查询

使用并行查询方式不仅可以在多个CPU间分配SQL语句的请求处理，当所查询的数据处于不同的磁盘时，一个个独立的进程可以同时进行数据读取。

（3）、使用优秀工具进行大数据量的装载

使用该方法进行数据装载时，程序创建格式化数据块直接写入数据文件中，不要求数据库内核的其他I/O。

4、系统采用集群和负载均衡

本项目的应用服务器将采用集群和负载均衡技术实现对系统访问的连续运行以及系统之间的业务分流，减少单个服务器的运行压力，提高系统整体的并发响应能力。

3、系统性能指标

性能需求场景基本信息描述,针对零售户的系统，零售户预计使用人数为15万，其中卷烟订购的日均人数5万，使用零售终端扫码的客户8万，日均上传100万笔消费交易数据，扫码数据实时上传。针对烟草内部管理的系统，日均预计使用人数2000人。针对消费者的系统，预计使用人数700万，日均使用人数10万人，存在日均人数突发性增长的可能。

7.1.高效性

简单网页、接口、服务等（如首页、功能页、低数据量查询等）的请求响应时间。从业务功能数量上来看，80%的业务功能的平均响应时间控制在1秒内，并且单个业务功能98%的请求都在1秒内；20%的业务功能的平均响应时间控制在2秒内，并且单个业务功能98%的请求都在2秒内；特殊情况下，最长时间不超过5秒。

7.2.并发性

各个子系统根据业务需求，稳定支持1000至50000人的集中访问与使用。高并发的场景举例如下，系统要保障包含但不限于以下业务场景等能够稳定、正确、有效的运行。

例一：对零售户的电商网站，开展积分兑换的秒杀活动，秒杀活动预计早上10点开始，库存有限，5万零售户在该时间临界点同时访问，多次刷新网页，10点准时发起抢购，最终耗时最短的那一部分客户能够抢购成功，其余客户返回库存已空，不允许超库存兑换。

例二：使用零售扫码设备及系统的零售户8W，每一笔扫码交易数据实时上传，预计日均上传笔数100万笔，系统需要保障交易数据能够稳定、及时的从零售户端传回服务器，并能正确的处理突发性的大量数据同时传回服务器时的并发性问题。

例三：对消费者存在会员体系，预计会员人数800万，会员积分系统的日均使用人数10万。会员存在成长值积分，消费者每达到一定的成长值积分会得到不同的会员等级。会员的各类行为会触发成长值积分的增加，比如在零售户的终端扫码设备上扫码消费、每日签到、会员活动等，其中预计日均扫码笔数100万笔，每一笔订单代表需要更新消费者的会员成长值积分，系统能够稳定处理该场景下同时更新大量会员成长值积分的并发性问题，保障消费者会员成长值积分的实时更新。

7.3.兼容性

（一）系统需对各类常见浏览器进行兼容性优化，保障系统能在各类浏览器下正确打开与使用。包括但不限于：IE8及以上版本、360（兼容模式）、搜狗（兼容模式）（Trident内核）；Firefox（Gecko内核）；Chrome、360（极速模式）、搜狗（极速模式）（Blink内核）、EDGE。

（二）系统需对移动端Android系统和IOS系统、pc端window7系统和window10系统及主流国产操作系统等进行兼容性支持；web类系统根据业务需要，需对移动与PC端进行双端支持，保证各设备不同屏幕尺寸下、不同系统下能够合理、正确的展示与使用各项功能。后台管控子系统要求按照互联网架构，基于数字中台共享服务中心设计和开发。并支持对后续新增国产化操作系统进行适配性改造。

7.4.稳定性

（一）系统在一定的业务压力情况下，持续运行一段时间（一般为24小时），确保系统能够稳定运行，要求各个子系统各项功能点正常打开的几率≥99.95%。

（二）系统支持7×24小时持续可用，可在每日特定时间段内对系统进行维护，稳定性要求达到99.95%，稳定性计算规则（1-服务不可用时间/总服务时间）*100%。传输数据服务要求准确，不能丢失数据。系统需达到输入有提示，数据有检查，防止数据异常，能够处理系统运行过程中出现的各种异常情况，如：人为操作错误、输入非法数据、硬件设备失败等，系统应能正确的处理，恰当的回避，并以显著方式提示错误信息。系统需提供错误处理机制，当系统运行过程中发生错误时，系统可以明确提示错误信息并指导用户按照错误处理指引进行处理。系统应提供运行监控机制，应有详细的系统日志，记录系统运行的状态及所有操作痕迹，可追踪系统的历史使用情况。系统应提供数据备份、故障恢复机制，定期对系统的数据、运行状态等进行备份，使得在由于系统的错误或其他原因引起系统的数据丢失或系统的数据被破坏时，能够及时恢复和还原数据。

4、易用性设计

系统用户界面友好，使用操作便捷，用户对照使用说明书或者略经培训就可快速掌握使用；通过提供批量处理、便捷功能、下拉菜单、弹出页面等多种方式，以及更多的快捷方式（快捷键、右键菜单等），减少用户机械、重复操作，尽可能支持导入功能，使用户能够方便快速的将数据传入系统。对于常用不变的数据项、重复数据项、可枚举的数据项、可自动产生的数据项，应设置为缺省值或自动提供，以减少用户录入操作。系统需注重产品体验，比如某个页面数据量大，导致加载时间长，给用户提供加载进度条，预计加载时间，减少用户焦虑；查询数据量很大时，采用分页加载、懒加载每次加载部分数据，当用户进行操作时，再逐渐加载等。

全国统一卷烟营销管理平台省级营销子系统，将在行业标准的方案以及产品的基础之上，结合特色业务，并以实际应用者需求为设计思考，力求用户界面友好，使用操作便捷，用户对照使用说明书或者略经培训就可快速掌握使用；产品功能设计，通过提供批量处理、便捷功能、下拉菜单、弹出页面等多种方式，以及更多的快捷方式（快捷键、右键菜单等），减少用户机械、重复操作，尽可能支持导入功能，使用户能够方便快速的将数据传入系统。对于常用不变的数据项、重复数据项、可枚举的数据项、可自动产生的数据项，应设置为缺省值或自动提供，以减少用户录入操作。系统需注重产品体验，比如某个页面数据量大，导致加载时间长，给用户提供加载进度条，预计加载时间，减少用户焦虑；查询数据量很大时，采用分页加载、懒加载每次加载部分数据，当用户进行操作时，再逐渐加载等。

6、可扩展与可维护性设计

（一）可扩展性

系统应采用模块化、组件化、面向对象的体系结构。在技术架构和设计模式上保证技术的延续性，灵活的扩展性和广泛的适应性，确保系统能够根据技术发展、用户在数据及业务功能方面需求的增加不断升级扩展。在选择技术实现时尽量做到可配性强、配置灵活，以适应不同情况下用户的需求。在规定的业务规范范围内，能够机动、灵活地更改业务内容，增删业务处理程序，改变相关报表及统计信息，并能够为后续系统扩展和功能完善增加组件设置接口，使得数据更新简便、系统升级容易。充分考虑现有应用以及今后业务的可能扩展，随着数据量的增加和运行节点的扩展，应用系统能够随着硬件和系统软件的升级或增加，具有良好的可扩展性。应用软件应具有良好的开放性，遵循业界相关标准，支持开放的标准接口，使整个系统成为一个统一的整体。

（二）可维护性

系统各业务功能模块可单独创建、更新、移除，改动过程中不可影响系统其他业务功能的运行。开发过程中，从接到修改请求后，对于普通修改应在1至2天内完成；对于评估后为重大需求或设计修改应在1周内完成。90%的BUG修改时间不超过1个工作日，其他不超过2个工作日。任何对象的任何方法都不允许超过200行代码。一个模块或方法的最大圈复杂度不能超过15。系统代码可读性要强，每个类、接口、方法、属性等命名要有意义且要求尽可能进行中文注释，确保能够帮助理解代码，注释率≥60%，注释率计算规则（类、接口、方法、属性等已添加注释的个数/类、接口、方法、属性等总个数）*100%。

6、敏捷迭代性基础建设

有效进行高层次的业务抽象，对所有业务进行横向、纵向拆解切分，合并相同部分，独立不同部分。制定一系列标准，在业务逻辑之上能够提供统一流程编排服务，实现微服务化。同时，通过可视化、配置化、低代码的方式，降低对每个API学习域的熟悉成本，从而不抵消API复用的便利性。

实现可视化，有效降低使用方的学习成本；实现配置化，能够把各个业务使用的能力集中管理，让熟悉业务的人员直接控制应用中的业务逻辑，更好的执行标准；实现低代码，降低开发人员学习中台复杂技术框架的门槛，使其能忽略底层的技术实现，只关心业务逻辑部分。

同时，做好系统设计与中台化标准之间的平衡，在满足复用性的基础上，有效的实现快速低成本创新。

建立围绕运行域与管理域的中台整体应用架构，以页面、功能、能力和数据模型四个维度为标准，建立运行域八大中心共用库，同时开发元数据管理、能力管理、组件管理三个管理域基础功能，实现对八大中心的有效管理。具体要具备以下几种能力：

元数据管理主要完成对数据模型的管理，包括对内置对象的数据结构进行扩展、部分字段的设定以及对应用中的定制对象进行定义等功能。

能力管理主要针对能力和功能的管理，主要包括：（一）对中台预置的配置项进行注册和发现；（二）中台预留抽象类，实现应用的定制化开发，通过机制进行注册和发现并提供给应用使用，具体需实现以下几种功能：

（1）在代码中使用统一注释，通过扫描可以自动把注释部分的代码上报到能力管理实现注册；

（2）在能力对应的代码进行修改后，扫描机制也能在一定的时机进行更新；

（3）通过统一的编码规范，对某些类预留抽象类，可暴露给应用方自己进行实现；

（4）应用方对抽象类进行实现后，可通过扫描机制发现，并让应用进行调用。

组件管理主要针对页面组件和服务组件的管理，页面组件在设计时需要区分面对不同用户的页面组件管理，如用户、商城、运营人员。前端的组件最终以页面编辑器的方式实现，后端的页面组件库，则需要实现与全局管理中的资源、菜单、角色管理配合，共同满足业务需求。

通过以上三种能力，实现对数据模型、能力、功能以及页面的统一管理需求。同时，还需要能够按照新系统开发迭代业务需求，通过配置化、低代码的方式，组装成新内容。

在以上业务逻辑中，还需要满足以下几点：

（1）所有的模块均需在业务中台中进行定义，需要有统一的实体编号生成机制，且这个统一的机制能够与业务身份所需要的信息进行关联；

（2）模块与组件由开发方生产，可以被任一消费方、开发方、运维方调用，而不需要进行代码上的重复开发；

（3）业务中台的能力都是通过接口提供给上方的功能或者页面，所以所有应用对应的底层业务逻辑代码，都要使用业务中台的代码，并且在开发时要做好代码本地化部署