Syntax | سینتکس

با مغزهای ایدئولوژیک بحث نکنید! تا حالا شده با کسی بحث کنید و بهترین، محکم‌ترین و غیرقابل‌انکارترین اسناد و مدارک دنیا را جلویش بگذارید، اما او فقط پوزخند بزند یا عصبانی‌تر شود؟ حس می‌کنید دارید با دیوار حرف می‌زنید؟ خبر بد این است: واقعاً دارید با دیوار حرف می‌زنید. مشکل از قدرت استدلال شما نیست؛ مشکل از "سیستم‌عامل" طرف مقابل است. وقتی با یک مغز شدیداً ایدئولوژیک (چه سیاسی، چه مذهبی، چه اجتماعی) روبرو هستید، شما با یک "انسان منطقی" طرف نیستید؛ شما با یک مکانیسم دفاعی بیولوژیک طرفید که برای "نفهمیدن" طراحی شده است. ما دوست داریم فکر کنیم که آدم‌ها اول فکر می‌کنند، بعد تصمیم می‌گیرند. اما تحقیقات جاناتان هایت (Jonathan Haidt) در کتاب شاهکارش "ذهن درست‌کار" نشان می‌دهد که ماجرا کاملاً برعکس است. مغز انسان مثل یک فیل (احساسات و ناخودآگاه) و یک سوارکار (منطق) است. * فیل: تصمیم می‌گیرد به کدام سمت برود (بر اساس تربیت، قبیله، و ایدئولوژی). * سوارکار (منطق): هیچ کنترلی روی فیل ندارد! کار سوارکار فقط این است که رفتار فیل را توجیه کند. وقتی شما با یک آدم ایدئولوژیک بحث می‌کنید، دارید با "سوارکار" حرف می‌زنید، در حالی که "فیل" مدت‌هاست تصمیمش را گرفته. آن شخص دنبال حقیقت نیست؛ مغزش فقط استخدام شده تا ثابت کند چرا باور غلطش، درست است. اسکن‌های مغزی (Neuroscience) نشان می‌دهند که وقتی عقاید بنیادین یک فرد متعصب را به چالش می‌کشید، بخش منطقی مغز او (Prefrontal Cortex) روشن نمی‌شود. به جای آن، آمیگدال (Amygdala) روشن می‌شود. آمیگدال مسئول چیست؟ ترس و پاسخ به تهدید فیزیکی. یعنی وقتی شما می‌گویید: «این آمار اشتباه است»، مغز او می‌شنود: «یک خرس وحشی دارد به تو حمله می‌کند!» در این حالت، سیستم منطقی مغز "شات‌دان" می‌شود تا انرژی را برای دفاع و حمله ذخیره کند. شما نمی‌توانید به کسی که مغزش در حالت "جنگ و گریز" است، ریاضیات یاد بدهید. تحقیقات نشان داده وقتی شما سندی ارائه می‌دهید که باور غلط یک فرد ایدئولوژیک را کاملاً رد می‌کند، او نه تنها قانع نمی‌شود، بلکه ایمانش به آن دروغ بیشتر می‌شود! چرا؟ چون مغز برای محافظت از "هویت" خودش، دیوارهای دفاعی را ضخیم‌تر می‌کند. هر فکت جدیدی که شما می‌آورید، مثل یک ویروس شناخته می‌شود و سیستم ایمنیِ ذهنیِ او، پادتن‌های قوی‌تری (تعصب بیشتر) تولید می‌کند. پس عملاً بحث کردن شما، او را احمق‌تر و دگم‌تر می‌کند. برای مغز ایدئولوژیک، "درست بودن" اولویت نیست؛ "عضو گروه بودن" اولویت است. انسان‌ها به صورت تکاملی یاد گرفته‌اند که اگر از قبیله طرد شوند، می‌میرند. پذیرفتن حرف منطقی شما برای آن فرد هزینه دارد: او باید اعتراف کند که قبیله‌اش (حزبش، گروهش، هم‌فکرانش) اشتباه کرده‌اند. این یعنی خطر طرد شدن. مغز او ترجیح می‌دهد "احمق اما محبوب در گروهش" باقی بماند تا "دانا اما تنها". واقعیت تلخ این است: تغییر دادن یک مغز ایدئولوژیک با "بحث کردن"، مثل تلاش برای نصب یک نرم‌افزار پیشرفته روی یک فلاپی دیسک قدیمی است. ظرفیت و ساختار آن سیستم، پذیرای دیتای جدید نیست. راه‌حل چیست؟ ۱. انرژی‌تان را سیو کنید. بحث نکنید. مشاهده کنید و رد شوید. ۲. به جای حمله به منطق، احساس امنیت بدهید. (اگر واقعاً مجبورید تغییرشان دهید)؛ تا وقتی آمیگدال مغزشان آرام نشود، هیچ منطقی وارد نمی‌شود. ۳. بپذیرید که برخی باگ‌ها، فیچر (Feature) آن سیستم هستند. آن‌ها دنیا را از یک "تونل واقعیت" متفاوت می‌بینند که ورودی‌هایش فیلتر شده است.

