Shuttle ESB（六）——在工程中的应用

假设你可能浏览在前面几篇文章ESB介绍，我相信，在这篇文章中，你会发现很多共鸣。

虽然。市面上开源的ESB确实很之多。像Java中的Mule ESB。Jboss ESB；.Net中的NServiceBus。而Shuttle ESB是一个新兴的开源框架，网络上资源也比較少。我们当初为什么会选用Shuttle ESB呢？

正所谓没有最好。仅仅有更合适。多次调研发现，Shuttle ESB有下面几大长处：

1、Shuttle ESB是基于EDA的；

2、Shuttle ESB的实现以公布订阅为核心；

3、Shuttle ESB核心不依赖不论什么第三方组件。

Shuttle ESB的这些特点，与项目的高速通信、广播消息、高度可控很吻合。

经过前面几篇博客的解说，大家对Shuttle ESB这一开源项目应该已经不陌生了。

可是，怎样把它应用到项目中，架构起来。并正常执行。也不是一件简单的事情。我在完毕这个工作的期间，就遇到了非常多这样那样的问题（既然选择了较新的技术。就一定会遇到这种问题）。

所以。我决定以项目为主要选材，抽象出来一个模型，供大家參考。希望对想学习该框架的朋友。起到一定的帮助作用。另外，您假设有不论什么疑问。或者新的想法，请及时跟我联系或者留言。我会尽量满足。

注：关于这篇文章是否侵权，我已经多方考察过。眼下，在全国，并非我们唯一一家在做这个的。而我们将模仿Sum公司。致力于做一个全国联网的系统。

当然，其它局也能够做，可是假设实现多局共享。就必须參照我们制定出来的标准。既然非常多家都在做，那么我就避重就轻。避开特色的东西，谈谈共性的需求，就不涉及侵权了。

以下我就来介绍一下，Shuttle ESB在项目中的应用

宏观上来讲，这是一款铁路局列车行驶时的灾害监測系统。项目划的圈比較大，它要实现的是一种全国的联网。

这样。一条ESB服务总线就不够用了。并且。据我对Shuttle ESB的性能測试，当client不断增多的时候。消息的传输速度会随之减少。

这尽管对我们现系统执行影响不大，可是这样就限制了client的数量。

此外。对于Shuttle ESB实例启动的时候，会导致系统有一个非常高的IO吞吐量。这两个问题。眼下我也没有解决。虽然Eben多次跟我说没事儿。这还是我对这个系统最操心的地方。

考虑到上面提到的问题。而且结合实际情况。我们对系统中ESB部分的架构做例如以下设计：

这样设计，每个分局至少有一条ESB服务总线，将系统中显示终端控制器、规则引擎、WCF服务、以及相关的通信系统都挂在这条总线上。因为ESB主要起到消息路由器的作用，一旦相关的通信系统或某终端显示器发出消息，该局全部显示终端都会接收到消息。

那么如何实现全国联网呢？每一个分局的ESB服务总线都会遵循一定的标准设计。然后再利用二八定律，将频繁通信的分局ESB总线上之间。架设一条新的服务总线。终于。全国可能会有非常多条服务总线。

可是，全部的总线都会挂在一条总线上，实现全国联网。

以下。我就来介绍一条服务总线的具体架构设计。

         

如图2所看到的，它的操作流程基本例如以下：

1、Shuttle ESB Server为报警数据的接收端，也是报警数据和报警解除数据的发送端。

通信系统检測到报警信息，通信系统会将报警数据以CopyData消息的方式发送至队列，Shuttle ESB Server将接收该消息；

2、Shuttle ESB Server总程序接收到消息后，并对消息进行对应的处理（包含：格式转换、升降级推断、自己主动解除推断等等）。然后将处理后的报警消息发送给clientA机器、clientB机器……

3、终端控制器MainClient通过Handler接收到消息后，然后将处理后的报警消息发送给本机的各个终端显示器，如列调终端、综合调度台；

4、显示终端接收到报警解除消息后。它会经过一定的逻辑处理，然后公布一条报警解除的消息。

5、Shuttle ESB Server的Handler将接收该解除消息，经过一定的处理后，它会将报警解除消息又一次发送给终端控制器。继而通知到全部订阅该消息的终端。

