تراکنش ها (Transaction) بخش اساسی اپلیکیشن ها هستند. بدون آنها، حفظ ثبات اطلاعات (data consistency) غیرممکن خواهد بود. یکی از انواع تراکنش ها Two-Phase Commit نامیده می شوند. که به طور خلاصه انجام اولین تراکنش به اتمام دومین تراکنش بستگی دارد. به طور مثال ثبت سفارش به این بستگی دارد که از موجودی انبار نیز کم شود.
هنگامی که با میکروسرویس کار می کنید، پیچیده تر می شود. هر سرویس دارای دیتابیس مختص خود است و دیگر نمی توان از Two-Phase Commit برای حفظ ثبات اطلاعات کل سیستم خود استفاده کنید.
هنگامی که این توانایی را از دست می دهید، دیتابیس های RDBMS گزینه مناسبی برای ذخیره سازی محسوب نمی شود ، به همین دلیل است که اکثر شرکت هایی که با میکروسرویس کار می کنند از NoSQL نیز استفاده می کنند.
برای توضیح بیشتر این مشکل، معماری Microservices سیستم فروشگاهی زیر را در نظر بگیرید:
در مثال بالا شما نمی توانید تمام عملیات های پرداخت، بروز رسانی موجودی انبار و ارسال به سیستم تحویل را در یک تراکنش ACID انجام دهید. به دلیل توزیع شده بودن سیستم نیاز به تراکنشی در محیط توزیع شده داریم.
الگوی SAGA دنباله ای از تراکنش ها است. که هر تراکنش را در یک سرویس به روز می کند. تراکنش اول توسط یک درخواست خارجی متناسب با عملکرد سیستم آغاز می شود و سپس هر مرحله بعدی با اتمام مرحله قبلی انجام می شود.
الگوی saga با استفاده از مثال بالا به شکل زیر است.
برای اجرای saga ، روش های مختلفی وجود دارد، اما محبوب ترین آن ها عبارتند از:
در این روش ، هر تراکنش هنگام انجام کار خود رویدادی را منتشر می کند. تراکنشی دیگر که این رویداد را دریافت می کند رفتار مناسب را انجام می دهد. کار وقتی تمام می شود که تمام تراکنش ها انجام شود.
در Choreography این فرآیند و ارتباطات توسط خود تراکنش ها اداره می شود.
مزایای Choreography:
معایب Choreography:
در این روش، یک سرویس جداگانه وجود دارد که کل فرایند را هماهنگ می کند. این سرویس مدیریت می کند که چه زمانی کدام سرویس اجرا شود. اگر یکی از تراکنش ها به دلایلی از کار بیفتد Orchestrator مسئولیت برگشت (rollback) تراکنش هایی قبلاً انجام شده را بر عهده دارد.
مزایای Orchestration:
معایب Orchestration:
انتخاب اینکه از کدام روش استفاده کنیم بستگی به سازمان و نیاز سیستم است.
منابع:
