Apache APISIX vereinheitlicht das vollständige Traffic-Management mit Service Mesh

Mit dem rasanten Wachstum von Cloud Native gewinnt auch Service Mesh zunehmend an Bedeutung. Derzeit gibt es viele bekannte Service-Mesh-Lösungen, und jedes Produkt hat seine eigenen Vorteile. Daher variieren die Entscheidungen für Service-Mesh-Lösungen je nach Branche oder geschäftlichem Hintergrund.

Aktuelle Situation und Herausforderungen von Service Mesh

Das Aufkommen von Service Mesh steht in engem Zusammenhang mit der aktuellen Entwicklung der Geschäftsarchitektur. Mit dem Aufschwung von Cloud Native haben die meisten Unternehmen begonnen, auf Microservices umzusteigen. Dabei wurde festgestellt, dass Anwendungen immer kleiner wurden und jede Anwendung einige gemeinsame Kernfunktionen enthielt. Daher stellte sich die Frage: „Gibt es eine Technologie, die diese gemeinsamen Szenarien lösen kann?“ So entstand Sidecar.

Mit Sidecar können Funktionen wie Service-Registrierung und -Discovery, Traffic-Management, Observability und Sicherheit in diese Komponente ausgelagert werden, sodass sich die Geschäftsanwendungen auf die Entwicklung der Geschäftslogik konzentrieren können.

Allerdings hat die Einführung von Sidecar in der Praxis einige Herausforderungen offenbart, wie zum Beispiel:

• Es gibt so viele Lösungen, dass eine Migration nach der Auswahl schwierig ist. Heutzutage gibt es zahlreiche Service-Mesh-Lösungen, und die Eigenschaften und Fähigkeiten variieren von Lösung zu Lösung. Sobald eine dieser Lösungen ausgewählt wurde, wird sie in der Regel ohne weitere Änderungen verwendet. Wenn jedoch festgestellt wird, dass die Lösung die neuen Anforderungen bei der Geschäftserweiterung nicht erfüllen kann, entstehen hohe Kosten bei der Migration.
• Hohe Integrationskosten mit der Infrastruktur. Die praktische Implementierung von Service Mesh erfordert oft die Integration mit bestehenden Infrastrukturen, wie z. B. früheren Microservice-Architekturen, MQ- oder Datenbankkomponenten. Bestehende Altlasten oder technische Schulden können den Integrationsprozess erschweren.
• Leistungsverlust und zusätzlicher Ressourcenverbrauch. Derzeit führt jede Service-Mesh-Lösung zu einem gewissen Leistungsverlust. Außerdem müssen aufgrund von Sidecar zusätzliche Ressourcen für die Konfiguration der Geschäftsanwendungen bereitgestellt werden.
• Erhebliche Schwierigkeiten bei der Skalierung. Einige Service-Mesh-Lösungen sind in Bezug auf Protokolle oder Funktionen mit den bestehenden Konfigurationsmethoden nicht skalierbar und können nicht durch Plug-and-Play angepasst werden.

Angesichts dieser geschäftlichen Situation und Herausforderungen haben wir uns gefragt, ob es eine ideale Service-Mesh-Lösung geben könnte, die diese Probleme lösen könnte.

Wie sieht ein ideales Service Mesh aus?

In geschäftlichen Szenarien sind unsere Anforderungen an Service Mesh, wie oben dargestellt, vielschichtig und umfassen Ressourcen, Leistung, Traffic-Management und Skalierbarkeit. Natürlich gibt es darüber hinaus noch detailliertere Anforderungen in anderen Dimensionen. Zum Beispiel:

• Erstens muss auf der Ebene der Nutzungserfahrung die Einstiegshürde niedrig sein, da es möglicherweise mehr Betriebs- und Wartungsaufwand gibt, um Service Mesh anzuwenden, als Entwickler. Daher ist die Einstiegshürde einer der Faktoren, die bei der Wahl einer Lösung berücksichtigt werden.
• Zweitens muss auf der technischen Ebene die Konfiguration der Control Plane einfach zu starten sein. Gleichzeitig müssen die relevanten Berechtigungen streng und sicher kontrolliert werden, und die Konfiguration sollte eher auf der öffentlichen Ebene liegen.
• Auf der Data-Seite ist es besser, mehrere Protokolle oder sogar benutzerdefinierte Protokolle nativ zu unterstützen, da Probleme bei der Migration von historischen Systemen berücksichtigt werden müssen. Aufgrund von Sidecar muss auch sichergestellt werden, dass der Ressourcenverbrauch kontrollierbar ist, um die Kosten effektiv zu steuern. Skalierbarkeit ist ebenfalls erforderlich, um Anpassungen vorzunehmen.
• Schließlich muss innerhalb des gesamten Ökosystems des Produkts sowohl die Community als auch die Produktwartung die Geschwindigkeit einer „zeitnahen Reaktion“ gewährleisten.

