企业服务总线ESB方案书.doc

《企业服务总线ESB方案书.doc》由会员分享，可在线阅读，更多相关《企业服务总线ESB方案书.doc（38页珍藏版）》请在三一办公上搜索。

1、企业服务总线 ESB 方案书第 1 页，共 38 页1 需求综述 . 41.1 主数据平台接口 . 41.2 业务数据接口 . 41.3 OA 系统接口： . 51.4 国家法定信息发布媒体： . 52 系统解决方案 . 52.1 系统技术架构 . 52.1.1 运行平台 .62.1.2 开发平台 .62.1.3 监控平台 .72.1.4 公共服务 .72.1.5 适配器 .72.2 部署方案 . 92.2.1 管理监控部分部署方案 .92.2.2 硬件选型建议 . 102.2.3 逻辑分区部署方案 . 112.2.4 硬件配置建议 . 112.2.5 服务接口规范 . 122.2.6 高性能

2、、高可用性及扩展能力设计 . 122.2.7 完善的安全机制 . 132.3 整体解决方案 . 152.3.1 接入控制 . 162.3.2 通信接入模块 . 172.3.3 请求系统适配 . 182.4 集成服务功能 . 192.4.1 服务治理 . 192.4.2 提供对出错服务的及时检测和隔离功能 . 202.4.3 协议转换 . 202.4.4 消息格式转换 . 212.4.5 服务路由 . 222.4.6 监控和运维 . 222.4.7 服务等级 . 232.5 系统非功能需求 . 242.5.1 可用性 . 242.5.2 可扩展性 . 242.5.3 可维护性 . 25第 2 页

3、，共 38 页1.5 安全性 . 251.6 性能需求 . 252.6 公用服务 . 262.1.6 流量控制 . 262.1.7 故障隔离 . 262.1.8 统一流水号 . 272.1.9 日志记录 . 272.7 管理监控 . 272.2.8 系统平台级监控 . 272.2.9 应用级监控 . 272.2.10 统计分析 . 272.2.11 异常报警 . 282.2.12 统一的运维管理 . 283 技术支持与服务方案 . 282.3.4 技术支持与售后服务体系 . 292.3.5 服务管理模式 . 292.3.6 服务响应 . 302.4.8 问题优先级（或问题严重程度）级定义 .

4、302.4.9 服务响应时间 . 312.4.10 问题解决时间 . 332.4.11 服务文档 . 342.3.7 维护支持服务流程 . 352.5.4 服务消息创建流程 . 352.5.5 问题处理流程 . 352.5.6 服务确认流程 . 362.5.7 投诉及问题升级流程 . 37第 3 页，共 38 页1 需求综述1.7 主数据平台接口系统建立与 SAP 相同的基础数据管理库， 通过数据总线接口同步能源集团 MDM 中传输过来的编码或数据， 以满足电子采购平台基础数据管理的需求。 基础数据信息包括：物料编码、计量单位、供应商、客户等。1.8 业务数据接口系统业务数据通过数据总线接口同

5、 SAP、OA、EC 等系统进行数据交互。系统必须确保通过数据总线接口访问 SAP、OA、EC 等系统数据与电子采购平台数据传输及时准确、数据完整统一；SAP数 OA办公系统据 数MDM总 据线 中 EC系 心统中矿微星系统电商平台第 4 页，共 38 页1.9 OA 系统接口：支持将电子采购平台中的待办事项发送到 OA 办公系统进行审批，并读取审批流。1.10 国家法定信息发布媒体：按照国家相关要求，选择相关媒体建立统一接口，支持招标公告、变更公告、结果公示等的自动发布。如国家无强行规定，可以不做接口。2 系统解决方案2.8 系统技术架构第 5 页，共 38 页1.11 运行平台运行平台内部

6、按照集成应用的特点分为多个集成“通路”，目前考虑分为四类通路：1、关键服务通路关键业务、实时性要求高。2、非关键通路非关键业务，查询等。3、服务代理通路从目标架构过渡过程中，与集成目标无关的可以采取“穿透”的方式，减少实施工作量和实施成本。另外，复用价值较低的服务请求也适合采用“代理模式”。4、低成本通路对于实时性要求不高， 且信息量大的服务， 可采取批量处理模式， 降低集成实施成本。实际部署环境中，每一类通路都可以有多个物理部署，用来保证系统的可靠性，同时也支持横向的扩展和减少不同系统之间的相互影响。1.12 开发平台基于 ESB 系统标准的服务接口定义、 内部统一的元数据管理、 数据结构和

