Style architektury i wzorce komunikacji

Tworzenie aplikacji na AWS

Ricardo Sueiras

Principal Technologist

Twój instruktor

Czym są wzorce architektoniczne?

 

 

 

• Gotowe rozwiązanie powtarzającego się problemu.
• Wzorce pokazują, jak łączyć usługi AWS.
• Architektura decyduje o zachowaniu aplikacji pod obciążeniem.
• Poznasz kilka kluczowych wzorców architektonicznych.

Monolity

 

 

 

 

• Jedna, ściśle powiązana całość.
• Jedna baza kodu, jedno wdrożenie.
• Na początku prosta w tworzeniu.
• Trudna do skalowania: wszystko skaluje się razem.

Mikroserwisy

 

 

• Małe, niezależne serwisy — każdy odpowiada za jedną funkcję biznesową.
• Każdy serwis można wdrażać, skalować i aktualizować niezależnie.
• Kompromis: większa złożoność operacyjna i komunikacja między serwisami.

Serverless

• Żadnej infrastruktury do zarządzania — tylko kod i konfiguracja.
• Budujesz, składając zarządzane usługi AWS.
• AWS zajmuje się provisioningiem, skalowaniem i utrzymaniem.
• Kompromis: limity czasu wykonania, zimne starty, uzależnienie od dostawcy.
• Minimalne koszty operacyjne i automatyczne skalowanie.

 

Architektura sterowana zdarzeniami (EDA)

• Komponenty komunikują się przez zdarzenia, nie bezpośrednie wywołania.
• Zdarzenie rejestruje fakt, który nastąpił (złożono zamówienie, odebrano płatność, wysłano towar).
• Producenci emitują zdarzenia.
• Konsumenci subskrybują interesujące ich zdarzenia.

 

Systemy silnie i luźno powiązane

• Nowoczesne aplikacje chmurowe składają się z wielu serwisów.
• Serwisy muszą się komunikować i koordynować pracę.
• Komunikacja synchroniczna — silne powiązanie.
• Komunikacja asynchroniczna — luźne powiązanie.

Komunikacja synchroniczna

 

• Serwis wysyła żądanie i czeka na odpowiedź.
• Wywołujący jest blokowany do czasu odpowiedzi lub przekroczenia limitu czasu.
• Prosta w implementacji i zrozumieniu.
• Silne powiązanie: spowolnienie lub awaria niżej mogą kaskadowo się rozchodzić.
• Zaradź temu przez limity czasu, ponawianie i wyłączniki automatyczne.

Wzorzec: żądanie/odpowiedź

• Podstawa większości interfejsów aplikacji.
• Przewidywalne zachowanie.
• Natychmiastowa informacja zwrotna dla użytkowników.

Komunikacja asynchroniczna

 

• Nadawca nie czeka na odpowiedź.
• Wysyła wiadomość lub zdarzenie i kontynuuje przetwarzanie.
• Odbiorca przetwarza wiadomość niezależnie.
• Luźne powiązanie: lepsza skalowalność i odporność na awarie.
• Dobrze radzi sobie ze skokami ruchu i częściowymi awariami.
• Wyzwania: zduplikowane wiadomości, kolejność, spójność ostateczna.

Wzorzec: rozdzielanie przez kolejkę

• Producent wysyła wiadomości do kolejki.
• Konsument pobiera i przetwarza wiadomości niezależnie.
• Zapobiega kaskadowemu rozchodzeniu się awarii.
• Producent i konsument skalują się niezależnie.

 

Wzorzec: kolejka robocza

• Wiele workerów pobiera wiadomości z jednej kolejki.
• Wiadomości przetwarzane równolegle.
• Umożliwia skalowanie poziome i wyższą przepustowość.
• Kolejność wiadomości nie jest gwarantowana.

Wzorzec: publikuj/subskrybuj

• Wydawcy wysyłają wiadomości do tematu SNS.
• Wielu subskrybentów otrzymuje tę samą wiadomość.
• Rozgłaszanie w czasie rzeczywistym do wielu konsumentów.

 

Wzorzec: fan-out

• Jedna wiadomość dostarczana jednocześnie do wielu konsumentów.
• Szeroko stosowany w architekturach sterowanych zdarzeniami.
• Przydatny, gdy wiele serwisów musi reagować na to samo zdarzenie.

Kolejność wiadomości

• Niektóre zadania wymagają przetwarzania wiadomości w odpowiedniej kolejności.
• Amazon SQS FIFO i Kinesis obsługują przetwarzanie w kolejności.
• Ścisła kolejność zmniejsza przepustowość.
• Znajdź balans między poprawnością a skalowalnością.

Czas na praktykę!

Tworzenie aplikacji na AWS