خوب دوستان، قبلا از اینکه به event sourcing بپردازم، میخوام مزیا و چالش های استفاده از میکروسرویس ها را بیان کنم، چون میشه بعد از اون واضح تر بگم که چرا به event sourcing نیاز داریم.
مقیاس پذیری چند بعدی : خوب همونطور که میدونید، وقتی اپلیکیشن ما رشد میکنه و تعداد درخواستهاش زیاد میشه، باید اینقدر انعاطاف پذیر باشه که بتونه این درخواست ها رو مدیریت کنه و به خوبی پاسخ بده. فارغ از مباحث scaling up و scaling out، ما تو معماری میکروسرویس به جای اینکه یک اپلیکیشن یزرگ رو مقیاس پذیر کنیم، میاییم ، مثلا اگه قراره منابع رو افزایش بدیم، فقط به اون میکروسرویس ها یا واحدهای کوچکتری از اپلیکیشن، اون مکنابع رو میدیم که مقرون به صرفه تر باشه.
بهبود تحمل خطا پذیری : وقتی یه میکروسرویس از چند میکروسرویس شما خطا بده، می‌توان آن خرابی را به آن سرویس ایزوله کرده و از خرابی‌های فوری که باعث خرابی کل اپلیکیشن میشود، جلوگیری کرد.
تنوع تکنولوژی : میتونیم برای هر میکروسرویس بر اساس چالش ها و بیزینسش، از یه تکنولوژی متفاوت استفاده کنیم. علاوه بر این ریفکتور کردن یک اپلیکیشن بزرگ، کاملا سخته.
امکان دیپلوی مستقل : این مورد یکی از سودمندترین مزیت های میکروسرویس است که ما میتونیم فقط، اصطلاحا bounded context هایی را دیپلوی کنیم که ورژن جدیدی از آن ها را میخواهیم. حالا اینکه bounded context چیه بذارین یه کم در موردش توضیح بدم.
بر اساس رویکرد DDD، تقریبا Domain تمامی نرم افزارهای Enterprise از چندین Subdomain تشکیل شده. شناخت Subdomain های سیستم، ما را قادر می سازه تا بیزینس را به بخش های کوچک تر تقسیم کنیم.در حالت ایده آل هر Subdomain در پیاده سازی به یک bounded context تبدیل می شود. هر bounded context یک واحد مستقل شناخته می شود و Domain Model مخصوص به خود را دارد. شکل زیر این مفاهیم رو یه سادگی توضیح میده
حالا چند تا از چالش هایی که میکروسرویس داره رو توضیح میدم
طراحی و پیچیدگی عملیات : وقنی که ما در حال طراحی به اپلیکیشن جدید هستیم ما باید bounded context های مناسب بیسزینس را در نظر بگیریم. چون که این bounded context ها، هرکدوم سرویس های متفاوت و حتی یکپارچه ای با بقیه bounded context ها دارن، پس مدیریت، تست و خطایابی مخصوص خود را دارن.
یکپارچگی داده ها : همونطور که میدونید، در سیستم های با معماری monolithic، کامیت و رول بک تراکنش های یک سرویس تضمین میشود اما در میکروسرویس، همه bounded context ها میتونن منابع از جمله دیتابیس مختص خودشون رو داشته باشن، بنابراین مدیریت غیر متمرکز داده ها نیاز است. چالش همگام سازی داده ها😎
قبل از اینکه وارد بحث اصلی بشیم، لازمه که انواع یکپارچگی داده رو بشناسیم :
یکپارچگی قوی (Strong Consistency) : این نوع از یکپارچگی، تضمین میکند که تمامی نودها در یک سیستم توزیع شده، آخرین ورژن داده هارا میبینند.به عبارت دیگه، وقتی که یه write انجام میشه، همه عملیات read بعدی از هر نود، جدیدترین ورزن write شده را برمیگردانند.
یکپارچگی نهایی(Eventual Consistency) : این نوع از یکپارچگی، تضمین میکند که، به روز رسانی ها در نهایت منتشر میشوند و به یک حالت ثابت میرسند. ممکن است در لحظاتی اختلاف مقدار داده ای در نودها هنگام read وجود داشته باشد ولی با گذشت زمان به سمت سازگاری همگام میشوند. یک رسانه اجتماعی را در نظر بگیرین که کاربراش میتونن، پیام ارسال کنند و این پیام ها در چندین مرکز داده تکرار میشن تا از دسترسی بالا و تحمل خطا اطمینان حاصل شود. هر مرکز داده حاوی کپی پست های کاربر است و برای حفظ یکپارچگی نهایی به صورت ناهمزمان همگام می شوند.
یکپارچگی ضعیف (Weak Consistency) : این نوع از یکپارچگی، تضمین نمیکند که همه نودها ورژن یکسانی از داده ها را به طور همزمان ببینند. یکی از خصوصیاتش این است که اغلب مدل Eventual رو حفظ میکند.
حالا برای اینکه بهتر این سه مدل رو درک کنیم یه مقایسه جدولی براش میارم :
