Сучасний транзакційний стек

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

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

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

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

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

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

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

Транзакції, гарантії та сучасні додатки 

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

Сучасні програми — це великі розподілені системи з великою кількістю користувачів, які роблять багато речей. Таким чином, навіть збереження узгодженого стану програми (наприклад, відстеження того, де різні користувачі перебувають у процесі виписки) перетворюється на проблему розподіленої транзакції. У традиційних монолітних архітектурах керування транзакціями за допомогою SQL із базою даних OLTP було певною мірою ефективним. Але в новому, складному світі мікросервісів, які взаємодіють через API вищого рівня (наприклад, REST або gRPC), транзакційні потреби стали розподіленими за своєю природою. 

Однак багато компаній, які переходять на мікросервіси, не зробили багато для того, щоб розширити надійні гарантії транзакцій за межі бази даних. І на практиці це так майже завжди В ПОРЯДКУ. Але в міру масштабування додатків зростає невідповідність даних, а також пов’язані з цим недоліки та неузгоджені помилки в бізнес-даних. Що, звичайно, може бути дуже проблематичним. Це змушує розробників додатків мати справу з великою кількістю сценаріїв збоїв і стратегій вирішення конфліктів, а також забезпечувати узгодженість стану, створюючи власні стратегії за допомогою різних архітектурних шаблонів.

Визначення Бізнес-дані («дані») відноситься до критично важливих для бізнесу даних, які традиційно зберігаються в базі даних OLTP для збереження та обробки (наприклад, інформація профілю користувача, така як ім’я, адреса, кредитний рейтинг тощо). Стан програми відноситься до поточного стану системи; стан програми визначається значенням, що зберігається в системі зберігання даних, і кроком, на якому виконується програма в кінцевому автоматі (наприклад, стан замовлення, наприклад «замовлення отримано», «інвентаризація перевірена», «кредит перевірено» ”, “відправлено”, “повернено”). Бізнес-логіка відноситься до частини програми, яка стосується того, як програма насправді працює або що вона робить, замість деталей виконання (наприклад, «Якщо user_income > $100K & credit_score >650 ⇒ mortgage_approved = TRUE»).

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

У типовому потоці запит надходить із інтерфейсу, проходить автентифікацію, а потім направляється через шлюз API або GraphQL до відповідної кінцевої точки. 

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

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

Зростання стеків транзакцій, орієнтованих на робочий процес і базу даних

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

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

На діаграмі нижче наведено приблизний ескіз того, як підходи, орієнтовані на робочий процес і/або базу даних, використовуються в програмі Javascript/Typescript, припускаючи, що використовуються обидва. Хоча сьогодні вони є окремими частинами цієї архітектури, ми бачили перші ознаки тенденції, коли бази даних включають функції робочого процесу, а робочі процеси починають використовувати довговічне зберігання. Таке злиття можливостей вказує на те, що межі між двома підходами стираються і стають менш чіткими в сучасних архітектурах. 

Детально про підходи, орієнтовані на робочий процес 

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

Як приклад, нижче наведено візуальне представлення робочого процесу виписки, що працює на Orkes (Conductor): 

Існує два грубих підходи за допомогою яких двигуни робочого процесу отримують тягу. В одному (типовим типом якого є Temporal.io) розробники пишуть код, використовуючи стандартні серверні мови програмування (наприклад, Go або Java) і система забезпечить виконання коду до кінця, навіть під час збою. У цій моделі стек програмних викликів зберігається, навіть якщо код очікує завершення виклику блокування (наприклад, читання або запису). Для цього середовище виконання мови змінено, щоб запобігти частковому виконанню коду під час збоїв. Перевага цього підходу полягає в тому, що розробники можуть писати знайомими мовами та легко налагоджувати за допомогою підтримуваного стеку викликів. Ми бачимо, що цей підхід найбільш популярний серед бек-енд команд, які мають справу з великими, складними програмами. 

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

