系统集成的本质就是最优化的综合统筹设计，一个大型的综合计算机网络系统，系统集成包括软件、硬件、操作系统技术、数据库技术、网络通讯技术等的集成，以及不同厂家产品选型，搭配的集成，系统集成所要达到的目标整体性能最优，即所有部件和成分合在一起后不但能工作，而且全系统是低成本的、高效率的、性能匀称的、可扩充性和可维护的系统。
（2）系统集成特点
[1]系统集成要以满足用户对需求为根本出发点。
[2]系统集成不是选择最好的产品的简单行为，而是要选择最适合用户的需求和投资规模的产品和技术。
[3]系统集成不是简单的设备供货，它体现更多的是设计，调试与开发，是技术含量很高的行为。
[4]系统集成包含技术，管理和商务等方面，是一项综合性的系统工程。技术是系统集成工作的核心，管理和商务活动是系统集成项目成功实施的可靠保障。
[5]性能价格比的高低是评价一个系统集成项目设计是否合理和实施成功的重要参考因素。
(3)典型的系统集成技术
1.数据库与数据仓库技术
传统的数据库以单一的数据源即数据库为中心，进行事务处理、批处理、决策分析等数据处理工作，主要有操作型处理和分析型处理两类。
分析型处理则用于管理人员的决策分析，经常要访问大量的历史数据。
数据仓库（DataWarehouse）是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，用于支持管理决策。可从两个层面理解数据仓库：
首先数据仓库用于决策支持，面向分析型数据处理，不同于企业现有的操作型数据库；
其次数据仓库是对多个异构数据源的有效集成，集成后按主题重组，且放在数据仓库中的数据一般不再修改。
数据仓库系统结构包含四个层次：
l数据源，数据仓库系统的基础；
l数据的存储与管理，核心；
l联机分析处理（OLAP），服务器对分析需要的数据进行有效集成，按多维模型组织，以便进行多角度、多层次的分析并发现趋势；
l前端工具。
2.WEBServices技术
web服务定义了一种松散的、粗粒度的分布式计算模式，使用标准的HTTP(S)协议传送XML表示和封装的内容；
webservices技术使得运行在不同机器上的不同应用无需借助附加的、专门的第三方软件或硬件，可相互交换数据或集成。根据webservices服务规范来实施的应用与应用之间无论它们使用什么语言、平台或者内部协议，都可以互相交换数据。
XML，可拓展性标记语言，类似HTMl，设计宗旨是传输数据，而非显示数据；XML标签没有被预定义，需要自行定义，是W3C的推荐标准。
3.JavaEE
JavaEE（JavaPlatformEnterpriseEdition）即Java的平台企业版，是Sun公司为企业级应用推出的标准平台，用来开发B/S架构软件，JavaEE是一个框架，也可以说是一种规范。
4..NET架构
.NET是微软新一代技术平台，为敏捷商务构建互联互通的应用系统。它的执行机制与很多编程语言都不同，先将高级语言（C#、VB）编译成为中间语言（IL），然后在编译为机器语言。
5.软件引擎技术
6.组件在系统集成项目中的重要性
组件是实现了某些功能的、有输入输出接口的黑盒子，它将一些人们所关心的，但不便让最终用户去直接操作的细节进行封装，同时实现各种业务逻辑规则，用于处理用户的内部操作细节。
常用的组件标准有：微软的COM/DCOM/COM+、OMG的CORBA、Java的RMI/EJB。
二、系统集成方法
（1）文件传输（共享）
文件共享传输的方式是一种简单直观的办法。它的典型交互场景如下：
文件共享传输方式的缺点：
1、无法避免物流系统与其他系统同时修改该文件，即在物流应用产生文件的时候无法保证集成应用不去修改；
2、通信问题，即文件产生后怎么通知集成应用的问题；
3、集成系统之间信息不同步。
文件共享传输方式的优势：
1、在信息交换不是很频繁，而且对于信息的及时性要求不太高的情况下，文件传输方式简单直接。
2、可以采用一些timerjob的方式来产生和消费文件。保证两者不产生冲突和他们正确的执行顺序。
（2）共享数据库
将数据库作为相对独立提供服务的一部分。对于其他集成系统的对接比较容易，这种集成的方式如下图：
共享数据库的优势：
可以保证数据的一致性。共享数据库里所有的数据都是统一存储在公共的数据库里，可以保证数据的同步和一致性。对于任何一个系统产生的数据或者变化，另外一个系统马上可以看到。
共享数据库的缺点：
1、对于多个应用来说，这个共享数据库需要能够适应他们所有的场景。不同的应用考量的点是不一样的，要能适应所有的需求对于数据库这一部分就显得尤其的困难。
2、性能方面。不同的应用可能会同时访问相同的数据导致数据访问冲突，因此也会带来如死锁等问题。所以说，共享数据库方案出现问题的根源在于用一种统一的数据模型来解决各种不同的应用需求是并不现实的。
（3）RPC（远程过程调用）
远程过程调用的方法典型的如Java的RMI。典型的应用场景如下：
(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风格接口实现，协议栈如图所示：
a业务消息
b会话数据
cHTTP/HTTPS
dTCP/IP
e底层承载
在接口协议中，包含接口的版本信息，通过协议版本约束服务功能规范，支持服务平台间接口协作的升级和扩展。一个服务提供者可通过版本区别同时支持多个版本的客户端，从而使得组件服务的提供者和使用者根据实际的需要，独立演进，降低系统升级的复杂度，保证系统具备灵活的扩展和持续演进的能力。
（8）业务消息约定
请求消息URI中的参数采用UTF-8编码并经过URLEncode编码。
应答消息根节点为“response”，每个响应包含固定的两个属性节点：“status”和“message”。它们分别表示操作的返回值和返回消息描述，其他的同级子节点为业务返回对象属性，根据业务类型的不同，有不同的属性名称。
当客户端支持数据压缩传输时，需要在请求的消息头的“Accept-Encoding”字段中指定压缩方式(gzip)，如消息可以被压缩传输则平台将应答的数据报文进行压缩作为应答数据返回，Content-Length为压缩后的数据长度。
（9）响应码规则约定
响应结果码在响应消息的“status”属性中，相应的解释信息在响应消息的“message”属性中。解释消息为终端用户可读的消息，终端应用不需要解析可直接呈现给最终用户。响应结果码为6位数字串。根据响应类型，包括以下几类响应码。
l0：成功；
l1XXXXX：系统错误；
l2XXXXX：输入参数不合法错误；
l3XXXXX：应用级返回码，定义应用级的异常返回；
l4XXXXX正常的应用级返回码，定义特定场景的应用级返回说明。
（10）数据管理
1、业务数据检查：接口应提供业务数据检查功能，即对接收的数据进行合法性检查，对非法数据和错误数据则拒绝接收，以防止外来数据非法入侵，减轻应用支撑平台系统主机处理负荷。
对于接口，其业务数据检查的主要内容有以下几个方面：
l数据格式的合法性：如接收到非预期格式的数据。包括接收的数据长度，类型，开始结束标志等。
l业务类型的合法性：如接收到接口指定业务类型外的接入请求。
l对于业务数据检查中解析出非法数据应提供以下几种处理方式：
l事件报警：在出现异常情况时自动报警，以便系统管理员及时进行处理。
2、数据压缩/解压：接口根据具体的需求应提供数据压缩/解压功能，以减轻网络传输压力，提高传输效率，从而使整个系统能够快速响应并发请求，高效率运行。
在使用数据压缩/解压功能时，应具体分析每一类业务的传输过程、处理过程、传输的网络介质、处理的主机系统和该类业务的并发量、峰值及对于所有业务的比例关系等，从而确定该类业务是否需要压缩/解压处理。对于传输文件的业务，必须压缩后传输，以减轻网络压力，提高传输速度。
在接口中所使用的压缩工具必须基于通用无损压缩技术，压缩算法的模型和编码必须符合标准且高效，压缩算法的工具函数必须是面向流的函数，并且提供校验检查功能。
（11）完整性管理
根据业务处理和接口服务的特点，应用系统的业务主要为实时请求业务和批量传输业务。两类业务的特点分别如下：
1、实时请求业务：
[1]采用基于事务处理机制实现
[2]业务传输以数据包的方式进行
[3]对传输和处理的实时性要求很高
[4]对数据的一致性和完整性有很高的要求
[5]应保证高效地处理大量并发的请求
2、批量传输业务：
[1]业务传输主要是数据文件的形式
[2]业务接收点可并发处理大量传输，可适应高峰期的传输和处理
[3]要求传输的可靠性高
根据上述特点，完整性管理对于实时交易业务，要保证交易的完整性；对于批量传输业务，要保证数据传输的完整性。
(12)接口双方责任
2、消息响应方：遵循本接口规范中规定的验证规则，对接收的数据进行验证，保证数据的完整性、准确性。
及时响应并解决接口数据接收过程中出现的问题。
3、异常处理：对接口流程调用过程中发生的异常情况，如流程异常、数据异常、会话传输异常、重发异常等，进行相应的异常处理，包括：
l对产生异常的记录生成异常记录文件。
l针对可以回收处理的异常记录，进行自动或者人工的回收处理。
（13）接口的可扩展性规划与设计
各个系统间的通信接口版本信息限定了各个系统平台间交互的数据协议类型、特定版本发布的系统接口功能特征、特定功能的访问参数等接口规格。通过接口协议的版本划分，为客户端升级、其他被集成系统的升级、以及系统的部署提供了较高的自由度和灵活性。
系统可根据接口请求中包含的接口协议版本实现对接口的向下兼容。系统平台可根据系统的集群策略，按协议版本分别部署，也可多版本并存部署。由于系统平台可同时支持多版本的外部系统及客户端应用访问系统，特别是新版本客户端发布时，不要求用户强制升级，也可降低强制升级安装包发布的几率。从而支持系统的客户端与系统平台分离的持续演进。
（14）接口安全性设计
为了保证系统平台的安全运行，各种集成的外部系统都应该保证其接入的安全性。接口的安全是平台系统安全的一个重要组成部分。保证接口的自身安全，通过接口实现技术上的安全控制，做到对安全事件的“可知、可控、可预测”，是实现系统安全的一个重要基础。根据接口连接特点与业务特色，制定专门的安全技术实施策略，保证接口的数据传输和数据处理的安全性。
系统应在接口的接入点的网络边界实施接口安全控制。接口的安全控制在逻辑上包括：安全评估、访问控制、入侵检测、口令认证、安全审计、防(毒)恶意代码、加密等内容。
1、安全评估：安全管理人员利用网络扫描器定期(每周)/不定期(当发现新的安全漏洞时)地进行接口的漏洞扫描与风险评估。扫描对象包括接口通信服务器本身以及与之关联的交换机、防火墙等，要求通过扫描器的扫描和评估，发现能被入侵者利用的网络漏洞，并给出检测到漏洞的全面信息，包括位置、详细描述和建议改进方案，以便及时完善安全策略，降低安全风险。
接口的配置文件包括接口服务间相互协调作业的配置文件、系统平台与接口对端系统之间协调作业的配置文件，对接口服务应用的配置文件进行严格控制，并且配置文件中不应出现口令明文，对系统权限配置限制到能满足要求的最小权限，关键配置文件加密保存。为了防止对配置文件的非法修改或删除，要求对配置文件进行文件级的基线控制。
2、访问控制：访问控制主要通过防火墙控制接口对端系统与应用支撑平台之间的相互访问，避免系统间非正常访问，保证接口交互信息的可用性、完整性和保密性。访问控制除了保证接口本身的安全之外，还进一步保证应用支撑平台的安全。
系统对接口被集成系统只开放应用定义的特定端口。
采用防火墙的地址翻译功能，隐藏系统内部网络，向代理系统提供翻译后的接口通信服务器地址及端口，禁止接口对端系统对其它地址及端口的访问。
对通过/未通过防火墙的所有访问记录日志。
3、入侵检测：接口安全机制应具有入侵检测(IDS)功能，实时监控可疑连接和非法访问等安全事件。一旦发现对网络或主机的入侵行为，应报警并采取相应安全措施，包括自动阻断通信连接或者执行用户自定义的安全策略。
为保证接口的自身安全，对接口通信服务器和其它设备的操作和管理要求采用强口令的认证机制，即采用动态的口令认证机制。
5、安全审计：为了保证接口的安全，要求对接口通信服务器的系统日志、接口应用服务器的应用日志进行实时收集、整理和统计分析，采用不同的介质存档。
6、防恶意代码或病毒：由于Internet为客户提WEB服务，因此，对于Internet接口要在网络分界点建立一个功能强大的防恶意代码系统，该系统能实时地进行基于网络的恶意代码过滤。建立集中的防恶意代码系统控制管理中心。
三、系统集成方案
1.整体开发项目采用微服务的技术架构，各微服务中心之间的接口调用采用RPC调用，消息传输格式为json。
2.整体开发项目对外提供的能力，如对各销售渠道前端产品提供的商品、订单、库存等能力服务，通过API网关封装为HTTP接口，消息传输格式为json。
3.整体开发项目也可以集成的外部第三方平台及能力，如天猫&京东等合作商城、仓储WMS、物流TMS等，通过集成平台进行集成，由集成平台屏蔽外部接口的版本变更或不同外部平台供应商接口的差异。集成平台对外接口为HTTP，对内根据业务场景不同，可采用RPC、HTTP或消息队列MQ等不同的接口方式。对外消息传输格式采用第三方平台的消息格式类型，如XML或SOAP等，对内消息格式尽量转换为json。
4.跟外部第三方平台的集成根据业务场景也会采用文件传输的方式，如跟第三方物流运单、结算单、对账单等的数据交换，数据提供方生成文件放入指定的文件目录，数据消费方下载文件进行处理。
6.整体开发项目跟BI系统的数据对接方式为BI系统通过ETL工具对新企业的读库进行数据抽取。
（1）系统集成特征
本期项目系统平台不是孤立的，跟其他周边系统形成紧密的业务集成关系。
1．新系统通过接口方式对销售渠道包括自营网站商城（PC、APP、H5、小程序）、ARS语音下单及第三方在线商城提供商品、用户、会员、订单、库存等服务，支撑各销售渠道的销售业务。
2．履约方面，新企业通过接口方式跟仓储系统WMS、物流配送TMS进行库存、配送发货等业务握手完成订单履约。
4．跟其他消息服务如SMS短信、邮件系统、Push推送平台等完成对用户的消息发送。
5．跟企业管理平台，暂时分析无直接业务对接关系，需调研后确认。
6．其他。
（2）架构集成方案
在本项目建设过程中，需要和外围系统对接实现集成服务。
1、采用微服务的技术架构，各微服务中心之间的接口调用采用RPC调用，消息传输格式为json。
2、对外提供的能力，如对各销售渠道前端产品提供的商品、订单、库存等能力服务，通过API网关封装为HTTP接口，消息传输格式为json。
3、需要集成的外部第三方平台及能力，如物流平台、外呼平台等，通过集成平台进行集成，由集成平台屏蔽外部接口的版本变更或不同外部平台供应商接口的差异。集成平台对外接口为HTTP，对内根据业务场景不同，可采用RPC、HTTP或消息队列MQ等不同的接口方式。对外消息传输格式采用第三方平台的消息格式类型，如XML或SOAP等，对内消息格式尽量转换为json。
4、跟外部第三方平台的集成根据业务场景也会采用文件传输的方式，如跟第三方物流公司运单、结算单、对账单等的数据交换，数据提供方生成文件放入指定的文件目录，数据消费方下载文件进行处理。
6、跟BI系统的数据对接方式为BI系统通过ETL工具对系统的读库进行数据抽取。
（3）系统接口方案
1、接口原则
接口提供方提供接口方案，包括接口形式、传输协议及消息格式，接口调用方进行接口适配。为便于统一监控和接口管理，原则上建议内部接口采用RPC，外部接口采用HTTP，对实时性要求不高或下游接口可异步处理的接口调用采用MQ。
2、接口方式
1)消息接口
同步请求/应答方式：客户端向服务器端发送服务请求，客户端阻塞等待服务器端返回处理结果。
异步请求/应答方式：客户端向服务器端发送服务请求，与同步方式不同的是，在此方式下，服务器端处理请求时，客户端继续运行；当服务器端处理结束时返回处理结果。
会话方式：客户端与服务器端建立连接后，可以多次发送或接收数据，同时存储信息的上下文关系。
2)文件接口
3)消息队列
广播通知方式：由服务器端主动向客户端以单个或批量方式发出未经客户端请求的广播或通知消息，客户端可在适当的时候检查是否收到消息并定义收到消息后所采取的动作。
事件订阅方式：客户端可事先向服务器端订阅自定义的事件，当这些事件发生时，服务器端通知客户端事件发生，客户端可采取相应处理。事件订阅方式使客户端拥有了个性化的事件触发功能，方便客户端及时响应所订阅的事件。
3、消息接口消息格式
json
xml
SOAP
以上接口消息格式尽量采用json。
（4）系统接口监控方案
TraceInsight负责链路追踪，针对现有的分布式系统开发，实现了从web或service入口到数据库类中间件调用全链路记录，支持采样统计，并记录链路中各阶段的性能指标，定时发送追踪数据到数据中心供监控分析及告警。
追踪记录每次调用的依赖关系、持续事件甚至参数和异常。
通过应用的追踪数据，可以计算出应用间调用关系，应用与数据库中间件的拓扑结构，如下所示，其中EU（EnderUser）代指用户，每个节点代表一个应用或者数据库、中间件，连接2个节点的线条代指调用关系与调用次数。
数据库事物展示了数据库事物详情，以Web应用中DAO方法维度（mybatis）统计调用明细，耗时前五的查询性能趋势，总体吞吐量，与慢数据库追踪。
吞吐量Top5：展示了最近一小时内（可选）每分钟被请求数据库查询排列前五位的次数与趋势。
缓存事务主要包括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加载线程。
浏览器监控总共分为"访问域名"，"访问页面"，"定位分析"，"Ajax接口"，"脚本错误"，"浏览器性能"，"摘要"，"地理"八个维度。
访问域名
（5）系统平台集成能力
系统接口服务规范化管理：发布基于Webservice的常用业务接口；具备系统接口服务的管理工具，可查看、维护、测试接口的WSDL文件。
我公司系统平台的构件可区分为客户端构件和服务端构件，对于服务端构件，可以通过“发布”功能，发布为标准的WebService服务接口。
同时，系统平台提供“常用业务接口”功能，可以查看当前系统里所有的WebService服务接口，并可以联查每个WebService服务的WSDL描述信息。
平台预置常用业务数据接口：平台预置常用业务数据的接口，包括：凭证信息、应收单、应付单、预算数。
在本项目产品中，所有的业务数据接口，是以数据交换包的形式体现的，系统预制了大量的常用业务数据接口，包括凭证接口、审计接口、应收应付、主数据等，如下图所示：
Portal支持：平台已具有成熟的Portal集成框架，能与业务流程无缝集成。
本项目企业信息门户平台是参考国外先进门户解决方案，结合国内应用实际设计研发而成的一套企业门户系统，即是一套门户开发框架，也是一套门户应用系统。
本项目企业信息门户平台具有优秀的跨系统信息集成能力，通过一套信息集成与展现模型，把与异构系统的接口屏蔽在数据连接层面，通过预置各种常见数据连接器及信息描述规范，能够快速实现系统集成；本项目企业信息门户平台具有高度可扩展性，系统对门户展现、通讯、事件等进行了统一封装，内置各种配置管理工具和开发工具，通过这些工具，可快速实现系统功能扩展；本项目企业信息门户平台还具有强大的内容管理能力，对企业的各种结构化和非结构化信息都能够进行良好的支持，能够为这些信息提供的统一呈现和检索服务。
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技术和业务整合方面有着深远的意义。
基于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技术
八、非对称加密技术
1976年，美国学者Dime和Henman为解决信息公开传送和密钥管理问题，提出一种新的密钥交换协议，允许在不安全的媒体上的通讯双方交换信息，安全地达成一致的密钥，这就是“公开密钥系统”。相对于“对称加密算法”这种方法也叫做“非对称加密算法”。
与对称加密算法不同，非对称加密算法需要两个密钥：公开密钥（Publickey）和私有密钥（Privatekey）。公开密钥与私有密钥是一对，如果用公开密钥对数据进行加密，只有用对应的私有密钥才能解密；如果用私有密钥对数据进行加密，那么只有用对应的公开密钥才能解密。因为加密和解密使用的是两个不同的密钥，所以这种算法叫作非对称加密算法。
贸易方利用该非对称加密算法实现机密信息交换的基本过程是：贸易方甲生成一对密钥并将其中的一把作为公用密钥向其他贸易方公开；得到该公用密钥的贸易方乙使用该密钥对机密信息进行加密后再发送给贸易方甲；贸易方甲再用自己保存的另一把专用密钥对加密后的信息进行解密。贸易方甲只能用其专用密钥解密由其公用密钥加密后的任何信息。
在微软的WindowNT的安全性体系结构中，公开密钥系统主要用于对私有密钥的加密过程。每个用户如果想要对数据进行加密，都需要生成一对自己的密钥对（Keypair）。密钥对中的公开密钥和非对称加密解密算法是公开的，但私有密钥则应该由密钥的主人妥善保管。
使用公开密钥对文件进行加密传输的实际过程包括四步：
1.发送方生成一个自己的私有密钥并用接收方的公开密钥对自己的私有密钥进行加密，然后通过网络传输到接收方；
2.发送方对需要传输的文件用自己的私有密钥进行加密，然后通过网络把加密后的文件传输到接收方；
3.接收方用自己的公开密钥进行解密后得到发送方的私有密钥；
4.接受方用发送方的私有密钥对文件进行解密得到文件的明文形式。
因为只有接收方才拥有自己的公开密钥，所以即使其他人得到了经过加密的发送方的私有密钥，也因为无法进行解密而保证了私有密钥的安全性，从而也保证了传输文件的安全性。实际上，上述在文件传输过程中实现了两个加密解密过程：文件本身的加密和解密与私有密钥的加密解密，这分别通过私有密钥和公开密钥来实现。
五、系统集成策略
1、统一的标准规范设计
项目标准规范体系是由一定范围内的具有内在联系的标准组成的科学的有机整体，它包括现有的、正在制定的和应着手制定的各类标准，是促进一定范围内的标准组成趋向科学化和合理化的手段，通常用标准体系框架和明细表的方式来表达。
一、大局着眼，急用先行
全面分析项目需求，结合项目信息化化标准体系，从信息化建设的高度着眼，完善信息化标准体系框架，本着急用先行的原则制定编制计划和标准经费概算，明确在本项目中需要完成的标准以及需要引用的标准，配合本项目的实施进度。
二、结构合理、前瞻性强
标准体系是支撑本项目实施质量的标准规范框架，其设计过程必须充分考虑标准之间的互补关系，以合理的结构，全面地体现本项目的建设需要，以规范本项目的建设并完善我国的信息化标准体系。同时，信息化建设日新月异，标准体系设计必须有一定的前瞻性，充分考虑未来企业的发展趋势。
三、充分利用现有标准
标准体系设计要充分继承现有客户端现有标准，对于现有标准可以满足项目需求的，要尽量引用，减少标准的新编任务。
四、统一标准，保障安全
统一标准，保障安全是项目建设必须坚持的重要原则之一。
五、切实可行，准确实用
标准和规范必须根据实际情况而制订和修改，这样才能使标准符合实际。标准的制订和修订要求准确实用，使执行者易于理解和执行，具有较强的可操作性。
六、遵循电子政务的国家标准、企业标准、国际标准
标准和规范的制订应遵照、继承和贯彻国家标准、企业标准，避免重复建设，参考国际标准和国外先进标准。标准和规范的采用顺序是：先国家标准，后企业标准，最后是国际标准。
七、前瞻性强，易于扩展
由于项目建设是一个跨部门、复杂的系统，各个业务部门都有其特点，因此标准的制订和采用应具有前瞻性并成熟可用，满足易于扩展的需求，使之能适应企业的变化。
八、统一组织，各级参与
标准和规范建设涉及面广，不是一个单位、一个部门所能解决的。因此，在标准的制订过程中必须调动各部门的积极性，吸收尽可能多的单位参与。特别是业务处理规范和业务数据标准的制订，必须有各业务部门的业务人员的参与。在标准和规范的执行过程中，也需要各级业务部门的配合。在统一采集数据的基础上，建立系统的、分层次的管理指标规范。
系统性能设计
一、客户端快速访问响应设计
1、管理项的数量、大小和复杂度
（1）管理项的数量
发送作为浏览器或客户端热点图的菜单，而不是带有单独图形元素的表格。因为传输表格本身就很慢，特别是那些带有图形元素的表格。
将项结合起来，这样Web服务器只需用较少的机器周期就能检索和传输内容了。
避免使用鼠标滑过时产生效果的GIF格式的图片。使用动态改变外观的GIF鼠标滑过效果图似乎很有趣，不过为实现这种操作效果，需要下载额外的GIF图片。不使用鼠标滑过效果的GIF图片可以减少页面中项的总和。
虽然大多人为减少项的数量削弱了界面的一些功能，但还是有其它的技巧存在。
（2）管理项的大小
（3）管理项的复杂度
页面的复杂度影响页面呈现的速度。在选择具有增加复杂度特性的项时，请考虑所涉及的延迟。决定页面复杂度的因素包括大表格、动态计算大小的表格单元、Java脚本和Java小应用程序。动画GIF、图像颜色管理和图像抖动也造成了延迟。延迟因浏览器的不同而不同，还因浏览器中级别的不同而不同；幸好有了新的级别，它们将趋于更快，但并不总是如此。
2、控制连接数量
（1）、如果必须传输多个项，持久的连接可减少连接设置开销
（3）、Web站点可以在传输完一项后，对保持打开套接字连接或关闭进行控制。如果一个Web站点关闭了连接，浏览器必须为每一项建立一个新的连接。在装入页面时，这种连接开销会显著扩大访问者感觉到的延迟。大多数浏览器试图在它们这一端保持连接的打开状态，但两端必须都同意让连接保持在打开状态。是否保持连接开启的选项通常取决于Web服务器端，服务器上有个配置选项，这个选项决定了在浏览器有持久连接能力时，服务器是否支持持久连接的使用。
（4）、如果运行一个海量网站，还是不要保持持久连接，因为这种连接会造成所有端口或其它受限的服务器资源（如线程）都被占用。可以在服务器端分配额外资源，从而支持持久连接。
（5）、我们的目标是每页只有四个连接。随着服务器和HTTP服务器软件的发展，它们打破了使资源受限制的局限。当服务器端的连接保持打开状态时，站点访问者会受益。
3、控制被访问的服务器数量
尽可能使用直接链接，避免中间页面这一开销。重定向是专用于—当一组新的页面从原有的书签中装入时，将浏览器指向它。
4、控制空白的使用
页面设计者经常使用空白帮助他们使页面表现更形象。没有额外的空白，浏览器也可以工作的很好。在将页面放到产品Web服务器上之前，可以考虑使用可用的实用程序消除HTML源码中额外的空白。
避免在需要加密的页面使用额外的空白。虽然明文中额外空白可以在拨号线路中被很好压缩，但加密的空白却不能被很好的压缩，因为这已不再是一个重复字符符号的字符串。加密后，每个重复空白块通常以独特的字节字符串表示，这就使它们不大可能被调制解调器压缩。每个额外字节的传输也占用资源，而对站点访问者没有任何好处。
5、管理装入顺序
6、了解数据安全性的影响
加密页面上的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、数据访问性能优化
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.高效性
7.2.并发性
各个子系统根据业务需求，稳定支持1000至50000人的集中访问与使用。高并发的场景举例如下，系统要保障包含但不限于以下业务场景等能够稳定、正确、有效的运行。
例二：使用零售扫码设备及系统的零售户8W，每一笔扫码交易数据实时上传，预计日均上传笔数100万笔，系统需要保障交易数据能够稳定、及时的从零售户端传回服务器，并能正确的处理突发性的大量数据同时传回服务器时的并发性问题。
7.3.兼容性
（一）系统需对各类常见浏览器进行兼容性优化，保障系统能在各类浏览器下正确打开与使用。包括但不限于：IE8及以上版本、360（兼容模式）、搜狗（兼容模式）（Trident内核）；Firefox（Gecko内核）；Chrome、360（极速模式）、搜狗（极速模式）（Blink内核）、EDGE。
（二）系统需对移动端Android系统和IOS系统、pc端window7系统和window10系统及主流国产操作系统等进行兼容性支持；web类系统根据业务需要，需对移动与PC端进行双端支持，保证各设备不同屏幕尺寸下、不同系统下能够合理、正确的展示与使用各项功能。后台管控子系统要求按照互联网架构，基于数字中台共享服务中心设计和开发。并支持对后续新增国产化操作系统进行适配性改造。
7.4.稳定性
4、易用性设计
6、可扩展与可维护性设计
（一）可扩展性
（二）可维护性
6、敏捷迭代性基础建设
有效进行高层次的业务抽象，对所有业务进行横向、纵向拆解切分，合并相同部分，独立不同部分。制定一系列标准，在业务逻辑之上能够提供统一流程编排服务，实现微服务化。同时，通过可视化、配置化、低代码的方式，降低对每个API学习域的熟悉成本，从而不抵消API复用的便利性。
实现可视化，有效降低使用方的学习成本；实现配置化，能够把各个业务使用的能力集中管理，让熟悉业务的人员直接控制应用中的业务逻辑，更好的执行标准；实现低代码，降低开发人员学习中台复杂技术框架的门槛，使其能忽略底层的技术实现，只关心业务逻辑部分。
同时，做好系统设计与中台化标准之间的平衡，在满足复用性的基础上，有效的实现快速低成本创新。
建立围绕运行域与管理域的中台整体应用架构，以页面、功能、能力和数据模型四个维度为标准，建立运行域八大中心共用库，同时开发元数据管理、能力管理、组件管理三个管理域基础功能，实现对八大中心的有效管理。具体要具备以下几种能力：
元数据管理主要完成对数据模型的管理，包括对内置对象的数据结构进行扩展、部分字段的设定以及对应用中的定制对象进行定义等功能。
能力管理主要针对能力和功能的管理，主要包括：（一）对中台预置的配置项进行注册和发现；（二）中台预留抽象类，实现应用的定制化开发，通过机制进行注册和发现并提供给应用使用，具体需实现以下几种功能：
（1）在代码中使用统一注释，通过扫描可以自动把注释部分的代码上报到能力管理实现注册；
（2）在能力对应的代码进行修改后，扫描机制也能在一定的时机进行更新；
（3）通过统一的编码规范，对某些类预留抽象类，可暴露给应用方自己进行实现；
（4）应用方对抽象类进行实现后，可通过扫描机制发现，并让应用进行调用。
组件管理主要针对页面组件和服务组件的管理，页面组件在设计时需要区分面对不同用户的页面组件管理，如用户、商城、运营人员。前端的组件最终以页面编辑器的方式实现，后端的页面组件库，则需要实现与全局管理中的资源、菜单、角色管理配合，共同满足业务需求。
通过以上三种能力，实现对数据模型、能力、功能以及页面的统一管理需求。同时，还需要能够按照新系统开发迭代业务需求，通过配置化、低代码的方式，组装成新内容。
在以上业务逻辑中，还需要满足以下几点：
（1）所有的模块均需在业务中台中进行定义，需要有统一的实体编号生成机制，且这个统一的机制能够与业务身份所需要的信息进行关联；
（2）模块与组件由开发方生产，可以被任一消费方、开发方、运维方调用，而不需要进行代码上的重复开发；
（3）业务中台的能力都是通过接口提供给上方的功能或者页面，所以所有应用对应的底层业务逻辑代码，都要使用业务中台的代码，并且在开发时要做好代码本地化部署。
推荐阅读
1.3常规信息系统集成技术
[图片]
324
系统集成技术的三种方案对比
910
实践案例|WebService服务，解决…
小编推荐由于历史发展原因，企业内部往往不止存在一套信息管理系统。在某些大型企业中，系统甚至会高达几十套。集团总部想要及时掌握各子公司的经营情况，但这往往需…