Чому моноліт ламає мобільний застосунок при зростанні навантаження
Монолітний бекенд мобільного застосунку тримається до певного порогу: поки запитів небагато і команда одна, він передбачуваний і дешевий у підтримці. Проблема в тому, що мобільний клієнт — найвимогливіший споживач API.
Він ходить із нестабільних мереж, надсилає пачки запитів при відкритті екрана й оновлюється хвилями, коли користувачі ставлять нову версію. Щойно навантаження на одну з ділянок зростає, деградує весь сервіс, а не окрема функція.
Першим здається час відгуку API. Важка аналітика, вивантаження стрічок або перерахунок рекомендацій виконуються в тому самому процесі, що й вхід у застосунок, — і запити на авторизацію стають у спільну чергу за ними.
Далі вмикається каскад: повільна ділянка утримує з'єднання, пул потоків вичерпується, і відмовляють уже ті ручки, які до перевантаження не мають відношення. Користувач бачить не «не працює розділ», а «застосунок не відкривається», і йде раніше, ніж ви встигаєте відреагувати.
Друге вузьке місце — релізний цикл. Будь-яка правка, навіть в одному модулі, вимагає перезбирання й повторного викочування всього моноліту, тому зміни накопичуються у спільних гілках і виходять великими партіями. Помилка в такій партії відкочує назад усі доопрацювання, а не одне.
Команди починають узгоджувати вікна викочування між собою, і швидкість постачання падає рівно тоді, коли ринок вимагає її нарощувати.
Мікросервісна архітектура мобільного застосунку знімає це інакше: критичні ділянки — вхід, оплата, стрічка — живуть окремими сервісами зі своїми ресурсами і своїм ритмом викочування.
Перевантаження рекомендацій більше не роняє авторизацію, а збій локалізується в одному контурі замість усього бекенду. Розбираємо, як це закривається на практиці: де проходить межа сервісів, як налаштовується ізоляція відмов і що відбувається з релізним циклом.
Мікросервісна архітектура мобільного застосунку: що змінюється
Мікросервісна архітектура мобільного застосунку: що змінюється
Перехід на мікросервісну архітектуру мобільного застосунку починається з декомпозиції сервісів за межами бізнес-можливостей: каталог, замовлення, платежі, профіль, сповіщення.
Кожен сервіс отримує власну схему даних і релізний цикл — правка логіки доставки більше не потребує перезбирання та повторного тестування всього моноліту. На практиці це скорочує час від коміту до продакшену з годин до хвилин і прибирає чергу релізів між командами.
Ізоляція відмов замість спільного падіння
У моноліті падіння одного обробника тягне за собою весь процес: клієнт бачить помилку на всіх екранах одразу. У мікросервісах збій платежів локалізується — каталог, кошик і профіль продовжують відповідати, застосунок показує зрозумілий стан замість білого екрана.
Circuit breaker на шлюзі відсікає деградований сервіс за частки секунди, а черга повторної доставки повертає втрачені запити, коли сервіс піднявся. Частка успішних сесій при частковій деградації залишається високою, а не падає до нуля.
Незалежні релізи та зворотна сумісність
Кожен сервіс версіонується окремо: мобільний клієнт продовжує працювати зі старою версією контракту, поки нова розкочується на частину користувачів. Це знімає головний біль релізів — примусове оновлення застосунку через правку на бекенді.
Контракти фіксуються у схемі, несумісні зміни проходять через версіонування, а не через одночасний викат клієнта і сервера.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Моноліт з модулями | Рання стадія, одна команда, неясні межі | Спільний релізний цикл, відмова одного модуля валить усе |
| Мікросервіси зі спільним шлюзом | Кілька команд, різний темп змін | Потрібні спостережуваність і контракти, дорожча експлуатація |
| Гібрид: ядро + сервіси | Поступове винесення вузьких місць | Тимчасова подвійна маршрутизація запитів |
Для наскрізного трасування запиту між сервісами використовуємо розподілений трейсинг — OpenTelemetry: видно, на якій ділянці ланцюжка зросла затримка, без ручного зіставлення логів.
Що це дає за метриками
Після декомпозиції час відновлення після збою окремого сервісу вимірюється хвилинами, а не зупинкою всього продукту. Команди релізять незалежно, частка змін, що доходять до продакшену без ручної синхронізації, зростає, а радіус ураження одного дефекту обмежується одним доменом.
Етапи впровадження мікросервісної архітектури
Перехід до мікросервісів — це не «переписати бекенд», а керована заміна моноліту, де кожен крок перевіряється і є оборотним. Починаємо з інвентаризації поточного стану: які модулі пов'язані напряму, де спільні таблиці та транзакції, які виклики критичні для мобільного клієнта.
За підсумками аудиту видно, які сервіси виділяються без болю, а які тягнуть за собою перебудову даних — це визначає порядок робіт і межі першого релізу.
- Аудит бекенду. Знімаємо карту залежностей, профілюємо навантаження за ендпоінтами, фіксуємо вузькі місця та точки відмови. На виході — перелік доменів-кандидатів і оцінка ризиків за кожним.
- Проєктування сервісів. Визначаємо межі доменів, контракти між ними, схему даних і стратегію міграції. Окремо проєктуємо шар для мобільного клієнта: агрегація відповідей, версіонування API, щоб старі збірки застосунку не ламалися при оновленні сервісів.
- Налаштування інфраструктури. Розгортаємо контейнеризацію, оркестрацію, маршрутизацію трафіку, централізовані логи та метрики. Налаштовуємо автомасштабування та health-перевірки, щоб відмова одного сервісу не валила застосунок повністю.
- Поетапне винесення логіки. Переносимо домени по одному, з паралельною роботою старого і нового контуру та перемиканням трафіку. Кожен крок відкочується без простою.
- Приймання рішення. Проганяємо навантажувальні та відмовостійкі перевірки, звіряємо метрики з базовими, перевіряємо коректність даних після міграції.
- Передача та документація. Віддаємо схеми сервісів, конфігурації, регламенти розгортання та моніторингу, навчаємо команду замовника.
Такий порядок дає передбачуваний результат: час відгуку під навантаженням перестає деградувати, а збій в одному домені локалізується замість падіння всього бекенду. Опишіть задачу — повернемося з оцінкою та планом за вашим контуром.
Чим відрізняється мікросервісна архітектура від модульного моноліту?
Модульний моноліт — це один застосунок, усередині якого код розділено на ізольовані модулі з чіткими межами та забороною на прямі звернення між ними.
Збірка та деплой відбуваються одним артефактом, транзакції залишаються локальними, а зв'язаність модулів контролюється на рівні збірки.
Мікросервісна архітектура мобільного застосунку розносить ті самі модулі в окремі процеси зі своїми сховищами та мережевими контрактами — і саме тут змінюється все: вартість володіння, швидкість релізів і ціна помилки.
Швидкість релізів. У моноліті нова функція їде у спільному релізі: поки її не пропустять через регрес усього застосунку, вона не вийде.
У мікросервісах команда котить свій сервіс незалежно, але платить за це контрактами — ламальна зміна в API одного сервісу зупиняє релізи всіх, хто від нього залежить. Виграш у швидкості реальний лише за версіонування контрактів і зворотної сумісності за замовчуванням.
Вартість володіння. Моноліт дешевший в експлуатації: один рантайм, одна база, один моніторинг. Мікросервіси додають розподілені транзакції, ретраї, ідемпотентність, трасування між сервісами та окремий контур спостережуваності. Ці витрати не разові — вони входять у кожну нову функцію.
Складність експлуатації. Відмова в моноліті локальна й відтворювана на одному стенді. У мікросервісах збій одного вузла проявляється каскадом: таймаути, повтори, переповнення черг. Без circuit breaker і лімітів на паралелізм такий каскад гасить весь бекенд.
Практичний висновок: модульний моноліт виграє, поки команд небагато і домен ще змінюється. Перехід на мікросервіси виправданий, коли модулі вже стабільні, а релізні цикли команд почали заважати одна одній.
Кейс: як ми скоротили час відновлення після збою
Замовник прийшов із монолітом: один сервіс обслуговував каталог, замовлення, оплату та сповіщення. Будь-яка правка в модулі оплати тягла за собою перезбирання й перезапуск усього застосунку, а падіння одного вузла укладало весь бекенд.
Мобільний клієнт у такі моменти отримував помилки на всіх екранах одразу — від стрічки до кошика. Середній час відновлення після збою тримався на рівні кількох годин, і це без урахування часу на пошук причини.
Що змінили
Ми розрізали моноліт за межами предметних областей: каталог, замовлення, платежі, сповіщення та профіль стали окремими сервісами зі своїми сховищами. Мобільний клієнт спілкується з ними через єдиний шлюз, який маршрутизує запити й тримає авторизацію.
Критичний шлях «кошик → оплата» винесли в окремий сервіс із власним пулом ресурсів — його недоступність більше не роняє каталог.
Окремо закрили клас відмов, який раніше був найчастішим: перевантаження при піковому навантаженні. Черга повідомлень згладжує сплески, а кожен сервіс масштабується незалежно — під розпродаж піднімаємо тільки оплату та замовлення, не чіпаючи решту.
Метрики до і після
| Показник | До | Після |
|---|---|---|
| Середній час відновлення | години | хвилини |
| Частка відмов через перевантаження | основна причина простоїв | поодинокі випадки |
| Область ураження при збої | весь застосунок | один сервіс |
| Випуск оновлення модуля | перезбирання всього бекенду | збирання одного сервісу |
Скорочення часу відновлення далося не лише розділенням коду. Ми налаштували перевірки живості кожного сервісу, автоматичний перезапуск застосунків, що впали, і збір метрик із трасуванням запитів — тепер причина відмови видна за ланцюжком викликів, а не шукається перебором логів.
Kubernetes узяв на себе оркестрацію: перезапуск, розподіл навантаження та оновлення без простою. Інженерна частина — у тому, щоб правильно нарізати сервіси й не перетворити мікросервісну архітектуру мобільного застосунку на розподілений моноліт.
Сумніви перед стартом: сумісність, міграція, відкат
Перехід з моноліту на мікросервісну архітектуру мобільного застосунку майже ніколи не робиться «за один день» — тому перше питання на старті зазвичай про міграцію без простою.
Ми розбиваємо переїзд на етапи: спочатку виносимо некритичний сервіс, ганяємо його паралельно з монолітом і звіряємо відповіді, і тільки коли розбіжності нульові — перемикаємо трафік.
Такий підхід дає можливість відкату змін на будь-якому кроці: поки стара логіка жива, повернутися назад — це перемкнути маршрут, а не відновлювати базу з бекапу.
Що якщо частина даних уже накопичена в старій схемі? Міграцію робимо оборотною: пишемо в нове сховище і продовжуємо дублювати в старе, поки не переконаємося в цілісності.
Окремо перевіряємо, що мобільні клієнти старих версій, які ще живуть на пристроях, продовжують працювати — API-контракт розширюємо, а не ламаємо.
Як бути з доступами та безпекою? Сервіси спілкуються по внутрішній мережі, назовні відкритий тільки шлюз, кожен сервіс отримує власні облікові дані з мінімальними правами. Секрети не лежать у коді — вони в сховищі й ротуються.
Чи можна відкотити реліз, якщо проблема вилізла в проді?
Так. Кожен сервіс версіонується окремо, тому відкат зачіпає тільки його, а не весь застосунок. Схему даних змінюємо так, щоб попередня версія сервісу продовжувала з нею працювати — тоді повернення на минулий реліз не потребує міграції назад.
На руки замовник отримує:
- схему сервісів та їхніх зон відповідальності;
- опис API-контрактів і правил версіонування;
- конфігурації середовищ і політику доступу;
- регламент міграції без простою та план відкату;
- налаштований моніторинг і оповіщення по кожному сервісу;
- документацію щодо розгортання та експлуатації.
Опишіть вашу поточну архітектуру та обмеження — повернемося з оцінкою та планом переходу.
Терміни впровадження мікросервісної архітектури за етапами
Перехід від моноліту до мікросервісів не робиться одним релізом: поки новий контур не прийняв бойове навантаження, старий продовжує обслуговувати користувачів. Тому план-графік будуємо так, щоб кожен етап давав працюючий результат і залишав можливість відкату.
Нижче — орієнтовні терміни для типового мобільного продукту з активною аудиторією; на конкретному проєкті вони зсуваються залежно від кількості інтеграцій та обсягу накопичених даних.
Терміни залежать від трьох речей: скільки зовнішніх інтеграцій зав'язано на моноліт, чи є виділена команда під міграцію і наскільки строгі вимоги до безперервності сервісу. За жорсткого вікна доступності хвилі перенесення розтягуються, зате продукт не йде в простій.
Ми фіксуємо контрольні точки за етапами, щоб ви бачили прогрес не за звітами, а за працюючими сервісами в бою.
Опишіть ваш продукт і поточне навантаження — повернемося з оцінкою та планом за етапами.
