Wir haben das Problem mit dem Fehler 429 während der großen Rabattaktion mithilfe des Kubernetes-Gateways gelöst und gleichzeitig 30% der Serverkosten eingespart.

Letzten Monat, während des Black Friday, wäre unser Team fast zusammengebrochen:13 Prozent der Anfragen zur Adress解析 der Nutzer werden direkt mit einem Fehlercode 429 abgewiesen.Nach einer halben Ermittlung im Hintergrund stellte sich heraus, dass die zuvor für jeden Microservice einzeln festgelegten Throttling-Regeln zu streng waren. Dadurch ist der Datenverkehr im Logistikabfrage-Modul um das Dreifache gestiegen, und die anderen verfügbaren Ressourcen konnten nicht genutzt werden.

Früher dachten wir immer, dass der Kubernetes-Gateway ein komplexer Komponent ist, der nur von großen Unternehmen verwendet wird. Erst als wir auf dieses Problem stießen, wurden wir gezwungen, ihn einzuführen. Es dauerte weniger als eine Woche, und das Ergebnis war viel besser, als wir erwartet hatten.

Was genau ist ein Kubernetes-Gateway?

Einfach ausgedrückt: Es handelt sich um die zentrale Eintrittspforte für den gesamten Kubernetes-Cluster. Alle externen Anfragen gelangen zunächst dorthin, bevor sie an die entsprechenden Backend-Dienste weitergeleitet werden. Die von uns verwendete Open-Source-Version kann mit nur einer Instanz pro Sekunde bis zu 12.000 Anfragen bewältigen – kleine Teams müssen sich daher keine Sorgen um Leistungsengpässe machen.

Drei echte Vorteile, die wir erhalten haben

Der erste und offensichtlichste Vorteil: Die Regelungen zur Begrenzung des Datenverkehrs müssen nicht mehr für jeden einzelnen Dienst separat konfiguriert werden. Früher mussten wir bei großen Verkaufsaktionen die Begrenzungswerte von sieben oder acht Microservices ändern; wenn dabei ein Fehler auftrat, hatte das negative Auswirkungen auf den gesamten Betrieb. Jetzt erfolgt die dynamische Begrenzung des Datenverkehrs direkt auf der Gateway-Ebene, wodurch freie Serverressourcen automatisch an die Module mit höherem Datenverkehr umgeleitet werden. Während der diesjährigen Weihnachtsverkaufsaktion sank die Anzahl der 429-Fehler, die auftraten, auf null.

Der zweite Vorteil ist die Kosteneinsparung. Früher haben wir für die Bewältigung von Spitzenlasten drei Kerndiensten jeweils mit zwei zusätzlichen redundanten Servern ausgestattet, wobei die Ressourcennutzung die meiste Zeit nur bei 20% lag. Jetzt kann das Gateway automatisch Lastverteilung durchführen, und wir haben sechs Server direkt abgeschaltet. Nach der Berechnung sind die monatlichen Cloudkosten um 30% gesunken.

Der dritte Vorteil ist, dass es nicht mehr notwendig ist, die Backend-Systeme ständig umzuprogrammieren, um universelle Logiken wie Cross-Origin-Verarbeitung und Authentifizierung zu implementieren. Früher musste für jeden neuen Dienst der Backend-Code zur JWT-Überprüfung neu geschrieben werden. Jetzt genügt es, eine Regel auf der Gateway-Ebene einzurichten, und schon ist alles erledigt. Dadurch haben unsere drei Backend-Entwickler wöchentlich mindestens eine halbe Stunde mehr Zeit, um an dem eigentlichen Geschäftskodex zu arbeiten.

Hören Sie nicht nur auf die Vorteile – diese beiden Fallstricke haben wir wirklich zu spüren bekommen.

Das erste Problem ist die zu lange Standardzeitüberschreitung. Schon am ersten Tag nach der Veröffentlichung stellten wir fest, dass 5 Prozent der Adressauflösungsanfragen fehlgeschlagen sind, weil sie die Zeitüberschreitung erreichten. Nach langen Untersuchungen stellten wir fest, dass die Standardzeitüberschreitung des Gateways auf 30 Sekunden eingestellt war, während unsere Adressauflösungsdienste in der Regel bis zu 40 Sekunden benötigen. Nachdem wir die Regel geändert hatten, verbesserte sich die Situation sofort. Vor der Veröffentlichung sollte man unbedingt die Zeitüberschreitungswerte für jede eigene Geschäftsschnittstelle individuell überprüfen.

Der zweite Fehler besteht darin, nicht von Anfang an alle Funktionen auf einmal zu aktivieren. Ursprünglich wollten wir alle Funktionen wie Protokollierung, Throttling, WAF und Graustufenveröffentlichung gleichzeitig aktivieren, aber aufgrund eines Fehlers in der Konfiguration war der gesamte Cluster für 20 Minuten nicht erreichbar. Später haben wir zunächst nur Routing und Throttling aktiviert, und nach drei Tagen stabilen Betriebs haben wir nach und nach weitere Funktionen hinzugefügt – seitdem gab es keine Probleme mehr.

Soll man es überhaupt verwenden? Unsere Kriterien für die Entscheidung sind sehr einfach.

Anwendbare Fälle:

• Sie haben bereits mehr als 5 Microservices, und jedes Mal, wenn Sie die allgemeinen Konfigurationen ändern müssen, müssen Sie an mehreren Stellen nachbessern.
• Häufig treten Spitzenbelastungen auf, wodurch es nicht möglich ist, die Ressourcen zwischen den verschiedenen Diensten flexibel zu verteilen.
• Das Backend-Team besteht aus weniger als 5 Personen, und wir möchten keine Zeit mit der Wiederholung der Erstellung allgemeiner Logiken verschwenden.

Fälle, in denen man sich nicht die Mühe machen sollte:

• Sie haben nur zwei Microservices, und der Datenverkehr ist das ganze Jahr über stabil. Derzeit gibt es keinerlei Probleme mit der Nutzung von NGINX für die Weiterleitung des Datenverkehrs.
• Niemand im ganzen Team versteht die Grundlagen von Kubernetes – versucht also nicht, neue Technologien zu überstürzt einzuführen, nur um mit dem Trend zu gehen.

Zwei praktische Ratschläge für kleine Teams, die zum ersten Mal damit arbeiten

Man muss sich keine Gedanken über die Auswahl der Software machen – kleine Teams können einfach auf die open-source-Lösungen API-SIX oder Kong zurückgreifen. Es gibt umfassende Dokumentationen, und bei Problemen findet man in der Regel Lösungen, wenn man sucht. Es ist nicht notwendig, eine kommerzielle Version zu kaufen; die Funktionen der kostenlosen Versionen reichen völlig aus.

Vor der Live-Veröffentlichung sollten zuerst 10 % des Datenverkehrs für 24 Stunden umgeleitet werden, um insbesondere zu überprüfen, ob es zu Fällen von Timeout oder fehlerhafter Blockierung von Anfragen kommt. Erst wenn alles in Ordnung ist, sollte der gesamte Datenverkehr umgeleitet werden. Man sollte nicht von Anfang an den gesamten Verkehr auf die neue Plattform übertragen.

Zum Schluss noch eine häufig gestellte Frage: Keiner von uns drei Backend-Entwicklern hatte zuvor speziell mit Gateways gearbeitet. Wir haben uns zwei Tage lang mit den offiziellen Dokumentationen beschäftigt und das Gateway dann aufgebaut – es ist wirklich nicht so kompliziert, wie man vielleicht denkt.