企业服务总线ESB方案书(DOC39页)

1、企业服务总线ESB 方案书 TOC o 1-5 h z 需求综述 4主数据平台接口 4业务数据接口 4 HYPERLINK l bookmark2 o Current Document OA系统接口： 5 HYPERLINK l bookmark4 o Current Document 国家法定信息发布媒体： 5系统解决方案 5系统技术架构 5运行平台 6开发平台 6监控平台 7公共服务 7适配器 7 HYPERLINK l bookmark9 o Current Document 部署方案 9 HYPERLINK l bookmark11 o Current Document 管理监控部分部

2、署方案 9硬件选型建议 10逻辑分区部署方案 11 HYPERLINK l bookmark13 o Current Document 硬件配置建议 11 HYPERLINK l bookmark15 o Current Document 服务接口规范 12 HYPERLINK l bookmark17 o Current Document 高性能、高可用性及扩展能力设计 12 HYPERLINK l bookmark19 o Current Document 完善的安全机制 13整体解决方案 15接入控制 16 HYPERLINK l bookmark21 o Current Documen

3、t 通信接入模块 18 HYPERLINK l bookmark23 o Current Document 请求系统适配 18 HYPERLINK l bookmark25 o Current Document 集成服务功能 20服务治理 20 HYPERLINK l bookmark27 o Current Document 提供对出错服务的及时检测和隔离功能 20协议转换 20 HYPERLINK l bookmark31 o Current Document 消息格式转换 21服务路由 22监控和运维 23服务等级 23 HYPERLINK l bookmark37 o Current

4、Document 系统非功能需求24可用性 24可扩展性 25可维护性 25安全性 25性能需求 26 HYPERLINK l bookmark39 o Current Document 公用服务 26流量控制 26故障隔离 27统一流水号 27日志记录 27 HYPERLINK l bookmark41 o Current Document 管理监控 27系统平台级监控 28应用级监控 28统计分析 28异常报警 28 HYPERLINK l bookmark43 o Current Document 统一的运维管理 28 HYPERLINK l bookmark45 o Current D

5、ocument 技术支持与服务方案 29 HYPERLINK l bookmark47 o Current Document 技术支持与售后服务体系 29 HYPERLINK l bookmark49 o Current Document 服务管理模式29 HYPERLINK l bookmark51 o Current Document 服务响应 30 HYPERLINK l bookmark53 o Current Document 问题优先级（或问题严重程度）级定义 30 HYPERLINK l bookmark57 o Current Document 服务响应时间 32 HYPERL

6、INK l bookmark59 o Current Document 问题解决时间 33服务文档 34 HYPERLINK l bookmark61 o Current Document 维护支持服务流程35 HYPERLINK l bookmark63 o Current Document 服务消息创建流程 35 HYPERLINK l bookmark65 o Current Document 问题处理流程 35服务确认流程 37 HYPERLINK l bookmark67 o Current Document 投诉及问题升级流程 38需求综述主数据平台接口系统建立与SAP 相同的基础

7、数据管理库，通过数据总线接口同步能源集团 MDM 中传输过来的编码或数据，以满足电子采购平台基础数据管理的需求。基础数据信息包括：物料编码、计量单位、供应商、客户等。业务数据接口系统业务数据通过数据总线接口同SAP、 OA 、 EC 等系统进行数据交互。系统必须确保通过数据总线接口访问SAP、OA、EC等系统数据与电子采购平台数据传输及时准确、数据完整统一；SAP数 据 中 心电商平台OA系统接口:支持将电子采购平台中的待办事项发送到 OA办公系统进行审批，并读取审批流国家法定信息发布媒体：按照国家相关要求，选择相关媒体建立统一接口，支持招标公告、变更公告、结果公示等的自动发布。如国家无强行规

8、定，可以不做接口。系统解决方案系统技术架构送配器建变螭罡疗受援考怎招宇坤翎济行愿召冬詈悠君三；4?能务学建伊上=曾脸系航信配器咨式槽化.代西转接取完系蛇道配器通正畸禽.后声导悔就*喟擒5t.代日触I便走本曲?ft 求一幅各辖门懈市统一苣国 废一器将、父井好访问而并廿怪赛求同一注江量字高吞叶能力怕近代同s求国商我住要看小港批龊方式修长砺F逑室事绕集成 复用傍似硝应性/一股者isnm.统一苴理.俊一:r脖一夬个阳务访向：请求系蜕诸求接入应用程面RU诘聿某旅运行平台运行平台内部按照集成应用的特点分为多个集成“通路”，目前考虑分为四类通路:1、关键服务通路关键业务、实时性要求高。2、非关键通路非关键业

9、务，查询等。3、服务代理通路从目标架构过渡过程中，与集成目标无关的可以采取“穿透”的方式，减少实施工作量和实施成本。另外，复用价值较低的服务请求也适合采用“代理模式”。4、低成本通路对于实时性要求不高，且信息量大的服务，可采取批量处理模式，降低集成实施成本。实际部署环境中，每一类通路都可以有多个物理部署，用来保证系统的可靠性，同时也支持横向的扩展和减少不同系统之间的相互影响。开发平台基于ESB系统标准的服务接口定义、内部统一的元数据管理、数据结构和服务接口定义、路由规则等，实现多个技术通路的统一配置开发。开发平台的是对各个技术通路实际实现方法的抽象封装。提供服务逻辑的开发框架和组件库，用于转换

