上一篇文章中,介绍了Shuttle ESB架构模型中的三个重要部分。

今天,我们继续介绍剩余的三个内容:模式和消息路由。

四、模式

Request/Response(请求/响应模式)

对基于Request/Response消息机制的内容。你能够看WiKi的一些文章:http://en.wikipedia.org/wiki/Request-response

向一个终端发送请求。运行某项功能,你能够发送一个命令消息:

bus.Send(new RequestMessage());

虽然这是一个很easy的模式,可是,它却构成了一种耦合紧密的行为。虽然如此,这也未必是一件坏事。在很多情况下这是绝必需的。

通常,命令消息的Handler(处理程序)。进行业务逻辑与消息的处理。可是非常多时候。请求须要有响应。

响应能够以命令消息或者事件消息的形式返回。

使用的时候很easy。你仅仅须要通过服务总线实例进行例如以下调用:

bus.Send(new ResponseMessage(), c => c.Reply());

当然,仅仅要你愿意,你能够将“响应”作为事件消息返回。来达到解耦合的目的。那么这将不再是请求/响应模式了,而是公布订阅模式。

请求/响应模式的优点是:它提供了一种机制,使调用者发出调用请求后。可以收到服务端的反应。

Publish/Subscribe(公布订阅模式)

对于基础公布订阅消息模式的很多其它内容,你能够看这里:http://en.wikipedia.org/wiki/Publish/subscribe

这样的模式的特点就是。让公布者和订阅者之间没有行为耦合。实际上,一个事件消息可能都没有订阅者。

可是这是不太符合实际情况的。

太多的实践证明,大多数情况下,我们要求至少要有一个订阅者。

公布一个事件消息,你能够採用例如以下格式:

bus.Send(new ResponseMessage(), c => c.Reply());

消息发送后。每个订阅者会都到接收到自己的消息。

这全然不同于一对一的消息分配处理机制。

消息分发

可想而知,假设一个端点接收太多的消息。那么处理这些消息就会端点处理能力减少,并且变得臃肿不堪。

这样的情况下,能够将消息改分配到服务节点上。

假设该终端接收到一个服务节点的请求消息,它将向其它服务节点自己主动分配该消息。一个终端能够配置成仅仅发送消息。配置非常easy,仅仅须要设置收件箱标签分配属性为true就可以。

由于消息分布都集成到收件箱。在处理同样端点时。仅仅须要在多个不同的机器上安装一对一的消息。你接收消息的一端。须要一个控制收件箱的配置。

由于全部的Shuttle消息都须要处理,而不是在队列中保持等待状态。

每个服务网站在配置中唯一标识。端点的控制收件箱须要例如以下配置:

<configuration>
<configSections>
<section name="serviceBus" type="Shuttle.ESB.Core.ServiceBusSection, Shuttle.ESB.Core"/>
</configSections>
<serviceBus>
<control
workQueueUri="msmq://./control-inbox-work"
errorQueueUri="msmq://./shuttle-error"/>
<inbox
distribute="true"
workQueueUri="msmq://./inbox-work"
errorQueueUri="msmq://./shuttle-error"/>
</serviceBus>
</configuration>

不论什么接收消息的一端都能这样配置。

然后,你就能够依据你的须要,建立多个服务节点。随着相关的全部公布者的增多,就会形成一个消息的逻辑终点。公布者的配置例如以下:

<configuration>
<configSections>
<section name="serviceBus" type="Shuttle.ESB.Core.ServiceBusSection, Shuttle.ESB.Core"/>
</configSections>
<serviceBus>
<worker
distributorControlWorkQueueUri="msmq:///control-inbox=work" />
<inbox
workQueueUri="msmq://./workerN-inbox-work"
errorQueueUri="msmq://./shuttle-error"
threadCount="15">
</inbox>
</serviceBus>
</configuration>

仅仅要应用程序配置文件包括一个闲置线程的标记。它就会发送一个消息给公布者,表明一个线程成为可运行的。然后订阅者将为每一个可用的线程公布消息。

当应用程序配置文件包括工人标记每一个线程去闲置将消息发送到经销商表示。一个线程已成为可运行的话。

经销商将为每一个可用的线程发送消息。

消息分发的特例

