Евристика конструкції для розкладання монолітів

“Коли ви розробляєте систему …, тоді, якщо об’єкти можна розбити на … вільно зв’язані групи відносно тісно пов’язаних елементів, тоді це розділення – це добре, щоб бути частиною проекту. Це просто хороша інженерія”. – Тім Бернерс-Лі

Розкладання монолітів на сьогоднішній день є модною темою в архітектурі програмного забезпечення.

Я побачив чудову бесіду на #SACON Владика Хрононова, яка мала деякі важливі застереження та евристику дизайну для наближення декомпозиції, якими я думав поділитися.

Оскільки ми розкладаємо програмні послуги з монолітної великої кулі бруду, ми схильні застосовувати розробку, спрямовану на домен, для визначення обмежених контекстів на основі бізнес-доменів. Звідти ми можемо продовжувати розкладання далі до мікросервісів, а потім ще далі. Як ви бачите з цього графічного зображення, існує чіткий компроміс між розміром послуги та складністю та обслуговуванням системи, оскільки з розповсюдженням нано-послуг ви отримуєте перевагу високої модульності, але з вартістю високої комунікації та координації між службами.

Службовий API – це інтерфейс, за допомогою якого ви обмінюєтеся інформацією в межах і з певної служби. Мікросервіс представляє мікроінтерфейс, зменшуючи площу поверхні цього API, що допомагає зменшити зв’язок між службами, що робить цю послугу простішою для розуміння, більш стійкою до несправностей і менш схильною до модифікації в міру зміни системи.

”Глобальна складність … – це складність загальної структури програми чи системи. тобто ступінь асоціації або взаємозалежності серед основних частин програми “- Гленфорд Дж. Майерс

По мірі того, як компанії мігрують свої системи до мікропослуг, спокушається переборщити, і тим самим створюють розподілений моноліт, який насправді збільшує складність системи. Тепер вам доведеться змінити багато невеликих служб, щоб отримати нову функцію, замість того, щоб вносити зміни в єдину монолітну базу коду.

Але звідки ви знаєте, наскільки далеко вам слід зайняти своє розкладання?

Владик запропонував кілька евристик проекту, щоб допомогти архітекторам робити такі типи інженерних компромісів, і ось короткий зміст:

1 Розкласти до обмеженого контексту

Не застосовуйте логічно суперечливі моделі в одній службі, натомість намагайтеся розкластись до обмеженого рівня контексту

2 Не застосовуйте перший закон розподіленого дизайну об’єктів

“Не розповсюджуйте свої предмети” – Мартін Фаулер

Якщо немає чіткої бізнес-мети, намагайтеся не розкладати обмежений контекст далі на цьому етапі

Пам’ятайте, що мікросервіси вам насправді можуть не знадобитися, тому не розкладайтеся без потреби

3 Логічно сегментуйте свої домени на Core, Generic та Support

Купуйте або приймайте загальні субдомени, оскільки це повсякденні та складні проблеми, які виникають у всіх, і їх уже вирішують інші постачальники програм

Основні субдомени представляють конкурентну перевагу вашого бізнесу та те, що ви сподіваєтесь поглибити та розвинути

Підтримка субдоменів не є складною чи цікавою, не забезпечує конкурентних переваг, але необхідна для підтримки основних субдоменів

4 Не поспішайте

Витягніть свої основні субдомени і чітко дотримуйтесь їх меж

Подальше розкладання лише тоді, коли ви набуваєте глибоких знань домену

Найкращі проекти вимагають вивчення та повторення, майже ніхто не отримує цього з першого разу

5 Підтримка субдоменів

Оскільки вони змінюються рідше, часто можна безпечно розкласти межі субдоменів для служб підтримки

6 Оцініть вимоги до послідовності

Які залежності між вашими послугами?

Чи потрібно одній службі читати останню запис іншої?

= Можна використовувати дві служби з синхронним зв’язком

Чи можлива узгодженість?

= Може використовувати 2+ послуги з асинхронним зв’язком

Вам потрібно контролювати паралельність?

= Можливо, покласти їх на одну службу

Хороша евристика полягає в тому, що якщо ваш дизайн мікросервісу вимагає розподілених атомних транзакцій, просто не робіть цього та об’єднуйте їх в єдину службу.

7 Публічні / приватні заходи

Класифікуйте події як публічні чи приватні, де публічні події представляють ваші “двері обслуговування” та пам’ятайте, що ви також можете згорнути кілька приватних подій у публічні події.

Зберігайте знання домену всередині служб і виставляйте лише відповідні події, що змінюють стан

8 Зробіть події явними

Усуньте двозначність, щоб клієнти не мусили робити припущення щодо ваших подій чи інтерфейсів

9 Оцініть причини змін

Якщо дві служби регулярно потребують змін разом, це запах дизайну, можливо, вони повинні бути однією службою

10 Оцініть службові двері

Мікросервіси повинні мати мікро «дверцята для обслуговування» або інтерфейс

Спочатку ця публікація була опублікована за адресою https://www.linkedin.com/pulse/design-heuristics-decomposing-monoliths-raul-rupsingh/.

Raul Rupsingh люб’язно дозволив нам перекласти і опублікувати цю статтю.