java - 使用 Camel 的最合适的架构

Question

我们正在为我们公司的应用程序定义架构，因此该架构必须负责与其他应用程序/系统的集成。我们想到的第一件事是将所有集成集中在一个 ESB (Mule) 中，它将以独立模式运行。然而新的要求出现了，事实是每个应用程序都必须管理自己的集成(尚未定义，但它们应该不会很复杂)。

现在我们在嵌入式场景中使用 Apache Camel 或 Mule 进行评估。与一些伙伴讨论它，我们不是很清楚哪种是设置此架构的最佳(或更合适)方式。在我看来，作为每个应用程序的责任，我会将 Camel 直接集成到我的应用程序中(作为一个库)；但他们说在单独的项目中部署 Camel 是更好的选择。

这些是我所看到的场景:

1. 我的应用程序嵌入了 Camel。例如，如果我的应用程序必须调用 Web 服务，我只需对其进行编码并发送(From(...).to(...) 等)

2. 我的应用程序和另一个嵌入了 Camel 的应用程序。如果我的应用程序必须调用 Web 服务，并且我想通过 Camel 管理所有集成，我想我有要调用 camel 项目(通过 JMS，或调用它公开的接口(interface))，请在该项目中定义一个路由，该路由表示:当我从 X(调用的接口(interface))读取时调用此 WS。我的意思是，当我认为不需要时，它会增加更多的复杂性。

可能我误解了 Camel 的真正工作原理，所以我很高兴听到我错在哪里；)

Answer 1

Camel 的最佳架构？这取决于您的需要。您似乎有多个应用程序需要相互集成。因此，对于需要与另一个应用程序集成的每个应用程序，都会有一个集成路径。

让我们扩展一下。

假设我们有两个应用程序，一个是客户管理应用程序，一个是订单管理应用程序。这两者必须相互融合。从概念上讲，您需要创建和维护的应用程序有两条路线。

对于这种让应用程序相互集成的简单集成，在应用程序本身(嵌入式模式)中使用 Camel /骡子是有意义的。集成量是最小的。

由于这两个应用程序现在通过集成路由本身紧密耦合，因此客户应用程序中的更改可能会导致订单应用程序中的更改。然而，由于系统很小，所以这是最少量的工作。

但是，如果涉及更多系统，这种方法将成为维护噩梦。让我们稍微提高一下复杂性。

让我们进入四个系统。需要相互集成的客户、订单、会计和运输系统。只需再添加两个系统进行集成，您的路线总数就会达到 12 条。我们将系统数量翻了一番，但我们将路由数量增加了 6 倍。也就是说，可能出错的地方增加了 600%。

使用 ESB 将大大简化此设计。希望你多了解一点。

注意:使用 camel 仅从应用程序调用 Web 服务是矫枉过正的。而是使用更适合此的 Apache CXF 来执行此操作。