الگوی Saga در Microservice چیست؟
الگوی Saga یکی از 6 الگوی مهم مدیریت دادههای Microservice است که میتوان آن را نتیجهی مستقیم الگوی Database-per-service دانست.من ارسلان میربزرگی، در این مقاله قصد دارم تا شما را با مفهوم Microservice با استفاده از Saga Pattern آشنا کنم. در الگوی Database-per-service، هر Microservice مسئول دادههای خود است. بااینحال سؤال اینجاست که چه اتفاقی میافتد اگر یک Transaction شامل دادههایی باشد که در چندین Microservice وجود دارد؟ در این موقعیتهاست که نیاز به الگوی Saga پدید میآید.
الگوی Saga بهعنوان الگوی معماری Microservice ها برای پیادهسازی Transaction هایی است که شامل چندین سرویس هستند. Saga توالی Microservice ها است. هر سرویس در یک Saga، Transaction خود را انجام داده و رویدادی را منتشر میکند. سایر سرویسها به آن رویداد گوش میدهند و Transaction محلی بعدی را انجام میدهند. اگر به یک دلیل Transaction ای ناموفق باشد، این الگو، بهمنظور خنثی کردن تأثیر Transaction های قبلی، Transaction های Compensating یا جبران کننده را اجرا میکند.
بهعنوان یک مثال ساده، مراحل کاری در یک برنامهی تحویل غذا را بررسی میکنیم. وقتی کاربر سفارش خود را ثبت میکند، مراحل زیر میتواند بهعنوان اقدامات انجامشده وجود داشته باشد: سرویس سفارش غذا یک سفارش ایجاد میکند. در این مرحله، سفارش در حالت PENDING است. این الگو زنجیرهی رویدادها را مدیریت میکند و از طریق برنامه با رستوران تماس گرفته و سفارش را در رستوران انتخابی ثبت میکند و پس از دریافت تأییدیه از رستوران، نتیجه را برای شما ارسال میکند. این الگو پاسخ را دریافت کرده و با توجه به پاسخ دریافتی، میتواند سفارش را تائید یا رد کند. سپس برنامهی سفارش غذا وضعیت سفارش را تغییر میدهد. در صورت تائید سفارش، جزئیات بعدی را به مشتری اطلاع داده و در صورت عدم پذیرش، با پیام عذرخواهی به مشتری اطلاع میدهد.
همانطور که میبینید این روش، کاملاً متفاوت از رویکرد point-to-point است.
انواع Saga
دو نوع Saga وجود دارد:
- Saga مبتنی بر Orchestration
در این روش، Saga orchestrator همهی Transaction ها را مدیریت کرده و بر اساس Event ها، Participant service ها را به سمت Transaction های در حال اجرا هدایت میکند. این Orchestrator میتواند بهعنوان مدیر Saga نیز در نظر گرفته شود.
- Saga مبتنی بر Choreography
در این رویکرد، هیچ Orchestrator مرکزی وجود ندارد. هر Participant service در Saga، Transaction های خود را انجام میدهد و Event ها را منتشر میکند و سایر سرویسها بر اساس آن Event ها عمل کرده و Transaction های خود را انجام میدهند. همچنین، آنها ممکن است با توجه به شرایط سایر رویدادها را منتشر کرده و یا از انتشار آن ها صرف نظر کنند.
مزایا و معایب
مزیت اصلی این الگو این است که بدون Tight coupling به حفظ Consistency دادهها در چندین سرویس کمک میکند؛ که این یک جنبهی بسیار مهم برای معماری Microservice ها است.
بااینحال، نقطه ضعف اصلی این الگو داشتن Apparent complexity از نظر برنامهنویسی است. همچنین، Developer ها بهاندازهی Transaction های سنتی به نوشتن این الگو عادت ندارند. چالش دیگر این است که برای کار کردن Saga نیاز به Transaction های Compensating است.
و در آخر
وبسایت میربزرگی قصد دارد تا با ارائه مقاله ها و تجربههای کاربردی شما را در زمینه یادگیری و رفع اشکالاتتان کمک کند. در صورت وجود هرگونه سوالی به من ایمیل بزنید.