在一個分布式系統(tǒng)中，有各種消息的處理，有各種服務(wù)模式，有同步異步，有高并發(fā)問題甚至應(yīng)對高并發(fā)問題的Actor編程模型，本文嘗試對這些問題做一個簡單思考和總結(jié)。

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

? ? 在傳統(tǒng)的Client/Server結(jié)構(gòu)中，信息獲取方式是按“拉”(Pull)的模型進(jìn)行的：服務(wù)器根據(jù)用戶終端發(fā)送的服務(wù)請求進(jìn)行處理并返回用戶所需的結(jié)果。在Push系統(tǒng)中，服務(wù)器把信息“推”給用戶終端系統(tǒng)。雖然兩者數(shù)據(jù)傳輸?shù)姆较蚨际菑姆?wù)器流向用戶，但操作的發(fā)起者是不同的。從“信源”與“用戶”的關(guān)系來看，信息的流動可分為兩種模式，即信息推送與信息拉取模式。
? ? 在成熟的消息隊列產(chǎn)品中，對消息的獲取，也分為消息拉取模式和消息推送模式，這兩種模式各有優(yōu)點，需要根據(jù)應(yīng)用的特點來選擇。

Push“推”的好處包括：
1、高效。如果沒有更新發(fā)生，不會有任何更新消息推送的動作，即每次消息推送都發(fā)生在確確實實的更新事件之后，都是有意義的。
2、實時。事件發(fā)生后的第一時間即可觸發(fā)通知操作。
3、可以由發(fā)布者確立通知的時間，可以避開一些繁忙時間。
4、可以表達(dá)出不同事件發(fā)生的先后順序。
?
Pull“拉”的好處包括：
1、如果觀察者眾多，訂閱者來維護(hù)訂閱者的列表，可能困難，或者臃腫，把訂閱關(guān)系解脫到觀察者去完成。
2、觀察者可以不理會它不關(guān)心的變更事件，只需要去獲取自己感興趣的事件即可。
3、觀察者可以自行決定獲取更新事件的時間。
4、拉的形式可以讓訂閱者更好地控制各個觀察者每次查詢更新的訪問權(quán)限。

二、同步、異步和并行

? ? 一個大型的程序系統(tǒng)常常是由很多不能功能模塊組成的。程序系統(tǒng)運行時不同功能模塊要按一定順序執(zhí)行，以協(xié)同完成一件任務(wù)。功能模塊協(xié)作運行完成一件任務(wù)存在同步和異步兩種方式。
? ? 如果在某一時間段，這個程序系統(tǒng)的所有功能模塊都在為完成相同的一件任務(wù)而服務(wù)，某一個功能模塊在完成一件任務(wù)的子任務(wù)后，需要等待其他功能模塊完成子任務(wù)，這樣只有當(dāng)全部功能模塊按順序完成一件任務(wù)后，程序系統(tǒng)才能接收下一個任務(wù)，功能模塊是串行運行，這稱之為同步模式。
? ? 反之，在某一時間段，這個程序系統(tǒng)的不同功能模塊可以獨立運行完成一件任務(wù)的子任務(wù)，無須等待其他功能模塊完成子任務(wù)就可以繼續(xù)處理下一件任務(wù)的子任務(wù)，功能模塊是并行運行，這稱之為異步模式。
? ? 反映在OLTP程序系統(tǒng)中，一個交易就是一個任務(wù)。如程序系統(tǒng)一次只完成一個交易，在這個交易沒有完成前，程序系統(tǒng)不接受其他交易，這就是同步模式。如程序系統(tǒng)把交易任務(wù)分拆成幾個獨立的子進(jìn)程，每個子進(jìn)程獨立完成交易的一個子任務(wù)，幾個子進(jìn)程同時運行，這就是異步模式。由于交易在模塊之間是按照一定順序運行的，所以對一個具體交易而言，模塊之間任務(wù)執(zhí)行時并不表現(xiàn)為并行運行，但對大批量交易的宏觀效果而言，模塊之間卻是表現(xiàn)為并行運行。

?

三、服務(wù)的處理模式

? ? 消息獲取的“推、拉模式”，實際上是站在消息的消費者，也就是客戶端的角度來說的，即消息是服務(wù)器推送給我，還是我去拉取消息的問題。如果站在服務(wù)器的角度，也就是消息的生產(chǎn)者來看，也有2種模式。

2.1，“請求-響應(yīng)”模式?

