پشته معاملاتی مدرن

پایگاه داده های تراکنش از دیرباز حیاتی ترین جزء طراحی اپلیکیشن بوده اند. چرا؟ از آنجا که یک پایگاه داده استوار به طور کلی نقطه اجرایی نهایی برای صحت در یک دنیای آشفته و توزیع شده است. بدون آنها ما اضافه پرداخت و هزینه کمتری دریافت می کردیم. سوارکارانی را که می‌خواستند از فرودگاه به خانه برسند، گم می‌کردیم، و اقلامی را در سبد خریدمان گم می‌کردیم. حساب‌های آنلاین ما گم می‌شوند، تکراری می‌شوند یا خراب می‌شوند و از کار می‌افتند. 

در واقع، پایگاه داده تراکنشی (که عموماً OLTP - مخفف پردازش تراکنش آنلاین - پایگاه داده نامیده می شود) آنقدر برای توسعه برنامه کاربردی بوده است که با گذشت زمان، عملکرد برنامه های کاربردی بیشتر و بیشتری را مصرف می کند. با این حال، میکروسرویس‌ها و دیگر معماری‌های کاربردی مدرن، پیچیدگی‌های جدیدی را در طراحی برنامه‌ها ایجاد کردند: توسعه‌دهندگان نیاز به مدیریت داده‌ها در سرویس‌های مختلف و اطمینان از سازگاری بین آنها داشتند، که آنها را مجبور کرد تا مکانیزم‌های همگام‌سازی و پردازش داده‌های پیچیده را در داخل بسازند. 

و بنابراین، به عنوان یک صنعت، ما شاهد افزایش آگاهی هستیم که ضمانت های معاملاتی خارج از مدل سنتی مورد نیاز است. ما داریم می بینیم ظهور سیستم هایی که تضمین های تراکنش قوی را فراتر از پایگاه داده، به خود برنامه های توزیع شده گسترش می دهند. 

ما در چند سال گذشته این راه حل ها را دنبال کرده ایم. به طور کلی، آنها تلاش می کنند تا امکان مدیریت تراکنشی حالت را در یک برنامه توزیع شده بزرگ، بدون ایجاد چالش های مقیاس بندی و در عین حال فراهم کردن یک محیط برنامه نویسی مدرن فراهم کنند. 

ما متوجه می شویم که این راه حل ها تقریباً به دو دسته تقسیم می شوند. یک دسته است ارکستراسیون گردش کار. این اساساً تضمین می کند که یک بلوک کد تا پایان کامل خواهد شد، حتی در صورت شکست. بنابراین می توان از آن برای مدیریت یک ماشین حالت توزیع شده به صورت قطعی و بدون افتضاح استفاده کرد. دسته دوم است پایگاه داده + گردش کار، که طراحی سنتی پایگاه داده OLTP را گسترش می دهد و امکان اجرای کد دلخواه را برای همان هدف فراهم می کند. 

این هنوز یک منطقه بسیار نوپا است و در مورد نامگذاری، نحوه استفاده از هر ابزار در عمل و اینکه چه کسی باید از آنها استفاده کند، سردرگمی زیادی وجود دارد. برای کمک به درک بهتر، از شاغلین سازمان‌های مهندسی پیشرو در مورد پشته تراکنش‌ها و اینکه چگونه به سه مفهوم کلیدی برای حجم کاری تراکنش فکر می‌کنند، پرسیدیم: وضعیت برنامه، منطق کسب‌وکار، و داده‌های تجاری. 

با این حال، قبل از بررسی این پشته های جدید، در اینجا یک انحراف نیمه فنی سریع برای کمک به درک چگونگی رسیدن به اینجا آورده شده است.

تراکنش ها، ضمانت ها و برنامه های مدرن 

نسخه بسیار خشن این است: مجموعه ای از کارها - تراکنش ها - وجود دارد که یا می خواهید همه آنها را انجام دهید یا هیچ کدام. هر کاری در این بین (اگر تا حدی انجام شود) به یک وضعیت فاسد ختم می شود. تضمین کردنش سخته هر چیزی در یک سیستم توزیع شده، اما پایگاه های داده این کار را با تراکنش ها به خوبی انجام می دهند. بنابراین، ساده‌ترین راه برای رسیدگی به ضمانت‌ها در بسیاری از سیستم‌ها این است که فقط بیشتر موارد را انجام دهید و به پایگاه داده اجازه دهید آنها را مدیریت کند.

