9

我正试图围绕 Apache Camel，它似乎是一个轻量级 ESB。如果我正确理解 Camel/ESB，那么您可以将 Camel Route 视为节点和边的图。每个节点都是路由上的一个端点（可以消费/产生消息）。每条边都是两个不同端点（1 个生产者和 1 个消费者）之间的路由。

假设这是正确的，我有一个实际问题：最佳实践对部署应用程序的 ESB/Camel Route 有什么要求？我应该将它打包为自己的 JAR，还是值得成为自己的 EAR，里面装满了 EJB、Web 服务和其他 JAR？

我想我在问应该如何部署/构建 Camel Route 或 ESB，例如：

my-esb.ear/
    ejb1.jar/
        MyEJB_1.class
    ejb2.jar/
        MyEJB_2.class
    webservice.war/
        MyWebService.class

或者...

my-esb.jar/
    MyEJB_1.class
    MyEJB_2.class
    MyWebService.class
4

5 回答 5

7

据我了解，有几种方法可以运行 Camel。

  1. 嵌入到 Java 应用程序中：您可以将 Camel 嵌入到独立的 Java 应用程序中。在这种情况下，您将在您的应用程序中启动一个 Camel 上下文，它将启动路由等。当您的应用程序需要与服务等进行通信时，这非常有用。为此，您需要为组件部署 Camel 和第三方 jars类路径。

  2. 嵌入 Web 应用程序：正如人们已经指出的那样，这似乎是一种流行的选择。Camel jars 和第三方 jars 被包装在一个 WAR 文件中，并且基本上部署到一个 Web 容器（例如 Tomcat）来托管 Camel 服务。

  3. 嵌入应用程序服务器：我读过一些关于如何将 Camel 部署到 JBoss 等应用程序服务器的文章，我什至读过有关部署到 Glassfish 的人的文章。这似乎与您部署到 Tomcat 的方式非常相似。JBoss 有一些你需要解决的类加载问题，这使得它变得棘手。所以是的，您可以通过 WAR 路由部署到应用程序服务器。

  4. 部署到 OSGi：您可以相对快速地将 Camel jar 制作成 OSGi 包，然后部署到 OSGi 框架，例如 Apache Felix。将 jar 转换为适当的 OSGi 包然后部署相对简单。这里的一个大问题是某些第三方可能没有 OSGi 兼容的捆绑包供您部署。

我个人的偏好是 OSGi 路线。它既简单又轻量，允许我将我的骆驼路由托管为持久服务（即 Window 服务、Unix Deamon），占用空间非常小。

您现在应该意识到 Apache Camel 可以通过多种方式进行部署，您可以自行决定如何进行部署。我花了一段时间才了解如何部署 Camel，因为我必须使用不同的部署模型才能对它有一个好的感觉。我唯一没有接触过的是部署到应用服务器，因为我觉得这些服务器中的大多数都足够重了。

就架构而言，我喜欢将不同的路由/应用程序保存在不同的 jar 中。由于我使用的是 OSGi，因此我希望能够更新特定路由并进行部署，而无需重新部署所有内容。如果您将所有内容部署在一个 jar 中，您将需要重新构建世界并重新部署该 jar。但是，这是个人喜好，您的里程可能会有所不同

希望这个对你有帮助。

于 2012-06-22T07:23:39.510 回答
4

让我一一回答您的问题：

提供一个描述性的、非模糊的一般因素列表，应用于确定如何最好地部署 ESB（作为单个 EAR，每个端点都是嵌入式 JAR 或作为单个“整体”JAR）；

嵌入式或单体 jar 无关紧要。重要的是捆绑或战争部署。在独立包的情况下，您最终可能会得到一个非常胖的部署存档，其中包含大量用于依赖解析的 jar。

充分解释为什么 Camel 不能很好地与 JBoss 或 GlassFish 等 Java EE 应用服务器配合使用

  1. App-Server/Container 的线程/资源/端口管理可能会施加限制。

  2. 常用库版本冲突

  3. ClassLoading 机制冲突

从逻辑上讲，如果您的容器支持 OSGi，那么 Camel 应该不会遇到任何问题。

  1. 由于 Apache Camel 是一个非常轻量级的消息路由器，因此您绝对可以将它与您的 Web 应用程序一起打包为一个war文件。如果您使用 maven/Ivy 并且您的 Web 容器支持 osgi，那么 Bingo！生活会轻松很多。
  2. 第二种选择是将您的应用程序部署为捆绑包
  3. 另一个是独立的 Java SE jar。

按照下面的链接[虽然，已经过时了]，这些将为您提供有关包装的逐步指导，至少对包装机制有清晰的认识：

骆驼一步一步

Web 应用程序中的骆驼

OSGi 环境中的 Camel Real Life 打包和部署

于 2012-06-25T18:19:00.747 回答
1

与其他答案一样，这取决于您的需求，但 ESB 通常是不同集成过程的组合，它们不一定共享相同的生命周期。

如果您遇到这种情况，我建议您使用jar按集成流程的方法。这样，您可以为每个不同jar的开发生命周期提供不同的开发生命周期，并且您可以向您的客户保证，除了其中的代码之外，您没有接触过任何代码jar。

这并不意味着您必须采用ear解决方案。您可以将不同进程的代码完美地打包在一个war文件中，而不会产生ear开销。

于 2012-06-21T16:28:19.583 回答
0

这取决于您的需求。没有比这更好的真理答案了。

Camel 可以适应您现有的基础架构和运行时平台。因此，使用 Camel 嵌入您的应用程序，以该平台可以执行的方式以及您想要的方式进行打包。

例如，要在 Web 应用程序 (WAR) 中使用 Camel，您可以查看此链接：http ://camel.apache.org/tutorial-on-using-camel-in-a-web-application.html

于 2012-06-19T03:48:13.257 回答
0

你正在考虑.ear嵌入，我明白了。

我建议您在将 Camel 嵌入到功能齐全的 Java EE 服务器中时三思而后行。这当然是可行的，但是您将需要做一些工作来连接它们（使用 commonJ、WorkManagers、JNDI 引用等）。具体来说，让 Camel 处理线程是一大优势。

将 Camel 嵌入 spring web-app (.WAR) 我个人最喜欢在 Jetty 或 Tomcat 中部署。然后你可以访问一个像样的 servlet 容器，一个可以做一些事情的运行时，等等。

实际上，我在一些带有嵌入式 Camel 的生产环境中使用了 ActiveMQ 的标准下载，更多的是用于适配器目的，而不是 ESB，但是，如果 ActiveMQ 是您的 ESB 的消息传递主干，它可能是一个有效的选择。

于 2012-06-19T20:45:28.437 回答