之前在資料庫章節有提到過資料庫的平滑遷移，比如追日誌、雙寫等策略，對於mq，作為訊息中介軟體，也是某種資料儲存設施，也存在公升級需求，比如要講activemq換成rabbitmq，也就同樣需要平滑遷移的方案。
mq架構回顧
乙個簡單的mq架構主要由三部分組成，訊息傳送方的mq客戶端，mq服務端（可以是集群），訊息接收方的mq客戶端。
那麼要實現平滑遷移，替換mq**商，我們就需要替換掉至少三個部分，傳送發的mq client，mq server，接收方的mq client.
平滑遷移方案
遷移目標：不停服，平滑遷移。
如果按照主題來進行遷移，通常有三個步驟：
1 消費方雙向訂閱
假設我們的遷移目標是將全部的粉色mq元件替換為藍色，即發布、服務、訂閱都要變成新的mq元件。
第一步就是消費方的雙向訂閱，新增藍色的mq server，並在消費方內新增藍色的mq client去訂閱新的mq server。
此時，mq依舊走的全部都是舊的元件，因為藍色新的還沒有訊息傳送方到mq server的tcp連線，它還沒有任何訊息。
2 生產方公升級為新發布
第二步生產方訊息發布由舊的發布替換為新的發布，這個時候雖然訊息的訂閱方還保持著連線，這可以讓它們消費完剩下的訊息，但是已經不會有新的訊息再增加了。
3 消費方下線舊訂閱
第三步當然就是顯而易見的了，我們只需要把訂閱方的舊**移除即可，至此就完成了從全粉到全藍的替換。
按主題的平滑遷移總共分為三步：
消費方雙向訂閱
生產方公升級為新發布
下線舊的訂閱
淺淺的封裝一層
如果不僅是單個主題，而是整個服務要進行遷移呢？
這裡在前面第一章內容裡面提到的「淺淺封裝一層」會非常關鍵。因為這樣子對於業務層來說不需要關心底層的mq元件是什麼，而只需要依賴封裝的元件即可，介面本身是不會變化的。
假如沒有淺淺的封裝一層，那麼就會是直接呼叫元件，比如訊息的傳送方和接收方用activemq：
activemq-client:
:sendmsg
(topic, msg)
;activemq-client:
:recvmsg
(top, msg, callback_func)
;
第一步：recvmsg公升級為雙向訂閱
shenjianmq:
:recvmsg
(topic, msg, callback_func)
shenjianmq:
:sendmsg
(topic, msg)
小白聊架構師 怎麼成為架構師
還有人說 我早就掌握了物件導向設計，也看了 企業應用架構模式 架構之美 大型 技術架構 等等架構的書，為啥還當不了架構師？是啊，這高階，大氣，上檔次的架構師是怎麼煉成的？這裡講乙個小王的故事吧。又到了畢業季，一批應屆生進了乙個軟體公司，小王也在其中。新人進入公司，基本上都是從最底層做起，做那些最髒最...
如何成為架構師系列 前言
很多it新人都對架構感興趣，我的團隊裡打算往架構方向發展的同事也不少 我在乙個二十人左右的軟體團隊裡任部門經理 他們會問我要往哪個方向去努力，看什麼書啊，積累什麼技能啊，但怎麼說呢，或許是我的見識有限，我覺得很難用幾句話說清這件事情。上網搜尋 如何成為架構師 大部分人都說得靠經驗 得積累等等。去買架...
MQ，網際網路架構解耦神器
乙個架構常識 當呼叫方需要關心執行結果，通常使用rpc呼叫。ret passportservice userauth name,pass switch ret case yes return yeshtml case no return nohtml case jump return 304html...