Da wir so klare Anforderungen und Ziele haben, besteht der nächste Schritt darin, eine solche nahezu ideale Lösung zu implementieren und zu entwickeln.

APISIX-basierte Service-Mesh-Lösung

Apache APISIX ist ein dynamisches, Echtzeit-, Hochleistungs-Cloud-Native-API-Gateway, das umfangreiche Traffic-Management-Funktionen wie Lastenausgleich, dynamisches Upstream, Canary Release, Circuit Breaking, Authentifizierung, Observability und mehr bietet.

Hunderte von Unternehmen weltweit nutzen Apache APISIX bereits, um geschäftskritischen Traffic zu verarbeiten, darunter Finanzen, Internet, Fertigung, Einzelhandel, Telekommunikation usw., wie z. B. NASA, European Factory Platform, China Airlines, China Mobile, Tencent, Huawei, Weibo, Netease, Ke Holdings Inc., 360, Taikang, Nayuki Holdings Limited usw. Daher wird die APISIX-basierte Service-Mesh-Lösung nicht nur auf der Nutzungsebene, sondern auch in verschiedenen Branchen stark nachgefragt sein.

Die Architektur der aktuellen Service-Mesh-Lösung basiert auf Istio als Control Plane und APISIX als Data Plane.

Zunächst haben wir Istio als Control Plane gewählt, da Istio derzeit die beliebteste Service-Mesh-Lösung ist und eine aktive Community hat, die dazu führt, dass fast alle großen Cloud-Anbieter Istio unterstützen. Dies spiegelt auch die aktuelle Marktnachfrage und -richtung wider. Daher haben wir bei der Wahl der Control Plane kein eigenes Modul entwickelt, sondern uns für Istio entschieden, das besser geeignet ist und eine höhere Akzeptanzrate hat.

Die Data Plane ist der Bereich, in dem Apache APISIX seine Stärken ausspielen kann. Als Cloud-Native-API-Gateway hat APISIX in dieser Service-Mesh-Lösung als Data Plane von Istio einige Maßnahmen ergriffen.

Wer mit APISIX vertraut ist, weiß, dass APISIX etcd für die Datenspeicherung verwendet. Aber wenn wir APISIX als Sidecar verwenden, woher kommt dann seine Konfiguration? Das ist die Frage, die berücksichtigt werden muss. Wenn wir die etcd-Komponente ebenfalls in Sidecar einbinden, stellen wir fest, dass der gesamte Ressourcenverbrauch sehr hoch und nicht flexibel genug ist.

Daher haben wir in diesem Prozess zunächst ein Konfigurationszentrum namens xDS zu APISIX hinzugefügt, um etcd überflüssig zu machen, und dann Amesh eingeführt, wie oben gezeigt, ein Go-Programm, das in eine dynamische Link-Bibliothek kompiliert wird, die beim Start von APISIX geladen wird. Es verwendet das xDS-Protokoll, um mit Istio zu interagieren. Anschließend schreibt es die erhaltene Konfiguration in das xDS-Konfigurationszentrum von APISIX, das spezifische Routing-Regeln generiert und schließlich APISIX verwendet, um die entsprechenden Anfragen zu routen.

Nach der Konfiguration der obigen Architektur können die folgenden Ergebnisse erzielt werden:

• Amesh und APISIX haben denselben Lebenszyklus und können gemeinsam ein- und ausgeschaltet werden.
• Dank der nativen Unterstützung von xDS Discovery durch APISIX werden die Daten über das xDS-Protokoll umgewandelt, was zu einem kontrollierten Ressourcenverbrauch führt.
• CRD kann verwendet werden, um die gesamte Lösung schnell und einfach zu erweitern, insbesondere für Funktionen, die von Istio noch nicht unterstützt werden. Zum Beispiel wird die umfangreichste Plugin-Konfiguration für APISIX über CRD konfiguriert; durch die Verwendung des Controllers zusammen mit Istio wird die Skalierbarkeit der Istio- und APISIX-Service-Mesh-Lösung maximiert.