برنامه‌های مدرن سیستم‌های توزیع‌شده بزرگی هستند که تعداد زیادی از کاربران کارهای زیادی را انجام می‌دهند. بنابراین حتی ثابت نگه داشتن وضعیت برنامه (مانند ردیابی جایی که کاربران مختلف در جریان خروج هستند) به یک مشکل تراکنش توزیع شده تبدیل می شود. در معماری های یکپارچه سنتی، مدیریت تراکنش ها با استفاده از SQL با پایگاه داده OLTP تا حدودی موثر بود. اما در دنیای جدید و پیچیده ریز سرویس‌ها که از طریق APIهای سطح بالاتر (مانند REST یا gRPC) در تعامل هستند، نیازهای تراکنشی در طبیعت توزیع شده‌اند. 

با این حال، بسیاری از شرکت‌هایی که در سفر به میکروسرویس‌ها هستند، کار زیادی برای گسترش ضمانت‌های تراکنش قوی فراتر از پایگاه داده انجام نداده‌اند. و در عمل همینطور است تقریبا همیشه خوب. اما با گسترش برنامه‌ها، ناهماهنگی‌ها در داده‌ها افزایش می‌یابد، و همچنین اشکالات ناشی از آن و خطاهای تطبیق‌نشده در داده‌های تجاری افزایش می‌یابد. که البته می تواند بسیار مشکل ساز باشد. این امر توسعه دهندگان برنامه را مجبور می کند تا با طیف گسترده ای از سناریوهای شکست و استراتژی های حل تعارض مقابله کنند و با ارائه استراتژی های خود از طریق الگوهای معماری مختلف، سازگاری حالت را تضمین کنند.

تعاریف داده های کسب و کار ("داده") به داده های حیاتی تجاری که به طور سنتی در پایگاه داده OLTP برای تداوم و پردازش ذخیره می شود (مثلا اطلاعات نمایه کاربر مانند نام، آدرس، امتیاز اعتباری و غیره) اشاره دارد. وضعیت برنامه به وضعیت فعلی سیستم اشاره دارد. وضعیت برنامه توسط یک مقدار ذخیره شده در یک سیستم ذخیره سازی داده تعیین می شود و اجرای برنامه در کدام مرحله در یک ماشین حالت محدود است (به عنوان مثال وضعیت یک سفارش، مانند "سفارش دریافت شده"، "موجودی بررسی شده"، "اعتبار بررسی شده است" , "ارسال شد" "بازگشت"). منطق تجارت به بخشی از برنامه اشاره می‌کند که به جای جزئیات اجرا، به این بخش از برنامه می‌پردازد که برنامه واقعاً چگونه کار می‌کند یا چه کاری انجام می‌دهد (مثلاً «اگر user_income > 100K دلار و امتیاز اعتبار > 650 ⇒ mortgage_approved = TRUE»).

برای اهداف این بحث، تشخیص وضعیت برنامه و داده های تجاری مهم است. به عنوان مثال، دانستن اینکه مشتری کارت اعتباری خود را وارد کرده است اما آن را چک نکرده است، وضعیت درخواست است. داده‌های کارت اعتباری و موارد موجود در سبد خرید، داده‌های تجاری هستند. 

در یک جریان معمولی، یک درخواست از front-end می آید، احراز هویت می شود، و سپس از طریق یک دروازه API یا GraphQL به نقطه پایانی مربوطه هدایت می شود. 

آن نقطه پایانی API واحد اکنون باید ده‌ها یا صدها ریزسرویس را برای ارائه تراکنش تجاری به مشتری نهایی تنظیم کند. اینجاست که توسعه‌دهندگان معمولاً همه چیز را در حباب‌های منطقی تجاری جمع می‌کنند، و سپس از ترکیبی از صف‌ها، کش‌ها و مکانیسم‌های رمزگذاری مجدد دستی برای دریافت داده‌ها به پایگاه داده استفاده می‌کنند - امیدواریم به عنوان یک تراکنش کامل انجام شود.

با افزایش مقیاس برنامه، پیچیدگی مدیریت صف‌ها و کش‌ها و همچنین تعداد لبه‌های تیز در منطق تطبیق در هنگام بروز مشکلات افزایش می‌یابد. 

ظهور پشته های تراکنش محور گردش کار و پایگاه داده محور

خوب، بنابراین تراکنش ها مهم هستند. LAMP در پایگاه داده برای مقیاس کافی نبود. و یک گلوله موی عظیم از صف ها و منطق امتحان مجدد خیلی شکننده است. برای مقابله با این موضوع، در چند سال گذشته شاهد ظهور راه‌حل‌های جدیدی بوده‌ایم که عقل را به منطق معامله بازمی‌گرداند. آنها را می توان تقریباً به عنوان رویکردهای گردش کار محور یا رویکردهای پایگاه داده محور طبقه بندی کرد.

تا به امروز، موتورهای گردش کار عمدتاً بر روی وضعیت برنامه کار می کنند تا داده های تجاری، و اغلب هنگام ادغام با پایگاه داده های سنتی به پیچیدگی خاصی نیاز دارند. رویکردهای پایگاه داده محور منطق برنامه را در کنار داده های تجاری اضافه می کنند، اما هنوز پیچیدگی اجرای کد مشابه موتورهای گردش کار را ندارند. 

نمودار زیر یک طرح تقریبی از نحوه استفاده از رویکردهای گردش کار و/یا پایگاه داده محور در یک برنامه Javascript/Typescript ارائه می دهد، با فرض اینکه هر دو مورد استفاده هستند. در حالی که امروزه آنها قطعات متمایز این معماری هستند، ما نشانه‌های اولیه روندی را دیده‌ایم که در آن پایگاه‌های داده ویژگی‌های گردش کار را ترکیب می‌کنند و جریان‌های کاری شروع به استفاده از ذخیره‌سازی بادوام کرده‌اند. این ادغام قابلیت ها نشان می دهد که خطوط بین این دو رویکرد در معماری های مدرن محو شده و کمتر متمایز می شود. 

رویکردهای گردش کار با جزئیات 

یک گردش کار به سادگی بلوک‌هایی از کد است که بر اساس رویدادها یا تایمرهایی اجرا می‌شوند که ماشین حالت برنامه را تکامل می‌دهند. گردش کار تراکنش اجرای کد را با ضمانت‌های قوی تضمین می‌کند و از وضعیت‌های جزئی یا ناخواسته در برنامه جلوگیری می‌کند. توسعه دهندگان منطق را می نویسند و موتور گردش کار تراکنش ها، جهش ها و عدم توانایی را مدیریت می کند. موتورهای گردش کار مختلف، مبادلات متفاوتی را از نظر میزان جزئیات تراکنش در معرض توسعه دهندگان ایجاد می کنند. 

به عنوان مثال، در زیر یک نمایش بصری از یک گردش کار در حال اجرا بر روی Orkes (Conductor) ارائه شده است: 

وجود دارد دو رویکرد خشن که توسط آن موتورهای گردش کار کشش را به دست می آورند. در یکی (که توسط Temporal.io مشخص می شود)، توسعه دهندگان با استفاده از زبان های برنامه نویسی استاندارد Back-end (مانند Go یا Java) کد می نویسند و سیستم از اجرای کد تا تکمیل شدن اطمینان حاصل می کند، حتی در هنگام شکست. در این مدل، پشته تماس برنامه حفظ می‌شود حتی اگر کد منتظر تکمیل تماس مسدودکننده باشد (مثلاً خواندن یا نوشتن). برای انجام این کار، زمان اجرا زبان برای جلوگیری از اجرای جزئی کد در هنگام خرابی اصلاح می شود. مزیت این رویکرد این است که توسعه‌دهندگان می‌توانند به زبان‌های آشنا بنویسند و با یک پشته تماس حفظ شده، به راحتی اشکال‌زدایی کنند. ما این رویکرد را در میان تیم‌های بک‌اند که با برنامه‌های بزرگ و پیچیده سروکار دارند، محبوب‌تر می‌بینیم. 

