面料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控制臺，用于管理您的配置文件，部署，代理，服務等。在出現問題時，Camel路由以及調試和跟蹤功能甚至都具有豐富的可視化。

發現

對于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的強化，已經對某些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

總結

以上是生活随笔為你收集整理的Meet Fabric8：基于Camel和ActiveMQ的开源集成平台的全部內容，希望文章能夠幫你解決所遇到的問題。

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