Jaki jest standardowy schemat koordynowania mikrousług?

Jeśli mikrousługa wie tylko o swojej własnej domenie, ale istnieje przepływ danych, który wymaga interakcji wielu usług w jakikolwiek sposób, jak to zrobić?

Powiedzmy, że mamy coś takiego:

• Fakturowanie
• Wysyłka

Dla celów argumentu powiedzmy, że po wysłaniu zamówienia należy utworzyć fakturę.

Gdzieś ktoś naciska przycisk GUI„Skończyłem, zróbmy to!” W klasycznej architekturze usług monolitycznych powiedziałbym, że istnieje albo ESBobsługa tego, albo usługa wysyłkowa ma wiedzę na temat usługi fakturowania i po prostu to nazywa.

Ale jak ludzie sobie z tym radzą w tym nowym, wspaniałym świecie mikrousług?

Rozumiem, że można to uznać za wysoce oparte na opiniach. ale ma to konkretną stronę, ponieważ mikrousługi nie powinny robić powyższego. Musi więc istnieć „co z definicji powinien zrobić”, który nie jest oparty na opiniach.

Strzelać.

Mikrousług Book Building szczegółowo opisuje style wymienione przez @RogerAlsing w jego odpowiedzi.

Na stronie 43 w sekcji Orchestration vs. Choreography książka mówi:

Gdy zaczynamy modelować coraz bardziej złożoną logikę, musimy zmierzyć się z problemem zarządzania procesami biznesowymi, które rozciągają się na granice poszczególnych usług. A dzięki mikrousługom osiągniemy ten limit wcześniej niż zwykle. [...] Jeśli chodzi o faktyczne wdrożenie tego przepływu, możemy zastosować dwa style architektury. W przypadku orkiestracji polegamy na centralnym mózgu, który kieruje procesem, podobnie jak dyrygent w orkiestrze. Dzięki choreografii informujemy każdą część systemu o jego pracy i pozwalamy mu dopracować szczegóły, podobnie jak tancerze, którzy odnajdują drogę i reagują na innych wokół w balecie.

Następnie książka wyjaśnia dwa style. Styl aranżacji odpowiada bardziej pomysłowi SOA na usługi orkiestracji / zadań , podczas gdy styl choreografii odpowiada głupim rurkom i inteligentnym punktom końcowym wspomnianym w artykule Martina Fowlera.

Styl aranżacji

W tym stylu powyższa książka wspomina:

Zastanówmy się, jak wyglądałoby to rozwiązanie dla tego przepływu. Tutaj prawdopodobnie najprostszą rzeczą byłoby, aby nasza obsługa klienta działała jako centralny mózg. Podczas tworzenia rozmawia z bankiem punktów lojalnościowych, usługami e-mail i usługami pocztowymi [...] za pośrednictwem serii wezwań / odpowiedzi. Sama obsługa klienta może następnie śledzić, gdzie klient jest w tym procesie. Może sprawdzić, czy konto klienta zostało skonfigurowane, czy wysłano wiadomość e-mail, czy dostarczono pocztę. Możemy pobrać schemat blokowy [...] i zamodelować go bezpośrednio w kodzie. Możemy nawet użyć narzędzi, które to nam zaimplementują, być może używając odpowiedniego silnika reguł. Do tego celu istnieją narzędzia komercyjne w postaci oprogramowania do modelowania procesów biznesowych. Zakładając, że używamy synchronicznego żądania / odpowiedzi, moglibyśmy nawet wiedzieć, czy każdy etap działał [...] Minusem tego podejścia do aranżacji jest to, że obsługa klienta może stać się zbyt dużym organem centralnym. Może stać się centrum w środku sieci i centralnym punktem, w którym zaczyna się logika. Zauważyłem, że takie podejście skutkuje niewielką liczbą inteligentnych „bożych” usług mówiących anemicznym usługom opartym na CRUD, co robić.

Uwaga: przypuszczam, że gdy autor wspomina o narzędziach, odnosi się do czegoś takiego jak BPM (np. Activity , Apache ODE , Camunda ). W rzeczywistości witryna wzorców przepływu pracy ma niesamowity zestaw wzorców do tego rodzaju aranżacji, a także oferuje szczegóły oceny różnych narzędzi dostawców, które pomagają w implementacji tego sposobu. Nie sądzę jednak, by autor sugerował, że wymagane jest użycie jednego z tych narzędzi do wdrożenia tego stylu integracji, można jednak użyć innych lekkich struktur aranżacyjnych, np. Spring Integration , Apache Camel lub Mule ESB

