企业服务总线ESB方案书.docx
《企业服务总线ESB方案书.docx》由会员分享，可在线阅读，更多相关《企业服务总线ESB方案书.docx（28页珍藏版）》请在冰豆网上搜索。
企业服务总线ESB方案书
企业效劳总线ESB方案书
1需求综述
1.1主数据平台接口
系统建立与SAP相同的根底数据管理库，通过数据总线接口同步能源集团MDM中传输过来的编码或数据，以满足电子采购平台根底数据管理的需求。
根底数据信息包括：
物料编码、计量单位、供给商、客户等。
1.2业务数据接口
系统业务数据通过数据总线接口同SAP、OA、EC等系统进行数据交互。
系统必须确保通过数据总线接口访问SAP、OA、EC等系统数据与电子采购平台数据传输及时准确、数据完整统一；
1.3OA系统接口：
支持将电子采购平台中的待办事项发送到OA办公系统进行审批，并读取审批流。
1.4国家法定信息发布媒体：
按照国家相关要求，选择相关媒体建立统一接口，支持招标公告、变更公告、结果公示等的自动发布。
如国家无强行规定，可以不做接口。
2系统解决方案
2.1系统技术架构
2.1.1运行平台
运行平台内部按照集成应用的特点分为多个集成“通路〞，目前考虑分为四类通路：
1、关键效劳通路
关键业务、实时性要求高。
2、非关键通路
非关键业务，查询等。
3、效劳代理通路
从目标架构过渡过程中，与集成目标无关的可以采取“穿透〞的方式，减少实施工作量和实施本钱。
另外，复用价值较低的效劳请求也适合采用“代理模式〞。
4、低本钱通路
对于实时性要求不高，且信息量大的效劳，可采取批量处理模式，降低集成实施本钱。
实际部署环境中，每一类通路都可以有多个物理部署，用来保证系统的可靠性，同时也支持横向的扩展和减少不同系统之间的相互影响。
2.1.2开发平台
基于ESB系统标准的效劳接口定义、内部统一的元数据管理、数据结构和效劳接口定义、路由规那么等，实现多个技术通路的统一配置开发。
开发平台的是对各个技术通路实际实现方法的抽象封装。
提供效劳逻辑的开发框架和组件库，用于转换适配逻辑、公共效劳逻辑等的标准化开发、组件重用和统一管理。
2.1.3监控平台
ESB应用系统要建立统一的日志标准、流水记录标准、错误码标准、系统运行状态检测标准、系统运行状态控制标准，实现对ESB系统整体统一的监视和控制。
是
ESB系统的集成“控制面板〞。
主要功能包括：
异常监视、通知提醒、运行控制、实时查询、统计分析、效劳的配置和发布、效劳管理、统一维护和版本部署等。
由于ESB系统是整个企业的效劳访问枢纽，ESB可以集中监控企业内所有的效劳访问，能够提供各个系统的效劳质量和状态的统计数据，例如：
成功率、效劳响应时间、效劳访问量、效劳状态异常等。
2.1.4公共效劳
提供统一的流量控制效劳、日志记录、接入参数控制等公共效劳。
从而实现多技术平台、多物理部署运行环境的公共效劳支持。
2.1.5适配器
适配器是ESB系统解决与外部系统之间各类差异的总称。
ESB将外部系统分为请求系统和效劳系统两类。
2.1.5.1效劳系统适配器
对于效劳系统，尤其是遗留效劳系统，根本集成策略是由ESB工程组开发适配器进行集成。
但是效劳系统适配器，并不能解决所有的效劳适配问题，例如：
ESB效劳接口标准与效劳系统标准的复杂对应和匹配工作，尤其是涉及到多个效劳系统接口的复杂流程调用局部，如果由ESB组合这类效劳流程组合，解决相关的交易完整性、一致性问题，代价太大而且无法保证。
因此，实际集成实施过程中，不可防止的要涉及到对效劳系统的改造工作。
2.1.5.2请求系统适配器
对于请求系统，ESB的根本原那么是要求请求系统符合ESB的技术标准和效劳接口标准。
目的是减少不必要的转换适配层次，提高系统的集成效劳效率，降低资源消耗。
ESB系统可为请求系统提供API，对请求系统屏蔽通讯适配、报文组包等技术细节。
请求系统只需要理解业务层面的接口标准，从而大大简化请求系统的集成工作，同时还可以加强对请求系统的监控管理，同时为接口技术实现的升级改造提供辅助支持。
ESB也可以开发适配器，实现请求系统的集成。
主要针对那些无法改造或改造本钱过高的请求系统。
2.2部署方案
2.2.1管理监控局部部署方案
ESB系统的部署方案必须符合企业根底架构的要求。
1〕WebServer和ApplicationServer必须别离，分别部署在Web2区和APP区。
或者Web2区的应用通过生产区域的APP，访问DB。
2〕用户管理要符合集团的标准。
用户权限控制统一通过UM。
UM决定用户是否有权限操作ESB的管理监控平台。
UM权限通控制通过以后，由ESB管理监控应用来进行详细的角色权限管理。
3〕考虑到费用问题，可以采用Apache和Tomcat。
2.2.2硬件选型建议
ESB系统目标架构硬件选型主要考虑从以下因素：
1〕本钱因素
ESB系统基于Java技术实现，具有跨平台的技术优势，因此可将本钱是考虑硬件选型的首要指标，未来随着ESB应用规模的不断增长，硬件本钱在工程投入所占比重将会增加，因此选择性价比高的硬件平台是提高效费比的有效途径。
2〕硬件扩容周期
ESB作为企业内部信息化最为关键的效劳枢纽，必须能够快速响应应用规模的增长，其中包括硬件的采购周期、系统扩容部署速度。
3〕资源调配的简便性、灵活性
ESB系统应能够针对业务量的周期性变化，灵活的增减系统资源配置，资源的调整不应对集成效劳持续性造成影响。
基于上述考虑，ESB系统的硬件推荐采用刀片效劳器。
刀片效劳器还具有以下优点：
1）硬件本钱相对低廉，配套的系统软件和中间件价格也相对较低。
2）虚拟化的集中资源管理，可有效提高资源的利用率。
3）在集群中插入新的刀片，就可以提高整体性能。
4）支持热插拔，硬件资源可以轻松地进行替换，并且将维护时间减少到最小。
5）节约空间、便于集中管理、易于扩展和提供不间断的效劳。
2.2.3逻辑分区部署方案
2.2.4硬件配置建议
其对应分配如下：
名称
功能分布
配置
计算单元数量
适配器/公共效劳
适配器公共效劳
2cpu（8核）
32GBmemory
1*2
集成核心
WebMethods
MessageBroker
2cpu（8核）
32GBmemory
1*2
数据库效劳器
Oracle
2cpu（8核）
32GBmemory
1
归档数据库效劳器
Oracle
2cpu（8核）
32GBmemory
1
备份资源池
作为公共备份
2cpu（8核）32GBmemory
1
总计
7
2.2.5效劳接口标准
ESB系统负责解决实施效劳接口标准与效劳系统接口的差异，可将主要的实施工作控制在ESB工程范围内，大大降低周边系统的改造工作量，配合一些系统的瘦身方案的分阶段顺利实施。
2.2.6高性能、高可用性及扩展能力设计
高处理能力保证措施
控制信息+XML应用报文，中间层次不必解析XML应用报文，使系统不仅具备完善的管理控制能力，同时还减少了报文解析开销，提高了效率。
非阻塞的异步模式、流水线式的作业处理，提高吞吐能力。
异步记录流水日志，保证信息的完整记录，同时不影响系统的处理性能。
系统处理能力可随硬件资源的扩展线性的增长。
系统所有配置规那么均加载到Cache中，运行过程中不存在对数据库配置信息的读写操作，保证系统高效运行。
持续稳定运行保障措施
所有应用模块均为群集部署，系统不存在单点故障隐患，某个模块的故障不影响正常运行。
系统应用版本的升级可按模块分别进行，不影响业务的正常运行。
采用数据库分区技术，实现海量数据记录的清理和分区切换过程15秒钟内完成，无需采用与应用相关的数据库分表方式，实现批量数据处理对总线应用透明。
系统提供完备的动态平安刷新手段，配置信息可运行时在线刷新。
可扩展性
系统可以在CPU、内存等资源增加及扩容的情况下自我线性扩展处理能力；每个逻辑模块可以采用横向扩展的多物理模块部署。
中间用队列进行通讯。
可维护性
系统具有较为完善的用户管理界面，提供对系统所有功能的维护与参数配置管理的功能；系统采用统一的效劳模式和开发框架，从开发商增加可维护性，系统部署上采用多逻辑单元别离部署，减少系统内部的耦合度，增加整个系统的可维护性。
2.2.7完善的平安机制
企业应用集成技术使复杂的业务流程、大量的信息和数据在各IT应用系统和业务部门之间高效的流转和共享，实现业务流程标准化和自动化，促进业务流程优化，提高建行运营效率。
任何不平安因素都会造成不可估量的损失，故所有数据的传输、处理、交换都必须在良好的平安环境下进行，因此，必须建立一套完整的平安机制，以确保整个通信系统的平安运行。
方案主要为ESB系统提供如下几个方面的平安效劳：
1.密钥管理
提供平安有效的密钥管理方案，实现应用系统和ESB系统的密钥产生、密钥分发、密钥更新、密钥注销等。
提供密钥的自动更新机制，保证密钥的平安性，提供高效的对称密码算法，确保应用系统具有可用性和易用性。
2.身份认证
保证接入ESB系统的合法性，提供给用系统和ESB系统之间的双向身份认证，采用基于证书的认证模式，系统使用的数字证书由第三方CA或者采用自运行维护的CA提供。
CA证书采用离线下发的方式，以PKCS#12文件的格式安装到ESB系统和应用接入系统。
身份认证完成后，双方得到一个64个字节的随机数，通讯双方使用的对称密钥都是基于这一组随机数产生，对称密钥的选取规那么双方使用相同的策略。
对称密钥和对方的公钥信息存放在系统主机的共享内存，方便应用系统加密使用
3.通讯加密
ESB系统的平安性是保障IT应用系统平安可靠运行的重要环节，使用PKI技术实现系统的密钥管理和通讯加密是目前解决此类问题的最有效途径，应用系统和ESB系统之间通讯的报文使用对称算法加密保护其机密性。
为了提高密码运算的处理速度，这里推荐使用AES算法，密钥的长度为128bit。
通讯双方在身份认证完成后，在共享内存中保存对称密钥。
客户端和效劳器端的加密流程如下：
客户端加/解密流程：
1）查询共享内存中的对称密钥和算法ID，根据加密要求选取对称密钥，如果共享内存中没有对称密钥，加/解密失败。
2）使用查询得到的对称加密密钥，对报文进行加/解密处理。
效劳器端加/解密流程：
1）根据客户端的系统代码，查询共享内存的加密密钥和算法ID，如果共享内存中没有对称密钥，加/解密失败。
2）使用查询得到的对称密钥，对报文进行加/解密处理。
4.关键字段MAC
2.3整体解决方案
ESB集成技术架构方案划分为四个层面：
渠道通迅接入、数据交换层、平台效劳调度层、效劳适配层。
系统的每个层次都可进行横向扩展，实际应用中系统处理能力可以线性增长。
●对于渠道效劳请求的接入，ESB提供标准的通迅协议〔支持TCP/IP、、SNA、FTP、MQSeries、JMS等协议和中间件〕和ＭＢＳＤ标准接口标准，同时还为请求系统提供效劳请求的API，屏蔽通讯协议和报文格式的技术细节，能够提高请求系统的集成开发效率、减少转换适配环节，同时还大大加强了总线系统对接入的控制和管理，促进了集成应用的快速推广和可靠运行。
●对于改造本钱过高的存量系统，
通过集成开发在数据交换层实现分类路由、同步异步转换、消息格式转换、代码转换等功能。
●平台效劳调度支持四种模式：
〔一〕、ＭＢ通道，用于高时效性、高一致性、高吞吐能力的效劳；
〔二〕、ＷＥＢＭＥ通道，用于时效性和一致性要求不高的效劳；
〔三〕、效劳代理通道，目标架构过渡过程中，与当期集成目标无关，可以采取“穿透〞的方式，减少实施工作量和实施本钱。
另外，复用价值较低的效劳请求也适合采用“代理模式〞；
〔四〕、低本钱通道，对于实时性要求不高，且信息量大的效劳，可采取批量处理模式，降低集成实施本钱及节省系统资源。
●所有适配器需要在对存量系统分析后集成开发，ESB集成方案中集成产品的相互访问统一使用ＭＱ队列方式。
2.3.1接入控制
需要完成以下功能：
1.对渠道提供不同协议的接入功能，包括MQ，webmethods,等协议的接入。
2.对不同的渠道提供不同的接入点，实现系统负载均衡和最大限度的故障隔离，提供高容量，高可靠性的效劳。
3.参数效劳为渠道提供统一效劳接口模式，伺服渠道下载需要的通道接入信息。
4.渠道通过轮询请求方式主动下载版本变化信息，初始化变化的连接池。
5.效劳端进行主动控制，实时控制渠道的接入通路。
6.当某一接入点故障时，通过主动控制渠道接入点，自动切换到可以的接入点，实现故障的完全隔离。
7.对压力较大的接入点，通过主动控制，把局部数据切换到压力较小的通路，实现实现负载控制。
8.效劳端为渠道维护相应标识信息和其所有当前版本和历史版本信息。
9.通过维护历史版本信息，实现版本回退功能。
实现方案：
1.整体架构图
2.3.2通信接入模块
负责和外部系统进行通讯，进行原始报文数据的传输。
通信接入层实现以下功能：
1．利用系统层通讯协议和请求系统进行通讯，包括TCP/IP、、SNA、FTP、MQSeries、JMS。
2．外部系统约定的通讯方式的实现，包括如何进行通讯连接，如何进行通讯应答，如何进行数据传输，如何约定通讯报文的大小，如何确定数据传输是否完毕，如何处理通讯错误，如何关闭通讯连接，如何处理通讯层数据完整性校验等。
3．识别外部系统类型。
4多通讯连接的并发处理。
以下的功能不需要由通讯接口层完成：
1.非通讯层面的数据报文的加解密。
2.非通讯层面的数据报文的压缩，解压缩处理。
通讯接入层屏蔽了所有的通讯细节，数据交换层只知道从某个外部系统获得了或者发送了一个数据报文，至于该数据报文是如何获得或者发送的，和数据交换层本身无关。
2.3.3请求系统适配
完成从效劳端返回数据到标准输出之间的转换或从一个渠道端请求接口数据到MBSD效劳标准请求数据之间的转换。
具体功能包括：
1.应用层面的数据报文的加解密。
2.应用层面的数据报文的压缩，解压缩处理。
3.数据报文类型的识别。
4.数据报文的打包拆包，根据报文类型以及相关配置将数据报文拆分成统一的数据接口或者相反。
5.数据接口之间的转换，根据定义的规那么从一个数据接口转换成效劳数据接口或者相反。
接入适配层屏蔽了数据的具体物理表示和组织，平台效劳调度层只知道收到了一个效劳请求要求处理，至于该效劳请求是从哪个系统发起的，原始的请求数据是什么，和效劳整合层没有关系，只和数据交换层有关。
接入适配框架提供可配置的定长、变长报文转换适配器，以及可扩展的接口可以适应各种不同格式的报文转换。
同时接入框架提供了MBSD元数据管理功能，能够方便的定义报文的元数据，为报文的转换以及应用的开发提供便利。
2.4集成效劳功能
2.4.1效劳治理
提供效劳标准定义、效劳封装、注册与发布等功能,提供位置透明性的效劳路由和定位效劳ESB的效劳接口标准应该基于对业务流程的理解，经过抽象、归纳形成，效劳接口标准独立与现有系统的具体实现，接口标准具有较强的独立性、稳定性。
从而真正消除请求系统与效劳系统之间的关联关系，实现效劳的位置以及效劳的具体实现与效劳的访问过程无关。
我们提供MBSD标准落地实施的工具：
元数据管理，效劳接口定义配置，导入导出工具〔可以通过web页面形式和导出文件形式对外公布〕，效劳标准适配的开发框架。
我们提供MBSD标准落地实施的工具：
元数据管理，效劳接口定义配置，导入导出工具〔可以通过web页面形式和导出文件形式对外公布〕，效劳标准适配的开发框架。
2.4.2提供对出错效劳的及时检测和隔离功能
ESB系统实时检测效劳系统的效劳状态，当效劳出现异常时，能够及时发现，通过监控平台发出报警，通过人工手段或预先设定的规那么，对状态异常的效劳或效劳系统进行迅速隔离，防止因故障导致效劳阻塞，保证请求系统对其他效劳的正常访问。
2.4.3协议转换
支持外部系统通过TCP/IP、、SNA、FTP、MQSeries、JMS等协议和中间件与ESB平台通讯。
一般情况下，请求系统使用ESB系统提供的API，按照ESB系统的技术标准和效劳标准进行效劳访问，从而防止不必要的协议转换开销。
但是对于请求系统无法改造或改造本钱过高的情况下，ESB系统应提供接入协议适配的功能，支持外部系统通过不同的通讯协议与ESB平台通讯。
但是应注意，ESB更多的情况下是为了适应效劳系统的技术差异，才进行通讯的适配，从系统的标准化和易维护性角度考虑，不推荐被动的对请求系统进行通讯协议适配。
接入框架提供了对各种通讯协议的转换适配器，可以满足上述协议转换要求。
MQ自身作为消息中间件为JMS通讯协议提供底层的通讯效劳。
但ESB作为企业效劳总线需要有大吞吐量，而同步效劳并发有限，容易造成资源的阻塞，以异步的方式进行访问，而MQ作为消息中间件，是最好的异步通讯方式。
2.4.4消息格式转换
支持通过元数据管理消息格式定义；支持任意类型报文之间的转换。
消息格式转换是集成类系统应具备的根本功能，ESB系统对于消息格式的转换是基于配置实现的，因此消息报文的的数据域需要在配置中进行定义。
ESB的效劳接口标准标准中包括标准中使用的数据域。
在ESB系统内部数据域分为不同的类型、长度、精度等表示形式，ESB系统引用预先定义的、标准化的元数据对效劳接口标准进行描述，使用元数据可以是标准定义工作更加标准化、减少冗余、便于管理和统一维护。
元数据可根据应用范围划分成不同的“域〞，可以更加方便的进行方便维护和管理。
ESB系统一般通过配置方式实现标准与非标准的报文转换，包括：
格式转换和数据映射，对于复杂的映射规那么可以通过增加映射功能函数〔效劳组件〕的形式实现
MBSD接入框架提供了可配置的定长、变长报文转换组件，以及可扩展的接口可以适应各种不同格式的报文转换。
同时接入框架提供了MBSD元数据管理功能，能够方便的定义报文的元数据，为报文的转换以及应用的开发提供了便利。
目前已经支持XML，定长等多种报文格式。
2.4.5效劳路由
基于效劳ID、内容、结果等方式路由；交易流程能使用智能路由组合多个子交易。
我们采用两个层次的路由：
前端API进行的效劳通路路由。
前端API根据ESB平台提供的接入参数信息决定采用哪条通路〔MB/WEBMETHODS〕进行效劳访问。
核心的交易路由。
由MB/WEBMTHODS核心进行路由，根据交易码决定哪个后台效劳系统进行效劳访问。
路由方式：
效劳ID路由。
也就是交易码进行路由判断。
数据依赖路由。
动态的根据报文中的数据和配置业务规那么进行路由选择。
复杂流程路由。
在复杂组合交易中根据每一步的响应结果和配置的复杂交易流程来进行路由选择。
此路由在ESB平台的流程配置来实现。
2.4.6监控和运维
提供效劳调用的记录、测量和监控数据；提供事件检测、触发和发布功能；支持产品版本升级后对现有组件的兼容性。
ESB系统应记录每一次效劳访问的流水信息，用于统计和分析。
记录过程应该是高效的，应防止流水的记录影响效劳的执行效率。
流水记录一般只记录效劳过程的摘要信息。
需要时，可以通过开关控制翻开或关闭详细的报文信息。
系统还应及时捕获效劳处理过程中的各种异常信息，通过统一的控制台发出报警，警示信息应划分异常的类别和级别，对于重要的异常还可以通过短信等手段及时通知运维人员及时处理。
监控管理的接口定义应是可扩展的，例如异常种类、异常级别、流水信息数据项等，做到信息的获取与后续的处理动作无关，从而保证接口的兼容性、稳定性。
2.4.7效劳等级
可定义不同的效劳等级并实现具体内容。
可以从多种维度来定义效劳的属性，包括效劳的级别。
效劳的级别可以关联到不同的处理动作。
效劳级别与处理的关联关系可以通过规那么进行定义，实现功能的灵活定义与扩展。
关联的动作可以是：
处理的优先级，异常提醒方式等。
2.5系统非功能需求
2.5.1可用性
系统能提供功能方面的各种需求的实现，在运行环境下提供7*24小时NONE-STOP效劳；ESB是效劳访问的枢纽，不允许由于系统的故障和恢复过程中断系统效劳，ESB应采用群集模式保证系统的高可用性，群集模式还可以使系统资源得到充分利用。
对于数据库效劳器、通讯接入效劳起等模块的高可用性需求，为降低实现方案的复杂度和实施本钱，可采用设备之间相互热备的方式。
例如数据库效劳器可以和归档数据库效劳器采用热备的方式保证高可用性。
系统自身的批量处理，如：
数据归档清理，日志归档等工作，不能影响系统的正常运行，保证系统7*24小时连续运行。
需要定期进行的系统资源累积效应消除动作，如：
定期重启Java虚拟机消除长期运行后的堆栈碎片，应保证在其他群集模块正常运行的情况依次进行，保证系统效劳不间断。
系统的配置更新应采用动态刷新的机制联机进行，防止配置更新对系统的处理能力造成影响。
2.5.2可扩展性
系统可以在CPU、内存等资源增加及扩容的情况下自我线性扩展处理能力；系统的架构设计要保证系统的各个层次均可按照负载情况，单独进行横向的扩展，以提高处理能力。
应保证处理能力随硬件资源的扩展呈线性增长。
2.5.3可维护性
统具有较为完善的用户管理界面，提供对系统所有功能的维护与参数配置管理的功能；
系统涉及到多种平台产品和技术、采用多物理分区的部署方式，单独对每个分区进行监控和维护是不现实的，必须提供统一的管理监控界面，实现系统的集中统一管理、监控和维护。
2.5.4平安性
提供认证和授权、不可否认和机密性、平安标准的支持等。
ESB系统作为效劳访问的中间层，除了发布标准的平安标准以外，还要满足各类集成应用的平安需求，要实现与存量效劳系统的平安协议支配，因此ESB需要支持通讯层面，应用层面的平安技术标准。
例如：
对标准平安协议的支持，通讯过程加解密，MAC校验，PKI，特定场景的数字签名等。
2.5.5性能需求
统能通过招标人的压力测试。
性能指标：
日均1000万笔数据，ESB对于关键数据的处理时间<1秒，对于非关键数据ESB的处理时间<2秒。
到达系统性能指标峰值要求时，系统处理能力应留有足够的余量，CPU，内存等系统资源的使用率应低于80%，到达平均值要求时，系统资源使用率应低于50%。
保证系统在设计指标压力情况下的长期稳定运行。
2.6公用效劳
2.6.1流量控制
当效劳访问量超过预设的流量值时，总线系统快速挡回对该效劳的访问请求，根据效劳系统的效劳响应时间和返回状态，判断效劳状态是否异常，当效劳系统发生异常到达设定的条件时，自动降低对该效劳系统的访问流量限制，防止效劳系统的故障影响范围扩大。
通过交易阀值的统计来完成实时的后台系统效劳质量统计。
从而到达对前端系统访问的指示。
在后台效劳质量不好的情况下，把针对此后台的数据在接入层直接挡回，防止交易在ESB中占用过多处理资源。
由于系统超时时间一般设置的比拟长，防止公用通路被单一后台效劳通道堵塞，需要知道后台系统的运行状况，当出现问题后，及时隔离，不影响主通路运行。
2.6.2故障隔离
效劳系统发生异常到达设定的条件时，自动降低对该效劳系统的访问流量限制，防止效劳系统的故障影响范围扩大。
保存少量的探测效劳对故障系统进行探测，效劳系统故障排除恢复正常后，总线系统可自动恢复其正常的流量。
2.6.3统一流水号
实现ESB平台内统一标准平台流水号的分配功能，唯一标识请求系统的发往ESB平台单次效劳调用。
2.6.4日志记录
应用日志作为效劳系统的又一I/O点，也可以采用异步模式。
将一个效劳线程在完成一次报文处理过程中的所有日志集中一次性异步输入到指定文件是必要的
升级会员 