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

Одне виділення від початку до кінця — шістнадцять кроків, як зрозуміти, що кожен зроблено, і шлях назад

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

До першого виділення: причина й кандидат

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

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

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

Шість способів переносити код, не зупиняючи систему

Найвідоміший патерн має ботанічну назву. Під час відпустки в дощових лісах Квінсленду 2001 року Мартін Фаулер побачив фікуси-душителі (strangler fig). Фікус починається як насінина в заглибині дерева-господаря, росте вниз до землі й угору до світла і зрештою може стояти сам там, де було дерево. Через пару років він використав це як образ того, як його колеги замінювали застарілі системи, у короткому дописі «Strangler Application». Згодом він перейменував його на «Strangler Fig Application», бо люди запам’ятовували жорстоке слово й забували рослину. У серпні 2024 року він переписав допис, і нова версія називає чотири види діяльності, які Ян Картрайт, Роб Горн і Джеймс Льюїс визначили для будь-якої поступової заміни. Зрозуміти, яких результатів ви хочете. Вирішити, як розбити проблему на менші частини. Успішно поставити ці частини. І змінити організацію, щоб так могло тривати й далі.

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

Фасад ставлять першим, ще до будь-якого виділення (крок 4). Із фасадом на місці перше виділення є зміною маршрутизації, і його відкат — теж. Без нього перше виділення — це зміна в кожному викликачі, а відкат — ще одна зміна в кожному викликачі. Книжка Сема Ньюмана «Monolith to Microservices» (2019) збирає strangler fig і ще п’ять споріднених патернів для перенесення коду, і кожен пасує до своєї ситуації:

Branch by abstraction: шов усередині коду

Фасад бачить лише те, що перетинає край системи. Багато з того, що ви хочете виділити, викликають зсередини — функцію ціноутворення, якою користуються оформлення замовлення, рахунки й адмінка. Для цього випадку є branch by abstraction. Назву техніці дав Пол Геммант, коли обстоював розробку в trunk, а саму ідею він приписує Стейсі Керлу; кроки Фаулер описав у січні 2014 року. Поставити інтерфейс перед старим кодом. Перевести на інтерфейс кожного викликача, по одному. Збудувати нову реалізацію за тим самим інтерфейсом — тут це клієнт, що викликає новий сервіс. Перемикати викликачів прапорцем. Коли старою реалізацією вже ніхто не користується, видалити її, а згодом і інтерфейс, якщо він більше не виправдовує себе. Кожен коміт на цьому шляху лишає систему такою, що збирається й готова до релізу, тож жодну довгоживучу гілку зливати не доводиться.

Паралельний запуск: довести новий код, перш ніж йому довіряти

Переписаний код вартий рівно стільки, наскільки точно він повторює стару поведінку, а її рідко хтось записував. Паралельний запуск (крок 10) вимірює її замість того, щоб вгадувати. Кожен запит або вибірка запитів іде в обидві реалізації. Користувач отримує стару відповідь. Нову порівнюють із нею, і кожну різницю записують із достатнім контекстом для налагодження. GitHub збудував для цього бібліотеку Scientist і описав, як із нею замінював код, що зливає pull requestpull requestзміна, запропонована на рев’юЗапит на злиття однієї гілки в іншу, де зміну переглядають, обговорюють і перевіряють пайплайном, перш ніж вона потрапить у головну гілку; у GitLab те саме зветься merge request. Його ціна — очікування: pull request, що днями чекає на рев’ю, і породжує довгоживучі гілки та болісні злиття.Докладніше в статті →Усі терміни. Після чотирьох днів виправлення того, що знайшов експеримент, — зокрема функції, якої в новому рушії злиття не було взагалі, — новий код 24 години обробляв 100% запитів без жодного розходження й жодного повільного випадку. До вимкнення старого шляху перевірили десятки мільйонів злиттів. Khan Academy робив те саме на краю своєї системи й називав це тестуванням пліч-о-пліч: шлюз надсилав більшість трафіку запиту в моноліт, а частину — в нові сервіси, і результати порівнювали, доки не виправили кожну різницю.

Поділ даних — сама міграція

Виділити код — тиждень роботи. Виділити дані — це і є міграція. Саме тут команди, що пропустили цей розділ, опиняються з двома сервісами на одній базі — тим результатом, якого вся вправа мала уникнути. Ньюман описує три порядки: спершу розділити базу, спершу розділити код або все одразу. Від «усе одразу» він застерігає. З його досвіду, найпоширеніший — спершу код, бо він раніше дає результат. Його звичний провал на практиці — зупинитися на цьому, коли новий сервіс досі читає таблиці моноліту.

