Zustandsbehaftete und zustandslose Anwendungen – Best Practices und Vorteile

Von Gursimran Singh|Insights|06,Oct,2020

Was sind zustandsbehaftete und zustandslose Anwendungen?

Eine zustandsbehaftete Anwendung merkt sich bestimmte Details eines Benutzers wie Profil, Einstellungen und Benutzeraktionen. Diese Informationen werden als „Status“ eines Systems betrachtet.
Zum Beispiel Ihr Einkaufswagen bei der Nutzung einer beliebigen Website in der Cloud. Jedes Mal, wenn Sie einen Artikel auswählen und in den Warenkorb legen, fügen Sie ihn mit den zuvor hinzugefügten Artikeln zusammen und navigieren schließlich zur Kassenseite.

Eine zustandslose Anwendung oder ein zustandsloser Prozess ist etwas, das keine Informationen über vorherige Operationen speichert oder referenziert. Jedes Mal führt es jede Operation von Grund auf neu aus, genau wie beim ersten Mal, und stellt die Funktionalität zur Verfügung, um den Druck, das CDN (Content Delivery Network) oder die Webserver zu nutzen, um jede kurzfristige Anfrage zu verarbeiten.
Zum Beispiel sucht jemand eine Frage in der Suchmaschine und drückt die Enter-Taste. Wird der Suchvorgang aus irgendeinem Grund unterbrochen oder beendet, muss man einen neuen starten, da es keine gespeicherten Daten für die vorherige Anfrage gibt.

Stateful vs. Stateless Session

Stateful- und Stateless-Anwendungen speichern den Status von Client-Anfragen auf dem Server selbst und verwenden diesen Status, um weitere Anfragen zu verarbeiten. Sie verwenden eine DB zum Speichern von Daten als Backend, aber die Sitzungsinformationen werden auf dem Server selbst gespeichert. Wenn ein Benutzer eine Login-Anfrage sendet, kann er sich jetzt anmelden und der Benutzer wird authentifiziert, und bei der zweiten Anfrage sieht der Benutzer das Dashboard. Stateful-Applikationen müssen keinen zweiten Aufruf an die DB machen, da die Session-Informationen auf dem Server selbst gespeichert sind. Die Rolle von Containern in DevOps zu verstehen, ist ein besserer Weg, um sich mit Microservices-Anwendungen vertraut zu machen.

Es ist also schneller. Aber es hat auch Nachteile. Es gibt einen Load Balancer, und dahinter stehen zwei Server, auf denen die gleiche Stateful-Anwendung läuft. Die erste Anfrage zum Einloggen geht an Server 1 und die zweite Anfrage könnte an Server 2 gehen; da nun nur der eine Server das Einloggen aktiviert hat, wird der Benutzer nicht in der Lage sein, zu loggen, wenn LB ihn zum zweiten Server schickt. Es ist also nicht möglich, Stateful-Anwendungen horizontal zu skalieren.

Stateless und Stateful Container Management

Während Stateless-Anwendungen auf unterschiedliche Weise arbeiten, speichern sie keinen Zustand auf dem Server. Sie verwenden eine DB, um alle Informationen zu speichern. Die DB ist zustandsbehaftet, d.h. sie verfügt über einen persistenten Speicher.

Typischerweise fordert ein Benutzer eine Anmeldung mit Anmeldeinformationen an, einer der Server hinter LB verarbeitet die Anfrage, generiert ein Auth-Token, speichert es in der DB und gibt das Token an den Client am Frontend zurück. Die nächste Anfrage wird zusammen mit dem Token gesendet. Egal, welcher Server die Anfrage verarbeitet, er wird das Token mit den Informationen in der DB abgleichen und dem Benutzer die Anmeldung gewähren. Jede Anfrage ist unabhängig und hat keine Verbindung zu vorherigen oder nächsten Anfragen, genau wie bei REST.

Obwohl zustandslose Anwendungen einen zusätzlichen Overhead durch den Aufruf der DB haben, sind diese Anwendungen erstaunlich gut horizontal skalierbar, was für moderne Anwendungen, die Millionen von Benutzern haben können, entscheidend ist.

Moderne Anwendungen und Legacy-Anwendungen haben eine Eigenschaft gemeinsam, nämlich ob sie einen Zustand speichern oder nicht. Ob man es mit Monolithen oder Microservices zu tun hat, hängt von den Bedürfnissen der Anwendung ab; einige müssen den Zustand speichern, während andere sich nicht um den Zustand kümmern müssen.

Unterschied zwischen Stateful vs. Stateless Applications

