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

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

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

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

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

二、同步、异步和并行

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

 

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

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

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

    这是绝大部分Client/Server结构对信息的处理模式，服务器提供不间断的服务，等待客户端的请求。一旦接收到客户端的请求，服务器马上处理该请求，然后生成处理结果，最后将结果响应给客户端。请求-响应模式通常是一对一的响应，客户端主动发起请求，服务端被动响应。典型的例子就是HTTP服务器。
    请求-响应模式要求服务器能够实时的进行响应，客户端接收到响应后在进行下一步处理，因此它的处理过程常常是“同步”的。但有时候，客户端发出的请求服务端需要进行长时间的处理才能返回结果给客户端，让客户端长时间等待就不合理了，这时候可以使用异步处理技术，客户端发出请求后就返回到自己的处理线程，服务器处理完成后回调客户端提供的方法。广泛流行的Ajax 即“Asynchronous java script And XML”（异步 java script 和 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的具体实现中，“请求-响应”模式是“发布-订阅”模式的特例，内部都是通过后者的基础实现的，可以这么认为：“请求-响应