Architektura mikro usług metodą naukową

W każdym projekcie, tym bardzo daleko, ale też tych zupełnie blisko (w sumie nawet w tych w pokoju obok) ktoś próbuje rozproszyć istniejący system informatyczny… albo napisać nowy – już rozproszony. Przybiera to wiele różnych nazw, wiele postaci: mikroserwisy, współdzielona baza danych, rozproszona baza danych, asynchroniczne kolejki.

Ok. Decyzja jak decyzja, spróbujmy na początek jej nie oceniać, ale przeanalizujmy jej skutki. Co zyskamy? Co tracimy? Co może się nie udać? Czy powinniśmy się spodziewać nieoczekiwanych problemów? Czy możemy im zapobiec? I czy te problemy naprawdę są takie nieoczekiwane?

Nie są! Ale nie dostrzegamy ich dopóki nie zejdziemy z naszej wieży z kości słoniowej i spojrzymy na system nie z wysokości 30 tysięcy stóp, ale przyjrzymy się pojedynczym śrubkom i nitom, gdzieś blisko metalu. Okazuje się że jest wiele reguł i praw które regulują jak nasz system będzie się zachowywał. Przyglądnijmy się co to może być:

1. Czy latencja jest problematyczna? Zacznijmy od prostych rzeczy
2. Jeżeli to jest problem, to czy zawsze powinienem się odwoływać do najbliższego węzła? Jak to zrobić? Czy są jakieś reguły – może, skoro CDNy jakoś działają
3. A skoro już rozproszyliśmy nasz system, to jaka liczba węzłów to „wystarczająco”? Z punktu widzenia dostępności? Z punktu widzenia spójności danych? Czy to w ogóle powinno mieć znaczenia?

Na każde z tak stawianych pytań bardzo łatwo jest znaleźć odpowiedź w google. 3, 7, 42 – jest wiele odpowiedzi, ale spróbujemy pójść poziom głębiej. Bo za każda wartością podaną na stackoveflow powinna stać metoda naukowa, eksperyment, czasem wręcz wzór matematyczny – i takich właśnie odpowiedzi będziemy poszukiwać podczas tej sesji.

powrót