企业服务总线ESB技术设计方案

1、企业服务总线ESB技术设计方案目 录 TOC o 1-4 f u 1项目需求理解 PAGEREF _Toc57135091 h 31.1.项目背景 PAGEREF _Toc57135092 h 31.2.项目目标及项目范围 PAGEREF _Toc57135093 h 42ESB服务总线技术解决方案 PAGEREF _Toc57135094 h 42.1.企业服务总线技术方案 PAGEREF _Toc57135095 h 42.1.1企业服务总线集成架构模型 PAGEREF _Toc57135096 h 42.1.2企业服务总线体系结构 PAGEREF _Toc57135097 h 62.1.

2、3企业服务总线功能性需求解决方案 PAGEREF _Toc57135098 h 8 消息传输 PAGEREF _Toc57135099 h 8 安全管理 PAGEREF _Toc57135100 h 8 消息处理 PAGEREF _Toc57135101 h 9 服务管理 PAGEREF _Toc57135102 h 11 流量控制 PAGEREF _Toc57135103 h 132.1.4企业服务总线非功能性需求解决方案 PAGEREF _Toc57135104 h 15 可用性 PAGEREF _Toc57135105 h 15 及时性 PAGEREF _Toc57135106 h 16

3、 可靠性 PAGEREF _Toc57135107 h 16 故障恢复方案 PAGEREF _Toc57135108 h 18 业务连续性方案 PAGEREF _Toc57135109 h 18 系统备份方案 PAGEREF _Toc57135110 h 18 安全性 PAGEREF _Toc57135111 h 19 系统架构、可扩展性、集成性 PAGEREF _Toc57135112 h 192.1.5企业服务总线部署方案 PAGEREF _Toc57135113 h 20 部署架构原则 PAGEREF _Toc57135114 h 20 部署架构方案 PAGEREF _Toc571351

4、15 h 23项目需求理解项目背景公司是一家集专业产品、研发、生产、销售于一体的高新技术企业，作为首批国家高新技术企业, 公司专业从事宽带接入终端、无线通信设备、光通信设备等产品的研发、生产、销售和服务。公司是全球诸多著名运营商及系统设备提供商的主要合作伙伴。公司产品在全球范围内广泛使用，服务于通信、家庭、金融和教育等领域。成立以来，公司坚持自主研发的道路，坚持以先进的技术创造产品价值的产品研发策略，每年的研发投入占当年销售收入的3.5%以上，持续、不断的研发高投入，为共进公司保持技术优势提供了物质保证。到目前为止，公司已经形成在通讯终端产品方面完整的研发体系和生产线，产品涉及7个大类100多

5、个品种，奠定了共进公司在通讯终端产品领域的行业领导地位。截至目前为止，公司信息系统基本覆盖公司供应链、生产制造、财务管理业务领域；2015年以前财务系统使用金蝶K/3进行管理，未在U9系统中实现财务业务管控。2015年1月份全面上线U9系统应收、应付、成本、固定资产、总账业务模块，初步实现财务业务一体化系统应用；但财务在安财系统中进行预算、费用统计，未与现有系统有效集成；同时实现COMEX、PLM、ERP、MES、IMS等多个主干系统平台的关键应用集成；并引入MES系统实现对产品级在线管理及防呆控制，在线物料使用“盘古IMS”管理贴片物料，其他物料正在客制化开发在线物料管理功能；PLM系统使用

6、的是PDM产品数据管理功能。目前公司业务量以每年增长30%-40%的速度快速发展，业务形式也发展成拥有两个研发基地和几个销售基地的集团型企业，公司主营业务规模的迅猛发展对其自身的信息化建设水平提出了更高的要求，目前的信息化水平已远远不能满足业务规模日益增长的需要。针对公司在信息化系统建设方面存在的不足，本次ERP系统建设的关键点在于以下三方面：横向流程的贯通：在产品研发线、采购业务线、销售业务线、生产业务线、日常运营业务线，需要横向打通部门间协作，提高整体业务运作效率。纵向业务的整合：在财务管理、预算管理、资金管理、主数据管理等方面，需要实现纵向整合，满足多业务线的管控要求。多信息系统集成：需

