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

معرفی مدل RIG – معمای طراحی سیستم‌های مایکروسرویسی با تضمین سازگاری داده

نکات کلیدی

• این مقاله مدل جدید RIG را معرفی می‌کند که از طراحی سیستم‌های مایکروسرویسی با تضمین سازگاری داده از منظر کسب‌وکار پشتیبانی می‌کند.
• RIG مخفف Reversible (برگشت‌پذیر)، Irreversible (برگشت‌ناپذیر) و Guaranteed (تضمین‌شده) است و رفتار مایکروسرویس‌ها را در قالب یک دنباله از تراکنش‌های محلی، که با نام ساگا نیز شناخته می‌شود، دسته‌بندی می‌کند.
• مدل RIG سه قانون برای زنجیره فراخوانی یک ساگا تدوین می‌کند که سازگاری نهایی داده را تضمین می‌کند.
• این مقاله یک ابزار RIG با رویکرد بازی‌گونه پیشنهاد می‌دهد. این ابزار از سه قطعه اصلی RIG تشکیل شده و تیم‌ها می‌توانند با آن یک سیستم مایکروسرویسی با سازگاری داده تضمین‌شده را مانند یک پازل مدل‌سازی کنند.

مقدمه

هر زمان که یک معماری مایکروسرویسی پیشنهاد می‌شود، باید این سؤال را بپرسید:

آیا مطمئن هستیم داده‌های ما سازگار باقی خواهند ماند؟

می‌توانید به‌راحتی این سؤال را نادیده بگیرید و فقط روی وعده‌هایی تمرکز کنید که مایکروسرویس‌ها ارائه می‌دهند: «مایکروسرویس‌ها به تیم‌ها امکان می‌دهند مستقل‌تر کار کنند، زمان عرضه به بازار را کاهش دهند، قابلیت‌های جدید توسعه دهند، باگ‌ها را رفع کنند و غیره»، طبق گفته Sam Newman در کتاب Building Microservices.

و واقعاً هم احتمالاً در سناریوهای «همه‌چیز خوب پیش می‌رود» به دردسر نمی‌افتید. اما همان‌طور که همه می‌دانیم، شیطان در جزئیات است. وقتی اوضاع شروع کند به خراب شدن چه اتفاقی می‌افتد؟ خب، احتمالاً می‌شنوید: «از ساگاها با تراکنش‌های جبرانی استفاده می‌کنیم، پس نگران نباشید. ساگاها در نهایت به سازگاری می‌رسند.»

سؤال این است: آیا این حرف درست است؟ آیا ساگاها با تراکنش‌های جبرانی سازگاری نهایی را تضمین می‌کنند؟

پاسخ کوتاه: «نه.»
پاسخ بلندتر: «نه، مگر اینکه…»

مشخص می‌شود اگر ساگاها با قوانین مشخصی هم‌خوان باشند، می‌توانید سازگاری نهایی را تضمین کنید.

این مقاله درباره روشن‌کردن این قوانین است و همچنین ارائه ابزاری به تیم‌ها برای طراحی ساگاهایی که با تضمین بتوانند در سناریوهای «نه‌چندان خوشحال‌کننده» به سازگاری نهایی برسند. یا اگر چنین چیزی ممکن نباشد، دست‌کم مبنایی فراهم شود برای انتخاب راه‌حلی که در آن پیامدها را از قبل می‌دانید.

این مقاله یک پایه نظری در قضیه CAP دارد که ابتدا توسط Eric Brewer مطرح و سپس به‌روزرسانی شد، و همچنین بر کارهای Sam Newman، Chris Richardson، و Kaj Steen Bromose و Ronni Laursen تکیه دارد. تبدیل این کار نظری به یک ابزار برای اهل عمل، عمدتاً با همکاری یک شرکت بزرگ فین‌تک دانمارکی انجام شده است و در حال حاضر هم داخل شرکت و هم در یک دوره دانشگاهی درباره مایکروسرویس‌ها در حال «اجرای آزمایشی» است. تست‌های اولیه نشان می‌دهند ابزار همان‌طور که امیدوار بودیم کار می‌کند. مشابه EventStorming، ابزار ما یک فضای مؤثر برای گفت‌وگو بین کسب‌وکار و توسعه‌دهندگان ایجاد می‌کند. در مورد ما، موضوع «سازگاری داده» است. مشخص می‌شود مشکلات مربوط به سازگاری نهایی اغلب باید با همکاری کسب‌وکار حل شوند، یا با تغییر فرآیندهای کسب‌وکار یا با پذیرش یک ریسک حساب‌شده. ابزارهای RIG این گفت‌وگو را به شکلی غیر فنی تسهیل می‌کنند و به‌جای تمرکز بر جزئیات تکنیکی، با نمونه‌سازی ساگاها به صورت بازی‌گونه، روی فرآیندهای کسب‌وکار تمرکز می‌کنند.

