Podejście na komponenty Microservice

Question

Mam pytanie do społeczności mikroserwisów. Podam przykład z dziedziny edukacji, ale dotyczy to każdej architektury mikroserwisów.

Powiedzmy mam Student-usługę i licencjonowania usług z wymogiem biznesowym, że liczba studentów jest ograniczona przez licencję. Więc za każdym razem, gdy uczeń jest tworzony, musi zostać sprawdzona licencja. Istnieje wiele rodzajów licencji, więc typ licencji musiałby zostać uwzględniony w operacji.

Moje pytanie brzmi: które podejście znalazłeś to lepiej w praktyce:

1. Budowa kompozytowego usługę, która wywołuje usługi 2
2. Sprzęgło Student-service licencjonowaniu-usługi tak, że kiedy createStudent nazywa się Student usług sprawia, że ​​wezwanie do licencjonowania usług i jedynie wówczas, gdy zostanie zakończona student być tworzone
3. Użyj architekturę opartego na zdarzeniu

peop Mówię o architekturach mikroserwisowych bardziej przypominających wykres niż o hierarchii, a opcja 1 zmienia się w hierarchię, w której dostajemy coraz grubsze kompozyty. Inne wady powodują niejasności co do tego, jakich usług klienci powinni faktycznie używać i istnieje pewne powielanie, ponieważ interfejs API kompozytów musi zawierać wszystkie parametry potrzebne do wywołania usług niższego rzędu. Ma to dużą zaletę, ponieważ daje naturalne miejsce do obsługi awarii, choreografii i zachowania spójności.

Opcja 2 Wygląda na to, że ma wady też:

• API licencjonowania musiałby przedostać się do API studentów, dzięki czemu można określić ograniczenia licencyjne.

• stawia wiele obciążeń na studenta-usługi, ponieważ musi obsługiwać spójność we wszystkich usług zależnych

• jak więcej usług trzeba reagować, gdy student jest tworzony widziałem wykres zależności szybko wymknięcie się spod kontroli i usługa będzie musiała obsłużyć tę złożoność oprócz tej z własnej logiki zarządzania studentami.

Wariant 3 Będąc oddzielenie nieba, ja naprawdę nie sądzę, by działać, ponieważ to wszystko jest wyzwalany z UI i ludzie naprawdę nie są używane do „idź zrobić coś innego, dopóki to nowy uczeń zjawia " podejście.

Dziękuję

Answer 1

licencjonowaniem aplikacji oraz tworzenie studenci są prostopadłe więc opcja 2 nie ma sensu.

Opcja 1 jest bardziej rozsądna, ale staram się nie budować innej usługi. Zamiast tego spróbuję "odfiltrować" połączenia z usługami studenckimi za pośrednictwem oprogramowania pośredniczącego licencjonowania.

W ten sposób można użyć tego oprogramowania pośredniego do innych wywołań serwisowych (np.usługi klasy) i zmiany w API zarówno licencjonowania, jak i studentów mogą być wykonywane niezależnie, ponieważ te rzeczy są naprawdę niezależne. Zdarza się, że licencjonowanie wykorzystuje liczbę studentów, ale może to łatwo ulec zmianie.

Nie jestem pewien, w jaki sposób opcja 3, podejście oparte na zdarzeniach może w tym pomóc. Może jednak rozwiązać inne problemy.

Answer 2

IMHO, wybrałbym opcję 2. Kilka rzeczy do rozważenia. Jeśli kupujesz kompletnie w SOA, a także w mikroserwisach, nie możesz się wzdrygnąć za każdym razem, gdy usługa potrzebuje skontaktować się z inną usługą. Czuć się komfortowo z tym .... pamiętaj o co chodzi. To, co naprawdę podoba mi się w przypadku opcji 2, to to, że pomyślna odpowiedź typu student-usługa nie jest wysyłana, dopóki żądanie usługi licencyjnej nie powiedzie się. Traktuj usługę licencyjną jako dowolną inną usługę zewnętrzną, w której można zawijać usługę licencjonowania w obiekcie klienta, który może zostać opublikowany przez plik JAR licencji.

• Interfejs API licencjonowania musiałby przeciekać do interfejsu API ucznia, aby można było określić ograniczenia licencjonowania.

Tak, użyty zostanie interfejs API usługi licencyjnej. Możesz nazwać to wyciekiem (ktoś musi go użyć) lub hermetyzacją, aby klient żądający usługi studenckiej nie musiał się martwić o licencję.

• kładzie dużo obciążenie studenta-usługi, ponieważ musi obsługiwać spójność we wszystkich usług zależnych

