الگوهای معاملات توزیع شده در یک معماری میکروسرویس

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

معامله توزیع شده چیست؟

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

در اینجا یک مثال سفارش مشتری با یک سیستم یکپارچه با استفاده از معامله محلی وجود دارد:

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

وقتی این سیستم را تجزیه می کنیم ، هم سفارشی Microservice و Ordermicroservice را ایجاد کردیم که دارای پایگاه داده های جداگانه ای هستند. در اینجا یک مثال سفارش مشتری با میکروسرویس ارائه شده است:

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

مشکل چیه؟

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

چگونه معامله را اتمی نگه داریم؟

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

آیا ما اقدامات کاربر را برای درخواست های همزمان جدا می کنیم؟

اگر یک شی توسط یک معامله و در عین حال (قبل از پایان معامله) نوشته شده است ، با درخواست دیگری خوانده می شود ، آیا شیء باید داده های قدیمی یا داده های به روز شده را برگرداند؟در مثال بالا ، هنگامی که UpdateCustomerFund موفق شد اما هنوز منتظر پاسخ از ایجاد کننده است ، آیا باید درخواست های صندوق مشتری فعلی مبلغ به روز شده را برگرداند یا خیر؟

راه حل های ممکن

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

• 2pc (تعهد دو فاز)
• حماسه

الگوی تعهد دو فاز (2pc)

2pc به طور گسترده در سیستم های پایگاه داده استفاده می شود. برای برخی از شرایط ، می توانید از 2pc برای میکروسرویس استفاده کنید. فقط مراقب باش؛همه موقعیت ها کت و شلوار 2pc و در واقع ، 2pc غیر عملی در یک معماری میکروسرویس در نظر گرفته می شود (در زیر توضیح داده شده است).

تعهد دو فاز چیست؟

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

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

در اینجا یک اجرای 2pc برای مثال سفارش مشتری وجود دارد:

در مثال بالا ، هنگامی که کاربر درخواست سفارش سفارش را ارسال می کند ، هماهنگ کننده ابتدا با تمام اطلاعات زمینه یک معامله جهانی ایجاد می کند. سپس به CustomerMicroservice می گوید تا برای به روزرسانی صندوق مشتری با معامله ایجاد شده آماده شود. به عنوان مثال ، اگر مشتری بودجه کافی برای انجام معامله داشته باشد ، به عنوان مثال ، به عنوان مثال بررسی می کند. هنگامی که CustomerMicroservice برای انجام تغییر خوب است ، شیء را از تغییرات بیشتر قفل می کند و به هماهنگ کننده می گوید که آماده شده است. همین اتفاق در هنگام ایجاد سفارش در Ordermicroservice اتفاق می افتد. هنگامی که هماهنگ کننده تأیید کرد که تمام خدمات ریزگردها آماده اعمال تغییرات خود هستند ، سپس از آنها می خواهد که با درخواست تعهد با معامله ، تغییرات خود را اعمال کنند. در این مرحله ، همه اشیاء باز می شوند.

اگر در هر نقطه یک میکروسرویس تنها نتواند آماده شود ، هماهنگ کننده معامله را سقط می کند و روند بازگشت را آغاز می کند. در اینجا نمودار یک بازگشت 2pc برای مثال سفارش مشتری وجود دارد:

در مثال بالا ، Customermicroservice به دلایلی نتوانست آماده شود ، اما سفارش Microservice پاسخ داده است که آماده ایجاد سفارش است. هماهنگ كننده با معامله ، در سفارش MicroService تماس می گیرد و OrderMicroservice هرگونه تغییر ساخته شده را به عقب بازگرداند و اشیاء پایگاه داده را باز كند.

مزایای استفاده از 2pc

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

مضرات استفاده از 2pc

در حالی که 2pc مشکل را حل کرده است ، برای بسیاری از سیستم های مبتنی بر میکروسرویس واقعاً توصیه نمی شود زیرا 2pc همزمان است (مسدود کردن). پروتکل باید قبل از اتمام معامله ، شیء را که تغییر می کند قفل کند. در مثال بالا ، اگر مشتری سفارش را صادر کند ، قسمت "صندوق" برای مشتری قفل می شود. این مانع از اعمال سفارشات جدید مشتری می شود. این امر منطقی است زیرا اگر یک شیء "آماده" پس از ادعای "آماده شدن" تغییر کند ، مرحله تعهد نمی تواند کار کند.

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

الگوی حماسه

الگوی حماسه یکی دیگر از الگوی گسترده برای معاملات توزیع شده است. این متفاوت از 2pc است که همزمان است. الگوی حماسه ناهمزمان و واکنشی است. در یک الگوی SAGA ، معامله توزیع شده توسط معاملات محلی ناهمزمان در کلیه خدمات میکروسروس های مرتبط انجام می شود. میکروسرویس از طریق اتوبوس رویداد با یکدیگر ارتباط برقرار می کند.

در اینجا نمودار الگوی حماسه برای مثال سفارش مشتری وجود دارد:

در مثال بالا ، OrderMicroservice درخواست سفارش سفارش را دریافت می کند. ابتدا یک معامله محلی را برای ایجاد سفارش شروع می کند و سپس یک رویداد سفارش داده شده را منتشر می کند. CustomerMicroservice برای این رویداد گوش می دهد و پس از دریافت این رویداد ، صندوق مشتری را به روز می کند. اگر کسر با موفقیت از یک صندوق انجام شود ، یک رویداد Compeliation Fundupdated منتشر می شود ، که در این مثال به معنای پایان معامله است.

اگر هرگونه خدمات میکروسریس نتواند معامله محلی خود را انجام دهد ، سایر خدمات میکروسرویس معاملات جبران خسارت را انجام می دهند تا تغییرات را به عقب برگردانند. در اینجا یک نمودار از الگوی حماسه برای معامله جبران وجود دارد:

در مثال بالا ، updateCustomerFund به دلایلی شکست خورد و سپس یک رویداد مشتری FundUpdateFailed را منتشر کرد. Ordermicroservice برای این رویداد گوش می دهد و معامله جبران خسارت خود را برای بازگشت به ترتیب ایجاد شده شروع می کند.

مزایای الگوی حماسه

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

مضرات الگوی حماسه

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

اضافه کردن یک مدیر فرآیند

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

نتیجه

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

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