1. 首頁 > 生活百科 > >

微服務架構體系的深度治理 什么是架構體系？( 四 )

小知識架構體系


接下來再看看集群限流 ， 集群限流的情況要更復雜一些 ， 首先在各個微服務節點上要有一個計數器 ， 對單位時間片內的調用進行計數 ， 計數值會被定期的匯總到日志中心 ， 由統計分析器進行統一匯總 ， 算出這個時間片的總調用量 ， 集群限流分析器會拿到這個總調用量 ， 并和預先定義的限流閾值進行比對 ， 計算出一個限流比例 ， 這個限流比例會通過服務注冊中心下發到各個服務節點上 ， 服務節點基于限流比例會各自算出當前節點對應的最終限流閾值 ， 最后利用單機限流進行流控 。
我們可以看到 ， 這是一套環環相扣的、各環節緊密協作配合的技術體系 。 單純拎出一個點來看 ， 實現技術都不麻煩 ， 但要構建起這么一套貫穿整個技術棧的技術體系 ， 則需要有一套統一的技術標準 ， 各個環節都需要遵循這套標準 ， 對不符合標準的應用還要推動其進行改造 ， 才能保證標準落地 ， 有了標準之后才能推動各環節一點一點的改造構建起這套限流技術體系 ， 所以構建服務限流能力的難點 ， 一在于標準化 ， 二在于體系化 。
另外 ， 限流一大原則是限流動作盡量前置 ， 畢竟被限制的流量注定要被“拋棄” ， 越早處理越好 ， 免得無謂的消耗資源 。
【集群容錯】
接下來再來看看集群容錯 ， 集群容錯是微服務集群高可用的保障 ， 它有很多策略可供選擇 ， 包括：

  • 快速失?。‵ailfast）
  • 失敗轉移（Failover）
  • 失敗重試（Failback）
  • 聚合調用（Forking）
  • 廣播調用（Broadcast）
不管用哪種集群容錯策略 ， 一定要注意重試的次數 ， 尤其是線上負載已經很高的時候 ， 這時候如果重試次數太多 ， 一方面 ， 會推高服務被調用方的負載及并發 ， 另外一方面 ， 會導致服務調用方的調用延時增長 ， 雙重因素疊加之下 ， 最終極可能導致“服務雪崩” ， 導致集群被“擊穿” 。
所以 ， 在使用集群容錯的時候 ， 一定要設置最大重試次數 。
【服務降級】服務降級和服務限流類似 ， 也是微服務集群自我保護的機制 ， 一般在線上動用服務降級手段的時候 ， 都是線上比較危急的時候 ， 生死存亡了 ， 這時候留給你思考和反應的時間已經不多 ， 所以在使用服務降級之前一定要做好預案 ， 你要提前梳理出核心業務鏈路和非核心業務鏈路 ， 然后通過降級開關一鍵把部分或所有非核心鏈路降級 ， 這樣才能救命 。
服務降級也有很多手段可以使用 ， 包括：
  • 容錯降級
  • 靜態返回值降級
  • Mock降級
  • 備用服務降級
我們常說的熔斷 ， 本質上也是容錯降級策略的一種 ， 只不過它比一般容錯降級提供了更為豐富的容錯托底策略 ， 支持半開降級及全開降級模式 。 構建服務降級能力也和限流機制類似 ， 同樣需要堅持標準化和體系化 。
【故障定界定位】線上的故障定界定位應該是我們每天做的最多的事情 。 分布式環境下的故障定界定位 ， 最有效的工具就是動態調用鏈路跟蹤 ， 這應該是沒有疑義的 ， 不管你是使用開源的Zipkin ， SkyWalking、PinPoint、CAT ， 還是使用商用的聽云、AppDynamic或NewRelic等等 。
調用鏈本質上也是基于日志 ， 只不過它比常規的日志更重視日志之間的關系 。 在一個請求剛發起的時候 ， 調用鏈會賦予它一個跟蹤號（traceID） ， 這個跟蹤號會隨著請求穿越不同的網絡節點 ， 并隨著日志落盤 ， 日志被收集后 ， 可以根據traceID來對日志做聚合 ， 找到所有的關聯日志 ， 并按順序排序 ， 就能構建出這個請求跨網絡的調用鏈 ， 它能詳細描述請求的整個生命周期的狀況 。
動態調用鏈要用的好一定是需要和監控大盤相結合 。 介紹一下我們的使用經驗 ， 我們在很早之前就構建了動態調用鏈跟蹤體系 ， 在我們的監控大盤上有很多的點可以進入調用鏈：
1、我們有一個單位時間段內異常最多服務的TopN排序列表 ， 點擊列表上的任何一個服務 ， 會打開這個服務這個時間段內所有異常的列表 ， 再點擊列表上的每一個異常 ， 就會打開這個異常所屬調用鏈 ， 進行故障分析 。
2、可以利用監控大盤 ， 監控大盤上有很多“毛刺” ， 這些都是系統的一些異常點 ， 點擊任何一個“毛刺” ， 會將“毛刺”所在時間段內的請求以“散點”的形式列出（可能會基于請求數量做抽樣） ， “散點”的顏色代表了不同的狀態 ， 有的成功 ， 有的失敗 。 點擊任何一個“散點” ， 就可以進入這個請求對應的調用鏈 。

推薦閱讀