1

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

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

这些是我所看到的场景：

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

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

可能我误解了骆驼的真正工作原理，所以我很高兴听到我错了什么；）

4

1 回答 1

3

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

让我们稍微扩展一下。

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

两应用集成

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

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

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

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

在此处输入图像描述

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

注意： 使用 camel 从应用程序中调用 Web 服务是多余的。而是使用更适合此的 Apache CXF 执行此操作。

于 2014-06-12T23:43:42.707 回答