循序車隊模式

以定義的順序處理一組相關的訊息，而不會封鎖處理其他訊息群組。

內容和問題

應用程式通常需要依訊息到達的順序來處理一連串的訊息，同時仍能夠相應放大以處理增加的負載。 在分散式架構中，依序處理這些訊息並不簡單，因為背景工作角色可以使用競爭取用者模式獨立調整，而且通常會獨立提取訊息。

例如，訂單追蹤系統會收到包含訂單的總賬，以及這些訂單的相關作業。 這些作業可能是建立訂單、將交易新增至訂單、修改過去的交易或刪除訂單。 在此系統中，作業必須以先出 （FIFO） 方式執行，但只能在順序層級執行。 不過，初始佇列會收到一個總帳，其中包含許多訂單的交易，這可能會交錯。

解決方案

將相關訊息推送至佇列系統中的類別，並讓佇列接聽程式一次鎖定並只從一個類別提取一則訊息。

以下是一般循序車隊模式的外觀：

在佇列中，可能會交錯不同類別的訊息，如下圖所示：

問題和考慮

決定如何實作此模式時，請考慮下列幾點：

• 類別/縮放單位。 您可以相應放大傳入訊息的哪些屬性？ 在訂單追蹤案例中，此屬性是訂單標識符。
• 輸送量。 您的目標訊息輸送量為何？ 如果很高，您可能需要重新考慮 FIFO 需求。 例如，您可以強制執行開始/結束訊息、依時間排序，然後傳送批次進行處理嗎？
• 服務功能。 您選擇的訊息總線是否允許在佇列或佇列類別內一次處理訊息？
• 可進化性。 如何將新類別的訊息新增至系統？ 例如，假設上述總賬系統是特定的一個客戶。 如果您需要讓新客戶上線，您是否有一組總賬處理器來散發每個客戶標識元的工作？
• 取用者可能會因為傳送訊息時的變動網路等待時間而無法依序接收訊息。 請考慮使用序號來驗證排序。 您也可以在交易的最後一則訊息中包含特殊的「序列結尾」旗標。 Spark 或 Azure 串流分析等串流處理技術可以在時間範圍內依序處理訊息。

使用此模式的時機

當下列情況時，請使用此模式：

• 您有訊息會依序抵達，且必須以相同順序處理。
• 抵達的訊息是或可以「分類」的方式，讓類別成為系統的縮放單位。

此模式可能不適合：

• 極高輸送量案例（數百萬則訊息/分鐘或秒），因為 FIFO 需求會限制系統可完成的調整。

工作負載設計

架構設計人員應該評估循序車隊模式如何用於其工作負載的設計中，以解決 Azure 良好架構架構支柱中涵蓋的目標和原則。 例如：

如同任何設計決策，請考慮對其他可能以此模式導入之目標的任何取捨。

範例

在 Azure 上，您可以使用 Azure 服務匯流排 訊息會話來實作此模式。 針對取用者，您可以使用Logic Apps搭配 服務匯流排 預覽鎖定連接器，或搭配 服務匯流排觸發程式使用 Azure Functions。

針對先前的訂單追蹤範例，依照收到的順序處理每個總賬訊息，並將每個交易傳送至另一個佇列，其中類別設定為訂單標識符。 在此案例中，交易永遠不會跨越多個訂單，因此取用者會平行處理每個類別，但在類別內的 FIFO。

Ledge 處理器會取消批處理第一個佇列中每個訊息的內容，以將訊息扇出：

總賬處理器會負責：

1. 一次一次走一個總帳一筆交易。
2. 設定訊息的會話標識碼以符合訂單標識碼。
3. 將每個總帳交易傳送至次要佇列，並將會話標識元設定為訂單標識符。

取用者會接聽次要佇列，這些佇列會依序處理具有相符順序標識碼的所有訊息。 取用者使用 預覽鎖定 模式。

考慮延展性時，總賬佇列是主要瓶頸。 張貼至總帳的不同交易可以參考相同的訂單標識碼。 不過，訊息可以在總賬之後向無伺服器環境中的訂單數目展開。

下一步

實作此模式時，可能會有下列相關信息：

• 訊息工作階段：先進先出 （FIFO）
• 檢視鎖定訊息 （非破壞性讀取）
• 使用 服務匯流排 工作階段在 Logic Apps 中傳遞相互關聯的訊息 （MSDN 部落格）