Що нового у світі мікросервісів. Думка System Architect

Мене звати Олег Касьян, я співпрацюю з ЕРАМ Україна у ролі System Architect. У цій статті поговоримо про мікросервіси.

Мікросервісна архітектура пройшла свій шлях становлення від перших згадок в середині 2000-х до найбільш популярної зараз реалізації сервісно-орієнтованої архітектури. Але навіть тепер деякі джерела відзначають, що єдиного визначення мікросервісів не існує. У цій статті я буду використовувати визначення, що дає автор відомої «Microservices Patterns» Кріс Річардсон.

Отже, за Крісом Річардсоном, мікросервіси, також відомі як «Мікросервісна архітектура», — це архітектурний стиль, що визначає структуру додатка як колекцію сервісів, які:

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

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

Наскільки «мікро» мають бути мікросервіси

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

• Чи може сервіс виконувати декілька функцій, що відносяться до однієї бізнес-вимоги?
• Чи має сервіс одночасно вміти писати та читати дані?

Відповіді на ці питання можуть бути різними в залежності від вимог. Для прикладу візьмемо REST API для роботи з даними користувача (User Service), що має наступні інтерфейси:

POST /signin

Перевірка логіну / паролю в Active Directory

POST /signup

Створення нового запису про юзера в Active Directory

GET /profile

Дані юзера з Active Directory

PUT /profile

Оновлення даних користувача

Традиційний підхід

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

Контекстний вид для User Service

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

З іншого боку, /profile не є транзакційним і його можна зробити слабко зчепленим з AD, використовуючи, наприклад, CQRS або Event Sourcing.

Приклад реалізації User Service з додатковою Read Replica

Nanoservices

Наносервіси (nanoservices) — це не зовсім нова ідея, а скоріше генералізація такого підходу як FaaS (function as a service). Якщо FaaS, виходячи з назви, це про те, як запускати окремі функції, не маючи необхідності налаштовувати інфраструктуру, то наносервіси — це архітектурний стиль, в якому кожна функція є окремим сервісом.

Розглядаючи попередній приклад з User Service, кожен API може бути окремим сервісом:

Наносервіси — кожний сервіс — це окрема функція

Основні переваги такого підходу:

• Scalability — кожну функцію можна масштабувати окремо від інших.
• Простий feature toggle — кожну функцію можна контролювати окремо від інших.
• Незалежна розробка — кожну функцію можна розробляти та розгортати окремо, що також зменшує ефект від помилок.

Недоліки:

• Складність розгортання — кількість таких сервісів значно більша, ніж звичайних мікросервісів, також вони можуть розроблятись різними командами, що ускладнює процес.
• Використання ресурсів — у випадку використання FaaS-платформ це не є проблемою, у разі kubernetes / managed containers або інших PaaS-платформ буде більшим порівняно з традиційним підходом.
• Пошук помилок — може ускладнюватись, оскільки такі сервіси створюють складні ланцюжки залежностей.

API Gateway та мікросервіси

Останнім часом дуже популярною є тема використання API Gateway разом з мікросервісами. Серед іншого також дуже добре прослідковується вплив інших патернів зі світу мікросервісів.

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

Edge API Gateways і використання разом з Service Mesh

Дуже цікавою є ідея використання API Gateway разом з Service Mesh, такими як istio, linkerd, consul. Як приклад, можна подивитись на такі продукти як Gloo Edge або Ambassador Edge Stack. В цьому прикладі найцікавішим є те, що сам API Gateway фактично є лише сервісом, що контролює, і задача якого — оновлювати конфігурацію Service Mesh.

Реалізація Edge Gateway на прикладі GlooEdge, з сайту docs.solo.io

Перевагами такого підходу є:

• Просте налаштування, орієнтоване саме на можливості API Gateway (порівняно з тим самим istio або linkerd).
• Висока продуктивність, безпосередньо сам сервіс надається Service Mesh, який націлений на продуктивність.

Основним недоліком є орієнтованість на одну платформу, ті самі Gloo та Ambassador можна використовувати лише з Kubernetes.

Microgateways

Більшість традиційних API Gateway — це моноліти, та не дуже добре масштабуються через необхідність контролювати та зберігати власний стан. Ідеєю такого підходу як microgateway є створення мікросервісів, що будуть використовуватись як API Gateway. Конфігурація компілюється разом з артефактом і є незмінною, що дозволяє горизонтально масштабувати такий сервіс. Прикладом реалізації є WSO2 Microgateway.

Приклад реалізації Microgateway з сайту wso2.com

Переваги:

— Можливість горизонтального масштабування.

— Стабільність за рахунок відсутності керування станом, та зовнішніх залежностей.

Недоліки:

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

Мікросервіси + фронтенд = Мікрофронтенд?

Такий термін як мікрофротенд взагалі не дуже новий, але останнім часом швидко набирає популярності. Сучасний тренд для фронтенду — це SPA (Single Page Application), написані на React / Angular або схожих фреймворках. Така аплікація, найчастіше написана однією командою, з часом збільшується, стає все складнішою та повільною в розробці й згодом перетворюється у «Фронтенд Моноліт».

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

Приклад реалізації мікрофронтенду з сайту aws.amazon.com

Такий підхід буде мати всі недоліки та переваги мікросервісної архітектури.

Event Mesh

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

Приклад реалізації Event Mesh з сайту eventmesh.apache.org

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

Event Mesh надає такі можливості:

• Service discovery — дозволяє комунікацію з сервісом, не знаючи його деталей, при цьому, на відміну від стандартних Message Queue, можлива peer-to-peer комунікація.
• Load balancing — балансування подій між декількома екземплярами сервісу.
• Шифрування.
• Авторизація та аутентифікація.
• Protocol agnostic — протокол комунікації та фреймворк/мова програмування не має значення.
• Телеметрія.

Завдяки своїм можливостям Event Mesh дозволяє встановлювати комунікацію між різними типами систем без необхідності змінювати код самих систем. Прикладами реалізації Event Mesh є Solace, Apache Event Mesh, SAP Event Mesh.

Підсумовуючи

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

А яка ваша думка? Чи є майбутнє у мікросервісів або на зміну їм має прийти щось нове? Які нові тренди ви спостерігаєте у світі мікросервісів? Пишіть у коментарях.