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

Автор: Орхан Гасімов, Technology Director, GlobalLogic

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

Що таке мікросервіс?

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

Типова довідкова архітектура мікросервісного веб-додатку

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

Front-End — Client Application, Static Content
Back-End — API Gateway, Experience Microservices, Domain Microservices
Data & Integration — Data Stores, Integration Interfaces / Connectors

Розглянемо кожен ярус і опишемо, за що він відповідає.

Логічні яруси

• Клієнтська програма

У випадку веб-програми, клієнтом, як правило, є веб-браузер. Дехто вважає, що клієнт - це UI, але це не так. Браузер - це клієнт, який завантажує статичний контент із віддаленого сервера і рендерить UI всередині себе. І він же є клієнтом, що обробляє фізичні HTTP запити ща надходять до сервера. Важливо розрізняти клієнт та контент. Особливо, якщо ви розробляєте micro-app frontend.

Клієнт (веб-браузер) взаємодіє з Backend, щоб рендерити UI та викликати API.

• Статичний контент

Найкраща практика - розділити відповідальність шляхом роз’єднання логічних компонентів, щоб жоден компонент не відповідав за все. З цієї причини рекомендується подавати статичний контент через окремий серверний компонент. Це дозволяє відокремлювати статичний контент від API. Кілька важливих принципів, на які потрібно звернути увагу, - це server-side rendering, кешування та контроль доступів.

• API Gateway

API Gateway - це центральні двері для всіх публічних API. Це єдина точка входу для так званих Experience APIs, доступних для клієнтських програм, і є важливою складовою найкращих практик управління API (API Management). По суті, він передає запити реальним бекенд сервісам та здатен приймати рішення. Частіше за все, API Gateway відповідає за такий функціонал, як:

• Request handling
• Upstream (або downstream) data transfer (або transformation)
• Access control
• Security policies
• Throttling
• Rate limiting
• Analytics
• Caching

• Experience мікросервіси

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

Experience сервіси покладаються на доменні сервіси, що знаходяться на нижчому ярусі.

Уявіть набір мікросервісів, які надають API вищого рівня, орієнтовані на клієнтський досвід, повторно використовуючи низкорівневі гранулярні API, доступні в системі. Наприклад, різні продукти, що постачаються для веб- і мобільних клієнтів (Experience), можуть використовувати різний набір experience API, представлених незалежними мікросервісами за API шлюзом (API gateway).

Ці мікросервіси утворюють experience ярус, який логічно відокремлений від інших ярусів. Він може бути керований та налаштований (масштабований, налаштований, захищений тощо) незалежно. Зверніться до архітектурних паттернів API-Led Connectivity та Backend For Frontend, щоб глибоко заглибитися у зв’язані концепції.

• Доменні мікросервіси

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

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

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

• Бази даних

Best practice полягає в тому, що база даних повинна належати лише одному мікросервісу. Жодні інші сервіси не повинні мати можливості безпосереднього доступу до бази даних, лише через API сервіса-власника. Це дозволяє кожному сервісу керувати консистентністю та структурою бази даних, якою він володіє. Також це дозволяє обирати найбільш відповідну базу даних для конкретних цілей без будь-якої залежності від вимог системи в цілому. Наприклад, один сервіс може використовувати нормалізовану базу даних SQL, тоді як інший може отримати вигоду з бази даних NoSQL. Однак один мікросервіс може керувати кількома базами даних.

Сервіс може мати безпосередній доступ до бази даних, лише якщо він є власником. В іншому випадку він повинен використовувати API мікросервіса-власника і ніколи не мати безпосередній доступ до бази даних інших сервісів.

Спільне використання бази даних може потенційно призвести до анти-паттерна Distributed Monolith. Якщо вам потрібно надати загальний доступ до даних, зверніться до таких концепцій централізованих сховищ, як :

• DWH (Data Warehouse), 
• DFS (Distributed File System) 
• Data Lake. 

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

• Інтеграційні інтерфейси та конектори

Окрім внутрішніх джерел даних, програмі може знадобитися доступ до інших підсистем та сторонніх API. Корисна практика - розділяти інтеграційний ярус, запровадивши окремі сервіси-конектори.

Підіб’ємо підсумки. Мікросервісна архітектура по суті є патерном який вчить застосовувати різні (чи інші) архітектурні патерни, стилі та підходи в рамках єдиного додатка, розподіленого в мережі. У цій статті ми розглянули лише верхівку айсберга, так звану high-level архітектуру. В наступній частині, ми проаналізуємо набір більш низькорівневих підходів та патернів, які заслуговують на увагу при подальшому зануренні в тему.

Читайте другу частину статті за посиланням.