Niektóre usługi ma podjąć tego ciężaru. Ale będę to zarządzać organicznie. Mówimy o 1 służbie, która wymaga innej. Jeśli to rośnie i staje się konkretnie kłopotliwe, można dokonać refaktoryzacji. Jeśli liczba usług potrzebnych do nauki przez studenta rośnie, myślę, że można je elegancko refaktoryzować, a być może usługa studencka staje się usługą złożoną, a grupy niezależnie używanych usług mogą być w razie potrzeby skonsolidowane w nowe usługi. Ale jeśli lista usług zależnych, z których korzysta student, jest wykorzystywana wyłącznie przez studentów, to nie wiem, czy warto ją zgrupować w swoją własną usługę. Myślę, że zamiast obciążeń i przecieków można na to spojrzeć jako na hermetyzację i własności ... gdzie studencka usługa jest właścicielem tego obciążenia, więc nie musi przeciekać do innych klientów/usług.

• jak więcej usług trzeba reagować, gdy student jest tworzony mogłem zobaczyć na wykresie zależność szybko wymyka się spod kontroli, a usługa będzie musiał obsługiwać tę złożoność oprócz jednego z własnej logiki do zarządzania studentów.

Alternatywą byłyby różne usługi złożone. Podobnie jak moja odpowiedź na poprzedni punkt kulisy, można to potraktować elegancko, jeśli stanowi prawdziwy problem.

W razie wymuszenia każdą z opcji można przekształcić w opłacalne rozwiązanie. Zgłaszam uzasadniony wniosek w sprawie opcji 2.

Answer 3

Wiem, że pytanie zostało zadane jakiś czas temu, ale myślę, że mam coś do powiedzenia, które może mieć tutaj wartość.
Po pierwsze, twoje podejście będzie zależeć od ogólnego rozmiaru Twojego produktu końcowego. Mam do czynienia z pewną regułą: jeśli miałbym zbyt wiele zależności między poszczególnymi mikro-usługami, zwykle używam czegoś, co uprościłoby i prawdopodobnie usunęło te zależności. Nie chcę skończyć z pajęczą siecią usług! Warto tutaj spojrzeć na kolejki wiadomości, na przykład RabbitMQ.
Jednak, jeśli mam tylko kilka usług, które ze sobą rozmawiają, po prostu nawiążę je do siebie nawzajem, ponieważ wszelkie alternatywne rozwiązania, upraszczając architekturę, dodadzą trochę kosztów związanych z przetwarzaniem danych i infrastrukturą.

Niezależnie od tego, z jakim podejściem zdecydujesz się wybrać, zaprojektuj swoje usługi w rozmiarze Hexagonal architecture! Pozwoli to zaoszczędzić Ci kłopotów, gdy zdecydujesz się na migrację z jednego rozwiązania do drugiego. To, co robię, to projektowanie moich DAO jako "adapterów", więc DAO, który wywołuje usługę A, albo wywoła je bezpośrednio, albo za pośrednictwem kolejki wiadomości, niezależnie od logiki biznesowej. Kiedy muszę to zmienić, mogę zmienić to DAO na inne, bez konieczności dotykania jakiejkolwiek logiki biznesowej (na koniec logika biznesowa nie dba o to, jak otrzyma dane). Sześciokątna architektura doskonale pasuje do testów mikroserwisowych, TDD i black-box.

Answer 4

Opcja 1 i 2 tworzy zwarte sprzężenie, którego należy unikać w jak największym stopniu, ponieważ chciałbyś, aby twoje usługi były niezależne. Pojawia się zatem pytanie:

Jak to zrobić w architekturze opartej na zdarzeniach?

1. Wykorzystuj zdarzenia do śledzenia informacji o licencjach z usługi licencjonowania w ramach usługi dla studentów, praktycznie duplikowanie danych. Wady są następujące: masz tylko ostateczną spójność, ponieważ duplikacja danych jest asynchroniczna.

2. Użyj zdarzeń asynchronicznych, aby wywołać łańcuch zdarzeń, które ostatecznie powodują utworzenie ucznia. Z Twojego pytania wynika, że ​​masz już pomysł, ale masz problem z interfejsem użytkownika. Masz tu dwie możliwe opcje: poczekaj na zdarzenie utworzenia studenta (lub awarii) z niewielkim czasem oczekiwania, lub (lepiej jeśli wydarzenie), spraw, aby system był całkowicie reaktywny (użyj mechanizmu push-client dla interfejsu użytkownika).