Installing❌ in Stalin ✅

🚫عجیب اما واقعی...

با افتخار اعلام میکنیم که در طرح "اول آورد 2" توانستیم 100 میلیون تومان اعتبار حمایتی از Avalai.ir عزیز کسب کنیم.
این طرح برای کسب و کارهای بزرگ است که اولین کسب و کار اسنپ فود بود که در این طرح قرار گرفت، اما با حمایت و لطف تیم خوب avalai ، رفهاب هم شامل این طرح شد، این برای ما تجربه ی شگفت آور و با ارزشی ست که گام بزرگی برای رشد Refhub.ir خواهد بود.

𝗧𝗼𝗽 𝟲 𝗚𝗮𝗺𝗲 𝗖𝗵𝗮𝗻𝗴𝗶𝗻𝗴 𝗞𝘂𝗯𝗲𝗿𝗻𝗲𝘁𝗲𝘀 𝗗𝗲𝗽𝗹𝗼𝘆𝗺𝗲𝗻𝘁 𝗦𝘁𝗿𝗮𝘁𝗲𝗴𝗶𝗲𝘀 🚀

𝟭. 𝗥𝗲𝗰𝗿𝗲𝗮𝘁𝗲:
All existing instances are terminated at once, and new instances with the updated version are created

𝘋𝘰𝘸𝘯𝘵𝘪𝘮𝘦: Yes
𝘜𝘴𝘦 𝘤𝘢𝘴𝘦: Non-critical applications or during initial development stages

𝟮. 𝗥𝗼𝗹𝗹𝗶𝗻𝗴 𝗨𝗽𝗱𝗮𝘁𝗲:
Application instances are updated one by one, ensuring high availability during the process

𝘋𝘰𝘸𝘯𝘵𝘪𝘮𝘦: No
𝘜𝘴𝘦 𝘤𝘢𝘴𝘦: Periodic releases

𝟯. 𝗦𝗵𝗮𝗱𝗼𝘄:
A copy of the live traffic is redirected to the new version for testing without affecting production users

This is the most complex deployment strategy and involves establishing mock services to interact with the new version of the deployment

𝘋𝘰𝘸𝘯𝘵𝘪𝘮𝘦: No
𝘜𝘴𝘦 𝘤𝘢𝘴𝘦: Validating new version performance and behavior in a real environment

𝟰. 𝗖𝗮𝗻𝗮𝗿𝘆:
The new version is released to a subset of users or servers for testing before broader deployment

𝘋𝘰𝘸𝘯𝘵𝘪𝘮𝘦: No
𝘜𝘴𝘦 𝘤𝘢𝘴𝘦: Impact validation on a subset of users

𝟱. 𝗕𝗹𝘂𝗲-𝗚𝗿𝗲𝗲𝗻:
- Two identical environments are maintained: one with the current version (blue) and the other with the updated version (green)
- Traffic starts with blue, then switches to the prepared green environment for the updated version

𝘋𝘰𝘸𝘯𝘵𝘪𝘮𝘦: No
𝘜𝘴𝘦 𝘤𝘢𝘴𝘦: High-stake updates

𝟲. 𝗔/𝗕 𝗧𝗲𝘀𝘁𝗶𝗻𝗴:
Multiple versions are concurrently tested on different users to compare performance or user experience

𝘋𝘰𝘸𝘯𝘵𝘪𝘮𝘦: Not directly applicable
𝘜𝘴𝘦 𝘤𝘢𝘴𝘦: Optimizing user experience

