Największa zaleta mikro-serwisów, a mianowicie pojedyncza odpowiedzialność, często bywa również problemem, a raczej wyzwaniem. Załóżmy, że nasz system ma następujący mikro-usługi:
- CustomerService – podstawowe informacje o klientach
- AddressService – wyszukiwarka adresów
- CreditCardDetails – dane o kartach
Nie chce wymieniać tutaj długiej listy, ale wyobraźmy sobie, że mamy 10 usług co jest normą w przypadku mikro-serwisów. Często w celu wykonania jednej operacji (np. dokonanie płatności w sklepie internetowym), musimy zgromadzić informacje z różnych usług – np. w celu wystawienia faktury.
Oznacza to, że nasz klient będzie musiał łączyć się z wszystkimi nimi, w celu uzyskania danych. Rozwiązanie jest nie tylko wolne (liczba połączeń), ale i brzydkie – klient musi znać wewnętrzna architekturę naszych usług. Często kod po stronie klienta może przypominać spaghetti ze względu, że odwołuje się do tylu różnych usług
Innymi słowy, rozdrobnienie usług, a sposób w jaki klient je konsumuje zwykle jest różny. Dane o kliencie (ConsumerService) oraz o adresach zamieszkania (AddressService) zwykle konsumowane są jednocześnie i z punktu widzenia klienta, jest to nienaturalne, że pochodzą z dwóch różnych usług.
Z tego względu, warto rozważyć wzorzec gateway, który jest po prostu punktem centralnym i dostępowym do naszych mikro usług, o których klient nie powinien często nawet wiedzieć. Idea mikro-serwisów polega na możliwości ich wprowadzenia w każdym momencie, bez wielkich zmian po stronie klienta.
Jak widać z rysunku, implementacja gateway może sprowadzać się do zwykłego proxy. Klient wysyła zapytanie tylko do jednego punktu, a potem jest to już odpowiedzialność bramki, aby odpowiednio komunikować się z mikro-usługami.
Oczywiście nie możemy mieć logiki biznesowej w bramce. Jedynie co gateway zawiera to proxy, caching, autoryzacja i inne “cross-cutting concerns”, czyli problemy niezależne od usługi.
Gdybyśmy jakąś logikę wrzucili do gateway, to skończylibyśmy na starym monolitycznym SOA.
W następnych wpisach zajmiemy się implementacją bramki ponieważ nie jest to takie oczywiste. Często, szczególnie w przypadku REST, mamy do dyspozycji z różnymi typami klientów. Na przykład, aplikacja mobilna może nie potrzebować wszystkich danych na raz. Z tego względu, bramka powinna być zaimplementowana w sposób generyczny, eksponując różne API, w zależności od kontekstu.
Kolejnym zagadnieniem, którym musimy się zając jest agregacja danych, nierzadko z różnych usług. Jeśli mamy 10 usług, to klient może zażądać dowolnej kombinacji (np. CustomerService,CreditCardDetails lub CreditCardsService, AddressService).
Wynika z tego, że będziemy musieli opracować elastyczne rozwiązanie bo oczywiście nie jesteśmy w stanie zaimplementować sami wszystkim metod, biorąc pod uwagę, że w każdej chwili infrastruktura mikro-usług może zmienić się.
Dzięki takiemu rozwiązaniu, zachowamy łatwość w utrzymaniu i wdrażaniu usług, a jednocześnie nie będziemy mieli spaghetti po stronie klienta.
Seria zapowiada się ciekawie. Czekam na jakieś detale techniczne 🙂
mikro serwisy to złoooo 😀
Fajnie gateway opisany – niestety to co za nim ciagle kojarzy mi sie ze zlym SOA (blednie uzywanym). Mikro serwisy w liczbie 10 to jest cos normalnego ale juz dla wiekszych aplikacji. W mikroserwisach nie chodzi o to aby byly male (to blednie rozumiane micro w nazwie) tylko by zastapic duze monolityczne aplikacje (dla malych nie maja zbyt wiele sensu). Oczywiscie moge byc w bledzie i dla konkretnego przykladu wszystko jest ok ale ten CustomerService i addressService jakos mi tak sie gryza (chyba ze sa to tylko nazwy “serwisow” istniejacych w jednym mikroserwisie). Ogolnie polecam przeczytac https://www.tigerteam.dk/2014/micro-services-its-not-only-the-size-that-matters-its-also-how-you-use-them-part-1/
@marek:
Wiesz adres to nie tylko musi polegac na odczycie jednej tabeli danych, ale czesto jest to osobna baza danych, szyfrowana i na dodatek taka usluga laczy sie z inna usluga ktora dostarcza z kolei post code lookup. Zadanie jest wiec zupelnie innne niz CustomersService.