Мікросервісна архітектура (MSA): коли потрібна бізнесу

Мікросервісна архітектура (Microservices Architecture, MSA) — це підхід до розробки програмного забезпечення, в якому застосунок розбивається на маленькі незалежні частини, що «спілкуються» одна з одною через API.

IT-компанії десятиріччями використовували монолітну архітектуру. Та у 2000-х роках, коли бізнеси почали активно масштабуватися, недоліки моноліту стали особливо відчутними. Класичний моноліт складно масштабувати та оновлювати, адже збій у роботі однієї частини коду може вразити всю систему.

Термін «мікросервіси» почали активно використовувати у 2011–2012 роках, а 2014 року британський розробник Мартін Фаулер та американський консультант із програмного забезпечення Джеймс В. Льюїс опублікували статтю, де сформулювали концепцію мікросервісів та описали принципи їхньої роботи.

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

Мікросервіси взаємодіють між собою через API або системи обміну повідомленнями та використовують API Gateway як єдину точку входу для клієнтів. Це працює так: ви натискаєте «додати в кошик», запит спочатку потрапляє до Gateway, який перевіряє авторизацію та передає його до відповідного сервісу. 

Окремі частини системи спілкуються між собою двома способами: синхронно та асинхронно. Якщо результат потрібен одразу, наприклад, треба перевірити баланс гаманця перед оплатою, взаємодія синхронна — відповідь надходить одразу. Коли можна почекати, наприклад, сервіс оплати повідомляє сервісу сповіщень, що кошти надійшли на рахунок — він надсилає подію в чергу, як лист на пошту. У разі збою повідомлення буде доставлено пізніше. Це дозволяє системі працювати швидше та стабільніше під навантаженням.

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

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

Мікросервісна архітектура має багато переваг:

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

Мікросервіси природно інтегруються з хмарною інфраструктурою: контейнерами, автоматичним масштабуванням і моделлю pay-as-you-go. Компанії, що переходять на MSA, зазвичай ефективніше використовують хмарні ресурси, адже можуть масштабувати лише ті сервіси, які реально навантажені в конкретний момент. 

Щоб оптимізувати витрати на IT-інфраструктуру, використовуйте Kyivstar Cloud — зручне рішення, що дозволяє розгортати IT-сервіси в хмарі. Надаємо віддалений доступ до окремого фізичного сервера та обчислювальних потужностей, аби ви могли працювати з високонавантаженими системами, масштабувати ресурси та будувати власну приватну хмару, не збільшуючи мережеву затримку.

Попри всі перелічені переваги, мікросервіси — це не універсальне рішення для кожного бізнесу. Десятки сервісів — це десятки процесів, за якими треба стежити одночасно, тож операційне навантаження зростає в рази. Підтримка складніша, моніторинг дорожчий.

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

Мікросервісна архітектура підійде:

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

Історія однієї з найвідоміших служб таксі у світі, компанії Uber, починається з того, як двоє її майбутніх засновників не змогли зловити таксі в Парижі далекого 2008 року і вирішили запустити свій сервіс. Вони почали з моноліту — одна база даних і невелика команда. Спочатку Uber був доступний тільки в Сан-Франциско, та швидко став масштабуватися на інші міста та країни. Так почалися проблеми — будь-яке незначне оновлення вимагало релізу всієї системи.

У 2012 році компанія почала перехід на мікросервісну архітектуру. Однак кількість сервісів швидко перевищила сотні: сьогодні в Uber понад 4000 мікросервісів. У якийсь момент компанія навіть зіткнулася з так званим мікросервісним хаосом, коли стало складно зрозуміти, який сервіс за що відповідає і хто є його власником. Через це Uber довелося інвестувати у створення внутрішньої платформи для управління сервісами та їхніми залежностями. 

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

Що врахувати бізнесу при переході на мікросервісну архітектуру:

• зростає складність інфраструктури та підтримки;
• збільшується навантаження на DevOps-команди;
• складніше тестувати й відстежувати помилки в розподіленій системі;
• з’являються ризики затримок і збоїв через мережеву взаємодію між сервісами;
• потрібні додаткові інструменти, щоб моніторити та управляти сервісами;
• для невеликих продуктів мікросервіси часто створюють більше складності, ніж користі.

MACH — це абревіатура з чотирьох принципів: 

• Microservices: система складається з незалежних сервісів;
• API-first: усі компоненти взаємодіють через API;
• Cloud-native: продукт одразу створюють для роботи в хмарі, а не переносять туди зі старого сервісу;
• Headless: backend (логіка та дані) повністю відокремлений від frontend (того, що бачить користувач). Один backend може працювати і для сайту, і для мобільного застосунку.

Термін MACH-підхід був формалізований у 2020 році з появою MACH Alliance — об’єднання технологічних компаній, які почали просувати цей підхід як альтернативу монолітним платформам. 

MACH — це розширення ідеї мікросервісної архітектури до рівня бізнес-стратегії: не просто технічний вибір, а підхід до побудови всього продукту.