اما قبل از آن، بیایید زمینه را مشخص کنیم. طبق گفته Newman، اگر قرار است مایکروسرویس‌ها مزایای خود را ارائه دهند، باید به‌صورت مستقل قابل استقرار (deployable) باشند. پیامد طراحی برای استقرار مستقل این است که از یک سیستم دیتابیس واحد با تراکنش‌های ACID (Atomicity, Consistency, Isolation, Durability) فاصله می‌گیرید؛ جایی که قابلیت rollback در تراکنش‌های ACID وضعیت‌هایی را مدیریت می‌کند که در آن قوانین کسب‌وکار یک یا چند موجودیت مشارکت‌کننده نقض می‌شوند. یک معماری مایکروسرویسی که هر سرویس آن مستقل قابل استقرار باشد، معمولاً به «یک دیتابیس برای هر سرویس» نیاز دارد و مدیریت تراکنش توزیع‌شده را کنار می‌گذارد.

در نتیجه، امکان سازگاری سخت‌گیرانه مبتنی بر تراکنش‌های ACID را از دست می‌دهید. در تراکنش‌هایی که چند مایکروسرویس را در بر می‌گیرند، تنها گزینه شما برای رسیدن به سازگاری، سازگاری نهایی (eventual consistency) است. این جابه‌جایی از سازگاری سخت‌گیرانه به سازگاری نهایی یکی از پیچیدگی‌های اصلی الگوی «یک دیتابیس برای هر مایکروسرویس» است. یک روش محبوب برای رسیدن به سازگاری نهایی استفاده از الگوی Saga است. Richardson ساگا را این‌گونه توصیف می‌کند: «یک دنباله از تراکنش‌های محلی در هر مایکروسرویس مشارکت‌کننده.» هدف ساگا این است که در سطح کل سیستم، سازگاری نهایی داده را برای یک دنباله از تراکنش‌های محلی در زنجیره‌ای از فراخوانی‌های مایکروسرویسی با اتصال سست فراهم کند. یعنی همه دیتابیس‌ها باید در نهایت به یک حالت سازگار از داده‌های درگیر در «تراکنش» برسند.

الگوی Saga می‌تواند از طریق تراکنش‌های جبرانی سازگاری نهایی داده را تضمین کند، اما نه در همه حالت‌ها. همان‌طور که Bromose و Laursen در Ensuring Eventual Consistency in a Microservices Architecture توضیح داده‌اند، برای تضمین سازگاری نهایی داده، باید برخی محدودیت‌ها در زنجیره فراخوانی مایکروسرویس‌ها رعایت شود. Richardson در Microservice Patterns اشاره می‌کند حتی اگر این محدودیت‌ها رعایت شوند، استفاده از الگوی Saga هم تضمین‌کننده سازگاری داده نیست، زیرا ساگاهای درهم‌تنیده (interleaved) ممکن است سازگاری داده را به‌دلیل نبود ویژگی «Isolation» که در تراکنش ACID وجود دارد، به خطر بیندازند و به مشکلاتی مثل dirty read، lost update و غیره منجر شوند.

برای بسیاری از برنامه‌های کسب‌وکاری، نبود تضمین سازگاری نهایی داده مسئله‌ای حیاتی است. این موضوع گاهی باعث می‌شود معماری مایکروسرویس به‌عنوان راه‌حل کنار گذاشته شود، اما این مقاله مدل جدید RIG و یک ابزار اولیه بازی‌گونه را معرفی می‌کند. RIG مخفف Reversible، Irreversible و Guaranteed است و رفتار مایکروسرویس‌ها را در محدوده یک ساگا دسته‌بندی می‌کند (pdf). ابزار مدل RIG امکان طراحی ساگاها را برای سیستم‌های مایکروسرویسی فراهم می‌کند که در آن‌ها سازگاری نهایی داده باید تضمین‌شده باشد. ابزار RIG از روش EventStorming که توسط Alberto Brandolini ایجاد شده الهام گرفته و قرار است یک ابزار تعاملی، سریع و کسب‌وکارمحور باشد تا قبل از ورود به پیاده‌سازی، ساگاها درست طراحی شوند.

مدل RIG و ابزار آن

مدل RIG

مدل RIG پایه طراحی ساگا را فراهم می‌کند. این مدل بر قضیه CAP و کار Bromose و Laursen بنا شده است. خروجی این کار نظری، مجموعه‌ای از دسته‌بندی‌های مایکروسرویس و قوانینی است که ساگاها باید از آن‌ها پیروی کنند تا بتوانیم سازگاری داده را تضمین کنیم.

مدل RIG رفتار مایکروسرویس‌ها در یک ساگا را به سه دسته تقسیم می‌کند:

• مایکروسرویس‌های تضمین‌شده (Guaranteed): تراکنش‌های محلی همیشه موفق خواهند بود. هیچ محدودیت کسب‌وکاری تراکنش را نامعتبر نمی‌کند.

• مایکروسرویس‌های برگشت‌پذیر (Reversible): تراکنش‌های محلی همیشه می‌توانند با کمک تراکنش‌های جبرانی لغو شوند و rollback موفق انجام شود.

• مایکروسرویس‌های برگشت‌ناپذیر (Irreversible): تراکنش‌های محلی قابل لغو نیستند.

باید تراکنش‌ها را از دید کسب‌وکار در نظر بگیرید (یعنی محدودیت‌های منطق کسب‌وکار تعیین می‌کنند هر سرویس در کدام دسته قرار می‌گیرد، نه محدودیت‌های فنی). از منظر فنی فرض می‌شود سیستم به اندازه کافی مقاوم و تاب‌آور است تا در صورت مشکلات فنی مانند قطعی شبکه، کرش مایکروسرویس و غیره، پیام‌ها را حفظ کند. این یک نیاز ساده‌ای نیست، اما اگر نگرانی را به دید بیرونی و درونی تفکیک کنید قابل مدیریت است. از دید بیرونی، یکی از راه‌های کمک به این تاب‌آوری استفاده از سیستم صف پیام با تحویل تضمین‌شده است. از دید درونی، می‌توانید از یک مکانیزم تراکنش همراه با الگوی outbox استفاده کنید تا سازگاری بین دیتابیس مایکروسرویس و سیستم پیام‌رسان خروجی برای انتشار پیام‌ها تضمین شود. درباره پیام‌های ورودی، می‌توان از خواندن تراکنشی از صف ورودی استفاده کرد؛ جایی که پیام به‌عنوان بخشی از commit کار داخلی مایکروسرویس از صف حذف می‌شود. برای مثال، نوشتن داده‌های برنامه، نوشتن داده‌های outbox و حذف پیام از صف ورودی به‌صورت «یک واحد کار» در همان محدوده تراکنش مدیریت می‌شوند.

ابزار

ابزار مدل‌سازی RIG قرار است یک ابزار مشارکتی برای تیم‌های توسعه فراهم کند تا بتوانند بخش‌های مصالحه و ریسک در سازگاری داده را نمونه‌سازی و شناسایی کنند.

این ابزار از سه قطعه تشکیل شده که به‌ترتیب نماینده مایکروسرویس Reversible (R)، Irreversible (I) و Guaranteed (G) هستند. قطعات RIG از رنگ‌های چراغ راهنمایی استفاده می‌کنند: قرمز برای برگشت‌ناپذیر، زرد برای برگشت‌پذیر و سبز برای تضمین‌شده. فلش‌های توپر مسیر منطق کسب‌وکار را نشان می‌دهند و فلش‌های خط‌چین مسیر rollback را نمایش می‌دهند.

قطعات نشان‌داده‌شده در شکل ۱ در اندازه Sticky Note هستند. سه قطعه بالایی با PLA و به‌صورت سه‌لایه چاپ سه‌بعدی شده‌اند. لایه میانی سیاه است و یک آهنربا داخل آن قرار گرفته تا قطعات روی وایت‌بردهای مغناطیسی قابل استفاده باشند. سه قطعه پایینی از آکریلیک ساخته شده‌اند و یک برچسب چاپ‌شده روی آن‌ها قرار دارد. فایل CAD قابل دانلود است. زیر‌بخش بعدی قطعات را با جزئیات بیشتری توضیح می‌دهد.

