分布式系统的消息&服务模式简单总结

分布式系统的消息&服务模式简单总结

在一个分布式系统中，有各类消息的处理，有各类服务模式，有同步异步，有高并发问题甚至应对高并发问题的Actor编程模型，本文尝试对这些问题作一个简单思考和总结。

1、消息的“推、拉模式” 

    在传统的Client/Server结构中，信息获取方式是按“拉”(Pull)的模型进行的：服务器根据用户终端发送的服务请求进行处理并返回用户所需的结果。在Push系统中，服务器把信息“推”给用户终端系统。虽然二者数据传输的方向都是从服务器流向用户，但操做的发起者是不一样的。从“信源”与“用户”的关系来看，信息的流动可分为两种模式，即信息推送与信息拉取模式。
    在成熟的消息队列产品中，对消息的获取，也分为消息拉取模式和消息推送模式，这两种模式各有优势，须要根据应用的特色来选择。

Push“推”的好处包括：
一、高效。若是没有更新发生，不会有任何更新消息推送的动做，即每次消息推送都发生在确确实实的更新事件以后，都是有意义的。
二、实时。事件发生后的第一时间便可触发通知操做。
三、能够由发布者确立通知的时间，能够避开一些繁忙时间。
四、能够表达出不一样事件发生的前后顺序。
 
Pull“拉”的好处包括：
一、若是观察者众多，订阅者来维护订阅者的列表，可能困难，或者臃肿，把订阅关系解脱到观察者去完成。
二、观察者能够不理会它不关心的变动事件，只须要去获取本身感兴趣的事件便可。
三、观察者能够自行决定获取更新事件的时间。
四、拉的形式可让订阅者更好地控制各个观察者每次查询更新的访问权限。

2、同步、异步和并行

    一个大型的程序系统经常是由不少不能功能模块组成的。程序系统运行时不一样功能模块要按必定顺序执行，以协同完成一件任务。功能模块协做运行完成一件任务存在同步和异步两种方式。
    若是在某一时间段，这个程序系统的全部功能模块都在为完成相同的一件任务而服务，某一个功能模块在完成一件任务的子任务后，须要等待其余功能模块完成子任务，这样只有当所有功能模块按顺序完成一件任务后，程序系统才能接收下一个任务，功能模块是串行运行，这称之为同步模式。
    反之，在某一时间段，这个程序系统的不一样功能模块能够独立运行完成一件任务的子任务，无须等待其余功能模块完成子任务就能够继续处理下一件任务的子任务，功能模块是并行运行，这称之为异步模式。
    反映在OLTP程序系统中，一个交易就是一个任务。如程序系统一次只完成一个交易，在这个交易没有完成前，程序系统不接受其余交易，这就是同步模式。如程序系统把交易任务分拆成几个独立的子进程，每一个子进程独立完成交易的一个子任务，几个子进程同时运行，这就是异步模式。因为交易在模块之间是按照必定顺序运行的，因此对一个具体交易而言，模块之间任务执行时并不表现为并行运行，但对大批量交易的宏观效果而言，模块之间倒是表现为并行运行。

 

3、(消息)服务的处理模式

    消息获取的“推、拉模式”，其实是站在消息的消费者，也就是客户端的角度来讲的，即消息是服务器推送给我，仍是我去拉取消息的问题。若是站在服务器的角度，也就是消息的生产者来看，也有2种模式。

2.1，“请求-响应”模式（点对点） 

    这是绝大部分Client/Server结构对信息的处理模式，服务器提供不间断的服务，等待客户端的请求。一旦接收到客户端的请求，服务器立刻处理该请求，而后生成处理结果，最后将结果响应给客户端。请求-响应模式一般是一对一的响应，客户端主动发起请求，服务端被动响应。典型的例子就是HTTP服务器。
    请求-响应模式要求服务器可以实时的进行响应，客户端接收到响应后在进行下一步处理，所以它的处理过程经常是“同步”的。但有时候，客户端发出的请求服务端须要进行长时间的处理才能返回结果给客户端，让客户端长时间等待就不合理了，这时候可使用异步处理技术，客户端发出请求后就返回到本身的处理线程，服务器处理完成后回调客户端提供的方法。普遍流行的Ajax 即“Asynchronous Javascript And XML”（异步 JavaScript 和 XML），就是这种异步处理请求-响应模式的方案，它提供了一种建立交互式网页应用的网页开发技术。

2.2，“发布-订阅”模式

    有时候，不要求服务器收到请求后马上给客户端响应结果，而是在随后的某个时间，服务器才能处理完成结果或者说生产消息，经过某种方式送到客户端。这种通讯模式特别像报刊的订阅：出版社出版一份报刊，读者订阅此报刊，而后出版社经过邮局将报刊按期投递到读者手中。因此咱们将这种通讯模式形象的称呼为“发布-订阅”模式，即服务器（发布者）发布一个消息主题，客户端（订阅者）订阅此主题，而后服务器按期或者不按期的将消息推送给客户端。

    因为“发布-订阅”模式消息不能及时响应给客户端的特色，因此一般实现为异步处理模式，客户端提供一个回掉函数，服务端有消息的时候这个回掉函数被调用。

    受限于Client/Server结构两端所处的位置不一样，客户端可能在内网经过NAT方式上网，而且HTTP短链接的应用特色，Client/Server并非实时链接的，服务器没法主动链接客户端，那么消息也就没法实时推送给客户端，只有客户端不断的请求服务器来获取最新的消息，因而出现了“长轮询”（long-pull）技术，服务器会Hold住客户端的链接，若是在超时以前尚未结果，那么服务器生成一个空消息给客户端；客户端收到此空消息后再次发起请求，知道收到服务器真正的消息为止。
    可是，长轮询须要消耗过多的服务器资源和网络资源，而且浏览器的并发请求数一般也有限制，因此长轮询并非一个很好的方案，若是服务器可以主动将消息推送给客户端就能够避免这些问题，因而基于“长链接”的消息推送技术产生了，WebSocket就是这样一种技术：浏览器发起一个普通请求，告诉服务器这是一个WebSocket请求，而后服务器升级服务处理级别，切换到Socket处理方式，与客户端浏览器创建Soket通讯通道，当服务器有消息后就推送给浏览器。
    若是客户端不是浏览器，能够直接和服务器创建Socket通讯并保持为长链接，由服务器推送消息给客户端。好比PDF.NET的消息服务器框架（MSF），就是基于WCF的TCP双工长链接，来实现服务器推送消息的。

    因此，“发布-订阅”是一种服务模式，它能够经过短链接的客户端轮询请求（pull）或者基于长链接的服务器主动推送(push)来实现。消息的“推、拉模式”，都可实现“发布-订阅”这种种服务模式。

