Tech Industry

Типові помилки при переїзді на мікросервіси

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

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

1. Нав’язлива ідея Один-Сервіс-для-Однієї-Функції

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

Загалом, виділення окремої функціональності на окремий мікросервіс – гарна ідея. Проте дуже легко можна перетворити ефективну мікросервісну архітектуру на безладдя, з яким буде неможливо впоратися.

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

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

2. Надмірне подрібнення мікросервісів

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

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

3. Прив’язка до одного рішення для розгортання

На сьогодні, розгортання мікросервісів через контейнери з використанням OpenShift чи іншої платформи для kubernetes є загальною практикою.

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

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

4. Вимога оновлювати усі мікросервіси одночасно

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

Якщо ви завжди працювали з “монолітом”, то це звичайна думка у вашій голові. Але з мікросервісами це підхід означатиме, що ви стрілятимете собі в ногу. Однією з цілей мікросервісів є те, що оновлення, масштабування чи перезапуск частини вашого додатку не впливатиме на весь додаток та інші його частини.

Проте, якщо зміна в одному мікросервісі означає, що інші мусять бути також змінені, то ви втрачатимете багато гнучкості, які можуть запропонувати мікросервіси. Водночас вам буде важче налагодити continuous delivery, тому що ви не зможете оновити один сервіс без впливу на інші.

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

5. Нехтування логуванням

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

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

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

Висновки

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