برگشت‌پذیر (Reversible)

مایکروسرویس‌های برگشت‌پذیر قوانین کسب‌وکاری دارند که ممکن است تراکنش محلی را نامعتبر کند. برای مثال، ممکن است یک قانون کسب‌وکار داشته باشید که تعداد یک کالا در انبار باید مثبت باشد، یعنی اگر کالا تمام شده باشد سفارش را قبول نمی‌کنیم. برای مثال. اگر تلاش کنید سفارشی ثبت کنید که باعث شود موجودی منفی شود، سرویس تراکنش به‌روزرسانی موجودی را رد می‌کند و یک پیام جبرانی رو به عقب با دلیل «out of stock» صادر می‌کند.

اگر یک قانون کسب‌وکار تراکنش ساگا را نامعتبر کند، مایکروسرویس باید هر تراکنش محلی در حال انجام را rollback کند و یک پیام «cancel transaction» ارسال کند.

یک مایکروسرویس برگشت‌پذیر باید از تراکنش جبرانی پشتیبانی کند و بتواند پیام ورودی «cancel transaction» را مدیریت کند. وقتی درخواست «cancel transaction» دریافت می‌شود، مایکروسرویس باید به حالت قبل از ساگا «بازگردد».

مدیریت تراکنش‌های جبرانی در یک مایکروسرویس برگشت‌پذیر باید مانند یک سرویس «Guaranteed» رفتار کند. این می‌تواند چالش‌برانگیز باشد؛ شاید بخواهید الگوی «invoice/credit note» را برای حل این مسئله در نظر بگیرید. برای مثال، وقتی مقدار موجودی یک کالا را تغییر می‌دهید، می‌توانید یک جدول «item event» داشته باشید که مقدار کاهش موجودی را (به‌صورت مقدار منفی) در آن ثبت کنید. و اگر نیاز به تراکنش جبرانی داشتید، همان مقدار را این بار به‌صورت عدد مثبت در جدول «item event» می‌نویسید. در این حالت مقدار موجودی برابر مجموع مقادیر جدول «item event» خواهد بود، مشابه روشی که حساب بانکی با یک جدول حساب و یک جدول ثبت گردش‌ها (posting) مدیریت می‌شود.

قطعه زردِ برگشت‌پذیر دارای اتصال‌دهنده‌های مثلثی است که نشان می‌دهد rollback از طریق تراکنش جبرانی ممکن است. مدیریت تراکنش‌های جبرانی در یک مایکروسرویس برگشت‌پذیر باید مانند یک سرویس «Guaranteed» رفتار کند که با رنگ سبز فلشِ جریان برگشتی نشان داده شده است.

برگشت‌ناپذیر (Irreversible)

مایکروسرویس برگشت‌ناپذیر از تراکنش‌های جبرانی پشتیبانی نمی‌کند. وقتی تراکنش محلی در این مایکروسرویس انجام شد، دیگر قابل لغو یا rollback نیست. با این حال، اگر به‌دلیل نقض یک قانون کسب‌وکار در مایکروسرویس، تراکنش محلی شکست بخورد، می‌تواند یک درخواست جبرانی به ساگا صادر کند. یعنی از نظر رد شدن تراکنش شبیه دسته برگشت‌پذیر است، اما توانایی مدیریت پیام‌های «cancel transaction» را ندارد. برای مثال، اگر یک دستگاه خودپرداز پول را تحویل داده باشد، دیگر نمی‌توانید به عقب برگردید. قطعه برگشت‌ناپذیر قرمز است و با یک اتصال‌دهنده گرد مشخص می‌شود.

تضمین‌شده (Guaranteed)

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

قوانین RIG و بازی‌گونه‌سازی

این بخش سه قانون RIG را توضیح می‌دهد؛ ابتدا دو محدودیت داخلی ساگا و سپس محدودیت بیرونی آن.

محدودیت‌های داخلی ساگا (Saga Constraints)

فقط دو قانون داخلی وجود دارد وقتی از ابزار RIG برای رسیدن به سازگاری تضمین‌شده در یک ساگا (زنجیره فراخوانی) استفاده می‌کنید:

