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組件 。

對于標稱負載，Camel可以很好地處理這些事件。 但是當隊列變得更深時，駱駝在跟上時遇到了一些麻煩。 每分鐘僅收到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

總結

以上是生活随笔為你收集整理的快速的骆驼和云消息传递的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。