導(dǎo)讀：本文主要介紹了高德在服務(wù)單元化建設(shè)方面的一些實(shí)踐經(jīng)驗(yàn)，服務(wù)單元化建設(shè)面臨很多共性問題，如請(qǐng)求路由、單元封閉、數(shù)據(jù)同步，有的有成熟方案可以借鑒和使用，但不同公司的業(yè)務(wù)不盡相同，要盡可能的結(jié)合業(yè)務(wù)特點(diǎn)，做相應(yīng)的設(shè)計(jì)和處理。

一、為什么要做單元化

• 單機(jī)房資源瓶頸

隨著業(yè)務(wù)體量和服務(wù)用戶群體的增長(zhǎng)，單機(jī)房或同城雙機(jī)房無法支持服務(wù)的持續(xù)擴(kuò)容。

• 服務(wù)異地容災(zāi)

異地容災(zāi)已經(jīng)成為核心服務(wù)的標(biāo)配，有的服務(wù)雖然進(jìn)行了多地多機(jī)房部署，但數(shù)據(jù)還是只在中心機(jī)房，實(shí)現(xiàn)真正意義上的異地多活，就需要對(duì)服務(wù)進(jìn)行單元化改造。

二、高德單元化的特點(diǎn)

在做高德單元化項(xiàng)目時(shí)，我們首先要考慮的是結(jié)合高德的業(yè)務(wù)特點(diǎn)，看高德的單元化有什么不一樣的訴求，這樣就清楚哪些經(jīng)驗(yàn)和方案是可以直接拿來用的，哪些又是需要我們?nèi)ソ鉀Q的。

高德業(yè)務(wù)和傳統(tǒng)的在線交易業(yè)務(wù)還是不太一樣，高德為用戶提供以導(dǎo)航為代表的出行服務(wù)，很多業(yè)務(wù)場(chǎng)景對(duì)服務(wù)的RT要求會(huì)很高，所以在做單元化方案時(shí)，盡可能減少對(duì)整體服務(wù)RT的影響就是我們需要重點(diǎn)考慮的問題，盡量做到數(shù)據(jù)離用戶近一些。轉(zhuǎn)換到單元化技術(shù)層面需要解決兩個(gè)問題:

1.用戶設(shè)備的單元接入需要盡可能的做到就近接入，用戶真實(shí)地理位置接近哪個(gè)單元就接入哪個(gè)單元，如華北用戶接入到張北，華南接入到深圳。

2.用戶的單元?jiǎng)澐肿詈媚芘c就近接入的單元保持一致，減少單元間的跨單元路由。如用戶請(qǐng)求從深圳進(jìn)來，用戶的單元?jiǎng)澐肿詈镁驮谏钲趩卧?#xff0c;如果劃到張北單元就會(huì)造成跨單元路由。

另外一個(gè)區(qū)別就是高德很多業(yè)務(wù)是無須登錄的，所以我們的單元化方案除了用戶ID也要支持基于設(shè)備ID。

三、高德單元化實(shí)踐

服務(wù)的單元化架構(gòu)改造需要一個(gè)至上而下的系統(tǒng)性設(shè)計(jì)，核心要解決請(qǐng)求路由、單元封閉、數(shù)據(jù)同步三方面問題。

請(qǐng)求路由：根據(jù)高德業(yè)務(wù)的特點(diǎn)，我們提供了取模路由和路由表路由兩種策略，目前上線應(yīng)用使用較多的是路由表路由策略。

單元封閉：得益于集團(tuán)的基礎(chǔ)設(shè)施建設(shè)，我們使用vipserver、hsf等服務(wù)治理能力保證服務(wù)同機(jī)房調(diào)用，從而實(shí)現(xiàn)單元封閉(hsf unit模式也是一種可行的方案，但個(gè)人認(rèn)為同機(jī)房調(diào)用的架構(gòu)和模式更簡(jiǎn)潔且易于維護(hù))。

數(shù)據(jù)同步：數(shù)據(jù)部分使用的是集團(tuán)DB產(chǎn)品提供的DRC數(shù)據(jù)同步。

單元路由服務(wù)采用什么樣的部署方案是我們另一個(gè)要面臨的問題，考慮過以下三種方案：