一些队列不须要消息分发。不使用客户终端,而是用它的还有一个实例。也可以使用同样的输入队列。这样的机制适用于代理。由于代理通过消费者线程执行的消耗。集中管理消息。由于消费者来自哪里都无所谓。所以队列可以给各个线程使用。

像基于MSMQ或者基于SqlServer的队列,这些都是通过启一个线程执行host。使用Handler进行消息处理。

代理的方式不同于这样的方式。在代理方式中,过程A将不知道这些消息所消耗的过程,并且导致B过程可能向其它端点获取消息。

五、消息路由

通常。我们说发送一个消息。依据“发送”,我们就确定它是一个命令消息。可是,它不一定必须是命令消息。你也能够给一个特定端点发送一个事件消息。实际情况下。很多其它的往往是发送事件消息。而不是命令消息。

消息发送后,通过调用服务总线实例相关的重载方法:

TransportMessage Send(object message);
TransportMessage Send(object message, Action<TransportMessageConfigurator> configure);

仅仅有那些没有RecipientInboxWorkQueueUri集的信息。将会通过服务总线进行传输。

假设你须要訪问不论什么可用的信息源数据。传输信息的Envelop将被退回。

Shuttle ESB採用了ImessageRouteProvider的实现。来确认消息发送。

    public interface IMessageRouteProvider
{
IEnumerable<string> GetRouteUris(object message);
} The message route provider to use is specified when constructing the service bus: bus = ServiceBus
.Create(c => c.MessageRouteProvider(new DefaultForwardingRouteProvider())
.Start();

默认消息路由提供者,使用应用配置文件。来确定往哪发送消息:

<?xml version="1.0" encoding="utf-8" ?

>
<configuration>
<configSections>
<section name="serviceBus" type="Shuttle.ESB.Core.ServiceBusSection, Shuttle.ESB.Core"/>
</configSections>
<serviceBus>
<messageRoutes>
<messageRoute uri="msmq://serverA/inbox">
<add specification="StartsWith" value="Shuttle.Messages1" />
<add specification="StartsWith" value="Shuttle.Messages2" />
</messageRoute>
<messageRoute uri="sql://serverB/inbox">
<add specification="TypeList" value="DoSomethingCommand, Assembly" />
</messageRoute>
<messageRoute uri="msmq://serverC/inbox">
<add specification="Regex" value=".+[Cc]ommand.+" />
</messageRoute>
<messageRoute uri="sql://serverD/inbox">
<add specification="Assembly" value="TheAssemblyName" />
</messageRoute>
</messageRoutes>
</serviceBus>
</configuration>

IMessageRouteProvider接口的每个实现,都能决定一个实现线路。

然而,它都须要从给定的消息发送。一个典型的场景,以及defaultmessagerouteprovider的工作方式,是使用完整的类型名称来确定目标。

注意:使用发送的每一个消息类型。仅仅能被发送到一个端点。

原文地址:http://shuttle.github.io/shuttle-esb/architecture/#Concepts

Shuttle ESB(三)——架构模型介绍(2)的更多相关文章

  1. word2vec 入门(三)模型介绍

    两种模型,两种方法 模型:CBOW和Skip-Gram 方法:Hierarchical Softmax和Negative Sampling CBOW模型Hierarchical Softmax方法 C ...

  2. Shuttle ESB(四)——宣布订阅模式实例介绍(1)

    前,我的重点是关注的三篇文章Shuttle ESB入境和宏观的概念范例. Shuttle ESB模式:请求/对应模式与Pub/Sub模式. 关于这两种模式的区分,请看以下文章的介绍:Shuttle E ...

  3. Shuttle ESB(四)——公布订阅模式实例介绍(1)

    前面,我已经集中用了三篇文章来讲Shuttle ESB的入门实例与宏观概念. Shuttle ESB一共同拥有两种发送消息的模式:请求/对应模式与Pub/Sub模式. 关于这两种模式的区分.请看以下文 ...

  4. Shuttle ESB

    Shuttle ESB(六)——在项目中的应用 如果说你认真看了前面几篇关于ESB的介绍,我相信,在这一篇文章中,你将会找到很多共鸣. 尽管,市面上开源的ESB确实非常之多,像Java中的Mule E ...

  5. 【Hadoop离线基础总结】Hadoop的架构模型

    Hadoop的架构模型 1.x的版本架构模型介绍 架构图 HDFS分布式文件存储系统(典型的主从架构) NameNode:集群当中的主节点,主要用于维护集群当中的元数据信息,以及接受用户的请求,处理用 ...

  6. 第1节 kafka消息队列:2、kafka的架构介绍以及基本组件模型介绍

    3.kafka的架构模型 1.producer:消息的生产者,主要是用于生产消息的.主要是接入一些外部的数据源,从外部获取数据,比如说我们可以从flume获取数据,还可以通过ftp传入数据等,还可以通 ...

  7. PowerDesigner(三)-企业架构模型(转)

    企业架构模型(Enterprise Architecture Model,EAM)是PowerDesigner 15新增的功能,它能够以图形的方式展现企业架构,从而取代文字描述:以偏向非技术性的表达方 ...

  8. 第1节 storm编程:3、storm的架构模型的介绍

    nimbus:主节点,接收客户端提交的任务,并且分配任务,新的版本当中nimbus已经可以有多个了 zookeeper集群:storm依靠zk来保存一些节点信息,nimbus将分配的任务信息都写入到z ...

  9. Shuttle ESB(六)——在工程中的应用

    假设你可能浏览在前面几篇文章ESB介绍,我相信,在这篇文章中,你会发现很多共鸣. 虽然.市面上开源的ESB确实很之多.像Java中的Mule ESB.Jboss ESB:.Net中的NServiceB ...

随机推荐

  1. onvif开发实战1--总结框架搭建

    Gsoap及开发框架生成: 一:gsoap下载和编译   1.下载Gsoap:地址:http://sourceforge.net/projects/gsoap2/files/gSOAP/ 2.安装: ...

  2. 原生JavaScript 封装ajax

    原生JavaScript 封装ajax   function myajax(options){ //新建一个局部对象 用来存放用户输入的各种参数 var opt={ type:options.type ...

  3. MFC ClistCtr锁定隐藏某一列

    通过设置列的宽度为0, 可以隐藏列表框的某一列,但是用户通过拖动列表框的大小,隐藏的列,可能又被显示出来了. 我们可以自己写一个CListEx继承CListCtr,然后捕获拖动的消息,对该消息进行特殊 ...

  4. Android 小米盒子游戏手柄按键捕获 - 能获取到的 home 键依旧是个痛

    Android 小米盒子游戏手柄按键捕获 太阳火神的漂亮人生 (http://blog.csdn.net/opengl_es) 本文遵循"署名-非商业用途-保持一致"创作公用协议 ...

  5. 【Java】Java Socket 通信演示样例

    用socket(套接字)实现client与服务端的通信. 这里举两个样例: 第一种是每次client发送一个数据,服务端就做一个应答. (也就是要轮流发) 另外一种是client能够连续的向服务端发数 ...

  6. Android实现点击通知栏后,先启动应用再打开目标Activity

    情况简述 在开发Android app的过程中,遇到这样一个需求:app中启动一个Service,该Service在独立进程中运行,与服务器保持长连接,将服务器推送过来的消息在通知栏中显示,并设置点击 ...

  7. BC 52 div2 A Victor and Machine

    简单数学题,把这道题目贴上去的不过为了不想看到这个月写了某个数字篇博客,该数字有点不吉利... 近期没有学习的欲望.. . 集中不了注意力,今天打BC还是做出来一题,尽管涨分了,真心希望能接近cf的水 ...

  8. ajax中打开新页面使用window.open方法被拦截的解决方法

    $('.testA').unbind('click').bind('click',function(){ var result=""; $.ajax({ url:'http://l ...

  9. javascript预解释中的机制

    预解释是一种毫无节操的机制(自从学了预解释,从此节操是路人) in:‘num’ in window 判断num是否为window这个对象的一个属性,是的话返回true,不是返回false 1.预解释的 ...

  10. Spring Boot 热部署(转)

    Spring Boot 热部署 实际开发中,修改某个页面数据或逻辑功能都需要重启应用.这无形中降低了开发效率,所以使用热部署是十分必要的. 什么是热部署? 应用启动后会把编译好的Class文件加载的虚 ...