Service Mesh (ASM)的寬鬆泳道能力可以協助使用者實現在一個全量版本的基礎上部署多套非全量環境。但在一些情境中，調用鏈路上存在訊息佇列，而ASM暫時還不支援訊息佇列協議，因此需要進行一些適配工作，以使得流量標籤能夠在訊息佇列中傳遞。本文介紹如何在寬鬆泳道中適配訊息佇列。
使用前提
在寬鬆泳道中使用訊息佇列，需要確保訊息佇列和應用滿足以下要求。
訊息佇列
需要支援在訊息中設定自訂中繼資料。
需要消費者支援指定特徵進行過濾，只消費攜帶該指定特徵的訊息。
應用部署
在消費者主動拉取的訊息佇列中，由於消費者無法感知泳道相關的服務發現資訊，為了確保訊息被正確消費，需要確保在任意泳道中合法部署消費者和生產者，如下圖：
合法部署：在一條泳道中，訊息佇列的生產者和消費者要麼同時存在，要麼同時不存在。
不合法部署：泳道中存在單獨的生產者或消費者。
適配方案
訊息佇列生產者將泳道標籤寫入訊息
在適配時，我們需要請求鏈路中的請求即使經過了訊息佇列，也可以維持泳道特徵，泳道中應用產生的訊息才可以被正確的消費者消費，同時消費者可以將訊息中攜帶的特徵還原到發送給上遊的請求中。因此，生產者應用APP-B在寫入訊息佇列時，需要將應用所在泳道資訊和下遊請求中攜帶的泳道標籤一同寫入到訊息中。同時，消費者的消費過濾條件欄位也需要包含應用所在泳道的資訊，如下圖。
應用所在泳道：即過濾key。由於應用所在的泳道由其工作負載攜帶的標籤決定，因此通過讀取應用標籤（可以通過環境變數將標籤值暴露給應用）可以擷取到應用所在的泳道。
下遊請求中攜帶的泳道標籤：在經過網關引流後，網關發出的請求中會攜帶泳道的標識，用於網格代理將請求路由到正確的泳道中，ASM會通過要求標頭
x-asm-prefer-tag在整個HTTP調用鏈路上透傳該標識。
訊息佇列消費者按照所在泳道消費訊息
您應該通過配置使消費者只訂閱當前所在泳道的過濾key，使得訊息佇列中的訊息能夠被正確消費。
訊息應用已部署到泳道v1和v2中：可以看到，兩條泳道都進行了全量部署，APP-C(v1)消費過濾key為v1的訊息，最終將消費由應用APP-B(v1)生產的訊息。APP-C(v2)消費過濾key為v2的訊息，最終消費由應用APP-B(v2)生產的訊息。
訊息應用未在泳道v2中部署：生產者和消費者部署在v1泳道，泳道v2則只部署了APP-A(v2)和APP-C(v2)。當APP-A(v2)收到請求後，由於APP-B未部署v2版本，因此ASM寬鬆泳道將訊息路由至APP-B(v1)，因此，APP-B(v1)無論接收到來自哪個泳道的訊息，都將過濾key寫為其所在泳道(v1)的標籤值，以確保其可以被APP-C(v1)消費。APP-C(v1)消費訊息後，將訊息中攜帶的用到標識取出，使訊息再轉寄給APP-D時，可以將泳道標識為v2的訊息，轉寄給APP-D(v2)。
消費者應用將訊息中擷取的泳道標識寫入發出的請求
如果消費者應用不是調用鏈的最終環節，即該應用在消費訊息後還需要進一步調用其他應用，則需要將訊息中攜帶的泳道標識寫入到所有發出的訊息中，以便ASM網格代理能利用標識進行後續的請求路由。
經過適配後，消費者應用會為發出的請求添加要求標頭x-asm-prefer-tag，並將其值設定為從訊息佇列消費的訊息中攜帶的泳道標識。 當請求經過ASM網格代理時，ASM網格代理會根據x-asm-prefer-tag要求標頭的值，將請求路由至正確的泳道。