Jednak inne książki , które przeczytałem na temat Microservices i ogólnie większość artykułów, które znalazłem w sieci, wydają się nie podobać temu podejściu do aranżacji i zamiast tego sugerują użycie następnego.

Styl choreografii

W stylu choreografii autor mówi:

Dzięki podejściu choreograficznemu zamiast tego możemy po prostu sprawić, aby obsługa klienta emitowała zdarzenie w sposób asynchroniczny, mówiąc, że klient został utworzony. Usługa poczty elektronicznej, usługi pocztowe i bank punktów lojalnościowych po prostu subskrybują te wydarzenia i odpowiednio reagują [...] Podejście to jest znacznie bardziej oddzielone od siebie. Jeśli jakaś inna usługa musiała dotrzeć do stworzenia klienta, musi po prostu zasubskrybować wydarzenia i wykonać swoją pracę w razie potrzeby. Minusem jest to, że wyraźny obraz procesu biznesowego, który widzimy w [przepływie pracy], jest teraz tylko domyślnie odzwierciedlony w naszym systemie [...] Oznacza to, że potrzebne są dodatkowe prace, aby zapewnić, że możesz monitorować i śledzić, czy właściwe rzeczy mają stało się. Na przykład, czy wiesz, czy bank punktów lojalnościowych miał błąd i z jakiegoś powodu nie założył właściwego konta? Jednym z rozwiązań, które lubię sobie z tym poradzić, jest zbudowanie systemu monitorowania, który wyraźnie pasuje do widoku procesu biznesowego w [przepływie pracy], ale następnie śledzi, co każda usługa robi jako niezależna jednostka, pozwalając zobaczyć dziwne wyjątki odwzorowane na bardziej wyraźny przebieg procesu. [Schemat blokowy] [...] nie jest siłą napędową, ale tylko jedną soczewką, przez którą możemy zobaczyć, jak zachowuje się system. Ogólnie stwierdziłem, że systemy, które bardziej podchodzą do podejścia choreograficznego, są luźniej powiązane i są bardziej elastyczne i podatne na zmiany. Trzeba jednak wykonać dodatkową pracę, aby monitorować i śledzić procesy w granicach systemu. Odkryłem, że większość mocno zaaranżowanych implementacji jest wyjątkowo krucha, co wiąże się z wyższym kosztem zmian. Mając to na uwadze, zdecydowanie wolę celować w choreograficzny system, w którym każda usługa jest wystarczająco inteligentna, aby zrozumieć jej rolę w całym tańcu.

Uwaga: do dziś nie jestem pewien, czy choreografia to tylko inna nazwa dla architektury opartej na zdarzeniach (EDA), ale jeśli EDA jest tylko jednym ze sposobów, aby to zrobić, jakie są inne sposoby? (Zobacz także Co rozumiesz przez „sterowany zdarzeniami”? I znaczenie architektury opartej na zdarzeniach ). Wygląda też na to, że CQRS i EventSourcing bardzo dobrze współbrzmią z tym stylem architektonicznym, prawda?

Teraz przychodzi zabawa. Książka Microservices nie zakłada, że ​​mikrousług będą wdrażane z REST. W następnej części książki rozważają rozwiązania oparte na RPC i SOA, a na końcu REST. Ważną kwestią jest to, że Microservices nie implikuje REST.

A co z HATEOAS? (Hypermedia jako silnik stanu aplikacji)

Teraz, jeśli chcemy zastosować podejście RESTful, nie możemy zignorować HATEOAS lub Roy Fielding z przyjemnością powie na swoim blogu, że nasze rozwiązanie nie jest naprawdę REST. Zobacz jego post na blogu na temat interfejsu API REST. Musi być napędzany hipertekstem :

Denerwuje mnie liczba osób nazywających dowolny interfejs oparty na protokole HTTP interfejsem API REST. Co należy zrobić, aby wyjaśnić styl architektoniczny REST, że hipertekst jest ograniczeniem? Innymi słowy, jeśli silnik stanu aplikacji (a tym samym API) nie jest sterowany przez hipertekst, to nie może być RESTful i nie może być API REST. Kropka. Czy jest gdzieś zepsuty podręcznik, który należy naprawić?

Jak widać, Fielding uważa, że ​​bez HATEOAS tak naprawdę nie budujesz aplikacji RESTful. W przypadku Fielding HATEOAS jest właściwą drogą, jeśli chodzi o usługi orkiestracji. Właśnie się tego uczę, ale dla mnie HATEOAS nie określa jasno, kto lub jaka siła napędowa faktycznie podąża za linkami. W interfejsie użytkownika, którym może być użytkownik, ale w interakcjach między komputerami, przypuszczam, że musi to zrobić usługa wyższego poziomu.

Według HATEOAS jedynym łącznikiem, który naprawdę musi znać konsument interfejsu API, jest ten, który inicjuje komunikację z serwerem (np. POST / zamówienie). Od tego momentu usługa REST będzie przeprowadzać przepływ, ponieważ w odpowiedzi tego punktu końcowego zwrócony zasób będzie zawierał łącza do następnych możliwych stanów. Klient interfejsu API decyduje następnie, który link wybrać i przenieść aplikację do następnego stanu.

Pomimo tego, jak fajnie to brzmi, klient nadal musi wiedzieć, czy łącze musi zostać wysłane, wysłane, pobrane, poprawione itp. A klient nadal musi zdecydować, jaki ładunek przekazać. Klient nadal musi wiedzieć, co zrobić, jeśli to się nie powiedzie (spróbuj ponownie, zrekompensuj, anuluj itp.).

Jestem całkiem nowy w tym wszystkim, ale dla mnie, z punktu widzenia HATEOA, ten klient lub klient API jest usługą wysokiego poziomu. Jeśli uważamy to z punktu widzenia człowieka, można wyobrazić sobie użytkownika końcowego na stronie internetowej, który decyduje, które linki mają podążać, ale programista strony musiał zdecydować, jaką metodę użyć, aby wywołać linki, i jaki ładunek przekazać. Tak więc, moim zdaniem, w interakcji komputer-komputer komputer przyjmuje rolę użytkownika końcowego. Raz jeszcze nazywamy to usługą orkiestracji.

Myślę, że możemy używać HATEOAS z orkiestracją lub choreografią.

Wzorzec bramy API

Kolejny interesujący wzorzec sugeruje Chris Richardson, który również zaproponował coś, co nazwał Wzorzec API API .

W architekturze monolitycznej klienci aplikacji, tacy jak przeglądarki internetowe i aplikacje rodzime, wysyłają żądania HTTP za pośrednictwem modułu równoważenia obciążenia do jednego z N identycznych wystąpień aplikacji. Ale w architekturze mikrousług monolit zastąpiono zbiorem usług. W związku z tym kluczowym pytaniem, na które musimy odpowiedzieć, jest to, z czym współpracują klienci?

Klient aplikacji, taki jak natywna aplikacja mobilna, może wysyłać żądania RESTful HTTP do poszczególnych usług [...] Na pierwszy rzut oka może to wydawać się atrakcyjne. Istnieje jednak prawdopodobieństwo znacznego niedopasowania w szczegółowości interfejsów API poszczególnych usług i danych wymaganych przez klientów. Na przykład wyświetlenie jednej strony internetowej może potencjalnie wymagać połączeń z dużą liczbą usług. Na przykład Amazon.com opisuje, w jaki sposób niektóre strony wymagają połączeń z ponad 100 usługami. Składanie tylu żądań, nawet przez szybkie łącze internetowe, nie mówiąc już o sieci komórkowej o niższej przepustowości i większym opóźnieniu, byłoby bardzo nieefektywne i powodowałoby słabe wrażenia użytkownika.

O wiele lepszym rozwiązaniem jest wysyłanie przez Internet niewielkiej liczby żądań na stronę, być może zaledwie jednej, przez Internet do serwera frontonu zwanego bramą API.

Brama API znajduje się między klientami aplikacji a mikrousługami. Zapewnia interfejsy API dostosowane do klienta. Brama API zapewnia gruboziarnisty interfejs API dla klientów mobilnych i bardziej szczegółowy interfejs API dla klientów stacjonarnych korzystających z sieci o wysokiej wydajności. W tym przykładzie klienci pulpitu wysyłają wiele żądań w celu pobrania informacji o produkcie, podczas gdy klient mobilny wysyła jedno żądanie.

Brama API obsługuje przychodzące żądania poprzez wysyłanie żądań do pewnej liczby mikrousług za pośrednictwem wysokowydajnej sieci LAN. Na przykład serwis Netflix opisuje, w jaki sposób każde żądanie obejmuje średnio sześć usług zaplecza. W tym przykładzie drobnoziarniste żądania od klienta stacjonarnego są po prostu proxy do odpowiedniej usługi, podczas gdy każde gruboziarniste żądanie od klienta mobilnego jest obsługiwane przez agregację wyników wywoływania wielu usług.

Brama API nie tylko optymalizuje komunikację między klientami a aplikacją, ale także opisuje szczegóły mikrousług. Umożliwia to ewolucję mikrousług bez wpływu na klientów. Na przykład można połączyć dwie mikrousługi. Inna mikrousługa może być podzielona na dwie lub więcej usług. Tylko brama API wymaga aktualizacji, aby odzwierciedlić te zmiany. Klienci pozostają bez zmian.

Teraz, gdy przyjrzeliśmy się, jak brama API pośredniczy między aplikacją a jej klientami, przyjrzyjmy się teraz, jak zaimplementować komunikację między mikrousługami.

Brzmi to dość podobnie do wspomnianego powyżej stylu aranżacji, ale z nieco inną intencją, w tym przypadku wydaje się, że chodzi o wydajność i uproszczenie interakcji.

Próbuję tutaj agregować różne podejścia.

Wydarzenia domenowe

Wydaje się, że dominującym podejściem jest wykorzystanie zdarzeń domenowych, w których każda usługa publikuje zdarzenia dotyczące tego, co się wydarzyło, a inne usługi mogą subskrybować te zdarzenia. Wydaje się, że idzie to w parze z koncepcją inteligentnych punktów końcowych, głupich rur, którą opisuje Martin Fowler tutaj: http://martinfowler.com/articles/microservices.html#SmartEndpointsAndDumbPipes

Pełnomocnik

Innym podejściem, które wydaje się powszechne, jest zawinięcie przepływu biznesu we własną usługę. Gdzie proxy koordynuje interakcję między mikrousługami, jak pokazano na poniższym obrazku:

.

Inne wzory kompozycji

Ta strona zawiera różne wzory kompozycji.

Czym więc różni się organizacja mikrousług od organizacji starych usług SOA, które nie są „mikro”? W ogóle niewiele.

Mikrousługi zwykle komunikują się przy użyciu protokołu HTTP (REST) ​​lub wiadomości / zdarzeń. Orkiestracja jest często kojarzona z platformami orkiestracji, które umożliwiają tworzenie skryptowej interakcji między usługami w celu automatyzacji przepływów pracy. W dawnych czasach SOA platformy te używały WS-BPEL. Dzisiejsze narzędzia nie używają BPEL. Przykłady nowoczesnych produktów do aranżacji: Netflix Conductor, Camunda, Zeebe, Azure Logic Apps, Baker.

Pamiętaj, że orkiestracja to złożony wzór, który oferuje kilka możliwości tworzenia złożonych kompozycji usług. Mikrousługi są częściej postrzegane jako usługi, które nie powinny uczestniczyć w skomplikowanych kompozycjach, a raczej być bardziej autonomiczne.

Widzę mikrousługę wywoływaną w zorganizowanym przepływie pracy w celu wykonania prostego przetwarzania, ale nie widzę mikrousługi jako usługi orkiestratora, która często korzysta z mechanizmów takich jak kompensacja transakcji i repozytorium stanów (odwodnienie).

Masz więc dwie usługi:

1. Faktura mikro-usługa
2. Usługa mikro przesyłki

W prawdziwym życiu miałbyś coś, w czym utrzymywałbyś stan porządku. Nazwijmy to usługą zamawiania. Następnie masz przypadki użycia przetwarzania zamówień, które wiedzą, co zrobić, gdy zamówienie przechodzi z jednego stanu do drugiego. Wszystkie te usługi zawierają pewien zestaw danych, a teraz potrzebujesz czegoś innego, co zapewni całą koordynację. To może być:

• Prosty GUI znający wszystkie twoje usługi i implementujący przypadki użycia („Gotowe” wywołuje usługę wysyłki)
• Mechanizm procesów biznesowych, który czeka na zdarzenie „Gotowe”. Ten silnik implementuje przypadki użycia i przepływ.
• Mikrousługa aranżacyjna, powiedzmy sama usługa przetwarzania zamówień, która zna przypadki przepływu / wykorzystania Twojej domeny
• Coś jeszcze, o czym jeszcze nie myślałem

Chodzi przede wszystkim o to, że kontrola jest zewnętrzna. Wynika to z faktu, że wszystkie komponenty aplikacji są pojedynczymi elementami składowymi, luźno powiązanymi. Jeśli zmieniają się przypadki użycia, musisz zmienić jeden komponent w jednym miejscu, którym jest komponent aranżacyjny. Jeśli dodasz inny przepływ zamówień, możesz łatwo dodać innego orkiestratora, który nie będzie kolidował z pierwszym. Myślenie w zakresie mikrousług polega nie tylko na skalowalności i wykonywaniu fantazyjnych interfejsów API REST, ale także na przejrzystej strukturze, zmniejszonych zależnościach między komponentami oraz ponownym wykorzystaniu wspólnych danych i funkcji, które są wspólne dla całej firmy.

HTH, Mark

Jeśli państwo musi być zarządzane, wówczas Event Sourcing z CQRS jest idealnym sposobem komunikacji. W przeciwnym razie do komunikacji między mikrousługami można użyć systemu asynchronicznego przesyłania komunikatów (AMQP).

Z twojego pytania jasno wynika, że ​​ES z CQRS powinien być właściwym połączeniem. Jeśli używasz Java, spójrz na framework Axon. Lub zbuduj niestandardowe rozwiązanie za pomocą Kafka lub RabbitMQ.

napisałem kilka postów na ten temat:

Może te posty mogą również pomóc:

Wzorzec API API - API o ziarnistym przebiegu a API o drobnoziarnistej strukturze

https://www.linkedin.com/pulse/api-gateway-pattern-ronen-hamias/ https://www.linkedin.com/pulse/successfulapi-ronen-hamias/

API usług gruboziarnistych vs drobnoziarnistych

Z definicji operacja gruboziarnista ma szerszy zakres niż usługa drobnoziarnista, chociaż warunki są względne. gruboziarnista, zwiększona złożoność projektu, ale może zmniejszyć liczbę połączeń wymaganych do wykonania zadania. w architekturze mikrousług gruboziarnisty może znajdować się w warstwie API Gateway i koordynować kilka mikrousług w celu zakończenia określonej operacji biznesowej. gruboziarniste interfejsy API muszą być starannie zaprojektowane, ponieważ obejmują kilka mikrousług, które zarządzają różnymi dziedzinami wiedzy specjalistycznej, co wiąże się z ryzykiem mieszania się problemów w jednym interfejsie API i łamaniem zasad opisanych powyżej. gruboziarniste interfejsy API mogą sugerować nowy poziom szczegółowości funkcji biznesowych, które nie istnieją inaczej. na przykład zatrudniony pracownik może obejmować dwa połączenia z mikrousługami do systemu HR w celu utworzenia identyfikatora pracownika i kolejne połączenie z systemem LDAP w celu utworzenia konta użytkownika. alternatywnie klient mógł wykonać dwa drobnoziarniste wywołania API, aby osiągnąć to samo zadanie. podczas gdy gruboziarnisty reprezentuje biznesowe konto użytkownika, natomiast drobnoziarnisty API reprezentuje możliwości związane z takim zadaniem. ponadto bardziej drobnoziarniste API mogą obejmować różne technologie i protokoły komunikacyjne, natomiast gruboziarniste abstrakcyjne je w ujednolicony przepływ. projektując system, należy wziąć pod uwagę oba te elementy, ponieważ ponownie nie ma złotego podejścia, które rozwiązałoby wszystko, i każdy z nich jest kompromisowy. Gruboziarniste są szczególnie przydatne jako usługi do wykorzystania w innych kontekstach biznesowych, takich jak inne aplikacje,

odpowiedź na pierwotne pytanie to wzór SAGA.