-
Мікро, міні та макросервіси. Що за чим стоїть та що обрати для проєкту
-
Мікро, міні та макросервіси. Що за чим стоїть та що обрати для проєкту
Я ж і не кажу, що мікросервіси це панацея, для кожного з підходів є свої use case’и та свої недоліки і переваги, що відображені в порівняльній таблиці. Головна ідея моєї статті — донести, що крім моноліту і мікросервісів є ще варіанти.
-
Мікро, міні та макросервіси. Що за чим стоїть та що обрати для проєкту
Це є ознайомча публікація, детальне заглиблення в тему вважаю недорічним, але поміркую щодо більш детальної статті.
Підтримав: Вознюк Андрій -
Мікро, міні та макросервіси. Що за чим стоїть та що обрати для проєкту
Дякую за коментар,
Здебільшого масштабується вертикально (шляхом збільшення кількості RAM та CPU), адже використання горизонтального масштабування не є доцільним.
Цікаво, а чому? Горизонтальне масштабування по-перше, забезпечує High availability, по-друге, знижує навантаження на кожен сервер.
Горизонтальне масштабування для монолітів не є оптимальним з точки зору використанням пам’яті, адже на 99.9% потрібно вам не потрібно скейлити весь функціонал моноліту, а лише окрему його частину
Надійність. Помилка в будь-якому з модулів програми може призвести до зупинки всього додатка.
Наприклад, яка помилка? Я часто зустрічав помилки, які робили компонент неробочим. Але щось не пам’ятаю помилки, які призводили саме до зупинки додатка.Як приклад — Memory leak
Переваги:
Можливість експериментувати з різними технологіями: між модулями є менші технологічні залежності. Відкат до попередніх ітерацій менш складний.Тут трохи спірне питання. Уявімо ситуацію, що вам потрібно створити три команди розробників (у кожної свій мікросервіс).
І ви замість трьох Java команд набираєте команду на Java, Пітоні та Node.js. Теоретично це працюватиме, але наскільки ефективно вони разом працюватимуть, вирішувати спільні проблеми, створювати best practices?Як і мікросервіси, команди повинні будти loosely coupled, і тому спільних проблем у них не має бути. Лише у випадку небхідності інтеграції мікросервісів команди мають комунікувати щодо формату взаємодії(message format, API contract).
Щодо команд, рекомендую ознайомитись зі статтею.Мале зв’язування (Low coupling): компоненти мікросервісів слабо пов’язані, тому вони не є взаємозалежними та можуть бути перевірені окремо. Це також робить додаток більш адаптованим до змін з часом.
Якщо команда розробників досить досвідчена, вона може і моноліт розбити на слабо-пов’язані модулі, які легко окремо розробляти і тестувати. Тісно-пов’язані компоненти — це не особливість монолітної архітектури, а недолік проектування конкретного проекту.
Частково згоден, але не варто забувати про деплоймент, і тому монолітний додаток буде більш зв’язаний, ніж мікросервісний.
Покращена ізоляція несправностей (fault isolation): великі додатки продовжують функціонувати у випадку збою одного модуля.
Якщо чесно, то не завжди. Тут часто відбувається «ефект доміно». Коли один сервіс перестає працювати, а ті сервіси, що залежать від нього (використовують його REST API, наприклад), також перестають працювати. І це може торкнутися весь проект, якщо не передбачити спеціальних заходів (типу circuit breaker)
Імплементація мікросервісного підходу має на увазі і обробку negative case’ів, тому проблеми типу «ефект доміно» мають бути оброблені ще на етапі проєктування архітектури.
-
Мікро, міні та макросервіси. Що за чим стоїть та що обрати для проєкту
Дякую за коментар, але не можу з цим погодитися, адже одного часу може з’явитися потреба використовувати функціонал частіше і потрібно буде робити додаткову роботу.
-
Мікро, міні та макросервіси. Що за чим стоїть та що обрати для проєкту
Reuse говорить про те, чи можемо ми перевикористати цілий сервіс, тому у випадку моноліта оцінка є низькою.
Щодо оцінок, то 1/5 — мінімальна оцінка, 5/5 — максимальна оцінка. Тому 5/5 у development time каже, що розробка і деплоймент займе менше часу ніж у іншіх.
-
Мікро, міні та макросервіси. Що за чим стоїть та що обрати для проєкту
Дякую за коментар, врахую ваші зауваження)
Взагалі, моноліт легше деплоїти у порівнянні з мікросервісами, але проблеми можуть бути наступні:
1) High-risk deployment: Deploying an entire solution or application in one go poses a high risk as all modules are going to be deployed even for a single change in one of the modules.
2) Higher testing time: As we have to deploy the complete application, we will have to test the functionality of the entire application. We can’t go live without testing. Due to higher interdependency, the change might cause a problem in some other module.
3) Unplanned downtime: Complete production deployment needs code to be fully tested and hence we need to schedule our production deployment. This is a time-consuming task that results in high downtime. Although planned downtime, during this time, both business and customers will be affected due to the unavailability of the system; this could cause revenue loss to the business.