10

虽然我了解什么是系统集成，但我对所有最新方法都有些陌生。我非常熟悉 Web 服务和 JMS，但我对 ESB 的概念感到完全困惑。

我做了一些研究，但我仍然不明白。我通过例子而不是理论工作得更好。

那么有人可以举一个简单的例子来说明为什么要使用 Enterprise Service Bus 而不是 Queue 、 web service 、文件系统或其他？

我希望该示例能够增强 ESB 的功能，这是任何其他传统集成方法都无法实现的，或者至少无法以相同的效率实现。

非常感谢所有答复。

谢谢，鲍勃

4

4 回答 4

9

这听起来有点刺耳，但基本上如果你需要一个 ESB，你就会知道你需要一个 ESB。

对于大多数用例，ESB 是寻找问题的解决方案。它是为大多数场景设计的软件堆栈。大多数人根本没有做足够多的处理来保证它。“企业”的“E”在这里值得注意。

在一个简单的情况下：

tail -F server.log | grep SEVERE >> severe.log

这是 ESB 场景实例的一个简单示例。

“但这只是一个 UNIX 命令管道！”

对，就是这样。

“ESB”部分是“|” 和“>>”

ESB 是运行时，您可以在其中将模块链接在一起、监控流量、设计各种古怪的场景，如扇出和连接等。

ESB 以拥有一堆连接器来读取一堆源并写入一堆目的地而著称。它们以使用相当粗略的逻辑块编织更复杂的图形和工作流来处理而著称。

但大多数人通常做的是：

input -> DO_STUFF -> output

使用 ESB，他们可以获得：

ESB[input -> DO_STUFF -> output]

在野外，大多数管道根本没有那么复杂。他们往往有一个不可重用的逻辑，人们倾向于将它整合到一个单一的逻辑模块中。

好吧，哎呀，你可以用 Perl 脚本做到这一点。

ESB 中的长管道往往效率低下。有大量数据进出通用模块的编组（因为您很少使用二进制有效负载）。

因此，比如说，CSV 进入，转换为 XML，对其进行处理，输出 XML 以作为 XML 输入到另一个步骤，XML 对其进行编组、处理、将其转换回 XML 以进行又一个步骤。冲洗并重复，直到 CPU 达到 400%（多核 FTW）。

然后有人提出“嘿，如果我将这些模块拖放到一个例程中，我们将跳过所有这些 XML 垃圾！”，最终得到“输入 -> DO_STUFF -> 输出”。

对于大型系统，有很多需要进行临时、临时集成的 Web 服务，它们可以很好。如果您从事的业务很多，那么它们可以很好地工作。当您拥有数十条管道时，它们可以帮助管理它们的运营方面。

但是对于复杂的流水线，如果您有很多步骤，那么除了原型设计之外，这可能不是一个好主意，尤其是在涉及任何实际体积的情况下。请注意，您可能没有任何选择，这取决于您正在集成的系统。

如果没有，如果你有一个单一的界面，你需要站起来——那就去做吧。用 Perl、Java、C# 等任何方式来做。不要用完并积累一些奇怪的 100MB 基础设施和复杂性，您现在可以学习、掌握和维护这些基础设施。

所以，再一次，如果你需要一个 ESB，你会知道的。真的。您将拥有由不同的东西组成的任何系统，您会与之抗争，与同事谈论所有这些东西是多么痛苦，您会偶然发现一些指向某个供应商的站点的链接并阅读一份白皮书然后说“就是这样！”，但如果你还没有这样做，那么你不会错过任何东西。

于 2012-10-26T23:47:48.923 回答
3

ESB is for the cases where you do have that web service and queue and file system all in the same system and need to integrate them. An ESB product usually solves the following

  1. Security
  2. Message routing
  3. Orchestration (which is advanced message routing)
  4. Protocol transformation
  5. Message transformation
  6. Monitoring
  7. Eventing

You can do all of these with other tools as well and if you just need one or two of these capabilities you can probably do without and ESB (as it introduced additional complexity) but when you need several of them an integrated solution in the form of an ESB can be a better solution.

于 2012-10-27T07:10:40.040 回答
1

正如@WillHartung 总结的那样，ESB 倾向于在大型、复杂的情况下正确使用。这就是为什么它被命名为企业服务总线。

现在，要真正回答您的问题，ESB 通常会：

  • 通过多种协议（例如 HTTP、消息队列等）进行通信，用于输入和输出

  • 建立通用的消息格式，并经常从其他格式转换为“规范”格式

  • 提供端点透明性（例如，您向总线发送消息并得到答复，但您不明确知道也连接到总线的服务处理了您的请求。

  • 提供监控和管理能力

  • 促进服务和消息的版本控制

  • 在需要时加强安全性。

因此，正如您所看到的，这是因为当进行大量点对点通信（“就这样做”）将是一大堆难以管理的意大利面条。事实上，在我见过 SOA 实施的大多数地方，它正在取代已经存在的大量意大利面条。

于 2012-10-27T00:00:19.233 回答
0

ESB 是一种企业服务总线，如果您喜欢面向服务的架构，它是一个基础架构背板。想象一下数百个服务愉快地重用彼此的混乱。如何管理这样的环境？您如何在服务之间提供灵活、解耦的路由？如何避免点对点的意大利面条式架构？您如何管理混合技术环境中的事务和安全性？您如何跟踪跨多个系统的复杂流中消息的位置？

您使用 ESB。

ESB 通常允许您使用 XML 配置语言设计跨多个系统的流程，为您提供大量 EIS 适配器、转换和中介插件等。有些将提供 IDE 来帮助您设计流程。有些 ESB 非常昂贵，有些是开源的。

如果您想了解 ESB，请查看 Mule 或 WSO2，它们都是优秀的开源产品，甚至是 Spring Integration，它是一种非集群解决方案，但非常适合将 Java 与底层外部接口点解耦。

于 2012-11-24T08:39:58.470 回答