歡迎光臨
每天分享高質量文章

【系統架構】億級Web 系統的容錯性實踐【上】

簡單重試機制

最容易也最簡單被人想到的容錯方式,當然就是“失敗重試”,總而言之,簡單粗暴!簡單是指它的實現通常很簡單,粗暴則是指使用不當,很可能會帶來系統“雪崩”的風險,因為重試意味著對後端服務的雙倍請求。

我們請求一個服務,如果服務請求失敗,則重試一次。假設,這個服務在常規狀態下是99.9%的成功率,因為某一次波動性的異常,成功率下跌到95%,那麼如果有重試機制,那麼成功率大概還能保持在99.75%。而簡單重試的缺陷也很明顯,如果服務真的出問題,很可能帶來雙倍流量,衝擊服務系統,有可能直接將服務衝垮。而在實際的真實業務場景,往往更嚴重,一個功能不可用,往往更容易引起用戶的“反覆點擊”,反而製造更大規模的流量衝擊。比起服務的成功率比較低,系統直接被衝擊到“掛掉”的後果明顯更嚴重。

簡單重試,要使用在恰當的場景。或者,主動計算服務成功率,成功率過低,就直接不做重試行為,避免帶來過高的流量衝擊。

主備服務自動切換

既然單一服務的重試,可能會給該帶來雙倍的流量衝擊,而最終導致更嚴重的後果,那麼我們不如將場景變為主備服務的自動重試或者切換。例如,我們搭建了兩套獲取openid的服務,如果服務A獲取失敗,則嘗試從服務B中獲取。因為重試的請求壓力是壓到了服務B上,服務A通常不會因為重試而產生雙倍的流量衝擊。

這種重試的機制,看似比較可用,而實際上也存在一些問題:

(1) 通常會存在“資源浪費”的問題。因為備份服務系統,很可能長期處於閑置狀態,只有在主服務異常的時候,它的資源才會被比較充分地使用。不過,如果對於核心的服務業務(例如核心資料、營收相關)進行類似的部署,雖然會增加一些機器成本和預算,但這個付出通常也是物有所值的。

(2) 觸發重試機制,對於用戶的請求來說,耗時必然增加。主服務請求失敗,然後再到備份服務請求,這個環節的請求耗時就至少翻倍增長,假設主服務出現連接(connect)超時,那麼耗時就更是大幅度增加。一個服務在正常狀態下,獲取資料也許只要50ms,而服務的超時時間通常會設置到500-1000ms,甚至更多,一旦出現超時重試的場景,請求耗時必然大幅度增長,很可能會比較嚴重地影響用戶體驗。

(3) 主備服務一起陷入異常。如果是因為流量過大問題導致主服務異常,那麼備份服務很可能也會承受不住這種級別的流量而掛掉。

重試的容錯機制,在AMS上有使用,但是相對比較少,因為我們認為主備服務,還是不足夠可靠。

動態剔除或恢復異常機器

在AMS里,我們的後端涉及數以百計的各類服務,來支撐整個運營系統的正常運作。所有後端服務或者儲存,首先是部署為無狀態的方式提供服務(一個服務通常很多台機器),然後,通過公司內的一個公共的智慧路由服務L5,納入到AMS中。

(1) 所有服務與儲存,無狀態路由。這樣做的目的,主要是為了避免單點風險,就是避免某個服務節點掛了,導致整個服務就癱瘓了。實際上,即使像一些具有主備性質(主機器掛了,支持切換到備份機器)的接入服務,也是不夠可靠的,畢竟只有2台,它們都掛了的情況,還是可能發生的。我們後端的服務,通常都以一組機器的形式提供服務,彼此之間沒有狀態關係,支撐隨機分配請求。

(2) 支持平行擴容。遇到大流量場景,支持加機器擴容。

(3) 自動剔除異常機器。在我們的路由服務,發現某個服務的機器異常的時候(成功率低於50%),就會自動剔除該機器,後續,會發出試探性的請求,確認等它恢復正常之後,再重新加回到服務機器組。

例如,假如一組服務下擁有服務機器四台(ABCD),假設A機器的服務因為某種未知原因,完全不可用了,這個時候L5服務會主動將A機器自動從服務組裡剔除,只保留BCD三台機器對外提供服務。而在後續,假如A機器從異常中恢復了,那麼L5再主動將機器A加回來,最後,又變成ABCD四台機器對外提供服務。

