Mamy jeden mikroserwis i jest on połączony z wieloma innymi, jeśli jeden padnie to jakie są sposoby aby się przed tym zabezpieczyć?
Do głowy mi przychodzi cachowanie i np. load balancer, może ktoś się wypowiedzieć z praktycznego punktu widzenia takich sytuacji?
Dzięki
0
1
Do głowy mi przychodzi cachowanie i np. load balancer
to są jakieś narzędzia do wykorzystania. czasem można je łączyć.
oprócz tego możesz wykorzystać komunikację asynchroniczną po kafce i założyć, że kafka nie padnie :) dzięki kafce możesz wysłać wiadomość na topic i np. zorganizować kod tak, że wiadomość będzie tam siedzieć dopóki nie zostanie w pełni obsłużona.
1
Jak padnie jedna instancja, to LB powinien automatycznie ja odpiac. Haslo do wyguglowania: load balancer i health check. Nie, nie potrzebujesz do tego Kafki ;D
Od strony klienta zabezpieczeniami są glownie retry’e i timeouty, zwykle dodaje sie rowniez circuit breakera. Mozna rozwazyc implementacje fallbacka i cache.
2
Co mówią żeby mieć zanim zacznie się robić mikroserwisy? INFRASTRUKTURĘ!
https://martinfowler.com/bliki/MicroservicePrerequisites.html
Jak się firma dorobi k8s to w konfigu wpiszesz że mają być 3 instancje i więcej Ciebie nie będzie obchodzić...
Przy 1 to masz większe problemy:
- Jak zrobisz deploy tak żeby nie było błędów?
- Co jak poleci OOM? Czy usługa po prostu zdechnie i nic jej nawet nie będzie próbowało podnosić?
Zróbcie to porządnie na k8s lub Docker Swarm tak żeby wszystkie usługi były w wielu instancjach. Ponieważ to będą kontenery to nie będzie aż tak dużego kosztu jak przy maszynach fizycznych. Dodatkowo można wtedy robić "rolling" restarty i "blue-green" deploymenty.
1
Pytanie jest zbyt ogólne żeby coś konkretnego doradzić. Takie standardowe podejścia:
- Wiele instancji każdego serwisu, stojących za load balancerem. Każda taka instancja śle jakieś heartbeat albo ma endpoint do sprawdzania czy żyje. Jak umrze to wylatuje z load balancera, a jak ożyje to znów wraca. To oczywiście zawiedzie, jeśli akurat trafisz na okno czasowe gdzie serwis już leży a LB jeszcze nie wie :( i musisz mieć po swojej stronie jakieś
retry. - Operacje realizowane asynchronicznie - twoja akcja nie komunikuje się bezpośrednio z docelowym serwisem, tylko np. wrzuca request na jakaś kolejkę, z której serwisy wyciagaja sobie i obsługują a potem robią callback do ciebie z odpowiedzią. Dzięki temu w ogóle nie obchodzi cię jak jakiś serwis umrze. Nadal niby może umrzeć kolejka, ale to mało prawdopodobne. Jednocześnie to oczywiscie komplikuje obsługę "synchronicznych" operacji, bo teraz musisz np. blokować i czekać aż nie przyjdzie callback i musisz mieć jakis timeout.
- Generalnie takie podejście z wieloma instancjami ma też inne wady - np. utrzymanie spójnosci danych albo jakiegoś szybkiego memory-cache jest trudne, bo twoje requesty idą losowo do różnych instancji. Można czasem to jakos usprawnić, mając jakiś dodatkowy serwis ogarniający routowanie requestów, tak zeby cała sesja leciała (w miarę możliwości) do jednego noda.
0
mariusz00 napisał(a):
Mamy jeden mikroserwis i jest on połączony z wieloma innymi, jeśli jeden padnie to jakie są sposoby aby się przed tym zabezpieczyć?
Tak jak ci pisali - albo przez zerwanie zależności od innych mikroserwisów, albo przez zwielokrotnienie instancji i schowanie za loadbalancerem. Najprościej pewnie w zrobić to w kubernetesie, ogarniając przy okazji skalowanie. Ogólnie usługa powinna być w stanie obsłużyć żądanie bez komunikowania się z kaskadą innych usług.
Do głowy mi przychodzi cachowanie i np. load balancer, może ktoś się wypowiedzieć z praktycznego punktu widzenia takich sytuacji?
Dzięki
Ten myk z kafką, to takie trochę cache, gdzie topic/kolejka robi za cache. W tej chwili modne jest Event Sourcing, czyli zakładając, że operacja dotyczy zapisu, ten twój mikroserwis wrzuca komendę zmiany danych na topic, wszystkie serwisy, które tych danych potrzebują, "kiedyś" sobie tę komendę odczytają i zrobią update. Jak podnosi się nowa instancja, to przetwarza dane od początku topica posiłkując się jakimiś snapshotami.