esb架构之企业实施案例.pdf

本文讲述了 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 ），每个部门子域都是高 度自治的。 它们可以独立地处理域各个系统的整合， 只有当需要使用其他域中的 服务时，才会请求其它的域。 为了防止部门域之间变成一个蜘蛛网， 这里我们引 入了企业域管理器，来统一管理域的服务与及对这些部门域进行必要的监控。 在企业域管理器中主要有以下的几个组件： ?