Beide, Stateful und Stateless, sind in IT-Läden allgegenwärtig. Aber moderne Software wird in der Stateless Art und Weise architektiert, da Skalierung ein wesentlicher Faktor für die heutige Welt ist.

Die acht Hauptunterschiede zwischen Stateful und Stateless Anwendungen sind –

1. Arbeitszustand: Stateful-Applikationen reagieren nach dem aktuellen Zustand, während Stateless-Applikationen eigenständig unter Berücksichtigung der vorherigen/nächsten Anfrage agieren.
2. Gespeicherte Daten: Wenn der Webserver Daten im Backend speichert und sie dazu verwendet, den Benutzer als immer verbundenen Client zu identifizieren, ist der Dienst Stateful. Bei Stateless speichert der Server zwar Daten, aber in einer Datenbank, um den Benutzer/Client zu verifizieren, wann immer er eine Verbindung herstellen muss.
3. Reaktion gegenüber Clients: Bei Stateful denkt der Server, dass der Client nur eine dumme Maschine ist, während der Server bei Stateless denkt, dass der Client eine intelligente Maschine ist, die nicht von irgendeinem Zustand auf der Serverseite abhängig sein muss.
4. Anfragen: In Stateless sind Requests in sich abgeschlossen, d.h. alles ist in der Anfrage enthalten, und werden in zwei getrennten Phasen abgewickelt, einer „Anfrage“ und einer „Antwort“. Während bei Stateful die Anfragen immer vom serverseitigen Zustand abhängig sind.
5. Generated State: Beim Browsen im Internet wird der Zustand generiert und irgendwo gespeichert. Obwohl der Zustand in beiden Typen generiert wird, wenn der Zustand auf dem Server gespeichert wird, erzeugt er eine Sitzung. Dies wird eine Stateful-Anwendung genannt.
6. State Stored: Wenn der Zustand vom Client gespeichert wird, erzeugt er einige Daten, die für weitere Anfragen verwendet werden, obwohl er technisch gesehen „Stateful“ ist, da er auf einen Zustand verweist, aber der Zustand wird vom Client gespeichert, daher nennt man ihn „Stateless“.
7. Cookie speichert: Auf der Client-Seite speichert das Cookie Authentifizierungsdaten. Auf der Server-Seite werden temporäre Client-Daten angelegt oder in einer Datenbank gespeichert (dies ist der typische Fall). Wenn Sie zum Dashboard zurückkehren, um eine weitere Zahlung vorzunehmen, ist es ein Cookie, das im Browser gespeichert wird und den Zustand mit dem Server herstellt.
8. User Base: Stateful ist Vergangenheit, als es Monolithen und keine dynamische Benutzerbasis gab. Stateless ist Zukunft, da Microservices im Umlauf sind und meist über REST-Schnittstellen kommunizieren und alles skalierbar ist, da kein Zustand gespeichert wird.

Der Wechsel zu Microservices und Containern hilft Unternehmen, die Legacy-Technologien hinter sich lassen wollen, aber es bleiben Herausforderungen.

Warum sind zustandslose Anwendungen wichtig?

• Warum gibt es einen Bedarf für zustandslose Anwendungen, wenn die Dinge vorher mit zustandsabhängigen Anwendungen gut liefen?

Zustandsabhängige Anwendungen sind für minimale Anwendungsfälle hervorragend geeignet, aber sie haben einige Probleme. Erstens: Wenn der Benutzer einen Zustand auf dem Server referenziert, werden viele unvollständige Sessions geöffnet und es kommt zu Transaktionen.

• In einem Stateful-System wird der Zustand vom Client berechnet, wie lange soll das System die Verbindung offen lassen?
• Wie kann serverseitig überprüft werden, dass der Client abgestürzt ist oder die Verbindung zur Session unterbrochen wurde?
• Wie können die Aktionen des Benutzers nachverfolgt werden, während die Dokumentenänderungen beibehalten und Rollbacks durchgeführt werden?
• Die meisten Konsumenten/Clients reagieren auf intelligente, dynamische Art und Weise auf den Server, so dass ein vom Client unabhängiger Serverzustand aufrechterhalten wird, wenn man davon ausgeht, dass der Client nur ein „Dummer“ ist; der Client ist verschwenderisch.
• Zustandslosigkeit ist ein grundlegender Aspekt moderner Anwendungen – jeden Tag; es wird eine Vielzahl von zustandslosen Diensten und Anwendungen verwendet. Sie nutzt HTTP für zustandslose Verbindungen und verwendet Nachrichten, die gerendert werden und isoliert voneinander und vom Client-Zustand arbeiten.
• Facebook nutzt ständig einen zustandslosen Dienst. Wenn der Server über die Facebook-API eine Liste der letzten Nachrichten anfordert, stellt er eine GET-Anfrage mit Token und Datum. Die Antwort ist unabhängig vom Serverzustand, und alles wird auf dem Rechner des Clients in Form eines Caches gespeichert.
• Analog dazu wird beim Aufruf eines POST-Befehls ein komplexer Body mit Autorisierungs-/Authentifizierungsdaten im Header übergeben, ohne den Serverzustand zu berücksichtigen.
• Es gibt keine Beziehung zur vorherigen, aktuellen & nächsten Anfrage. Bei Stateless wartet der Client nicht auf die Synchronisation durch den Server. In der Serverless-Architektur für Big Data gibt es kein Konzept der Prozessvervollständigung. Es ist also schneller.

