Meet Fabric8：基于Camel和ActiveMQ的开源集成平台

面料8

Fabric8是Red Hat的JBoss Fuse产品的Apache 2.0许可上游社区。

这是一个基于Apache ActiveMQ ， Camel ， CXF ， Karaf ， HawtIO等的集成平台。

它提供了自动化的配置和部署管理，以帮助使部署变得容易，可重复且不易发生人为错误。

JBoss Fuse（v6.1 ）的最新GA版本最近发布，并且基于Fabric8的v1.0 ：
fabric8_logo

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社区中进行了相当长时间的讨论：