7、服务接口定义、路由规则等，实现多个技术通路的统一配置开发。开发平台的是对各个技术通路实际实现方法的抽象封装。提供服务逻辑的开发框架和组件库，用于转换适配逻辑、公共服务逻辑等的标准化开发、组件重用和统一管理。第 6 页，共 38 页1.13 监控平台ESB 应用系统要建立统一的日志规范、流水记录规范、错误码规范、系统运行状态检测规范、系统运行状态控制标准，实现对 ESB 系统整体统一的监视和控制。是ESB 系统的集成“控制面板”。主要功能包括：异常监视、通知提醒、运行控制、实时查询、统计分析、服务的配置和发布、服务管理、统一维护和版本部署等。由于 ESB 系统是整个企业的服务访问枢纽， ESB

8、可以集中监控企业内所有的服务访问，能够提供各个系统的服务质量和状态的统计数据， 例如：成功率、服务响应时间、服务访问量、服务状态异常等。1.14 公共服务提供统一的流量控制服务、日志记录、接入参数控制等公共服务。从而实现多技术平台、多物理部署运行环境的公共服务支持。1.15 适配器适配器是 ESB 系统解决与外部系统之间各类差异的总称。ESB 将外部系统分为请求系统和服务系统两类。2.9 服务系统适配器第 7 页，共 38 页对于服务系统， 尤其是遗留服务系统， 基本集成策略是由 ESB 项目组开发适配器进行集成。但是服务系统适配器，并不能解决所有的服务适配问题，例如： ESB 服务接口规范与

9、服务系统规范的复杂对应和匹配工作，尤其是涉及到多个服务系统接口的复杂流程调用部分， 如果由 ESB 组合这类服务流程组合， 解决相关的交易完整性、 一致性问题，代价太大而且无法保证。因此，实际集成实施过程中，不可避免的要涉及到对服务系统的改造工作。2.1.5.2 请求系统适配器对于请求系统， ESB 的基本原则是要求请求系统符合 ESB 的技术规范和服务接口规范。目的是减少不必要的转换适配层次，提高系统的集成服务效率，降低资源消耗。ESB 系统可为请求系统提供 API ，对请求系统屏蔽通讯适配、报文组包等技术细节。请求系统只需要理解业务层面的接口规范，从而大大简化请求系统的集成工作，同时还可以

10、加强对请求系统的监控管理，同时为接口技术实现的升级改造提供辅助支持。ESB 也可以开发适配器， 实现请求系统的集成。主要针对那些无法改造或改造成本过高的请求系统。第 8 页，共 38 页1.16 部署方案2.10 管理监控部分部署方案ESB 系统的部署方案必须符合企业基础架构的要求。1）WebServer 和 Application Server 必须分离，分别部署在 Web2 区和 APP 区。或者 Web2 区的应用通过生产区域的 APP，访问 DB。2）用户管理要符合集团的规范。用户权限控制统一通过 UM。UM 决定用户是否有权限操作 ESB 的管理监控平台。UM 权限通控制通过以后，由

11、 ESB 管理监控应用来进行详细的角色权限管理。3）考虑到费用问题，可以采用 Apache 和 Tomcat 。第 9 页，共 38 页1.17 硬件选型建议ESB 系统目标架构硬件选型主要考虑从以下因素：1）成本因素ESB 系统基于 Java 技术实现，具有跨平台的技术优势，因此可将成本是考虑硬件选型的首要指标， 未来随着 ESB 应用规模的不断增长， 硬件成本在项目投入所占比重将会增加，因此选择性价比高的硬件平台是提高效费比的有效途径。2）硬件扩容周期ESB 作为企业内部信息化最为关键的服务枢纽，必须能够快速响应应用规模的增长，其中包括硬件的采购周期、系统扩容部署速度。3）资源调配的简便性