نقطه ضعف آن این است که اغلب به کار یکپارچه سازی و کد بسته بندی زیادی نیاز دارد تا رابط های مفید و ایمن را در اختیار توسعه دهندگان برنامه قرار دهد. نکته منفی دیگر این است که به جای زبان خالی به لایه اجرای سفارشی متکی است و موارد لبه ای وجود دارد که اجرا با زمان اجرا زبان اصلی متفاوت است. بنابراین، در حالی که توسعه‌دهندگان می‌توانند از زبان‌هایی که با آن‌ها آشنا هستند استفاده کنند، هنوز باید بدانند که سیستم زیربنایی چگونه کار می‌کند.  

روش دیگری که بیشتر در بین توسعه دهندگان برنامه (به ویژه Typescript/Javascript) محبوب است، این است که موتور گردش کار به عنوان ارکستراتور توابع ناهمگام عمل می کند (به عنوان مثال Inngest، Defer، و Trigger). در این مدل، رویدادها یا توابع شخص ثالث به موتور گردش کار هدایت می شوند، که سپس منطق ثبت شده توسط برنامه نویسان برنامه را ارسال می کند، که باید پس از ایجاد نیاز به مسدود کردن یک تابع غیر همگام دیگر، کنترل را برگردانند. نکته مثبت این است که این یک روش بسیار سبک وزن برای ادغام در یک برنامه است. همچنین ساختار کافی را بر روی کد تحمیل می کند که تیمی که روی آن کار می کند بتواند راحت تر آن را درک کند. با این حال، اشکال‌زدایی این رویکرد بدون پشتیبانی ابزار دشوارتر است، بنابراین اشکال‌زدایی معمولاً مختص پلتفرم است.

موتورهای گردش کار از این جهت قدرتمند هستند که امکان پذیرش تدریجی برنامه‌های موجود را فراهم می‌کنند. آنها را می توان به صورت تکه تکه در جریان های کاری خاص با حداقل ردپا اعمال کرد. با این حال، دو نقص بزرگ موتورهای گردش کار از این واقعیت ناشی می شود که آنها به پایگاه داده گسترش نمی یابند. در نتیجه، یک منبع منفرد و قابل پرس و جو از حقیقت در میان داده های وضعیت برنامه و کسب و کار وجود ندارد. همچنین، معنای تراکنشی به طور کلی با معنایی پایگاه داده متفاوت است، و به توسعه دهندگان برنامه نیاز دارد تا شرایط لبه را مدیریت کنند. 

اگرچه امروزه عادی نیست، اما می‌خواهیم معماری‌های مفهومی را نشان دهیم که چگونه گردش‌های کاری می‌توانند در بسیاری از موارد به‌عنوان ذخیره‌سازی داده‌های پایدار استفاده شوند:

رویکردهای پایگاه داده محور با جزئیات 

رویکردهای پایگاه‌محور با یک پایگاه داده شروع می‌شوند، اما آن را برای پشتیبانی از اجرای کد دلخواه گسترش می‌دهند تا امکان گردش کار در کنار مدیریت داده‌ها را فراهم کند. آنها این کار را با دادن کنترل به برنامه نویسان انجام می دهند تا بتوانند تصمیمات صریح در مورد جهش ها، تراکنش ها و عدم توانایی برای بلوک های کد معمولی بگیرند - اساساً با افشای مستقیم معنایی OLTP. برنامه نویس مسئول جدا نگه داشتن منطق تجاری و داده های تجاری از حالت برنامه است. 

در واقع، دیدگاه پایگاه داده خالص این است که وضعیت برنامه همیشه می تواند از داده های تجاری مشتق شود. این معمولاً با ذخیره سازی وضعیت برنامه به عنوان مجموعه ای از تراکنش ها انجام می شود که داده های تجاری را در پایگاه داده تغییر می دهد. ساده‌ترین کار این است که این را به‌عنوان پایگاه داده‌ای در نظر بگیرید که می‌تواند بلوک‌های کد را با همان تضمین‌های قوی مانند سیستم‌های گردش کار که در بالا توضیح داده شد، اجرا کند. 

