本文讨论4.6版jxTMS的数据采集系统的分布式处理，整个系列的文章请查看：docker版jxTMS使用指南：4.6版升级内容
docker版本的使用，请查看：docker版jxTMS使用指南
4.0版jxTMS的说明，请查看：4.0版升级内容
4.2版jxTMS的说明，请查看：4.2版升级内容
4.4版jxTMS的说明，请查看：4.4版升级内容
从构思jxTMS之初，笔者就考虑过分布式处理的问题，所以jxTMS系统是构筑在rabbitMQ之上的：jxTMS分为两个主要部分：web服务和ORG【代表一个个组织】，可以有多个web服务和多个ORG，全部都通过MQ勾连。
由于实现企业业务与管理操作的capa虽然是基于python【运行于java之上的jython，停在了python2.7】编写，但出于安全的考虑【参考：jxTMS设计思想之安全】，jxTMS限制了import语句的使用，所以只使用python编写的capa时jxTMS能力有限，即只能使用笔者所编写并开放给capa的java模块。
为了能让jxTMS具备全能力【包括操作系统、系统软件、应用软件、第三方软件、python丰富的软件包库】，发展出catalogService，将提供全能力的功能模块挂到MQ上，再注册到catalogService中，然后就可以在capa中以远过程调用的方式来访问这些扩展功能了：jxTMS设计思想之能力扩展
在此基础上，笔者用go写了一些基础部件开放给python，在此基础上又用python实现了python侧的catalogService服务客户端部件以及其它基础模块。所以docker版的jxTMS包括了jxTMS的主系统以及一个用来提供全能力的扩展，然后以数据采集作为示例。
所以本质上，docker版的jxTMS本身已经是一个分布式系统了，只是数据采集这个功能扩展是standalone构型。所以数据采集系统的分布式，只需我们将python侧的jxTMS数据采集系统拆分为多个大块的组件，然后用MQ勾连起来，就可以实现数据采集系统的分布式处理了。
而standalone构型拆分为分布式构型的核心，就是不同模块间的数据交换方式的改变：
standalone构型中各功能模块间是通过模块接口直接调用来执行功能、读取数据，后期增加了通过本地数总线进行隔离与间接递送
分布式构型中各功能模块间的数据交换需要通过消息系统或高速缓存来间接获取
所以很简单的，我们就看向了之前曾讲述过的本地数据总线。本地数据总线的初衷，就是解构数据采集与处理、应用的耦合。那么，把本地数据总线也通过MQ来实现也就自然而然的实现了分布式构型。
所以，基于jxTMS的数据采集系统变更为分布式构型主要是：
1、jxTMS本就建构在MQ之上，python侧的数据采集系统也是通过catalogService注册到主系统中并通过MQ来接受主系统的管理的，所以只要将数据采集系统拆分为子系统后分别注册到catalogService中即可
2、将本地的数据总线基于MQ重构，然后将数据采集系统拆散的子系统通过数据总线进行工作衔接即可
即，重构数据总线，然后将数据采集系统依托数据总线进行拆分。
参考资料：
下面的系列文章讲述了如何用jxTMS开发一个实用的业务功能：
下面的系列文章讲述了jxTMS的一些基本开发能力：