У 60-х і 70-х роках, монолітна архітектура був запозичений для розроблення додатків через обмежені обчислювальні ресурси, які вимагали поєднання всіх функцій в одну, цілісну одиницю.
Усе змінилось наприкінці 1990-х і 2000-х років, коли монолітна архітектура почала не справлятися зі зростаючим розміром і складністю додатків, особливо з розвитком інтернету та розподілених систем.
Це привело до розроблення більш модульних підходів, таких як архітектури, орієнтовані на сервіси (SOA) та, пізніше, архітектури мікросервісів (MSA), які набули широкого поширення на початку 2010-х років.
На цьому дозвіл мене зупинитися — це лише стисла пояснення базового концепту мікросервісів. Давайте розглянемо, як мікросервіси витіснили монолітну архітектуру, як вони працюють, та наведемо приклади. Потім обговоримо ключові аспекти розгортання мікросервісів і що робити, якщо ви хочете їх розгорнути.
Що таке мікросервіси? Як вони працюють?
Як я вже згадував, мікросервіси з'явилися як відповідь на зростаючу складність і розмір додатків — вони дозволяють компаніям розбити функціональність на незалежно розгортаємі сервіси.
Термін «мікросервіси» популяризували гідеї Мартін Фаулер та Джеймс Льюїс, які формально представили його в статті блогу в 2014 році. Їхня робота визначила ключові принципи та характеристики, включаючи необхідність незалежно розгортаємих сервісів, децентралізованого управління даними та агностицизму до технологій.
З тих пір мікросервіси стали основним архітектурним вибором, підтриманим прогресом у технологіях контейнеризації, як Docker, інструментах оркестрування, як Kubernetes, та платформах бессерверних обчислень. Але як працюють мікросервіси?
Як працюють мікросервіси?
По суті, архітектура мікросервісів розбиває велику програму на менші окремі сервіси, кожен з яких відповідає за конкретну бізнес-функцію. Ці сервіси взаємодіють один з одним через мережу, часто за допомогою REST API, gRPC або брокерів повідомлень, таких як RabbitMQ чи Apache Kafka.
Згідно визначення Мартіна Фаулера та Джеймса Льюїса, мікросервіси мають чотири ключові характеристики:
- Одна відповідальність: Кожен мікросервіс розроблений для виконання конкретного завдання або функції, що дозволяє спеціалізуватися та зменшує складність.
- Незалежність: Мікросервіси можна розробляти, розгортати та масштабувати незалежно один від одного, що забезпечує гнучкість і стійкість.
- Децентралізоване управління даними: Мікросервіси часто мають свої власні бази даних, уникаючи потреби в єдиній централізованій базі.
- Технологічна нейтральність: Команди можуть вибрати найкращу технологію для кожного сервісу, не будучи обмеженими виборами інших сервісів.
Цей підхід контрастує з традиційною монолітною архітектурою, де всі компоненти програми тісно інтегровані в одну цілісну одиницю.
Ключові етапи розгортання мікросервісів
Хоча архітектура мікросервісів пропонує багато переваг — високу масштабованість, гнучкість, ефективність, ізоляцію помилок тощо — вона вимагає знання, як правильно розгортати мікросервіси, та вимагає ретельного планування для успіху.
Саме тому важливо мати комплексне розуміння ключових концептів, етапів та практик розгортання мікросервісів для успішної архітектури. Тож давайте розглянемо ключові етапи розгортання мікросервісів та що означає кожен етап.
Планування та підготовка до розгортання мікросервісів
Усе добре потребує планування та терпіння. Успішне розгортання мікросервісів — не виключення. Вам знадобиться ретельне планування та підготовка. Саме тому важливо дотримуватися найкращих практик мікросервісів і все детально підготувати перед розгортанням.
Як я згадував раніше, один із ключових принципів мікросервісів — це Принцип єдиної відповідальності. Якщо кожен мікросервіс відповідає за одну функцію, ваша команда зможе розробляти, розгортати та масштабувати сервіси незалежно один від одного.
Крім того, розширення цього принципу — це принцип слабкого зв'язку. Це означає, що кожен сервіс працює незалежно і мінімально залежить від інших сервісів при обміні даними. Таким чином, зміни в одному сервісі не впливають на інші, що дозволяє масштабувати мікросервіси самостійно.
Це знижує ризик каскадних збоїв, коли проблема в одній частині системи запускає ланцюгову реакцію відмов по всій системі.
Важлива практика — виділена система зберігання даних для кожного сервісу. Це розширення принципу слабкого зв'язку, яке запобігає конфліктам і підвищує масштабованість сервісу.
Вам також потрібні асинхронні закономірності комунікації мікросервісів, наприклад черги повідомлень, щоб забезпечити спілкування сервісів без прямих залежностей.
Останній крок — впровадження конвеєрів неперервної інтеграції та доставки (CI/CD) для мікросервісів. Ці конвеєри дозволяють командам розгортати нові можливості або виправлення через Інструменти CI/CD такі як Jenkins та GitLab, дозволяючи організаціям зберігати стабільність системи при частому випуску нових можливостей.
Тепер, коли ви мають загальне уявлення про планування та підготовку для розгортання мікросервісів, давайте поговоримо про стратегії розгортання.
Стратегії розгортання мікросервісів
Вибір стратегії розгортання залежить від функцій сервісу, трафіку, інфраструктури, знань команди та витрат. Загалом, стратегії розгортання мікросервісів виглядають так:
- Екземпляр сервісу на контейнер Кожен мікросервіс працює у власному контейнері, що забезпечує кращу ізоляцію, ніж модель з декількома екземплярами на хості. Контейнери спрощують масштабування та поліпшують розподіл ресурсів.
- Екземпляр сервісу на віртуальну машину Кожен сервіс працює на окремій віртуальній машині (VM), забезпечуючи ще більшу ізоляцію, ніж контейнери. Хоча це покращує безпеку та стабільність, витрати ресурсів зазвичай вищі.
- Поетапні випуски: Спочатку розгорніть нову версію мікросервісу для невеликої групи користувачів, перевіривши її стабільність перед повним випуском. Цей підхід мінімізує вплив проблем і дозволяє швидко повернутися до попередної версії для збереження цілісності системи.
- Розгортання синього-зеленого Цей метод використовує два ідентичні виробничі середовища: одне обслуговує реальний трафік, друге використовується для тестування нового випуску. Розгортання синього-зеленого забезпечує легкий откат і оновлення без простоїв, оскільки трафік можна плавно перемикати між обома середовищами.
- Поетапні випуски: Ця стратегія передбачає поступовий випуск оновлень для різних груп користувачів або середовищ. Часто починається з внутрішніх середовищ перед переходом до виробництва, обмежуючи область впливу потенційних проблем і дозволяючи команді вирішувати проблеми поетапно.
- Безсерверний розпорядок Цей підхід використовує безсерверні платформи, такі як AWS Fargate та Go Google Cloud Run, які автоматизують управління інфраструктурою, беручи на себе масштабування та розподіл ресурсів. З безсерверним розгортанням ви не потребуєте управління базовими серверами, що дозволяє зосередитися на самих мікросервісах.
Після вибору однієї зі стратегій розгортання мікросервісів вам знадобиться інструмент оркестрації мікросервісів.
Оркестрування мікросервісів
Вибравши одну з багатьох стратегій розгортання мікросервісів, вам знадобиться инструмент для оркестрування мікросервісів. Інструменти оркестрування мікросервісів, такі як Kubernetes, автоматизують розгортання мікросервісів, масштабування, моніторинг і управління контейнеризованими мікросервісами.
Наприклад, Airbnb використовує Kubernetes, що дозволяє його інженерам розгортати сотні змін до своїх мікросервісів без ручного контролю. Однією з важливих функцій інструментів оркестрування мікросервісів, як Kubernetes, є вбудоване балансування навантаження.
Якісне балансування навантаження розподіляє вхідний трафік між кількома екземплярами мікросервісу. Це запобігає тому, щоб окремий екземпляр став вузьким місцем, і підвищує здатність системи справлятися зі скачками навантаження.
Kubernetes відіграє важливу роль в управлінні мікросервісами через функцію самовідновлення, де невдалі контейнери автоматично замінюються і перезапускаються. The New York Times використовує цю функцію для підтримання мікросервісів без впливу на користувацький досвід і без простоїв.
Крім того, Kubernetes підвищує безпеку мікросервісів завдяки шифруванню конфігурацій і секретів, таких як облікові дані баз даних або API ключі, за допомогою ConfigMaps і Secrets. Це особливо важливо для компаній і сервісів, як Uber, що працюють з чутливими даними клієнтів і користувачів.
Нарешті, інструменти оркестрування мікросервісів, як Kubernetes, особливо корисні для стратегій мікросервісів, які передбачають поступові оновлення та відкати, наприклад поетапні випуски. Поступові оновлення дозволяють розгортати нові версії мікросервісів без переривання обслуговування, утримуючи запущеними кілька екземплярів старої версії.
Після налаштування інструмента оркестрування мікросервісів вам потрібно буде створити й автоматизувати Конвеєри CI/CD для розгортання мікросервісів.
CI/CD-конвеєри для розгортання мікросервісів
Як ми говорили раніше, конвеєри безперервної інтеграції та безперервної доставки для мікросервісів є важливими аспектами розгортання мікросервісів. CD-конвеєри в CI/CD-конвеєрах відповідають за автоматичне розгортання змін коду в production, як тільки вони пройдуть етапи тестування і інтеграції CI/CD-конвеєра.
Потім вступає в дію CD-частина CI/CD-конвеєра, так що кожен раз, коли зміни коду пройдуть етапи тестування і інтеграції, сервіс розгортається в інструмент оркестрування мікросервісів, такий як Kubernetes-кластер.
Крім того, етапи тестування й інтеграції повністю автоматизовані CI/CD-конвеєрами, оскільки до конвеєра включені модульні тести, інтеграційні тести та наскрізні тести.
Це дозволяє командам перевіряти оновлення на кожному етапі, одночасно зберігаючи стабільність системи. Крім того, якщо виникнуть проблеми зі змінами коду, незважаючи на різноманітне тестування, автоматичні відкати можуть повернути попередню стабільну версію.
Нарешті, впровадження CI/CD-конвеєрів для мікросервісів відповідно до найкращих практик мікросервісів допомагає організаціям досягти швидшого розробки, скоротити ручні помилки і підтримувати високі стандарти якості.
Багато компаній, таких як Spotify, Expedia, iRobot, Lufthansa, Pandora тощо, використовують CI/CD-конвеєри для мікросервісів через інструменти CI/CD, як CircleCI, AWS CodePipeline та GitLab, для автоматизації процесів розгортання, забезпечення узгодженої якості коду та швидкої доставки нових функцій при збереженні стабільності системи.
Моделі взаємодії мікросервісів
Те, як мікросервіси взаємодіють один з одним, повністю залежить від функції, загальної архітектури, бажаної масштабованості й надійності ваших мікросервісів. Загалом використовуються два основні типи моделей взаємодії мікросервісів: синхронний та асинхронний моделі взаємодії мікросервісів.
У синхронних моделях взаємодії мікросервісів сервіси взаємодіють в реальному часі, що означає, що сервіс надсилає запит і чекає на відповідь перед продовженням. Найчастіше використовуються такі синхронні моделі взаємодії мікросервісів: REST (Representational State Transfer) API, gRPC (Go Remote Procedure Call), і GraphQL.
Як правило, такі моделі взаємодії мікросервісів використовуються в галузях і компаніями, які зазвичай потребують обробки даних в реальному часі й миттєвих відповідей. Галузі, як фінанси, охорона здоров'я та електронна комерція, часто використовують синхронні моделі взаємодії для забезпечення того, щоб транзакції, отримання даних або взаємодія відбувалися миттєво, зберігаючи плавний та чуткий користувацький досвід.
Однак, хоча синхронні моделі взаємодії мікросервісів мають переваги, як-от відповіді в реальному часі та простота, вони також мають певні недоліки, такі як можливі вузькі місця через тісний зв'язок, низька масштабованість під високим навантаженням, повільні часи відповіді й висока затримка в періоди високого трафіку.
З іншого боку, асинхронні шаблони комунікації мікросервісів зазвичай більше підходять для мікросервісів, оскільки вони базуються на принципі слабого зв'язку, про який ми говорили раніше.
Цей тип шаблону комунікації мікросервісів розв'язує сервіси, дозволяючи їм надсилати та отримувати повідомлення через брокер, як от Kafka або RabbitMQ. Надсилаючи повідомлення до черги, яка служить буфером, сервіси спілкуються незалежно один від одного, а не чекають відповіді, як у синхронних шаблонах комунікації. Цей буфер дає іншим сервісам можливість обробляти повідомлення в своєму темпі, дозволяючи відправнику продовжувати роботу без очікування.
Асинхронний шаблон комунікації мікросервісів не лише забезпечує розв'язаність сервісів під час розгортання, але й дає таку саму реакцію в реальному часі, яку забезпечують синхронні шаблони комунікації мікросервісів.
Це обумовлено архітектурою, керованою подіями, в асинхронних шаблонах комунікації мікросервісів, коли сервіси спілкуються, видаляючи події при виникненні конкретної дії. Інші сервіси можуть підписатися на ці події та реагувати відповідно. Це дозволяє створити системи, що реагують швидко на зміни в реальному часі без прямого зв'язку між сервісами.
Крім того, в асинхронному Pub/Sub (Publish-Subscribe) у шаблонах комунікації мікросервісів сервіси (видавці) надсилають повідомлення в тему, а інші сервіси (підписники) слухають цю тему, щоб отримати оновлення. Цей моделю підтримує кількох підписників, одночасно розсилаючи повідомлення багатьом сервісам.
На завершення, подібно до шаблонів, керованих подіями, асинхронні хореографія-орієнтована сага шаблони комунікації мікросервісів також використовують події для комунікації один з одним; проте в цьому шаблону існує певний порядок, що означає, що події запускають наступний крок та активують конкретний сервіс.
Різниця тут полягає в тому, що в шаблонах, керованих подіями, немає певної послідовності або робочого процесу, і кілька сервісів можуть реагувати на подію, на відміну від конкретного процесу та порядку в шаблоні choreography-based saga.
Той тип асинхронного шаблону комунікації мікросервісів, який ви використовуєте, залежить від завдання та загальної функції ваших мікросервісів. Черги повідомлень, такі як RabbitMQ та Amazon SQS, зазвичай використовуються для планування завдань, розподілу навантажень та електронної комерції для обробки замовлень і систем сповіщень.
Брокери повідомлень, керовані подіями, як от Apache Kafka та AWS EventBridge, зазвичай використовуються для обробки великомасштабних потоків подій у реальному часі та маршрутизації подій між мікросервісами в областях, таких як фінансові послуги та AWS середовищах.
Що стосується брокерів Pub/Sub, таких як Google Cloud Pub/Sub та Redis Streams, ці брокери повідомлень зазвичай використовуються для масштабної обробки повідомлень у розподілених системах для аналітики в реальному часі та прийому подій, а також для сповіщень у реальному часі та застосунків чату.
Нарешті, брокери повідомлень choreography-based saga в основному використовуються для обробки замовлень в електронній комерції, систем бронювання подорожей та використання, де складні багатокрокові транзакції потребують координації між кількома сервісами без централізованого контролю.
Виявлення сервісів мікросервісів
Після того як ви встановили та реалізували шаблон комунікації, який відповідає вашим потребам, вам потрібно переконатися, що ваші сервіси можуть знаходити один одного на початку. Як я згадував раніше, інструменти оркестрування мікросервісів, такі як Kubernetes, відіграють важливу роль у виявленні сервісів мікросервісів.
Це здійснюється через вбудоване виявлення сервісів, яке надає Kubernetes DNS, яке динамічно оновлює IP-адреси та DNS записи по мірі масштабування або переміщення сервісів у кластері.
Цей метод виявлення сервісів мікросервісів називається виявленням на стороні сервера, оскільки відповідальність за маршрутизацію делегована балансувальнику навантаження, який потім запитує реєстр і спрямовує трафік на відповідний примірник.
З іншого боку, у нас також є метод виявлення на стороні клієнта для виявлення сервісів мікросервісів, коли сервіс або API шлюз запитує реєстр сервісів, як от Consul або Eureka, щоб знайти доступні примірники.
Вибір найкращого методу виявлення сервісів для розгортання мікросервісів залежить від вимог та масштабу системи.
При виявленні сервісів мікросервісів на стороні клієнта клієнт має повний контроль над тим, з яким примірником він спілкується. Це не лише дозволяє більше налаштувань, але й зменшує складність, оскільки не потрібна централізована служба виявлення.
Наприклад, розгортання мікросервісів Netflix використовує виявлення сервісів на стороні клієнта з Eureka та Ribbon для балансування навантаження, дозволяючи клієнту вибрати найкращий примірник на основі критеріїв, як от затримка та навантаження на сервер.
Проте виявлення сервісів мікросервісів на стороні сервера більше підходить для більших середовищ, оскільки централізоване виявлення сервісів може підвищити ефективність і забезпечити послідовне балансування навантаження в розподіленій системі.
Рішення виявлення сервісів мікросервісів на стороні сервера, такі як Kubernetes, AWS Elastic Load Balancing та API Gateways (Kong, NGINX та інші), допомагають ефективно маршрутизувати трафік та підтримувати високу доступність, і використовуються компаніями, як от Airbnb, Pinterest, Expedia, Lyft та іншими.
Безпека мікросервісів
Хоча монолітна архітектура в більшості аспектів поступається мікросервісам, в одному вона мала перевагу — безпека. Оскільки мікросервіси побудовані на принципі вільного зв'язку та мають розподілений характер, неможливо впровадити єдиний універсальний захід безпеки.
Кожен сервіс потребує незалежного захисту, тому необхідні додаткові заходи, оскільки поверхня атаки мікросервісів значно більша. Для цього зазвичай використовують стандарти OAuth2 та JSON Web Tokens (JWT) для автентифікації та авторизації, як ви, мабуть, вже здогадалися.
Крім того, часто застосовується шлюз API для управління безпекою мікросервісів, оскільки він забезпечує автентифікацію та авторизацію на вхідній точці. До того ж, API шлюзи можуть також впровадити обмеження частоти запитів, логування та моніторинг, що додає додаткові рівні безпеки мікросервісів.
Хоча ці заходи захищають основну вхідну точку, для забезпечення взаємодії між сервісами потрібні додаткові механізми безпеки.
Тут на допомогу приходять сіткові сервіси, які додають рівень мережевої безпеки мікросервісів та шифрують трафік між сервісами, забезпечуючи політики на кшталт взаємної TLS. Ці мережні сервіси, по суті, встановлюють комплексне наскрізне шифрування, що значно покращує безпеку мікросервісів.
Масштабування мікросервісів
Однією з найбільших переваг архітектури мікросервісів — і саме причиною, через яку вона була розроблена для заміни монолітної архітектури — є її висока масштабованість. Зазвичай масштабування мікросервісів відбувається двома способами: вертикальним і горизонтальним.
Вертикальне масштабування мікросервісів (масштабування вгору) — це додавання більше ресурсів, таких як CPU або пам'ять, до існуючого екземпляра. На відміну від цього, горизонтальне масштабування мікросервісів (масштабування вширину) розподіляє навантаження та збільшує пропускну спроможність.
З точки зору реалізації, вертикальне масштабування мікросервісів є простішим, оскільки потрібно лише модифікувати один екземпляр, оновивши його на більший сервер, збільшивши пам'ять або обчислювальну потужність у хмарному екземплярі або додавши більше сховища.
Цей тип масштабування зазвичай використовується в тих випадках, коли збільшення RAM або CPU потужності може покращити продуктивність запитів та обробку даних, наприклад у сервісах, відповідальних за кешування у пам'яті.
Однак, хоча вертикальне масштабування простіше та дає миттєве покращення продуктивності, воно має недоліки. Вертикальне масштабування обмежене апаратною спроможністю сервера, тому рано чи пізно доведеться перейти на горизонтальне масштабування.
Крім того, вертикальне масштабування коштує дорого, оскільки апаратура та більші екземпляри зазвичай мають високу вартість. І нарешті, якщо масштабований екземпляр виходить з ладу, сервіс повністю припиняє роботу, оскільки немає додаткових екземплярів для обробки навантаження.
При горизонтальному масштабуванні мікросервісів замість оновлення ресурсів одного екземпляра ви розгортаєте нові екземпляри цього сервісу. Хоча ці екземпляри працюють незалежно, вони все ще обробляють один сервіс та частини одного навантаження.
На відміну від вертикального масштабування, горизонтальне масштабування мікросервісів необмежене, тобто ви можете додавати стільки екземплярів, скільки вам потрібно, щоб обробити зростаюче навантаження та всплески трафіку, забезпечуючи більшу масштабованість.
Крім того, оскільки у вас є кілька екземплярів, якщо один виходить з ладу, ви не ризикуєте усім, оскільки інші екземпляри можуть продовжити обробку запитів. І нарешті, горизонтальне масштабування набагато економічніше в довгостроковій перспективі, оскільки ви можете використовувати кілька менших і дешевших екземплярів для створення надійнішої та потужнішої продуктивності.
Однак горизонтальне масштабування та додавання нових екземплярів потребують більше балансувальників навантаження, механізмів виявлення сервісів мікросервісів та інструментів оркестрування мікросервісів, що робить архітектуру мікросервісів набагато складнішою.
Горизонтальне масштабування найбільше підходить для сценаріїв веб-сервісів та застосунків, таких як електронна комерція або соціальні мережі, які часто відчувають мінливий трафік та високий обсяг запитів.
Але це не питання вибору одного або іншого, оскільки обидва типи масштабування підтримуються в мікросервісах і часто необхідні. Зазвичай менші організації використовують вертикальне масштабування, оскільки його простіше впровадити та управляти ним, але з часом і як застосунок зростає, вводиться горизонтальне масштабування для обробки великого попиту.
І нарешті, хмарні платформи пропонують послуги автоматичного масштабування, які автоматично додають або видаляють екземпляри на основі реального попиту, що значною мірою допомагає організаціям збалансувати вертикальне та горизонтальне масштабування.
Моніторинг мікросервісів
На цьому етапі ви фактично завершили розгортання мікросервісів, залишилося лише переконатися, що вона працює послідовно та надійно. Для цього потрібні інструменти моніторингу мікросервісів, такі як Prometheus та Grafana крок внутрь.
Ці інструменти надають реальні аналітичні дані про метрики сервісів, що дозволяє командам стежити за використанням ресурсів, затримкою та частотою помилок. Крім того, ці інструменти також пропонують розподілене трасування (Jaeger, Zipkin та інші), яке допомагає візуалізувати потоки запитів між сервісами та може бути дуже корисним для діагностики проблем.
І нарешті, оскільки збої можуть розповсюджуватися між сервісами через розподілений характер мікросервісів, агрегація логів є критичною практикою моніторингу мікросервісів. Консолідуючи логи на централізовану платформу та встановлюючи сповіщення в реальному часі, ви завжди будете на два кроки попереду проблем і зможете проактивно реагувати на них до того, як вони вплинуть на користувачів.
Завершальні думки
Хоча світ мікросервісів, безсумнівно, складно зрозуміти з першого разу, вивчення основ та ключових етапів розгортання мікросервісів може значно спростити весь процес. Крім того, з плином часу все більше і більше інструментів із суттєво більшим функціоналом стають вам доступними, що робить розгортання мікросервісів простішим, ніж будь-коли.
Часто задавані питання
Які стратегії розгортання зазвичай використовуються для мікросервісів?
Хоча існує багато різних стратегій розгортання мікросервісів, найчастіше використовуються стратегії з використанням екземплярів сервісів у контейнерах, поетапних релізів, синьо-зеленого розгортання та безсерверного розгортання, кожна з яких забезпечує різні рівні ізоляції, гнучкості та масштабованості.
Яку роль відіграє Kubernetes в організації мікросервісів?
Мікросервіси залежать від інструментів оркестрування, таких як Kubernetes, які автоматизують розгортання, масштабування та управління контейнеризованими сервісами. Вони забезпечують балансування навантаження, автоматичне масштабування та самовідновлення, що гарантує стійкість і ефективність мікросервісної архітектури.
Як забезпечити безпеку в середовищі мікросервісів?
Через розподілену природу мікросервіси вносять більше складності в питання безпеки порівняно з монолітною архітектурою. Безпека в мікросервісах передбачає аутентифікацію та авторизацію запитів, шифрування міжсервісної комунікації та використання API-шлюзів API та сервісних сіток, як Istio, для централізованого управління безпекою.
