Jak radzisz sobie ze wspólnymi koncepcjami w architekturze mikrousług?


39

Badam wzorce architektoniczne dla opracowywanej przeze mnie aplikacji, a podejście oparte na mikrousługach wydaje się być dobrym wyborem, ale nie jestem pewien, jak poradzić sobie z interakcjami między usługami.

Aplikacja zajmuje się przede wszystkim użytkownikami, profilami użytkowników, zdjęciami i tagami reprezentującymi jeden lub wiele profili na zdjęciu. Możliwe są metody zwracania zdjęć przesłanych przez użytkownika, zwracania zdjęć zawierających określony otagowany profil itp.

To moje pierwsze doświadczenie w projektowaniu architektury opartej na mikrousługach i wywodzę się z historii inspirowanej modelem domeny monolitycznej . W tym świecie kontrolery połączyliby te obiekty domenowe razem, ale mam problem z owinięciem głowy, jak to by działało w sposób mikrousługowy.

Odpowiedzi:


34

Zwykle usługi dzwonią do innych usług, gdy potrzebują dostępu do swoich danych. Każda część danych powinna należeć do określonej usługi, która będzie jedynym punktem dostępu do dostępu do tych danych i ich modyfikacji. Niektóre usługi będą proste i zwykle będą ściśle odpowiadać modelowi domeny (np. Usługa do obsługi użytkowników), podczas gdy inne będą na wysokim poziomie i będą wykorzystywać dane z innych usług (np. Wyświetlanie listy zdjęć wraz z informacjami o użytkownikach, którzy je przesłali) ).

W przypadku użycia powinieneś zacząć od zewnątrz i zastanowić się, jakie operacje chcesz udostępnić użytkownikowi za pośrednictwem interfejsu API (jeśli jest to usługa zaplecza) lub jakie operacje powinny być dostępne w interfejsie GUI, jeśli jest to aplikacja internetowa. Zauważ, że część GUI jest często zwykłą aplikacją z własnymi kontrolerami: operacje mogą być wywoływane przez REST (jak w AngularJS), ale te punkty końcowe są zaprojektowane tylko do użytku aplikacji GUI i nie są mikrousługami w zdrowym znaczeniu.

Załóżmy, że chcesz wyświetlać zdjęcia wraz z informacjami o przesyłających. Możesz mieć usługę użytkownika, która zwraca informacje o użytkowniku z podanym identyfikatorem użytkownika oraz usługę fotograficzną, która może wyświetlać zdjęcia (np. Poprzez wyszukiwanie według niektórych kryteriów). Lista zdjęć zawierałaby dla każdego zdjęcia identyfikator przesyłającego użytkownika. W ten sposób te dwie usługi nie są powiązane - usługa fotograficzna wie tylko o identyfikatorach użytkowników, ale nic o samych danych użytkownika. Oprócz tych dwóch usług można utworzyć trzecią usługę z operacją, taką jak „wyświetlanie listy zdjęć z informacjami o przesyłających”, która łączy dwie pozostałe usługi i łączy dane, które zwracają. Alternatywnie, tę operację może wykonać aplikacja internetowa zamiast usługi.


1
To mi bardzo pomogło. Zacząłem od napisania kilku przypadków użycia interfejsu użytkownika, które sprawdzałyby stos i wszystko w większości się układało.
anjunatl

1
W tym konkretnym przykładzie powinniśmy zrobić np. 10 połączeń z serwisem użytkownika w celu uzyskania danych użytkownika, jeśli mamy 10 zdjęć na naszej liście? Czy nie spowodowałoby to dużych kosztów ogólnych?
Ricardo Souza

1
@rcdmk Możesz dodać punkt końcowy REST, który pobiera listę wielu identyfikatorów jako dane wejściowe i zwraca wiele zdjęć jako dane wyjściowe. Jest to często wykonywane w praktyce ze względu na wydajność. Czasami projektowanie API jest kompromisem między czystością a względami praktycznymi.
Michał Kosmulski

@ MichałKosmulski Muszę rozpocząć dyskusję, ale zniechęca ich projekt StackExchange :) W tym konkretnym przykładzie nie podoba mi się podejście oparte na mikrousługach. Bezpośrednie zapytanie do bazy danych (w której przechowywane są użytkownicy i obrazy) może być znacznie wydajniejsze. Wyobraź sobie, że te usługi upstream zależą od innych usług upstream i tak dalej. Bezpośrednie zapytanie do magazynu danych jest znacznie bezpieczniejsze. tylko moje 5 centów - nic więcej. Znowu bardzo chciałbym prowadzić produktywną dyskusję na ten temat, ale StackExachange nie jest na to dobrym miejscem (czy możesz polecić fora dyskusyjne dotyczące
mikrousług

@ajukraine Myślę, że na stackexchange są czaty, które mogą być dobrym miejscem do dyskusji. Jeśli chodzi o wydajność: 1. Mikrousługi wiążą się z kosztem wydajności, a 2. Mikrousługi są dobre w niektórych sytuacjach, ale nie w innych. Jeśli chodzi o zależności: w architekturze mikrousług często wykonujesz lokalne kopie danych i używasz asynchronicznego przesyłania komunikatów w celu zmniejszenia liczby zależności. To prawdziwa zmiana architektury, nie tylko automatyczna zmiana każdego modułu aplikacji na osobną aplikację.
Michał Kosmulski

4

Aplikacja zajmuje się przede wszystkim użytkownikami, profilami użytkowników, zdjęciami i tagami reprezentującymi jeden lub wiele profili na zdjęciu. Możliwe są metody zwracania zdjęć przesłanych przez użytkownika, zwracania zdjęć zawierających określony otagowany profil itp.

Usługa profilu nie powinna działać z obiektem użytkownika. Może znać tylko identyfikator użytkownika, dla którego jest proszony o zwrócenie danych, nie więcej. W ten sposób nie będzie wymagana interakcja między usługą użytkownika a usługą profilu.

Jeśli to nie odpowiada na twoje pytanie, czy możesz to wyjaśnić, opisując dokładnie sytuację, z którą masz do czynienia?


To i odpowiedź Michała pomogła mi to zrozumieć, ale jego sugestia pomogła mi zaplanować usługi, których potrzebowałem. Utknąłem w myśleniu, że muszę reprezentować pełny obiekt zamiast tylko odniesienia do obiektu (obiekt użytkownika kontra identyfikator użytkownika). Bardzo dziękuję, dziękuję!
anjunatl

@anjunatl Witamy;)
Vladislav Rastrusny
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.