流量隔離方案 Dpath 護航雙十一新零售

 

摘要： 本文做者： 思邪，阿里巴巴中間件技術專家，全程參與2018 雙11的技術支撐工做，長期關注RPC及微服務技術領域，擅長系統架構和性能優化。

需求

在今年的雙11準備期間，業務同窗提出要針對新零售進行特殊的保障，但願新零售過來的流量，單獨進入到一批機器，和其餘普通流量隔離開來，這對新零售系統穩定性提出更高的要求。

需求總結下來就是：

• 針對特殊流量能夠在鏈路上按需選擇一些應用，從全部機器（公共集羣）裏圈定一些機器做爲特殊流量的專屬機器，以便對特殊流量進行特殊支持。
• 普通流量不進入專屬服務器，特殊流量能夠按需使用普通服務器

1. 若是鏈路上某個應用app_x沒有劃出專屬機器，那麼特殊流量和普通流量公用app_x的全部機器（咱們稱之爲公共集羣）。
2. 若是app_x劃了專屬機器，可是這些機器由於某種緣由不可達，那麼特殊流量能夠根據配置的failover策略決定是否使用公共集羣。

• 整個鏈路上各個應用的劃出來的專屬機器組成了特殊流量的專屬通道，相似公交專用道。
• 咱們的RPC框架已有的路由功能是在單次調用上生效，基於單次調用的路由功能實現全鏈路的路由會很是麻煩。因此咱們提出了一個全鏈路上的作流量隔離的方案Dpath(Dedicated path)。

方案工做機制

咱們分三步來講明Dpath如何工做：

• 圈定專屬服務器
• 識別特殊流量
• 在鏈路上引導流量到對應的服務器

圈定專屬機器

簡單來講，咱們須要的信息就是一個專屬環境裏包含哪些應用的哪些機器。該信息以JSON形式存放在配置中心，樣本以下：

{
"enable": true, 
"envRules": [
    {
        "envName": "newRetail", 
        "failoverPolicy": 0,
        "envAppRules": [
            {
                "appName": "app1", 
                "ips": [ ], 
                "machineGroups": [
                    "app1_newRetail_host"
                ]
            }, 
            {
                "appName": "app2", 
                "ips": [ ], 
                "machineGroups": [
                    "app2_newRetail_host"
                ]
            }, 
            {
                "appName": "app3", 
                "ips": [ ], 
                "machineGroups": [
                    "app3_newRetail_host"
                ]
            }, 
            {
                "appName": "newRetailEntryApp", 
                "ips": [ ], 
                "machineGroups": [
                    "newRetailEntryApp_host"
                ]
            }
        ]
    }
]
}

上述配置申明瞭一個名爲newRetail的專屬環境，裏邊包含app1,app2,app3,newRetailEntryApp四個應用以及對應的機器。

Dpath工具包會訂閱該配置，各個中間件使用Dpath工具包便可獲知所需的信息。

識別流量

Dpath經過trace模塊(全鏈路的trace功能，能夠在鏈路上傳遞數據)攜帶的dpath_env屬性來識別當前流量屬於哪個專屬環境。具體如何根據請求信息映射到一個專屬環境是業務邏輯，由業務同窗完成。這個識別動做能夠放在以下三個地方：

• Nginx

能夠根據http請求信息來識別流量。根據業務規則實現請求到dpath_env的映射，經過Nginx模塊生成將env信息添加到trace模塊的上下文

• 入口應用

中間件取環境信息若是爲空，默認會使用當前機器所屬的環境。因此若是入口應用肯定，那麼將整個入口應用劃到專屬環境便可。目前新零售都是這種模式。

• 業務代碼

業務代碼能夠根據須要設置trace模塊上下文中的的dpath_env，隨時改變流量所屬的環境。

引導流量

dpath只定義了機器，環境，以及流量的關係，並無規定如何引導流量。引導流量由各個中間件自行實現。

這裏只以rpc爲例說明如何基於Dpath的規則來引導流量到對應的服務器。

爲了方便理解，先忽略RPC其餘的路由邏輯，看最簡單狀況下，單次調用的處理。沒有Dpath功能時，RPC客戶端就是從註冊中心拿到service對應的服務器列表，而後隨機調用。以下圖所示：

增長Dpath功能以後，服務名到服務器的映射中間插入了一個dpath_env的邏輯。RPC客戶端先根據請求上下文中的環境信息選中對應環境的地址，而後隨機調用。以下圖所示：

整個鏈路上，一個專屬環境裏全部應用的專屬服務器串起來構成了特殊流量的專屬路徑。以下圖所示：

• newRetailEntryApp進入的newRetail流量使用專屬機器
• 鏈路上沒有劃機器給newRetail的應用，使用公共集羣

RPC以外，消息等中間件，都用各自的方式達到了相似的隔離效果。這裏再也不贅述細節。下面只提供一個RPC和消息支持Dpath的效果簡圖：

野流量隔離

根據上面的描述，RPC的隔離邏輯是在客戶端生效。那麼若是客戶端沒升級的話（很難快速協調全部客戶端統一升級），就會有未知流量打到專屬服務器，老客戶端過來的不符合規則的流量咱們稱之爲野流量。

爲了解決野流量問題。註冊中心的同窗在發佈訂閱功能的基礎上，提供了一個namespace功能。咱們會把專屬服務器的服務發佈到Dpath這個namespace下，普通服務器默認發佈到default這個namespace。新版本的客戶端會訂閱default+dpath兩個namespace的數據，至關於拿到全量地址。而註冊中心保證老的客戶端只能看到default空間下的數據，這樣就不會有野流量達到專屬服務器了。

總結

Dpath是一個通用的流量隔離方案，能夠支持一些須要隔離或者引導流量的場景，好比全鏈路常態隔離，灰度測試，藍綠髮布等。

目前業務方主要是在全鏈路上按業務屬性進行常態流量隔離，已經在幾個新零售場景線上使用，而且經歷了雙11的考驗。

如下列舉一些業務流量隔離的好處：

• 業務方能夠根據業務屬性的不一樣作不一樣的支持：個性的配置，更全的監控等。
• 重要業務不受其餘流量影響，不會由於其餘流量突增而致使load高，被限流。
• 小集羣支持單業務，發佈，回滾，都更快。當特定業務出問題時，能夠更快地響應。

做者： 中間件小哥
原文連接 本文爲雲棲社區原創內容，未經容許不得轉載。