7月安卓手機(jī)性價(jià)比榜：努比亞+紅魔兩款新機(jī)入榜
7月登場(chǎng)的新機(jī)有努比亞Z50S Pro和紅魔8S Pro，除了三星之外目前唯二的兩款搭載超頻版驍龍8Gen2處理器的產(chǎn)品，而且努比亞和紅魔也一貫有著不錯(cuò)的性價(jià)比，所以在本次的性價(jià)比榜單
在實(shí)際業(yè)務(wù)運(yùn)行過程中，有一種故障影響可能沒有那么大，但發(fā)生的概率較高，這就是今天聊的接口級(jí)的故障。
接口級(jí)故障的典型表現(xiàn)就是，系統(tǒng)并沒有宕機(jī)、網(wǎng)絡(luò)也沒有中斷，但業(yè)務(wù)卻出現(xiàn)問題了，例如業(yè)務(wù)響應(yīng)緩慢、大量訪問超時(shí)和大量訪問出現(xiàn)異常（給用戶彈出提示“無法連接數(shù)據(jù)庫”）。
這類問題的主要原因在于系統(tǒng)壓力太大、負(fù)載太高，導(dǎo)致無法快速處理業(yè)務(wù)請(qǐng)求，由此引發(fā)更多的后續(xù)問題。最常見的情況就是，數(shù)據(jù)庫慢查詢將數(shù)據(jù)庫的服務(wù)器資源耗盡，導(dǎo)致讀寫超時(shí)，業(yè)務(wù)讀寫數(shù)據(jù)庫時(shí)要么無法連接數(shù)據(jù)庫、要么超時(shí)，最終用戶看到的現(xiàn)象就是訪問很慢，一會(huì)兒訪問拋出異常，一會(huì)兒訪問又是正常結(jié)果。
如果進(jìn)一步探究，導(dǎo)致接口級(jí)故障的原因可以分為兩大類：
解決接口級(jí)故障的核心思想和異地多活基本類似，都是優(yōu)先保證核心業(yè)務(wù)和優(yōu)先保證絕大部分用戶。常見的應(yīng)對(duì)方法有四種，降級(jí)、熔斷、限流和排隊(duì)，下面我會(huì)一一講解。
降級(jí)指系統(tǒng)將某些業(yè)務(wù)或者接口的功能降低，可以是只提供部分功能，也可以是完全停掉所有功能。
例如，論壇可以降級(jí)為只能看帖子，不能發(fā)帖子；也可以降級(jí)為只能看帖子和評(píng)論，不能發(fā)評(píng)論；而App的日志上傳接口，可以完全停掉一段時(shí)間，這段時(shí)間內(nèi)App都不能上傳日志。
降級(jí)的核心思想就是丟車保帥，優(yōu)先保證核心業(yè)務(wù)。
例如，對(duì)于論壇來說，90%的流量是看帖子，那我們就優(yōu)先保證看帖的功能；對(duì)于一個(gè)App來說，日志上傳接口只是一個(gè)輔助的功能，故障時(shí)完全可以停掉。
常見的實(shí)現(xiàn)降級(jí)的方式有兩種：
簡(jiǎn)單來說，就是系統(tǒng)預(yù)留了后門用于降級(jí)操作。例如，系統(tǒng)提供一個(gè)降級(jí)URL，當(dāng)訪問這個(gè)URL時(shí)，就相當(dāng)于執(zhí)行降級(jí)指令，具體的降級(jí)指令通過URL的參數(shù)傳入即可。這種方案有一定的安全隱患，所以也會(huì)在URL中加入密碼這類安全措施。
系統(tǒng)后門降級(jí)的方式實(shí)現(xiàn)成本低，但主要缺點(diǎn)是如果服務(wù)器數(shù)量多，需要一臺(tái)一臺(tái)去操作，效率比較低，這在故障處理爭(zhēng)分奪秒的場(chǎng)景下是比較浪費(fèi)時(shí)間的。
為了解決系統(tǒng)后門降級(jí)方式的缺點(diǎn)，我們可以將降級(jí)操作獨(dú)立到一個(gè)單獨(dú)的系統(tǒng)中，實(shí)現(xiàn)復(fù)雜的權(quán)限管理、批量操作等功能。
其基本架構(gòu)如下：
圖片
熔斷是指按照規(guī)則停掉外部接口的訪問，防止某些外部接口故障導(dǎo)致自己的系統(tǒng)處理能力急劇下降或者出故障。
圖片
熔斷和降級(jí)是兩個(gè)比較容易混淆的概念，因?yàn)閱渭儚拿稚峡矗孟穸加薪鼓硞€(gè)功能的意思。但它們的內(nèi)涵是不同的，因?yàn)榻导?jí)的目的是應(yīng)對(duì)系統(tǒng)自身的故障，而熔斷的目的是應(yīng)對(duì)依賴的外部系統(tǒng)故障的情況。
假設(shè)一個(gè)這樣的場(chǎng)景：A服務(wù)的X功能依賴B服務(wù)的某個(gè)接口，當(dāng)B服務(wù)的接口響應(yīng)很慢的時(shí)候，A服務(wù)的X功能響應(yīng)肯定也會(huì)被拖慢，進(jìn)一步導(dǎo)致A服務(wù)的線程都被卡在X功能處理上，于是A服務(wù)的其他功能都會(huì)被卡住或者響應(yīng)非常慢。
這時(shí)就需要熔斷機(jī)制了：A服務(wù)不再請(qǐng)求B服務(wù)的這個(gè)接口，A服務(wù)內(nèi)部只要發(fā)現(xiàn)是請(qǐng)求B服務(wù)的這個(gè)接口就立即返回錯(cuò)誤，從而避免A服務(wù)整個(gè)被拖慢甚至拖死。
實(shí)現(xiàn)熔斷機(jī)制有兩個(gè)關(guān)鍵點(diǎn)：
一是需要有一個(gè)統(tǒng)一的API調(diào)用層，由API調(diào)用層來進(jìn)行采樣或者統(tǒng)計(jì)。如果接口調(diào)用散落在代碼各處，就沒法進(jìn)行統(tǒng)一處理了。
二是閾值的設(shè)計(jì)，例如1分鐘內(nèi)30%的請(qǐng)求響應(yīng)時(shí)間超過1秒就熔斷，這個(gè)策略中的“1分鐘”“30%”“1秒”都對(duì)最終的熔斷效果有影響。實(shí)踐中，一般都是先根據(jù)分析確定閾值，然后上線觀察效果，再進(jìn)行調(diào)優(yōu)。
降級(jí)是從系統(tǒng)功能優(yōu)先級(jí)的角度考慮如何應(yīng)對(duì)故障，而限流則是從用戶訪問壓力的角度來考慮如何應(yīng)對(duì)故障。限流指只允許系統(tǒng)能夠承受的訪問量進(jìn)來，超出系統(tǒng)訪問能力的請(qǐng)求將被丟棄。
雖然“丟棄”這個(gè)詞聽起來讓人不太舒服，但保證一部分請(qǐng)求能夠正常響應(yīng)，總比全部請(qǐng)求都不能響應(yīng)要好得多。
限流一般都是系統(tǒng)內(nèi)實(shí)現(xiàn)的，常見的限流方式可以分為兩類：基于請(qǐng)求限流和基于資源限流。
基于請(qǐng)求限流指從外部訪問的請(qǐng)求角度考慮限流，常見的方式有兩種。
第一種是限制總量，也就是限制某個(gè)指標(biāo)的累積上限，常見的是限制當(dāng)前系統(tǒng)服務(wù)的用戶總量，例如：某個(gè)直播間限制總用戶數(shù)上限為100萬，超過100萬后新的用戶無法進(jìn)入；某個(gè)搶購活動(dòng)商品數(shù)量只有100個(gè)，限制參與搶購的用戶上限為1萬個(gè)，1萬以后的用戶直接拒絕。
第二種是限制時(shí)間量，也就是限制一段時(shí)間內(nèi)某個(gè)指標(biāo)的上限，例如1分鐘內(nèi)只允許10000個(gè)用戶訪問；每秒請(qǐng)求峰值最高為10萬。
無論是限制總量還是限制時(shí)間量，共同的特點(diǎn)都是實(shí)現(xiàn)簡(jiǎn)單，但在實(shí)踐中面臨的主要問題是比較難以找到合適的閾值。例如系統(tǒng)設(shè)定了1分鐘10000個(gè)用戶，但實(shí)際上6000個(gè)用戶的時(shí)候系統(tǒng)就扛不住了；或者達(dá)到1分鐘10000用戶后，其實(shí)系統(tǒng)壓力還不大，但此時(shí)已經(jīng)開始丟棄用戶訪問了。
即使找到了合適的閾值，基于請(qǐng)求限流還面臨硬件相關(guān)的問題。例如一臺(tái)32核的機(jī)器和64核的機(jī)器處理能力差別很大，閾值是不同的，可能有的技術(shù)人員以為簡(jiǎn)單根據(jù)硬件指標(biāo)進(jìn)行數(shù)學(xué)運(yùn)算就可以得出來，實(shí)際上這樣是不可行的，64核的機(jī)器比32核的機(jī)器，業(yè)務(wù)處理性能并不是2倍的關(guān)系，可能是1.5倍，甚至可能是1.1倍。
為了找到合理的閾值，通常情況下可以采用性能壓測(cè)來確定閾值，但性能壓測(cè)也存在覆蓋場(chǎng)景有限的問題，可能出現(xiàn)某個(gè)性能壓測(cè)沒有覆蓋的功能導(dǎo)致系統(tǒng)壓力很大；另外一種方式是逐步優(yōu)化：先設(shè)定一個(gè)閾值然后上線觀察運(yùn)行情況，發(fā)現(xiàn)不合理就調(diào)整閾值。
基于上述的分析，根據(jù)閾值來限制訪問量的方式更多的適應(yīng)于業(yè)務(wù)功能比較簡(jiǎn)單的系統(tǒng)，例如負(fù)載均衡系統(tǒng)、網(wǎng)關(guān)系統(tǒng)、搶購系統(tǒng)等。
基于請(qǐng)求限流是從系統(tǒng)外部考慮的，而基于資源限流是從系統(tǒng)內(nèi)部考慮的，也就是找到系統(tǒng)內(nèi)部影響性能的關(guān)鍵資源，對(duì)其使用上限進(jìn)行限制。常見的內(nèi)部資源包括連接數(shù)、文件句柄、線程數(shù)和請(qǐng)求隊(duì)列等。
例如，采用Netty來實(shí)現(xiàn)服務(wù)器，每個(gè)進(jìn)來的請(qǐng)求都先放入一個(gè)隊(duì)列，業(yè)務(wù)線程再從隊(duì)列讀取請(qǐng)求進(jìn)行處理，隊(duì)列長(zhǎng)度最大值為10000，隊(duì)列滿了就拒絕后面的請(qǐng)求；也可以根據(jù)CPU的負(fù)載或者占用率進(jìn)行限流，當(dāng)CPU的占用率超過80%的時(shí)候就開始拒絕新的請(qǐng)求。
基于資源限流相比基于請(qǐng)求限流能夠更加有效地反映當(dāng)前系統(tǒng)的壓力，但實(shí)際設(shè)計(jì)時(shí)也面臨兩個(gè)主要的難點(diǎn)：如何確定關(guān)鍵資源，以及如何確定關(guān)鍵資源的閾值。
通常情況下，這也是一個(gè)逐步調(diào)優(yōu)的過程：設(shè)計(jì)的時(shí)候先根據(jù)推斷選擇某個(gè)關(guān)鍵資源和閾值，然后測(cè)試驗(yàn)證，再上線觀察，如果發(fā)現(xiàn)不合理，再進(jìn)行優(yōu)化。
為了更好地實(shí)現(xiàn)前面描述的各種限流方式，通常情況下我們會(huì)基于限流算法來設(shè)計(jì)方案。常見的限流算法有兩大類四小類，它們的實(shí)現(xiàn)原理和優(yōu)缺點(diǎn)各不相同，在實(shí)際設(shè)計(jì)的時(shí)候需要根據(jù)業(yè)務(wù)場(chǎng)景來選擇。
第一大類是時(shí)間窗算法，它會(huì)限制一定時(shí)間窗口內(nèi)的請(qǐng)求量或者資源消耗量，根據(jù)實(shí)現(xiàn)方式又可以細(xì)分為“固定時(shí)間窗”和“滑動(dòng)時(shí)間窗”。
固定時(shí)間窗算法的實(shí)現(xiàn)原理是，統(tǒng)計(jì)固定時(shí)間周期內(nèi)的請(qǐng)求量或者資源消耗量，超過限額就會(huì)啟動(dòng)限流，如下圖所示：
圖片
它的優(yōu)點(diǎn)是實(shí)現(xiàn)簡(jiǎn)單，缺點(diǎn)是存在臨界點(diǎn)問題。例如上圖中的紅藍(lán)兩點(diǎn)只間隔了短短10秒，期間的請(qǐng)求數(shù)卻已經(jīng)達(dá)到200，超過了算法規(guī)定的限額（1分鐘內(nèi)處理100）。但是因?yàn)檫@些請(qǐng)求分別來自兩個(gè)統(tǒng)計(jì)窗口，從單個(gè)窗口來看還沒有超出限額，所以并不會(huì)啟動(dòng)限流，結(jié)果可能導(dǎo)致系統(tǒng)因?yàn)閴毫^大而掛掉。
為了解決臨界點(diǎn)問題，滑動(dòng)時(shí)間窗算法應(yīng)運(yùn)而生，它的實(shí)現(xiàn)原理是，兩個(gè)統(tǒng)計(jì)周期部分重疊，從而避免短時(shí)間內(nèi)的兩個(gè)統(tǒng)計(jì)點(diǎn)分屬不同的時(shí)間窗的情況，如下圖所示：
圖片
總體上來看，滑動(dòng)時(shí)間窗的限流效果要比固定時(shí)間窗更好，但是實(shí)現(xiàn)也會(huì)稍微復(fù)雜一些。
第二大類是桶算法，用一個(gè)虛擬的“桶”來臨時(shí)存儲(chǔ)一些東西。根據(jù)桶里面放的東西，又可以細(xì)分為“漏桶”和“令牌桶”。
漏桶算法的實(shí)現(xiàn)原理是，將請(qǐng)求放入“桶”（消息隊(duì)列等），業(yè)務(wù)處理單元（線程、進(jìn)程和應(yīng)用等）從桶里拿請(qǐng)求處理，桶滿則丟棄新的請(qǐng)求，如下圖所示：
圖片
我們可以看到漏桶算法的三個(gè)關(guān)鍵實(shí)現(xiàn)點(diǎn)：
漏桶算法的技術(shù)本質(zhì)是總量控制，桶大小是設(shè)計(jì)關(guān)鍵，具體的優(yōu)缺點(diǎn)如下：
漏桶算法主要適用于瞬時(shí)高并發(fā)流量的場(chǎng)景（例如剛才提到的0點(diǎn)簽到、整點(diǎn)秒殺等）。在短短幾分鐘內(nèi)涌入大量請(qǐng)求時(shí)，為了更好的業(yè)務(wù)效果和用戶體驗(yàn)，即使處理慢一些，也要做到盡量不丟棄用戶請(qǐng)求。
令牌桶算法和漏桶算法的不同之處在于，桶中放入的不是請(qǐng)求，而是“令牌”，這個(gè)令牌就是業(yè)務(wù)處理前需要拿到的“許可證”。也就是說，當(dāng)系統(tǒng)收到一個(gè)請(qǐng)求時(shí)，先要到令牌桶里面拿“令牌”，拿到令牌才能進(jìn)一步處理，拿不到就要丟棄請(qǐng)求。
它的實(shí)現(xiàn)原理是如下圖所示：
圖片
我們可以看到令牌桶算法的三個(gè)關(guān)鍵設(shè)計(jì)點(diǎn)：
令牌桶算法的技術(shù)本質(zhì)是速率控制，令牌產(chǎn)生的速率是設(shè)計(jì)關(guān)鍵，具體的優(yōu)缺點(diǎn)如下：
令牌桶算法主要適用于兩種典型的場(chǎng)景，一種是需要控制訪問第三方服務(wù)的速度，防止把下游壓垮，例如支付寶需要控制訪問銀行接口的速率；另一種是需要控制自己的處理速度，防止過載，例如壓測(cè)結(jié)果顯示系統(tǒng)最大處理TPS是100，那么就可以用令牌桶來限制最大的處理速度。
剛才介紹漏桶算法的時(shí)候我提到漏桶算法可以應(yīng)對(duì)瞬時(shí)高并發(fā)流量，現(xiàn)在介紹令牌桶算法的時(shí)候，我又說令牌桶允許突發(fā)流量。
你可能會(huì)問，這兩種說法好像差不多啊，它們到底有什么區(qū)別，到底誰更適合做秒殺呢？
其實(shí)，令牌桶的“允許突發(fā)”實(shí)際上只是“允許一定程度的突發(fā)”，比如系統(tǒng)處理能力是每秒100 TPS，突發(fā)到120 TPS是可以的，但如果突發(fā)到1000 TPS的話，系統(tǒng)大概率就被壓垮了。所以處理秒殺時(shí)高并發(fā)流量，還是得用漏桶算法。
令牌桶的算法原本是用于網(wǎng)絡(luò)設(shè)備控制傳輸速度的，而且它控制的目的是保證一段時(shí)間內(nèi)的平均傳輸速度。之所以說令牌桶適合突發(fā)流量，是指在網(wǎng)絡(luò)傳輸?shù)臅r(shí)候，可以允許某段時(shí)間內(nèi)（一般就幾秒）超過平均傳輸速率，這在網(wǎng)絡(luò)環(huán)境下常見的情況就是“網(wǎng)絡(luò)抖動(dòng)”。
但這個(gè)短時(shí)間的突發(fā)流量并不會(huì)導(dǎo)致雪崩效應(yīng)，網(wǎng)絡(luò)設(shè)備也能夠處理得過來。對(duì)應(yīng)到令牌桶應(yīng)用到業(yè)務(wù)處理的場(chǎng)景，就要求即使有突發(fā)流量來了，系統(tǒng)自己或者下游系統(tǒng)要真的能夠處理的過來，否則令牌桶允許突發(fā)流量進(jìn)來，結(jié)果系統(tǒng)或者下游處理不了，那還是會(huì)被壓垮。
因此，令牌桶在實(shí)際設(shè)計(jì)的時(shí)候，桶大小不能像漏桶那樣設(shè)計(jì)很大，需要根據(jù)系統(tǒng)的處理能力來進(jìn)行仔細(xì)的估算。例如，漏桶算法的桶容量可以設(shè)計(jì)為100萬，但是一個(gè)每秒30 TPS的令牌桶，桶的容量可能只能設(shè)計(jì)成40左右。海外有的銀行給移動(dòng)錢包提供的接口TPS上限是30，壓測(cè)到了40就真的掛了。
排隊(duì)實(shí)際上是限流的一個(gè)變種，限流是直接拒絕用戶，排隊(duì)是讓用戶等待一段時(shí)間，全世界最有名的排隊(duì)當(dāng)屬12306網(wǎng)站排隊(duì)了。
排隊(duì)雖然沒有直接拒絕用戶，但用戶等了很長(zhǎng)時(shí)間后進(jìn)入系統(tǒng)，體驗(yàn)并不一定比限流好。
由于排隊(duì)需要臨時(shí)緩存大量的業(yè)務(wù)請(qǐng)求，單個(gè)系統(tǒng)內(nèi)部無法緩存這么多數(shù)據(jù)，一般情況下，排隊(duì)需要用獨(dú)立的系統(tǒng)去實(shí)現(xiàn)，例如使用Kafka這類消息隊(duì)列來緩存用戶請(qǐng)求。
下圖是1號(hào)店的“雙11”秒殺排隊(duì)系統(tǒng)架構(gòu)：
圖片
它的基本實(shí)現(xiàn)摘錄如下：
【排隊(duì)模塊】 負(fù)責(zé)接收用戶的搶購請(qǐng)求，將請(qǐng)求以先入先出的方式保存下來。每一個(gè)參加秒殺活動(dòng)的商品保存一個(gè)隊(duì)列，隊(duì)列的大小可以根據(jù)參與秒殺的商品數(shù)量（或加點(diǎn)余量）自行定義。
【調(diào)度模塊】 負(fù)責(zé)排隊(duì)模塊到服務(wù)模塊的動(dòng)態(tài)調(diào)度，不斷檢查服務(wù)模塊，一旦處理能力有空閑，就從排隊(duì)隊(duì)列頭上把用戶訪問請(qǐng)求調(diào)入服務(wù)模塊，并負(fù)責(zé)向服務(wù)模塊分發(fā)請(qǐng)求。這里調(diào)度模塊扮演一個(gè)中介的角色，但不只是傳遞請(qǐng)求而已，它還擔(dān)負(fù)著調(diào)節(jié)系統(tǒng)處理能力的重任。我們可以根據(jù)服務(wù)模塊的實(shí)際處理能力，動(dòng)態(tài)調(diào)節(jié)向排隊(duì)系統(tǒng)拉取請(qǐng)求的速度。
【服務(wù)模塊】 負(fù)責(zé)調(diào)用真正業(yè)務(wù)來處理服務(wù)，并返回處理結(jié)果，調(diào)用排隊(duì)模塊的接口回寫業(yè)務(wù)處理結(jié)果。
今天我為你講了接口級(jí)故障的四種應(yīng)對(duì)方法，分別是降級(jí)、熔斷、限流和排隊(duì)，希望對(duì)你有所幫助。
圖片
本文鏈接：http://m.www897cc.com/showinfo-26-87011-0.html架構(gòu)設(shè)計(jì)中如何應(yīng)對(duì)接口級(jí)故障？
聲明：本網(wǎng)頁內(nèi)容旨在傳播知識(shí)，若有侵權(quán)等問題請(qǐng)及時(shí)與本網(wǎng)聯(lián)系，我們將在第一時(shí)間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請(qǐng)聯(lián)系：2376512515@qq.com 津ICP備18001702號(hào)
津公網(wǎng)安備 12010102000574號(hào)