电子采购平台技术服务解决方案

1、电子采购平台技术服务解决方案电子采购平台技术服务解决方案电子采购平台技术服务解决方案（此文档为 word格式,下载后您可任意修改编辑！）目录 TOC o 1-5 h z HYPERLINK l bookmark53 o Current Document 需求综述4 HYPERLINK l bookmark56 o Current Document 1.1主数据平台接口 4 HYPERLINK l bookmark59 o Current Document 1.2业务数据接口 4 HYPERLINK l bookmark65 o Current Document OA系统接口： 5 HYPERL

2、INK l bookmark69 o Current Document 国家法定信息发布媒体： 52系统解决方案62.1系统技术架构6 HYPERLINK l bookmark77 o Current Document 运行平台6 HYPERLINK l bookmark85 o Current Document 开发平台7 HYPERLINK l bookmark89 o Current Document 监控平台7 HYPERLINK l bookmark93 o Current Document 公共服务8 HYPERLINK l bookmark97 o Current Documen

3、t 适配器82.2部署方案9管理监控部分部署方案 9 HYPERLINK l bookmark116 o Current Document 硬件选型建议 10逻辑分区部署方案 11 HYPERLINK l bookmark128 o Current Document 硬件配置建议 12 HYPERLINK l bookmark132 o Current Document 服务接口规范 13 HYPERLINK l bookmark136 o Current Document 高性能、高可用性及扩展能力设计 13 HYPERLINK l bookmark140 o Current Documen

4、t 完善的安全机制14 HYPERLINK l bookmark151 o Current Document 2.3整体解决方案16 HYPERLINK l bookmark158 o Current Document 接入控制17 HYPERLINK l bookmark175 o Current Document 通信接入模块 19 HYPERLINK l bookmark183 o Current Document 请求系统适配19 HYPERLINK l bookmark192 o Current Document 2.4集成服务功能20服务治理20 HYPERLINK l bookm

5、ark195 o Current Document 提供对出错服务的及时检测和隔离功能 21 HYPERLINK l bookmark199 o Current Document 协议转换21 HYPERLINK l bookmark203 o Current Document 消息格式转换 22 HYPERLINK l bookmark207 o Current Document 服务路由23 HYPERLINK l bookmark211 o Current Document 监控和运维24 HYPERLINK l bookmark215 o Current Document 服务等级 2

6、4 HYPERLINK l bookmark219 o Current Document 2.5系统非功能需求25 HYPERLINK l bookmark222 o Current Document 可用性25可扩展性25 HYPERLINK l bookmark226 o Current Document 可维护性26 HYPERLINK l bookmark230 o Current Document 安全性26 HYPERLINK l bookmark234 o Current Document 性能需求26 HYPERLINK l bookmark238 o Current Docu

7、ment 2.6公用服务27 HYPERLINK l bookmark241 o Current Document 流量控制27故障隔离27 HYPERLINK l bookmark245 o Current Document 统一流水号28 HYPERLINK l bookmark249 o Current Document 日志记录 28 HYPERLINK l bookmark253 o Current Document 2.7管理监控28 HYPERLINK l bookmark257 o Current Document 系统平台级监控 28 HYPERLINK l bookmark

8、261 o Current Document 应用级监控28 HYPERLINK l bookmark265 o Current Document 统计分析29 HYPERLINK l bookmark269 o Current Document 异常报警29 HYPERLINK l bookmark273 o Current Document 统一的运维管理 29 HYPERLINK l bookmark277 o Current Document 3技术支持与服务方案29 HYPERLINK l bookmark281 o Current Document 3.1技术支持与售后服务体系30

9、 HYPERLINK l bookmark284 o Current Document 3.2服务管理模式303.3服务响应31 HYPERLINK l bookmark291 o Current Document 问题优先级（或问题严重程度）级定义 31 HYPERLINK l bookmark297 o Current Document 服务响应时间33 HYPERLINK l bookmark301 o Current Document 问题解决时间34 HYPERLINK l bookmark305 o Current Document 服务文档35 HYPERLINK l bookm

