Microservices: jak zintegrować interfejs użytkownika?

Question

Dzisiaj zacząłem czytać o architekturach Microservice - i wydaje się to bardzo interesujące! Mam jednak jedną wątpliwość, że potrzebuję trochę ekleniacji na: Załóżmy, że chcę utworzyć bloga i zbuduję 4 mikroserwisy do tego: Usługa użytkownika/logowania, Usługa artykułu, Usługa komentarzy i Usługa raportowania/analityki (nie jest to realistyczny przykład, I wiedzieć...). Usługa raportowania/analityki ma charakter czysto backendowy - tutaj nie ma problemu z mojej strony. Ale trzy pozostałe obejmują pewną część UI - i jeśli chodzi o moje zrozumienie ta część UI powinna być częścią samej mikroserwisu, prawda? Jak działa integracja interfejsu użytkownika? Czy miałbym wtedy piątą usługę "front door", która zbiera żądania użytkowników, przekazuje je innym usługom, które następnie odpowiadają za pomocą HTML/CSS, a usługa drzwi wejściowych mogłaby następnie skomponować indywidualne odpowiedzi na to, co zostanie zwrócone użytkownikowi?

Jakąkolwiek zmianę masz przykład/przypadek użycia dla takiego scenariusza?

Dzięki i pozdrawiam!

Answer 1

Z mojego doświadczenia wynika, że ​​w architekturze mikroserwisów często przydatne jest posiadanie usługi, która działa jak bramka API, którą front ładuje do mikrousługów bardziej specyficznych dla domeny, które wykonują pracę. Odpowiedzialność bramki API może polegać na agregowaniu wyników i zwracaniu ich do interfejsu użytkownika, ale konsolidacja odpowiedzi zwracanych z mikrousługi polegałaby na połączeniu wiedzy o tych dwóch usługach i przeniknięciu wiedzy niektórych dziedzin do warstwy bramy API. Brama API powinna być możliwie najcieńsza i powinna dotrzeć do usług, aby coś osiągnąć.

Opisany tu przypadek użycia będzie próbą uwierzytelnienia użytkownika przed skontaktowaniem się z usługą logowania, a następnie z usługą dotyczącą artykułu lub komentarzy. W sumie przedni koniec nadal pozostanie monolityczny, jeśli będzie częścią tego samego zastosowania.

Jeśli aplikacja będzie wystarczająco duża, aplikacja będzie oddzielona produktami, ale prawdopodobnie nadal będzie polegać na podstawowym zestawie usług. W takim przypadku prawdopodobnie będą żyć w różnych interfejsach, co sprawi, że będzie mniej skomplikowany (rodzaj mikroserwisów na zapleczu). Tak na marginesie, że architektura mikroserwisów zwykle wprowadza zestaw podstawowych usług, które mogą być wykorzystywane przez różne zespoły, a zatem różne aplikacje, które mają różne interfejsy. Przykładem może być aplikacja e-commerce, w której dział obsługi klienta edytuje zamówienia na obsługę klientów i klientów przy użyciu usługi zamówień w celu dokonania zakupów. W efekcie są to dwie aplikacje i będą miały dwa różne interfejsy. Mam nadzieję że to pomoże!

Inną rzeczą, na którą chciałbym zwrócić uwagę, jest to, że architektura mikroserwisów sprawdza się doskonale tylko wtedy, gdy aplikacja staje się zbyt duża i złożona. Architektura mikroserwisów wymaga więcej zasobów, ponieważ ma dodatkowe obciążenie. Zacznij od monolitycznego pierwszego :).