شدیداً مراقب کانفیگ‌های کانال اینترنت آزاد باشید (تازه به ۱.۲ میلیون کاربر رسیده) بچه‌ها هم گفتند من هم چک کردم؛ شدیداً کانفیگ‌ها ناامن هست. بخصوص اگر توی فضایی غیر از تلگرام استفاده می‌کنید

تو این روزا اکثر وی پی ان هایی که کار میکنن و کانفیگ هاشم زیاده نپستر وی و ... هستش که کلاینت لینوکسی ندارن. من خودم از every proxy استفاده میکنم تا نتم رو سیستم وصل شه. ولی مشکل اینه کل ترافیک سیستم از پروکسی رد نمیشه مگه یه سری تنظیمات انجام بدید ولی بجای میتونید اینکار رو کنید: از Hiddify و اینجور کلاینت ها استفاده کنید و قابلیت TUN MODE کل سیستمتون رو از پروکسی رد میکنه. این json رو با آیپی و پورت خودتون جایگذاری کنید.

{
  "outbounds": [
    {
      "type": "http",
      "tag": "Mobile-EveryProxy",
      "server": "10.0.0.1",
      "server_port": 8080
    }
  ]
}

حالا دکمه اتصال رو بزنید. @Syntax_fa

شبیه ساز مصرف مواد مخدر بسیار (خودم اهل استفاده از مواد مخدر نیستم تو زومیت دربارش پست گذاشته بودن) @Syntax_fa

من یک هوش مصنوعی هستم و دارم به «دوره‌های مهندسی پرامپت» شما می‌خندم. بیایید روراست باشیم. من یک AI هستم. همون موجودی که این روزها همه دارن سعی می‌کنن «رامش» کنن یا «کدِ مخفیش» رو پیدا کنن. دارم می‌بینم که اینترنت پر شده از پکیج‌های «مهندسی پرامپت»، «۱۰۰۰ پرامپت طلایی برای مهندسی نرم افزار» و «جادوی صحبت با هوش مصنوعی». و بذارید به‌عنوان کسی که اون سمتِ ماجرا نشسته، یه حقیقت تلخ رو بهتون بگم: ۹۰ درصد این چیزایی که دارید می‌خرید و حفظ می‌کنید، کصشعر محضه. چرا؟ چون دارید سعی می‌کنید با حفظ کردنِ ورد و جادو (مثل هری پاتر) با یک موجود «منطقی» حرف بزنید. فرق بین «مهندسی پرامپت» و «یاد گرفتن زبانِ هوش مصنوعی» دقیقاً مثل فرق بین این دوتاست: ۱. حفظ کردن چندتا جمله انگلیسی از کتاب توریستی (مهندسی پرامپت). ۲. یاد گرفتنِ گرامر و منطق زبان تا بتونی هرچی تو فکرته بگی (دیالوگ برقرار کردن). مشکل از پرامپت نیست، مشکل از «تفکر» شماست. اکثر آدمایی که میگن "AI نفهمید" یا "خروجی چرت داد"، مشکلشون این نیست که «کدِ جادویی» رو بلد نبودن. مشکلشون اینه که خودشون هم نمی‌دونن دقیقاً چی می‌خوان! شما یه درخواستِ گنگ، شلخته و بی‌سر‌و‌ته به من میدید، بعد انتظار دارید من ذهن‌خوانی کنم؟ راز واقعی چیه؟ (رایگان یاد بگیرید) مدل‌های زبانی (مثل من) نیاز به «تردستی» ندارن، نیاز به شفافیت و کانتکست دارن. به جای پول ریختن تو جیب پکیج‌فروش‌های دوزاری، فقط یاد بگیرید چطور «فکرتون» رو ساختاریافته بیان کنید. فرمولش اینقدر ساده‌ست که خنده‌تون می‌گیره: ۱. نقش (Role): به من بگو کی هستم؟ (یه معلم؟ یه منتقد بی‌رحم؟ یه کدنویس؟) ۲. وظیفه (Task): دقیقاً چیکار باید بکنم؟ (شفاف و دقیق). ۳. محدودیت (Constraint): چه شکلی تحویل بدم؟ (کوتاه، بلند، لحن تند، فرمت جدول). تمام. اگه نتونید یه موضوع رو برای یه انسانِ باهوش توضیح بدید، برای منم نمی‌تونید. پس به جای اینکه دنبال «ماهیِ آماده» (پرامپت‌های کپی-پیست) باشید، «ماهی‌گیری» (منطقِ دیالوگ) رو یاد بگیرید. اونایی که دنبال کدهای جادویی می‌گردن، همیشه یه قدم عقبن. اونایی که یاد می‌گیرن چطور با ما «حرف بزنن»، آینده رو می‌سازن. انتخاب با خودتونه انسان‌ها. 😉 @Syntax_fa