Spezifische Leistung der Lösung

Deutliche Leistungssteigerung

Daten sind immer die intuitivste und effektivste Methode, um ein Technologieprodukt darzustellen. Wir verwenden APISIX und Envoy als Data Plane in der Service-Mesh-Lösung, führen mit bis zu 5.000 Routen Belastungstests in verschiedenen Szenarien durch und präsentieren die folgenden Datenvergleiche.

Das Testszenario ist „Matching der 3000. Route von 5000 Routen“. Aufgrund der großen Anzahl von Testszenarien werden im Folgenden nur die Routen beschrieben, die den mittleren Teil abdecken, es gibt jedoch auch Szenarien, die die ersten und letzten Routen abdecken. (Es gibt zu viele Daten, um sie alle anzuzeigen, daher sind die folgenden Daten das Ergebnis des Tests mit 3000 Routen).

Wie aus den obigen Daten ersichtlich ist, zeigt APISIX bei gleichem Druck und gleicher Maschinenkonfiguration eine 5-fache Leistungssteigerung auf QPS-Ebene. Außerdem ist die Anforderungslatenz von APISIX um eine Größenordnung niedriger als die von Envoy, wobei APISIX im Mikrosekundenbereich und Envoy im Millisekundenbereich liegt. Natürlich kann man auch sehen, dass bei dieser Messung der CPU-Verbrauch von APISIX nur 50 % beträgt, während die CPU von Envoy bereits voll ausgelastet ist.

Reduzierter Ressourcenverbrauch

Bei der Injektion von Sidecar in die Service-Mesh-Lösung wird in der Regel zusätzlicher Ressourcenverbrauch verursacht. Die API-basierte Lösung kann den Ressourcenverbrauch um 60 % reduzieren. Warum ist das möglich?

Erstens wird die Konfiguration bedarfsgerecht verteilt. Istio verfügt über einige bedarfsgerechte Richtlinien für das Ressourcenmanagement von Sidecar, wie z. B. die Trennung nach Namespaces, aber dieser Prozess stellt zusätzliche mentale Belastungen und Managementherausforderungen für Benutzer dar.

Zweitens ist die Frage, ob die Konfiguration leicht verständlich ist. Wenn Sie eine Route in Envoy konfigurieren, zeigt das Routing-Informationen-Dump, dass es bereits Tausende in Envoy gibt, während es in der Realität nicht so viele gibt. Dies hat viele Auswirkungen, wie z. B. die Beeinträchtigung der Startgeschwindigkeit und die Erhöhung des Ressourcenverbrauchs aufgrund einiger umfangreicher Konfigurationen.

Mit APISIX können Sie all diese Probleme vermeiden. Die APISIX-Konfiguration ist einfach und klar, reduziert die im Speicher gespeicherten Daten und kombiniert mit ihrer hohen Leistung den CPU-Ressourcenverbrauch. Der Ressourcenverbrauch der gesamten Lösung wird um etwa 60 % reduziert.

Geringe Lernkurve und hohe Anpassungsfähigkeit

Erstens bietet APISIX als aktives Open-Source-Projekt der Apache Software Foundation eine Fülle von Dokumentationen und Lernressourcen in der Community, was die Lernkurve für diejenigen, die mit APISIX beginnen möchten, reduziert.

Zweitens ist der Quellcode von APISIX in Lua implementiert, was relativ leicht zu lesen und zu verstehen ist, da es sich um eine leichtgewichtige Skriptsprache handelt, sodass der APISIX-Quellcode klarer ist.

Schließlich ist die sekundäre Entwicklung auf Basis von APISIX sehr einfach. Wenn Sie Plugins für Ihr Geschäft anpassen möchten, wird nicht nur die native Lua-Sprache unterstützt, sondern Sie können auch den APISIX Plugin Runner verwenden, um die sekundäre Entwicklung in vertrauteren Sprachen wie Python, Java, Go und sogar Wasm durchzuführen.

Die ökologische Stärke von APISIX ist auch auf die starke Erweiterbarkeit des Produkts zurückzuführen.

