ویرگول
ورودثبت نام
Saeid Noormohammadi
Saeid Noormohammadi
Saeid Noormohammadi
Saeid Noormohammadi
خواندن ۳ دقیقه·۲ سال پیش

Messaging as the Single Source of Truth

به زبان ساده در این پترن پیام ها منبع اصلی و معتبر اطلاعات و عملیات ها در سیستم های توزیع شده می باشند. به عبارت دیگر به جای اینکه هر سرویس به صورت مستقل دیتاها را نگهداری و مدیریت کند, تمام event ها به شکل پیام ثبت و به سیستم های دیگر ارسال می شوند. اینجا تمام سرویس ها از طریق همین پیام ها به روزرسانی و همگام می شوند که این کار باعث همگام سازی داده ها, کاهش وابستگی ها و افزایش قابلیت تحمل خطا می شود.

برای مثال صرافی دیجیتال نوبیتکس را در نظر بگیرید. فرض می کنیم که نوبیتکس برای انجام معامله ها سه تا سرویس زیر را دارد:
Wallet Service: برای مدیریت موجودی.
Order Service: ثبت سفارش های خرید و فروش.
Trade Service: انجام تراکنش های خرید و فروش.
برای انجام معامله TradeService سفارش ها رو از OrderService گرفته و موجودی کاربر را با WalletService چک می کند. اما مشکلی که هستش از کجا می شود مطمعن شد که اطلاعات این سرویس ها همیشه به روز و دقیق است؟ فکر کنید کاربر میخواد ارز همستر کامبت(😁) بخره, اینجا اگر این سه تا سرویس هرکدام بخوان داده های خودشون رو داشته باشند و مدیریت کنند ممکن هستش مشکلاتی مثل Data Inconsistency رخ بدهد. برای مثال سفارش در OrderService ثبت شده ولی هنوز موجودی WalletService به روزرسانی نشده!

اینجاست که Messaging SSOT وارد می شود, چطوری؟ در این پترن پیام ها تنها منبع برای بررسی هستند. به جای اینکه هر سرویس خودش به صورت مستقل داده ها رو مدیریت کنه, هر تغییر مهم در سیستم به عنوان یک پیام ثبت میشه و این پیام به سرویس ها ارسال می شود. در نهایت سرویس ها از آن پیام برای انجام کار استفاده می کنند. درخواست خرید همستر کامبت تو OrderService ثبت میشه. این سرویس پیام خرید رو برای بررسی TradeService ارسال می کنه و TradeService موجودی رو با WalletService چک میکنه, موجودی کافی باشه تراکنش رو انجام میده و پیام خرید رو به WalletService و OrderService بر میگردونه تا موجودی به روزرسانی بشه.

مزایا
همگام سازی سریع (Fast Sync): همه سرویس ها از طریق پیام ها همگام هستند.
کاهش وابستگی بین سرویس ها (Reduced Service Coupling): دیگر سرویس ها نیازی به بررسی با یکدیگر ندارند.
تحمل خطا (Fault Tolerance): در صورت بروز مشکل در یک سرویس بعد از بازیابی سرویس می تواند پیام ها را پردازش کند.
بازپخش رویدادها (Event Replay): در صورت مشکل یا نیاز می توان پیام های گذشته را برای تنظیم وضعیت سرویس ها تکرار کرد.

چالش ها
مصرف منابع (Resource Usage):
با توجه به اینکه نیاز به ذخیره سازی تمام پیام ها می باشد, این موضوع باعث افزایش مصرف منابع می شود.
طراحی پیچیده (Complex Design): پیاده سازی و مدیریت این مدل کمی پیچیده می باشد که نیازمند تجربه و طراحی درست می باشد تا پیام ها به شکل درست پردازش شوند.

تفاوت Messaging as the Single Source of Truth و Event Sourcing:
در Messaging SSOT تمرکز بر تبادل پیام بین سرویس ها برای همگام سازی می باشد اما در Event Sourcing تغییرات به صورت Event ذخیره می شوند تا تاریخچه ی سیستم را بازسازی کنیم. اطلاعات بیشتر درمورد Event Sourcing:
https ://lnkd.in/dtTJGGZS

در پایان, توجه داشته باشید که این رویکرد بیشتر برای سیستم های پیچیده و توزیع شده که نیاز به همگام سازی مداوم بین سرویس ها دارند مناسب می باشد. پیشنهاد می کنم برای سرویس های ساده سمتش نرید که پیچدگی و هزینه های زیادی داره.

۰
۰
Saeid Noormohammadi
Saeid Noormohammadi
شاید از این پست‌ها خوشتان بیاید