12、、灵活性ESB 系统应能够针对业务量的周期性变化， 灵活的增减系统资源配置，资源的调整不应对集成服务持续性造成影响。基于上述考虑， ESB 系统的硬件推荐采用刀片服务器。刀片服务器还具有以下优点：1) 硬件成本相对低廉，配套的系统软件和中间件价格也相对较低。2) 虚拟化的集中资源管理，可有效提高资源的利用率。3) 在集群中插入新的刀片，就可以提高整体性能。4) 支持热插拔，硬件资源可以轻松地进行替换，并且将维护时间减少到最小。5) 节约空间、便于集中管理、易于扩展和提供不间断的服务。第 10 页，共 38 页1.18 逻辑分区部署方案1.19 硬件配置建议其对应分配如下：名称 功能分布 配置

13、计算单元数量适配器公共服务 2cpu(8 核) 1*2 适配器/公共服务32GB memory集成核心 WebMethods 2cpu(8 核) 1*2Message Broker 32GB memory数据库服务器 Oracle 2cpu(8 核)132GB memory归档数据库服务器 Oracle 2cpu(8 核) 132GB memory备份资源池 作为公共备份 2cpu(8 核)32GB 1memory总计 7第 11 页，共 38 页1.20 服务接口规范ESB 系统负责解决实施服务接口规范与服务系统接口的差异， 可将主要的实施工作控制在 ESB 项目范围内，大大降低周边系统的改

14、造工作量， 配合一些系统的瘦身计划的分阶段顺利实施。1.21 高性能、高可用性及扩展能力设计高处理能力保证措施控制信息+XML 应用报文， 中间层次不必解析 XML 应用报文， 使系统不仅具备完善的管理控制能力，同时还减少了报文解析开销，提高了效率。非阻塞的异步模式、流水线式的作业处理，提高吞吐能力。异步记录流水日志，保证信息的完整记录，同时不影响系统的处理性能。系统处理能力可随硬件资源的扩展线性的增长。系统所有配置规则均加载到 Cache 中，运行过程中不存在对数据库配置信息的读写操作，保证系统高效运行。持续稳定运行保障措施所有应用模块均为群集部署，系统不存在单点故障隐患，某个模块的故障不影

15、响正常运行。系统应用版本的升级可按模块分别进行，不影响业务的正常运行。采用数据库分区技术，实现海量数据记录的清理和分区切换过程 15 秒钟内完成，无需采用与应用相关的数据库分表方式，实现批量数据处理对总线应用透明。第 12 页，共 38 页系统提供完备的动态安全刷新手段，配置信息可运行时在线刷新。可扩展性系统可以在 CPU、内存等资源增加及扩容的情况下自我线性扩展处理能力； 每个逻辑模块可以采用横向扩展的多物理模块部署。中间用队列进行通讯。可维护性系统具有较为完善的用户管理界面，提供对系统所有功能的维护与参数配置管理的功能；系统采用统一的服务模式和开发框架，从开发商增加可维护性，系统部署上采用

16、多逻辑单元分离部署，减少系统内部的耦合度，增加整个系统的可维护性。1.22 完善的安全机制企业应用集成技术使复杂的业务流程、 大量的信息和数据在各 IT 应用系统和业务部门之间高效的流转和共享，实现业务流程标准化和自动化，促进业务流程优化，提高建行运营效率。任何不安全因素都会造成不可估量的损失，故所有数据的传输、处理、交换都必须在良好的安全环境下进行，因此，必须建立一套完整的安全机制，以确保整个通信系统的安全运行。方案主要为 ESB 系统提供如下几个方面的安全服务：2.11 密钥管理提供安全有效的密钥管理方案， 实现应用系统和 ESB 系统的密钥产生、 密钥分发、 密钥更新、密钥注销等。提供密

17、钥的自动更新机制，保证密钥的安全性，提供高效的对称密码算法，确保应用系统具有可用性和易用性。2.12 身份认证第 13 页，共 38 页保证接入 ESB 系统的合法性，提供应用系统和 ESB 系统之间的双向身份认证，采用基于证书的认证模式，系统使用的数字证书由第三方 CA 或者采用自运行维护的 CA提供。CA 证书采用离线下发的方式，以 PKCS#12 文件的格式安装到 ESB 系统和应用接入系统。身份认证完成后，双方得到一个 64 个字节的随机数，通讯双方使用的对称密钥都是基于这一组随机数产生，对称密钥的选取规则双方使用相同的策略。对称密钥和对方的公钥信息存放在系统主机的共享内存，方便应用系