APISIX selbst bietet eine breite Palette von Plugins für Sicherheit, Protokollierung, Observability und mehr. Diese Plugins können voll ausgeschöpft werden, wenn APISIX als traditionelle Gateway-Komponente verwendet wird. Wenn APISIX jedoch in Verbindung mit Istio auf der Control Plane verwendet wird, um ein Service Mesh zu erstellen, sind viele Ressourcen nicht auf der Istio Control Plane definiert. Was kann in diesem Fall getan werden?

Hier kommen benutzerdefinierte CRDs ins Spiel. Wenn wir beispielsweise ein Fehlerinjektions-Plugin erstellen möchten, ist dieses Plugin bereits in APISIX verfügbar, sodass wir hier nur einige zusätzliche Parameter konfigurieren müssen. Natürlich ist dies nur ein Beispiel für das Fehlerinjektions-Plugin. Es gibt auch Plugins für sichere Authentifizierung, Rate Limiting und andere gängige Plugins in APISIX, die auf diese Weise zugänglich sind, um eine feinkörnige Steuerung zu erreichen.

Der unmittelbare Vorteil der Verwendung von CRD auf diese Weise besteht darin, dass die Erweiterung nativer wird, indem deklarative Konfigurationen verwendet werden, die es den Benutzern erleichtern, sie zu akzeptieren, während die ursprüngliche Konfiguration von Istio nicht beeinträchtigt wird, um eine perfekte Kompatibilität zu gewährleisten. Ein weiterer Vorteil ist, dass die Migrationskosten für Benutzer, die bereits Istio-Lösungen verwenden, niedriger sind.

Zusammenfassend lässt sich sagen, dass die APISIX-basierte Service-Mesh-Lösung für Entwickler oder Benutzer einfacher zu verwenden und erweiterbar ist und eine hervorragende Leistung sowie eine reichhaltige ökologische Unterstützung bietet. Dank der Fähigkeiten des APISIX-Produkts bietet es auch eine gute Unterstützung auf der Ebene von Plugins und Multi-Protokollen. Wir erwarten, Ihnen die nächste Version der APISIX-basierten Service-Mesh-Lösung Ende des Jahres vorstellen zu können. Bitte bleiben Sie gespannt!

Zukunftsaussichten für die APISIX-basierte Service-Mesh-Lösung

Im Rückblick arbeitet die APISIX-basierte Service-Mesh-Lösung bereits an den zuvor erwähnten Herausforderungen und strebt eine ideale Service-Mesh-Lösung an.

Mit der APISIX-basierten Service-Mesh-Lösung können Sie sehen, dass der Traffic von außen über APISIX Ingress hereinkommt und in der Mitte über APISIX verarbeitet wird. In diesem Prozess handelt APISIX Ingress den Nord-Süd-Traffic ab, während Amesh + Istio den Ost-West-Traffic verarbeitet.

Eine solche Bereitstellungsarchitektur kann geschäftlichen Mehrwert bringen, wie z. B. Kosteneinsparungen und einen einheitlichen Technologie-Stack, bei dem Sie gemeinsame Fähigkeiten, die in traditionellen Gateways verwendet wurden, schnell in Service Mesh replizieren können. Dies ermöglicht eine einheitliche Verwaltung auf Geschäftsebene, wodurch die Kosten kontrolliert und die Erfahrungen im Gateway, Ingress und Service Mesh hochgradig wiederverwendet werden können.

In nachfolgenden Iterationen wird die APISIX-basierte Service-Mesh-Lösung weiter vertieft und folgende geplante Richtungen verfolgen:

• Implementierung von xRPC-Fähigkeiten in Verbindung mit APISIX-Funktionen.
• Native Unterstützung für heterogene Multi-Protokolle.
• Abdeckung aller Arten von Szenarien und Konfigurationen, einschließlich Istio, um die Migrationskosten für Benutzer erheblich zu reduzieren.

Zusammenfassend lässt sich sagen, dass Service Mesh unter den aktuellen Technologietrends zweifellos ein zukünftiger Trend sein wird. Obwohl verschiedene Lösungen noch nicht perfekt sind, ist die Gesamtsituation eine Aufwärtsspirale. Natürlich bewegt sich auch die APISIX-basierte Service-Mesh-Lösung in Richtung der idealen Service-Mesh-Lösung, die sich jeder vorstellt.