1. Що таке мікросервісная архітектура
2. Мікросервіси vs моноліт
3. недоліки підходу
4. Спочатку - моноліт
5. Для яких рішень краще вибрати мікросервіси

Автор

Михайло

Python розробник

Мікросервіси - популярний підхід до розробки, який Netflix і Amazon успішно використовують більше трьох років.
Ми помітили, що не завжди вибір мікросервісов буває усвідомленим. Щоб мікросервіси вибиралися свідомо, ми вирішили розібрати найбільш часті питання:
У чому переваги мікросервісов?
Для яких рішень краще вибрати мікросервіси?

Що таке мікросервісная архітектура

Термін «мікросервіси» розкриває Сем Ньюмен в книзі "Building Microservices": це невеликі і націлені на те, щоб добре справлятися тільки з однією роботою, автономні, спільно працюють сервіси.
Сама ідея розділяти систему на незалежні компоненти не нова. Попередником мікросервісной архітектури є сервіс-орієнтована архітектура (SOA) , Яка також поділяє бізнес-логіку на компоненти. По суті, мікросервісная архітектура - окремий випадок SOA c набором більш строгих правил.

У мікросервісов є особливі властивості, вони ж переваги:

• Гетерогенність: можливість побудувати систему за допомогою різних мов програмування і технологій;
• Децентралізоване управління даними: кожен мікросервіс містить свій набір даних, доступний іншим мікросервісам тільки через відповідний інтерфейс;
• Незалежність інфраструктури: кожен мікросервіс - незалежна одиниця, тому вносити зміни і розгортати його можна незалежно від інших;
• Масштабованість: щоб збільшити продуктивність системи, потрібно розширити тільки ті сервіси, які цього потребують.

Мікросервіси vs моноліт

Мікросервіси протиставляються традиційній монолітної архітектури. Моноліт означає, що компоненти продукту взаємопов'язані і взаємозалежні. Якщо перестає працювати один - всі інші теж «відвалюються».

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

В таких умовах мікросервісная архітектура виграє у моноліту:

1. Простіше змінити один з мікросервісов і відразу впровадити його, ніж змінювати весь моноліт і перезапускати інфраструктуру цілком;
2. Нові розробники легше включаються в роботу - для цього їм не потрібно вивчати систему цілком, можна працювати тільки над своєю частиною;
3. Мікросервіси не залежить від будь-якої платформи, тому впроваджувати нові технології простіше, ніж в моноліт.

недоліки підходу

Не все так ідеально. Мікросервіси накладають обмеження на розробку і підтримку продукту:

1. Складність початкової розробки і створення інфраструктури. Розподілені системи складніше розробляти, тому що потрібно передбачити незалежність одного мікросервіса від збою в іншому компоненті;
2. Розробка розподілених систем накладає додаткові витрати на обмін даними між мікросервісамі: потрібно правильно вибрати протоколи спілкування між компонентами, щоб взаємодія була максимально ефективно;
3. Для розподіленої системи складно підтримувати сувору узгодженість: загальні частини системи потрібно або складати в загальну бібліотеку, але тоді при зміні цієї бібліотеки потрібно буде перезапускати і все залежні мікросервіси, або зберігати загальний код в кожному з мікросервісов, але такий код йде врозріз з принципом DRY ( Do not repeat yourself), і його складніше підтримувати;
4. Інша структура команди розробки. Команда розбивається на групи, кожна з яких повністю розробляє один мікросервіс. Глава Amazon Джефф Безос пропонує оптимальний розмір команди: щоб їх можна було нагодувати двома піцами, тобто 7-9 чоловік.

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

Спочатку - моноліт

Мартін Фаулер , Один з основоположників ідеї мікросервісов, запропонував об'єднати обидва підходи в один - «Спочатку - моноліт» (MonolithFirst). Основна ідея: «не слід починати новий проект з мікросервісов навіть при повній впевненості, що майбутнє додаток буде досить великим, щоб виправдати такий підхід». У монолітному проект простіше спостерігати зв'язність модулів і додавати новий функціонал. Потім система розбивається на кілька частин, і вони переробляються в відокремлені мікросервіси.

Так долається головний недолік створення мікросервісной архітектури з нуля: не потрібно витрачати багато часу на початкове розподіл системи на компоненти і організацію взаємодії між ними. Важливо вибрати правильний момент для початку поділу на сервіси: занадто рано - і мікросервіси НЕ будуть наповнені необхідної бізнес-логікою, занадто пізно - кордони модулів будуть розмиті, і розділити на мікросервіси буде складно. Вірна ознака, що потрібно починати ділити - коли вартість нового функціоналу стає вище, ніж користь від нього. Наприклад, якщо з додатком знадобилося підключення до декількох платіжних систем, варто виділити цю логіку в окремий сервіс, ніж пристосовувати всю систему під них.
Головний недолік такого підходу описаний в статті Do not start with a monolith : Складно розробляти монолітну структуру, яку згодом можна буде безболісно розділити на компоненти. З переходом на мікросервіси зміняться і команда, і процеси розробки. Наприклад, незалежна доставка змін кожного мікросервіса на бойовий сервер, Версіонування компонентів, дроблення команди на групи, достатні для обслуговування кожного мікросервіса.

Для яких рішень краще вибрати мікросервіси

Зверніть увагу на параметри проекту: предметну область, кваліфікацію команди, терміни релізу, навантаженість проекту, кількість зовнішніх систем, з якими програма повинна спілкуватися. Якщо на проекті не плануються високі навантаження і постійне додавання взаємодії із зовнішніми сервісами (платіжні системи, банки, зовнішні сховища тощо), краще вибрати моноліт. І навпаки: якщо система повинна працювати при будь-яких навантаженнях і з великою кількістю сервісів, то мікросервісная архітектури обов'язкове.
На момент написання статті ми з командою розробляємо систему управління мережею Постамат. Клієнт замовляє посилку в інтернет-магазині і забирає її у зручний час в одному з Постамат - ніяких черг на пошті і втрачених посилок. Після аналізу вимог ми вибрали мікросервісную архітектуру, т.к одна з умов існування системи - її постійне масштабування: система повинна взаємодіяти з платіжними системами, банками, агрегаторами посилок і т.п. І коли нам знадобилося інтегрувати систему з черговою транспортною компанією, ми зрозуміли, що прийняли правильне архітектурне рішення: кожен компонент незалежний, тому ми розробили новий мікросервіс незалежно від основної частини, не зупиняючи роботу системи.
Розповідь про досвід розробки мікросервісной архітектури буде неповний без згадки труднощів, з якими доведеться зіткнутися. Через пару місяців після першого релізу, ми виявили просідання продуктивності в деяких частинах системи. Це сталося через те, що кілька мікросервісов взяли на себе занадто багато бізнес-логіки. Звідси і головна порада: завжди звертайте увагу на те, як логіка додатка лягає на компоненти і будьте готові «перекроювати» ці компоненти для досягнення найкращого результату. Але навіть тут нам вдалося виправити ситуацію мінімальними витратами: перевантажені мікросервіси ми розділили на більш дрібні, один з компонентів - проксі запитів в систему - просто переписали з нуля з використанням більш швидких технологій. І найголовніше, всю роботу ми змогли распараллелить і надати користувачам сервісу перші результати оптимізації вже за кілька годин.

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