Warum Beike, die beliebte Wohnungsplattform, Apache APISIX wählt

Hallo, ich bin Hui Wang und verantworte die Entwicklung des API-Gateway-Systems bei Ke Holdings (Beike), einer führenden integrierten Online- und Offline-Plattform für Immobilientransaktionen und -dienstleistungen in China. Beike verwendet Apache APISIX als API-Gateway im Produktionssystem. Als datengetriebenes Unternehmen durchlaufen täglich Millionen von Produktionsanfragen das API-Gateway, und Apache APISIX bietet dabei eine stabile und herausragende Leistung. Kürzlich ist Apache APISIX dem Apache-Inkubator beigetreten, und ich möchte diese Gelegenheit nutzen, um die Gründe zu teilen, warum wir uns anfangs für Apache APISIX entschieden haben, sowie einige Erfahrungen bei der Nutzung.

Kong oder Apache APISIX

Für die technischen Anforderungen des Gateways muss es zunächst eine hervorragende Leistung und die Fähigkeit bieten, den Zugriff auf erheblichen Datenverkehr zu unterstützen. Darüber hinaus sollte es auch stabil sein, mit einer Fehlerrate von null.

Das Auswahlprinzip für den Anbieter besteht darin, eine stabilere Version basierend auf oder inspiriert von anderen Open-Source-Projekten zu erstellen, um einen größeren Datenverkehr zu bewältigen. Nach der Bewertung der Vor- und Nachteile besprach ich diese Idee mit meinem Vorgesetzten, und wir beschlossen, das Projekt zu starten. Die erste Wahl, die mir in den Sinn kam, war Kong, ein weiteres bekanntes Open-Source-Gateway.

Nachdem ich die offizielle Website von Kong durchsucht und einige verwandte Artikel gelesen hatte, dachte ich, dass Kong eine geeignete Option sei, da es die meisten Benutzeranforderungen erfüllen konnte und die Leistung ebenfalls sehr stabil war. Ich klonte sofort den Code und begann, ihn zu lesen. Allerdings war ich auch nach mehreren Tagen der Untersuchung ziemlich verwirrt. Ich vermute, ich habe den Grund verstanden, warum Kong eine so große Codebasis hat, nämlich dass es eine Vielzahl von Funktionen bieten muss.

Plötzlich tauchten mehrere Fragen in meinem Kopf auf. Wie lange wird es dauern, Kong vollständig zu verstehen? Wie lange wird es dauern, ein Projekt zu erstellen, das alle Anforderungen erfüllt? Brauche ich all diese Funktionen, die Kong bietet?

Einige Tage zuvor wurde die API-Gateway-Version 0.5 von Apache APISIX veröffentlicht. Mit einer lernenden Einstellung sah ich mir schnell dieses Open-Source-Projekt an und stellte überrascht fest, dass es von Yuansheng Wang und Ming Wen, zwei Experten im Bereich der API, gemeinsam entwickelt wurde. Ich konnte dieses Produkt aufgrund der Empfehlungen dieser Experten nicht ablehnen.

Da das Open-Source-Projekt noch nicht lange existierte, waren die unterstützten Funktionen von Apache APISIX ebenfalls recht begrenzt. Allerdings waren bereits alle wesentlichen Funktionen wie dynamischer Lastausgleich, Circuit Breaker, Authentifizierung und Ratenbegrenzung implementiert. Gleichzeitig reduziert eine relativ kleine Codebasis auch die Lernkosten. Im Vergleich zu Kong konnte ich den Sieg von Apache APISIX verkünden. Apache APISIX ist besser für meine aktuelle Situation geeignet, da es meinen anfänglichen Funktionsplan erfüllen konnte, ohne Bedenken hinsichtlich unnötiger Funktionen.

Das kritischste Problem war jedoch, dass die Leistung von Apache APISIX aufgrund seiner begrenzten Open-Source-Zeit ein Schwachpunkt sein könnte. Im Vergleich der Stress-Test-Ergebnisse mit Kong unter denselben Testbedingungen schlug Apache APISIX schließlich Kong. Allerdings ist dies nicht fair für Kong, da Kong viel schwergewichtiger und komplexer ist. Andererseits gibt es in meinem Anwendungsfall keinen Unterschied, da alle benötigten Funktionen in Apache APISIX bereitgestellt werden. Laut dem Leistungstestbericht von Apache APISIX kann eine Single-Core-CPU 24k QPS erreichen, während die Latenz nur 0,7 Millisekunden beträgt.

Zusammenfassend habe ich Apache APISIX aus folgenden Gründen gewählt:

• Unter der Voraussetzung, dass es alle Anforderungen des Projekts erfüllen kann, sind die Lernkosten von Apache APISIX niedrig
• Kong hat eine große Codebasis, was die Wartung des Codes erschwert
• Die Autoren von Apache APISIX sind aktiver in der OpenResty-Community, was eine bessere Codequalität bietet
• Das Wichtigste ist, dass Fragen schnell durch direkte Kommunikation mit den Autoren gelöst werden können

Die Gründe für APISIX, die auf der offiziellen Website angegeben sind, sind in der folgenden Abbildung dargestellt:

Welche Fähigkeiten bietet Apache APISIX?

• Hot Updates und Hot Plugins
• Dynamischer Lastausgleich
• Aktive und passive Gesundheitsprüfung
• Circuit Breaking
• Authentifizierung
• Ratenbegrenzer
• gRPC-Protokollumwandlung
• Dynamischer TCP/UDP, gRPC, WebSocket, MQTT-Broker
• Dashboard
• Verbots- und Erlaubnisliste
• Serverless

Apache APISIX wurde in fast zehn Versionen veröffentlicht und unterstützt weit mehr Funktionen als die hier aufgeführten. Das Architekturdiagramm wurde entsprechend der Geschäftssituation erstellt und sieht wie folgt aus:

Die Geschichte unserer Integration von APISIX

Nach einigen Tagen des Code-Lesens hatte ich ein grundlegendes Verständnis von Apache APISIX, aber eine Frage tauchte auf: Ich habe noch nie ein Open-Source-Projekt entwickelt. Wie könnte ich das schaffen? Ich erstellte drei verschiedene Branches lokal, ein Apache APISIX-Branch verweist auf das Upstream-Open-Source-Repository, ein weiterer Branch dev wird für regelmäßige Geschäftsiterationen verwendet, und der letzte Main-Branch wird für Online-Upgrades verwendet.

Nach zwei Wochen harter Arbeit hatte mein Projekt endlich einige grundlegende Strukturen. Es war an der Zeit, das Ergebnis zu überprüfen; so begannen wir die Stress-Test-Phase. Der Dienst wird auf Tencent Cloud mit 8 Core und 32 GB RAM-Servern bereitgestellt, und das Upstream ist eine reguläre Cloud-Produktionsumgebung, daher kann es nicht zu hart getestet werden. Der Leistungsbericht ist wie folgt:

Zusammenfassung des Leistungsberichts: Die Schnittstellenzeit wurde um 47% reduziert, es wurden keine Fehler ausgelöst, und die Stabilität wurde verbessert. Der TPS-Spitzenwert wurde um 82% erhöht, es wurden keine Fehler ausgelöst, und die Stabilität wurde verbessert.

Die Entwicklungsumgebung ist bereit, und wir begannen mit der Untersuchung der Cloud-Bereitstellung. Apache APISIX unterstützt viele Installationsmethoden: Docker, RPM-Paket, Luarocks und Quellcode. Die schlechte Nachricht ist, dass in der Cloud-Umgebung nichts installiert werden darf, und der Quellcode kann nur in einem festen Pfad platziert werden. Daher würden viele Apache APISIX-Funktionen nicht unterstützt, da sie auf OpenResty 1.15.8 basieren. Was konnte ich tun? Kompilierte Dateien werden im Code-Repository generiert, sie müssen unter einem bestimmten Verzeichnis kompiliert werden, und Sie können die statische Bindung von PCRE nicht verwenden, was uns 1-2 Tage kostete. Schließlich passten wir das Grau-Release an; der Datenverkehr stieg innerhalb weniger Wochen von 2% auf das Gesamtvolumen. Glücklicherweise verlief am Ende alles erfolgreich.

Nach mehreren Wochen der Überwachung ist der Online-Dienst relativ stabil. Viele Funktionen von Apache APISIX 0.5 müssen über API-Schnittstellenaufrufe implementiert werden. Die Anforderungsparameter sind anfällig für Syntaxfehler, und es gibt keine intuitive und bequeme Seite. Abgesehen davon benötigt unser Geschäftsszenario die Funktion, Upstream-Dienste zu prüfen. Es ist ein solcher Zufall, dass Apache APISIX Version 0.7 gerade veröffentlicht wurde, und Version 0.7 unterstützt die Konsole und die Upstream-Dienstprüfung, was genau das ist, was wir jetzt brauchen. Was für eine großartige Nachricht! Wir müssen upgraden!

