原文連結：Routing Mechanisms For AMQP Protocol
作者：Paolo Patierno，紅帽高階軟體工程師
譯者：趙屹華 審校：劉翔宇
責編：周建丁（[email protected]）
未經許可，請勿轉載！

在上一篇文章裡，我們安裝了Qpid Dispatch Router，並且快速地瀏覽了安裝包提供的路由管理和監控工具。

本文將介紹幾個路由器的使用例子，從簡單的配置和網路拓撲到複雜的結構，包括AMQP傳送端、接收端和代理者。代理部分並不是必須的，因為AMQP協議是一種“對等”協議，它可以直接連線兩個客戶端，不需要代理提供的“儲存再轉發”機制。關於這方面的介紹，可以閱讀本系列的

在本文中，我將使用預設配置的路由器來演示傳送端和接收端是如何與它連線的，以及如何通過路由器來交換訊息。

路由機制

首先，值得一提的一點是路由器支援兩種不同的路由機制。

訊息路由

當路由器從鏈路上收到一條訊息，它使用傳送端發到路由器時所指定的目的地址；如果這一地址沒有被指定，則目的地址從訊息的“to”屬性中獲取。基於這個資訊，路由器查詢路由表從而決定訊息傳遞的路徑。它可能是直接相連的接收端，也可能是網路中的另一個路由器來作為下一塊跳板。當然，訊息也可以被送達地址相同的多個不同的接收端。這裡的關鍵點是針對每一條接受到的訊息都做一次路由決策，而且路由器內部節點之間和外部客戶端往往還有很多通訊。

從上圖中可以看出，鏈路是建立在傳送端和路由器以及接收端和路由器之間的。在基於訊息的路由機制下，路由器和傳送端以及接收端的訊息交換是兩條截然不同的鏈路。

這也意味著路由器（內部的接收端）與傳送端、路由器（內部的傳送端）與接收端有著不同的流量控制策略。當然，如果接收端獲得的分值很低（比如10），但是路由器（內部接收端）給了傳送端很大的分值（預設是250），這個差值需要被考慮到。如果接收端由於某些原因（收到10條訊息後）關閉了連線，而傳送端傳送的訊息已經超過10條（根據“accepted”標誌），因為路由器無法向已經關閉的接收端繼續傳送訊息，它會回覆一個“released”標誌。

另一個有趣的地方在於訊息的“處置”。路由器總是在網路中傳播遞送和處置。當接收一條“預處置”訊息時，它的屬性被傳播到了目的地址。“未處置”訊息也是如此：在這種情況下，路由器需要跟蹤傳入的遞送，並將未處置訊息發往目的地址；當它從最終的接收端收到已處置標誌時，它將以同樣的方式回覆原始傳送端。

訊息路由的最後一點有趣之處在於其路由模式，定義了訊息在網路中的遊走路徑：

• 最近路線：即使有許多接收端的地址相同，訊息還是按照最短路徑送往目的地址。這也意味著只有一個接收端能夠收到訊息。

• 平衡路線：當有多個接收端的地址相同時，發往該地址的訊息將分佈在各個接收端上。意思是說各個接收端以類似“競爭消費者”的形式每次接收不同的訊息。

• 多路傳送：這有點類似“釋出/訂閱”模式，即附著在同一個地址的所有接收端都能收到同樣的訊息。

當某個地址上的所有接收者都與同一個路由器相連，我們可以近似認為“最近路線”和“平衡路線”的效果是一樣的，因為所有的路徑長度都相等，接收端與路由器的距離等級都相同。事實上並不完全這樣，因為在“最近路線”模式下路由器對各個接收端使用嚴格的迴圈分佈，而在“平衡路線”模式下它考慮了各個接收端未處置遞送的個數，選擇其中“更快”的一個（即處置訊息更快）。

舉個例子，假設有一個傳送端S、兩個接收端R1和R2和一個路由器網路，R1與S連線在同一個路由器上，R2連在了另一個路由器（連到前一個）。我們認為R1到S的距離是1級，R2到S的距離是2級。

在下面的場景中，按照“最近路線”模式S傳送的所有訊息都將被傳遞到R1。

按照“平衡路線”模式，訊息分佈在兩個接收端上，且與路徑長度無關。

最後，在“多路傳送”模式下所有的訊息被髮送到所有的接收端。

鏈路路由

當路由器收到一條附加請求時，它被傳播於整個網路，以至於找到目的地節點，建立起一條真正的鏈路。當傳送端開始給路由器傳送訊息，在訊息層面上不需要任何決策過程，直接通過建立起的鏈路送達目的地址。你可以認為它是一種虛擬連線或是一條連同傳送端和接收端的隧道。

如你在上述圖片中所見，鏈路直接建在兩個端點之間，所有的活動都是通過它來進行。

從流量控制的角度來看，它直接由傳送端和接收端控制；傳送端給予的任何分值直接到達接收端，無需路由器的中間干擾。穿越路由器的鏈路就像一條“隧道”，兩個端點就像是直接相連的。

對於“未處置”訊息的標誌也是一樣的，傳送端直接收到來自接收端的標誌。

不同路由模式的概念在這裡沒有意義，因為在這種情況下有一條連線傳送端和接收端的直接路徑，因此路由器對單條訊息不做任何決策，只需要沿著鏈路傳遞每一幀資料。

我們開始吧……超級簡單！

現在，我們用一個預設配置的路由器做一個簡單的例子，只有一個傳送端和一個接收端與其相連，掛載在/my_address的地址上。

我使用了simple_recv和simple_send的C++客戶端例子，它們在Quid Proton安裝資料夾裡都能找到。

首先，我們定義接收端的地址和接收訊息的條數，比如10條訊息，啟動接收端。

我們使用qdstat管理工具可以發現my_address被定義為“輸出”（從路由器到接收端）的端點，還沒有傳送過訊息。

之後，我們開啟發送端來發送一些自動生成的訊息，比如5條訊息。

如你所見，所有的訊息被處置且得到確認。在接收端一側的情況如何呢？

傳送端傳送的所有訊息都已經接收，但應用並未關閉，因為它在等待另外5條訊息（當然，這只是應用本身的行為，與路由機制無關）。

使用qdstat管理工具，我們可以看到在my_address的輸出端點有5條已傳送訊息。我們無法檢視的是同一個地址下的“輸入”端點（從傳送端到路由器），因為訊息傳送之後，傳送端關閉了與路由器的連線，這個端點也隨之被刪除。相信我，傳送端在傳送訊息時這個端點確確實實是存在的！

你應該發現了我們直接將傳送端和接收端相連，不需要代理者在中間儲存和轉發訊息。在上述場景中，當訊息被處置並且給傳送端確認之後，就意味著訊息真正的被接收端所接收了。

總結

在本文中，我介紹了Qpid Dispatch Router提供的訊息路由的不同機制。我們可以針對不同的場景選擇最佳的方式，使得我們的分散式應用能更有效地傳遞訊息。我們演示了一個簡單的例子，它不需要代理者參與，而是直接將傳送端和接收端與路由器相連。在下一篇文章裡，我將不再使用預設的配置檔案，探索連線路由器與客戶端和代理者的不同方式，增加系統的複雜性。