Książka Building Microservices opisuje szczegółowo style wspomniane przez @RogerAlsing w jego odpowiedzi.

Na stronie 43 pod Orchestration vs Choreography książka mówi:

Gdy zaczynamy modelować coraz bardziej złożoną logikę, musimy sobie poradzić z problem zarządzania procesami biznesowymi, które rozciągają się na granice poszczególnych usług. A z mikroserwisów trafimy to ograniczenie szybciej niż zwykle. [...] Jeśli chodzi o faktycznie realizując ten przepływ, istnieją dwa style architektury, które moglibyśmy za mną. Z orkiestracją polegamy na centralnym mózgu, który prowadzi i kieruj procesem, podobnie jak dyrygent w orkiestrze. Z choreografii, informujemy każdą część systemu o jego pracy i pozwalamy wypracować szczegóły, tak jak tancerze wszyscy odnajdują swoją drogę i reagowanie na innych wokół nich w balecie.

Następnie książka wyjaśnia dwa style. Styl orkiestracji odpowiada bardziej do idei SOA orchestration / task services , podczas gdy styl choreografii odpowiada dumb pipes i smart endpoints wspomnianym w artykule Martina Fowlera.

Styl Orkiestracji

Pod tym stylem w powyższej książce wspomina się:

Zastanówmy się, jak wyglądałoby rozwiązanie orkiestracyjne ten przepływ. Tutaj najprościej byłoby mieć nasza obsługa klienta działa jako centralny mózg. On creation, it talks do banku punktów lojalnościowych, poczty elektronicznej i poczty [...], poprzez serię zapytań / odpowiedzi. Na sama obsługa klienta może następnie śledzić, gdzie klient jest w tym proces. Może sprawdzić, czy konto klienta zostało ustawione up, lub e-mail wysłany, lub poczta dostarczona. Możemy wziąć flowchart [...] i modelować go bezpośrednio w kodzie. Moglibyśmy nawet użyć oprzyrządowanie, które realizuje to dla nas, być może za pomocą odpowiedniego silnik zasad. Narzędzia komercyjne istnieją do tego właśnie celu w postaci oprogramowania do modelowania procesów biznesowych. Zakładając, że używamy synchronicznego Prośba/odpowiedź, możemy nawet wiedzieć, czy każdy etap zadziałał [...] Minusem takiego podejścia jest to, że klient Służba może stać się zbyt wielką centralną władzą zarządzającą. Może stać się centrum w środku sieci i centralnym punktem, w którym logika zaczyna żyć. Widziałem, że takie podejście skutkuje niewielką liczbą mądry " Bóg" usługi informujące o tym, co robić.

Uwaga: przypuszczam, że gdy autor wspomina o narzędziach, odnosi się do czegoś w rodzaju BPM (np. aktywność, Apache ODE, Camunda ). W rzeczywistości strona Workflow Patterns ma niesamowity zestaw szablonów do tego rodzaju orkiestracji, a także oferuje szczegóły oceny różnych narzędzi dostawców, które pomagają wdrożyć go w ten sposób. Nie sądzę, by autor oznacza to, że do implementacji tego stylu integracji wymagane jest użycie jednego z tych narzędzi, jednak można użyć innych lekkich frameworków orkiestracyjnych, np., Apache Camel lub Mule ESB

Jednak inne książki czytałem na temat mikroserwisów i ogólnie większość artykułów, które znalazłem w Internecie, wydaje się nie pasować do tego podejścia orkiestracji i zamiast tego sugerować użycie następnego jeden.

Styl Choreografii

Pod styl choreografii autor mówi:

Z choreograficznym podejściem, moglibyśmy zamiast tego mieć klienta usługa emituje Zdarzenie w sposób asynchroniczny, mówiąc klient stworzony. Serwis e-mail, poczta i bank punktów lojalnościowych następnie wystarczy zapisać się na te wydarzenia i odpowiednio zareagować [...] Podejście to jest znacznie bardziej oddzielone od produkcji. Jeśli niektóre inne usługi potrzebne do dotarcia do stworzenia klienta, to po prostu musi zapisać się na wydarzenia i wykonywać swoją pracę w razie potrzeby. Na minusem jest to, że wyraźne spojrzenie na proces biznesowy widzimy w [workflow] jest teraz tylko pośrednio odzwierciedlone w naszym systemie [...] Oznacza to, że potrzebna jest dodatkowa praca, aby zapewnić możliwość monitorowania i śledzić, że właściwe rzeczy się wydarzyły. Na przykład, czy wiedzieć czy bank punktów lojalnościowych miał błąd i z jakiegoś powodu nie skonfigurować prawidłowe konto? Jedno podejście, które lubię radzenie sobie z tym jest zbudowanie systemu monitorowania, który wyraźnie pasuje do widoku proces biznesowy w [workflow], ale następnie śledzi, co każdy z usługi działają jako niezależne podmioty, dzięki czemu można zobaczyć dziwne wyjątki odwzorowane na bardziej wyraźny przepływ procesu. [SCHEMAT BLOKOWY] [...] nie jest siłą napędową, ale tylko jednym obiektywem przez które możemy zobaczyć, jak system się zachowuje. Ogólnie rzecz biorąc, znalazłem że systemy, które skłaniają się bardziej ku choreograficznemu podejściu są więcej luźno połączone i są bardziej elastyczne i podatne na zmiany. Ty tak konieczność wykonania dodatkowej pracy w celu monitorowania i śledzenia procesów w całym systemie jednak granice. Znalazłem najbardziej zaaranżowane wdrożenia mają być niezwykle kruche, przy wyższych kosztach zmian. Mając to na uwadze, zdecydowanie wolę dążyć do choreografii system, w którym każda usługa jest na tyle inteligentna, że nie spełnia swojej roli w cały taniec.

Uwaga: do dziś nie jestem pewna jeśli choreografia to tylko inna nazwa dla event-driven architecture (EDA), ale jeśli EDA jest tylko jednym ze sposobów, jakie są inne sposoby? (Zobacz także co masz na myśli przez "napędzane zdarzeniami"?i znaczenia architektury opartej na zdarzeniach ). Wydaje się również, że rzeczy takie jak CQRS i EvenSourcing często współgrają z tym stylem architektonicznym, prawda?

Teraz, po tym przychodzi zabawa. Księga mikroserwisów nie zakłada, że mikroserwisy będą implementowane z Odpoczywaj. W następnej sekcji książki przystępują do rozważenia rozwiązań opartych na RPC i SOA i na koniec odpoczywają. Ważne jest tutaj, że mikroserwisy nie oznaczają odpoczynku.

A co z HATEOAS?

Teraz, jeśli chcemy podążać za spokojnym podejściem, nie możemy ignorować HATEOASA lub Roy Fielding z przyjemnością powie na swoim blogu, że naszym rozwiązaniem nie jest naprawdę odpoczynek. Zobacz jego wpis na blogu REST API musi być Hipertekstem Driven :

Denerwuje mnie ilość osób dzwoniących na dowolny HTTP interfejs a REST API. Co należy zrobić, aby reszta stylu architektonicznym jasno na myśl, że hipertekst jest ograniczenie? Innymi słowy, jeśli silnik stanu aplikacji (i stąd API) nie jest napędzany hipertekstem, wtedy nie może być RESTful i nie może być REST API. Kropka. Czy jest jakaś zepsuta Instrukcja gdzieś, gdzie trzeba to naprawić?

Tak, jak widzisz, Fielding uważa, że bez HATEOAS nie budujesz naprawdę spokojnych aplikacji. Dla fieldingu HATEOAS jest drogą, jeśli chodzi o usługi orkiestrowe. Właśnie się tego wszystkiego uczę, ale dla mnie HATEOAS nie określa jasno, kto lub co jest siłą napędową faktycznie podążania za linkami. W interfejsie użytkownika, który może być użytkownikiem, ale w interakcjach komputer-komputer, przypuszczam, że musi to być zrobione przez usługę wyższego poziomu.

Według HATEOAS, jedyny link klient API naprawdę musi wiedzieć, to ten, który inicjuje komunikację z serwerem (np. POST /order). Od tego momentu REST będzie przeprowadzał przepływ, ponieważ w odpowiedzi tego punktu końcowego zwracany zasób będzie zawierał linki do kolejnych możliwych stanów. Następnie użytkownik API decyduje, które łącze należy śledzić i przenosi aplikację do następnego stanu.

Pomimo tego, jak fajnie to brzmi, klient nadal musi wiedzieć, czy link musi być opublikowany, wycięty, GETed, Łatane itp. A klient nadal musi zdecydować, jaki ładunek przekazać. Klient nadal musi być świadomy, co zrobić, jeśli to się nie powiedzie (ponów próbę, zrekompensuj, anuluj itp.).

