perl大骆驼和小骆驼_快速的骆驼和云消息传递

perl大骆驼和小骆驼

Apache Camel是一个流行的，成熟的开源集成库。 它实现了企业集成模式 ，这是在集成分布式系统时经常出现的一组模式。 过去，我写过很多关于Camel的文章， 包括为什么我比Spring Integration更喜欢它 ， 路由引擎 如何 工作 ， 如何在AWS SQS中使用JMS选择器， 等等 。

Camel还实现了197个连接器/适配器，用于与外部系统进行对话（转到源代码，components /目录并运行此命令：ls -lp components / | grep / | wc -l）， github还有很多 ，您可以编写你自己很琐碎。 与其他集成库相比，这为Camel提供了更广泛的连接选项。

最近，我很幸运能够帮助使用Camel的一家知名的顶级电子零售商。 他们接受在线订单，并使用事件驱动的体系结构处理它们，其中包括发布事件，例如“ order_received”，“ order_cancelled”，“ order_ready_to_ship”等。 这些事件由有兴趣参与订单处理流程的微服务来处理，并且由于存在适当的EDA而被松散耦合。

这种类型的零售业务的性质是非常季节性的。 在一年中的某些时段（节假日等），负载往往会增加几个数量级。 因此，能够在不中断的情况下进行扩展以满足这些季节性高峰至关重要。

幸运的是，由于他们是一群聪明人，他们使用Apache Camel进行集成，尤其是其中某些服务的实现。 每个订单都会生成很多事件，因此必须及时处理它们，并保持其余的负载。 为此的排队服务是Amazon SQS，而Camel为此提供了一个AWS SQS组件 。

对于标称负载，骆驼可以很好地处理这些事件。 但是当队列变深时，骆驼在跟上时遇到了一些麻烦。 每分钟只收到200条消息，这没有通过气味测试。 深入研究发现，AWS库使您可以垂直扩展规模， 从而增加连接数并按批处理消息传递方式 （最多10条批处理消息）。 批处理很有帮助，实现了Camel来处理批处理，但是它仍然不够快，每小时仅发送约1万条消息。

进一步挖掘后，我们可以看到只有一个线程正在处理消息队列的轮询。 因此，我们决定使用SEDA队列 ，而不是与轮询队列的线程内联处理消息，以便我们可以从SQS中提取消息并快速转储到内存队列中，这样就可以启动下一个轮询：

from("amazon-sqs://order.queue").to("seda:incomingOrders");

from("seda:incomingOrders").process(do our processing in another thread...);

这使我们能够使用暂存事件驱动的架构模式来处理负载。 这一变化使我们的性能再次提高到每小时约4万条消息，但是我们谈论的是一个非常受欢迎的商务站点，因此仍然不足以进行扩展以满足高峰期系统的需求。

因此，我们又看了一遍，想知道为什么不能同时进行多个线程/连接轮询？ AWS库是考虑到这一点编写的，但是没有一种方法可以配置Camel以针对这种特定类型的终端节点执行此操作。 Camel可以对其他端点（JMS，SEDA等）执行此操作，但是为此我们需要在Camel SQS中进行一些小的更改。

这就是使用开源，社区风格的开发理念的美妙之处：代码是开放的，社区欢迎变化，现在Camel及其功能的未来用户可以从这种协作中受益。

因此，我们犯了一个补丁 ，允许您设置的SQS队列concurrentConsumers选项，将斜升用于连接和查询队列的线程数。 像这样：

from("amazon-sqs://order.queue?concurrentConsumers=50").to(.... processing here....)

有关更多信息，请参见camel-sqs上的文档 。 此更改将是Apache Camel 2.15.0发行版的一部分，该发行版将在接下来的几周内发布。

通过此设置，我们能够处理黑色星期五和网络星期一可能在站点上引发的所有负载，一次处理每小时> 150万条消息。

谢谢开源！

翻译自: https://www.javacodegeeks.com/2015/02/very-fast-camels-and-cloud-messaging.html

perl大骆驼和小骆驼