10、适配逻辑、公共服务逻辑等的标准化开发、组件重用和统一管理。监控平台ESB应用系统要建立统一的日志规范、流水记录规范、错误码规范、系统运行状态检测规范、系统运行状态控制标准，实现对 ESB系统整体统一的监视和控制。是ESB系统的集成“控制面板”主要功能包括：异常监视、通知提醒、运行控制、实时查询、统计分析、服务的配置 和发布、服务管理、统一维护和版本部署等。由于ESB系统是整个企业的服务访问枢纽，ESB可以集中监控企业内所有的服务访问， 能够提供各个系统的服务质量和状态的统计数据，例如：成功率、服务响应时间、服 务访问量、服务状态异常等。提供统一的流量控制服务、日志记录、接入参数控制等公共服务。

11、从而实现多技术平 台、多物理部署运行环境的公共服务支持。适配器适配器是ESB系统解决与外部系统之间各类差异的总称。ESB将外部系统分为请求系统和服务系统两类。服务系统适配器对于服务系统，尤其是遗留服务系统，基本集成策略是由ESB项目组开发适配器进行 集成。但是服务系统适配器，并不能解决所有的服务适配问题，例如：ESB服务接口规范与服务系统规范的复杂对应和匹配工作，尤其是涉及到多个服务系统接口的复杂 流程调用部分，如果由ESB组合这类服务流程组合，解决相关的交易完整性、一致性 问题，代价太大而且无法保证。因此，实际集成实施过程中，不可避免的要涉及到对服务系统的改造工作请求系统适配器对于请求系统,

12、ESB的基本原则是要求请求系统符合 ESB的技术规范和服务接口规范。目的是减少不必要的转换适配层次，提高系统的集成服务效率，降低资源消耗。ESB系统可为请求系统提供API,对请求系统屏蔽通讯适配、报文组包等技术细节。请求系统只需要理解业务层面的接口规范，从而大大简化请求系统的集成工作，同时还可以加强对请求系统的监控管理，同时为接口技术实现的升级改造提供辅助支持。ESB也可以开发适配器，实现请求系统的集成。主要针对那些无法改造或改造成本过局的请求系统。部署方案管理监控部分部署方案ESB系统的部署方案必须符合企业基础架构的要求。百南区出门区或者Web2区的应用通过生产区域的 APP,访问DB2）用

13、户管理要符合集团的规范。用户权限控制统一通过 UMUM决定用户是否有权限操作ESB的管理监控平台UM权限通控制通过以后，由ESB管理监控应用来进行详细的角色权限管理3）考虑到费用问题，可以采用 Apache和Tomcat2.2.2硬件选型建议ESB系统目标架构硬件选型主要考虑从以下因素:8才内部药户1） Webserver和Application Server必须分离，分别部署在Web2区和APP区。1）成本因素ESB 系统基于 Java 技术实现，具有跨平台的技术优势，因此可将成本是考虑硬件选型的首要指标，未来随着ESB应用规模的不断增长，硬件成本在项目投入所占比重将 会增加，因此选择性价比

14、高的硬件平台是提高效费比的有效途径。)硬件扩容周期ESB 作为企业内部信息化最为关键的服务枢纽，必须能够快速响应应用规模的增长，其中包括硬件的采购周期、系统扩容部署速度。)资源调配的简便性、灵活性ESB 系统应能够针对业务量的周期性变化，灵活的增减系统资源配置，资源的调整不应对集成服务持续性造成影响。基于上述考虑， ESB 系统的硬件推荐采用刀片服务器。刀片服务器还具有以下优点：硬件成本相对低廉，配套的系统软件和中间件价格也相对较低。虚拟化的集中资源管理，可有效提高资源的利用率。在集群中插入新的刀片，就可以提高整体性能。支持热插拔，硬件资源可以轻松地进行替换，并且将维护时间减少到最小。节约空间

15、、便于集中管理、易于扩展和提供不间断的服务。2.2.3逻辑分区部署方案2.2.3逻辑分区部署方案2.2.4硬件配置建议其对应分配如下:名称功能分布配置计算单元数量适配器/公共服务适配器公共服务2cpu（8 核）32GB memory1*2集成核心WebMethodsMessage Broker2cpu（8 核）32GB memory1*2数据库服务器Oracle2cpu（8 核）32GB memory1归档数据库服务器Oracle2cpu（8 核）32GB memory1备份资源池作为公共备份2cpu（8 核）32GB memory1总计7.2.5服务接口规范ESB系统负责解决实施服务接口规范

16、与服务系统接口的差异，可将主要的实施工作控 制在ESB项目范围内，大大降低周边系统的改造工作量， 配合一些系统的瘦身计划的 分阶段顺利实施。.2.6高性能、高可用性及扩展能力设计高处理能力保证措施控制信息+XML应用报文，中间层次不必解析 XML应用报文，使系统不仅具备完善 的管理控制能力，同时还减少了报文解析开销，提高了效率。非阻塞的异步模式、流水线式的作业处理，提高吞吐能力。异步记录流水日志，保证信息的完整记录，同时不影响系统的处理性能。系统处理能力可随硬件资源的扩展线性的增长。系统所有配置规则均加载到Cache中，运行过程中不存在对数据库配置信息的读写操 作，保证系统高效运行。持续稳定运

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

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

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

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