وقتی این پست رو داخل یکی از گروه های زیرساخت و شبکه ارسال کردم ، یکی از اعضای گروه نظر جالبی داشت که همینجا هم ارسالش میکنم تا شما هم بتونید مطالعه کنید .
در واقع این پست رو استارت گفتن موضوعی کرد که تامل برانگیز بود برای من ، به نوبه ی خودش نظری داد که درستی و یا غلط بودن اون نیاز به تجربه و درک عمیقی از این حوزه داره .
اما آیا راستی آزمایی اینچنین اظهار نظرات کار راحتی هست؟ آیا یک استاندارد واحد یا یک مدل ثابت یا به نقل از اساتید حوزه ی فیزیک ، "یک نظریه ی همه چیز" برای مباحث زیرساخت و دواپس وجود دارد؟
طرز بیان و دیدگاه ایشان گواه از ید طولا و دست و پنجه نرم کردن در این فیلد دارد ، شماهم وقت کردید مطالعه بفرمایید ، نظری یا نقدی و یا حتی تصدیقی داشتید بفرمایید .
مشارکت در فروم های فنی خیلی راه ساز و چاره ساز خواهد بود .

دقیقا به همین دلیل داکر و تکنولوژی های میکرو سرویس رو یا مبتدی ها استفاده میکنن، یا کمپانی های خیلی بزرگ که روی پروژه های خیلی بزرگ کار میکنن چون نمیتونن به تعداد کل نیروهاشون آدم متخصص خبره استخدام کنن و مجبورن آدم های معمولی استخدام کنن مجبور میشن از این تکنولوژی ها استفاده کنن!

به طور کلی تکنولوژی ها میکروسرویس فقط به درد کمپانی های های تچ میخوره و سودش اینه که تیم های مختلف میتونن روش همزمان کار کنن و اختلالی روی هم ایجاد نکنن و اصلا بدرد شرکت های کوچیک متوسط و بزرگ نمیخوره سربار پردازشی و شبکه و مانیتورینگ و مدیریت میکرو سرویس ها فقط روی سرویس هایی که بیشتر از صد هزار ریکوست کانکارنت در لحظه دارن و تیمشون بیشتر از چند هزار نفر هست میتونه توجیح داشته باشه! وگرنه هزینه و پیچیدگی هاش بیشتر از منافعش هست

ارتباط بین میکرو سرویس ها سربار شبکه ایجاد میکنه
که همزمان باعث سربار پردازشی و مصرف منابع پردازشی میشه
همچنین باعث بوجود اومدن لتنسی میشه
تکرار داده ها و کشینگ های داخلی سربار پردازشی ایجاد میکنه
ساگا پترن ها سربار پردازشی دارن
اجرای جداگونه کانتینر ها منابع بیشتر مصرف میکنه تا یه سیستم مونولیتی
هرسرویس منابع مجزا نیاز داره و از همه مهم تر پورت جداگونه نیاز داره که استک داخلی کرنل رو فلود میکنه
امکانات مدیریت کانتینرها سربار پردازشی و شبکه ایجاد میکنه
عیب یابی زمانی که سرویس ها متعدد باشن به صورت منوال به شدت سخته و باید از زیپکین یا جی گر استفاده کنن که باز سربار پردازشی و شبکه ایجاد میکنه
مانیتورینگ و لاگ گزاری پیشرفته تری نیاز هست که باز سربار پردازشی و شبکه اضافی ایجاد میکنه

برنامه نویس های مبتدی معمولا درکی از شبکه و سخت افزارو نحوه اجرای کد ندارن یا اگر هم دارن خیلی سطحی هست ! برنامه نویس های حرفه ای معمولا هر ریکوست شبکه هر سویچ کانتکس روی سی پی رو حساب میکنن زمانی که دارن یه پروژه ای رو طراحی میکنن تا بتونن حداکثر توان پردازشی و شبکه رو از سخت افزار بگیرن و هزینه و منابع استفاده شده رو در سطح مناسب نگه دارن مثلا به زبون ساده بگم روی یه معماری درست مونولیتی که محاسبات فنی دقیق داشته باشه شما میتونید روی یه سرور با چهار هسته سی پی یو و دو گیگ رم تا حدود 500 هزار ریکوست همزمان رو ریسپانس بدین بدون لتنسی ! ولی وقتی از میکرو سرویس ها استفاده کنید و تمامی موارد بهینه سازی رو در نظر بگیرید حداکثر میتونید روی همون ماشین تا 1500 ریکوست همزمان رو پاسخ بدید و عملا منابع سیستم رو کامل مصرف کردید!

