0

我参与了使用 Spring Cloud 和 Apache Camel 的服务设计。今天,当一位同事问(也许提倡会是一个更好的词)我们是否真的需要 Apache Camel 时,我吃了一惊。在他看来,我们讨论的大多数下游系统都是基于 REST 的,因此不需要集成框架。如果我没记错的话,他还暗示微服务和集成框架不兼容。

我开始热情地建议 Spring Cloud 帮助解决部署/操作问题,而集成框架解决集成问题并且它们具有正交要求。

以下是系统将用于通信的一些协议:

REST
SOAP
AMQP
Azure SDK
AWS SDK (S3, SimpleBD, etc.)
Dropbox SDK
Paypal SDK
Braintree SDK
Caching (Memcached, EhCache)
Async (VM, Direct-VM, SEDA, SEDA-VM)
Facebook
Twitter
FTP
SMTP
File IO
SOLR/Elesticsearch
Quartz

未知协议:当我们集成到客户环境中时,我们需要与他们的系统集成。通信协议尚不清楚。

Martin Fowler 和 James Lewis 的以下声明似乎表明 ESB 和微服务是不兼容的:“我们无法抗拒提及 Jim Webber 的声明,即 ESB 代表“Egregious Spaghetti Box”。现在,您认为该声明在多大程度上适用于像 Apache Camel 这样的集成框架?

更一般地说,我的同事有意见吗?这是否意味着集成模式在微服务中没有位置?

4

1 回答 1

2

Apache Camel 并不是真正的 ESB(除非您希望它是),而是一种以面向消息的方式连接“东西”的语言/框架。

如果你觉得你可以使用简洁的语法和灵活的瑞士军刀来连接你的微服务中的“东西”,当然 - 使用 Apache Camel。如果您宁愿以其他方式解决集成代码,请这样做。

于 2014-10-08T07:28:55.377 回答