7、要实现ERP系统、PLM系统、费用控制系统、SRM、MES、IMS、BI等系统集成，重点关注用户操作体验，提升最终用户系统应用满意度。项目目标及项目范围项目总体目标是通过信息化软件平台及管理设计思想为公司的整体战略提供信息化支撑。通过在全公司进行统一的系统建设，形成一体化运作的管理平台，使ERP系统管理方式与实际业务运作流程紧密贴合，提高企业管理工作标准化、规范化、精细化、高效化，确保IT应用系统真正为企业经营决策服务。信息系统建设应该满足以下四个原则：统一性保证总部和下属工厂、部门之间的互联与互通，同时节约总体投资成本；安全性保证系统、数据的安全性，系统应有先进的传输加密措施和机制，并采用分

8、级授权管理模式，同时保证系统持续、稳定的运行；高效性保证系统的性能能够满足各类业务与应用的需要，整个系统的方案设计、功能融合并体现领先的信息技术和先进的管理思想；整个系统应便于管理，提供多层次、多维度的管理手段；扩展性保证系统为满足业务发展的需要所应具备的扩展能力。ESB服务总线技术解决方案企业服务总线技术方案企业服务总线集成架构模型SOA是在面向对象体系结构基础上扩展的新体系结构，以服务为核心来封装业务流程和应用系统，服务具有更高的抽象层次，可以实现更高级别的重用，并解决了IT系统与业务流程的相关性。与传统构建系统的方法比较，SOA更强调标准化应用，更加重视系统的层次架构。SOA特性之一的互

9、联互通性就体现在系统中任一个服务能被其他服务甚至是其他系统的服务准确无误地发现及理解，而满足这种特性最直接的方式就是每个服务都遵循一系列统一标准。因此，只要遵循SOA的理念，采用统一的标准，任何现有技术都能用来开发SOA系统。企业服务总线集成架构与传统架构的区别在于系统均是基于“服务”构造，“服务”之间的交互和组合实现了系统之间的松耦合关系。企业服务总线集成架构遵循SOA理念，企业服务总线集成架构中的构件包括：（1）服务：可以通过已发布接口使用服务，并且允许服务使用者调用服务。（2）服务描述：服务描述指定服务使用者与服务提供者交互的方式。它指定来自服务的请求和响应的格式。服务描述可以指定一组前

10、提条件、后置条件和/或服务质量（Q0S）级别。（3）服务使用者（服务消费者）：服务使用者是一个应用程序、一个软件模块或需要一个服务的另一个服务。它发起对企业服务总线的服务的查询，通过传输绑定服务，并且执行服务功能。服务使用者根据接口契约来执行服务。（4）服务提供者：服务提供者是一个可通过网络寻址的实体，它接受和执行来自使用者的请求。它将自己的服务和接口契约发布到企业服务总线，以便服务使用者可以发现和访问该服务。（5）企业服务总线：企业服务总线充当SOA中服务提供者和服务使用者之间的连接服务的中间层。企业服务总线“虚拟化企业里的服务”， 也就是所有的服务会由企业服务总线里的一个虚拟端点来表示，而

11、服务消费者只需要连接在企业服务总线里的虚拟服务端点，由企业服务总线在运行的时候来定位实际的服务在哪里。企业服务总线核心是一个消息处理引擎，对于服务使用者的请求（典型的如SOAP消息），按照正确的规则去了解消息的内容，处理之后把消息发给正确的服务提供者，然后需要记录处理的中间结果，再协调服务使用者和服务提供者的关系，在两个或者多个本来没有设计为互相调用的服务间提供互相调用并监控他们的相互调用。企业服务总线集成架构示意图企业服务总线集成架构中的每个实体都扮演着服务提供者、使用者这两种角色中的某一种（或多种）。企业服务总线集成架构中的操作包括：（1）发布：为了使服务可访问，需要发布服务描述以使服务使

