從本質上講，與流量削峰一樣，服務降級解決的也是在有限的系統資源下，需要承載超高流量的需求問題。像秒殺系統這種瞬時超高并發流量的場景，即使我們對系統做了流控措施，在整場秒殺活動下，如果系統持續處于高并發流量的壓力下，秒殺鏈路上部分服務就可能會出現問題。

所以，除了流控以外，我們對秒殺系統也要增加其他的容錯方案。

一、前言

在前面的文章中，我們對秒殺系統進行了一系列的優化措施。同時，對秒殺系統實現了分布式流控、單機限流的流控措施。引入了業務網關，能夠在業務網關層面實現分布式流控和單機流控。為了盡可能的將流控和數據校驗前置化，引入了流量網關。為了進一步保證秒殺系統整個交易鏈路上服務的穩定性，我們還需要對秒殺系統進行容錯處理，其中，服務降級就是秒殺系統中非常重要的一環。

二、本章訴求

講述服務降級的核心原理與落地實現方案，不只是秒殺系統適用，任何互聯網項目甚至傳統IT項目，在系統資源有限的情況下，需要支持高并發流量訪問。此時，都需要對系統進行降級處理，使系統能夠在資源有限的環境中，平穩運行。

三、服務降級

從本質上講，與流量削峰一樣，服務降級解決的也是在有限的系統資源下，需要承載超高流量的需求問題。像秒殺系統這種瞬時超高并發流量的場景，即使我們對系統做了流控措施，在整場秒殺活動下，如果系統持續處于高并發流量的壓力下，秒殺鏈路上部分服務就可能會出現問題，所以，除了流控以外，我們對秒殺系統也要增加其他的容錯方案。

當然，如果你的系統資源充足，或者訪問流量根本不高，此時可以不考慮服務降級。反之，如果系統資源有限，并且訪問系統的流量比較高，系統資源不足以支撐這么高的并發訪問流量時，就需要考慮服務降級了。

服務降級一般都是有損的，常見的服務降級方案有：寫服務降級、讀服務降級和精簡系統流程。

四、寫服務降級

學到這里，小伙伴們應該比較清楚了，在秒殺系統中，不可能是一個單體系統或者單個微服務在運行，往往是各個微服務組成了整個秒殺的交易鏈路，此時，就會涉及到多數據源的問題。

其實，盡管有數據一致性理論和分布式事務落地方案的指導，在多數據源場景下，數據的強一致性其實也是比較難以保證的，這不僅僅是分布式事務在高并發場景下實現比較困難，更是由于在高并發場景下，需要對強一致性和高可用性做出權衡和取舍。

因此，一般在涉及金融資產類對一致性要求比較高的場景時，才會使用強一致性分布式事務解決方案，其他場景下，會采用弱一致性或者最終一致性分布式事務方案來解決數據一致性的問題。

在訪問流量不高時，可以將寫請求直接路由到MySQL數據庫，再通過Canal監聽MySQL數據庫BinLog的變化，將變化的數據更新到Redis緩存，如圖95-1所示。

圖片

這種設計下，緩存與數據庫的數據就是最終一致的，通過將數據庫中的增量變化數據同步到緩存中，通過緩存可以抗更高的并發讀操作。但是，此時系統的寫操作會受限于數據庫磁盤的IO操作。

當訪問系統的流量激增時，就需要對寫操作進行降級，由先寫MySQL數據庫，再同步Redis緩存，降級為先寫Redis緩存，再異步寫MySQL數據庫。由Redis的強大讀寫能力來抗更高的并發流量，如圖95-2所示。

圖片

這里，通過降級寫服務，將寫數據庫的操作降級為寫Redis緩存，再異步寫MySQL數據庫，但是帶來的影響就是緩存數據與數據庫數據的一致性問題。這種為了追求性能而造成的數據一致性問題是比較常見的。我們可以設計一個定時任務比對數據，及時發現問題后進行修復。

五、讀服務降級

在高并發系統設計時，為了提供系統的讀性能，我們往往會設計多級緩存，此時，如果系統發生故障，則能夠及時降級止損。例如，在系統中，我們為讀操作設計了JVM內存緩存、Redis緩存后，又為系統增加了ES緩存，如圖95-3所示。

圖片

此時，如果Redis緩存出現故障，我們可以快速將讀請求降級到ES上。如果Redis和ES同時出現了故障（實際場景下很少會發生同時出現故障的情況），我們還可以快速將請求降級到MySQL數據庫。

六、精簡系統流程

正常情況下，我們在打開電商平臺的商詳頁時，除了會看到商品的基本信息外，還會看到一些商品的附加屬性信息，比如商品的排行、評價和推薦，商品的收藏數量以及當前用戶是都收藏過商品。在下單頁面，還會存在使用優惠券等等入口。

大家可以想象一下，其實，對于普通商品來說，這些附加信息越豐富越好，它能夠在一定程度上吸引用戶下單促成交易轉化。但是，在秒殺業務下，這些附加信息就不是越多越好了，秒殺系統要求響應迅速，性能高。此時，返回的數據越少、交互越少，整個交易鏈路越短，響應越快，用戶的體驗就越好。

所以，對于秒殺商品來說，就需要根據具體的情況確定是否要展示這些附加信息了，如果某個秒殺商品迅速成為了平臺的爆品，此時就需要對這種爆款商品進行附加信息的降級處理了，這也是對非核心功能的降級。對非核心功能進行降級，優先保證核心功能的正常運行。

七、降級開關設計

無論是寫服務降級，還是讀服務降級，亦或是精簡系統流程，我們都可以設計一個降級開關進行降級，通過降級開關進行一鍵降級，可以實現流量在不同的鏈路之間進行切換。具體實現上，我們可以通過配置中心，對降級開關進行變更，各個微服務會訂閱配置中心的配置，然后配置中心將變更的降級開關狀態推送到各個微服務實例上，如圖95-4所示。

圖片

可以看到，運營人員在配置中心控制臺變更降級開關狀態后，配置中心會將開關的狀態推送到各個微服務實例上，各個微服務實際就會即時生效，實現流量在不同的鏈路之間進行切換。

八、總結

本章，對服務降級的核心原理和落地方案進行了介紹。首先，簡單描述了本章的需求。隨后對服務降級進行了簡要的說明。并對寫服務降級、讀服務降級和精簡系統流程進行了簡單的說明。最后，簡單介紹了降級開關的設計。

九、寫在最后

在冰河的知識星球除了目前正在熱更的高性能網關和RPC視頻外，還有其他9個項目，像DeepSeek大模型、手寫高性能熔斷組件、手寫通用指標上報組件、手寫高性能數據庫路由組件、分布式IM即時通訊系統、Sekill分布式秒殺系統、手寫RPC、簡易商城系統等等，這些項目的需求、方案、架構、落地等均來自互聯網真實業務場景，讓你真正學到互聯網大廠的業務與技術落地方案，并將其有效轉化為自己的知識儲備。

節選自：《Seckill秒殺系統：第95章：服務降級核心原理與落地方案》一文，文章鏈接：https://articles.zsxq.com/id_ehf2k7838z4b.html