Dieser Artikel führt Sie durch den Schutzschaltermechanismus in Node.js. Ich hoffe, er wird Ihnen hilfreich sein!
Wenn wir die traditionelle CS-Architektur verwenden, blockiert der Server Anfragen aufgrund von Fehlern und anderen Gründen, was dazu führen kann, dass die Anfrage des Clients nicht mehr reagiert, was wiederum zu einer Vielzahl von Benutzern führt bis „Dienst konnte nicht in Anspruch genommen werden“. Die möglichen Auswirkungen dieser Situation sind begrenzt und können abgeschätzt werden.
In einem Microservice-System ist Ihr Server jedoch möglicherweise auf mehrere andere Microservices angewiesen, und diese Microservices können wiederum auf weitere Microservices angewiesen sein. In diesem Fall kann ein bestimmter Dienst innerhalb von Sekunden zu einer nachgelagerten Überlastung führen Der kaskadierende Ressourcenverbrauch hat katastrophale Folgen für die gesamte Verbindung, wir nennen es „Service-Zusammenbruch“. [Empfohlenes Lernen: „nodejs-Tutorial“]
Sicherungsmodus: Wie der Name schon sagt, genau wie bei einem Haushaltsstromkreis, wenn die Spannung einer Leitung zu hoch ist zu hoch, wird die Sicherung durchbrennen, um einen Brand zu verhindern. Wenn in einem System, das den Leistungsschaltermodus verwendet, festgestellt wird, dass der Upstream-Dienstaufruf langsam ist oder eine große Anzahl von Zeitüberschreitungen vorliegt, wird der Dienstaufruf direkt beendet, Informationen werden direkt zurückgegeben und Ressourcen werden freigegeben schnell. Der Anruf wird erst wieder aufgenommen, wenn sich der Upstream-Dienst verbessert.
Die Existenz des Leistungsschalters ist gleichbedeutend damit, uns eine Schutzschicht zu bieten. Wenn Dienste und Ressourcen aufgerufen werden, die nicht stabil sind oder wahrscheinlich ausfallen, kann der Leistungsschalter diese überwachen Fehler und Fehlschlagen der Anfrage nach Erreichen eines bestimmten Schwellenwerts, um einen übermäßigen Ressourcenverbrauch zu verhindern. Darüber hinaus verfügt der Leistungsschalter über die Funktion, den Betriebszustand automatisch zu erkennen und wiederherzustellen. Wenn der vorgelagerte Betrieb wieder normal ist, kann der Leistungsschalter die normalen Anforderungen automatisch ermitteln und wieder aufnehmen.
Sehen wir uns einen Anforderungsprozess ohne Leistungsschalter an: Der Benutzer verlässt sich auf ServiceA, um Dienste bereitzustellen, und ServiceA verlässt sich auf die von ServiceB bereitgestellten Dienste. Angenommen, dass ServiceB zu diesem Zeitpunkt fehlschlägt um 10 Sekunden verzögerte Reaktion.
Angenommen, wir haben N Benutzer, die den Dienst von ServiceA anfordern. Innerhalb weniger Sekunden werden die Ressourcen von ServiceA aufgrund der Aussetzung von Anfragen an ServiceB verbraucht, wodurch alle nachfolgenden Anfragen des Benutzers abgelehnt werden. Für Benutzer bedeutet dies, dass sowohl ServiceA als auch ServiceB gleichzeitig ausgefallen sind, wodurch die gesamte Dienstverknüpfung zusammengebrochen ist.
Und was passiert, wenn wir einen Leistungsschalter auf ServiceA installieren?
Nachdem die Anzahl der Ausfälle einen bestimmten Schwellenwert erreicht, stellt der Leistungsschalter fest, dass die Anforderung an ServiceB ungültig ist. Zu diesem Zeitpunkt muss ServiceA ServiceB nicht weiter anfordern, sondern gibt den Fehler direkt zurück oder verwendet einen anderen Fallback Sicherungsdaten. Zu diesem Zeitpunkt befindet sich der Leistungsschalter im Zustand „offener Stromkreis“.
-Zustand.
Das Statusdiagramm des Leistungsschalters sieht wie folgt aus:
Es ist ersichtlich, dass mehrere Kernpunkte des Leistungsschalters wie folgt sind:
Timeout: Wie lange die Anforderung dauert bevor es zu einem Ausfall kommtZeitüberschreitung bei Wiederholungsversuchen: Wie lange dauert es, bis der Leistungsschalter im offenen Stromkreiszustand ist, um mit dem erneuten Versuch der Anforderung zu beginnen, d ein Leistungsschalter:
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; } }
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'; } }
Ergänzende verbleibende Funktionen:
// 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(); }
Bei Verwendung eines Leistungsschalters müssen Sie die Anforderung nur in die Call-Methode der Leistungsschalterinstanz einschließen und sie aufrufen:
... const circuitBreaker = new CircuitBreaker(3000, 5, 2000); const response = await circuitBreaker.call('http://0.0.0.0:8000/flakycall');
Ausgereifte Node.js-Leistungsschalterbibliothek
Red Hat hat seit langem eine ausgereifte Node.js-Leistungsschalterimplementierung namens
Opossum. Bei verteilten Systemen kann die Verwendung dieser Bibliothek die Fehlertoleranz Ihres Dienstes erheblich verbessern und das Problem des Dienstausfalls grundlegend lösen. Originaladresse: https://juejin.cn/post/7019217344601948173
Autor: ES2049 / Looking for SingularityWeitere Programmierkenntnisse finden Sie unter:Programmiervideo
! !
Das obige ist der detaillierte Inhalt vonEine eingehende Analyse des Leistungsschaltermechanismus in Node.js. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!