Stateful i Stateless Applications Best Practices and Advantages

By Gursimran Singh|Insights|06,Oct,2020

Czym są Stateful i Stateless Applications?

Aplikacja Stateful zapamiętuje specyficzne szczegóły użytkownika, takie jak profil, preferencje i działania użytkownika. Informacje te są uważane za „stan” systemu.
Na przykład, Twój koszyk na zakupy podczas korzystania z dowolnej strony internetowej w chmurze. Za każdym razem, gdy wybierasz przedmiot i dodajesz go do koszyka, dodajesz go z przedmiotami dodanymi wcześniej i ostatecznie przechodzisz do strony kasy.

Bezstanowa aplikacja lub proces to coś, co nie zapisuje lub nie odwołuje się do informacji o poprzednich operacjach. Za każdym razem przeprowadza każdą operację od podstaw tak jak za pierwszym razem i zapewnia funkcjonalność korzystania z druku, CDN (Content Delivery Network) lub serwerów internetowych w celu przetworzenia każdego krótkoterminowego żądania.
Na przykład, ktoś szuka pytania w wyszukiwarce i nacisnął przycisk Enter. W przypadku, gdy operacja wyszukiwania zostanie przerwana lub zamknięta z jakiegoś powodu, musisz rozpocząć nową, ponieważ nie ma zapisanych danych dla poprzedniego żądania.

Stateful vs Stateless Session

Stateful i Stateless aplikacje przechowują stan z żądań klienta na samym serwerze i używają tego stanu do przetwarzania dalszych żądań. Używają DB do przechowywania danych jako backendu, ale informacje o sesji przechowywane są na samym serwerze. Kiedy użytkownik wysyła żądanie logowania, umożliwia to logowanie jako prawdziwe i użytkownik uwierzytelnia się teraz, a na drugie żądanie, użytkownik widzi pulpit. Aplikacje stanowe nie potrzebują wywoływać DB po raz drugi, ponieważ informacje o sesji są przechowywane na samym serwerze. Understanding the Role of Containers in DevOps jest lepszym sposobem na zapoznanie się z aplikacjami Microservices.

Więc jest to szybsze. Ale ma to swoje wady. Jest load balancer, a za nim są dwa serwery, na których działa ta sama aplikacja Stateful. Pierwsze żądanie logowania trafia na serwer pierwszy, a drugie żądanie może trafić na serwer drugi; teraz, ponieważ tylko serwer włączył logowanie jako prawdziwe, użytkownik nie będzie w stanie logować się, gdy LB wysyła go na serwer drugi. Tak więc nie jest możliwe poziome skalowanie aplikacji stateful.

Stateless and Stateful Container Management

Mimo że aplikacje stateless działają na różne sposoby, nie przechowują żadnego stanu na serwerze. Używają DB do przechowywania wszystkich informacji. DB jest stanowy, to znaczy, ma dołączony do niego trwały magazyn.

Typowo, użytkownik prosi o zalogowanie się z danymi uwierzytelniającymi, któryś z serwerów za LB przetwarza żądanie, generuje auth token, przechowuje go w DB i zwraca token do klienta na front-endzie. Następne żądanie jest wysyłane wraz z tokenem, Teraz, niezależnie od tego, który serwer przetworzy żądanie, dopasuje token do informacji w DB i udzieli loginu użytkownikowi. Każde żądanie jest niezależne i nie ma żadnego powiązania z poprzednim lub następnym żądaniem, tak jak REST.

Aczkolwiek aplikacje bezpaństwowe mają jeden dodatkowy narzut w postaci połączenia z DB, aplikacje te są niesamowite w skalowaniu poziomym, kluczowym dla nowoczesnych aplikacji, które mogą mieć miliony użytkowników.

Nowoczesne aplikacje i starsze aplikacje mają jedną wspólną cechę, czy przechowywać stan czy nie. To czy mamy do czynienia z monolitami czy mikroserwisami zależy od potrzeb aplikacji; niektóre z nich muszą przechowywać stan, podczas gdy inne nie muszą dbać o stan.

Różnica pomiędzy aplikacjami stateful vs. stateless

Oba typy aplikacji Stateful i Stateless są wszechobecne w sklepach IT. Jednak współczesne oprogramowanie jest projektowane w sposób bezpaństwowy, ponieważ skalowanie jest istotnym czynnikiem w dzisiejszym świecie.

