https://virgool.io/feed/@MostafaAkbarizadeh من برنامه‌نویسی هستم که عاشق یادگیری و عملی کردن مفاهیم جدید در پروژه‌ها با توجه به نیاز واقعی تیم‌ها هستم. موفقیت را در رشد جمعی می‌بینم و باور دارم هیچ موفقیتی بدون کار تیمی پایدار نیست. fa 2026-06-16 05:13:06 https://files.virgool.io/upload/users/3545408/avatar/xkSmX0.jpg?height=120&width=120 https://virgool.io/@MostafaAkbarizadeh https://virgool.io/@MostafaAkbarizadeh/%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%DA%A9%D8%B4-%DA%86%DA%AF%D9%88%D9%86%D9%87-%D8%A8%D8%A7-%D9%85%D8%AF%DB%8C%D8%B1%DB%8C%D8%AA-%D9%87%D9%88%D8%B4%D9%85%D9%86%D8%AF%D8%A7%D9%86%D9%87-%D8%B2%DB%8C%D8%B1%D8%B3%D8%A7%D8%AE%D8%AA%DB%8C-%D9%BE%D8%A7%DB%8C%D8%AF%D8%A7%D8%B1-%D8%AF%D8%A7%D8%B4%D8%AA%D9%87-%D8%A8%D8%A7%D8%B4%DB%8C%D9%85-cxmiu3eaz24f داستان ما: پروژه بزرگ فروشگاه "زودتر بخر"تصور کن مدیر فنی یه فروشگاه آنلاین بزرگی هستی به اسم "زودتر بخر"، که ماهانه میلیون‌ها کاربر داره. تو جلسه‌ای که با تیم برگزار می‌کنی، تیم زیرساخت می‌گه:"سرور های ما زیر فشارن، تاخیرها داره بیشتر می‌شه. هر کاربری که صفحه محصولات رو باز می‌کنه، انگار یه چکُش می‌زنه تو سر دیتابیس!"این جمله ساده، یه چالش بزرگ رو نشون می‌ده:درخواست‌های پرتکرار: کاربرا بارها دسته‌بندی‌های مشابه رو می‌بینن.داده‌های تکراری: مثل قیمت محصولات یا توضیحات اون‌ها، هزاران بار از دیتابیس خونده می‌شه.تجربه کاربری ضعیف: تأخیر در بارگذاری صفحه، مشتری رو فراری می‌ده.خب، چیکار کنیم؟!گام اول: کش به عنوان ناجی سیستمتوی جلسه‌ای که با بچه‌های تیم گذاشتی، یکی پیشنهاد می‌ده:"بیایم کش کنیم! اینطوری دیگه لازم نیست هر بار اطلاعات تکراری رو مستقیم از دیتابیس بخونیم."اما سوال اینجاست:چی رو کش کنیم؟ مثلاً آیا موجودی کالا هم کش بشه؟چطور کش رو مدیریت کنیم؟ اگه اطلاعات کش قدیمی بشه چی؟چه ابزارهایی رو استفاده کنیم؟ Redis؟ CDN؟ یا همون MemoryCache؟گام دوم: تعریف اولویت‌هابرای تصمیم‌گیری، اول باید مشخص کنیم چه داده‌هایی ارزش کش کردن دارن:داده‌های پرتکرار و تغییرات کم:مثل دسته‌بندی محصولات یا پرفروش‌ترین‌ها.داده‌هایی که بارها خوانده می‌شن اما حساس نیستن:مثل توضیحات محصولات.اطلاعات حساس؟ اصلاً کش نکن!کسی نمی‌خواد اطلاعات تراکنش یا لاگین کاربرها تو کش گیر بیفته.گام سوم: انتخاب ابزار مناسبخب، حالا نوبت انتخاب تکنولوژیه. بیایم برای هر بخش، ابزار درست رو انتخاب کنیم:1.ردیس (Redis) برای داده‌های توزیع‌شده:چون "زودتر بخر" چندین سرور داره، بهتره از Redis استفاده کنیم.سناریو: کش کردن لیست محصولات یا قیمت‌ها برای درخواست‌های پرتکرار.چالش: باید مطمئن بشیم TTL (زمان انقضا) تنظیم بشه تا اطلاعات قدیمی پاک بشن.2. سی دی ان (CDN) برای محتوای ثابت (Static Content):تصور کن تصاویر و CSSهای سایت برای میلیون‌ها کاربر بارگذاری می‌شن.سناریو: استفاده از CloudFront یا Azure CDN برای کاهش فشار روی سرورها.چالش: اگه یه فایل تغییر کنه (مثلاً لوگوی سایت آپدیت بشه) چطور کش پاک شه؟3. کش درون حافظه ای( In-Memory Cache) برای داده‌های خاص سرور:مثلاً تو هر سرور، اطلاعات مربوط به session کاربرها رو تو MemoryCache نگه داریم.سناریو: کش کردن جزییات سبد خرید کاربر.چالش: این روش تو سیستم‌های توزیع‌شده، همگام‌سازی سخت‌تری داره.گام چهارم: حل مساله کش قدیمی (Stale Cache)یه روز صبح که چای می‌خوری، پشتیبانی زنگ می‌زنه:"قیمت محصولات تو سایت قدیمی نشون داده می‌شه!"مشکل از اینه که کش به موقع ریفرش(Refresh) نشده. چاره؟زمان انقضا (TTL): هر کشی باید عمر مشخصی داشته باشه.اتفاق‌محور: هر وقت دیتابیس آپدیت شد، کش هم ریست بشه.مثلاً با یه سیستم Event-Driven، تغییرات رو به Redis ارسال کنیم.گام پنجم: مدیریت منابع و سربار حافظهتیم می‌گه: "ردیس داره کلی رم می‌خوره. باید داده‌های کش شده رو مدیریت کنیم."الگوریتم LRU: کم‌استفاده‌ترین داده‌ها رو حذف کن.اندازه‌گیری حافظه: برای هر داده، اندازه مصرف حافظه رو بسنج.گام نهایی: یکپارچگی کش در پروژهدر نهایت، باید یه معماری کامل طراحی کنیم که کش تو همه لایه‌ها (اپلیکیشن، شبکه، و کلاد) بهینه عمل کنه. پیشنهاد:اپلیکیشن: MemoryCache برای داده‌های خاص سرور.شبکه: Redis برای داده‌های مشترک بین سرورها.کلاد: CDN برای کاهش فشار روی سرور.جمع‌بندی: تجربه "زودتر بخر" در کشبا یه استراتژی درست برای کش، تونستیم:زمان پاسخ‌دهی رو به شدت کاهش بدیم.هزینه‌های زیرساخت رو کم کنیم.تجربه کاربری عالی ارائه بدیم. Mostafa Akbarizadeh Mostafa Akbarizadeh Sun, 15 Dec 2024 11:29:13 +0330 https://virgool.io/@MostafaAkbarizadeh/%D9%88%D9%82%D8%AA%DB%8C-%D8%AF%D8%B1%D8%AE%D9%88%D8%A7%D8%B3%D8%AA-%D9%87%D8%A7-%D8%B5%D9%81-%D9%85%DB%8C-%DA%A9%D8%B4%D9%86-rate-limiting-throttling-%D9%88-%D9%86%D8%A8%D8%B1%D8%AF%DB%8C-%D8%A8%D8%B1-%D8%B3%D8%B1-%DA%A9%D9%86%D8%AA%D8%B1%D9%84-%D8%B3%DB%8C%D8%B3%D8%AA%D9%85-%D9%87%D8%A7-b14rj1vwkizo تا حالا شده بخواین وارد یه اپلیکیشن بشین، اما هر چی تلاش می‌کنین، هی پیام "Too Many Requests" جلوی چشمتون رژه بره؟ حس می‌کنین به جای اینکه کاربر باشین، به یه نفوذگر بدافزار تبدیل شدین! این همون اتفاقیه که یه Rate Limiting بد می‌تونه برای تجربه کاربری رقم بزنه. حالا بیاین ببینیم این داستان چی هست، چه تفاوتی با Throttling داره، و چطور می‌شه این دو رو به بهترین شکل استفاده کرد.Rate limiting محدودیت تعداد درخواست(Rate Limiting) : مرزها را مشخص کن، اما زیاده‌روی نکن!چیزی شبیه به این می‌گه: "آهای کاربر، شما فقط مجاز به ارسال 10 درخواست در هر دقیقه هستین؛ نه کمتر، نه بیشتر!" هدفش ساده‌ست: کنترل رفتر کاربران، جلوگیری از سوءاستفاده‌ها و محافظت از منابع.موارد استفاده:کنترل دسترسی کاربران: یه Spamer رو تصور کنید که می‌خواد توی یک ثانیه 1000 درخواست به API شما بزنه. با Rate Limiting، راحت می‌تونید بگین: "نه آقا، نوبت شما تموم شد!"محافظت از سیستم: برای جلوگیری از قفل شدن سیستم در برابر حملات یا درخواست‌های بیش از حد.مشکل کجاست؟یه روز خواستم اشتراک یه پلتفرم پخش فیلم رو بگیرم. وارد شدم، اما هر بار به خاطر یه لاگین اشتباه با پیام "Too Many Requests" مواجه شدم. بعد از چند تلاش ناموفق، خسته شدم و گفتم: "پلتفرمتون مال خودتون، بدرود!"کاهش نرخ پردازش(Throttling): سرعت رو کم کن، اما توقف نکن!برخلاف Rate Limiting، Throttling به جای اینکه درخواست‌ها رو رد کنه، سرعت پردازششون رو کم می‌کنه. مثلاً، اگر 1000 درخواست به سیستم برسه، به جای اینکه همه رو همزمان پردازش کنه، در هر لحظه فقط 100 درخواست رو انجام می‌ده.موارد استفاده:مدیریت ترافیک: وقتی حجم درخواست‌ها بالا میره، با Throttling می‌تونید سیستم رو زنده نگه دارین.بهبود تجربه کاربری: به جای اینکه کاربر با خطا مواجه بشه، بهش نشون بدین که درخواستش توی صفه و منتظر باشه. کدامش ؟ Rate Limiting یا Throttling آیا می‌توان همزمان از هر دو استفاده کرد؟بله، استفاده همزمان از Rate Limiting و Throttling نه تنها ممکن است، بلکه در بسیاری از سیستم‌های پیچیده توصیه می‌شود. هر یک مکمل دیگری است:محدودیت تعداد درخواست (Rate Limiting) : برای جلوگیری از رفتارهای غیرمجاز کاربران و کاهش بار سیستم. کاهش نرخ پردازش (Throttling) : برای مدیریت سرعت درخواست‌ها و تضمین پایداری در شرایط بحرانی.سناریوی ترکیبی:در یک API عمومی، Rate Limiting را تنظیم کنید تا هر کاربر حداکثر 1000 درخواست در روز ارسال کند.در همین حال، از Throttling استفاده کنید تا در ساعات اوج فقط 100 درخواست همزمان پردازش شوند. Mostafa Akbarizadeh Mostafa Akbarizadeh Wed, 11 Dec 2024 10:03:12 +0330 https://virgool.io/CTO-insight/%D9%86%D8%B8%D8%B1%D8%AA%D9%88%D9%86-%D8%AF%D8%B1%D8%A8%D8%A7%D8%B1%D9%87-%D8%AA%D8%B3%D8%AA-%D9%86%D9%88%DB%8C%D8%B3%DB%8C-%DA%86%DB%8C%D9%87-%D8%A8%DB%8C%D8%A7%DB%8C%D8%AF-%DB%8C%D9%87-%DA%86%D8%A7%D9%84%D8%B4-%D8%B1%D8%A7%D9%87-%D8%A8%D9%86%D8%AF%D8%A7%D8%B2%DB%8C%D9%85-%D9%88-%D8%A7%DB%8C%D9%86-%D9%87%DB%8C%D9%88%D9%84%D8%A7%DB%8C-%D8%AF%D9%88%D8%B3%D8%AA%D8%AF%D8%A7%D8%B4%D8%AA%D9%86%DB%8C-%D8%B1%D9%88-%D8%A7%D9%87%D9%84%DB%8C-%DA%A9%D9%86%DB%8C%D9%85-ys05eliutgh7 بیاید راستشو بگیم، وقتی حرف از تست‌نویسی می‌شه، بیشترمون قیافه می‌گیریم انگار یکی گفته "بیا ظرف‌ها رو بشور!" یه سری می‌گن: "وقت نداریم"، یه سری دیگه: "این واسه پروژه‌های خیلی بزرگه" و بعضیا هم کلاً: "حال نداریم." ولی خب، اگه تا حالا تو یه تیم فنی یا پروژه شخصی بودی، می‌دونی که بدون تست، هر تغییر کوچیک ممکنه مثل دومینوی خرابکاری همه چیز رو بریزه بهم!واقعیت اینه که ما تست‌نویسی رو جدی نمی‌گیریم چون بیشتر حواسمون به اینه که پروژه رو سریع تحویل بدیم، نه اینکه مطمئن باشیم بعدش زندگی آسون‌تری داریم. اما صبر کن! بیاید یه نگاهی به Unit Testing بندازیم و ببینیم چرا انقدر مهمه و چطوری می‌تونه کارمون رو متحول کنه.Unit Testing – Software Testingتست واحد (Unit Testing) چیه؟تصور کن داری یه ماشین می‌سازی. قبل از اینکه کل ماشین رو سرهم کنی، میای تک‌تک قطعاتش رو تست می‌کنی. چرخ‌ها رو می‌چرخونی، فرمان رو تکون می‌دی، مطمئن می‌شی ترمز درست کار می‌کنه. چرا؟ چون نمی‌خوای وسط جاده بفهمی یه جای کار می‌لنگه، درسته؟تست واحد هم همینه! یعنی هر بخش کوچیکی از کدت (مثل یه تابع، یه متد یا یه کلاس) رو جداگانه تست می‌کنی و می‌بینی همون‌طور که باید، کار می‌کنه. انگار داری به این قطعه کوچیک از کدت یه مُهر تضمین می‌زنی و می‌گی: "آی مردم! من مطمئنم که این بچه هر وقت اجرا بشه، یه چیزی رو خراب نمی‌کنه!" 😄چطوری باید تست واحد بنویسیم؟۱.توسعه مبتنی بر تست Test-Driven Development (TDD): این سبک رو وقتی دوست داری که می‌خوای خیلی شسته‌رفته کار کنی. اول تست می‌نویسی و بعد کد. شاید به نظرت عجیب بیاد، ولی این روش باعث می‌شه کمتر کد بزنی، چون دقیقاً می‌دونی چی می‌خوای.۲. شبیه‌سازی (Mocking): فرض کن داری یه سیستم پیچیده رو تست می‌کنی، ولی نمی‌خوای همه‌چیز رو بیاری تو تستت. اینجا از Mock استفاده می‌کنی؛ یعنی یه نسخه الکی (اما هوشمند) از قسمت‌هایی که نیاز داری، می‌سازی.۳. آزمون هرم (Pyramid Testing): این استراتژی می‌گه بیشتر تمرکزت روی تست‌های واحد باشه، بعد برو سراغ تست یکپارچه سازی(Integration) و بعد End-to-End. انگار داری یه هرم می‌سازیخب واقعاً چرا باید تست بنویسیم؟ بذار چند تا دلیل خفن برات بیارم:1. کیفیت بالا:با تست واحد، مطمئن می‌شی که هر تغییر کوچیکی تو کدت، سیستم رو به فنا نمی‌ده. یه جورایی خیال خودت و تیمت رو راحت می‌کنی که همه چیز سر جاشه.2. کمتر شدن باگ‌ها:تست‌نویسی دقیقاً مثل واکسن زدنه. شاید اولش وقت و انرژی بگیره، ولی بعداً جلوی مریضی‌های سنگین رو می‌گیره. باور کن پیدا کردن یه باگ تو محیط تولید مثل درمان سرماخوردگی نیست، بیشتر شبیه جراحی قلب بازه!3. اعتمادبه‌نفس:وقتی همه تست‌ها سبز بشن، حس می‌کنی یه ابرقهرمانی که می‌تونه با یه دست کد بزنه و با دست دیگه دنیا رو نجات بده. انگار کدت داره بهت می‌گه: "من آماده‌ام، بزن بریم!"4. سرعت در توسعه:شاید اولش فکر کنی تست‌نویسی سرعتت رو کم می‌کنه، ولی در درازمدت کمک می‌کنه کمتر وقتت رو روی رفع مشکلات تکراری بذاری و با خیال راحت پیش بری. مثل اینه که اول مسیر یه پلی بسازی تا لازم نباشه هر بار از رودخونه شنا کنی!همون‌طور که هر چیز خوبی یه سری چالش داره، تست‌نویسی هم بی‌ایراد نیست. بیایید منصف باشیم:1. وقت‌گیر:تست‌نویسی زمان می‌بره، مخصوصاً وقتی تیمت کوچیک باشه یا تحت فشار باشی که پروژه رو سریع تحویل بدی. انگار داری برای یه ماراتن آماده می‌شی، ولی کارفرما می‌خواد صد متر رو همون لحظه بدوی!2. نیاز به دانش فنی:نوشتن تست خوب، خودش یه هنره. مثل رانندگی نیست که با آزمون و خطا یادش بگیری؛ باید برایش وقت بذاری و یاد بگیری چی کجا تست بشه. اوایل شاید کمی چالش‌برانگیز باشه، ولی وقتی یاد بگیری، دیگه به کارت نمی‌آدازن.3. پوشش محدود:تست‌های واحد همه مشکلات رو نمی‌گیرن. مثل اینه که فقط چرخ‌های ماشین رو چک کنی، ولی موتور رو ندیده بگیری. برای اینکه همه چیز رو پوشش بدی، به تست‌های دیگری مثل Integration و End-to-End نیاز داری.کجاها Unit Testing کم‌فایده‌ست؟حقیقت اینه که تست‌نویسی همیشه هم راه‌حل مناسبی نیست. بعضی مواقع بهتره بدون دردسر پیش بری. مثلاً:1. پروژه‌های کوچیک:اگه پروژه کوچیکه و تغییراتش محدود، شاید نوشتن تست اصلاً ارزش وقت گذاشتن نداشته باشه. برای این جور مواقع، شاید به جای وقت گذاشتن روی تست‌ها، بهتر باشه سریع‌تر کد رو بنویسی و تمامش کنی.2. تیم‌های کوچک با منابع محدود:وقتی تیم کوچیکی داری و منابع (یعنی آدم و زمان) هم محدود، تست‌نویسی ممکنه اولویت بالایی نداشته باشه. در این شرایط باید انتخاب کنی که کجاها بیشتر به کار میاد و کجا می‌تونی فشاری که رو دوش تیم هست رو کمتر کنی.3. ددلاین‌های سنگین:وقتی مشتری می‌خواد "دیروز پروژه رو تحویل بگیره"، تست‌نویسی معمولاً می‌ره تو لیست اولویت‌ها و سقوط آزاد می‌کنه! این مواقع بیشتر دنبال تحویل سریع و بدون دردسر هستی تا اینکه بخوای وارد جزئیات تست بشی.تست‌نویسی همیشه عالی نیست، اما در خیلی از شرایط می‌تونه مثل یه ابرقهرمان عمل کنه که جلوی فاجعه‌ها رو می‌گیره.تجربه شخصیتو یکی از پروژه‌های بزرگ، تست‌نویسی رو جدی نگرفتیم. نه تنها تیم، بلکه بیشتر بچه‌ها اصلاً تسلط کاملی هم روی تست‌نویسی نداشتن. به عنوان یه تیم فنی همیشه فکر می‌کردیم که هر چی سریع‌تر پیش بریم و پروژه رو تموم کنیم، بهتره. درسته که پروژه بزرگ بود، ولی چون فکر می‌کردیم وقت نداریم، تست‌نویسی رو کنار گذاشتیم. نتیجه؟ هر بار که یه آپدیت جدید می‌دادیم، به جای اینکه فقط یه مشکل رو حل کنیم، یه عالمه مشکل دیگه هم از دلش بیرون می‌اومد!از اونجایی که ردیابی خطاها تو محیط پروداکشن یه مصیبت عظمایی که همه شما تجربه‌شو داشتین، این وضعیت برامون تبدیل به یه درس عبرت بزرگ شد. حس کردیم که این اشتباه، نه تنها کیفیت پروژه رو پایین آورد، بلکه زمان زیادی از تیم رو هم تلف کرد. Mostafa Akbarizadeh Mostafa Akbarizadeh Mon, 09 Dec 2024 20:36:01 +0330 https://virgool.io/CTO-insight/%DA%86%D8%B1%D8%A7-cohesion-%DB%8C%DA%A9%D9%BE%D8%A7%D8%B1%DA%86%DA%AF%DB%8C-%D9%88-coupling-%D9%88%D8%A7%D8%A8%D8%B3%D8%AA%DA%AF%DB%8C-%D9%85%D9%87%D9%85-%D8%A7%D9%86%D8%AF-lebbv4tqfygp Differences between Coupling and Cohesionتوی دنیای نرم‌افزار، همیشه یکسری اصول پایه‌ای بودن که شاید به ظاهر ساده و پیش‌پاافتاده به نظر برسن، ولی اگر عمیق‌تر نگاه کنیم، این اصول ستون‌های پنهان هر سیستم نرم‌افزاری قدرتمندن. مشکل اینجاست که این اصول اون‌قدر عادی شدن که خیلی از مهندسان نرم‌افزار کمتر بهشون توجه می‌کنن، یا بهتره بگم، مغفول می‌مونن.حالا چرا این موضوع مهمه؟ چون همین غفلت از اصول می‌تونه مثل یه بمب ساعتی عمل کنه و هر لحظه پروژه نرم‌افزاری شما رو به نابودی بکشونه. خیلی از Legacy System‌هایی که الان باهاشون دست‌وپنجه نرم می‌کنیم، دقیقاً به‌خاطر رعایت نکردن همین اصول به این حال‌وروز افتادن. باگ‌های عجیب، کدهای غیرقابل نگهداری، و سیستم‌هایی که به محض لمس شدن، مثل برج جِنگا فرو می‌ریزن، همه از این درد رنج می‌برن.حالا شاید بپرسین، این اصول چی هستن که این‌قدر مهمن؟ اجازه بدید وقتتون رو زیاد نگیرم و بریم سر اصل ماجرا. اینجا قراره با دو استاد بزرگ طراحی نرم‌افزار آشنا بشیم: Cohesion و Coupling. شاید اسمشون ساده به نظر بیاد، ولی این دو استاد طوری حرفه‌ای بازی می‌کنن که حتی باتجربه‌ترین مهندسان هم گاهی تو دامشون می‌افتن.پس بیاید این دو مفهوم کلیدی رو مثل دوستای قدیمی بشناسیم، چالش‌هاشون رو درک کنیم، و یاد بگیریم چطور با احترام و هوشمندی در کنار این دو، یه سیستم نرم‌افزاری بی‌نقص طراحی کنیم. 😉تصور کنید در حال طراحی یک نرم‌افزار بزرگ هستید؛ مثل یک فروشگاه اینترنتی یا یک سیستم مدیریت کتابخانه. این سیستم‌ها از بخش‌های مختلفی تشکیل شده‌اند که باید باهم کار کنند، اما اگر این بخش‌ها خیلی به هم وابسته باشند (یعنی یک تغییر کوچک در یکی از آن‌ها باعث شود کل سیستم به هم بریزد) یا اگر هر بخش خودش نداند دقیقا چه‌کار می‌کند، این پروژه تبدیل به یک کابوس واقعی می‌شود!اینجاست که دو مفهوم بسیار مهم به نام‌های Cohesion (یکپارچگی) و Coupling (وابستگی) وارد ماجرا می‌شوند.یکپارچگی Cohesion به ما می‌گوید که هر بخش از نرم‌افزار (یا ماژول) باید چقدر منسجم و یکپارچه باشد. چسبندگی Coupling نشان‌دهنده این است که ماژول‌ها چقدر به هم وابسته‌اند.هدف اصلی ما این است که Cohesion را تا می‌توانیم بالا ببریم و Coupling را تا حد ممکن پایین نگه داریم. حالا بیایید باهم ببینیم که این مفاهیم چه هستند و چرا این‌قدر مهم‌اند.مفهوم Cohesion: خودکفا و منظمیکپارچگی (Cohesion) یعنی عناصر داخل یک ماژول چقدر خوب با هم کار می‌کنند تا یک هدف مشخص را محقق کنند. وقتی می‌گوییم یک ماژول "High Cohesion" دارد، یعنی تمام عناصر آن فقط و فقط روی یک هدف مشخص تمرکز دارند. از طرف دیگر، اگر ماژولی "Low Cohesion" داشته باشد، یعنی درون خودش چند کار مختلف انجام می‌دهد که ممکن است به هم بی‌ربط باشند.مثال: ماژول مدیریت کاربرانفرض کنید یک سیستم داریم که ماژولی به نام "User Management" دارد. این ماژول کارهایی مثل ثبت‌نام (Register)، ورود (Login)، و خروج (Logout) را انجام می‌دهد. حالا تمام این عملیات‌ها حول محور یک هدف خاص یعنی مدیریت کاربران می‌چرخند. این یعنی High Cohesion.اما اگر همین ماژول بخواهد هم مدیریت کاربران انجام دهد، هم محصولات را اضافه کند، و هم گزارش‌های مالی تولید کند، در این حالت با یک ماژول "Low Cohesion" روبه‌رو هستیم. این وضعیت باعث می‌شود نه‌تنها فهمیدن کد سخت‌تر شود، بلکه تغییرات هم به‌راحتی ممکن است مشکلات جدیدی ایجاد کنند.مفهوم Coupling: وابستگی یا استقلال؟حالا بیایید به Coupling نگاه کنیم. Coupling یعنی اینکه دو ماژول چقدر به هم وابسته‌اند. اگر تغییر در یک ماژول باعث شود ماژول دیگر هم نیاز به تغییر داشته باشد، به این حالت High Coupling می‌گوییم. اما اگر ماژول‌ها مستقل از هم عمل کنند، این به معنای Low Coupling است.مثال: ماژول‌های کتاب و اعضا در یک کتابخانهفرض کنید یک سیستم کتابخانه داریم. دو ماژول داریم:ماژول مدیریت کتاب‌ها (Book Management): اضافه کردن و حذف کتاب.ماژول مدیریت اعضا (Member Management): اضافه کردن و حذف اعضا.این دو ماژول مستقل عمل می‌کنند و تغییر در یکی باعث نمی‌شود دیگری به مشکل بخورد. مثلا، اگر فرایند اضافه کردن کتاب تغییر کند، هیچ اثری روی فرایند اضافه کردن اعضا ندارد. این یعنی Low Coupling. اما اگر این دو ماژول برای کار کردن کاملا به هم متکی باشند، مثلا هر تغییری در مدیریت اعضا باعث شود کد مدیریت کتاب‌ها هم تغییر کند، این یعنی High Coupling.تفاوت‌های کلیدی بین Cohesion و Couplingبرای درک بهتر این دو مفهوم، بیایید تفاوت‌های اصلی‌شان را بررسی کنیم:Difference Between Cohesion and Couplingچرا High Cohesion و Low Coupling مهم است؟وقتی Cohesion بالا و Coupling پایین دارید:نگهداری و توسعه راحت‌تر است.تغییر در یک بخش باعث خراب شدن بخش‌های دیگر نمی‌شود.تست‌پذیری بهتر است.ماژول‌ها را می‌توان به‌صورت جداگانه تست کرد.درک کد ساده‌تر می‌شود.هر ماژول یک هدف مشخص دارد و دیگر نیازی به بررسی وابستگی‌های پیچیده نیست.انواع Cohesion و Couplingحالا که فهمیدیم Cohesion و Coupling چقدر مهم هستند، وقتشه کمی عمیق‌تر بشیم و انواع هر کدوم رو بررسی کنیم. این بخش مثل نقشه‌ایه که شما رو راهنمایی می‌کنه چطور ماژول‌هاتون رو طراحی کنید. هر نوع رو با مثال توضیح می‌دم که موضوع حسابی جا بیافته.انواع Cohesion: از بدترین تا بهترین! یکپارچگی (Cohesion) به ۷ نوع تقسیم می‌شه که از خیلی ضعیف شروع می‌شه و به خیلی قوی ختم می‌شه حالا بریم سراغ انواعش1.تصادفی (Coincidental Cohesion)وقتی عناصر یک ماژول هیچ ارتباط منطقی‌ای با هم ندارن و صرفا از روی شانس کنار هم جمع شدن.مثال: ماژولی دارید که توش هم یک فایل می‌سازید، هم به کاربر ایمیل می‌فرستید، هم یه API رو صدا می‌زنید. این‌ها هیچ ارتباطی به هم ندارن، ولی به‌صورت تصادفی کنار هم جمع شدن.مشکل: مثل گذاشتن سیب‌زمینی، کفش، و لپ‌تاپ توی یه کشو. بی‌ربط و گیج‌کننده!2. منطقی (Logical Cohesion)وقتی عناصر یک ماژول کارهای مرتبط انجام می‌دن ولی انتخاب کار به یک شرط منطقی وابسته‌ست.مثال: یک ماژول دارید که بسته به ورودی، یا به فایل می‌نویسه یا ایمیل ارسال می‌کنه یا دیتابیس رو به‌روز می‌کنه.مشکل: وابستگی به ورودی باعث می‌شه که فهمیدن کد و نگهداریش سخت بشه.3. زمانی (Temporal Cohesion)وقتی عناصر یک ماژول کارهایی رو انجام می‌دن که در یک زمان خاص باید انجام بشه.مثال: یک ماژول که وقتی کاربر لاگین می‌کنه، کوکی رو ذخیره می‌کنه، لاگ رو ثبت می‌کنه، و تاریخچه رو آپدیت می‌کنه.مشکل: این کارها به زمان وابسته هستن، نه به هدف مشخص.4. رویه‌ای (Procedural Cohesion)وقتی عناصر ماژول به‌خاطر ترتیب و مراحل خاصی کنار هم هستن.مثال: ماژولی که اول داده‌ها رو بخونه، بعد اعتبارسنجی کنه، و بعد اون‌ها رو در دیتابیس ذخیره کنه.مشکل: هنوز هدف مشخصی دیده نمی‌شه؛ فقط رویه مشخصه.5. ارتباطی (Communicational Cohesion)وقتی عناصر ماژول با استفاده از داده‌های مشترک کارهای متفاوتی انجام می‌دن.مثال: ماژولی که برای یک سفارش، هم تخفیف محاسبه می‌کنه و هم مالیات رو.مشکل: بهتره این دو کار رو جدا کنیم؛ چون هر دو به داده سفارش نیاز دارن، اما هدف متفاوتی دارن.6. کارکردی (Functional Cohesion)وقتی همه عناصر ماژول برای رسیدن به یک هدف خاص کار می‌کنن.مثال: ماژول محاسبه قیمت نهایی که تخفیف، مالیات، و هزینه حمل‌ونقل رو با هم ترکیب می‌کنه.مزیت: بهترین نوع Cohesion که باعث نظم و استقلال ماژول می‌شه.7. توالی‌ای (Sequential Cohesion)وقتی خروجی یک عنصر مستقیماً ورودی عنصر دیگه باشه.مثال: ماژول پردازش تصویر که اول تصویر رو بخونه، بعد فشرده کنه، و بعد ذخیره کنه.مزیت: نزدیک به Functional Cohesion و بسیار مناسب.انواع Coupling: از بدترین تا بهترین!حالا بریم سراغ Coupling. این مفهوم هم به انواع مختلفی تقسیم می‌شه که از خیلی وابسته شروع می‌شه و به مستقل‌ترین حالت ختم می‌شه.1. محتوایی (Content Coupling)وقتی یک ماژول مستقیم به کد داخلی ماژول دیگه دسترسی داره.مثال: ماژول A مستقیماً یک متغیر خصوصی (Private) در ماژول B رو تغییر بده.مشکل: این بدترین نوع Coupling هست. تغییر در یکی، کل سیستم رو خراب می‌کنه.2. اشتراکی (Common Coupling)وقتی دو ماژول از یک متغیر یا منبع مشترک استفاده می‌کنن.مثال: دو ماژول به یک متغیر Global دسترسی دارن و مقدارش رو تغییر می‌دن.مشکل: شبیه به دعوا سر کنترل تلویزیون؛ هرکی کانال رو عوض کنه، بقیه شاکی می‌شن.3. بیرونی (External Coupling)وقتی دو ماژول به یک واسط یا سیستم خارجی وابسته باشن.مثال: ماژول پرداخت آنلاین و ماژول سفارش که هردو به یک Gateway پرداخت وابسته هستن.مشکل: وابستگی به ابزار خارجی می‌تونه خطرساز باشه.4.کنترلی (Control Coupling)وقتی یک ماژول به ماژول دیگه بگه دقیقاً چه کاری انجام بده.مثال: ماژول A به ماژول B یک Flag بفرسته که بگه با این مقدار خاص کار کن.مشکل: تغییرات در Flag نیازمند تغییر در هر دو ماژول هست.سؤال چالش‌برانگیز: آیا می‌شود همه‌چیز ایده‌آل باشد؟خب، حقیقت این است که همیشه نمی‌توان به Low Coupling و High Cohesion به‌طور کامل دست یافت. گاهی وابستگی‌هایی بین ماژول‌ها وجود دارند که اجتناب‌ناپذیرند. اما هدف این است که این وابستگی‌ها را تا جای ممکن کاهش دهیم.جمع‌بندیبه‌طور خلاصه، Cohesion و Coupling دو مفهوم کلیدی در طراحی نرم‌افزار هستند که اگر درست رعایت شوند، می‌توانند سیستم‌های نرم‌افزاری ما را قابل‌اعتمادتر، مقیاس‌پذیرتر و آسان‌تر برای نگهداری کنند. در طراحی‌های بعدی‌تان، همیشه تلاش کنید ماژول‌هایتان را با Cohesion بالا و Coupling پایین طراحی کنید. این کار، مثل استفاده از یک دستور آشپزی دقیق، نتیجه کار را خوشمزه‌تر می‌کنه! 😄 Mostafa Akbarizadeh Mostafa Akbarizadeh Sun, 08 Dec 2024 07:57:15 +0330 https://virgool.io/CTO-insight/%DA%86%D8%B1%D8%A7-%D8%AC%D9%85%D8%B9-%D8%A2%D9%88%D8%B1%DB%8C-%D9%86%DB%8C%D8%A7%D8%B2%D9%85%D9%86%D8%AF%DB%8C-%D9%87%D8%A7-%D8%A7%DB%8C%D9%86-%D9%82%D8%AF%D8%B1-%D9%85%D9%87%D9%85-%D8%A7%D8%B3%D8%AA-%DB%8C%DA%A9-%DA%AF%D9%BE-%D8%AF%D9%88%D8%B3%D8%AA%D8%A7%D9%86%D9%87-%D8%A8%D8%A7-%D8%B4%D9%85%D8%A7-l4n9otbdgjiu Requirements Gathering in Software Developmentسلام دوستان عزیزم ! بذارین یه داستان براتون تعریف کنم که شاید پروژه بعدیتون از کلی دردسر نجاتتون بده. موضوعش Requirements Gathering یا همون جمع‌آوری نیازمندی‌هاست. نترسین، قول میدم خشک و کسل‌کننده نباشه. می‌خوام بگم چرا این مرحله اونقدر مهمه که می‌تونه یه پروژه رو از موفقیت به فاجعه برسونه یا بالعکس. آماده‌ای؟ بزن بریم!مرحه اول: Identify Stakeholders – کی کیه؟خب اول از همه، باید بفهمیم چه کسایی از پروژه استفاده می‌کنن و چه کسایی قراره نظر بدن. از کاربر نهایی گرفته تا مدیر پروژه، همه باید تو این مرحله صداشون شنیده بشه.تصورش کنین: دارین یه برنامه مدیریت محتوا (CMS) طراحی می‌کنیم. Content Creators هامی‌خوان محیط کاربری ساده باشه، Editor ها دنبال تأیید محتوا قبل از انتشارن، و تیم IT هم می‌خواد زیرساخت قوی باشه. هر کسی یه چیزی می‌خواد و اینجاست که همه رو دور یه میز می‌نشونیم.مرحله دوم: Define Objectives and Scope – چی می‌خوایم بسازیم؟تو این مرحله، باید دقیقاً مشخص کنیم هدف سیستم چیه و پروژه قراره چه کارایی انجام بده.اینجا مثل اینه که داری نقشه گنج می‌کشیم. اگه ندونیم دنبال چی می‌گردیم، سر از ناکجاآباد در میاریم! به عبارتی، Define clear objectives and scope تا پروژه از مسیرش خارج نشه.مرحله سوم: Conduct Interviews and Workshops – بزن بریم مصاحبه!حالا وقتشه که بریم سراغ ذینفع‌ها و باهاشون صحبت کنیم. باهاشون مصاحبه کنیم، ورکشاپ راه بندازیم یا حتی یه فنجون چای بخوریم و گپ بزنیم! تو این مرحله، باید بفهمیم واقعاً چی می‌خوان. سوالات باز بپرسیم تا چیزی رو از قلم نندازیم. اینجا می‌خواییم با تکنیک‌های Interviews and Workshops حرفای دلشون رو بخونیم. 😉مرحله چهارم: Document Requirements – همه چیزو بنویس!حالا که اطلاعات جمع شد، وقتشه همه چیزو مرتب و مستند کنیم. می‌تونیم از Use Cases، User Stories، یا حتی Functional Requirements Specifications (FRS) و Non-Functional Requirements Specifications (NFRS) استفاده کنیم.اینو یادتون باشه: مستندات باید واضح، مختصر و بدون ابهام باشن، وگرنه وسط پروژه داد همه درمیاد که «این چیزی نبود که ما می‌خواستیم!»مرحله پنجم: Prioritize Requirements – چی از همه مهم‌تره؟وقتی همه چیزو نوشتیم، وقتشه که نیازمندی‌ها رو اولویت‌بندی کنیم. از تکنیک‌هایی مثل MoSCoW Prioritization استفاده کنیم:Must have: بدون ایناها سیستم فایده‌ای نداره.Should have: خیلی مهمن ولی بدونش هم می‌تونیم زندگی کنیم.Could have: اگه بود خوبه، اگه نبود هم کسی شکایت نمی‌کنه.Won’t have: باشه برای بعد!مرحله ششم: Validate Requirements – یه دور چک کنیم!الان وقتشه که هر چی نوشتیم رو با ذینفع‌ها چک کنیم. اگه اختلاف نظر یا ابهامی هست، همین حالا حلش کنیم. یه Validation Session خوب می‌تونه کلی دردسر آینده رو کم کنه. حتماً مطمئن بشیم که نیازمندی‌ها ، نیاز واقعی و دقیق رو منعکس می‌کنند.مرحله هفتم: Iterate and Refine – تا می‌تونی بهترش کنیم!یه نکته طلایی: جمع‌آوری نیازمندی‌ها خط صاف نیست؛ بیشتر شبیه یه مسیر پرپیچ‌وخم و پر ماجراست. پس آماده باشیم که چندین بار Iterate and Refine کنیم. هیچ‌وقت نگا نکنیم که این تغییرات نشونه ضعف هستن؛ نشونه اینه که پروژه داره زنده پیش میره.مرحله هشتم: Manage Requirements Changes – تغییرات رو مدیریت کنیم!یکی از بزرگ‌ترین دردسرهای پروژه‌ها همینه: Scope Creep یا همون زیاد شدن بی‌برنامه نیازمندی‌ها. پس یه سیستم تغییرات مثل Change Control Mechanism داشته باشیم تا همه تغییرات رو ارزیابی، تأیید و ردیابی کنیم.مرحله نهم: Review and Approval – امضا بگیریم!م: Communication and Collaboration – مثل یک تیم کار کنید!م. اینجوری وقتی وسط کار کسی ایراد گرفت، می‌تونیم بگیمم: «همینه که هست، خودتون امضا کردید!» 😄مرحله دهم: Communication and Collaboration – مثل یک تیم کار کنیم!آخرین و شاید مهم‌ترین نکته: Communication and Collaboration رو فراموش نکنیم. پروتوتایپ درست کنیم، از ابزارهای تصویری استفاده کنیم، و مطمئن بشین همه تو جریانن. همه چیز وقتی خوب پیش میره که همه هم‌راستا باشن.چرا باید این همه زحمت بکشیم؟ببین، اگه نیازمندی‌ها درست جمع نشه:پروژه از مسیرش خارج میشه،کلی وقت و پول حروم میشه،در نهایت محصولی ساخته میشه که به درد هیچ‌کس نمی‌خوره.ولی اگه این مرحله درست انجام بشه:محصول دقیقاً مطابق انتظارات کارفرما میشه(Alignment with Stakeholder Needs)کسی نمی‌تونه بگه «من فکر می‌کردم اینو می‌سازید!» (Clear Understanding of Project Scope)مشکلات را با چشم باز از ابتدا میشناسیم و راه حل میدیم (Identification of Risks and Constraints) همه تیم یه زبان مشترک پیدا می‌کنن( Improved Communication)وقت و منابعمون به هدر نمیره (Efficient Resource Allocation)یه مثال واقعی: جمع‌آوری نیازمندی‌ها برای یک Fitness Appخب، فرض کن قراره یه اپلیکیشن Fitness Tracking بسازیم. توی مرحله Identify Stakeholders ما می‌فهمیم که مشتری‌ها دنبال این هستن که فعالیت‌های ورزشی‌شون رو راحت‌تر ثبت کنن و اون‌ها را پیگیری کنن. حالا این مرحله به معنی شناسایی ذینفعان پروژه‌ست. هر پروژه نرم‌افزاری آدم‌ها و گروه‌هایی داره که یا از نتیجه نهایی پروژه تأثیر می‌گیرن یا به نوعی می‌تونن روند پروژه رو تحت تأثیر بذارند.حالا بیایید کمی دقیق‌تر بگیم این ذینفعان چی هستند:کاربران نهایی (End-users): یعنی همون افرادی که قراره از اپ استفاده کنن. تمام نیازها و تجربیات این افراد باید اولویت اول تیم توسعه باشه.مدیران (Managers): این‌ها کسانی هستن که تصمیمات کلیدی می‌گیرن. ممکنه به گزارش‌ها و اطلاعات مدیریتی نیاز داشته باشن که بتونن پروژه رو پیگیری کنن و به درستی مدیریت کنن.مشتریان (Clients): این‌ها همون کسانی هستن که در نهایت اپلیکیشن به اون‌ها تحویل داده میشه. انتظار دارن که اپ دقیقاً نیازها و خواسته‌های خاص‌شون رو برآورده کنه.توسعه‌دهندگان (Developers): این تیم‌های فنی هستن که قراره این اپلیکیشن رو بسازن. تخصص‌شون تو کدنویسی و پیاده‌سازی سیستمه.متخصصین حوزه (Subject Matter Experts): این افراد ممکنه تو زمینه‌هایی مثل تکنولوژی، صنعت یا فرآیندهای تجاری تخصص داشته باشن و می‌تونن مشاوره‌های فنی یا راهکارهای کاربردی به تیم بدن.گروه‌های پشتیبانی و IT: کسانی که بعد از پیاده‌سازی مسئول نگهداری، آپدیت و پشتیبانی از سیستم هستن.شناسایی این ذینفعان به تیم توسعه کمک می‌کنه تا دقیقاً متوجه بشن که هرکسی چی می‌خواد و چطور می‌تونن نیازهاشون رو درست جمع‌آوری کنن. این کار باعث میشه در آینده مشکلات و سوء تفاهم‌ها کمتر بشه و پروژه به خوبی پیش بره.حالا توی مرحله Document Requirements باید مشخص کنیم که سیستم باید Personalized Recommendations ارائه بده. این یعنی به هر کاربر بر اساس علایق و رفتارهای خاص خودش پیشنهادهایی داده بشه. مثلا فرض کن یک کاربر دنبال رژیم غذایی برای کاهش وزن باشه. سیستم می‌تونه پیشنهاد بده که بر اساس تاریخچه تمرینی و اهداف شخصی‌ش، بهترین برنامه‌های تمرینی و غذایی برای اون طراحی بشه.هدف از این پیشنهادات اینه که تجربه کاربری به شدت بهبود پیدا کنه. وقتی کاربر می‌بینه که سیستم دقیقاً می‌دونه چی می‌خواد، احساس می‌کنه که تجربه‌ای منحصر به فرد داره.حالا توی Prioritize Requirements هم باید مشخص کنیم که چطور این نیازمندی‌ها رو اولویت‌بندی کنیم. این یعنی این که کدوم ویژگی‌ها یا نیازمندی‌ها می‌تونن به تأخیر بیفتند یا اصلاً پیاده‌سازی نشن. این کار کمک می‌کنه که تیم منابع، زمان و انرژی‌ش رو به درستی تخصیص بده.جمع‌بندی: هنر جمع‌آوری نیازمندی‌هادوست من، جمع‌آوری نیازمندی‌ها یک هنره. اگه این هنر رو درست انجام بدی، پروژه‌ت یه اثر هنری میشه که همه عاشقش میشن. حالا دست‌به‌کار شو و دفعه بعدی که پروژه گرفتی، این مراحل رو دقیق اجرا کن. موفق باشی! 💪 Mostafa Akbarizadeh Mostafa Akbarizadeh Sat, 07 Dec 2024 09:52:30 +0330 https://virgool.io/CTO-insight/%D8%B7%D8%B1%D8%A7%D8%AD%DB%8C-%D8%B3%DB%8C%D8%B3%D8%AA%D9%85-%DA%86%D8%B1%D8%A7-%D8%A7%D9%87%D9%85%DB%8C%D8%AA-%D8%AF%D8%A7%D8%B1%D8%AF-frwxzbb1uyg4 System Designمقدمهدر دنیای توسعه نرم‌افزار، طراحی سیستم (System Design) به‌عنوان یکی از پایه‌های اصلی موفقیت یک پروژه شناخته می‌شود. هدف از طراحی سیستم، ایجاد یک معماری جامع، تعریف کامپوننت‌های اصلی و طراحی رابط‌هایی است که بتوانند نیازهای کاربران نهایی را به بهترین شکل برآورده کنند. اما چرا طراحی سیستم این‌قدر اهمیت دارد؟ و چگونه می‌توان یک سیستم را به گونه‌ای طراحی کرد که هم پایداری، هم مقیاس‌پذیری (Scalability) و هم قابلیت نگهداری (Maintainability) داشته باشد؟این مقاله به بررسی عمیق اهمیت طراحی سیستم در توسعه نرم‌افزار پرداخته و نکات فنی و تجربی مرتبط با این حوزه را معرفی می‌کند.1. تعریف طراحی سیستمطراحی سیستم فرایند تعیین ساختار کلی یک سیستم نرم‌افزاری است که شامل تصمیم‌گیری درباره معماری (Architecture)، کامپوننت‌ها (Components)، و نحوه ارتباط میان آن‌ها (Interfaces) می‌شود.این طراحی شامل دو سطح اصلی است: طراحی سطح بالا High-Level Design (HLD) تمرکز بر معماری کلی، شناسایی کامپوننت‌های بزرگ مانند سرویس‌ها، دیتابیس‌ها و ارتباطات بین آن‌ها. طراحی سطح پایین Low-Level Design (LLD) جزئیات داخلی هر کامپوننت مانند ساختار داده‌ها، الگوریتم‌ها و منطق داخلی.2. اهمیت طراحی سیستم در توسعه نرم‌افزارقابلیت مقیاس‌پذیری (Scalability):هر سیستم نرم‌افزاری که در محیط تولید (Production) اجرا می‌شود، با چالش‌هایی مانند افزایش ترافیک یا نیاز به منابع بیشتر روبه‌رو خواهد شد. طراحی سیستمی که بتواند به‌راحتی منابع بیشتری اضافه کند (مانند Scaling Out با افزایش سرورها) یا منابع موجود را بهینه‌تر استفاده کند، کلید موفقیت است.پایداری (Reliability):سیستم‌هایی که به طور مکرر دچار خرابی می‌شوند، اعتماد کاربران را از بین می‌برند. طراحی خوب باید Fault Tolerance را مدنظر قرار دهد، مانند استفاده از Load Balancer یا Replication برای اطمینان از دسترسی‌پذیری بالا (High Availability).قابلیت نگهداری و توسعه (Maintainability & Extensibility):طراحی ضعیف باعث پیچیدگی بیش از حد در توسعه و رفع مشکلات می‌شود. یک معماری مدولار (Modular Architecture) و استفاده از اصول SOLID، سیستم را برای تغییرات آینده آماده می‌کند.3. تأثیر طراحی ضعیف بر سیستم‌هاطراحی ضعیف سیستم می‌تواند منجر به مشکلات زیر شود:گلوگاه (Bottleneck) در عملکرد: یک نقطه‌ضعف در سیستم که باعث کاهش سرعت پردازش کل می‌شود.عدم مقیاس‌پذیری: نیاز به بازطراحی کامل سیستم با افزایش کاربران.هزینه‌های بالای نگهداری: کد پیچیده و غیرقابل تغییر که زمان توسعه را افزایش می‌دهد.خرابی‌های مکرر: عدم وجود Backup یا Recovery مناسب، که باعث از دست رفتن داده‌ها یا کاهش اعتماد کاربران می‌شود.4. ویژگی‌های یک طراحی سیستم ایده‌آلبرای داشتن یک سیستم کارآمد و حرفه‌ای، باید اصول زیر رعایت شود: ماجولاریتی Modularity:سیستم به ماژول‌های مستقل تقسیم شود تا تغییرات در یک بخش، تأثیری بر بخش‌های دیگر نگذارد. بهینه سازی تاخیر Latency Optimization:بهینه‌سازی تاخیر (Latency) از طریق استفاده از Caching یا نزدیک‌کردن سرورها به کاربران (CDN). مقیاس پذیری Scalability:استفاده از Partitioning و Sharding برای مقیاس‌پذیری دیتابیس‌ها و استفاده از Load Balancing برای مدیریت بار. مانیتورینگ Observability:اضافه‌کردن لاگ‌ها (Logs)، متریک‌ها (Metrics) و Tracing برای بررسی و رفع مشکلات سیستم. در دسترس بودن بالا High Availability:طراحی با استفاده از Replication، Failover و تکنیک‌های Disaster Recovery.5. مراحل اولیه طراحی سیستمهنگام شروع طراحی یک سیستم، باید به سوالات کلیدی زیر پاسخ دهید:چه مقدار بار (Load) را انتظار دارید؟تعداد درخواست‌ها در ثانیه (Requests per Second) یا اندازه داده‌ها.چه سطحی از پایداری و دسترس‌پذیری نیاز دارید؟آیا سیستم باید 24/7 بدون Downtime کار کند؟چه داده‌هایی نیاز به ذخیره‌سازی دارند؟نوع داده‌ها (Structured vs Unstructured) و روش ذخیره‌سازی (SQL vs NoSQL).6. نگاهی به آیندهدر مقالات بعدی، به بررسی دقیق هر یک از این مفاهیم خواهیم پرداخت:طراحی سیستم‌های توزیع‌شده (Distributed Systems)الگوریتم‌های مقیاس‌پذیری دیتابیس (Database Sharding)بهینه‌سازی عملکرد با استفاده از Cachingمدیریت Fault Tolerance و High Availabilityاین سفر یادگیری، شما را از اصول ابتدایی تا تکنیک‌های پیشرفته در طراحی سیستم همراهی خواهد کرد.نتیجه‌گیری:طراحی سیستم، هنر ترکیب دانش فنی، خلاقیت و تجربه برای ایجاد سیستمی است که نیازهای حال و آینده کاربران را برآورده کند. با درک عمیق مفاهیم و استفاده از ابزارها و تکنیک‌های مناسب، می‌توانید سیستمی بسازید که نه‌تنها عملکرد بالایی داشته باشد، بلکه قابلیت توسعه و مقیاس‌پذیری در شرایط مختلف را نیز دارا باشد.منتظر مقالات بعدی من در مورد همین موضوع باشید! Mostafa Akbarizadeh Mostafa Akbarizadeh Tue, 03 Dec 2024 08:09:43 +0330 https://virgool.io/CTO-insight/%DA%86%DA%AF%D9%88%D9%86%D9%87-%D8%A8%D8%A7-opentelemetry-%D8%B3%DB%8C%D8%B3%D8%AA%D9%85-%D9%87%D8%A7%DB%8C-%D9%85%DB%8C%DA%A9%D8%B1%D9%88%D8%B3%D8%B1%D9%88%DB%8C%D8%B3%DB%8C-%D8%B1%D8%A7-%D8%A8%DB%8C-%D9%86%D9%82%D8%B5-%D8%B1%D8%AF%DB%8C%D8%A7%D8%A8%DB%8C-%DA%A9%D9%86%DB%8C%D9%85-v7g8uamc2sqx چالش‌های ردیابی در سیستم‌های میکروسرویسیسیستم‌های میکروسرویسی با وجود مزایای زیادی مانند انعطاف‌پذیری، مقیاس‌پذیری و قابلیت استقرار مستقل، چالش‌های جدیدی را در زمینه مانیتورینگ و رفع خطاها ایجاد می‌کنند. برخلاف معماری‌های یکپارچه (Monolithic)، که تمام بخش‌های سیستم در یک مکان متمرکز هستند، میکروسرویس‌ها به دلیل توزیع‌شدگی اجزای خود، بررسی جریان درخواست‌ها و شناسایی خطاها را دشوار می‌سازند. در این سیستم‌ها، هر درخواست ممکن است از چندین سرویس عبور کند، و تشخیص منشأ خطا نیازمند ابزاری دقیق و استاندارد است.چرا ردیابی توزیع‌شده مهم است؟کشف مشکلات پیچیده: در یک سیستم میکروسرویسی، خطا ممکن است در یکی از سرویس‌ها رخ دهد اما تأثیر آن در سرویس‌های دیگر ظاهر شود.مدیریت عملکرد: برای بهبود تجربه کاربر، باید بدانیم کدام سرویس باعث تأخیر در پاسخ‌دهی شده است.شناسایی نقاط شکست: به کمک ردیابی، می‌توان نقاط حساس و بحرانی سیستم را پیدا کرد و از خرابی‌های بزرگ جلوگیری کرد.راه‌حل‌ها برای ردیابی، مانیتورینگ و رفع خطا در میکروسرویس‌ها1. ردیابی توزیع‌شده (Distributed Tracing)نحوه کارکرد: در این روش، هر درخواست یک شناسه یکتا (Trace ID) دریافت می‌کند که با آن می‌توان کل مسیر درخواست را از ابتدا تا انتها دنبال کرد. این شناسه به تمامی سرویس‌هایی که درخواست از آن‌ها عبور می‌کند، اضافه می‌شود.ابزارهای کلیدی:OpenTelemetry: یک استاندارد باز برای جمع‌آوری داده‌های ردیابی، متریک‌ها و لاگ‌ها.Jaeger: برای ذخیره‌سازی و نمایش Traceها.Zipkin: ابزاری مشابه Jaeger برای ردیابی درخواست‌ها در سیستم‌های توزیع‌شده.2. مانیتورینگ متریک‌هانحوه کارکرد: متریک‌ها داده‌های عددی هستند که وضعیت عملکرد سیستم را نمایش می‌دهند (مانند زمان پاسخ‌دهی، تعداد درخواست‌ها و غیره).ابزارهای کلیدی:Prometheus: ابزاری قدرتمند برای ذخیره و کوئری متریک‌ها.Grafana: برای نمایش گرافیکی داده‌های جمع‌آوری‌شده توسط Prometheus.3. سیستم‌های لاگینگ متمرکزنحوه کارکرد: لاگ‌ها اطلاعاتی در مورد وضعیت داخلی سرویس‌ها ارائه می‌دهند و برای رفع خطا حیاتی هستند.ابزارهای کلیدی:ELK Stack (Elasticsearch, Logstash, Kibana): یک راه‌حل کامل برای ذخیره، پردازش و نمایش لاگ‌ها.Fluentd: جایگزینی برای Logstash که برای پردازش داده‌های لاگ استفاده می‌شود.4. ردیابی خطاها (Error Tracking)نحوه کارکرد: این سیستم‌ها به شما کمک می‌کنند خطاهای سیستم را جمع‌آوری و بررسی کنید.ابزارهای کلیدی:Sentry: ابزاری برای شناسایی و گزارش خطاها.Raygun: مشابه Sentry اما با تمرکز بیشتر روی تجربه کاربر.https://opentelemetry.io/docs/معماری و استقرار ابزارها در محیط میکروسرویسیپیکربندی OpenTelemetry:در هر سرویس، SDK مربوط به OpenTelemetry نصب می‌شود. سپس، پروایدر ردیابی (Trace Provider) به آن متصل شده و داده‌ها را به سرور مرکزی (مانند Jaeger) ارسال می‌کند.ادغام Prometheus و Grafana:سرویس‌ها با اکسپوز کردن متریک‌ها (به کمک endpointهای HTTP) داده‌های خود را برای Prometheus قابل دسترسی می‌کنند. این داده‌ها در Grafana به صورت داشبوردهای زیبا نمایش داده می‌شوند.راه‌اندازی ELK Stack:لاگ‌های جمع‌آوری‌شده از سرویس‌ها به Logstash ارسال می‌شود. سپس، داده‌ها در Elasticsearch ذخیره شده و در نهایت از طریق Kibana نمایش داده می‌شوند.نمونه کامل ردیابی توزیع‌شده در سیستم‌های میکروسرویسی با .NET Core و OpenTelemetryمعماری پروژه و ابزارهاOpenTelemetry برای ردیابی توزیع‌شده.Jaeger برای مشاهده و تحلیل داده‌های ردیابی.ASP.NET Core برای توسعه میکروسرویس‌ها.PostgreSQL برای ذخیره‌سازی داده‌ها.Docker برای استقرار ابزارها.Adding OpenTelemetry to .NET ApplicationsconfigureDistributed TracingPublishing a message with MassTransitExamining additional trace informationنتیجه‌گیریردیابی توزیع‌شده و مانیتورینگ پیشرفته نه‌تنها باعث بهبود عملکرد سیستم‌های میکروسرویسی می‌شوند، بلکه از طریق شناسایی مشکلات، هزینه‌های نگهداری را کاهش می‌دهند. ابزارهایی مانند OpenTelemetry، Prometheus، Jaeger و ELK Stack به توسعه‌دهندگان کمک می‌کنند تا دید کاملی نسبت به سیستم داشته باشند و در مواقع بحرانی، به‌سرعت مشکل را برطرف کنند. Mostafa Akbarizadeh Mostafa Akbarizadeh Mon, 02 Dec 2024 11:23:05 +0330 https://virgool.io/CTO-insight/%DA%A9%D8%A7%D9%87%D8%B4-%D8%AA%D8%A7%D8%AE%DB%8C%D8%B1-latency-%D8%AF%D8%B1-%D9%85%DB%8C%DA%A9%D8%B1%D9%88%D8%B3%D8%B1%D9%88%DB%8C%D8%B3-%D9%87%D8%A7-gq9jhxevggak تصور کنید یک کاربر به سایت شما سر زده تا خریدی انجام بده. وارد صفحه محصول میشه، کمی گشت می‌زنه، محصول مورد نظرش رو انتخاب می‌کنه، اما... صفحه پرداخت چند ثانیه بیشتر از حد معمول طول می‌کشه تا لود بشه. نتیجه؟ کاربر خسته میشه و خرید رو نیمه‌کاره رها می‌کنه. حالا این چند ثانیه چقدر هزینه داره؟در دنیای دیجیتال امروز، صبر کاربران کمتر از همیشه شده. وقتی چیزی کند میشه، احساس ناراحتی فوراً جایگزین تجربه کاربری خوب میشه.برای میکروسرویس‌ها، این مسئله حتی پیچیده‌تره. میکروسرویس‌ها مثل گروهی از موزیسین‌ها هستن که هر کدوم یک ساز رو می‌زنن، اما برای اینکه یک موسیقی هماهنگ تولید بشه، باید همه با ریتم درست کار کنن. حالا تصور کنید یکی از موزیسین‌ها (یعنی یکی از میکروسرویس‌ها) کمی کندتر باشه؛ این باعث میشه کل قطعه بهم بخوره. در دنیای میکروسرویس‌ها، یه تاخیر کوچیک در یکی از سرویس‌ها می‌تونه مثل دومینو روی همه سیستم تاثیر بذاره.چرا کاهش Latency اینقدر مهم است؟Latency در میکروسرویس‌ها فقط یک چالش فنی نیست، بلکه تأثیر مستقیمی روی تجربه کاربری، هزینه‌های عملیاتی، و توانایی مقیاس‌پذیری سیستم دارد. در ادامه دلایل اهمیت آن را بررسی می‌کنیم:تجربه کاربری بهترکاربران انتظار پاسخ سریع دارند. هر ثانیه تأخیر می‌تواند باعث رها کردن سرویس و کاهش رضایت مشتریان شود. در صنعت‌هایی مانند تجارت الکترونیک یا بازی‌های آنلاین، این موضوع حیاتی است.بالاترین کاراییعملکرد بهتر زمانی رخ می‌دهد که ارتباطات بین سرویس‌ها سریع‌تر و بهینه‌تر باشد. این موضوع نه‌تنها سرعت سیستم را بالا می‌برد، بلکه مصرف منابع را کاهش می‌دهد.مقیاس‌پذیری (Scalability)میکروسرویس‌ها برای مقیاس‌پذیری طراحی شده‌اند. اگر یک بخش از سیستم دچار Latency شود، گلوگاه ایجاد می‌شود که کل سیستم را مختل می‌کند.کاهش هزینه‌هامنابع بیشتر یعنی هزینه‌های بیشتر. کاهش Latency یعنی استفاده بهینه از منابع، که در نهایت به کاهش هزینه‌های سخت‌افزاری و زیرساختی منجر می‌شود.پردازش آنی داده‌ها (Real-Time Processing)در سیستم‌هایی که نیاز به پردازش داده‌ها در لحظه دارند، مثل سیستم‌های مالی، هرگونه تأخیر غیرقابل قبول است و به‌سرعت مشکلات بزرگی ایجاد می‌کند.دلایل رایج Latency در میکروسرویس‌هابرای کاهش Latency، ابتدا باید دلایل رایج آن را بشناسیم. در زیر برخی از مهم‌ترین این دلایل آورده شده است:ارتباطات بین سرویس‌ها (Service-to-Service Communication)ارتباطات ناهمزمان، درخواست‌های شبکه‌ای سنگین، یا فاصله جغرافیایی بین سرویس‌ها، از عوامل اصلی ایجاد تأخیر در انتقال داده‌ها هستند.تماس‌های بیش از حد (Excessive Service Calls)وقتی میکروسرویس‌ها بیش از حد با هم ارتباط برقرار می‌کنند، زمان کلی پاسخگویی سیستم افزایش می‌یابد.الگوهای ارتباطی پرسر و صدا (Chatty Communication Patterns)در مواردی که یک میکروسرویس برای انجام کارهای ساده نیاز به درخواست‌های مکرر دارد، تأخیرها به‌طور تصاعدی افزایش می‌یابند.کوئری‌های پیچیده (Complex Queries)استفاده از کوئری‌های ناکارآمد در دیتابیس‌ها می‌تواند زمان پاسخگویی را به‌شدت افزایش دهد.استفاده از کانتینرها و ماشین‌های مجازی (Containers and Virtual Machines)ماشین‌های مجازی و کانتینرها، علی‌رغم مزایای زیاد، گاهی اوقات به دلیل سربار منابع اضافی، تأخیر ایجاد می‌کنند.لاگ‌گذاری و نظارت (Logging and Monitoring)افزایش نظارت و لاگ‌گذاری می‌تواند به کند شدن عملکرد سیستم منجر شود، به‌ویژه در سیستم‌های بسیار بزرگ.روش‌های بهینه‌سازی برای کاهش Latency1. بهینه‌سازی ارتباطات بین سرویس‌هاارتباطات ناهمزمان (Asynchronous Communication)استفاده از Message Queueهایی مثل RabbitMQ یا Kafka می‌تواند تاخیرها را کاهش دهد. این روش به سرویس‌ها اجازه می‌دهد به‌جای منتظر ماندن برای پاسخ، کارهای خود را ادامه دهند.استفاده از فرمت‌های داده‌ای بهینهفرمت‌های باینری مثل Protocol Buffers یا Avro سریع‌تر از فرمت‌هایی مثل JSON و XML هستند.کاهش تعداد تماس‌هااطلاعات مرتبط را در یک درخواست دسته‌بندی کنید تا نیاز به تماس‌های مکرر کاهش یابد.2. استفاده از کش (Caching)کش در حافظه (In-Memory Caching)ابزارهایی مثل Redis و Memcached برای ذخیره‌سازی داده‌های پرتکرار بسیار کارآمد هستند.کش توزیع‌شدهدر معماری‌های بزرگ، می‌توانید از کش‌های توزیع‌شده برای کاهش فشار بر روی سرویس‌های اصلی استفاده کنید.کش سمت کلاینتبرخی داده‌ها را می‌توان در سمت کلاینت ذخیره کرد تا فشار روی سرورها کاهش یابد.3. بهینه‌سازی دیتابیس‌هاپارتیشن‌بندی و شاردینگ (Partitioning and Sharding)داده‌های بزرگ را به بخش‌های کوچکتر تقسیم کنید تا کوئری‌ها سریع‌تر انجام شوند.استفاده از Connection Poolingزمان ایجاد اتصال به دیتابیس با استفاده از Poolهای اتصالات کاهش می‌یابد.کوئری‌های بهینهاز ابزارهایی مثل Entity Framework Profiler برای بررسی و بهینه‌سازی کوئری‌ها استفاده کنید.4. ابزارهای نظارتی و مانیتورینگابزارهایی مثل Prometheus و Grafana برای نظارت بر عملکرد سیستم و شناسایی گلوگاه‌ها بسیار مفید هستند.5. استفاده از شبکه‌های سرویس (Service Mesh)ابزارهایی مثل Istio یا Linkerd برای مدیریت ارتباطات سرویس به سرویس، کنترل ترافیک، و نظارت بر عملکرد بهینه‌سازی بسیار مفید هستند.مثال‌های واقعی کاهش Latency در میکروسرویس‌ها1. نتفلیکس (Netflix)نتفلیکس یکی از پیشگامان معماری میکروسرویس است. این شرکت به دلیل حجم بالای کاربران جهانی، نیاز به کاهش Latency را به‌خوبی درک کرده و اقدامات زیر را انجام داده است:بهینه‌سازی ارتباطات بین سرویس‌هاراه‌حل: استفاده از پروتکل gRPC به‌جای REST برای ارتباطات داخلی سرویس‌ها.نتیجه: کاهش چشمگیر در زمان انتقال داده بین میکروسرویس‌ها، زیرا gRPC مبتنی بر HTTP/2 است و داده‌ها را به شکل باینری انتقال می‌دهد.کش سمت کلاینتراه‌حل: استفاده از Edge Caching برای ذخیره محتوای پرکاربرد در سرورهای نزدیک به کاربران.نتیجه: کاربران در هر نقطه از دنیا، محتوای ویدئویی را بدون تأخیر تجربه می‌کنند.استفاده از Circuit Breakerراه‌حل: پیاده‌سازی ابزار Hystrix برای جلوگیری از خرابی‌های زنجیره‌ای در میکروسرویس‌ها.نتیجه: اگر یک سرویس کند یا غیرقابل دسترس باشد، سرویس‌های دیگر به‌سرعت از آن عبور کرده و پاسخ‌های پیش‌فرض ارائه می‌دهند.2. آمازون (Amazon)آمازون به‌عنوان یکی از بزرگ‌ترین فروشگاه‌های آنلاین جهان، با میلیاردها درخواست روزانه روبه‌روست. کاهش Latency در سیستم این شرکت ضروری است.کاهش تعداد درخواست‌هاراه‌حل: گروه‌بندی داده‌ها در یک درخواست (Batching) برای کاهش تعداد تماس‌ها به دیتابیس و سرویس‌های داخلی.نتیجه: Latency کلی به‌طور قابل‌توجهی کاهش یافت، به‌ویژه در روزهای پر ترافیک مثل بلک فرایدی.کش توزیع‌شدهراه‌حل: استفاده از DynamoDB به‌همراه Elasticache برای کشینگ داده‌های پرتکرار.نتیجه: کاربران به داده‌ها با سرعت بالا دسترسی پیدا می‌کنند، حتی در صورت فشار سنگین بر سیستم.استفاده از Retry Patternراه‌حل: در زمان بروز خطاهای موقتی (مثل خطای شبکه)، درخواست‌ها مجدداً ارسال می‌شوند.نتیجه: کاهش نرخ شکست درخواست‌ها بدون نیاز به تلاش دستی کاربران.3. اوبر (Uber)اوبر که میلیون‌ها سفر روزانه را مدیریت می‌کند، نیاز دارد تا درخواست‌ها و پاسخ‌ها با کمترین تأخیر ممکن انجام شوند.بهینه‌سازی دیتابیسراه‌حل: استفاده از Sharding برای تقسیم‌بندی داده‌ها بر اساس مناطق جغرافیایی.نتیجه: کاهش زمان پاسخگویی به درخواست‌های کاربران محلی.استفاده از Service Meshراه‌حل: پیاده‌سازی Istio برای مدیریت ترافیک بین میکروسرویس‌ها.نتیجه: کاهش پیچیدگی مدیریت ارتباطات بین سرویس‌ها و بهبود کارایی کلی.راه‌حل: استفاده از پیام‌رسان‌هایی مثل Kafka برای مدیریت ارتباطات ناهمزمان.نتیجه: سرویس‌ها به‌جای منتظر ماندن برای پاسخ، به کار خود ادامه می‌دهند و داده‌ها به‌صورت بلادرنگ پردازش می‌شوند.4. لینکدین (LinkedIn)لینکدین به‌عنوان یک شبکه اجتماعی حرفه‌ای با کاربران زیاد، از روش‌های زیر برای کاهش Latency استفاده کرده است:بهینه‌سازی نمایش داده‌هاراه‌حل: استفاده از GraphQL به‌جای REST برای درخواست‌های API.نتیجه: کاربران فقط داده‌های موردنیاز خود را دریافت می‌کنند، که این موضوع باعث کاهش حجم انتقال داده و زمان پاسخ می‌شود.کش توزیع‌شدهراه‌حل: استفاده از Voldemort، یک سیستم کش توزیع‌شده، برای داده‌های پرتکرار مثل پروفایل‌ها و ارتباطات کاربران.نتیجه: سرعت بارگذاری صفحات به شکل قابل‌توجهی افزایش یافت.نتیجه‌گیری از مثال‌هاتجارب شرکت‌های بزرگ نشان می‌دهد که کاهش Latency نیازمند ترکیبی از استراتژی‌های طراحی معماری، انتخاب ابزارهای مناسب و بهینه‌سازی فرآیندها است. برای کاهش Latency در پروژه‌های میکروسرویسی خود، می‌توانید از این تجربیات الهام بگیرید و ابزارهای مشابه را متناسب با نیازهای خود پیاده‌سازی کنید. #MicroservicesOptimization #LatencyReduction #SystemPerformance #TechInnovation #ScalableSystems #EcommerceArchitecture #RealTimeProcessing #CloudComputing#DistributedSystems #TechForBusiness #AppPerformance #SoftwareEngineering #LatencyChallenges #MicroservicesArchitecture #EfficientTech #TechSolutions #APIOptimization #ServerlessComputing #NetworkLatency #TechStrategy Mostafa Akbarizadeh Mostafa Akbarizadeh Sat, 30 Nov 2024 11:19:46 +0330 https://virgool.io/CTO-insight/%D9%85%D8%A7%D9%86%DB%8C%D8%AA%D9%88%D8%B1%DB%8C%D9%86%DA%AF-%D9%88-observability-%D8%AF%D8%B1-microservices-%D8%AA%D8%B3%D9%84%D8%B7-%DA%A9%D8%A7%D9%85%D9%84-%D8%A8%D8%B1-%D8%B9%D9%85%D9%82-%D8%B3%DB%8C%D8%B3%D8%AA%D9%85-%D9%87%D8%A7-smqjqepju5ur مانیتورینگ و هشدار: چشم و گوش سیستمت باش!تصور کن یه کشتی بزرگ داری و روی اقیانوس در حال حرکت هستی. کسی رادار رو چک نمی‌کنه، کسی به وضعیت موتور نگاه نمی‌کنه و خبری از زنگ خطر نیست. خب، فقط یه موج کافیه تا همه چیز بره زیر آب! سیستم‌های نرم‌افزاری هم دقیقاً مثل همین کشتی هستند: اگه Monitoring و Alerting نداشته باشی، یه خطای کوچیک می‌تونه به یه فاجعه بزرگ تبدیل بشه.حالا بیایید بررسی کنیم چرا این دو مفهوم حیاتی هستن، چطور می‌تونیم از ابزارها و تکنیک‌های مناسب استفاده کنیم، و در نهایت، روش‌های دیباگ بین سرویس‌ها در معماری Microservices رو یاد بگیریم.چالش‌ها: چرا Monitoring و Alerting ضروریه؟۱. خطاهای پنهانبدون مانیتورینگ مناسب، ممکنه مشکلات و خطاها برای مدت‌ها شناسایی نشن. این خطاها به مرور زمان انباشته می‌شن و در نهایت به اختلالات بزرگ منجر می‌شن.۲. نارضایتی کاربرانکاربران همیشه توقع یه تجربه سریع و بدون مشکل دارن. اگه یه باگ یا قطعی به موقع برطرف نشه، احتمال زیادی هست که کاربرها رو از دست بدی.۳. از دست دادن درآمدمشکلاتی مثل server downtime یا خرابی دیتابیس می‌تونه مستقیماً روی درآمد تاثیر بذاره، چون تراکنش‌ها متوقف می‌شن و اعتماد کاربران خدشه‌دار می‌شه.۴. مدیریت پیچیدگیتوی سیستم‌های بزرگ که اجزای مختلف به هم متصل هستن، یه مشکل کوچیک می‌تونه کل سیستم رو تحت تأثیر قرار بده. پیدا کردن علت این نوع مشکلات بدون مانیتورینگ واقعاً سخته.راه‌حل‌ها: سیستم همیشه زیر ذره‌بین!۱. استفاده از ابزارهای مانیتورینگابزارهایی مثل Prometheus، Grafana یا ELK Stack می‌تونن برای بررسی لحظه‌ای عملکرد سیستم استفاده بشن.این ابزارها شاخص‌های کلیدی مثل CPU Usage، Memory Usage یا Response Time رو رصد می‌کنن و اطلاعات ارزشمندی در اختیارت می‌ذارن.۲. تنظیم هشدارهابرای رویدادهای خاص مثل پر شدن فضای دیسک، بالا رفتن زمان پاسخ‌دهی یا افزایش خطاهای HTTP 500، هشدارهای خودکار تعریف کن.ابزارهایی مثل PagerDuty یا Slack Notifications می‌تونن این هشدارها رو به تیم مربوطه ارسال کنن.۳. مانیتورینگ سلامت سرویسبا استفاده از Health Check APIs، می‌تونی وضعیت سرویس‌ها رو به‌صورت خودکار بررسی کنی و به محض بروز مشکل اقدام لازم رو انجام بدی.۴. ذخیره‌سازی لاگ‌هالاگ‌های سیستمت رو به یه سیستم متمرکز مثل ElasticSearch یا Fluentd منتقل کن. این کار کمک می‌کنه تا اگه مشکلی پیش اومد، به راحتی دلیلش رو پیدا کنی.۵. داشبوردهای گرافیکیبا ابزارهایی مثل Grafana یا Kibana داشبوردهای زیبا و کاربردی بساز. این داشبوردها بهت کمک می‌کنن تا وضعیت سیستم رو فقط با یه نگاه بررسی کنی.۶. هشدار هوشمندبه جای این که برای هر مشکل کوچیکی هشدار ارسال بشه، از سیستم‌های هوشمند استفاده کن که فقط وقتی مشکل جدیه هشدار بدن. این کار از خستگی تیم پشتیبانی جلوگیری می‌کنه و به مدیریت بهتر زمان کمک می‌کنه.روش دیباگ بین سرویس‌ها در معماری Microservicesیکی از بزرگ‌ترین چالش‌ها در معماری Microservices، دیباگ بین سرویس‌هاست. وقتی یک درخواست از چندین سرویس عبور می‌کنه و در نهایت خطایی ایجاد می‌شه، پیدا کردن منبع اصلی مشکل می‌تونه بسیار سخت باشه. در ادامه روش‌های کلیدی دیباگ بین سرویس‌ها رو بررسی می‌کنیم:۱. استفاده از Distributed Tracingبا استفاده از ابزارهایی مثل Jaeger یا Zipkin می‌تونی trace کامل یک درخواست رو در بین سرویس‌ها ردیابی کنی.این ابزارها هر مرحله از پردازش درخواست رو ثبت می‌کنن و بهت نشون می‌دن که درخواست چطور از یک سرویس به سرویس دیگه منتقل شده.شاخص‌هایی مثل زمان تأخیر، نقاط شکست، و سرویس‌های متأثر رو به وضوح نمایش می‌ده.۲. استفاده از Correlation IDیک Correlation ID به هر درخواست ورودی اختصاص بده و این شناسه رو در طول چرخه حیات درخواست بین سرویس‌ها حفظ کن.این شناسه رو در لاگ‌های هر سرویس ذخیره کن تا بتونی جریان کامل درخواست رو دنبال کنی.برای پیاده‌سازی این روش، از یک Middleware برای اضافه کردن و مدیریت Correlation ID استفاده کن.۳. تحلیل لاگ‌هاابزارهایی مثل ELK Stack (Elasticsearch, Logstash, Kibana) بهت اجازه می‌ده لاگ‌های تمامی سرویس‌ها رو در یک مکان متمرکز ذخیره و تحلیل کنی.با استفاده از این ابزارها می‌تونی به راحتی مشکلات خاصی رو که در یک سرویس یا جریان رخ داده، پیدا کنی.ایجاد فیلترهایی بر اساس Correlation ID می‌تونه جریان‌های مرتبط رو به صورت مستقیم نمایش بده.۴. مانیتورینگ متریک‌هابا ابزارهایی مثل Prometheus، می‌تونی متریک‌های دقیق هر سرویس مثل تعداد درخواست‌ها، زمان پاسخ‌دهی، و خطاها رو مانیتور کنی.این اطلاعات بهت کمک می‌کنه تا سرویس‌هایی که عملکرد غیرعادی دارن رو شناسایی کنی.همچنین می‌تونی با تنظیم هشدارهای خودکار، به موقع از مشکلات آگاه بشی.۵. شبیه‌سازی خطابرای تست و دیباگ مؤثرتر، از ابزارهایی مثل Chaos Monkey استفاده کن تا خطاها رو شبیه‌سازی کنی و واکنش سیستم رو در شرایط بحرانی ارزیابی کنی.مثال کاربردی: دیباگ در یک فروشگاه اینترنتیفرض کن فروشگاه اینترنتی داری و کاربر هنگام ثبت سفارش با خطای 500 Internal Server Error مواجه می‌شه.مراحل دیباگ به این صورت خواهد بود:تحلیل لاگ‌ها: شناسه Correlation ID رو از لاگ درخواست کاربر پیدا کن.ردیابی درخواست: با ابزار Jaeger، مراحل عبور درخواست از سرویس‌های مختلف (مثل Order Service و Payment Service) رو بررسی کن.بررسی متریک‌ها: متریک‌های Order Service و Payment Service رو در Prometheus بررسی کن و ببین کدوم سرویس بیشترین زمان تأخیر یا خطا رو داره.رفع مشکل: با تحلیل نتایج، مشکل شناسایی و برطرف می‌شه.نتیجه‌گیری ابزارهای دیباگ و Monitoring، Alerting مثل داشتن دوربین امنیتی و ابزارهای پیشرفته تجزیه و تحلیل تو سیستم‌هات هستن. اگه بخوای یه سیستم قابل اعتماد و پایدار بسازی، باید همیشه وضعیت سرویس‌هات رو زیر نظر داشته باشی و برای مشکلات غیرمنتظره آماده باشی.با ترکیب ابزارهای مانیتورینگ، هشداردهی و دیباگ، نه‌تنها می‌تونی مشکلات رو سریع‌تر حل کنی، بلکه می‌تونی از وقوع بسیاری از مشکلات جلوگیری کنی. سیستم‌ت رو حرفه‌ای‌تر مدیریت کن و همیشه یک قدم جلوتر باش. 🚀#Microservices#Monitoring #Observability #DevOps #SystemReliability #Metrics #DistributedSystems #LoggingAndTracing #IncidentManagement #CloudComputing #Prometheus #Grafana #ErrorReporting #DebuggingTechniques #ScalableArchitecture Mostafa Akbarizadeh Mostafa Akbarizadeh Wed, 27 Nov 2024 09:25:12 +0330 https://virgool.io/CTO-insight/handling-large-files-in-microservices-%D9%85%D8%AF%DB%8C%D8%B1%DB%8C%D8%AA-%D9%81%D8%A7%DB%8C%D9%84-%D9%87%D8%A7%DB%8C-%D8%A8%D8%B2%D8%B1%DA%AF-%D8%AF%D8%B1-%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D9%85%DB%8C%DA%A9%D8%B1%D9%88%D8%B3%D8%B1%D9%88%DB%8C%D8%B3-%D9%87%D8%A7-dkk4ahhxf1cs مدیریت فایل‌های بزرگ یکی از چالش‌های اساسی در سیستم‌های مبتنی بر معماری میکروسرویس‌هاست. این مسئله به‌ویژه زمانی که نیاز به ارسال یا دریافت فایل‌های حجیم باشد، خود را به‌وضوح نشان می‌دهد. در این مقاله، راهکارهای مختلف این موضوع را بررسی می‌کنیم، خوبی‌ها و بدی‌های هر روش را تحلیل می‌کنیم و به مثال‌هایی از دنیای واقعی مثل یوتیوب، نتفلیکس و اینستاگرام اشاره خواهیم کرد.چالش‌ها: چرا فایل‌های بزرگ دردسرساز هستند؟سرعت پایین انتقال داده: ححجم زیاد فایل‌ها می‌تواند زمان انتقال را به شدت افزایش دهد و تجربه کاربری را تحت تأثیر قرار دهد.مثال: کاربری که قصد دارد ویدیویی 4K با حجم چند گیگابایت را در یوتیوب آپلود کند.استفاده زیاد از منابع سرور : ذخیره و پردازش فایل‌های بزرگ، فشار زیادی بر منابع CPU، حافظه و فضای ذخیره‌سازی وارد می‌کند.مثال: نتفلیکس باید ویدیوهای بزرگ را در چند فرمت مختلف برای دستگاه‌های گوناگون تبدیل کند.محدودیت پهنای باند : انتقال فایل‌های حجیم باعث مصرف زیاد پهنای باند می‌شود که ممکن است عملکرد سایر بخش‌های سیستم را مختل کند.از دست رفتن داده‌ها : قطع اتصال هنگام انتقال فایل‌های بزرگ می‌تواند باعث از دست رفتن کامل داده و لزوم شروع دوباره فرآیند شود.مقیاس‌پذیری محدود : مدیریت فایل‌های حجیم در سیستم‌هایی که به طور مداوم در حال گسترش هستند، دشوارتر است.راهکارهای مدیریت فایل‌های بزرگ1. استفاده از Object Storageتوضیح:این روش به‌جای ذخیره مستقیم فایل‌ها روی سرورها، از سرویس‌های ذخیره‌سازی ابری مثل Amazon S3، Azure Blob Storage یا Google Cloud Storage استفاده می‌کند.مزایا:مقیاس‌پذیری بالا. کاهش هزینه‌های ذخیره‌سازی به دلیل پرداخت بر اساس استفاده. امکان دسترسی از نقاط مختلف جهان با تاخیر کم.معایب:ممکن است هزینه‌های انتقال داده (Data Egress) بالا باشد. به وابستگی به ارائه‌دهنده ابری منجر می‌شود.مثال واقعی:یوتیوب و نتفلیکس از Amazon S3 و Google Cloud برای ذخیره فایل‌های حجیم و دسترسی سریع کاربران استفاده می‌کنند.2. تقسیم فایل‌ها به بخش‌های کوچک‌تر (Chunking)توضیح:فایل‌های بزرگ به بخش‌های کوچک‌تر تقسیم شده و هر بخش به‌صورت جداگانه آپلود می‌شود. در انتها، بخش‌ها در سرور تجمیع می‌شوند.مزایا:قابلیت ادامه آپلود در صورت قطع ارتباط.کاهش فشار بر شبکه و منابع سرور.معایب:سربار اضافی برای تجمیع بخش‌ها.نیاز به مدیریت متادیتای بخش‌ها.مثال واقعی:یوتیوب از آپلود قطعه‌ای (Chunked Upload) استفاده می‌کند تا کاربران بتوانند ویدیوهای خود را حتی با اینترنت ناپایدار بارگذاری کنند.3. استفاده از Block Storageتوضیح:این روش داده‌ها را در بلوک‌های کوچک ساختارمند ذخیره می‌کند و برای برنامه‌هایی که نیاز به IOPS بالا دارند، ایده‌آل است.مثال: Amazon EBS، Azure Managed Disks.مزایا:سرعت بالا در ذخیره و دسترسی.مناسب برای پایگاه‌های داده و فایل‌های حجیم با دسترسی مکرر.معایب:هزینه بالاتر نسبت به Object Storage.نیاز به مدیریت دقیق‌تر.مثال واقعی:نتفلیکس از این روش برای نگهداری داده‌های قابل تغییر مثل زیرنویس‌ها یا متادیتای فیلم‌ها استفاده می‌کند.4. فشرده‌سازی (Compression)توضیح:فایل‌ها قبل از انتقال با استفاده از الگوریتم‌هایی مثل GZIP یا Brotli فشرده می‌شوند.مزایا:کاهش حجم داده‌های انتقالی.بهبود سرعت انتقال.معایب:سربار محاسباتی برای فشرده‌سازی و باز کردن فایل.کاهش کارایی برای فایل‌هایی که از قبل فشرده شده‌اند.مثال واقعی:اینستاگرام از فشرده‌سازی تصاویر و ویدیوها برای کاهش حجم فایل‌های ارسالی کاربران استفاده می‌کند.5. استفاده از پروتکل‌های سریع‌ترتوضیح:پروتکل‌های مدرنی مثل HTTP/2 یا gRPC می‌توانند سرعت انتقال داده‌ها را افزایش دهند.مزایا:انتقال موازی چندین جریان داده.کاهش زمان تأخیر (Latency).معایب:نیاز به زیرساخت و پشتیبانی مناسب.مثال واقعی:گوگل در محصولات خود مثل Google Drive از gRPC برای افزایش سرعت انتقال فایل‌ها استفاده می‌کند.6. امکان ادامه آپلود (Resume Upload)توضیح:در صورت قطع انتقال، فایل می‌تواند از همان نقطه ادامه پیدا کند. پروتکل‌هایی مثل Tus یا Multipart Upload این قابلیت را فراهم می‌کنند.مزایا:جلوگیری از اتلاف وقت و منابع.تجربه کاربری بهتر.معایب:پیچیدگی در پیاده‌سازی.نیاز به نگهداری متادیتای انتقال.مثال واقعی:یوتیوب و نتفلیکس برای مدیریت آپلودها و دانلودهای کاربران از این روش بهره می‌برند.درس‌هایی از دنیای واقعینتفلیکس:نتفلیکس با استفاده از Object Storage و الگوریتم‌های فشرده‌سازی پیشرفته، ویدیوها را به قطعات کوچک تقسیم کرده و برای هر دستگاه نسخه بهینه تولید می‌کند. این کار باعث کاهش تاخیر و بهبود تجربه کاربری شده است.اینستاگرام:تصاویر و ویدیوها در اینستاگرام قبل از ارسال، فشرده و به قطعات کوچک تقسیم می‌شوند. این روش آپلود پایدار حتی در شرایط اینترنت ضعیف را تضمین می‌کند.یوتیوب:آپلود قطعه‌ای همراه با امکان Resume Upload باعث شده کاربران بتوانند بدون نگرانی از قطع ارتباط، ویدیوهای حجیم خود را بارگذاری کنند.نتیجه‌گیریمدیریت فایل‌های بزرگ در معماری میکروسرویس‌ها مانند عبور از یک پل شلوغ با یک کامیون پر از بار است. استفاده از راهکارهای مناسب مانند Object Storage، Chunking، یا پروتکل‌های مدرن می‌تواند انتقال فایل‌ها را ساده‌تر و مطمئن‌تر کند. با انتخاب راهکار مناسب بر اساس نیازهای سیستم خود، می‌توانید این چالش را به فرصتی برای بهبود کارایی تبدیل کنید.#MicroservicesArchitecture #FileManagement #LargeFileHandling #CloudStorage #DataTransfer #ObjectStorage #FileChunking #CompressionTechniques #ScalableSolutions #HighPerformanceComputing #HTTP2 #GRPC #ResumableUploads #ServerOptimization #DistributedSystems #NetflixEngineering #YouTubeScaling #TechnicalWriting #DevOpsSolutions #SoftwareDesignPatterns Mostafa Akbarizadeh Mostafa Akbarizadeh Tue, 26 Nov 2024 10:39:10 +0330 https://virgool.io/@MostafaAkbarizadeh/%D8%AA%D8%B5%D9%88%D8%B1-%D9%BE%D8%B1%D8%AF%D8%A7%D8%AE%D8%AA-%D8%A8%D8%A7-%DB%8C%DA%A9-%DA%A9%D9%84%DB%8C%DA%A9-%D8%A7%D8%B2-%D8%AD%D8%B3%D8%A7%D8%A8-%D8%A8%D8%A7%D9%86%DA%A9%DB%8C-ly0io3wjrmqt قدیم‌ندیم‌ها که خیلی از دوستان جدید یادشون نمیاد، همه‌چیز رسم و رسومی داشت. نه خبری از راحتی‌های امروزی بود، نه سرعتی که امروز در زندگی روزمره داریم. هر کاری که می‌خواستیم انجام بدیم، باید وقت و انرژی زیادی می‌ذاشتیم. حالا شاید برای شما که با دنیای دیجیتال بزرگ شدین این موضوع عجیب به نظر بیاد، اما بذارید یک کم بهتون بگم چطور همه‌چیز تغییر کرده.شماها که یک دفعه چشم باز کردید و افتادید تو عصر امکانات، فکر کنید که چطور زندگی ما برای انجام کوچک‌ترین کارها نیاز به زمان و تلاش زیادی داشت. چه برای خرید یک سیب‌زمینی، چه برای رزرو بلیط یا حتی خرید یک وسیله الکترونیکی، هر کدوم از این کارها یک پروسه طولانی و پیچیده بودن. حتی پرداخت قبض‌های خونگی هم کاری بود که حسابی وقت می‌گرفت. حالا شاید بگید اینا چه ربطی به پرداخت با یک کلیک داره؟ بذارید براتون توضیح بدم.تو دهه‌های گذشته، برای پرداخت قبض برق، باید مرخصی می‌گرفتی و می‌رفتی تو صف‌های طولانی بانک‌ها یا ادارات دولتی. از گرما و سرما نمی‌گم که چطور ساعت‌ها تو صف وایمیستادی، بلکه از اینکه باید با تمام صبر و حوصله منتظر می‌موندی تا نوبتت بشه. شاید چندین بار با نفر قبلی یا بعدی حرف می‌زدی تا بالاخره قبض رو پرداخت کنی و از نگرانی بابت قطع شدن برق خلاص بشی!الان که چشمان مبارک رو باز می‌کنید، همه‌چیز تغییر کرده. امروز دیگه خبری از صف‌های طولانی نیست. پرداخت‌ها خیلی سریع‌تر و راحت‌تر از همیشه انجام میشه. کافیه انگشتان مبارک رو روی صفحه موبایل بکشید، یه پیام میاد که "سفارش شما ثبت شد و در اسرع وقت به دست شما می‌رسد". از خرید لوازم الکترونیکی گرفته تا خرید سیب‌زمینی و پیاز، همه‌چیز با چند کلیک ساده انجام میشه. حتی در همین لحظه‌ای که شاید هنوز خواب و بیدار هستید، می‌تونید در عرض چند ثانیه و با یه حرکت ساده از حساب بانکی‌تون پرداخت رو انجام بدید!تصور کنید این راحتی چقدر برای ما شگفت‌انگیز بوده. پرداخت با یک کلیک از حساب بانکی حالا به یک واقعیت تبدیل شده. برای همین پیشرفت‌ها باید شکرگذار باشیم که حالا دیگه نیازی نیست برای هر پرداختی ساعت‌ها وقت بذاریم یا در صف‌های طولانی منتظر بمونیم. امروز همه‌چیز توی دست‌هایمونه، فقط کافیه کمی انگشت‌هامون رو تکون بدیم و بقیه کارها به سرعت انجام میشه.حالا که تکنولوژی اینقدر راحت کرده که همه‌چیز با یک کلیک انجام بشه، باید قدرش رو بیشتر بدونیم. شاید خیلی وقت‌ها از این امکانات استفاده می‌کنیم و متوجه تغییرات عمیق‌شون نمی‌شیم، اما همونطور که از خواب بیدار میشیم و با چند کلیک همه‌چیز رو پرداخت می‌کنیم، باید به این راحتی‌ها آگاه باشیم و شکر کنیم که زندگی امروز چقدر راحت‌تر از گذشته شده.پس با وجود همه‌ی این امکانات، یادمون باشه که چقدر پیشرفت کردیم. وقتی هر کاری رو با چند کلیک ساده انجام می‌دیم، باید از این لحظه‌های راحتی بهره ببریم و ازشون قدردانی کنیم.#پرداخت_مستقیم_پیمان Mostafa Akbarizadeh Mostafa Akbarizadeh Mon, 25 Nov 2024 19:27:35 +0330 https://virgool.io/CTO-insight/%D9%85%D9%87%D8%A7%D8%AC%D8%B1%D8%AA-%D8%A7%D8%B2-%D8%B3%DB%8C%D8%B3%D8%AA%D9%85-%D9%87%D8%A7%DB%8C-%D9%82%D8%AF%DB%8C%D9%85%DB%8C-%D8%B1%D8%A7%D9%87%DA%A9%D8%A7%D8%B1%D9%87%D8%A7%DB%8C-%D8%B9%D9%85%D9%84%DB%8C-%D8%A8%D8%B1%D8%A7%DB%8C-%D9%85%D9%88%D9%81%D9%82%DB%8C%D8%AA-%D8%AF%D8%B1-%D9%BE%D8%B1%D9%88%DA%98%D9%87-%D9%87%D8%A7%DB%8C-%D9%BE%DB%8C%DA%86%DB%8C%D8%AF%D9%87-vxbg1crtgbcj سلام به همه دوستان 🌟دهه‌های ۷۰ و ۸۰: عصر دلفی و ویژوال بیسیکیادتونه اون روزهایی که نرم‌افزارهایی مثل دلفی و ویژوال بیسیک همه‌جا حرف اول رو می‌زدن؟ اون موقع، برنامه‌نویس‌ها بیشتر شبیه مهندسانی بودن که سیستم‌های پیچیده و سنگین می‌ساختن. این سیستم‌ها، که امروز بهشون "سیستم‌های قدیمی" می‌گیم، ستون اصلی خیلی از کسب‌وکارها بودن.امروز: تغییرات دنیای تکنولوژیاما حالا زمانه عوض شده. دیگه اون سیستم‌های قدیمی جوابگو نیستن. تکنولوژی پیشرفت کرده، نیازهای کسب‌وکارها تغییر کرده و برنامه‌نویس‌های قدیمی هم کم‌کم بازنشسته می‌شن. این سیستم‌ها که زمانی شاهکار بودن، حالا مثل باری سنگین روی دوش شرکت‌ها افتادن.مشکلات سیستم‌های قدیمیاین سیستم‌ها مشکلات جدی دارن:قدیمی و منسوخ: تکنولوژی‌شون دیگه کارایی نداره.پیچیده و سخت: تغییر یا توسعه‌شون مثل حل یک پازل سخت و بی‌انتهاست.داده‌های سنگین: حجم بالای اطلاعات کار انتقال رو دشوار کرده.کمیاب بودن تخصص: برنامه‌نویس‌هایی که بتونن باهاشون کار کنن، نایاب شدن.عدم انطباق با نیازهای جدید: انتظارات مدرن کسب‌وکارها رو برآورده نمی‌کنن.هزینه‌های بالا: نگهداری این سیستم‌ها به‌صرفه نیست.وقت تغییر استتغییر همیشه سخت و چالش‌برانگیز است، اما برای پیشرفت، گریزناپذیر. به‌روزرسانی سیستم‌های قدیمی مثل جراحی قلب یک بیمار است؛ حساس و دقیق. این کار فقط آپدیت یک نرم‌افزار نیست، بلکه باید تمام ابعاد سیستم، از داده‌ها تا فرآیندها، دقیقاً بررسی و ارزیابی بشه.تصور کنید سیستمی که سال‌ها ازش استفاده شده، هر برنامه‌نویس به سلیقه خودش توش تغییراتی داده و حالا تبدیل شده به یک ساختار پیچیده که فقط خودش و خالقش می‌فهمن! چطور می‌شه مدیران و برنامه‌نویس‌ها رو قانع کرد که تغییر این سیستم، به‌رغم همه چالش‌ها، ضروریه؟تجربه‌ها و درس‌هامن بارها در این مسیر قدم گذاشتم و با چالش‌های زیادی روبرو شدم. تیم‌های فنی و برنامه‌نویس‌ها معمولاً اول راه با اشتیاق شروع می‌کنن، اما وسط مسیر از حجم مشکلات ناامید می‌شن. از طرفی، صاحبان کسب‌وکار به دلیل فشار بازار و نیازهای جدید، انتظارات بالایی دارن و سیستم‌های قدیمی توان پاسخگویی ندارن.راه‌حل‌هایی مثل ساخت سیستم‌های جزیره‌ای یا بازنویسی کامل از صفر اغلب امتحان می‌شه. ولی وقتی به میانه راه می‌رسیم، تازه ابعاد واقعی چالش نمایان می‌شه؛ از مسئله یکپارچگی و گزارش‌دهی تا کانورت داده‌ها و تطبیق با نیازهای جدید.چرا شکست می‌خوریم؟با اینکه شرکت‌های بزرگ دنیا موفق به این تغییرات می‌شن، خیلی از پروژه‌ها در ایران به نتیجه نمی‌رسن. چرا؟شاید چون برنامه‌ریزی کافی انجام نمی‌شه یا جزئیات حیاتی نادیده گرفته می‌شه.تجربه شما چیست؟آیا شما هم با چنین چالش‌هایی روبرو شدین؟ تجربه‌های خودتون رو در مهاجرت از سیستم‌های قدیمی به تکنولوژی‌های جدید با ما به اشتراک بذارین. 😊 Mostafa Akbarizadeh Mostafa Akbarizadeh Mon, 25 Nov 2024 18:55:17 +0330