Entschlüsselung der Hochverfügbarkeit von Microservices: Erforschung von API-Governance-Strategien mit Apache APISIX

Einführung

Die Microservices-Architektur hat sich inzwischen zur Mainstream-Wahl für IT-Architekturen entwickelt. Ihre Flexibilität und Skalierbarkeit ermöglichen es Unternehmen, sich leichter an schnell ändernde Geschäftsanforderungen anzupassen. Allerdings ist die Gewährleistung der hohen Verfügbarkeit von Microservices zu einem zentralen Thema in der Architekturgestaltung geworden. In diesem Zusammenhang sind die drei Kernstrategien der API-Service-Governance – Ratenbegrenzung, Circuit Breaking und Degradation – besonders wichtig.

Als eine wesentliche Grundkomponente in der Microservices-Architektur spielt das API-Gateway eine entscheidende Rolle in der Service-Governance. Apache APISIX, als eine neue Generation eines Cloud-nativen API-Gateways, bietet nicht nur hohe Leistungsfähigkeit und Sicherheitsfunktionen, sondern auch umfangreiche Funktionen zur Verkehrssteuerung. In der folgenden Diskussion werden wir uns eingehend mit dem „Dreiklang“ der API-Service-Governance befassen und detaillierte Einblicke geben, wie diese Strategien in APISIX angewendet werden können, um die hohe Verfügbarkeit unserer Dienste sicherzustellen.

API-Governance-Strategien

Ratenbegrenzung

Ratenbegrenzung, wie der Name schon sagt, ist ein restriktiver Mechanismus, der auf den Datenverkehr angewendet wird. Ihr Kernprinzip besteht darin, eine Überlastung oder sogar einen Absturz des Systems durch übermäßigen Datenverkehr zu verhindern. Das grundlegende Konzept liegt in der Regulierung des Anfragevolumens innerhalb bestimmter Zeitintervalle, wobei nur Anfragen, die bestimmte Einschränkungen erfüllen, Zugang zum System erhalten, um so den stabilen Betrieb von Microservices und des gesamten Systems sicherzustellen. In realen Szenarien ist das Konzept der Ratenbegrenzung ebenfalls offensichtlich. Zum Beispiel werden während der Stoßzeiten in U-Bahn-Stationen mehrere Zugangstore für Sicherheitskontrollen eingerichtet, um ein geordnetes und reibungsloses Anstellen zu ermöglichen.

Ratenbegrenzung kann auf verschiedene Arten implementiert werden, darunter:

Basierend auf der Anzahl der Anfragen: Verfolgung der Anzahl der Anfragen innerhalb jedes Zeitraums und Begrenzung auf einen bestimmten Schwellenwert. Zum Beispiel die Verarbeitung von maximal 100 Anfragen pro Sekunde.
Basierend auf der Anfragehäufigkeit: Begrenzung der Anfragehäufigkeit pro Client oder IP-Adresse, um eine übermäßige Anzahl von Anfragen zu verhindern. Zum Beispiel die Zulassung von maximal 10 Anfragen pro Minute.
Basierend auf der Anzahl der Verbindungen: Begrenzung der Anzahl gleichzeitiger Verbindungen, um den Verbrauch von Systemressourcen zu vermeiden. Zum Beispiel die Zulassung von maximal 100 gleichzeitigen Verbindungen.

Verschiedene Ratenbegrenzungsstrategien ermöglichen es uns, unterschiedliche Szenarioanforderungen zu bewältigen. Zum Beispiel können wir für wertvolle API-Ressourcen die Anzahl der Anfragen auf 10 pro Minute begrenzen. Oder, um die Verfügbarkeit des Dienstes zu erhöhen, können wir die Anzahl der gleichzeitigen Anfragen begrenzen, um die Antwortzeit des Dienstes zu verringern, unter anderem. Die richtige Implementierung dieser Ratenbegrenzungsstrategien kann dazu beitragen, den normalen Betrieb von Diensten bei hoher Parallelität und plötzlichen Verkehrsspitzen sicherzustellen.

Circuit Breaking

In einer Microservices-Architektur kann es Situationen geben, in denen Dienste sich gegenseitig aufrufen. Sobald ein Dienst ausfällt, kann dies andere Dienste beeinträchtigen oder sogar zum Zusammenbruch des gesamten Systems führen, ein Phänomen, das anschaulich als „Kaskadenausfall“ oder „Lawineneffekt“ bezeichnet wird. Der Circuit-Breaking-Mechanismus, als Schutzmaßnahme gegen Kaskadenausfälle in Microservices, wird verwendet, um die Ausbreitung von Ausfällen zu verhindern. Wenn ein Microservice Anomalien oder Verzögerungen aufweist, wird der Circuit Breaker schnell ausgelöst, indem Anfragen an diesen Dienst vorübergehend blockiert werden, um sicherzustellen, dass die Stabilität des gesamten Systems nicht beeinträchtigt wird.

Das Kernprinzip des Circuit-Breaking-Mechanismus liegt in der Echtzeitüberwachung der Dienstantwortzeit oder Fehlerraten. Sobald diese Metriken voreingestellte Schwellenwerte überschreiten, wird der Circuit Breaker automatisch ausgelöst und stoppt schnell Anfragen an den fehlerhaften Dienst, bis dieser wieder normal funktioniert. Nach der Stabilisierung des Dienstes schließt sich der Circuit Breaker automatisch und ermöglicht wieder den Zugriff auf den Dienst. Dieser Mechanismus ähnelt einem Widerstand in einem elektrischen Stromkreis. Wenn die Spannung seinen Toleranzbereich überschreitet, trennt der Widerstand automatisch den Stromkreis, um zu verhindern, dass übermäßiger Strom andere elektronische Komponenten beschädigt. Nach der Überprüfung und Reparatur des Stromkreises schließt sich der Widerstand wieder, und der Stromkreis funktioniert normal weiter.

Durch die Einführung von Circuit-Breaking-Mechanismen kann die Microservices-Architektur besser mit potenziellen Kaskadenausfällen umgehen, die sich aus gegenseitigen Dienstaufrufen ergeben, und die Stabilität und Zuverlässigkeit des Systems sicherstellen, insbesondere unter Hochdruckszenarien.

Degradation

Degradation, als eine effektive Strategie zur Bewältigung hoher Systemlasten, beinhaltet die vorübergehende Deaktivierung einiger nicht kritischer Funktionen oder die moderate Reduzierung der Qualität bestimmter Dienste, um den stabilen Betrieb des Gesamtsystems sicherzustellen. In der Microservices-Architektur kann die Anwendung von Degradationsmechanismen einige nicht-kernbezogene oder vorübergehend entbehrliche Funktionen intelligent abschirmen, um so die kontinuierliche und stabile Funktion der Kernfunktionen sicherzustellen. Zum Beispiel können wir in einer Videokonferenzanwendung, wenn die Netzwerkbandbreite begrenzt ist, die Qualität der Videoübertragung reduzieren oder die Videofunktion vorübergehend deaktivieren, um klare und stabile Audiogespräche zu gewährleisten und so die grundlegenden Kommunikationsbedürfnisse der Besprechung zu erfüllen.

Häufige Strategien umfassen:

Funktionsdegradation: Vorübergehende Schließung oder Einschränkung des Zugriffs auf bestimmte Funktionen, um den normalen Betrieb von Kerndiensten sicherzustellen. Zum Beispiel kann eine Social-Media-Anwendung während der Stoßzeiten die Funktionen „Gefällt mir“ oder „Kommentar“ vorübergehend deaktivieren, um sicherzustellen, dass Benutzer Inhalte normal durchsuchen können.
Qualitätsdegradation: Während hoher Systemlasten die Qualitätsanforderungen bestimmter Dienste oder Funktionen senken. Zum Beispiel, wie bereits erwähnt, die Reduzierung der Videoklarität oder Bildrate, um eine reibungslose Kommunikation zu gewährleisten.

