Що таке мікросервісна архітектура?
Мікросервісна архітектура – це підхід до розробки програмного забезпечення, при якому додаток складається з невеликих незалежних сервісів, кожен з яких виконує окрему функцію і взаємодіє з іншими через чітко визначені інтерфейси.
У цій статті ми розглянемо основи мікросервісів, їхні переваги і складнощі, а також дамо рекомендації щодо впровадження такої архітектури в проєкти різної складності. Посібник для архітектора-початківця ПЗ.
Про мікросервісну архітектуру
Сучасні додатки та сайти складаються з безлічі рядків коду, який пишуть різні люди. Тому важливо організувати все так, щоб під час поєднання різних шматочків проєкт працював як єдиний механізм.
Те, як організований код, називається архітектурою програмного забезпечення – вона буває монолітною або мікросервісною. Вибір архітектури залежить від проєкту: у великих проєктах розробники, як правило, обирають мікросервіси.
Що таке мікросервісна архітектура?
Мікросервісна архітектура – це підхід до розробки програмного забезпечення, за якого систему поділяють на невеликі незалежні сервіси. Кожен виконує певну функцію і взаємодіє з іншими сервісами через API.
Уявіть, що ви організовуєте файли на своєму комп’ютері. Можна скласти все в одну папку: і сімейні фото, і улюблені фільми, і робочі документи. Якщо у вас лише кілька файлів, нескладно знайти те, що потрібно. Але якщо їх сотні, доведеться довго гортати, перш ніж ви знайдете другу частину «Гаррі Поттера». Тому ми сортуємо файли по різних папках.
Приблизно так працюють мікросервіси – один сервіс виконує одну ізольовану функцію.
Відмінність мікросервісної архітектури від монолітної
Найлегше зрозуміти, як працює мікросервісна архітектура, якщо порівняти її з іншою популярною моделлю – монолітом.
Монолітна архітектура – традиційний підхід до розробки програмного забезпечення. Додаток являє собою модуль, у якому об’єднані всі компоненти. Управління інтерфейсом, бізнес-логікою і базою даних здійснюється в одному місці.
Монолітна архітектура здається більш простою і зрозумілою. Але, коли продукт розростається, підтримувати таку архітектуру стає складно.
Одна з компаній, яка використовує мікросервісну архітектуру, – Netflix. Платформа побудована на більш ніж 1000 мікросервісів. Безліч незалежних модулів відповідають за обробку особистих даних користувачів, здійснення платежів за передплатою і надання персоналізованих рекомендацій.
Склад мікросервісної архітектури
Склад мікросервісної архітектури формується набором окремих сервісів, кожен з яких відповідає за конкретну бізнес-функцію. Ці сервіси взаємодіють між собою через стандартизовані інтерфейси, що забезпечує їхню незалежність та гнучкість у розвитку.
Мікросервіс
Мікросервіс – це невеликий автономний компонент системи. Його можна розробити і розгорнути незалежно від інших компонентів. Кожен модуль відповідає за конкретну функцію.
Система може бути розподіленою. Це означає, що мікросервіси можуть працювати на різних серверах і зв’язуватися один з одним.
API
API – це набір правил і команд, який дає змогу різним програмам взаємодіяти одна з одною.
У мікросервісній архітектурі API – набір універсальних «ручок», доступ до яких можна надати кожному. Якщо треба, щоб один із мікросервісів щось зробив, то можна просто «смикнути ручку» й отримати відповідь. При цьому не треба знати, як сервіс виконуватиме завдання.
Роботу API можна розглянути на прикладі автомобіля. Під капотом у нього знаходиться двигун, система управління кліматом, електроніка і безліч датчиків. У салоні водій бачить тільки кнопки і важелі.
Якщо він захоче набрати швидкість, то просто сильніше натисне на педаль газу. Йому не треба знати, як у цей момент подаватиметься паливо і охолоджуватиметься двигун. У цьому випадку елементи управління в салоні авто – ручки API.
API-шлюзи (API Gateways)
Уявімо, що ви хочете потрапити в будівлю, але, щоб увійти, потрібно пройти через охоронця. Він перевіряє вашу особу, дозволяє увійти і підказує, як зорієнтуватися всередині будівлі. У світі комп’ютерних програм ці функції виконують API-шлюзи (API Gateways). Вони – провідники між різними частинами сервісу. Коли одна частина програми хоче надіслати запит іншій, вона робить це через шлюз.
API Gateway перевіряє, чи має програма право робити те, що вона запитує. Це як перевірка вашого паспорта охоронцем. Якщо все гаразд, він спрямує програму туди, куди потрібно, – як охоронець, який направляє вас у потрібне місце.
Шлюз може зберігати деякі відповіді, щоб не запитувати їх щоразу заново. Це так, ніби охоронець пам’ятав, що ви вже були тут раніше і відразу вас пропускав.
Так що API Gateway – це такий контрольно-пропускний пункт для взаємодії різних частин програми між собою. Він перевіряє рівні доступу і направляє запит у потрібний бік.
Бази даних
База даних – це віртуальне сховище інформації. Замість того щоб тримати дані в окремих файлах або таблицях, їх поміщають у єдину базу. Так набагато швидше і зручніше шукати інформацію.
Найчастіше база даних має вигляд набору таблиць, де кожна представляє певний тип даних, наприклад інформацію про користувачів програми. Кожен рядок таблиці представляє окремий запис, а стовпці визначають різні атрибути, наприклад стать і вік. За допомогою спеціальних запитів можна витягувати, оновлювати, додавати або видаляти дані з таблиць.
Ще зустрічаються нереляційні бази даних – їх називають NoSQL (тобто не пов’язані з мовою SQL). У них подання інформації не прив’язане до табличного вигляду.
Мікросервіси використовують бази даних для зберігання інформації. При цьому у кожного сервісу вона може бути своя. Наприклад, в інтернет-магазині один мікросервіс відповідає за те, щоб заносити дані нових користувачів у базу, а інший – довантажує дані про товари зі своєї бази в міру оновлення сторінки.
Моніторинг
Системи моніторингу аналізують стан кожного мікросервісу для підтримки працездатності всього застосунку. Кожен мікросервіс записує логи – файли, які містять інформацію про його роботу. Це можуть бути повідомлення про події, помилки, запити та інші важливі моменти.
За допомогою цього можна автоматично збирати метрики для оцінки продуктивності мікросервісів. Усі отримані дані зберігаються, щоб потім можна було проаналізувати аномалії та тренди.
Конфігурація
Конфігурація в мікросервісах – централізований спосіб зміни параметрів, які впливають на роботу всієї системи. Оскільки мікросервіси розробляють незалежно один від одного, важливо мати можливість змінювати конфігурацію не лише окремих сервісів, а й одразу всіх компонентів без перезапуску.
Уявіть собі кав’ярню з різними напоями в меню: еспресо, лате та американо. Для кожного виду кави є рецепт, у якому зазначено кількість зерен, їхній сорт, температура води та час заварювання. Рецепти – це ваша конфігурація.
Якщо ви вирішите змінити порядок приготування еспресо, то краще відразу оновити рецепт у базі даних закладу. Інакше доведеться бігати по всьому кафе і розповідати кожному бариста про те, як тепер слід заварювати еспресо.
Контейнеризація
Для розгортання і масштабування мікросервісів використовую контейнери і системи оркестрації. Найчастіше розробники обирають для цього популярні Docker і Kubernetes.
За допомогою контейнерів можна упакувати мікросервіси з усім необхідним для перенесення на сервер. Якщо треба буде переїхати, то розробникам не доведеться збирати все знову. Це і робить мікросервіси переносними. Ще контейнери відповідають за ізоляцію, запобігаючи впливу сервісів один на одного.
Плюси та мінуси архітектур
Кожна архітектурна модель має свої переваги та недоліки, які варто враховувати при виборі підходу до розробки програмного забезпечення.
Монолітна
Монолітна архітектура іноді може бути корисною.
Переваги
- Простота розробки. Усі компоненти застосунку знаходяться в одному місці, що робить процес розробки простим і прозорим.
- Простота розгортання. Розгортання монолітного застосунку простіше, оскільки для цього не потрібно керувати великою кількістю мікросервісів.
- Менші витрати на інфраструктуру. Моноліти часто вимагають менше інфраструктури для розгортання і підтримки, що допомагає скоротити витрати на розробку.
- Зменшена залежність від мережі. Оскільки всі частини застосунку працюють у межах одного процесу, немає потреби в постійній взаємодії через мережу.
Недоліки
- Складність масштабування. Моноліти можуть зіткнутися з труднощами в масштабуванні, особливо якщо певні частини застосунку потребують більше ресурсів.
- Взаємозалежність компонентів. Якщо одна частина моноліту потребує змін, це може вплинути на всю систему, що ускладнює внесення змін.
- Складність підтримки. Великі проєкти важко підтримувати і розуміти, як працюють усі їхні компоненти.
- Обмежена гнучкість. Зміни в одній частині моноліту можуть торкнутися інших, що може зробити систему менш гнучкою і податливою до змін.
- Обмеженість стека. Моноліти зазвичай використовують єдиний стек технологій, що обмежує можливості використання різних технологій для різних компонентів.
Мікросервісна
Мікросервісна архітектура має низку переваг перед монолітною архітектурою.
Переваги
- Гнучкість. Мікросервіси дають змогу розробляти, змінювати та масштабувати окремі частини застосунку незалежно від інших. Це робить систему більш гнучкою.
- Масштабованість. Кожен мікросервіс можна масштабувати окремо від усієї системи. Складність проєкту зростає разом зі збільшенням навантаження.
- Ізоляція помилок. Проблеми в одному мікросервісі рідко впливають на інші, а отже, шукати й усувати помилки стає простіше.
- Свобода стека. Для кожного мікросервісу можна вибрати свій стек технологій і мову програмування. Це дає більше свободи розробникам.
Недоліки
- Складність управління. Що більше мікросервісів у проєкті, то складніше ними керувати. Для цього потрібні додаткові інструменти та фахівці.
- Залежність від мережі. Мікросервіси спілкуються один з одним мережею, це може викликати затримки і проблеми з продуктивністю.
- Витрати на розгортання та інфраструктуру. Розгортання і підтримка інфраструктури для мікросервісів обходиться дорожче.
- Кожен із цих двох методів підходить для створення програмного забезпечення в різних ситуаціях. Моноліт – коли потрібно швидко запустити і протестувати невеликий застосунок. Мікросервіси – для складних систем, які будуть доповнюватися і розвиватися роками.
Висновок
Мікросервісна архітектура підходить для проєктів зі складною логікою та великими командами, де важлива масштабованість і швидкість змін.
Водночас вона вимагає більше уваги до організації процесів і підтримки інфраструктури. Вибір між монолітом і мікросервісами залежить від конкретних потреб проєкту, ресурсів і планів розвитку.