12、用者可以发现和调用它。（2）发现：服务请求者定位服务，方法是查询服务注册中心来找到满足其标准的服务。（3）调用：在检索完服务描述之后，服务使用者继续根据服务描述中的信息来调用服务。企业服务总线体系结构企业服务总线是SOA体系中重要的组成部分。企业服务总线实现了松耦合、粗粒度服务的基础结构要素，为服务提供者和消费者之间提供中介服务，为参与集成的各方屏蔽了硬件平台、软件、网络和物理位置上的差异，有效地对服务进行管理并且降低服务之间的依赖关系，提高服务调用在多变的企业应用集成场景中的灵活性。企业服务总线应具备下图所包含的功能组件：企业服务总线体系结构图企业服务总线功能架构图服务管理企业服务总线提供嵌

13、入式的服务管理，对服务运行状态及相关KPI指标进行监控，并通过多种展现方式展示，同时可以生成相关统计报表。另外，也应支持完善的异常处理功能。消息处理企业服务总线需提供基于配置的服务组合环境，无需用户编写代码即可完成消息路由配置、消息流模型创建等操作。同时应提供消息验证及消息转换的功能。安全管理企业服务总线需要提供认证，授权，加密等安全功能保证企业服务总线上的服务被安全的调用，以及企业服务总线可以按服务提供者需要的安全机制调用提供者。企业服务总线通过使用明确的安全策略（如基本授权、HTTPS、SSL、WS-Policy等）为服务提供可靠的安全架构。消息传输企业服务总线需要支持多种接入方式、消息传

14、输协议转换等，包括对服务调用者提供多种调用协议，以及能够连接使用各种私有传统接口的服务提供者。企业服务总线功能性需求解决方案 消息传输企业服务总线提供内建的对各种服务传输协议的支持。企业服务总线还提供客户化传输协议的开发，使客户能够根据需要扩展服务总线的能力。多协议传输支持包含如下功能：功能描述支持的多协议支持包括HTTP，HTTPS，JMS，MQFTE，File，FTP，SFTP，JCA，TCP/IP，E-mail(POP/SMTP)等传输协议支持中间件之间的互操作支持.NET, Oracle, BEA WebLogic, Tibco EMS, ORACLE MQ, ORACLE WebSp

15、here等中间件消息传输优化支持基于XPath、XSLT、XQuery、XML Schema、Java代码等对XML消息进行格式转换和路由处理优先级传输支持消息按优先级传输，即消息被赋予一定的优先级，优先级较高的消息优先传输大文件传输支持大容量的消息传输，但不建议使用非持久化消息支持持久化消息和非持久化消息，原则上采用非持久化消息Base64编码解决特殊字符的传输和解析 安全管理企业服务总线提供消息安全、身份认证、权限审计、加密签名等功能，所有参与集成的业务应用服务的安全统一由企业服务总线负责。调用方的业务应用经过企业服务总线的身份证认证后方可访问服务；业务应用与企业服务总线之间采用消息安全机

16、制实现信息的安全传输。安全管理包含如下功能：功能描述传输安全支持SSL/Basic授权服务安全支持WS-Policy/WS-Security, 用户名/口令，数字签名和加密安全策略支持自定义安全策略，提升WS-Security & WS-Policy 消息处理消息转换消息转换用于服务使用者与服务提供者之间存在不同的数据类型，以及需要数据映射以便转换数据的情况。消息转换包含如下功能：功能描述支持消息类型支持SOAP格式定义与转换应支持基于Schema的消息内容和消息头、规则以及过滤器进行控制，支持XSLT格式转换支持通过对外调用方式，调用外部基于Java代码的转换自定义处理逻辑企业服务总线提供扩

17、展功能，用户可自定义消息处理逻辑，如通过Xquery、Xpath、XSLT、Java Code等方式进行扩展字符集支持支持中文字符消息验证消息验证可用于服务访问控制、服务版本控制，以针对不同版本的schema或WSDL验证消息。这是为了确保消息被发送到服务端点的正确版本，或在发送消息前检查是否必须应用转换。消息验证包含如下功能：功能描述消息验证支持消息的验证，对照WSDL或XML schema验证进出的消息。保证进出的消息符合目的地服务使用者或提供者期望的格式验证失败的消息可记录该失败，还可以产生错误消息路由服务是由不同服务提供者提供的。服务使用者在调用这些服务的时候，无需关心服务的实际提供者