در داخل، ما این را می نامیم پلت فرم تراکنش منطقی برنامه (ALTP) رویکرد، زیرا در نهایت، تراکنش های OLTP را به برنامه گسترش می دهد. اما چیزی که واقعاً ALTP را مشخص می کند این است که برای برنامه های Greenfield، می تواند به طور کامل نیاز توسعه دهندگان برنامه را برای مدیریت مستقیم زیرساخت های back-end برطرف کند.  

از لنز ALTP، متداول ترین رویکرد مورد استفاده با Firebase شروع شد، که ارائه می دهد خدمات کامل "تجربه پشتیبان"، از جمله اعتبار، ذخیره داده ها، پایگاه های داده و موارد دیگر. Firebase و شرکت‌های جدیدتر، مانند Supabase، پلتفرم‌های بسیار محبوبی برای پروژه‌های Greenfield هستند. و در حالی که آنها تمایل دارند به ریشه های OLTP خود وفادار بمانند - و بنابراین از اجرای کد دلخواه برای توابع پشتیبان تراکنش پشتیبانی نمی کنند - Supabase در حال حاضر شروع به اضافه کردن پشتیبانی برای گردش کار کرده است.

با این حال، ارائه های نسل بعدی ALTP مانند Convex اجازه اجرای کد دلخواه را به عنوان یک تراکنش در کنار پایگاه داده می دهد. این پیشنهادها امکان نوشتن کد کاملاً منطبق با تراکنش را در یک زبان معمولی (مثلاً جاوا اسکریپت/تایپ اسکریپت) فراهم می‌کند، جایی که یک بلوک کد می‌تواند داده‌ها را بخواند، بنویسد و تغییر دهد - هم وضعیت برنامه و هم داده‌های تجاری. به یک معنا، به توسعه‌دهندگان یک منبع پرس‌وجو از حقیقت می‌دهد و جریان‌های کاری اولیه مانند اشتراک‌ها را فراهم می‌کند. 

ALTP مشکل موتورهای گردش کار در جدا شدن از پایگاه داده را حل می کند، اما در نتیجه، کاربران را ملزم می کند که برای دریافت مزایا، به ارائه پایگاه داده خود به جای OLTP استاندارد تکیه کنند. در نتیجه، ما عمدتاً می‌بینیم که تیم‌ها ALTP را برای برنامه‌های سبز فیلد اتخاذ می‌کنند، به جای ادغام آن در backendهای موجود و پیچیده.

نمودار بالا ترکیبی از بسیاری از اپراتورهایی است که با آنها صحبت کردیم. برخی فقط از موتور گردش کار استفاده می کنند. برخی فقط از یک رویکرد پایگاه داده محور استفاده می کنند. اما بسیاری از آنها از هر دو استفاده خواهند کرد - به خصوص زمانی که تازه شروع به پذیرش گردش کار می کنند. کاربران موتورهای گردش کار امروزه تمایل دارند تیم‌های پشتیبان باشند که با برنامه‌های کاربردی بزرگ و پیچیده سروکار دارند، اگرچه ما شاهد استفاده از تیم‌های کامل پشته نیز بوده‌ایم. راه‌حل‌های Back-end-as-a-service تمایل بیشتری به برنامه‌نویس دارند و زمانی که برنامه انتخاب فناوری را هدایت می‌کند، بیشتر مورد استفاده قرار می‌گیرند. 

همگرایی

مشخص شده است که رویکردهای گردش کار محور و رویکردهای پایگاه داده محور در مسیر برخورد قرار دارند. دلیل اصلی این امر این است که در حالی که وضعیت برنامه و وضعیت پایگاه داده از نظر منطقی متمایز هستند، اما به یکدیگر وابسته هستند و سیستمی که هر دو را پوشش نمی‌دهد برای درست کردن و رفع اشکال پیچیده است.  

