Wir befinden uns in der Anfangsphase der Entwicklung einer neuen Webanwendung und möchten die Amazon Cloud-Plattform nutzen. Wir haben jedoch die Wahl, Webanwendungen mit Java spring framework oder einer anderen Programmiersprache / Framework zu entwickeln. Die mehrseitige Anwendung ist nicht zustandslos, d. H. Die Anwendung muss die Benutzersitzung nach einmal eingeloggten Transaktionen verfolgen. Sobald alle erforderlichen Informationen vom Benutzer über mehrere Seiten erfasst sind, wird die Transaktion an die Datenbank übergeben.
Es besteht jedoch die Möglichkeit, dass wir für diese Anwendung AWS lambda -Dienste verwenden. Wäre es eine richtige Entscheidung, eine Webanwendung mit den oben genannten Anforderungen mit AWS Lambda zu entwickeln (in der Gewissheit, dass der Lambda-Service sessionless ist)?
Ihre Frage ist nicht spezifisch für Lambda. Der einzige Fall, in dem die Sitzungsverwaltung einfach ist (z. B. kann durch einen Speicher oder einen dateibasierten Speicher gelöst werden), ist in einer Einzelserverumgebung. Das ist wahrscheinlich, wo du herkommst.
Sobald Sie anfangen horizontal zu skalieren (setzen Sie mehr Server in den Mix, anstatt einfach mehr RAM / CPU in den Server zu packen), benötigen Sie einen zentralen Speicher für Sitzungen (und auch Cache). Dies gilt auch, wenn Sie Andocker oder EC2- oder sogar Metallserver hinter einem Load Balancer auswählen.
Dies liegt daran, dass Sie nie erkennen können, ob die nächste Anfrage von demselben Benutzer in derselben Umgebung landen wird. Das gilt natürlich auch für Lambda. Es gibt jedoch eine Problemumgehung: Wenn Sie einen Loadbalancer verwenden, um "sticky sessions" zu verwenden, werden alle Anfragen desselben Benutzers an dieselbe Maschine weitergeleitet, siehe dieses AWS-Dokument zur Sitzungsverwaltung . Aber sticky Sitzung ist immer suboptimal (z. B. würde das Herunterskalieren bedeuten, Sitzungen zu zerstören) und für Lambda sind sticky Sitzungen nicht möglich afaik.
Die wirkliche Lösung, wie die anderen Antworten hier andeuten, beinhaltet den zentralen Sitzungsspeicher über Elasticache. Ein Zitat aus dem obigen Link:
Um die Skalierbarkeit zu erreichen und einen gemeinsamen Datenspeicher für Sitzungen bereitzustellen, auf die von jedem einzelnen Webserver aus zugegriffen werden kann, können Sie die HTTP-Sitzungen von den Webservern selbst abstrahieren. Eine gängige Lösung hierfür ist die Verwendung eines speicherinternen Schlüssel / Wertspeichers wie Redis und Memcached.
Möglicherweise haben Sie eine statusbehaftete Anwendung, die auf Lambda ausgeführt wird, wenn Sie einen externen permanenten Speicher für Ihre Sitzungsdaten verwenden können.
Sie können DynamoDB oder Elasticache zum Beispiel als temporären Speicher für Ihre Sitzungsdaten verwenden und sobald alle erforderlichen Daten bereit sind, können Sie sie dauerhaft in Ihren Datenbankabfragen persistieren.
Bei der Entscheidung, ob eine serverlose Architektur für Ihre Anwendung geeignet ist, ist eine Menge zu beachten. Ich glaube nicht, dass es eine "one size fits all" Antwort auf diese Frage gibt.
Die Verwendung von Lambda anstelle von beispielsweise einem Servlet-Container führt tatsächlich zu einem gewissen Entwicklungsaufwand in Bezug auf die Sitzungspersistenz. Ich denke jedoch nicht, dass dies unbedingt eine primäre Überlegung sein sollte, wenn Sie sich fragen, ob eine serverlose Architektur für Ihre Anwendung geeignet ist. Bevor ich mir Gedanken darüber mache, wie die Sitzung funktionieren wird, frage ich mich:
Wenn Ihre Anwendung wirklich für eine serverlose Architektur geeignet ist, ist der Aufwand, herauszufinden, wie eine Sitzung wahrscheinlich beibehalten wird, nicht so kostspielig, um ein Deal Breaker zu sein.
Nach meiner Erfahrung haben Entwickler (einschließlich mir selbst) viel mehr mit Paradigmenwechsel zu Microservices und (oft) clientseitigem Rendering zu tun, als mit den Besonderheiten, wie die Session implementiert oder fortgeführt wird.
Tags und Links web-applications aws-lambda