API Gateway Praxis bei Tencent mit Apache APISIX

Was ist ein API-Gateway?

Traditionelle Architektur

Vor der Integration mit einem API-Gateway hatten wir nur wenige Möglichkeiten, einige allgemeine Funktionen wiederzuverwenden, wie z.B.:

• Sicherheit: Authentifizierung, Autorisierung, Anti-Replay, Anti-Manipulation, Anti-DDoS usw.
• Zuverlässigkeit: Dienstdegradierung, Fusing, Traffic-Limiting usw.

In der traditionellen Architektur war die gängigste Methode, diese Funktionen in ein Service-Framework zu integrieren und sie über AOP zu implementieren, ähnlich wie in der folgenden Architekturdiagramm dargestellt:

Das traditionelle Architekturdiagramm enthält die folgenden Module.

• Backend: Backend-Dienste
• AOP: AOP-Schicht, die vom Framework getragen wird;
• SD: Service Center, das für die interne Dienstentdeckung verwendet wird. In Cloud-Native-Technologien verwenden wir oft Service, um diese Komponente zu ersetzen;
• LB: Load Balancer, den wir an der Netzwerkgrenze als Einstiegspunkt für externen Traffic verwenden.

Diese Art von Architektur war in den frühen Jahren weit verbreitet und hat viele umfassende Service-Frameworks wie Dubbo, SpringCloud usw. hervorgebracht. Wir werden feststellen, dass die meisten davon viele ähnliche Funktionen haben.

Der Vorteil dieser Architektur besteht darin, dass die Beziehungen zwischen Upstream und Downstream einfacher und klarer sind und sie eine Weiterleitung in der Netzwerkübertragung reduziert. Aber ihre Nachteile sind ebenfalls offensichtlich:

• Standardfunktionen erzwingen Updates von Geschäftsdiensten: Da Code-Referenzen verwendet werden, müssen wir Geschäftsdienste neu kompilieren, um die Funktionen wirksam zu machen. Einige Teams, die kein Rolling Release erreichen, müssen während der Ruhezeiten des Geschäfts Releases durchführen.
• Schwierige Versionsverwaltung: Da wir nicht alle Dienste bei jedem Release auf die neueste Version aktualisieren können, wird die Leistung der verschiedenen Dienste nach einer gewissen Zeit inkonsistent.

Warum nicht diese gleichen Funktionen in einen eigenständigen Dienst auslagern, der separat aktualisiert oder gewartet werden kann?

Gateway-Modus

Im Vergleich zur traditionellen Architektur sehen wir eine zusätzliche Komponente zwischen den Backend-Diensten und dem LB: das Gateway.

Ein Gateway enthält normalerweise viele standardisierte und wiederverwendbare Funktionen wie Authentifizierung, Traffic-Management usw. Hier sind die Vorteile, die wir daraus ziehen können:

• Das Gateway ist eine abhängige Komponente in den Systemen, und wir könnten eine bessere Wartungserfahrung haben.
• Das Gateway ist sprachunabhängig.

Allerdings hat der Gateway-Modus auch seine Nachteile:

• Da wir den Traffic zuerst an das Gateway weiterleiten, haben wir eine zusätzliche Weiterleitung und eine höhere Latenz. Dies führt zu einer höheren Komplexität bei der Fehlerbehebung.
• Wenn das Gateway nicht korrekt funktioniert, kann es zu einem Engpass für das gesamte System werden.

Wie man die Vorteile und Nachteile des Gateway-Modells ausbalanciert, ist eine Herausforderung für das technische Team. Lassen Sie uns sehen, wie das Tencent OTeam mit Apache APISIX arbeitet.

Einführung

OTeam

Tencent’s OTeam ist eine Gruppe von Teams, und jedes Team verwaltet ein oder mehrere technische Produkte. Ihr Ziel ist es, eine stabile, aber robuste Mid-Plattform für interne Systeme zu schaffen. Eines der OTeams unterstützt die interne Apache APISIX-Customization-Distribution von Tencent.

Um die doppelten Räder innerhalb des Unternehmens zu integrieren und die technische Mitte zu stärken, hat Tencent mehrere technische Produkte gleicher Art in dasselbe Oteam integriert, die Wartungsmitarbeiter zusammengeführt und sie gemeinsam aktiviert, damit sie sich allmählich zu einem großen und umfassenden Produkt zusammenschließen können, dem Oteam.