به عنوان مثال، یک موتور گردش کار را در نظر بگیرید که برای ردیابی ماشین وضعیت برای فرآیند پرداخت کاربر استفاده می شود و آن کاربر در حال افزودن یک کالا به یک سبد خرید است. به طور معمول، موتورهای گردش کار تضمین می کنند که یک مرحله کد حتی در صورت خرابی اجرا می شود. با این حال، ممکن است مواردی وجود داشته باشد که موتور نیاز به اجرای یک مرحله معین در هنگام خرابی داشته باشد، زیرا کاملاً مطمئن نیست که آیا مرحله به طور کامل تکمیل شده است یا خیر. اگر آن مرحله شامل نوشتن داده‌های کسب‌وکار در یک پایگاه داده سنتی (در این مورد، مورد موجود در سبد خرید) باشد و پایگاه داده از تلاش مجدد تکراری آگاه نباشد، در نهایت با یک ورودی تکراری ختم می‌شود. 

دو راه برای مقابله با این موضوع وجود دارد. یکی از راه‌ها این است که مشکل را به توسعه‌دهنده برنامه منتقل کنید، که از یک nonce ارائه شده توسط سیستم گردش کار استفاده می‌کند تا اطمینان حاصل کند که فقط یک مورد نوشته شده است. اما این فرض را بر این می‌گذارد که توسعه‌دهنده بی‌توانی را درک می‌کند، که برای درست کردن آن بسیار دشوار است، و این بسیاری از جادوی داشتن یک سیستم گردش کار را از بین می‌برد. راه دیگر این است که موتور گردش کار را به پایگاه داده ای متصل کنید که از معنای تراکنشی گردش کار آگاه است. این اتفاق هنوز کاملاً رخ نداده است، اما باورش سخت نیست. 

از سوی دیگر، رویکردهای پایگاه‌داده محور متوجه می‌شوند که گردش کار عمومی واقعاً برای توسعه‌دهندگان اپلیکیشن مفید است. و بنابراین ما شروع به دیدن پایگاه‌های داده (مانند Convex) کرده‌ایم - که از عملکردهای پایگاه داده سنتی مانند پرس و جو، جهش، فهرست‌ها و غیره پشتیبانی می‌کنند - عملکردهایی مانند زمان‌بندی و اشتراک‌ها را پیاده‌سازی می‌کنند. اینها به آنها اجازه می دهد تا به عنوان موتورهای گردش کار استفاده شوند. یعنی امکان اجرای بلوک های کد دلخواه با تضمین های قوی را می دهند. 

همانطور که یان لیوینگستون (که بازخورد خود را در مورد این قطعه ارائه کرد) بیان کرد:این کلاسیک "آیا منطق برنامه را به پایگاه داده می آورید یا پایگاه داده را به منطق برنامه؟" بازی دوباره ... این بار با شکستن یکپارچه به وجود آمد. با داشتن این دوگانگی برای چندین دهه، واضح است که هر دو مدل در کوتاه مدت باقی خواهند ماند. خیلی کمتر مشخص است که در درازمدت همینطور باقی خواهد ماند. 

تشکر ویژه از چارلی پلی (دفر)، دن فارلی (اینگست)، دیوید خورشید (استاتلی)، ایان لیوینگستون (کیپ سکیوریتی)، انس آکار (آپستاش)، جیمز کاولینگ (محدب)، جیمی ترنر (محدب)، پل کاپلستون (سوپا بیس) ، سم لمبرت (PlanetScale)، تونی هولدستاک-براون (اینجست)، مت ایتکن (تریگر) برای بررسی این پست و ارائه بازخورد. علاوه بر این، از Benjamin Hindman (Reboot)، فردریک Björk (Grafbase)، Glauber Costa (Chiselstrike)، Guillaume Salles (Liveblocks)، Maxim Fateev (Temporal)، استیون Fabre (Liveblocks) و Viren Baraiya (Orkes) برای کمک به ما تشکر می کنیم. تحقیق.

• محتوای مبتنی بر SEO و توزیع روابط عمومی. امروز تقویت شوید.
• پلاتوبلاک چین. Web3 Metaverse Intelligence. دانش تقویت شده دسترسی به اینجا.
• ضرب کردن آینده با آدرین اشلی. دسترسی به اینجا.
• منبع: https://a16z.com/2023/04/14/the-modern-transactional-stack/