18、，由企业服务总线基于消息内容实现动态路由，将请求消息投递到正确的一个或多个目的地服务。对于复杂的路由需求，服务总线还能够支持“调用外部服务（service callout）”操作，对一个外部服务进行调用，然后依据其返回结果完成路由操作。动态路由包含如下功能：功能描述动态路由路由可以基于SOAP报文头，传输报文的头，JMS用户定义的属性，MQ的报文头，文件目录，E-mail，消息内容（XML数据和格式化的非XML数据）来进行路由机制通过配置实现，不需要针对每一个服务使用者和服务提供者进行硬编码。消息流模型企业服务总线提供可视化的开发、配置、调试环境，用户可通过图形界面创建消息流模型，配置消息管道

19、Pipeline，通过拖拽方式完成消息的转换、格式校验、变量定义、路由判断等一系列操作。消息流模型包含如下功能：功能描述消息模型请求应答、发布订阅、查询查复交互模式同步、异步；包括请求/应答、基于事件驱动的发布/订阅机制、通知、定时轮询等可视化的集成开发环境提供一个开发、配置、运行管理的可视化环境，支持消息流、数据格式、数据转换等开发，提供友好的图形界面，利用方便的图形工具实现对消息格式和处理规则的定制 服务管理服务管理监控企业服务总线提供基于Web的控制台，能够提供所有的配置和监控功能。管理监控平台应能够管理部署在多个服务总线的实例，展现服务的运行状况、统计信息及服务水平告警信息等功能。企业

20、服务总线应提供统一的日志管理功能，日志功能可以记录通过ESB平台的服务调用过程，以及在必要情况下，记录通过ESB平台的消息副本。日志管理功能为事后审计及故障排查、分析提供依据。服务管理监控包含如下功能：功能描述监控指标企业服务总线的消息通道、服务端口、性能、负载、定时器、安全等监控指标展现形式向用户提供多种展现方式，能够立即允许用户查看监控信息；展现形式包括：折线图、柱图、饼图等展现方式监控信息所运用的展现方式，展现方式包括：HTML，FLEX等方式提供完善的日志管理记录生产环境中，传输运行时交换的信息提供完善的操作日志记录服务管理监控平台上的操作活动信息统计分析企业服务总线提供对服务器以及服

21、务指标进行统计并提供分析报表。统计分析包含如下功能：功能描述服务统计指标对企业服务总线及服务进行统计，并提供错误与性能统计数据及分析，服务统计指标包括：成功/失败率；消息数；错误数；异常数；响应时间、服务处理开销、总线处理开销、报文长度、请求链路IP、总线IP报表向用户提供关键性能指标的分析报表，并可提供自定义报表统计展现具备对统计信息的展现功能，展现形式与方式请参考服务监控管理中展现项目异常处理企业服务总线提供完善的错误处理功能，能够灵活地配置服务的错误处理。企业服务总线应提供统一的异常检测和处理机制，所有接入系统都会有一套错误代码在ESB中注册。ESB维护一套处理机制，针对不同的错误代码，

22、判断异常处理的逻辑。当某类服务调用发生故障时，不会造成ESB的访问阻塞，不影响服务请求方对于其他类别服务的访问。异常处理包含如下功能：功能描述消息跟踪支持利用进出消息的记录，获得消息流的精确描述，提高错误的可视性，辅助快速识别异常产生原因异常处理机制支持捕获多层的异常，处理SOAP中的异常；提供丰富的客户化差错消息，可调用服务；提供通过Email等方式的异常消息通知；提供默认系统错误句柄处理错误；服务注册/授权用户可通过服务管理监控平台向企业服务总线手动注册服务，也可通过服务管理监控平台进行服务访问授权，发布到ESB平台的服务，只有经过ESB平台的授权，才可被合法的系统进行调用，这是由服务访问

23、权限控制功能来保障的。服务发现包含如下功能：功能描述服务注册支持向企业服务总线注册服务服务授权支持进行服务访问的授权 流量控制流量控制原则保证用户体验在系统处理能力不足时，应该及时通知用户或限制用户调用总线服务，对于不同级别的用户，总线应该提供不同总线访问通道，这样可以避免在系统达到容量限制时，所有用户都被拒绝访问服务。隔离原则在需要流量控制的情况下，首先考虑使用隔离的方法将流量分散到不同的通道中，隔离的方法可以是物理格式和逻辑隔离。物理隔离是指在物理上分散，例如可以部署多个企业服务总线实例，为高级别用户或重要系统，关键服务单独使用。逻辑分离是指在同一个服务总线实例上分散访问服务的能力，例如可

