Мікросервісна архітектура

Read same in English

Microservice architecture

Термін “Мікросервісна архітектура”, також відомий як мікросервіси, з’явився в середині 2010-х, щоб описати особливий архітектурний стиль розробки програмних додатків. Цей стиль розробки отримав розповсюдження в зв’язку з розвитком практик гнучкої розробки та DevOps. На даний момент мікросервісній архітектурі приділяється багато уваги: статті, блоги, дискусії в соціальних мережах і презентації на конференціях. Коли йдеться про забезпечення гнучкої розробки і доставки складних корпоративних додатків — такий спосіб розробки має значні переваги.

Якщо коротко, то архітектурний стиль мікросервісів — це підхід, коли єдиний додаток будується як сукупність невеликих, самодостатніх, незалежних, не тісно зв’язаних сервісів, що спілкуються між собою за допомогою легких механізмів як то HTTP, gRPC, AMQP. Ці сервіси побудовані навколо бізнес-потреб (кожен відповідальний за конкретний процес) та розгортаються незалежно з використанням повністю автоматизованого середовища. Існує абсолютний мінімум централізованого управління цими сервісами. Самі по собі сервіси можуть бути написані на різних мовах і використовувати різні технології зберігання даних.

Причини використання

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

При всьому цьому не потрібно забувати що такий підхід додає додаткову складності проекту в цілому. Нам потрібні DevOps’и для моніторингу та управління, при цьому між ними і розробниками повинні бути тісні відносини і хороша взаємодія. При роботі з мікросервісами нам доводиться більше розгортати, ускладнюється система моніторингу, сильно розростається кількість можливих збоїв. Тому в компанії дуже важлива сильна DevOps-культура.

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

Для того щоб простіше розпочати знайомство з мікросервісною архітектурою потрібно порівняти цей стиль розробки з так званим монолітним стилем.

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

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

Тому веб проекти все частіше розробляються як окремі сервіси що можна розгортати та масштабувати окремо.

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

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

Переваги та недоліки мікросервісів

До переваг можемо віднести:

• Сервіси запускається швидше, що робить розробників більш продуктивними та прискорює розгортання
• Кожен сервіс може бути розгорнутий незалежно від інших. Тож якщо ви змінюєте щось в одному з них, ви можете розгорнути ці зміни, не чіпаючи інших мікросервісів, які можуть продовжувати працювати.
• Кожен сервіс може бути масштабований окремо.
• Баг в одному мікросервісі не підірве роботу системи. Неполадки у мікросервісі не повинні зламати весь додаток. Швидше за все, вони не вплинуть суттєво на роботу додатку, особливо великого.
• Усуваються будь-які довгострокові зобов’язання щодо технології. При розробці нового сервісу ви можете вибрати новий стек технологій. Будь-який сервіс у системі можна замінити. Його можна переписати з нуля в межах прийнятного часу та бюджету без необхідності перебудовувати всю систему.
• Мікросервіси, як правило, краще організовані, оскільки кожен мікросервіс має дуже специфічну роботу і не займається роботою інших сервісів. Тож потенційно легші для розуміння, підтримки і тестування.
• Також відокремлені сервіси легше перекомпонувати і переналаштувати, щоб виконувати задачі різних додатків (наприклад, обслуговувати веб-клієнтів і публічний API).

Недоліки мікросервісів:

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

Мікросервіси як подолання складності

Багато відомих компаній вирішили проблему моноліту, прийнявши архітектуру мікросервісів, замість того, щоб будувати єдиний монструозний моноліт. Серед них маємо Amazon, eBay, Walmart, Netflix, SoundCloud, Spotify, Twitter, Stripe, PayPal, Uber та Medium.

Доречі статтю одного з розробників Medium про перехід від моноліту до мікросервісів я знайшов зовсім нещодавно.

Microservice Architecture at Medium

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

Висновок

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

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

Мені як full stack розробнику, що цікавиться технологіями Docker та Kubernetes, розділяє принцип “Під кожну задачу свій інструмент”. Мікросервісна архітектура дуже імпонує.