الگوی طراحی حماسه راهی برای مدیریت سازگاری داده ها در میان میکروسرویس ها در سناریوهای معامله توزیع شده است. حماسه دنباله ای از معاملات است که هر سرویس را به روز می کند و یک پیام یا رویداد را برای شروع مرحله معامله بعدی منتشر می کند. اگر یک گام با شکست مواجه, حماسه اجرا جبران معاملات که مقابله با معاملات قبل.
زمینه و مشکل
تراکنش یک واحد واحد از منطق یا کار است که گاهی از چندین عملیات تشکیل شده است. در یک معامله, یک رویداد یک تغییر دولت است که به یک نهاد رخ می دهد, و یک فرمان کپسوله تمام اطلاعات مورد نیاز برای انجام یک عمل و یا ماشه یک رویداد بعد.
معاملات باید اتمی استوار جدا شده و با دوام (اسید). معاملات درون یک سرویس واحد اسیدی هستند اما سازگاری داده های متقابل سرویس نیاز به یک استراتژی مدیریت تراکنش متقابل سرویس دارد.
در معماری چند سرویس:
- اتمی مجموعه ای از عملیات تقسیم ناپذیر و غیرقابل کاهش است که همه باید اتفاق بیفتند یا هیچ کدام رخ ندهند.
- سازگاری به این معنی است که معامله داده ها را فقط از یک حالت معتبر به حالت معتبر دیگر می رساند.
- جداسازی تضمین می کند که تراکنش های همزمان همان حالت داده ای را تولید می کنند که تراکنش های متوالی اجرا شده تولید می کردند.
- دوام تضمین می کند که معاملات متعهد حتی در صورت خرابی سیستم یا قطع برق متعهد باقی می مانند.
یک مدل پایگاه داده در هر میکروسرویس مزایای زیادی برای معماری های میکروسرویس ها فراهم می کند. کپسوله سازی داده های دامنه به هر سرویس اجازه می دهد تا از بهترین نوع و طرحواره فروشگاه داده خود استفاده کند و در صورت لزوم فروشگاه داده خود را مقیاس بندی کند و از خرابی سایر خدمات عایق بندی شود. با این حال, حصول اطمینان از ثبات داده ها در سراسر پایگاه داده خدمات خاص شمار چالش.
معاملات توزیع شده مانند پروتکل متعهد دو فاز (2 عدد) به همه شرکت کنندگان در یک معامله نیاز دارد تا قبل از ادامه معامله متعهد یا عقب نشینی کنند. با این حال برخی از پیادهسازیهای شرکتکنندگان مانند پایگاه دادههای نوسکیوال و بروکرینگ پیام از این مدل پشتیبانی نمیکنند.
یکی دیگر از محدودیتهای تراکنش توزیع شده همزمانی و در دسترس بودن ارتباطات بین پردازشی است. سیستم عامل - به شرطی که سیستم عامل به فرایندهای جداگانه اجازه می دهد تا داده ها را به اشتراک بگذارند. برای انجام معاملات توزیع شده همه خدمات شرکت کننده باید در دسترس باشند و به طور بالقوه در دسترس بودن کلی سیستم را کاهش دهند. پیادهسازیهای معماری با محدودیتهای تراکنش یا پیکری کاندیدای الگوی حماسه هستند.
راه حل
الگوی حماسه مدیریت تراکنش را با استفاده از دنباله ای از معاملات محلی فراهم می کند . معامله محلی تلاش کار اتمی است که توسط یک شرکت کننده در حماسه انجام می شود. هر معامله محلی پایگاه داده را به روز می کند و یک پیام یا رویداد را برای ایجاد معامله محلی بعدی در حماسه منتشر می کند. اگر یک معامله محلی نتواند, حماسه اجرا یک سری از معاملات جبران است که خنثیسازی تغییراتی که توسط معاملات محلی قبل ساخته شد.
در الگوهای حماسه:
- معاملات قابل جبران معاملاتی هستند که به طور بالقوه می توانند با پردازش تراکنش دیگری با اثر معکوس معکوس شوند.
- معامله محوری نقطه رفتن / ممنوعیت رفتن در یک حماسه است. اگر معامله محوری مرتکب, حماسه اجرا می شود تا اتمام. یک معامله محوری می تواند معامله ای باشد که نه قابل جبران است و نه قابل تکرار است یا می تواند معامله قابل جبران یا اولین معامله قابل جبران در حماسه باشد.
- تراکنش های قابل تکرار تراکنش هایی هستند که از معامله محوری پیروی می کنند و موفقیت را تضمین می کنند.
دو روش اجرای حماسه مشترک وجود دارد, طراحی رقص و ارکستراسیون . هر رویکرد مجموعه ای از چالش ها و فناوری های خاص خود را برای هماهنگی گردش کار دارد.
طراحی رقص
رقص و رقص راهی برای هماهنگی حماسه هایی است که شرکت کنندگان بدون یک نقطه کنترل متمرکز رویدادها را رد و بدل می کنند. با طراحی رقص, هر معامله محلی منتشر حوادث دامنه که باعث معاملات محلی در سایر خدمات.
مزایا
- خوب برای گردش کار ساده است که نیاز به چند شرکت کنندگان و منطق هماهنگی نیاز ندارد.
- نیازی به پیاده سازی و نگهداری سرویس اضافی ندارد.
- یک نقطه شکست را معرفی نمی کند زیرا وظایف در میان شرکت کنندگان در حماسه توزیع می شود.
اشکالاتی
- گردش کار می تواند هنگام اضافه کردن مراحل جدید گیج کننده باشد زیرا دشوار است که شرکت کنندگان حماسه به کدام دستورات گوش دهند.
- خطر وابستگی چرخه ای بین شرکت کنندگان در حماسه وجود دارد زیرا باید دستورات یکدیگر را مصرف کنند.
- تست یکپارچه سازی دشوار است زیرا همه سرویس ها باید برای شبیه سازی یک معامله اجرا شوند.
ارکستراسیون
ارکستراسیون راهی برای هماهنگی حماسه ها است که یک کنترل کننده متمرکز به شرکت کنندگان در حماسه می گوید چه معاملات محلی را انجام دهند. ارکستر حماسه تمام معاملات را انجام می دهد و به شرکت کنندگان می گوید که کدام عملیات را بر اساس رویدادها انجام دهند. ارکستر اجرا درخواست حماسه, فروشگاه ها و تفسیر ایالات از هر وظیفه, و دسته بازیابی شکست با جبران معاملات.
مزایا
- خوب برای گردش پیچیده شامل بسیاری از شرکت کنندگان و یا شرکت کنندگان جدید اضافه شده در طول زمان.
- مناسب زمانی که کنترل هر شرکت کننده در روند وجود دارد و کنترل جریان فعالیت ها.
- وابستگی های دوره ای را معرفی نمی کند زیرا ارکستر به طور یک جانبه به شرکت کنندگان در حماسه بستگی دارد.
- شرکت کنندگان در حماسه نیازی به دانستن دستورات سایر شرکت کنندگان ندارند. تفکیک روشن نگرانی ها منطق کسب و کار را ساده می کند.
اشکالاتی
- پیچیدگی طراحی اضافی نیاز به اجرای منطق هماهنگی دارد.
- یک نقطه اضافی از شکست وجود دارد, چرا که ارکستر مدیریت گردش کار کامل.
موضوعات و ملاحظات
هنگام اجرای الگوی حماسه نکات زیر را در نظر بگیرید:
- الگوی حماسه ممکن است در ابتدا چالش برانگیز باشد زیرا نیاز به یک روش جدید تفکر در مورد چگونگی هماهنگی یک معامله و حفظ ثبات داده ها برای یک فرایند تجاری شامل چندین میکروسرویس دارد.
- الگوی حماسه به خصوص سخت به اشکال زدایی است, و پیچیدگی رشد می کند به عنوان شرکت کنندگان افزایش.
- داده ها را نمی توان به عقب برگرداند زیرا شرکت کنندگان در حماسه مرتکب تغییراتی در پایگاه داده های محلی خود می شوند.
- پیاده سازی باید قادر به مدیریت مجموعه ای از خرابی های گذرا بالقوه باشد و برای کاهش عوارض جانبی و اطمینان از ثبات داده ها ناتوانی ایجاد کند. عدم توانایی به این معنی است که همان عمل را می توان چندین بار بدون تغییر نتیجه اولیه تکرار کرد. برای کسب اطلاعات بیشتر, راهنمایی را ببینید در حصول اطمینان از بیکاری در هنگام پردازش پیام ها و به روز رسانی دولت با هم.
- بهتر است برای پیاده سازی مشاهده برای نظارت و پیگیری گردش کار حماسه.
- فقدان جداسازی داده های شرکت کنندگان چالش های دوام را تحمیل می کند. اجرای حماسه باید شامل اقدامات متقابل برای کاهش ناهنجاری ها باشد.
ناهنجاری های زیر می تواند بدون اقدامات مناسب اتفاق بیفتد:
- به روز رسانی از دست داده , زمانی که یک حماسه بدون خواندن تغییرات ایجاد شده توسط حماسه دیگر می نویسد.
- کثیف می خواند, هنگامی که یک معامله و یا یک حماسه می خواند به روز رسانی ساخته شده توسط یک حماسه است که هنوز کسانی که به روز رسانی تکمیل نشده.
- فازی / تکرار نشدنی می خواند, زمانی که مراحل مختلف حماسه خواندن داده های مختلف به دلیل به روز رسانی داده ها بین بار خوانده شده رخ می دهد.
اقدامات متقابل پیشنهادی برای کاهش یا جلوگیری از ناهنجاری ها عبارتند از:
- قفل معنایی, یک قفل در سطح برنامه که یک معامله قابل جبران حماسه از یک سمافور برای نشان دادن به روزرسانی در حال انجام است.
- به روزرسانی های جابجایی که می توانند به هر ترتیب اجرا شوند و نتیجه یکسانی داشته باشند.
- دیدگاه بدبینانه: این امکان وجود دارد برای یک حماسه به خواندن داده های کثیف, در حالی که حماسه دیگر در حال اجرا است یک معامله جبران به عقب عملیات. دیدگاه بدبینانه مجددا مرتب حماسه به طوری که به روز رسانی داده های اساسی در یک معامله مجدد, که امکان خواندن کثیف از بین می برد.
- ارزش بازخوانی تایید می کند که داده ها بدون تغییر است و سپس رکورد را به روز می کند. اگر رکورد تغییر کرده است, مراحل سقط و حماسه ممکن است راه اندازی مجدد.
- یک فایل نسخه عملیات را هنگام ورود روی یک رکورد ثبت می کند و سپس به ترتیب صحیح اجرا می کند.
- با ارزش از ریسک تجاری هر درخواست برای انتخاب پویا مکانیسم همزمانی استفاده می کند. درخواست های کم خطر به نفع حماسه, در حالی که درخواست در معرض خطر به نفع معاملات توزیع.
زمان استفاده از این الگو
در صورت نیاز از الگوی حماسه استفاده کنید:
- اطمینان از سازگاری داده ها در یک سیستم توزیع شده بدون اتصال محکم.
- رول یا جبران اگر یکی از عملیات در دنباله نتواند.
الگوی حماسه کمتر مناسب است:
- معاملات محکم همراه.
- جبران معاملات که در شرکت کنندگان قبلی رخ می دهد.
- وابستگی های چرخه ای.
مثال
حماسه مبتنی بر ارکستراسیون در بدون سرور یک مرجع اجرای حماسه با استفاده از رویکرد ارکستراسیون است که سناریوی انتقال پول را با گردش کار موفق و ناموفق شبیه سازی می کند.
گام های بعدی
منابع مرتبط
الگوهای زیر نیز ممکن است هنگام اجرای این الگو مفید باشد:
