CS模式（客戶端/伺服器模式） 最場景的信息傳遞模式，也稱為Request/Response模式，或者調用模式。http/https協議即此模式。因為最常用所以大家一般都比較熟悉，這裡不重點講了，大家請看圖下圖： 發佈/訂閱模式(Publish/Subscribe) 發佈訂閱模式相對於BS模式稍微難 ...
CS模式（客戶端/伺服器模式）
最場景的信息傳遞模式，也稱為Request/Response模式，或者調用模式。http/https協議即此模式。因為最常用所以大家一般都比較熟悉，這裡不重點講了，大家請看圖下圖：
發佈/訂閱模式(Publish/Subscribe)
發佈訂閱模式相對於BS模式稍微難點，我們不妨先看一個生活中的小例子：
如果沒有郵局會怎麼樣？毫無疑問出版社既要發行雜誌又要把雜誌投遞給用戶，不僅累而且極其低效！因為大部分時間都將耽誤在投遞上，發行雜誌的事情還有肯能被耽誤！此例子可以理解為生活中的"發佈訂閱模式"
理解完生活中的事例，我們再來看發佈訂閱模式在軟體開發中的重要作用！我們先看下圖：
這是一個新聞入庫程式的實現的流程，我們來看看此流程有什麼問題：
-
邏輯會越來越複雜：不停將新功能追加後面必然導致程式越來越複雜。
-
非非同步流程：程式是串列執行的，只有確認推送成功後才會走到寫入elasticsearch流程。意味著可能有進程等待，程式執行過程將會較長，甚至會超時。
-
不穩定：只要中間任何一個流程掛掉了，整個程式就掛了，無法走到後面的流程。
再看採用發佈訂閱模式處理流程：
可以看到新聞入庫過程被簡化了，只有新聞寫入資料庫和發佈到kafka兩個過程。其他的處理程式採用訂閱kafka中的新聞消息來實現了各自功能，我們再來看看這樣處理有什麼好處：
-
新聞入庫簡化且幾乎不再變更。
-
處理流程是非同步的：新聞發佈到kafka後就可以給用戶返回新聞入庫成功，用戶體驗好！後面的事情其他程式會非同步去完成。
-
一個程式被拆分成多個程式，每個程式都不算複雜。
-
即使有一個程式（例如推送程式）掛掉了，其他程式依然可以穩定運行。
總結髮布/訂閱模式：
我們可以看到發佈訂閱模式有3個角色，分別是一個生產者，一個消息管理器，多個消費者，生產者將消息發佈到消息管理器，而多個消息消費者則會訂閱消息管理器中消費者發佈的內容。這便是發佈訂閱模式的基本組成。
發佈訂閱模式的意義：
-
降低系統耦合性。
-
提供系統穩定性。
-
系統更加靈活
-
降低每個程式的複雜度
...
本節就先分析到這來了！
仁者見仁智者見智，歡迎大家評論指正！
分享或關註公眾號的帥哥會越來越帥！美女會越來越美！