قانون ۱: فقط یک مایکروسرویس برگشت‌ناپذیر مجاز است.
قانون ۲: بعد از یک مایکروسرویس برگشت‌ناپذیر فقط می‌توان از مایکروسرویس‌های تضمین‌شده استفاده کرد.

قطعات RIG فقط زمانی کنار هم جور می‌شوند که ساگا به سازگاری داده برسد، و نمونه‌ای از آن در شکل ۲ نشان داده شده است.

اگر ساگا با قوانین RIG سازگار نباشد و در نتیجه نتواند سازگاری را تضمین کند، قطعات کنار هم جور نمی‌شوند. در نمونه شکل ۳، ساگا بعد از یک سرویس برگشت‌ناپذیر یک سرویس برگشت‌پذیر دارد. این یعنی ساگا نمی‌تواند سازگاری را تضمین کند و این موضوع با قطعاتی که به هم نمی‌خورند نمایش داده می‌شود.

این مثال‌ها فقط یک زنجیره خطی را نشان می‌دهند. با این حال، جریان‌های موازی در زنجیره هم می‌توانند وجود داشته باشند، به شرطی که با محدودیت‌های RIG هم‌خوان باشند. «Fork» و «Merge» در ارکستراسیون ساگا این موضوع را مدیریت می‌کنند.

محدودیت‌های بیرونی ساگا

قانون ۳: ساگاها نباید در هم تنیده (interleaved) شوند.

همان‌طور که در مقدمه گفته شد، ساگا مکانیزم ایزولیشن تراکنشی مثل سطح‌های ایزولیشن ACID را ندارد. این باعث مشکلات شناخته‌شده هنگام درهم‌تنیدن تراکنش‌ها با سطح ایزولیشن «read uncommitted» می‌شود؛ مثل dirty read، non-repeatable read یا phantom read.

برای جلوگیری از این مشکلات، ساگاها نباید در هم تنیده شوند. بنابراین، یک ساگا باید از ساگاهای دیگر ایزوله باشد. اگر ساگای دیگری داده‌های ساگای جاری را تغییر دهد، سازگاری نهایی نمی‌تواند تضمین شود، زیرا تراکنش جبرانی (rollback) ممکن است به‌دلیل تغییرات ایجادشده توسط ساگای درهم‌تنیده شکست بخورد.

Bromose و Laursen روش‌هایی برای ایجاد ایزولیشن ساگاها توصیف می‌کنند که این مقاله آن را بیشتر توضیح نمی‌دهد.

استفاده از ابزار روش RIG چگونه پیش می‌رود؟

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

ابتدا شما و تیم‌تان بررسی می‌کنید آیا رخداد کسب‌وکاری، نسبت به مایکروسرویس‌های درگیر، رفتار تراکنشی لازم دارد یا نه. آیا به یک ساگا نیاز است؟ اگر بله، شما و تیم‌تان درباره دسته هر مایکروسرویس در ساگا بحث می‌کنید: R است، I است یا G. سپس شروع می‌کنید به نمونه‌سازی جریان ساگا با قطعات RIG، شاید روی یک وایت‌برد، و تیم با هم همکاری می‌کند تا جریانی پیدا کند که قطعات در آن به هم بخورند. دو نتیجه ممکن است رخ دهد:

• قطعات به هم می‌خورند. تبریک! شما یک ساگای سازگار با داده دارید.

• قطعات به هم نمی‌خورند. این وضعیت بدی است که باید حل شود و لازم است مایکروسرویس‌ها را بازطراحی کنید تا قطعات جور شوند.

چند پیشنهاد برای حل این بازطراحی:

• ادغام برخی مایکروسرویس‌ها در یک micro monolith ماژولار.

• تغییر نیازمندی‌های کسب‌وکار برای رخداد مورد نظر، برای کاهش محدودیت‌های یکی یا چند مایکروسرویس در ساگا، تا قطعات جور شوند.

در پایان جلسه، شما یک ساگا دارید که قطعاتش به‌خوبی کنار هم قرار می‌گیرند.

در طول فرآیند، همچنین درباره نیازمندی‌های تراکنشی مایکروسرویس‌ها هم شفافیت پیدا می‌کنید، آن هم با بررسی «یک رخداد کسب‌وکاری در هر مرحله».

