一、為什麼要做單元化
隨著業務體量和服務使用者群體的增長，單機房或同城雙機房無法支援服務的持續擴容。
異地容災已經成為核心服務的標配，有的服務雖然進行了多地多機房部署，但資料還是只在中心機房，實現真正意義上的異地多活，就需要對服務進行單元化改造。
二、高德單元化的特點
在做高德單元化專案時，我們首先要考慮的是結合高德的業務特點，看高德的單元化有什麼不一樣的訴求，這樣就清楚哪些經驗和方案是可以直接拿來用的，哪些又是需要我們去解決的。
1.使用者裝置的單元接入需要盡可能的做到就近接入，使用者真實地理位置接近哪個單元就接入哪個單元，如華北使用者接入到張北，華南接入到深圳。
2.使用者的單元劃分最好能與就近接入的單元保持一致，減少單元間的跨單元路由。如使用者請求從深圳進來，使用者的單元劃分最好就在深圳單元，如果劃到張北單元就會造成跨單元路由。
另外乙個區別就是高德很多業務是無須登入的，所以我們的單元化方案除了使用者id也要支援基於裝置id。
三、高德單元化實踐
服務的單元化架構改造需要乙個至上而下的系統性設計，核心要解決請求路由、單元封閉、資料同步三方面問題。
請求路由：根據高德業務的特點，我們提供了取模路由和路由表路由兩種策略，目前上線應用使用較多的是路由表路由策略。
單元封閉：得益於集團的基礎設施建設，我們使用vipserver、hsf等服務治理能力保證服務同機房呼叫，從而實現單元封閉(hsf unit模式也是一種可行的方案，但個人認為同機房呼叫的架構和模式更簡潔且易於維護)。
資料同步：資料部分使用的是集團db產品提供的drc資料同步。
單元路由服務採用什麼樣的部署方案是我們另乙個要面臨的問題，考慮過以下三種方案：
第一種sdk的方式因為對業務的強侵入性是首先被排除的，統一接入層進行**和去中心化外掛程式整合兩種方案各有利弊，但當時首批要接入單元化架構的服務很多都還沒有統一接入到gateway，所以基於現狀的考慮使用了去中心化外掛程式整合的方式，通過在應用的nginx整合unitrouter。
服務單元化架構
以賬號系統為例介紹下高德單元化應用的整體架構。
賬號系統服務是三地四機房部署，資料分別儲存在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，萬分之幾的誤命中率導致的跨單元路由在業務可接受範圍內。
通過日誌分析出使用者所屬大區後，我們將不同分組做成多個布隆過濾器，計算時逐層過濾。這個計算有兩種特殊情況：
1) 因為bloomfilter存在誤算率，有可能存在一種情況，華南分組的使用者被計算到華北了，這種情況比例在萬分之3 (生成bloomfilter時可調整)，它對業務上沒有什麼影響，這類使用者相當於被劃分到乙個非所在大區的分組裡，但這個關係是穩定的，不會影響到業務，只是存在跨單元路由，是可接受的。
2) 新使用者不在分組資訊裡，所以經過逐層的計算也沒有匹配到對應大區分組，此時會使用取模進行模除分組的計算。
如果業務使用的是取模路由而非路由表路由策略，則直接根據tid或uid計算對應的模除分組，原理簡單不詳表了。
單元切流
在發生單元故障進行切流時，主要分為四步驟
開啟單元禁寫 (跨單元寫不敏感業務可以不配置)
檢查業務延時
切換預案
解除單元禁寫
ps：更新路由表時，也需要上述操作，只是第3步的切換預案變成切換新版本路由表；單元禁寫主要是了等待資料同步，避免資料不一致導致的業務問題。
核心指標
單元計算耗時1~2ms
跨單元路由比例底於5%
除了效能外，因就近接入的訴求，跨單元路由比例也是我們比較關心的重要指標。從線上觀察看，路由表策略單元計算基本上在1、2ms內完成，跨單元路由比例3%左右，整體底於5%。
四、後續優化
統一接入整合單元化能力
目前大部分服務都接入了統一接入網關服務，在閘道器整合單元化能力將大大減少服務單元化部署的成本，通過簡單的配置就可以實現單元路由，服務可將更多的精力放在業務的單元封閉和資料同步上。
分組機制的優化
按大區分組存在三個問題：
通過ip計算大區有一定的誤算率，會導致部分使用者劃分錯誤分組。
分組粒度太大，單元切流時流量不好分配。舉例，假如華東是我們使用者集中的大區，切流時把這個分組切到任意乙個指定單元，都會造成單元服務壓力過大。
計算次數多，分多少個大區，理論最大計算次數是有多少次，最後採取取模策略。
針對上述幾個問題我們計畫對分組機制做如下改進
通過使用者進入單元的記錄來確認使用者所屬單元，而非根據使用者ip所在大區來判斷，解上述問題1。
每個單元劃分4個虛擬分組，支援更細粒度單元切流，解上述問題2。
使用者確實單元後，通過取模來劃分到不同的虛擬分組。每個單元只要一次計算就能完成，新使用者只需經過3次計算，解上述問題3。
熱更時的雙表計算
與取模路由策略不同，路由表策略為了把跨單元路由控制在乙個較好的水平需要定期更新，目前更新時需要乙個短暫的單元禁寫，這對於很多業務來說是不太能接受的。
為優化這個問題，系統將在路由表更新時做雙(路由)表計算，即將新老路由表同時載入進記憶體，更新時不再對業務做完全的禁寫，我們會分別計算當前使用者(或裝置)在新老路由表的單元結果，如果單元一致，則說明路由表的更新沒有導致該使用者(或裝置)變更單元，所以請求會被放行，相反如果計算結果是不同單元，說明發生了單元變更，該請求會被攔截，直至到達新路由表的乙個完全起用時間。
優化前服務會完全禁寫比如10秒(時間取決於資料同步時間)，優化後會變成觸發禁寫的是這10秒內路由發生變更的使用者，這將大大減少對業務的影響。
服務端資料驅動的單元化場景
前面提到高德在路由策略上結合業務的特別設計，但整體單元劃分還是以使用者(或裝置)為維度來進行的，但高德業務還有乙個大的場景是我們未來要面對和解決的，就是以資料維度驅動的單元設計，基於終端的服務路由會變成基於資料域的服務路由。
高德很多服務是以服務資料為核心的，像地圖資料等它並非由使用者直接產生。業務的發展資料儲存也將不斷增加，包括5g和自動駕駛，對應資料的爆發式增長單點全量儲存並不實現，以服務端資料驅動的服務單元化設計，是我們接下來要考慮的重要應用場景。
寫在最後
不同的業務場景對單元化會有不同的訴求，我們提供不同的策略和能力供業務進行選擇，對於多資料服務我們建議使用業務取模路由，簡單且易於維護；對於rt敏感的服務使用路由表的策略來盡可能的降低服務響應時長的影響。另外，要注意的是強依賴性的服務要採用相同的路由策略。
C C 單元自動化測試解決方案實踐
vivo 網際網路伺服器團隊 li qingxin c c 開發效率一直被業內開發人員詬病，單元測試開發效率也是如此，以至於開發人員不願花時間來寫單元測試。那麼我們是不是可以通過改善編寫單元測試的效率來提公升專案的測試用例覆蓋率？上圖展示了c c 單元測試的基本流程，在日常開發過程中寫單元測試是一項...
微服務架構視覺化平台實踐
隨著企業進行微服務架構改造，系統架構複雜度越來越高，架構變化日益頻繁，微服務改造後的實際架構模型可能與預期已經產生了巨大差異，架構師或系統運維人員很難準確記憶所有資源例項的構成和互動情況 其次，系統架構在動態演化過程中可能引入了一些不可靠的因素，比如弱依賴變強依賴 區域性容量不足 系統耦合過重等，給...
微服務架構視覺化平台實踐
隨著企業進行微服務架構改造，系統架構複雜度越來越高，架構變化日益頻繁，微服務改造後的實際架構模型可能與預期已經產生了巨大差異，架構師或系統運維人員很難準確記憶所有資源例項的構成和互動情況 其次，系統架構在動態演化過程中可能引入了一些不可靠的因素，比如弱依賴變強依賴 區域性容量不足 系統耦合過重等，給...