? ? 這是絕大部分Client/Server結(jié)構(gòu)對信息的處理模式，服務(wù)器提供不間斷的服務(wù)，等待客戶端的請求。一旦接收到客戶端的請求，服務(wù)器馬上處理該請求，然后生成處理結(jié)果，最后將結(jié)果響應(yīng)給客戶端。請求-響應(yīng)模式通常是一對一的響應(yīng)，客戶端主動發(fā)起請求，服務(wù)端被動響應(yīng)。典型的例子就是HTTP服務(wù)器。
? ? 請求-響應(yīng)模式要求服務(wù)器能夠?qū)崟r的進(jìn)行響應(yīng)，客戶端接收到響應(yīng)后在進(jìn)行下一步處理，因此它的處理過程常常是“同步”的。但有時候，客戶端發(fā)出的請求服務(wù)端需要進(jìn)行長時間的處理才能返回結(jié)果給客戶端，讓客戶端長時間等待就不合理了，這時候可以使用異步處理技術(shù)，客戶端發(fā)出請求后就返回到自己的處理線程，服務(wù)器處理完成后回調(diào)客戶端提供的方法。廣泛流行的Ajax 即“Asynchronous Javascript And XML”（異步 JavaScript 和 XML），就是這種異步處理請求-響應(yīng)模式的方案，它提供了一種創(chuàng)建交互式網(wǎng)頁應(yīng)用的網(wǎng)頁開發(fā)技術(shù)。

2.2，“發(fā)布-訂閱”模式

? ? 有時候，不要求服務(wù)器收到請求后立刻給客戶端響應(yīng)結(jié)果，而是在隨后的某個時間，服務(wù)器才能處理完成結(jié)果或者說生產(chǎn)消息，通過某種方式送到客戶端。這種通信模式特別像報刊的訂閱：出版社出版一份報刊，讀者訂閱此報刊，然后出版社通過郵局將報刊定期投遞到讀者手中。所以我們將這種通信模式形象的稱呼為“發(fā)布-訂閱”模式，即服務(wù)器（發(fā)布者）發(fā)布一個消息主題，客戶端（訂閱者）訂閱此主題，然后服務(wù)器定期或者不定期的將消息推送給客戶端。

? ? 由于“發(fā)布-訂閱”模式消息不能及時響應(yīng)給客戶端的特點，所以通常實現(xiàn)為異步處理模式，客戶端提供一個回掉函數(shù)，服務(wù)端有消息的時候這個回掉函數(shù)被調(diào)用。

? ? 受限于Client/Server結(jié)構(gòu)兩端所處的位置不同，客戶端可能在內(nèi)網(wǎng)通過NAT方式上網(wǎng)，并且HTTP短連接的應(yīng)用特點，Client/Server并不是實時連接的，服務(wù)器無法主動連接客戶端，那么消息也就無法實時推送給客戶端，只有客戶端不斷的請求服務(wù)器來獲取最新的消息，于是出現(xiàn)了“長輪詢”（long-pull）技術(shù)，服務(wù)器會Hold住客戶端的連接，如果在超時之前還沒有結(jié)果，那么服務(wù)器生成一個空消息給客戶端；客戶端收到此空消息后再次發(fā)起請求，知道收到服務(wù)器真正的消息為止。
? ? 但是，長輪詢需要消耗過多的服務(wù)器資源和網(wǎng)絡(luò)資源，并且瀏覽器的并發(fā)請求數(shù)通常也有限制，所以長輪詢并不是一個很好的方案，如果服務(wù)器能夠主動將消息推送給客戶端就可以避免這些問題，于是基于“長連接”的消息推送技術(shù)產(chǎn)生了，WebSocket就是這樣一種技術(shù)：瀏覽器發(fā)起一個普通請求，告訴服務(wù)器這是一個WebSocket請求，然后服務(wù)器升級服務(wù)處理級別，切換到Socket處理方式，與客戶端瀏覽器建立Soket通信通道，當(dāng)服務(wù)器有消息后就推送給瀏覽器。
? ? 如果客戶端不是瀏覽器，可以直接和服務(wù)器建立Socket通信并保持為長連接，由服務(wù)器推送消息給客戶端。比如PDF.NET的消息服務(wù)器框架（MSF），就是基于WCF的TCP雙工長連接，來實現(xiàn)服務(wù)器推送消息的。

? ? 所以，“發(fā)布-訂閱”是一種服務(wù)模式，它可以通過短連接的客戶端輪詢請求（pull）或者基于長連接的服務(wù)器主動推送(push)來實現(xiàn)。消息的“推、拉模式”，均可實現(xiàn)“發(fā)布-訂閱”這種種服務(wù)模式。