10、ark313 o Current Document 3.4维护支持服务流程36 HYPERLINK l bookmark316 o Current Document 服务消息创建流程 36 HYPERLINK l bookmark324 o Current Document 问题处理流程36 HYPERLINK l bookmark334 o Current Document 服务确认流程38 HYPERLINK l bookmark343 o Current Document 投诉及问题升级流程 391 需求综述1.1 主数据平台接口系统建立与SAP相同的基础数据管理库，通过数据总线接口同步

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

12、可以不做接口。系统解决方案2.1系统技术架构应用系蜻1倒用蔡境N管理监控胴龛素蛛送配器通流适配器.局步部转换化、代码g服务轻毓适配器逢讯适配薯.同步异步转换格耕化.代码转碰集戒开发关键诵踣|非美罹蹈通蹈|低成本通路|蜕一月希接口瞩皂.筑一官埋.线一志挨.公共雁削沛1高实时性耍求扃一致性要承商舂吐能力悒应时问要求不高_致性要求不高曲留系统集成 套用牌底的应fita方式障低供统一目竭用【I理范、统一宣理、哉一答控，公共服将访问撞入朝，分舞蹈由，同步取荏援 谩讯适配、格式转化、代码转捶 鸣昧貌适配器请求接入应用程原接口靖求系炕I运行平台运行平台内部按照集成应用的特点分为多个集成“通路”，目前考虑分为

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

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

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

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

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

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

19、。4）支持热插拔，硬件资源可以轻松地进行替换，并且将维护时间减少到最小。5）节约空间、便丁集中管理、易丁扩展和提供不问断的服务。2.2.3逻辑分区部署方案适配器J接入集成核心数捐庠管理监控ConftgM anager硬件配置建议其对应分配如下:名称功能分布配置计算单兀数重适配器/公共服务适配器公共服务2cpu（8 核）32GB memory1*2集成核心WebMethodsMessage Broker2cpu（8 核）32GB memory1*2数据库服务器Oracle2cpu（8 核）32GB memory1归档数据库服务器Oracle2cpu（8 核）32GB memory1备份资源池作为

20、公共备份2cpu（8 核）32GB memory1总计7服务接口规范ESB系统负责解决实施服务接口规范与服务系统接口的差异， 可将主要的实施工作控 制在ESB项目范围内，大大降低周边系统的改造工作量，配合一些系统的瘦身计划的 分阶段顺利实施。高性能、高可用性及扩展能力设计高处理能力保证措施控制信息+XML应用报文，中间层次不必解析XML应用报文，使系统不仅具备完善的 管理控制能力，同时还减少了报文解析开销，提高了效率。非阻塞的异步模式、流水线式的作业处理，提高吞吐能力。异步记录流水日志，保证信息的完整记录，同时不影响系统的处理性能。系统处理能力可随硬件资源的扩展线性的增长。系统所有配置规则均加

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

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

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

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

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

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

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

28、的接入通路当某一接入点故障时，通过主动控制渠道接入点，自动切换到可以的接入点，实现 故障的完全隔离。对压力较大的接入点，通过主动控制，把部分数据切换到压力较小的通路，实现实 现负载控制。服务端为渠道维护相应标识信息和其所有当前版本和历史版本信息。通过维护历史版本信息，实现版本回退功能。实现方案：整体架构图请求方J通信接入模块负责和外部系统进行通讯，进行原始报文数据的传输。通信接入层实现以下功能：1 .利用系统层通讯协议和请求系统进行通讯，包括 TCP/IP、HTTP、SNA、FTP、 MQSeries、JMS。外部系统约定的通讯方式的实现，包括如何进行通讯连接，如何进行通讯应答， 如何进行数据

29、传输，如何约定通讯报文的大小，如何确定数据传输是否完毕，如何处 理通讯错误，如何关闭通讯连接，如何处理通讯层数据完整性校验等。识别外部系统类型。4多通讯连接的并发处理。以下的功能不需要由通讯接口层完成：非通讯层面的数据报文的加解密。非通讯层面的数据报文的压缩，解压缩处理。通讯接入层屏蔽了所有的通讯细节，数据交换层只知道从某个外部系统获得了或者发 送了一个数据报文，至丁该数据报文是如何获得或者发送的，和数据交换层本身无关请求系统适配完成从服务端返回数据到标准输出之间的转换或从一个渠道端请求接口数据到MBSD服务标准请求数据之间的转换。具体功能包括：电子采购平台技术服务解决方案2.4.1服务治理电

