作为一名经验丰富的 Spring 用户,我认为 Spring Integration 在最近需要一些(JMS)消息传递功能的项目中最有意义(更多细节)。使用 Spring Integration 几天后,考虑到必须配置的通道数量来实现一些请求-响应(侦听不同的 JMS 队列)通信,仍然感觉配置开销很大。

因此,我一直在寻找一些背景信息,Camel 与 Spring Integration 有何不同,但似乎那里的信息相当多余,我发现:

问题是:您在使用其中一种堆栈而不是另一种堆栈时获得了哪些经验?如果 Spring Integration 缺乏支持,您会在哪些场景下推荐 Camel?您在哪里看到每个的优点和缺点?任何来自实际项目的建议都将受到高度赞赏。

有帮助吗?

解决方案

我们选择 Camel 而不是 Spring-Integration,因为流畅的 API 非常好。我们实际在Spring项目中使用它,并使用Spring来配置一部分。编程 API 很清晰,并且有大量合理的组件。

我们进行了一场小规模的枪战,基本上当时我们的要求是骆驼赢了。我们主要使用它来将内部数据文件传输到外部各方或从外部各方传输内部数据文件,这通常需要使用 ftp/sftp/... 进行格式转换。或将其附加到电子邮件中并发送出去。

我们发现编辑-编译-调试周期缩短了。使用 groovy 来尝试设置路线还有额外的好处。

Spring-Integration也是一个很棒的产品,我确信它也能满足我们的需求。

其他提示

如果您已经有了一个 Spring 项目,并且只需使用文件、FTP、JMS、JDBC 等添加一些“基本”集成,我只推荐 Spring Integration。

Apache Camel 有两个主要优点:

  1. 支持很多很多的技术。
  2. 此外,还有一个(好的)XML DSL,还有适用于 Java、Groovy 和 Scala 的流畅 API。

因为 Apache Camel 与 Spring 的集成非常好,所以我什至会在大多数 Spring 项目中使用它来代替 Spring Integration。

如果您需要更多详细信息,可以在我的博客文章中阅读我的经验: 多种选择:使用哪种集成框架 – Spring Integration、Mule ESB 还是 Apache Camel?

我最近进行了 Camel 与 Spring 集成的竞赛,目的是集成 阿帕奇·卡夫卡. 。尽管我是一名狂热的 Spring 开发人员,但我遗憾地发现我对 Spring 不断增长的项目堆栈的怀疑得到了证实: Spring 作为 IOC 容器非常棒,可以作为其他框架的粘合剂,但它未能提供可行的替代方案 那些框架. 。可能会有例外,即与 MVC 相关的一切,Spring 的由来和它的出色工作,但其他在容器功能之上提供新功能的尝试都达不到要求。 三个原因SI 卡夫卡用例 确认了所有这些:

  • 引入了冗长且难以使用的用于 XML 配置的 DSL。
  • 用于连接所有框架组件的 xml 配置代码页面。
  • 缺少提供与专用框架同等功能的资源。

现在,回到我的点球大战的结果:最重要的是,Camels的整体概念给我留下了深刻的印象 端点之间的路由. 。Kafka 与这个概念无缝集成,三行配置足以让一切启动并运行。过程中遇到的问题都一一解决 项目团队提供的充足文档 以及 Stackoverflow 上的很多问题。最后但并非最不重要的一点是,有一个 全面融入Spring 一切愿望都能实现。

与 SI 相反,Kafka 集成的文档是 相当激烈 并且仍然没有解释清楚如何集成Kafka。Kafka的集成是 按下 融入 SI 做事方式,这增加了额外的复杂性。其他文档,例如Stackoverflow 上的内容也不如 Camel 丰富,帮助也较小。

我的结论:cobbler 坚持你的行业——使用 Spring 作为容器,使用 Camel 作为系统集成框架。

我真的取决于你想做什么。如果您需要扩展某些内容来构建自己的消息传递解决方案,Spring Integration 具有更好的编程模型。如果您需要无需自定义代码即可支持多种协议的东西,Camel 优于 Spring Integration。

进行小规模的枪战是一个非常好的主意,只要确保你正在尝试做你通常在项目中做的事情。

