Microservices Flashcards
Jakie są sposoby komunikacji między mikroserwisami ?
- synchroniczna - REST, gRPC
- asynchroniczna - kolejki, RabbitMQ,, Event driven architecutre
Zalety synchronicznej
- natychmiastowa odpowiedź (klient otrzymuj odpowiedź natychmiast po przetworzeniu przez zerwer)
- łatwość debugowania (łatwiej śledzić przepływ rządań)
Wady synchronicznej
- thight coupling usługi są ściśle powiązane - klienci oczekują dostępności serwera w czasie rzeczywistym
- Single point of Failure - jeśli serwis jest niedostępny, klient czeka lub błąd
- Skalowalność
Zalety asynchronicznej
- Lose coupling serwisy mogą działać niezależnie, nadawca nie musi wiedzieć o dostępności odbiorcy
- odporność na awarie jeśli jeden serwis jest niedostępny wiadmości przetwarzane później
- Skalowalność
- przepustowość obsługa wielu żadań i rozłożenie obciązenia w czasie
Wady asynchronicznej
- złożoność wymagają brokerów
- trudniejsze w debbugowaniu trudniej śledzić asynchroniczny przepływ
- potencjalne opóźnienia
Zalety mikroserwisów
- Luźne powiązanie usługi są w dużej mierze niezależne od siebie
- Autonomia są traktowane jako niezależne komponenty, które łatwo wymieniać
- są stosunkowo proste i skupiają się na jednej funkcjonalnośći
- każdy programista pracuje niezależnie od innych,
- CI/CD mogą być szybciej i częściej wdrażane
- **skalowalność*
Monolit
- jednolitość wszystkie komponenty są ściśle powiązane
- ## budowa -jedno duże oprogramowanie , wszystko w jednej bazie kodu, tylko jedna aplikacja
Monolit vs Mikroserwisy
Monolity:
- trudniej skalowany
- tylko jedna technologia
- jeśli jedna rzecz nie działa to całość nie działa
- nie można pracować na różnymi serwsiami jednocześnie
- wolniejszy development
Wady mikrosewisów
- złożonośc zarządzania
- trudność w transkacjach
- testowanie wymaga testowania interakcji pomiędzy mikroserwisami
- komunikacja pomiędzy serwisami
- monitoring i debbugowanie
- network latency
Działanie architektury mikroserwisowej
Service Discovery and registration
- usługi rejestrują sie do service registry
- umożliwia mikroserwisom znajdowanie się nawzajem w dynamicznym środowisku,
- instancje usług mogą być dodawane lub usuwane.
- mikroserwisy pytają service registry
- rozwiązuje problem tradycyjnego loadbalancera - routing tables
- umożliwa odpowiedni loadbalance pomiędzy instancjami tego samego mikroserwisu
- eureka -> spring cloud load balancer -> Feign Client
API Gateway
- punkt wejścia do systemu, który przekierowuje przychodzące żądania z zewnątrz do odpowiednich mikroserwisów
- Autoryzacja i uwierzytelnianie Może przeprowadzać wstępną autoryzację i uwierzytelnianie żądań, zanim zostaną przekazane do mikroserwisów.
- agregacja agregować odpowiedzi z wielu mikroserwisów i dostarczać je jako jedną skonsolidowaną odpowiedź do klienta.
- spring cloud gatwey, zuul
- global filters to tracing, logging
Czym jest loadbalancer
- urządzenie lub oprogramowanie
- głównym zadaniem jest równomierne rozdzielenie ruchu sieciowego między mikroserwisami
- zapewnia, że ząden mikroserwis nie jest przeciążony
- zapewnia wysoką dostępność i odporność na awarie systemu
- przykład AWS Elastic Load Balancing
Jak działa loadbalancer
- dystrybucja ruchu monitoruje ilość ruchu i żadań przychodzących do serwera i na tej podstawej dytrybuuje ruch do róznych serwerów
- Health Checks sprawdza stan serwerów , czy odpowiadają na pingi) jeśli wykryje, że serwer jest niedostępny do nie będzie kierował
- High Availabillity zapewnia, że awaria jednego serwera nie spowoduje niedostępności usługi
- Optymalizacja wykorzystania zasobów
Algorytmy Load balancingu
- Round Robin:
- Least Connections
- IP Hash
Round Robin
- Każdy serwer otrzymuje żądanie po kolei w równych odstępach czasu.
- Jest prosty w implementacji, ale nie bierze pod uwagę aktualnego obciążenia serwera.
Least Connections:
- Żądania są kierowane do serwera z najmniejszą liczbą aktywnych połączeń.
- Dobrze sprawdza się w środowiskach, gdzie sesje są długie i zróżnicowane pod kątem zasobów.
Circuti Breaker
- wzorzec stosowany mikroserwisach
- TRZY STANY - CLOSED, HALF_OPEN, OPEN
- ideą jest wykrycie awarri usługi i uniemożliwienie wysyłania do niej kolejnych żadań
- może być zaimplmentowany poprzez dodanie warstwy pomiędzy usługa wykonująca a zależna
- warstwa ta działa jak przełącznik - blokuje gdy usługa nie działa
- ma na celu zapobiegania łańcuchowym awariom i zapewnienia odporności systemu
- Hystrix (lub Resilience4J)
OpenFeign
- wspiera synchroniczną komunikację miedzy serwsiami
- pozwala tworzyć klientów interfejsów HTTP w sposób dekleratywny
- definiujesz @FeignClinet interfejs z abstrakcyjnymi metodami
- ułatwia wywoływanie metod REST Api innego mikroserwisy jakby były to lokalne metody javy
Saga
- sekwencja lokalny transakcji
- każda lokalna transkacja aktualizuje baze danych i publikuje event, który triggeruje kolejna transkacje
- jeśli transkacja lokalna się nie powiedzie do działanie kompensujące poprzedniej.
- sercem jest Eventual consistency - system w końcu osiągnie spójność
- komunikacja asnynchroniczna między mikroserwisami
- Saga log - przechowuje każda transakcje i kompensacje
- latencja
Saga Choreography
Nie ma centralnego punktu orkiestracji.
1. Klient składa zamówienie order-service
2. Order-service rejestruje zamówienie w bazie ze statusem CREATED oraz publikuje na kolejke event OrderCreated
3. Payment-service nasłuchuje zdarzeń OrderCreated
4. Gdy payment-service odbiera zdarzenie OrderCreated przetwarza płatność
5. Jeśli płatność sie powiedzie - publikuje PaymentFailed a jeśli się powiedzie PaymentProcessed
6. Order-serivce nasłuchuje zdarzeń PaymentProcessed i PaymentFailed
- Komunikacja między mikroserwisami jest asynchroniczna, co zwiększa skalowalność i odporność systemu.
- Każdy mikroserwis zarządza własną logiką i reaguje na zdarzenia, na które jest subskrybowany.
- System osiąga spójność ostateczną, nie gwarantuje natychmiastowej spójności w każdym punkcie procesu.
EventSourcing
- w stanie aplikacji jest przechowywana sekwencja zdarzeń na EventStore
- zamiast zapisywać tylko bieżący stan obiektu domenowego, zapisuje każde zmianę jako zdarzenie w trwałym logu zdarzeń
- stan aplikacji może być odtworzony przez doczytanie i zastosowanie wszystkich zdarzeń od początku
- spójność jest zapewniona przez sekwencyjne przetwarzanie zdarzeń i fakt, że zdarzenia są niezmienne po ich zapisaniu.
- jest używany w rozproszonych systemach, gdzie tradycyjne zarządzanie transakcjami jest trudniejsze.
Even Sourcing przykład order-service oraz payment-service
Typy zdarzeń
OrderCreated:
OrderUpdated:
PaymentReceived:
OrderShipped:
OrderCancelled:
- każde zdarzenie zawiera kluczowe informacje, takie jak identyfikator zamówienia, timestamp
- zdarzenia są zapisywane w kolejności ich występowania w bazie
- aby odtworzyć bieżacy stan od najstarszego
CQRS Pattern
- rozdzielenie READ i WRITE zzamiast posiadania jednego interfejsu obługującym te dwie operacje
- Commad - operacje WRITE, modyfikują stan ale nic nie zwracaja
- Query - operacje READ, zwracają
- aplikacja może mieć inne wymagania dotyczące READ i WRITE np. 5% WRITE i 95 % READ
- pozwala na niezależne skalowanie - wzrost wydajności
- łączy się z EventSourcing
Kiedy nie użyć mikroserwisów
- dla dużych i skomplikowanych projektów
- kiedy niska latencja jest priorytetem
Zasady projektowania mikroserwisów
- Modułowość: Usługi powinny być samodzielne i mieć jeden, dobrze zdefiniowany cel.
- Skalowalność: Usługi powinny być w stanie skalować się niezależnie, aby poradzić sobie z rosnącym obciążeniem.
- Decentralizacja: System powinien być zdecentralizowany, pozwalając na luźno powiązane usługi.
- Wysoka dostępność: Usługi powinny być zaprojektowane tak, aby były wysoce dostępne w celu zapewnienia niezawodności systemu.
- Odporność: Usługi powinny być zaprojektowane tak, aby z wdziękiem radziły sobie z awariami.
- Zarządzanie danymi: Usługi powinny zarządzać własnymi danymi i nie powinny współdzielić wspólnej bazy danych.
- Bezstanowośc: Usługi powinny być bezstanowe, aby umożliwić łatwe skalowanie i buforowanie.
- Niezależne wdrażanie: Usługi powinny być wdrażane niezależnie od innych usług.
- Obserwowalność: System powinien mieć wbudowane funkcje monitorowania i rejestrowania, aby umożliwić wgląd w zachowanie systemu.
- Automatyzacja: Wdrażanie, testowanie i skalowanie powinno być w jak największym stopniu zautomatyzowane.
Dlaczego mikroserwisy bezstanowe
- skalowalność bezstanowe łatwiej skałować poziomo, dokładając więcej istancji
- Odporność w razie awarii nie maja wpływu na reszte systemu
- Prostsze do wdrożenia i testowania
Co to jest Distribiuted Tracing ?
- śledzenie i monitorowanie przepływu żadania lub transkacji w wielu mikroserwsiach
- sposób na uzyskanie wglądu w złożone, rozporszone architentury i diagnozowanie problemów z wydajnościa i niezawodnościa
- traceId dla każdego żadania
- tag - URI request, username itd
- każda usługa rejestruje przepływ
- OpenTelemetry, Micrometer Tracing
- Tempo analiza
Jak ograniczyć mikrousługę przed wywoływaniem innej mikrousługi?
- użycie API Gateway to egzekowania reguł kontrolii dostępu
- Bramę można skofnigurować aby zewalała tylko autoryzowany mikorousługom na wysyłanie żadań API
- autoryzacja OAuth, JWT
Dlaczego Spring Boot jest dobry wyborem dla mikroserwisów
- możesz budować JAR zamiast WAR oraz EAR
- JAR zawiera wszystkie wymagane konfiguracje do uruchomienia mikroserwisu
- nie potrzeba zewnętrznego webserwisu
- autokonfiguracja, dependency injection
- health checks, metyka,
- obsługujący could development Kubernetes
- ## wspiera konteneryzacje
Jak uruchomić Jar mavenem ?
mvn spring-boot:run
Jak uruchomić jar java ?
java -jar .\target\accounts-0.0.1-SNAPSHOT.jar
Jak zdbudować docker file
- mvn clean install -> create jar
- create Dockerfile
- docker build
- docker run
Wady Dockerfile
- przy dużej aplikacji bardzo skomplikowany
- duża wiedza devopsowa
google jib
do czego sluży docker compose
- to definiowania i uruchamiania wielokonenerowych aplikacji
- pilk yaml do konfiguracji
- jedna komedną docker-compose up możemy odpalić wszystko
Liveness Probe
- używne do sprawdzanie czy aplikacja wewnątrz kontenera działa
- Kubernetes podejmuje działania jak restart kontenera
- np. deadlock
Readiness probe
- kiedy kontener jest gotowy do przyjęcia ruchui sieciowego
- Kubernetes kieruje ruch do innego kontnera
Client side discovery
Resilience4j
- bibliotek zaprojektowana do budowania aplikacji odpornych ba blędy
- skupia się na obsłudze awarii i zapewnieniu odporności na różne rodzaje błedów
- oferuje wzorce projektowe = **Circuit Breaker, Rate Limiter, Retry, Bulkhead, TimeLimiter, Cache **
implementacja Circuit Breaker
- filtr w API GATE WAY
- we filtrze fallBackUri
- w propertisach po nie udanych ma się włączyć
- jeśli @FeginClient (fallback= FallBack.class)
Jak rozwiązać problem timeoutów ?
repsonse-time out w properistach
Retry
Automatycznie ponawia wykonywanie operacji, które nie powiodły się z powodu tymczasowych problemów, co może zwiększyć stabilność aplikacji.
Można skonfigurować po kilku próbach circuit braker open.
RateLimiter Pattern
- Ogranicza liczbę zapytań do danej usługi w określonym czasie, co jest użyteczne do ochrony usług przed przeciążeniem.
- chroni przed DDOS
- ZWRÓCI 429 TO MANY REQUEST
Bulkhead
Izoluje elementy w systemie, tak aby awaria jednego elementu nie prowadziła do awarii całego systemu. Działa poprzez ograniczenie zasobów przydzielonych do poszczególnych usług lub zadań.
Czym jest Observability ?
- obserwowanie wewnętrznego działania, stanu mikroserwisu
- umożliwa identyfikowanie problemów z wydajnośćia, działaniem
- optymalizacja wydajności
- zapewnienia niezawodności
- Logi - zapisy wydarzeń które miał miejsce w systemie
- Metryki - wykorzystanie CPU, pamięci, latency
- Traces - zapisy indywidualnych transkacji lub przepływów przez system.
Czym jest Monitoring ?
- ciągłegy proces zbierania , analizowania i interpretowania różnych danych związanych z działaniem systemu
- celem jest zapewnienie ciąglóści działania, wydajności, bezpieczeństwa
- Zbieranie danych - zbieranie danych jak metryki, wydajności, logi
- Wykrywanie anomali -
- Alarmy i powiadomienia - powiadamiają o problemach
- Anliza Trendów
Monitoring vs Observability
Grafana, Loki & Promtail
- narzędzia do vizualizacji metryk, logów oraz traces
1. **Grafana Loki **- log aggregation system.
2. Promtail - zbiera logi z kontenerów i przesyła do Loki
3. Grafana - UI aplikacja
Micrometer, Prometheus, Grafana Actutator
- Actuator - udostępnia metryki pod endpointami
- Micrometer - przetwarza format metryk Actuatora na format Proemetheus
- Prometheus - agreguje metryki z konreneró.
- Grafa - wizualizuje
Jak zarządzać transakcjami i spójnością danych w systemie opartym na zdarzeniach ?
- Kompensacyjne transkacje
- Saga Pattern - każda transkacja zależy od wyniku poprzedniej.
- Event Sourcing
Eventual Consistency
- oznacza, że system może nie być spójny w każdym momencie czasu, ale osiągnie spójność po pewnym czasie, gdy wszystkie operacje zostaną wykonane.
- W architekturze opartej na zdarzeniach, gdzie zdarzenia są asynchroniczne, Eventual Consistency jest naturalnym modelem spójności.