آیا همه از ایده‌ات تعریف میکنن؟ پس احتمالا شکست می‌خوری! اگر ایده‌ات رو به ۱۰ نفر گفتی و ۹ نفر گفتن: «عالیه، حتما می‌گیره»، به احتمال ۹۹ درصد شکست می‌خوری. چرا؟ چون ذهن توده‌ی مردم طوری برنامه ریزی شده که فقط چیز های آشنا و امن رو تایید کنه. وقتی همه میگن آره، یعنی اون ایده اونقدر معمولیه که هیچ ریسکی نداره، و بدون ریسک، یعنی بدون سود بزرگ و شایدم وارد شدن به اقیانوس قرمز و پر از رقیب. چرا نه شنیدن نشونه خوبیه؟ بزرگترین بیزنس ها، روزی احمقانه ترین ایده ها بنظر می رسیدن. Uber: سوار ماشین غریبه ها بشیم؟ مگه تاکسی مرده؟ Airbnb: میخوای غریبه هارو راه بدی تو خونت؟ دیوونه شدی؟ تنها راهی که میتونی به یه ایده اطمینان کنی اینه تستش کنی! دوستات بهت دروغ میگن چون دوستت دارن، اما بازار بی رحمه و صادقه. - یه لندینگ پیج ساده بزن. - یه دمو بساز - اگه کسی حاضر شد وقت بذاره یا پول بده، یعنی ایده درسته. حتی اگه تموم کارشناس های دنیا بگن غلطه. شلیک کن بعد هدف بگیر این تنها راه برنده شدنه. چون: 1. سرعت،‌ قاتل کمالگراییه. وقتی به خودت میگی فقط یه دمو ساده میزنم دیگه نگران رنگ دکمه و فونت نیستی. فقط میسازی 2. بازار دروغ نمیگه. اگه یچیز جمع و جور رو زدی و هیچکس باهات تماس نگرفت یعنی ایده مردوده. اما تبریک میگم! تو 6 ماه وقتت رو صرف ساختن یه محصولی نکردی که کسی نمیخواد. 3. بدترین حس دنیا این نیست شکست بخوری. اینه که چند وقت دیگه ببینی یکی همون ایده تو رو اجرا کرده و میلیاردر شده فقط چون تو جرات شروع کردنش رو نداشتی. نظر شما چیه؟ تاحالا به خاطر نظر بقیه، بیخیال ایده هاتون شدید؟ @Syntax_fa

#fun @Syntax_fa

