CS模式（客戶端/服務器模式）

最場景的信息傳遞模式，也稱為Request/Response模式，或者調用模式。http/https協議即此模式。因為最常用所以大家一般都比較熟悉，這裏不重點講了，大家請看圖下圖：

發布/訂閱模式(Publish/Subscribe)

發布訂閱模式相對於BS模式稍微難點，我們不妨先看一個生活中的小例子：

如果沒有郵局會怎麽樣？毫無疑問出版社既要發行雜誌又要把雜誌投遞給用戶，不僅累而且極其低效！因為大部分時間都將耽誤在投遞上，發行雜誌的事情還有肯能被耽誤！此例子可以理解為生活中的"發布訂閱模式"

理解完生活中的事例，我們再來看發布訂閱模式在軟件開發中的重要作用！我們先看下圖：

這是一個新聞入庫程序的實現的流程，我們來看看此流程有什麽問題：

1. 邏輯會越來越復雜：不停將新功能追加後面必然導致程序越來越復雜。

2. 非異步流程：程序是串行執行的，只有確認推送成功後才會走到寫入elasticsearch流程。意味著可能有進程等待，程序執行過程將會較長，甚至會超時。

3. 不穩定：只要中間任何一個流程掛掉了，整個程序就掛了，無法走到後面的流程。

再看采用發布訂閱模式處理流程：

可以看到新聞入庫過程被簡化了，只有新聞寫入數據庫和發布到kafka兩個過程。其他的處理程序采用訂閱kafka中的新聞消息來實現了各自功能，我們再來看看這樣處理有什麽好處：

1. 新聞入庫簡化且幾乎不再變更。

2. 處理流程是異步的：新聞發布到kafka後就可以給用戶返回新聞入庫成功，用戶體驗好！後面的事情其他程序會異步去完成。

3. 一個程序被拆分成多個程序，每個程序都不算復雜。

4. 即使有一個程序（例如推送程序）掛掉了，其他程序依然可以穩定運行。

總結發布/訂閱模式：

我們可以看到發布訂閱模式有3個角色，分別是一個生產者，一個消息管理器，多個消費者，生產者將消息發布到消息管理器，而多個消息消費者則會訂閱消息管理器中消費者發布的內容。這便是發布訂閱模式的基本組成。

發布訂閱模式的意義：

1. 降低系統耦合性。

2. 提供系統穩定性。

3. 系統更加靈活

4. 降低每個程序的復雜度

...

本節就先分析到這來了！

仁者見仁智者見智，歡迎大家評論指正！

分享或關註公眾號的帥哥會越來越帥！美女會越來越美！

C/S模式，發布/訂閱模式和PUSH/PULL模式（上）