LBS檢索容災(zāi)架構(gòu)研究

符穎

摘要：文章結(jié)合LBS檢索場景提出了一個穩(wěn)定性容災(zāi)架構(gòu)，通過過載保護、容災(zāi)環(huán)境、負載調(diào)度、分級發(fā)布等幾部分相互配合，為在線檢索服務(wù)提供了一個離線、在線相互配合的沙盒環(huán)境。該容災(zāi)架構(gòu)能在任一個檢索服務(wù)容量不足時快速地做出響應(yīng)并將流量引導(dǎo)到安全環(huán)境下，保證對用戶的影響降到最低，為服務(wù)的快速發(fā)布提供更多的保障。

關(guān)鍵詞：容災(zāi)系統(tǒng)；過載保護；容災(zāi)cache；負載均衡；分級發(fā)布

隨著移動互聯(lián)網(wǎng)技術(shù)的不斷發(fā)展，互聯(lián)網(wǎng)開發(fā)模式采用持續(xù)迭代的方式來持續(xù)驅(qū)動服務(wù)的不斷升級，并采用分級/灰度發(fā)布的方式實現(xiàn)在線迭代產(chǎn)品特性?；ヂ?lián)網(wǎng)開發(fā)模式在快速改變著互聯(lián)網(wǎng)研發(fā)生態(tài)的同時也引入了更多的穩(wěn)定性風(fēng)險，而服務(wù)的持續(xù)穩(wěn)定是至關(guān)重要的，引入更快的迭代開發(fā)可能帶來服務(wù)質(zhì)量的下降，降低穩(wěn)定性風(fēng)險是研究互聯(lián)網(wǎng)開發(fā)模式的重點。本文結(jié)合LBS檢索業(yè)務(wù)場景，引入容災(zāi)體系架構(gòu)，為快速迭代開發(fā)的業(yè)務(wù)構(gòu)建穩(wěn)定性的容災(zāi)環(huán)境，解決服務(wù)穩(wěn)定性等問題。并設(shè)計一種主動容災(zāi)系統(tǒng)，其結(jié)合影響在線服務(wù)穩(wěn)定性的若干因素，使其一旦發(fā)生異常時盡可能減少對用戶的影響。

1在線服務(wù)穩(wěn)定性綜述

1.1影響在線服務(wù)穩(wěn)定性的若干因素

影響在線服務(wù)穩(wěn)定性的服務(wù)級因素因服務(wù)變更帶來更大的穩(wěn)定性風(fēng)險。服務(wù)級的故障包括3個方面，其中用戶請求包括突發(fā)流量和異常流量，突發(fā)流量可能導(dǎo)致服務(wù)上限被打破，異常流量可能導(dǎo)致整個服務(wù)的崩潰。變更包括服務(wù)變更、程序升級、基礎(chǔ)數(shù)據(jù)的實時更新等。系統(tǒng)因素可以定義為服務(wù)所在的宿主節(jié)點的網(wǎng)絡(luò)等突發(fā)故障或被爭搶帶來服務(wù)異常表現(xiàn)的一些因素。這類問題的觸發(fā)本身是不可抗力的，但可以通過服務(wù)級的調(diào)度快速發(fā)現(xiàn)并隔離這些異常節(jié)點。

1.2主動容災(zāi)系統(tǒng)設(shè)計

主動容災(zāi)系統(tǒng)設(shè)計的主要目標(biāo)是通過實時診斷監(jiān)測可能的異常行為并立即進行補救處理，將對用戶的影響降到最低甚至無影響。整體架構(gòu)如圖1所示。

整體架構(gòu)包括4個部分：過載保護主要通過活躍線程狀態(tài)指標(biāo)快速判定服務(wù)當(dāng)前是否處于過載狀態(tài)，一旦過載就會立即拒絕無法及時處理的請求并向上匯報過載狀態(tài)，主要通過檢測活躍線程的狀態(tài)趨勢對服務(wù)狀態(tài)作出可能的判斷。容災(zāi)環(huán)境提供了保證服務(wù)穩(wěn)定輸出的在線環(huán)境，它由容災(zāi)cache和延遲環(huán)境2個部分組成。負載調(diào)度是面向服務(wù)的頂層節(jié)點進行調(diào)度，通過對頂層節(jié)點作過載判斷或異常隔離來對頂層節(jié)點進行實時流量調(diào)度與負載均衡，當(dāng)項層節(jié)點容量不足或不可用的時候，會實時將流量引到容災(zāi)系統(tǒng)。分級發(fā)布主要包括服務(wù)和數(shù)據(jù)的發(fā)布，通過分級發(fā)布實現(xiàn)數(shù)據(jù)或服務(wù)的灰度上線。

