在知道微服務架構被稱為之前，我一直在使用它們。 我曾經使用過由隔離模塊組成的管道應用程序，這些模塊通過隊列相互交互。 從那時起，許多（前）ThoughtWorks專家討論了微服務。 首先是 Fred George， 然后是 James Lewis，最后是Martin Fowler， 寫了關于微服務的博客 ，這使它成為下一個流行語，因此每個公司都希望很少有微服務。 如今有＃主題標簽，認可，喜歡，培訓，甚至是為期2天的會議 。 我讀和聽有關微服務架構的內容越多，我就越了解Apache Camel（及其周圍的相關項目）如何完全適合這種應用程序樣式。 在本文中，我們將了解Apache Camel框架如何幫助我們輕松地用Java創建微服務風格的應用程序。

微服務特征

微服務中沒有什么新東西。 如此長時間以來，已經設計并實現了許多應用程序。 微服務只是一個新術語，描述了具有某些特征并遵循某些原則的軟件系統樣式。 它是一種體系結構樣式，其中應用程序或軟件系統由單獨的獨立服務組成，這些獨立服務使用輕量級協議以基于事件的方式進行通信。 與TDD可以幫助我們創建分離的單一職責類一樣，微服務原理也可以指導我們在系統級別創建簡單的應用程序。 在這里，我們不會討論這種架構的原理和特性，也不會爭論它是在實踐中實現SOA的方式還是在應用程序設計中采用全新的方法，而是探討用于實現微服務的最常見實踐以及Apache Camel如何實現幫助我們在實踐中實現目標。 還沒有確切的列表，但是如果您閱讀或觀看上面發布的視頻，您會發現以下是創建微服務的非常常見的做法：

體積小。 微服務的最基本原理說，每個應用程序都很小，并且只做一件事并且做得很好。 大小是可以爭論的，數字從10 LOC到1000不等，但從我的角度來看，我喜歡這樣的想法：它應該足夠小以適合您的頭部。 有些人腦袋大，所以即使是有爭議的，但是我認為只要應用程序做一件事情并且做得很好，就不會被認為是nanoservices ，這是一個不錯的選擇。
駱駝應用本來就很小。 帶有錯誤處理和輔助bean路徑的駱駝上下文大約為100 LOC。 借助Camel DSL和URI提取端點的能力，可以通過HTTP或JMS接收事件，將其編組，持久化并發送回一個響應，大約為50 LOC。 它足夠小，可以端到端進行測試，重寫甚至扔掉而不會感到re悔。

有交易界限。 由多個微服務組成的應用程序構成了一個最終一致的系統系統，其中在任何給定時間都不知道整個系統的狀態。 這本身給不習慣使用這種分布式應用程序的團隊提供了理解和采用微服務的障礙。 即使整個系統的狀態不是固定的，具有定義消息當前所屬位置的事務邊界也很重要。
確保跨異構系統的交易行為并非易事，但Camel具有強大的交易能力。 Camel的端點可以參與事務，事務處理的路線和錯誤處理程序，冪等的使用者和補償行為，所有這些都可以幫助開發人員輕松創建具有事務行為的服務。

自我監控 。 這是我最喜歡的微服務領域之一。 服務應公開描述其所依賴的各種資源的狀態以及服務本身的信息。 這些是統計信息，例如處理消息的平均，最小，最大時間，成功和失敗消息的數量，能夠跟蹤消息等。
有了Camel，您就可以輕松獲得OOTB。 默認情況下，每個Camel應用程序都會收集整個應用程序，單個路由，端點等的JMX統計信息。它將告訴您成功完成了多少消息，失敗了多少，失敗的地方等等。這不是只讀的API，JMX允許還可以在運行時更新和調整應用程序，因此基于這些統計信息，您可以使用相同的API來調整應用程序。 還可以使用jConsole，VisualVM，Hyperic HQ等工具訪問信息，這些信息可以使用Jolokia通過HTTP公開，也可以輸入到名為hawtio的出色Web UI中。

如果OOTB可用的功能不符合您的自定義要求，則存在多個擴展點，例如nagios，jmx，amazon cloudwatch和新的指標組件，或者將事件通知程序用于自定義事件。
登錄消息傳遞應用程序是另一個挑戰，但是Camel的MDC日志記錄與吞吐量記錄器相結合，可以輕松地跟蹤單個消息或獲取聚合統計信息作為日志記錄輸出的一部分。

