Czy warto w tym przypadku dzielić mikroserwis na mniejsze

Jest u nas mikroserwis X, który integruje się przez różne api do systemów zewnętrznych A,B,C,D… itd.
I teraz ten system X ma takie flow działania, że (wyimaginowany przykład) jak wyślemy request do niego żeby coś „kupić” to on w zależności od tego co chcemy „kupić” zintegruje się z jednym z tych zewnętrznych systemów. Czyli można powiedzieć, że jest takim jakby gatewayem, który ma jedno zunifikowane api i pod spodem tłumaczy to na api systemów zewnętrznych, które mogą być różne czyli jakby ukrywa pewne complexity.
I teraz powstał pomysł aby ten mikroserwis X rozdzielić na mniejsze tj. X.A, X.B, X.C itd. każdy z nich byłby odpowiedzialny za komunikację tylko z jednym systemem zewnętrznym.

Zaletami tego mają być to, że np. jak coś się zmieni w api do A to tylko zmieniamy i wdrażamy X.A a nie wszystko i nie robimy regresji dla wszystkiego. Kolejna rzecz to jak np. będzie więcej ruchu do B to wtedy można przeskalować tylko X.B a nie wszystko.

Zastanawiam się czy takie rozdrabnianie się ma sens i czy nie doda tylko niepotrzebną złożoność bo przecież X -> X.A, X.B, X.C też muszą się jakoś komunikować?

lookacode1 napisał(a):

Zaletami tego mają być to, że np. jak coś się zmieni w api do A to tylko zmieniamy i wdrażamy X.A a nie wszystko i nie robimy regresji dla wszystkiego. Kolejna rzecz to jak np. będzie więcej ruchu do B to wtedy można przeskalować tylko X.B a nie wszystko.

Zalety, zaletami, ale czy macie z tego tytułu jakieś problemy w chwili obecnej? Czy komplikuje wam to deploymenty? Czy macie problem ze skalowaniem i zarządzaniem ruchem? Jeśli nie to bym zostawił jak jest i dzielił w momencie, jeżeli faktycznie pojawią się jakieś ograniczenia i będziecie mieć faktyczny powód do zmiany. Tak, to tylko narobicie sobie roboty i problemów, rozwiązując problemy które mogą w ogóle nie nastąpić.

Tak, ma to sens. Warto, jeśli czujecie, że wam to pomoże. Problemy przy takim podejściu:

• potrzeba nadrzędny serwis, który będzie ogarniał tą całą hałastrę
• skoro serwisy są podobne, to pewnie będzie dużo zduplikowanego kodu. Alternatywą jest używanie jakiś wspólnych bibliotek ale to ciężki problem

Zakładając, ze macie już mikroserwisy, to ma to jakiś sens. Problem jaki widzę, to to, że wewnętrzna architektura systemu jest zdefiniowana przez odpowiedzialności jakichś kawałków na zewnątrz. Jeżeli jakaś funkcja zostanie przeniesiona z serwisu A do B, to będziecie też przenosić ten kawałek adaptera z X.A do X.B, a w ślad za tym co ktoś zrobił w swoich systemach? Sensowniej byłoby dzielić ten adapter po odpowiedzialnościach widzianych od wewnątrz (funkcjach biznesowych).

Sensowniej byłoby dzielić ten adapter po odpowiedzialnościach widzianych od wewnątrz (funkcjach biznesowych).

@piotrpo: z jednej strony tak, z drugiej strony komunikacja z jednym zewnętrznym API może mieć dużo części wspólnych i trzymanie tej części na poziomie jednego serwisu ma sens. Mój aktualny projekt to własnie coś takiego: serwis per dostawca (w dużej ilości tj. kilkadziesiąt) i nadrzędne serwisy per feature wołające te serwisy. Moja obserwacja jest taka, że problem jest ciężki: jest dużo części wspólnych, które chciałoby się umieścić w jakiś wspólnych bibliotekach. A taka kombinacja "serwisy x biblioteki: jest ciężka do utrzymania, jeśli nie trzyma się odpowiedniego rygoru

Jeżeli jakaś funkcja zostanie przeniesiona z serwisu A do B, to będziecie też przenosić ten kawałek adaptera z X.A do X.B, a w ślad za tym co ktoś zrobił w swoich systemach?

Nie taki przypadek nie może mieć miejsca.
A i B wgl nie wiedzą o sobie to jest coś na zasadzie np. A - Netflix i B - Tidal.

@slsy: @lookacode1
Nie wiem jak jest w waszych konkretnych przypadkach. Rolą takiego serwisu jest izolacja tego co na zewnątrz od tego co wewnątrz. Usługa wewnątrz powinna wiedzieć, że ma się zwrócić do serwisu "Muzyka", lub "Film" a adapter od strony wewnętrznego API powinien gwarantować stałość kontraktu. Dlatego podział na usługi powinien wynikać od tego co jest wewnątrz systemu, a nie z tego co jest na zewnątrz.
Ogólnie pytanie kiedy dzielić coś na usługi nie jest proste. IMO, błędem jest podejście dzielenie na osobne usługi tylko ze względu na lepsze zarządzanie kodem. Jak pisze @slsy - to potencjalnie prowadzi do większego bałaganu i stwarza więcej problemów niż rozwiązuje. Powody dla których warto dokonywać takich akcji to:

• skalowalność, pod warunkiem, ze usługa daje się skalować i istnieje taka potrzeba

• niezawodność, czyli pada nam usługa od filmów, ale muzyka nadal działa - pytanie czy rzeczy wewnątrz są na taki scenariusz przygotowane, czy też jak walnie jeden z klocków to i tak wszystko przestaje działać, albo co gorsza nikt nie wie co wtedy przestanie działać

• obszar zmian, czyli można wrzucić poprawki (hot fix) jakiejś usługi i mieć pewność, że reszta nie przestanie działać.

• istnieje powód, żeby użyć jakiejś innej technologii - cały system w Javie, a tutaj najlepiej użyć jakiegoś Pythona, bo mamy komponent AI, albo jakiegoś narzędzia do integracji typu Pentaho.

  Co do bibliotek, to ogólnie nie ma problemu z ich używaniem, o ile to są "biblioteki", wiadomo co robią, po co, mają zdefiniowane swoje kontrakty i są utrzymywane tak jak się utrzymuje biblioteki - wersje, kompatybilność wsteczna. Problem jest w momencie kiedy zamiast "biblioteki" mamy zapakowane w osobne repo trochę klas wykorzystywanych we wszystkich innych miejscach systemu i na koniec okazuje się, że żeby całość działała, to wszystkie serwisy musza używać tej samej wersji biblioteki.