架构设计之「服务限流」
原文:架構設計之「服務限流」
?
上一篇我們聊過了架構設計中的「服務隔離」模式,今天我們繼續來探索一下在分布式系統架構中的另一個常用的設計:服務限流。
那么,什么是「服務限流」呢??
在解釋「服務限流」之前,我們來看一下前些時間網上很火的一個段子,說的是新浪微博的一名工程師正在家里辦婚禮,突然接到公司的電話要緊急處理線上流量激增的問題,那天應該是某當紅明星突然在微博上公布戀情,微博流量突增好幾倍,導致系統功能出現不穩定,用戶訪問不暢。然后這名工程師就只好晾開新娘,在婚禮現場穿著西裝打開筆記本調試代碼了。
當時這名工程師內心肯定是崩潰的,肯定在想:為啥要在今天公布戀情!等我把系統的擴容和服務限流機制做好先啊。
哈哈,看完了段子,基本上服務限流的作用也就明白:?
服務限流其實是指當系統資源不夠,不足以應對大量請求,即系統資源與訪問量出現矛盾的時候,我們為了保證有限的資源能夠正常服務,因此對系統按照預設的規則進行流量限制或功能限制的一種方法。
一、為什么要做服務限流設計?
再舉一個我們生活中的例子:一些熱門的旅游景點,往往會對每日的旅游參觀人數有嚴格的限制,比如廈門的鼓浪嶼、北京的故宮等,每天只會賣出固定數目的門票,如果你去的晚了,可能當天的票就已經賣完了,當天就無法進去游玩了。
為什么旅游景點要做這樣的限制呢?多賣一些門票多賺一些錢豈不是更好?
其實對于旅游景點而言,她們也很無奈,因為景點的服務資源有限嘛,每日能服務的人數是有限的,一旦放開限制了,景點的工作人員就會不夠用,衛生情況也得不到保障,安全也有隱患,超密集的人群也會嚴重的影響游客的體驗。?
但由于景區名氣大,來游玩的旅客絡繹不絕,遠超出了景區的承載能力,因此景區只好做出限制每日人員流量的舉措。
同理,在IT軟件行業中,系統服務也是這樣的。
如果你的系統理論是時間單位內可服務100W用戶,但是今天卻突然來了300W用戶,由于用戶流量的隨機性,如果不加以限流,很有可能這300W用戶一下子就壓垮了系統,導致所有人都得不到服務。
因此為了保證系統至少還能為100W用戶提供正常服務,我們需要對系統進行限流設計。
有的人可能會想,既然會有300W用戶來訪問,那為啥系統不干脆設計成能足以支撐這么大量用戶的集群呢?
這是個好問題。如果系統是長期有300W的用戶來訪問,肯定是要做上述升級的,但是常常面臨的情況是,系統的日常訪問量就是100W,只不過偶爾有一些不可預知的特定原因導致的短時間的流量激增,這個時候,公司往往出于節約成本的考慮,不會為了一個不常見的尖峰來把我們的系統擴容到最大的尺寸。
二、服務限流應該怎么做?
對系統服務進行限流,一般有如下幾個模式:
這個模式是需要系統在設計之初,就要把熔斷措施考慮進去。當系統出現問題時,如果短時間內無法修復,系統要自動做出判斷,開啟熔斷開關,拒絕流量訪問,避免大流量對后端的過載請求。系統也應該能夠動態監測后端程序的修復情況,當程序已恢復穩定時,可以關閉熔斷開關,恢復正常服務。
將系統的所有功能服務進行一個分級,當系統出現問題,需要緊急限流時,可將不是那么重要的功能進行降級處理,停止服務,這樣可以釋放出更多的資源供給核心功能的去用。?
例如在電商平臺中,如果突發流量激增,可臨時將商品評論、積分等非核心功能進行降級,停止這些服務,釋放出機器和CPU等資源來保障用戶正常下單,而這些降級的功能服務可以等整個系統恢復正常后,再來啟動,進行補單/補償處理。?
除了功能降級以外,還可以采用不直接操作數據庫,而全部讀緩存、寫緩存的方式作為臨時降級方案。
這個模式需要在系統的前端設置一個流量緩沖池,將所有的請求全部緩沖進這個池子,不立即處理。然后后端真正的業務處理程序從這個池子中取出請求依次處理,常見的可以用隊列模式來實現。這就相當于用異步的方式去減少了后端的處理壓力,但是當流量較大時,后端的處理能力有限,緩沖池里的請求可能處理不及時,會有一定程度延遲。
這個模式需要將用戶進行分類,通過預設的分類,讓系統優先處理需要高保障的用戶群體,其它用戶群的請求就會延遲處理或者直接不處理。
那在實際項目中,對訪問流量的限制,可采用如下幾種技術方法:
- 熔斷技術
熔斷的技術可以重點參考Netflix的開源組件hystrix的做法,主要有三個模塊:熔斷請求判斷算法、熔斷恢復機制、熔斷報警。
?
?
- 計數器方法
系統維護一個計數器,來一個請求就加1,請求處理完成就減1,當計數器大于指定的閾值,就拒絕新的請求。?
基于這個簡單的方法,可以再延伸出一些高級功能,比如閾值可以不是固定值,是動態調整的。另外,還可以有多組計數器分別管理不同的服務,以保證互不影響等。 - 隊列方法
就是基于FIFO隊列,所有請求都進入隊列,后端程序從隊列中取出待處理的請求依次處理。?
基于隊列的方法,也可以延伸出更多的玩法來,比如可以設置多個隊列以配置不同的優先級。 - 令牌桶方法
首先還是要基于一個隊列,請求放到隊列里面。但除了隊列以外,還要設置一個令牌桶,另外有一個腳本以持續恒定的速度往令牌桶里面放令牌,后端處理程序每處理一個請求就必須從桶里拿出一個令牌,如果令牌拿完了,那就不能處理請求了。我們可以控制腳本放令牌的速度來達到控制后端處理的速度,以實現動態流控。
?
三、服務限流的注意事項
我們在做服務限流的時候,還是有一些原則和事項需要注意的:
- 實時監控:系統必須要做好全鏈路的實時監控,才能保證限流的及時檢測和處理。
- 手動開關:除系統自動限流以外,還需要有能手動控制的開關,以保證隨時都可以人工介入。
- 限流的性能:限流的功能理論上是會在一定程度影響到業務正常性能的,因此需要做到限流的性能優化和控制。
系統故障常常都是不可預測且難以避免的,因此作為系統設計師的我們,必須要提前預設各種措施,以應對隨時可能的系統風險。
?
?
posted on 2019-03-29 12:58 NET未來之路 閱讀(...) 評論(...) 編輯 收藏轉載于:https://www.cnblogs.com/lonelyxmas/p/10620593.html
總結
以上是生活随笔為你收集整理的架构设计之「服务限流」的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 为什么从前那些.NET开发者都不写单元测
- 下一篇: 简易promise的实现(二)