Jestem całkiem nowy w tym wszystkim, ale dla mnie, z perspektywy HATEOAs, ten klient, czyli API consumer jest usługą o wysokim zamówieniu. Jeśli myślimy o tym z perspektywy człowieka, można sobie wyobrazić użytkownika końcowego na stronie internetowej, decydującego o tym, jakie linki należy śledzić, ale mimo to programista strony musiał zdecydować, jakiej metody użyć do wywołania linków, i jaki ładunek przekazać. Tak więc, do mojego punktu widzenia, w interakcji Komputer-Komputer, komputer przyjmuje rolę użytkownika końcowego. Po raz kolejny nazywamy to serwisem orkiestracyjnym.

Przypuszczam, że możemy użyć HATEOAS z orkiestracją lub choreografią.

Wzorzec bramy API

Innym ciekawym wzorcem jest zaproponowany przez Chrisa Richardsona, który również zaproponował tak zwany wzorzec bramy API .

In monolitycznej architektury, klientów aplikacji, takich jak web przeglądarek i aplikacji natywnych, dokonać żądań HTTP poprzez obciążenie balancer do jednej z N identycznych instancji aplikacji. Ale w architektury mikrousług, monolit został zastąpiony przez zbieranie usług. W związku z tym kluczowe pytanie, na które musimy odpowiedzieć z czym współpracują klienci?

Klient aplikacji, np. natywna aplikacja mobilna, może RESTful HTTP requests to poszczególne usługi [...] Na powierzchni to może wydawać się atrakcyjne. Jest jednak prawdopodobne, że istotne niedopasowanie w ziarnistości między API jednostki usługi i dane wymagane przez klientów. Na przykład wyświetlanie jednego strona internetowa może potencjalnie wymagać połączeń do dużej liczby usług. Amazon.com, na przykład, opisuje Jak niektóre strony wymagają połączeń do ponad 100 usług. Składając tyle próśb, nawet przez szybki internet połączenia, nie mówiąc już o niższej przepustowości, sieci komórkowej o większym opóźnieniu, byłaby bardzo nieefektywna i skutkowałaby słabe doświadczenie użytkownika.

Znacznie lepszym podejściem jest dla klientów wykonanie niewielkiej liczby wnioski na stronę, Być może nawet jedną, przez Internet do serwer front-end znany jako brama API.

Brama API znajduje się pomiędzy klientami aplikacji a mikroserwisy. Zapewnia interfejsy API, które są dostosowane do klienta. Na API gateway zapewnia Gruboziarnisty API dla klientów mobilnych i drobnoziarniste API do klientów desktopowych, które korzystają z wysokowydajnego sieć. W tym przykładzie klienci desktopowi wysyłają wiele żądań aby uzyskać informacje o produkcie, gdzie jako klient mobilny składa jedną prośbę.

Brama API obsługuje przychodzące żądania, wysyłając żądania do niektórych liczba mikroserwisów w wysokowydajnej sieci LAN. Netflix, dla przykład, opisuje jak każde żądanie fanów na średnio sześć usług zaplecza. W tym przykład, drobnoziarniste żądania z klienta desktop są po prostu proxy do odpowiedniej służby, natomiast każdy Gruboziarnisty żądanie klienta mobilnego jest obsługiwane przez agregację wyników wywołuję wiele usług.

Bramka API nie tylko optymalizuje komunikację między klientami i aplikacji, ale także zawiera szczegóły mikroserwisy. Umożliwia to rozwój mikroserwisów bez wpływanie na klientów. Przykładowo, dwie mikroserwisy mogą być / align = "left" / Inna mikrousługa może być podzielona na dwie lub więcej usługi. Tylko brama API musi zostać zaktualizowana, aby odzwierciedlić te zmiany. Klienci nie mają wpływu.

Teraz, gdy przyjrzeliśmy się, jak Brama API pośredniczy między aplikacji i jej klientów, przyjrzyjmy się teraz, jak wdrożyć komunikacja między mikroserwisami.

To brzmi dość podobnie do wspomniany powyżej styl orkiestracji, tylko z nieco inną intencją, w tym przypadku wydaje się, że chodzi o wykonanie i uproszczenie interakcji.

Czytaj Dalej

W blogu NGINX niedawno opublikowano świetną serię artykułów, które polecam zagłębić się w te wszystkie pojęcia:

• Wprowadzenie do mikroserwisów
• budowanie mikroserwisów: Korzystanie z API Gateway
• Tworzenie mikroserwisów: IPC w architekturze mikroserwisów
• wykrywanie usług w architekturze mikroserwisów
• zarządzanie danymi sterowanymi zdarzeniami dla mikroserwisów
• wybór strategii wdrażania mikroserwisów
• Refaktoryzacja monolitu na mikroserwisy