• مایکروسرویس‌های برگشت‌پذیر باید یک تراکنش جبرانی بدون شکست برای رخداد کسب‌وکاری پیاده‌سازی کنند.

• مایکروسرویس‌های تضمین‌شده باید هم تراکنش اصلیِ بدون شکست و هم تراکنش جبرانیِ بدون شکست را برای رخداد کسب‌وکاری پیاده‌سازی کنند.

مدل جریان طراحی سیستم RIG

ابزار RIG که توضیح داده شد بخش مرکزی پازل طراحی سیستم‌های مایکروسرویسی با تضمین سازگاری داده است. اما این ابزار فرآیند «از کسب‌وکار تا مایکروسرویس‌ها» را پوشش نمی‌دهد. مدل جریان طراحی سیستم RIG یک چارچوب پیرامون ابزار RIG به شما می‌دهد و شما را از کسب‌وکار تا طراحی یک سیستم هدایت می‌کند. این سیستم همیشه مایکروسرویسی نیست، اما اگر سیستم مایکروسرویسی باشد، فرآیند شامل ابزار RIG هم خواهد بود.

پس «مدل جریان طراحی سیستم RIG» چیست؟ این یک فرآیند متمرکز بر دامنه مسئله است که به شما کمک می‌کند سیستم‌های مایکروسرویسی را از منظر کسب‌وکار طراحی کنید. این مدل یک مسیر از تحلیل نیازمندی‌های کسب‌وکار تا یک طرح معماری از سیستم IT پشتیبان نیازمندی‌ها ارائه می‌دهد. نقطه تمرکز، سازگاری داده است و از منظر کسب‌وکار، تصمیم‌گیری ریسک‌محور و مستدل درباره پذیرش احتمال نرسیدن به سازگاری نهایی. به‌طور خلاصه:

• مدل جریان طراحی سیستم RIG یک ابزار پشتیبانی تصمیم است که کمک می‌کند سیستم‌های مایکروسرویسی را از منظر کسب‌وکار طراحی کنید.

• مدل RIG یک ابزار طراحی است که به شما اجازه می‌دهد اعتبارسنجی کنید جریان‌های ساگا همیشه می‌توانند به سازگاری نهایی برسند.

• مدل RIG در محدوده مدل جریان طراحی سیستم RIG زندگی می‌کند.

شکل ۴ مدل طراحی سیستم RIG را به‌صورت یک فلوچارت نشان می‌دهد. یک جریان می‌تواند مراحل زیر را دنبال کند:

a) شناسایی مرزها و قوانین کسب‌وکار.
وقتی همه مرزها و قوانین مهم شناسایی شدند، به مرحله b بروید.
پیشنهاد می‌کنیم در این مرحله از EventStorming و مفهوم Bounded Context در Domain-Driven Design، همراه با مفاهیم dark matter و dark energy استفاده کنید.

b) تقسیم‌بندی به مایکروسرویس‌ها.
بررسی کنید آیا ساگاها در جریان وجود دارند یا نه. اگر بله، به مرحله c بروید.

c) ساخت یک جریان که قطعات RIG در آن به هم بخورند.
یک سیستم سازگار زمانی به دست می‌آید که جریان با سه قانون RIG هم‌خوان باشد.

d) بازبینی مرزها و قوانین کسب‌وکار.

e) رسیدگی به ساگاهای درهم‌تنیده و ایجاد ایزولیشن.

مشخص می‌شود وقتی سیستم‌تان را به مایکروسرویس‌ها خرد می‌کنید، باید تا حد امکان از سرویس‌های قرمزِ برگشت‌ناپذیر دوری کنید. این‌ها وقتی شروع می‌کنید به مدل‌سازی ساگاها، چابکی کسب‌وکار را خراب می‌کنند؛ دلیلش هم این است که ساگاها را به‌شدت محدود می‌کنند: «هر بار فقط یک قطعه قرمز می‌تواند روی میز باشد»، یعنی وقتی یک ساگا را مدل می‌کنید، قانون اول RIG فعال می‌شود و ممکن است طراحی ساگا را دست‌وپاگیر کند. به‌طور کلی، سبز و زرد خوب‌اند و قرمز بد است.

مواجهه با نبودِ سازگاری نهاییِ تضمین‌شده

گاهی لازم است از خودتان بپرسید: واقعاً به سازگاری نهاییِ تضمین‌شده نیاز دارم؟

