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

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 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

camel