Osiem głównych różnic pomiędzy aplikacjami stateful i bezpaństwowymi to –

1. Stan pracy: Aplikacje Stateful reagują przez aktualny stan, podczas gdy aplikacje Stateless działają niezależnie z uwzględnieniem poprzedniego/kolejnego żądania.
2. Przechowywane dane: Jeśli webserver przechowuje dane w sposób backendowy i używa ich do identyfikacji użytkownika jako zawsze połączonego klienta, usługa jest Stateful. Podczas gdy w Stateless, serwer przechowuje dane, ale w bazie danych, aby zweryfikować użytkownika/klienta za każdym razem, gdy musi się połączyć.
3. Reakcja na klientów: W Stateful, serwer myśli, że klient jest tylko głupią maszyną, podczas gdy w Stateless, serwer myśli, że klient jest inteligentną maszyną, która nie musi zależeć od żadnego stanu po stronie serwera.
4. Żądania: W Stateless, żądania są samoistne, tj. wszystko zawarte w żądaniu, i obsługiwane w dwóch odrębnych fazach, „żądanie” i „odpowiedź”. Podczas gdy w Stateful, żądania zawsze zależą od stanu po stronie serwera.
5. Stan generowany: Podczas przeglądania Internetu, stan generowany i przechowywany gdzieś. Chociaż stan generowany w obu typach, gdy stan przechowywany na serwerze, generuje sesję. To się nazywa Stateful aplikacji.
6. State Stored: Kiedy stan przechowywany przez klienta, generuje pewne dane wykorzystywane do dalszych żądań, podczas gdy technicznie „Stateful”, jak to odnosi się do stanu, ale stan przechowywany przez klienta, więc nazwać go Stateless.
7. Cookie Stores: Po stronie klienta, cookie przechowuje dane uwierzytelniające. Po stronie serwera, tworzą tymczasowe dane klienta lub przechowują je w bazie danych (jest to typowy przypadek). Podczas powrotu do dashboardu w celu dokonania kolejnej płatności, to właśnie cookie przechowywane w przeglądarce ustala stan z serwerem.
8. Baza użytkowników: Stateful to przeszłość, gdy istniały Monolity i nie było dynamicznej bazy użytkowników. Stateless jest przyszłością, posiadając Microservices pływające wokół i głównie komunikują się poprzez interfejsy REST i skalują się jak wszystko, ponieważ nie ma przechowywanego stanu.

Przejście do mikroserwisów i kontenerów pomaga przedsiębiorstwom, które chcą przejść przez starsze technologie, ale wyzwania nadal pozostają.

Why Stateless Applications Matters?

• Dlaczego potrzebne są aplikacje bezpaństwowe, skoro wcześniej wszystko działało dobrze z aplikacjami pełnostanowymi?

Aplikacje pełnostanowe są doskonałe dla minimalnych przypadków użycia, ale mają pewne problemy. Po pierwsze, gdy użytkownik odwołuje się do stanu na serwerze, otwiera wiele niekompletnych sesji i dochodzi do transakcji.

• W systemie Stateful, stan obliczany przez klienta, jak długo system powinien pozostawiać otwarte połączenie?
• Jak zweryfikować po stronie serwera, że klient uległ awarii lub odłączył się od sesji?
• Jak śledzić działania użytkownika przy zachowaniu zmian w dokumencie i robieniu rollbacków?
• Większość konsumentów/klientów odpowiada serwerowi w inteligentny, dynamiczny sposób, utrzymując w ten sposób stan serwera niezależny od klienta, zakładając, że klient jest tylko „głupi”; klient jest marnotrawny.
• Bezstanowość jest podstawowym aspektem nowoczesnych aplikacji – każdego dnia; używa wielu bezstanowych usług i aplikacji. Używa HTTP do łączenia się w sposób bezpaństwowy, wykorzystując wiadomości, które są renderowane i działają w izolacji od siebie i stanu klienta.
• Facebook nieustannie korzysta z usługi bezpaństwowej. Kiedy serwer żąda listy ostatnich wiadomości za pomocą API Facebooka, wydaje żądanie GET z tokenem i datą. Odpowiedź jest niezależna od jakiegokolwiek stanu serwera, a wszystko jest przechowywane na maszynie klienta w postaci pamięci podręcznej.
• Podobnie, wywołując polecenie POST, przekazujemy złożone ciało z danymi autoryzacji/uwierzytelnienia w nagłówku bez uwzględniania stanu serwera.
• Nie ma żadnego związku z poprzednim, bieżącym & następnym żądaniem. W Stateless, klient nie czeka na synchronizację z serwera. Nie ma koncepcji zakończenia procesu w architekturze bezserwerowej dla Big Data. Więc jest to szybsze.

