在Mule应用中的流程图架构
本篇对Mule应用中的流程图进行描述，流程图是用Mule来构建应用的默认结构。注意，Mule也支持适用于大数据和流式消息处理的批处理作业。批处理作业也可以与流程图相结合使用，但是其结构和功能会与下面的内容有所不同。由Batch Processing可见更多关于批处理作业的内容。
关键点
简单应用的场合，Mule应用每次接收一个消息，按照接收消息的循序对消息进行依次处理。如此处理可能有多种结果：
-
某些情况下，Mule应用向原始消息的来源返回更改过的消息或者替换后的消息
-
或者，Mule应用向若干第三方发送原始消息或更改过的消息
-
又或者，Mule可以拒绝对消息进行处理，倘若消息不符合预期。
更进一步
复杂的Mule应用不会局限于线性消息处理。高级的处理机制可以对不同的消息进行不同方式的处理。你可以结合以下几点来构建应用：
-
安排各式队列与线程来最大化数据吞吐
-
使用事务或节点集群来最大化可靠性
-
使用对象存储来包装数据持久性
-
批处理作业用来处理大数据和流式消息，通过将消息拆解成子记录进行处理
这些只是你可以用来实现Mule应用的大量特性中的一部分。
下面的章节用Anypoint Studio中的处理器的概念来探讨流程图架构。处理器在Mule xml配置中对应于xml元素，但是为了对流程图建模和以及便于理解，本文会使用Studio中的图形化呈现。
在流程图中的处理器
处理器被划分为不同的功能类别，其中某些处理器又由若干的子处理器构成处理块。
处理器在流程图中能被放置的位置是有一点限制的。通常处理器可放置的位置以及其可配置的表现，和流程图已存在的其他处理器有关（特别是与其相邻的处理器）。
下一节将详述各种可以放到Mule流程图中的处理器（以及处理器块）
消息源
大多数流程图中的第一个处理器会是消息源，消息源从一个或多个外部资源接收消息，藉此触发生成流程图实例。每次收到一个不同的消息，消息源就会触发生产新的流程图实例。
Anypoint连接器就是典型的消息源
有时消息源会将传入的消息立即放入到队列中。这使得消息源可以关闭传入消息的接收线程，然后立即开启另外的线程接收其他的传入消息。被放入到队列的消息会在队里中排队，直到轮到它被流程图中的逻辑进行处理。由于消息是依次（按照队列内设的间隔）被两个不同的线程进行处理，从头至尾的连续事务处理是不可能的。
译注：我的理解是，从头至尾是指第一个消息处理开始至第二消息处理结束，因为是不同的处理线程，所以无法将两个消息纳入相同事务。只能通过分布式事务，或者另外的线程进行事务管理。
Message Received, Queued, Processed
消息源可以从多个传输渠道接收消息。你可以将一个HTTP节点和Servlet节点相结合来构成复合消息源。或者创建可同时接收IMAP和POP3邮件的复合消息源。其中的任一连接器都可以在受到传入消息时触发创建一个流程图实例。
特定情况下，流程图不需要通过消息源也可触发。比如，流程图引用可以触发同一应用的不同流程图。类似的，异步作用域可以触发异步执行另一个流程图（与源流程图并行执行）。
消息处理器
通常、消息处理器是多个消息处理功能单元的封装，各单元对消息进行不方式的处理。消息处理器的优势在于：
-
通常无需自定义代码即可直接使用。
-
复数个消息处理器可以用不通过的方式组合起来以实现满足应用需求。
有两种不同的方式来将消息处理器结合起来做出应用（或者说做出流程图）：
-
在Studio画布上排列元件（从元件工具箱将元件拖放到画布上）
-
在应用配置文件中插入xml代码
消息处理器划分为不同的类别，如下表所示：
| 分类 | 简述 |
|---|---|
| 连接器 | 提供Mule应用与外界通讯的手段。通常作为消息源，也可以出现在流程图中的其他位置。与流程图外的资源进行数据交换，或者作为消息的最终目的地。 |
| 作用域 | 从多个方面对消息处理器或者处理块（由多个消息处理器构成的功能组）进行增强。 |
| 组件 | 使你可以为流程图附加机能，例如日志，或者显示输出。或者通过特定语言的命令行接口来将旧系统中的业务逻辑集成到Mule应用中。 |
| 转换器 | 增强或者改变消息负载，属性，变量或者附件 |
| 过滤器 | 单独使用或者结合成组，用来判断消息是否可以流过应用流程图。 |
| 流程图控制 | 指定消息如何在流程图中各个消息处理器之间路由。或可在路由前对消息进行处理（聚合，拆分或者重新排序） |
| 异常处理 | 指定不同场合下的各式异常处理过程 |
| 其他 | 该特殊类别目前只有一个成员：自定义业务事件处理器，用来放置在其他的处理器之间来记录关键性能指标KPI。通过Mule控制台可以对其进行监控。 |
在你的流程图中按照适合的顺序排列好了你的各式处理器之后，你需要配置各消息处理器：
-
在图形界面中属性编辑器中输入属性值完成设置
-
在xml配置代码中输入属性值。
消息处理块
Mule提供了不同的方式将多个消息处理器合成为功能处理块
可以使用合成源作用域将2个或以上的的Anypoint连接器合成为一个消息源，各连接器监听不同的渠道。任一连接器收到传入消息，都会触发流程图实例，使消息按序进行处理。
其他的作用域处理器提供了多种将消息处理器组成功能组的方式，使用它们可以：
-
让你的xml代码更易读
-
实现并行处理
-
创建可重用的消息处理序列
交换模式
许多Anypoint连接器是基于节点的，要么是作为传入节点（通常出现在流程图的最开始），要么是作为传出节点（可以出现在流程图中间或者结束）。通过通用的协议（HTTP，FTP，SMTP等等）进行通讯。传入节点和传出节点可以实现单向或者请求响应交换模式。
当基于传入节点的连接器譬如HTTP或VM被配置为请求响应交换模式时，其等效的变为混合传入传出节点。即使有其他的传出节点并存在流程图中将数据传出，配置为请求响应交换模式的传入节点也会将数据传出流程图，会向消息的原始发送者返回响应。
请求响应交互模式
传出节点被配置为请求响应交换模式时，它们可以与流程图外的资源交换数据，也可以与同一Mule应用中的一些消息处理器交换数据。
并非所有的节点都可以被配置成请求响应交换模式，且对于可配置响应交换模式的节点，只有其中的部分是默认配置为该模式的。如果主流程图中没有节点被配置为请求响应交换模式，流程图在接收消息时会遵受单向交换模式，且不会向原始发送者发送响应。但是，流程图可以向其他方发送数据，例如日志文件、数据库、邮件服务器或者Web API。
处理策略
处理策略决定了Mule运行消息处理器的顺序。例如，当消息源配置为请求响应交换模式时，Mule将处理策略设置为同步，则流程图的执行是在单一的处理线程中进行的。这样确保整个消息处理器序列得以执行，客户端可按照预期获得相应。
与之相反，当流程图配置为单向交换模式且非事务性（源消息发送者不需要收到响应，且不必对全部执行步骤进行完成校验），Mule会将处理策略设置为队列化异步，这样可能会增加流程图的吞吐量。这种情况下，传入节点将传入消息立即放入队列，并关闭对应接收线程。当消息在队里中排到出队列后，则该消息会被另一个不同的线程继续处理。由于通过了不同的线程对消息进行，在某一线程中出现异常则无法回滚另一线程中的处理，所以横跨整个过程的事务管理是无法使用的。
单向异步模式
更多细节：参见流程图处理策略
异常处理策略
异常处理策略决定了Mule对于消息处理过程中发生的异常如何进行响应。最简单的处理方式是将异常记录到日志文件。
通过配置自定义异常处理策略可以灵活的根据不同的条件进行响应。比如异常在消息被转换之后发生，你可以设置Mule在异常发生之前被转换之后就立刻被提交，这样可以避免消息被意外的重复处理。
Stuido提供了四种现成的异常处理策略来应对消息处理序列中各种位置抛出的异常。详情请见异常处理.
流程图架构
Mule流程图极其灵活，所以你可以用许多不同的方式来组织处理器来达成相同的结果。然而，在许多用户用例下，松散排序模式下的消息处理器更容易出错。譬如，假设你要创建一个应用，该应用从网页接收产品目录请求，将产品目录的PDF发送给提交请求的客户端。另外，你想通过这个流程图将客户端的客户信息保存到日志并记录事务。你的流程图可能会一如下图所示：
在线假日广告册下载-设计
注意过滤器和转换器可以内嵌在传入节点，但是把它们放在主流程图易读性更佳，对于图形界面的画布和xml格式的配置文件皆是如此。
在线假日广告册下载-流程图
<?xml version="1.0" encoding="UTF-8"?>
<mule xmlns:scripting="http://www.mulesoft.org/schema/mule/scripting" xmlns:http="http://www.mulesoft.org/schema/mule/http" xmlns:mulexml="http://www.mulesoft.org/schema/mule/xml" xmlns="http://www.mulesoft.org/schema/mule/core" xmlns:doc="http://www.mulesoft.org/schema/mule/documentation" xmlns:spring="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-current.xsd
http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd
http://www.mulesoft.org/schema/mule/xml http://www.mulesoft.org/schema/mule/xml/current/mule-xml.xsd
http://www.mulesoft.org/schema/mule/http http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd
http://www.mulesoft.org/schema/mule/scripting http://www.mulesoft.org/schema/mule/scripting/current/mule-scripting.xsd">
<http:listener-config name="HTTP_Listener_Configuration" host="localhost" port="8081" doc:name="HTTP Listener Configuration"/>
<flow name="Catalog_DownloaderFlow1" >
<http:listener config-ref="HTTP_Listener_Configuration" path="/" doc:name="HTTP"/>
<mulexml:xml-to-object-transformer doc:name="XML to Object"/>
<scripting:component doc:name="Groovy">
<scripting:script engine="Groovy" file="myScript.groovy"/>
</scripting:component>
<logger level="INFO" doc:name="Logger"/>
</flow>
</mule>
流程图配置
虽然流程图很灵活，但是处理器放置在流程图中的位置依然是有一定限制的。根据流程图中已放置的处理器，可继续放置的处理器位置会有所不同。处理器根据其在流程图中所处位置不同，其可配置的属性也会不尽相同。
如果你通过Anypoint Studio的可视化编辑器进行Mule应用的开发，Studio会自动跟踪处理器之间的限制，以确保你不会将处理器放到不应该出现的位置。
以下是覆盖大部分运用场景的创建可用的流程图的处理器序列的规则。
-
一个消息源包含若干传入节点或流式连接器，任一节点和连接器收到消息时都会触发流程图。
-
过滤器用来判断无效的消息并阻止无效的消息通过流程图中的其他处理。
-
转换器可将传入消息转换成流程图中其他消息处理器可处理的格式
-
消息增强器可往消息中增加特定的关键信息。譬如，附带着地址信息的消息传入，消息增强器可能会利用其中的邮政编码来查找相应的电话区号，然后将查到的信息追加到消息头部供市场部门使用。
-
消息准备好被处理后，通常会被发送往预先组装好的自定义业务逻辑（通常称为组件）进行处理。这样就可以对内容按照合适的方法去处理。
-
关于流程图的结尾有各种可能；以下的可能部分出现或全部出现：
-
Mule向消息的原始发送者发送响应
-
Mule将业务处理的结果记录日志到数据库或者发给第三方
-
流程图处理之后，你可以：
-
将消息发送往队列（即便是同一流程图中也可以往多种队列发送）
-
指定线程模型
-
调用各式其他的流程图
更多内容
作者：麦克斯杜
链接：https://www.jianshu.com/p/86e3b3c377a7
扫一扫
325
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