2在線穩(wěn)定性系統(tǒng)設(shè)計

2.1過載保護

容量和性能對于在線服務(wù)是非常重要的，一般情況下通過擴容或性能優(yōu)化不斷地提升服務(wù)容量，滿足更多的用戶訪問需求，通過不斷的優(yōu)化性保證用戶的訪問體驗。對于在線服務(wù)而言，服務(wù)不可用是災(zāi)難性的。常規(guī)的容災(zāi)手段多數(shù)屬于事后容災(zāi)，因此如何通過服務(wù)行為的變化快速診斷出可能的系統(tǒng)異常十分重要。

從容量的角度來講，可以分為2個方面：一是極端情況下的服務(wù)宕機，會導(dǎo)致拒絕及服務(wù)容量的突然下降，服務(wù)宕機通過心跳或連接狀態(tài)等都能比較快地發(fā)現(xiàn)；一種則是服務(wù)異?；蛄髁客辉鰧?dǎo)致系統(tǒng)臨時容量不足，服務(wù)宕機進一步規(guī)約宕機也可認(rèn)為是容量不足。

容量不足不等于系統(tǒng)完全不可用，需要極力規(guī)避服務(wù)容量不足時的雪崩效應(yīng)以保證容量不足時的最大化輸出，但處理不當(dāng)就會導(dǎo)致整個系統(tǒng)的癱瘓，在這種情況下，一個穩(wěn)定、可靠的擁塞預(yù)判檢測機制就顯得尤為重要。常見的擁塞判定方式包括：通過隊列狀態(tài)判斷和根據(jù)QPS判斷。

以上2個指標(biāo)在系統(tǒng)的負載狀態(tài)上都有一定缺陷。對于檢索服務(wù)而言，磁盤讀寫、網(wǎng)絡(luò)I/O消耗相對比較低，基于此觀測每個線程的任務(wù)調(diào)度狀態(tài)，如圖2所示，其中綠色塊表示被調(diào)度的任務(wù)。

結(jié)合圖2，正常情況下在一個時間切片下活躍任務(wù)數(shù)比較小，在CPU利用率較低的時候工作線程大部分時段空閑，在線程數(shù)換I/0的模型下任務(wù)活躍代表占用了CPU時間，因為使用I/0消耗在總時間中的比例等比例放大工作線程個數(shù)，因此本文使用工作線程活躍狀態(tài)表征系統(tǒng)負載。

在線程數(shù)換I/0模型下，工作線程數(shù)的設(shè)置一般會結(jié)合計算、I0的消耗去設(shè)定，如果在計算密集型服務(wù)下一般和CPU核數(shù)保持一致就可以，在I/0消耗的服務(wù)下可以根據(jù)I/0消耗占比調(diào)大工作線程數(shù)，使用I/0換計算。在檢索線程模型下，設(shè)置合理的工作線程數(shù)代表了服務(wù)滿載時的計算能力，因此當(dāng)前服務(wù)CPU利用率的計算方法如下：

其中C代表線程計數(shù)，分子為活躍線程計數(shù)，分母為總的工作線程數(shù)，P則為CPU利用率。

對于在線服務(wù)來說，為保證服務(wù)的穩(wěn)定高性能輸出、多機房互備的資源儲備，CPU利用率一般不希望超過40%，在這種情況下應(yīng)當(dāng)結(jié)合服務(wù)的計算、I/0消耗的比例，所能承載的最大活躍線程數(shù)也相應(yīng)地確定。

活躍線程數(shù)指標(biāo)是基于cPU利用率提出的，但磁盤、I/O出現(xiàn)性能問題的時候也同樣會在活躍線程數(shù)上有一定表現(xiàn)。一般情況下總的工作線程數(shù)需提前計算，磁盤、I/0故障時CPU利用率不會明顯變化，但性能會下降，活躍線程數(shù)也會快速膨脹，當(dāng)活躍線程超過一定限度的時候同樣可以被認(rèn)定為過載。

一般情況下系統(tǒng)容量不足的時候會快速影響工作線程數(shù)，但活躍線程數(shù)的變化會有一個膨脹的過程，通過捕獲到這個過程并快速處理，在系統(tǒng)實際過載前將無法處理的流量及時丟棄，直到活躍線程數(shù)穩(wěn)定恢復(fù)到合理的范圍，同時在流量丟棄的過程中不斷地向上通報服務(wù)過載。

