ESB架构之企业实施案例.docVIP

ESB架构之企业实施案例作者 郭时光 发布于 2011年4月6日 本文讲述了ESB架构在企业内的实际运用，包括在部门内、部门间以及企业级ESB架构的设计和案例；分享了ESB设计过程需要考虑的关键问题；描述了不同ESB域的实施重心。 概述 ESB的存在主要是为了整合企业内部的应用，使企业内的应用能融为一体，而不是成为一个个信息孤岛。可以说ESB是企业内所有服务的中心点，其它系 统间的交互都需要通过ESB来完成。为此，它需拥有如下质量属性：可用性、性能、可修改性、可测试性、易用性。参考“ESB的质量属性”一节。 为了解释这些架构属性，我们可以从企业域、部门域、ESB内部视角三个层次来进行说明。ESB除了高可用性和性能之外，高可伸缩性也很重要，在实际 实施过程中，读者可以对整个结构进行裁减，在开始时，可能只需要一个部门域，部门域内支持水平扩展。当达到瓶颈之后，则可能需要部署到多个部门域，这样就 可以扩展出多个水平扩展的节点，减少单个节点的职责。 ESB的质量属性 可用性 ESB是企业内应用之间及对外第三方系统之间交互的集中点，它集中管理了交互的所有服务。它还提供服务查找、管理、审计、监控、分析等功能。当ESB服务出现故障，就将会影响企业内所有应用的正常运行。所以，可用被性放在了第一位。 性能 随着企业内部整合的推进，ESB内部的服务交易量应该不会少，高性能对于ESB来说也是非常重要的。 可修改性 因为SOA的企业治理是一个循序渐进的过程，在ESB部署之初，很难准确估计未来的交易量，所以，对性能的扩展性要求也比较高。 在实际的生产运维过程中，我们还是会常常发现，服务可能会出现这样或那样的问题。为了不影响服务消费者对服务的正常使用，快速的修改和部署，是一个很重要的问题。 ESB项目是随着SOA治理的发展而一次次迭代的，这也就要求了很高的可修改性。 可测试性 ESB上线既然是一个迭代的过程，服务会根据SOA理念的深入而增多。在迭代过程中，要保证以前的服务能顺利通过测试，可测试性是一个很重要的保障。 企业内的应用应该只需面向ESB，它们交互时并不需要知道这个服务位于哪里或是谁在使用该服务。这时，ESB测试就是一个很大的问题，因为当一笔交易开始的时候，你可能并不知道它会在哪里，但我们却要保证这笔交易是正确的，这样才能保持服务的正确性。 易用性 实现易用性需要提高服务的开发效率，即能快速开发和部署服务。因为它对生产上的活动没有影响，所以将它放在末尾。 企业域视图 在大多数据情况下，如果交易量不大，你大可以只使用一个部门域来支撑整个企业内的服务。但如果只是一个ESB的部门域的话，是没有办法支撑后来交易 量的逐年增长的。虽然每一个部门域都可以自行进行水平的扩展，但这还是有一个度的，超过这个度后，水平扩展的难度就会提高，此时可能需要在业务上进行垂直 拆分，这种方式当然没有水平扩展来得廉价，但它能更容易的支撑更大的业务量。 在企业域中，最大的特点就是有多个部门子域（图2.1），每个部门子域都是高度自治的。它们可以独立地处理域内各个系统的整合，只有当需要使用其他 域中的服务时，才会请求其它的域。为了防止部门域之间变成一个蜘蛛网，这里我们引入了企业域管理器，来统一管理域内的服务与及对这些部门域进行必要的监 控。 在企业域管理器中主要有以下的几个组件： 企业服务查找注册组件：这个组件一般情况下是独立部署的，而且应该有很高的可用性，在理想状态下，应该可以查找到所有部门域中的所有交易。跨域的交易都需要通过这个组件来查找到对应域的服务。 监控组件：这个组件可以查看各个部门域的运行情况。 图 2.1 元素 企业域管理器 企业服务查找注册组件 这个是企业域管理器的核心组件，使用它来管理企业内的所有服务，这个组件应该有以下几个功能。 服务注册：注册服务地址、服务描述及服务规约。 服务版本管理：管理服务的多个版本。 服务客户端代码的生成：根据服务地址及说明生成服务客户端，在我们的实施中，一般为java 版本。 服务路由表的查找：主要作用是查找对应的服务地址，而且可以推送给服务路由器。 服务的使用方注册：要调用服务，就必须到注册组件中进行注册，没有注册的使用方不允许进行服务的调用。这样就可以通过此组件找到此服务的使用路径，从而当服务进行更改后，可以有效的通知相应的服务使用方。 监控组件 这个组件可以查看各个部门域内的运行情况，并在部门域的运行超过阀值时发出预警。必要时，操作域内流控组件。具体的功能如下： 查看各个部门域的运行情况。如硬件资源、交易信息、流控信息和配置信息。 对资源使用情况进行预警。 根据情况操作部门域内的配置参数，比如流控的配置参数。 操作域内的流控组件，保证重要交易，放弃次要交易。 定时收集各个域内的信息。信息保存之后，为报表、决策分析等提供信息支持。