Коли кажуть про переваги мікросервісу, часто забувають згадати, що перехід на нього займає досить багато часу. До прикладу, у FAVBET Tech почали переходити на мікросервіс кілька років тому, але й досі мають 30% залишків моноліту.
Не зручно? Так. Але чи витримає їхній моноліт highload? Теж так. А чи є для його оптимізації якісь особливі підходи та чи варто за нього триматися, розповідає в партнерському тексті Head of Engineering в FAVBET Tech Максим Ільїн.
Моноліт VS мікросервіс для високонавантажених систем
Зазвичай високонавантажені продукти використовують мікросервісну архітектуру. За словами Максима Ільїна, це найправильніший шлях. Тільки так можна масштабувати певний функціонал (сервіс), а також ізолювати й виділяти необхідні ресурси для кожного сервісу окремо.
Крім того, у мікросервісів:
- гнучкіші розгортання та релізи, що дозволяє оновлювати тільки необхідні частини продукту й не впливати на інші;
- гнучкіша розробка – кожним мікросервісом може займатись окрема команда, що не спричинить конфліктів функціоналу.
Натомість моноліт має наступні обмеження:
- Не можна масштабувати різні компоненти системи. Для монолітної архітектури можемо масштабувати систему в цілому, і це дуже дорого для інфраструктури.
- Функціонал не ізольований, що за певних обставин може впливати на весь проєкт у цілому, аж до непрацездатності продукту. Це стосується не тільки кодової бази проєкту, а й баз даних.
- Складні розгортання та релізи. Мінімальні зміни чи виправлення помилок програми можуть вимагати певного даунтайму всієї системи.
Максим Ільїн, Head of Engineering в FAVBET Tech
«Проблеми особливо видно при високому навантаженні. Коли вони з’являються, ти розумієш, що недолік у маленькій частині коду тягне за собою весь моноліт – це дуже незручно. Отже, щоб виправити щось невеличке, треба багато ресурсів, у тому числі грошових»
Але чи означає це, що для highload-проєктів у жодному випадку не можна використовувати моноліт? Не зовсім так.
Максим Ільїн:
«Використання монолітної архітектури на стадіях MVP чи для продуктів з невеликою кількістю залежностей – абсолютна норма. Коли замовник не впевнений в реалізації ідеї та потрібно протестувати її на ринку, з фінансового погляду не доцільно вкладати в це великі гроші. А монолітну архітектуру побудувати дешевше, аніж мікросервіс. Тож уже в міру зростання продукту відбувається перехід, і інколи якась частина так і лишається на моноліті».
У компанії FAVBET Tech перехід на мікросервісну архітектуру почали ще кілька років тому. Наразі тут мають приблизно 80% мікросервісів і 20% моноліту. І хоча найближчим роком у компанії планують повністю перейти на мікросервіс, Максим зазначає, що й у моноліта є свої переваги:
- Не потрібно використовувати транспорт між компонентами (мікросервісами) системи. Таким чином не витрачається час, щоб передати дані мережею з одного сервісу в інший.
- У випадку невеликих проєктів певні зручності є для розробки. Робота з кодовою базою виконується в одному репозиторії – там розробнику простіше орієнтуватися по всьому функціоналу системи.
Коли 100% час переходити на мікросервіс
У компанії FAVBET Tech було кілька тригерів, які призвели до рішення перейти на мікросервісну архітектуру.
Кейс FAVBET Tech №1
Популярні спортивні події мають велику кількість маркетів (варіанти ставок), та одночасно з великою кількістю користувачів на сайті призводить до великого навантаження платформи. Оновлення даних в реальному часі для кожного окремого гравця в такому випадку стає викликом стійкості всієї системи.
Поки функціонал нотифікацій не був виділений в окремий мікросервіс, кожне навантаження на сайт під час популярних подій спричиняло проблеми для всієї платформи.. Виникали проблеми з обробкою запитів – аж до того, що платформа взагалі переставала працювати.
Кейс FAVBET Tech №2
Коли певна кількість користувачів приходила на сайт, відкривала сторінки та робила ставки, платформа могла перестати працювати з незрозумілих причин. Усе тому, що серія HTTP викликів йшла на монолітний сервіс, який містив багато функціоналу. Проаналізувати його логи, щоб виявити, що саме треба поправити, було майже неможливо, й доводилось працювати майже наосліп.
Максим каже, що, відтоді як компанія почала переходити на мікросервіс, продуктивність системи збільшилась у рази. Це відстежують кількома способами:
- Внутрішні технічні метрики системи.
- Кількість інцидентів на платформі за період часу.
- Час витрачений на вирішення проблеми з боку команди розробки.
- Фідбек від клієнтів.
Декілька років томи проблеми із платформою виникали доволі регулярно. На сьогоднішній день збої в роботі є радше виключенням із правил і трапляються дуже рідко. Тим не менш ми продовжуємо шукати шляхи вдосконалення і максимізації нашого Up time.
Як у FAVBET Tech працюють із залишками моноліту
Головне правило роботи з монолітом у контексті highload – не фокусуватися на його збереженні, а планувати перехід і впроваджувати ті самі методи оптимізації, що працюють і для мікросервісу.
Найефективніші з них:
- Якісне навантажувальне тестування: щоб знати максимальні можливості платформи.
- Скейлінг і даунскейлінг: збільшення і зменшення кількості серверів під потреби.
- Шардування: розподіл даних по декількох базах.
Читати також: Стабільні версії на бекапі, кастомні метрики і не тільки: найкращі практики для highload від FAVBET Tech
Унікальних практик для роботи з монолітом для його підготовки під високе навантаження не існує. Тому Максим радить дотримуватись балансу і підходити до питання завчасно — якщо є стратегічний план розвитку бізнесу і можна оцінити майбутні навантаження на продукт, варто заздалегідь планувати перехід на мікросервісну архітектуру та закладати час на вирішення технічного боргу. Це не швидкий процес зі своїми складнощами.
Максим Ільїн, Head of Engineering в FAVBET Tech
Максим Ільїн:
«Найпростіший шлях – зупинити розробку фіч і переробити архітектуру від початку, враховуючи нові вимоги. Але це дуже рідкісний випадок, і зазвичай потрібно робити оптимізації паралельно з розвитком проєкту. У нас було саме так. Ми часто закривали технічний борг разом з новими доробками та фічами, для чого оцінювали задачі по часу більше, ніж вони б потребували без оптимізації моноліту».
Висновки
Працювати з монолітом можна. Для цього типу архітектури у плані оптимізації під високе навантаження використовують ті самі практики. Утім, їх впровадження може бути складнішим та обходитися дорожче.
Тож загалом Максим Ільїн рекомендує переходити на мікросервіс: з поправкою на те, що інколи перехід триватиме доволі багато часу. Тому найкраще дотримуватись балансу та використовувати переваги обох архітектур з користю для продукту.
Візуал: редакція highload.tech
Сообщить об опечатке
Текст, который будет отправлен нашим редакторам: