Мікросервіси

Що додає мережа — шістнадцять проблем, патерн для кожної і його ціна

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

Що робить сервіс мікросервісом — дев’ять характеристик і та одна, що визначає

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

Термін визначили 25 березня 2014 року, коли Джеймс Льюїс і Мартін Фаулер описали «підхід до розробки одного застосунку як набору невеликих сервісів, кожен з яких працює у власному процесі й спілкується через легкі механізми». Формального визначення вони не дали. Натомість перелічили дев’ять характеристик, які зазвичай мали спільними системи, що вони бачили. Більшість пояснень цей список пропускає, і дарма, бо кожен пункт називає спосіб, яким стиль ламають на практиці. Ось усі дев’ять у їхньому порядку:

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

Що потрібно мати до другого сервісу

28 серпня 2014 року Мартін Фаулер опублікував короткий список того, що потрібно команді, перш ніж будувати мікросервіси, і анонсував його фразою «You must be this tall to use microservices» — як табличка зі зростом біля атракціону. У списку чотири пункти. Жоден не екзотичний, і один застосунок може роками жити без будь-якого з них. Двадцять сервісів без них не протягнуть і тижня. Ось вони — з перевіркою, яку можна провести у своїй команді сьогодні:

За дев’ять місяців Фаулер назвав ціну, що стоїть за цим списком: мікросервісна премія. Автоматизований деплой, моніторинг, обробка збоїв і узгодженість «з часом» — це робота, якої моноліт не потребує, і вона починається ще до появи будь-якої користі. Тож проста система як мікросервіси менш продуктивна, і лише після певного рівня складності стиль окуповує себе. Висновок у нього був різкий: «навіть не розглядайте мікросервіси, якщо у вас немає системи, надто складної, щоб керувати нею як монолітом». Сторінка про моноліт показує, що спробувати до цієї точки, а сторінка «Моноліт → мікросервіси» — як рухатися, коли ви вже за нею.

Дані між сервісами: без JOIN і без спільних транзакцій

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

Саги: транзакція, яку ви пишете самі

Розподілені транзакції існують. У двофазній фіксації (two-phase commit) координатор просить кожного учасника підготуватися, а потім зафіксувати зміни, і бази даних підтримують це десятиліттями. Між сервісами її використовують рідко, з трьох причин. Кожен учасник, зокрема брокер повідомлень, мусить її підтримувати, а багато хто не підтримує. Учасники тримають блокування, поки чекають. А якщо координатор відмовить не в той момент, вони лишаються заблокованими, доки він не повернеться. Тож звична відповідь старша й простіша. Гектор Гарсія-Моліна й Кеннет Салем описали її 1987 року для довгих транзакцій усередині однієї бази й назвали сагою (saga).

Сага — це послідовність локальних транзакцій. Кожна фіксується у своєму сервісі й запускає наступну. Кожен крок, який можна скасувати, має компенсаційний крок, що його скасовує, — не відкат, а нову дію з протилежним бізнес-змістом. Сага замовлення створює замовлення в стані «очікує», резервує товар, списує гроші з картки, потім підтверджує. Якщо банк відхилив оплату, сага йде назад: знімає резерв і позначає замовлення відхиленим. Книжка Кріса Річардсона «Microservices Patterns» дає порядку кроків корисний словник. Спершу йдуть кроки, які можна компенсувати. Потім — опорний крок (pivot), після якого сага рухається лише вперед. Кожен крок після нього треба повторювати, доки він не вдасться.

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

Outbox: зберегти й опублікувати як один крок

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

Transactional outbox прибирає цей розрив. Сервіс записує подію в таблицю outbox у власній базі, у тій самій транзакції, що й саме замовлення. Або фіксуються обидва рядки, або жоден. Окремий ретранслятор потім читає outbox і публікує кожну подію. Він може опитувати таблицю або читати власний журнал змін бази — захоплення змін даних (change data capturechange data captureпотік змін із журналу базиПотокова передача кожної вставки, зміни й видалення з власного журналу змін бази в інші системи, як це роблять інструменти на кшталт Debezium. Вона тримає другу копію синхронною без того, щоб застосунок писав двічі, ціною прив’язки кожного споживача до структури таблиць джерела.Усі терміни), підхід, який використовують інструменти на кшталт Debezium. Ретранслятор може впасти після публікації й до того, як позначить подію надісланою, тож іноді він опублікує її двічі. Саме тому існує рядок 10: кожен споживач записує id оброблених подій і ігнорує повтор.

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

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

