java - 了解 ESB

Question

<分区>

Answer 1

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

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

在一个简单的例子中:

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

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

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

是的，完全正确。

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

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

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

但大多数人通常做的是:

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 服务，它们可能没问题。如果您从事的业务经常这样做，那么它们可以很好地工作。当您有数十条管道时，它们可以帮助管理它们的运营方面。

但是对于复杂的管道，如果您有很多步骤，那么除了原型(prototype)制作之外，这可能不是一个好主意，尤其是当涉及到任何实际体积时。请注意，您可能别无选择，具体取决于您要集成的系统。

如果没有，如果您只有一个界面，您需要站起来——那就去做吧。用 Perl、Java、C# 等等。不要耗尽您现在需要学习、掌握和维护的 100MB 的基础架构和复杂性。

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