24、以通过MQ通道区分不同优先级的请求或者用户，为高优先级的服务或用户提供服务。保证企业服务总线健康稳定运行在流量控制时，应保证不对其他系统或通道造成影响，例如，分多个企业服务总线物理隔离时，即使某一实例达到性能瓶颈，也不为高优先级用户服务的实例提供服务。在保证各系统健康稳定运行的情况下，考虑公平及效率原则公平原则是指为了避免某类用户、系统、服务被流量控制后，在相当长的时间内得不到系统响应，在实施流量控制后，需要对控制发生的原因进行重试请求。效率原则是指在控制之后，应该选择合适的时机进行流量控制恢复，例如当企业服务总线空闲时。基于ESB平台的流量控制场景在一个或多个企业服务总线平台上，可以设置ES

25、B平台的总流量，可以在流量允许的情况下提供服务。控制时机ESB平台：控制时机为在一定时间T（建议3分钟）内，如果系统请求并发数超过ESB平台所能容纳的请求并发数，即产生流量控制。ESB平台流量值可以事先设置，在运行过程中可以随时修改。控制恢复时机ESB平台：在一定时间T（建议3分钟）内，如果系统请求并发数低于ESB平台所能容纳的请求并发数的数量的80%，即开始恢复最近拒绝的ESB平台级别。例如，ESB平台被流量控制后3分钟内，系统请求并发数持续低于所能容纳并发数则恢复各系统接入企业服务总线。基于系统的流量控制场景在一个企业中，不同的系统功能不同，有的系统重要性不是很高，可以在流量允许的情况下提

26、供服务，对于重要的业务系统，则要实时保证为其提供服务，例如营销、财务。控制时机系统：控制时机为在一定时间T（建议3分钟）内，如果系统并发数超过接入层所能容纳的系统并发数，即产生流量控制。系统并发数可以事先设置，在运行过程中可以随时修改。控制恢复时机系统：在一定时间T（建议3分钟）内，如果系统并发数低于接入层所能容纳的数量的80%，即开始恢复最近拒绝的系统级别。例如，某系统被流量控制后3分钟内，系统并发数持续低于所能容纳并发数则恢复某系统接入企业服务总线。基于服务的流量控制场景对于相同的业务系统中，不同的服务的重要性不同，需要根据服务的优先级保证重要服务的运行。例如，对于财务系统的凭证同步服务和

27、查询现金流量表服务，就需要首先保证凭证同步服务优先服务。控制时机服务：控制时机为在一定时间T（建议3分钟）内，如果服务并发数超过接入层所能容纳的服务并发数，即产生流量控制。服务并发数可以事先设置，在运行过程中可以随时修改。控制恢复时机服务：在一定时间T（建议3分钟）内，如果服务并发数低于接入层所能容纳的数量的80%，即开始恢复最近拒绝的服务级别。例如，财务系统某查询操作被流量控制后3分钟内，服务并发数持续低于所能容纳并发数则恢复财务系统某查询操作接入企业服务总线。为了保证服务的服务质量，通过流量控制的机制来保证服务请求方不会在单位时间内产生过多的服务请求，服务提供方不会在单位时间内接受过多的服

28、务请求，影响服务提供方的服务质量。企业服务总线非功能性需求解决方案 可用性1、应用层采用PCP架构，两台应用服务器并行运行，通过负载均衡器来分配Web层的负载，单节点故障时，并发请求会自动转到另一台服务器上，系统不会停止提供服务2、数据库层采用RAC架构，使用两台数据库服务器搭建RAC架构，Oracle RAC技术采用Share Everything架构，组成集群的每一台服务器都可以访问共享磁盘，都能对外提供服务，单节点故障时，系统不会停止提供服务 及时性应用系统采用两台服务器的PCP架构，使用负载均衡技术能够根据负载动态的分配访问，能够有效的减少前台访问的延迟，提高访问效率。数据库层使用两台

