實(shí)踐解析：大眾點(diǎn)評賬號業(yè)務(wù)高可用進(jìn)階之路

  在任何一家互聯(lián)網(wǎng)公司，不管其主營業(yè)務(wù)是什么，都會有一套自己的賬號體系。賬號既是公司所有業(yè)務(wù)發(fā)展留下的最寶貴資產(chǎn)，它可以用來衡量業(yè)務(wù)指標(biāo)，例如日活、月活、留存等，同時(shí)也給不同業(yè)務(wù)線提供了大量潛在用戶，業(yè)務(wù)可以基于賬號來做用戶畫像，制定各自的發(fā)展路徑。因此，賬號服務(wù)的重要性不言而喻，同時(shí)美團(tuán)業(yè)務(wù)飛速發(fā)展，對賬號業(yè)務(wù)的可用性要求也越來越高。本文將分享一些我們在高可用探索中的實(shí)踐。

　　衡量一個(gè)系統(tǒng)的可用性有兩個(gè)指標(biāo)：

　　1. MTBF (Mean Time Between Failure)即平均多長時(shí)間不出故障;

　　2. MTTR (Mean Time To Recovery)即出故障后的平均恢復(fù)時(shí)間。

　　通過這兩個(gè)指標(biāo)可以計(jì)算出可用性，也就是我們大家比較熟悉的“幾個(gè)9”。

　　每條監(jiān)控都會根據(jù)過去的業(yè)務(wù)曲線計(jì)算出一條基線(見下圖)，用來跟當(dāng)前數(shù)據(jù)做對比，超出設(shè)定的閾值后就會觸發(fā)告警。

　　2. 柔性可用

　　柔性可用的目的是延長不出故障的時(shí)間，當(dāng)業(yè)務(wù)依賴的下游服務(wù)出故障時(shí)不影響自身的核心功能或服務(wù)。賬號對上層業(yè)務(wù)提供的鑒權(quán)和查詢服務(wù)即核心服務(wù)，這些服務(wù)的QPS非常高，業(yè)務(wù)方對服務(wù)的可用性要求很高，別說是服務(wù)故障，就連任何一點(diǎn)抖動都是不能接受的。對此我們先從整體架構(gòu)上把服務(wù)拆分，其次在服務(wù)內(nèi)對下游依賴做資源隔離，都盡可能的縮小故障發(fā)生時(shí)的影響范圍。

　　另外對非關(guān)鍵路徑上的服務(wù)故障做了降級。例如賬號的一個(gè)查詢服務(wù)依賴Redis，當(dāng)Redis抖動的時(shí)候服務(wù)的可用性也隨之降低，我們通過公司內(nèi)部另外一套緩存中間件Tair來做Redis的備用存儲，當(dāng)檢測到Redis已經(jīng)非常不可用時(shí)就切到Tair上。

　　通過開源組件Hystrix或者我們公司自研的中間件Rhino就能非常方便地解決這類問題，其原理是根據(jù)最近一個(gè)時(shí)間窗口內(nèi)的失敗率來預(yù)測下一個(gè)請求需不需要快速失敗，從而自動降級，這些步驟都能在毫秒級完成，相比人工干預(yù)的情況提升幾個(gè)數(shù)量級，因此系統(tǒng)的可用性也會大幅提高。下圖是優(yōu)化前后的對比圖，可以非常明顯的看到，系統(tǒng)的容錯能力提升了，TP999也能控制在合理范圍內(nèi)。

　　對于關(guān)鍵路徑上的服務(wù)故障我們可以減少其影響的用戶數(shù)。比如手機(jī)快捷登錄流程里的某個(gè)關(guān)鍵服務(wù)掛了，我們可以在返回的失敗文案上做優(yōu)化，并且在登錄入口掛小黃條提示，讓用戶主動去其他登錄途徑，這樣對于那些設(shè)置過密碼或者綁定了第三方的用戶還有其他選擇。

　　具體的做法是我們在每個(gè)登錄入口都關(guān)聯(lián)了一個(gè)計(jì)數(shù)器，一旦其中的關(guān)鍵節(jié)點(diǎn)不可用，就會在受影響的計(jì)數(shù)器上加1，如果節(jié)點(diǎn)恢復(fù)，則會減1，每個(gè)計(jì)數(shù)器還分別對應(yīng)一個(gè)標(biāo)志位，當(dāng)計(jì)數(shù)器大于0時(shí)，標(biāo)志位為1，否則標(biāo)志位為0。我們可以根據(jù)當(dāng)前標(biāo)志位的值得知登錄入口的可用情況，從而在登錄頁展示不同的提示文案，這些提示文案一共有2^5=32種。

　　3. 異地多活

　　除了柔性可用，還有一種思路可以來延長不出故障的時(shí)間，那就是做冗余，冗余的越多，系統(tǒng)的故障率就越低，并且是呈指數(shù)級降低。不管是機(jī)房故障，還是存儲故障，甚至是網(wǎng)絡(luò)故障，都能依賴冗余去解決，比如數(shù)據(jù)庫可以通過增加從庫的方式做冗余，服務(wù)層可以通過分布式架構(gòu)做冗余，但是冗余也會帶來新的問題，比如成本翻倍，復(fù)雜性增加，這就要衡量投入產(chǎn)出比。

　　目前美團(tuán)的數(shù)據(jù)中心機(jī)房主要在北京上海，各個(gè)業(yè)務(wù)都直接或間接的依賴賬號服務(wù)，盡管公司內(nèi)已有北上專線，但因?yàn)閷＞€故障或抖動引發(fā)的賬號服務(wù)不可用，間接導(dǎo)致的業(yè)務(wù)損失也不容忽視，我們就開始考慮做跨城的異地冗余，即異地多活。

　　3.1 方案設(shè)計(jì)

　　首先我們調(diào)研了業(yè)界比較成熟的做法，主流思路是分set化，優(yōu)點(diǎn)是非常利于擴(kuò)展，缺點(diǎn)是只能按一個(gè)維度劃分。比如按用戶ID取模劃分set，其他的像手機(jī)號和郵箱的維度就要做出妥協(xié)，尤其是這些維度還有唯一性要求，這就使得數(shù)據(jù)同步或者修改都增加了復(fù)雜度，而且極易出錯，給后續(xù)維護(hù)帶來困難?？紤]到賬號讀多寫少的特性(讀寫比是350:1)，我們采用了一主多從的數(shù)據(jù)庫部署方案，優(yōu)先解決讀多活的問題。

　　Redis如果也用一主多從的模式可行嗎?答案是不行，因?yàn)镽edis主從同步機(jī)制會優(yōu)先嘗試增量同步，當(dāng)增量同步不成功時(shí)，再去嘗試全量同步，一旦專線發(fā)生抖動就會把主庫拖垮，并進(jìn)一步阻塞專線，形成“雪崩效應(yīng)”。因此兩地的Redis只能是雙主模式，但是這種架構(gòu)有一個(gè)問題，就是我們得自己去解決數(shù)據(jù)同步的問題，除了保證數(shù)據(jù)不丟，還要保證數(shù)據(jù)一致。

　　另外從用戶進(jìn)來的每一層路由都要是就近的，因此DNS需要開啟智能解析，SLB要開啟同城策略，RPC已默認(rèn)就近訪問。

　　總體上賬號的異地多活遵循以下三個(gè)原則：

　　1. 北上任何一地故障，另一地都可提供完整服務(wù)。2. 北上兩地同時(shí)對外提供服務(wù)，確保服務(wù)隨時(shí)可用。3. 兩地服務(wù)都遵循BASE原則，確保數(shù)據(jù)最終一致。

　　最終設(shè)計(jì)方案如下：

　　寫并發(fā)時(shí)數(shù)據(jù)同步過程如下圖：

　　我們優(yōu)化的方向是在緩存加載時(shí)不同步，只有在數(shù)據(jù)庫有更新時(shí)才去同步。但是數(shù)據(jù)更新這個(gè)流程里不能再使用delete操作，這樣做有可能使緩存出現(xiàn)臟數(shù)據(jù)，比如下面這個(gè)例子：

　　從理論變?yōu)楣こ虒?shí)現(xiàn)的時(shí)候還有些需要注意的地方，比如同步消息沒發(fā)出去、數(shù)據(jù)收到后寫失敗了。因此我們還需要一個(gè)方法來檢測數(shù)據(jù)不一致的數(shù)量，為了做到這點(diǎn)，我們新建了一個(gè)定時(shí)任務(wù)去scan兩地的數(shù)據(jù)做對比統(tǒng)計(jì)，如果發(fā)現(xiàn)有不一致的還能及時(shí)修復(fù)掉。

　　項(xiàng)目上線后，我們也取得一些成果，首先性能提升非常明顯，異地的調(diào)用平均耗時(shí)和TP99、TP999均至少下降80%，并且在一次線上專線故障期間，賬號讀服務(wù)對外的可用性并沒有受影響，避免了更大范圍的損失。

　　總結(jié)

　　服務(wù)的高可用需要持續(xù)性的投入與維護(hù)，比如我們會每月做一次容災(zāi)演練。高可用也不止體現(xiàn)在某一兩個(gè)重點(diǎn)項(xiàng)目上，更多的體現(xiàn)在每個(gè)業(yè)務(wù)開發(fā)同學(xué)的日常工作里。任何一個(gè)小Bug都可能引起一次大的故障，讓你前期所有的努力都付之東流，因此我們的每一行代碼，每一個(gè)方案，每一次線上改動都應(yīng)該是仔細(xì)推敲過的。高可用應(yīng)該成為一種思維方式。最后希望我們能在服務(wù)高可用的道路上越走越遠(yuǎn)。

　　本文轉(zhuǎn)載自美團(tuán)技術(shù)團(tuán)隊(duì)微信公眾號，作者: 堂堂 德鑫 楊正，轉(zhuǎn)載授權(quán)請聯(lián)系原創(chuàng)作者（meituantech）！