《ESB架构之企业实施案例》由会员分享，可在线阅读，更多相关《ESB架构之企业实施案例（16页珍藏版）》请在金锄头文库上搜索。
1、. . 本文讲述了ESB架构在企业的实际运用，包括在部门、部门间以及企业级ESB架构的设计和案例；分享了ESB设计过程需要考虑的关键问题；描述了不同ESB域的实施重心。概述ESB的存在主要是为了整合企业部的应用，使企业的应用能融为一体，而不是成为一个个信息孤岛。可以说ESB是企业所有服务的中心点，其它系统间的交互都需要通过ESB来完成。为此，它需拥有如下质量属性：可用性、性能、可修改性、可测试性、易用性。参考“ESB的质量属性”一节。为了解释这些架构属性，我们可以从企业域、部门域、ESB部视角三个层次来进行说明。ESB除了高可用性和性能之外，高可伸缩性也很重要，在实际实施过程中，读者可以对整个
2、结构进行裁减，在开始时，可能只需要一个部门域，部门域支持水平扩展。当达到瓶颈之后，则可能需要部署到多个部门域，这样就可以扩展出多个水平扩展的节点，减少单个节点的职责。ESB的质量属性可用性ESB是企业应用之间及对外第三方系统之间交互的集中点，它集中管理了交互的所有服务。它还提供服务查找、管理、审计、监控、分析等功能。当ESB服务出现故障，就将会影响企业所有应用的正常运行。所以，可用被性放在了第一位。性能随着企业部整合的推进，ESB部的服务交易量应该不会少，高性能对于ESB来说也是非常重要的。可修改性因为SOA的企业治理是一个循序渐进的过程，在ESB部署之初，很难准确估计未来的交易量，所以，对性
3、能的扩展性要求也比较高。在实际的生产运维过程中，我们还是会常常发现，服务可能会出现这样或那样的问题。为了不影响服务消费者对服务的正常使用，快速的修改和部署，是一个很重要的问题。ESB项目是随着SOA治理的发展而一次次迭代的，这也就要求了很高的可修改性。可测试性ESB上线既然是一个迭代的过程，服务会根据SOA理念的深入而增多。在迭代过程中，要保证以前的服务能顺利通过测试，可测试性是一个很重要的保障。企业的应用应该只需面向ESB，它们交互时并不需要知道这个服务位于哪里或是谁在使用该服务。这时，ESB测试就是一个很大的问题，因为当一笔交易开始的时候，你可能并不知道它会在哪里，但我们却要保证这笔交易是
4、正确的，这样才能保持服务的正确性。易用性实现易用性需要提高服务的开发效率，即能快速开发和部署服务。因为它对生产上的活动没有影响，所以将它放在末尾。企业域视图在大多数据情况下，如果交易量不大，你大可以只使用一个部门域来支撑整个企业的服务。但如果只是一个ESB的部门域的话，是没有办法支撑后来交易量的逐年增长的。虽然每一个部门域都可以自行进行水平的扩展，但这还是有一个度的，超过这个度后，水平扩展的难度就会提高，此时可能需要在业务上进行垂直拆分，这种方式当然没有水平扩展来得廉价，但它能更容易的支撑更大的业务量。在企业域中，最大的特点就是有多个部门子域（图2.1），每个部门子域都是高度自治的。它们可以独
5、立地处理域各个系统的整合，只有当需要使用其他域中的服务时，才会请求其它的域。为了防止部门域之间变成一个蜘蛛网，这里我们引入了企业域管理器，来统一管理域的服务与及对这些部门域进行必要的监控。在企业域管理器中主要有以下的几个组件： 企业服务查找注册组件：这个组件一般情况下是独立部署的，而且应该有很高的可用性，在理想状态下，应该可以查找到所有部门域中的所有交易。跨域的交易都需要通过这个组件来查找到对应域的服务。 监控组件：这个组件可以查看各个部门域的运行情况。图 2.1元素企业域管理器企业服务查找注册组件这个是企业域管理器的核心组件，使用它来管理企业的所有服务，这个组件应该有以下几个功能。 服务注册
6、：注册服务地址、服务描述及服务规约。 服务版本管理：管理服务的多个版本。 服务客户端代码的生成：根据服务地址及说明生成服务客户端，在我们的实施中，一般为java 版本。 服务路由表的查找：主要作用是查找对应的服务地址，而且可以推送给服务路由器。 服务的使用方注册：要调用服务，就必须到注册组件中进行注册，没有注册的使用方不允许进行服务的调用。这样就可以通过此组件找到此服务的使用路径，从而当服务进行更改后，可以有效的通知相应的服务使用方。监控组件这个组件可以查看各个部门域的运行情况，并在部门域的运行超过阀值时发出预警。必要时，操作域流控组件。具体的功能如下： 查看各个部门域的运行情况。如硬件资源、
7、交易信息、流控信息和配置信息。 对资源使用情况进行预警。 根据情况操作部门域的配置参数，比如流控的配置参数。 操作域的流控组件，保证重要交易，放弃次要交易。 定时收集各个域的信息。信息保存之后，为报表、决策分析等提供信息支持。部门域部门域是企业的一个个ESB节点，每个部门域会根据项目群，或者根据部门来进行划分，在各个部门域都有一个ESB组件，通过这个ESB来整合部门的服务及应用。这个组件我们将会在部门域的视角中详细描述。场景子域间交互所有服务都会注册到企业管理器的服务查找组件中，这个组件拥这些服务的描述及地址信息。图2.2描述了一个流程示例，部门域A如果要发起一个跨域的服务请求，就必须要使用企
8、业域管理器的服务查找组件，通过这个组件的路由表获取此服务提供者所在的部门域B的服务地址后，才能请求对应的服务。为了提高性能，在这个场景里，也可以在启动的时就获取所有路由信息，并缓存起来，服务请求时通过缓存来找到部门域B的地址。在这里有一点需要注意，当部门域改变了服务地址之后的通知机制，我们的实施中有下以几种策略： 服务查找组件进行推送 如果服务请求地址出错，重新请求服务查找组件 定时清空路由缓存 图 2.2部门域视图部门域是企业ESB实施的基本组成单元，在一定交易量围，它甚至可以独立存在于企业。部门域ESB可以独立地进行水平扩展，以进行性能的伸缩，而且，这种性能的伸缩在一定程度上应该是相对廉价
9、的。在部门域的视角，我们不用关心ESB的部实现，在一般情况下，只有以下四个场景 同步请求服务 异步请求服务 同步提供服务 异步提供服务同一域的系统只需要知道以上四种场景就足够了，其它工作会在ESB部进行整合。比如，与某个遗留系统的交易，ESB会通过适配器与之整合，我们会在ESB部视图进行阐述这一容。部门域主要涉及多种应用系统和ESB两种元素（图3.1），所有应用系统之间的交互都要经过ESB，它们是星型拓扑结构，所以，ESB成了一个单点故障点，出了问题会影响到整个部门域的各个子系统，这也是为什么在ESB的系统中可用性的质量属性如此重要的原因。图 3.1元素ESB组件ESB组件是核心，这个元素部的
10、功能将在ESB部视图中详细阐述。它位于部门域，其主要作用是： 减少各应用间的依赖：ESB最大的好处是可以把蜘蛛网结构的依赖关系理顺，使各个应用只依赖于ESB。 整合现有应用：ESB可以通过自身的一些技术组件，对现有的应用进行协议转换，让现有的应用能快速融入到企业整合的大环境中，不至于形成一个个的信息孤岛。 流控：保证高优先级服务的高可用性。域应用系统域应用系统是企业部信息/服务的实际提供者和消费者，当它需要为其它消费者提供信息/服务，或者要消费其它系统的信息/服务时，就会和ESB产生关系。企业外系统当今企业大多会与企业外部系统产生关系。我们不应在应用系统部直接和外部的系统产生关系，这样会耗费更
11、多的时间在安全管理上，而且很多时候这些外系统并不是只有一个应用在使用。此时，不但会增加了单个应用系统的复杂度，而且还会出现一些冗余。我们完全可以通过ESB来统一完成这些工作，简化应用系统消费服务的过程。BPMBPM系统实际上是应用系统的一部分，把BPM独立出来进行管理，是因为BPM在ESB架构中占有比较大的成分。在ESB实际实施过程中，我们可以使用ESB部的各种路由和端点的组合实现一定程度上的的BPM功能，但这样实际上会复杂化ESB。如果能使用BPM产品来做这个交易的流程编排，就能减化ESB部的复杂性。如果应用系统中没有BPM这类的应用系统，如果可能的话，我们最好能使在企业域中加入一个BPM组
12、件来实现业务流程。此时，ESB需要能很好地与BPM应用系统进行交互。场景在以下场景中，一次请际上会通过两个或更多的组件，之所以会这样，是因为ESB会屏蔽ESB的请求方和服务方的细节，当系统要与外部系统进行交互时，只应知道ESB这个系统。这也是为什么可测试性在ESB系统很重要的原因。在ESB系统中，整合测试是非常重要的。在同异步服务提供的场景下，因为交易的请求方只知道ESB，或者有时候根本没有请求方，在这种场景下的测试就显得非常重要了，ESB不但要满足技术上的测试功能，还要和服务方一起完成业务测试，这样才能保证这笔交易的正确性。同步请求下图是一个最简单的应用场景（图 3.2），在这个场景中ESB
13、只做交易转发，当然中间也可能做了报文转换的工作。这一切应该在部门级视角上看应该透明的，在部门域服务的使用者只需要依赖ESB提供的服务接口，而不需要依赖服务的最终实现。此处的细节会在ESB的部视角中进行阐述。 图 3.2异步请求如果服务不能在短时间能完成操作，就不应该使用同步请求，而应该使用异步请求。当该服务完成操作后，再回调一个方法来获取处理结果，当然，也可能不需要返回结果。 图 3.3同步提供服务 图 3.4异步提供服务 图 3.5ESB部视图静态看ESB系统，它主要由三部分组成（图 4.1） 端点（Endpoint）：它的职责可分为两部分，一部分是接收服务请求，另一部分是调用服务提供者 路
14、由器（Router）：主要是消息的路由。当端点接收到一个请求后，会交由路由器来选择相应的消息服务方。 基础组件：支持通用ESB模式的通用组件。图 4.1从动态地看ESB系统，你会发现，我们可以将ESB部看作一个个有组织的消息通道（图 4.2），客户端请求ESB时选择一个相应的消息通道。在这个消息通道中，会有很多的消息处理器，它们根据处理器自己的职责对消息流进行相应的处理。图 4.2元素消息处理通道消息处理通道是ESB架构的核心部分，ESB核心的消息处理器分为两部分，一部分是路由处理器，一部分是端点处理器。当然，我们的基础组件也会适时地在两个处理器中间，拦截加入多个基础组件处理器。例如，日志组件
15、会加入日志处理器，以记录ESB运行的日志。图 4.2中描述的是一个简单通道，在这个通道中没有分支，路由处理器也只有一个，在实际使用过程中当然没有这么简单，路由处理器可能有多个，Endpoint也可能有多个。当整个通道的分支过于复杂的时候，建议还是把它看成一个业务流程，交给专业的BPM产品来做，这样不但可以减少ESB实施的复杂度，还还可以大大提升其可修改性。在实际开发过程中，我们可以使用责任链模式（Chain of Responsibility Pattern图 4.3）。一条责任链就是一个通道，消息处理器就是责任链中的一个个处理器（handler）。我们可以使用配置组件，在ESB初始化的时候就完成一个个消息处理器初始化工作。图 4.3消息对象因为使用了消息通道，通道的消息流必然是要有统一的消息对象（图4.4）来进行良好的定义，这个消息对象，不但带有消息容，还应该包含消息状态，以及消息所处通道的上下文信息。
