Im vorherigen Artikel haben wir die Funktionsweise von Serverless unter der Haube untersucht. Im Wesentlichen nutzt Serverless geschichtetes Scheduling und schnelle Kaltstarts, sodass es auf Null herunterskalieren kann, wenn keine Ereignisse verarbeitet werden. Es ähnelt einer sprachaktivierten Lampe, die leuchtet, wenn jemand anwesend ist, und sich automatisch ausschaltet, wenn der Raum leer ist.
Nachdem Sie die Grundlagen verstanden haben, fragen Sie sich vielleicht, welche praktischen Anwendungen diese beeindruckende Technologie hat. Heute werden wir uns mit den Anwendungsfällen von Serverless befassen. Voraussetzung für das Verständnis seiner Anwendungen ist jedoch das Verständnis seines Prozessmodells, ein Konzept, das ebenso entscheidend ist wie Kaltstarts.
Das Serverless-Prozessmodell
Lassen Sie uns den Serverless-Kaltstartprozess aus der letzten Sitzung noch einmal durchgehen. Denken Sie daran, dass der Cloud-Anbieter die Container- und Laufzeitvorbereitungsphasen verwaltet, sodass wir uns ausschließlich auf die Funktionsausführung konzentrieren können. Im Serverless-Bereich wird die Funktionsausführung von einem „Function Service“ übernommen. Wenn der Funktionstrigger das Eintreffen eines „Ereignisses“ signalisiert, erstellt der Function Service nach Bedarf Funktionsinstanzen und führt die entsprechenden Funktionen aus. Sobald eine Funktion abgeschlossen ist, verabschiedet sich die zugehörige Instanz, sodass die Serverless-Anwendung auf Null herunterskalieren und in einen Energiesparmodus wechseln kann.
Nun fragen Sie sich vielleicht, ob es möglich ist, eine Instanz nach der Funktionsausführung am Leben zu erhalten, anstatt sie zu beenden, damit sie auf den nächsten Funktionsaufruf warten kann. Dies würde den Kaltstart-Overhead jedes Mal eliminieren und zu schnelleren Antwortzeiten führen.
Tatsächlich sieht Serverless solche Szenarien vor. Aus der Sicht des Prozesses, der die Funktionsinstanz ausführt, gibt es daher zwei Modelle:
- Run-to-Completion: In diesem Modell führt die Funktionsinstanz die Funktion aus und beendet sich sofort. Dies stellt die reinste Form der Serverless-Nutzung dar.
- Persistenter Prozess: Hier endet die Funktionsinstanz nach der Funktionsausführung nicht. Stattdessen kehrt sie zurück und wartet geduldig auf den nächsten Funktionsaufruf. Beachten Sie, dass der Cloud-Anbieter die Funktionsinstanz auch in diesem Modell irgendwann zerstört, wenn für einen bestimmten Zeitraum kein Ereignis sie auslöst.
Datenorchestrierung
Die meisten Entwickler sind mit dem MVC-Muster (Model-View-Controller) vertraut, einem weit verbreiteten und erfolgreichen Designparadigma. Der Aufstieg von Frontend-MVVM-Frameworks hat jedoch die View-Schicht nach vorne geschoben, was zu SPAs (Single Page Applications) geführt hat. Im Gegensatz dazu sind die Control- und Model-Schichten des Backends nach unten gerückt, was zu serviceorientierten Backend-Anwendungen geführt hat.
Diese Verschiebung hat zu einer gründlicheren Entkopplung von Frontend und Backend geführt. Die Frontend-Entwicklung kann unabhängig voranschreiten, indem sie sich auf Mock-Datenschnittstellen stützt, während sich Backend-Teams auf die Entwicklung von Datenschnittstellen konzentrieren können. Diese Trennung führt jedoch zu einer Daten-Gateway-Schicht mit hohem Netzwerk-I/O.
Node.js hat mit seinem asynchronen, nicht-blockierenden Charakter und der Affinität von JavaScript zu Frontend-Entwicklern natürlich die Rolle der Daten-Gateway-Schicht übernommen. Dies führte zur Entstehung der Node.js BFF-Schicht (Backend For Frontend), die Backend-Daten und -Schnittstellen orchestriert und sie in Datenstrukturen umwandelt, die für das Frontend geeignet sind.
Die BFF-Schicht fungiert als Vermittler zwischen Frontend und Backend. Unverarbeitete Daten, oft als Rohdaten oder Metadaten bezeichnet, sind für Endbenutzer praktisch unlesbar. Daher müssen wir relevante Daten kombinieren und verarbeiten, um einen Mehrwert zu schaffen und sie sinnvoll zu machen. Dieser Prozess des Kombinierens und Verarbeitens wird als Datenorchestrierung bezeichnet.
Traditionell war die Verwaltung von Node.js-Anwendungen für die BFF-Schicht ressourcenintensiv und erforderte virtuelle Maschinen oder PaaS-Plattformen. Da die BFF-Schicht jedoch hauptsächlich zustandslose Datenorchestrierung durchführt, können wir die Node.js-Anwendung nahtlos durch Serverless mit dem Run-to-Completion-Modell ersetzen. Dies ist der Kern des zunehmend populären Begriffs SFF (Serverless For Frontend).
Nachdem wir die Entwicklung von BFF zu SFF verstanden haben, wollen wir den neuen Anforderungsablauf nachvollziehen. Wenn das Frontend eine Datenanforderung initiiert, aktiviert der Funktionstrigger unseren Function Service. Unsere Funktion startet dann, ruft die Metadatenschnittstelle des Backends auf, verarbeitet die zurückgegebenen Metadaten in das vom Frontend benötigte Format, und schließlich kann unsere Serverless-Funktion eine wohlverdiente Pause einlegen.
Serviceorchestrierung
Serviceorchestrierung ähnelt der Datenorchestrierung, wobei der Hauptunterschied darin besteht, dass sie sich auf das Kombinieren und Verarbeiten verschiedener vom Cloud-Anbieter bereitgestellter Dienste konzentriert. Obwohl das Konzept älter ist als Serverless, wurde seine traditionelle Implementierung durch die SDK-Sprachversionen eingeschränkt, die von den Diensten unterstützt wurden. Typischerweise griffen wir auf YAML-Dateien oder Befehlszeilenschnittstellen zurück, um Dienste zu orchestrieren. Die Nutzung dieser Dienste oder APIs erforderte das Finden entsprechender SDKs in unserer bevorzugten Programmiersprache, das Laden in unseren Code und die Verwendung von geheimen Schlüsseln, um SDK-Methoden zur Orchestrierung aufzurufen. Ähnlich wie bei der Datenorchestrierung waren die Backend-Operationen und Bereitstellungskosten erheblich, und das Fehlen eines SDK erforderte eine manuelle Implementierung basierend auf den Schnittstellen oder Protokollen der Plattform.
Serverless erweitert die Grenzen der SDK-Nutzung. Stellen Sie sich zum Beispiel einen Webdienst vor, der Verifizierungscodes per E-Mail versenden muss. Dies können wir mit einer Run-to-Completion-Serverless-Funktion erreichen, die das SDK des Cloud-Anbieters zum Versenden von E-Mails verwendet. Gleichzeitig kann eine persistente Serverless-Funktion zufällige Zeichenfolgen-Verifizierungscodes generieren, speichern und die E-Mail-versendende Serverless-Funktion auslösen, um die Codes an die Postfächer der Benutzer zu liefern. Bei der Verifizierung können wir die persistente Serverless-Funktion erneut aufrufen, um die Codes zu validieren.
Ein bemerkenswerter Vorteil von Serverless ist seine Sprachunabhängigkeit. Dies befreit Entwicklungsteams von der Beschränkung auf eine einzige Sprache und ermöglicht es ihnen, die Stärken von Java, PHP, Python, Node.js und anderen zu nutzen, um gemeinsam komplexe Anwendungen zu entwickeln.
Die offene Natur der Serverless-Serviceorchestrierung hat bei Cloud-Anbietern große Aufmerksamkeit erregt. Sie ermöglicht die Erstellung vielfältiger und komplexer Serviceorchestrierungsszenarien, während sie gleichzeitig sprachunabhängig bleibt, und erweitert die Anwendungsfälle verschiedener Cloud-Dienste erheblich. Dies erfordert jedoch auch, dass Entwickler sich mit der Palette der Dienste ihres gewählten Cloud-Anbieters vertraut machen.
Fazit
- Es gibt zwei Arten von Prozessmodellen für Serverless: den residenten Prozesstyp und den Verwenden-und-Zerstören-Typ. Der residente Prozesstyp ist darauf ausgelegt, sich an die traditionelle MVC-Architektur anzupassen und wirkt nicht natürlich; Wenn Sie ab jetzt mit Serverless beginnen, würde ich definitiv das Verwenden-und-Zerstören-Modell empfehlen, das die Vorteile von Serverless maximieren kann.
- Rückblickend habe ich das durch die Trennung von Frontend und Backend entwickelte BFF sortiert, das dann durch SFF ersetzt werden kann. Ob es sich um interne Schnittstellenorchestrierung oder externe Datenorchestrierung handelt, Serverless kann einen großen Vorteil bieten.
- Über die Datenorchestrierung hinaus können wir die Fähigkeiten von Serverless und Cloud-Dienstanbietern nutzen, um Serviceorchestrierung zu erreichen, leistungsfähigere zusammengesetzte Serviceszenarien zu schaffen und unsere Forschungs- und Entwicklungseffizienz zu steigern.
Novita AI ist die All-in-One-Cloud-Plattform, die Ihre KI-Ambitionen unterstützt. Integrierte APIs, Serverless, GPU-Instanz – die kosteneffizienten Tools, die Sie brauchen. Verzichten Sie auf Infrastruktur, starten Sie kostenlos und machen Sie Ihre KI-Vision zur Realität.
Empfohlene Lektüre
Die Revolution enthüllen: Die Welt des Serverless Computing erkunden