30、子采购平台技术服务解决方案2.4.1服务治理应用层面的数据报文的加解密。应用层面的数据报文的压缩，解压缩处理。数据报文类型的识别。数据报文的打包拆包，根据报文类型以及相关配置将数据报文拆分成统一的数据接 口或者相反。数据接口之间的转换，根据定义的规则从一个数据接口转换成服务数据接口或者相 反。接入适配层屏蔽了数据的具体物理表示和组织，平台服务调度层只知道收到了一个服 务请求要求处理，至丁该服务请求是从哪个系统发起的，原始的请求数据是什么，和 服务整合层没有关系，只和数据交换层有关。接入适配框架提供可配置的定长、变长报文转换适配器，以及可扩展的接口可以适应 各种不同格式的报文转换。同时接入框架提

31、供了 MBSD元数据管理功能，能够方便的 定义报文的元数据，为报文的转换以及应用的开发提供便利。2.4集成服务功能电子采购平台技术服务解决方案电子采购平台技术服务解决方案提供服务标准定义、服务封装、注册与发布等功能 ，提供位置透明性的服务路由和定 位服务ESB的服务接口规范应该基丁对业务流程的理解， 经过抽象、归纳形成，服务 接口规范独立与现有系统的具体实现，接口规范具有较强的独立性、稳定性。从而真 正消除请求系统与服务系统之间的关联关系,实现服务的位置以及服务的具体实现与 服务的访问过程无关。我们提供MBSD规范落地实施的工具：元数据管理，服务接口定义配置，导入导出工 具（可以通过web页面

32、形式和导出文件形式对外公布），服务规范适配的开发框架。我们提供MBSD规范落地实施的工具：元数据管理，服务接口定义配置，导入导出工 具（可以通过web页面形式和导出文件形式对外公布），服务规范适配的开发框架。提供对出错服务的及时检测和隔离功能ESB系统实时检测服务系统的服务状态，当服务出现异常时，能够及时发现，通过监 控平台发出报警，通过人工手段或预先设定的规则，对状态异常的服务或服务系统进 行迅速隔离，避免因故障导致服务阻塞，保证请求系统对其他服务的正常访问。协议转换支持外部系统通过 TCP/IP、HTTP、SNA、FTP、MQSeries、JMS等协议和中间件 与ESB平台通讯。一般情况下

33、，请求系统使用 ESB系统提供的API，按照ESB系统的技术标准和服务 规范进行服务访问，从而避免不必要的协议转换开销但是对丁请求系统无法改造或改造成本过高的情况下，ESB系统应提供接入协议适配的功能，支持外部系统通过不同的通讯协议与 ESB平台通讯。但是应注意，ESB更多的情况下是为了适应服务系统的技术差异，才进行通讯的适配，从系统的规范化和易维护性角度考虑，不推荐被动的对请求系统进行通讯协议适配。接入框架提供了对各种通讯协议的转换适配器，可以满足上述协议转换要求。MQ自身作为消息中问件为JMS通讯协议提供底层的通讯服务。但 ESB作为企业服务总线 需要有大吞吐量，而同步服务并发有限，容易造

34、成资源的阻塞，以异步的方式进行访 问，而MQ作为消息中问件，是最好的异步通讯方式。消息格式转换支持通过元数据管理消息格式定义；支持任意类型报文之间的转换。消息格式转换是集成类系统应具备的基本功能，ESB系统对丁消息格式的转换是基丁 配置实现的，因此消息报文的的数据域需要在配置中进行定义。ESB的服务接口规范标准中包括规范中使用的数据域。在ESB系统内部数据域分为不同的类型、长度、精度等表示形式，ESB系统引用预先定义的、规范化的元数据对 服务接口规范进行描述，使用元数据可以是规范定义工作更加规范化、减少冗余、便 丁管理和统一维护。元数据可根据应用范围划分成不同的“域”，可以更加方便的进行方便维

