直入主題，不討論為什麼遷移，直接談遷移方案。

既然是從AMQ（AtiveMQ的簡稱）遷移到kafka，那麼遷移過程中肯定需要做到平滑遷移：對於業務沒有影響，對於上下游系統沒有依賴。

由於系統一般會和多個上游，多個下游通過MQ中介軟體保持依賴關係，遷移的過程中，肯定要做到各個系統上線沒有任何依賴。打個比方訂單系統傳送topic，會員系統和積分系統都會接收這個topic（會員增加成長值，積分系統加積分）。改造後釋出時，訂單系統，會員系統，積分系統三個系統上線應該可以任意順序，任意時間釋出上線。

依賴關係

給出具體方案之前，先捋一下各個系統之間的依賴關係。再複雜的系統，和其他系統之間的依賴關係也就如下圖所示，假設我們關注的是系統H。它會接受上游系統A和B傳送的topic，以及給下游系統X，Y和Z傳送topic（說明：下圖是系統依賴關係圖，而不是例項關係依賴圖）。

根據這張架構圖，我們將訊息分為幾個型別：

1. 生產型(1-1)--這種訊息由本身系統H傳送，下游系統X，Y，Z中任意且只有一個系統消費（AMQ中Queue的使用場景）；
2. 生產型(1-N)--這種訊息由本身系統H傳送，下游系統X，Y，Z中任意多個系統消費（AMQ中VirtualTopic的使用場景）；
3. 消費型--這種訊息由上游系統例如A或者B傳送，系統H負責消費；
4. 自產自消型--這種訊息由本身系統H傳送，本身系統H負責消費。

VirtualTopic

生產型(1-N)訊息，不能認為是Topic的使用場景，而應該是VirtualTopic的使用場景（至少大部分情況下）。兩者的區別如下圖所示（AMQ的VirtualTopic具體用法網上一大堆，這裡就不累述了）：

如上圖所示，系統X有三個例項X-1，X-2，X-3；系統Y有三個例項Y-1，Y-2，Y-3。如果系統H傳送一個VirtualTopic，假如名為VirtualTopic.PAY_SUCCESS_ORDER。系統X和系統Y分別接收佇列：VConsumers.memberGroup.VirtualTopic.PAY_SUCCESS_ORDER和VConsumers.pointIssue.VirtualTopic.PAY_SUCCESS_ORDER。那麼系統X的三個例項只會有一個例項接收到VConsumers.memberGroup.VirtualTopic.PAY_SUCCESS_ORDER，系統Y的三個例項也只有一個例項接收到VConsumers.pointIssue.VirtualTopic.PAY_SUCCESS_ORDER。如果系統H傳送一個Topic，假如名為PAY_SUCCESS_ORDER，那麼系統X的三個例項和系統Y的三個例項都會接收到這個Topic。

接下來我們分別討論這幾種訊息如何做到平滑遷移（假定系統H就是我們要改造的系統）。

消費型

這類訊息由於我們的系統H是消費者，即被動方，我們不確定上游系統A和B的傳送方式什麼時候從AMQ切換到kafka，另外我們無法預知我們訂閱的AMQ存量訊息什麼時候消費完。所以對於這種型別的訊息，系統H在改造時要保留原來的AMQ訊息接收方式，同時需要新增kafka訊息接收方式即可。

生產型(1-1)

這種場景就是AMQ中Queue的使用場景。這類訊息由於我們的系統H是生產者，即主動方。且依賴關係比較簡單，就是1對1。但是考慮到下游系統即消費者不確定什麼時候加入kafka接收方式。所以，我們重構時AMQ傳送方式要保留，kafka傳送方式也要新增。但是需要在傳送的地方增加一個開關，在兩種傳送方式之間切換。當下遊系統即消費者引入kafka接收方式後，這個開關就可以切換到kafka傳送。生產者的AMQ傳送方式的程式碼和開關在下一個版本就可以刪除了。同理，這個消費者的AMQ消費方式在下一個版本也可以刪除。

生產型(1-N)

這種場景就是AMQ中VirtualTopic的使用場景。這類訊息由於我們的系統H是生產者，即主動方。但是依賴關係相比Queue使用場景要複雜一點，因為消費者比較多。考慮到若干個下游系統即消費者不確定什麼時候加入kafka接收方式。所以，我們重構時AMQ傳送方式要保留，kafka傳送方式也要新增。但是需要在傳送的地方增加一個開關，在兩種傳送方式之間切換。當下遊系統即消費者全部引入kafka接收方式後，這個開關就可以切換到kafka傳送。生產者的AMQ傳送方式的程式碼和開關在下一個版本就可以刪除了。同理，若干個消費者的AMQ消費方式在下一個版本也可以刪除。

自產自消型

這種型別的訊息，即使訊息的生產和消費都在我們的系統H中，整個過程我們能夠完全掌控。如果不考慮多個例項之間部署的時間差，那麼直接將AMQ的傳送方式和接收方式全部更新為kafka傳送方式和接收方式。例如本地快取定時重新整理這種場景。

如果考慮多個例項之間部署的時間差，那麼就比較麻煩了。

• 1-1
  如果自產自消是1-1型別訊息，即系統H傳送一個Queue，消費者也是系統H，且需要考慮多個例項之間部署的時間差。這個切換過程比較簡單。直接將AMQ的傳送方式和接收方式全部更新為kafka傳送方式和接收方式，整個滾動部署過程如下：

1. 上線前
   重構上限前，所有系統都有AMQ傳送方式和AMQ接收方式。自產自消。

   
   
   

   image.png

2. 例項H1上線後
   例項H1上線後，例項H1是kafka傳送方式和接收方式。如果訊息是H1傳送的，那麼只能H1接收。如果訊息是H2或者H3傳送的，那麼H2和H3都可以接收。

   
   
   

   image.png

3. 例項H2上線後
   例項H2上線後，例項H1和H2是kafka傳送方式和接收方式。如果訊息是H1或者H2傳送的，那麼H1和H2都能接收。如果訊息是H3傳送的，那麼H3可以接收。

   
   
   

   image.png

4. 例項H3上線後
   例項H3即最後一個上線後，三個例項全部是kafka的傳送方式和接收方式。

   
   
   

   image.png

• 1-N
  如果自產自消是1-N型別訊息，即系統H傳送一個Topic，消費者也是系統H，且需要考慮多個例項之間部署的時間差。這個切相對麻煩一點。

1. 需要保留AMQ的接收方式，同時新增kafka接收方式，釋出一個版本。
2. 新增kafka傳送方式，刪除AMQ傳送方式，滾動釋出，直到所有例項部署完成。

總結

通過上面的方案設計，即使整個部門，或者整個公司相互之間通過MQ中介軟體依賴的系統有成百上千個，也可以做到從容不迫，一個系統一個系統慢慢遷移。完全不受其他專案組，不受其他部門的影響。整個過程真正做到平滑遷移。完美^_