追求簡單的設計.

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

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

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

好回歸正題，先上圖：

每層的角色職責分別為:

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

2:Guitar.Comet.Client ?封裝基于SignalR的客戶端實現.

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

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

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

3:Guitar.Comet.Host ? 封裝基于SignalR的服務端實現.

　　　　(1) 分發消息給訂閱的消費者;

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

?

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

?Guitar.Comet層的類圖:

?

?

Guitar.Comet.Client層的類圖:

?

?

類圖關系就不多說了，看源碼部分即可.

設計是偏技術的，但還是要立足于業務需求的，而領域設計既迎合了技術又重視業務,那什么是領域我理解的領域是代表者客觀事實規律，而領域設計我覺的是面向對象式的去表示客觀事實,技術和領域相輔相成，沒有技術則領域無法落地，沒有領域技術顯的沒有價值，那如何面向領域去思考設計，我看一些牛人的文章使用四元模式，即明確實體，角色，描述及時刻.我比較認同.

?

? ? ? 簡單的設計，不簡單的業務.持續優化重構.

?

轉載于:https://www.cnblogs.com/wangzhiyong/p/3906996.html

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。