基于活躍線程數(shù)的過載保護機制如圖3所示，為防止活躍線程數(shù)抖動對過載判斷造成影響，本文過載判斷設(shè)計了3個階段：過載發(fā)現(xiàn)、過載模式和過載退場。

LBs檢索系統(tǒng)由多個模塊組成，采用的是相似的網(wǎng)絡(luò)/線程模型，每個服務(wù)節(jié)點只對自己負責(zé)，同時接收下游節(jié)點服務(wù)的狀態(tài)匯報，當(dāng)前節(jié)點接收到下游服務(wù)的狀態(tài)匯報狀態(tài)時，會根據(jù)下游節(jié)點是否是關(guān)鍵節(jié)點向上主動匯報自己是否可用，形成一個逐級向上傳遞的匯報鏈。對于檢索服務(wù)接入的第一個服務(wù)節(jié)點，稱之為頂層節(jié)點。負載調(diào)度將檢索服務(wù)與其他外部服務(wù)隔離開來。通過服務(wù)自身的過載及可用性判斷形成了完整的過載判斷，下游業(yè)務(wù)節(jié)點的狀態(tài)通過處理并逐級上報后最終匯總到頂層節(jié)點下，頂層節(jié)點進一步將過載狀態(tài)匯報給負載調(diào)度服務(wù)，完成檢索服務(wù)狀態(tài)的最終匯報。

2.2負載調(diào)度

在容災(zāi)系統(tǒng)的設(shè)計中，檢索服務(wù)頂層節(jié)點以下的所有業(yè)務(wù)模塊出現(xiàn)了影響整體容量的問題時，容災(zāi)系統(tǒng)應(yīng)該都能檢測出來并給出合理的處理。在這種情況下，容災(zāi)系統(tǒng)的設(shè)計需有一個負載調(diào)度用來隔離業(yè)務(wù)系統(tǒng)和外部接入，并在檢測到頂層節(jié)點異常時及時觸發(fā)容災(zāi)調(diào)度。為保證容災(zāi)系統(tǒng)的穩(wěn)定工作，負載調(diào)度層需高度穩(wěn)定，對其進行升級改造的頻率是非常低的，所以將其設(shè)計為一個獨立的服務(wù)。

ATR是負載調(diào)度服務(wù)，其主要作用是對下游節(jié)點進行狀態(tài)管理，并根據(jù)節(jié)點狀態(tài)進行負載均衡和流量分發(fā)。通過下游項層節(jié)點的主動匯報及ATR向下對頂層節(jié)點的主動探測來獲取下游服務(wù)的狀態(tài)。它的核心功能包括4個部分：過載檢測、異常隔離、負載調(diào)度和ATR異常隔離隊列，其中ATR異常隔離隊列包括過載隊列、異常隊列、不可用隊列和離線隊列。ATR服務(wù)獨立一層完成對檢索服務(wù)的調(diào)度與穩(wěn)定性隔離，下游服務(wù)異常時能夠非常靈敏地將流量遷移到容災(zāi)環(huán)境中。

2.3容災(zāi)環(huán)境

前節(jié)中主要介紹了過載保護和負載調(diào)度，負載調(diào)度會將檢索服務(wù)無法處理的流量引導(dǎo)到容災(zāi)環(huán)境中。容災(zāi)環(huán)境包括容災(zāi)cache和延遲環(huán)境。

在LBS檢索場景下，結(jié)果狀態(tài)由于和位置相關(guān)，結(jié)果級cache的命中率是極低的，由于容災(zāi)本身就是一種降級手段，在實際簽名設(shè)計中考慮了位置的泛化，保留了核心請求參數(shù)對用戶query作簽名訓(xùn)練容災(zāi)cache，以泛需求檢索[美食]為例，用戶可能在相聚幾十米的2個地方搜美食，結(jié)果是不一樣的。在容災(zāi)降級場景下，其檢索結(jié)果可以一樣，對用戶不會有明顯的感知，本文采用加權(quán)投票的方式確定在一個geo區(qū)塊內(nèi)的cache結(jié)果選擇，如圖4所示。

對于檢索服務(wù)而言，請求query分布有高中低頻之分，高中頻query連續(xù)2天都會有一定概率的重復(fù)出現(xiàn)，但一些低頻query可能1年也出現(xiàn)不了幾次，而容災(zāi)cache是基于歷史日志訓(xùn)練的，對于命中率不能得到絕對的保證，在實際測試中，LBS檢索下的cache命中率大概78%。

