具有多个注册中心的直连 ESB

　　直连 ESB 模式上的变量对每个 ESB 使用一个注册中心(可能通过中央注册中心来扩展，最大扩展至集中式控制)。如果没有中央注册中心，则每个业务单元都必须定义和符合向其他部门提供的服务承诺。任何一个变量都需要仔细考虑 1) 如何在多个注册中心之间对服务元数据进行复制、同步、分割、转换等，以及 2) 当服务跨多个 ESB 交互时如何维护非功能特性(不只是安全性，还有性能、可靠性、事务性等)。

　　代理 ESB

　　与前一个模式类似，代理 ESB 模式适合具有多个区域或部门的业务。它也通过集中发布服务来使本地拥有的服务跨部门可用。然而，边远的 ESB 环节只连接到代理 ESB，而没有直接相互连接。这种分离使得基础设施能够更快速地反映业务变化。它应用于中介控制模式，其中服务规范和实现是在业务单元级别控制的，并通过一定程度的集中控制来使得跨部门的服务能够重用和互操作。

　　图 6. 代理 ESB 模式

　　在代理 ESB 中，有一个公共代理来提供桥接服务，这些服务选择性地将请求者公开给其他域中的合作伙伴，以便控制多个 ESB 安装之间的共享(每个安装管理自己的名称空间)。

　　代理 ESB 显示以下请求流程:请求者从其本地 ESB 请求一个服务。该请求被中转和路由到该代理，它进行第二次中转，将请求路由到与提供者关连的 ESB。此 ESB 将请求传递到服务提供者，由其完成初始请求。

　　代理有助于克服直连 ESB 模式的点到点连接的可维护性挑战。虽然在几个 ESB 共同参与时代理有着明显的优势，但预期的服务调用量也是很可观的。这里与直连 ESB 不同的是，跨 ESB 的代理逻辑是集中放置的(虽然每个边远的 ESB 都有自己的服务注册中心)，而且中央注册中心包含有利于代理的条目。

　　在代理 ESB 中，各个业务单元负责在其生命周期内控制和管理自己的 ESB。为了协调数据格式和策略差别，公共代理将集中控制。为了促进灵活性和重用，常用方法(例如标准企业消息格式)允许通过代理进行互操作。

　　除了以下几点不同外，SOA 用户角色的任务与直连 ESB 模式中的任务相匹配:

　　集成开发人员可能另外开发对公共消息格式和策略的中介。
　　操作员的任务是相同的，但围绕服务调用代理的监视和管理中心除外。
　　控制的重点在于通过代理进行服务交互和中介，以及通过定义和管理公共格式来提高重用性和灵活性。中介和策略所负的责任必须明确。

　　中介模式与直连 ESB 类似，但较松散的耦合提高了服务可见性。

　　代理 ESB 模式适用于业务领域开发和管理自己的服务，但只共享其中的很少一部分，或者选择性地访问另一个业务单元的服务的情况。当服务所有权更改时——例如，一个部门独立出去——则此模式可能使受影响的服务交互的修改任务减少，因为(由于可视化)只有代理受到影响。

　　轮辐式 ESB

　　存储/分支业务设计的特征是集中管理业务流程及其底层服务，并可能在分支中有一些本地服务。分支可能部署一些可以连接到中心或独立运行的服务以启用本地操作。对于特定于分支的服务，可能有一定程度的分布式控制。具有强大中心组织的本地控制模式是最为常见的。一些集成场景可能得益于联合控制。

　　图 7. 轮辐式 ESB

　　在轮辐式 ESB 模式(它最适合于存储/分支业务设计)中，几个分支 ESB 直接连接到中心 ESB，而分支之间没有直连。整个网络的服务使用者和提供者通过其中的一个 ESB 来访问服务。这种拓扑可以联合一组在监控组织监控下适度自主的分支;它还使每个分支能够灵活地提供本地服务。分支中的特定功能可以委托给中心 ESB，但是如果具有合适和一致的本地支持能力，则分支可以进行自主。