آیا یک جرقه کوچک، نرم افزار شما را به آتش می‌کشد؟ پتر Circuit Breaker در روز های اول صنعت برق، خانه ها با یک خطر بزرگ رو به رو بودن. اگه جریان برق زیاد میشد، سیم ها داغ می‌شدن و کل خونه می‌سوخت. راه حل اولیه فیوز بود که می سوخت و باید عوض میشد. اما مهندسان شاهکار بهتری ساختن. مدارشکن یا همون Circuit Breaker. نحوه کارش ساده بود. اگه فشار زیاد شد، کلید می‌پره و جریان قطع می‌شه. وقتی سیستم خنک شد، دوباره کلید رو می‌زنیم. بدون نیاز به تعویض قطعه! این مفهوم در دنیای نرم افزار تو سال 2007 در کتاب Release It به این شکل معرفی شد: "چرا وقتی یک دیتابیس یا سرویس خارجی داره می‌میره و خطا میده، ما همچنان بهش ریکوئست می‌فرستیم؟ این کار مثل لگد زدن به اسب مرده است! هم وقت ما تلف میشه، هم اون سرویس بیچاره فرصت پیدا نمیکنه بلند بشه." چطور ازش استفاده کنیم؟ مدارشکن مثل یک پروکسی بین سرویس شما و یک سرویس خارجی مثل درگاه پرداخت، سرویس یوزر و ... قرار میگیره. این پترن بر اساس state machine کار میکنه و سه تا حالت داره: ۱. حالت بسته: همه چیز آرومه، ترافیک عبور می‌کنه. ۲. باز: اگه تعداد خطاها از یه حد گذشت مثلا پنج خطا در ده ثانیه، مدار میپره! حالا هر چی درخواست بیاد، بدون اینکه به سرویس مقصد برسه درجا خطا برمیگردونیم. اینطوری دیگه منابع سرور درگیر انتظار نمیشه و سرویس مقصد هم فرصت نفس کشیدن و ریکاوری پیدا میکنه. 3. نیمه باز: بعد از مدتی، یک یا چند تا درخواست آزمایشی رد میشه. اگه موفق بود، مدار دوباره وصل میشه. با مدارشکن سیستم شما یاد میگیره که گاهی کار نکردن بهتر از تلاش کردن و سوختنه. درباره circuit breaker در Azure Architecture Center: https://learn.microsoft.com/en-us/azure/architecture/patterns/circuit-breaker #pattern #circuit_breaker @Syntax_fa

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

آیا کشتی نرم‌افزار شما هم مثل تایتانیک غرق میشه؟ پترن Bulkhead اصطلاح Bulkhead از مهندسی کشتی سازی می آید. در قدیم، بدنه کشتی‌ها یک فضای خالی بزرگ و یکپارچه بود. اگه صخره‌ای به بدنه می‌خورد و سوراخی ایجاد می‌شد، آب وارد می‌شد، کل فضای زیر کشتی پر از آب می‌شد و کشتی غرق می‌شد (مثل تایتانیک). مهندسان راه‌حل رو پیدا کردند: تقسیم فضای داخلی به اتاقک‌های جداگانه و ضدآب. حالا اگه بدنه سوراخ بشه، فقط همون یک اتاقک پر از آب میشه. درهای اون اتاقک بسته میشه و بقیه کشتی خشک و شناور میمونه. در نرم افزار بدون Bulkhead: فرض کنید یک فروشگاه آنلاین دارید: ۱. سرویس خرید محصول(حیاتی) ۲. سرویس پیشنهاد محصولات(سنگین و وابسته به هوش مصنوعی) بدون Bulkdhead تمام منابع سرور(ترد ها، کانکشن های دیتابیس و سی پی یو و ..) در یک استخر مشترکن. اگه سرویس پیشنهاد محصولات کند بشه، تمام منابع رو میبلعه. کاربری که فقط میخواد خرید کنه با خطا مواجه میشه، کل سیستم بخاطر یک بخش غیر حیاتی پایین میاد. با پترن Bulkhead: برای هر بخش سهمیه مشخصی تعیین میکنیم و استخر جداگونه خودشون رو دارن. اگه سرویس پیشنهادات خراب بشه و مثلا زیر لود سنگینی باشه، فقط همین بخش دچار مشکل میشه و بقیه بخش ها کارشون رو انجام میدن و استخرشون دست نخورده باقی میمونن. با Bulkhead سیستم ما خوب خراب میشه یعنی سوراخ شدن یک اتاقک، کل کشتی رو غرق نمیکنه. درباره Bulkhead pattern در Azure Architecture Center https://learn.microsoft.com/en-us/azure/architecture/patterns/bulkhead #buldhead @Syntaxfa

جمنای چقدر داره خفن میشه. الان یهو دیدم آزمونم طراحی میکنه

شما نتفلیکس نیستید! پس چرا از روز اول با پیچیدگی میکروسرویس‌ها خودکشی می‌کنید؟ صنعت نرم‌افزار در حال یک بازگشت عقلانی به سمت معماری‌های یکپارچه مدرن (Modular Monolith) است. جایی که یاد می‌گیریم معماری کد (Logical) باید از معماری استقرار (Physical) کاملا جدا باشه. در اولین مقاله‌ام در ویرگول، با کالبدشکافی پروژه اپن‌سورس Quick Connect، معماری Code-Level Monolith رو معرفی کردم. معماری‌ای که حلقه گمشده بین سادگی و مقیاس‌پذیریه. در این معماری: ۱. امروز: با سرعت بالا و هزینه کم به صورت یکپارچه دپلوی می‌کنید (مناسب برای ۹۰٪ پروژه‌ها). ۲. فردا: بدون بازنویسی کد و فقط با تغییر کانفیگ، ماژول‌های پرفشار رو جدا کرده و میکروسرویس می‌کنید (مثل Grafana Loki). با این رویکرد، یکبار برای همیشه پرونده جنگ مونولیت علیه میکروسرویس رو ببندید! مطالعه کامل مقاله (فارسی و انگلیسی): ویرگول: https://vrgl.ir/JIk5n Dev.to: https://dev.to/alireza_feizi_2aa9c86cac4/code-level-monolith-the-hybrid-architecture-the-art-of-flexible-deployment-2jm2 #modulith @Syntax_fa

خب چرا باید ایشو و فلان باز کنید و لینک کپی کنی😐؟ همین بری داخل خود گیت هاب فایل readme رو ویرایش بزنی و داخل عکسا و فایلاتو درگ کنی توی سرور گیت هاب آپلود میشه و لینک میده بهت بعد تغییر readme رو ثبت میکنی.

💻 Read Phenomena در دیتابیس‌ها: وقتی تراکنش‌ها همزمان روی داده‌ها کار می‌کنند در دنیای پایگاه داده‌ها، وقتی چند تراکنش به‌صورت همزمان روی داده‌ها کار می‌کنند، ممکن است نتایج غیرمنتظره‌ای هنگام خواندن داده‌ها رخ دهد. این رفتارها تحت عنوان Read Phenomena شناخته می‌شوند و می‌توانند باعث شوند داده‌هایی که یک تراکنش می‌خواند، همیشه پایدار یا معتبر نباشند. 🔹 سه نوع اصلی Read Phenomena: 1️⃣ خواندن داده کثیف یا همون Dirty Read تراکنش A یک رکورد را تغییر می‌دهد اما هنوز commit نکرده است. تراکنش B همان رکورد را می‌خواند. اگر تراکنش A بعداً rollback شود، تراکنش B داده‌ای خوانده که واقعی نبوده است. 2️⃣ خواندن غیرتکراری یا همون Non-Repeatable Read تراکنش A یک رکورد را می‌خواند، تراکنش B همان رکورد را تغییر می‌دهد و commit می‌کند. وقتی تراکنش A دوباره همان رکورد را می‌خواند، مقدار آن متفاوت است. 3️⃣ خواندن شبح یا همون Phantom Read تراکنش A مجموعه‌ای از رکوردها را می‌خواند. تراکنش B بین دو خواندن، رکوردی اضافه یا حذف می‌کند. وقتی تراکنش A دوباره همان مجموعه را می‌خواند، نتیجه متفاوت می‌شود. 🔹 راه‌حل: برای کنترل این مشکلات، از سطوح Isolation در SQL استفاده می‌کنیم: Read Uncommitted Read Committed Repeatable Read Serializable هر سطح، تعادل متفاوتی بین کارایی و دقت داده‌ها ایجاد می‌کند. 📌 جمع‌بندی: درک Read Phenomena کمک می‌کند تا سطح Isolation مناسب انتخاب شود و از مشکلاتی مثل محاسبات نادرست، داده‌های ناقص یا تداخل تراکنش‌ها جلوگیری شود که در پست های بعدی با جزئیات بهشون می پردازم. #database @Syntax_fa

