Мікро, міні та макросервіси. Що за чим стоїть та що обрати для проєкту

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

«Making decisions in system design is all about trade-offs...»
― Sam Newman, Building Microservices: Designing Fine-Grained Systems

Всім привіт! Я Артем Палагно — Tech Lead у компанії SoftServe. І майже всю свою кар’єру, за винятком 2-3 місяців, я працюю з мікросервісами у різному їхньому прояві — міграція з моноліту, проєктування та побудова з нуля, а також робота з вже існуючими. Досвіду в темі маю достатньо, але нещодавно дуже здивувався, коли вперше почув про концепцію мінісервісів. Тому вирішив розібратися і поділитися своїми висновками та порадами. Вони будуть корисні тим розробникам, хто прагне структурувати свої знання, а також тим, хто вперше ознайомлюється з мінісервісами.

Вступ: поява мінісервісів

У сьогоднішніх реаліях всі звикли до того, що є всього два класичних варіанти архітектури програми — моноліт і мікросервіси (поки що винесемо за дужки serverless і т. д.). І, здебільшого, якщо вже йдеться про моноліт, то про його міграцію та перехід на мікросервісний підхід. І можна подумати, що наші архітектурні підходи живуть у чорно-білому світі, де є тільки добро, зло і нічого іншого. Але не все так просто, як здається на перший погляд.

Тому як третя альтернатива з’являється підхід з використанням мінісервісів.

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

Розбираємося в типах сервісів

Моноліт (макросервіс)

Переваги:

• Простота. Монолітні архітектури прості в створенні, тестуванні та розгортанні. Здебільшого масштабується вертикально (шляхом збільшення кількості RAM та CPU), адже використання горизонтального масштабування не є доцільним.
• Наскрізні проблеми (Cross-cutting concerns): за допомогою єдиної кодової бази монолітні програми можуть легко впоратися з наскрізними проблемами (Cross-cutting concerns), такими як логування, керування конфігурацією та моніторинг продуктивності.
• Ефективність. Компоненти в моноліті зазвичай спільно використовують пам’ять (RAM), тому і взаємодія між ними є швидшою, ніж зв’язок між сервісами за допомогою IPC[1] або інших механізмів.

Недоліки:

• Надійність. Помилка в будь-якому з модулів програми може призвести до зупинки всього додатка.
• Оновлення. Через єдину велику кодову базу та тісне зв’язування, для кожного оновлення потрібно буде розгортати весь додаток.
• Стек технологій. Монолітний додаток повинен використовувати один і той же технологічний стек. Зміни в технологічному стеку коштують дорого, як з точки зору часу, так і витрат.

Мікросервіс

Переваги:

• Можливість експериментувати з різними технологіями: між модулями є менші технологічні залежності. Відкат до попередніх ітерацій менш складний.
• Мале зв’язування (Low coupling): компоненти мікросервісів слабо пов’язані, тому вони не є взаємозалежними та можуть бути перевірені окремо. Це також робить додаток більш адаптованим до змін з часом.
• Покращена ізоляція несправностей (fault isolation): великі додатки продовжують функціонувати у випадку збою одного модуля.

Недоліки:

• Комунікація між сервісами ускладняється: оскільки тепер кожен сервіс є незалежним, тому необхідно звертати увагу на варіанти взаємодій для service-to-service communication[2]. В одному з таких сценаріїв розробники можуть бути змушені писати додатковий код, щоб уникнути збоїв.
• Тестування та моніторинг: щойно ви розбиваєте програми на незалежні сервіси, у вас буде більше рухомих частин, які потрібно відстежувати та виправляти. Без належних інструментів тестування та моніторингу ситуація може швидко вийти з-під контролю.

Мінісервіси

Переваги:

• Незалежна розробка: міні-сервіси можна розробляти незалежно один від одного. Оскільки домени чітко розділені, уклавши контракти з API, командам залишається лише турбуватися про виконання завдань у своєму домені.
• Масштабування: щоб масштабувати програму на основі мінісервісів, вам потрібно лише масштабувати певні компоненти, що оптимізує використання ресурсів.

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

Менші кодові бази означають легше та швидше розгортання. Це пояснюється тим, що існує менше залежностей, про які потрібно подбати в рамках сервісів. Незалежне розгортання окремих сервісів також робить можливим безперервне розгортання. Таким чином, гарантуючи, що програмне забезпечення постійно оновлюється для користувачів.

При цьому варто враховувати, що всі перелічені переваги трохи програють мікросервісам.

Недоліки:

• Контроль інтерфейсів ще важливіший: кожен сервіс має свій власний API, на який додатки покладаються, щоб бути послідовними. Хоча ви можете легко вносити зміни до сервіс, не впливаючи на зовнішні системи, що взаємодіють з нею, якщо ви зміните API (інтерфейс), будь-яка програма, що використовує цей мікросервіс, буде вражена, якщо зміна не буде зворотно сумісною.
• Попередні витрати можуть бути вищими: щоб архітектура працювала у вашій організації, вам потрібна достатня інфраструктура хостингу з підтримкою безпеки та обслуговування, а також потрібні кваліфіковані команди розробників, які розуміють усі служби та керують ними..

На відміну від переваг, недоліки у мінісервісах не такі значущі, ніж у мікросервісах.

Порівнюємо міні та мікросервіси

Щоб зрозуміти різницю між мікросервісами та мінісервісами, розглянемо варіанти реалізації одного ТЗ, використовуючи два підходи, та порівняємо їх між собою.

ТЗ: Web-додаток з аутентифікацією, рендерингом pdf та відправкою файлів поштою.

Підхід № 1 (мікросервісний)

Згідно з розділенням відповідальності (Separation of Concerns) проєктуємо мікросервіси з чітко визначеними обов’язками і отримаємо:

1) HTML-renderer service — сервіс рендерингу html.

2) HTML-to-PDF service — сервіс конвертації html to pdf.

3) Mailer service — сервіс поштової відправки.

4) JWT-generator service — сервіс генерації jwt токенів.

5) Authentication service — сервіс аутентифікації.

6) File-proxy service — сервіс взаємодії з файлами.

Підхід № 2 (мінісервісний)

Мінісервісний підхід передбачає групування схожих, або залежних функціональностей в один сервіс, тому отримуємо наступні сервіси:

1) PDF-renderer service — інкапсулює функціональність HTML-renderer service та HTML-to-PDF.

2) Mailer service — залишається незмінним.

3) Authentication service — інкапсулює функціональність JWT-generator service та Authentication service.

4) File proxy service — залишається незмінним.

Висновок: мікро та міні сервіси залишаються схожими з точки зору взаємодії між собою, або з базою даних, єдина відмінність — це кількість обов’язків, які інкапсулюються (мікросервіс = 1, мінісервіс > 1).

Порівняння у глобальному масштабі

Порівняємо основні характеристики різних підходів:

Висновок: кожен з підходів має свої переваги та недоліки, але для кожного з підходів є свій головний use-case.

Monolith — маленький додаток (не буде збільшуватись) для швидкого виходу у production.

Miniservice — м’яка міграція (менш затратна) з Monolith.

Microservice — побудова складного/великого додатку з 0 (from scratch).

Що обрати: критерії

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

1. Чи чітко визначені вимоги додатку?
2. Чи оцінили ми бізнес-ризики?
3. Чи має наша команда достатньо експертизи (у мікро/міні/макро)?
4. Чи маємо ми необхідну інфраструктуру?

Додаткова інформація

1. IPC (Inter-process communication).
2. Service-to-service communication.