Einige Oteams haben bis zu einem Dutzend Produkte unter sich, während andere nur eines haben. Zum Beispiel hat das Oteam, in dem Apache APISIX angesiedelt ist, nur ein Produkt, Apache APISIX. Der ursprüngliche Zweck dieses Oteams war es, die Customization-Features von Apache APISIX innerhalb von Tencent zu pflegen.

Apache APISIX

Apache APISIX ist ein Top-Level-Projekt der Apache Software Foundation, und hier sind einige wichtige Punkte:

• Apache APISIX ist ein Cloud-natives, dynamisches API-Gateway basierend auf OpenResty, mit einer höheren Routing-Leistung als Kong.
• Apache APISIX bietet umfangreiche Traffic-Management-Funktionen wie Load Balancing, dynamisches Upstream, Canary Release, Circuit Breaking, Authentifizierung, Observability und mehr.
• Apache APISIX ist gut darin, traditionellen Nord-Süd-Traffic sowie Ost-West-Traffic zwischen Diensten zu handhaben. Es kann auch als k8s Ingress Controller verwendet werden.
• Apache APISIX verwendet standardmäßig ETCD als Konfigurationszentrum, das die Konfiguration in Sekunden aktualisieren kann.
• Apache APISIX hat die Apache Software Foundation abgeschlossen und brauchte nur wenige Monate.

Betriebsstrategie des Tencent OTeams

Das obige Diagramm zeigt, wie das OTeam mit der Apache APISIX-Community zusammenarbeitet:

• Benutzer geben Feedback oder Anforderungen über GitHub Issue.
• OTeam-Mitglieder diskutieren Lösungen bei wöchentlichen Treffen oder antworten direkt im Issue.
• Implementierung von Funktionen oder Behebung von Fehlern gemäß der Diskussion.
• Code Review und CI-Prüfung, dann Release bei Bedarf.

Dieser Prozess ähnelt anderen Open-Source-Projekten. Hier sind einige wichtige Punkte:

• Nach der Lösung des Issues bestimmen Tencent-Ingenieure, ob das Problem auch ein allgemeines Problem für die Community ist. Wenn ja, reichen sie einen PR bei der Community ein.
• Das Tencent OTeam überprüft regelmäßig die neuen Funktionen von Apache APISIX, um festzustellen, ob sie stabil sind und ob sie auch ein Schmerzpunkt für Tencent sind. Wenn die Antwort ja ist, werden die relevanten Codes übernommen.

Anfangs synchronisierte das OTeam die Codes mit Apache APISIX alle 12 Stunden, damit wir Apache APISIX schnell folgen konnten, aber dieser Ansatz brachte einige Probleme mit sich:

• Nach der Synchronisation der Codes mit Apache APISIX konnten wir sicherstellen, dass die Vorschriften korrekt sind, aber nicht, dass die Codes stabil sind. Einige gelegentliche Fehler traten in Konkurrenzfällen auf.
• Die zusammengeführten Codes verursachten manchmal logische Konflikte mit mehreren PRs upstream, aber die CI von Apache APISIX und OTeam konnte diesen Fall nicht erkennen. Erst wenn wir PRs in den Master-Branch zusammenführten, stellten wir fest, dass etwas schief gelaufen war.

Aus diesen Gründen geht das OTeam nun dazu über, die Codes für erforderliche Funktionen nach internen Überprüfungen zu übernehmen.

OTeam-Trend

Stand Mai 2021 hat das OTeam Apache APISIX bei mehr als zehn Teams innerhalb von Tencent eingeführt, mit einem enormen täglichen Geschäftsanfrage-Traffic von über einer Milliarde. Gleichzeitig hat das OTeam auch mehr als zehn Funktionen für Apache APISIX entwickelt, darunter Service Discovery, RPC-Protokollumwandlung und die Verbindung mit der Monitoring-Plattform.

Gleichzeitig hat das OTeam auch einige Standardfunktionen zur Apache APISIX-Community beigetragen. Derzeit sind zwei Mitglieder des OTeam-Teams auch PMCs von Apache APISIX, und das OTeam hat mehr als 50 PRs zur Community beigetragen. Wir glauben, dass das OTeam in Zukunft weiterhin mit der Apache APISIX-Community zusammenarbeiten wird.

