jboss fuse 教程
Torsten Mielke通过以前的FuseSource（现在由Red Hat领导的项目）介绍了一些强大的OSGi和ESB概念。
管理大量部署了数十个应用程序的ServiceMix实例并非易事，但是Red Hat的开源项目ServiceMix可以帮助降低应用程序部署的复杂性。
Apache ServiceMix是相当流行的开源ESB，最适合于Integration和SOA项目。 它提供了商业ESB所期望的所有功能，但是与大多数商业ESB相比，它的核心是真正基于开放标准和规范。
ServiceMix利用了许多非常流行的开源项目。 其出色的消息路由功能基于Apache Camel框架。 Apache Camel是一个轻量级的集成框架，它使用标准的企业集成模式（EIP）来定义使用各种特定于域的语言（DSL）的集成路由。
大多数集成项目需要可靠的消息传递基础结构。 ServiceMix通过嵌入Apache ActiveMQ消息代理来支持可靠的消息传递，该代理是最受欢迎，完全符合JMS 1.1的开源消息代理之一。 它提供了很多消息传递功能，可以扩展到数千个客户端，并支持许多群集和高可用性代理拓扑。
通过集成Apache CXF获得对Web服务和RESTful服务的支持。 CXF可能是最著名的开源Web服务框架，并且已完全集成到ServiceMix中。 CXF支持JAX-WS和JAX-RS标准以及所有主要的WS- *规范。
ServiceMix的核心是OSGi容器运行时。 OSGi框架负责加载和运行真正的动态软件模块，即所谓的OSGi捆绑软件。 OSGi捆绑包是一个普通的Java jar文件，其中包含有关jar中包含的类和资源的其他OSGi特定的元数据信息。
Service Karax中使用的OSGi运行时是Apache Karaf ，它提供了许多有趣的功能，例如热部署，运行时OSGi捆绑包的动态配置，集中式日志记录系统，通过JMX进行的远程管理以及可用于管理以下方面的可扩展外壳程序控制台： OSGi运行时。 使用Karaf可以分别管理已部署应用程序模块的所有生命周期方面。 Karaf不仅支持部署OSGi捆绑软件，而且还支持纯Java jar文件，Blueprint XML，Spring XML和war文件。 灵活的部署选项简化了将现有Java应用程序迁移到OSGi的过程。
ServiceMix在Karaf OSGi运行时之上开箱即用地部署这些开源项目。 ActiveMQ和Camel将其他Shell命令注册到Karaf Shell中，该命令可以在运行时管理嵌入式JMS代理和Camel环境。 也可以仅部署特定项目所需的那些ESB功能。 如果不需要对某些元素（例如Web服务）的支持，则可以全部卸载与CXF相关的OSGi捆绑软件。 这进一步减少了ServiceMix已经很小的运行时内存占用。 图1总结了Apache ServiceMix构建的技术和标准。
ServiceMix利用了许多非常成功的开源项目。 每个项目都基于开放标准和行业规范，旨在提供最大程度的互操作性。 所有这些方面使ServiceMix成为非常流行的ESB，并且已在当今成千上万的客户站点和许多关键任务应用程序中部署。 Red Hat（2012年收购FuseSource）和Talend等公司也提供专业的企业级支持。
保险丝面料介绍
不足为奇的是，有些公司在其IT基础架构中部署了数十甚至数百个ServiceMix实例。 较大的项目可能会产生多个ServiceMix容器，因为一个单独的JVM实例无法容纳整个应用程序。 此外，出于负载平衡的原因，同一应用程序可以部署到多个ServiceMix容器。 每个ServiceMix实例都是一个独立的OSGi容器，具有自己的OSGi运行时和一组单独的已部署应用程序。 但是，管理大量部署了数十个应用程序的ServiceMix实例变得不容易，因为ServiceMix本身不提供任何工具来集中管理多个ESB实例。
安装部署到多个独立OSGi容器的应用程序更新变得繁琐且容易出错。 必须手动登录每个OSGi容器（例如，使用ssh客户端会话），停止现有应用程序，安装并可能重新配置应用程序的新版本，最后启动新应用程序。 然后，需要在运行同一应用程序的所有其余ESB实例上重复这些步骤。 如果在升级过程中出现任何问题，则需要手动将更改还原。 这种手动方法很麻烦，而且一路上容易出错。
在这里，我们可以使用Fuse Fabric ，这是获得Apache许可的开源集成平台，该平台最初是FuseSource中的一个项目。 使用Fuse Fabric，您可以将所有ServiceMix容器实例分组为一个或几个群集，即Fabrics 。 然后，可以从中央位置管理此群集的所有实例，该位置可能是Fabric中的任何ServiceMix实例。 这既包括群集中所有ESB实例的配置，也包括将应用程序部署到每个ServiceMix容器。
Fabric用其他命令扩展了Karaf Shell，以管理OSGi容器集群，因此用户不需要使用其他工具来管理Fabric。 它还支持将应用程序部署到私有云和公共云。 使用jclouds库，支持所有主要的云提供商。 可以使用单个Karaf shell命令将应用程序部署到云中，甚至Fabric中的虚拟机也可以由Fabric启动。
Fabric还可以按需创建ESB容器。 它不仅可以在本地创建新的ESB容器（共享ServiceMix的现有安装），而且还可以在没有预安装ServiceMix的远程计算机上启动新的ESB容器。 使用ssh，Fabric能够将完整的ServiceMix安装流式传输到远程计算机，解压缩并启动该ServiceMix安装并为其提供预配置的应用程序。
为了更好地理解这些功能，让我们看一下Fabric使用的机制和概念。
面料概念
Fabric定义了两个组件，这些组件可以一起工作以提供集中式集成平台。
每个结构都包含一个或多个结构注册表 。 Fabric Registry是基于Apache Zookeeper的分布式高可用性配置服务，它在配置注册表中存储构成集群的所有ESB容器的完整配置和部署信息。
数据存储在Zookeeper内部的分层树状结构中。 Fabric会根据配置注册表中存储的信息来配置ESB容器。 还有一个运行时注册表，用于存储组成Fabric群集的物理ESB实例，它们的物理位置以及它们正在运行的服务的详细信息。 客户端使用运行时注册表在运行时动态发现可用服务。 通过运行副本实例，可以使Fabric注册表高度可用。 图2中的示例集群由三个ESB实例组成，每个实例都运行一个注册表副本。
Fabric注册表存储所有ESB实例的所有配置和部署信息。 架构配置文件中描述了此信息，用户在其中充分描述了他们的应用程序和这些配置文件中的必要配置。 因此，概要文件成为Fabric中的高级部署单元，并指定特定应用程序或应用程序模块需要哪些OSGi捆绑软件，纯Java jar或war文件，什么配置以及哪些捆绑存储库。
一个配置文件可以部署到许多ESB容器，并且每个ESB容器可以部署多个配置文件。 配置文件是版本控制的，支持继承关系，并使用一组Karaf shell命令进行管理。 可以在其他更具体的配置文件继承的基本配置文件中描述公共配置或部署信息。
图3显示了一些现成提供的示例配置文件。 它定义了一个通用的基本配置文件，称为default，所有其他配置文件都继承自该配置文件。 该示例还列出了名为camel，mq或cxf的配置文件。 这些配置文件为各种ESB功能（如消息路由（基于Camel），可靠消息传递（基于ActiveMQ）和Web服务支持（基于CXF））定义了OSGi捆绑包和配置。 鼓励用户创建从这些标准配置文件继承的自己的配置文件。
图3：样本配置文件
配置文件可以轻松部署到一个或多个ESB容器。 将配置文件部署到特定容器是Fabric Agent的任务。 Fabric群集中的每个ESB容器上都运行着一个代理。 它连接到Fabric Registry，并评估需要部署到其容器的一组配置文件。 代理进一步侦听概要定义的更改，并将更改立即提供给其容器。
最后，Fabric定义了Fabric Server或Fabric容器的组件。 这是每个由Fabric管理的ESB容器。 每个Fabric Server都有一个正在运行的Fabric Agent。
对于真实的位置透明度，Fabric还定义了许多Fabric Extensions 。 每个基于CXF的Web服务，每个Camel使用者端点（Camel集成路由的起始端点）和每个ActiveMQ消息代理实例都可以在启动时在Fabric运行时注册表中注册其端点地址。 客户端可以在运行时查询注册表中的这些地址，而不必对地址进行硬编码。 这使您可以在运行时将端点移动到不同的物理机，出于负载平衡的原因运行端点的副本，甚至可以创建主/从拓扑，其中从属端点（例如，从消息代理）等待备用以使主端点不可用。 Fabric Extensions不在本文讨论范围之内，但是上面的链接详细介绍了它们。
Fabric定义了一些非常强大的概念。 所有供应信息都以结构配置文件的形式存储在高度可用的结构注册表中。 然后，借助光纤网代理，可以将这些配置文件快速部署到群集中的任意数量的ESB实例。 此外，Fabric能够根据需要创建新的本地和远程ESB实例。 与Fabric Extensions一起使用，可以实现非常灵活的部署。 如果特定ESB容器的负载增加，则有可能启动另一个ESB容器实例（可能在云中），该实例部署相同的应用程序集，然后在所有实例之间平衡整个工作。 此外，如果需要在客户端自动重新平衡的同时在更快的硬件上运行，则可以将ESB实例移至其他物理服务器。 借助Fuse Fabric，可以快速轻松地适应运行时要求的任何变化，并具有完全灵活的集成平台。
演练
在介绍了Fabric的概念之后，最后一部分旨在提供有关如何实际使用Fuse Fabric部署集成项目的快速介绍。 尽管可以从其项目网站下载并运行Fuse Fabric，但这部分使用Red Hat发布的Fuse ESB Enterprise 7.1 。 Fuse ESB Enterprise基于Apache ServiceMix，并已包括现成的Fabric。 它在此处完整记录。 使用Fabric时的默认工作流程如下：
创建一个新的结构。 这将启动Fabric注册表并导入默认配置文件。
使用ServiceMix提供的技术创建Integration或SOA应用程序。
在一个或多个结构概要中定义应用程序的部署及其配置。
创建所需数量的ESB容器，并为一个或多个配置文件配置这些容器。
测试或运行已部署的应用程序。
让我们一步一步地完成这些步骤。
创建一个新的Fabric
安装Fuse ESB Enterprise 7.1后，可以使用脚本“ bin / fuseesb”启动它。 几秒钟后，将显示Shell控制台的欢迎屏幕。
| ___| | ___|/ ___|| ___
| |_ _ _ ___ ___ | |__ `--. | |_/ /
| _|| | | |/ __| / _ | __| `--. | ___
| | | |_| |__ | __/ | |___ /__/ /| |_/ /
_| __,_||___/ ___| ____/ ____/ ____/
Fuse ESB (7.1.0.fuse-047)
http://fusesource.com/products/fuse-esb-enterprise/
Hit '' for a list of available commands
and '[cmd] --help' for help on a specific command.
Hit '' or 'osgi:shutdown' to shutdown Fuse ESB.
FuseESB:karaf@root> 提示：所有Karaf shell命令都使用–help参数，该参数显示该命令的快速手册页。
此ESB容器在首次启动时未预先配置结构。 它只是一个独立的ServiceMix安装，已部署了许多OSGi捆绑软件。 首先需要使用Karaf shell命令 ' fabric：create ' 创建一个Fabric 。 这将重新配置当前的ESB容器，部署并启动Fabric注册表，并将默认配置文件导入注册表。 另外，容器可以使用命令“ fabric：join ” 加入现有的Fabric集群，以 提供已经运行的Fabric注册表的URL。 默认情况下，此启用了Fabric的ESB容器不部署任何ESB功能（使用命令' osgi：list '进行验证）。 通过部署相关配置文件可以启用ESB功能。
创建集成或SOA应用程序
Fuse ESB Enterprise 7.1还附带了几个演示，本文从中选择了examples / jms演示。 它演示了如何连接到ActiveMQ代理以及如何在两条基于骆驼的集成路由之间使用JMS消息传递。 该演示在普通的ServiceMix环境中工作，但在本部分中，它将部署到启用了Fabric的ESB容器中。 该演示仅包含一个有趣的文件，即“ examples / jms / src / main / resources / OSGI-INF / blueprint / camel-context.xml”中的Camel路由定义。
/order:order/order:customer/order:country = 'UK'
/order:order/order:customer/order:country = 'US'
此骆驼上下文定义了两条骆驼路线。 第一条具有id = file-to-jms-route的路由使用来自本地文件系统上文件位置（目录work / jms / input）的消息。 然后，它记录文件名，并将文件的内容发送到外部ActiveMQ代理上的入库队列。
第二个id = jms-cbr-route的Camel路由使用来自来信订单JMS队列的消息，并运行基于内容的路由。 根据消息的XML有效负载，它将被路由到本地文件系统上的不同目标目录。 这是一个简单但相当普遍的集成用例。 需要一些小的附加配置来告诉Camel如何连接到外部ActiveMQ代理。
请注意brokerURL属性。 无需使用像tcp：// localhost：61616这样的硬编码url，而是在运行时使用Fabric MQ扩展从Fabric注册表中查询真实的代理地址。 这样，可以将代理移动到其他物理计算机，并且客户端会自动重新连接到新的代理地址。
可以通过运行' mvn install'来构建演示。 这会将生成的OSGi捆绑包安装到本地Maven存储库。
现在是时候创建用于部署此集成项目的Fabric配置文件了。 让我们假设需要在其自己的ESB容器中外部运行ActiveMQ代理，由于各种原因，例如为多个已部署的应用程序提供通用的消息传递基础结构，这可能很有用。 因此，需要两个ESB容器：一个运行ActiveMQ代理，另一个运行Camel集成路由。
为了运行ActiveMQ代理，已经有一个开箱即用的名称为mq的配置文件。 该ActiveMQ代理具有默认配置，足以运行此演示。 mq配置文件可以简单地重复使用，因此无需创建新的配置文件。 命令“ fabric：profile-list ”列出了所有可用的配置文件。 “ fabric：profile-display profilename ”显示配置文件的内容。
为了运行Camel集成演示，需要将Camel运行时部署到ESB容器。 此外，两条骆驼路线都连接到外部ActiveMQ代理。 因此，还必须将ActiveMQ客户端库部署到此ESB容器。 ' fabric：profile-list '列出了以下三个配置文件
FuseESB:karaf@root> profile-list
[id] [# containers] [parents]
activemq-client 0 default
camel 0 karaf
camel-jms 0 camel, activemq-client
...概要文件activemq-client部署了连接到ActiveMQ代理所需的ActiveMQ客户端库。 概要文件骆驼部署了核心的Camel运行时（但没有部署许多Camel组件）。 最后，配置文件camel-jms有两个父配置文件，分别为camel和activemq-client，因此它部署了两个ActiveMQ客户端库– Camel核心运行时和camel-jms组件。 将配置文件camel-jms用作父级时，它将自动部署Camel运行时和ActiveMQ客户端运行时。
fabric：profile-create –parents camel-jms camel-jms-demo
此命令将创建一个名为camel-jms-demo的新配置文件，并将配置文件camel-jms用作其父项。该配置文件还需要部署ServiceMix演示的OSGi捆绑包。 可以使用演示的Maven坐标（该演示先前已构建并安装到本地Maven存储库）来添加
fabric：profile-edit –bundle mvn：org.fusesource.examples / jms / 7.1.0.fuse-047 camel-jms-demo
它修改了骆驼的JMS演示配置文件，添加由它的Maven坐标 'org.fusesource.examples / JMS / 7.1.0.fuse-047 标识的演示的OSGi包 。 就这样！ 借助现成的配置文件，仅用了两个Fabric shell命令即可创建一个配置文件，该配置文件完全部署了Camel集成演示。
创建ESB容器
最后一步是创建两个运行ActiveMQ代理和Camel演示的ESB容器。 要在其自己的ESB容器中运行ActiveMQ代理，只需执行以下命令：
面料：容器创建子–profile mq root activemq-broker
它使用父容器作为根容器创建一个新的本地ESB容器，称为“ activemq-broker”（使用Fuse ESB Enterprise的现有安装）。 它还部署mq配置文件，该配置文件运行ActiveMQ代理。 可以使用命令 fabric：container-create-ssh 在另一台计算机上创建ESB容器 。 运行 ' fabric：container-list '验证新的ESB容器已启动。 可以使用“ fabric：container-connect activemq-broker ” 连接到该容器， 并使用 “ log：tail ” 检查日志文件 。 如果ActiveMQ代理成功启动，则日志将包含以下行：
Apache ActiveMQ 5.7.0.fuse-71-047（activemq-broker，ID：XPS-49463-1357740918210-0：1）已启动。
随着代理运行，可以将camel-jms-demo概要文件部署到另一个ESB容器。 现有的根容器仅运行Fabric Registry，因此可以使用以下命令将演示部署到根容器
面料：容器添加配置文件骆驼JMS演示根
这重新配置了根容器，以同时部署camel-jms-demo配置文件（jms演示）。
测试应用
最后，可以通过将示例XML消息复制到第一个Camel路由监听的work / jms / input文件夹中来测试该演示。 幸运的是，演示中提供了一些示例消息。 在普通的Unix或Windows Shell上运行
cp示例/jms/src/test/data/order2.xml实例/ camel-jms-demo / work / jms / input /
复制后，文件将立即由Camel拾取，并通过JMS通过两条Camel路由进行路由，最后被放入目标目录instance / camel-jms-demo / work / jms / output / uk / order2.xml中 。 这可以验证该演示是否正常运行。
对于不喜欢命令行工具的用户，还可以使用 保险丝管理控制台（FMC ） 管理 Fabric的所有方面 。 FMC是用于Fabric的基于图形的基于浏览器的管理工具，是使用Karaf Shell的完整替代方案。 可以使用以下命令将其直接安装到根ESB容器：
面料：容器添加配置文件FMC根
之后，可以使用URL http：// localhost：8181 / index.html 从浏览器访问它 （请参见图4 ）。 讨论保险丝管理控制台的细节不在本文讨论范围之内。
图4：保险丝管理控制台
结论
任何需要管理ServiceMix的多个实例的人都应该研究Fuse Fabric。 集中描述所有部署并将其部署到任意数量的ESB实例的能力可以大大提高生产率并降低管理复杂性。
作者简介：
Torsten Mielke是Red Hat的高级技术支持工程师。 他是Red Hat全球专业支持团队的成员，也是开源企业集成和消息传递系统的专家。 Torsten积极从事开源项目，例如Apache ActiveMQ，Apache ServiceMix，Apache Camel和Apache CXF，并且是Apache ActiveMQ项目的提交者。
本文发表在《 JAX杂志：套接字！！》中。 有关其他文章和问题，请单击此处。
图片由Razor512提供
翻译自: https://jaxenter.com/tutorial-managing-apache-servicemix-clusters-with-fuse-fabric-106023.html
jboss fuse 教程