Wie APISIX die lokale Bereitstellung der Beeto Social Media Plattform im Nahen Osten erleichtert

Überblick

Herausforderungen

• Monolithische Service-Architektur führt zu hohen Kosten in Wartung und Betrieb
• Komplexe Architekturbereitstellung und Service-Aufrufe sowie mehrere Technologie-Stacks

Ergebnisse

• Vereinheitlichung des Nord-Süd- und Ost-West-Datenverkehrs, Einsparung von Ressourcen und Personalkosten sowie Ermöglichung einer dynamischen und einheitlichen Verwaltung
• Vereinfachung der Bereitstellungsarchitektur, wodurch die Interaktion zwischen dem Gateway und den Benutzern reduziert wird
• Die zahlreichen Erweiterungs-Plugins von APISIX halfen Beeto, die Berechtigungsüberprüfung, Routenverteilung und Gesundheitsprüfungen der Dienste effizient zu verwalten
• APISIX ermöglicht es Beeto, Dienste dynamisch zu starten und zu migrieren, was entwicklerfreundlich ist

Einführung in Beeto

Für den Nahen Osten ist Beeto eine arabische Social-Media-Plattform mit lokalisiertem Produktdesign und technischer Architektur. Sie erreichte Platz 4 der Top-Liste des saudi-arabischen iOS App Stores und übertraf damit den etablierten Social-Media-Giganten Facebook.

Die Internetentwicklung im Nahen Osten ist fortgeschritten, mit einer sehr hohen Penetration aktiver Nutzer in sozialen Netzwerken. Besonders in Saudi-Arabien nutzten 2019 90 % der Menschen das Internet. Die Penetrationsrate aktiver Nutzer in Saudi-Arabien lag 2020 auf Platz 9.

Die Reife des Internetmarktes führte zu beliebten internationalen Social-Software-Anwendungen wie WhatsApp, YouTube und Instagram. Dennoch gibt es keine ähnliche lokal angepasste Social-Software wie Twitter. Daher startete Beeto, mit dem Ziel des „reifen Internets, aber wenig Lokalisierung“ im Nahen Osten, die lokalisierte Produktentwicklung.

Lokalisierung ist für Beeto wichtig

Verglichen mit Feed-Stream-Anwendungen wie Twitter und Facebook hat Beeto einen relativ vollständigen Rahmen für die Bereitstellung seiner Geschäftsarchitektur im Nahen Osten geplant. Zum Beispiel war es darauf ausgerichtet, die Beziehungsinteraktion sozialer Attribute, den Konsum von Inhalten (Text, Video-Livestream, lokale Werbung usw.) sowie verschiedene Geschäfte wie Belohnungen, Abhebungen, Abstimmungen und Lotterien der Finanz- und Dienstleistungskategorien zu erfüllen, und sogar die Anforderungen der Plattformüberwachung und Inhaltsüberprüfung.

Wie bereits erwähnt, erfordert die Reife des Internets im Nahen Osten zwangsläufig hochwertige Produkte. Daher war die erste Version der Geschäftsarchitektur von Beeto ein vollständiges Produkt, das alle Funktionen integrierte, die Mainstream-Social-Software haben sollte. Gleichzeitig ist Beetos Ziel, die größte arabische Social-Plattform und die beste arabische Community im Nahen Osten mit „Lokalisierungsmerkmalen“ zu werden. Um dieses Ziel zu erreichen, analysierte Beeto die Lokalisierungsanforderungen wie folgt.

Herausforderungen in der Architekturgestaltung von Beeto

Die Lokalisierung umfasst die bestehenden lokalen sozialen Anforderungen auf Geschäftsebene und Lokalisierungsoperationen auf technischer Ebene, wie z. B. die Bereitstellung von Diensten und die Datenspeicherung. Wer mit Weibo oder Twitter vertraut ist, weiß, dass Dutzende oder Hunderte von Architektursystemen hinter einem so großen Informationsflussprodukt zusammenarbeiten müssen. Die Herausforderungen in der Architektur von Beeto sind wie folgt.

