В останні декілька років в колах IT-спільноти все частіше можна почути про нову панацею - мікросервісна архітектура. Ми постійно читаємо про чергові історії успіху мікросервісів. Попрацювавши з мікросервісним підходом ось вже як 4 роки хочу поділитись з читачем своїми болями і стражданням.
Недолік перший - складність
Отже, мікросервісна архітектура — це підхід до розробки програмного забезпечення, при якому додаток розбивається на менші фрагменти, кожен з яких відповідає за свою конкретну функцію. Цей підхід має деякі переваги, такі як більша гнучкість (в теорії), і краща масштабованість. Однак, на жаль, мікросервісна архітектура має й деякі недоліки. Один з найбільших недоліків мікросервісної архітектури - це складність. Я б сказав, додана складність. Оцінити таку сутність неможливо в абсолютних величинах, лише у відносних.
Архітектура мікросервісних додатків незрівнянно складна в порівнянні з монолітом, з чого випливає також і складність розгортання. Якщо розробник не знає добре архітектуру, то він може легко заплутатися в мережі мікросервісів, що може призвести до непередбачуваних наслідків. Крім того, необхідно підтримувати всі мікросервіси і координувати їх між собою. Це може вимагати великих зусиль та затрат на забезпечення безперебійної роботи системи в цілому. Теорія надійності нам каже, що чим більше в системі вузлів, тим вища вірогідність відмови.
В монолітній архітектурі пошук помилки зазвичай зводиться у перегляд стеку, або файлів логування. А в мікросервісній потрібно спершу знайти в якому модулі виникла помилка! Передивлятись файли логів в кожному з них, або налаштовувати системи моніторингу і збору логів, що ще збільшує затрати на розробку продукту. А збитковий шаблонний код скоріш за все, буде дублюватись від сервісу до сервісу, а його оновлення буде справжнім нічним кошмаром.
Недолік другий - складність тестування
Інший недолік мікросервісної архітектури - це складність тестування. Класичне монолітне тестування дозволяє запускати тест і отримувати результат миттєво. З мікросервісами кожен мікросервіс повинен бути протестований окремо та відносно взаємодії з іншими мікросервісами. Це може стати проблемою, оскільки тестування повинно проводитися на багатьох різних рівнях, і це може вимагати великої кількості часу та ресурсів. Наявність багатьох зв'язаних служб робить тестування неможливим без оркестрування.
Недолік третій - швидкодія та ресурсоємність
Крім того, ще один недолік мікросервісної архітектури полягає у тому, що вона потребує більше мережевих ресурсів та пропускної здатності.
В класичному монолітному додатку зв'язок між модулями використовує швидку пам'ять. Швидкодія пам'яті і мережі відрізняється на три порядки (мінімум в 1000 разів). Оскільки кожен мікросервіс є окремим додатком, він повинен здійснювати зверненання до інших мікросервісів через брокер повідомлень чи іншний мережевий засіб, що може призвести до збільшення навантаження на мережу. Це може стати особливо проблематичним, якщо додаток мікросервісної архітектури запускається в середовищі з обмеженими ресурсами. А мережева затримка в 100-300мс робить такий підхід неприйнятним для деяких задач. Уявість складну транзакцію, яка охоплює декілька сервісів, і дію з розподіленими транзакціями на кожну з яких витрачаються мікросекунди, замість наносекунд. Ще подобаютсья мікросервіси? Тоді йдемо далі!
Недолік четвертий - управління транзакціями
Ще один недолік мікросервісної архітектури - це складність управління транзакціями.
Оскільки мікросервіси є окремими додатками, вони можуть взаємодіяти між собою з використанням різних транзакційних менеджерів. Це може призвести до проблем з управлінням транзакціями, оскільки кожен менеджер може мати власний підхід до обробки транзакцій, що може привести до неконсистентності даних. Також децентралізоване керування даними може бути надзвичайно небезпечним. Може виникати необхідність у використанні розподілених транзакцій, що значно збільшує складність коду і відладки.
Неподік п'ятий - безпека
Ще один недолік мікросервісної архітектури - це складність забезпечення безпеки.
Оскільки мікросервіси взаємодіють між собою через мережу, дуже важливо забезпечити безпеку між мікросервісами.
Це може вимагати надскладних налаштувань інфраструктури та інструментів безпеки, що робить мікросервісну архітектуру дорожчою у розробці та підтримці.
Як зменшити біль від мікросервісів?
Одним зі способів зменшення недоліків мікросервісної архітектури є правильне розподілення функцій між мікросервісами.
Якщо функції, які виконуються декількома мікросервісами, можна об'єднати в один мікросервіс, це зменшить кількість міжсервісних викликів, що зменшить навантаження на мережу. (так-так, монолітизуємо мікросервіси =) )
Крім того, можна використовувати інструменти, щоб забезпечити збалансованість навантаження між мікросервісами.
Наприклад, моніторингові інструменти можуть допомогти виявити мікросервіси, які мають високе навантаження, щоб розподілити навантаження рівномірніше.
Взагалі, засоби моніторингу для мікросервісної архітектури - маст хев.
Щодо управління транзакціями, можна використовувати різні підходи, такі як компенсуючі транзакції, щоб забезпечити консистентність даних між мікросервісами. Також можна використовувати інструменти для моніторингу транзакцій, щоб виявляти проблеми з транзакціями та вирішувати їх.
Нарешті, для забезпечення безпеки між мікросервісами можна використовувати різні методи, такі як мережеві політики, шифрування даних.
Висновок
Мікросервіси - не панацея і не срібна куля. Взагалі кожний інструмент та підхід має вирішувати певну задачу. Фактично єдиним сильним плюсом мікросервісів в проектах де я брав участь була можливість масштабування окремого мікросервісу. Тобто запуск декількох інстансів одного сервісу.
Якщо у вас є на це час, декілька команд розробки, сили і гроші - мікросервіси - ваш вибір.
Якщо проект розробляється одною невеликою командою, немає часу на оформлення належної документації по значно більшій кількості коду, немає часу на укладання контрактів спілкування через брокер повідомлень, різнорівневе тестування, налаштування інфраструктури, розгортання, забезпечення безпеки то ваш вибір - моноліт.
Якщо можеш не використовувати мікросервіси - не використовуй мікросервіси
