這篇文章將為大家詳細(xì)講解有關(guān)Node.js中斷路器機(jī)制是怎么樣的，小編覺(jué)得挺實(shí)用的，因此分享給大家做個(gè)參考，希望大家閱讀完這篇文章后可以有所收獲。
讓客戶滿意是我們工作的目標(biāo)，不斷超越客戶的期望值來(lái)自于我們對(duì)這個(gè)行業(yè)的熱愛(ài)。我們立志把好的技術(shù)通過(guò)有效、簡(jiǎn)單的方式提供給客戶，將通過(guò)不懈努力成為客戶在信息化領(lǐng)域值得信任、有價(jià)值的長(zhǎng)期合作伙伴，公司提供的服務(wù)項(xiàng)目有：域名注冊(cè)、虛擬空間、營(yíng)銷(xiāo)軟件、網(wǎng)站建設(shè)、金鄉(xiāng)網(wǎng)站維護(hù)、網(wǎng)站推廣。
當(dāng)我們使用傳統(tǒng)的 CS 架構(gòu)時(shí)，服務(wù)端由于故障等原因?qū)⒄?qǐng)求堵塞，可能會(huì)導(dǎo)致客戶端的請(qǐng)求失去響應(yīng)，進(jìn)而在一段時(shí)間后導(dǎo)致一批用戶無(wú)法獲得服務(wù)。而這種情況可能影響范圍是有限，可以預(yù)估的。
然而，在微服務(wù)體系下，您的服務(wù)器可能依賴(lài)了若干其他微服務(wù)，而這些微服務(wù)又依賴(lài)其它更多的微服務(wù)，這種情況下，某個(gè)服務(wù)對(duì)于下游的堵塞，可能會(huì)瞬間（數(shù)秒內(nèi)）因?yàn)榧?jí)聯(lián)的資源消耗造成整條鏈路上災(zāi)難性的后果，我們稱(chēng)之為“服務(wù)血崩”?！就扑]學(xué)習(xí)：《nodejs 教程》】
熔斷模式：顧名思義，就如同家用電路一樣，如果一條線路電壓過(guò)高，保險(xiǎn)絲會(huì)熔斷，防止火災(zāi)。在使用熔斷模式的系統(tǒng)中，如果發(fā)現(xiàn)上游服務(wù)調(diào)用慢，或者有大量超時(shí)的時(shí)候，直接中止對(duì)于該服務(wù)的調(diào)用，直接返回信息，快速釋放資源。直至上游服務(wù)好轉(zhuǎn)時(shí)再恢復(fù)調(diào)用。
隔離模式：將不同的資源或者服務(wù)的調(diào)用分割成幾個(gè)不同的請(qǐng)求池，一個(gè)池子的資源被耗盡并不會(huì)影響其它資源的請(qǐng)求，防止某個(gè)單點(diǎn)的故障消耗完全部的資源。這是非常傳統(tǒng)的一種容災(zāi)設(shè)計(jì)。
限流模式：熔斷和隔離都是一種事后處置的方式，限流模式則可以在問(wèn)題出現(xiàn)之前降低問(wèn)題出現(xiàn)的概率。限流模式可以對(duì)某些服務(wù)的請(qǐng)求設(shè)置一個(gè)最高的 QPS 閾值，超出閾值的請(qǐng)求直接返回，不再占用資源處理。但是限流模式，并不能解決服務(wù)血崩的問(wèn)題，因?yàn)橥鹧啦⒉皇且驗(yàn)檎?qǐng)求的數(shù)量大，而是因?yàn)槎鄠€(gè)級(jí)聯(lián)層數(shù)的放大。
斷路器的存在，相當(dāng)于給了我們一層保障，在調(diào)用穩(wěn)定性欠佳，或者說(shuō)很可能會(huì)調(diào)用失敗的服務(wù)和資源時(shí)，斷路器可以監(jiān)視這些錯(cuò)誤并且在達(dá)到一定閾值之后讓請(qǐng)求失敗，防止過(guò)度消耗資源。并且，斷路器還擁有自動(dòng)識(shí)別服務(wù)狀態(tài)并恢復(fù)的功能，當(dāng)上游服務(wù)恢復(fù)正常時(shí)，斷路器可以自動(dòng)判斷并恢復(fù)正常請(qǐng)求。
讓我們看一下一個(gè)沒(méi)有斷路器的請(qǐng)求過(guò)程： 用戶依賴(lài) ServiceA 來(lái)提供服務(wù)，ServiceA 又依賴(lài) ServiceB 提供的服務(wù)，假設(shè) ServiceB 此時(shí)出現(xiàn)了故障，在 10 分鐘內(nèi)，對(duì)于每個(gè)請(qǐng)求都會(huì)延遲 10 秒響應(yīng)。
那么假設(shè)我們有 N 個(gè) User 在請(qǐng)求 ServiceA 的服務(wù)時(shí)，幾秒鐘內(nèi)，ServiceA 的資源就會(huì)因?yàn)閷?duì) ServiceB 發(fā)起的請(qǐng)求被掛起而消耗一空，從而拒絕 User 之后的任何請(qǐng)求。對(duì)于用戶來(lái)說(shuō)，這就等于 ServiceA 和 ServiceB 同時(shí)都出現(xiàn)了故障，引起了整條服務(wù)鏈路的崩潰。
而當(dāng)我們?cè)?ServiceA 上裝上一個(gè)斷路器后會(huì)怎么樣呢？
斷路器在失敗次數(shù)達(dá)到一定閾值后會(huì)發(fā)現(xiàn)對(duì) ServiceB 的請(qǐng)求已經(jīng)無(wú)效，那么此時(shí) ServiceA 就不需要繼續(xù)對(duì) ServiceB 進(jìn)行請(qǐng)求，而是直接返回失敗，或者使用其他Fallback 的備份數(shù)據(jù)。此時(shí)，斷路器處于 開(kāi)路狀態(tài)。
在一段時(shí)間過(guò)后，斷路器會(huì)開(kāi)始定時(shí)查詢(xún) ServiceB 是否已經(jīng)恢復(fù)，此時(shí)，斷路器處于 半開(kāi)狀態(tài)。
如果 ServiceB 已經(jīng)恢復(fù)，那么斷路器會(huì)置于 關(guān)閉狀態(tài)，此時(shí) ServiceA 會(huì)正常調(diào)用 ServiceB 并且返回結(jié)果。
斷路器的狀態(tài)圖如下：
由此可見(jiàn)，斷路器的幾個(gè)核心要點(diǎn)如下：
超時(shí)時(shí)間：請(qǐng)求達(dá)到多久，算引起了一次失敗
失敗閾值：即斷路器觸發(fā)開(kāi)路之前，需要達(dá)到的失敗次數(shù)
重試超時(shí)：當(dāng)斷路器處于開(kāi)路狀態(tài)后，隔多久開(kāi)始重新嘗試請(qǐng)求，即進(jìn)入半開(kāi)狀態(tài)
有了這些知識(shí)，我們可以嘗試創(chuàng)建一個(gè)斷路器：
重慶分公司
重慶分公司
class CircuitBreaker {
constructor(timeout, failureThreshold, retryTimePeriod) {
// We start in a closed state hoping that everything is fine
this.state = 'CLOSED';
// Number of failures we receive from the depended service before we change the state to 'OPEN'
this.failureThreshold = failureThreshold;
// Timeout for the API request.
this.timeout = timeout;
// Time period after which a fresh request be made to the dependent
// service to check if service is up.
this.retryTimePeriod = retryTimePeriod;
this.lastFailureTime = null;
this.failureCount = 0;
}
}構(gòu)造斷路器的狀態(tài)機(jī)：
async call(urlToCall) {
// Determine the current state of the circuit.
this.setState();
switch (this.state) {
case 'OPEN':
// return cached response if no the circuit is in OPEN state
return { data: 'this is stale response' };
// Make the API request if the circuit is not OPEN
case 'HALF-OPEN':
case 'CLOSED':
try {
const response = await axios({
url: urlToCall,
timeout: this.timeout,
method: 'get',
});
// Yay!! the API responded fine. Lets reset everything.
this.reset();
return response;
} catch (err) {
// Uh-oh!! the call still failed. Lets update that in our records.
this.recordFailure();
throw new Error(err);
}
default:
console.log('This state should never be reached');
return 'unexpected state in the state machine';
}
}補(bǔ)充剩余功能：
// reset all the parameters to the initial state when circuit is initialized
reset() {
this.failureCount = 0;
this.lastFailureTime = null;
this.state = 'CLOSED';
}
// Set the current state of our circuit breaker.
setState() {
if (this.failureCount > this.failureThreshold) {
if ((Date.now() - this.lastFailureTime) > this.retryTimePeriod) {
this.state = 'HALF-OPEN';
} else {
this.state = 'OPEN';
}
} else {
this.state = 'CLOSED';
}
}
recordFailure() {
this.failureCount += 1;
this.lastFailureTime = Date.now();
}使用斷路器時(shí)，只需要將請(qǐng)求包裹在斷路器實(shí)例中的 Call 方法里調(diào)用即可：
...
const circuitBreaker = new CircuitBreaker(3000, 5, 2000);
const response = await circuitBreaker.call('http://0.0.0.0:8000/flakycall');Red Hat 很早就創(chuàng)建了一個(gè)名叫 Opossum的成熟 Node.js 斷路器實(shí)現(xiàn)，鏈接在此：Opossum 。對(duì)于分布式系統(tǒng)來(lái)說(shuō)，使用這個(gè)庫(kù)可以極大提升你的服務(wù)的容錯(cuò)能力，從根本上解決服務(wù)血崩的問(wèn)題。
關(guān)于“Node.js中斷路器機(jī)制是怎么樣的”這篇文章就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，使各位可以學(xué)到更多知識(shí)，如果覺(jué)得文章不錯(cuò)，請(qǐng)把它分享出去讓更多的人看到。