在過去的3年裡,我們逐步將AMS內的服務,漸漸從寫死IP串列或者主備狀態的服務,全部升級和優化為L5樣式的服務,慢慢實現了AMS後端服務的自我容錯能力。至少,我們已經比較少遇到,再因為某一臺機器的軟體或者硬體故障,而不得不人工介入處理的情況。我們也慢慢地從疲於奔命地處理告警的苦難中,被解放出來。

設置超時時間

呼叫任何一個服務或者儲存,一個合理的超時時間(超時時間,就是我們請求一個服務時,等待的最長時間),是非常重要的,而這一點往往比較容易被忽視。通常Web系統和後端服務的通信方式,是同步等待的樣式。這種樣式,它會帶來的問題比較多。

對於服務端,影響比較大的一個問題,就是它會嚴重影響系統吞吐率。假設,我們一個服務的機器上,啟用了100個處理請求的worker,worker的超時時間設置為5秒,1個worker處理1個任務的平均處理耗時是100ms。那麼1個work在5秒鐘的時間里,能夠處理50個用戶請求,然而,一旦網絡或者服務偶爾異常,響應超時,那麼在本次處理的後續整整5秒里,它僅僅處理了1個等待超時的失敗任務。一旦比較大概率出現這型別的超時異常,系統的吞吐率就會大面積下降,有可能耗盡所有的worker(資源被占據,全部在等待狀態,直到5s超時才釋放),最終導致新的請求無worker可用,只能陷入異常狀態。

算上網絡通信和其他環節的耗時,用戶就等待了超過5s時間,最後卻獲得一個異常的結果,用戶的心情通常是崩潰的。

解決這個問題的方式,就是設置一個合理的超時時間。例如,回到上面的的例子,平均處理耗時是100ms,那麼我們不如將超時時間從5s下調到500ms。從直觀上看,它就解決了吞吐率下降和用戶等待過長的問題。然而,這樣做本身又比較容易帶來新的問題,就是會引起服務的成功率下降。因為平均耗時是100ms,但是,部分業務請求本身耗時比較長,耗時超過500ms也比較多。例如,某個請求服務端耗時600ms才處理完畢,然後這個時候,客戶端認為等待超過500ms,已經斷開了連接。處理耗時比較長的這型別業務請求會受到比較明顯的影響。

解決超時時間過短帶來成功率下降問題

超時時間設置過短,會將很多本來處理成功的請求,當做服務超時處理掉,進而引起服務成功率下降。將全部業務服務,以一刀切的方式設置一個超時時間,是比較不可取的。優化的方法,我們分為兩個方向。

(1)快慢分離

根據實際的業務維度,區分對待地給各個業務服務配置不同的超時時間,同時,最好也將它們的部署服務也分離出來。例如,天天酷跑的查詢服務耗時通常為100ms,那麼超時時間我們就設置為1s,某新手游的查詢服務通常耗時為700ms,那麼我們就設置為5s。這樣的話,整體系統的成功率,就不會受到比較大的影響。

(2)解決同步阻塞的

“快慢分離”可以改善系統的同步等待問題,但是,對於某些耗時本來就比較長的服務而言,系統的行程/執行緒資源仍然在同步等待過程中,無法響應其他新的請求,只能阻塞等待,它的資源仍然是被占據,系統的整體吞吐率仍然被大幅度拉低。

解決的思路,當然是利用I/O多路復用,通過異步回呼的方式,解決同步等待過程中的資源浪費。AMS的一些核心服務,採用的就是“協程”(又叫“微執行緒”,簡單的說,常規異步程式代碼里嵌套比較多層的函式回呼,編寫複雜。而協程則提供了一種類似寫同步代碼的方式,來寫異步回呼程式),以解決同步等待的問題。異步處理的簡單描述,就是當行程遇到I/O網絡阻塞時,就保留現場,立刻切換去處理下一個業務請求,行程不會因為某個網絡等待而停止處理業務,進而,系統吞吐率即使遇到網絡等待時間過長的場景,通常都能保持在比較高的水平。

值得補充一點的是,異步處理只是解決系統的吞吐率問題,對於用戶的體驗問題,並不會有改善,用戶需要等待的時間並不會減少。

防重入,防止重覆發貨

前面我們提到,我們設置了一個比較“合理的超時時間”,簡而言之,就是一個比較短的超時時間。而在資料寫入的場景,會引起新的問題,就我們的AMS系統而言,就是發貨場景。如果是發貨請求超時,這個時候,我們需要思考的問題就比較多了。

1、發貨等待超時,發貨服務執行發貨失敗。這種場景,問題不大,後續用戶重新點擊領取按鈕,就可以觸發下一次重新發貨。

