前言
微服務成了網際網路架構的標配模式，對微服務之間的呼叫的流量治理和管控就尤為重要。哪些場景需要流量防控，針對這些場景又有哪些應對措施。有沒有乙個通用的措施來降低風險呢？這篇文章咱就聊聊這個。
一、服務被過載呼叫
當服務d的某個介面服務被上游服務過載呼叫時，如果不對服務d加入保護，可能整體將服務d整體拖垮。在這種場景中，我們需要對服務d配置限流，以保護服務d不被整體衝跨。
應對措施：針對服務提供方d配置流量防護規則，對進入服務d的流量進行控制，從而對服務d提供保護。觸發流控時可以有多重策略，例如：快速失敗、預熱模式、排隊等待、預熱模式+排隊等待。
快速失敗：發生流控時直接丟擲異常。
預熱模式：發生流控時，流量緩慢增加的一種模式，效果如下圖所示，流量qps從200緩慢增加到600。
排隊等待：請求勻速通過，過多請求需要排隊，此時排隊有超時時間，超過排隊時間丟擲流控異常。效果如下圖所示：請求qps保持1000的勻速通過。
預熱模式+排隊等待：這種模式是預熱和排隊等待的疊加模式，請求以勻速的方式緩慢增加。如下圖：請求從0緩慢增加到500，勻速通過一段時間後，再增加到1000。
二、服務慢呼叫或故障
下面的場景a呼叫b、a呼叫c、a呼叫d，當服務b服務不穩定時，服務a呼叫服務b發生了慢呼叫或者大量異常錯誤。這種場景，如果不干預，可能影響到a呼叫c和a呼叫d的狀況。
應對措施：a呼叫b配置熔斷降級規則，當服務b不穩定發生慢呼叫或者異常時，如果觸發閾值，將服務b的呼叫熔斷；從而保護了服務a呼叫c、服務a呼叫d的正常情況。
熔斷效果：熔斷的實現通常通過斷路器實現，具體過程為：
三、服務資源被擠占
分布式鏈路中，如果某一條鏈路產生慢呼叫，對其他鏈路造成擠壓。除了上面提到配置熔斷降級外，可以通過執行緒併發控制來隔離。
下圖中有3條鏈路，其中鏈路1由於服務e的不穩定，產生了慢呼叫。
應對措施：通過對服務d的methoda1、methoda2的執行緒數併發設定規則，超過閾值時將會觸發阻斷，不再向下游呼叫，避免不可用引發雪崩。
併發控制效果下圖中設定了呼叫方的併發執行緒數為10，通過每分鐘的查詢可以看出，執行緒數一直保持在10。
四、資料過熱擠占資源
熱點資料，比如：大促時的熱銷產品、秒殺類產品等。如下圖所示，如果不對熱點商品下單流量進行管控，可能對其他商品造成擠壓；影響整個商品下單體驗。
應對措施：通過對熱點引數測速，配置流控規則，超過閾值時觸發流控。例如：通過對入參產品id進行測速，超過設定的閾值時，觸發流控，避免對其過度擠占資源。
五、通用防護分組措施
上面的現象中，無論是服務不穩定、還是被擠占、或者被過載呼叫。除了通過上述的防護措施外，可以對服務進行等級劃分並分組。
如下圖所示：服務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。在服務消費方訂閱節點時根據不同的分組篩選節點呼叫。
有道無術，術可成；有術無道，止於術
好文章，我在看❤️
微服務與工作流
本文主要想談一談工作流在微服務系統中的使用以及工作流能夠為微服務系統帶來的好處。通過查詢資料可得，微服務的編排主要分為兩種形式，一種是 choreography 有人將其翻譯成微服務的編排 另一種是 orchestration 有人將其翻譯成微服務的編制。兩者的差異很簡單，前者是點對點互動，沒有乙個...
微服務專案的完整資訊流
api web 這個是根據業務實際情況來做的,乙個目的是引數校驗,各種控制統一在這裡,另乙個就是資料聚合,有些介面部分資料從a來 部分資料從b來,總得有地方給組合一下,讓a搞或者讓b搞都容易扯皮,索性就讓c來搞 是後端提供的所有的前端的介面 如果前端沒控制好 會在這一層再控制一次 前端通過api w...
結合實際場景談一談微服務配置
作為 nacos 5w1h 的系列文章，本文將圍繞 where 講述 nacos 配置管理的三個典型的應用場景 spring.datasource.url 生產環境的資料庫連線位址 spring.datasource.username 生產環境的資料庫使用者賬號 spring.datasource....