Content Negotiation
تصور کنید که ما یک سایت بین‌المللی داریم که روزانه هزاران درخواست توسط افراد از سرتاسر جهان دریافت میکند. همه‌مان می‌دانیم که برای چنین سایت بزرگی نمی‌توانیم صرفا محتوا را به زبان انگلیسی به اشتراک بگذاریم بلکه باید از یک مکانیزم استفاده کنیم تا هر کاربر به زبان کشور خودش محتوا را دریافت کند.
به این موضوع Content Negotiation میگوییم.
در این پیام به نحوه تصمیم‌گیری برای انتخاب یک زبان می‌پردازیم.
به طور کلی ما دو روش برای انتخاب زبان داریم:
- Client-driven negotiation
- Server-driven negotiation
اکنون به Client-driven negotiation می‌پردازیم.
در این مکانیزم هنکامی که کاربر به سایت codecrafters.ir درخواست می‌زنند, سرور کد کرفرترز برای کلاینت لیستی از زبانها را ارسال میکند. اکنون مرورگر میتواند تصمیم بگیرد که کدام یک از url ها را باز کرده و به کاربر نشان دهد.
همانطور که متوجه شدید, این روش اصلا مناسب نیست! چرا که باید ۲ برابر ریکوئست ارسال شود و این موضوع latency را به شدت افزایش می‌دهد. پس بهتر است به فکر یک روش دیگری باشیم تا دیگر کلاینت این‌همه درگیر انتخاب زبان نباشد.
برای حل این موضوع Server-side negotiation بوجود آمد.
وب‌سرور به ۲ روش تصمیم می‌گیرد که کدام یک از زبانها را انتخاب کند.
۱- استفاده از header هایی مانند Accept-language و Accept-charset.
۲- استفاده از User-agent کاربر.
شاید این سوال برایتان پیش بیاید که چرا مورد دوم را بررسی میکنیم.
در جواب این سوال باید بدانیم که گاهی تنها زبان مهم نیست بلکه مهم این است که اطلاعات درست به کاربر نمایش داده شود. تصور کنید که یک وبسایت در صفحاتش از جاوااسکریپت استفاده میکند و مرورگر قدیمی ما از جاوا اسکریپت پشتیبانی نمی‌کنید.
پس سرور باید محتوای درستی که از JS استفاده نمی‌کند را با زبان درست برای کاربر ارسال کنید.
گاهی Http اجازه می‌دهد که کاربران یک لیست از انتظارات خود ارسال کنند.
تصور کنید ما می‌خواهیم به سایت codecrafters.ir درخواست بزنیم اما نمی‌دانیم که آیا زبان المانی پشتیبانی میشود یا خیر.
پس ما در هدر Accept-language مقدار زیر را ارسال میکنیم:
Accept-language: en;q=0.5, fr;q=0.0., du;1.0.
هنگامی که سرور این پیام را دریافت میکند, اینگونه برداشت میکند که محتوا باید المانی باشد, اگر چنین چیزی موجود نبود, انگلیسی نیز می‌پذیرد. اما باید توجه داشته باشد که هیچگاه محتوای فرانسوی ارسال نکند.
گاهی نیز این تصمیمات را بر عهده proxy می‌سپاریم.
این proxy server است که تصمیم می‌گیرد به کدام resource درخواست بزند و اطلاعات لازم را به کاربر ارسال کند.
#http_guideline
@code_crafters
تصور کنید که ما یک سایت بین‌المللی داریم که روزانه هزاران درخواست توسط افراد از سرتاسر جهان دریافت میکند. همه‌مان می‌دانیم که برای چنین سایت بزرگی نمی‌توانیم صرفا محتوا را به زبان انگلیسی به اشتراک بگذاریم بلکه باید از یک مکانیزم استفاده کنیم تا هر کاربر به زبان کشور خودش محتوا را دریافت کند.
به این موضوع Content Negotiation میگوییم.
در این پیام به نحوه تصمیم‌گیری برای انتخاب یک زبان می‌پردازیم.
به طور کلی ما دو روش برای انتخاب زبان داریم:
- Client-driven negotiation
- Server-driven negotiation
اکنون به Client-driven negotiation می‌پردازیم.
در این مکانیزم هنکامی که کاربر به سایت codecrafters.ir درخواست می‌زنند, سرور کد کرفرترز برای کلاینت لیستی از زبانها را ارسال میکند. اکنون مرورگر میتواند تصمیم بگیرد که کدام یک از url ها را باز کرده و به کاربر نشان دهد.
همانطور که متوجه شدید, این روش اصلا مناسب نیست! چرا که باید ۲ برابر ریکوئست ارسال شود و این موضوع latency را به شدت افزایش می‌دهد. پس بهتر است به فکر یک روش دیگری باشیم تا دیگر کلاینت این‌همه درگیر انتخاب زبان نباشد.
برای حل این موضوع Server-side negotiation بوجود آمد.
وب‌سرور به ۲ روش تصمیم می‌گیرد که کدام یک از زبانها را انتخاب کند.
۱- استفاده از header هایی مانند Accept-language و Accept-charset.
۲- استفاده از User-agent کاربر.
شاید این سوال برایتان پیش بیاید که چرا مورد دوم را بررسی میکنیم.
در جواب این سوال باید بدانیم که گاهی تنها زبان مهم نیست بلکه مهم این است که اطلاعات درست به کاربر نمایش داده شود. تصور کنید که یک وبسایت در صفحاتش از جاوااسکریپت استفاده میکند و مرورگر قدیمی ما از جاوا اسکریپت پشتیبانی نمی‌کنید.
پس سرور باید محتوای درستی که از JS استفاده نمی‌کند را با زبان درست برای کاربر ارسال کنید.
گاهی Http اجازه می‌دهد که کاربران یک لیست از انتظارات خود ارسال کنند.
تصور کنید ما می‌خواهیم به سایت codecrafters.ir درخواست بزنیم اما نمی‌دانیم که آیا زبان المانی پشتیبانی میشود یا خیر.
پس ما در هدر Accept-language مقدار زیر را ارسال میکنیم:
Accept-language: en;q=0.5, fr;q=0.0., du;1.0.
هنگامی که سرور این پیام را دریافت میکند, اینگونه برداشت میکند که محتوا باید المانی باشد, اگر چنین چیزی موجود نبود, انگلیسی نیز می‌پذیرد. اما باید توجه داشته باشد که هیچگاه محتوای فرانسوی ارسال نکند.
گاهی نیز این تصمیمات را بر عهده proxy می‌سپاریم.
این proxy server است که تصمیم می‌گیرد به کدام resource درخواست بزند و اطلاعات لازم را به کاربر ارسال کند.
#http_guideline
@code_crafters
❤8👍2
پروژه وقتی به مرحله پروداکشن میرسه، یه گام خیلی مهم داره که انجام اون الزام آوره
لاگ گرفتن و لاگ انداختن
موضوعی که تو همه پروژه‌ها از کوچیک تا بزرگش و تو هر معماری مورد نیاز هستش
انواع مختلف لاگ رو داریم در سطوح مختلف و همیشه کنترل کردنش بهتره بگیم نوشتن لاگ شخصی و توسعه اون یه دردسر نسبتا بزرگ هستش
مهمترین نوع لاگ در دنیای برنامه نویسی audit log (لاگ میمیزی) هستش که در سطح امنیتی و رهگیری تمامی رفتارهای کاربر در سیستم انجام میشه که با جزئیات کامل صورت میگیره
در جنگو کتابخونه django-auditlog با نصب و کانفیگ (تنظیماتش خیلی راحت هستش) کردنش لاگ ممیزی رو در سیستم شما پیاده سازی میکنه و فیچرهای کنترلی زیادی رو هم بهتون میده
کمتر از نیم ساعت این کتابخونه رو بخونید و خیلی راحت تو پروژه‌ها ازش بهره ببرید هم بخش امنیتی سازمان و هم پشتیبانی و مدیران رده بالا رو به رضایت از بخش لاگ گیری سیستم میرسونه
#monitoring
#django
#log
#audit_log
@code_crafters
لاگ گرفتن و لاگ انداختن
موضوعی که تو همه پروژه‌ها از کوچیک تا بزرگش و تو هر معماری مورد نیاز هستش
انواع مختلف لاگ رو داریم در سطوح مختلف و همیشه کنترل کردنش بهتره بگیم نوشتن لاگ شخصی و توسعه اون یه دردسر نسبتا بزرگ هستش
مهمترین نوع لاگ در دنیای برنامه نویسی audit log (لاگ میمیزی) هستش که در سطح امنیتی و رهگیری تمامی رفتارهای کاربر در سیستم انجام میشه که با جزئیات کامل صورت میگیره
در جنگو کتابخونه django-auditlog با نصب و کانفیگ (تنظیماتش خیلی راحت هستش) کردنش لاگ ممیزی رو در سیستم شما پیاده سازی میکنه و فیچرهای کنترلی زیادی رو هم بهتون میده
کمتر از نیم ساعت این کتابخونه رو بخونید و خیلی راحت تو پروژه‌ها ازش بهره ببرید هم بخش امنیتی سازمان و هم پشتیبانی و مدیران رده بالا رو به رضایت از بخش لاگ گیری سیستم میرسونه
#monitoring
#django
#log
#audit_log
@code_crafters
👍7❤6👎1
محاسبات موازی: یک عملیات روی چند هسته انجام میشود
محاسبات همزمان: یک هسته بین چند عملیات جابجا میشود
داریم راجب چی صحبت میکنیم؟؟؟
وقتی برنامه شما اجرا میشه، تبدیل به فرآیندهایی در سطح سیستم عامل میشه و سیستم عامل شروع میکنه به مدیریت اونها (به شکل پیشگیرانه) مطابق استاندارد خودش، اینکه چه منابعی رو و چقدر درگیر کنه یا نگه داره و یا از سر بگیره و به دیگری بده و ...
واسه جماعت برنامه نویس خبر خوب اینکه هیچی دست شما نیست، و خبر بد اینکه هیچی دست شما نیست😅😅😅
در واقع این مشکل شما نیست منتها نمی‌تونید کار زیادی هم انجام بدید
در پایتون دو کتابخانه داریم:
یکی تردها:
که بوسیله اون چندین نخ روی هسته اجرا میشه - کنترل اون رو سیستم عامل در دست میگیره - هرگاه یک نخ دچار مشکل بشه مابقی نخ‌ها توسط سیستم عامل اجرا و کار رو پیش می‌برند - مناسب کارهای ورودی خروجی هستش - پیچیدگی استفاده دارند (نمیدونیم چه اتفاقی داره میافته و اصلا نخ فعال داریم یا نه تا زمانیکه رخ دادی ازشون مشاهده کنیم مثه خونه جن زده تا اتفاقی نیافته متوجه حضورشون نمی‌شیم) - به سطح فرآیند برسند gil فعال شده و در واقع موازی سازی ندارید دلیل اون هم جلوگیری از شرایط مسابقه (race conditions) هستش ـ پر هزینه هم هستند
دومی مولتی پراسس:
هر فرایند روی یک هسته اجرا میشه - کنترل اون توسط سیستم عامل هست - مناسب پردازش‌های سنگین - پیچیدگی خاص خودش رو داره و اندکی کار خطرناک هستش - پر هزینه هم هستند
مشکل این دو کتابخانه پیچیدگی زیاد در استفاده هستش و هر کدام در یک کتابخانه جدا تهیه شده بود که استفاده ازش دردسر خاص خودش رو داشت
در نهایت کتابخانه concurrent.future اومد وسط که استخر تردها و پروسس هارو باهم داشت و در api سطح بالا بهمون کمک می‌کرد مشکلات gil در ترد سرجای خودش باقی موند منتها کار و مدیریت رو راحت‌تر میکنه برامون
تا اینجا تردها به رویکرد پیشگیرانه توسط سیستم عامل عمل میکردن
میرسیم به نخ‌های سبز:
این نوع نخ‌ها در سطح برنامه شما (مفسر پایتون) کار میکنن - در سطح سیستم‌عامل تنها بر روی یک نخ اجرا میشوند - دسترسی بیشتری بابت مدیریت و کنترل بهمون میدن و باید خودمون مدیریت کنیم - به روش مشارکتی کار میکنن (منابع رو بر اساس نقاطی که ما مشخص کردیم بهمدیگه پاس میدن) - هزینه کمتری دارن - اما یک اشتباه از سمت ما منجر به کرش برنامه خواهد شد (دیباگ سخت) - هزینه کمتر و سبک تر و اغلب سریع‌تر از تردهای سیستم عامل هستند - در صورت ترکیب با چند پردازنده موازی سازی رخ میده (در غیر این صورت چون در یک نخ در سیستم عامل اجرا میشود تحت کنترل gil است)
در موضوع بالا احتمال دیباگ و خطا منحر به کرش برنامه می‌شد بابت همین asyncio اومد وسط که کاملا از لحاظ کارایی شبیه نخ‌های سبز بود با این تفاوت که در نخ سبز نقاط پایانی و جابجایی توسط ما بود (همون جایی که ممکن بود خطا کنیم)، ناهمزمانی در یک حلقه رویداد رخ میداد و بدین ترتیب مشکل کرش بر طرف شد - اندکی سرعتش از نخ‌های سبز کمتره و نیاز به یادگیری داره
در نهایت برگردیم سر وب، در وب هر فریمورکی که بر پایه و اساس starlette نوشته بشه (یک ماژول برای http) از ناهمزمانی پشتیبانی میکنه و میتونه رقیب سر سختی برای go و nodejs محسوب بشه که نمونه بارز اون fastapi هستش
اما این مسائل بر علیه django خواهد بود؟
نه حقیقتا، جنگو بشدت برای برنامه‌های بزرگ و پیچیده مناسب است
سعی کردم خیلی ساده براتون بگم 😂😂😂
#python
#thread
#gil
#process
@code_crafters
محاسبات همزمان: یک هسته بین چند عملیات جابجا میشود
داریم راجب چی صحبت میکنیم؟؟؟
وقتی برنامه شما اجرا میشه، تبدیل به فرآیندهایی در سطح سیستم عامل میشه و سیستم عامل شروع میکنه به مدیریت اونها (به شکل پیشگیرانه) مطابق استاندارد خودش، اینکه چه منابعی رو و چقدر درگیر کنه یا نگه داره و یا از سر بگیره و به دیگری بده و ...
واسه جماعت برنامه نویس خبر خوب اینکه هیچی دست شما نیست، و خبر بد اینکه هیچی دست شما نیست😅😅😅
در پایتون دو کتابخانه داریم:
یکی تردها:
که بوسیله اون چندین نخ روی هسته اجرا میشه - کنترل اون رو سیستم عامل در دست میگیره - هرگاه یک نخ دچار مشکل بشه مابقی نخ‌ها توسط سیستم عامل اجرا و کار رو پیش می‌برند - مناسب کارهای ورودی خروجی هستش - پیچیدگی استفاده دارند (نمیدونیم چه اتفاقی داره میافته و اصلا نخ فعال داریم یا نه تا زمانیکه رخ دادی ازشون مشاهده کنیم مثه خونه جن زده تا اتفاقی نیافته متوجه حضورشون نمی‌شیم) - به سطح فرآیند برسند gil فعال شده و در واقع موازی سازی ندارید دلیل اون هم جلوگیری از شرایط مسابقه (race conditions) هستش ـ پر هزینه هم هستند
دومی مولتی پراسس:
هر فرایند روی یک هسته اجرا میشه - کنترل اون توسط سیستم عامل هست - مناسب پردازش‌های سنگین - پیچیدگی خاص خودش رو داره و اندکی کار خطرناک هستش - پر هزینه هم هستند
مشکل این دو کتابخانه پیچیدگی زیاد در استفاده هستش و هر کدام در یک کتابخانه جدا تهیه شده بود که استفاده ازش دردسر خاص خودش رو داشت
در نهایت کتابخانه concurrent.future اومد وسط که استخر تردها و پروسس هارو باهم داشت و در api سطح بالا بهمون کمک می‌کرد مشکلات gil در ترد سرجای خودش باقی موند منتها کار و مدیریت رو راحت‌تر میکنه برامون
تا اینجا تردها به رویکرد پیشگیرانه توسط سیستم عامل عمل میکردن
میرسیم به نخ‌های سبز:
این نوع نخ‌ها در سطح برنامه شما (مفسر پایتون) کار میکنن - در سطح سیستم‌عامل تنها بر روی یک نخ اجرا میشوند - دسترسی بیشتری بابت مدیریت و کنترل بهمون میدن و باید خودمون مدیریت کنیم - به روش مشارکتی کار میکنن (منابع رو بر اساس نقاطی که ما مشخص کردیم بهمدیگه پاس میدن) - هزینه کمتری دارن - اما یک اشتباه از سمت ما منجر به کرش برنامه خواهد شد (دیباگ سخت) - هزینه کمتر و سبک تر و اغلب سریع‌تر از تردهای سیستم عامل هستند - در صورت ترکیب با چند پردازنده موازی سازی رخ میده (در غیر این صورت چون در یک نخ در سیستم عامل اجرا میشود تحت کنترل gil است)
در موضوع بالا احتمال دیباگ و خطا منحر به کرش برنامه می‌شد بابت همین asyncio اومد وسط که کاملا از لحاظ کارایی شبیه نخ‌های سبز بود با این تفاوت که در نخ سبز نقاط پایانی و جابجایی توسط ما بود (همون جایی که ممکن بود خطا کنیم)، ناهمزمانی در یک حلقه رویداد رخ میداد و بدین ترتیب مشکل کرش بر طرف شد - اندکی سرعتش از نخ‌های سبز کمتره و نیاز به یادگیری داره
در نهایت برگردیم سر وب، در وب هر فریمورکی که بر پایه و اساس starlette نوشته بشه (یک ماژول برای http) از ناهمزمانی پشتیبانی میکنه و میتونه رقیب سر سختی برای go و nodejs محسوب بشه که نمونه بارز اون fastapi هستش
نه حقیقتا، جنگو بشدت برای برنامه‌های بزرگ و پیچیده مناسب است
سعی کردم خیلی ساده براتون بگم 😂😂😂
#python
#thread
#gil
#process
@code_crafters
❤9👍2
در حیطه جستجوی متن خیلی از ما با تصور اینکه پستگرس میتونه انجام بده پیش میریم، اما حقیقت تو سازمان اصلا اینکار رو نمیکنن و سمت پلتفرم‌های مخصوص میرن که نمونه اون elasticsearch هستش (بیشتر بابت الگوریتم‌هایی که داخلشون استفاده میشه که قدرت شگرفی رو خلق میکنه، حتما راجب الگوریتم‌ها بخونید تا تفاوت رو درک کنید)
زبان کوئری خاص خودش رو داره و تو حالت‌های مختلفی هم میتونید کنار هم بچینید و باهاش یک جستجوی متن حرفه‌ای ازش در بیارید
بالطبع واسه جنگو هم کتابخونه جهت کار کردن باهاش موجوده ولی منتها من توصیه نمیکنم کار کردن با کتابخونه‌های سطح پایین‌تری مثه خود elasticsearch پایتونی بهتره و کلی اختیارات و دست بازتر جهت نوشتن کوئری‌هایی با پرفورمنس بهتر وجود دارد
خود الاستیک کار میکنه اما یکی از نکات مهم اون سینک کردنش با دیتابیس هستش که یک چالش واسه مصاحبه‌ها و شرکت‌ها هستش
دانشگاه mit یه موتور بابت این موضوع توسعه داده با اسم hystack که مخصوص جنگو هستش و علاوه بر الاستیک ، ابزارهای دیگه رو هم ساپورت میکنه، خیلی چیزهارو بهمون میده مثلا حروف اضافه رو در جستجوها و ایندکس‌ها قرار نده و بابت هر زبانی یک پکیج هم بهمون داده، نرمالایزر و ... هم بهمون میده که همه این‌هارو باید تنظیم کنید
راجبش حتما بخونید من داخل دو پروژه ازش استفاده کردم و بشکل چشم گیری قدرت سرچ رو بالا برد
#django
@code_crafters
زبان کوئری خاص خودش رو داره و تو حالت‌های مختلفی هم میتونید کنار هم بچینید و باهاش یک جستجوی متن حرفه‌ای ازش در بیارید
بالطبع واسه جنگو هم کتابخونه جهت کار کردن باهاش موجوده ولی منتها من توصیه نمیکنم کار کردن با کتابخونه‌های سطح پایین‌تری مثه خود elasticsearch پایتونی بهتره و کلی اختیارات و دست بازتر جهت نوشتن کوئری‌هایی با پرفورمنس بهتر وجود دارد
خود الاستیک کار میکنه اما یکی از نکات مهم اون سینک کردنش با دیتابیس هستش که یک چالش واسه مصاحبه‌ها و شرکت‌ها هستش
دانشگاه mit یه موتور بابت این موضوع توسعه داده با اسم hystack که مخصوص جنگو هستش و علاوه بر الاستیک ، ابزارهای دیگه رو هم ساپورت میکنه، خیلی چیزهارو بهمون میده مثلا حروف اضافه رو در جستجوها و ایندکس‌ها قرار نده و بابت هر زبانی یک پکیج هم بهمون داده، نرمالایزر و ... هم بهمون میده که همه این‌هارو باید تنظیم کنید
راجبش حتما بخونید من داخل دو پروژه ازش استفاده کردم و بشکل چشم گیری قدرت سرچ رو بالا برد
#django
@code_crafters
👍9❤1
برنامه ریزی سبد محصول
بسیاری از سازمانها بر روی تولید چند محصول همزمان کار میکنند که نیازمند رویکردی هستند تا تجربه خود را با چابکی ادغام کنند در غیر این صورت شکاف عمیقی بین برنامه ریزی و مدیریت سبد محصول بوجود می‌آید. در این بخش ۱۱ استراتژی مورد استفاده را در قالب ۳ گروه زمانبندی، جریان ورودی محصول و جریان خروجی محصول توضیح داده و روشی جهت تصمیم‌گیری بابت ادامه یا توقف سرمایه گذاری روی محصولات را بررسی خواهیم کرد
نگاه کلی
برنامه ریزی سبد محصول فعالیتی است که طی آن مشخص میشود روی چه اقلامی از بک‌لاگ به چه ترتیبی و چه مدتی کار انجام شود. یک قلم از سبد میتواند یک محصول، بخش قابل عرضه از یک محصول یا یک پروژه باشد
زمان انجام
برنامه ریزی سبد محصول فعالیتی است که هیچگاه به پایان نمی‌رسد و تا زمانیکه بیش از یک محصول داریم این روند. برنامه ریزی سبد کلان‌تر از برنامه ریزی محصول است اما به معنای تقدم بر آن نیست. ترسیم چشم انداز محصول میتواند ورودی خوبی برای برنامه ریزی سبد باشد. ابتدا بر روی سرمایه گذاری روی محصول و بعدا در کجا قرار گرفتن محصول در بک لاگ تصمیم گرفته میشود. برنامه ریزی سبد فقط برای محصولات جدید نیست بلکه در بازه‌های زمانی منظم و برنامه ریزی شده برای بازنگری محصولات جاری (در حال توسعه، عملیاتی شده، در حال فروش) نیز انجام میشود
شرکت کنندگان
از آنجا که برنامه ریزی سبد هم با محصولات جدید و جاری در ارتباط است لازم است مالکان به‌همراه ذینفعان داخلی، معماران ارشد و مدیران فنی در آن شرکت داشته باشند. بهتر است ذینفعان درک درستی از کسب و کار داشته باشند تا در اولویت بندی بک‌لاگ خوب عمل کنند در برخی سازمانها گروهی با عنوان هیئت نظارت بر این فرآیند نظارت میکنند. مالکان در برنامه ریزی سبد به‌عنوان نماینده محصول خود شرکت کرده تا منابع مورد نیاز خود را اعلام کرده و از آن دفاع کنند. جهت اطمینان از قید فنی مهم در تصمیم گیری‌ها معماران ارشد یا مدیران فنی حضور دارند
فرآیند
برنامه ریزی سبد شامل محصولات جاری و محصولاتیست که چشم انداز آنها به تازگی ترسیم شده است. محصولات جدید به همراه داده‌هایی مانند هزینه، مدت تولید، ارزش و ریسک به برنامه ریزی سبد وارد میشوند که موارد در مرحله ترسیم چشم انداز محصول بدست می‌آیند. محصولات جاری نیز به همراه بازخورد مشتریان میانی، بهای تمام شده، زمان بندی، محدوده برآورد شده محصول، میزان بدهی فنی و اطلاعات بازار وارد برنامه ریزی سبد محصول میشوند که در تعیین مسیر آینده محصولات تاثیر گذارند. تصویر اول در کامنت
فعالیت برنامه ریزی سبد دو خروجی دارد
۱- بک‌لاگ سبد محصول که فهرست اولویت بندی شده از محصولات آتی است که تایید شده اما توسعه آنها هنوز شروع نشده
۲- مجموعه‌ای از محصولات فعال است که دو دسته هستند، دسته اول محصولات جدید تایید شده که در انتظار شروع توسعه هستند، دسته دوم محصولاتی که در لیست محصولات جاری قرار گرفته و ادامه سرمایه گذاری آنها تایید شده است
برای رسیدن به این خروجی‌ها چهار فعالیت انجام میشود: زمان بندی، مدیریت جریان ورودی، مدیریت جریان خروجی، و مدیریت محصولات جاری. تصویر دوم در کامنت
استراتژی زمان بندی
باید منابع سازمان را به شیون اقتصادی به محصولات اختصاص داد. روش‌ها و استراتژی‌های گوناگونی جهت قرار دادن محصولات در سبد وجود دارد از جمله:
۱- بهینه کردن سود چرخه‌ی عمر
۲- محاسبه هزینه تاخیر
۳- برآورد صحیح، نه دقیق
بهینه کردن سود چرخه‌ی عمر
ابتدا باید تصمیم بگیریم از چه متغیری برای اندازه گرفتن بهینه سازی استفاده کنیم. چارچوب اقتصادی یکی از موارد پیشنهادی است که می‌توان سود چرخه‌ی عمر را بررسی کرد که بر اساس آن باید سود چرخه‌ی عمر کل سبد بیشینه باشد. سود چرخه عمر، سودیست که یک محصول برای همیشه دارد لذا در سبد این را برای کل محصولات در نظر میگیریم و سود برخی محصولات را کاهش می‌دهیم بنابراین استراتژی سود چرخه عمر یافتن نگترتیب قرار دادن اقلام در بک‌لاگ سبد است که موجب بیشترین سود شود. در تعیین سود چرخه عمر دو عامل هزینه‌ی تاخیر و مدت تولید دارای اهمیت می‌باشد (مدت تولید محصول شاخص جایگزین حجم کار و اندازه‌ی محصول است) براساس مشاهده این دو مورد در محصولات سه گزینه پیش روی ما است (تصویر سوم در کامنت)
#scrum
@code_crafters
بسیاری از سازمانها بر روی تولید چند محصول همزمان کار میکنند که نیازمند رویکردی هستند تا تجربه خود را با چابکی ادغام کنند در غیر این صورت شکاف عمیقی بین برنامه ریزی و مدیریت سبد محصول بوجود می‌آید. در این بخش ۱۱ استراتژی مورد استفاده را در قالب ۳ گروه زمانبندی، جریان ورودی محصول و جریان خروجی محصول توضیح داده و روشی جهت تصمیم‌گیری بابت ادامه یا توقف سرمایه گذاری روی محصولات را بررسی خواهیم کرد
نگاه کلی
برنامه ریزی سبد محصول فعالیتی است که طی آن مشخص میشود روی چه اقلامی از بک‌لاگ به چه ترتیبی و چه مدتی کار انجام شود. یک قلم از سبد میتواند یک محصول، بخش قابل عرضه از یک محصول یا یک پروژه باشد
زمان انجام
برنامه ریزی سبد محصول فعالیتی است که هیچگاه به پایان نمی‌رسد و تا زمانیکه بیش از یک محصول داریم این روند. برنامه ریزی سبد کلان‌تر از برنامه ریزی محصول است اما به معنای تقدم بر آن نیست. ترسیم چشم انداز محصول میتواند ورودی خوبی برای برنامه ریزی سبد باشد. ابتدا بر روی سرمایه گذاری روی محصول و بعدا در کجا قرار گرفتن محصول در بک لاگ تصمیم گرفته میشود. برنامه ریزی سبد فقط برای محصولات جدید نیست بلکه در بازه‌های زمانی منظم و برنامه ریزی شده برای بازنگری محصولات جاری (در حال توسعه، عملیاتی شده، در حال فروش) نیز انجام میشود
شرکت کنندگان
از آنجا که برنامه ریزی سبد هم با محصولات جدید و جاری در ارتباط است لازم است مالکان به‌همراه ذینفعان داخلی، معماران ارشد و مدیران فنی در آن شرکت داشته باشند. بهتر است ذینفعان درک درستی از کسب و کار داشته باشند تا در اولویت بندی بک‌لاگ خوب عمل کنند در برخی سازمانها گروهی با عنوان هیئت نظارت بر این فرآیند نظارت میکنند. مالکان در برنامه ریزی سبد به‌عنوان نماینده محصول خود شرکت کرده تا منابع مورد نیاز خود را اعلام کرده و از آن دفاع کنند. جهت اطمینان از قید فنی مهم در تصمیم گیری‌ها معماران ارشد یا مدیران فنی حضور دارند
فرآیند
برنامه ریزی سبد شامل محصولات جاری و محصولاتیست که چشم انداز آنها به تازگی ترسیم شده است. محصولات جدید به همراه داده‌هایی مانند هزینه، مدت تولید، ارزش و ریسک به برنامه ریزی سبد وارد میشوند که موارد در مرحله ترسیم چشم انداز محصول بدست می‌آیند. محصولات جاری نیز به همراه بازخورد مشتریان میانی، بهای تمام شده، زمان بندی، محدوده برآورد شده محصول، میزان بدهی فنی و اطلاعات بازار وارد برنامه ریزی سبد محصول میشوند که در تعیین مسیر آینده محصولات تاثیر گذارند. تصویر اول در کامنت
فعالیت برنامه ریزی سبد دو خروجی دارد
۱- بک‌لاگ سبد محصول که فهرست اولویت بندی شده از محصولات آتی است که تایید شده اما توسعه آنها هنوز شروع نشده
۲- مجموعه‌ای از محصولات فعال است که دو دسته هستند، دسته اول محصولات جدید تایید شده که در انتظار شروع توسعه هستند، دسته دوم محصولاتی که در لیست محصولات جاری قرار گرفته و ادامه سرمایه گذاری آنها تایید شده است
برای رسیدن به این خروجی‌ها چهار فعالیت انجام میشود: زمان بندی، مدیریت جریان ورودی، مدیریت جریان خروجی، و مدیریت محصولات جاری. تصویر دوم در کامنت
استراتژی زمان بندی: کمک میکند تا ترتیب قرار گرفتن محصولات در بک‌لاگ سبد محصول تعیین شوند
استراتژی جریان ورودی: به شرکت کنندگان کمک میکند تا بدانند چه زمانی اقلام را به یک لاگ سبد اضافه کنند
استراتژی جریان خروجی: زمان خروج یک محصول از سبد را مشخص میکند
استراتژی محصولات جاری: تصمیم گیری درباره حفظ، تغییر مسیر، تحویل یا کنار گذاشتن محصولات جاری استفاده میشود
استراتژی زمان بندی
باید منابع سازمان را به شیون اقتصادی به محصولات اختصاص داد. روش‌ها و استراتژی‌های گوناگونی جهت قرار دادن محصولات در سبد وجود دارد از جمله:
۱- بهینه کردن سود چرخه‌ی عمر
۲- محاسبه هزینه تاخیر
۳- برآورد صحیح، نه دقیق
بهینه کردن سود چرخه‌ی عمر
ابتدا باید تصمیم بگیریم از چه متغیری برای اندازه گرفتن بهینه سازی استفاده کنیم. چارچوب اقتصادی یکی از موارد پیشنهادی است که می‌توان سود چرخه‌ی عمر را بررسی کرد که بر اساس آن باید سود چرخه‌ی عمر کل سبد بیشینه باشد. سود چرخه عمر، سودیست که یک محصول برای همیشه دارد لذا در سبد این را برای کل محصولات در نظر میگیریم و سود برخی محصولات را کاهش می‌دهیم بنابراین استراتژی سود چرخه عمر یافتن نگترتیب قرار دادن اقلام در بک‌لاگ سبد است که موجب بیشترین سود شود. در تعیین سود چرخه عمر دو عامل هزینه‌ی تاخیر و مدت تولید دارای اهمیت می‌باشد (مدت تولید محصول شاخص جایگزین حجم کار و اندازه‌ی محصول است) براساس مشاهده این دو مورد در محصولات سه گزینه پیش روی ما است (تصویر سوم در کامنت)
#scrum
@code_crafters
👍4
محاسبه هزینه تاخیر
در مرتب سازی محصولات در سبد باید توجه داشت که تمامی محصولات باهم شروع نمی‌شوند و تاخیر در شروع به معنای تاخیر در تحویل است و این یعنی صرف هزینه کردن که مبلغ آن قابل محاسبه است. هزینه تاخیر موجب تصمیم گیری آگاهانه میشود و با این وجود سازمانها عاجز از پاسخ دادن به این سوال هستند که اگر یک محصول یکماه تاخیر داشته باشد چقدر هزینه بردار است؟
اکثر سازمانها در این شرایط کار بر روی محصول با بازدهی بیشتر را شروع میکنند که تفکری خوب اما اشتباه است، با یک مثال پیش برویم دو محصول داریم که اولی هزینه بازگشتی بیشتری نسبت به دومی دارد، در این حالت میگوییم که خب ابتدا توسعه اولی را آغاز کنیم. اما اگر هزینه تاخیر اولی ۵ هزار واحد و دومی ۷۵ هزار واحد باشد آنگاه متوجه میشوید که محاسبه هزینه تاخیر تاثیر بسیار زیادی در رویکرد سازمان و ترتیب اقلام خواهد داشت. هزینه تاخیر نشانگر این است که زمان بشدت روی متغیرهای ما تاثیر گذار است. در مثال ما متغیرهای تحت تاثیر زمان عبارت‌اند از:
۱- زمان شروع و پایان توسعه
۲- میزان منابع در دسترس در زمان توسعه
۳- هزینه منابع
۳- مبلغی که افراد حاضر به پرداخت آن برای محصول هستند
۴- ریسک‌های موجود
۵- احتمال وقوع این ریسک‌ها و میزان تاثیر آنها بر هزینه
تاخیر و تسریع در شروع توسعه و مقادیر بالا بر سود محصول تاثیرگذار است بنابراین هزینه تاخیر تنها عامل تعیین کننده اولویت دهی اقلام سید نیست و باید زمان را که تاثیری بر مقادیر هزینه، سود، دانش و ریسک را دارد نیز در نظر گرفت.
یکی از راه‌های محاسبه هزینه تاخیر برابر با جمع سه عامل زیر است:
۱- ارزش کاربری: ارزش بالقوه از نگاه کاربر
۲- ارزش زمانی: چگونگی کاهش «ارزش کاربری» با گذشت زمان
۳- ارزش ناشی از کاهش ریسک یا استفاده از فرصت
به هر یک از این گزینه‌ها عددی مابین ۱ تا ۱۰ داده شده و جمع نهایی این سه برابر با جمع هزینه تاخیر است که می‌توان با آن پروفایل هزینه تاخیر را بررسی کرد. تصویر اول در کامنت
هزینه تاخیر عامل بسیار مهمی در اولویت بندی اقتصادی سبد بازسازی محصولات است
برآورد صحیح، نه دقیق
برای زمان بندی درست اقلام در بک لاگ سبد باید نسبت حجم کار به هزینه هر محصول را بدانیم. در ابتدای برآورد اطلاعات کمی در اختیار داریم لذا در برآورد هر قلم بدنبال صحت هستیم، نه دقت
در بخش‌های قبلی گفتیم سازمانها برای برآورد اقلام بجای اعداد از سایز استفاده میکنند (تصویر دوم در کامنت) که معادل هزینه محصول هستند که شامل حقوق و دستمزد کارکنان، مخارج سرمایه‌ای و سایر هزینه‌های تولید محصول است که معمولا بیشترین هزینه مربوط به حقوق است. مزیت رویکرد استفاده از سایز به اندازه مافی دقیق بودن آن است و اطلاعات مفیدی برای تصمیم گیری در سطح سبد محصول فراهم میکند
استراتژی‌های جریان ورودی
ترسیم چشم انداز به ما اطلاعات مفید و مورد نیاز برای تصمیم گیری اقتصادی در مورد ادامه یا توقف محصول فراهم میکند. و استراتژی جریان ورودی به ما در نحوه چگونگی اعمال فیلتر اقتصادی برای توقف یا ادامه محصول را می‌دهد و به موارد زیر نیز می‌پردازد
۱- اعمال فیلتر اقتصادی
خروجی ترسیم چشم انداز، عبارت است از سند چشم‌انداز محصول و اطلاعات لازم برای شفاف سازی.
این خروجی شامل داده‌های مربوط به محصول جدید است که بعنوان ورودی برنامه ریزی استفاده میشود که سازمان بر اساس آن تصمیم به ادامه یا توقف محصول را می‌گیرد.
هر سازمان فیلترهای اقتصادی مخصوص بخود را دارد اما یک فیلتر خوب باید فرصت‌هایی که نسبت ارزش به هزینه آنها چشم گیر است را به سرعت تایید کند و هرچیزی غیر از این را رد کند مگر در شرایط خاص (اگر ارزش محصول هزینه را پوشش می‌دهد آن را در سبد محصول قرار دهید، اگر بحث مبلغ ناچیز است آن را رد کنید)
۲- ایجاد توازن بین نرخ ورود و نرخ خروج
در عمل انتظار داریم یک جریان پیوسته در ورود اقلام به سبد و خروج آن برقرار باشد و از طرفی هم نمی‌خواهیم افزودن یکباره تعداد زیادی از محصولات، بک لاگ محصولات را شلوغ کنیم، چنین کاری فشار قابل توجهی به سیستم وارد میکند. اکثر سازمانها تصمیمات اقتصادی خود را در سه ماهه سوم سال با یک رویداد برگزار میکنند و محصولات زیادی را در سبد قرار می‌دهند که منجر به اختلال میشود
#scrum
@code_crafters
در مرتب سازی محصولات در سبد باید توجه داشت که تمامی محصولات باهم شروع نمی‌شوند و تاخیر در شروع به معنای تاخیر در تحویل است و این یعنی صرف هزینه کردن که مبلغ آن قابل محاسبه است. هزینه تاخیر موجب تصمیم گیری آگاهانه میشود و با این وجود سازمانها عاجز از پاسخ دادن به این سوال هستند که اگر یک محصول یکماه تاخیر داشته باشد چقدر هزینه بردار است؟
اکثر سازمانها در این شرایط کار بر روی محصول با بازدهی بیشتر را شروع میکنند که تفکری خوب اما اشتباه است، با یک مثال پیش برویم دو محصول داریم که اولی هزینه بازگشتی بیشتری نسبت به دومی دارد، در این حالت میگوییم که خب ابتدا توسعه اولی را آغاز کنیم. اما اگر هزینه تاخیر اولی ۵ هزار واحد و دومی ۷۵ هزار واحد باشد آنگاه متوجه میشوید که محاسبه هزینه تاخیر تاثیر بسیار زیادی در رویکرد سازمان و ترتیب اقلام خواهد داشت. هزینه تاخیر نشانگر این است که زمان بشدت روی متغیرهای ما تاثیر گذار است. در مثال ما متغیرهای تحت تاثیر زمان عبارت‌اند از:
۱- زمان شروع و پایان توسعه
۲- میزان منابع در دسترس در زمان توسعه
۳- هزینه منابع
۳- مبلغی که افراد حاضر به پرداخت آن برای محصول هستند
۴- ریسک‌های موجود
۵- احتمال وقوع این ریسک‌ها و میزان تاثیر آنها بر هزینه
تاخیر و تسریع در شروع توسعه و مقادیر بالا بر سود محصول تاثیرگذار است بنابراین هزینه تاخیر تنها عامل تعیین کننده اولویت دهی اقلام سید نیست و باید زمان را که تاثیری بر مقادیر هزینه، سود، دانش و ریسک را دارد نیز در نظر گرفت.
یکی از راه‌های محاسبه هزینه تاخیر برابر با جمع سه عامل زیر است:
۱- ارزش کاربری: ارزش بالقوه از نگاه کاربر
۲- ارزش زمانی: چگونگی کاهش «ارزش کاربری» با گذشت زمان
۳- ارزش ناشی از کاهش ریسک یا استفاده از فرصت
به هر یک از این گزینه‌ها عددی مابین ۱ تا ۱۰ داده شده و جمع نهایی این سه برابر با جمع هزینه تاخیر است که می‌توان با آن پروفایل هزینه تاخیر را بررسی کرد. تصویر اول در کامنت
برخی سازمانها تحت تاثیر قوانین خاص و سخت گیرانه نظارت شده هستند مانند سازمانهای تولید کننده محصولات پزشکی و بهداشتی، در این سازمان این عوامل میتواند از متغییرهای تاثیر گذار بر هزینه تاخیر باشد. برای مثال استاندارد ICD-10-CM نظام پزشکی ایالات متحده و رعایت قوانین U.S.HIPAA است
هزینه تاخیر عامل بسیار مهمی در اولویت بندی اقتصادی سبد بازسازی محصولات است
برآورد صحیح، نه دقیق
برای زمان بندی درست اقلام در بک لاگ سبد باید نسبت حجم کار به هزینه هر محصول را بدانیم. در ابتدای برآورد اطلاعات کمی در اختیار داریم لذا در برآورد هر قلم بدنبال صحت هستیم، نه دقت
در بخش‌های قبلی گفتیم سازمانها برای برآورد اقلام بجای اعداد از سایز استفاده میکنند (تصویر دوم در کامنت) که معادل هزینه محصول هستند که شامل حقوق و دستمزد کارکنان، مخارج سرمایه‌ای و سایر هزینه‌های تولید محصول است که معمولا بیشترین هزینه مربوط به حقوق است. مزیت رویکرد استفاده از سایز به اندازه مافی دقیق بودن آن است و اطلاعات مفیدی برای تصمیم گیری در سطح سبد محصول فراهم میکند
استراتژی‌های جریان ورودی
ترسیم چشم انداز به ما اطلاعات مفید و مورد نیاز برای تصمیم گیری اقتصادی در مورد ادامه یا توقف محصول فراهم میکند. و استراتژی جریان ورودی به ما در نحوه چگونگی اعمال فیلتر اقتصادی برای توقف یا ادامه محصول را می‌دهد و به موارد زیر نیز می‌پردازد
- ایجاد توازن بین نرخ ورود محصولات به سبد و نرخ خروج از آن
- روش استفاده از فرصت‌های نوظهور و جلوگیری از ایجاد گلوگاه در سبد محصول با استفاده از انتشارهای کوچکتر و زود به زود
۱- اعمال فیلتر اقتصادی
خروجی ترسیم چشم انداز، عبارت است از سند چشم‌انداز محصول و اطلاعات لازم برای شفاف سازی.
این خروجی شامل داده‌های مربوط به محصول جدید است که بعنوان ورودی برنامه ریزی استفاده میشود که سازمان بر اساس آن تصمیم به ادامه یا توقف محصول را می‌گیرد.
هر سازمان فیلترهای اقتصادی مخصوص بخود را دارد اما یک فیلتر خوب باید فرصت‌هایی که نسبت ارزش به هزینه آنها چشم گیر است را به سرعت تایید کند و هرچیزی غیر از این را رد کند مگر در شرایط خاص (اگر ارزش محصول هزینه را پوشش می‌دهد آن را در سبد محصول قرار دهید، اگر بحث مبلغ ناچیز است آن را رد کنید)
۲- ایجاد توازن بین نرخ ورود و نرخ خروج
در عمل انتظار داریم یک جریان پیوسته در ورود اقلام به سبد و خروج آن برقرار باشد و از طرفی هم نمی‌خواهیم افزودن یکباره تعداد زیادی از محصولات، بک لاگ محصولات را شلوغ کنیم، چنین کاری فشار قابل توجهی به سیستم وارد میکند. اکثر سازمانها تصمیمات اقتصادی خود را در سه ماهه سوم سال با یک رویداد برگزار میکنند و محصولات زیادی را در سبد قرار می‌دهند که منجر به اختلال میشود
#scrum
@code_crafters
👍4❤1
این رویکرد زمانی مناسب است که با عدم قطعیت بالا در سازمان روبرو باشیم
اغلب سازمانها برنامه استراتژیک سالانه خود را در سه ماه سوم سال برگذار میکنند و یکی از این نتایج فهرست محصولاتی است که می‌خواهند روی آن کار کنند. این محصولات باهم در بک‌لاگ سبد محصول وارد شده و موجب اختلال در برنامه ریزی سبد محصول میشوند
رویکرد استراتژیک خوب است اما نباید موجب اختلال در تصمیم گیری بک‌لاگ سبد محصول شود که تصمیمی برگشت ناپذیر است. این تصمیم‌ها زمانی گرفته میشود که با عدم قطعیت بالا روبرو هستیم و موجب نقض اصل باز نگه داشتن انتخاب‌های تا لحظه آخر هم میشود. از طرفی انتخاب همه اقلام بک‌لاگ سبد محصول اصل انتخاب اقتصادی اندازه بسته‌ها را نیز لغو میکند. این پردازش بسته بزرگ کار بیهوده و کم هزینه است. در سبد کوچکتر هر ترکیب با اندکی دقت کاملا اقتصادی و به صرفه است
بهترین کار بجای ورود ناگهانی، بلکه ورود اندک و در بازه‌های مشخص کوتاه مدت است که منجر به کاهش هزینه و حجم کار بازنگری هم میشود
همچنین بهتر است روی محصولات کوچکتر تمرکز کنیم تا جریان ورودی و خروجی توازن داشته باشد. در حجم بالا می‌توان از فیلترها و معیارهای پذیرش، سنجشی و اقتصادی سختگیرانه‌تری بهره ببریم که جریان ورودی را کنترل کند و موجب آزاد شدن محصول بعدی از بک‌لاگ سبد محصول با آهنگ منظمی گردد
۳-استقبال از فرصت نو ظهور
در برنامه ریزی سبد فرصت طلب باشید. فرصت نوظهور را بپذیرید. فرصتی که قبلا ناشناخته بوده یا احتمال وقوع آن به قدری کم بوده که تا به امروز ارزش سرمایه‌گذاری نداشته است. اقدام دیر در قبال فرصت‌ها موجب میشود بخش بزرگ ارزش اقتصادی را از دست بدهید.
شما نیاز دارید بک برنامه منظم و پیوسته همراه فیلتر اقتصادی موثر داشته باشید و در کنار آن از انتشارهای کوچک و سقف کار در جریان نیز بهره ببرید
۴-برنامه ریزی برای انتشارهای کوچک و زود به زود
انتشارات کوچکتر توجیه اقتصادی بهتری دارند و همواره موجب افزایش سود چرخه عمر محصول میشود. علاوه بر این از ایجاد «اثر کاروانی» نیز جلوگیری میکند، تصور کنید یک اسکانیا در مسیر وجود دارد و موجب شده که ماشین‌های کوچکتر وشت سر او صف طولانی تشکیل دهند این همان اثر کاروانی است که با ورود محصول بزرگ ایجاد میشود و دلیل آن استفاده از تمام ظرفیت جاده و مسیر است. محصولات بزرگ منابع زیاد و طولانی نیاز دارند و موجب صف تاخیر میشود که خود هزینه بردار است. راه جلوگیری از آن اعمال سیاست سازمانی است بزای مثال هیچ محصولی با حجم کاری بیش از نه ماه پذیرفته نمیشود مگر راه حلی برای شکستن آن در انتشارات کوچکتر پیدا شود. همچنین تصور عدم وجود انتشار دوم موجب میشود که جانب احتیاط را گرفته و ویژگی‌هایی اضافه کنیم که موجب بزرگ شدن محصول میشود
استراتژی جریان خروجی
این استراتژی به سازمانها کمک میکند تا تصمیم بگیرند چه زمانی یک محصول را از سبد محصول خارج کنند، سه استراتژی در این بخش
استراتژی اول
بجای افراد بیکار به کارهای ناتمام توجه کنید.
این اصل بیان میکند اتلاف منابع و خسارت ناشی از کارهای ناتمام بیشتر از بیکاری افراد به مراتب بیشتر است. شیوه مدیریت سبد محصول در اغلب سازمانها با این اصل در تناقض است.
شیوه رایج اما اشتباه شروع توسعه محصول:
این رویکرد همه افراد را مشغول نگه می‌دارد. نتیجه دیگر آن خطاپذیری و کند شدن کاری است که روی هر یک از محصولات انجام میشود. رویکرد بهتر انتخاب و شروع کار روی محصولی است که جریان کار مناسبی دارد و جریان کار دیگر محصولات جاری را مختل نمی‌کند، که ارتباط تنگاتنگی با استراتژی دوم دارد
استراتژی دوم
هرگز نباید محصولی را از سبد برداشت که فراتر از توان ماست (مدیر باهوش)، این رفتار منجر میشود ظرفیت اختصاص داده شده به هر محصول کاهش یابدکه منجر در تاخیر و کاهش کیفیت در تمامی محصولات میشود.
تعیین سقف مناسب کار در جریان چگونه است؟ قبلا گفتیم تیم‌ها واحد اندازه گیری هستند و باید از آنها استفاده نمود (اطلاع از تعداد تیم‌های اسکرام و توانایی آنها به ما کمک میکند تا تعداد و نوع فعالیت‌های که می‌توان همزمان انجام داد را تعیین کنیم)
استراتژی سوم
قبل از شروع کار بر روی یک محصول منتظر بمانید تا تیم اسکرام کامل تشکیل شود (تیم ناقص، تیمی است که تخصص کافی برای تکمیل ویژگی‌ها را ندارد) اکثر سازمانها به اشتباه فقط دنبال پر کردن تایم و مشغول نگه داشتن تیم هستند و این منجر میشود که اجازه ورود محصول دیگری را بدهند که منجر به کند شدن و اتلاف میشود
#scrum
@code_crafters
اغلب سازمانها برنامه استراتژیک سالانه خود را در سه ماه سوم سال برگذار میکنند و یکی از این نتایج فهرست محصولاتی است که می‌خواهند روی آن کار کنند. این محصولات باهم در بک‌لاگ سبد محصول وارد شده و موجب اختلال در برنامه ریزی سبد محصول میشوند
رویکرد استراتژیک خوب است اما نباید موجب اختلال در تصمیم گیری بک‌لاگ سبد محصول شود که تصمیمی برگشت ناپذیر است. این تصمیم‌ها زمانی گرفته میشود که با عدم قطعیت بالا روبرو هستیم و موجب نقض اصل باز نگه داشتن انتخاب‌های تا لحظه آخر هم میشود. از طرفی انتخاب همه اقلام بک‌لاگ سبد محصول اصل انتخاب اقتصادی اندازه بسته‌ها را نیز لغو میکند. این پردازش بسته بزرگ کار بیهوده و کم هزینه است. در سبد کوچکتر هر ترکیب با اندکی دقت کاملا اقتصادی و به صرفه است
بهترین کار بجای ورود ناگهانی، بلکه ورود اندک و در بازه‌های مشخص کوتاه مدت است که منجر به کاهش هزینه و حجم کار بازنگری هم میشود
همچنین بهتر است روی محصولات کوچکتر تمرکز کنیم تا جریان ورودی و خروجی توازن داشته باشد. در حجم بالا می‌توان از فیلترها و معیارهای پذیرش، سنجشی و اقتصادی سختگیرانه‌تری بهره ببریم که جریان ورودی را کنترل کند و موجب آزاد شدن محصول بعدی از بک‌لاگ سبد محصول با آهنگ منظمی گردد
۳-استقبال از فرصت نو ظهور
در برنامه ریزی سبد فرصت طلب باشید. فرصت نوظهور را بپذیرید. فرصتی که قبلا ناشناخته بوده یا احتمال وقوع آن به قدری کم بوده که تا به امروز ارزش سرمایه‌گذاری نداشته است. اقدام دیر در قبال فرصت‌ها موجب میشود بخش بزرگ ارزش اقتصادی را از دست بدهید.
شما نیاز دارید بک برنامه منظم و پیوسته همراه فیلتر اقتصادی موثر داشته باشید و در کنار آن از انتشارهای کوچک و سقف کار در جریان نیز بهره ببرید
۴-برنامه ریزی برای انتشارهای کوچک و زود به زود
انتشارات کوچکتر توجیه اقتصادی بهتری دارند و همواره موجب افزایش سود چرخه عمر محصول میشود. علاوه بر این از ایجاد «اثر کاروانی» نیز جلوگیری میکند، تصور کنید یک اسکانیا در مسیر وجود دارد و موجب شده که ماشین‌های کوچکتر وشت سر او صف طولانی تشکیل دهند این همان اثر کاروانی است که با ورود محصول بزرگ ایجاد میشود و دلیل آن استفاده از تمام ظرفیت جاده و مسیر است. محصولات بزرگ منابع زیاد و طولانی نیاز دارند و موجب صف تاخیر میشود که خود هزینه بردار است. راه جلوگیری از آن اعمال سیاست سازمانی است بزای مثال هیچ محصولی با حجم کاری بیش از نه ماه پذیرفته نمیشود مگر راه حلی برای شکستن آن در انتشارات کوچکتر پیدا شود. همچنین تصور عدم وجود انتشار دوم موجب میشود که جانب احتیاط را گرفته و ویژگی‌هایی اضافه کنیم که موجب بزرگ شدن محصول میشود
استراتژی جریان خروجی
این استراتژی به سازمانها کمک میکند تا تصمیم بگیرند چه زمانی یک محصول را از سبد محصول خارج کنند، سه استراتژی در این بخش
۱-توجه به کارهای ناتمام به جای افراد بیکار
۲-تعیین سقف برای کار در جریان
۳-منتظر ماندن برای تشکیل یک تیم کاما
استراتژی اول
بجای افراد بیکار به کارهای ناتمام توجه کنید.
این اصل بیان میکند اتلاف منابع و خسارت ناشی از کارهای ناتمام بیشتر از بیکاری افراد به مراتب بیشتر است. شیوه مدیریت سبد محصول در اغلب سازمانها با این اصل در تناقض است.
شیوه رایج اما اشتباه شروع توسعه محصول:
۱-محصول ردیف اول بک‌لاگ را بردارید و افرادی را برای انجام آن تعیین کنید
۲-آیا همه وقتشان پر شده است، اگر خیر گام اول را تکرار کنید
این رویکرد همه افراد را مشغول نگه می‌دارد. نتیجه دیگر آن خطاپذیری و کند شدن کاری است که روی هر یک از محصولات انجام میشود. رویکرد بهتر انتخاب و شروع کار روی محصولی است که جریان کار مناسبی دارد و جریان کار دیگر محصولات جاری را مختل نمی‌کند، که ارتباط تنگاتنگی با استراتژی دوم دارد
استراتژی دوم
هرگز نباید محصولی را از سبد برداشت که فراتر از توان ماست (مدیر باهوش)، این رفتار منجر میشود ظرفیت اختصاص داده شده به هر محصول کاهش یابدکه منجر در تاخیر و کاهش کیفیت در تمامی محصولات میشود.
تعیین سقف مناسب کار در جریان چگونه است؟ قبلا گفتیم تیم‌ها واحد اندازه گیری هستند و باید از آنها استفاده نمود (اطلاع از تعداد تیم‌های اسکرام و توانایی آنها به ما کمک میکند تا تعداد و نوع فعالیت‌های که می‌توان همزمان انجام داد را تعیین کنیم)
استراتژی سوم
قبل از شروع کار بر روی یک محصول منتظر بمانید تا تیم اسکرام کامل تشکیل شود (تیم ناقص، تیمی است که تخصص کافی برای تکمیل ویژگی‌ها را ندارد) اکثر سازمانها به اشتباه فقط دنبال پر کردن تایم و مشغول نگه داشتن تیم هستند و این منجر میشود که اجازه ورود محصول دیگری را بدهند که منجر به کند شدن و اتلاف میشود
#scrum
@code_crafters
👍4
استراتژی محصولات جاری
این استراتژی در تصمیم‌گیری به ما کمک میکند کدام اقدام را انجام دهیم: حفظ، تغییر مسیر، تحویل یا توقف. که در پایان هر اسپرینت گرفته میشود و گاها در بازه‌های و هنگام وقوع رویدادهای غیرعادی، بازبینی، بازبینی محصولات جاری ضروری میشود. واحدهای حاکمیتی شازمان استراتژی‌های متفاوتی دارند که یکی از این موارد «مطلوبیت اقتصاد نهایی» است که با اصول اسکرام و چابکی سازگار است و باید در تصمیم گیری‌ها مورد استفاده قرار گیرد
استفاده از مطلوبیت اقتصاد نهایی
تمام کارهای انجام شده تا قبل از لحظه تصمیم گیری، هزینه برگشت ناپذیر است. برای گام بعدی مطلوبیت اقتصاد نهایی مدنظر است، که با این سوال که آیا هزینه کردن سرمایه با توجه به بازدهی آینده توجیه پذیر است.
این دیدگاه به چهار انتخاب اصلی می‌دهد:
اگر سرمایه گذاری توجیه دارد در حالت حفظ قرار میگیریم، این سناریو زمانی رخ می‌دهد که یکی از محصولات جاری را بازنگری کنیم
در غیر این صورت باید رو سه حالت دیگر تصمیم گرفت
اگر محصول کمینه ویژگی‌های قابل انتشار را داراست حالت تحویل، در غیر این صورت مسیر اشتباه پیش رفته‌ایم، و اگر فکر کنیم مسیر دیگری ارزش اکتشاف داشته باشد حالت تغییر مسیر، اگر سرمایه گذاری توجیه ندارد و از موقعیت خود نیز رضایت نداریم حالت توقف
#scrum
@code_crafters
این استراتژی در تصمیم‌گیری به ما کمک میکند کدام اقدام را انجام دهیم: حفظ، تغییر مسیر، تحویل یا توقف. که در پایان هر اسپرینت گرفته میشود و گاها در بازه‌های و هنگام وقوع رویدادهای غیرعادی، بازبینی، بازبینی محصولات جاری ضروری میشود. واحدهای حاکمیتی شازمان استراتژی‌های متفاوتی دارند که یکی از این موارد «مطلوبیت اقتصاد نهایی» است که با اصول اسکرام و چابکی سازگار است و باید در تصمیم گیری‌ها مورد استفاده قرار گیرد
استفاده از مطلوبیت اقتصاد نهایی
تمام کارهای انجام شده تا قبل از لحظه تصمیم گیری، هزینه برگشت ناپذیر است. برای گام بعدی مطلوبیت اقتصاد نهایی مدنظر است، که با این سوال که آیا هزینه کردن سرمایه با توجه به بازدهی آینده توجیه پذیر است.
این دیدگاه به چهار انتخاب اصلی می‌دهد:
حفظ: ادامه توسعه محصول
تحویل: توقف کار و تحویل محصول
تغییر مسیر: ثبت آموخته‌ها و تغییر سمت و سوی آینده محصول
توقف: اتمام کار و کنار گذاشتن محصول
تصویر اول در کامنت‌ها
اگر سرمایه گذاری توجیه دارد در حالت حفظ قرار میگیریم، این سناریو زمانی رخ می‌دهد که یکی از محصولات جاری را بازنگری کنیم
در غیر این صورت باید رو سه حالت دیگر تصمیم گرفت
اگر محصول کمینه ویژگی‌های قابل انتشار را داراست حالت تحویل، در غیر این صورت مسیر اشتباه پیش رفته‌ایم، و اگر فکر کنیم مسیر دیگری ارزش اکتشاف داشته باشد حالت تغییر مسیر، اگر سرمایه گذاری توجیه ندارد و از موقعیت خود نیز رضایت نداریم حالت توقف
هیچگاه اجازه ندهید که تصمیمات حسابداری شما را به رفتار نابخردانه بکشاند
#scrum
@code_crafters
👍5
میکروسرویس‌ها یه روش جدید و مدرن برای طراحی نرم‌افزاره که برنامه‌های پیچیده رو به تکه‌های کوچکتر و مستقل تقسیم میکنه. این تکه‌ها (یا همون سرویس‌ها) هر کدوم یه کار خاص انجام میدن و می‌تونن جداگونه توسعه داده بشن، مستقر بشن و بزرگ‌تر بشن. این روش باعث میشه کار توسعه سریع‌تر، انعطاف‌پذیرتر و مقاوم‌تر باشه. ولی برای اینکه بتونیم میکروسرویس‌ها رو درست پیاده‌سازی کنیم، باید چالش‌های سیستم‌های توزیع‌شده رو خوب بشناسیم. دیزاین پترن ها راه‌حل‌های آماده و امتحان‌شده‌ای هستن که بهمون کمک میکنن این چالش‌ها رو راحت‌تر حل کنیم.
تو این مجموعه قراره تو ۵ بخش، ۱۰ دیزاین پترن مهم برای ساختن میکروسرویس قوی و مقیاس‌پذیر رو توضیح بدم. تو بخش اول، میریم سراغ اینکه میکروسرویس‌ها چی هستن؟ چرا دیزاین پترن ها مهم هستن؟، و دو تا الگوی خاص به اسم Service Service Registry Pattern(رجیستری سرویس) و Service Mesh Pattern(مش سرویس) رو بررسی میکنیم.
میکروسرویس‌ها چی هستن؟
چرا ادیزاین پترن ها مهم‌ان؟
دیزاین پترن میکروسرویس‌ها
1- رجیستری سرویس
برای درک بهتر الگوی رجیستری سرویس، فرض کنید یه شهر بزرگ دارید که پر از مغازه‌ها و خدمات مختلفه. هر مغازه (که اینجا نماینده یه میکروسرویسه) باید به مشتری‌ها (یا سرویس‌های دیگه) بگه کجاست و چی ارائه میده. حالا اگه هیچ سیستم مرکزی وجود نداشته باشه، هر مغازه باید خودش بره دنبال مغازه‌های دیگه، که این کار خیلی زمان‌بر و پیچیده میشه.
اینجاست که رجیستری سرویس مثل یه دفتر اطلاعات شهری عمل میکنه. هر مغازه وقتی شروع به کار میکنه، می‌ره و خودش رو تو این دفتر ثبت میکنه. مثلاً میگه: «من مغازه قهوه‌فروشی‌ام، تو این آدرس کار میکنم و این خدمات رو ارائه می‌دم.» بعد، اگه یه مغازه دیگه (مثلاً یه شیرینی‌فروشی) بخواد قهوه سفارش بده، به جای گشتن تو کل شهر، مستقیم می‌ره به این دفتر اطلاعات و آدرس قهوه‌فروشی رو پیدا میکنه.
تصویر دوم
اجزای اصلی این الگو:
- ثبت‌نام: هر سرویس وقتی شروع به کار میکنه، میگه "من فلان سرویسم، این آدرس شبکه‌م، اینم اطلاعاتم." اینجوری رجیستری همیشه یه لیست به‌روز از سرویس‌ها داره.
- پیدا کردن سرویس: وقتی یه سرویس میخواد با یکی دیگه حرف بزنه، از رجیستری می‌پرسه "فلان سرویس کجاست؟" و رجیستری آدرسش رو میده.
- چک کردن سلامت: رجیستری مرتب چک میکنه که سرویس‌ها سالم و فعالن یا نه. اگه یه سرویس از کار افتاده باشه، از لیست خطش می‌زنه.
- به‌روزرسانی پویا: اگه یه سرویس خاموش بشه، روشن بشه یا جاش عوض بشه، اطلاعاتش تو رجیستری به‌روز میشه تا همیشه اطلاعات درست باشه.
مثال: Netflix Eureka
Eureka یه ابزار کشف سرویس ساخته نتفلیکسه. سرورش طوری طراحی شده که همیشه در دسترس باشه و چند تا سرور بتونن اطلاعات سرویس‌های ثبت‌شده رو با هم به اشتراک بذارن.
تو این مجموعه قراره تو ۵ بخش، ۱۰ دیزاین پترن مهم برای ساختن میکروسرویس قوی و مقیاس‌پذیر رو توضیح بدم. تو بخش اول، میریم سراغ اینکه میکروسرویس‌ها چی هستن؟ چرا دیزاین پترن ها مهم هستن؟، و دو تا الگوی خاص به اسم Service Service Registry Pattern(رجیستری سرویس) و Service Mesh Pattern(مش سرویس) رو بررسی میکنیم.
میکروسرویس‌ها چی هستن؟
میکروسرویس‌ها یه سبک طراحی نرم‌افزارن که به جای یه برنامه بزرگ و یکپارچه، برنامه رو به یه سری سرویس‌های کوچیک و مستقل تقسیم میکنن. هر سرویس روی یه کار مشخص تمرکز داره، مثلاً مدیریت سفارش‌ها یا پردازش پرداخت. این سرویس‌ها می‌تونن جداگونه نوشته بشن، اجرا بشن و حتی با زبانها و ابزارهای مختلف ساخته بشن.
تصویر اول
این سرویس‌ها با هم از طریق API باهم ارتباط برقرار میکنند و معمولاً از روش‌های ساده‌ای مثل HTTP یا از مسیچ بروکر هایی (مثل RabbitMQ) استفاده میکنن. این روش باعث میشه:
- سیستم انعطاف‌پذیرتر باشه، چون هر سرویس جداگونه قابل‌تغییره.
- سریع‌تر بتونی تغییرات رو اعمال کنی.
- اگه یه سرویس خراب بشه، کل سیستم از کار نمی‌افته (مثل وقتی یه قطعه پازل خراب بشه، کل تصویر خراب نمی‌شه).
چرا ادیزاین پترن ها مهم‌ان؟
دیزاین پترن ها مثل یه جعبه‌ابزار برای توسعه‌دهنده‌ها هستن. دلایل اهمیت‌شون:
- استفاده دوباره و مقیاس‌پذیری: این الگوها مشکلات تکراری رو حل کردن، پس می‌تونی از راه‌حل‌های آماده استفاده کنی و کدهات رو طوری بنویسی که بعداً راحت بتونی سیستمت رو بزرگ‌تر کنی. مثلاً میکروسرویس‌ها بهت کمک میکنن با اضافه کردن سرویس‌های جدید، سیستم رو مقیاس‌پذیر کنی.
- نگهداری و انعطاف: الگوها یه ساختار استاندارد به کدها میدن که باعث میشه کدت تمیزتر و قابل‌فهم‌تر باشه. اینجوری اگه بخوای چیزی رو تغییر بدی، کل سیستم به هم نمی‌ریزه. مثلاً الگوهایی مثل Observer یا Strategy بهت کمک میکنن کدت رو مدولار و قابل‌تغییر نگه داری.
- بهینه‌سازی و زبان مشترک: بعضی الگوها کمک میکنن سیستمت سریع‌تر کار کنه، حافظه کمتری مصرف کنه یا امن‌تر باشه. ضمناً این الگوها یه زبان مشترک بین توسعه‌دهنده‌ها ایجاد میکنن که بتونن راحت‌تر با هم درباره سیستم‌های پیچیده حرف بزنن.
دیزاین پترن میکروسرویس‌ها
1- رجیستری سرویس
برای درک بهتر الگوی رجیستری سرویس، فرض کنید یه شهر بزرگ دارید که پر از مغازه‌ها و خدمات مختلفه. هر مغازه (که اینجا نماینده یه میکروسرویسه) باید به مشتری‌ها (یا سرویس‌های دیگه) بگه کجاست و چی ارائه میده. حالا اگه هیچ سیستم مرکزی وجود نداشته باشه، هر مغازه باید خودش بره دنبال مغازه‌های دیگه، که این کار خیلی زمان‌بر و پیچیده میشه.
اینجاست که رجیستری سرویس مثل یه دفتر اطلاعات شهری عمل میکنه. هر مغازه وقتی شروع به کار میکنه، می‌ره و خودش رو تو این دفتر ثبت میکنه. مثلاً میگه: «من مغازه قهوه‌فروشی‌ام، تو این آدرس کار میکنم و این خدمات رو ارائه می‌دم.» بعد، اگه یه مغازه دیگه (مثلاً یه شیرینی‌فروشی) بخواد قهوه سفارش بده، به جای گشتن تو کل شهر، مستقیم می‌ره به این دفتر اطلاعات و آدرس قهوه‌فروشی رو پیدا میکنه.
تصویر دوم
اجزای اصلی این الگو:
- ثبت‌نام: هر سرویس وقتی شروع به کار میکنه، میگه "من فلان سرویسم، این آدرس شبکه‌م، اینم اطلاعاتم." اینجوری رجیستری همیشه یه لیست به‌روز از سرویس‌ها داره.
- پیدا کردن سرویس: وقتی یه سرویس میخواد با یکی دیگه حرف بزنه، از رجیستری می‌پرسه "فلان سرویس کجاست؟" و رجیستری آدرسش رو میده.
- چک کردن سلامت: رجیستری مرتب چک میکنه که سرویس‌ها سالم و فعالن یا نه. اگه یه سرویس از کار افتاده باشه، از لیست خطش می‌زنه.
- به‌روزرسانی پویا: اگه یه سرویس خاموش بشه، روشن بشه یا جاش عوض بشه، اطلاعاتش تو رجیستری به‌روز میشه تا همیشه اطلاعات درست باشه.
مثال: Netflix Eureka
Eureka یه ابزار کشف سرویس ساخته نتفلیکسه. سرورش طوری طراحی شده که همیشه در دسترس باشه و چند تا سرور بتونن اطلاعات سرویس‌های ثبت‌شده رو با هم به اشتراک بذارن.
👍4
CodeCrafters
میکروسرویس‌ها یه روش جدید و مدرن برای طراحی نرم‌افزاره که برنامه‌های پیچیده رو به تکه‌های کوچکتر و مستقل تقسیم میکنه. این تکه‌ها (یا همون سرویس‌ها) هر کدوم یه کار خاص انجام میدن و می‌تونن جداگونه توسعه داده بشن، مستقر بشن و بزرگ‌تر بشن. این روش باعث میشه…
2-الگوی مش سرویس
تصور کنید تو یه شهر شلوغ هستید که پر از ماشین‌ها (میکروسرویس‌ها) است که می‌خوان با هم ارتباط برقرار کنن. اگه هر ماشین بخواد خودش مسیرش رو پیدا کنه، ترافیک قفل میشه، تصادف پیش میاد و هیچکس به موقع به مقصد نمی‌رسه. حالا مش سرویس مثل یه سیستم هوشمند مدیریت ترافیک عمل میکنه. این سیستم یه شبکه‌ی اختصاصی از «پروکسی‌ها» (مثل چراغ‌های راهنمایی یا پلیس‌های ترافیک) داره که تمام ارتباطات بین ماشین‌ها رو هدایت، کنترل و بهینه میکنه.
تصویر سوم
این لایه‌ی واسطه (که معمولاً با ابزارهایی مثل Istio یا Linkerd پیاده‌سازی میشه) مسئولیت کارهای زیر رو به عهده میگیره:
هدایت ترافیک: تصمیم میگیره درخواست‌ها از کدوم مسیر برن. مثلاً اگه یه سرویس شلوغ باشه، درخواست‌ها رو به یه نمونه‌ی دیگه از همون سرویس می‌فرسته.
تعادل بار (Load Balancing): بار کاری رو بین نسخه‌های مختلف یه سرویس تقسیم میکنه تا هیچ سرویسی بیش از حد تحت فشار نباشه.
امنیت: ارتباط‌ها رو رمزنگاری میکنه (مثلاً با TLS) و مطمئن میشه فقط سرویس‌های مجاز بتونن با هم حرف بزنن.
نظارت و رصد: اطلاعاتی مثل زمان پاسخ‌گویی، تعداد درخواست‌ها یا خطاها رو جمع‌آوری میکنه تا تیم توسعه بتونه عملکرد سیستم رو تحلیل کنه.
مدیریت خطا: اگه یه سرویس از کار بیفته، مش سرویس میتونه درخواست‌ها رو به‌طور خودکار به یه سرویس سالم هدایت کنه یا یه پیام خطای مناسب برگردونه.
مثال واقعی: فرض کنید تو یه اپلیکیشن خرید آنلاین، سرویس «پرداخت» و سرویس «سبد خرید» باید با هم کار کنن. بدون مش سرویس، هر کدوم از این سرویس‌ها باید خودشون منطق ارتباطی، مثل مدیریت خطاها یا رمزنگاری، رو پیاده‌سازی کنن. اما با مش سرویس، یه لایه‌ی پروکسی (مثلاً Envoy تو Istio) بین این دو سرویس قرار میگیره و تمام این کارها رو به‌صورت خودکار انجام میده. اینجوری تیم توسعه میتونه روی منطق اصلی سرویس‌ها تمرکز کنه و نگران پیچیدگی‌های ارتباطی نباشه.
مزیت بزرگ: مش سرویس کد سرویس‌ها رو ساده‌تر میکنه، چون منطق شبکه‌ای (مثل retry، timeout یا رمزنگاری) از سرویس‌ها جدا میشه و به لایه‌ی مش منتقل میشه. اما یه نکته هم داره: راه‌اندازی و مدیریت مش سرویس ممکنه خودش پیچیدگی‌هایی به سیستم اضافه کنه، مخصوصاً تو محیط‌های کوچکتر.
#microservice #design_patterns
@code_crafters
تصور کنید تو یه شهر شلوغ هستید که پر از ماشین‌ها (میکروسرویس‌ها) است که می‌خوان با هم ارتباط برقرار کنن. اگه هر ماشین بخواد خودش مسیرش رو پیدا کنه، ترافیک قفل میشه، تصادف پیش میاد و هیچکس به موقع به مقصد نمی‌رسه. حالا مش سرویس مثل یه سیستم هوشمند مدیریت ترافیک عمل میکنه. این سیستم یه شبکه‌ی اختصاصی از «پروکسی‌ها» (مثل چراغ‌های راهنمایی یا پلیس‌های ترافیک) داره که تمام ارتباطات بین ماشین‌ها رو هدایت، کنترل و بهینه میکنه.
تصویر سوم
این لایه‌ی واسطه (که معمولاً با ابزارهایی مثل Istio یا Linkerd پیاده‌سازی میشه) مسئولیت کارهای زیر رو به عهده میگیره:
هدایت ترافیک: تصمیم میگیره درخواست‌ها از کدوم مسیر برن. مثلاً اگه یه سرویس شلوغ باشه، درخواست‌ها رو به یه نمونه‌ی دیگه از همون سرویس می‌فرسته.
تعادل بار (Load Balancing): بار کاری رو بین نسخه‌های مختلف یه سرویس تقسیم میکنه تا هیچ سرویسی بیش از حد تحت فشار نباشه.
امنیت: ارتباط‌ها رو رمزنگاری میکنه (مثلاً با TLS) و مطمئن میشه فقط سرویس‌های مجاز بتونن با هم حرف بزنن.
نظارت و رصد: اطلاعاتی مثل زمان پاسخ‌گویی، تعداد درخواست‌ها یا خطاها رو جمع‌آوری میکنه تا تیم توسعه بتونه عملکرد سیستم رو تحلیل کنه.
مدیریت خطا: اگه یه سرویس از کار بیفته، مش سرویس میتونه درخواست‌ها رو به‌طور خودکار به یه سرویس سالم هدایت کنه یا یه پیام خطای مناسب برگردونه.
مثال واقعی: فرض کنید تو یه اپلیکیشن خرید آنلاین، سرویس «پرداخت» و سرویس «سبد خرید» باید با هم کار کنن. بدون مش سرویس، هر کدوم از این سرویس‌ها باید خودشون منطق ارتباطی، مثل مدیریت خطاها یا رمزنگاری، رو پیاده‌سازی کنن. اما با مش سرویس، یه لایه‌ی پروکسی (مثلاً Envoy تو Istio) بین این دو سرویس قرار میگیره و تمام این کارها رو به‌صورت خودکار انجام میده. اینجوری تیم توسعه میتونه روی منطق اصلی سرویس‌ها تمرکز کنه و نگران پیچیدگی‌های ارتباطی نباشه.
مزیت بزرگ: مش سرویس کد سرویس‌ها رو ساده‌تر میکنه، چون منطق شبکه‌ای (مثل retry، timeout یا رمزنگاری) از سرویس‌ها جدا میشه و به لایه‌ی مش منتقل میشه. اما یه نکته هم داره: راه‌اندازی و مدیریت مش سرویس ممکنه خودش پیچیدگی‌هایی به سیستم اضافه کنه، مخصوصاً تو محیط‌های کوچکتر.
#microservice #design_patterns
@code_crafters
👍5
Web hosting
در روزهای نخستین WWW هنگامی که مردم می‌خواستند محتوایی را در این شبکه به اشتراک بگذارند, می‌بایستی یک ماشین تهیه می‌کردند و با کانفیگ کردن آن در شبکه, اطلاعات ذخیره شده در آن را برای عموم قابل دستیابی می‌کردند. با گذر زمان و رشد این شبکه, شرکت‌ها متوجه شدند که همه مردم نمی‌توانند یک سرور فیزیکی بخرند و آن را کانفیگ کنند. پس شرکت های web hosting تاسیس شدند.
در این پیام می‌خواهیم به این بپردازیم که این شرکت‌ها دقیقا چه کاری انجام می‌دادند.
Dedicated Hosting:
تصور کنید Joe و Mary هرکدامشان یک سایت فروشگاهی دارند. آنها از یک شرکت به نام Irene’s Isp درخواست میکنند تا سایت آنها را host کنند. شرکت پروایدر که در رک خود چند سرور دارد, یکی را به Joe و یکی را به Mary می‌دهد که هرکس دامنه سایت آنها را وارد کرد, شرکت پروایدر تصمیم بگیرد که درخواست را به سمت کدام سرور هدایت کند.
Virtual Hosting:
تا اینجای ماجرا همه چیز خوب بنظر میرسه اما وقتی بحث قیمت سرورا میشه, هیچکس حاضر نیست هزاران دلار برای یک سرور بده که یک سایت ساده رو بیاره بالا!
پرووایدر ها تصمیم گرفتند که بجای اینکه به هر مشتری یک سرور گران بدهند, آن سرور را بخش بخش کنند و چندین سایت را روی آن serve کنند.
در این موقعیت کلی پول و منابع ذخیره میشود.
اما این به این معنی نیست که یک سرور چندین سایت را serve میکند. بلکه ممکن است replication انجام بشود و ترافیک این سایت ها بین چندین سرور پخش شود!
برسی یکی از مشکلات Virtual hosting:
تصور کنید دو سایت را روی یک سرور serve میکنیم.
a.com/index.html
b.com/index.html
برای دسترسی به این ریسورس‌‌ها یک ریکوئست مانند ریکوئست زیر ساخته و ارسال میشود:
GET /index.html HTTP/1.0
ما فقط میگوییم که از این host فایل index.html را می‌خواهیم اما سرور نمیداند که فایل را از کدام یکی از سایت های موجود بردارد.
برای حل این مشکل, در HTTP 1.1 تصمیم گرفتند که URL کامل را ارسال کنند تا وب سرور تصمیم بگیرد به کدام اپلیکیشن درخواست را ارسال کند. اما مشکل این است که این تصمیم بعد از توسعه هزاران اپلیکیشن گرفته شد. تکلیف برنامه های قدیمی چیست؟
1- ارسال url کامل
2- ارسال port اپلیکیشن
3- ارسال یک ip که isp آن را به یک اپلیکیشن منتسب کرده.
4- ارسال یک header که مشخص میکند به کدام برنامه ارسال شود
موارد ۱ و ۲ و ۴ تا حدودی مشخص است اما مورد سوم نیاز به توضیح بیشتری دارد.
در این روش که بسیار مرسوم است, پرووایدر یک آیپی را به joe می‌دهد که آن را برای سایت خودش استفاده کند. هنگامی که به این ایپی درخواست بزنیم, پرووایدر دقیقا می‌داند که این درخواست برای کدام یک از سرور ها و برای کدام سایت دیپلوی شده روی آن است.
#http_guideline
@code_crafters
در روزهای نخستین WWW هنگامی که مردم می‌خواستند محتوایی را در این شبکه به اشتراک بگذارند, می‌بایستی یک ماشین تهیه می‌کردند و با کانفیگ کردن آن در شبکه, اطلاعات ذخیره شده در آن را برای عموم قابل دستیابی می‌کردند. با گذر زمان و رشد این شبکه, شرکت‌ها متوجه شدند که همه مردم نمی‌توانند یک سرور فیزیکی بخرند و آن را کانفیگ کنند. پس شرکت های web hosting تاسیس شدند.
در این پیام می‌خواهیم به این بپردازیم که این شرکت‌ها دقیقا چه کاری انجام می‌دادند.
Dedicated Hosting:
تصور کنید Joe و Mary هرکدامشان یک سایت فروشگاهی دارند. آنها از یک شرکت به نام Irene’s Isp درخواست میکنند تا سایت آنها را host کنند. شرکت پروایدر که در رک خود چند سرور دارد, یکی را به Joe و یکی را به Mary می‌دهد که هرکس دامنه سایت آنها را وارد کرد, شرکت پروایدر تصمیم بگیرد که درخواست را به سمت کدام سرور هدایت کند.
Virtual Hosting:
تا اینجای ماجرا همه چیز خوب بنظر میرسه اما وقتی بحث قیمت سرورا میشه, هیچکس حاضر نیست هزاران دلار برای یک سرور بده که یک سایت ساده رو بیاره بالا!
پرووایدر ها تصمیم گرفتند که بجای اینکه به هر مشتری یک سرور گران بدهند, آن سرور را بخش بخش کنند و چندین سایت را روی آن serve کنند.
در این موقعیت کلی پول و منابع ذخیره میشود.
اما این به این معنی نیست که یک سرور چندین سایت را serve میکند. بلکه ممکن است replication انجام بشود و ترافیک این سایت ها بین چندین سرور پخش شود!
برسی یکی از مشکلات Virtual hosting:
تصور کنید دو سایت را روی یک سرور serve میکنیم.
a.com/index.html
b.com/index.html
برای دسترسی به این ریسورس‌‌ها یک ریکوئست مانند ریکوئست زیر ساخته و ارسال میشود:
GET /index.html HTTP/1.0
ما فقط میگوییم که از این host فایل index.html را می‌خواهیم اما سرور نمیداند که فایل را از کدام یکی از سایت های موجود بردارد.
برای حل این مشکل, در HTTP 1.1 تصمیم گرفتند که URL کامل را ارسال کنند تا وب سرور تصمیم بگیرد به کدام اپلیکیشن درخواست را ارسال کند. اما مشکل این است که این تصمیم بعد از توسعه هزاران اپلیکیشن گرفته شد. تکلیف برنامه های قدیمی چیست؟
1- ارسال url کامل
2- ارسال port اپلیکیشن
3- ارسال یک ip که isp آن را به یک اپلیکیشن منتسب کرده.
4- ارسال یک header که مشخص میکند به کدام برنامه ارسال شود
موارد ۱ و ۲ و ۴ تا حدودی مشخص است اما مورد سوم نیاز به توضیح بیشتری دارد.
در این روش که بسیار مرسوم است, پرووایدر یک آیپی را به joe می‌دهد که آن را برای سایت خودش استفاده کند. هنگامی که به این ایپی درخواست بزنیم, پرووایدر دقیقا می‌داند که این درخواست برای کدام یک از سرور ها و برای کدام سایت دیپلوی شده روی آن است.
#http_guideline
@code_crafters
❤6
CodeCrafters
میکروسرویس‌ها یه روش جدید و مدرن برای طراحی نرم‌افزاره که برنامه‌های پیچیده رو به تکه‌های کوچکتر و مستقل تقسیم میکنه. این تکه‌ها (یا همون سرویس‌ها) هر کدوم یه کار خاص انجام میدن و می‌تونن جداگونه توسعه داده بشن، مستقر بشن و بزرگ‌تر بشن. این روش باعث میشه…
سری دیزاین پترن میکروسرویس‌ها — بخش دوم
تو بخش اول، سرکی کشیدیم تو میکروسرویس‌ها فهمیدیم چرا دیزاین پترن مثل یه جعبه‌ابزار برای توسعه‌دهنده‌ها مهم‌ان، و دو تا الگوی بکاربردی به اسم رجیستری سرویس و مش سرویس رو بررسی کردیم. حالا تو بخش دوم، قراره دو تا الگوی دیگه رو مورد بررسی قرار بدیم: Circuit Breaker Pattern (الگوی مدار شکن😂) وEvent Sourcing Pattern(یافتن منبع رویداد)یکیشون جلوی خرابی‌های بزرگ رو میگیره، اون یکی تاریخچه سیستم رو نگه می‌داره تا هیچوقت چیزی از دست نره!
3- مدار شکن (Circuit Breaker Pattern)
تصور کنید تو یه خونه پر از وسایل برقی هستید. اگه یه دستگاه شروع کنه به خرابکاری و فیوز بپره، کل برق خونه قطع میشه. حالا Circuit Breaker و میکروسرویس‌ها یه جور فیوز هوشمند عمل میکنه. وقتی یه سرویس شروع میکنه به قاطی کردن (مثلاً چون شلوغه یا خاموشه)، این الگو می‌فهمه و نمی‌ذاره بقیه سرویس‌ها هم به مشکل بخورن. چطور؟ با قطع موقت ارتباط با سرویس خراب و دادن یه فرصت بهش که خودشو درست کنه!
اCircuit Breaker چطور کار میکنه؟
مثال:
سرویس پرداخت یهو قاطی میکنه چون کلی آدم همزمان دارن خرید میکنن. اگه اCircuit Breakerنباشه، کل سایت ممکنه هنگ کنه, اما با این پترن، سیستم می‌فهمه سرویس پرداخت مشکل داره، درخواست‌ها رو بهش نمی‌فرسته، وپیفام هایی مثل «لطفاً چند دقیقه دیگه امتحان کنیئ». حتی ممکنه یه صفحه کش‌شده نشون بده تا بتونییم بقیه خریدیمون رو ادامه بدیم. خرزمان سرویس پرداخت برگشت، همه‌چیز آروم‌آروم به حالت عادی برمی‌گرده.
همچنین تو پایتون، می‌تونیم از کتابخانه CircuitBreaker استفاده کنیم.
تو بخش اول، سرکی کشیدیم تو میکروسرویس‌ها فهمیدیم چرا دیزاین پترن مثل یه جعبه‌ابزار برای توسعه‌دهنده‌ها مهم‌ان، و دو تا الگوی بکاربردی به اسم رجیستری سرویس و مش سرویس رو بررسی کردیم. حالا تو بخش دوم، قراره دو تا الگوی دیگه رو مورد بررسی قرار بدیم: Circuit Breaker Pattern (الگوی مدار شکن😂) وEvent Sourcing Pattern(یافتن منبع رویداد)یکیشون جلوی خرابی‌های بزرگ رو میگیره، اون یکی تاریخچه سیستم رو نگه می‌داره تا هیچوقت چیزی از دست نره!
3- مدار شکن (Circuit Breaker Pattern)
تصور کنید تو یه خونه پر از وسایل برقی هستید. اگه یه دستگاه شروع کنه به خرابکاری و فیوز بپره، کل برق خونه قطع میشه. حالا Circuit Breaker و میکروسرویس‌ها یه جور فیوز هوشمند عمل میکنه. وقتی یه سرویس شروع میکنه به قاطی کردن (مثلاً چون شلوغه یا خاموشه)، این الگو می‌فهمه و نمی‌ذاره بقیه سرویس‌ها هم به مشکل بخورن. چطور؟ با قطع موقت ارتباط با سرویس خراب و دادن یه فرصت بهش که خودشو درست کنه!
اCircuit Breaker چطور کار میکنه؟
صور کنید یه سرویس مثل یه لامپه. مدار شکن سه تا حالت داره:
بسته (CLOSED): لامپ سالمه، همه‌چیز رواله، درخواست‌ها راحت میرن و میان.
باز (OPEN): لامپ سوخته یا اتصالی کرده! مدار شکن درخواست‌ها رو بلاک میکنه تا سرویس فرصت داشته باشه درست بشه.
نیمه‌باز (HALF OPEN): لامپ انگار داره کم‌کم روشن میشه. مدار شکن یه چند تا تست میکنه ببینه سرویس دوباره اوکیه یا نه. اگه اوکی بود، همه‌چیز به حالت عادی برمی‌گرده.
مراحل کارش چیه؟
چک کردن سلامت: مدار شکن مثل یه دکتر، مدام سرویس‌ها رو چک میکنه که حالشون خوبه یا نه.
تنظیم حد و مرز: یه سری خط قرمز برای چیزایی مثل تعداد خطاها یا سرعت پاسخ سرویس تعریف میکنه.
قطع کردن: اگه سرویس از خط قرمز رد شد، مدار شکن میگه «دیگه کافیه!» و ارتباط رو قطع میکنه.
پاسخ جایگزین: به جای اینکه کاربر رو تو تاریکی ول کنه، ممکنه یه پاسخ آماده (مثل داده کش‌شده) بده.
امتحان دوباره: بعد یه مدت، مثل یه معلم صبور، یه امتحان از سرویس میگیره ببینه درستش شده یا نه.
مثال:
سرویس پرداخت یهو قاطی میکنه چون کلی آدم همزمان دارن خرید میکنن. اگه اCircuit Breakerنباشه، کل سایت ممکنه هنگ کنه, اما با این پترن، سیستم می‌فهمه سرویس پرداخت مشکل داره، درخواست‌ها رو بهش نمی‌فرسته، وپیفام هایی مثل «لطفاً چند دقیقه دیگه امتحان کنیئ». حتی ممکنه یه صفحه کش‌شده نشون بده تا بتونییم بقیه خریدیمون رو ادامه بدیم. خرزمان سرویس پرداخت برگشت، همه‌چیز آروم‌آروم به حالت عادی برمی‌گرده.
همچنین تو پایتون، می‌تونیم از کتابخانه CircuitBreaker استفاده کنیم.
👍5
4-الگوی Event Sourcing
حالا تصور کنید یدیه دفترچه خاطرات دارید که هر چیزی تو زندگیت توناتفاق میافته رو توش می‌نویسیید: امروز چی خریدید، کجا رفتید، چی گفتی. اگه بخوادی یه روز خاص رو یادتون بیاد، فقط کافیه دفترچه رو باز کنید و اون صفحه رو بخونید. الگوی Event Sourcing به همون منبع یابی رویداد تو میکروسرویس‌ها هم یه همچین چیزیه تقریبا. جای اینکه فقط حالت فعلی سیستم (مثل موجودی حساب بانکی) رو ذخیره کنید، هر اتفاقی که تو سیستم میافته رو به‌عنوان یه ایونت ثبت میکنید. بعد هر وقت بخوایذ، می‌تونیذ این رویدادها رو بخونیذ و حالت سیستم رو بازسازی کنی.
اجزای اصلی این الگو:
مثال:
کلام آخر این که تو این بخش، دو تا الگوی خفن دیگه رو بررسی کردیم:Circuit Breaker که مثل یه نگهبان جلوی خرابی‌های بزرگ رو میگیره(مثل بتمن🥸)، و Event Sourcing که مثل یه دفترچه خاطرات همه‌چیز رو ثبت میکنه.
#microservice #design_patterns
@code_crafters
حالا تصور کنید یدیه دفترچه خاطرات دارید که هر چیزی تو زندگیت توناتفاق میافته رو توش می‌نویسیید: امروز چی خریدید، کجا رفتید، چی گفتی. اگه بخوادی یه روز خاص رو یادتون بیاد، فقط کافیه دفترچه رو باز کنید و اون صفحه رو بخونید. الگوی Event Sourcing به همون منبع یابی رویداد تو میکروسرویس‌ها هم یه همچین چیزیه تقریبا. جای اینکه فقط حالت فعلی سیستم (مثل موجودی حساب بانکی) رو ذخیره کنید، هر اتفاقی که تو سیستم میافته رو به‌عنوان یه ایونت ثبت میکنید. بعد هر وقت بخوایذ، می‌تونیذ این رویدادها رو بخونیذ و حالت سیستم رو بازسازی کنی.
اجزای اصلی این الگو:
ا(Event): مثل یه خط تو دفترچه‌ست. مثلاً «کاربر X صد تومن واریز کرد». هر ایونت یه تغییر تو سیستم رو نشون میده.
ا(Event Store): همون دفترچه خاطراته! همه رویدادها رو به ترتیب و بدون امکان تغییر ذخیره میکنه.
ا(Event Handler): مثل یه کتابدار که می‌ره تو دفترچه، ایونت رو می‌خونه و سیستم رو به‌روزرسانی میکنه.
ا(Aggregate): یه گروه از ایونت هایی مرتبط که با هم یه داستان کامل (مثل لاگ یه حساب بانکی) رو تعریف میکنن.
ا(Event Stream): تاریخچه ایونت هایی یه چیز خاص (مثلاً همه تراکنش‌های یه حساب).
ا(Event Publisher): مثل یه پستچی که خبر رو به بقیه میرسونه، ایونت رو به سرویس‌های دیگه می‌فرسته.
ا(Event Subscriber): سرویس‌هایی که منتظرن خبر جدید برسه و باهاش کار کنن.
ا(Command): درخواست‌هایی که کاربر می‌فرسته (مثل «پول واریز کن») و باعث میشن یه ایونت جدید ساخته بشه.
مثال:
این دفعه تصیور کنید یه اپلیکیشن بانکی دارید. به جای اینکه فقط موجودی حساب کاربر رو تو دیتابیس ذخیره کنید، هر تراکنش (مثل واریز، برداشت، یا انتقال) رو به‌عنوان یه رویداد ثبت می‌کنیذ. مثلاً:
رویداد 1: «100 تومن واریز شد»
رویداد 2: «50 تومن برداشت شد» اگه بخواید موجودی حساب رو ببینی،د سیستم همه رویدادهای اون حساب رو می‌خونه و محاسبه میکنه: 100 - 50 = 50 تومن. این روش نه‌تنها تاریخچه کامل رو نگه می‌داره، بلکه اگه بخواهید حسابرسی کنید یا خطایی رو پیدا کنید، خیلی راحت میتونید همه‌چیز رو بررسی کنید.
همچنین مقیاس پذیری ,حسابرسی و انعظاف پذیری از ویژگی های Event Sourcing به حساب میان.
کلام آخر این که تو این بخش، دو تا الگوی خفن دیگه رو بررسی کردیم:Circuit Breaker که مثل یه نگهبان جلوی خرابی‌های بزرگ رو میگیره(مثل بتمن🥸)، و Event Sourcing که مثل یه دفترچه خاطرات همه‌چیز رو ثبت میکنه.
#microservice #design_patterns
@code_crafters
👍5
رمان گرگ بیابان از هرمان هسه
قبل از هرچیزی عمیقا باور کردم که این کتاب رو خدا و شیطان باهم نوشتند
موضوع کتاب ارجاع به درون انسان هستش، خویشتن‌های درونی هر انسانی
اما بر خلاف خیلی از کتاب‌های دیگه به بخش تاریک و ترسناک درون انسان پرداخته و در تقابل روح پاک و پلید انسان و چگونه پیروز شدن پلیدی بر پاکی در درون می‌پردازد
درک سطر به سطر کتاب برام سخت بود
در یک کلام چنین شاهکار وحشتناکی رو تا کنون نخونده بودم، خوندنش رو به هرکسی توصیه نمیکنم، منتها اگر حس میکنید روحتون در بالاترین حالت پذیرش درونتون قرار داره بخونیدش
یک بخش از کتاب برای خودم خیلی ترسناک بود
#book
@code_crafters
قبل از هرچیزی عمیقا باور کردم که این کتاب رو خدا و شیطان باهم نوشتند
موضوع کتاب ارجاع به درون انسان هستش، خویشتن‌های درونی هر انسانی
اما بر خلاف خیلی از کتاب‌های دیگه به بخش تاریک و ترسناک درون انسان پرداخته و در تقابل روح پاک و پلید انسان و چگونه پیروز شدن پلیدی بر پاکی در درون می‌پردازد
درک سطر به سطر کتاب برام سخت بود
در یک کلام چنین شاهکار وحشتناکی رو تا کنون نخونده بودم، خوندنش رو به هرکسی توصیه نمیکنم، منتها اگر حس میکنید روحتون در بالاترین حالت پذیرش درونتون قرار داره بخونیدش
#book
@code_crafters
👍6
CodeCrafters
4-الگوی Event Sourcing حالا تصور کنید یدیه دفترچه خاطرات دارید که هر چیزی تو زندگیت توناتفاق میافته رو توش می‌نویسیید: امروز چی خریدید، کجا رفتید، چی گفتی. اگه بخوادی یه روز خاص رو یادتون بیاد، فقط کافیه دفترچه رو باز کنید و اون صفحه رو بخونید. الگوی Event…
سری الگوهای طراحی میکروسرویس‌ها — بخش سوم
تو بخش اول، با مفاهیم پایه‌ی میکروسرویس‌ها آشنا شدیم و الگوهای رجیستری سرویس و مش سرویس رو بررسی کردیم و تو تو بخش دوم هم الگوهای مدار شکن و منبع‌یابی رویداد رو دیدیم که چطور به پایداری و تاریخچه‌نگاری سیستم کمک میکنن.
حالا تو بخش سوم، قراره با دو تا الگوی مهم دیگه آشنا بشیم: الگوی SAGA و الگوی API Gateway. این دو الگو بهمون کمک میکنن تا هماهنگی داده‌ها و دسترسی به سرویس‌ها رو تو سیستم‌های پخش‌شده بهتر مدیریت کنیم.
5. الگوی SAGA (SAGA Pattern)
الگوی SAGA یه روش کارآمد برای مدیریت هماهنگی داده‌ها تو تراکنش‌های پخش‌شده بین میکروسرویس‌هاست.
تو سیستم‌های سنتی، تراکنش‌ها با مدل ACID مدیریت میشن که تضمین میکنه همه‌چیز یا کامل انجام بشه یا اصلاً انجام نشه.
اما تو معماری میکروسرویس، که هر سرویس دیتابیس خودش رو داره، پیاده‌سازی این مدل خیلی سخته.
اینجاست که الگوی SAGA یه راه‌حل هوشمندانه ارائه میده.
چطور کار میکنه SAGA؟
6. الگوی API Gateway (API Gateway Pattern)
الگوی API Gateway یه راه‌حل برای ساده‌سازی و مدیریت دسترسی به میکروسرویس‌هاست.
تو سیستم‌های پخش‌شده، معمولاً سرویس‌های زیادی وجود دارن که هر کدوم وظیفه خاصی دارن.
اگه کلاینت‌ها (مثلاً اپ موبایل یا وب) بخوان مستقیماً با هر سرویس ارتباط برقرار کنن، کار خیلی پیچیده میشه.
اینجاست که API Gateway وارد میشه و همه‌چیز رو ساده‌تر میکنه.
چطور کار میکنهAPI Gateway ؟
مثل یه دربان هوشمند جلوی سیستم می‌ایسته.
هر درخواستی که از سمت کاربر میاد، اول وارد API Gateway میشه، بعد اون تصمیم میگیره این درخواست باید به کدوم سرویس بره.
#microservice #design_patterns
@code_crafters
تو بخش اول، با مفاهیم پایه‌ی میکروسرویس‌ها آشنا شدیم و الگوهای رجیستری سرویس و مش سرویس رو بررسی کردیم و تو تو بخش دوم هم الگوهای مدار شکن و منبع‌یابی رویداد رو دیدیم که چطور به پایداری و تاریخچه‌نگاری سیستم کمک میکنن.
حالا تو بخش سوم، قراره با دو تا الگوی مهم دیگه آشنا بشیم: الگوی SAGA و الگوی API Gateway. این دو الگو بهمون کمک میکنن تا هماهنگی داده‌ها و دسترسی به سرویس‌ها رو تو سیستم‌های پخش‌شده بهتر مدیریت کنیم.
5. الگوی SAGA (SAGA Pattern)
الگوی SAGA یه روش کارآمد برای مدیریت هماهنگی داده‌ها تو تراکنش‌های پخش‌شده بین میکروسرویس‌هاست.
تو سیستم‌های سنتی، تراکنش‌ها با مدل ACID مدیریت میشن که تضمین میکنه همه‌چیز یا کامل انجام بشه یا اصلاً انجام نشه.
اما تو معماری میکروسرویس، که هر سرویس دیتابیس خودش رو داره، پیاده‌سازی این مدل خیلی سخته.
اینجاست که الگوی SAGA یه راه‌حل هوشمندانه ارائه میده.
چطور کار میکنه SAGA؟
تو این الگو، یه تراکنش بزرگ به چند قدم کوچیک‌تر تقسیم میشه که هر کدومش رو یه سرویس انجام میده.
هر قدم یه پیام یا رویداد منتشر میکنه که باعث فعال شدن قدم بعدی میشه.
اگه یه قدم به مشکل بخوره، یه سری عملیات جبرانی (Compensating Transactions) اجرا میشن تا وضعیت به حالت اولیه برگرده.
دو نوع هماهنگی در SAGA:
🔹 کروئوگرافی (Choreography):
هیچ هماهنگ‌کننده‌ی مرکزی نداریم. هر سرویس یه رویداد منتشر میکنه و بقیه سرویس‌ها خودشون به اون گوش میدن.
مثلاً سرویس سفارش یه رویداد «سفارش ثبت شد» می‌فرسته، سرویس انبار اینو می‌شنوه و موجودی رو کم میکنه.
این روش تو سیستم‌های ساده خوبه، ولی تو سیستم‌های بزرگ مدیریت سخت میشه.
🔹 ارکستراسیون (Orchestration):
اینجا یه سرویس مرکزی (Orchestrator) همه‌چیز رو مدیریت میکنه. مثلاً اول به سرویس سفارش میگه سفارش رو ثبت کن، بعد به سرویس پرداخت دستور میده پول رو بگیره.
مدیریتش متمرکزه و برای سیستم‌های پیچیده بهتره، ولی نقطه‌ی شکست هم میتونه باشه.
یه مثال ساده:
تو یه فروشگاه آنلاین، وقتی سفارشی ثبت میکنید، چند مرحله باید طی بشه:
سرویس سفارش، سفارش رو ثبت میکنه.
سرویس انبار، موجودی رو کم میکنه.
سرویس پرداخت، مبلغ رو برداشت میکنه.
اگه پرداخت موفق نباشه، عملیات جبرانی فعال میشن: موجودی انبار برمی‌گرده و سفارش لغو میشه.
اینطوری مطمئن میشیم که هیچ چیزی نصفه نمی‌مونه.
چرا SAGA مهمه؟
تضمین هماهنگی داده‌ها تو سیستم‌های پخش‌شده
مدیریت درست خطاها با عملیات جبرانی
مناسب برای معماری‌های مدرن که نمی‌تونن از تراکنش‌های سنتی استفاده کنن
6. الگوی API Gateway (API Gateway Pattern)
الگوی API Gateway یه راه‌حل برای ساده‌سازی و مدیریت دسترسی به میکروسرویس‌هاست.
تو سیستم‌های پخش‌شده، معمولاً سرویس‌های زیادی وجود دارن که هر کدوم وظیفه خاصی دارن.
اگه کلاینت‌ها (مثلاً اپ موبایل یا وب) بخوان مستقیماً با هر سرویس ارتباط برقرار کنن، کار خیلی پیچیده میشه.
اینجاست که API Gateway وارد میشه و همه‌چیز رو ساده‌تر میکنه.
چطور کار میکنهAPI Gateway ؟
مثل یه دربان هوشمند جلوی سیستم می‌ایسته.
هر درخواستی که از سمت کاربر میاد، اول وارد API Gateway میشه، بعد اون تصمیم میگیره این درخواست باید به کدوم سرویس بره.
وظایف کلیدی API Gateway:
هدایت و تعادل بار (Routing and Load Balancing): درخواست‌ها رو بر اساس قوانین به سرویس درست می‌فرسته و با پخش بار بین نسخه‌های مختلف، سیستم رو پایدار نگه می‌داره.
ترجمه پروتکل (Protocol Translation): میتونه درخواست‌های HTTP رو به فرمت‌های دیگه (مثل gRPC) تبدیل کنه تا با سرویس‌های بک‌اند سازگار بشه.
تغییر درخواست (Request Transformation): درخواست‌ها و پاسخ‌ها رو بر اساس نیاز سرویس‌ها تغییر میده، مثلاً پارامترها یا هدرها رو تنظیم میکنه.
کش کردن (Caching): با ذخیره داده‌ها، سرعت رو بالا می‌بره و بار رو از روی سرویس‌ها کم میکنه.
هدایت و تعادل بار (Load Balancing) بین چند سرور
یه مثال ساده:
فرض کنید یه اپلیکیشن خرید دارید.
به‌جای اینکه اپ مستقیماً با سرویس سفارش، پرداخت و ارسال ارتباط بگیره، همه درخواست‌ها میرن سمت API Gateway.
اونجا اول اعتبارسنجی انجام میشه، بعد درخواست به سرویس مربوطه فرستاده میشه، و اگه لازم باشه، جواب کش میشه تا سریع‌تر به دست کاربر برسه.
چرا API Gateway مهمه؟
دسترسی به سرویس‌ها رو متمرکز و ساده میکنه
امنیت و نظارت رو از یه نقطه انجام میده
به مقیاس‌پذیری، پایداری و مانیتورینگ سیستم کمک میکنه
#microservice #design_patterns
@code_crafters
👍5
نوشتن یا بررسی یک نرم افزار رو از کجا شروع کنیم؟؟؟
سوالی که همیشه وجود داره حتی تو مصاحبه‌های استخدامی
گاها وقت‌ها حس میکنم اون چیزی که یاد میگیریم و راجبش میخونیم رو یجوری محدود میکنیم که واقعا از گزینه‌های بیشتری که بهمون میده رو فراموش میکنیم
یک نرم افزار از بیرون سه تا بخش داره
view
service
model
چرا میگیم این سه بخش و بالاتر گفتم محدود؟
دو شیوه توسعه نرم افزار مهم رو به یاد بیارید DDD و TDD علاوه بر اینکه این دو رویکرد تمام جنبه‌های خاص رو مورد پوشش قرار میدن موارد انتزاعی هم بهمون تدریس میکنن
که یکی از اونها سوال اولمون بود؟؟؟
از کجا شروع به نوشتن یا بررسی کنیم
در رویکرد DDD میگه اول سرویس‌هات رو بنویس و بعد لایه داده و ویوت رو مطابق با اون پیش ببر (در ابتدای نوشتن از فیک دیتا بهره ببر) چرا این رویکرد جالبه برامون، چون ما هیچ درکی از پیچیدگی نداریم و هیچ درکی هم از تمام نیازمندی داده هم نداریم، وقتی DDD میاد وسط هم پیچیدگیت مشخص میشه و هم درکت از نیازمندی داده، تو شروع پروژه کمتر مدلت رو لمس میکنی یا بهتره بگیم مدام و مدام مدل‌هات رو لمس نمیکنی و درکت از داده بیشتر میشه، این از اتلاف وقت و هزینه برای سازمان جلوگیری میکنه و بهمون میگه با چه چیزی قراره روبرو بشیم
تو روش TDD میگه بیا اول تست بنویس بعد حالا اون رو پاس کن، که از ویوهامون شروع میکنی، چه اتفاقی میافته؟؟؟
انتظارمون کاملا مشخص میشه و این منجر میشه ویوهای کامل و جامعتری داشته باشیم و بدونیم چی لازم داریم بابتش و باز همین منجر میشه کمتر مدل رو لمس کنی و تغییر بدی، انتظارت از خروجی کاملا مشخص هستش و بدهی فنی رو به حد مناسبی میرسونه که لازمه یک پروژه هستش، صرف زمان اولیه داره اما بازخورد دورنگر بهتری بهمون میده
این دو رویکرد منجر به برطرف کردن بدفهمی و کج فهمی‌های مدل سه لایه میشه و خب بسیار عالی
ولی از کجا بدونیم کدومش رو کجا بکار ببریم؟؟؟
اگه با یک سیستم دارای پیچیدگی روبرو هستید DDD
اگه با یک سیستم با اطمینان بالا روبرو هستید TDD
آیا رویکرد بهتری سراغ داریم؟؟؟
بله ترکیب این دو با هم
#DDD
#TDD
@code_crafters
سوالی که همیشه وجود داره حتی تو مصاحبه‌های استخدامی
گاها وقت‌ها حس میکنم اون چیزی که یاد میگیریم و راجبش میخونیم رو یجوری محدود میکنیم که واقعا از گزینه‌های بیشتری که بهمون میده رو فراموش میکنیم
یک نرم افزار از بیرون سه تا بخش داره
view
service
model
چرا میگیم این سه بخش و بالاتر گفتم محدود؟
دو شیوه توسعه نرم افزار مهم رو به یاد بیارید DDD و TDD علاوه بر اینکه این دو رویکرد تمام جنبه‌های خاص رو مورد پوشش قرار میدن موارد انتزاعی هم بهمون تدریس میکنن
که یکی از اونها سوال اولمون بود؟؟؟
از کجا شروع به نوشتن یا بررسی کنیم
در رویکرد DDD میگه اول سرویس‌هات رو بنویس و بعد لایه داده و ویوت رو مطابق با اون پیش ببر (در ابتدای نوشتن از فیک دیتا بهره ببر) چرا این رویکرد جالبه برامون، چون ما هیچ درکی از پیچیدگی نداریم و هیچ درکی هم از تمام نیازمندی داده هم نداریم، وقتی DDD میاد وسط هم پیچیدگیت مشخص میشه و هم درکت از نیازمندی داده، تو شروع پروژه کمتر مدلت رو لمس میکنی یا بهتره بگیم مدام و مدام مدل‌هات رو لمس نمیکنی و درکت از داده بیشتر میشه، این از اتلاف وقت و هزینه برای سازمان جلوگیری میکنه و بهمون میگه با چه چیزی قراره روبرو بشیم
تو روش TDD میگه بیا اول تست بنویس بعد حالا اون رو پاس کن، که از ویوهامون شروع میکنی، چه اتفاقی میافته؟؟؟
انتظارمون کاملا مشخص میشه و این منجر میشه ویوهای کامل و جامعتری داشته باشیم و بدونیم چی لازم داریم بابتش و باز همین منجر میشه کمتر مدل رو لمس کنی و تغییر بدی، انتظارت از خروجی کاملا مشخص هستش و بدهی فنی رو به حد مناسبی میرسونه که لازمه یک پروژه هستش، صرف زمان اولیه داره اما بازخورد دورنگر بهتری بهمون میده
این دو رویکرد منجر به برطرف کردن بدفهمی و کج فهمی‌های مدل سه لایه میشه و خب بسیار عالی
ولی از کجا بدونیم کدومش رو کجا بکار ببریم؟؟؟
اگه با یک سیستم دارای پیچیدگی روبرو هستید DDD
اگه با یک سیستم با اطمینان بالا روبرو هستید TDD
آیا رویکرد بهتری سراغ داریم؟؟؟
بله ترکیب این دو با هم
یه مصاحبه دعوت شدم بابت تیم لید یک مجموعه، فرد مقابل هیچ درکی از نقش تیم لید نداشت و کل مصاحبه با پرسیدن چگونه باگ یا یک چالش رو حل کنیم، دوست عزیز نماینده اون سازمان اول اینکه خیلی خوشحال شدم از آشناییت، دوم اینکه شما درکی از مرز بین تیم لید و سوپر دولوپر نداری چرا قبول کردی بعنوان نماینده سازمان بیای تو مصاحبه، اینکه حتی بهم نگفتی جایگاهت در سازمان چیه که امیدوارم مدیرفنی نبوده باشی، کل مصاحبه من ذهنم درگیر خودت بود بیشتر و اینکه داری چکار میکنی، تیم لیدی که جواب یا حلال مشکلات باشه به اون سرعت تو مصاحبه هیچوقت نمیتونه لیدر خوبی باشه، این پست یکی از وظایف تیم لید هستش
#DDD
#TDD
@code_crafters
👍5❤3👎1
حضور CTEs در دیتابیس و محدودیت ormها
بیایید با یک مثال براتون توضیح بدم، یک پیچیدگی نسبتا معمولی در دیتابیس و کوئری‌ها
یک مدل رو تصور کنید که دوتا فیلد داره
class Model:
id: int(PK)
name: str
parent: FK(self, null)
در نگاه اول این یک مدل کاملا ساده هستش و کاملا هم درست فکر میکنید این یه مدل ساده و ابتدایی هستش، اما منطق تجاری؟؟؟
منطق تجاری از ما میخواد که در ازای یک کوئری تمام والد‌های اون object رو بدست بیاریم، تصور کنید که ریشه‌های تو در تو داخل مدل برای یک object حدود 100 والد وجود داره و برای یک object دیگه ممکنه 1000 والد وجود داشته باشه، منطق تجاری از ما خواسته والد هر آبجکتی که درخواست میشه از مدل رو هم بهش برگردونیم، در دید اول این یک مسئله ساده هستش اما یک منطق تجاری نسبتا پیچیده هستش
خود CTEs ها در دیتابیس چیه؟
بطور خلاصه یک‌نمای جدولی موقتی هستش که فقط و فقط در طول اجرای همون کوئری وجود دارند. داخل زبان کوئری با استفاده از With همراه با join و on ما یک ساختار درختی رو متصور میشیم و داده مدنظر خودمون رو ازش میکشیم بیرون. جدول موقت اولین گام برای ورود به ادمین پایگاه داده شدن هستش شاید تعجب کنید از این حرف ولی حقیقت داره، در مثال ما یک منطق نسبتا پیچیده مطرح شد (از نوع CTE بازگشتی) کاربرد اصلی CTE در تحلیل داده و مهندسی داده خودش رو نشون میده
چرا محدودیت در orm گفتیم؟؟
در orm ها موارد cte مطرح و پیاده سازی نشده چرا که دلیل اون این هستش که orm ها طراحی شدن بابت queryset های معمولی و نه بابت انجام کوئری‌های پیچیده، اینجاست که تو مثال بالا که مطرح کردیم اگه بخوایم از orm استفاده کنیم دچار محدودیت میشیم برای مثال اگه از prefetch استفاده کنیم محدود به انتخاب سطح میشیم بصورت دستی، اگه از زبان‌های برنامه نویسی بهره ببریم کارایی و کندی میاد سراغمون، به هر حال تصور درختی دیتابیسی که چندین میلیون رکورد داخلش هست کار راحتی نیستش، به اجبار باید سراغ CTEها بریم
واسه بچه‌هایی که با جنگو کار میکنند یکم تایم بزارید و django-cte و django-treebeard رو بخونید
کتابخونه‌های زیادی احتمالا پیدا بشه منتها این دوتا رو معرفی میکنم که بابت دو سناریوی مختلف مناسب هستند که خودتون بخونید راجبشون
#sql
#django
@code_crafters
بیایید با یک مثال براتون توضیح بدم، یک پیچیدگی نسبتا معمولی در دیتابیس و کوئری‌ها
یک مدل رو تصور کنید که دوتا فیلد داره
class Model:
id: int(PK)
name: str
parent: FK(self, null)
در نگاه اول این یک مدل کاملا ساده هستش و کاملا هم درست فکر میکنید این یه مدل ساده و ابتدایی هستش، اما منطق تجاری؟؟؟
منطق تجاری از ما میخواد که در ازای یک کوئری تمام والد‌های اون object رو بدست بیاریم، تصور کنید که ریشه‌های تو در تو داخل مدل برای یک object حدود 100 والد وجود داره و برای یک object دیگه ممکنه 1000 والد وجود داشته باشه، منطق تجاری از ما خواسته والد هر آبجکتی که درخواست میشه از مدل رو هم بهش برگردونیم، در دید اول این یک مسئله ساده هستش اما یک منطق تجاری نسبتا پیچیده هستش
خود CTEs ها در دیتابیس چیه؟
بطور خلاصه یک‌نمای جدولی موقتی هستش که فقط و فقط در طول اجرای همون کوئری وجود دارند. داخل زبان کوئری با استفاده از With همراه با join و on ما یک ساختار درختی رو متصور میشیم و داده مدنظر خودمون رو ازش میکشیم بیرون. جدول موقت اولین گام برای ورود به ادمین پایگاه داده شدن هستش شاید تعجب کنید از این حرف ولی حقیقت داره، در مثال ما یک منطق نسبتا پیچیده مطرح شد (از نوع CTE بازگشتی) کاربرد اصلی CTE در تحلیل داده و مهندسی داده خودش رو نشون میده
چرا محدودیت در orm گفتیم؟؟
در orm ها موارد cte مطرح و پیاده سازی نشده چرا که دلیل اون این هستش که orm ها طراحی شدن بابت queryset های معمولی و نه بابت انجام کوئری‌های پیچیده، اینجاست که تو مثال بالا که مطرح کردیم اگه بخوایم از orm استفاده کنیم دچار محدودیت میشیم برای مثال اگه از prefetch استفاده کنیم محدود به انتخاب سطح میشیم بصورت دستی، اگه از زبان‌های برنامه نویسی بهره ببریم کارایی و کندی میاد سراغمون، به هر حال تصور درختی دیتابیسی که چندین میلیون رکورد داخلش هست کار راحتی نیستش، به اجبار باید سراغ CTEها بریم
واسه بچه‌هایی که با جنگو کار میکنند یکم تایم بزارید و django-cte و django-treebeard رو بخونید
کتابخونه‌های زیادی احتمالا پیدا بشه منتها این دوتا رو معرفی میکنم که بابت دو سناریوی مختلف مناسب هستند که خودتون بخونید راجبشون
#sql
#django
@code_crafters
❤4👍1
یو یو, ipfs چیست؟(InterPlanetary File System)
تفاوت آدرس ها
امروزه وقتی یک دیتا رو ذخیره میکنیم یک URL منحصر به فرد داره که آدرس اون هست.
اما در ipfs آدرس دهی مبتنی بر content addtessing هست. به‌جای اشاره به مکان ذخیره‌سازی، داده‌ها با یک هش (Hash) منحصربه‌فرد که همیشه با Qm شروع میششن شناسایی میشن.
این روش باعث میشه که اگر محتوای فایل تغییر کنه، هش اونم تغییر کنه. در نتیجه، داده‌ها قابل تأیید هستن و نمی‌شه اونا رو دستکاری کرد بدون اینکه کسی متوجه بشه.
چطور کار میکنه؟
وقتی فایلی رو در IPFS آپلود میکنید، اون به بخش‌های کوچک تقسیم و بین نودها پخش میشه. هر بخش یه هش داره و کل فایل با یک هش اصلی شناسایی میشه. برای دسترسی، فقط کافیه هش رو وارد کنید،
چرا IPFS مهمه؟
غیرمتمرکز و ضدسانسور: هیچ نهاد مرکزی نمیتونه داده‌ها رو حذف یا محدود کنه.
سرعت و صرفه‌جویی: داده‌ها از نزدیک‌ترین نودها بارگذاری میشن(این موضوع و چگونگی کار کردنش یکم پیچیده به نظر میاد)
غیر متمرکز بودنش باعث میشه اگه یک نود آفلاین بشه، داده‌ها از نودهای دیگه بارگذاری بشن و درواقع هیچوقت این چرخه از بین نمیره
فارغ این از که ipfs تو شبکه‌های ویدئویی و استریم P2P یا میزبانی وبسایت ها یا بدیهی ترینش ذخیره داده کاربرد داره ,در DApps ههم خیلی کاربرد داره و با بلاکچین ادغام میشه(نقطه عطف🔥)
بلاکچین به تنهایی برای ذخیره‌سازی داده‌های بزرگ مثل تصاویر، ویدئوها یا اسناد مناسب نیست، چون هر نود در شبکه باید یک کپی از کل بلاکچین را نگه داره که این کار هزینه‌بر هستش و اون رو ناکارآمد میکنه. IPFS این مشکل راو به خوبی درک کرده و به راحتی میتونه این ضعف بلاکچین رو پوشش بده .،این ویژگی‌ها با اصول بلاکچین، یعنی امنیت، شفافیت و غیرمتمرکز بودن، هم جهت و هم راستا هست.
#ipfs
#web3
@code_crafters
یک پروتکل غیرمتمرکز برای ذخیره‌سازی و شتراک‌گذاری داده‌هاست که با استفاده از آدرس‌دهی مبتنی بر محتوا (Content Addressing) و به روش p2p ، اطالاعت رو بین نودهای مختلف توزیع میکنه. برخلاف سیستم‌های متمرکز که به سرورهای خاص وابستن IPFS امکان دسترسی سریع‌تر، امن‌تر و مقاوم‌تر به داده‌ها را فراهم میکنه دقیقا مثل چیزی که در ساختار بیت کوین وجود داره.همه چیزو خود مردم مدیریت میکنند بدون وابستگی به دولت ها یا یک قدرت متمرکز.
تفاوت آدرس ها
امروزه وقتی یک دیتا رو ذخیره میکنیم یک URL منحصر به فرد داره که آدرس اون هست.
"C:\Program Files\Epic Games
اما در ipfs آدرس دهی مبتنی بر content addtessing هست. به‌جای اشاره به مکان ذخیره‌سازی، داده‌ها با یک هش (Hash) منحصربه‌فرد که همیشه با Qm شروع میششن شناسایی میشن.
QmQ3hUpzcze4ASWwmo42M4ZG6ALYsqjY6wyw694vRbPtcV
این روش باعث میشه که اگر محتوای فایل تغییر کنه، هش اونم تغییر کنه. در نتیجه، داده‌ها قابل تأیید هستن و نمی‌شه اونا رو دستکاری کرد بدون اینکه کسی متوجه بشه.
چطور کار میکنه؟
وقتی فایلی رو در IPFS آپلود میکنید، اون به بخش‌های کوچک تقسیم و بین نودها پخش میشه. هر بخش یه هش داره و کل فایل با یک هش اصلی شناسایی میشه. برای دسترسی، فقط کافیه هش رو وارد کنید،
چرا IPFS مهمه؟
غیرمتمرکز و ضدسانسور: هیچ نهاد مرکزی نمیتونه داده‌ها رو حذف یا محدود کنه.
سرعت و صرفه‌جویی: داده‌ها از نزدیک‌ترین نودها بارگذاری میشن(این موضوع و چگونگی کار کردنش یکم پیچیده به نظر میاد)
غیر متمرکز بودنش باعث میشه اگه یک نود آفلاین بشه، داده‌ها از نودهای دیگه بارگذاری بشن و درواقع هیچوقت این چرخه از بین نمیره
فارغ این از که ipfs تو شبکه‌های ویدئویی و استریم P2P یا میزبانی وبسایت ها یا بدیهی ترینش ذخیره داده کاربرد داره ,در DApps ههم خیلی کاربرد داره و با بلاکچین ادغام میشه(نقطه عطف🔥)
بلاکچین به تنهایی برای ذخیره‌سازی داده‌های بزرگ مثل تصاویر، ویدئوها یا اسناد مناسب نیست، چون هر نود در شبکه باید یک کپی از کل بلاکچین را نگه داره که این کار هزینه‌بر هستش و اون رو ناکارآمد میکنه. IPFS این مشکل راو به خوبی درک کرده و به راحتی میتونه این ضعف بلاکچین رو پوشش بده .،این ویژگی‌ها با اصول بلاکچین، یعنی امنیت، شفافیت و غیرمتمرکز بودن، هم جهت و هم راستا هست.
#ipfs
#web3
@code_crafters
🔥5
CodeCrafters
یو یو, ipfs چیست؟(InterPlanetary File System) یک پروتکل غیرمتمرکز برای ذخیره‌سازی و شتراک‌گذاری داده‌هاست که با استفاده از آدرس‌دهی مبتنی بر محتوا (Content Addressing) و به روش p2p ، اطالاعت رو بین نودهای مختلف توزیع میکنه. برخلاف سیستم‌های متمرکز که به سرورهای…
قسمت دوم: نودها سودشون چیه و پروژه‌های کریپتو چرا عاشقش شدن؟
خب، تا اینجا فهمیدیم IPFS چطوری داده‌ها رو بین نودهای شبکه پخش میکنه و چطور آدرس‌دهی‌ش مبتنی بر محتوا (Content Addressing) هست، اما سوال اصلی اینه:
نودها چجوری سود میکنن؟
نودها (همون کامپیوترهایی که داده‌ها رو نگه می‌دارن و بین همدیگه رد و بدل میکنن) تو IPFS یه چیزی بیشتر از یک نقش ساده دارن:
ذخیره‌سازی و اشتراک‌گذاری داده‌ها: نودها فایل‌ها رو نگه می‌دارن و وقتی کسی درخواست داد، سریع اون فایل رو ارسال میکنن.
پاداش برای سرویس‌دهی: پروژه‌های مبتنی بر IPFS، مخصوصاً تو دنیای کریپتو و Web3، معمولاً برای نودهایی که بیشتر و بهتر خدمات میدن پاداش میدن. یعنی هر چقدر یک نود داده‌ها رو سریع‌تر و مطمئن‌تر تحویل بده، سود بیشتری می‌بره.
استفاده از توکن‌ها: شبکه‌های ذخیره‌سازی غیرمتمرکز مثل Filecoin که بر پایه IPFS ساخته شده، به نودها توکن Filecoin میدن به عنوان پاداش. این توکن‌ها میشه در بازارهای کریپتو معامله کرد و سود واقعی ازشون گرفت.
چرا پروژه‌های بزرگ کریپتو مثل Chainlink و غیره IPFS رو انتخاب کردن؟
Chainlink و ذخیره‌سازی داده‌های اوراکل: Chainlink که نقش اوراکل‌های امن رو بازی میکنه، نیاز داره داده‌ها رو جایی امن، سریع و غیرمتمرکز ذخیره کنه. IPFS این امکان رو بهش میده تا داده‌ها رو بدون وابستگی به یک سرور خاص، بین هزاران نود توزیع کنه و تضمین کنه که داده‌ها دستکاری نشدن.
غیرمتمرکز بودن و امنیت: پروژه‌هایی که امنیت و اعتماد بالا براشون مهمه، به IPFS تکیه میکنن چون امکان سانسور و از بین رفتن داده تقریبا صفر میشه.
مقیاس‌پذیری: IPFS به دلیل ساختار توزیع‌شده، مقیاس‌پذیری خیلی بهتری نسبت به سیستم‌های سنتی ذخیره‌سازی داره. برای پروژه‌های کریپتو که روز به روز بزرگ‌تر میشن، این موضوع حیاتی محسوب میشه.
پروژه‌های معروف دیگه که IPFS دارن استفاده میکنن:
ایک-Filecoin: شبکه ذخیره‌سازی غیرمتمرکز که با IPFS کاملا یکپارچه شده و توکن مخصوص به خودش رو داره.
دو-اArweave: پروتکلی برای ذخیره دائمی داده‌ها، که IPFS هم بهش کمک میکنه.
سه=Unstoppable Domains: استفاده از IPFS برای ساخت دامنه‌های وب غیرقابل سانسور.
چهار-Audius: پلتفرم موزیک غیرمتمرکز که IPFS رو برای نگهداری موزیک‌ها و داده‌ها استفاده میکنه.
#ipfs
#web3
@code_crafters
خب، تا اینجا فهمیدیم IPFS چطوری داده‌ها رو بین نودهای شبکه پخش میکنه و چطور آدرس‌دهی‌ش مبتنی بر محتوا (Content Addressing) هست، اما سوال اصلی اینه:
نودها چجوری سود میکنن؟
نودها (همون کامپیوترهایی که داده‌ها رو نگه می‌دارن و بین همدیگه رد و بدل میکنن) تو IPFS یه چیزی بیشتر از یک نقش ساده دارن:
ذخیره‌سازی و اشتراک‌گذاری داده‌ها: نودها فایل‌ها رو نگه می‌دارن و وقتی کسی درخواست داد، سریع اون فایل رو ارسال میکنن.
پاداش برای سرویس‌دهی: پروژه‌های مبتنی بر IPFS، مخصوصاً تو دنیای کریپتو و Web3، معمولاً برای نودهایی که بیشتر و بهتر خدمات میدن پاداش میدن. یعنی هر چقدر یک نود داده‌ها رو سریع‌تر و مطمئن‌تر تحویل بده، سود بیشتری می‌بره.
استفاده از توکن‌ها: شبکه‌های ذخیره‌سازی غیرمتمرکز مثل Filecoin که بر پایه IPFS ساخته شده، به نودها توکن Filecoin میدن به عنوان پاداش. این توکن‌ها میشه در بازارهای کریپتو معامله کرد و سود واقعی ازشون گرفت.
چرا پروژه‌های بزرگ کریپتو مثل Chainlink و غیره IPFS رو انتخاب کردن؟
Chainlink و ذخیره‌سازی داده‌های اوراکل: Chainlink که نقش اوراکل‌های امن رو بازی میکنه، نیاز داره داده‌ها رو جایی امن، سریع و غیرمتمرکز ذخیره کنه. IPFS این امکان رو بهش میده تا داده‌ها رو بدون وابستگی به یک سرور خاص، بین هزاران نود توزیع کنه و تضمین کنه که داده‌ها دستکاری نشدن.
غیرمتمرکز بودن و امنیت: پروژه‌هایی که امنیت و اعتماد بالا براشون مهمه، به IPFS تکیه میکنن چون امکان سانسور و از بین رفتن داده تقریبا صفر میشه.
مقیاس‌پذیری: IPFS به دلیل ساختار توزیع‌شده، مقیاس‌پذیری خیلی بهتری نسبت به سیستم‌های سنتی ذخیره‌سازی داره. برای پروژه‌های کریپتو که روز به روز بزرگ‌تر میشن، این موضوع حیاتی محسوب میشه.
پروژه‌های معروف دیگه که IPFS دارن استفاده میکنن:
ایک-Filecoin: شبکه ذخیره‌سازی غیرمتمرکز که با IPFS کاملا یکپارچه شده و توکن مخصوص به خودش رو داره.
دو-اArweave: پروتکلی برای ذخیره دائمی داده‌ها، که IPFS هم بهش کمک میکنه.
سه=Unstoppable Domains: استفاده از IPFS برای ساخت دامنه‌های وب غیرقابل سانسور.
چهار-Audius: پلتفرم موزیک غیرمتمرکز که IPFS رو برای نگهداری موزیک‌ها و داده‌ها استفاده میکنه.
#ipfs
#web3
@code_crafters
🔥7