四，消息服务框架（MSF）的服务模式

    消息服务框架（MSF）支持前面讲的两种服务模式：“请求-响应”模式，“发布-订阅”模式。在MSF的具体实现中，“请求-响应”模式是“发布-订阅”模式的特例，内部都是经过后者的基础实现的，能够这么认为：“请求-响应”模式是一种及时响应的，一对一消息推送的“发布-订阅”模式，也就是说，前者只有一个客户端，或者有多个客户端。MSF的这种处理模式，获得一个意外的结果：

  同一个服务，既能够是“请求-响应”模式的，又能够是“发布-订阅”模式，具体取决于客户端的调用方式。

有关MSF的两种服务模式，请参考前篇：
《“一切都是消息”--MSF（消息服务框架）之【请求-响应】模式 》
《“一切都是消息”--MSF（消息服务框架）之【发布-订阅】模式》   

    两种模式从主动性上来看，“请求-响应”模式是客户端主动的，因此我将它简称为 “请求模式”，而“发布-订阅”模式是服务器主动的，因此我将它简称为 “推送模式”。

     MSF的“请求模式”也支持服务器推送消息，即在一次请求过程当中，服务器能够屡次推送消息给客户端，“回调”客户端提供的函数，因此这种回调结果一般做为服务器最终响应结果的“中间结果”。好比请求一个文件上传服务，服务器屡次回调客户端，读取客户端的文件数据。

    MSF的“推送模式”分为定时推送模式和事件推送模式，事件推送模式的意思是将服务器发生的事件做为消息推送到客户端，而后客户端响应此事件类型的消息，等同于客户端订阅了服务器的事件，本质上就是一种“分布式事件”了。

五，Actor对象的激活与生命周期

    Actor编程模型是一种基于消息处理的并发编程模型，它有几个典型特色：

• Actor之间只经过消息进行通讯，没有观察者模式或者事件代码的耦合；
• Actor的内部状态只能由本身改变
• Actor能够经过消息激活别的Actor以建立响应式的任务，这种类型的任务处理是易于并行处理的。

    消息服务框架（MSF）是基于分布式消息处理的框架，在设计上它具备Actor模式的特色，MSF的每一个服务对象实例都是一个Actor，MSF经过不一样的服务模式来控制Actor的生命周期：

• “请求-响应”模式：每次请求，服务器会建立一个独立的服务对象实例；
• “发布-订阅”模式：每个相同“主题”的订阅，服务器会建立同一个服务对象实例。

    这里说的“主题”，指的是相同的服务名，相同的方法名和相同的参数值，在MSF中，也称呼为“订阅任务”。客户端订阅不一样的主题，服务端会建立不一样的服务对象实例。

    无论是哪一种服务模式，MSF的服务对象实例（Actor）它的生命周期都会执行到服务方法执行完成，可是“发布-订阅”服务模式的服务对象实例，它执行完成任务后能够继续等待直到设定的超时时间以后，这样没必要建立新的服务对象而接受下一次的订阅请求。固然，也能够在服务的订阅任务处理完成后，经过编码及时中止服务而不等待。

    建立同一个服务对象实例有一个很大的好处，它让多个订阅的客户端共享了同一个服务对象实例，将会很是有用。
    好比客户端订阅了产品A的服务，至关于客户端激活了服务端的一个对象，这个对象将存活到它的任务处理完成为止。若是另一个客户端也订阅了产品A的服务，新客户端将同样收到服务端推送过来的消息。

    假设客户端A激活了服务端B服务，而服务端B服务又去调用服务端C服务，将激活服务端C服务.....一个分布式对象服务的链式激活过程开启了。你只须要去调用须要的服务，服务的激活和服务对象的销毁，MSF框架会帮你搞定一切。

    总之，MSF的这种服务之间的通讯都是经过消息进行的，对象之间只有消息，而且是分布式的消息，因此，MSF是一个真正的分布式Actor编程模型。

 

MSF消息和服务的总结

MSF的服务分为“请求订阅”和“推送订阅”：

l  “请求订阅”是客户端和服务端进行的点对点消息通讯，服务端能够按需屡次调用客户端提供的回调函数；

l  “推送订阅”采用的是一对多的消息推送模式，服务端会向订阅同一个消息主题的每一个客户端推送一样的消息。

MSF.Host会为每个“请求订阅”的客户端建立一个服务于它的新的服务实例对象，客户端关闭链接后服务端实例会自动释放；而对于“推送订阅”，它在第一个客户端发起订阅的时候建立一个服务实例对象，此后其它订阅此消息的客户端都会使用一样一个服务实例对象，期间任意一个客户端均可以断开后从新链接，而服务端实例对象会一直工做到没有任何客户端链接它，或者在“事件推送”模式下工做到全部的事件处理完成自行结束工做线程为止。