在一個分散式系統中，有各種消息的處理，有各種服務模式，有同步非同步，有高併發問題甚至應對高併發問題的Actor編程模型，本文嘗試對這些問題做一個簡單思考和總結。 ...

分散式系統的消息&服務模式簡單總結

在一個分散式系統中，有各種消息的處理，有各種服務模式，有同步非同步，有高併發問題甚至應對高併發問題的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的“請求模式”也支持伺服器推送消息，即在一次請求過程中，伺服器可以多次推送消息給客戶端，“回調”客戶端提供的函數，所以這種回調結果通常作為伺服器最終響應結果的“中間結果”。比如請求一個文件上傳服務，伺服器多次回調客戶端，讀取客戶端的文件數據。

MSF的“推送模式”分為定時推送模式和事件推送模式，事件推送模式的意思是將伺服器發生的事件作為消息推送到客戶端，然後客戶端響應此事件類型的消息，等同於客戶端訂閱了伺服器的事件，本質上就是一種“分散式事件”了。

五，Actor對象的激活與生命周期

Actor編程模型是一種基於消息處理的併發編程模型，它有幾個典型特點：

Actor之間只通過消息進行通信，沒有觀察者模式或者事件代碼的耦合；
Actor的內部狀態只能由自己改變
Actor可以通過消息激活別的Actor以創建響應式的任務，這種類型的任務處理是易於並行處理的。

消息服務框架（MSF）是基於分散式消息處理的框架，在設計上它具有Actor模式的特點，MSF的每個服務對象實例都是一個Actor，MSF通過不同的服務模式來控制Actor的生命周期：

“請求-響應”模式：每次請求，伺服器會創建一個獨立的服務對象實例；
“發佈-訂閱”模式：每一個相同“主題”的訂閱，伺服器會創建同一個服務對象實例。

這裡說的“主題”，指的是相同的服務名，相同的方法名和相同的參數值，在MSF中，也稱呼為“訂閱任務”。客戶端訂閱不同的主題，服務端會創建不同的服務對象實例。

不管是哪種服務模式，MSF的服務對象實例（Actor）它的生命周期都會執行到服務方法執行完成，但是“發佈-訂閱”服務模式的服務對象實例，它執行完成任務後可以繼續等待直到設定的超時時間之後，這樣不必創建新的服務對象而接受下一次的訂閱請求。當然，也可以在服務的訂閱任務處理完成後，通過編碼及時停止服務而不等待。

創建同一個服務對象實例有一個很大的好處，它讓多個訂閱的客戶端共用了同一個服務對象實例，將會非常有用。
比如客戶端訂閱了產品A的服務，相當於客戶端激活了服務端的一個對象，這個對象將存活到它的任務處理完成為止。如果另外一個客戶端也訂閱了產品A的服務，新客戶端將一樣收到服務端推送過來的消息。

假設客戶端A激活了服務端B服務，而服務端B服務又去調用服務端C服務，將激活服務端C服務.....一個分散式對象服務的鏈式激活過程開啟了。你只需要去調用需要的服務，服務的激活和服務對象的銷毀，MSF框架會幫你搞定一切。