LBS檢索容災架構研究

符穎

摘要：文章結合LBS檢索場景提出了一個穩定性容災架構，通過過載保護、容災環境、負載調度、分級發布等幾部分相互配合，為在線檢索服務提供了一個離線、在線相互配合的沙盒環境。該容災架構能在任一個檢索服務容量不足時快速地做出響應并將流量引導到安全環境下，保證對用戶的影響降到最低，為服務的快速發布提供更多的保障。

關鍵詞：容災系統；過載保護；容災cache；負載均衡；分級發布

隨著移動互聯網技術的不斷發展，互聯網開發模式采用持續迭代的方式來持續驅動服務的不斷升級，并采用分級/灰度發布的方式實現在線迭代產品特性。互聯網開發模式在快速改變著互聯網研發生態的同時也引入了更多的穩定性風險，而服務的持續穩定是至關重要的，引入更快的迭代開發可能帶來服務質量的下降，降低穩定性風險是研究互聯網開發模式的重點。本文結合LBS檢索業務場景，引入容災體系架構，為快速迭代開發的業務構建穩定性的容災環境，解決服務穩定性等問題。并設計一種主動容災系統，其結合影響在線服務穩定性的若干因素，使其一旦發生異常時盡可能減少對用戶的影響。

1在線服務穩定性綜述

1.1影響在線服務穩定性的若干因素

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

1.2主動容災系統設計

主動容災系統設計的主要目標是通過實時診斷監測可能的異常行為并立即進行補救處理，將對用戶的影響降到最低甚至無影響。整體架構如圖1所示。

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

2在線穩定性系統設計

2.1過載保護

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

從容量的角度來講，可以分為2個方面：一是極端情況下的服務宕機，會導致拒絕及服務容量的突然下降，服務宕機通過心跳或連接狀態等都能比較快地發現；一種則是服務異常或流量突增導致系統臨時容量不足，服務宕機進一步規約宕機也可認為是容量不足。

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

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

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

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

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

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

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

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

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

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

2.2負載調度

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

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

2.3容災環境

前節中主要介紹了過載保護和負載調度，負載調度會將檢索服務無法處理的流量引導到容災環境中。容災環境包括容災cache和延遲環境。

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

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

為保證長尾query的召回，在容災環境中增加了延遲環境，所謂延遲環境是2天以前的線上環境的鏡像，其數據和服務都是靜止的，且經歷過了至少2天線上流量的驗證，可以認為是穩定的，長尾流量會被容災環境進一步導到延遲環境做進一步的召回。

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

2.4分級發布

分級發布包括服務變更和數據變更的分級發布2種形式。通過分級發布，可以有效地控制因發布帶來的穩定性、效果風險，通過只影響少量用戶的快速驗證，規避更大的影響，一旦發布出現問題就可以快速回滾。

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

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

3結語

本文創造性地使用活躍線程數判定服務的過載狀態，大大簡化了過載判斷的復雜度，減少了額外的風險。通過過載保護/負載調度/容災環境構建了一個穩健的在線容災系統，創新性地對容災作了一個系統級的抽象，在其他的復雜計算的業務場景下也具有比較好的借鑒價值。

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