Інший підхід, більш популярний серед розробників додатків (зокрема, Typescript/Javascript), полягає в тому, щоб механізм робочого процесу служити оркестровником асинхронних функцій (наприклад, Inngest, Defer і Trigger). У цій моделі події або функції сторонніх розробників спрямовуються до механізму робочого процесу, який потім надсилає логіку, зареєстровану програмістами додатків, які мають повернути керування, коли виникає потреба заблокувати іншу асинхронну функцію. Перевагою є те, що це набагато легший метод інтеграції в програму. Це також забезпечує достатню структуру коду, щоб команда, яка над ним працює, могла легше його зрозуміти. Однак цей підхід може бути складнішим для налагодження без підтримки інструментів, тому налагодження, як правило, залежить від платформи.

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

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

Детально про підходи, орієнтовані на базу даних 

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

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

Внутрішньо ми називаємо це транзакційна платформа логіки додатків (ALTP) підхід, тому що, зрештою, він розширює транзакції OLTP у програмі. Але те, що справді характеризує ALTP, так це те, що для нових додатків він може повністю позбавити розробників додатків потреби безпосередньо керувати внутрішньою інфраструктурою.  

Від об’єктива ALTP найпоширеніший підхід почався з Firebase, який пропонує a повний спектр послуг, включаючи авторизацію, сховище даних, бази даних тощо. Firebase і нещодавні учасники, такі як Supabase, залишаються дуже популярними платформами для нових проектів. І хоча вони, як правило, залишаються вірними своїм кореням OLTP — і тому не підтримують виконання довільного коду для транзакційних внутрішніх функцій — Supabase вже починає додавати підтримку для робочих процесів.

Тим не менш, пропозиції ALTP наступного покоління як і Convex, вони дозволяють виконувати довільний код як транзакцію разом із базою даних. Ці пропозиції дозволяють писати повністю сумісний з транзакціями код звичайною мовою (наприклад, Javascript/Typescript), де один блок коду може читати, записувати та змінювати дані — як стан програми, так і бізнес-дані. У певному сенсі це дає розробникам єдине джерело істини, доступне для запитів, і забезпечує примітиви робочого процесу, такі як підписки. 

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

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

Конвергенція

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

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

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

З іншого боку, підходи, орієнтовані на базу даних, розуміють, що загальний робочий процес дійсно корисний для розробників програм. І тому ми починаємо бачити бази даних (наприклад, Convex), які підтримують традиційні функції баз даних, як-от запити, зміни, індекси тощо, реалізовуючи такі функції, як планування та підписки. Це дозволяє використовувати їх як двигуни робочого процесу. Тобто вони дозволяють виконувати довільні блоки коду з сильними гарантіями. 

Як сказав Ян Лівінгстон (який надав відгук про цей твір), «Знову грає класичне «Ви привносите логіку додатка в базу даних чи базу даних у логіку додатка?»... цього разу викликане руйнуванням моноліту». З огляду на таку дихотомію протягом десятиліть, очевидно, що обидві моделі збережуться в короткостроковій перспективі. Набагато менш ясно, що так і залишиться в довгостроковій перспективі. 

Особлива подяка Чарлі Полі (Defer), Дену Фарреллі (Inngest), Девіду Хоуршиду (Stately), Іану Лівінгстону (Cape Security), Енесу Акару (Upstash), Джеймсу Каулінгу (Convex), Джеймі Тернеру (Convex), Полу Копплстоуну (Supabase). ), Сему Ламберту (PlanetScale), Тоні Холдсток-Брауну (Inngest), Метту Ейткену (Trigger) за перегляд цієї публікації та надання відгуків. Крім того, дякуємо Бенджаміну Хіндману (Reboot), Фредріку Бьорку (Grafbase), Глауберу Кості (Chiselstrike), Гійому Саллесу (Liveblocks), Максиму Фатєєву (Temporal), Стівену Фабру (Liveblocks) і Вірен Барайя (Orkes) за допомогу дослідження.

• Розповсюдження контенту та PR на основі SEO. Отримайте посилення сьогодні.
• Платоблокчейн. Web3 Metaverse Intelligence. Розширені знання. Доступ тут.
• Карбування майбутнього з Адріенн Ешлі. Доступ тут.
• джерело: https://a16z.com/2023/04/14/the-modern-transactional-stack/