REST jest głównym sposobem projektowania, architektury i rozwoju nowoczesnych interfejsów API & Representational State Transfer (REST) is stateless.

How Stateless Application Works?

Stateless Architecture oznacza, że aplikacja jest zależna tylko od pamięci masowej stron trzecich, ponieważ nie przechowuje żadnego rodzaju stanu w pamięci lub na swoim dysku. Wszystkie dane, których potrzebuje lub wymaga muszą być pobrane z jakiejś innej usługi stanowej (Baza Danych) lub są obecne w żądaniu CRUD.

Architektura bezpaństwowa jest zupełnie inna i lepsza niż państwowa. Aplikacje bezpaństwowe skalują się bardzo słabo.

Krok 1: Żądania równoważone obciążeniem do każdej repliki usługi bezpaństwowej, ponieważ ma wszystkie dane przechowywane gdzie indziej, zwykle DB z trwałą pamięcią masową.

Krok 2: Gdy ilość współbieżnych użytkowników rośnie w rozmiarze w aplikacjach stateful, więcej serwerów uruchamia aplikacje dodane, a obciążenie równomiernie rozprowadzane między tymi serwerami za pomocą load-balancera. Ale ponieważ każdy serwer „pamięta” stan każdego zalogowanego użytkownika, konieczne staje się skonfigurowanie load-balancera w trybie „sticky-mode.”

Krok 3: W tym samym czasie, rozdzielając obciążenie pomiędzy serwerami, load-balancer wymaga wysłania każdego żądania użytkownika do tego samego serwera, który odpowiada na poprzednie żądanie tego użytkownika, aby poprawnie przetworzyć żądanie, co mija się z celem równoważenia obciążenia, ponieważ obciążenie nie jest dystrybuowane w prawdziwy sposób Round-Robin.

Krok 4: Logika po stronie serwera zakodowana w taki sposób, że nie zależy od „wcześniej zapisanego stanu” klienta.

Krok 5: Informacja o stanie wysyłana wraz z każdym żądaniem, do serwera, przez który serwer kontynuuje obsługę żądania. Load-balancer nie musi się martwić o kierowanie żądań do tego samego serwera, a prawdziwie równomierne równoważenie obciążenia osiągnięte.

Krok 6: Load-balancer wysyła ruch do dowolnego serwera & żądanie obsługiwane dobrze, ponieważ klient wysyłający token lub inne potrzebne informacje z każdym żądaniem. JSON Web Token (JWT) jest powszechnie używany do tworzenia aplikacji bezpaństwowych.

Korzyści z aplikacji bezpaństwowych

Oto 5 głównych zalet aplikacji bezpaństwowych:

1. Usuwa koszty ogólne tworzenia/używania sesji.
2. Niezwykle skaluje się horyzontalnie, co jest niezbędne dla potrzeb współczesnego użytkownika.
3. Nowe instancje aplikacji dodawane/usuwane na żądanie.
4. Pozwala na spójność pomiędzy różnymi aplikacjami.
5. Bezstanowość sprawia, że aplikacja jest wygodniejsza w pracy i łatwiejsza w utrzymaniu.

Dodatkowe korzyści skalowania i wydajności aplikacji bezpaństwowych są następujące:

1. Zmniejsza zużycie pamięci po stronie serwera.
2. Eliminuje problem wygasania sesji – Czasami, wygasające sesje powodują problemy, które są trudne do znalezienia i przetestowania. Aplikacje bezpaństwowe nie potrzebują sesji & stąd nie cierpią z tego powodu.
3. Od strony użytkownika, bezpaństwowość pozwala na linkowanie zasobów. Jeśli strona jest bezpaństwowa, to kiedy użytkownik linkuje znajomego do tej strony, zapewnia to, że użytkownik widzi to samo, co inny użytkownik.

