Es sieht so aus, als ob das Wort „langlebig“ ein aufkommender Begriff in der Welt von Serverless ist. Soweit ich das verstehe, ermöglicht es Zustände an Orten, an denen man sie normalerweise nicht erwarten würde. Zum Beispiel rufen Sie eine Cloud-Funktion auf und führen JavaScript aus… es sei denn, Sie lassen sie Daten von woanders abrufen, hat sie keine Informationen außer ihrem eigenen Code. Sie erinnert sich nicht daran, was beim letzten Ausführen passiert ist. Sie ist jedes Mal ein unbeschriebenes Blatt. Aber nehmen wir an, Ihre Cloud-Funktion war eine Klasse, und wenn Sie diese Klasse initialisiert haben, haben Sie eine ID erhalten, und über diese ID könnten Sie mit **genau dieser Instanz dieser Klasse** sprechen, wann immer Sie wollten. Diese Instanz bleibt so lange bestehen, wie Sie sie brauchen. Sie ist *langlebig*.
Cloudflare hat ein Feature namens Durable Objects veröffentlicht.
… wir haben uns auf „Unique Durable Objects“ oder kurz „Durable Objects“ geeinigt. Lassen Sie mich erklären, was sie sind, indem ich das aufschlüssle.
• **Objects:** Durable Objects sind Objekte im Sinne der objektorientierten Programmierung. Ein Durable Object ist eine Instanz einer Klasse — buchstäblich, eine Klassendefinition, geschrieben in JavaScript (oder Ihrer bevorzugten Sprache). Die Klasse hat Methoden, die ihre öffentliche Schnittstelle definieren. Ein Objekt ist eine Instanz dieser Klasse und kombiniert den Code mit einem privaten Zustand.
• **Unique:** Jedes Objekt hat eine global eindeutige Kennung. Dieses Objekt existiert zu jeder Zeit nur an einem Ort auf der ganzen Welt. Jeder Worker, der irgendwo auf der Welt läuft und die ID des Objekts kennt, kann Nachrichten an es senden. Alle diese Nachrichten werden an denselben Ort geliefert.
• **Durable:** Im Gegensatz zu einem normalen Objekt in JavaScript können Durable Objects einen persistenten Zustand auf der Festplatte speichern. Der langlebige Zustand jedes Objekts ist privat für dieses Objekt, was nicht nur bedeutet, dass der Zugriff auf den Speicher schnell ist, sondern das Objekt kann sogar sicher eine konsistente Kopie des Zustands im Speicher aufrechterhalten und ihn mit null Latenz bearbeiten. Das In-Memory-Objekt wird im Leerlauf heruntergefahren und später bei Bedarf neu erstellt.
Ziemlich cool. Die Echtzeit-Aspekte sind extrem überzeugend.
Azure verwendet ebenfalls „langlebig“ in seinen Büros durch Durable Functions. Ein Teil dieses Angebots sind Entity Functions.
Entitäten verhalten sich ein wenig wie winzige Dienste, die über Nachrichten kommunizieren. Jede Entität hat eine eindeutige Identität und einen internen Zustand (falls vorhanden). Wie Dienste oder Objekte führen Entitäten Operationen aus, wenn sie dazu aufgefordert werden. Wenn eine Operation ausgeführt wird, kann sie den internen Zustand der Entität aktualisieren. Sie kann auch externe Dienste aufrufen und auf eine Antwort warten. Entitäten kommunizieren mit anderen Entitäten, Orchestrierungen und Clients über Nachrichten, die implizit über zuverlässige Warteschlangen gesendet werden.
Die Dokumentation ist für mich etwas kniffliger zu verstehen (ich glaube, sie richtet sich an Leute, die sich mehr damit beschäftigen als ich), aber das Konzept klingt dem von Cloudflare sehr ähnlich. Entitäten haben IDs, über die man auf sie zugreift. Sie sind persistent und können für dieselben Echtzeit-Sachen verwendet werden, wie z. B. die Anzeige des Zustands/Punktestands eines Videospiels für jeden, der verbunden ist.