　　在分支中，服务请求是向本地 ESB 提出的，它再将请求转发和路由到中心 ESB，进而到中心服务提供者上。类似地，中心 ESB 发起的服务调用可以通过反方向路由到驻留在分支的服务，但分支到分支的交互是不存在的。

　　当发生与中心连接中断的事件时，分支可能在本地支持有限的业务功能，一旦连接恢复，随即与其同步。

　　分支 ESB 基础设施是集中提供的，集中提供的还有转换、策略、安全性和服务注册中心项。然而，如果分支可以自主定义和实现其他本地服务(或者集中定义本地部署的服务的变化)，则控制模型需要与此相符。对本地分支 IT 技能的投入可能很少，但是对任何本地必需服务的分析、设计、实现和操作的投入却很充足。基础设施监视和管理可以集中进行，也可以在本地进行，而且应该反映控制模型。

　　SOA 用户角色所受影响如下:

　　业务分析人员关注维持分支活动的中心流程及服务的结构布局，以及它们如何访问必需的数据。分支到分支的交互通过中心来中转。分支中的业务分析人员捕捉其他本地需求和变化。

　　解决方案架构师定义分支和中心站点之间的交互，包括安全性、策略、监视和管理。存在的一些问题包括:如何保护分支中的用户访问、断开连接的操作、如何进行服务级监视以及数据同步延迟。带宽不足可能会限制性能或影响移动数据以支持本地服务执行的能力。架构师也定义创建本地服务或改变中心服务的机制。
　　集成开发人员遵循分支到中心和中心到分支的互操作性规范，包括中介产生的特定监视事件。
　　解决方案管理员组装解决方案，并确保对中心 ESB 和所有分支进行同等部署。分支中的用户访问通常是集中管理的。服务变化和增加需要本地管理，它们也应该是安全的。
　　操作员监视中心和分支 ESB，以便在服务级别不符合或者分支连接中断或恢复时维护可用性;也可以在分支中进行本地操作。
　　该中介模式类似于单一 ESB 的模式，不同之处在于:

　　根据连接性，路由会发生变化。当一个分支断开时，正常情况下发往中心的请求被送到本地提供者，以便分支继续运行。集中中转的分支到分支交互也会受到类似的影响。

　　根据连接性和性能，会动态调整请求的分发，将其分发到多个有关方，以维护请求者可接受的服务级别。
　　为了能够对服务级别进行管理，将对消息流量进行监视，公开整个分布式拓扑的活动，特别是当它与中断的分支连接有关时。
　　聚合多个消息以创建新的、复杂事件的中介必须符合业务需求，即使在期望的事件延迟或根本没有到达时也该如此。

　　强加式 ESB

　　强加式 ESB 模式(轮辐式 ESB 的一种更极端特例)适合所有服务都集中控制的存储/分支业务设计。总部或区域办事处提供所有的 IT 服务(在分支级别很少或没有投资 IT 技能)，因为不允许本地自主。与轮辐式一样，可以将服务部署到分支以支持具有单点回退功能的中心连接操作。

　　服务请求和完成的一般模式，以及出现操作中断并在连接恢复时进行同步的可能性，都与中心和分支模式相同。

　　分支 ESB 的基础设施、转换、策略、安全性和服务注册中心项都是集中创建和管理的，很少或根本没有本地自定义。任何请求更改 IT 的分支请求都被提交到中心 IT 管理，由其批准和推出。监视和基础设施管理都是集中进行的。

　　对用户角色的影响与中介模式是类似的，除了控制和管理完全集中进行以外，因为分支所具有的 IT 人员极少。

　　服务注册中心的复杂应用程序

