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.
.