18、统加密使用1.23 通讯加密ESB 系统的安全性是保障 IT 应用系统安全可靠运行的重要环节，使用 PKI 技术实现系统的密钥管理和通讯加密是目前解决此类问题的最有效途径， 应用系统和 ESB 系统之间通讯的报文使用对称算法加密保护其机密性。为了提高密码运算的处理速度，这里推荐使用 AES 算法，密钥的长度为 128bit 。通讯双方在身份认证完成后，在共享内存中保存对称密钥。客户端和服务器端的加密流程如下：客户端加/解密流程：1) 查询共享内存中的对称密钥和算法 ID，根据加密要求选取对称密钥，如果共享内存中没有对称密钥，加 /解密失败。2) 使用查询得到的对称加密密钥，对报文进行加 /解密

19、处理。服务器端加 /解密流程：第 14 页，共 38 页1) 根据客户端的系统代码，查询共享内存的加密密钥和算法 ID，如果共享内存中没有 对称密钥，加 /解密失败。2) 使用查询得到的对称密钥，对报文进行加 /解密处理。1.24 关键字段 MAC2.13 整体解决方案ESB 集成技术架构方案划分为四个层面：渠道通迅接入、数据交换层、平台服务调度层、服务适配层。系统的每个层次都可进行横向扩展，实际应用中系统处理能力可以线性增长。对于渠道服务请求的接入， ESB 提供标准的通迅协议（支持 TCP/IP 、HTTP 、SNA、 FTP、MQSeries 、JMS 等协议和中间件）和标准接口规范，同

20、时还为请求系统提供服务请求的 API，屏蔽通讯协议和报文格式的技术细节，能够提高请求系统的集成开发效率、减少转换适配环节，同时还大大加强了总线系统对接入的控制和管理，促进了集成应用的快速推广和可靠运行。对于改造成本过高的存量系统，通过集成开发在数据交换层实现分类路由、同步异步转换、消息格式转换、代码转换等功能。平台服务调度支持四种模式：（一）、通道，用于高时效性、高一致性、高吞吐 能力的服务；第 15 页，共 38 页（二）、通道，用于时效性和一致性要求不高的服务；（三） 、服务代理通道， 目标架构过渡过程中， 与当期集成目标无关， 可以采取“穿透”的方式，减少实施工作量和实施成本。另外，复用

21、价值较低的服务请求也适合采用“代理模式”；（四）、低成本通道，对于实时性要求不高，且信息量大的服务，可采取批量处理模式，降低集成实施成本及节省系统资源。所有适配器需要在对存量系统分析后集成开发， ESB 集成方案中集成产品的相互访问统一使用队列方式。1.25 接入控制需要完成以下功能：2.14 对渠道提供不同协议的接入功能，包括 MQ，webmethods, http 等协议的接入。2.15 对不同的渠道提供不同的接入点，实现系统负载均衡和最大限度的故障隔离，提供高容量，高可靠性的服务。2.16 参数服务为渠道提供统一服务接口模式，伺服渠道下载需要的通道接入信息。2.17 渠道通过轮询请求方式

22、主动下载版本变化信息，初始化变化的连接池。2.18 服务端进行主动控制，实时控制渠道的接入通路。2.19 当某一接入点故障时，通过主动控制渠道接入点，自动切换到可以的接入点，实现故障的完全隔离。第 16 页，共 38 页1.26 对压力较大的接入点，通过主动控制，把部分数据切换到压力较小的通路，实现实现负载控制。1.27 服务端为渠道维护相应标识信息和其所有当前版本和历史版本信息。1.28 通过维护历史版本信息，实现版本回退功能。实现方案：2.20 整体架构图2.1.10 通信接入模块负责和外部系统进行通讯，进行原始报文数据的传输。通信接入层实现以下功能：第 17 页，共 38 页1利用系统层