Monolithische Service-Architektur verursacht hohe Kosten

Die Dienste von Beeto können in acht Teile unterteilt werden, wie unten dargestellt.

Die Umsetzung dieser Geschäfte erfordert eine lokale Bereitstellung im Nahen Osten. Jeder Dienst ist eine separate monolithische Architektur, wenn jedes Geschäft nach Dienst aufgeteilt wird.

Das obige Diagramm der monolithischen Architektur zeigt eine gängige Bereitstellungsarchitektur. Nehmen wir den Feed-Streaming-Dienst von Beeto als Beispiel. Wenn wir die Nachfrage der Benutzer nach dem Durchsuchen des Feed-Streams realisieren wollen, müssen wir den Zugriff über das öffentliche Netzwerk unterstützen, d. h. den Nord-Süd-Datenverkehr; gleichzeitig bietet der Feed-Streaming-Dienst auch einige interne Aufrufe in Form von Themen-Geschäften, d. h. Ost-West-Datenverkehr.

Daher unterstützt der gesamte Dienst externe und interne Aufrufmodi. Nach dem Lastausgleich auf Ebene 7 wird der Benutzerverkehr auf verschiedene Server verteilt, und dann werden verschiedene Speicherressourcen aufgerufen. Der Ost-West-Datenverkehr ist ähnlich. Der Layer-7-Cluster verarbeitet Nord-Süd- und Ost-West-Datenverkehr, Lastausgleich, Authentifizierung und Knotenüberwachung.

Wenn die Dienste mehrerer Geschäfte kombiniert werden, kann die Gesamtarchitektur wie folgt aussehen:

Wie Sie sehen können, existieren Dienste in den Anpassungs-, Geschäfts- und Basisdienstschichten. Die Bereitstellungsarchitektur für jeden dieser Dienste hat die oben erwähnten Details der monolithischen Architektur, daher gibt es mehrere Layer-7-Cluster dazwischen, was ein sehr großes und komplexes Systemarchitektur ist.

Da sich das Beeto-Produkt jedoch in der Startphase befindet und das Produkt im Nahen Osten eingeführt wird, aber das Entwicklungsteam in China sitzt, sind hohe Server- und Wartungskosten erforderlich. Darüber hinaus wird mit zunehmendem Geschäft die Anzahl der monolithischen Dienste zwangsläufig zunehmen, was die Kontrolle sowohl der Kosten als auch der Wartungsoperationen erschwert.

Schwierigkeiten beim Start mehrerer Dienste

Neben der Komplexität der Architekturbereitstellung sind die Aufrufe zwischen den Diensten innerhalb des Clusters ebenfalls sehr komplex.

Der Nord-Süd-Datenverkehr wird auf verschiedene Dienstpools verteilt, und der Ost-West-Datenverkehr ist ebenfalls zwischen verschiedenen Diensten verschachtelt, wobei die Aufrufbeziehungen zwischen diesen Diensten verflochten sind.

Darüber hinaus müssen diese Aufrufbeziehungen von den Diensten verwaltet werden, was zu unklaren Aufrufverfolgungen und schlechter Verwaltung führt.

Neben den komplexen Aufrufbeziehungen gibt es auch Unterschiede in den Technologie-Stacks zwischen den einzelnen Diensten. Zum Beispiel bieten einige Dienste HTTP an, während andere RPC anbieten; in Bezug auf die Entwicklung von Programmiersprachen gibt es eine Mischung aus Java, Go und anderen Programmiersprachen.

Ein solches Multi-Service-Architektursystem wird offensichtlich das Problem hoher Bereitstellungs- und Wartungskosten aufwerfen, wenn es lokal implementiert wird. Darüber hinaus muss Beeto Serverkosten für jeden Satz von Layer-7-Diensten aufwenden, während der Verkehrsunterschied jedes Dienstes zu unausgewogenem Verkehr führt, was zu einer niedrigen Auslastung von Ressourcen wie Servern und Ressourcenverschwendung führt.

