瓜田老梁

讀完需要

4

分鐘

速讀僅需 2 分鐘

老梁，GitChat&CSDN 專欄《RocketMQ 實戰與進階》聯合作者、參與了《RocketMQ 技術內幕》審稿工作。

微服務成了互聯網架構的標配模式，對微服務之間的調用的流量治理和管控就尤為重要。哪些場景需要流量防控，針對這些場景又有哪些應對措施。有沒有一個通用的措施來降低風險呢？這篇文章咱就聊聊這個。

1

? ?

服務被過載調用

應對措施：針對服務提供方 D 配置流量防護規則，對進入服務 D 的流量進行控制，從而對服務 D 提供保護。觸發流控時可以有多重策略，例如：快速失敗、預熱模式、排隊等待、預熱模式+排隊等待。

快速失敗：發生流控時直接拋出異常。

預熱模式：發生流控時，流量緩慢增加的一種模式，效果如下圖所示，流量 QPS 從 200 緩慢增加到 600。

排隊等待：請求勻速通過，過多請求需要排隊，此時排隊有超時時間，超過排隊時間拋出流控異常。效果如下圖所示：請求 QPS 保持 1000 的勻速通過。

預熱模式+排隊等待：這種模式是預熱和排隊等待的疊加模式，請求以勻速的方式緩慢增加。如下圖：請求從 0 緩慢增加到 500，勻速通過一段時間后，再增加到 1000。

2

? ?

服務慢調用或故障

下面的場景 A 調用 B、A 調用 C、A 調用 D，當服務 B 服務不穩定時，服務 A 調用服務 B 發生了慢調用或者大量異常錯誤。這種場景，如果不干預，可能影響到 A 調用 C 和 A 調用 D 的狀況。

應對措施：A 調用 B 配置熔斷降級規則，當服務 B 不穩定發生慢調用或者異常時，如果觸發閾值，將服務 B 的調用熔斷；從而保護了服務 A 調用 C、服務 A 調用 D 的正常情況。

熔斷效果： 熔斷的實現通常通過斷路器實現，具體過程為：

• 當滿足慢調用比例、異常比例、異常數量閾值后，觸發熔斷（OPEN），在熔斷時長內拒絕所有請求

• 當熔斷過了定義的熔斷時長，狀態由熔斷（OPEN）變為探測（HALF_OPEN）

• 接下來的一個請求不發生慢調用或者異常，熔斷結束由探測狀態（HALF_OPEN）變為（CLOSED）

• 接下來的一個請求發生慢調用或者異常，繼續熔斷，由探測狀態（HALF_OPEN）變為（OPEN）

3

? ?

服務資源被擠占

分布式鏈路中，如果某一條鏈路產生慢調用，對其他鏈路造成擠壓。除了上面提到配置熔斷降級外，可以通過線程并發控制來隔離。下圖中有 3 條鏈路，其中鏈路 1 由于服務 E 的不穩定，產生了慢調用。

鏈路標號調用鏈

鏈路1	服務A-->服務D#Method1-->服務E
鏈路2	服務B-->服務D#Method2-->服務F
鏈路3	服務C-->服務D#Method2-->服務G

鏈路 1 慢調用可能導致如下情況：

• 鏈路 1 線程數增多對服務 D 資源造成擠壓

• 對服務 D 資源的過度擠壓，鏈路 2 和鏈路 3 造成不穩定

• 極端情況導致整個服務 D 不可用，嚴重時引發雪崩

應對措施：通過對服務 D 的 MethodA1、MethodA2 的線程數并發設置規則，超過閾值時將會觸發阻斷，不再向下游調用，避免不可用引發雪崩。

并發控制效果 ：下圖中設置了調用方的并發線程數為 10，通過每分鐘的查詢可以看出，線程數一直保持在 10。

4

? ?

數據過熱擠占資源

熱點數據，比如：大促時的熱銷產品、秒殺類產品等。如下圖所示，如果不對熱點商品下單流量進行管控，可能對其他商品造成擠壓；影響整個商品下單體驗。

應對措施：通過對熱點參數測速，配置流控規則，超過閾值時觸發流控。例如：通過對入參產品 ID 進行測速，超過設置的閾值時，觸發流控，避免對其過度擠占資源。

5

? ?

通用防護分組措施

上面的現象中，無論是服務不穩定、還是被擠占、或者被過載調用。除了通過上述的防護措施外，可以對服務進行等級劃分并分組。

如下圖所示：服務 A 和服務 D 為核心服務、服務 B 和服務 C 為非核心服務。通過將服務 D 進行分組，分成了 1 組和 2 組。分組 1 只允許核心服務調用，分組 2 只允許非核心服務調用。

這樣做的好處：將流量進行物理隔離，避免由于非核心業務流量對核心業務流量造成擠壓、保護核心鏈路穩定性。

分組措施@1 通常可以更換注冊中心路徑實現，服務 A 和服務 D（分組 1）放在同一個注冊中心路徑（例如：soa-group1）；服務 B、服務 C、服務 D（分組 2）放在另一個不同的注冊中心路徑（例如：soa-group2）。

分組措施@2 通過對分組的服務節點打標實現，例如：服務 D（分組 1）節點被打標為 group1，服務 D（分組 2）節點被打標為 group2。在服務消費方訂閱節點時根據不同的分組篩選節點調用。

EOF

往期推薦

深入分布式緩存之EVCache探秘開局篇（文末贈書）

螞蟻金服資深技術專家經國：云原生時代微服務的高可用架構設計

一文看懂高可用：異地多活

阿里高級技術專家至簡: Service Mesh 在超大規模場景下的落地挑戰

歐創新：深度解析DDD中臺和微服務設計

神一樣的CAP理論在微服務中是如何應用的？

程序人家：你的老板逼你上微服務了嗎？？

緩存，確實很香，卻也很受傷！

微博技術專家陳波：百億級訪問量的應用如何做緩存架構設計

天弘基金首席架構師李鑫：微服務接口限流的算法及架構實現

已火 2 年，Service Mesh究竟給微服務帶來了什么？

波波老師: 解決微服務的數據一致性分發問題？

為什么我不推薦你盲目追求微服務？遲早要吃虧！

DevOps是微服務的秘方

阿里高級技術專家邱小俠：微服務架構的理論基礎 - 康威定律

導致微服務失敗的 11 個原因

停！你不需要微服務

緩存穿透、緩存擊穿和緩存雪崩實踐(附源碼)

可能是全網最通俗易懂的微服務架構改造解讀

想要加入中生代架構群的小伙伴，請添加群合伙人大白的微信

申請備注（姓名+公司+技術方向）才能通過哦！

? ?END ? ?? #架構師必備#點分享點點贊點在看

總結

以上是生活随笔為你收集整理的瓜田老梁：FA1# 微服务流控防护场景与应对措施的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。