21、共享内存的加密密钥和算法ID ，如果共享内存中没有 对称密钥，加/ 解密失败。使用查询得到的对称密钥，对报文进行加/ 解密处理。. 关键字段MAC2.3 整体解决方案ESB 集成技术架构方案划分为四个层面：渠道通迅接入、数据交换层、平台服务调度层、服务适配层。系统的每个层次都可进行横向扩展，实际应用中系统处理能力可以线性增长。对于渠道服务请求的接入，ESB提供标准的通迅协议(支持 TCP/IP、HTTP、SNA、FTP、MQSeries、JMS等协议和中间件)和MBS D标准接口规范，同时还为请求系统提供服务请求的 API ，屏蔽通讯协议和报文格式的技术细节，能够提高请求系统的集成开发效率、减

22、少转换适配环节，同时还大大加强了总线系统对接入的控制和管理，促进了集成应用的快速推广和可靠运行。对于改造成本过高的存量系统，通过集成开发在数据交换层实现分类路由、同步异步转换、消息格式转换、代码转换等功能。平台服务调度支持四种模式：能力的服务；（二）、WEBME通道，用于时效性和一致性要求不高的服务；（三）、服务代理通道，目标架构过渡过程中，与当期集成目标无关，可以采取“穿透”的方式，减少实施工作量和实施成本。另外，复用价值较低的服务请求也适合采用“代理模式”；（四）、低成本通道，对于实时性要求不高，且信息量大的服务，可采取批量处理模 式，降低集成实施成本及节省系统资源。所有适配器需要在对存量

23、系统分析后集成开发，ESB集成方案中集成产品的相互访问统一使用MQ队列方式。接入控制需要完成以下功能：.对渠道提供不同协议的接入功能，包括 MQ , webmethods, http 等协议的接入。.对不同的渠道提供不同的接入点，实现系统负载均衡和最大限度的故障隔离，提供 高容量，高可靠性的服务。.参数服务为渠道提供统一服务接口模式，伺服渠道下载需要的通道接入信息。.渠道通过轮询请求方式主动下载版本变化信息，初始化变化的连接池。.服务端进行主动控制，实时控制渠道的接入通路。.当某一接入点故障时，通过主动控制渠道接入点，自动切换到可以的接入点，实现 故障的完全隔离.对压力较大的接入点，通过主动控

24、制，把部分数据切换到压力较小的通路，实现实 现负载控制。.服务端为渠道维护相应标识信息和其所有当前版本和历史版本信息.通过维护历史版本信息，实现版本回退功能。实现方案：1.整体架构图2.3.2通信接入模块负责和外部系统进行通讯，进行原始报文数据的传输。通信接入层实现以下功能:.利用系统层通讯协议和请求系统进行通讯，包括 TCP/IP、HTTP、SNA、FTP、 MQSeries、JMS。.外部系统约定的通讯方式的实现，包括如何进行通讯连接，如何进行通讯应答， 如何进行数据传输，如何约定通讯报文的大小，如何确定数据传输是否完毕，如何处 理通讯错误，如何关闭通讯连接，如何处理通讯层数据完整性校验等

25、。.识别外部系统类型。4多通讯连接的并发处理。以下的功能不需要由通讯接口层完成：.非通讯层面的数据报文的加解密。.非通讯层面的数据报文的压缩，解压缩处理。通讯接入层屏蔽了所有的通讯细节，数据交换层只知道从某个外部系统获得了或者发 送了一个数据报文，至于该数据报文是如何获得或者发送的， 和数据交换层本身无关.3.3请求系统适配完成从服务端返回数据到标准输出之间的转换或从一个渠道端请求接口数据到MBSD服务标准请求数据之间的转换。具体功能包括：.应用层面的数据报文的加解密.应用层面的数据报文的压缩，解压缩处理。.数据报文类型的识别。.数据报文的打包拆包，根据报文类型以及相关配置将数据报文拆分成统一

26、的数据接口或者相反。.数据接口之间的转换，根据定义的规则从一个数据接口转换成服务数据接口或者相反。接入适配层屏蔽了数据的具体物理表示和组织，平台服务调度层只知道收到了一个服务请求要求处理，至于该服务请求是从哪个系统发起的，原始的请求数据是什么，和服务整合层没有关系，只和数据交换层有关。接入适配框架提供可配置的定长、变长报文转换适配器，以及可扩展的接口可以适应各种不同格式的报文转换。 同时接入框架提供了 MBSD 元数据管理功能， 能够方便的定义报文的元数据，为报文的转换以及应用的开发提供便利。集成服务功能服务治理提供服务标准定义、服务封装、注册与发布等功能 ，提供位置透明性的服务路由和定 位服

