Microservices Flashcards
1
Q
Jakie są sposoby komunikacji między mikroserwisami ?
A
- synchroniczna - REST, gRPC
- asynchroniczna - kolejki, RabbitMQ,, Event driven architecutre
2
Q
Zalety synchronicznej
A
- natychmiastowa odpowiedź (klient otrzymuj odpowiedź natychmiast po przetworzeniu przez zerwer)
- łatwość debugowania (łatwiej śledzić przepływ rządań)
2
Q
Wady synchronicznej
A
- 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ść
2
Q
Zalety asynchronicznej
A
- 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
3
Q
Wady asynchronicznej
A
- złożoność wymagają brokerów
- trudniejsze w debbugowaniu trudniej śledzić asynchroniczny przepływ
- potencjalne opóźnienia
4
Q
Zalety mikroserwisów
A
- 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ść*
5
Q
Monolit
A
- jednolitość wszystkie komponenty są ściśle powiązane
- ## budowa -jedno duże oprogramowanie , wszystko w jednej bazie kodu, tylko jedna aplikacja
6
Q
Monolit vs Mikroserwisy
A
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
7
Q
Wady mikrosewisów
A
- 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
8
Q
Działanie architektury mikroserwisowej
A
9
Q
Service Discovery and registration
A
- 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
10
Q
API Gateway
A
- 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
11
Q
Czym jest loadbalancer
A
- 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
12
Q
Jak działa loadbalancer
A
- 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
13
Q
Algorytmy Load balancingu
A
- Round Robin:
- Least Connections
- IP Hash
14
Q
Round Robin
A
- 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.
15
Q
Least Connections:
A
- Żą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.
16
Q
Circuti Breaker
A
- 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)
17
Q
OpenFeign
A
- 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
18
Q
Saga
A
- 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
19
Q
Saga Choreography
A
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.
20
Q
EventSourcing
A
- 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.
21
Q
Even Sourcing przykład order-service oraz payment-service
A
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
22
Q
CQRS Pattern
A
- 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
23
Kiedy nie użyć mikroserwisów
- dla dużych i skomplikowanych projektów
- kiedy niska latencja jest priorytetem
24
Zasady projektowania mikroserwisów
1. **Modułowość**: Usługi powinny być samodzielne i mieć jeden, dobrze zdefiniowany cel.
2. **Skalowalność**: Usługi powinny być w stanie skalować się niezależnie, aby poradzić sobie z rosnącym obciążeniem.
3. **Decentralizacja**: System powinien być zdecentralizowany, pozwalając na luźno powiązane usługi.
4. **Wysoka dostępność**: Usługi powinny być zaprojektowane tak, aby były wysoce dostępne w celu zapewnienia niezawodności systemu.
5. **Odporność**: Usługi powinny być zaprojektowane tak, aby z wdziękiem radziły sobie z awariami.
6. **Zarządzanie danymi:** Usługi powinny zarządzać własnymi danymi i nie powinny współdzielić wspólnej bazy danych.
7. **Bezstanowośc**: Usługi powinny być bezstanowe, aby umożliwić łatwe skalowanie i buforowanie.
8. **Niezależne wdrażanie**: Usługi powinny być wdrażane niezależnie od innych usług.
9. **Obserwowalność**: System powinien mieć wbudowane funkcje monitorowania i rejestrowania, aby umożliwić wgląd w zachowanie systemu.
10. **Automatyzacja**: Wdrażanie, testowanie i skalowanie powinno być w jak największym stopniu zautomatyzowane.
25
Dlaczego mikroserwisy bezstanowe
1. **skalowalność** bezstanowe łatwiej skałować poziomo, dokładając więcej istancji
2. **Odporność** w razie awarii nie maja wpływu na reszte systemu
4. **Prostsze do wdrożenia i testowania**
26
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
27
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
28
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
-
29
Jak uruchomić Jar mavenem ?
`mvn spring-boot:run`
30
Jak uruchomić jar java ?
`java -jar .\target\accounts-0.0.1-SNAPSHOT.jar`
31
Jak zdbudować docker file
- mvn clean install -> create jar
- create Dockerfile
- docker build
- docker run
32
Wady Dockerfile
- przy dużej aplikacji bardzo skomplikowany
- duża wiedza devopsowa
33
google jib
34
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
35
Liveness Probe
- używne do sprawdzanie czy aplikacja wewnątrz kontenera działa
- Kubernetes podejmuje działania jak restart kontenera
- np. deadlock
36
Readiness probe
- kiedy kontener jest gotowy do przyjęcia ruchui sieciowego
- Kubernetes kieruje ruch do innego kontnera
37
Client side discovery
38
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 **
39
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)
40
Jak rozwiązać problem timeoutów ?
repsonse-time out w properistach
41
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.
42
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
43
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ń.
44
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
1. **Logi** - zapisy wydarzeń które miał miejsce w systemie
2. **Metryki** - wykorzystanie CPU, pamięci, latency
3. **Traces** - zapisy indywidualnych transkacji lub przepływów przez system.
45
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
1. **Zbieranie danych** - zbieranie danych jak metryki, wydajności, logi
2. **Wykrywanie anomali** -
3. **Alarmy i powiadomienia** - powiadamiają o problemach
4. **Anliza Trendów**
46
Monitoring vs Observability
47
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
48
Micrometer, Prometheus, Grafana Actutator
1. **Actuator** - udostępnia metryki pod endpointami
2. **Micrometer** - przetwarza format metryk Actuatora na format Proemetheus
3. **Prometheus** - agreguje metryki z konreneró.
4. **Grafa** - wizualizuje
49
Jak zarządzać transakcjami i spójnością danych w systemie opartym na zdarzeniach ?
1. **Kompensacyjne transkacje**
2. **Saga Pattern** - każda transkacja zależy od wyniku poprzedniej.
3. **Event Sourcing**
50
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.