به طور مثال وقتی از پورت مپینگ استفاده میکنین اون پشت چه اتفاقی میوفته ؟ :
داکر مجبور میشه از NAT برای ترجمه آدرس ها و پورتهای بین شبکه هاست و کانتینر استفاده کنه که باعث سربار اضافی روی سی پی یو میشه
این باعث بوجود اومدن لتنسی میشه چون بسته ها باید از لایه نت عبور کنن
درخواست ها اول به پورت هاست میرسن و بعد به پورت کانتینر فوروارد میشن که این باعث فلود استک شبکه در سطح کرنل میشه و همچنین مسیر طولانی تری به نسبت ارتباط مستقیم هست
هر بسته داده از طریق بریدج شبکه داخلی داکر باید عبور کنه که باز سربار پردازشی اضافی وفلود استک شبکه میشه که باعث بروز لتنسی میشه
وقتی از پورت مپینگ استفاده کنین باز مجبورین از رول های iptables استفاده کنید که باز هم سربار پردازشی اضافی ایجاد میشه

برای درک موضوع :

هر کور سی پی یو در اصل یه حلقه است که با سرعت ثابت ( فرکانس سی پی یو ) داره اجرا میشه و هی کد های نرم افزار رو اجرا میکنه
وقتی شما مثلا 4 تا کور سی پی یو دارین یعنی در اصل چهار تا حلقه برای اجرای کد های نرم افزار دارین
حالا وقتی از ترد استفاده میکنید یا تعداد پروسس ها بیشتر از تعداد کور های سی پی یو هست تسک اسکجولر با استفاده از کانتکس سویچینگ بین اینها هی سویچ میکنه که بتونه همه رو همزمان اجرا کنه ! که خب این سویچ کردن خودش یک زمانی رو مصرف میکنه ! و بقیه باید توی صف منتظر بمونن تا سویچ روشون اتفاق بوفته!
اینکه میگیم سربار پردازشی یعنی این کار اضافه میره توی صف پردازش و تسک های قابل اجرا برای سی پی یو هی اضافه میشه ! و اینجوریه که سی پی یو مصرف میشه و شما توی مانیتورینگ میبینید مصرف سی پیو بالا رفته ! و اون لتنسی که اتفاق میوفته اینه یعنی تسک ها باید منتظر اجرا بمونن ! البته خیلی پیچیده تره و من سعی کردم به زبان ساده و مختصر توضیح بدم!

"We are like books"

اگر سایتی دارید که محتوای پارسی یا عربی داخلش قرارداره ، اما به صورت چپ به راست نمایش داده میشه ،
مثل همین ایرادی که من توی این پکیج Onlyoffice داشتم ، و براتون آزاردهنده هست ، میتونید از افزونه مناسبی استفاده کنید که براتون تمام محتویات رو به صورت راست به چپ بچینه .

محدودیت هایی داره ، مثلا گاهی ممکنه با ChatGPT مکاتبات پارسی داشته باشید ، خب همه چیز نرمال به نظر میرسه تا وقتی که ChatGPT تصمیم میگیره که اولین کلمه ی جمله رو با یک کلمه ی انگلیسی شروع کنه ، اون موقع هست که کارو خراب میکنه و همه ی جملات اون بخش رو به صورت چپ به راست نمایش میده .
این اکسنتشن اینجا اصلا بدرد بخور نیست ، و دردی رو دوا نمیکنه .

اما درکل بودنش خوبه ، مثل وقتایی که یک سایت خارجی زبان رو مطالعه میکنید ، و تصمیم عجیب غریبی میگیرد که تمام متن های سایت رو با کمک گوگل به پارسی ترجمه کنید ، اینجا با کمک این افزونه ، میتونید همه چیز رو راست به چپ کنید و از خواندن متون پارسی لذت ببرید.
آدرس نصب افزونه :
https://chromewebstore.google.com/detail/rtl-all/eilpimgcclncpehhmnnplnfokcmdiefa

RTL = Right To Left
LTR = Left To Right

Busy week