Jak zaadoptować Aplikacje Bezpaństwowe?

Oto 5 kroków do zaadoptowania Aplikacji Bezpaństwowych

Krok 1: Adaptacja i rozwój nowych aplikacji

Zaadoptowanie Aplikacji Bezpaństwowych może być zniechęcającym zadaniem na początku, ponieważ jest to nowy paradygmat. Ale z odpowiednim nastawieniem i informacjami, dostosuj i rozwijaj nowe aplikacje bez utrzymywania jakiegokolwiek stanu. Użyj Uwierzytelniania/Autoryzacji, aby połączyć się z serwerem.

Krok 2: Rozwijaj aplikacje używając Mikroserwisów

W tym kroku, konteneryzacja zostanie wykonana dla celów wdrożenia. Kontenery są najlepsze w uruchamianiu bezstanowych obciążeń. Kiedy kilka kontenerów do zarządzania wzrostem, należy rozważyć przejście na Cloud Orchestration i narzędzia do zarządzania, takie jak Kubernetes, aby uruchomić dużą liczbę kontenerów.

Krok 3: Konteneryzowane aplikacje Microservices

Znajdź najlepszą lokalizację do uruchomienia Container Security z punktu widzenia zasobów i utrzymania HA (High Availability) aplikacji.

Krok 4: Dołącz pamięć masową do Stateless Ephemeral

Pamięć masowa dołączona do Stateless jest efemeryczna. Organizacje muszą zacząć od Stateless Containers, ponieważ są one łatwiejsze do zaadaptowania do tego typu architektury i oddzielone od aplikacji monolitycznych i niezależnie skalowane.

Krok 5: Zastosuj filozofię REST

Do budowania aplikacji backend powinien używać wzorców projektowych REST. Filozofia REST nie wymaga utrzymywania stanu, jedynie w niewielkim stopniu ciasteczka i lokalne przechowywanie po stronie klienta.

Najlepsze praktyki dla aplikacji bezstanowych

Dziewięć prostych praktyk dla prawidłowego utrzymywania aplikacji bezstanowych jest poniżej:

1. Staraj się unikać sesji za wszelką cenę.
2. Sesje dodają niepotrzebną złożoność dostarczając bardzo mało wartości.
3. Ciężko jest odtworzyć błędy.
4. Trudno jest naprawić błędy związane z sesjami, ponieważ wszystko jest przechowywane po stronie serwera.
5. Nie jest możliwe skalowanie sesji.
6. Jeśli obciążenie aplikacji wzrasta wykładniczo, rozdziel obciążenie na różne serwery. Jeśli używasz sesji, replikuj wszystkie sesje na wszystkie serwery w tym samym czasie. System staje się bardzo skomplikowany i podatny na błędy. Unikaj sesji.
7. Sesje są użyteczne tylko w specyficznych przypadkach użycia, takich jak FTP (File Transfer Protocol).
8. Dla przypadków użycia takich jak współdzielony Dropbox, sesje stanowe dodają dodatkowy narzut, podczas gdy sesje bezstanowe są idealnym rozwiązaniem.
9. Funkcjonalność sesji replikowana przy użyciu ciasteczek, buforowanie po stronie klienta.

Poznaj więcej o Microservices with Golang – A Complete Solution

Narzędzia dla aplikacji bezpaństwowych

Najlepsze narzędzia dla aplikacji bezpaństwowych są poniżej:

1. Nowoczesne języki takie jak Python, Golang.
2. Dla celów wdrożenia – Kontenery i Orkiestracja takie jak Docker i Kubernetes.
3. Inne usługi Discovery – Kube proxy service, Etcd.
4. API Gateway – Do łączenia się z różnymi usługami z zewnątrz.
5. Dla Service Mesh wokół wszystkich aplikacji Stateless: LinkerD / Istio.

Zakończenie Stateless Applications

Większość firm IT, które budują Microservices, tworzy już Stateless aplikacje wykorzystujące projektowanie REST API. Zrozumienie tej koncepcji jest fundamentem, na którym opiera się większość nowoczesnych architektur, takich jak koncepcje takie jak projektowanie RESTful. Dobre zrozumienie i przewaga Stateless nad Stateful jest niezbędna w tworzeniu aplikacji do obsługi masowych potrzeb dzisiejszych użytkowników.

Podziel się :

.