Що таке мікросервіси?
Мікросервіси — архітектурний підхід, за якого застосунок складається з кількох невеликих самостійних сервісів. Кожен відповідає за свою область — оплату, каталог, сповіщення, — розгортається окремо й спілкується з рештою через API.
Головна перевага — незалежність. Команди випускають свої сервіси, не чекаючи одна на одну, кожен сервіс масштабується окремо під своє навантаження, а відмова одного не обовʼязково роняє всю систему.
Ціна — складність експлуатації. Зʼявляються мережеві затримки, розподілені помилки, потреба у наскрізному логуванні та узгодженості даних між сервісами. Тому більшість продуктів розумно починати з моноліту й виділяти сервіси тоді, коли для цього є конкретна причина.
Де застосовується
До мікросервісів приходять великі системи з великими командами: маркетплейси, банки, сервіси доставки, телеком. Каталог, оплата, сповіщення і пошук живуть окремо, розгортаються незалежно і можуть бути написані різними мовами — команда обирає те, що краще підходить її задачі.
Платою за гнучкість стає інфраструктура. Потрібні контейнери й оркестрація, наскрізне трасування запитів, централізовані логи, обробка відмов і продумані контракти між сервісами. Саме тому нові продукти частіше стартують одним застосунком і розділяються пізніше, коли біль від спільного коду стає реальним.
Приклад
У чорну пʼятницю навантаження зростає лише на каталог і оплату. У мікросервісній архітектурі масштабують саме ці два сервіси, залишивши решту в попередньому вигляді. У єдиному застосунку довелося б збільшувати потужність для всієї системи цілком.
Часті запитання
Чим мікросервіси відрізняються від моноліту?
Моноліт — один застосунок, який збирається і розгортається цілком. Мікросервіси — набір окремих сервісів, кожен зі своєю базою і релізним циклом. Моноліт простіший у розробці та експлуатації, мікросервіси виграють у незалежності команд і точковому масштабуванні.
З чого краще починати новий проєкт?
У переважній більшості випадків — з моноліту, але з акуратно розділеними модулями. Поки продукт шукає свою форму, межі між сервісами змінюються, і зафіксувати їх надто рано — означає отримати всю складність розподіленої системи без її переваг.
Які складнощі зʼявляються з мікросервісами?
Мережеві виклики можуть падати і пригальмовувати, транзакція тепер охоплює кілька сервісів, логи розкидані по різних системах, а відтворити проблему на своїй машині помітно складніше. Додається й експлуатація: наскрізний моніторинг, версіонування контрактів, узгоджені розгортання.
Як мікросервіси спілкуються між собою?
Найчастіше синхронно через REST чи gRPC, коли відповідь потрібна негайно, і асинхронно через черги повідомлень на кшталт Kafka чи RabbitMQ, коли важлива стійкість до тимчасової недоступності. Зрілі системи зазвичай використовують обидва способи в різних сценаріях.