Ratenbegrenzung, Circuit Breaking und Degradation in APISIX

Wie können wir die oben genannten drei großen Strategien, die in APISIX aktiviert sind, nutzen, um die hohe Verfügbarkeit von Microservices zu verbessern? Im Folgenden sind nur einige gängige Anwendungsbeispiele zur Veranschaulichung aufgeführt.

Ratenbegrenzung mit dem `limit-count`-Plugin

APISIX bietet verschiedene integrierte Verkehrsmanagement-Plugins wie limit-count, limit-req und limit-conn. Je nach tatsächlichem Bedarf können wir die geeignete Methode zur Verkehrskontrolle wählen. Nehmen wir das limit-count-Plugin als Beispiel, es begrenzt die Gesamtzahl der Anfragen innerhalb eines bestimmten Zeitintervalls und gibt die verbleibende Anzahl der Anfragen im HTTP-Header zurück.

curl -i http://127.0.0.1:9080/apisix/admin/routes/1 \
-H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "uri": "/get",
    "plugins": {
        "limit-count": {
            "count": 3,
            "time_window": 60,
            "rejected_code": 429,
            "key_type": "var",
            "key": "remote_addr"
        }
    },
    "upstream": {
        "type": "roundrobin",
        "nodes": {
            "httpbin.org:80": 1
        }
    }
}'

Circuit Breaking mit dem `api-breaker`-Plugin

Das api-breaker-Plugin in APISIX löst automatisch Circuit-Breaking-Mechanismen basierend auf voreingestellten Schwellenwerten aus, um Kaskadenausfälle zu verhindern. Zum Beispiel kann es Circuit Breaking auslösen, wenn Upstream-Dienste 3 aufeinanderfolgende 500- oder 503-Statuscodes zurückgeben, und den Zugriff wiederherstellen, wenn ein 200-Statuscode empfangen wird.

curl "http://127.0.0.1:9180/apisix/admin/routes/1" \
-H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "plugins": {
        "api-breaker": {
            "break_response_code": 502,
            "unhealthy": {
                "http_statuses": [500, 503],
                "failures": 3
            },
            "healthy": {
                "http_statuses": [200],
                "successes": 1
            }
        }
    },
    "upstream": {
        "type": "roundrobin",
        "nodes": {
            "httpbin.org:80": 1
        }
    },
    "uri": "/get",
}'

Degradation mit dem `fault-injection`-Plugin

Die Plugins fault-injection und mocking in APISIX unterstützen die Einstellung von Degradationsstrategien, um während hoher Systemlasten bestimmte Funktionen vorübergehend zu deaktivieren oder direkt voreingestellte Daten zurückzugeben, um die Systemstabilität zu gewährleisten. Zum Beispiel kann das fault-injection-Plugin direkt spezifizierte HTTP-Statuscodes und Body-Werte an Clients zurückgeben.

curl http://127.0.0.1:9180/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "plugins": {
       "fault-injection": {
           "abort": {
              "http_status": 200,
              "body": "Fault Injection!"
           }
       }
    },
    "upstream": {
       "nodes": {
           "httpbin.org:80": 1
       },
       "type": "roundrobin"
    },
    "uri": "/get"
}'

Fazit

Ratenbegrenzung, Circuit Breaking und Degradation, als entscheidende Maßnahmen der Service-Governance in der Microservices-Architektur, spielen eine unersetzliche Rolle bei der Verbesserung der hohen Verfügbarkeit von Microservices. Sie fungieren als solide Schilde, die die Microservices-Architektur vor verschiedenen potenziellen Risiken und Herausforderungen schützen. Angesichts unterschiedlicher Geschäftsszenarien sollten wir diese Maßnahmen flexibel und vorsichtig anwenden, um sicherzustellen, dass die Stabilität und Zuverlässigkeit der Microservices-Architektur optimal geschützt sind.