27、务ESB的服务接口规范应该基于对业务流程的理解，经过抽象、归纳形成，服务 接口规范独立与现有系统的具体实现，接口规范具有较强的独立性、稳定性。从而真 正消除请求系统与服务系统之间的关联关系，实现服务的位置以及服务的具体实现与 服务的访问过程无关。我们提供MBSD规范落地实施的工具：元数据管理，服务接口定义配置，导入导出工 具（可以通过web页面形式和导出文件形式对外公布），服务规范适配的开发框架。我们提供MBSD规范落地实施的工具：元数据管理，服务接口定义配置，导入导出工 具（可以通过web页面形式和导出文件形式对外公布），服务规范适配的开发框架。提供对出错服务的及时检测和隔离功能ESB系统实

28、时检测服务系统的服务状态，当服务出现异常时，能够及时发现，通过监 控平台发出报警，通过人工手段或预先设定的规则，对状态异常的服务或服务系统进 行迅速隔离，避免因故障导致服务阻塞，保证请求系统对其他服务的正常访问。2.4.3协议转换支持外部系统通过 TCP/IP、HTTP、SNA、FTP、MQSeries、JMS等协议和中间件与ESB平台通讯。一般情况下，请求系统使用ESB系统提供的API,按照ESB系统的技术标准和服务规 范进行服务访问，从而避免不必要的协议转换开销。但是对于请求系统无法改造或改造成本过高的情况下，ESB系统应提供接入协议适配的功能，支持外部系统通过不同的通讯协议与 ESB平台

29、通讯。但是应注意，ESB更多的情况下是为了适应服务系统的技术差异，才进行通讯的适配，从系统的规范化和易维护性角度考虑，不推荐被动的对请求系统进行通讯协议适配。接入框架提供了对各种通讯协议的转换适配器，可以满足上述协议转换要求。MQ自身作为消息中间件为JMS通讯协议提供底层的通讯服务。但 ESB作为企业服务总线 需要有大吞吐量，而同步服务并发有限，容易造成资源的阻塞，以异步的方式进行访 问，而MQ作为消息中间件，是最好的异步通讯方式。消息格式转换支持通过元数据管理消息格式定义；支持任意类型报文之间的转换。消息格式转换是集成类系统应具备的基本功能，ESB系统对于消息格式的转换是基于配置实现的，因此

30、消息报文的的数据域需要在配置中进行定义。ESB的服务接口规范标准中包括规范中使用的数据域。在ESB系统内部数据域分为不同的类型、长度、精度等表示形式，ESB系统引用预先定义的、规范化的元数据对服 务接口规范进行描述，使用元数据可以是规范定义工作更加规范化、减少冗余、便于 管理和统一维护。元数据可根据应用范围划分成不同的“域”，可以更加方便的进行方便维护和管理。ESB系统一般通过配置方式实现标准与非标准的报文转换，包括：格式转换和数据映射，对于复杂的映射规则可以通过增加映射功能函数(服务组件)的形式实现MBSD接入框架提供了可配置的定长、变长报文转换组件，以及可扩展的接口可以适应各种不同格式的报

31、文转换。同时接入框架提供了 MBSD元数据管理功能，能够方便 的定义报文的元数据，为报文的转换以及应用的开发提供了便利。目前已经支持XML , 定长等多种报文格式。服务路由基于服务ID、内容、结果等方式路由；交易流程能使用智能路由组合多个子交易。我们采用两个层次的路由：前端API进行的服务通路路由。前端API根据ESB平台提供的接入参数信息决定 采用哪条通路(MB/WEBMETHODS )进行服务访问。核心的交易路由。由MB/WEBMTHODS 核心进行路由，根据交易码决定哪个后台服务系统进行服务访问路由方式:服务ID路由。也就是交易码进行路由判断数据依赖路由。动态的根据报文中的数据和配置业务

32、规则进行路由选择。复杂流程路由。在复杂组合交易中根据每一步的响应结果和配置的复杂交易流程来 进行路由选择。此路由在 ESB平台的流程配置来实现。监控和运维提供服务调用的记录、测量和监控数据；提供事件检测、触发和发布功能；支持产品 版本升级后对现有组件的兼容性。ESB系统应记录每一次服务访问的流水信息，用于统计和分析。记录过程应该是高效 的，应避免流水的记录影响服务的执行效率。流水记录一般只记录服务过程的摘要信 息。需要时，可以通过开关控制打开或关闭详细的报文信息。系统还应及时捕获服务处理过程中的各种异常信息，通过统一的控制台发出报警，警 示信息应划分异常的类别和级别，对于重要的异常还可以通过短

33、信等手段及时通知运 维人员及时处理。监控管理的接口定义应是可扩展的，例如异常种类、异常级别、流水信息数据项等， 做到信息的获取与后续的处理动作无关，从而保证接口的兼容性、稳定性。服务等级可定义不同的服务等级并实现具体内容0可以从多种维度来定义服务的属性，包括服务的级别。服务的级别可以关联到不同的处理动作。服务级别与处理的关联关系可以通过规则进行定义，实现功能的灵活定义与扩展。关联的动作可以是：处理的优先级，异常提醒方式等。系统非功能需求可用性系统能提供功能方面的各种需求的实现，在运行环境下提供7*24小时NONE-STOP服务；ESB是服务访问的枢纽，不允许由于系统的故障和恢复过程中断系统服务

