Самотній візок в спекотному літньому Сан-Франциско.
Визначення доменів, піддоменів та обмежених контекстів в рамках підходу, орієнтованого на проєктування доменів (Domain-Driven Design), є творчим процесом, який залучає людей з різних спеціальностей в бізнес-домені та технологіях. Це є основним кроком у визначенні мікросервісів за допомогою підходу згори вниз, який є напрямом більшості ініціатив трансформації.
В ідеальному світі, мікросервіси повинні бути простими для підрозділу та агрегації в міру того, як відбуваються ітерації проєктування або коли, під час їхнього життєвого циклу, це вважається доцільним. Це очікується при виборі мікросервісів як архітектурної моделі. Але в реальному світі чи це просто? Ні, це не так, дуже далеко від цього.
Як можна вільно застосовувати поділ і агрегацію обмежених контекстів без обмежень технічних аспектів або обмежень?
Проблема
При визначенні проблемного простору в проєктуванні доменів, доменах, піддоменах та моделях, не слід обмежуватися технологіями, а натомість надихатися бізнес-вимогами, комунікаційною структурою компанії* і семантикою домену.
**Закон Конвея:*
Організації, які проєктують системи (в широкому сенсі, що використовується тут), змушені створювати проєкти, які є копіями комунікаційних структур цих організацій.
— Мелвін Е. Конвей, Як комітети винаходять?
При переході до простору рішень, технологія та методологія проєкту визначають обмежені контексти як технічні артефакти, які, зазвичай, хоча й не обов'язково, відповідають одному мікросервісу.
На цьому етапі можуть виникнути різні технічні питання, такі як:
- Яка причина для розділення мікросервісу, який (на даний момент) вважається не дуже повторно використовуваним? (наприклад, інтеграційний сервіс, що виступає як анти-корупційний шар, є типовим прикладом)
- Як буде збалансована операційна складність та зусилля для підтримки ще одного мікросервісу проти абстрактної "нематеріальної" цінності добре спроектованої доменної архітектури і операційних витрат, які це вимагає?
- Чому ми розділяємо високочастотний мікросервіс? Хіба це не створить точку відмови і не закріпить занепокоєння споживачів щодо витрат, масштабованості та доступності без можливості їх вирішення?
І всі ці питання є справедливими. Іноді архітектори занурюються в "гарну практику" і забувають, іронічно, про практичність своїх проектів, коли вони повинні бути реалізовані. Це смертельний гріх, про який архітектор повинен бути обізнаний і працювати над тим, щоб стримати його в будь-який можливий спосіб. Необхідно зберігати делікатний баланс між архітектурними прерогативами та практичністю.
Рішення
Яка основна різниця між цільовим мікросервісом і програмним компонентом, що знаходиться в одному середовищі виконання разом із його споживачем? Перший є незалежним у розгортанні, підтримці, масштабуванні, автономним у виборі технологій та керується самодостатньою, спеціалізованою командою. Є й інші характеристики, звісно, але для цілей цієї статті цих буде достатньо.
Шаблон проєктування Вбудовані сервіси має на меті подолати цей розрив, дозволяючи окремо реалізованому мікросервісу бути розгорнутим як в Автономному, так і в Вбудованому режимах.
- Автономний режим — це стандартний режим, коли мікросервіс розгортається автономно та окремо від інших середовищ виконання.
- Вбудований режим розгортає мікросервіс як незалежний програмний компонент у середовищі виконання хост-сервісу, який виступає як його споживач.
Незалежно від режиму, важливо розуміти, що мікросервіс все ще керується та версіонується незалежною командою, як це вимагається від методології, що супроводжує архітектуру мікросервісів.
Необхідно враховувати кілька застережень при впровадженні шаблону Вбудовані сервіси, але вони можуть бути вирішені, як тільки їх буде виявлено.
Застосування
Цільовий мікросервіс повинен бути споживаний через спеціалізоване API, щоб уникнути порушення інкапсуляції та залишатися незалежно керованим. За допомогою налаштувань споживач виконує виклик в пам'яті, якщо цільовий мікросервіс знаходиться в режимі Вбудований, або віддалений виклик (наприклад, HTTP), якщо він розгорнутий в режимі Автономний, без змін у коді клієнта.
Впровадження спеціалізованих фреймворків для керування взаємодіями між мікросервісами, таких як сітка сервісів (service mesh), гарантує, що зазначене обмеження буде реалізовано один раз без дублювання. У будь-якому випадку, середовище виконання споживача не знає про режим розгортання цільового мікросервісу.
Застереження
Розгортання в режимі Автономний не повинно ділити стан або бути пов'язане з екземплярами в режимі Вбудований, і навпаки. Необхідно прийняти, що різні версії вбудованих екземплярів можуть існувати в їхніх споживачах-хостах, оскільки команда, що керує останніми, відповідає за оновлення кожного разу, коли це необхідно, і їхні пріоритети та можливості для цього можуть відрізнятися.
Переваги
Переваги включають, але не обмежуються, зниженими операційними витратами, підвищеною ефективністю та зменшенням складності; підвищеною продуктивністю для вбудованих сервісів при виконанні викликів в пам'яті; меншим трафіком, що потрібен для інфраструктури мережі сервісів; і вищою ефективністю витрат через масштабування за необхідністю.
Бажаю чудового дня.
Перекладено з: Microservice Design Patterns | Embedded Services