Кожен виклик між сервісами може бути повільним, може впасти або — найгірше з трьох — може вдатися на тому боці, повернувши вам помилку. Синхронний виклик ще й зв’язує доступність. Припустімо, запит проходить через шлюз, далі замовлення, далі білінг, далі реєстр. Якщо кожен доступний 99,9% часу — це близько 43 хвилин простою на місяць, — то ланцюг доступний 99,6%, тобто майже три години на місяць. Це гірше за будь-який компонент у ньому й гірше за моноліт, що робив ту саму роботу в одному процесі.

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

Почніть із таймауту (рядок 1), бо без нього не працює ніщо інше: викликач без таймауту тримає потік, доки залежність не відповість, а мертва залежність не відповідає ніколи. Практика Amazon, як її описує Марк Брукер, — обрати прийнятну частку хибних таймаутів, скажімо 0,1%, і поставити таймаут на відповідному перцентилі затримки викликаного — у цьому випадку на 99,9-му. Передавайте залишок часу далі вниз як дедлайн. Інакше сервіс за п’ять переходів униз і далі працює для викликача, який давно здався.

Повтори (рядок 2) — місце, де добрі наміри перетворюються на аварії. Повтор допомагає зі збоєм, що не повториться, як-от перезапущений екземпляр. Проти перевантаженого сервісу він додає навантаження саме тоді, коли навантаження і є проблемою. Повтори ще й множаться. Приклад Брукера — запит, що проходить стеком із п’яти сервісів, із трьома спробами на кожному рівні. Якщо база внизу почне падати під навантаженням, вона отримає 3 × 3 × 3 × 3 × 3 = 243 запити на кожен запит клієнта. Правило Amazon — повторювати лише в одній точці стеку, з експоненційною затримкою (exponential backoffbackoffдедалі довша пауза між повторамиПауза перед повтором невдалого виклику, що зростає після кожного збою, — наприклад, 1, 2, 4 і 8 секунд, — зазвичай із випадковою добавкою (jitter), щоб багато клієнтів не повторювали в одну мить. Без неї повтори приходять саме тоді, коли сервіс, якому й так важко, найменше може їх собі дозволити.Усі терміни) та джитером: паузи ростуть і мають випадкову складову, тож клієнти не повторюють у такт.

Обмеження на повтори не дає поганій годині стати поганим днем. Книжка Google про SRE описує два. Кожен запит отримує щонайбільше три спроби. А кожен клієнт стежить, яку частку його запитів становлять повтори, і припиняє повторювати, щойно ця частка сягає 10%. У найгіршому сценарії Google саме перше правило ще дозволяє трафіку вирости майже втричі; обидва разом тримають зростання на рівні приблизно 1,1 раза. Ту саму роботу виконує відро токенів (token bucket) на кожному клієнті, і AWS вбудував його у свої SDKSDKSoftware Development Kit — готовий набір для платформиЗібраний набір бібліотек, інструментів і прикладів для роботи з чужою платформою. Відмінність від API в тому, що API лише описує правила, а SDK дає код, який уже вміє за цими правилами говорити.Усі терміни ще 2016 року.

Запобіжники (рядок 3) — найвідоміша відповідь, і про них сперечаються найбільше. Майкл Найгард назвав запобіжник (circuit breaker) і переборку (bulkhead) у книжці «Release It!» 2007 року. Запобіжник рахує збої і, щойно вони перетинають поріг, на певний час припиняє виклики залежності й натомість швидко повертає помилку. Бібліотека Hystrix від Netflix, відкрита 2012 року, зробила обидва патерни стандартом у світі Java. 19 листопада 2018 року Netflix перевів Hystrix у режим підтримки на версії 1.5.18. Фокус компанії змістився на адаптивні ліміти паралельності, що реагують на виміряну затримку, а не на пороги, задані вручну, і нові проєкти вона скерувала до resilience4j. Amazon у власних настановах іде далі. Запобіжники додають другий режим поведінки, який важко тестувати, пише Брукер, і можуть суттєво подовжити відновлення. Amazon натомість обмежує повтори локальним відром токенів.

Останній рядок — те, про що ніколи не попереджають джуніорів і на чому обпікся кожен сеньйор (рядок 5). Мережевий збій не каже, чи сталася операція: виклик міг пройти, а загубилася лише відповідь. Тож будь-який повтор будь-чого, що змінює стан, має бути безпечним, а отже, отримувач мусить упізнавати запит, який уже обробив. Клієнт надсилає з запитом унікальний ключ ідемпотентності (idempotency keyidempotency keyid запиту, що робить повтор безпечнимУнікальне значення, яке клієнт надсилає із запитом, що щось змінює, — платежем, замовленням, — щоб сервер упізнав повтор і повернув перший результат, а не діяв двічі. Сервер мусить зберігати ключі й вирішувати, скільки їх тримати; повтор, що прийшов після того, як його ключ прибрали, вважають новим запитом.Докладніше в статті →Усі терміни); отримувач зберігає ключ разом із результатом і на повтор повертає збережений результат. Повтори без ідемпотентності — це не стійкість. Це машина для дублювання побічних ефектів.

Експлуатація багатьох сервісів: трасування, виявлення, шлюзи й сітка

З одним сервісом запит, що впав, лишає один стектрейс. З багатьма — уривки у восьми наборах логів, і нічого їх не з’єднує, якщо ви цього не запланували (рядок 15). Рішення — id трасування, створений на вході й переданий з кожним викликом, щоб кожен рядок логу й кожен замір часу можна було згрупувати за запитом. Переносним це роблять два стандарти. W3C Trace Context, рекомендація W3C з лютого 2020 року, визначає заголовок traceparent, що переносить id між сервісами. OpenTelemetryOpenTelemetryнезалежний від вендора стандарт телеметріїВідкритий проєкт, що визначає, як застосунки створюють і надсилають траси, метрики й логи, — бібліотеки, формат даних і протокол, — щоб інструмент, який їх зберігає й показує, можна було змінити без повторного інструментування коду. У травні 2026 року він отримав статус graduated у Cloud Native Computing Foundation. Він стандартизує, як збирати телеметрію, а не те, що варто збирати.Усі терміни дає бібліотеки й протокол, щоб збирати траси, метрики й логи без прив’язки до одного постачальника; 11 травня 2026 року проєкт отримав статус graduated у Cloud Native Computing Foundation. Uber описав, чого коштує відсутність трасування: одне розслідування означало пройти близько 50 сервісів дванадцяти команд, щоб знайти першопричину.

Виявлення сервісів (рядок 12) — адресна книга, що дозволяє сервісам знаходити одне одного, поки екземпляри з’являються й зникають. У Kubernetes його дає платформа через DNS; деінде — реєстр на кшталт Consul. Хай там як, це тепер те, від чого залежить кожен виклик, і воно заслуговує на таку саму турботу, як база даних. Roblox засвоїв це за 73 години в жовтні 2021 року — це один із п’яти кейсів нижче.

Шлюз (рядок 13) дає клієнтам одну точку входу замість двадцяти. Його ризик — гравітація: автентифікація, потім правила маршрутизації, потім трохи бізнес-логіки, доки шлюз знову не стане монолітом. Четверта характеристика Льюїса й Фаулера — розумні кінцеві точки, тупі труби — це перевірка, якої слід його тримати. Корисний варіант з’явився в SoundCloud, і 2015 року його описав Сем Ньюман: окремий бекенд для кожного фронтенду, або BFF. Мобільний застосунок і вебсайт отримують кожен тонкий бекенд, яким володіє команда цього клієнта, тож потреби жодного з клієнтів не гнуть спільний API.

