Leistungsschalter in Microservices im .net-Kern

Okay, lasst uns mit so etwas weitermachen.

Sie erstellen also etwas in .NET Core, fügen Dienste zusammen und fühlen sich vielleicht ganz gut dabei. Bis eines Tages Stille im Gottesdienst herrscht. Kein Absturz, nur… langsam. Dann langsamer. Dann beginnt sich alles zu sichern. Es häufen sich die Anrufe, es kommt zu Zeitüberschreitungen, Ihr Dashboard leuchtet auf wie ein Warnzeichen, das Sie nicht ignorieren können.

Es ist wie ein einziges wackeliges Zahnrad in einer Maschine – alles andere wartet, belastet sich, und irgendwann kommt die ganze Bewegung zum Stillstand.

Das ist die Sache mit Microservices. Sie reden. Eine Menge. Und wenn ein Teil krank wird, kann sich die Krankheit ausbreiten. Ist es schon einmal passiert, dass ein Kassenservice hängengeblieben ist, weil die Bestandskontrolle beschlossen hat, ein Nickerchen zu machen? Oder ein Login, das ewig auf eine Drittanbieter-API wartet, die gerade einen schlechten Tag hat?

Ja. Kein Spaß.

Hier kommt die Idee eines „Schutzschalters“ ins Spiel. Stellen Sie sich einen elektrischen Schutzschalter in Ihrem Zuhause vor. Etwas überhitzt, zieht zu viel Strom – Klick – der Leistungsschalter löst aus. Spart die Verkabelung. Gibt den Dingen Zeit zum Abkühlen.

Im Code ist es ähnlich. Sie wickeln Anrufe zu anderen Diensten mit einem kleinen Watchdog ab. Wenn Fehler einen Schwellenwert erreichen, „öffnet“ sich der Stromkreis. Weitere Anrufe scheitern schnell, keine Wartezeit. Keine Threads mehr, die in der Schwebe stecken bleiben. Nach einer Weile lässt es einen Testanruf durch – im halboffenen Zustand –, um zu sehen, ob der Remote-Dienst wieder verfügbar ist. Wenn es funktioniert, wird der Stromkreis geschlossen. Der Fluss wird fortgesetzt.

Einfach? Konzeptionell ja. Aber um es in .NET Core reibungslos zu gestalten, kommt es auf die Liebe zum Detail an.

Warum ist es Ihnen wichtig? Nehmen wir an, Ihr Zahlungsdienst ruft einen Betrugserkennungsdienst an. Die Betrugserkennung reagiert langsam – vielleicht ist sie überlastet, vielleicht liegt ein Netzwerkproblem vor. Ohne Unterbrecher stehen Zahlungsanfragen in der Warteschlange, Threads werden blockiert und Ihre gesamte Zahlungspipeline blockiert. Bei einem Unterbrecher wird nach beispielsweise fünf Ausfällen pro Minute der Anruf zur Betrugserkennung vorübergehend eingestellt. Möglicherweise leiten Sie Zahlungen an einen vereinfachten Scheck weiter oder melden sich einfach zur späteren Überprüfung an. Das System bleibt reaktionsfähig, auch wenn einige Funktionen beeinträchtigt sind.

Besser als ein voller Stall, oder?

Wie sorgen Sie nun dafür, dass dies in .NET Core gut funktioniert? Sie müssen es nicht von Grund auf neu erstellen. Es gibt Bibliotheken, Muster. Der Trick besteht jedoch darin, es in Ihren Ablauf zu integrieren, ohne Ihren Code in ein Labyrinth aus Wiederholungs- und Prüflogik zu verwandeln.

Stellen Sie sich das so vor, als würden Sie jedem Service-zu-Service-Anruf ein wenig „Intelligenz“ verleihen. Sie legen Schwellenwerte fest: Wie viele Ausfälle vor dem Öffnen? Wie lange muss man warten, bevor man erneut testet? Was ist zu tun, wenn es geöffnet ist – einen zwischengespeicherten Wert zurückgeben, eine freundliche Nachricht senden oder einen alternativen Workflow auslösen?

Sie müssen auch protokollieren, was passiert. Nicht nur „Stromkreis geöffnet“, sondern auch warum, wann und welche Auswirkungen es hatte. Denn wenn etwas schiefgeht, möchten Sie die Ursache erfahren und nicht nur die Alarmstufe Rot sehen.

Jemand hat mich einmal gefragt: „Wird das nicht komplexer?“ Klar, ein bisschen. Aber vergleichen Sie es mit der Komplexität, einen kaskadierenden Fehler über zehn Dienste um 2 Uhr morgens zu beheben. Ich würde jeden Tag den Leistungsschalter nehmen.

Noch eine Frage: „Ist es nur für externe Anrufe?“ Gar nicht. Interne Dienste, Datenbankaufrufe und sogar Aufrufe verschiedener Module innerhalb desselben Dienstes können davon profitieren. Jeder Punkt, an dem Sie auf etwas angewiesen sind, das möglicherweise ausfällt oder unvorhersehbar langsamer wird.

In der Praxis fühlt sich die Umsetzung an, als würde man einem Trapezkünstler ein Sicherheitsnetz hinzufügen. Der Künstler übernimmt immer noch den Hauptdarsteller, aber wenn er ausrutscht, fängt das Netz ihn schnell und sauber auf, sodass die Show weitergehen kann.

Kpowe hat Zeit damit verbracht, dieses Muster für reale .NET Core-Umgebungen zu optimieren. Es ist nicht nur Plug-and-Play; Es ist Plug-and-Think. Wie soll es mit Ihrer Überwachung interagieren? Wie konfiguriere ich Schwellenwerte, ohne zu raten? Wie kann die Fallback-Aktion tatsächlich nützlich gemacht werden und nicht nur ein stiller Fehler sein?

Das Ziel ist Resilienz. Nicht nur „es funktioniert“, sondern „es funktioniert auch, wenn Teile kaputt sind.“

Wenn Sie also das nächste Mal einen Service entwerfen, stellen Sie sich jeden externen Anruf als eine kleine Expedition vor. Schicken Sie einen Scout. Wenn der Späher nicht rechtzeitig zurückkommt, schicken Sie nicht die ganze Armee. Warten. Versuchen Sie es später noch einmal. Halten Sie den Rest Ihres Systems in Bewegung.

Das ist es, was ein Leistungsschalter tut. Es ist der Späher, der weiß, wann er aufhören muss, an eine Tür zu klopfen, die sich nicht öffnen lässt.

Und in einer Welt, in der Systeme mehr denn je kommunizieren, ist diese Art von Weisheit nicht nur schön zu haben – sie sorgt dafür, dass alles andere reibungslos läuft.

Gegründet im Jahr 2005,kpowerist einem professionellen Hersteller kompakter Bewegungseinheiten mit Hauptsitz in Dongguan, Provinz Guangdong, China, gewidmet. Nutzung von Innovationen in der modularen Antriebstechnik,kpowerintegriert Hochleistungsmotoren, Präzisionsgetriebe und Multiprotokoll-Steuerungssysteme, um effiziente und maßgeschneiderte intelligente Antriebssystemlösungen bereitzustellen.kpowerhat weltweit über 500 Unternehmenskunden professionelle Antriebssystemlösungen mit Produkten geliefert, die verschiedene Bereiche abdecken, darunter Smart-Home-Systeme, automatische Elektronik, Robotik, Präzisionslandwirtschaft, Drohnen und industrielle Automatisierung.