REST ist eine gängige Art, moderne APIs zu entwerfen, zu architektieren und zu entwickeln.& Representational State Transfer (REST) ist zustandslos.

Wie funktioniert eine zustandslose Anwendung?

Zustandslose Architektur bedeutet, dass die App nur vom Speicher eines Drittanbieters abhängig ist, da sie keine Art von Zustand im Speicher oder auf ihrer Festplatte speichert. Alle Daten, die sie benötigt, müssen von einem anderen zustandsbehafteten Dienst (Datenbank) geholt werden oder sind in der CRUD-Anfrage vorhanden.

Zustandslose Architektur ist völlig anders und besser als zustandsbehaftet. Zustandslose Anwendungen skalieren sehr schlecht.

Schritt 1: Anfragen werden auf jedes Replikat eines zustandslosen Dienstes lastverteilt, da alle Daten irgendwo anders gespeichert sind, normalerweise in einer DB mit persistentem Speicher.

Schritt 2: Wenn die Anzahl der gleichzeitigen Benutzer in zustandsabhängigen Anwendungen wächst, werden mehr Server hinzugefügt, auf denen die Anwendungen laufen, und die Last wird mithilfe eines Load-Balancers gleichmäßig auf diese Server verteilt. Da sich aber jeder Server den Status jedes angemeldeten Benutzers „merkt“, muss dieser Load-Balancer im „Sticky-Modus“ konfiguriert werden.

Schritt 3: Bei der Verteilung der Last auf die Server muss der Load-Balancer die Anfrage jedes Benutzers an denselben Server senden, der auf die vorherige Anfrage dieses Benutzers geantwortet hat, um die Anfrage korrekt zu verarbeiten, was den Zweck des Lastausgleichs verfehlt, da die Last nicht in einer echten Round-Robin-Methode verteilt wird.

Schritt 4: Die serverseitige Logik ist so kodiert, dass sie nicht vom „zuvor gespeicherten Zustand“ des Clients abhängt.

Schritt 5: Die Zustandsinformationen werden zusammen mit jeder Anfrage an den Server gesendet, über den der Server mit der Bearbeitung der Anfrage fortfährt. Der Load-Balancer muss sich nicht um die Weiterleitung von Anfragen an denselben Server kümmern, und es wird ein wirklich gleichmäßiger Lastausgleich erreicht.

Schritt 6: Der Load-Balancer sendet den Datenverkehr an jeden Server &, der die Anfrage gut bedient, da der Client bei jeder Anfrage ein Token oder andere notwendige Informationen mitschickt. JSON Web Token (JWT) wird häufig verwendet, um zustandslose Anwendungen zu erstellen.

Vorteile zustandsloser Anwendungen

Im Folgenden sind die 5 wichtigsten Vorteile der zustandslosen Anwendung aufgeführt:

1. Entfernt den Overhead zum Erstellen/Verwenden von Sitzungen.
2. Skaliert horizontal für die Bedürfnisse moderner Benutzer.
3. Neue Instanzen einer Anwendung werden bei Bedarf hinzugefügt/entfernt.
4. Ermöglicht Konsistenz über verschiedene Anwendungen hinweg.
5. Statelessness macht eine Anwendung komfortabler und wartbarer.

Zusätzliche Skalierungs- und Leistungsvorteile von zustandslosen Anwendungen sind folgende:

1. Reduziert den Speicherverbrauch auf der Serverseite.
2. Eliminiert das Problem des Ablaufs von Sitzungen – Manchmal verursachen ablaufende Sitzungen Probleme, die schwer zu finden und zu testen sind. Zustandslose Anwendungen benötigen keine Sessions & und leiden daher nicht unter diesen Problemen.
3. Aus Sicht des Benutzers ermöglicht die Zustandslosigkeit, dass Ressourcen verlinkt werden können. Wenn eine Seite zustandslos ist, wird sichergestellt, dass der Benutzer, wenn er einen Freund auf diese Seite verlinkt, die gleiche Ansicht wie ein anderer Benutzer sieht.

