java8 camel
面料8
Fabric8是來自Red Hat的JBoss Fuse産品的Apache 2.0許可上遊社群。
這是一個基于Apache ActiveMQ ， Camel ， CXF ， Karaf ， HawtIO等的內建平台。
它提供了自動化的配置和部署管理，以幫助使部署變得容易，可重複且不易發生人為錯誤。
JBoss Fuse（v6.1 ）的最新GA版本是最近釋出的，并且基于Fabric8的v1.0 ：
Fabric8統一并打包了這些開源項目，以幫助您建立系統之間的內建，并解決非功能性需求，例如管理您的部署，服務發現，故障轉移，負載平衡，集中式配置，自動化等等！ 它還為在諸如PaaS上的雲部署提供了一條清晰的道路 。最好的部分是，已經使用過Camel或ActiveMQ的人們對此很熟悉，它們分别是最受歡迎的開源內建庫和消息傳遞平台。
您可以從社群文檔中擷取更多資訊， 在freenode上的IRC上與開發人員聊天 ，以及在google-groups上的郵件清單 。
太好了，Fabric8給我什麼呢？
Fabric8提供了很多功能……但是，我想在這篇部落格文章中提到幾個關鍵功能，如果您直接使用組成項目，那麼您必須自己建構這些功能：
* Automated deployment and provisioning
* Polycontainer support
* Centralized management
* Service discovery
* Load balancing
* High availability
* Master/slave failover coordination
使用Fabric8，您可以建構內建塊，對其進行部署和管理（共同建立一個“結構”），其中節點代表具有已配置軟體（部署）的容器，并且已注冊端點（HTTP，MQ，SOAP / REST）在存儲庫中進行動态查找。
DevOpsy的故事
考慮一下您目前的建構和釋出過程是什麼樣的……
對于Java商店，您可能有Maven來建構源代碼， Subversion或git來提供圍繞源代碼的版本控制和更改管理，也許還有Jenkins來管理您的建構，對嗎？ 對于Java開發人員來說，這是一套非常強大的工具。
但是，無論它們的功能如何，建構和釋出過程都不僅僅是使用一些工具。
将您的代碼投入生産需要在操作方面進行很多開發工作，開發人員可能不了解或根本不了解。 您的代碼在哪些容器中運作？ 什麼作業系統？ 需要什麼樣的支援軟體？ 這些環境是否經過精心設計和手動配置，且易更改的龐然大物容器因運作于哪個環境（DEV / QA / UAT / PROD等）而異？
成功的IT部門采用DevOps運動及其通信和自動化原理，以建立易于編寫腳本/自動化，可複制的環境，并盡可能減少人工和手動配置。
開發人員會根據代碼和應用伺服器進行思考。
操作人員可能會在管理VM，伺服器，OS，網絡等方面進行思考。
但其中存在差距。 開發人員必須使用哪些工具來自動化部署容器，供應其應用程式，配置這些應用程式以及從中央位置可視化/管理該容器？
運維人員熟悉Puppet / Chef / Ansible / MCollective / capistrano …并将這些工具與Fabric8配合使用将為您提供非常強大的自動化和配置管理堆棧，以幫助您實作一緻且可複制的生産部署以實施持續傳遞模型。
那麼，Fabric8增加了什麼價值？
容器間的一緻性
使用可跨Java容器（ Karaf ， Tomcat ， Wildfly ， TomEE ），微服務架構（ Dropwizard ， Spring Boot ， Vert.x ）和純Java Main（PJJM）工作的Profiles配置部署的一緻方式。基于應用程式。
可視化
一個基于HawtIO的統一Web控制台，用于管理您的配置檔案，部署，代理，服務等。在出現問題時，甚至可以為您的駱駝路線以及調試和跟蹤提供豐富的可視化效果。
發現
對于Fabric内的所有部署，Fabric8不僅可以管理它們，還可以将它們注冊到運作時系統資料庫中，用戶端可以使用該系統資料庫自動找到所需的一組HTTP端點（SOAP / REST等）或MQ服務（經紀人，主/從對，經紀人網絡等）。 此外，外部用戶端還可以使用系統資料庫來發現服務。
對您正在運作的服務的深刻了解
盡管上面提到的熟悉的Ops工具非常适合将軟體放入多台機器的磁盤上，但它們不能充分了解運作的服務。 例如，使用Fabric8的Camel插件，您可以跟蹤完成的交換次數，失敗的次數，端點完成交換所花費的時間等。使用ActiveMQ插件，您可以可視化隊列/生産者/消費者，發送消息發送到隊列，從DLQ移動消息，等等。此外，ElasticSearch / Kibana有一些插件，可以更深入地了解您的代碼/駱駝路線所實作的業務/內建。
熟識
Fabric8使用Java開發人員編寫分布式內建服務或應用程式已經熟悉的工具。 例如，所有配置（配置檔案）都存儲在git中。 供應機制使用Maven。 協調服務使用[Apache Zookeeper] [zk]等。
管理雲中或跨混合雲的部署
Fabric8内置了對開箱即用的IaaS或PaaS部署和供應的支援。 甚至還提供了基于Docker的容器的支援，您可以在任何環境中進行運輸和使用！
那ServiceMix呢？
ServiceMix還是基于Apache Camel和ActiveMQ的開源ESB。 那麼這與Fabric8有什麼關系呢？
ServiceMix是目前JBoss Fuse / Fabric8的起源。 它始于9年前，是基于Java業務內建規範的EnterpriseServiceBus（ESB）的實作。 它的目标是提供一個具有标準化消息傳遞主幹的可插拔元件體系結構，該主幹将遵循标準接口和規範的XML資料格式。 盡管JBI是一個過于禮貌的規範（很多XML描述符，打包需求等），但ServiceMix還是廣受歡迎。 但是，盡管大多數産品/項目都以大型，複雜的容器形式提供內建服務，但在該複雜的“ ESB”環境之外也需要進行路由，轉換，與外部系統內建等需求！
在SMX 3.x和4.x的時間範圍内，該項目進行了一些重大的重構。 通過路由/中介DSL剝離并簡化了JBI實施，該DSL /後來成為Apache Camel 。 這樣，“ ESB”的“心髒”可用于其他項目（ActiveMQ，獨立等）中。 此外，核心容器也從JBI轉向OSGi。 再後來，實際的OSGi容器被重構為自己的項目，現在稱為Karaf 。 是以，ServiceMix不再是自己的項目，而是其他項目的打包，例如ActiveMQ，Karaf（曾經是SMX的核心）和Camel（曾經是SMX的核心）。 JBoss Fuse（Fuse ESB / Fuse Enterprise）的較舊版本基本上是對SMX的強化，而SMX的強化已經是對某些Apache項目的重新包裝。 此外，許多從事SMX工作的核心開發人員也緻力于為組成部分做出貢獻，而不一定是核心SMX。
Fabric8秉承ServiceMix的“ ESB”或“內建”精神，并添加了一個不錯的管理UI（ HawtIO ），以及我上面提到的所有DevOpsy東西，并描繪了通往大規模部署甚至遷移到雲/混合的清晰路徑雲體系結構 。
如果您想從社群中擷取更多資訊， 克勞斯·易蔔生 （ Claus Ibsen）撰寫了一篇不錯的部落格文章 。
在SMX社群中進行了相當長時間的讨論 ：
下一步
如果您使用Camel ， CXF或ActiveMQ開發系統/企業內建并部署到OSGi（ karaf ），Servlet（ Tomcat ），Java EE（ Wilfly ）或獨立運作（ Vert.x ， Spring Boot ， DropWizard ），看一下Fabric8 。
首先下載下傳最新版本，然後給我們您的回報 ！
在後續文章中，我将繼續深入介紹Fabric8的功能以及如何使用它來建構健壯的，可伸縮的內建，并為部署內建提供一緻且可複制的環境。
翻譯自: https://www.javacodegeeks.com/2014/06/meet-fabric8-an-open-source-integration-platform-based-on-camel-and-activemq.html
java8 camel