專為故障而設計 –每個微服務可能會停機或在一段時間內無響應，但這不會導致整個系統停機。 因此，微服務應具有容錯能力，并能夠在可能的情況下恢復。
駱駝也有很多有用的工具和模式來應對這些情況。 死信通道可以確保在失敗的情況下不會丟失消息，重試策略可以使用自定義退避方法和避免沖突功能，針對某些錯誤情況重試發送消息兩次。 支持各種模式的負載均衡器， 斷路器 ，故障轉移和其他策略，限制某些端點不會過載的Throttler，Detour，Sampler等模式在各種故障場景中都需要。 因此，為什么不使用它們而不是在每次服務中重新發明輪子。

高度可配置–應該很容易配置同一應用程序以實現高可用性，對其進行擴展以提高可靠性或吞吐量，或者換句話說：通過配置具有不同的自由度。
使用DSL創建Camel應用程序時，我們要做的就是定義消息流并配置各種端點和應用程序的其他特征。 因此，駱駝應用程序可以通過設計進行高度配置。 使用屬性組件將所有各種選項外部化后，就可以為應用程序配置不同的期望值并重新部署，而完全不必動用實際的源代碼。 Camel的可配置性很強，您可以更改另一個端點（例如，用JMS替換HTTP端點），而無需更改我們接下來將介紹的應用程序代碼。

使用智能端點。 微服務而不是Web服務更喜歡RESTish協議和輕量級消息傳遞。
駱駝偏愛任何東西。 它具有HTTP支持，沒有其他框架。 它具有異步Http，GAE URL提取服務，Apache HTTP客戶端，Jetty，Netty，Servlet，Restlet，CXF的組件以及用于序列化/反序列化消息的多種數據格式 。 另外，最近添加的Rest DSL使REST在Camel世界中成為頭等公民，并且只需創建很多這樣的服務即可。 至于排隊支持，OOTB有用于JMS，ActiveMQ，ZeroMQ，Amazon SQS，Amazon SNS，AMQP，Kestrel，Kafka，Stomp的連接器。

可測試的。 關于此特性沒有共識。 有些人根本不支持測試，而是依賴于業務指標。 有些根本無法承擔糟糕的業務指標。 我喜歡TDD，對我來說，能夠獨立于實際消息流測試我的業務POJO，然后通過模擬某些外部端點來分別測試該流是非常寶貴的。 駱駝測試支持可以攔截和模擬端點，模擬事件，輕松驗證期望。 擁有經過良好測試的微服務以實現預期的行為是使整個系統按預期運行的唯一保證。

單獨配置。 微服務的最重要特征是它們與其他服務（作為獨立Java應用程序）隔離運行。 駱駝可以嵌入到Spring，OSGI或Web容器中。 Camel還可以輕松地作為具有嵌入式Jetty端點的獨立Java應用程序運行。 但是，要管理多個流程，所有這些流程都在沒有集中式工具的情況下隔離運行，是一項艱巨的工作。 這就是Fabric8的用途。 Fabric8是由開發Camel的人開發的，并得到Red Hat JBoss的支持。 它是一個多Java應用程序供應和管理工具，可以部署和管理各種Java容器和獨立進程。 要了解有關Fabric8的更多信息， 這是 Christian Posta的精彩文章。

語言中立。 具有小型且獨立部署的應用程序使開發人員可以為給定任務選擇最合適的語言。 Camel具有XML，Java，Scala，Groovy和其他具有類似語法和功能的DSL，但是如果您不想完全將Camel用于特定的微服務，則仍然可以使用Fabric8來部署和管理以其他語言并將它們作為本機進程運行。

總結：微服務沒有嚴格定義，這就是美。 這是一種實現SOA的輕量級樣式。 Apache Camel也是如此。 它不是功能齊全的ESB，但可以作為JBoss Fuse的一部分。 它不是嚴格定義的規范驅動的項目，而是可以工作并且開發人員喜歡它的輕量級工具。

引用

弗雷德·喬治（Fred George）的微服務架構 （視頻）

微服務– Java， James Lewis 的UNIX方式

微服務由Martin Fowler

μ服務由Peter Kriens提供

詹姆斯·斯特拉坎（James Strachan）的Fabric8提供微服務的簡便方法 （帶視頻）

紅帽的Fabric8

Meet Fabric8： Christian Posta 的開源集成平臺

James Strachan的Fabric8通過Micro Services輕松實現

翻譯自: https://www.javacodegeeks.com/2014/09/apache-camel-for-micro-service-architectures.html

總結

以上是生活随笔為你收集整理的适用于微服务架构的Apache Camel的全部內容，希望文章能夠幫你解決所遇到的問題。

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