Шістнадцять кроків оминають обидві пастки, переносячи по одній речі за раз. Поділ починається всередині моноліту, де він дешевий (кроки 6–7). Розділіть таблиці модуля логічно: та сама база, власна схема, жодних JOIN і зовнішніх ключів через межу. Уже це виявляє кожну приховану залежність, бо кожен перетин тепер валить перевірку, і кожен виправляють, поки стара система працює. Потім дані копіюють і тримають синхронними (9), переводять читання (10–11), переводять запис (12), переводять останніх читачів (13) — і лише тоді щось видаляють (14).

GitHub зробив саме це у великому масштабі між 2019 і 2021 роками — на кластері бази, де жили користувачі, репозиторії, issues і pull request. Спершу з’явилися віртуальні розділи. Таблиці, що належать разом, згрупували в домени схеми, перелічені в простому YAML-файлі в застосунку на Rails. Групи забезпечували два лінтери: один валив будь-який запит, що звертався до таблиць двох доменів, інший — будь-яку транзакцію, що їх охоплювала. Наявні порушення позначили як винятки, і це перетворило їх на видимий беклог. Домен, у якому не лишилося винятків, був готовий до переїзду. Фізичне перенесення робили через Vitess або через власне перемикання на реплікації MySQL, що переводило запис за кілька десятків мілісекунд у найтихішу годину доби; одне таке перемикання перенесло 130 найнавантаженіших таблиць одразу. 2019 року кластер відповідав на 950 000 запитів на секунду. 2021 року ті самі таблиці, розподілені між кількома кластерами, відповідали на 1 200 000 — а середнє навантаження на кожен хост зменшилося вдвічі.

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

Саме на звітах зазвичай з’ясовується, що поділ даних не завершено (крок 13). Звіт, що поєднує таблиці шести модулів, роками працював, бо все лежало в одній базі. Після поділу чесних відповідей дві. Або звіт викликає сервіси, що володіють даними, або читає аналітичну копію, яку живлять події чи журнали бази. Ньюман радить окрему схему, збудовану для звітності, а не запити до робочих сховищ. Хай там як, знайдіть кожного читача до кроку 14. Той один щомісячний експорт, про який ніхто не пам’ятав, — класична причина відкату першого числа.

Модель і команди: прошарок проти псування й закон Конвея

Новому сервісу знадобляться дані старої системи, а модель старої системи зазвичай сформована п’ятнадцятьма роками випадковостей. Якщо новий сервіс говорить цією моделлю, він успадковує її назавжди, і виділяти його майже не було сенсу. Ерік Еванс назвав захист від цього в книжці «Domain-Driven Design» 2003 року: прошарок проти псування (anti-corruption layer). Це межа перекладу — тонкий шматок коду, що з одного боку говорить старою моделлю, а з іншого — моделлю нового сервісу, і належить новому сервісу. Він навмисно потворний, навмисно ізольований і навмисно тимчасовий. Коли старе джерело нарешті зникне, ви видалите один компонент, а не виколупуватимете модель із кожного файлу. Ось що він зазвичай перекладає:

Мелвін Конвей 1968 року помітив, що структура системи зрештою віддзеркалює структуру комунікації організації, яка її будувала. У міграції це не курйоз, а найсильніша сила в кімнаті. Якщо виділеним сервісом спільно володіють чотири команди, у ньому виростуть чотири внутрішні фракції й координаційна нарада, і він не деплоїтиметься незалежно, хоч би що казала схема. Застосована свідомо, та сама сила стає інструментом. Джонні Лерой і Метт Сімонс 2010 року назвали це зворотним маневром Конвея (inverse Conway maneuver): змініть межі команд на ті, які ви хочете бачити в сервісів, і архітектура піде слідом.

Він також задає чесну верхню межу міграції. Не можна отримати більше сервісів, ніж є команд, щоб ними володіти, а сервіс, яким не володіє ніхто, гниє в розподіленій системі швидше, ніж будь-коли гнив у моноліті. Тому крок 3 свідомо містить графік чергувань. Команда-власник експлуатує новий сервіс із дня, коли він отримав перший запит, — правило Amazon, словами Вернера Фогельса: «You build it, you run it».

Як вести міграцію: потужність, темп і коли зупинитися

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

Не давайте старому коду рости, поки ви його переносите. Правило Khan Academy під час переписування: кожну нову фічу в старому коді на Python мала особисто погодити людина, що очолювала інженерію, бо кожен новий рядок — це ще один рядок для перенесення. Той самий проєкт міряв прогрес тим, що переїхало, а не тим, що збудовано: часткою трафіку, яку обслуговує новий бекенд, кількістю готових полів APIAPIApplication Programming Interface — контракт між програмамиПравила, за якими одна програма звертається до іншої: які запити можна надіслати, у якому вигляді й що прийде у відповідь. Для того, хто звертається, це контракт — усе, що за ним, лишається чорною скринькою, і саме тому другий бік можна переписати, не зламавши вас.Докладніше в статті →Усі терміни та обсягом, що зростав, коли роботу краще розуміли. Таблиця перелічує заміри, що відрізняють робочу міграцію від тієї, що застрягла.

