Модульний моноліт чи мікросервіси: які межі потрібні iGaming-платформі

Казино-платформа може мати окремі API гаманця, ігор і бонусів, але для змін їй усе одно може знадобитися узгоджений реліз і спільна зміна бази даних. І навпаки: один застосунок, що розгортається як ціле, може містити чітко визначені предметні області, які зручно тестувати й підтримувати. Кількість сервісів не показує, яку платформу простіше змінювати та безпечніше експлуатувати.

Корисніше поставити вужче запитання: яка межа усуне підтверджене обмеження та які нові стани відмови вона створить? Для технічного директора, архітектора чи керівника розробки відповідь має пов’язувати бізнес-проблему з рішенням, яке можна впровадити. У цьому посібнику ми простежимо шлях ставки через таку межу, а потім розглянемо вибір і перевірку першого відокремлюваного компонента. Конкретне хмарне середовище, фреймворк чи поріг навантаження не передбачаються.

Розрізняйте модульність і незалежність розгортання

Модульний моноліт — застосунок, що розгортається як єдине ціле, із внутрішніми межами між функціями. Мікросервіс — функція з явним контрактом і повноваженнями щодо власних даних, яку розгортають окремо. Окремі репозиторії чи контейнери самі по собі не доводять, що сервіс можна випускати без узгоджених змін в інших компонентах.

У модульній платформі визначте інтерфейси гаманця, ставок, платежів і бонусів, дозволені залежності та відповідальність за записи. Не допускайте прямої зміни таблиць гаманця іншим модулем; спільна транзакція водночас може координувати роботу через ці інтерфейси. Закріплюйте межі перевірками залежностей, рев’ю коду й тестами. Інакше слово «модульний» описує лише структуру тек.

Для окремих сервісів контракти мають працювати через мережу: сторона, що викликає сервіс, може не дочекатися відповіді, версії можуть співіснувати, а результат віддаленої операції — залишатися невідомим. Сервіс може логічно володіти даними за спільної інфраструктури бази, але спільні ресурси та відмови зберігають залежності. Володіння сховищем і фізична ізоляція — різні рішення. У матеріалі про ключові домени та їхні межі докладно розглянуто модель відповідальності; тут питання в тому, чи виправдовує винесення цієї межі за межі процесу свою вартість.

Простежте шлях ставки через межу транзакції

Розгляньмо умовну платформу, яка приймає ставку, використовуючи власні записи гаманця й ставок. Якщо обидва записи беруть участь в одній транзакції бази даних, застосунок може разом зарезервувати доступні кошти за виконання потрібних умов і створити запис ставки. Водночас потрібні правила конкурентного доступу та стабільний ідентифікатор запиту. Спільна база сама по собі не заважає двом одночасним запитам витратити той самий залишок. Прийняття ставки стороннім провайдером або зовнішній платіж перебувають поза цією локальною транзакцією.

Тепер перенесімо гаманець в окремий сервіс. Можлива послідовність: зберегти незавершений запит, зарезервувати кошти з його стабільним ідентифікатором операції, зафіксувати результат прийняття ставки, потім завершити резервування за погодженим контрактом. Точний момент прийняття залежить від продукту й провайдера. Перш ніж схвалити поділ, з’ясуйте, що станеться, якщо гаманець зафіксує резерв, але відповідь загубиться, або якщо сторона, що його викликає, перезапуститься до збереження наступного кроку.

• Результат резервування невідомий: відновіть наявну операцію за ідентифікатором або повторіть запит за контрактом, що повертає її попередній результат. Прив’яжіть ідентифікатор до початкового запиту та відхиляйте змінені параметри. Не створюйте нового списання лише тому, що сторона, яка викликає сервіс, не дочекалася відповіді.
• Підтверджена відмова до прийняття ставки: вивільніть підтверджений резерв через операцію, що зберігається й допускає безпечне повторення.
• Ставку вже могли прийняти: зберігайте видимий незавершений випадок до з’ясування результату. Сплив часу очікування сам по собі не дає підстав вивільняти гроші, які можуть забезпечувати прийняту ставку. Закінчення строку резерву теж має враховувати цю невизначеність; автоматичний таймер вивільнення не замінює з’ясування результату.
• Одночасні запити: гаманець має забезпечувати дотримання правил витрачання під час оновлення даних, за яке відповідає сам гаманець; кешований баланс сторони, що викликає сервіс, не може дозволяти резервування.

Це вимоги до розглянутого прикладу, а не універсальний протокол провайдерів. У посібнику AWS щодо саг зазначено, що координація локальних транзакцій призводить до узгодженості із затримкою й не забезпечує ізоляції транзакцій. Компенсація потребує власних правил; це не відкочування транзакції бази даних одразу в усіх сервісах. Якщо команда не може пояснити кожен проміжний фінансовий стан, зберігайте локальну межу, доки це питання не розв’язано.

Визначте обмеження, яке справді усуне сервіс

Запишіть симптом, перш ніж пропонувати сервіс. Формулювання «платформа повільна» надто загальне. Звіт може конкурувати із записом операцій гаманця за ресурси бази; обробка зображень — займати процесор застосунку; інтеграція провайдера — затримувати реліз, оскільки всі зміни випускаються разом. Це різні обмеження.

• Ресурсомістке фонове завдання: спочатку перевірте окремий обробник із виділеним ресурсним бюджетом або модель даних для читання. Обробник можна масштабувати незалежно, не перетворюючи кожен домен на сервіс; перенесення роботи в інший процес змінює експлуатацію навіть за спільної кодової бази.
• Фінансовий запис із високою конкуренцією за доступ: виміряйте очікування блокувань, дослідіть плани запитів і конкурентний запис. Додавання мережевого виклику до того самого послідовного оновлення не підвищує пропускної здатності цього оновлення.
• Залежність між релізами: визначте контракт або зміну бази, що потребують узгодження. Окреме розгортання допомагає лише тоді, коли споживачі можуть далі працювати з підтримуваним контрактом.
• Поширення відмови однієї інтеграції: спочатку обмежте кількість одночасних операцій, чергу та споживання ресурсів. Окремий процес може поліпшити локалізацію, але синхронні залежності та спільна інфраструктура все ще здатні передавати відмову далі.

Зафіксуйте початкові показники за допомогою метрик процесів, логів і трасувань. Порівняйте однакове репрезентативне навантаження до й після зміни. Враховуйте завершені операції, час очікування та трудовитрати на відновлення, а не лише процесорне навантаження чи успішні HTTP-відповіді. Виділення обґрунтоване, якщо воно усуває заявлене обмеження, не приховуючи незавершену роботу в черзі.

Порівнюйте варіанти за доказами, а не балами

Використовуйте такі запитання для вибору рішення. Вони навмисно не дають зваженого «переможця»: неприпустимий фінансовий стан не можна компенсувати швидшим розгортанням.

• Стабільність межі: чи часто бізнес-правила переходять між запропонованими компонентами? Дослідіть нещодавні зміни та найближчі відомі вимоги продукту. Часте переміщення правил — аргумент на користь внутрішньої межі, яку простіше переглядати.
• Узгодженість: які записи мають змінюватися разом, а які споживачі даних допускають затримку? Розгляньте сплив часу очікування після кожного зафіксованого кроку. Зберігайте тісно пов’язані оновлення разом, якщо немає обґрунтування для повністю спроєктованого розподіленого процесу.
• Незалежність релізів: чи може відповідальна команда випустити сумісну зміну, поки споживачі залишаються на поточній версії? Покажіть це тестом контракту й репетицією, а не новим репозиторієм.
• Масштабування або локалізація: чи можна відокремити обмежувальний ресурс? За допомогою профілювання та тренування з відмовою покажіть, що ізоляція компонента поліпшує потрібний користувацький процес.
• Відповідальність за експлуатацію: хто відповідає за сповіщення, оновлення, відновлення та виведення контрактів із використання? Навіть незалежне розгортання потребує команди, здатної підтримувати його після того, як початковий розробник піде.
• Повна вартість: оцініть розробку, міграцію та паралельну роботу, а потім регулярні витрати на інфраструктуру, телеметрію, підтримку безпеки, розбір інцидентів і звірку. Порівняйте їх із виміряною вартістю поточного обмеження та простішого варіанта.

У Monolith First Мартін Фаулер на основі досвіду обґрунтовує спільний старт за невизначених меж. Він також розглядає старт із великими сервісами. Це аргументи для проєктування, а не універсальне правило; обирайте за можливостями й обмеженнями, які команда може підтвердити.

Перевірте незалежність змін і локалізацію відмов

Дослідіть три ознаки зв’язаності: споживач має розгортатися за кожної зміни залежності; кілька сервісів можуть змінювати один бізнес-запис без єдиного відповідального джерела; недоступність одного сервісу заважає завершити процес, у решті з ним не пов’язаний. Перейменування компонентів не розв’язує жодної з цих проблем.

Відрепетируйте сумісний реліз за одночасної роботи старих і нових споживачів. Додайте нове поле чи поведінку, не вимагаючи негайного переходу споживачів. Переведіть споживачів і простежте використання попереднього контракту, перш ніж вимагати нову поведінку або припиняти попередню підтримку. Застосовуйте ту саму послідовність до змін схеми. Зміни даних з інших сервісів мають відбуватися через контракт власника; права доступу до бази мають підтримувати цю модель повноважень. Спільна модель для читання може допомагати звітності, але не повинна ставати ще одним джерелом фінансового запису.

Потім вимкніть залежність. Визначте, які операції можна надійно зберегти для очікування, які допускають явно обмежене застаріле представлення, а які потрібно зупинити через недоступність компонента, уповноваженого ухвалювати рішення. Для звітності може бути допустима погоджена затримка; кешований звіт не повинен непомітно перетворюватися на дозвіл на ставку або виведення коштів. Обмежте роботу, що очікує, і перевірте поведінку за досягнення ліміту.

У Microservice Prerequisites Фаулер виділяє автоматизацію розгортання, моніторинг і спільну відповідальність розробки та експлуатації. Продемонструйте ці можливості до збільшення кількості сервісів. Вони корисні й моноліту. Розгляньте реальний шлях інциденту: хто його помічає, що дає змогу визначити зачеплені операції та хто може безпечно їх відновити?

Виділіть одну функцію без конкуруючих джерел запису

Припустімо, що кандидат на виділення — звітність, оскільки аналітичні запити заважають обробці транзакцій. Спочатку визначте початкові записи звіту, допустиму затримку оновлення та спосіб звірки. Переконайтеся, що ця функція звітності не ухвалює рішень щодо допуску користувача чи фінансових операцій. Створіть модель для читання, не змінюючи компонент, відповідальний за запис початкових даних. Виміряйте, чи перестали нові запити конкурувати за обмежувальний ресурс; репліка або окреме сховище можуть допомогти, але перенесення тієї самої дорогої роботи в інше спільне вузьке місце може виявитися марним.

Для публікації зафіксованих змін посібник AWS щодо транзакційного outbox описує збереження запису та вихідної події в одній транзакції з подальшою окремою публікацією. Він також попереджає про повторну доставку. Це закриває локальний розрив між базою й повідомленням, але не робить усі ефекти споживачів атомарними й не усуває затримок доставки.

Для пілота збережіть ідентифікатори та порядок, потрібний для кожного запису. Якщо це можливо, нехай споживач фіксує обробку повідомлення та своє локальне оновлення разом. Опишіть, як він перебудовує дані, наздоганяє джерело та виявляє пропущені зміни. Задайте ресурсний бюджет для outbox і накопиченої роботи у споживачів, а також поведінку на випадок, якщо тривала недоступність доставки вичерпає цей бюджет: асинхронна робота теж витрачає ресурси. Порівнюйте старі й нові звіти на одній межі даних; інакше звичайна затримка реплікації може виглядати як помилка міграції. Не допускайте зовнішніх платежів та інших повторних побічних ефектів під час тіньової обробки.

Якщо наступне виділення переносить повноваження запису, підготуйте окремий план перемикання: завершіть або врахуйте ще не завершені операції, спрямуйте команди одному призначеному власнику, вимкніть попередні шляхи запису та проведіть звірку на межі передачі. Збережіть шлях відновлення, що враховує записи після перемикання. Повертати трафік у стару базу небезпечно, якщо ці зміни є лише в новій. Матеріал про міграцію даних чинної платформи допоможе з контролями даних, а посібник із поетапної модернізації — із виведенням старих шляхів із використання.

Зафіксуйте конкретне рішення та перевірте його на пілоті

Завершіть роботу рішенням, яке можна предметно обговорити й оспорити. Зафіксуйте зачеплену функцію, поточне обмеження, обраний варіант, відхилену просту альтернативу, записи, що визначають достовірний стан, відповідального, додані стани відмови, обсяг міграції та докази, які стануть приводом для перегляду. Додайте витрати й припущення, невизначеність яких здатна змінити вибір.

В умовному пілоті звітності рішення може полягати в тому, щоб зберегти запис операцій гаманця й ставок разом, а читання для звітності перенести в окремий обробник і сховище. Критерії приймання — менший вплив на обробку транзакцій, актуальність звіту в погоджених межах, обмежений обсяг накопиченої роботи та відтворювана звірка. Визначте навантаження, інтервал вимірювання, ліміт і того, хто перевіряє, до запуску. Це запропонований експеримент, а не твердження про клієнта чи гарантоване поліпшення.

Успішний пілот обґрунтовує саме цю межу. Він не обґрунтовує наступне виділення гаманця й не передбачає оптимальної кількості сервісів. Якщо сумісні релізи, відновлення чи модель відповідальності не проходять перевірки нижче, вдосконалюйте межу, перш ніж розширювати розподілену систему.

Для ширшого огляду матеріал про архітектуру iGaming-платформи пояснює, як замовити проєкт, який команда зможе реалізувати, а модернізація платформи — як перейти від чинної системи до нової. Використовуйте їх разом із посібниками з міграції та спостережуваності, посилання на які наведено вище. Перш ніж вважати виділення завершеним, вимагайте чотири демонстрації для обраної межі:

• Сумісний реліз: розгорніть відокремлюваний компонент так, щоб наявний споживач далі працював. Перевірте період співіснування версій і покажіть, як попередній контракт буде виведено з використання.
• Локалізована відмова: вимкніть компонент і перевірте зачеплені та незачеплені користувацькі процеси. Покажіть обмеження роботи, що очікує, та погоджену поведінку за вичерпання ресурсів; застаріле представлення не має дозволяти фінансову дію.
• Перервана операція: виконайте перезапуск після фіксації оновлення, але до підтвердження. Повторіть той самий запит або подію й відновіть один збережений результат без повторних фінансових ефектів. Перевірте видимість незавершених випадків і відповідальність за них.
• Передача з можливістю відновлення: звірте обидві сторони на одній межі даних і відрепетируйте відновлення з урахуванням ще не завершених операцій та змін після перемикання. Підтвердьте, яке джерело має право запису для кожної команди протягом усього переходу.