Da Beeto sich mehr auf Geschäfts-Upgrades und -Iterationen konzentrierte, wurde die Architektur so gestaltet, dass sie die Wartung und einheitliche Verwaltung erleichtert. Wie kann dieses Ziel erreicht werden?

APISIX-Gateway stärkt die Architektur von Beeto

Um die Probleme der unbequemen Dienstverwaltung und hohen Kosten zu lösen und von der dynamischen Leistung von APISIX mit etcd zu profitieren, die besser den Produktanforderungen von Beeto entspricht, wurde APISIX als API-Gateway in die Architekturbereitstellung eingeführt und ein Gateway-Cluster aufgebaut, wie in der folgenden Abbildung dargestellt.

Das APISIX-Gateway-Cluster bietet Erweiterungstools wie ein Registrierungszentrum, Dienststeuerung, Dienstüberwachung, Protokollweiterleitung und Plugins für alle Dienste. Cluster von Diensten können alle beim Gateway registriert werden, und neue Dienste können direkt über das Gateway hinzugefügt und entfernt werden.

Nach der Einführung des Gateways war die Aufrufverfolgung des gesamten Clusters klarer. Der Nord-Süd-Datenverkehr wird vom Gateway geroutet und weitergeleitet, und der Ost-West-Datenverkehr wird vom Gateway für Dienste im Intranet verarbeitet. Auf der Funktionsebene ist APISIX für die Aufrechterhaltung der Authentifizierung verantwortlich, die von diesem Datenverkehr aufgerufen wird, sodass die Gateway-Schicht die Leistungsunterschiede und Verkehrsunterschiede zwischen den Diensten klar verstehen kann.

Natürlich wird, da das Gateway den gesamten Datenverkehr in dieser Architektur trägt, die Anzahl der Dienste mit der Erweiterung des Dienstes später zunehmen, die Wartungskosten des Gateways werden steigen, und neue Lösungen müssen in Betracht gezogen werden. Im aktuellen Kontext ist die Lösung jedoch immer noch die beste Wahl.

Praktiken nach der Anwendung von APISIX

Apache APISIX, als API-Gateway, kann eine Vielzahl von Richtlinien auf der Gateway-Ebene verarbeiten, wie z. B. Authentifizierung, Dienstweiterleitung und Gesundheitsprüfungen. Daher hat Beeto nach der Einführung von APISIX viele Versuche auf der Geschäftspraxis-Ebene unternommen.

Sicherheit: Authentifizierungs-Plugin

Nord-Süd-Datenverkehr: Cookie

Wie bereits erwähnt, passiert der Zugriffsverkehr der öffentlichen Netzwerkbenutzer das Gateway. Die Authentifizierung der öffentlichen Netzwerkbenutzer ist eine Benutzeranfrage basierend auf der Cookie-Authentifizierung. Wenn ein Benutzer eine Anfrage mit einem Cookie an das Gateway sendet, wird es durch das Authentifizierungs-Plugin überprüft.

Wie im obigen Flussdiagramm gezeigt, führt das Plugin zunächst eine Lokalisierungsvalidierung durch und führt dann eine Authentifizierungsüberprüfung des Remote-Dienstes gemäß der Richtlinie durch. Sobald die Anfrage cookie-geprüft ist, wird sie an den angegebenen Dienst weitergeleitet.

Die Vorteile dieser Vorgehensweise sind zweifach:

1. Die Sicherheit der Cookies der Benutzer wird gewährleistet. Nur die Gateway-Schicht kann während der Ausführung Cookies empfangen und verarbeiten, da Cookies sensible Daten sind. Dies verhindert Sicherheitsprobleme, die durch inkonsistante Geschäftsverarbeitungsregeln verursacht werden, und vermeidet effektiv das Auslaufen von Cookies aufgrund menschlicher Faktoren und Unregelmäßigkeiten.

2. Reduzierung der Komplexität der Cookie-Authentifizierung für Dienste. Cookies müssen lokal oder remote überprüft werden und erfordern gleichzeitige Dienst-Upgrades, wenn Cookies aktualisiert werden. APISIX vereinheitlicht die Verwaltung und Überprüfung, spart die Kosten für die Überprüfung von Geschäftsdiensten und zeigt die Ergebnisse an, die für die Verarbeitung von Geschäftsregeln verwendet werden können, wodurch sichergestellt wird, dass jede Geschäftsverarbeitung stärker auf das Geschäft selbst fokussiert ist.

Ost-West-Datenverkehr: Token

Im folgenden Diagramm ruft Dienst A Dienst B auf. Im Allgemeinen ist eine API alles, was benötigt wird, um sich gegenseitig aufzurufen. Im internen Prozess ist es jedoch notwendig zu verstehen, „wer die API aufgerufen hat, wie sie aufgerufen wurde, ob es notwendig ist, die Berechtigung zu überprüfen, und ob es notwendig ist, den Forscher zu kontrollieren“, und so weiter, was intern behandelt werden muss.

Mit dem APISIX-Gateway wird der Prozess viel einfacher. Der gegenseitige Aufruf aller internen Dienste muss nur beim Auth-Authentifizierungsdienst registriert werden, und jedem Dienst wird ein App-Schlüssel ausgestellt, der die Identitäts-ID des Dienstes angibt. Gleichzeitig wird der gegenseitige Aufruf interner Dienste auch das Gateway passieren. Nachdem der Token durch das Gateway getragen wurde, wird der Token durch die Token-Plugins authentifiziert. Nach der Authentifizierung wird das Authentifizierungsmerkmal an den aufgerufenen Dienst weitergegeben. Während des gesamten Prozesses führt das Dienstsystem eine Authentifizierungsregistrierung durch und vollendet einen gegenseitigen Aufruf.

Dank der Token-Regel des App-Schlüssels kann der obige Vorgang leicht auf die Quelle des Aufrufs zurückverfolgt werden, was für die Fehlerbehebung und Berechtigungskontrolle verwendet werden kann und auch eine effektive Kontrolle über illegale Aufrufe bietet. Daher besteht der Vorteil der einheitlichen Authentifizierung darin, dass sie, ob für Nord-Süd- oder Ost-West-Datenverkehr, die Sicherheit und Einheitlichkeit des Clusters gewährleistet, was bei der Problemverfolgung und Aufrufkontrolle sehr hilfreich ist.

Skalierbarkeit: Zustandslose Dienstausweitung und -migration

Die gesamte Bereitstellungsarchitektur des Clusters von Beeto von oben nach unten besteht aus: APISIX-Gateway-Clustern - Geschäftsdienstclustern zustandsloser Dienste - Datenzentrumsclustern zustandsbehafteter Dienste. Bei der lokalen Bereitstellung im Nahen Osten werden sie alle auf großen Cloud-Clustern bereitgestellt. Je nach der Cloud-Abdeckung im Nahen Osten und den Cloud-Anbietern in verschiedenen Regionen ist es notwendig, die Erweiterung und Migration von Cloud-Diensten bei der Bereitstellung von Diensten zu berücksichtigen.

Im Migrationsprozess konzentrierte sich Beeto auf die Migration zustandsloser Dienste. Es ist ungeeignet für dynamische Anpassungen aufgrund der begrenzten Migrationskosten des Datenzentrums; die meisten Anfragen werden von zustandslosen Diensten getragen, daher ist es sehr wichtig, sicherzustellen, dass der zustandslose Dienst eine gute Skalierbarkeit hat.

