追求簡單的設(shè)計.

也許你的設(shè)計功能很強(qiáng)大，但能夠在滿足你需求的前提下盡量簡單明了設(shè)計.

當(dāng)你的設(shè)計過于復(fù)雜的時候想想是不是有其它路可以走,你站在別人的角度想下，如果別人看了你的設(shè)計會不會心領(lǐng)神會，還是焦頭爛額.

當(dāng)然我們可以站在牛人的肩膀上，有很多的設(shè)計模式可以借鑒，拿來主義未嘗不可.

好回歸正題，先上圖：

每層的角色職責(zé)分別為:

1:Guitar.Comet ?封裝通用接口,包括消費(fèi)者接口，消息接口，消息總線接口，客戶端接口(抽象為兩種模式：1為推模式，2為拉模式)，消息分發(fā)器接口，另外抽象出消息體模型.為了能夠支持各種消息格式，我定義的字段比較泛化，包括消息名，發(fā)送時間，ID(GUID),消息體（以key/value形式存儲），發(fā)送的客戶端名.

2:Guitar.Comet.Client ?封裝基于SignalR的客戶端實(shí)現(xiàn).

　　　　(1)消息分發(fā)到服務(wù)端（目前單線程異步分發(fā)）;

　　　　(2)代理客戶端,訂閱消息,監(jiān)聽消費(fèi)者，響應(yīng)消費(fèi)者支持同步和異步兩種方式,如果消息是無序的，無相關(guān)性則可異步處理.如果非得讓消息有序處理，那也行！當(dāng)然這可能造成阻塞.

　　　　(3)長連接/斷開后重連服務(wù)端機(jī)制;客戶端連接上服務(wù)端后，連接通達(dá)一直打開（其實(shí)有定時 間隔的重連的）,如果服務(wù)端offline，那客戶端肯定保證消息不會丟，其次當(dāng)服務(wù)端online后客戶端重連服務(wù)端并繼續(xù)發(fā)消息.

3:Guitar.Comet.Host ? 封裝基于SignalR的服務(wù)端實(shí)現(xiàn).

　　　　(1) 分發(fā)消息給訂閱的消費(fèi)者;

　　　　(2) 當(dāng)消費(fèi)者端口后負(fù)責(zé)重試發(fā)送，一旦消費(fèi)者online,消息重新推給訂閱者消費(fèi)，當(dāng)然這只是在消息沒有過期的前提下，不然消費(fèi)者一下收到N封消息，那怎么受得了，所以這里面有個消費(fèi)消息的策略，給消息指定過期時間或統(tǒng)一消息在指定時間內(nèi)有效;

?

那為什么這樣分層：我主要考慮三點(diǎn):一是角色職責(zé)劃分,二是獨(dú)立性（可測試性）要求,三是用戶使用要求;有時候我們會比較糾結(jié)分一個什么層，我們的類文件到底放在那一層（無法安放的類）.我覺的從上面3點(diǎn)考慮會清晰點(diǎn).

?Guitar.Comet層的類圖:

?

?

Guitar.Comet.Client層的類圖:

?

?

類圖關(guān)系就不多說了，看源碼部分即可.

設(shè)計是偏技術(shù)的，但還是要立足于業(yè)務(wù)需求的，而領(lǐng)域設(shè)計既迎合了技術(shù)又重視業(yè)務(wù),那什么是領(lǐng)域我理解的領(lǐng)域是代表者客觀事實(shí)規(guī)律，而領(lǐng)域設(shè)計我覺的是面向?qū)ο笫降娜ケ硎究陀^事實(shí),技術(shù)和領(lǐng)域相輔相成，沒有技術(shù)則領(lǐng)域無法落地，沒有領(lǐng)域技術(shù)顯的沒有價值，那如何面向領(lǐng)域去思考設(shè)計，我看一些牛人的文章使用四元模式，即明確實(shí)體，角色，描述及時刻.我比較認(rèn)同.

?

? ? ? 簡單的設(shè)計，不簡單的業(yè)務(wù).持續(xù)優(yōu)化重構(gòu).

?

轉(zhuǎn)載于:https://www.cnblogs.com/wangzhiyong/p/3906996.html

總結(jié)

以上是生活随笔為你收集整理的分享基于分布式Http长连接框架--设计模型的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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