Shuttle ESB（六）——在项目中的应用

标签：style   blog   http   io   os   使用   ar   java   strong   

如果说你认真看了前面几篇关于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的性能测试，当客户端不断增多的时候，消息的传输速度会随之降低。这虽然对我们现系统运行影响不大，但是这样就限制了客户端的数量。

此外，对于Shuttle ESB实例启动的时候，会导致系统有一个很高的IO吞吐量。这两个问题，目前我也没有解决，尽管Eben多次跟我说没事儿，这还是我对这个系统最担心的地方。

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

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

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

下面，我就来介绍一条服务总线的详细架构设计。

如图2所示，它的操作流程基本如下：

1、Shuttle ESB Server为报警数据的接收端，也是报警数据和报警解除数据的发送端。通信系统检测到报警信息，通信系统会将报警数据以CopyData消息的方式发送至队列，Shuttle ESB Server将接收该消息；

2、Shuttle ESB Server总程序接收到消息后，并对消息进行相应的处理（包括：格式转换、升降级判断、自动解除判断等等）。然后将处理后的报警消息发送给客户端A机器、客户端B机器……

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

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

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

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

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

Shuttle ESB开源项目dll版本问题

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

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

设计缺陷

如上图2设计图，开始设计时，ESB Server发布消息，MainClient接收，然后MainClient再发送给各个显示终端。同时显示终端也可以将消息重新发送给ESB Server。这个过程中，一共启动了两个ESB实例（不包括ESB Server），原因是：

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

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

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

一、ESB实例启动时，需要启动大量的相关服务，这是比较耗时间的。登录时启动两个实例，很不明智；

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

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

解决方案很简单，既然启动两个不行，而且费力不讨好，那么去掉MainClient的服务总线实例，让显示终端直接监听Shuttle ESB Server的消息，也能够正常实现。

组件不识别资源

原错误信息如下：

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

思路很简单，由于总是报错照不到资源，我就将所有项目的生成路径更改到每个项目的debug下。项目就能正常运行。不过具体是哪个资源导致的不识别，就不知道了，我也没有深入研究。

正常的系统，不稳定

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

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

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

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

由于系统登录时，需要加载一堆服务，而且需要启动ESB实例。非常耗时。用户体验非常不好。

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

优点：用多线程来优化程序，减少启动时间，增强用户体验。

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

使用Oracle 数据库表队列

目前，Shuttle ESB提供三种队列支持：MSMQ、SqlServer基于表的队列和RabbitMQ。目前项目中使用的是SqlServer基于表的队列。如果想换成Oracle，必须自己写，没时间。

集成后不好调试

将Shuttle ESB集成到项目中后，仍需处理大量的业务数据以及相关逻辑。我这里判断的一些报警，还需要与规则引擎想结合，进行判断。同时，ArcGis地图界面，业务逻辑在不断变化，他们也需要不断作出调整。数据的来源端C++端也在处在开发期间，它也需要与规则引擎交互……

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

过了几天后，我实在无法忍受了。因为这样，我就干不了别的活了。然后，我将所有与Shuttle ESB交互的地方，都加上错误处理，写上明显的错误提示，这样，测试找我才稍微少了一些。

Shuttle ESB（六）——在项目中的应用

标签：style   blog   http   io   os   使用   ar   java   strong   

原文地址：http://blog.csdn.net/liu765023051/article/details/39692983