并發程式設計-26 高并發處理手段之服務降級與服務熔斷 + 資料庫切庫分庫分表

文章目錄

• 服務降級與服務熔斷概述

• 服務降級舉例
• 服務熔斷 VS 服務降級
• 服務降級要考慮的問題
• Hystrix

• 資料庫切庫分庫分表
• 高可用的一些手段

服務降級與服務熔斷概述

服務熔斷： 一般是指軟體系統中，由于某些原因使得服務出現了過載現象，為防止造成整個系統故障，進而采用的一種保護措施，熔斷也可以稱為過載保護

服務降級: 當服務壓力劇增的時候根據目前的業務情況及流量對一些服務和頁面有政策的降級，以此緩解伺服器的壓力，以保證核心任務的進行。同時保證部分甚至大部分任務客戶能得到正确的響應。也就是目前的請求處理不了了或者出錯了，給一個預設的傳回。

服務降級舉例

• 逾時降級：主要配置好逾時時間和逾時重試次數和機制，并使用異步機制探測回複情況
• 失敗次數降級：主要是一些不穩定的api，當失敗調用次數達到一定閥值自動降級，同樣要使用異步機制探測回複情況
• 故障降級：比如要調用的遠端服務挂掉了（網絡故障、DNS故障、http服務傳回錯誤的狀态碼、rpc服務抛出異常），則可以直接降級。降級後的處理方案有：預設值（比如庫存服務挂了，傳回預設現貨）、兜底資料（比如廣告挂了，傳回提前準備好的一些靜态頁面）、緩存（之前暫存的一些緩存資料）
• 限流降級： 比如當秒殺或者搶購一些限購商品時，此時可能會因為通路量太大而導緻系統崩潰，此時我們會使用限流來進行限制通路量，當達到限流閥值，後續請求會被降級；降級後的處理方案可以是：排隊頁面（将使用者導流到排隊頁面等一會重試）、無貨（直接告知使用者沒貨了）、錯誤頁（如活動太火爆了，稍後重試）等等

服務熔斷 VS 服務降級

兩者其實從某些角度看是有一定的類似性的：

• 目的很一緻，都是從可用性可靠性着想，為防止系統的整體緩慢甚至崩潰，采用的技術手段
• 最終表現類似，對于兩者來說，最終讓使用者體驗到的是某些功能暫時不可達或不可用
• 粒度一般都是服務級别，當然，業界也有不少更細粒度的做法，比如做到資料持久層（允許查詢，不允許增删改）
• 自治性要求很高，熔斷模式一般都是服務基于政策的自動觸發，降級雖說可人工幹預，但在微服務架構下，完全靠人顯然不可能，開關預置、配置中心都是必要手段；

而兩者的差別也是明顯的：

• 觸發原因不太一樣，服務熔斷一般是某個服務（下遊服務）故障引起，而服務降級一般是從整體負荷考慮
• 管理目标的層次不太一樣，熔斷其實是一個架構級的處理，每個微服務都需要（無層級之分），而降級一般需要對業務有層級之分（比如降級一般是從最外圍服務開始）
• 實作方式不太一樣

服務降級要考慮的問題

• 核心和非核心服務
• 是否支援降級，降級政策
• 業務放通的場景，政策

Hystrix

具備擁有回退機制和斷路器功能的線程和信号隔離，請求緩存和請求打包（request collapsing），以及監控和配置等功能

如何使用，請參考以前的博文

Spring Cloud【Finchley】-08使用Hystrix實作容錯

Spring Cloud【Finchley】-09Feign使用Hystrix

Spring Cloud【Finchley】-10Hystrix監控

Spring Cloud【Finchley】-11Feign項目整合Hystrix監控

Spring Cloud【Finchley】-12使用Hystrix Dashboard實作Hystrix資料的可視化監控

資料庫切庫分庫分表

資料庫的瓶頸：

• 單個資料庫資料量太大(1-2T)： 對應的政策—>拆分為多個庫
• 單個資料庫伺服器壓力太大，讀寫瓶頸：對應的政策—>拆分為多個庫
• 單個表資料量過大：對應的政策—>分表

切庫的基礎：讀寫分離 ( 主庫/從庫)

自定義注解完成資料庫切庫：見以前的博文

Spring Boot2.x-09 基于Spring Boot 2.1.2 + Mybatis使用自定義注解實作資料庫切換

Spring Boot2.x-10 基于Spring Boot 2.1.2 + Mybatis 2.0.0實作多資料源，支援事務

高可用的一些手段

任務排程系統分布式： elastic-job + zookeeper ， 請參考 elastic-job+zookeeper實作分布式定時任務排程的使用（springboot版本）