通过如上流程，将就一条最简单的Shuttle ESB服务总线架设在了系统之上。

我在完毕这个过程的时候，分享几个比較棘手的问题：

1、Shuttle ESB开源项目dll版本号问题

開始研究Shuttle ESB时。总是有dll版本号问题。导致在项目集成时，遇到非常多问题。

后来使用NuGet插件。屏蔽了这个问题。

2、设计缺陷

如上图2设计图，開始设计时。ESB Server公布消息，MainClient接收，然后MainClient再发送给各个显示终端。同一时候显示终端也能够将消息又一次发送给ESB Server。这个过程中。一共启动了两个ESB实例（不包含ESB Server），原因是：

一、MainClient须要启动一个ESB实例，监听消息；

二、多个显示终端共用一个Shuttle ESB实例。来监听消息。

这样设计是有问题的，并且会间歇性的报各种各样的怪问题：

一、ESB实例启动时。须要启动大量的相关服务，这是比較耗时间的。

登录时启动两个实例，非常不明智；

二、Server发送大量的消息，导致client无法接受正常的消息。它会一直接收错误消息，直到消息队列中没消息为止。

后来与Eben谈及此问题。他告诉我：在一个进程中，仅仅能启动一个Shuttle ESB服务总线实例，不然会导致系统不稳定。

解决方式非常easy，既然启动两个不行，并且费力不讨好，那么去掉MainClient的服务总线实例，让显示终端直接监听Shuttle ESB Server的消息，也可以正常实现。

3、组件不识别资源

原错误信息例如以下：

组件“ICT.RCS.Modules.Client.MainMenu.MainMenu”不具有由 URI“/ICT.RCS.Modules.Client.MainMenu;component/mainmenu.xaml”识别的资源。

这个问题。报错报的也非常莫名其妙。经过重复尝试，我的解决方式是更改MainFrameWork的生成路径到Module下。

思路非常easy，因为总是报错照不到资源，我就将全部项目的生成路径更改到每一个项目的debug下。项目就能正常执行。只是详细是哪个资源导致的不识别，就不知道了，我也没有深入研究。

4、正常的系统，不稳定

发送报警数据时。有时报错。

原因是：我与C++组的同事约定。C++与Shuttle ESB交互的部分，她那边拼接一个字符串过来，之间使用逗号“，”隔开。我这边依照约定进行拆分，然后转化为数组。

当她发送多区段时（多区段也是用逗号分隔，多区段涉及到详细业务）。数组总会多出几项。导致越界错误。

5、多线程解决系统启动慢的问题

因为系统登录时。须要载入一堆服务，并且须要启动ESB实例。很耗时。

用户体验很不好。

所以。我有一个思路：模拟Ajax，系统登录时。另启动一个线程。负责clientShuttle ESB总线实例的启动。

长处：用多线程来优化程序。降低启动时间，增强用户体验。

缺点：设计线程同步问题，没有经验。

6、使用Oracle 数据库表队列

眼下，Shuttle ESB提供三种队列支持：MSMQ、SqlServer基于表的队列和RabbitMQ。眼下项目中使用的是SqlServer基于表的队列。

假设想换成Oracle，必须自己写，没时间。

7、集成后不好调试

将Shuttle ESB集成到项目中后，仍需处理大量的业务数据以及相关逻辑。

我这里推断的一些报警。还须要与规则引擎想结合，进行推断。

同一时候。ArcGis地图界面，业务逻辑在不断变化，他们也须要不断作出调整。

数据的来源端C++端也在处在开发期间。它也须要与规则引擎交互……

也就是说。仅仅要系统有问题，就和我相关。測试的同事仅仅要測出来问题。就跑我这来说问题。我都是一步步跟代码，找出是谁那的问题后。再让他改。

费时费力啊。

过了几天后。我实在无法忍受了。由于这样。我就干不了别的活了。然后。我将全部与Shuttle ESB交互的地广场。所有附加的错误处理。写在明显的错误，此。我做了一个小测试，发现少了一些。

版权声明：本文博客原创文章，博客，未经同意，不得转载。