2、發貨等待超時,發貨服務實際在更晚的時候執行發貨成功,我們稱之為“超時成功”。比較麻煩的場景,則是每次都是發貨超時,而實際上都發貨成功,如果系統設計不當,有可能導致用戶可以無限領取禮包,最終造成活動運營事故。

第二種場景,給我們帶來了比較麻煩的問題,如果處理不當,用戶再次點擊,就觸發第多次“額外”發貨。

例如,我們假設某個發貨服務超時時間設置為6s,用戶點擊按鈕,我們的AMS收到請求後,請求發貨服務發貨,等待6s後,無響應,我們給用戶提示“領取失敗”,而實際上發貨服務卻在第8秒執行發貨成功,禮包到了用戶的賬戶上。而用戶看見“領取失敗”,則又再次點擊按鈕,最終導致“額外”多發一個禮包給到這個用戶。

例子的時序和流程圖大致如下:

這裡就提到了防重入,簡單的說,就是如何確認不管用戶點擊多少次這個領取按鈕,我們都確保結果只有一種預期結果,就是只會給用戶發一次禮包,而不引起重覆發貨。我們的AMS活動運營平臺一年上線的活動超過4000個,涉及數以萬計的各種型別、不同業務系統的禮包發貨,業務通信場景比較複雜。針對不同的業務場景,我們做了不同的解決方案:

1、業務層面限制,設置禮包單用戶限量。在發貨服務器的源頭,設置好一個用戶僅能最多獲得1個禮包,直接避免重覆發放。但是,這種業務限制,並非每個業務場景都通用的,只限於內部具備該限制能力的業務發貨系統,並且,有一些禮包本身就可以多次領取的,就不適用了。

2、訂單號機制。用戶的每一次符合資格的發貨請求,都生成一個訂單號與之對應,通過它來確保1個訂單號,只發貨1次。這個方案雖然比較完善,但是,它是依賴於發貨服務方配合做“訂單號發貨狀態更新“的,而我們的發貨業務方眾多,並非每一個都能支持”訂單號更新“的場景。

3、 自動重試的異步發貨樣式。用戶點擊領取禮包按鈕後,Web端直接傳回成功,並且提示禮包在30分鐘內到賬。對於後臺,則將該發貨錄入到發貨佇列或者儲存中,等待發貨服務異步發貨。因為是異步處理,可以多次執行發貨重試操作,直到發貨成功為止。同時,異步發貨是可以設置一個比較長的超時等待時間,通常不會出現“超時成功”的場景,並且對於前端響應來說,不需要等待後臺發貨狀態的傳回。但是,這種樣式,會給用戶帶來比較不好的體驗,就是沒有實時反饋,無法立刻告訴用戶,禮包是否到賬。

非訂單號的特殊防刷機制

某些特殊的合作場景,我們無法使用雙方約定訂單號方式,例如一個完全隔離獨立的外部發貨接口,不能和我們做訂單號的約定。基於這種場景,我們AMS專門做了一種防刷的機制,就是通過限制read超時的次數。但是,這種方案並非完美解決重覆發貨問題,只是能起到夠盡可能減少避免被刷的作用。一次網絡通信,通常包含:建立連接(connect),寫入資料發包(write),等待並且讀取回包(read),斷開連接(close)。

通常一個發貨服務如果出現異常,大多數情況,在connect步驟就是失敗或者超時,而如果一個請求走到等待回包(read)時超時,那麼發貨服務另外一邊就有可能發生了“超時但發貨成功”的場景。這個時候,我們將read超時的發生次數記錄起來,然後提供了一個配置限制次數的能力。假如設置為2次,那麼當一個用戶第一次領取禮包,遇到read超時,我們就允許它重試,當還遇到第二次read超時,就達到我們之前設置的閥值2,我們就認為它可能發貨成功,拒絕用戶的第三次領取請求。

這種做法,假設發貨服務真的出現很多超時成功,那麼用戶也最多只能刷到2次禮包(次數可配置),而避免發生禮包無限制被刷的場景。但是,這種方案並不完全可靠,謹慎使用。

在發貨場景,還會涉及分佈式場景下的CAP(一致性、可用性、分割槽容錯性)問題,不過,我們的系統並非是一個電商服務,大部分的發貨並沒有強烈的一致性要求。因此,總體而言,我們是弱化了一致性問題(核心服務,通過異步重試的方式,達到最終一致性),以追求可用性和分割槽容錯性的保證。

對於web系統容錯機制,還有服務降級、服務解耦等一系列方法將在下篇文章總結。

    已同步到看一看
    赞(0)

    分享創造快樂