34、，ESB应采用群集模式保证系统的高可用性，群集模式还可以使系统资源得到充分利用。对于数据库服务器、通讯接入服务起等模块的高可用性需求，为降低实现方案的复杂度和实施成本，可采用设备之间相互热备的方式。例如数据库服务器可以和归档数据 库服务器采用热备的方式保证高可用性。系统自身的批量处理，如：数据归档清理，日志归档等工作，不能影响系统的正常运行，保证系统7*24小时连续运行。需要定期进行的系统资源累积效应消除动作，如：定期重启Java虚拟机消除长期运行后的堆栈碎片，应保证在其他群集模块正常运行的情况依次进行，保证系统服务不间断。系统的配置更新应采用动态刷新的机制联机进行，避免配置更新对系统的处理能

35、力造成影响可扩展性系统可以在CPU、内存等资源增加及扩容的情况下自我线性扩展处理能力；系统的架构设计要保证系统的各个层次均可按照负载情况，单独进行横向的扩展，以提高处理 能力。应保证处理能力随硬件资源的扩展呈线性增长。可维护性统具有较为完善的用户管理界面，提供对系统所有功能的维护与参数配置管理的功能；系统涉及到多种平台产品和技术、采用多物理分区的部署方式，单独对每个分区进行 监控和维护是不现实的，必须提供统一的管理监控界面，实现系统的集中统一管理、 监控和维护。安全性提供认证和授权、不可否认和机密性、安全标准的支持等。ESB系统作为服务访问的中间层，除了发布标准的安全规范以外，还要满足各类集成

36、应用的安全需求，要实现与存量服务系统的安全协议支配，因此ESB需要支持通讯层面，应用层面的安全技术标准。例如：对标准安全协议的支持，通讯过程加解密，MAC 校验，PKI,特定场景的数字签名等。2.5.5性能需求统能通过招标人的压力测试。性能指标：日均1000万笔数据，ESB对于关键数据的处理时间1秒，对于非关键数 据ESB的处理时间2秒。达到系统性能指标峰值要求时，系统处理能力应留有足够的余量， CPU,内存等系统 资源的使用率应低于80%,达到平均值要求时，系统资源使用率应低于 50%。保证 系统在设计指标压力情况下的长期稳定运行。公用服务流量控制当服务访问量超过预设的流量值时，总线系统快速

37、挡回对该服务的访问请求，根据服务系统的服务响应时间和返回状态，判断服务状态是否异常，当服务系统发生异常达 到设定的条件时，自动降低对该服务系统的访问流量限制，避免服务系统的故障影响 范围扩大。通过交易阀值的统计来完成实时的后台系统服务质量统计。从而达到对前端系统访问 的指示。在后台服务质量不好的情况下，把针对此后台的数据在接入层直接挡回，避免交易在ESB中占用过多处理资源由于系统超时时间一般设置的比较长，防止公用通路被单一后台服务通道堵塞，需要知道后台系统的运行状况，当出现问题后，及时隔离，不影响主通路运行。故障隔离服务系统发生异常达到设定的条件时，自动降低对该服务系统的访问流量限制，避免 服

38、务系统的故障影响范围扩大。保留少量的探测服务对故障系统进行探测，服务系统 故障排除恢复正常后，总线系统可自动恢复其正常的流量。统一流水号实现ESB平台内统一标准平台流水号的分配功能，唯一标识请求系统的发往ESB平台单次服务调用。日志记录应用日志作为服务系统的又一 I/O点，也可以采用异步模式。将一个服务线程在完成 一次报文处理过程中的所有日志集中一次性异步输入到指定文件是必要的。一方面减 少业务处理线程的I/O操作，另一方面讲一次业务处理的日志集中输出相比传统的多 线程分离输出方便问题查找，大大增加了日志的可读性。管理监控由于实际部署的系统随着需求的增加，部署会经常发生变化，对于随着出现的多监

39、控源，我们需要建立统一集中的管理和操作平台。需要做到以下几方面：2.7.1系统平台级监控包括cpu ,内存，文件系统，各队列深度，应用日志，应用 core文件等。应用级监控包括各部署模块的内部运行状态。统计分析既定的汇报机制、汇报内容和汇报格式。有些汇报的内容是通过手工统计汇总的，能尽量将这些汇报物交由报表系统自动生成。ESB作为全行的运行基础平台，需要能向IT部分提供全面的IT资源运行情况，为全行的IT资源分配提供依据。异常报警对平台运行的问题进行报警，需要有统一的报警规范来支持未来报警类型的扩展，需要提供多种报警模式，例如声音，短信，微信等。统一的运维管理提供应用日志，流水日志的统一处理，