23、通讯协议和请求系统进行通讯，包括 TCP/IP 、HTTP 、SNA、FTP、MQSeries 、JMS。2外部系统约定的通讯方式的实现，包括如何进行通讯连接，如何进行通讯应答，如何进行数据传输，如何约定通讯报文的大小，如何确定数据传输是否完毕，如何处理通讯错误，如何关闭通讯连接，如何处理通讯层数据完整性校验等。3识别外部系统类型。4 多通讯连接的并发处理。以下的功能不需要由通讯接口层完成：1.29 非通讯层面的数据报文的加解密。1.30 非通讯层面的数据报文的压缩，解压缩处理。通讯接入层屏蔽了所有的通讯细节，数据交换层只知道从某个外部系统获得了或者发送了一个数据报文，至于该数据报文是如何获得

24、或者发送的， 和数据交换层本身无关。2.21 请求系统适配完成从服务端返回数据到标准输出之间的转换或从一个渠道端请求接口数据到MBSD 服务标准请求数据之间的转换。具体功能包括：2.1.11 应用层面的数据报文的加解密。2.1.12 应用层面的数据报文的压缩，解压缩处理。第 18 页，共 38 页1.31 数据报文类型的识别。1.32 数据报文的打包拆包，根据报文类型以及相关配置将数据报文拆分成统一的数据接口或者相反。1.33 数据接口之间的转换，根据定义的规则从一个数据接口转换成服务数据接口或者相反。接入适配层屏蔽了数据的具体物理表示和组织，平台服务调度层只知道收到了一个服务请求要求处理，至

25、于该服务请求是从哪个系统发起的，原始的请求数据是什么，和服务整合层没有关系，只和数据交换层有关。接入适配框架提供可配置的定长、变长报文转换适配器，以及可扩展的接口可以适应各种不同格式的报文转换。 同时接入框架提供了 MBSD 元数据管理功能， 能够方便的定义报文的元数据，为报文的转换以及应用的开发提供便利。2.22 集成服务功能2.1.13 服务治理提供服务标准定义、服务封装、注册与发布等功能 , 提供位置透明性的服务路由和定位服务 ESB 的服务接口规范应该基于对业务流程的理解， 经过抽象、 归纳形成，服务第 19 页，共 38 页接口规范独立与现有系统的具体实现，接口规范具有较强的独立性、

26、稳定性。从而真正消除请求系统与服务系统之间的关联关系，实现服务的位置以及服务的具体实现与服务的访问过程无关。我们提供 MBSD 规范落地实施的工具： 元数据管理， 服务接口定义配置， 导入导出工具（可以通过 web 页面形式和导出文件形式对外公布），服务规范适配的开发框架。我们提供 MBSD 规范落地实施的工具： 元数据管理， 服务接口定义配置， 导入导出工具（可以通过 web 页面形式和导出文件形式对外公布），服务规范适配的开发框架。1.34 提供对出错服务的及时检测和隔离功能ESB 系统实时检测服务系统的服务状态，当服务出现异常时，能够及时发现，通过监控平台发出报警，通过人工手段或预先设定

27、的规则，对状态异常的服务或服务系统进行迅速隔离，避免因故障导致服务阻塞，保证请求系统对其他服务的正常访问。1.35 协议转换支持外部系统通过 TCP/IP 、HTTP 、SNA 、FTP 、MQSeries 、JMS 等协议和中间件与 ESB 平台通讯。一般情况下，请求系统使用 ESB 系统提供的 API，按照 ESB 系统的技术标准和服务规范进行服务访问，从而避免不必要的协议转换开销。但是对于请求系统无法改造或改造成本过高的情况下， ESB 系统应提供接入协议适配的功能，支持外部系统通过不同的通讯协议与 ESB 平台通讯。第 20 页，共 38 页但是应注意，ESB 更多的情况下是为了适应服务系统的技术差异， 才进行通讯的适配，从系统的规范化和易维护性角度考虑，不推荐被动的对请求系统进行通讯协议适配。接入框架提供了对各种通讯协议的转换适配器，可以满足上述协议转换要求。 MQ 自身作为消息中间件为 JMS 通讯协议提供底层的通讯服务。但 ESB 作为企业服务总线需要有大吞吐量，而同步服务并发有限，容易造