一、 訂閱雜誌
我們很多人都訂過雜誌，其過程很簡單。只要告訴郵局我們所要訂的雜誌名、投遞的地址，付了錢就OK。出版社定期會將出版的雜誌交給郵局，郵局會根據訂閱的列表，將雜誌送達消費者手中。這樣我們就可以看到每一期精彩的雜誌了。
仔細思考一下訂雜誌的過程，我們會發現這樣幾個特點：
1、 消費者訂雜誌不需要直接找出版社；
2、 出版社只需要把雜誌交給郵局；
3、 郵局將雜誌送達消費者。
郵局在整個過程中扮演了非常重要的中轉作用，在出版社和消費者相互不需要知道對方的情況下，郵局完成了雜誌的投遞。
二、 發佈-訂閱消息模式
剛剛講了訂閱雜誌，下面我們會講傳統調用模式演化到發佈-訂閱消息模式。
有些網站在註冊用戶成功後發一封激活郵件，用戶收到郵件後點擊激活鏈接後才能使用該網站。一般的做法是在註冊用戶業務邏輯中調用發送郵件的邏輯。這樣用戶業務就依賴於郵件業務。如果以後改爲短信激活，註冊用戶業務邏輯就必須修改爲調用發送短信的邏輯。如果要註冊後給用戶加點積分，再加一段邏輯。經過多次修改，我們發現很簡單的註冊用戶業務已經越來越複雜，越來越難以維護。相信很多開發者都會有類似痛苦的經歷。
即使用戶業務實現中對其他業務是接口依賴，也避免不了業務變化帶來的依賴影響。怎麼辦？解耦！將註冊用戶業務邏輯中註冊成功後的處理剝離出來。
再回頭看看“訂閱雜誌”，如果沒有郵局，出版社就必須自己將雜誌送達所有消費者。這種情形就和現在的註冊用戶業務一樣。我們發現問題了，在用戶業務和其他業務之間缺少了郵局所扮角色。
我們把郵局抽象成一個管理消息的地方，叫“消息管理器”。註冊用戶成功後發送一個消息給消息管理器，由消息管理器轉發該消息給需要處理的業務。現在，用戶業務只依賴於消息管理器了，它再也不會爲了註冊用戶成功後的其他處理而煩惱。
註冊用戶的改造就是借鑑了“訂閱雜誌”這樣原始的模式。我們再進一步抽象，用戶業務就是消息的“生產者”，它將消息發佈到消息管理器。郵件業務就是消息的“消費者”，它將收到的消息進行處理。郵局可以訂閱很多種雜誌，雜誌都是通過某種編號來區分；消息管理器也可以管理多種消息，每種消息都會有一個“主題”來區分，消費者都是通過主題來訂閱的。
發佈-訂閱消息模式已經呈現在我們面前，利用它可以產生更靈活、更鬆散耦合的系統。
接下來，我會講解基於該模式在本地系統和分佈式系統中的應用，敬請期待！