四，消息服務(wù)框架（MSF）的服務(wù)模式

? ? 消息服務(wù)框架（MSF）支持前面講的兩種服務(wù)模式：“請求-響應(yīng)”模式，“發(fā)布-訂閱”模式。在MSF的具體實現(xiàn)中，“請求-響應(yīng)”模式是“發(fā)布-訂閱”模式的特例，內(nèi)部都是通過后者的基礎(chǔ)實現(xiàn)的，可以這么認(rèn)為：“請求-響應(yīng)”模式是一種及時響應(yīng)的，一對一消息推送的“發(fā)布-訂閱”模式，也就是說，前者只有一個客戶端，或者有多個客戶端。MSF的這種處理模式，得到一個意外的結(jié)果：

? 同一個服務(wù)，既可以是“請求-響應(yīng)”模式的，又可以是“發(fā)布-訂閱”模式，具體取決于客戶端的調(diào)用方式。

有關(guān)MSF的兩種服務(wù)模式，請參考前篇：
《“一切都是消息”--MSF（消息服務(wù)框架）之【請求-響應(yīng)】模式 》
《“一切都是消息”--MSF（消息服務(wù)框架）之【發(fā)布-訂閱】模式》 ??

? ? 兩種模式從主動性上來看，“請求-響應(yīng)”模式是客戶端主動的，所以我將它簡稱為 “請求模式”，而“發(fā)布-訂閱”模式是服務(wù)器主動的，所以我將它簡稱為 “推送模式”。

??? ?MSF的“請求模式”也支持服務(wù)器推送消息，即在一次請求過程中，服務(wù)器可以多次推送消息給客戶端，“回調(diào)”客戶端提供的函數(shù)，所以這種回調(diào)結(jié)果通常作為服務(wù)器最終響應(yīng)結(jié)果的“中間結(jié)果”。比如請求一個文件上傳服務(wù)，服務(wù)器多次回調(diào)客戶端，讀取客戶端的文件數(shù)據(jù)。

? ? MSF的“推送模式”分為定時推送模式和事件推送模式，事件推送模式的意思是將服務(wù)器發(fā)生的事件作為消息推送到客戶端，然后客戶端響應(yīng)此事件類型的消息，等同于客戶端訂閱了服務(wù)器的事件，本質(zhì)上就是一種“分布式事件”了。

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

? ? Actor編程模型是一種基于消息處理的并發(fā)編程模型，它有幾個典型特點：

• Actor之間只通過消息進(jìn)行通信，沒有觀察者模式或者事件代碼的耦合；

• Actor的內(nèi)部狀態(tài)只能由自己改變

• Actor可以通過消息激活別的Actor以創(chuàng)建響應(yīng)式的任務(wù)，這種類型的任務(wù)處理是易于并行處理的。

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

• “請求-響應(yīng)”模式：每次請求，服務(wù)器會創(chuàng)建一個獨立的服務(wù)對象實例；

• “發(fā)布-訂閱”模式：每一個相同“主題”的訂閱，服務(wù)器會創(chuàng)建同一個服務(wù)對象實例。

? ? 這里說的“主題”，指的是相同的服務(wù)名，相同的方法名和相同的參數(shù)值，在MSF中，也稱呼為“訂閱任務(wù)”。客戶端訂閱不同的主題，服務(wù)端會創(chuàng)建不同的服務(wù)對象實例。

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

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

? ? 假設(shè)客戶端A激活了服務(wù)端B服務(wù)，而服務(wù)端B服務(wù)又去調(diào)用服務(wù)端C服務(wù)，將激活服務(wù)端C服務(wù).....一個分布式對象服務(wù)的鏈?zhǔn)郊せ钸^程開啟了。你只需要去調(diào)用需要的服務(wù)，服務(wù)的激活和服務(wù)對象的銷毀，MSF框架會幫你搞定一切。

? ? 總之，MSF的這種服務(wù)之間的通信都是通過消息進(jìn)行的，對象之間只有消息，并且是分布式的消息，所以，MSF是一個真正的分布式Actor編程模型。

原文地址:https://www.cnblogs.com/bluedoctor/p/8127122.html

---

.NET社區(qū)新聞，深度好文，歡迎訪問公眾號文章匯總 http://www.csharpkit.com

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅持創(chuàng)作打卡瓜分現(xiàn)金大獎

總結(jié)

以上是生活随笔為你收集整理的分布式系统的消息服务模式简单总结的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。