Мікросервісна архітектура для початківців. Частина ІІ

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

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

Міжсервісна комунікація

Стратегія

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

Основні стратегії комунікацій

Існують різні мережеві протоколи високого та низького рівня, які можна використовувати як разом, так і окремо. Однак насамперед слід визначити загальну комунікаційну стратегію. Основні комунікаційні стратегії діляться на чотири типи, продемонстровані на схемі вище.

Це:

• Блокуючий та синхронний
• Блокуючий та асинхронний
• Неблокуючий та синхронний
• Неблокуючий та асинхронний

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

API

В рамках вибору комунікаційної стратегії, REST/HTTP та GraphQL – це базові протоколи, які зазвичай використовуються для надання високорівневих API для web. В будь-якому випадку дизайн високорівневих API вимагає чіткого розуміння best practice щодо API Management.

Для новачків важливим є розуміння концепцій API Gateway та версіонування API. Розуміння паттерну API-Led Connectivity – це відправна точка для глибокого занурення в організацію низькорівневих API та підсистем.

Відмовостійкість

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

Тут варто подумати про:

• Timeout – щоб гарантувати час відповіді
• Retry – для автоматизації повторних спроб у випадку деградації мережі
• Circuit Breaker – для контролю у випадку виникнення каскадних помилок
• Deadline – для контролю довгих запитів, що залежать від багатьох сервісів
• Rate Limiter – для контролю навантаження згідно з SLA (Service Layer Agreement)

Консистентність даних

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

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

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

Транзакції

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

Коли ви купуєте чашку кави, у цьому процесі, транзакції з базою даних не беруть участь. Ви платите гроші і чекаєте в черзі, поки не отримаєте повідомлення про те, що ваша кава готова. Якщо щось піде не так, ви просите компенсацію і або отримуєте вашу каву або повертаєте гроші. Іншими словами, це архітектура, керована подіями (Event-Driven Architecture).

Події

Існує дві логічні сутності: події та повідомлення. Вони відрізняються логічно так же, як шина подій (event bus) від черги повідомлень (message queue). Треба розрізняти логічну різницю між цими термінами.

Повідомлення (message) є частиною систем, заснованих на брокерах повідомлень (message broker), де повідомлення відправляється в чергу/топік, враховуючи, що отримувач (consumer) отримає його та щось зробить. Ця модель називається “fire and forget”.

Події дещо відрізняються від повідомлень. Повідомлення може бути чим завгодно (число, текст, JSON тощо). Події, своєю чергою, є логічно закінченою контекстною інформацією і повинні мати чітко визначену структуру (наприклад, JSON). Події також можна зберігати в системі до конкретного часу для повторного використання (event replay) або аудиту.

Шини подій зазвичай відповідають за зберігання/стрімінг/обробку подій, саме цим вони відрізняються від брокерів повідомлень. Наприклад, Kafka проти RabbitMQ.

Паттерни

Існують загально вживані паттерни, які використовуються для імплементації подієво-орієнтованих мікросервісних систем.

Наприклад:

• Event Sourcing – для збереження стану програми в серії подій
• CQRS – щоб скористатися перевагами розділенням моделей читання та запису
• SAGA – для забезпечення глобальної консистентності даних використовуючи послідовність локальних транзакцій
• Event Streaming – для застосування принципів обробки потоків до подій

Інфраструктура

Мікросервісна архітектура може стати дуже складною, тому керування інфраструктурою та застосування DevOps best practices є важливими на всіх етапах розробки.

Розробка масштабованого (scalable) та високодоступного (high-available) мікросервісного рішення може потребувати багато зусиль. В тому числі складно підтримувати систему де є сотні мікросервісів.

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

У будь-якому випадку (багатодоменний або ні), в мікросервісній архітектурі вам доведеться мати справу з такими темами, як:

• Code Repositories — mono-repo проти multi-repo
• Deployment Strategies — включаючи топологію оточення (dev, qa, uat, prod) та deployment стратегії (blue-green, canary, тощо).
• Автоматизація – включаючи оркестрацію кластера, Service Mesh, CI/CD.
• Загальні проблеми (Common Concerns) – контейнеризація, оркестрація, конфігурація, безпека, моніторинг, логування, трейсінг, кешування, комунікації тощо.
• Тестування – e2e, інтеграційне, contract-driven тощо.

Висновок

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

• best practices рефакторінгу монолітів до мікросервісів
• платформ обробки даних (Data Platform, Data Lake)
• різні event-driven архітектури

Тож не соромтесь, задавайте питання, співпрацюйте та підтримуйте зв’язок! Де та як?  До вашої уваги – професійні спільноти GlobalLogic, що діють у Facebook: