У цьому посібнику з програмування обговорюються деякі принципи проєктування мікрослужб, які слугуватимуть орієнтиром для створення масштабованих, високопродуктивних, відмовостійких застосунків на основі мікрослужб. Ось список ключових принципів (це лише кілька рекомендацій), яких мають дотримуватися програмісти, щоб створювати застосунки на основі мікросервісів, які є адаптивними, масштабованими та високопродуктивними.
Принцип мікросервісів № 1: висока зв’язність і низьке зчеплення
Застосунки на основі мікросервісів мають мати високу зв’язність і низьке зчеплення. Ідея, що лежить в основі цієї концепції, полягає в тому, що кожен сервіс має робити одну річ і робити її добре, а це означає, що сервіси мають бути надзвичайно зв’язними. Ці сервіси також не мають залежати один від одного, а отже, мати низьке зчеплення.
Зв’язність модуля стосується того, наскільки тісно пов’язані його функції. Високий рівень зв’язності означає, що функції всередині модуля нерозривно пов’язані й можуть сприйматися як єдине ціле. Низька зв’язність означає, що функції всередині модуля не пов’язані тісно між собою і не можуть розглядатися як єдиний набір. Що вища зв’язність, то краще — можна сказати, що модулі працюють разом.
Зчеплення вимірює, скільки знань один модуль має про інший (тобто наскільки тісно пов’язані різні частини програми). Високий рівень зчеплення вказує на те, що багато модулів знають один про одного; між модулями не так багато інкапсуляції. Низький рівень зчеплення вказує на те, що багато модулів ізольовані один від одного. Коли компоненти в застосунку слабко зчеплені, ви також можете легко протестувати застосунок.
Принцип мікросервісів № 2: дискретні межі
Мікросервіси — це невеликі й незалежно розгортані одиниці функціональності, що спрощує керування та масштабування. У дискретній мікросервісній архітектурі кожен із мікросервісів відповідає за певне завдання. Як приклад припустімо, що ви створили вебзастосунок, який дає користувачам змогу купувати взуття в Інтернеті.
У цьому випадку у вас може бути одна мікрослужба, що відповідає за обробку входу користувача, а інша — за процес купівлі та виставлення рахунків. Розробляючи мікросервісну архітектуру, слід уникати міжфункціональних залежностей між сервісами.
Наприклад, якщо у вас є два сервіси: один для автентифікації та авторизації, а інший для керування профілями користувачів, — не будуйте систему так, щоб для коректної роботи сервісу керування профілями потрібно було викликати сервіс автентифікації та авторизації.
Один зі способів уникнути цієї залежності — реалізувати шлюз, який перетворює запити від одного сервісу на запити, зрозумілі іншому сервісу. Наприклад: замість того щоб сервіс керування профілями викликав сервіс автентифікації та авторизації, нехай він спершу викликає шлюз API. Потім шлюз має перетворити ці запити на виклики, які мають сенс для його колеги на іншому боці, тобто сервісу автентифікації та авторизації.
Принцип мікросервісів № 3: принцип єдиної відповідальності
Принцип єдиної відповідальності стверджує, що в будь-який момент має бути лише одна причина для зміни класу. Переваги цього принципу очевидні — він зменшує складність і підвищує гнучкість, розширюваність та зручність обслуговування. Він також спрощує заміну класів, не порушуючи їхньої роботи. Мікрослужбу, яка дотримується принципу єдиної відповідальності, легше підтримувати й оновлювати, ніж мікрослужбу з кількома обов’язками. Вона також із меншою ймовірністю спричинить конфлікти з іншими мікросервісами.
Розробляючи застосунок на основі мікросервісів, програмісти мають дотримуватися цього принципу — у мікросервісу не має бути кількох обов’язків.
Принцип мікросервісів № 4: проєктування з урахуванням збоїв
Шаблон автоматичного вимикача — це шаблон проєктування програмного забезпечення, який захищає від каскадних збоїв у розподілених системах. Він дає змогу контролювати відмову сервісу, коли той починає часто давати збої, не зачіпаючи всю систему. Завдяки цьому інші сервіси можуть і далі нормально працювати, навіть якщо один із них не працює. Іншими словами, відмова одного сервісу (або його збій) не вплине на інші сервіси.
Помилка в мікросервісі (через витік пам’яті, проблеми з підключенням до бази даних тощо) не має призводити до відмови всього застосунку. Розгляньмо це на іншому прикладі з реального життя. Розробник може мати службу бази даних і службу застосунку. Якщо служба бази даних виходить з ладу, служба застосунків може продовжувати роботу. Це підвищує доступність вашого застосунку і зменшує обсяг роботи, потрібної для виправлення зламаних залежностей.
Застосунки на основі мікрослужб є автономними й незалежними, тому ви можете реалізувати шаблон автоматичного вимикача, щоб відключити зв’язок з однією або кількома службами, які або вимкнені, або працюють неналежним чином.
