引言

穩(wěn)定性設(shè)計第一篇：在分布式系統(tǒng)下，線上的某一個功能按鈕背后會有很多個服務(wù)共同完成，這些服務(wù)之間有依賴關(guān)系，且有一定的順序調(diào)用。那么這些服務(wù)如果其中有一個環(huán)節(jié)出現(xiàn)問題，會帶來一些連鎖反應(yīng)。

比如，突如其來的流量，部分服務(wù)突然宕機(jī)，你能想到的故障都算故障，是不是整個服務(wù)都不可用了嗎？作為開發(fā)者肯定不希望這樣的事情發(fā)生，那么有哪些解決問題？思路就是盡量給每個服務(wù)找一個“備胎” ，這個“備胎”不是集群概念里一個備用機(jī)器 ，而是一種備用方案。

1、面試官：

你對你負(fù)責(zé)的系統(tǒng)做了哪些提高可用性的設(shè)計？

問題分析：穩(wěn)定性設(shè)計三把斧：降級、熔斷和限流。即使你沒用過，也可以完全根據(jù)我描述的場景再結(jié)合自己的項目編造一個。

答：這個問題很好理解，舉個例子：比如外賣訂單服務(wù)，假設(shè)美團(tuán)外賣訂單系統(tǒng)，系統(tǒng)日常QPS 在 1000 左右（這里我拍腦袋假設(shè)，實際遠(yuǎn)高于1000），可能受天氣影響或者是否工作日，QPS 會上下浮動，為1000 - 2000之間。

假設(shè)線上系統(tǒng)設(shè)計時最多能承受2000 QPS，正常會發(fā)生的突發(fā)情況單量增多都能承受，突然有那么一天，你的競爭對手餓了么宕機(jī)了，用戶無法使用都蜂擁而至來美團(tuán)下單，這個時候QPS 變成了 3000，系統(tǒng)扛不住 3000 的QPS怎么辦？用戶都卡在提交訂單的頁面，誰也下不了單。那么如何有效解決這個問題？這個時候就要想到“備胎”方案，嘗試以下優(yōu)化思路。

1. 流量控制：也就是限流，限流包括單機(jī)限流和集群限流，訂單系統(tǒng)某一環(huán)節(jié)加一個開關(guān)，好比地鐵進(jìn)站口，人多要排隊，保證流量持續(xù)進(jìn)入，而不是撐破服務(wù)器大家都無法使用，比如將系統(tǒng)QPS控制在最高2000，后面的 1000 用戶告訴他“系統(tǒng)繁忙，請稍后再試”，這樣一來無非就是多點(diǎn)幾下或者等幾分鐘，你還能吃上飯。
2. 降級備案：比如商品列表查詢，默認(rèn)查詢的是 Redis 集群，各種故障趕在一起，Redis 所有集群都掛了不能用了，這個時候怎么辦，設(shè)計一個備胎 Elasticsearch，查詢速度可能沒 Redis 快，但好歹備胎還能用。
3. 熔斷： 這個可以理解成家庭電路中的保險絲，電流有異常后自動開啟熔斷保護(hù)，系統(tǒng)流量也同樣原理。

舉例： 我對公司內(nèi)部訂單查詢系統(tǒng)做的優(yōu)化，訂單查詢是運(yùn)營人員每天都要使用的功能，一定要保證服務(wù)可用，還要迅速響應(yīng)，為了解決這個問題，我使用了ES作為查詢主庫，如ES故障，系統(tǒng)會自動降級到MySQL查詢，完美解決了性能和可用性的問題。

（有了上面這個例子，面試官對我在系統(tǒng)可用性方面的設(shè)計能力放心多了。）

Tip： 說了這么多不如直接看看圖形界面，限流到底是怎么用的，舉個例子，我負(fù)責(zé)的一個接口，限流參數(shù)設(shè)置是這樣的。

這是限流功能做成頁面可視化系統(tǒng)以后，看看紅色框備注和提示如何設(shè)置限流，是不是so easy，使用開源的 Hystrix 也能解決此類問題。

總結(jié)

這一節(jié)的內(nèi)容不多，最重要的是要知道系統(tǒng)穩(wěn)定性設(shè)計還有三把斧：降級、熔斷和限流，內(nèi)容并不難，重要的是你要有這個意識，你能做到讓系統(tǒng)全年不故障持續(xù)提供服務(wù)，領(lǐng)導(dǎo)把這事兒交給你放心，offer不是你的是誰的？

以上就是分布式系統(tǒng)中的降級熔斷設(shè)計問題面試的詳細(xì)內(nèi)容，更多關(guān)于分布式系統(tǒng)中的降級熔斷設(shè)計的資料請關(guān)注腳本之家其它相關(guān)文章！