35、护和管理。ESB系统一般通过配置方式实现标准与非标准的报文转换，包括：格式转换和数据映射，对丁复杂的映射规则可以通过增加映射功能函数(服务组件)的形式实现MBSD接入框架提供了可配置的定长、变长报文转换组件，以及可扩展的接口可以适应各种不同格式的报文转换。同时接入框架提供了 MBSD元数据管理功能，能够方便 的定义报文的元数据，为报文的转换以及应用的开发提供了便利。目前已经支持XML, 定长等多种报文格式。服务路由基丁服务ID、内容、结果等方式路由；交易流程能使用智能路由组合多个子交易。我们采用两个层次的路由：前端API进行的服务通路路由。 前端API根据ESB平台提供的接入参数信息决 定采用

36、哪条通路(MB/WEBMETHODS )进行服务访问。核心的交易路由。由MB/WEBMTHODS核心进行路由，根据交易码决定哪个后台服务系统进行服务访问。路由方式：服务ID路由。也就是交易码进行路由判断。数据依赖路由。动态的根据报文中的数据和配置业务规则进行路由选择电子采购平台技术服务解决方案2.5.2可扩展性电子采购平台技术服务解决方案复杂流程路由。在复杂组合交易中根据每一步的响应结果和配置的复杂交易流程来 进行路由选择。此路由在 ESB平台的流程配置来实现。监控和运维提供服务调用的记录、测量和监控数据；提供事件检测、触发和发布功能；支持产品 版本升级后对现有组件的兼容性。ESB系统应记录每

37、一次服务访问的流水信息，用丁统计和分析。记录过程应该是高效的，应避免流水的记录影响服务的执行效率。流水记录一般只记录服务过程的摘要信 息。需要时，可以通过开关控制打开或关闭详细的报文信息。系统还应及时捕获服务处理过程中的各种异常信息，通过统一的控制台发出报警，警 示信息应划分异常的类别和级别，对丁重要的异常还可以通过短信等手段及时通知运 维人员及时处理。监控管理的接口定义应是可扩展的，例如异常种类、异常级别、流水信息数据项等， 做到信息的获取与后续的处理动作无关，从而保证接口的兼容性、稳定性。服务等级可定义不同的服务等级并实现具体内容。可以从多种维度来定义服务的届性，包括服务的级别。服务的级别

38、可以关联到不同的处理动作服务级别与处理的关联关系可以通过规则进行定义，实现功能的灵活定义与扩展。关 联的动作可以是：处理的优先级，异常提醒方式等。2.5系统非功能需求可用性系统能提供功能方面的各种需求的实现，在运行环境下提供7*24小时NONE-STOP服务；ESB是服务访问的枢纽，不允许由丁系统的故障和恢复过程中断系统服务，ESB 应采用群集模式保证系统的高可用性，群集模式还可以使系统资源得到充分利用。对丁数据库服务器、通讯接入服务起等模块的高可用性需求，为降低实现方案的复杂 度和实施成本，可采用设备之间相互热备的方式。例如数据库服务器可以和归档数据 库服务器采用热备的方式保证高可用性。系统

39、自身的批量处理，如：数据归档活理，日志归档等工作，不能影响系统的正常运行，保证系统7*24小时连续运行。需要定期进行的系统资源累积效应消除动作，如：定期重启Java虚拟机消除长期运行后的堆栈碎片，应保证在其他群集模块正常运行的情况依次进行，保证系统服务不 间断。系统的配置更新应采用动态刷新的机制联机进行，避免配置更新对系统的处理 能力造成影响。系统可以在CPU、内存等资源增加及扩容的情况下自我线性扩展处理能力；系统的架构设计要保证系统的各个层次均可按照负载情况，单独进行横向的扩展，以提高处理 能力。应保证处理能力随硬件资源的扩展呈线性增长。可维护性统具有较为完善的用户管理界面，提供对系统所有功

40、能的维护与参数配置管理的功能；系统涉及到多种平台产品和技术、采用多物理分区的部署方式，单独对每个分区进行 监控和维护是不现实的，必须提供统一的管理监控界面，实现系统的集中统一管理、 监控和维护。安全性提供认证和授权、不可否认和机密性、安全标准的支持等。ESB系统作为服务访问的中间层，除了发布标准的安全规范以外，还要满足各类集成 应用的安全需求，要实现与存量服务系统的安全协议支配，因此ESB需要支持通讯层面，应用层面的安全技术标准。例如：对标准安全协议的支持，通讯过程加解密，MAC 校验，PKI ,特定场景的数字签名等。性能需求统能通过招标人的压力测试电子采购平台技术服务解决方案2.6.2故障隔

41、离电子采购平台技术服务解决方案2.6.2故障隔离性能指标：日均1000万笔数据,ESB对丁关键数据的处理时间1秒，对丁非关键数 据ESB的处理时间2秒。达到系统性能指标峰值要求时，系统处理能力应留有足够的余量， CPU,内存等系统 资源的使用率应低丁 80%，达到平均值要求时，系统资源使用率应低丁 50%。保证系 统在设计指标压力情况下的长期稳定运行。2.6公用服务流量控制当服务访问量超过预设的流量值时，总线系统快速挡回对该服务的访问请求，根据服务系统的服务响应时间和返回状态，判断服务状态是否异常，当服务系统发生异常达 到设定的条件时，自动降低对该服务系统的访问流量限制，避免服务系统的故障影响

42、 范围扩大。通过交易阀值的统计来完成实时的后台系统服务质量统计。从而达到对前端系统访问 的指示。在后台服务质量不好的情况下，把针对此后台的数据在接入层直接挡回，避 免交易在ESB中占用过多处理资源。由丁系统超时时间一般设置的比较长，防止公用通路被单一后台服务通道堵塞，需要 知道后台系统的运行状况，当出现问题后，及时隔离，不影响主通路运行。电子采购平台技术服务解决方案电子采购平台技术服务解决方案服务系统发生异常达到设定的条件时，自动降低对该服务系统的访问流量限制，避免服务系统的故障影响范围扩大。保留少量的探测服务对故障系统进行探测，服务系统故障排除恢复正常后，总线系统可自动恢复其正常的流量。统一

43、流水号实现ESB平台内统一标准平台流水号的分配功能，唯一标识请求系统的发往ESB平台单次服务调用。日志记录应用日志作为服务系统的乂一 I/O点，也可以采用异步模式。将一个服务线程在完成一次报文处理过程中的所有日志集中一次性异步输入到指定文件是必要的。一方面减少业务处理线程的I/O操作，另一方面讲一次业务处理的日志集中输出相比传统的多线程分离输出方便问题查找，大大增加了日志的可读性。管理监控由丁实际部署的系统随着需求的增加，部署会经常发生变化，对丁随着出现的多监控源，我们需要建立统一集中的管理和操作平台。需要做到以下几方面：系统平台级监控包括cpu,内存，文件系统，各队列深度，应用日志，应用 c

44、ore文件等。应用级监控包括各部署模块的内部运行状态。统计分析既定的汇报机制、汇报内容和汇报格式。有些汇报的内容是通过手工统计汇总的，能尽量将这些汇报物交由报表系统自动生成。ESB作为全行的运行基础平台，需要能向IT部分提供全面的IT资源运行情况，为全行的IT资源分配提供依据。异常报警对平台运行的问题进行报警，需要有统一的报警规范来支持未来报警类型的扩展，需要提供多种报警模式，例如声音，短信，微信等。统一的运维管理提供应用日志，流水日志的统一处理，防止多点，多平台部署情况下维护混乱的情况。技术支持与服务方案公司在大力开拓市场的同时，高度重视售后服务及技术支持工作， 始终恪守“客户满意第一”的原