　　混合控制模式对服务注册中心的使用更复杂。例如，在直连和代理 ESB 模式中，某些服务可能由业务单元以分布式方式控制，而其他服务则集中控制，或者由一个业务单元开发的服务可能由其他业务单元(或集中)提供或运行。

　　图 8. 级联注册中心

　　级联注册中心样式(支持 ESB 拓扑)允许以分割方式进行控制，其中服务调用是在企业范围内公用的，而服务设计和构造是级联的。每个业务领域都有自己控制的注册中心。顶级服务注册中心是在企业级控制的，位于创建服务的业务领域之上。服务部署方式是将其注册到顶级注册中心，然后将一些或全部注册中心项级联到本地注册中心。

　　此模式应用一个企业范围的 ESB，外加每个业务领域一个 ESB。非常大的部署可能对每个业务单元增加第三层级的 ESB，以便将服务请求中转到该单元。服务(包括企业服务)可以在拓扑中的任何级别提供。请求者和提供者通过最少数量的 ESB 直接交互(不需要强制通过托管顶级注册中心的企业 ESB 来进行跨层次路由)。这种拓扑通过更改注册中心控制模型来扩展直连 ESB 模型。

　　它影响两个 SOA 用户角色:

　　解决方案架构师定义服务部署和注册中心管理机制(它们能够对跨多个 ESB 的请求寻找最佳路由)。
　　解决方案管理员在部署和管理服务时，根据需要将注册中心项从顶级注册中心级联到其他注册中心。
　　此拓扑成功与否最大程度地取决于是否存在有效的企业级控制。即使服务设计是级联的，部署都是从顶级注册中心发起的。这种拓扑形成了企业范围公共的服务定义。

　　这种体系结构适合部门或区域以很大程度联合的方式运行的公司——部门负责大多数业务操作，而企业级控制则促进了跨所有部门的公共业务方法。典型代表是想要跨整个企业提供公共的、共享的业务服务或管理其品牌的公司。

　　监视复杂的 ESB 拓扑

　　有时候复杂的 ESB 拓扑可以从独立的事件传输渠道获得好处。

　　技术事件是那些用于监视支持服务水平协议的基础设施的事件。正如 SOA 所定义的，业务事件通常包括可能触发后续逻辑(业务动作)的关键性能指标(业务度量)。简单的业务事件是一个事务的直接结果，而复杂的业务事件则是业务分析人员定义的一系列变化组合而形成的结果。

　　业务和技术事件对 ESB 强加了一些额外需求。不仅必须记录事务更改和承认相关事件，基础设施还必须能够处理事件流。另外，事件可能被发布到订户组，也可能被记录或审核。分析人员确定事件及其支撑中介所公开的工作负载是否最适合于单一 ESB 拓扑或独立渠道。

　　事件生产者通常离引发动作的站点很远;这种分离性需要在控制时特别注意。事实上，对事件创建和引发动作的分布式控制通常是与对整个控制的集中式控制结合进行的。

　　ESB 介于事件生产者和事件使用者之间。这可能包括跨整个 ESB 拓扑的 ESB 节点的选择性事件传播。在设计 SOA 中的事件流时，要考虑以下几点:

　　在发布-订阅交互中，一次发布的事件可能作用于多个订户;订户可以使用选择器筛选主题传入的事件。
　　可能需要使用访问控制来保护事件负载免受未经授权的访问。
　　发生的相同事件可以建模为几个简单的事件或一个复杂的聚合事件——每种方法都有不同的工作负载特征。
　　如果需要，可以通过相关器来准确识别事件流中的给定事件。

　　结束语

　　本文中列举的这些 ESB 模式并不详尽，但阐述了您在计划 ESB 拓扑和控制模式以实现业务设计时所面临的一些常见方法和注意事项。实际的组织结构和控制模型远比这些复杂，采用任何拓扑模式都需要进行一些调整。您可以组合这里列举的模式来创建具有 SOA 所承诺的灵活的体系结构，以补充您的组织的独特需要。