در سیستم های توزیع شده یکی از مهم ترین چالش ها مربوط به نحوه مدیریت و اشتراک گذاری داده ها بین سرویس ها می باشد. دو نوع داده داریم:
داده های داخلی (Data on the Inside): این داده ها مربوط به هر سرویس به صورت لوکال هستند و به عبارتی فقط داخل همان سرویس استفاده می شوند. این نوع داده ها را سرویس ها با خیال راحت به هر شکل که بخواهند می توانند تغییر دهند چون هیچ وابستگی به سرویس های دیگر ندارند.
داده های خارجی (Data on the Outside): این داده ها بین سرویس ها به اشتراک گذاشته می شوند و برای کارکرد صحیح نیاز به هماهنگی و یکپارچگی دارند. این دسته از داده ها بسیار حساس هستند زیرا مدیریت اشتباه آن ها باعث Data Inconsistency و مشکلات دیگر می شود.
آقای Pat Helland در مقاله "Data on the Inside and Data on the Outside" به این موضوع اشاره می کند که داستان داده های خارجی با داخلی بسیار متفاوت می باشد. چرا که تعداد زیادی سرویس از این داده ها استفاده می کنند و به همین دلیل تغییر این داده ها پیچیده می باشد. به عبارتی این داده ها یکی از مهم ترین بخش های سرویس ها هستند.
برای مدیریت این داده ها, تیم ها باید یک رویکرد باز و به اصطلاح به سمت بیرون داشته باشند. یعنی اینکه سرویس ها را برای کارکردن در یک اکوسیستم بزرگ طراحی کنند(به عنوان بخشی از یک اکوسیستم بزرگ). قبلا سرویس ها به شکلی طراحی میشدن که به صورت مستقل عمل کنند و این اشتراک گذاری داده هام عملا یک وصله پینه به حساب می اومد, اما الان باید این اشتراک گذاری را بخش جدایی ناپذیر از طراحی سرویس ها در نظر بگیریم.
به صورت کلی وقتی میخواهیم داده ای را به بین سرویس ها به اشتراک بگذاریم, معمولا از روش هایی مثل Service Interface ها, Messaging یا Shared Database ها استفاده می کنیم. ولی خب باید بدونیم که هیچکدوم از این روش ها ایده آل نیستند و هرکدوم مشکلات و محدودیت های خودشان را دارند:
سرویس اینترفیس (Service Interface): در این روش سرویس ها با استفاده از API ها باهم تعامل دارند که باعث ایجاد وابستگی های قوی بین سرویس ها میشه و مدیریت داده ها را در مقیاس بزرگ سخت میکنه.
دیتابیس مشترک (Shared Database): در این روش سرویس ها به یک دیتابیس مشترک دسترسی دارند که باعث ایجاد یک نقطه تمرکز قوی تو سیستم میشه که انعطاف پذیری را از ما میگیره و مقیاس پذیری رو هم محدود میکنه.
پیام رسانی (Messaging): به صورت کلی باعث کاهش وابستگی مستقیم بین سرویس ها میشه و کمک میکنه که داده ها را به صورت لوکال استفاده کنیم. اما خب این روش هیچ Message History برای داده ها نداره که مدیریت وضعیت سیستم و تشخیص مشکلات را پیچیده میکنه.
راه حل پیشنهادی - Replyable Log
این روش ترکیبی از Messaging و Database هستش که به عنوان یک نوع Event Store عمل می کند و تاریخچه ی رویدادها را ذخیره می کند. این کار به سرویس ها اجازه میده که به رویدادهای گذشته دسترسی داشته باشند و همچنین از آنها برای بازسازی وضعیت سیستم استفاده کنند. تو پست های آینده به صورت کامل در این مورد صحبت میکنم.