Сервісна сітка (рядок 14) виносить із коду в проксі шифрування між сервісами, повтори, таймаути й метрики. Класичні сітки ставлять проксі поруч із кожним сервісом як sidecar; режим ambient в Istio, загальнодоступний із версії 1.24 у листопаді 2024 року, натомість запускає спільний проксі на кожному вузлі. Користь — однаковість для всіх мов. Ціна — друга розподілена система, яку треба експлуатувати й оновлювати, і пастка, яку варто назвати: якщо повторює сітка і повторює застосунок, ви збудували множильний стек із рядка 2, не написавши жодного рядка коду. Вирішіть, який рівень володіє повторами, і вимкніть їх на іншому.

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

Сервіси й команди, що ними володіють

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

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

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

Історія Monzo починається як безпековий проєкт, а закінчується уроком про знання. У листопаді 2019 року безпекова команда банку хотіла, щоб сервіс, який керує зображеннями на «скарбничках», не міг звертатися до сервісу, що переказує гроші. З кількома сервісами список дозволів можна вести вручну. У Monzo їх було понад 1500, між ними — понад 9300 унікальних з’єднань, і список змінювався щодня. Ні в кого його не було. Тож команда написала rpcmap — інструмент, що читає Go-код кожного сервісу й знаходить виклики, які той робить до інших. Він генерує окремий файл правила на кожен викликаний сервіс і перевіряє ці файли на кожному push, а власники критичних сервісів можуть вимагати перегляду кожного нового викликача. Першим закрили реєстр. Урок ширший за безпеку: у великій системі сервісів справжній граф залежностей живе лише в коді, доки інструмент його не витягне, а без цього графа на рядок 16 не відповісти.

Uber — та сама проблема в більшому масштабі. До липня 2020 року компанія мала близько 2200 критичних мікросервісів, і її інженери прямо описали ціну. Сервіси стали чорними скриньками, чия поведінка могла змінитися будь-коли. Виклики йшли на багато рівнів углиб, тож сплеск затримки в одній залежності каскадом ішов угору. Пошук однієї першопричини вимагав пройти близько 50 сервісів, якими володіли 12 команд. Відповідь — Domain-Oriented Microservice Architecture — не злила сервіси. Вона їх згрупувала: пов’язані сервіси утворюють домен, домени утворюють шари, що обмежують, хто від кого може залежати, а до кожного домену звертаються через один шлюз. Uber розклав свої 2200 сервісів по 70 доменах і повідомив, що підключення нової фічі до платформи стало на 25–50% швидшим. Ще одне число з тексту варто запам’ятати: Uber виміряв період напіврозпаду мікросервісу — 1,5 року. Половину з них замінювали кожні півтора року, і шлюзи не давали кожній заміні стати міграцією для її викликачів.

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

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

• Спільна база даних, що перетворює набір сервісів на розподілений моноліт (рядок 7).
• Сервіси, названі за технічними шарами: кожна фіча зачіпає всі, і ніщо не виходить окремо.
• Релізи, що вимагають випуску кількох сервісів у фіксованому порядку, — це і є визначення відсутньої незалежності.
• Довгі ланцюги синхронних викликів, де доступність множиться вниз — нижче, ніж була в моноліті.
• Повтори на кожному рівні — у клієнті, у бібліотеці й у сітці, — що множаться в шторм (рядок 2).
• Повтори без ключів ідемпотентності, що дублюють побічні ефекти саме за тих умов, заради яких повтори існують (рядок 5).
• Код «зберегти, потім опублікувати» без outbox, що губить подію щоразу, коли процес помирає не в той момент (рядок 9).
• Саги, у яких ніхто не спитав, що бачить паралельний запит посеред процесу (рядок 8).
• Шлюз, що оброс бізнес-логікою, тож він знову моноліт — лише з додатковим переходом.
• Один сервіс на розробника, що дає топологію, яка відображає найм, а не предметну область.
• Відсутність розподіленого трасування, що перетворює кожен міжсервісний інцидент на археологію (рядок 15).

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

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

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

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

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