45、则，以全力满足用户的一切需要为己任，向用户提供“及时、专业、真诚”的技术服务。公司不仅为用户提供一流的产品，而且为用户提供一流的服务，在第 一时间对用户的服务要求做出响应公司将尽心尽力与用户紧密合作，为用户单位提供及时、全面的技术支持和服务, 保障系统的正常运行。3.1技术支持与售后服务体系为满足客户系统7X24小时不问断、高可靠地运行，公司按照国际质量标准，形成了一套完备严谨的质量管理体系，实现了从产品、服务到公司运营全过程、全方位 的质量管理1998通过 IS09001SU证2000通过系统集成一缀资扇认证2002通过CMM5畿认证MCT获美国FDA认证2007通过IS027001信悬安全

46、认证20B通过特一毂系统集成竺届认证1999CE认证2001通过级认证2004缀认i正磁共振貌CE及FDA认证2010通过PCMM5认证3.2服务管理模式公司将按如下模式进行技术支持与服务管理：1）公司服务代表是对客户服务需求的接口，并定位服务内容，指定服务技术人员咨询顾问。2）公司服务团队负责提供维护支持服务。3）公司全体技术人员，咨询顾问都可以作为后台资源，为服务技术人员，咨询顾问 提供支持，满足客户的服务需求。在必要时还可以要求合作伙伴提供技术支持， 为客户提供满意的服务。4）客户的服务需求将按级别优先级响应，并提供相应的服务。如话回Ur也果JT存世饷副系统的.护记录捉生服务琳认质服务响

47、应问题优先级（或问题严重程度）级定义优先级定义：优先级判定标准1系统崩溃，无法启动或拒绝连接等原因导致客户无法获得任何系 统服务，并对客户业务的正常运行造成重大影响。2系统主要功能不能正常工作，并对客户业务的正常运行造成较大影响；生产系统不稳定，并有周期性的中断。3系统有故障，但仍可全面运行，对客户业务系统的正常运行有一定的或轻微的影响4优先级1、2和3之外的问题和需求，例如产品性能增强请求； 产品功能、安装或配置方面需要信息或支持，对客户的业务运作 几乎无影响；非生产系统故障。严重程度定义：严重程度1:问题导致客户的业务系统完全丧失服务功能，对业务至关重要的工 作无法继续进行，情况紧急。具有

48、如下特点：数据丢失、关键功能丧失、系统不正常刮起、系统崩溃，并在启动后重复崩溃。严重程度2:问题导致客户的业务系统丧失部分重要的服务功能，没有可以接受 的替代解决方案，但业务系统可以有限的继续运行。严重程度3:问题导致客户的业务系统丧失较少的服务功能。对业务系统影响较 小，需要提供解决方案以恢复功能。严重程度4:问题导致客户的业务系统没有丧失服务功能。一般是较小的错误信 息、不正确的结果或文档错误，对业务系统运行没有影响服务响应时间在接到客户方通过电话、信函、传真、电子邮件等方式提出的服务请求后，我方将在规定的响应时间内尽快做出响应，并根据问题的优先级采取相应的措施。服务响应时间：优先级响应时

49、间1 1小时2 1工作日3 2工作日4 5工作日对优先级为1的问题：公司将不分昼夜和节假日，立即安排相关人员与客户沟通, 查找、分析问题原因，提供解决方案及处理意见，并采用远程和现场服务的方式，务 求在最短的时间内解决客户的问题。对优先级为2的问题：公司将不分节假日，在接到客户服务请求的当天内，安排 相关人员与客户沟通，查找、分析问题原因，提供解决方案及处理意见。在远程登录 无法解决问题时，最迟在48小时之内安排相关人员到达现场提供服务。对优先级为3的问题：公司将在法定工作时间内安排相关人员与客户联系，尽可 能通过远程服务方式为客户处理问题。对优先级为4的问题：公司将在法定工作时间内安排相关人员与客户联系，客户 应与公司协商,确定采用远程或现场服务方式及提供服务的时间注： 工作时间：周一至周五 9: 00 18 : 00问题解决时间此项仅作为内部考核参考用，不作为对客户的承诺。服务技术人员，咨询顾问在接到服务请求后，应该在规定的时间内给出解决方案， 并根据问题的优先级采取相应的措施。解决时间:优先级解决时间1 0.5工作日2 1工作日3 2工作日4 5工作日对优先级为1的问题：维护