Mule学习（六、控制消息的流向-数据路由）

1. 使用场景

我们来看一个常见的应用场景。我们的集成应用可以接收客户端提交订单的请求，有多种不同类型的客户端。手机客户端是一个App，我们在App上使用的消息格式通常是轻量级的JSON格式。而PC客户端是一个Windows时代的产物，它仍然使用XML格式。我们的集成应用在接收到订单请求后，会根据订单的类别分发到不同的仓库，订单类别存储在订单内容的OrderType字段中。

2. 基于消息头的路由

我们首先要区分订单的格式，因为JSON和XML的处理逻辑是完全不同的。在Mule中我们可以使用MEL的JSON Path来解决JSON文件的解析，XML Path来解决XML文件的解析。MEL的详细用法可以参考上一篇文章。订单的格式通常会放在消息头上传递，而Mule Message中对应消息头的部分就是Message Inboud Properties。

2.1 使用JSON提交订单的消息

{
    "OrderType": "Book",
    "TotalAmount": 1000,
    "OrderLines": [{
        "ProductName": "Learn English",
        "Qty": 3,
        "Price": 300
    }, {
        "ProductName": "Lean Mule ESB",
        "Qty": 1,
        "Price": 100
    }]
}

使用Postman提交JSON，注意Content-Type设置为application/json。

通过Postman的Preview可以看到，实际上Http的Request头信息上设定了Content-Type字段为application/json。

2.2 使用XML提交订单的消息

  Book
  1000
  
    
      Learn English
      3
      300
    
    
      Learn Mule ESB
      1
      100
    
  

使用Postman提交XML，注意Content-Type设置为application/xml。

通过Postman的Preview可以看到，实际上Http的Request头信息上设定了Content-Type字段为application/xml。

2.3 使用Choice组件判断订单格式

Mule ESB最基本的路由组件就是Choice组件，组件类似于我们在编程语言中的if/esle if/else。订单的格式是存放在Message Inbound Properties中的。这里就使用Choice组件来判断订单的格式。

Mule XML Config:

Mule UI Config:

通过Choice组件所支持的MEL语法，我们就能通过判断mule message inboundProperties来确定订单格式。需要注意的是，图上所示的Default是选择的最后一个路径，实际是if,else if,else,end if这个路径中的else路径。

3. 基于消息内容的路由

通过消息头的判断，我们已经可以区分JSON格式和XML格式订单，那么如果区分订单类型呢，这里就需要用到基于消息内容的路由，我们对前面的代码做改进，同时引入消息队列。

Mule XML Config:

Mule UI Config:

4. 其他控制流向的组件

除了使用Choice组件改变Flow执行路径以外，还要很多控制流向的组件。比如Round-Robin，Resequencer，Scatter-Gather，Splitter，Aggregator等组件。这些组件的用法各不相同，这里主要讲一下Round-Robin的用法。Round-Robin是一种轮询调度算法，在负载均衡的策略里面经常见到Round-Robin，轮询调度算法的原理是每一次把来自用户的请求轮流分配给内部中的服务器，从1开始，直到N(内部服务器个数)，然后重新开始循环。

Mule的Round-Robin组件也是类似的思路，轮询执行Flow中的分支路径。举例如下，我们接收到用户的检索请求，每次请求我们使用不同的执行路径，第一次使用Bing搜索，第二次使用Google，第三次使用Baidu。

Mule XML Config:

Mule UI Config: