Моноліт

Що це слово означає насправді

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

Плутанина походить від другого значення, що приліпилося до слова близько 2014 року: «велика грудка бруду», де все викликає все, жодну частину неможливо зрозуміти окремо, а зміна в рахунках ламає сторінку входу. Це реальний і поширений стан. Просто його спричиняє не єдина одиниця деплою, і поділ деплою його не лікує.

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

Чому це правильний вибір за замовчуванням

Аргумент на користь монолітного старту — не ностальгія. Він у тому, що єдиний процес усуває цілу категорію проблем, які інакше довелося б розв’язати ще до написання бізнес-логіки.

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

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

Як утримати межі

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

Найкращу віддачу дають архітектурні тести. Десяток рядків, які стверджують «ніщо поза модулем білінгу не має права імпортувати billing.internal», перетворюють правило, з яким усі згодні й якого ніхто не дотримує, на падіння збірки з конкретним іменем. Без них межі модулів живуть рівно доти, доки в команді лишається людина, якій вони не байдужі.

Де моноліт справді вичерпується

Реальні межі існують, і чесність щодо них відрізняє аргумент від уподобання. Жодна з них не стосується розміру коду.

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

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

Моноліт проти мікросервісів

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

Як це виявляється в реальній поставці

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

Де він вироджується

• Джойни через таблиці різних модулів зв’язують модулі через сховище, а не через інтерфейс.
• Пакети за шарами — контролери, сервіси, репозиторії — групують за технічною роллю й дають кожній фічі всю кодову базу як поверхню.
• Спільний модуль «common» чи «utils», від якого залежить усе і яким не володіє ніхто.
• Правила модулів, узгоджені в документі, а не перевірені в CI, тримаються один квартал.
• Тести, достатньо повільні, щоб їх перестали ганяти локально, — зникає той швидкий зворотний зв’язок, що робив моноліт дешевим.

Коли це застосовувати

Пов’язані сторінки

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