第一種SDK的方式因?yàn)閷?duì)業(yè)務(wù)的強(qiáng)侵入性是首先被排除的，統(tǒng)一接入層進(jìn)行代理和去中心化插件集成兩種方案各有利弊，但當(dāng)時(shí)首批要接入單元化架構(gòu)的服務(wù)很多都還沒有統(tǒng)一接入到gateway，所以基于現(xiàn)狀的考慮使用了去中心化插件集成的方式，通過在應(yīng)用的nginx集成UnitRouter。

服務(wù)單元化架構(gòu)

目前高德賬號(hào)，云同步、用戶評(píng)論系統(tǒng)都完成了單元化改造，采用三地四機(jī)房部署，寫入量較高的云同步服務(wù)，單元寫高峰能達(dá)到數(shù)w+QPS (存儲(chǔ)是mongodb集群)。

以賬號(hào)系統(tǒng)為例介紹下高德單元化應(yīng)用的整體架構(gòu)。

賬號(hào)系統(tǒng)服務(wù)是三地四機(jī)房部署，數(shù)據(jù)分別存儲(chǔ)在tair為代表的緩存和XDB里，數(shù)據(jù)存儲(chǔ)三地集群部署、全量同步。賬號(hào)系統(tǒng)服務(wù)器的Tengine上安裝UntiRouter，它請(qǐng)求的負(fù)責(zé)單元識(shí)別和路由，用戶單元?jiǎng)澐质峭ㄟ^記錄用戶與單元關(guān)系的路由表來控制。

PS：因歷史原因緩存使用了tair和自建的uredis(在redis基礎(chǔ)上添加了基于log的數(shù)據(jù)同步功能)，目前已經(jīng)在逐步統(tǒng)一到tair。數(shù)據(jù)同步依賴tair和alisql的數(shù)據(jù)同步方案，以及自建的uredis數(shù)據(jù)同步能力。
**
就近接入實(shí)現(xiàn)方案**

為滿足高德業(yè)務(wù)低延時(shí)要求，就要想辦法做到數(shù)據(jù)(單元)離用戶更近，其中有兩個(gè)關(guān)鍵鏈路，一個(gè)是通過aserver接入的外網(wǎng)連接，另一個(gè)是服務(wù)內(nèi)部路由(盡可能不產(chǎn)生跨單元路由)。

措施1：客戶端的外網(wǎng)接入通過aserver上的配置，將不同地理區(qū)域(七個(gè)大區(qū))的設(shè)備劃分到對(duì)應(yīng)近的單元，如華北用戶接入張北單元。

措施2：通過記錄用戶和單元關(guān)系的路由表來劃分用戶所屬單元，這個(gè)關(guān)系是通過系統(tǒng)日志分析出來的，用戶經(jīng)常從哪個(gè)單元入口進(jìn)來，就會(huì)把用戶劃分到哪個(gè)單元，從而保證請(qǐng)求入口和單元?jiǎng)澐值南鄬?duì)一致，從而減少跨單元路由。

所以，在最終的單元路由實(shí)現(xiàn)上我們提供了傳統(tǒng)的取模路由，和為降延時(shí)而設(shè)計(jì)的基于路由表路由兩種策略。同時(shí)，為解無須登錄的業(yè)務(wù)場(chǎng)景問題，上述兩種策略除了支持用戶ID，我們同時(shí)也支持設(shè)備ID。

路由表設(shè)計(jì)

路由表分為兩部分，一個(gè)是用戶-分組的關(guān)系映射表，另一個(gè)是分組-單元的關(guān)系映射表。在使用時(shí)，通過路由表查對(duì)應(yīng)的分組，再通過分組看用戶所屬單元。分組對(duì)應(yīng)中國(guó)大陸的七個(gè)大區(qū)。

先看“用戶-(大區(qū))分組”：

路由表是定期通過系統(tǒng)日志分析出來的，看用戶最近IP屬于哪個(gè)大區(qū)就劃分進(jìn)哪個(gè)分組，同時(shí)也對(duì)應(yīng)上了具體單元。當(dāng)一個(gè)北京的用戶長(zhǎng)期去了深圳，因IP的變化路由表更新后將劃進(jìn)新大區(qū)分組，從而完成用戶從張北單元到深圳單元的遷移。

再看“分組-單元”：

分組與單元的映射有一個(gè)默認(rèn)關(guān)系，這是按地理就近來配置的，比如華南對(duì)應(yīng)深圳。除了默認(rèn)的映射關(guān)系，還有幾個(gè)用于切流預(yù)案的關(guān)系映射。

老用戶可以通過路由表來查找單元，新用戶怎么辦？對(duì)于新用戶的處理我們會(huì)降級(jí)成取模的策略進(jìn)行單元路由，直至下次路由表的更新。所以整體上看新用戶跨單元路由比例肯定是比老用戶大的多，但因?yàn)樾掠脩羰且粋€(gè)相對(duì)穩(wěn)定的增量，所以整體比例在可接受范圍內(nèi)。

路由計(jì)算

有了路由表，接下來就要解工程化應(yīng)用的問題，性能、空間、靈活性和準(zhǔn)確率，以及對(duì)服務(wù)穩(wěn)定性的影響這幾個(gè)方面是要進(jìn)行綜合考慮的，首先考慮外部存儲(chǔ)會(huì)增加服務(wù)的穩(wěn)定性風(fēng)險(xiǎn)，后面我們?cè)贐loomFilter 、BitMap和MapDB多種方案中選擇BloomFilter，萬分之幾的誤命中率導(dǎo)致的跨單元路由在業(yè)務(wù)可接受范圍內(nèi)。

通過日志分析出用戶所屬大區(qū)后，我們將不同分組做成多個(gè)布隆過濾器，計(jì)算時(shí)逐層過濾。這個(gè)計(jì)算有兩種特殊情況：

1) 因?yàn)锽loomFilter存在誤算率，有可能存在一種情況，華南分組的用戶被計(jì)算到華北了，這種情況比例在萬分之3 (生成BloomFilter時(shí)可調(diào)整)，它對(duì)業(yè)務(wù)上沒有什么影響，這類用戶相當(dāng)于被劃分到一個(gè)非所在大區(qū)的分組里，但這個(gè)關(guān)系是穩(wěn)定的，不會(huì)影響到業(yè)務(wù)，只是存在跨單元路由，是可接受的。

2) 新用戶不在分組信息里，所以經(jīng)過逐層的計(jì)算也沒有匹配到對(duì)應(yīng)大區(qū)分組，此時(shí)會(huì)使用取模進(jìn)行模除分組的計(jì)算。

如果業(yè)務(wù)使用的是取模路由而非路由表路由策略，則直接根據(jù)tid或uid計(jì)算對(duì)應(yīng)的模除分組，原理簡(jiǎn)單不詳表了。

單元切流

在發(fā)生單元故障進(jìn)行切流時(shí)，主要分為四步驟

打開單元禁寫 (跨單元寫不敏感業(yè)務(wù)可以不配置)

檢查業(yè)務(wù)延時(shí)

切換預(yù)案

解除單元禁寫

PS：更新路由表時(shí)，也需要上述操作，只是第3步的切換預(yù)案變成切換新版本路由表；單元禁寫主要是了等待數(shù)據(jù)同步，避免數(shù)據(jù)不一致導(dǎo)致的業(yè)務(wù)問題。

核心指標(biāo)

單元計(jì)算耗時(shí)1~2ms

跨單元路由比例底于5%

除了性能外，因就近接入的訴求，跨單元路由比例也是我們比較關(guān)心的重要指標(biāo)。從線上觀察看，路由表策略單元計(jì)算基本上在1、2ms內(nèi)完成，跨單元路由比例3%左右，整體底于5%。

四、后續(xù)優(yōu)化

統(tǒng)一接入集成單元化能力

目前大部分服務(wù)都接入了統(tǒng)一接入網(wǎng)關(guān)服務(wù)，在網(wǎng)關(guān)集成單元化能力將大大減少服務(wù)單元化部署的成本，通過簡(jiǎn)單的配置就可以實(shí)現(xiàn)單元路由，服務(wù)可將更多的精力放在業(yè)務(wù)的單元封閉和數(shù)據(jù)同步上。

分組機(jī)制的優(yōu)化

按大區(qū)分組存在三個(gè)問題：

通過IP計(jì)算大區(qū)有一定的誤算率，會(huì)導(dǎo)致部分用戶劃分錯(cuò)誤分組。

分組粒度太大，單元切流時(shí)流量不好分配。舉例，假如華東是我們用戶集中的大區(qū)，切流時(shí)把這個(gè)分組切到任意一個(gè)指定單元，都會(huì)造成單元服務(wù)壓力過大。

計(jì)算次數(shù)多，分多少個(gè)大區(qū)，理論最大計(jì)算次數(shù)是有多少次，最后采取取模策略。

針對(duì)上述幾個(gè)問題我們計(jì)劃對(duì)分組機(jī)制做如下改進(jìn)

通過用戶進(jìn)入單元的記錄來確認(rèn)用戶所屬單元，而非根據(jù)用戶IP所在大區(qū)來判斷，解上述問題1。

每個(gè)單元?jiǎng)澐?個(gè)虛擬分組，支持更細(xì)粒度單元切流，解上述問題2。

用戶確實(shí)單元后，通過取模來劃分到不同的虛擬分組。每個(gè)單元只要一次計(jì)算就能完成，新用戶只需經(jīng)過3次計(jì)算，解上述問題3。

熱更時(shí)的雙表計(jì)算

與取模路由策略不同，路由表策略為了把跨單元路由控制在一個(gè)較好的水平需要定期更新，目前更新時(shí)需要一個(gè)短暫的單元禁寫，這對(duì)于很多業(yè)務(wù)來說是不太能接受的。

為優(yōu)化這個(gè)問題，系統(tǒng)將在路由表更新時(shí)做雙(路由)表計(jì)算，即將新老路由表同時(shí)加載進(jìn)內(nèi)存，更新時(shí)不再對(duì)業(yè)務(wù)做完全的禁寫，我們會(huì)分別計(jì)算當(dāng)前用戶(或設(shè)備)在新老路由表的單元結(jié)果，如果單元一致，則說明路由表的更新沒有導(dǎo)致該用戶(或設(shè)備)變更單元，所以請(qǐng)求會(huì)被放行，相反如果計(jì)算結(jié)果是不同單元，說明發(fā)生了單元變更，該請(qǐng)求會(huì)被攔截，直至到達(dá)新路由表的一個(gè)完全起用時(shí)間。

優(yōu)化前服務(wù)會(huì)完全禁寫比如10秒(時(shí)間取決于數(shù)據(jù)同步時(shí)間)，優(yōu)化后會(huì)變成觸發(fā)禁寫的是這10秒內(nèi)路由發(fā)生變更的用戶，這將大大減少對(duì)業(yè)務(wù)的影響。

服務(wù)端數(shù)據(jù)驅(qū)動(dòng)的單元化場(chǎng)景

前面提到高德在路由策略上結(jié)合業(yè)務(wù)的特別設(shè)計(jì)，但整體單元?jiǎng)澐诌€是以用戶(或設(shè)備)為維度來進(jìn)行的，但高德業(yè)務(wù)還有一個(gè)大的場(chǎng)景是我們未來要面對(duì)和解決的，就是以數(shù)據(jù)維度驅(qū)動(dòng)的單元設(shè)計(jì)，基于終端的服務(wù)路由會(huì)變成基于數(shù)據(jù)域的服務(wù)路由。

高德很多服務(wù)是以服務(wù)數(shù)據(jù)為核心的，像地圖數(shù)據(jù)等它并非由用戶直接產(chǎn)生。業(yè)務(wù)的發(fā)展數(shù)據(jù)存儲(chǔ)也將不斷增加，包括5G和自動(dòng)駕駛，對(duì)應(yīng)數(shù)據(jù)的爆發(fā)式增長(zhǎng)單點(diǎn)全量存儲(chǔ)并不實(shí)現(xiàn)，以服務(wù)端數(shù)據(jù)驅(qū)動(dòng)的服務(wù)單元化設(shè)計(jì)，是我們接下來要考慮的重要應(yīng)用場(chǎng)景。

寫在最后

不同的業(yè)務(wù)場(chǎng)景對(duì)單元化會(huì)有不同的訴求，我們提供不同的策略和能力供業(yè)務(wù)進(jìn)行選擇，對(duì)于多數(shù)據(jù)服務(wù)我們建議使用業(yè)務(wù)取模路由，簡(jiǎn)單且易于維護(hù)；對(duì)于RT敏感的服務(wù)使用路由表的策略來盡可能的降低服務(wù)響應(yīng)時(shí)長(zhǎng)的影響。另外，要注意的是強(qiáng)依賴性的服務(wù)要采用相同的路由策略。

原文鏈接
本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎(jiǎng)勵(lì)來咯，堅(jiān)持創(chuàng)作打卡瓜分現(xiàn)金大獎(jiǎng)

總結(jié)

以上是生活随笔為你收集整理的高德服务单元化方案和架构实践的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。