Мікросервіси " Будівництво книг" докладно описують стилі, згадані @RogerAlsing у своїй відповіді.
На сторінці 43 у розділі Оркестрація проти хореографії книга говорить:
Починаючи моделювати все більш складну логіку, ми маємо мати справу з проблемою управління бізнес-процесами, які простягаються через межу окремих служб. І за допомогою мікросервісів ми досягнемо цієї межі раніше, ніж зазвичай. [...] Що стосується фактичного впровадження цього потоку, ми можемо дотримуватися двох стилів архітектури. За допомогою оркестрації ми покладаємось на центральний мозок для керівництва та керування процесом, як диригент в оркестрі. За допомогою хореографії ми повідомляємо кожну частину системи про свою роботу і даємо їй розробити деталі, як танцівники, які знаходять свій шлях і реагують на оточуючих їх у балеті.
Потім книга переходить до пояснення двох стилів. Стиль оркестрації більше відповідає ідеї SOA щодо оркестрації / служб завдань , тоді як стиль хореографії відповідає дурним трубам та розумним кінцевим точкам, згаданим у статті Мартіна Фаулера.
Оркестровий стиль
Під цим стилем книга вище згадує:
Поміркуймо, як виглядатиме рішення для оркестрації для цього потоку. Тут, мабуть, найпростіше зробити, щоб наше обслуговування клієнтів виступало центральним мозком. Під час створення, він спілкується з банком лояльності, службою електронної пошти та поштовою службою [...], через низку дзвінків на запит / відповідь. Служба замовника сама може відстежувати, де знаходиться замовник у цьому процесі. Він може перевірити, чи налаштовано обліковий запис клієнта, чи надіслано електронний лист, чи відправлено повідомлення. Ми беремо взяти діаграму потоку [...] і моделювати її безпосередньо в код. Ми навіть могли використовувати інструменти, які реалізують це для нас, можливо, використовуючи відповідний механізм правил. Для цього існують комерційні інструменти у вигляді програмного забезпечення для моделювання бізнес-процесів. Якщо ми використовуємо синхронний запит / відповідь, ми навіть могли б знати, чи спрацював кожен етап [...] Недоліком цього підходу до оркестрування є те, що обслуговування клієнтів може стати занадто багато центральним органом управління. Він може стати центром посеред Інтернету та центральною точкою, де починає жити логіка. Я бачив, що такий підхід призводить до того, що невелика кількість розумних «богових» служб підказує анемічним службам на основі CRUD, що робити.
Примітка. Я припускаю, що коли автор згадує інструментарій, то він посилається на щось на зразок BPM (наприклад, Activity , Apache ODE , Camunda ). Власне кажучи, веб-сайт шаблонів робочого процесу має надзвичайний набір шаблонів для такого роду оркестрації, і він також пропонує детальну інформацію про оцінку різних інструментів постачальника, які допомагають реалізувати це таким чином. Я не думаю, що автор означає, що для реалізації цього стилю інтеграції потрібно використовувати один із цих інструментів, хоча інші легкі рамки оркестрації можуть бути використані, наприклад, Spring Integration , Apache Camel або Mule ESB
Однак інші книги, які я читав на тему «Мікросервіси», і загалом більшість статей, які я знайшов в Інтернеті, здаються недобрими таким підходом до оркестрації, а натомість пропонують використовувати наступну.
Хореографічний стиль
Під стиль хореографії автор говорить:
За допомогою хореографічного підходу, ми могли б замість того, щоб служба обслуговування клієнтів випускала подію асинхронно, кажучи, що Клієнт створений. Служба електронної пошти, поштова служба та банк лояльності потім просто підписуються на ці події та реагують відповідно [...] Цей підхід значно більше відокремлюється. Якщо для створення клієнта потрібна якась інша послуга, вона просто повинна підписатися на події та виконувати свою роботу, коли це потрібно. Мінус полягає в тому, що чіткий погляд на бізнес-процес, який ми бачимо в [робочому процесі], тепер лише неявно відображається в нашій системі [...] Це означає, що необхідна додаткова робота для того, щоб ви могли відстежувати та відстежувати, що потрібні речі є сталося. Наприклад, Ви б знали, якщо в банку очок лояльності була помилка і чомусь не створили правильний рахунок? Один із підходів, який мені подобається займатися цим, - це побудувати систему моніторингу, яка явно відповідає погляду на бізнес-процес у [робочому процесі], але потім відслідковує те, що кожен із служб виконує як незалежні суб'єкти, дозволяючи бачити непарні винятки, відображені на більш чіткий потік процесу. [Блок-схема] [...] - це не рушійна сила, а лише одна лінза, завдяки якій ми можемо побачити, як поводиться система. Взагалі, я виявив, що системи, які більше схильні до хореографічного підходу, є більш вільно пов'язаними і є більш гнучкими і піддаються змінам. Однак вам потрібно зробити додаткову роботу для контролю та відстеження процесів через межі системи. Я вважав, що більшість оркестрованих реалізацій є надзвичайно крихкими, з більшою вартістю змін. Зважаючи на це, я дуже вважаю за краще націлюватись на хореографічну систему, де кожна служба досить розумна, щоб зрозуміти її роль у всьому танці.
Примітка. На сьогоднішній день я все ще не впевнений, що хореографія - це лише інша назва архітектури, орієнтованої на події (EDA), але якщо EDA - це лише один із способів зробити це, якими є інші способи? (Див Що ви маєте в виду під «Event-Driven»? І смисли Event-Driven Architecture ). Крім того, здається, що такі речі, як CQRS та EventSourcing, дуже перегукуються з цим архітектурним стилем, правда?
Тепер після цього настає задоволення. Книга про мікросервіси не передбачає, що мікросервіси будуть реалізовані разом з REST. Власне кажучи, у наступному розділі книги вони переходять до розгляду рішень на основі RPC та SOA та нарешті REST. Тут важливим моментом є те, що мікросервіси не передбачають REST.
Отже, що з HATEOAS? (Hypermedia як двигун стану заявки)
Тепер, якщо ми хочемо дотримуватися RESTful підходу, ми не можемо ігнорувати HATEOAS або Рой Філдінг буде дуже радий сказати в своєму блозі, що наше рішення не є справді REST. Перегляньте його допис у блозі на API REST. Повинно бути гіпертекстом :
Мене засмучує кількість людей, які називають будь-який інтерфейс на основі HTTP REST API. Що потрібно зробити, щоб зрозумілий архітектурний стиль REST зрозумів, що гіпертекст є обмеженням? Іншими словами, якщо двигун стану програми (і, отже, API) не рухається гіпертекстом, він не може бути RESTful і не може бути API REST. Період. Чи є десь зламаний посібник, який потрібно виправити?
Отже, як ви бачите, Філдінг вважає, що без HATEOAS ви не справді будуєте RESTful програми. Для Fielding HATEOAS - це шлях, який стосується послуг з оркестрування. Я просто все це вчу, але для мене HATEOAS не чітко визначає, хто чи що є рушійною силою насправді за посиланнями. У користувальницькому інтерфейсі, який міг би бути користувачем, але у взаємодії комп'ютер-комп'ютер, я вважаю, що це потрібно зробити сервісом вищого рівня.
Згідно з HATEOAS, єдиним зв’язком, який справді повинен знати споживач API, є той, який ініціює спілкування з сервером (наприклад, POST / замовлення). З цього моменту REST збирається вести потік, оскільки у відповідь на цю кінцеву точку повернутий ресурс буде містити посилання на наступні можливі стани. Потім споживач API вирішує, за яким посиланням слід керувати, і переміщує програму в наступний стан.
Незважаючи на те, наскільки це здорово звучить, клієнт все ще повинен знати, чи повинно бути посилання POSTed, PUTed, GETed, PATCHed тощо. І клієнту все ж потрібно вирішити, яку корисну навантаження пройти. Клієнту все одно потрібно знати, що робити, якщо це не вдалося (повторити, компенсувати, скасувати тощо).
Я досить новий у всьому цьому, але для мене, з точки зору HATEOAs, цей клієнт або споживач API - це послуга високого замовлення. Якщо ми вважаємо це з точки зору людини, ви можете уявити собі кінцевого користувача на веб-сторінці, вирішивши, які посилання слід переходити, але все-таки програміст веб-сторінки повинен був вирішити, який метод використовувати для виклику посилань, і яке корисне навантаження пройти. Отже, на мій погляд, у взаємодії комп'ютер-комп'ютер комп'ютер бере роль кінцевого споживача. Ще раз це ми називаємо службою оркестрації.
Я думаю, ми можемо використовувати HATEOAS або з оркестрацією, або з хореографією.
Шаблон шлюзу API
Ще одна цікава модель запропонована Крісом Річардсоном, який також запропонував те, що він назвав API шлюзового інтерфейсу API .
У монолітній архітектурі клієнти програми, такі як веб-браузери та власні програми, роблять HTTP-запити через балансир навантаження до одного з N однакових примірників програми. Але в архітектурі мікросервісу моноліт був замінений набір послуг. Отже, ключовим питанням, на яке ми повинні відповісти, є те, з чим взаємодіють клієнти?
Клієнт додатків, наприклад нативний мобільний додаток, може робити RESTful HTTP-запити до окремих служб [...] На поверхні це може здатися привабливим. Однак, ймовірно, існує суттєва невідповідність деталізації API-програм окремих служб та даних, необхідних клієнтам. Наприклад, показ однієї веб-сторінки потенційно може вимагати дзвінків на велику кількість послуг. Наприклад, Amazon.com
описує, як деякі сторінки вимагають дзвінків до 100+ служб. Зрозуміло, що багато запитів, навіть через швидкісне з'єднання з Інтернетом, не кажучи вже про низькочастотну мобільну мережу з більш високою затримкою, було б дуже неефективним та призведе до поганого досвіду користувача.
Набагато кращий підхід полягає в тому, щоб клієнти мали невелику кількість запитів на сторінку, можливо, якнайбільше одного, через Інтернет до інтерфейсного сервера, відомого як шлюз API.
Шлюз API знаходиться між клієнтами програми та мікросервісами. Він надає API, адаптовані до клієнта. Шлюз API забезпечує грубозернистий API для мобільних клієнтів та більш дрібнозернистий API для настільних клієнтів, які використовують високопродуктивну мережу. У цьому прикладі настільні клієнти роблять кілька запитів для отримання інформації про продукт, тоді як мобільний клієнт робить один запит.
Шлюз API обробляє вхідні запити, роблячи запити до деякої кількості мікросервісів через високоефективну локальну мережу. Наприклад, Netflix
описує,
як вентилятори кожного запиту отримують в середньому шість сервісів заходу. У цьому прикладі дрібнозернисті запити від настільного клієнта просто пов'язані з відповідною послугою, тоді як кожен грубозернистий запит мобільного клієнта обробляється шляхом агрегування результатів виклику декількох служб.
Шлюз API не тільки оптимізує спілкування між клієнтами та додатком, але й інкапсулює деталі мікросервісів. Це дає можливість мікросервісам розвиватися, не впливаючи на клієнтів. Наприклад, дві мікросервіси можуть бути об'єднані. Інша мікросервіс може бути розділений на дві або більше служб. Необхідно оновити лише шлюз API, щоб відобразити ці зміни. Клієнти не зачеплені.
Тепер, коли ми розглянули, як шлюз API опосередковується між програмою та її клієнтами, давайте тепер розглянемо, як реалізувати зв’язок між мікропослугами.
Це звучить досить схоже на згаданий вище стиль оркестрації, лише з дещо іншим наміром, в цьому випадку, здається, все стосується продуктивності та спрощення взаємодій.
.