Loose coupling i mikroserwisy
Czy zdarzyło Ci się, że zmiana w jednej części aplikacji psuła coś kompletnie innego? To klasyczny objaw tight coupling, czyli ścisłego powiązania komponentów. W dobrze zaprojektowanej architekturze chmurowej chcesz, żeby komponenty były jak niezależni pracownicy: każdy robi swoje, komunikują się przez jasne kanały, a gdy jeden zachoruje, reszta dalej działa.
Monolit vs Mikroserwisy
Zanim wejdziemy w loose coupling, musisz rozumieć dwa fundamentalne podejścia do budowania aplikacji:
Monolit to jedna duża aplikacja, gdzie wszystko jest razem: logowanie, obsługa zamówień, płatności, wysyłka emaili. Cały kod w jednym repozytorium, deploy jako jeden pakiet, jedna baza danych.
Mikroserwisy to rozbicie aplikacji na małe, niezależne usługi. Każda robi jedną rzecz dobrze: serwis zamówień, serwis płatności, serwis notyfikacji. Każdy ma swoją bazę danych, swój deploy, może być napisany w innym języku.
| Aspekt | Monolit | Mikroserwisy |
|---|---|---|
| Wdrożenie | Cała aplikacja naraz | Każdy serwis osobno |
| Skalowanie | Cała aplikacja (nawet jeśli tylko 1 moduł potrzebuje więcej zasobów) | Skalujesz tylko ten serwis, który tego potrzebuje |
| Awaria | Może położyć całą aplikację | Pada jeden serwis, reszta działa |
| Złożoność | Prosty na początku, trudny przy dużej skali | Trudniejszy na początku, lepszy przy dużej skali |
| Technologia | Jeden język/framework | Każdy serwis może użyć innego |
Czym jest Loose Coupling?
Loose coupling (luźne powiązanie) to zasada projektowania, w której komponenty systemu są od siebie niezależne. Komunikują się przez dobrze zdefiniowane interfejsy, ale nie muszą wiedzieć o wewnętrznych szczegółach implementacji drugiego komponentu.
Wyobraź sobie pocztę. Nadawca wrzuca list do skrzynki. Nie musi wiedzieć, jakim samochodem jedzie listonosz, ile ma sortowni, ani czy listonosz jest na urlopie (wtedy zastąpi go ktoś inny). Nadawca i odbiorca są luźno powiązani, a poczta to warstwa pośrednia.
W tight coupling natomiast nadawca musiałby sam jechać do odbiorcy. Zna jego adres, numer piętra, kod do drzwi. Jeśli odbiorca się przeprowadzi, nadawca ma problem.
Wzorce Loose Coupling w AWS
AWS oferuje kilka usług, które są idealne do budowania luźno powiązanych architektur:
Amazon SQS (Simple Queue Service)
Kolejka wiadomości. Komponent A wrzuca wiadomość do kolejki, Komponent B ją pobiera i przetwarza. A nie musi wiedzieć, czy B działa, ile instancji B jest uruchomionych, ani jak szybko B przetwarza.
Przykład: serwis zamówień wrzuca zamówienie do kolejki SQS. Serwis realizacji pobiera zamówienia z kolejki we własnym tempie. Jeśli nagle wpada 1000 zamówień, kolejka buforuje je i serwis realizacji przetwarza je po kolei (lub skalujesz liczbę workerów).
Amazon SNS (Simple Notification Service)
Pub/Sub (publikuj/subskrybuj). Jeden nadawca wysyła wiadomość do tematu (topic), a wielu odbiorców ją otrzymuje. Nadawca nie wie, kto subskrybuje.
Przykład: gdy zamówienie zostanie złożone, serwis zamówień publikuje event "nowe zamówienie" do tematu SNS. Subskrybenci: serwis emailowy (wysyła potwierdzenie), serwis magazynowy (rezerwuje towar), serwis analytics (zbiera statystyki). Dodanie nowego subskrybenta nie wymaga żadnych zmian w serwisie zamówień.
SQS + SNS razem (Fan-Out Pattern)
Potężny wzorzec: SNS rozgłasza event do wielu kolejek SQS. Każda kolejka jest przetwarzana niezależnie. Jeśli jeden konsument padnie, pozostali dalej działają, a wiadomości czekają w kolejce.
Elastic Load Balancing (ELB)
ELB oddziela klientów od serwerów. Klient nie wie, który serwer obsłuży jego request. Możesz dodawać i usuwać serwery bez wpływu na klientów. ELB automatycznie sprawdza health check i kieruje ruch tylko do zdrowych instancji.
Amazon API Gateway
Fasada dla Twoich mikroserwisów. Klient nie wie, czy za API Gateway kryje się Lambda, EC2, czy ECS. API Gateway obsługuje routing, autoryzację, throttling i caching. Możesz zmieniać implementację backendu bez wpływu na klientów API.
Wybór między SQS a SNS zależy od wzorca komunikacji:
- SQS (kolejka): jeden producent, jeden konsument (lub grupa konsumentów przetwarzających tę samą kolejkę). Wzorzec: "zadanie do wykonania". Wiadomość jest pobierana i usuwana po przetworzeniu.
- SNS (pub/sub): jeden producent, wielu konsumentów. Wzorzec: "powiadomienie o zdarzeniu". Wiadomość jest dostarczana do wszystkich subskrybentów jednocześnie.
- SNS + SQS (fan-out): jedno zdarzenie musi być przetworzone na wiele sposobów, każdy niezależnie. SNS dostarcza do wielu kolejek SQS, każda przetwarza w swoim tempie.
Na egzaminie: jeśli pytanie mówi o "decouplingu" dwóch komponentów, odpowiedź to zazwyczaj SQS. Jeśli o "powiadamianiu wielu serwisów", to SNS.
Event-Driven Architecture
Architektura sterowana zdarzeniami to naturalne rozszerzenie loose coupling. Zamiast tego, żeby Serwis A bezpośrednio wywoływał Serwis B, Serwis A emituje event ("coś się stało"), a zainteresowane serwisy reagują na ten event.
W AWS kluczową usługą dla event-driven architecture jest Amazon EventBridge. To zaawansowany event bus, który pozwala na tworzenie reguł filtrujących eventy i kierujących je do odpowiednich celów (Lambda, SQS, SNS, Step Functions i wiele więcej).
Wyobraź sobie sklep internetowy zbudowany w architekturze event-driven:
- Klient składa zamówienie (event: OrderPlaced)
- EventBridge odbiera event i kieruje go do:
- Lambda: SendConfirmationEmail (wysyła email potwierdzający)
- SQS: PaymentProcessingQueue (kolejka dla serwisu płatności)
- Lambda: UpdateInventory (rezerwuje towar w magazynie)
- SNS: AnalyticsTopic (powiadomienie dla systemu analytics)
Każdy komponent działa niezależnie. Jeśli serwis emailowy padnie, zamówienie i tak zostanie przetworzone. Jeśli dodasz nowy serwis (np. program lojalnościowy), wystarczy dodać nową regułę w EventBridge.
Zasady 12-Factor App
12-Factor App to zestaw best practices dla budowania nowoczesnych aplikacji, które świetnie pasują do chmury. Nie musisz znać wszystkich 12 na egzamin, ale kilka kluczowych zasad warto zapamiętać:
- Codebase: jeden kod źródłowy w repozytorium (Git), wiele deploymentów (dev, staging, prod)
- Config: konfiguracja w zmiennych środowiskowych, NIE w kodzie (na AWS: Parameter Store, Secrets Manager)
- Stateless processes: aplikacja nie przechowuje stanu lokalnie. Sesje w zewnętrznym store (np. ElastiCache), pliki w S3
- Disposability: instancje można szybko uruchomić i wyłączyć (kluczowe dla Auto Scaling)
- Dev/prod parity: środowiska dev i prod powinny być jak najbardziej podobne
- Monolit to jedna duża aplikacja, mikroserwisy to wiele małych, niezależnych usług. Mikroserwisy lepiej skalują się i izolują awarie
- Loose coupling oznacza, że komponenty komunikują się przez pośredników (SQS, SNS, ELB), a nie bezpośrednio
- SQS (kolejka) do komunikacji 1:1, SNS (pub/sub) do komunikacji 1:wielu, Fan-Out = SNS + SQS
- API Gateway to fasada dla mikroserwisów, ELB oddziela klientów od serwerów
- Event-driven architecture: komponenty reagują na zdarzenia (EventBridge)
- Stateless applications: nie przechowuj stanu lokalnie, używaj ElastiCache/DynamoDB
Serwis zamówień musi powiadomić serwis emailowy, magazynowy i analytics o nowym zamówieniu. Która usługa AWS jest najlepsza?
Aplikacja przechowuje sesje użytkowników na dysku lokalnym EC2. Jaki problem wystąpi przy Auto Scaling?
Który wzorzec architektury AWS najlepiej realizuje "loose coupling"?