نگاهی به Event Sourcing (بخش اول)

Pooya Zangiabadi — Mon, 20 May 2024 13:18:10 +0330

خوب دوستان، قبلا از اینکه به 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 رو حفظ میکند. حالا برای اینکه بهتر این سه مدل رو درک کنیم یه مقایسه جدولی براش میارم :

نگاهی به WeakHashMap

Pooya Zangiabadi — Tue, 07 May 2024 20:02:46 +0330

به منظور درک این ساختار داده ای ، در اینجا از آن برای پیاده سازی یک cashساده استفاده خواهیم کرد. با این حال به خاطر داشته باشید که پیاده سازی یک cashبرای خودتان، عمدتا یک ایده بد است.ساختار داده Weak hashMap یک پیاده‌سازی بر اساس hashTable از اینترفیس Map در جاوا است که به کاربر امکان استفاده از weak refrence (اشاره‌گرهای ضعیف) برای کلیدها می‌دهد. Weak References در جاوا نوعی از اشاره‌گر است که از حذف آبجکت اشاره ‌شده توسط garbage collector جلوگیری نمی‌کند. در یک WeakHashMap ، کلیدها به عنوان اشاره‌گرهای ضعیف ذخیره می‌شوند، به این معنی که اگر کلیدها در هیچ‌جای دیگری در برنامه استفاده نشوند، ممکن است توسط garbage collectorحذف شوند. این می‌تواند در مواردی مفید باشد که شما می‌خواهید اطلاعات اضافی را با آبجکت‌ها مرتبط کنید بدون اینکه جلوی حذف آن‌ها توسط garbage collector را بگیرد.یک کاربرد شایع برایWeakHashMap در سناریوهای cashing است که می‌خواهید داده‌های اضافی مربوط به آبجکت‌ها را cash نمایید بدون جلوگیری از حذف آن‌ها توسط garbage collector وقتی دیگر نیازی به آن‌ها نیست. با استفاده از weak refrence، برای کلیدها در یک WeakHashMap، می‌توانید اطمینان حاصل کنید که حافظه استفاده شده توسط cash به طور خودکار توسط garbage collector بازیابی خواهد شد.احتیاط‌ هایی وجود دارد که باید هنگام استفاده از WeakHashMap آن‌را در نظر بگیرید. یکی از مهم‌ترین ملاحظه‌ها این است که رفتار Weak References ممکن است کمی پیش‌بینی ناپذیر باشد.کلاس Soft Referenceبه طور ساده، یک شیء که یک SoftReference به آن اشاره دارد تا زمانی که JVM به طور مطلق نیاز به حافظه دارد، توسط GC از بین نخواهد رفت. به بیان دیگر این شی واجد شرایط GC میباشد اما فقط زمانی جمع آوری میشود که JVM به طور مطلق به حافظه نیاز داشته باشد.کلاس Weak Referenceآن object هایی که فقط به وسیله weak refrence ها ارجاع داده میشوند، واجد شرایط برای GC میباشند و GC منتظر JVM برای نیازمندی به حافظه نمی ماند و در cycle بعدی garbage collector، اگر مورد استفاده نباشند، جمع آوری میشوند.خوب، میخواهیم یک حافظه cash بسازیم که تصاویر با حجم بزرگ را به عنوان مقادیر نگهداری کند و نام تصاویر را به عنوان کلیدها.استفاده از یک HashMap ساده یک انتخاب خوب نخواهد بود زیرا تصاویر ممکن است حافظه زیادی را اشغال کنند. علاوه بر این، آن‌ها هرگز توسط یک فرآیند GC از حافظه حذف نخواهند شد، حتی زمانی که دیگر در برنامه ما استفاده نمی‌شوند.وقتی که از WeakHashMap ، استفاده کنیم، زمانی که یک کلید (نام تصویر) از یک entry، درهیچ جای برنامه‌ی ما استفاده نمی‌شود، آن entry از آن object از حافظه حذف خواهد شد.public class LargeImageCache { private static WeakHashMap imageCache = new WeakHashMap<>(); public static BufferedImage getCachedImage(File imageFile) { BufferedImage cachedImage = imageCache.get(imageFile); if (cachedImage == null) { try { cachedImage = ImageIO.read(imageFile); imageCache.put(imageFile, cachedImage); } catch (IOException e) { e.printStackTrace(); } } return cachedImage; } public static void clearCache() { imageCache.clear(); } }public class Main { public static void main(String[] args) { File imageFile = new File("path/to/large/image.jpg"); BufferedImage cachedImage = LargeImageCache.getCachedImage(imageFile); // Use cachedImage in your application // ... LargeImageCache.clearCache(); // Clear the cache when no longer needed } }

نوشته های Pooya Zangiabadi

نگاهی به Event Sourcing (بخش اول)

نگاهی به WeakHashMap