2

我们目前正在考虑用可能的 ESB 或一些类似工具替换我们的一个应用程序，并正在寻找一些关于如何最好地解决这个问题的见解。

我们目前有一个独立的服务，它使用/交互不同的外部服务和数据源，其中一些通过 SOAP Web 服务交付，而另一些我们只使用数据库连接。此服务通过 SOAP 公开，我们有其他应用程序使用此服务但与它非常紧密耦合，现在我们还有其他应用程序需要使用一些外部服务并希望将其全部替换为 ESB 或某种 SOA 平台。

用 ESB 替换这个“外部”服务集成层的最佳方式是什么？我们正在考虑拥有一个“全局”合同/API，其中我们使用的所有服务都作为一个合同公开，我们使用的所有可能的操作和数据结构都公开在一个命名空间下，这是最好的方式吗？接近这个？如果是这样，是否有任何工具可以帮助我们自动化这个过程，或者我们基本上必须手工制作这个合约/API？这也意味着对于底层服务/API 的任何更改，我们也必须更新这个新的 API。

如果不是，那么我看到的另一个选择是基本上使用“ESB”作为“代理”层，在其中我们所有的源都按原样公开，所以我们最终会得到几个不同的“合同”/ API 端点，但是我真的看不出这其中的价值。

还考虑到上述情况，什么是这项工作的最佳工具？一个成熟的 ESB 是不是矫枉过正，还是我们使用 Apache Camel 或 Spring Integration 之类的东西更好地滚动我们自己的东西？

更多细节：

我们目前正在整合超过 5 种不同的外部服务，未来还会有更多。

目前只有几个应用程序在使用我们当前的应用程序，但未来其他几个应用程序/系统将需要使用其中一些外部服务。

我们目前在这些服务之间使用单一的通信方法 (SOAP)，但某些应用程序将来可能会使用 pub/sub 消息传递，尽管 SOAP 仍将是使用的主要协议。

我是 ESB 集成的新手，所以如果我误解了很多这些技术以及它们要解决的问题，我提前道歉。

任何帮助/提示/指针将不胜感激。

谢谢。

4

1 回答 1

5

您需要对随着时间的推移想要实现的目标提出一些设计思想。

引入 ESB 有多种好处和潜在的缺陷。

以下是一些典型的好处/用例

  • 当您的应用程序难以更改或具有非常不同的发布周期时，在中间放置一个可以快速采用更改的 ESB会很方便。当您的组织购买大量 COTS 产品和云服务时，这种情况非常常见，这些产品和云服务可能会在第二天更新，从而破坏当前的 API。

  • 当您需要将数据从一个主数据系统调整到其他几个系统并且它们可能不支持相同的接口时，即 CRM 系统可能希望数据一旦可用就通过 Web 服务导入，ERP 希望数据通过 db/staging 表和生产系统希望每个周末以通过 FTP 传送的平面文件的形式提供数据。为了保持主数据系统的清洁和易于维护，只需在主数据系统中实现一个集成服务，然后将此接口适配到 ESB 平台内的各种其他应用程序。

  • 聚合或拆分来自各种来源的数据以保护您的敏感系统可能是一个用例。假设您有一个旧系统，可以一次更新少量信息，不值得升级该系统 - 那么可以进行聚合或拆分或限制的集成解决方案可能是一个很好的解决方案。

其他好处和用例包括跟踪和窃听系统之间传递的每条消息的能力——甚至可以与商业智能工具一起使用来收集 KPI：s。

概念性 ESB 还可以引入规范消息格式，用于所有需要通信的服务。如果许多应用程序与其他几个应用程序共享相同的数据（不仅仅是点对点） - 那么规范消息格式的好处可能会超过成本（这是/可能很高）。ESB 服务器可能有助于处理规范数据，因为它通常非常擅长从一种格式映射到另一种格式。

但是，在没有计划的情况下引入 ESB 并试图获得什么好处并不是一件好事，因为它会引入开销——您需要另一台服务器来保持活动状态，您可能需要另一个团队来了解所有数据流。您需要有关集成产品的特殊知识。最后，您需要能够围绕它进行一些治理，以便您的 ESB 计划不会偏离您预见的目标/收益。

你应该选择一些你觉得舒服的技术——或者认为你可以接受。Apache Camel 确实非常强大，也是我最喜欢的集成引擎——但它不是 ESB，因为它没有提供可用于部署/管理/监控集成服务的运行时。您可以将它与大多数 Java EE 应用程序服务器一起使用，甚至更好 -为该任务构建的Apache ServiceMix (= Karaf + Camel + ActiveMQ + CXF )。

spring 集成也是如此 - 你需要在某个地方运行它，应用服务器或其他地方。

有大量不同的产品，包括开源的和商业的，都可以做这些事情。

于 2013-07-11T08:42:49.627 回答