Ніщо в цьому патерні не вимагає, щоб моноліт зник, а перетворення його зникнення на мету — це те, як міграція переживає власне обґрунтування. Кожне виділення обґрунтовувалося обмеженням. Коли решта частин нічого не блокує, за рештою виділень немає жодного аргументу, крім симетрії. Постійний гібрид — кілька сервісів навколо добре модуляризованого ядра, у якому досі лежить більша частина предметної області, — поширений і цілком гідний кінцевий стан. У більшості організацій це ще й точка найкращої віддачі: частини зі справжньою потребою в незалежності її мають, а решта не платить за мережу, яка їй ніколи не була потрібна. Інженери SoundCloud 2015 року сказали те саме: дещо з того, що робив моноліт, було таким малим і стабільним, що його, можливо, дешевше лишити там назавжди.

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

П’ять кейсів і те, чого в кожному бракувало

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

Історія Amazon — та, з якої взявся сам словник. В інтерв’ю 2006 року Вернер Фогельс описав Obidos — застосунок, що від заснування компанії тримав усю бізнес-логіку й логіку відображення Amazon. Роками зусилля з масштабування йшли в бази за ним, доки 2001 року не перестав масштабуватися сам фронтенд. Глибша проблема була в спільності. Бази ділили багато команд і процесів, тож ніщо не мало ізоляції й ніщо не мало чіткого власника, і застрягли і фронтенд, і бекенд. Відповіддю стала сервісно-орієнтована архітектура з одним правилом над усіма іншими: дані інкапсульовано разом із логікою, що з ними працює, доступ до них — лише через опублікований інтерфейс сервісу, без прямого доступу до бази ззовні. Вона розрослася до сотень сервісів. Перечитайте це правило й зверніть увагу, про що воно мовчить. Воно нічого не каже про те, яким малим має бути сервіс. Обмеженням була власність — і виправленням теж.

Netflix почав у серпні 2008 року, коли серйозне пошкодження бази на три дні позбавило його змоги відправляти DVD. Урок, який він виніс, — піти від вертикально масштабованих єдиних точок відмови, як-от однієї реляційної бази у власному дата-центрі. Він вирішив не переносити наявні системи в хмару без змін, бо так переїхали б і всі старі проблеми. Натомість перебудував: від монолітного застосунку до сотень мікросервісів, з денормалізованою моделлю даних на NoSQLNoSQLбази даних поза SQL-таблицямиПарасолькова назва для баз даних, що не зберігають реляційних таблиць із запитами мовою SQL: сховищ «ключ — значення», документних, ширококолонкових і графових. Більшість із них розміщує кожен запис на машині за ключем, обраним під час проєктування, тож запити з цим ключем дешеві за будь-якого обсягу, а більшість інших — дорогі або неможливі.Докладніше в статті →Усі терміни-сховищах. Усі системи, що працюють із клієнтами, переїхали до 2015 року. Білінг і дані клієнтів забрали час після цього, а останні частини дата-центру вимкнули на початку січня 2016 року — через сім років після старту. Найдовше тривали не сервіси. Найдовше тривали дані, до яких прив’язані найсуворіші правила.

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

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

• Повне переписування поруч із живою системою: увесь ризик приходить в один день, а стара система тим часом рухається далі.
• Немає названого обмеження, тож успіх рахують створеними сервісами (крок 1).
• Код виділено, а базу лишено спільною — розподілений моноліт із додатковими кроками (кроки 9–14 пропущено).
• Почати з найскладнішої центральної можливості — команда вчиться механіки там, де помилки коштують найдорожче (крок 2).
• Немає фасаду, тож кожне виділення й кожен відкат — це зміна в кожному викликачі (крок 4).
• Виділення, що тягнуться місяцями й перестають бути зворотними, бо моноліт під ними їде вперед.
• Подвійний запис без звірки — сховища тихо розходяться.
• Паралельний запуск, який ще й виконує побічні ефекти, подвоюючи те, що мав спостерігати (крок 10).
• Новий сервіс говорить старою моделлю даних — і завозить у себе той безлад, від якого тікав.
• Старі таблиці видалено до того, як переїхав кожен читач, — і це виявляє щомісячний звіт (кроки 13–14).
• Нові фічі досі приземляються в старому коді, тож обсяг перенесення росте швидше за саме перенесення.

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

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

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

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

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