Autor: Zen und die Kunst der Computerprogrammierung
1. Einleitung
WebSocket (vollständiger Name: Web Sockets) ist ein Protokoll für die bidirektionale Kommunikation über eine einzelne TCP-Verbindung, das es dem Server ermöglicht, Daten aktiv an den Client zu übertragen. Mit dem Aufkommen von Cloud Computing, Big Data, Internet der Dinge, mobilem Internet und anderen Technologien gibt es immer mehr Anwendungen, die auf WebSocket basieren, wie z. B. Chatrooms, Videokonferenzen, Smart Terminals, Live-Übertragungen von Spielen, Aktienhandelssimulationen und andere Szenarien.
Die traditionelle HTTP-basierte Serverarchitektur erfordert den Kauf von Lastausgleichsgeräten oder Frameworks zur Unterstützung von WebSocket, während die serverlose Architektur keine so komplexe Architektur erfordert. In diesem Artikel wird erläutert, wie Sie mithilfe der serverlosen Architektur ein Nachrichtenverarbeitungssystem erstellen, das die WebSocket-Kommunikation unterstützt.
Der Hauptinhalt des Artikels ist wie folgt:
- Was ist serverlos?
- Warum eine serverlose Architektur verwenden?
- Vor- und Nachteile der serverlosen Architektur
- Die Kombination von WebSocket und Serverless in der Praxis
- Anhang FAQ
- Quellcode-Repository und Links zu Beispielcodes
1.Was ist serverlos?
Serverlose Architektur ist ein Programmiermodell, das Anwendungen erstellt, ohne sich um die Serverinfrastruktur zu kümmern. Entwickler müssen sich lediglich auf die Geschäftslogik konzentrieren und Anwendungsfunktionen über API-Aufrufe, Ereignisauslöser oder andere Formen der direkten Ausführung implementieren, die von Tools oder Plattformen bereitgestellt werden. Serverlose Architekturen sind weit verbreitet, beispielsweise Amazon AWS Lambda, Microsoft Azure Functions, Google Cloud Functions usw.
Eine serverlose Architektur kann nicht nur die Betriebs- und Wartungskosten senken, sondern Benutzern auch dabei helfen, ihre Anwendungen schnell zu starten, da sie die Komplexität von Hardwareinvestitionen, Serververwaltung und -konfiguration eliminiert. Eine serverlose Architektur trägt dazu bei, die Entwicklungs- und Betriebskosten zu senken, sodass Unternehmen eine schnelle Iteration erreichen, Lieferzyklen verkürzen und den Produktwert steigern können.
2. Warum eine serverlose Architektur verwenden?
Da die Serverless-Architektur keine Serververwaltung erfordert, ist es sehr einfach, Anwendungen bereitzustellen und Ressourcen zu erweitern. Wenn der Anwendungsverkehr auf ein bestimmtes Niveau ansteigt, kann die Anzahl der Server erhöht werden, um mehr Anfragen zu bearbeiten; wenn der Verkehr abnimmt, kann die Anzahl der Server auch reduziert werden, um Ressourcen zu sparen. Für Startups, persönliche Projekte und kleine Teams können Anwendungen sehr bequem bereitgestellt werden. Gleichzeitig kann sich die serverlose Architektur gut an verschiedene Änderungen anpassen und Benutzern Kosten wie Server und Bandbreite sparen.
Obwohl die serverlose Architektur einfach und benutzerfreundlich ist, weist sie auch einige Einschränkungen auf. Erstens kann die serverlose Architektur serverseitige Funktionen nicht vollständig ersetzen. Wenn Sie beispielsweise mit langen Verbindungen, Anrufen zwischen Diensten usw. zu tun haben, müssen Sie immer noch Hintergrunddienste schreiben, um Aufgaben zu erledigen. Zweitens muss die serverlose Architektur auf Plug-Ins oder Dienste von Drittherstellern angewiesen sein, was ebenfalls problematisch ist.
In tatsächlichen Anwendungen können je nach Bedarf unterschiedliche Architekturmuster ausgewählt werden, z. B. Microservice-Architektur, Containerarchitektur usw.
3. Vor- und Nachteile einer serverlosen Architektur
3.1 Vorteile
- Die serverlose Pay-as-you-go-Architektur ermöglicht es Unternehmen, nur für die von ihnen genutzten Ressourcen zu bezahlen, was die Kosten erheblich senkt. Darüber hinaus müssen Benutzer nur für die Laufzeit der Funktion bezahlen, nicht für die Laufzeit jedes einzelnen Servers.
- Automatische Skalierung In Zeiten mit hohem Datenverkehr kann die serverlose Architektur automatisch erweitert werden, um auf Benutzeranfragen zu reagieren, und in Zeiten mit geringem Datenverkehr automatisch verkleinert werden. Dadurch können effektiv Ressourcen gespart und die Effizienz verbessert werden.
- Benutzer einer serverlosen Umgebung müssen lediglich den Quellcode hochladen, und die serverlose Architekturplattform kann automatisch Ressourcen für die Ausführung von Funktionen zuweisen. Bei dieser Architektur besteht keine Notwendigkeit, Server und Serverkonfigurationen zu verwalten, und es kommt zu keiner Verschwendung von Ressourcen.
- Flexibel und elastisch Da die Plattform nicht zu viele Ressourcen beansprucht, kann die Ressourcenzuteilung dynamisch an die Anwendungsnutzung angepasst werden. Dadurch ist auch eine elastische Skalierbarkeit gewährleistet.
- Effizienter Betrieb Da keine Serververwaltung erforderlich ist, kann die serverlose Architektur hochgradig gleichzeitige Anforderungen in kurzer Zeit erledigen, was effizienter als herkömmliche Architekturen ist.
- Reduzierung der Betriebskosten: Es besteht keine Notwendigkeit, Server zu warten oder sich Gedanken über Ausfälle von Hardwaregeräten zu machen, wodurch die Betriebskosten gesenkt werden.
- Pay-as-you-go-Nutzungsgebühren können basierend auf der Laufzeit der Funktion berechnet werden, was flexibler ist als das Festgebührenmodell traditioneller Architektur.
3.2 Nachteile
- Latenz Aufgrund der Verwendung einer asynchronen Architektur kann es bei Funktionsaufrufen zu Verzögerungen kommen. Dies kann jedoch durch gleichzeitige Verarbeitung gemildert werden.
- Verfügbarkeit Tritt in einer Funktion ein Fehler auf, kann dies Auswirkungen auf die Verfügbarkeit des gesamten Dienstes haben.
- Die laufenden Umgebungen der Isolationsfunktionen sind unabhängig voneinander und können nicht auf gemeinsam genutzte Ressourcen zugreifen, was zu Problemen bei der Datensicherheit führen kann.
- Ausführungsgeschwindigkeit Aufgrund der Verwendung einer asynchronen Architektur kann die Ausführungsgeschwindigkeit der Funktion begrenzt sein. Wenn die Ausführung einer Funktion lange dauert, müssen die Ausführungsergebnisse möglicherweise lange warten.
4. WebSocket und Serverless in der Praxis kombinieren
Basierend auf der oben erwähnten serverlosen Architektur und in Kombination mit der WebSocket-Technologie kann ein Nachrichtenverarbeitungssystem aufgebaut werden, das die WebSocket-Kommunikation unterstützt. Dieses System kann Front-End-WebSocket-Anfragen empfangen, den Nachrichteninhalt analysieren und die entsprechende Back-End-Dienstschnittstelle zur Verarbeitung aufrufen.
Das Architekturdiagramm sieht wie folgt aus:
- Das Frontend sendet eine WebSocket-Anfrage an die WebSocket-API, um eine Verbindung herzustellen.
- Die WebSocket-API ruft die Serverless-Plattform auf und fordert die Einrichtung eines virtuellen Netzwerkkanals für den Front-End-WebSocket an.
- Die Plattform erstellt im Hintergrund einen virtuellen WebSocket-Netzwerkkanal.
- Das Front-End sendet eine Nachricht an die WebSocket-API und die API leitet die Nachricht an die Nachrichtenwarteschlange des Servers weiter.
- Die Nachrichtenwarteschlange auf der Serverseite ruft die Nachricht ab und ruft die entsprechende Hintergrunddienstschnittstelle auf, um die Nachricht zu verarbeiten.
- Die Hintergrunddienstschnittstelle des Servers beendet die Verarbeitung der Nachricht und gibt das Ergebnis an die Nachrichtenwarteschlange zurück.
- Die Nachrichtenwarteschlange leitet die Ergebnisse an das Frontend weiter.
- Die WebSocket-API leitet Nachrichten an das Frontend weiter.
Zu den Vorteilen der Verwendung einer serverlosen Architektur zur Implementierung der WebSocket-Kommunikation gehören:
- Benutzer müssen keine Server im Voraus kaufen und müssen sich nur auf die Implementierung der Geschäftslogik konzentrieren.
- Die Plattform kann ihre Kapazität automatisch erweitern und plötzlichen Datenverkehr schnell bewältigen.
- Der Nachrichtenverarbeitungscode auf der Serverseite kann stark optimiert werden, um Probleme wie Netzwerküberlastung zu vermeiden.
- Benutzer müssen sich keine Gedanken über Probleme wie die zugrunde liegende Netzwerkstruktur und Bandbreite machen.
5. FAQ
5.1 Treten domänenübergreifende Probleme auf?
Serverlose Architekturplattformen bieten im Allgemeinen Zugriff auf unterschiedliche Domänennamen, sodass WebSocket-Anfragen unter unterschiedlichen Domänennamen als unterschiedliche Anfragen betrachtet werden, was bedeutet, dass sich auch das Feld „Ursprung“ im Anforderungsheader ändert. Aus Sicherheitsgründen blockieren Browser standardmäßig domänenübergreifende Anfragen, sodass die Verbindung nicht erfolgreich hergestellt werden kann. Allerdings können domänenübergreifende Probleme durch einige domänenübergreifende Lösungen wie CORS (Cross Origin Resource Sharing) gelöst werden.
5.2 Muss ich Rollenberechtigungen für jede Funktion separat konfigurieren?
In der serverlosen Architektur verfügt jede Funktion über eine eigene unabhängige Ausführungsumgebung, und IAM-Rollen (Identity and Access Management) können zur Steuerung von Zugriffsberechtigungen verwendet werden. Daher ist es nicht erforderlich, Berechtigungen für jede Funktion einzeln zu konfigurieren.
5.3 Was sind die Gründe für das Scheitern einer Anfrage?
- Die WebSocket-API wird nicht erstellt. Zum Erstellen einer WebSocket-API ist die Verwendung von AWS API Gateway erforderlich. Andernfalls müssen Sie zusätzliche Cloud-Ressourcen erwerben.
- Keine Berechtigung für den Zugriff auf die WebSocket-API. Es ist notwendig, die entsprechende Aufrufmethode auf dem API Gateway festzulegen und die entsprechenden Berechtigungen zu erteilen.
- Es liegt ein Problem mit dem Hintergrunddienst auf der Serverseite vor. Überprüfen Sie, ob der Servercode korrekt ist und die Ausgabeinformationen des Serverprotokolls.
- Zeitüberschreitung beim WebSocket-API-Aufruf. Solche Probleme können durch Netzwerkschwankungen und andere Gründe verursacht werden. Sie können es erneut versuchen oder auf die neueste Version der Software aktualisieren.
5.4 Wird es als Verkehr gezählt?
Bei der Verwendung von WebSocket wird die Anfrage des Benutzers nicht als Datenverkehr gezählt, aber das Herstellen und Schließen einer WebSocket-Verbindung wird als Datenverkehr gezählt.
5.5 Wie überwache ich den WebSocket-Status?
Sie können AWS CloudWatch verwenden, um den Status von WebSocket zu überwachen, einschließlich der Anzahl der Verbindungen, der Verbindungsdauer usw.