ممکن است از نظر کسب‌وکاری، پذیرفتن ریسک برای یک تراکنش مشخص تصمیمی منطقی باشد. بنابراین، اگر نمی‌توانید با قوانین RIG سازگار شوید، می‌توانید از قضیه CAP استفاده کنید تا جایگاه CAP ساگای خود را بر اساس میزان ریسکی که حاضر به پذیرش آن هستید تعیین کنید. ما این را «CAP پویا» می‌نامیم.

CAP پویا (Dynamic CAP)

ایده CAP پویا این است که لازم نیست کل سیستم‌تان را در یک جایگاه CAP مدل‌سازی کنید؛ مثلاً جایگاه AP که رایج‌ترین وضعیت برای یک سیستم مایکروسرویسی است. می‌توانید سیستم را طوری مدل کنید که بخش‌های مختلف آن جایگاه‌های CAP متفاوتی داشته باشند. حتی می‌توانید به یک جایگذاری CAP مبتنی بر سیاست فکر کنید که با رویکردی داده‌محور هدایت می‌شود. برای مثال، بسته به مقدار پولی که در تراکنش درگیر است، جایگاه CAP را به‌صورت پویا و بر اساس میزان تمایل به ریسک تغییر می‌دهید.

مونولیت ماژولار (The modular monolith)

اگر نمی‌خواهید هیچ ریسک کسب‌وکاری بپذیرید، بررسی کنید آیا معماری مایکروسرویس واقعاً ارزش این دردسر را دارد یا نه. انجام درستِ مایکروسرویس‌ها کار زیادی می‌برد و نگه‌داشتن مایکروسرویس‌ها در حال اجرا هم کار زیادی می‌برد (به‌خاطر نیاز به پایش و مانیتورینگ سیستم). بنابراین، اگر به مایکروسرویس‌ها نیاز ندارید، احتمالاً باید سراغ «بچه جدید محله» بروید: مونولیت ماژولار.

نتیجه‌گیری و کارهای آینده

این مقاله مدل RIG را پیشنهاد می‌کند که می‌تواند به تیم‌ها کمک کند با استفاده از قطعات RIG و بصری‌سازی ساگاهای سیستم، به سازگاری داده تضمین‌شده در سیستم‌های مایکروسرویسی برسند. قطعات RIG دو قانون اول RIG را تحمیل می‌کنند؛ قوانینی که وقتی قطعات به هم جور می‌شوند، به‌طور ضمنی رعایت شده‌اند. همچنین مقاله نشان می‌دهد رسیدن به داده سازگارِ تضمین‌شده ممکن است نیازمند بازنگری فرآیندهای کسب‌وکار باشد؛ مثلاً تغییر ترتیب اجرای فعالیت‌ها. به همین دلیل، مالک محصول (product owner) نقش محوری در طراحی ساگاهایی با سازگاری داده تضمین‌شده دارد.

کارهای آینده (Future work)

ما در مرحله تست با یک شرکت فین‌تک جاافتاده هستیم. نتایج اولیه نشان می‌دهد روش و ابزارهای RIG گفت‌وگوهای سازنده و کارآمد درباره قوانین کسب‌وکار، مایکروسرویس‌ها و ساگاها را تسهیل می‌کنند. گام بعدی، آزمودن مسائل واقعی کسب‌وکار در کارگاه‌های تمام‌عیار (full-scale) است.

در ادامه مسیر، ما یک چارچوب برای «Consistency Ping» معرفی خواهیم کرد؛ جایی که امکان ارسال یک «پینگ سازگاری» در یک ساگا وجود دارد. این پینگ یک گراف از سرویس‌های پارتیشن‌شده و دسته آن‌ها (R، I یا G) می‌سازد. سپس می‌توان گراف پینگ را به‌صورت خودکار از نظر نقض‌های سازگاری بررسی کرد. برای فعال‌کردن این پینگ، پیشنهاد می‌کنیم متادیتا در استاندارد AsyncAPI تعبیه شود تا سرویس‌ها دسته خود (R، I یا G) را اعلام کنند. به این ترتیب، افزودن «Consistency Ping» به سیستم‌هایی که با رویکرد API-first طراحی شده‌اند و در آن‌ها استاندارد AsyncAPI سرویس‌ها را توصیف می‌کند، ممکن خواهد بود.