--免责声明:我是 Spring Integration 提交者

我见过的大多数 Camel 和 SI 的比较都没有考虑以下因素:

1.) Spring Boot 对 Spring Integration 开发人员生产力的影响

2.) Spring XD 的作用是使 Spring Integration 应用程序无需代码编译即可使用 - 当您希望扩展 Spring XD 时,Spring XD 源和接收器也只是 Spring Integration 通道适配器。

3.) Spring XD 的作用是将 Spring Integration、Spring Batch、Spring Data (+Hadoop!) 统一在一个堆栈中,有效地为 Spring Integration 带来批处理和流处理、HDFS/Apache Hadoop 支持等。

4.) 即将发布的 Spring Integration 4.0 Java DSL 的效果 https://github.com/spring-projects/spring-integration-extensions/wiki/Spring-Integration-Java-DSL-Reference

供您考虑,

/Pieter(免责声明,我在 Pivotal 工作)

我们正在为我们的应用程序使用 Spring Integration,现在考虑迁移到 Apache Camel,因为我们在使用 Spring Integration 框架时遇到了很多问题。这里有几个问题。

  1. Spring 提供的 CachingConnectionFactory 在 IBM MQ 中打开了 1000 个空闲连接,并且不能保证这些连接会被重用。而且这些连接仍然会永远保持打开状态,这会给 MQ 端带来麻烦。必须每周在较低环境中重新启动应用程序才能刷新连接。Apache Camel 还提供缓存,并且连接似乎会根据负载而增加/减少。

  2. Spring 不提供 QoS 参数的映射器。即使启用 QoS,交付模式和过期/生存时间属性也会丢失(我将为此提出 JIRA 问题)。Apache Camel 处理此问题,并将 QoS 参数发送到上游应用程序,并且不会丢弃它。

我现在正在研究使用 Apache Camel 处理异常和事务的问题,而 Spring 似乎可以通过 AOP 更好地处理这些问题。

事实上,我想说FTP的潜伏期已经结束了。您可以在 SI 论坛/JIRA 上进行简单搜索,看看实现了哪些新功能以及修复了哪些错误。从各种讨论来看,它似乎已经有一些生产用途,所以我建议再看一下,当然也可以通过以下方式向我们传达您的担忧

http://forum.springsource.org/forumdisplay.php?42-集成
https://jira.springsource.org/browse/INT

欢呼

免责声明:我是 Spring Integration 提交者

Apache Camel 是一个非常好的框架,也非常完整。但如果你的应用程序使用Spring,我个人的建议是使用Spring Integration。

Spring Integration是Spring-Source生态系统的集成EIP投诉框架。它与生态系统具有良好的集成性:Spring boot,批量,XD;从 Spring Framework 4 开始,甚至核心也使用相同的抽象。框架中移动了一些消息抽象,这证明了 Spring Integration 的基本消息抽象非常强大。现在,Spring 框架使用 Spring Web 的消息抽象、Web 套接字支持。

在使用 Spring 集成的 Spring 应用程序中使用 Apache Camel 的另一件好事是,通过 Spring 集成,您只能使用一个应用程序上下文。请记住,Camel 上下文是 Spring 上下文。如果您有机会使用新的 Spring 版本,我建议使用 Spring Integration Java DSL 进行配置。我在我的新项目中使用它,感觉更具可读性和清晰性。我希望这篇反思能够对您的评估有所帮助。

使用 Camel 而不是 Spring Integration 的原因之一是当您需要功能更强大的 EIP 集时。Spring Integration 不提供对 ThreadPool 等事物的抽象。

Camel 确实提供了额外的构造来简化使用并发代码的一些方面:

http://camel.apache.org/camel-23-threadpool-configuration.html

如果您不需要此类东西而只想连接文件、JMS、FTP 端点等...然后只需使用Spring Integration。

Camel 充当应用程序的中间件,可以在其中执行数据建模、消息值转换和消息编排。

如果您当前的应用程序位于 Spring 中并且需要 EIP 的 Spring Integration 支持的功能,那么 Spring Integration 是最佳选择,否则需要更多第三方支持/协议/文件格式等

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top