29、服务器的RAC技术，并使用高效的存储阵列，能够提供大数据吞吐量的支持。提高了数据库相应速度。 可靠性使用基于企业服务总线的消息传递机制，保证数据在系统间传输过程中的一致性。有两种消息传递机制：同步、异步另外，还有完备的消息备份机制以解决消息传递过程中的异常：在消息通道处理消息过程中，有两种情况可能会导致消息发送失败，一种是消息接收者在接收消息时处于不可用的状态；另一种是消息处理节点在处理消息时发生异常。针对情况一，当监测到消息接收者处于正常运行状态时，取出第二次的消息全备份重新发送给消息接收者即可；针对情况二，当监测到异常的消息处理节点恢复正常时，先取出第一次的消息全备份，接着应用该异常消息处

30、理节点前所有的消息增量备份，重新构造消息，再次发送给该消息处理节点即可。 故障恢复方案1）故障恢复计划：应用系统故障恢复采用对文件备份进行克隆方式进行；数据库故障恢复使用RMAN备份的数据文件+归档日志进行恢复，通过设置RMAN的恢复参数，可以全自动进行。2）系统冗余/备份/恢复：应用层采用两台服务器PCP架构，数据库层采用两台服务器的RAC架构，备份文件包括保存在存储上的每周备份以及在磁带上的历史备份，保证有足够的备份，可以恢复到任意时间点。 业务连续性方案各系统之间使用基于企业服务总线的iBus集成，消息传递中有标准的备份恢复机制，保证其中一个系统维护时，不影响其他相关系统运行，并在维护系

31、统恢复时自动恢复消息传递，保证数据的完整性及连续性。 系统备份方案1、应用系统采用备份文件系统方式在不停机情况下备份oracle目录，便于对整个应用进行恢复，建议每月进行一次2、数据库使用RMAN备份在业务量较少的每周日进行一次0级备份，周一、周四进行1级增量备份，其他时间进行2级增量备份建议在存储上保留1-2周的备份（采用压缩方式，每周整个备份文件大小小于正式数据文件），建议在磁带机上保存至少1个月的备份（可以根据实际需要确定具体的备份量） 安全性应用系统部署在公司内网，并使用VPN技术提供外部合法访问。对于内部用户对数据库的访问，采用在数据库层设置绑定MAC地址方式，限定数据库访问权限，并

32、结合合理的apps密码变更策略增强访问安全性。 系统架构、可扩展性、集成性使用基于企业服务总线的企业应用集成架构，是一种粗粒度、松散耦合服务架构，服务之间通过简单、精确定义的接口进行通讯，不涉及底层编程接口和通讯模型。具有良好的跨平台能力和扩展性。企业服务总线部署方案 部署架构原则高可用性企业服务总线作为企业服务提供和消费的核心运行和管控平台，承载着企业各种关键应用和核心应用的数据交互、数据共享和数据分发，其稳定性必须得到保证，其故障率必须降到最低。企业服务总线的高可用性则成为其部署结构构的第一个原则，也是最重要的原则，企业服务总线必须无单点故障，必须实现平台故障时无缝切换。可采用的部分高可用

33、性技术如下：操作系统层面：LinuxHA（Linux），HACMP（AIX）实现机器硬件故障时的主备机切换，同时也可以实现对应用状态进行监听，在应用发生故障时，切换到备机并启动应用。ESB多实例：部署多个独立的ESB平台应用，共同对外提供服务，由Oracle HTTP Server 或者F5对多实例进行负载转发。ESB多实例部署可以很好的实现水平扩展。利用Cluster技术实现高可用性:Oracle HTTP Server 在对多实例进行负载转发时，如果侦测到故障实例，则停止向故障实例转发，保证请求能够正常得到处理。负载均衡作为企业各种关键应用和核心应用的数据交互、数据共享和数据分发的统一服务运行平台，企业服务总线的服务和数据交互的性能则尤为重要，为了提高保证企业服务总线应用，则必须使企业服务总线各个单元能效达到最优和最高，企业服务总线的部署架构必须实现负载