Wie führt man zustandslose Anwendungen ein?

Nachfolgend finden Sie die 5 Schritte zur Einführung zustandsloser Anwendungen

Schritt 1: Anpassen und Entwickeln neuer Anwendungen

Die Einführung zustandsloser Anwendungen kann anfangs eine entmutigende Aufgabe sein, da es sich um ein neues Paradigma handelt. Aber mit der richtigen Denkweise und den richtigen Informationen können Sie neue Anwendungen anpassen und entwickeln, ohne einen Zustand zu behalten. Verwenden Sie Authentifizierung/Autorisierung, um sich mit dem Server zu verbinden.

Schritt 2: Entwickeln Sie Anwendungen mit Microservices

In diesem Schritt wird die Containerisierung für die Bereitstellung durchgeführt. Container sind am besten geeignet, um zustandslose Workloads auszuführen. Wenn die Anzahl der Container steigt, sollten Sie den Einsatz von Cloud-Orchestrierungs- und Management-Tools wie Kubernetes in Betracht ziehen, um eine große Anzahl von Containern zu betreiben.

Schritt 3: Containerisierte Microservices-Anwendungen

Finden Sie den besten Standort, um die Containersicherheit von einem Ressourcenpunkt aus zu betreiben und die HA (Hochverfügbarkeit) der Anwendung aufrechtzuerhalten.

Schritt 4: Anhängen von Storage an Stateless Ephemeral

Storage, das an Stateless angehängt ist, ist ephemeral. Unternehmen müssen mit Stateless Containern beginnen, da diese leichter an diese Art von Architektur angepasst und von monolithischen Anwendungen getrennt und unabhängig skaliert werden können.

Schritt 5: REST-Philosophie anwenden

Das Backend sollte REST-Design-Patterns für den Aufbau von Anwendungen verwenden. Die REST-Philosophie besteht darin, keinen Zustand zu pflegen, sondern nur ein wenig Cookies und lokale Speicherung auf der Client-Seite.

Best Practices für zustandslose Anwendungen

Neun einfache Praktiken für die richtige Pflege von zustandslosen Anwendungen sind im Folgenden aufgeführt:

1. Versuchen Sie, Sitzungen um jeden Preis zu vermeiden.
2. Sessions fügen unnötige Komplexität hinzu und bieten einen sehr geringen Nutzen.
3. Es wird schwierig, Bugs zu reproduzieren.
4. Schwer, Session-bezogene Bugs zu beheben, da alles auf der Server-Seite gespeichert wird.
5. Es ist nicht möglich, Sessions zu skalieren.
6. Wenn die Last auf der Anwendung exponentiell ansteigt, verteilen Sie die Last auf verschiedene Server. Wenn Sie Sessions verwenden, replizieren Sie alle Sessions auf alle Server zur gleichen Zeit. Das System wird sehr anspruchsvoll und fehleranfällig. Vermeiden Sie Sitzungen.
7. Sitzungen sind nur für bestimmte Anwendungsfälle wie FTP (File Transfer Protocol) sinnvoll.
8. Für Anwendungsfälle wie die gemeinsame Nutzung von Dropbox fügen zustandsabhängige Sitzungen zusätzlichen Overhead hinzu, während zustandslose der perfekte Weg sind.
9. Sitzungsfunktionalität wird über Cookies repliziert, Caching auf der Client-Seite.

Erfahren Sie mehr über Microservices mit Golang – eine Komplettlösung

Tools für zustandslose Anwendungen

Die besten Tools für zustandslose Anwendungen sind folgende:

1. Moderne Sprachen wie Python, Golang.
2. Für die Bereitstellung – Container und Orchestrierung wie Docker und Kubernetes.
3. Für die Entdeckung anderer Dienste – Kube Proxy Service, Etcd.
4. API-Gateway – Zur Verbindung mit verschiedenen Diensten von außen.
5. Für Service Mesh um alle Stateless-Anwendungen: LinkerD / Istio.

Zustandslose Anwendungen abschließen

Die meisten IT-Unternehmen, die Microservices entwickeln, erstellen bereits zustandslose Anwendungen mit REST-API-Design. Das Verständnis dieses Konzepts ist die Grundlage, auf der die meisten modernen Architekturen basieren, wie zum Beispiel Konzepte wie RESTful Design. Ein gutes Verständnis und der Vorteil von Stateless gegenüber Stateful ist essentiell für die Entwicklung von Anwendungen, um die massiven Bedürfnisse der heutigen Benutzer zu bedienen.

Share :