高德服務單元化方案和架構實踐

時間 2019-11-29

標籤服務單元方案架構實踐欄目系統架構简体版

原文原文鏈接

導讀：本文主要介紹了高德在服務單元化建設方面的一些實踐經驗，服務單元化建設面臨不少共性問題，如請求路由、單元封閉、數據同步，有的有成熟方案能夠借鑑和使用，但不一樣公司的業務不盡相同，要儘量的結合業務特色，作相應的設計和處理。nginx

1、爲何要作單元化redis

單機房資源瓶頸

隨着業務體量和服務用戶羣體的增加，單機房或同城雙機房沒法支持服務的持續擴容。sql

服務異地容災

異地容災已經成爲核心服務的標配，有的服務雖然進行了多地多機房部署，但數據仍是隻在中心機房，實現真正意義上的異地多活，就須要對服務進行單元化改造。mongodb

2、高德單元化的特色緩存

在作高德單元化項目時，咱們首先要考慮的是結合高德的業務特色，看高德的單元化有什麼不同的訴求，這樣就清楚哪些經驗和方案是能夠直接拿來用的，哪些又是須要咱們去解決的。服務器

高德業務和傳統的在線交易業務仍是不太同樣，高德爲用戶提供以導航爲表明的出行服務，不少業務場景對服務的RT要求會很高，因此在作單元化方案時，儘量減小對總體服務RT的影響就是咱們須要重點考慮的問題，儘可能作到數據離用戶近一些。轉換到單元化技術層面須要解決兩個問題:架構

1.用戶設備的單元接入須要儘量的作到就近接入，用戶真實地理位置接近哪一個單元就接入哪一個單元，如華北用戶接入到張北，華南接入到深圳。性能

2.用戶的單元劃分最好能與就近接入的單元保持一致，減小單元間的跨單元路由。如用戶請求從深圳進來，用戶的單元劃分最好就在深圳單元，若是劃到張北單元就會形成跨單元路由。優化

另一個區別就是高德不少業務是無須登陸的，因此咱們的單元化方案除了用戶ID也要支持基於設備ID。ui

3、高德單元化實踐

服務的單元化架構改造須要一個至上而下的系統性設計，核心要解決請求路由、單元封閉、數據同步三方面問題。

請求路由：根據高德業務的特色，咱們提供了取模路由和路由表路由兩種策略，目前上線應用使用較多的是路由表路由策略。

單元封閉：得益於集團的基礎設施建設，咱們使用vipserver、hsf等服務治理能力保證服務同機房調用，從而實現單元封閉(hsf unit模式也是一種可行的方案，但我的認爲同機房調用的架構和模式更簡潔且易於維護)。

數據同步：數據部分使用的是集團DB產品提供的DRC數據同步。

單元路由服務採用什麼樣的部署方案是咱們另外一個要面臨的問題，考慮過如下三種方案：

第一種SDK的方式由於對業務的強侵入性是首先被排除的，統一接入層進行代理和去中心化插件集成兩種方案各有利弊，但當時首批要接入單元化架構的服務不少都尚未統一接入到gateway，因此基於現狀的考慮使用了去中心化插件集成的方式，經過在應用的nginx集成UnitRouter。

服務單元化架構

目前高德帳號，雲同步、用戶評論系統都完成了單元化改造，採用三地四機房部署，寫入量較高的雲同步服務，單元寫高峯能達到數w+QPS (存儲是mongodb集羣)。

以帳號系統爲例介紹下高德單元化應用的總體架構。

帳號系統服務是三地四機房部署，數據分別存儲在tair爲表明的緩存和XDB裏，數據存儲三地集羣部署、全量同步。帳號系統服務器的Tengine上安裝UntiRouter，它請求的負責單元識別和路由，用戶單元劃分是經過記錄用戶與單元關係的路由表來控制。

PS：因歷史緣由緩存使用了tair和自建的uredis(在redis基礎上添加了基於log的數據同步功能)，目前已經在逐步統一到tair。數據同步依賴tair和alisql的數據同步方案，以及自建的uredis數據同步能力。

就近接入實現方案

爲知足高德業務低延時要求，就要想辦法作到數據(單元)離用戶更近，其中有兩個關鍵鏈路，一個是經過aserver接入的外網鏈接，另外一個是服務內部路由(儘量不產生跨單元路由)。

措施1：客戶端的外網接入經過aserver上的配置，將不一樣地理區域(七個大區)的設備劃分到對應近的單元，如華北用戶接入張北單元。

措施2：經過記錄用戶和單元關係的路由表來劃分用戶所屬單元，這個關係是經過系統日誌分析出來的，用戶常常從哪一個單元入口進來，就會把用戶劃分到哪一個單元，從而保證請求入口和單元劃分的相對一致，從而減小跨單元路由。

因此，在最終的單元路由實現上咱們提供了傳統的取模路由，和爲降延時而設計的基於路由表路由兩種策略。同時，爲解無須登陸的業務場景問題，上述兩種策略除了支持用戶ID，咱們同時也支持設備ID。

路由表設計

路由表分爲兩部分，一個是用戶-分組的關係映射表，另外一個是分組-單元的關係映射表。在使用時，經過路由表查對應的分組，再經過分組看用戶所屬單元。分組對應中國大陸的七個大區。

先看「用戶-(大區)分組」：

路由表是按期經過系統日誌分析出來的，看用戶最近IP屬於哪一個大區就劃分進哪一個分組，同時也對應上了具體單元。當一個北京的用戶長期去了深圳，因IP的變化路由表更新後將划進新大區分組，從而完成用戶從張北單元到深圳單元的遷移。

再看「分組-單元」：

分組與單元的映射有一個默認關係，這是按地理就近來配置的，好比華南對應深圳。除了默認的映射關係，還有幾個用於切流預案的關係映射。

老用戶能夠經過路由表來查找單元，新用戶怎麼辦？對於新用戶的處理咱們會降級成取模的策略進行單元路由，直至下次路由表的更新。因此總體上看新用戶跨單元路由比例確定是比老用戶大的多，但由於新用戶是一個相對穩定的增量，因此總體比例在可接受範圍內。

路由計算

有了路由表，接下來就要解工程化應用的問題，性能、空間、靈活性和準確率，以及對服務穩定性的影響這幾個方面是要進行綜合考慮的，首先考慮外部存儲會增長服務的穩定性風險，後面咱們在BloomFilter 、BitMap和MapDB多種方案中選擇BloomFilter，萬分之幾的誤命中率致使的跨單元路由在業務可接受範圍內。

經過日誌分析出用戶所屬大區後，咱們將不一樣分組作成多個布隆過濾器，計算時逐層過濾。這個計算有兩種特殊狀況：

由於BloomFilter存在誤算率，有可能存在一種狀況，華南分組的用戶被計算到華北了，這種狀況比例在萬分之3 (生成BloomFilter時可調整)，它對業務上沒有什麼影響，這類用戶至關於被劃分到一個非所在大區的分組裏，但這個關係是穩定的，不會影響到業務，只是存在跨單元路由，是可接受的。
新用戶不在分組信息裏，因此通過逐層的計算也沒有匹配到對應大區分組，此時會使用取模進行模除分組的計算。

若是業務使用的是取模路由而非路由表路由策略，則直接根據tid或uid計算對應的模除分組，原理簡單不詳表了。

單元切流

在發生單元故障進行切流時，主要分爲四步驟

打開單元禁寫 (跨單元寫不敏感業務能夠不配置)

檢查業務延時

切換預案

解除單元禁寫

PS：更新路由表時，也須要上述操做，只是第3步的切換預案變成切換新版本路由表；單元禁寫主要是了等待數據同步，避免數據不一致致使的業務問題。

核心指標

單元計算耗時1~2ms

跨單元路由比例底於5%

除了性能外，因就近接入的訴求，跨單元路由比例也是咱們比較關心的重要指標。從線上觀察看，路由表策略單元計算基本上在一、2ms內完成，跨單元路由比例3%左右，總體底於5%。

4、後續優化

統一接入集成單元化能力

目前大部分服務都接入了統一接入網關服務，在網關集成單元化能力將大大減小服務單元化部署的成本，經過簡單的配置就能夠實現單元路由，服務可將更多的精力放在業務的單元封閉和數據同步上。

分組機制的優化

按大區分組存在三個問題：

經過IP計算大區有必定的誤算率，會致使部分用戶劃分錯誤分組。

分組粒度太大，單元切流時流量很差分配。舉例，假如華東是咱們用戶集中的大區，切流時把這個分組切到任意一個指定單元，都會形成單元服務壓力過大。

計算次數多，分多少個大區，理論最大計算次數是有多少次，最後採起取模策略。

針對上述幾個問題咱們計劃對分組機制作以下改進

經過用戶進入單元的記錄來確認用戶所屬單元，而非根據用戶IP所在大區來判斷，解上述問題1。

每一個單元劃分4個虛擬分組，支持更細粒度單元切流，解上述問題2。

用戶確實單元后，經過取模來劃分到不一樣的虛擬分組。每一個單元只要一次計算就能完成，新用戶只需通過3次計算，解上述問題3。

熱更時的雙表計算

與取模路由策略不一樣，路由表策略爲了把跨單元路由控制在一個較好的水平須要按期更新，目前更新時須要一個短暫的單元禁寫，這對於不少業務來講是不太能接受的。

爲優化這個問題，系統將在路由表更新時作雙(路由)表計算，即將新老路由表同時加載進內存，更新時再也不對業務作徹底的禁寫，咱們會分別計算當前用戶(或設備)在新老路由表的單元結果，若是單元一致，則說明路由表的更新沒有致使該用戶(或設備)變動單元，因此請求會被放行，相反若是計算結果是不一樣單元，說明發生了單元變動，該請求會被攔截，直至到達新路由表的一個徹底起用時間。

優化前服務會徹底禁寫好比10秒(時間取決於數據同步時間)，優化後會變成觸發禁寫的是這10秒內路由發生變動的用戶，這將大大減小對業務的影響。

服務端數據驅動的單元化場景

前面提到高德在路由策略上結合業務的特別設計，但總體單元劃分仍是以用戶(或設備)爲維度來進行的，但高德業務還有一個大的場景是咱們將來要面對和解決的，就是以數據維度驅動的單元設計，基於終端的服務路由會變成基於數據域的服務路由。