Interne Funktionen des OTeams

Interne Schmerzpunkte

Die Hauptverantwortung des OTeams besteht darin, die Funktionen von Apache APISIX für Tencent zu pflegen. Lassen Sie uns einen Blick darauf werfen, auf welche Schmerzpunkte das OTeam gestoßen ist.

• Das RPC-Framework ist nicht frontendfreundlich: Es gibt viele Legacy-Projekte innerhalb von Tencent, die das TARS-Framework verwenden, das nicht direkt das HTTP-Protokoll wie TRPC unterstützt, sondern nur das traditionelle TCP-Protokoll des RPC-Frameworks, und der Transportinhalt verwendet ein spezifisches Binärprotokoll. Wir müssen einen Zwischendienst pflegen, um diese Schnittstellen in eine frontendfreundliche HTTP + JSON-Form umzuwandeln.
• Diversifizierung der Service Center: Es gibt viele Service Center in den internen Diensten von Tencent, wie CL5, L5, Polaris usw. Obwohl wir schrittweise dasselbe Service Center verwenden werden, werden wir während dieser langen Übergangszeit mehrere Service Center gleichzeitig verwenden. Das ursprüngliche Apache APISIX unterstützt dies nicht.
• Alarm: Als Gateway ist der Alarm keine Richtung, auf die es achten sollte, aber als grundlegende Komponente muss der Alarm eine erforderliche Komponente für das Team sein. Wie man das Alarmproblem löst, ist ebenfalls ein Schmerzpunkt.
• Sicherheit: Tencent hat einen großen Traffic und Sicherheitsanforderungen. Viele toC-Produkte verwenden das OTeam, und sie müssen sich mit einer großen Anzahl von Benutzermissbrauch und Angriffen aus dem Netzwerk auseinandersetzen. Die typischsten Fälle sind DDos, Replay, Manipulation von Anfragen usw. Können wir diese Probleme auf der Gateway-Ebene lösen?

Problemlösung

Das obige Diagramm stammt aus einer Vereinfachung eines Implementierungsfalls innerhalb von Tencent. Wir können sehen, dass mehrere der gerade genannten Probleme im OTeam gelöst wurden:

• Protokollumwandlung: Basierend auf Apache APISIX erreicht das OTeam TRPC- und TARS-Protokollumwandlung. Diejenigen, die keine HTTP-Legacy-Dienste ausführen, können das Umwandlungs-Plugin im Gateway verwenden, um HTTP- und RPC-Transferanforderungen zu erreichen, ohne Zwischendienste zu schreiben.
• Mehrere Service Center: Wir haben diese Funktion zur Community beigetragen. Berichterstattung an die Monitoring-Plattform: Das Tencent OTeam verwendet Plugins, um sich mit Monitoring-Plattformen zu verbinden. Benutzer müssen nur einige Konfigurationen vornehmen, und dann meldet das System automatisch Metriken, Logs. Nebenbei können Benutzer Alarmrichtlinien auf der Monitoring-Plattform konfigurieren.
• Anti-Replay und Anti-Manipulation: Das OTeam implementiert Anti-Replay- und Anti-Manipulation-Plugins, die es externen Unternehmen, die diese Fähigkeiten benötigen, ermöglichen, sie direkt out of the box zu verwenden, um die Sicherheit ihrer APIs zu schützen.

Wir hoffen, dass diese Beispiele Ihnen helfen können, mehr Anwendungsfälle von Apache APISIX zu erkunden und es besser als eine hilfreiche Plattform zu nutzen. Zum Beispiel hat jemand das Gateway verwendet, um einige API-Spezifikationen gemäß den Richtlinien von Tencent Cloud verbindlich umzusetzen.

Zusammenfassung

Das OTeam hat dem Geschäftsteam geholfen, seine Schmerzpunkte zu lösen und die Funktionen von Apache APISIX innerhalb von Tencent kontinuierlich zu verbessern und die Entwicklung der Community voranzutreiben.

Wenn Ihr Team kein Gateway hat, können Sie mehr über Apache APISIX erfahren und sind herzlich eingeladen, an der Apache APISIX-Community teilzunehmen.