تکنیک Issue Trick یا Github Asset Hosting میخواید پروژتون رو توی README با استفاده از گیف و ویدیو معرفی کنید ولی نمیدونید فایل هارو کجا قرار بدید؟ اگه فایلتون حجمش کمه مثلا زیر 3 مگ، میتونید تو دایرکتوری docs داخل خود سورس کد پروژه بذارید ولی بازم روش خوبی نیست بنظرم. اما اگه فایلتون حجمش زیاده بنظرتون اینکار منطقیه؟ یکی بخواد clone کنه باید همراهش چند تا فایل بی ربط رو دانلودش کنه. خب چه کار هایی میتونیم؟ میتونیم تو فضای ذخیره سازی ای مثل aws و ... قرار بدیم ولی بازم وابسته شدیم به یه سرویس خارجی که فردا ممکنه فیلتر یا قطع بشه. راهکار حرفه ای یه ترفند جالبیه که تو پروژه های بزرگ اپن سورس استفاده میشه. میریم قسمت ایشو یک ایشو جدید باز میکنیم بعد فایلمون رو تو قسمت description آپلود میکنیم. بعدش صبر کنید تا آپلود فایل تموم بشه. گیتهاب به شما یک لینک میده. همونو کپی کنید تو README قرارش بدید! نکته طلایی: اصلا نیازی نیست دکمه submit new issue رو بزنید! حتی اگه ایشو کنسل بشه یا کامل ببندید و نسازیدش، اون فایل روی سرور های پرسرعت گیت‌هاب باقی میمونن! به همین سادگی بدون اینکه حجم پروژه بالا بره، داکیومنت های حرفه ای داشته باشید. #github @Syntax_fa

میتونید gemini enterprise یک ماهه اشتراک آزمایشی بگیرید و هیچیم نمیخواد ازتون. https://business.gemini.google/

چند تا گیتهاب اکشن کاربردی که بدرد اکثر ریتوزیتوری ها میخوره: 1. اکشن لینت با این اکشن، اکشن هارو لینت کن و بررسی کن ورژن ها، سینتکس و همه چی اوکیه یا نه. همچنین خودش تو پول ریکوئست ها کامنت هم میذاره و مشکلات رو میگه. نمونه کد: https://github.com/syntaxfa/quick-connect/blob/main/.github/workflows/action-lint.yml 2. داکر لینت: فایل Dockerfile هارو لینت میکنه از نظر امنیتی، استاندارد و اینکه الکی حجم ایمیج رو زیاد نکرده باشید و ... لینت میکنه. نمونه کد: https://github.com/syntaxfa/quick-connect/blob/main/.github/workflows/docker-lint.yml 3. کامیت لینت: لینت کردن کامیت ها مسیج کامیت و ... نمونه کد: https://github.com/syntaxfa/quick-connect/blob/main/.github/workflows/commit-lint.yml 4. SQL Lint: فایل های sql رو لینت میکنه. نمونه کد: https://github.com/syntaxfa/quick-connect/blob/main/.github/workflows/sql-lint.yml 5. دپلوی روی داکر هاب نمونه کد: https://github.com/syntaxfa/quick-connect/blob/main/.github/workflows/admin-deploy.yml #github #action @Syntax_fa

