Впровадження мікросервісів у виробничих середовищах

Informatec Digital » Ресурси » Впровадження мікросервісів у виробничих середовищах

Впровадження архітектури мікросервісів у реальному середовищі — це не просто розбиття моноліту на менші частини; це передбачає переосмислення інфраструктури, команд, процесів, даних, безпеки та операцій . Коли система переходить від теорії до робочого кластера, виникають проблеми щодо виявлення сервісів, контрактів між командами, неперервної інтеграції/комп'ютерної інтеграції (CI/CD), спостережуваності, стійкості та масштабованості. Якщо ці проблеми не вирішити належним чином, вони можуть перетворити мікросервіси на розподілений хаос.

Гарна новина полягає в тому, що сьогодні ми маємо багатий накопичений досвід таких організацій, як Netflix, Amazon, Google та інших великих корпорацій, які використовують сотні мікросервісів у продакшені . Спираючись на ці уроки, а також на передовий досвід у корпоративних середовищах з використанням Kubernetes та OpenShift, ми можемо розробити дуже надійний підхід до проектування, розгортання та експлуатації мікросервісів у великих масштабах без втрати контролю.

Навіщо розгортати мікросервіси у продакшені (і коли це того не варто)

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

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

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

З технологічної точки зору, мікросервіси сприяють свободі вибору мов, фреймворків та баз даних для кожного сервісу. Не всі потреби вписуються в один технологічний стек: у вас можуть бути бізнес-сервіси на .NET або Java, обробка даних на Scala/Spark, спеціалізовані сервіси на Python або F# або мікросервіси штучного інтелекту на R. Така контрольована різноманітність дозволяє використовувати правильний інструмент для кожного випадку, не змушуючи весь додаток до глобального технологічного зсуву.

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

Архітектурний та сервісний дизайн

Щоб мікросервіси добре працювали у продакшені, важливо почати з ретельного проектування меж сервісів та обов'язків . На практиці це зазвичай починається з визначення грубозернистих сервісів у межах існуючого моноліту: великих функціональних областей або бізнес-доменів (наприклад, замовлення, каталог, користувачі, виставлення рахунків), які вже мають певне логічне розділення.

Починаючи з цих великих структурних блоків, процес включає вдосконалення дизайну для отримання дрібнозернистих мікросервісів, які працюють на когерентному наборі даних , мають власну модель і точно знають, що їм потрібно зчитувати або записувати в інші сервіси. Цей процес зазвичай спирається на концепції проектування, орієнтованого на предметну область (DDD), та обмежені контексти, що запобігає перетворенню мікросервісу на «міні-моноліт».

API, що надають доступ до цих сервісів, повинні мати чітко визначені та стабільні контракти . Це передбачає ретельну документацію (REST з OpenAPI, gRPC з файлами .proto тощо), явне керування версіями, підтримку зворотної сумісності, де це можливо, та автоматизацію перевірки контрактів для виявлення критичних змін, перш ніж вони потраплять у робочу среду.

У середовищах з десятками або сотнями сервісів критично важливо враховувати шаблони стійкості на етапі проектування, щоб система була готова до часткових збоїв . Такі шаблони, як автоматичні вимикачі, повторні спроби з відстрочкою, чітко визначені тайм-аути, перегородки та зворотний тиск, допомагають запобігти тому, щоб збій одного сервісу спричинив виведення з ладу інших. Інструменти Chaos-інженерії, такі як ChaosMonkey або Gremlin, корисні для практичного тестування поведінки платформи під час змодельованих збоїв.

У багатьох складних системах відносно прості CRUD-сервіси співіснують із складнішими, які обробляють бізнес-правила, що постійно змінюються. Не всі мікросервіси вимагають складної внутрішньої архітектури : деякі можуть бути простими HTTP-контролерами з базовим доступом до даних, тоді як інші, такі як сервіси замовлень або виставлення рахунків, можуть використовувати більш просунуті шаблони (DDD, CQRS, події домену тощо).

