Einleitung: Warum Ihr C#-Dienst kein perfekter Mechanismus ist
\n\nStellen Sie sich vor: Sie haben einen eleganten Mikroservice in C# geschrieben. Der Code hat das Code Review bestanden, Unit-Tests decken 95% ab, Integrationstests sind grün. Sie bringen ihn in die Produktion, und… nach 3 Stunden fällt das System aus. Der Grund? Ein unerwarteter Traffic-Spitze, die den Thread-Pool überlastet hat, oder ein plötzlicher Datenbankausfall, den Sie nicht eingeplant hatten.
\n\nWillkommen in der realen Welt, in der Chaos Engineering kein Luxus, sondern eine Notwendigkeit ist. Es geht nicht darum, „alles aus Spaß kaputt zu machen“. Es ist eine Disziplin, die hilft, Schwachstellen in verteilten Systemen zu identifizieren, bevor Ihre Benutzer sie entdecken.
\n\nIn diesem Artikel werden wir uns ansehen, wie man Chaos Engineering für C#-Anwendungen anwendet: von der Theorie bis zu realen Codebeispielen mit den Bibliotheken Polly und Simmy. Sie erfahren, wie Sie gezielt Chaos in .NET-Dienste einbringen, um deren Widerstandsfähigkeit und Vorhersagbarkeit zu erhöhen.
\n\nWas ist Chaos Engineering und warum ist es für .NET wichtig?
\n\nChaos Engineering ist die Praxis, Experimente an einem verteilten System durchzuführen, um seine Fähigkeit zu testen, unerwartete Ausfälle zu überstehen. Netflix, Amazon, Microsoft – alle Giganten nutzen es. Für C#-Entwickler ist dies besonders relevant, da .NET Core/5+ zunehmend für den Bau hochlastiger Cloud-Dienste auf Microsoft Azure verwendet wird.
\n\nGrundprinzipien des Chaos Engineering:
\n- \n
- Definition des „Steady State“ (stabilen Zustands) – wie sich Ihr System normalerweise verhält (Latenz, Durchsatz, Fehlerrate). \n
- Formulierung einer Hypothese – „Wenn die Datenbank OrderDB ausfällt, antwortet der Bestelldienst weiterhin 5 Minuten lang mit zwischengespeicherten Daten.“ \n
- Einbringen von Chaos – Sie schalten OrderDB tatsächlich für 30 Sekunden ab. \n
- Überprüfung der Hypothese – Wir sehen uns die Metriken an. Wenn die Hypothese nicht bestätigt wird, haben Sie einen Fehler in der Architektur. \n
Das Schlüsselwort hier ist „Experiment“. Sie hoffen nicht einfach auf das Beste, Sie beweisen, dass Ihr System überleben wird.
\n\nWerkzeuge für Chaos Engineering in C#
\n\nIn der .NET-Welt gibt es zwei leistungsstarke Tools, die zusammenarbeiten:
\n- \n
- Polly – eine Bibliothek zur Implementierung von Ausfallsicherheitsmustern (Retry, Circuit Breaker, Timeout, Bulkhead Isolation). \n
- Simmy (Microsoft.Extensions.Resilience) – eine Bibliothek für Chaos Engineering, die Polly erweitert. Ermöglicht das „Injizieren“ von Fehlern in Ihre Richtlinien. \n
Simmy ist der „böse Bruder“ von Polly. Wenn Polly Ihrer Anwendung beibringt, zu überleben, dann testet Simmy, wie gut sie das kann, indem es gezielt Aufrufe kaputt macht.
\n\nPraxis: Einrichtung eines Chaos-Experiments in C#
\n\nKommen wir zum Code. Nehmen wir an, wir haben einen Buchungsdienst, der eine externe Zahlungs-API aufruft. Wir möchten testen, wie sich der BookingService verhält, wenn die Zahlungs-API mit Verzögerungen oder Fehlern zu antworten beginnt.
Schritt 1: Installation der Pakete
\ndotnet add package Microsoft.Extensions.Http.Polly\ndotnet add package Microsoft.Extensions.Resilience\n\n\nSchritt 2: Konfiguration des HttpClient mit Richtlinien
\nZuerst konfigurieren wir eine Standard-Circuit Breaker- und Retry-Richtlinie mit Polly. Dann „umhüllen“ wir sie mit einer Chaos-Richtlinie aus Simmy.
\n\nusing Microsoft.Extensions.DependencyInjection;\nusing Microsoft.Extensions.Http.Resilience;\nusing Polly;\nusing Polly.Extensions.Http;\n\npublic static class ServiceCollectionExtensions\n{\n public static IServiceCollection AddPaymentClient(this IServiceCollection services)\n {\n services.AddHttpClient<IPaymentService, PaymentService>(client =&g