Вступ
Перед тим як поговорити про повторне використання коду, давайте коротко визначимо основні переваги застосування архітектури мікросервісів:
- Розділення різних частин системи
- Незалежне масштабування різних частин системи
- Помилка в одному сервісі не обов'язково призводить до відмови всієї системи
- Свобода вибору різних технологій (БД, мови програмування тощо)
Ці переваги не знімають інші труднощі, з якими стикаються розробники при створенні та експлуатації системи, що складається з мікросервісної архітектури.
Деякі з цих труднощів при створенні мікросервісів:
- Повторне використання коду між мікросервісами
- Здатність передбачити місце можливих збоїв і усунути їх.
Наша мета в цій статті — дослідити варіанти і зрозуміти супутні виклики повторного використання коду. Я планую зайнятись другим аспектом найближчим часом.
Варіанти та виклики повторного використання коду в мікросервісах:
1. Упаковка повторно використовуваного коду в бібліотеки: Визначте код (моделі, загальні помилки відповіді тощо), який можна упакувати в бібліотеку і опублікувати в репозиторії для використання кількома мікросервісами.
Однак такий підхід може призвести до тісної прив'язки; зміни в бібліотеці можуть вимагати оновлень в кількох мікросервісах, що може призвести до введення несумісних змін.
2. Управляємий копіюванням:
Замість спільного використання бібліотек між мікросервісами, зберігайте копії повторно використовуваного коду в кожному мікросервісі та знайдіть спосіб синхронізувати зміни в коді за потреби.
Але це може призвести до витрат на обслуговування, якщо не використовуються надійні інструменти синхронізації, як-от (Bit-https://github.com/teambit/bit).
3. Загальна бізнес-логіка, інкапсульована як мікросервіс:
Визначте повторно використовувану бізнес-логіку, спільну для мікросервісів, і інкапсулюйте її в окремий мікросервіс.
Не вся загальна логіка є повторно використовуваною бізнес-логікою, і цей підхід може спричинити затримки через нерівномірні виклики мережі; також вимагає ретельного управління API.
Чи можна це зробити краще?
1. Модульний дизайн та абстракція Створюйте компоненти, які можна повторно використовувати, з чіткими межами та інтерфейсами, дотримуючись принципів SOLID та Domain-Driven Design (DDD).
Переваги: Підвищення масштабованості та підтримуваності; сприяє інкапсуляції.
Однак цей підхід може вимагати ретельного планування і інвестицій в зусилля з проектування.
2. Архітектура, орієнтована на події
Обмінюйте функціональність через події, а не безпосередні API виклики чи спільні бібліотеки.
Переваги: Покращує роз'єднання; дозволяє сервісам асинхронно реагувати на зміни.
Але не всі системи можуть підходити для архітектури, орієнтованої на події, і навіть якщо це так, цей підхід вимагає проектування і планування надійних систем управління подіями та боротьби з потенційною складністю обробки подій.
Висновок:
Як ви могли помітити, вибір правильного або ідеального підходу до повторного використання коду в архітектурі мікросервісів серед різних варіантів, зокрема тих, що я навів вище, а також інших можливих, не є простим. Однак, перед тим як прийняти рішення, потрібно зважити навантаження на команду проти підтримуваності коду та гнучкості команди.
Якщо ваша ситуація знаходиться на ранніх етапах розробки або коли межі контексту ще не зовсім зрозумілі, доцільно відкласти рішення про повторне використання бізнес-логіки, поки не будуть добре зрозумілі межі контексту мікросервісів.
Перекладено з: Is code reuse in microservices architecture a possibility ?