為保證長尾query的召回，在容災(zāi)環(huán)境中增加了延遲環(huán)境，所謂延遲環(huán)境是2天以前的線上環(huán)境的鏡像，其數(shù)據(jù)和服務(wù)都是靜止的，且經(jīng)歷過了至少2天線上流量的驗證，可以認(rèn)為是穩(wěn)定的，長尾流量會被容災(zāi)環(huán)境進一步導(dǎo)到延遲環(huán)境做進一步的召回。

這樣，通過容災(zāi)cache和延遲環(huán)境的相互配合提供了100%的檢索容災(zāi)服務(wù)。為防止容災(zāi)服務(wù)對新版本客戶端的影響，每一次發(fā)版測試階段都會例行使用新版本客戶端對容災(zāi)環(huán)境進行一次逆向驗證。這種100%容災(zāi)是相對的，是建立在假定容災(zāi)環(huán)境和線上環(huán)境不會同時故障的情況下的，所以容災(zāi)環(huán)境的穩(wěn)定性是必須實時保障的。

2.4分級發(fā)布

分級發(fā)布包括服務(wù)變更和數(shù)據(jù)變更的分級發(fā)布2種形式。通過分級發(fā)布，可以有效地控制因發(fā)布帶來的穩(wěn)定性、效果風(fēng)險，通過只影響少量用戶的快速驗證，規(guī)避更大的影響，一旦發(fā)布出現(xiàn)問題就可以快速回滾。

發(fā)布階段對穩(wěn)定性的影響主要包括響應(yīng)時間變差、結(jié)果不穩(wěn)定、服務(wù)宕機或服務(wù)無法啟動等，對效果的影響主要是檢索結(jié)果質(zhì)量變差。服務(wù)無法正常啟動這類問題比較容易規(guī)避，而大部分問題往往都是在提供服務(wù)之后觸發(fā)的。在正常提供服務(wù)階段，處理流程命中了臟數(shù)據(jù)或局部分支導(dǎo)致內(nèi)存被寫亂都可能導(dǎo)致比較嚴(yán)重的穩(wěn)定性問題，基于此，分級發(fā)布必然需要伴生在線測試來保證分級的效果。在線測試語料的選擇要盡可能全面地覆蓋業(yè)務(wù)場景、邏輯分支。另外，在線測試觸發(fā)的時間點的選擇也要盡可能地保證程序&數(shù)據(jù)分支己大部分被預(yù)熱。

為防止在一些極端的場景下服務(wù)全部崩潰導(dǎo)致所有服務(wù)完全不可用，在線測試的時間點需要盡可能選擇大于一次崩潰自動拉起的時間周期，這樣即便有大面積崩潰也始終能保證大部分服務(wù)還可以使用，提供盡力而為的服務(wù)。

3結(jié)語

本文創(chuàng)造性地使用活躍線程數(shù)判定服務(wù)的過載狀態(tài)，大大簡化了過載判斷的復(fù)雜度，減少了額外的風(fēng)險。通過過載保護/負載調(diào)度/容災(zāi)環(huán)境構(gòu)建了一個穩(wěn)健的在線容災(zāi)系統(tǒng)，創(chuàng)新性地對容災(zāi)作了一個系統(tǒng)級的抽象，在其他的復(fù)雜計算的業(yè)務(wù)場景下也具有比較好的借鑒價值。

通過對復(fù)雜的業(yè)務(wù)線如檢索提供容災(zāi)系統(tǒng)是很有意義的，在容災(zāi)系統(tǒng)的保護下對線上變更能更加從容，能比較有效地規(guī)避流量的突然增加、服務(wù)崩潰、服務(wù)性能突然變差對用戶的影響。容災(zāi)系統(tǒng)上線后，檢索服務(wù)還沒有出現(xiàn)過因服務(wù)穩(wěn)定性導(dǎo)致的服務(wù)拒絕。服務(wù)宕機導(dǎo)致服務(wù)大面積不可用這種情況的觸發(fā)概率本身就很低，1年最多也就兩三次，但一旦發(fā)生對用戶的影響就會是極端惡劣的，一旦觸發(fā)它的作用是巨大的，為此在日常的維護中需要絕對保證容災(zāi)環(huán)境的實時可用，避免容災(zāi)環(huán)境和線上服務(wù)同時不可用的慘況。