In der Architektur von Beeto spiegelt sich die Dienstskalierbarkeit hauptsächlich in zwei Aspekten wider: Skalierbarkeit des monolithischen Dienstes und Skalierbarkeit des gesamten Clusters. Zum Beispiel, wenn ein monolithischer Dienst keine Ressourcen mehr hat und erweitert werden muss, können APISIX-Gateways dynamisch Knoten für die Skalierung hinzufügen. Ebenso kann in Cross-Cluster- oder Cross-Cloud-Situationen die Clusterskalierbarkeit durch die Bereitstellung mehrerer APISIX-Gateways und die Migration verschiedener Dienste auf verschiedene Gateway-Knoten erreicht werden.

Für Geschäftsdienste bleibt die Gesamtarchitektur unverändert, sodass dynamische Erweiterungen und Kontraktionen verschiedener Dienste und Dienstmigrationen auf der Gateway-Ebene realisiert werden können. Der gesamte Prozess hat einen klaren Plan und ein klares Ziel, und sobald Änderungen beteiligt sind, wird die Gesamtarchitektur nicht instabil.

Funktionale Erweiterbarkeit: Dynamische Weiterleitung von Diensten

Neben diesen bekannten allgemeinen Gateway-Szenarien, die oben erwähnt wurden, bietet Apache APISIX auch erhebliche Unterstützung für Beeto in Bezug auf die dynamische Weiterleitung von Diensten.

Wer mit der UI und dem Backend von APPs vertraut ist, weiß, dass verschiedene Produktseiten von verschiedenen Diensten bereitgestellt werden. Eine Seite besteht aus verschiedenen Modulen, deren Inhalt alle von der API gesendet wird. Welche Daten die API an das Modul sendet, wird auf den Endgeräten gerendert. Dies ist eine gemeinsame Client-seitige Rendering-Spezifikation, um den Client-seitigen Rendering-Prozess generischer und die Geschäftsverarbeitung flexibler zu machen.

Bei der Implementierung von PageA in der obigen Abbildung ruft der Client beispielsweise die API von Dienst A auf, sendet die Daten des entsprechenden Moduls und vollendet das Rendering von PageA. Diese Operation führt zu Problemen, dass der Client jede Seite und API zu jedem Dienst pflegen muss. Wenn sich der Inhalt ändert, muss dies durch Veröffentlichung gelöst werden, was in Bezug auf Bedienbarkeit und Effizienz sehr unfreundlich ist.

Die Lösung für das obige Problem besteht darin, eine einheitliche Verteilung von Diensten in der Gesamtarchitektur zu implementieren. Der Client fordert zuerst die API-Adresse an, leitet alle Anfragen dieses Typs an eine API weiter, verarbeitet die Anfrageparameter und URL-Regeln für die URL-Adresse auf der Gateway-Ebene und führt dann das Verteilungs-Plugin ein. Schließlich werden die geparsten Anfragen gemäß den Konfigurationsregeln direkt an den angegebenen Dienst auf der Gateway-Ebene weitergeleitet.

Der Client muss während des gesamten Prozesses nur das Rendering-Spezifikation bestimmen, nicht die Quelle der Daten. Die Gateway-Ebene übernimmt die Verantwortung für die Dienstverteilung und leitet den Datenverkehr direkt weiter. Die Plugin-Konfigurationsdatei in APISIX kann in Echtzeit dynamisch aktualisiert werden, und die Weiterleitungsregeln können dynamisch angepasst werden, was sehr flexibel ist. Tatsächlich können für Anwendungen wie die BFF (Backend for Frontend)-Architektur solche Anforderungen auf der Gateway-Ebene gelöst werden.

Fazit

Dieser Artikel präsentiert die Anwendungspraktiken der Einführung von Apache APISIX durch Beeto aus den Perspektiven des Design-Denkens und der Geschäfte.

APISIX unterstützte Beeto bei der Kontrolle der Ressourcenkosten und mehrerer Geschäftsproduktlinien und half Beeto, die lokalisierte Bereitstellung, einheitliche Verwaltung und Betrieb sowie wartungsfreundliche Szenarien im Nahen Osten zu realisieren.