پیام رسانی قابل اعتماد در سیستم های توزیع شده

مشکل نوشتن دوگانه ساختن یک سیستم توزیع شده قابل اعتماد، بسیار در دسترس و مقیاس پذیر مستلزم رعایت تکنیک ها، اصول و الگوهای خاص است. طراحی چنین سیستم هایی مستلزم پرداختن به چالش های بی شماری است. یکی از رایج ترین و اساسی ترین مسائل است. مشکل نوشتن دوگانه چالشی است که در سیستمهای توزیعشده به وجود میآید، عمدتاً زمانی که با منابع داده یا پایگاههای اطلاعاتی متعددی سروکار داریم که باید همگام نگه داشته شوند. این به دشواری حصول اطمینان از اینکه تغییرات دادهها به طور مداوم در ذخیرهگاههای داده مختلف، مانند پایگاههای داده یا حافظههای پنهان نوشته میشوند، بدون ارائه مسائلی مانند ناسازگاری دادهها، تضادها، یا گلوگاههای عملکرد اشاره دارد. «مشکل نوشتن دوگانه» معماری میکروسرویس ها و پایگاه داده الگوی هر سرویس، مزایای بسیاری مانند استقرار و مقیاس بندی مستقل، خرابی های مجزا و افزایش بالقوه سرعت توسعه را برای شما به ارمغان می آورد. با این حال، عملیات نیاز به تغییراتی در میان چندین میکروسرویس دارد که شما را مجبور میکند به راهحلی مطمئن برای مقابله با این مشکل فکر کنید. تقریبا یک نمونه واقعی بیایید سناریویی را در نظر بگیریم که در آن دامنه ما شامل پذیرش درخواستهای وام، ارزیابی آنها و سپس ارسال هشدارهای اعلان به مشتریان است. بر اساس روح اصل مسئولیت واحد، قانون کانوی و رویکرد طراحی مبتنی بر دامنه، پس از چندین جلسه طوفانی رویداد، کل دامنه به سه زیر دامنه با زمینههای محدود تعریف شده با مرزهای روشن، مدلهای دامنه و زبان فراگیر تقسیم شد. وظیفه ، نصب و تدوین برنامه های وام جدید است. سیستم این برنامه ها را ارزیابی می کند و بر اساس داده های ارائه شده تصمیم می گیرد. این فرآیند ارزیابی، شامل بررسیهای KYC/KYB، ضد تقلب و ریسک اعتباری، میتواند زمانبر باشد و توانایی رسیدگی به هزاران برنامه را به طور همزمان ضروری میکند. در نتیجه، این عملکرد به یک میکروسرویس اختصاصی با پایگاه داده اختصاصی خود واگذار شده است که امکان مقیاس بندی مستقل را فراهم می کند. اول دوم علاوه بر این، این زیرسیستمها توسط دو تیم مختلف مدیریت میشوند که هر کدام دارای چرخههای انتشار، قراردادهای سطح خدمات (SLA) و الزامات مقیاسپذیری خاص خود هستند. ، یک سرویس اطلاع رسانی تخصصی برای ارسال هشدار به مشتریان وجود دارد. در نهایت در اینجا یک توضیح دقیق از مورد استفاده اولیه سیستم آمده است: مشتری یک درخواست وام ارسال می کند. خدمات درخواست وام درخواست جدید را با وضعیت "در انتظار" ثبت می کند و با ارسال درخواست به خدمات ارزیابی، فرآیند ارزیابی را آغاز می کند. خدمات ارزیابی درخواست وام دریافتی را ارزیابی می کند و متعاقباً تصمیم را به خدمات درخواست وام اطلاع می دهد. پس از دریافت تصمیم، سرویس درخواست وام وضعیت درخواست وام را مطابق با آن به روز می کند و سرویس اعلان ها را برای اطلاع مشتری از نتیجه فعال می کند. سرویس اعلانها این درخواست را پردازش میکند و طبق تنظیمات مشتری، اعلانها را از طریق ایمیل، پیامک یا سایر روشهای ارتباطی ترجیحی به مشتری ارسال میکند. این یک سیستم بسیار ساده و ابتدایی در نگاه اول است، اما بیایید به نحوه پردازش دستور درخواست وام توسط سرویس درخواست وام بپردازیم. ما می توانیم دو رویکرد را برای تعاملات سرویس در نظر بگیریم: در این رویکرد، سرویس پایگاه داده محلی خود را به روز می کند (commits) و سپس یک رویداد یا پیام را برای سرویس های دیگر منتشر می کند. First-Local-Commit-Then-Publish: برعکس، این روش شامل انتشار یک رویداد یا پیام قبل از انجام تغییرات در پایگاه داده محلی است. First-Publish-Then-Local-Commit: هر دو روش دارای اشکالاتی هستند و فقط تا حدی برای ارتباط در سیستم های توزیع شده ایمن هستند. این یک نمودار دنباله ای از اعمال رویکرد اول است. در این سناریو، سرویس درخواست وام از رویکرد استفاده می کند، جایی که ابتدا یک تراکنش را انجام می دهد و سپس سعی می کند یک اعلان به سیستم دیگری ارسال کند. با این حال، اگر برای مثال، مشکلات شبکه وجود داشته باشد، سرویس ارزیابی در دسترس نباشد، یا سرویس درخواست وام با خطای حافظه خارج از حافظه (OOM) مواجه شود و از کار بیفتد، این فرآیند مستعد شکست است. در چنین مواردی، پیام از بین میرود و ارزیابی بدون اطلاع از درخواست وام جدید باقی میماند، مگر اینکه اقدامات اضافی انجام شود. First-Local-Commit-Then-Publish و دومی. در سناریوی ، سرویس درخواست وام با خطرات مهم تری مواجه است. ممکن است سرویس ارزیابی را در مورد یک برنامه جدید مطلع کند، اما به دلیل مشکلاتی مانند مشکلات پایگاه داده، خطاهای حافظه یا اشکالات کد، این به روز رسانی را به صورت محلی ذخیره نمی کند. این رویکرد میتواند منجر به تناقضات قابلتوجهی در دادهها شود، که بسته به نحوه رسیدگی سرویس بررسی وام به برنامههای دریافتی، میتواند مشکلات جدی ایجاد کند. First-Publish-Then-Local-Commit بنابراین، ما باید راه حلی را شناسایی کنیم که مکانیزمی قوی برای انتشار رویدادها به مصرف کنندگان خارجی ارائه دهد. اما، قبل از پرداختن به راه حل های بالقوه، ابتدا باید انواع تضمین های تحویل پیام قابل دستیابی در سیستم های توزیع شده را روشن کنیم. ضمانت ارسال پیام چهار نوع تضمین وجود دارد که میتوانیم به آن برسیم. هیچ تضمینی وجود ندارد هیچ تضمینی وجود ندارد که پیام به مقصد برسد. رویکرد دقیقاً در این مورد است. مصرف کنندگان ممکن است پیام ها را یک بار، چندین بار یا اصلاً دریافت نکنند. First-Local-Commit-Then-Publish حداکثر یک بار تحویل حداکثر یک بار تحویل به این معنی است که پیام حداکثر 1 بار به مقصد تحویل داده می شود. رویکرد می توان به این روش نیز با خط مشی تلاش های مجدد با ارزش یک اجرا کرد. First-Local-Commit-Then-Publish را حداقل یک بار تحویل\مصرف کنندگان هر پیام را دریافت و پردازش می کنند اما ممکن است همان پیام را بیش از یک بار دریافت کنند. دقیقا یک بار تحویل\دقیقا یک بار تحویل به این معنی است که مصرف کننده یک بار پیام را به طور موثر دریافت می کند. از نظر فنی، دستیابی به معاملات کافکا و اجرای ناتوان خاص تولیدکننده و مصرف کننده امکان پذیر است. در بیشتر موارد، ضمانتهای تحویل با اطمینان از اینکه پیامها حداقل یک بار تحویل داده میشوند، بسیاری از مسائل را برطرف میکنند، اما مصرفکنندگان باید ناتوان باشند. با این حال، با توجه به خرابی های شبکه اجتناب ناپذیر، تمام منطق مصرف کننده باید برای جلوگیری از پردازش پیام های تکراری، بدون توجه به ضمانت های سازنده، ناتوان باشد. بنابراین، این نیاز به اندازه ای که واقعیت را منعکس می کند، یک اشکال نیست. «حداقل یکبار» راه حل ها راه حل های زیادی برای این مشکل وجود دارد که مزایا و معایب خود را دارند. تعهد دو فازی طبق ویکیپدیا، تعهد دو مرحلهای (2PC) یک پروتکل تراکنش توزیعشده است که در علم کامپیوتر و سیستمهای مدیریت پایگاه داده برای اطمینان از سازگاری و قابلیت اطمینان تراکنشهای توزیعشده استفاده میشود. این برای موقعیتهایی طراحی شده است که منابع متعدد (مثلاً پایگاههای داده) نیاز به مشارکت در یک تراکنش دارند، و تضمین میکند که یا همه آنها تراکنش را انجام میدهند یا همه آنها آن را لغو میکنند، در نتیجه ثبات دادهها را حفظ میکند. به نظر دقیقاً همان چیزی است که ما نیاز داریم، اما دو فاز Commit چندین اشکال دارد: اگر یکی از منابع شرکت کننده پاسخگو نباشد یا با شکست مواجه شود، کل فرآیند می تواند تا زمانی که مشکل حل شود مسدود شود. این می تواند منجر به مشکلات بالقوه عملکرد و در دسترس بودن شود. دو فاز commit مکانیسم های داخلی تحمل خطا را ارائه نمی دهد. برای رسیدگی به خرابی ها به مکانیسم های خارجی یا مداخله دستی متکی است. همه پایگاههای داده مدرن از دو فاز Commit پشتیبانی نمیکنند. پایگاه داده مشترک آشکارترین راه حل برای معماری میکروسرویس ها اعمال یک الگو (یا حتی گاهی اوقات ضد الگو) است - یک پایگاه داده مشترک. اگر به یکپارچگی تراکنش در چندین جدول در پایگاه های داده مختلف نیاز دارید، این رویکرد بسیار شهودی است، فقط از یک پایگاه داده مشترک برای این میکروسرویس ها استفاده کنید. اشکالات این رویکرد شامل معرفی یک نقطه شکست واحد، جلوگیری از مقیاسگذاری مستقل پایگاه داده و محدود کردن توانایی استفاده از راهحلهای مختلف پایگاهداده است که برای نیازهای خاص و موارد استفاده مناسب هستند. علاوه بر این، برای پشتیبانی از چنین شکلی از تراکنش توزیعشده، تغییراتی در پایگاههای کد میکروسرویسها ضروری است. صندوق خروجی تراکنش " " یک الگوی طراحی است که در سیستم های توزیع شده برای اطمینان از انتشار پیام قابل اعتماد، حتی در مواجهه با سیستم های پیام رسانی نامعتبر استفاده می شود. این شامل ذخیره رویدادها در یک جدول تعیین شده "OutboxEvents" در همان تراکنش با خود عملیات است. این رویکرد به خوبی با ویژگی های ACID پایگاه های داده رابطه ای هماهنگ است. در مقابل، بسیاری از پایگاههای داده No-SQL به طور کامل از ویژگیهای ACID پشتیبانی نمیکنند، در عوض اصول قضیه CAP و فلسفه BASE را انتخاب میکنند که در دسترس بودن و ثبات نهایی را بر سازگاری دقیق اولویت میدهند. صندوق خروجی تراکنش صندوق خروجی تراکنش می کند و می تواند با چندین رویکرد پیاده سازی شود: حداقل یک بار تضمین باطله ثبت معاملات ناشر نظرسنجی رویکرد به استفاده از راه حل های خاص پایگاه داده مانند CDC (Change Data Capture) اشاره دارد. اشکالات اصلی آن رویکرد عبارتند از: باطله ثبت تراکنش راه حل های خاص پایگاه داده افزایش تاخیر به دلیل ویژگی های پیاده سازی CDC روش دیگر است که با نظرسنجی جدول صندوق خروجی، بارگذاری خروجی را تسهیل می کند. اشکال اولیه این رویکرد، پتانسیل افزایش بار پایگاه داده است که می تواند منجر به هزینه های بالاتر شود. علاوه بر این، همه پایگاه های داده No-SQL از پرس و جوی کارآمد برای بخش های سند خاص پشتیبانی نمی کنند. بنابراین استخراج کل اسناد می تواند منجر به کاهش عملکرد شود. Polling Publisher در اینجا یک نمودار توالی کوچک توضیح داده شده است که چگونه کار می کند. به خودت گوش کن چالش اصلی الگوی صندوق خروجی تراکنش در وابستگی آن به ویژگی های ACID پایگاه داده نهفته است. ممکن است در پایگاه داده های معمولی OLTP ساده باشد، اما چالش هایی را در قلمرو NoSQL ایجاد می کند. برای رفع این مشکل، یک راه حل بالقوه این است که از ثبت پیوست (به عنوان مثال، کافکا) درست از آغاز پردازش درخواست استفاده کنید. بهجای پردازش مستقیم دستور «ارسال درخواست وام»، بلافاصله آن را به یک موضوع داخلی کافکا ارسال میکنیم و سپس نتیجه «پذیرفتهشده» را به مشتری برمیگردانیم. با این حال، از آنجایی که احتمال زیادی وجود دارد که دستور هنوز نیاز به پردازش داشته باشد، ما نمی توانیم بلافاصله نتیجه را به مشتری اطلاع دهیم. برای مدیریت این سازگاری نهایی، میتوانیم تکنیکهایی مانند نظرسنجی طولانی، نظرسنجی مبتنی بر مشتری، بهروزرسانیهای خوشبینانه UI یا استفاده از WebSockets یا رویدادهای ارسالشده از سرور برای اعلانها استفاده کنیم. با این حال، این موضوع کاملاً متمایز است، بنابراین اجازه دهید به موضوع اولیه خود بازگردیم. ما این پیام را در مورد یک موضوع داخلی کافکا ارسال کردیم. سپس Loan Application Service این پیام را مصرف می کند - همان فرمانی که از مشتری دریافت کرده است - و پردازش را شروع می کند. اول، برخی از منطق تجاری را اجرا می کند. تنها پس از اجرای موفقیت آمیز این منطق و تداوم نتایج، پیام های جدیدی را در مورد یک موضوع عمومی کافکا منتشر می کند. اجازه دهید کمی به شبه کدها نگاهی بیندازیم. public async Task HandleAsync(SubmitLoanApplicationCommand command, ...) { //First, process business logic var loanApplication = await _loanApplicationService.HandleCommandAsync(command, ...); //Then, send new events to public Kafka topic producer.Send(new LoanApplicationSubmittedEvent(loanApplication.Id)); //Then, commit offset consumer.Commit(); } نگران نباشید، از آنجایی که آفست هنوز انجام نشده است، پیام دوباره امتحان خواهد شد. اگر پردازش منطق تجاری با شکست مواجه شود چه؟ نگران نباشید، از آنجایی که منطق کسب و کار ضعیف است، یک درخواست وام تکراری ایجاد نمی کند. در عوض، تلاش خواهد کرد تا پیام هایی را به موضوع عمومی کافکا ارسال کند. اگر ارسال رویدادهای جدید به کافکا با شکست مواجه شود چه؟ نگران نباشید، از آنجایی که منطق کسب و کار ضعیف است، یک درخواست وام تکراری ایجاد نمی کند. در عوض، پیامهایی را به موضوع عمومی کافکا ارسال میکند و امیدوار است که تعهد افست این بار موفق شود. اگر پیامهایی برای کافکا ارسال شود، اما تعهد افست با شکست مواجه شود، چه؟ اشکالات اصلی این رویکرد شامل پیچیدگی اضافه مرتبط با یک سبک برنامهنویسی جدید، سازگاری نهایی (از آنجایی که مشتری فوراً نتیجه را نمیداند) و الزام برای ناتوانی منطق تجاری است. منبع یابی رویداد منبع یابی رویداد چیست و چگونه می توان آن را در اینجا اعمال کرد؟ منبعیابی رویداد یک الگوی معماری نرمافزاری است که برای مدلسازی وضعیت یک سیستم با ثبت تمام تغییرات دادههای آن بهعنوان مجموعهای از رویدادهای تغییرناپذیر استفاده میشود. این رویدادها نشان دهنده حقایق یا انتقال حالت هستند و به عنوان منبع واحد حقیقت برای وضعیت فعلی سیستم عمل می کنند. بنابراین، از نظر فنی، با پیادهسازی یک سیستم منبعیابی رویداد، ما در حال حاضر همه رویدادها را در EventStore داریم و این EventStore میتواند توسط مصرفکنندگان بهعنوان منبعی واحد از حقیقت در مورد آنچه اتفاق افتاده استفاده شود. نیازی به یک راه حل پایگاه داده خاص برای ردیابی همه تغییرات یا نگرانی های مربوط به سفارش نیست، تنها مشکل در سمت خواندن نشسته است، زیرا برای اینکه بتوان وضعیت واقعی موجودیت را به دست آورد برای پخش مجدد همه رویدادها لازم است. نتیجه گیری در این مقاله چندین رویکرد برای ایجاد پیام رسانی قابل اعتماد در سیستم های توزیع شده بررسی کردیم. چندین توصیه وجود دارد که ممکن است هنگام ساختن سیستم هایی با این ویژگی ها در نظر بگیریم همیشه مصرف کنندگان ناتوان ایجاد کنید زیرا شکست شبکه اجتناب ناپذیر است. با درک روشنی از الزامات تضمین با دقت استفاده کنید. ، از First-Local-Commit-Then-Publish هرگز از رویکرد استفاده نکنید زیرا ممکن است منجر به ناهماهنگی شدید داده ها در سیستم شما شود. First-Publish-Then-Local-Commit اگر تصمیم انتخاب پایگاه داده موجود به احتمال زیاد ممکن است تغییر کند یا استراتژی فنی مستلزم انتخاب بهترین راه حل ذخیره سازی برای مشکل باشد - با اتصال به راه حل های پایگاه داده مانند ، کتابخانه های مشترک ایجاد نکنید. CDC از رویکرد به عنوان یک راه حل استاندارد برای دستیابی به حداقل یک بار تضمین استفاده کنید. صندوق خروجی تراکنش هنگامی که پایگاه داده های No-SQL اهرمی هستند، از رویکرد استفاده کنید. Listen to yourself دفعه بعد، به یک مثال کاربردی تر از اجرای صندوق خروجی تراکنش خواهیم پرداخت. ببینید تو