本篇主要介绍在Mule ESB中控制消息的流向。控制消息的流向有很多不同的场景，数据的路由，数据的拆分和组合，数据的排序，数据的分发等。数据路由是ESB平台上最基本，也是最重要的功能之一，完整的ESB平台都会有相对应的功能。ESB基本的功能可分成消息路由，消息传输和消息转换等，后续几篇Mule ESB开发教程我们会陆续讲解这些功能。
Mule ESB同样具有很多的消息路由组件。作为开源ESB产品中很成熟的平台，Mule ESB的发展状态非常好，经过多年的发展，2017年在纽交所成功上市。Mule ESB拥有众多的企业案例，我们作为MuleSoft的重要合作伙伴，使用Mule ESB企业版开发实施，或者Mule ESB社区版开发实施，帮助国内众多的行业标杆客户成功上线企业集成项目。
专注Mule ESB社区版实施，分享开源中间件。我们的网站: http://www.enjoyingsoft.com，或者邮件联系我们Contact@EnjoyingSoft.com
Mule ESB的源代码托管在GitHub上，拥有非常详细的英文文档，Mule ESB的中文文档资料和开发教程却非常少，我们使用8篇文章来写基础Mule ESB中文开发教程，一起为开源软件做贡献。
- EnjoyingSoft之Mule ESB开发教程第一篇：初识Mule ESB
- EnjoyingSoft之Mule ESB开发教程第二篇：Mule ESB基本概念
- EnjoyingSoft之Mule ESB开发教程第三篇：Mule message structure - Mule message结构
- EnjoyingSoft之Mule ESB开发教程第四篇：Mule Expression Language - MEL表达式
- EnjoyingSoft之Mule ESB开发教程第五篇：控制消息的流向-数据路由
- EnjoyingSoft之Mule ESB开发教程第六篇：Data Transform - 数据转换
- EnjoyingSoft之Mule ESB开发教程第七篇：SOAP Web Service的消费和创建
- EnjoyingSoft之Mule ESB开发教程第八篇：使用API构建Rest Service
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:
本文同步发文于EnjoyingSoft Blogs ，博客园，CSDN
访问EnjoyingSoft 网站，获取更多Mule ESB 社区版 实施帮助。
欢迎转载，但必须保留原文和此段声明，且在文章页面明显位置给出原文链接，否则保留追究法律责任的权利。