viktor-yakubiv
commented
6 years ago Як показує практика (і логіка), мікросервісна архітектура не дає виграшу в продуктивності. Ми починаємо спілкуватися через TCP-стек замість простого обміну даними в пам'яті, а тут вже відчутна проблема: запакування, розпакування, перетворення форматів, створення каналів, додаткове навантаження на ситсему. Навіть тестувати не хочеться.
Та на це варто дивитися не тільки як розробник. Іноді потрібно глянути на проекти з точки зору бізнесу. Оцінити свої зусилля, вартість праці своєї та колег, ріст продукту, перспективи. Може навіть визначити точку краху. Порахувати надлишкові людино-години за merge-конфлікти, дискусії про те, як там щось має працювати, зайві транзакції всього в команді, нестримний ріст кількості людей тощо. Продуктивність не тільки в швидкості роботи застосунку, а й в простоті його підтримки, розподіленості (георграфічної в тому числі).
Іноді достатньо й навіть потрібно розділити проект на кілька. Це ріст. В ньому є переваги й недоліки.
Та можна дещо знайти в пошуковичку:
- Microservices: what are pros and cons? — опис поняття на StackOverflow
- Performance Evaluation of Microservices Architectures using Containers — наукова стаття про порівняння швидкості роботи застосунку в залежності від кількості його екземплярів
Навести порівняння продуктивності між реалізаціями на основі класичної монолітної архітектури та мікросервісної архітектури.
Бажано наводити порівняння для двох підходів реалізації одного застосунку чи дуже схожих застосунків, а не чогось зовсім різного. Також бажано наводити ресурси з детальним технічним описом, а не лише абстрактними висловленнями на зразок «перехід до мікросервісної архітектури дозволяє збільшити продуктивність в 5-7 разів, бо вона така крута» чи, навпаки, «продуктивність мікросервісів дуже погана, бо там багато запитів» :)