40、防止多点，多平台部署情况下维护混乱的情况。3技术支持与服务方案公司在大力开拓市场的同时，高度重视售后服务及技术支持工作，始终恪守“客 户满意第一”的原则，以全力满足用户的一切需要为己任，向用户提供“及时、专业、 真诚”的技术服务。公司不仅为用户提供一流的产品，而且为用户提供一流的服务， 在第一时间对用户的服务要求做出响应。公司将尽心尽力与用户紧密合作，为用户单位提供及时、全面的技术支持和服务, 保障系统的正常运行。技术支持与售后服务体系为满足客户系统7X24小时不间断、高可靠地运行，公司按照国际质量标准，形 成了一套完备严谨的质量管理体系，实现了从产品、服务到公司运营全过程、全方位 的质量管理

41、遇追J5Q9001石 量认证19993认证2000通过茶婉蔡成一 纭安比人证2002逋过匚MM 5霰认证爆旋二T获若国二DA认证2007通迎1口打如1倍 星安全M证20C1通过CMMm圾认证20042010通纸证通过PCMM5认证磁共板表CE及口用?证2013通过特一致紧统 捷泰W盾L,证服务管理模式公司将按如下模式进行技术支持与服务管理:1）公司服务代表是对客户服务需求的接口， 并定位服务内容，指定服务技术人员咨询顾问。2）公司服务团队负责提供维护支持服务。3）公司全体技术人员，咨询顾问都可以作为后台资源，为服务技术人员，咨询顾问提供支持，满足客户的服务需求。在必要时还可以要求合作伙伴提供技

42、术支持，为客户提供满意的服务。4）客户的服务需求将按级别优先级响应，并提供相应的服务。MHI1V* （电肃*仲风、晶香评附和传述明横落户鬲求明人副苏成那电. M也位电话n访圮录服务响应问题优先级（或问题严重程度）级定义优先级定义：优先级判定标准1系统崩溃，无法启动或拒绝连接等原因导致客户无法获得任何系统服务，并对客户业务的正常运行造成重大影响。2系统主要功能不能正常工作，并对客户业务的正常运行造成较大影响；生产系统不稳定，并有周期性的中断。3系统有故障，但仍可全面运行，对客户业务系统的正常运行有一定的或轻微的影响4优先级1、2和3之外的问题和需求，例如产品性能增强请求；产品功能、安装或配置方面

43、需要信息或支持， 对客户的业务运作几乎无影响；非生产系统故障。严重程度定义：严重程度1:问题导致客户的业务系统完全丧失服务功能，对业务至关重要的工 作无法继续进行，情况紧急。具有如下特点：数据丢失、关键功能丧失、系统不正常刮起、系统崩溃，并在启动后重复崩溃。严重程度2:问题导致客户的业务系统丧失部分重要的服务功能，没有可以接受 的替代解决方案，但业务系统可以有限的继续运行。严重程度3:问题导致客户的业务系统丧失较少的服务功能。对业务系统影响较 小，需要提供解决方案以恢复功能。严重程度4:问题导致客户的业务系统没有丧失服务功能。一般是较小的错误信 息、不正确的结果或文档错误，对业务系统运行没有影

44、响。服务响应时间在接到客户方通过电话、信函、传真、电子邮件等方式提出的服务请求后，我方 将在规定的响应时间内尽快做出响应，并根据问题的优先级采取相应的措施。服务响应时间:优先级响应时间1 1小时2 1工作日3 2工作日4 5工作日对优先级为1的问题：公司将不分昼夜和节假日，立即安排相关人员与客户沟通, 查找、分析问题原因，提供解决方案及处理意见，并采用远程和现场服务的方式，务 求在最短的时间内解决客户的问题。对优先级为2的问题：公司将不分节假日，在接到客户服务请求的当天内，安排 相关人员与客户沟通，查找、分析问题原因，提供解决方案及处理意见。在远程登录 无法解决问题时，最迟在48小时之内安排相

45、关人员到达现场提供服务。对优先级为3的问题：公司将在法定工作时间内安排相关人员与客户联系，尽可 能通过远程服务方式为客户处理问题。对优先级为4的问题：公司将在法定工作时间内安排相关人员与客户联系，客户 应与公司协商，确定采用远程或现场服务方式及提供服务的时间注： 工作时间：周一至周五 9: 00 18: 00问题解决时间此项仅作为内部考核参考用，不作为对客户的承诺。服务技术人员，咨询顾问在接到服务请求后，应该在规定的时间内给出解决方案， 并根据问题的优先级采取相应的措施。解决时间:优先级解决时间1 0.5工作日2 1工作日3 2工作日4 5工作日对优先级为1的问题：维护技术人员，咨询顾问应该在

46、半个工作日内确认问题原 因，给出解决方案，或者至少给出解决问题的方向（例如：硬件问题：找硬件厂商等）对优先级为2的问题：维护技术人员，咨询顾问应该在一个工作日内确认问题原 因，给出解决方案，或者给出解决问题的方向（例如：数据问题，给出切换方案）， 并和客户确认实施的时间点。对优先级为3的问题：维护技术人员，咨询顾问应该在两个工作日内确认问题原 因，给出解决方案，或者给出解决问题的方向，并确认后续实施的方式（例如：流程 问题，重新设计流程、配置及测试）。对优先级为4的问题：维护技术人员，咨询顾问应该在两个工作日内确认问题原 因，给出解决方案，或者给出解决问题的方向（例如：开发问题，给出开发需求分

47、析， 指导客户自行开发，或者帮助客户开发，确认完成及测试时间点等）。注：工作时间：周一至周五 9: 00 18: 00服务文档服务文档格式详见附件。（1）服务请求单：用于客户提出服务请求。需要简要描述服务需求，由客户联系人传递给公司服务代表。（2）服务确认单：用于技术人员，咨询顾问纪录解决方案，并由客户联系人确认服务效果，最后由公司服务代表存档。（3）需求定义报告：对于比较复杂的应用服务需求，由技术人员，咨询顾问完成需求定义报告，确认服务类型（应用配置、开发等），给出针对性分析，提交用户决策。（4）服务评估表：由客户对现场服务人员进行评估，交公司服务代表存档。维护支持服务流程服务消息创建流程流

48、程描述1）客户最终用户发现问题，提交关键用户确认。2）关键用户判断是否需要提交服务申请，如果不需要，流程结束。3）确认需要提交服务申请，通过Email或者传真发送给公司help desk manager ,由公司 help desk manager 仓建相关记录。4）公司help desk manager开始支持服务。问题处理流程流程描述Help desk manager 收到服务申请（包括电话中请，Email申请），进行初步诊断，判定服务申请级别和内容，指派技术人员，咨询顾问进行支持，并通知技 术人员，咨询顾问开始服务Help desk通知客户服务技术人员，咨询顾问姓名，联系方式3）服务技术

49、人员，咨询顾问收集服务需求信息，判断是否需要客户方的配合。4）如果需要客户的配合，服务技术人员，咨询顾问联系客户，取得响应的信息。5）服务技术人员，咨询顾问分析定位问题，提供解决方案。6）如果能解决问题，更新服务消息，并通知help desk manager 。同时通知客户, 确认解决方案实施。7）如果不能解决问题，提请问题升级处理流程。流程图:二 u二二二7.X二不工收钾H等申询电话港知户及凤的南到史浦此流更*弹扪记附-3.4.3服务确认流程流程描述1） Help Desk manager 收到通知，通过电话回访客户，确认问题已经解决。2）如果客户不满意或者问题没有解决，Help Desk

50、manager 通知技术人员，咨询顾问继续服务。3）如果客户确认问题已经解决，Help Desk manager 则检查服务记录是否更新， 解决方案记录是否完整有效。4）如果记录不完整，Help Desk manager 通知技术人员，咨询顾问更新维护记录。5）记录完整有效，Help Desk manager close 该记录，并将服务确认单 Email 发给客户。流程图：得划史新录抑电话回击客户fkist r.1. jk11建也用它审-r.噂痛认更新摩护记录，通111 help 曲&injiiadj?cr?I r- M3.4.4投诉及问题升级流程流程描述1）客户对顾问的服务不满意，可以通过

51、电话、邮件、传真等方式进行投诉。2） Help Desk manager 收到投诉，或者查到超期的服务记录，和服务工程师确认该问题的处理进度。3）根据工程师的反馈判断是否需要更换服务工程师。如果可以顺利继续，则由原工程师继续处理流程。4）如果原来工程师不能继续进行服务，或者有顾问提出升级申请，则调派高级工程师进行支持。5）高级工程师对问题进行诊断，继续服务流程，help desk manager通知客户相关变化 TOC o 1-5 h z 3.4 维护支持服务流程35服务消息创建流程 35问题处理流程 35服务确认流程 37投诉及问题升级流程 38需求综述主数据平台接口系统建立与SAP 相同的

52、基础数据管理库，通过数据总线接口同步能源集团 MDM 中传输过来的编码或数据，以满足电子采购平台基础数据管理的需求。基础数据信息包括：物料编码、计量单位、供应商、客户等。业务数据接口系统业务数据通过数据总线接口同 SAP、 OA 、 EC 等系统进行数据交互。系统必须确保通过数据总线接口访问SAP、OA、EC等系统数据与电子采购平台数据传输及时准确、数据完整统一；电商平台OA系统接口：支持将电子采购平台中的待办事项发送到 OA办公系统进行审批，并读取审批流。国家法定信息发布媒体：按照国家相关要求，选择相关媒体建立统一接口，支持招标公告、变更公告、结果公 示等的自动发布。如国家无强行规定，可以不

53、做接口。系统解决方案系统技术架构运行平台运行平台内部按照集成应用的特点分为多个集成“通路”，目前考虑分为四类通路:1、关键服务通路关键业务、实时性要求高2、非关键通路非关键业务，查询等。应用半抗u非吴保掘书涌路减一1R各搭门配或控一管IF废一器将、父井好访问五列管理IIL3方五降-三NT奉粥行与外行母依奉时罟清菱典A逋MS请求我入应用程面RU请求系蜕诘聿空好而白时接赛求 鬲一置上五竽 施吞叶西力法霍累阻集成 复用护信低的康庄粕或忖冏要求K商 旦性笠手/鼻接AJES分类路由，同步异步襁 面用直配，情式F型匕，代码转战取完系筑达配器 通市畸禽.W姓异带福撵 南擒5t.代丹触脸系就舟翼器I1FJ5S

