分布式系统的消息&服务模式简单总结
在一个分布式系统中，有各种消息的处理，有各种服务模式，有同步异步，有高并发问题甚至应对高并发问题的Actor编程模型，本文尝试对这些问题做一个简单思考和总结。
一、消息的“推、拉模式”
在传统的Client/server结构中，信息获取方式是按“拉”(Pull)的模型进行的：服务器根据用户终端发送的服务请求进行处理并返回用户所需的结果。在Push系统中，服务器把信息“推”给用户终端系统。虽然两者数据传输的方向都是从服务器流向用户，但操作的发起者是不同的。从“信源”与“用户”的关系来看，信息的流动可分为两种模式，即信息推送与信息拉取模式。
在成熟的消息队列产品中，对消息的获取，也分为消息拉取模式和消息推送模式，这两种模式各有优点，需要根据应用的特定来选择。
Push“推”的好处包括：
1、高效。如果没有更新发生，不会有任何更新消息推送的动作，即每次消息推送都发生在确确实实的更新事件之后，都是有意义的。
2、实时。事件发生后的第一时间即可触发通知操作。
3、可以由订阅者确立通知的时间，可以避开一些繁忙时间。
4、可以表达出不同事件发生的先后顺序。
Pull“拉”的好处包括：
1、如果观察者众多，订阅者来维护订阅者的列表，可能困难，或者臃肿，把订阅关系解脱到观察者去完成。
2、观察者可以不理会它不关心的变更事件，只需要去获取自己感兴趣的事件即可。
3、观察者可以自行决定获取更新事件的时间。
4、拉的形式可以让订阅者更好地控制各个观察者每次查询更新的访问权限。
二、同步、异步和并行
一个大型的程序系统常常是由很多不能功能模块组成的。程序系统运行时不同功能模块要按一定顺序执行，以协同完成一件任务。功能模块协作运行完成一件任务存在同步和异步两种方式。
如果在某一时间段，这个程序系统的所有功能模块都在为完成相同的一件任务而服务，某一个功能模块在完成一件任务的子任务后，需要等待其他功能模块完成子任务，这样只有当全部功能模块按顺序完成一件任务后，程序系统才能接收下一个任务，功能模块是串行运行，这称之为同步模式。
反之，在某一时间段，这个程序系统的不同功能模块可以独立运行完成一件任务的子任务，无须等待其他功能模块完成子任务就可以继续处理下一件任务的子任务，功能模块是并行运行，这称之为异步模式。
反映在OLTP程序系统中，一个交易就是一个任务。如程序系统一次只完成一个交易，在这个交易没有完成前，程序系统不接受其他交易，这就是同步模式。如程序系统把交易任务分拆成几个独立的子进程，每个子进程独立完成交易的一个子任务，几个子进程同时运行，这就是异步模式。由于交易在模块之间是按照一定顺序运行的，所以对一个具体交易而言，模块之间任务执行时并不表现为并行运行，但对大批量交易的宏观效果而言，模块之间却是表现为并行运行。
三、服务的处理模式
消息获取的“推、拉模式”，实际上是站在消息的消费者，也就是客户端的角度来说的，即消息是服务器退给我，还是我去拉取消息的问题。如果站在服务器的角度，也就是消息的生产者来看，也有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的“推送模式”分为定时推送模式和事件推送模式，事件推送模式的意思是将服务器发生的事件作为消息推送到客户端，然后客户端响应此事件类型的消息，等同于客户端订阅了服务器的事件，本质上就是一种“分布式事件”了。
五，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编程模型。