Gdzie powinna znajdować się logika biznesowa w architekturze mikrousług?

Wciąż próbuję owinąć głowę architekturą mikrousług, ponieważ jestem przyzwyczajony do monolitycznego podejścia

Załóżmy, że staramy się zbudować niezwykle uproszczony system rezerwacji Uber. Aby uprościć my powiedzmy mamy 3 obsługę oraz API bramy dla klienta: Booking, Drivers, Notificationi mamy następujący obieg:

Podczas tworzenia nowej rezerwacji:

1. Sprawdź, czy istniejący użytkownik ma już rezerwację
2. Uzyskaj listę dostępnych sterowników
3. Wyślij powiadomienie do kierowców, aby odebrać rezerwację
4. Kierowca odbiera rezerwację

Powiedzmy, że wszystkie wysyłanie wiadomości odbywa się za pośrednictwem połączenia http, a nie przez komunikator typu kafka, aby wszystko było proste.

W tym przypadku pomyślałem, że Bookingusługa może sprawdzić istniejącą rezerwację. Ale kto powinien otrzymywać listę dostępnych sterowników i powiadomień? Myślę o zrobieniu tego na poziomie bramy, ale teraz logika jest jakby podzielona na dwa miejsca:

• Gateway - pobierz listę dostępnych sterowników + wyślij powiadomienia
• Booking - sprawdź istniejącą rezerwację

I jestem prawie pewien, że brama nie jest właściwym miejscem, aby to zrobić, ale czuję, że jeśli robimy to w Bookingserwisie, staje się ściśle powiązana?

Aby to skomplikować, co się stanie, jeśli mamy inny projekt, który chce ponownie wykorzystać system rezerwacji, ale z własną logiką biznesową? Właśnie dlatego pomyślałem o zrobieniu tego na poziomie bramy, aby nowa brama projektu mogła mieć własną logikę biznesową oddzielną od istniejącej.

Innym sposobem, jak sądzę, jest to, aby każdy projekt miał własną usługę rezerwacji, która będzie rozmawiać z podstawową usługą rezerwacji, ale nie jestem pewien, jakie jest najlepsze podejście tutaj :-)

Ludzie często słyszą „mikro-usługę” i myślą „nano-usługa”, co może powodować pewne zamieszanie. Są mikro -services, więc nie trzeba osobny serwis dla każdego podmiotu. Wszystko, co próbujesz zrobić, powinno znajdować się w usługach bookingi notification. Nie potrzebujesz driverusługi (do żadnego z opisanych działań).

Uzyskiwanie listy sterowników dostępnych do rezerwacji należy do bookingusługi. Częstą pułapką jest nie grupowanie powiązanych działań w tę samą usługę, co nazywa się niską koherencją i jest bardzo złe. Pamiętaj, że grupujesz rzeczy w usługę według domeny problemu, a nie według podmiotu.

Teraz, jeśli chodzi o ponowne użycie, zaletą posiadania oddzielnej mikrousługi jest to, że teraz możesz mieć trzy oddzielne zespoły tworzące aplikacje dla konsumentów. Jeden zespół dla standardowej aplikacji HTML, aplikacji na Androida i aplikacji na iOS. Wszystkie te różne aplikacje mogą być budowane zupełnie inaczej i wyglądają odpowiednio do konkretnej platformy (bez powtarzania kodu). bookingKod serwisowy jest wykorzystywany przez wszystkie trzy z tych aplikacji, ponieważ wszystkie trzy aplikacje dokonać połączenia HTTP do usługi zamiast mającego swój własny kod rezerwacji.

Typowy przepływ rezerwacji wygląda następująco:

1. Aplikacja na Androida wywołuje bookingusługę, aby uzyskać listę dostępnych sterowników
2. Usługa rezerwacji zwraca listę aplikacji do aplikacji
3. Następnie użytkownik wybiera sterownik, a aplikacja wywołuje metodę „book” bookingusługi
4. bookingUsługowy wywołuje notificationusługę ze szczegółami rezerwacji
5. notificationUsługa wysyła powiadomienie do sterownika, powiadamiając go o rezerwacji
6. Aplikacja kierowcy wysyła komunikat do notificationusługi, gdy znajdują się w promieniu mili od klienta
7. notificationUsługa wysyła powiadomienie do klienta, że ich kierowca jest prawie

Mam nadzieję, że to pomogło; pamiętajcie, są to mikrousługi, a nie nanousługi, nie próbujcie dzielić tej samej problematycznej domeny. Tak więc, aby odpowiedzieć na tytuł pytania, kiedy utrzymujesz mikropłatność o odpowiednim rozmiarze, cała lub większość logiki biznesowej dla tej problematycznej domeny może istnieć w obrębie tej mikrousługi.

Wszystko zależy od twoich dokładnych wymagań.

Załóżmy, że masz dwie aplikacje dokonujące rezerwacji:

1. Pierwszy przypadek: jedna aplikacja może zezwolić jednemu użytkownikowi na wielokrotne rezerwowanie, a druga tylko na jednym. Oznacza to, że ograniczenie rezerwacji jest na poziomie aplikacji, jako że albo masz dwa punkty wejścia w systemie rezerwacji (jeden, który pozwala na wielokrotną rezerwację, jeden nie), albo po prostu sprawdzasz to w mikrousługach odpowiednich podanie.
2. Drugi przypadek: częścią definicji „rezerwacji” jest to, że użytkownik nie może mieć wielu, niezależnie od zastosowania, ta zasada obowiązuje dla całego systemu: oznacza to, że możesz umieścić czek w mikrousługi rezerwacji.

Jeśli chodzi o system powiadomień, możesz mieć mikrousługi rejestrujące się w Twojej usłudze rezerwacji, aby nasłuchiwać każdej nowej rezerwacji. W związku z tym mikrousługa rezerwacji powiadomi wszystkich subskrybentów i podejmie odpowiednie działania.

Jedynym problemem w tego rodzaju architekturze jest to, co dzieje się, jeśli coś się nie powiedzie po opublikowaniu powiadomienia, ponieważ dwie mikrousługi nie działają jak dwie funkcje wykonujące w tej samej transakcji bazy danych, będziesz musiał z wdziękiem obsługiwać błędy i ostatecznie odtwarzać procesy które zawiodły (automatycznie lub ręcznie)

Prosta odpowiedź jest taka, że ​​klienci mikrousług zarządzają logiką biznesową w „czystej” architekturze mikrousług. Aby ułatwić zrozumienie, rozważ jeszcze prostszy przykład. Usługa, która po prostu zwraca strumienie bajtów na podstawie identyfikatora URI. Samo w sobie nie jest to szczególnie przydatne. Bez jakiejkolwiek wiedzy o tym, które identyfikatory URI mają w sobie coś, możesz tylko zgadywać, gdzie coś wyciągnąć. Załóżmy teraz, że masz inną mikrousługę, która zapewnia funkcję wyszukiwania. Wysyłasz zapytanie z ciągiem zapytania, który zwraca identyfikatory URI. Teraz sprawy stają się bardziej interesujące. Mogę umieścić odniesienia do identyfikatorów URI dla pierwszej usługi w indeksie.

Ale nadal musimy jakoś skoordynować te dwa elementy. Odpowiedź jest prosta: używasz przeglądarki, aby pobrać identyfikatory URI z usługi indeksowania, a następnie pobrać dane z usługi danych. Żadna usługa nie „wie” o drugiej stronie i nie ma absolutnie żadnego związku między nimi. Mogę korzystać z usługi indeksowania z dowolną inną usługą danych i odwrotnie.

To niekoniecznie jest tak, że jest to najlepsze podejście we wszystkich scenariuszach, ale istnieje wiele korzyści z budowania tego w ten sposób, zwłaszcza ponownego użycia w scenariuszach, które nie są obecnie znane.