54、S .司h学位抵 咨式椿化、代麻接3、服务代理通路从目标架构过渡过程中，与集成目标无关的可以采取“穿透”的方式，减少实施工作量和实施成本。另外，复用价值较低的服务请求也适合采用“代理模式”。4、低成本通路对于实时性要求不高，且信息量大的服务，可采取批量处理模式，降低集成实施成本。实际部署环境中，每一类通路都可以有多个物理部署，用来保证系统的可靠性，同时也支持横向的扩展和减少不同系统之间的相互影响。开发平台基于ESB系统标准的服务接口定义、内部统一的元数据管理、数据结构和服务接口定义、路由规则等，实现多个技术通路的统一配置开发。开发平台的是对各个技术通路实际实现方法的抽象封装。提供服务逻辑的开发

55、框架和组件库，用于转换适配逻辑、公共服务逻辑等的标准化开发、组件重用和统一管理。监控平台ESB应用系统要建立统一的日志规范、流水记录规范、错误码规范、系统运行状态检测规范、系统运行状态控制标准，实现对 ESB系统整体统一的监视和控制。是ESB系统的集成“控制面板”主要功能包括：异常监视、通知提醒、运行控制、实时查询、统计分析、服务的配置 和发布、服务管理、统一维护和版本部署等。由于ESB系统是整个企业的服务访问枢纽，ESB可以集中监控企业内所有的服务访问， 能够提供各个系统的服务质量和状态的统计数据，例如：成功率、服务响应时间、服 务访问量、服务状态异常等。公共服务提供统一的流量控制服务、日志

56、记录、接入参数控制等公共服务。从而实现多技术平 台、多物理部署运行环境的公共服务支持。适配器适配器是ESB系统解决与外部系统之间各类差异的总称。ESB将外部系统分为请求系统和服务系统两类。服务系统适配器对于服务系统，尤其是遗留服务系统，基本集成策略是由ESB项目组开发适配器进行 集成。但是服务系统适配器，并不能解决所有的服务适配问题，例如： ESB服务接口 规范与服务系统规范的复杂对应和匹配工作，尤其是涉及到多个服务系统接口的复杂 流程调用部分，如果由ESB组合这类服务流程组合，解决相关的交易完整性、一致性 问题，代价太大而且无法保证。因此，实际集成实施过程中，不可避免的要涉及到对服务系统的改

57、造工作请求系统适配器对于请求系统,ESB的基本原则是要求请求系统符合 ESB的技术规范和服务接口规范。目的是减少不必要的转换适配层次，提高系统的集成服务效率，降低资源消耗。ESB系统可为请求系统提供API,对请求系统屏蔽通讯适配、报文组包等技术细节。请求系统只需要理解业务层面的接口规范，从而大大简化请求系统的集成工作，同时还可以加强对请求系统的监控管理，同时为接口技术实现的升级改造提供辅助支持。ESB也可以开发适配器，实现请求系统的集成。主要针对那些无法改造或改造成本过局的请求系统。部署方案管理监控部分部署方案ESB系统的部署方案必须符合企业基础架构的要求。WASen-er讨的区区a内都用户或

58、者Web2区的应用通过生产区域的 APP,访问DB2）用户管理要符合集团的规范。用户权限控制统一通过 UMUM决定用户是否有权限操作ESB的管理监控平台UM权限通控制通过以后，由ESB管理监控应用来进行详细的角色权限管理硬件选型建议ESB系统目标架构硬件选型主要考虑从以下因素:1） Webserver和Application Server必须分离，分别部署在Web2区和APP区。3）考虑到费用问题，可以采用Apache 和 Tomcat 。琏1）成本因素ESB 系统基于 Java 技术实现，具有跨平台的技术优势，因此可将成本是考虑硬件选型的首要指标，未来随着ESB应用规模的不断增长，硬件成本在

59、项目投入所占比重将 会增加，因此选择性价比高的硬件平台是提高效费比的有效途径。)硬件扩容周期ESB 作为企业内部信息化最为关键的服务枢纽，必须能够快速响应应用规模的增长，其中包括硬件的采购周期、系统扩容部署速度。)资源调配的简便性、灵活性ESB 系统应能够针对业务量的周期性变化，灵活的增减系统资源配置，资源的调整不应对集成服务持续性造成影响。基于上述考虑， ESB 系统的硬件推荐采用刀片服务器。刀片服务器还具有以下优点：硬件成本相对低廉，配套的系统软件和中间件价格也相对较低。虚拟化的集中资源管理，可有效提高资源的利用率。在集群中插入新的刀片，就可以提高整体性能。支持热插拔，硬件资源可以轻松地进

60、行替换，并且将维护时间减少到最小。节约空间、便于集中管理、易于扩展和提供不间断的服务。逻辑分区部署方案硬件配置建议其对应分配如下:名称功能分布配置计算单元数量适配器/公共服务适配器公共服务2cpu（8 核）32GB memory1*2集成核心WebMethodsMessage Broker2cpu（8 核）32GB memory1*2数据库服务器Oracle2cpu（8 核）32GB memory1归档数据库服务器Oracle2cpu（8 核）32GB memory1备份资源池作为公共备份2cpu（8 核）32GB memory1总计7服务接口规范ESB系统负责解决实施服务接口规范与服务系统接