تراکنش‌های توزیع‌شده در معماری میکروسرویس: پایداری داده با الگوی Saga در نرم‌افزارهای مالی

مقدمه و معماری سیستم‌های توزیع‌شده

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

در سناریوهایی که بیش از یک میکروسرویس دارای پایگاه داده اختصاصی خود است، یک تراکنش منطقی واحد می‌تواند چندین سرویس را در بر بگیرد. حل اصول سنتی ACID (اتمی بودن، سازگاری، جداسازی و دوام) در محیط‌های توزیع‌شده با پروتکل‌های ثبت دو مرحله‌ای (2PC) می‌تواند به گلوگاه‌های عملکردی و تأخیرهای بالا منجر شود. در این نقطه، نیاز به رویکردهای جایگزین برای تراکنش‌های توزیع‌شده و پایداری داده‌ها احساس می‌شود.

الگوی Saga چیست و چگونه کار می‌کند؟

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

هنگامی که در هر یک از مراحل زنجیره خطایی رخ دهد، الگوی Saga وارد عمل می‌شود. تراکنش‌های جبران‌کننده (compensating transactions) که اثرات مراحل قبلی را که با موفقیت انجام شده‌اند خنثی می‌کنند، فعال می‌شوند. این مکانیزم بر اساس اصل سازگاری نهایی (eventual consistency) کار می‌کند و تضمینی حیاتی برای نرم‌افزارهای مالی فراهم می‌کند.

روش‌های پیاده‌سازی گام‌به‌گام Saga

هنگام ادغام الگوی Saga در معماری خود، دو رویکرد اصلی وجود دارد که می‌توانید آن‌ها را ترجیح دهید:

۱. Saga مبتنی بر کورئوگرافی (Choreography)

در این روش که هیچ هماهنگ‌کننده‌ مرکزی وجود ندارد، سرویس‌ها از طریق رویدادها (events) با یکدیگر ارتباط برقرار می‌کنند.

• هر میکروسرویس تراکنش محلی خود را تکمیل کرده و یک رویداد منتشر می‌کند (event publishing).
• سرویس بعدی این رویداد را شنود کرده، تراکنش خود را انجام می‌دهد و رویداد جدیدی را فعال می‌کند.
• در صورت بروز خطا، سرویس مربوطه یک رویداد جبران‌کننده منتشر کرده و سایر سرویس‌ها با شنود این رویداد، داده‌های خود را بازمی‌گردانند.

۲. Saga مبتنی بر ارکستراسیون (Orchestration)

در این ساختار که یک مدیر مرکزی (orchestrator) وجود دارد، کل جریان کار توسط یک مؤلفه واحد کنترل می‌شود.

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

پیاده‌سازی در فرآیندهای مالی و نکات قابل توجه

در حوزه‌های حساسی مانند سیستم‌های مالی و حسابداری، پایداری داده‌ها اهمیت حیاتی دارد. در سناریوهایی مانند انتقال وجه، صدور صورت‌حساب یا کسر موجودی:

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

نتیجه‌گیری

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

مطالعه موردی بر اساس یک سناریوی فرضی مالی

برای ملموس‌تر کردن نحوه عملکرد الگوی Saga در عمل، بیایید یک سناریوی انتقال وجه چندملتی و تبدیل ارز را در نظر بگیریم. هنگامی که کاربر انتقال ارز از حساب مبدأ به حساب مقصد را آغاز می‌کند، سه میکروسرویس مجزا وارد عمل می‌شوند: سرویس موجودی حساب، سرویس تبدیل ارز و سرویس ثبت حسابداری. در مرحله اول، سرویس موجودی حساب مبلغ را از پایگاه داده محلی کاربر کسر کرده و پیام موفقیت تولید می‌کند. در مرحله دوم، سرویس تبدیل ارز تبدیل را با نرخ‌های روز انجام می‌دهد، اما در مرحله سوم یعنی بخش سرویس ثبت حسابداری، خطای غیرمنتظره‌ای مبنی بر اتمام زمان پایگاه داده (timeout) رخ می‌دهد. در این سناریو، به جای مکانیزم‌های قفل‌گذاری سنتی، اصل سازگاری نهایی اجرا می‌شود. به محض اینکه سرویس ارکستراتور سیگنال خطا را تشخیص می‌دهد، فرآیندهای جبران‌کننده را آغاز می‌کند. تبدیل ارز لغو شده و مبلغ کسر شده از حساب در مرحله اول، توسط سرویس موجودی حساب با یک تراکنش جبران‌کننده (compensating transaction) به کاربر بازگردانده می‌شود. بزرگ‌ترین دادوستد (trade-off) معماری که در این فرآیند باید به آن توجه شود، فدا کردن سازگاری آنی به منظور افزایش دسترسی‌پذیری (availability) سیستم است. اطلاعات مربوط به در انتظار بودن تراکنش باید به شکلی شفاف در رابط کاربری به اشتراک گذاشته شود.

چک‌لیست پیاده‌سازی و مدیریت خطا

نکات بحرانی وجود دارد که باید هنگام انتقال الگوی Saga به محیط عملیاتی در یک معماری مالی توزیع‌شده مد نظر قرار گیرد. اول از همه، تمام تراکنش‌ها و دستورات جبران‌کننده باید قطعا به صورت تکرارپذیر (Idempotent) طراحی شوند. در صورت ارسال مجدد یک پیام به دلیل قطعی شبکه، باید از کلیدهای تراکنش منحصربه‌فرد (idempotency keys) استفاده شود تا از اجرای مکرر عمل کسر یا بازپرداخت موجودی جلوگیری گردد. دوم، سناریوهای صف نامه مرده (Dead Letter Queue) که ممکن است در صف‌های پیام (Message Broker) رخ دهند باید از پیش برنامه‌ریزی شده و مکانیزم‌های هشدار برای شرایط استثنایی که نیاز به مداخله دستی دارند ایجاد شوند. سوم، در ادغام‌های سیستم‌های مالی و حسابداری قابلیت حسابرسی (auditability) یک ضرورت است؛ به همین دلیل، وضعیت، مهر زمانی و لاگ‌های خطای هر مرحله از Saga باید در یک زیرساخت لاگینگ مرکزی ذخیره شوند. در مرحله پایانی نیز سیستم باید تحت تست‌های بار قرار گیرد تا تحلیل شود که آیا سرویس‌های ارکستراتور زیر بار ترافیک بالا گلوگاه ایجاد می‌کنند یا خیر و زمان‌های تأخیر تراکنش‌های جبران‌کننده به تفصیل بررسی شوند.

منابع

• سیستم‌های مالی و حسابداری — Cy Logic Software