Виробнича інфраструктура: хмара, контейнери та Kubernetes/OpenShift

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

Зазвичай кожен мікросервіс упакований в образ контейнера, що базується на базовому образі компанії (наприклад, OpenJDK 21 для сервісів Java), яким керує команда інфраструктури. Цей базовий образ постійно оновлюється за допомогою патчів безпеки, і коли виходить нова версія, команди розробників відповідають за перебудову та повторне розгортання своїх сервісів у відповідних середовищах.

У Kubernetes/OpenShift базовою одиницею розгортання є pod, який інкапсулює один або декілька контейнерів . Зазвичай мікросервіс відповідає типу pod та розгортається за допомогою таких ресурсів, як Deployments (для сервісів без збереження стану) або StatefulSets (коли є пов'язаний стан). З самого початку визначається мінімальна кількість реплік на середовище, щоб тестові, передпродакційні та продакшн середовища мали рівні доступності, що відповідають їхній критичності.

Автоматичне масштабування реалізовано за допомогою HorizontalPodAutoscaler (HPA) , який регулює кількість реплік на основі таких показників, як процесор, пам'ять або інші користувацькі показники. Платформа також повинна налаштувати правила антиафінності подів, щоб розподіляти репліки одного й того ж сервісу між різними вузлами, запобігаючи виходу з ладу всіх екземплярів через збій одного вузла.

Щодо вертикального розміру, resources.requests та resources.limits використовуються для визначення діапазону процесора та пам'яті, які може споживати pod. Наприклад, резервування мінімум 100 МБ процесора та 256 МБ пам'яті, а також дозвіл до 500 МБ та 2 ГБ відповідно для сервісу Java, налаштування JVM (Xms, Xmx, Xss) для ефективного використання ресурсів контейнера.

Керування станом: мікросервіси з відображенням та без відображення стану

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

Однак, існують сценарії, коли немає іншої альтернативи, окрім як мати мікросервіси зі збереженням стану, що підтримуються постійними томами . Це стосується деяких баз даних, розподілених файлових систем або компонентів, які потребують підтримки локальних даних. Ці pod-системи зазвичай розгортаються за допомогою StatefulSets, пов'язані з PersistentVolumes за допомогою PersistentVolumeClaims та масштабуються вертикально, а не горизонтально.

Коли мікросервісу потрібне постійне сховище, запитується PersistentVolumeClaim (PVC) з його розміром, режимом доступу та цільовим призначенням , а операційна команда надає його відповідно до політик платформи. Цей PVC згадується в маніфесті розгортання та монтується в поді, щоб сервіс міг постійно читати та записувати дані.

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

Децентралізація даних та суверенітет послуг

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

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

Це не означає, що немає інтеграції даних; це означає, що узгодженість між сервісами керується за допомогою подій та асинхронного обміну повідомленнями , приймаючи остаточну узгодженість, коли це доцільно. Зазвичай для поширення змін стану між мікросервісами використовуються шини подій (RabbitMQ, Azure Service Bus, Kafka тощо), що зменшує сильну залежність від однієї бази даних.

Хмарна платформа дозволяє командам легко вибирати оптимальний тип бази даних для кожного сервісу (реляційний, документний, ключ-значення, часовий ряд тощо), не нав'язуючи єдину технологію. Ключовим є те, що проектування враховує можливість міграції схем і структур без порушення контрактів з іншими сервісами, а рішення щодо даних приймаються відповідно до меж домену кожного мікросервісу.

Розподілене управління, команди та організація

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

Кожна команда відповідає за один або декілька мікросервісів в межах однієї функціональної області, займаючись як розробкою, так і експлуатацією (ви створюєте, ви запускаєте) . Це означає, що команда керує своїми пайплайнами CI/CD, співпрацює з інфраструктурою для вирішення конкретних потреб, а також бере участь у моніторингу та реагуванні на інциденти. Інфраструктура та хмарна платформа зосереджені на наданні спільних та стандартизованих послуг.

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

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

CI/CD, автоматизація та модель GitOps

Коли архітектура складається з десятків або сотень мікросервісів, єдиний спосіб підтримувати їх працездатність — це значні інвестиції в комплексну автоматизацію . Це включає узгоджені конвеєри CI/CD, декларативні визначення розгортання, автоматизоване тестування та механізми автоматичного відкату.

Типовий конвеєр безперервної інтеграції та доставки обробляє компіляцію коду, проведення тестів, аналіз якості за допомогою таких інструментів, як SonarQube , створення образу контейнера з корпоративного Dockerfile та оновлення маніфестів розгортання. Звідти система, така як ArgoCD або подібна, застосовує зміни до кластера, використовуючи підхід GitOps.

Кожен репозиторій мікросервісів зазвичай містить стандартизований Dockerfile, файл конфігурації конвеєра (наприклад, ci.json) , властивості для аналізу якості та каталог розгортання з визначеннями Kubernetes (Kustomize або Helm), розділеними за середовищем. Вебхуки репозиторію запускають конвеєр, коли відбуваються такі події, як надсилання тегів або запити на злиття.

Шаблон GitOps визначає репозиторій Git як джерело достовірної інформації для інфраструктури та розгортання . Маніфести для розгортань, служб, ConfigMaps, PVC, SealedSecrets та інших ресурсів реєструються там, а спеціальні інструменти синхронізують стан кластера з тим, що визначено в Git. Це забезпечує відстеження, перегляд запитів на внесення змін та прості можливості відкату.

Налаштування, секрети та безпека

У зрілій платформі мікросервісів керування конфігурацією спирається на ConfigMaps для неконфіденційних параметрів та Secrets для конфіденційної інформації . Кожен мікросервіс зазвичай має власний ConfigMap, специфічний для середовища, який зберігає такі властивості, як URL-адреси залежних сервісів, прапорці функціональності та параметри налаштування.

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

Коли секретний код потрібно використовувати для спільного використання кількома сервісами (наприклад, облікові дані OTEL Collector або спільне сховище ключів ), його можна централізувати в репозиторії конфігурації для кожного простору імен. Проекти, що спільно використовують цей простір імен, координують його оновлення за потреби, контролюючи, хто може читати або змінювати ці ресурси.

Щодо безпеки зв'язку, домінуючою моделлю є Zero Trust : нічого не сприймається як належне лише тому, що трафік є «внутрішнім». Усі виклики між сервісами, як внутрішніми, так і зовнішніми, мають бути автентифіковані та авторизовані, в ідеалі за допомогою токенів mTLS, JWT або інших еквівалентних механізмів. Мікросервіси не делегують сліпо безпеку API Manager або мережі; вони також виконують власні перевірки.

Зв'язок між мікросервісами, API та обміном повідомленнями

У зрілій архітектурі мікросервісів комунікаційний рівень поділяється на кілька випадків. Для трафіку від клієнтів (браузерів, мобільних додатків, третіх сторін) до серверної частини використовуються опубліковані API, що керуються API Manager . Ці API зазвичай є RESTful (часто використовують OpenAPI) або, в деяких випадках, gRPC, що надаються через шлюз.

Виклики між мікросервісами, що знаходяться в одному просторі імен або навіть між кількома просторами імен в одному проєкті, зазвичай обробляються внутрішніми сервісами Kubernetes із внутрішнім DNS . Ці виклики обходять публічний API Manager, але дотримуються політик безпеки, автентифікації та авторизації. Для цих сценаріїв можна використовувати сервісну сітку або внутрішні шлюзи, що забезпечують дотримання спільних політик.

Коли мікросервіси належать до різних функціональних доменів або проектів , зв'язок вважається "публічним" на організаційному рівні. У таких випадках поширеною практикою є використання API Manager або шини сумісності, де керуються контракти, квоти, безпека, версії та аудит, що запобігає прямому зв'язку між незалежними кластерами або просторами імен.

Щодо інтеграції зі застарілими або зовнішніми системами, які не завжди можуть надавати доступ до сучасних API, зазвичай покладаються на певні конектори через шину сумісності . Таким чином, мікросервіси розмовляють спільною мовою (наприклад, події або внутрішні REST API), а конектор обробляє трансляцію до та з застарілої системи, завжди з підвищеною безпекою.

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

Спостережуваність, колектор OTEL та його експлуатація

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

Центральним компонентом цієї схеми є OpenTelemetry Collector (OTEL Collector) , який розгортається в просторі імен або централізовано для збору метрик, журналів та трас з усіх компонентів. Мікросервісам потрібно знати лише, що вони повинні надсилати свою телеметрію до Collector; Collector потім пересилає її до систем спостереження (Prometheus, Grafana, Jaeger, Elastic тощо) без необхідності знання деталей сервісом.

Для інфраструктурного рівня використовуються колектори та експортери на рівні вузлів для збору показників процесора, пам'яті, диска, мережі та журналів з подів, надсилаючи їх до Prometheus та Elasticsearch відповідно. Такі інструменти, як Grafana та Kibana, використовуються для візуалізації цієї інформації, створення інформаційних панелей та визначення сповіщень з інтелектуальними порогами та пов'язаними з ними наборами завдань.

Коли проєкт потребує дуже специфічної обробки своїх метрик або трас, він може розгорнути власний екземпляр OTEL Collector у своєму просторі імен, за умови наявності операційного схвалення та чіткої моделі обслуговування виробничого процесу.

Стратегія тестування, контракти та досвід локальної розробки

Тестування розподіленої архітектури мікросервісів вимагає складнішої стратегії тестування , ніж тестування моноліту. Модульні тести залишаються важливими, але контрактні тести (для API та подій), інтеграційні тести між сервісами та наскрізні тести, що охоплюють повні потоки, стають дедалі важливішими.

Для запобігання проблемам сумісності використовуються такі методи, як тестування контрактів, орієнтованих на споживача , де клієнти визначають очікування API, а постачальники послуг їх виконують. Кожна зміна контракту проходить автоматизоване тестування в рамках конвеєрів неперервної інтеграції (CI), запобігаючи розгортанням, які порушують роботу будь-яких відомих споживачів.

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

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

Шаблони розгортання мікросервісів у продакшені

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

У шаблоні екземплярів служби для кожної віртуальної машини кожна служба упакована як образ віртуальної машини (наприклад, EC2 AMI) та працює на власному екземплярі. Це забезпечує надійну ізоляцію, але за рахунок більшого споживання ресурсів та повільнішого часу запуску. Такі інструменти, як Packer або рішення, специфічні для постачальників хмарних послуг, дозволяють легко створювати образи віртуальних машин, готові до роботи.

Найпоширенішим шаблоном сьогодні є екземпляр сервісу на контейнер , де кожен мікросервіс будується як образ контейнера та розгортається на оркестраторі (Kubernetes, OpenShift тощо). Контейнери легші за віртуальні машини, запускаються дуже швидко та дозволяють упакувати все необхідне для сервісу, спрощуючи розгортання та забезпечуючи автоматичне масштабування.

Зрештою, популярність набули безсерверні підходи, такі як AWS Lambda . Ці пакети містять функції, що реагують на HTTP-запити або події з інших сервісів (S3, DynamoDB, черги тощо), при цьому користувачі платять лише за те, що вони використовують. Цей шаблон особливо добре підходить для дуже малих мікросервісів або короткочасних завдань, керованих подіями, хоча він вводить додаткові міркування щодо спостережуваності, холодного запуску та обмежень виконання.

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

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