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:

1. CustomerService – podstawowe informacje o klientach
2. AddressService – wyszukiwarka adresów
3. 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.