Der Apache APISIX-Branch ist einfach auf 0.7 zu aktualisieren, aber wie könnten wir den Code zusammenführen? Die Codeänderungen zwischen diesen beiden Versionen sind enorm. Ich versuche, sie zuerst zusammenzuführen, aber es gibt zu viele Konflikte, und wir sind in einem so gefährlichen Tempo. Die Standardmethode zur Konfliktlösung ist unrealistisch, was zu vielen versteckten Fehlern führen könnte. Gibt es eine effiziente Lösung? Ich suchte online und fand die Abkürzungsmethoden: git checkout –ours und git checkout –theirs (bitte suchen Sie danach, wenn Sie es noch nicht verwendet haben), und vollendete das Upgrade von APISIX 0.5 auf 0.7 in wenigen Minuten. Natürlich sollte auch die Robustheit des APISIX-Codes gedankt werden, die es mir ermöglicht, nur Geschäftsplugins hinzuzufügen, ohne jegliche Kopplung.

Da Apache APISIX Version 0.7 eine Konsole bietet, muss kein JSON mehr geschrieben werden. Ich überprüfte schnell die Gesundheitsprüfung, und es gab zunächst kein Problem, und ich konnte den Status des Upstream-Dienstes wahrnehmen. Als ich jedoch die Protokolle des Upstream-Dienstes überprüfte, stellte ich fest, dass nach mehreren Neustarts die Häufigkeit der Gesundheitsprüfung ständig zunahm. Ich vermute, dass es einen Fehler in der Gesundheitsprüfung geben könnte. Nach dem Lesen des Quellcodes stellte ich fest, dass der Checker für jeden Router nicht global eindeutig ist. Stattdessen hat jede Arbeit einen Checker. Wir könnten dieses Problem lösen, indem wir denselben Namen für alle erstellten Arbeiten verwenden. Auch wenn es sich um eine kleine Korrektur handelt, ist ein Hot-Fix-PR notwendig.

Ich aktualisierte den Online-Geschäfts-APISIX auf 0.7 und überwachte die Dienstressourcennutzung. Schließlich war es eine bedeutende Versionsänderung, und ich spürte in den ersten Stunden nichts, ähnlich wie bei der letzten 0.5-Änderung. Ich werde einen zweiten Blick darauf werfen, wenn ich von der Arbeit nach Hause komme. Es scheint, dass die Speichernutzung nicht korrekt ist. Die 0.5-Version war relativ stabil, aber die 0.7-Version scheint Speicherlecks zu haben. Da die Speichernutzung sehr langsam ansteigt, beschloss ich, sie die ganze Nacht zu überwachen. Am nächsten Tag verglich ich die überwachten Daten, stellte fest, dass es ein Speicherleck gab, und rollte schnell auf die vorherige Version zurück. Nachdem alles erledigt war, gab ich Yuan Sheng Feedback zu diesem Problem. Gemäß dem von mir beschriebenen Szenario fand ich das Problem durch Stress-Tests. Es war ein Problem mit dem Radix-Baum. Das gleiche Problem trat nie wieder auf, nachdem ich die Abhängigkeiten aktualisiert hatte, da Yuan Sheng die neue Version des Radix-Baums veröffentlichte.

Nach dem Neustart des Projekts konnte Apache APISIX Version 0.7 mir immer noch von Zeit zu Zeit Überraschungen bieten. Die Routing-Abhängigkeit, die in Apache APISIX 0.5 verwendet wurde, war libr3, während Apache APISIX 0.7 den Radix-Baum verwendete, der eine bessere Leistung bietet. Die CPU- und Speichernutzung sanken beide. In Apache APISIX 0.5 betrug die CPU-Nutzung 1-10%, und der Speicher 0.1%. In Apache APISIX 0.7 wurde die CPU-Nutzung auf 1-2% reduziert, und der Speicher betrug weniger als 0.1%, was ausgezeichnet ist.

Zukunftsplan

Apache APISIX wurde seit zwei Monaten eingesetzt, und es gab weder Ausfälle noch Fehler. Dies ist erst der Anfang, und wir können in Zukunft noch viel mehr tun, um mehr Fähigkeiten für Dienstleister zu zeigen. Das Gateway bietet einen Reverse-Proxy und hilft einigen Teams, die keine Zeit haben, Funktionen zu entwickeln, um die Dienststabilität zu gewährleisten, einschließlich Diensten wie Ratenbegrenzung, Circuit Breaker, Überwachung und Zugriffsplattformen.

Abschließend möchte ich Yuan Sheng und Wen Ming für die Bereitstellung eines so hervorragenden Produkts danken und der Apache APISIX-Community für die beigetragenen iterativen Funktionen. Der tägliche Datenverkehr des Gateways hat jetzt 100 Millionen überschritten, und es gibt keine Leistungsprobleme. Vielen Dank für Ihre Zeit und Aufmerksamkeit!