Принцип мікросервісів № 5: бізнес-можливості
Ви повинні будувати свій мікросервіс з урахуванням бізнес-можливостей. Кожна служба має відповідати за певну бізнес-можливість, а всі служби разом мають покривати всі необхідні бізнес-можливості вашого застосунку.
Цей принцип важливий з кількох причин:
- Він допомагає зберігати ваші служби невеликими й керованими. Якщо кожна служба відповідає лише за одну бізнес-можливість, її буде легше зрозуміти й за потреби змінити.
- Він допомагає забезпечити масштабованість застосунку розробника. Якщо кожну службу можна масштабувати незалежно, розробники можуть масштабувати ті частини свого застосунку, яким потрібно більше ресурсів, не зачіпаючи інші частини.
- Цей принцип може допомогти розробникам створювати стійкіші до відмов застосунки. Якщо одна служба виходить з ладу, інші продовжують працювати й надавати необхідні бізнес-можливості. Це може допомогти мінімізувати вплив збоїв і простоїв на ваших користувачів.
Принцип мікросервісів № 6: децентралізація
На відміну від монолітних застосунків, у застосунках на основі мікрослужб кожна служба підтримує власну копію даних. В ідеалі кожен мікросервіс має мати власну базу даних. Кілька служб, які звертаються до тієї самої бази даних або спільно її використовують, нівелюють саму мету мікросервісної архітектури.
Це дало б програмістам змогу централізовано контролювати доступ, безперешкодно запроваджуючи журнал аудиту й кешування. Це також дало б розробникам змогу централізувати контроль доступу та легко впроваджувати ведення журналу аудиту й кешування. В ідеалі для кожної служби має бути одна або дві таблиці бази даних.
Принцип мікросервісів № 7: автоматизація процесів
Автоматизація процесів — важливий принцип архітектури мікросервісів. Автоматизуючи процеси, програмісти можуть підвищити надійність, знизити витрати й прискорити цикли розробки програмного забезпечення. На відміну від монолітного застосунку, у застосунку на основі мікросервісів потрібно керувати кількома одиницями розгортання.
Отже, ви маєте мати змогу автоматизувати процес розгортання застосунку на основі мікрослужб. Це можна зробити, запровадивши у своїй організації культуру DevOps і використовуючи відповідні інструменти, як-от Azure DevOps або Jenkins.
Принцип мікросервісів № 8: взаємодія між службами
Коли ви розбиваєте наявний монолітний застосунок на мікрослужби, потрібно також визначити, як ці служби взаємодіятимуть. Оскільки архітектура мікросервісів дає змогу використовувати різнорідні технології, як ці служби можуть взаємодіяти між собою? Саме тут можуть допомогти інтерфейси прикладного програмування (API).
Існує кілька способів реалізувати взаємодію між службами в архітектурі мікрослужб. Один із варіантів — використати підхід на основі подій, за якого одна служба публікує подію, на яку інша служба може підписатися й відповідно відреагувати.
Інший варіант — використовувати протокол обміну повідомленнями, наприклад HTTP або AMQP, щоб можна було обмінюватися повідомленнями між службами без потреби знати будь-які подробиці їхньої реалізації. Програмісти повинні інкапсулювати технічні подробиці внутрішньої роботи своєї служби й надавати функції API, щоб інші служби (внутрішні, зовнішні або обидва типи) могли отримувати доступ до неї через ці методи API. Так вони гарантують, що їхня служба зможе розвиватися самостійно з часом, не ставлячи під загрозу інкапсуляцію.
Принцип мікросервісів № 9: моніторинг
Через розподілений характер застосунків на основі мікросервісів виявлення помилок за допомогою ручного процесу є складним завданням. Саме тому вам потрібна автоматизована система моніторингу. Моніторинг в архітектурі мікросервісів — справа складна, і не лише тому, що в ній більше рухомих частин. Проблема моніторингу мікросервісів полягає в тому, що їх спроєктовано незалежними одне від одного, а це означає, що їх часто створюють із використанням різних технологій і середовищ. Через це складно визначити, як контролювати систему загалом.
Моніторинг у мікросервісній архітектурі дещо відрізняється від моніторингу в монолітній архітектурі. Оскільки кожна мікрослужба — це окрема сутність, у будь-який момент часу може працювати кілька екземплярів кожної служби.
Це означає, що потрібно відстежувати більше метрик і досліджувати більше журналів. Система моніторингу має вміти збирати й аналізувати дані, а також генерувати корисні показники.
Принцип мікросервісів № 10: розділення відповідальності за команди й запити (CQRS)
Трафік до служб у застосунку на основі мікрослужб може відрізнятися. У вас може бути служба з величезним трафіком, а в іншої трафік може бути низьким. У цьому сенсі розробникам варто скористатися перевагами автоматичного масштабування й автоматичних вимикачів. Розділення відповідальності за команди й запити (CQRS) — це шаблон проєктування, який розділяє операції читання й запису на окремі класи. Це дає змогу незалежно масштабувати операції читання й запису, що може бути особливо корисним для архітектур мікросервісів. Шаблон CQRS зазвичай використовують в архітектурі мікросервісів.
Це пов’язано з тим, що він дає змогу різним компонентам відповідати за різні частини функціональності застосунку, спрощуючи його масштабування й підтримку. Оскільки в шаблоні проєктування CQRS доступ до даних обмежено однією базою даних, це може стати в пригоді для складних запитів, що охоплюють кілька баз даних служб. У цій архітектурі буде два розділи: команди й запити.
Командний компонент відповідатиме за створення, редагування й видалення операторів, а компонент запитів — за їх читання. Цей підхід має кілька переваг. По-перше, він дає змогу масштабувати читання незалежно від запису.
Наприклад, якщо у вашому застосунку багато операцій запису, але мало операцій читання, ви можете створити кілька екземплярів рівня запису, а потім мати один екземпляр рівня читання. Ще одна перевага полягає в тому, що цілісністю даних легше керувати, коли кожен клас має власну відповідальність.
Третя перевага полягає в тому, що ваш код легше тестувати, оскільки кожен клас матиме лише одну відповідальність, а не безліч обов’язків, як це зазвичай буває у зв’язках «багато до багатьох» у реляційних базах даних.
Підсумуймо
Розробники можуть долати проблеми, що виникають під час створення архітектури мікросервісів, дотримуючись правильних принципів проєктування, щоб створювати сучасні й легко масштабовані застосунки.
