百度自動內網流量排程進階實戰

從事服務管理、監控、平臺可用性建設相關工作。在分散式系統、大規模資料處理、可用性工程方向有廣泛的實踐經驗。

乾貨概覽

在前兩篇文章中，我們介紹了內網流量排程解決的核心問題，並以 qproxy 的實際使用場景進行了案例解析。

百度自動內網流量排程實踐

百度自動內網流量排程方案解析

流量接入層根據從 BNS 獲取到的例項和相關配置資訊，實現流量排程功能。

本文將重點介紹配置分發和流量排程引擎的實現。

設計目標 – 通用的流量排程邏輯

由於百度各業務的複雜多樣，為了便於遷移和適配新的使用場景，我們需要通用、可擴充套件的執行框架來支援使用者自定義流量排程邏輯。例如，在例項列表中增加使用者自定義的標籤或配置資訊，實現定製化的功能。

通用的流量排程邏輯，可以讓我們適配儘可能多的流量接入方式。 在實際的使用過程中，我們至少相容了以下流量接入方式：qproxy、nginx、rpc和其它使用者自研的流量接入層。

實現細節

為了降低實現複雜度以及接入成本，我們在 Naming Service 層增加了流量排程引擎的邏輯。

Naming Service 負責配置分發。使用者通過 SDK 從本地服務端獲取服務單元和例項資訊。

上游服務呼叫 SDK 獲取例項列表，請求發給本地服務端，本地服務端通過遠端服務端獲取到原始例項列表，之後，由流量排程引擎根據原始例項列表和路由表中的路由規則，生成最終返回給 SDK的例項列表。

   流量排程引擎   

流量排程引擎是一組根據使用者使用場景實現的程式碼，它的功能是參考路由表和其它使用者配置，對例項資訊進行篩選和重組，最終返回給流量接入層，達到控制流量的目的。

它可以根據使用者的需求來自定義功能，例如：

• 參考上游請求的來源機房（可以是物理機房或邏輯機房）和路由表，決定返回上游來源所對應的下游機房中的例項。

• 根據流量接入層型別，在返回的例項列表中增加自定義的標籤資訊。

   路由表   

下圖是一個實際的路由表，包含邏輯機房和物理機房的對映關係，路由規則，流量配比資訊：

• 邏輯機房和物理機房的對映關係：為了便於管理，我們一般會將某個地域的叢集，按照邏輯機房的形式進行組織。用來規避物理機房的變更導致流量對映關係的頻繁調整。也便於批量配置和運維操作。

• 路由規則和流量配比：路由規則描述了上下游邏輯機房之間的對映關係，還有他們之間的流量配比。

• 流量配比的計算方法：在預設場景下，會根據流量配比計算出對應的例項數量。對於不同的邏輯機房，原始例項數量可能有相當大的差別。因此需要根據流量配比對例項進行補全或抽樣。

當然，以上描述的是理想情況。在實際的系統中，還存在例項數上限、按權值返回例項等場景和需求，需要針對這些場景進行處理。限於篇幅，這裡不詳細展開。

   時效性   

對於流量排程場景來說，排程生效時間是一個最關鍵的效能指標。它決定了從流量排程操作發起到流量實際生效之間消耗的時間。

以業務的止損場景為例，生效時間決定了止損操作的速度。更低的生效延遲意味著更快的止損和更低的收入損失。

在實現上，我們選擇了推拉結合的方式。即所有變更推送到客戶端，並保留輪詢服務端作為可用性保障的降級預案。這樣，在時效性指標的保障範圍內，實現了秒級別的變更延遲。

   可用性   

流量排程系統包含的配置分發和排程引擎都處於流量接入的核心環節。這部分系統的可靠性直接影響到上下游呼叫的成功率。

原則上，我們通過冗餘的方式，提升系統的整體可用性。在整個服務中，有多層次的快取。另外，在流量排程引擎方面，我們也實現了按機房的灰度釋出，縮小故障的影響範圍。

總結

通過以上三篇文章，我們為大家解析了百度內網流量排程系統。這是基於百度複雜的內網結構和多樣的業務，綜合考慮功能、成本、效能、可用性等指標的一種工程實踐。隨著DevOps 的不斷髮展，新的服務框架和方案不斷湧現。例如 istio，linkerd 等開源專案都為服務釋出、測試、追蹤等流量排程的典型場景提供了新的解決方案和思路。我們也將在這個方向上持續探索，後續會有更多的工程應用經驗與大家分享。