本文分享自華為雲社群《建構高可用雲原生應用，如何有效進行流量管理？-雲社群-華為雲》，作者： breakDawn。
随着雲原生的概念越來越火，服務的架構應該如何發展和演進，成為很多程式員關心的話題。大名鼎鼎的《深入了解java虛拟機》一書作者于21年推出了新作《鳳凰架構》，從這本書中可以看到目前時下很多最新的技術或者理念。
是以本文以及後續都将持續沉澱釋出這本書的學習筆記和思考，也歡迎購買該書進行詳細學習，或者關注後續的學習筆記内容釋出，了解精華内容和總結思考。
流量治理
1 服務容錯
1.1 容錯政策
文章中介紹了故障轉移、快速失敗、安全失敗、沉默失敗、故障恢複、并行調用、廣播調用等幾種容錯政策，我用表格的形式直覺呈現一下這幾種政策的差別，友善了解和選型：
1.2 容錯設計模式
1.斷路器模式
即服務中發請求的地方都通過一個斷路器子產品來轉發發送
當10秒内請求數量達到20，且失敗門檻值達到50%以上（這些參數都可以調整）， 則認為出現問題， 于是主動進行服務熔斷， 斷路器收到的請求自動傳回錯誤，不再去調用遠端服務， 這樣可避免請求線程各種阻塞，能及時傳回報錯。
中間會保持有間隔的重試直到恢複後，關閉斷路。
2.艙壁隔離模式
如果一個服務中，可能要同時調用A\B\C三個服務，但是卻共用一個線程池。
如果調用C服務逾時，而調用C的請求源源不斷打來，會造成C服務的請求線程全在阻塞，直接把整體線程池給占滿了，影響了對A\B服務的調用。
一種隔離措施是對每個調用服務分别維護一個線程池。缺點是額外增加了排隊、排程、上下文切換的開銷，據說Hystrix線程池如果開啟了服務隔離，會增加3~10ms的延遲。
另一種隔離措施是直接自己定義三個服務的計數器，當服務線程數量到達門檻值，自動對這個服務調用做限流。
3.重試模式
故障轉移和故障恢複這2個政策一般都是借助重試模式來處理的，進行重複調用。
重試模式應該滿足以下條件才能使用：
- 僅在主路核心邏輯的關鍵服務上進行同步的重試， 而非關鍵的服務
- 隻對瞬時故障進行重試，對于業務故障不進行重試
- 隻對幂等型的服務進行重試
重試模式應該有明确的終止條件，例如：
- 逾時終止
- 次數終止
重試一定要謹慎開啟， 有時候在網關、負載均衡器裡也會配置一些預設的重試， 一旦鍊路很長且都有重試，那麼系統中重試的次數将會大大增加。
2 流量控制
流量控制需要解決以下3個問題
- 依據什麼名額來限流
- 如何限流
- 超額流量如何處理
2.1 流量統計名額(依據什麼名額來限流)
- 每秒事務數TPS： 事務是業務邏輯上具有原子操作的業務操作，對于對買書接口而言， 買書就是一個事務， 背後的其他請求是不感覺的。
- 每秒請求數HPS： 就是系統每秒處理的請求數， 如果1事務中隻有1個請求， 那麼TPS=HPS， 否則HPS>TPS
- 每秒查詢書QPS： 是一台伺服器能夠響應的查詢次數。 對于單節點系統而言，QPS=HPS，對于一個分布式系統而言HPS>TPS
通過限制最大TPS來限流的話，不能夠準确反映出系統的壓力， 是以主流系統傾向使用HPS作為首選的限流名額。
2.2 限流設計模式（如何限流）
流量計數器模式
統計每秒内的請求數是否大于門檻值
缺點：
- 每秒是基于1.0s-2.0這樣的區間統計， 但如果是0.5-1.5 和1.5-2.5分别超出門檻值，但是1.0-2.0沒有超過門檻值，則會出現問題。
- 每秒的請求超過門檻值，也不代表系統就真的承受不住，導緻五殺
滑動時間窗模式
滑動時間窗專門解決了流量計數器模式的缺點。
準備一個長度為10的數組，每秒觸發1次的定時器
①将數組最後一位的元素丢棄，并把所有元素都後移一位，然後在數組的第一位插入一個新的空元素
②将計數器中所有的統計資訊寫入第一位的空元素
③對數組中所有元素做統計，清空計數器資料
可以保證在任意時間片段内，隻通過簡單的調用計數比較， 控制請求次數不超過門檻值
缺點在于隻能用于否決式限流， 必須強制失敗或者降級，無法進行阻塞等待的處理。
漏桶模式
漏桶和令牌桶可以适用于阻塞等待的限流。
漏桶就是一個以請求對象作為元素的先入先出隊， 隊列程度等于漏桶大小，當隊列已滿拒絕信的請求進入。
比較困難的原因在于很難确定通的大小和水的流出速度，調參難度很大。
令牌桶模式
每隔一定時間，往桶裡放入令牌，最多可以放X個
每次請求消耗掉一個。
可以不依賴定時器實作令牌的放入，而是根據時間戳，在取令牌的時候當發現時間戳滿足條件則在那個時候放入令牌即可
2.3 分布式限流
前面的4個限流模式都隻是單機限流，經常放在網關入口處，不适用于整個服務叢集的複雜情況，例如有的服務消耗多有的服務消耗少，都放在入口處限流情況其實很多。
可以基于令牌桶的基礎上，在入口網關處給不同服務加不同的消耗令牌權重，達到分布式叢集限流的目的
總結
流量治理技術對雲原生場景的重要性
以上主要介紹了服務容錯和容錯設計模式，涉及到不同的容錯政策和容錯設計模式，如故障轉移、快速失敗、安全失敗、沉默失敗、故障恢複、并行調用和廣播調用。
這2個設計可以保證系統的穩定性和健壯性。這篇文章涉及的話題與雲原生服務息息相關，因為雲原生應用程式之間會頻繁通過進行請求和互動，需要通過容錯和彈性來保證高可用性。
是以，對于那些希望使用華為雲的雲原生服務的人來說，這篇文章提供了很好的指導，讓他們了解如何通過容錯來保證他們的服務的可用性和穩定性。
華為雲如何在流量治理中展現作用
如果能通過将服務API注冊到華為雲提供的APIG網關上，似乎能夠很友善地達成上述2個設計。
比如APIG支援斷路器政策，是API網關在後端服務出現性能問題時保護系統的内置機制。當API的後端服務出現連續N次逾時或者時延較高的情況下，會觸發斷路器的降級機制，向API調用方傳回固定錯誤或者将請求轉發到指定的降級後端。當後端服務恢複正常後，斷路器關閉，請求恢複正常。APIG-斷路器政策（https://support.huaweicloud.com/usermanual-apig/apig_03_0023.html）
同時APIG還提供了流量控制政策，支援從使用者、憑據和時間段等不同的次元限制對API的調用次數，保護後端服務。支援按分/按秒粒度級别的流量控制，閱讀了上文中提到的幾個流量政策，再去看APIG裡配置的流量政策值，則會很容易了解。APIG-流量控制政策（https://support.huaweicloud.com/usermanual-apig/apig_03_0025.html）
可以看到對于這些常見的經典服務設計政策，無需再重複造輪子，使用已有雲服務，可以很快地實作相關功能，提升産品的上線速度和疊代效率。
關注#華為雲開發者聯盟# 點選下方，第一時間了解華為雲新鮮技術~
華為雲部落格_大資料部落格_AI部落格_雲計算部落格_開發者中心-華為雲