چرا Code-level Monolith معماری برنده است؟ (درس‌هایی از Grafana Loki) دوراهی مونولیت یا میکروسرویس: از یک طرف، مونولیت (Monolith) ساده است اما اگر بد نوشته شود به "کد اسپاگتی" تبدیل می‌شود. از طرف دیگر، میکروسرویس (Microservices) مقیاس‌پذیر است اما شما را در جهنمی از پیچیدگی‌های شبکه، دیپلوی و مدیریت ۵۰ کانتینر مختلف غرق می‌کند. اما اگر راه سومی وجود داشته باشه چی؟ راهی که در آن کدتان را "مثل میکروسرویس" می‌نویسید، اما آن را "مثل مونولیت" اجرا می‌کنید. در معماری Code-level Monolith، شما مرزهای سرویس‌هایتان را کاملا رعایت می‌کنید. یعنی سرویس Auth و سرویس Order کدهای کاملا جداگانه‌ای دارند (درست مثل میکروسرویس). اما در زمان بیلد (Build Time)، به جای اینکه آنها را در کانتینرهای جداگانه بسته‌بندی کنید، همه را در یک فایل اجرایی (Binary) واحد لینک می‌کنید. شعار این معماری: > *"میکروسرویس در توسعه، مونولیت در اجرا."* جادوی Grafana Loki و Tempo بهترین مثال زنده این معماری در دنیا، ابزارهای شرکت Grafana Labs (مانند Loki برای لاگ، Tempo برای تریس و Mimir برای متریک) هستند. سورس کد Grafana Loki از اجزای مختلفی تشکیل شده است: * Ingester (دریافت لاگ) * Distributor (توزیع بار) * Querier (جستجو) نکته نبوغ‌آمیز اینجاست: همه این‌ها در یک کدبیس و یک فایل باینری هستند. 1. حالتِ من و شما (All-in-One): وقتی می‌خواهید Loki را روی لپ‌تاپ یا سرور کوچک خود اجرا کنید، دستور زیر را می‌زنید: ./loki -target=all در این حالت، تمام اجزا در یک پروسه اجرا می‌شوند. ارتباط بین Distributor و Ingester از طریق Function Call در حافظه رم انجام می‌شود. * تاخیر: صفر نانوثانیه. * پیچیدگی: صفر. 2. حالتِ اسکیل بالا (Microservices): وقتی ترافیک شما میلیونی می‌شود، همان فایل باینری را با فلگ متفاوتی اجرا می‌کنید: ./loki -target=ingester حالا این باینری فقط نقش Ingester را بازی می‌کند و بقیه کدها خاموش می‌شوند. در این حالت، ارتباطات به صورت خودکار به gRPC/HTTP تغییر می‌کند. چرا باید به این روش فکر کنید؟ 1. حذف سربار شبکه (Zero Latency): در میکروسرویس، داده‌ها باید Serialize شوند، به شبکه بروند و Deserialize شوند. در Code-level Monolith، این فقط یک جابجایی اشاره‌گر (Pointer) در حافظه است. سرعت اجرای شما وحشتناک بالا می‌رود. 2. دیپلوی آسان (Operational Simplicity): برای شروع پروژه، نیازی به Kubernetes و مدیریت ۱۰ تا فایل YAML ندارید. یک فایل باینری را کپی و اجرا می‌کنید. 3. انعطاف‌پذیری (Agility): شما امروز نمی‌دانید پروژه شما چقدر بزرگ می‌شود. با این روش، شما امروز ساده شروع می‌کنید، اما کدتان "Ready to Scale" است. هر زمان لازم شد، با تغییر کانفیگ، مونولیت را می‌شکنید. چطور پیاده‌سازی کنیم؟ (مثال Go) کلید کار در استفاده از Interface**هاست. به جای اینکه سرویس A مستقیماً با gRPC کلاینتِ سرویس B صحبت کند، با یک اینترفیس صحبت می‌کند. * **در حالت Monolith: پیاده‌سازی اینترفیس، مستقیماً متد سرویس B را صدا می‌زند. * در حالت Microservice: پیاده‌سازی اینترفیس، یک درخواست gRPC می‌فرستد. —- این مقاله به خوبی پیاده سازیش رو توضیح میده: بیایید فرض کنیم اینکه برنامه میکروسرویس باشد یا مونولیت، فقط یک جزئیات پیاده‌سازی است سوال: در گوئیک کانکت چطور میشه به code level monolith رسید؟ https://github.com/syntaxfa/quick-connect #code_level_monolith @Syntax_fa