🧩 7️⃣ الگوی Sidecar (Sidecar Pattern) (بخش هفتم)
ءSidecar Pattern یک کامپوننت کمکی را در کنار container اصلی اپلیکیشن شما deploy می‌کند که وظیفه ارائه قابلیت‌های پشتیبان مانند logging، monitoring، configuration یا networking را بر عهده دارد. 🛠
ءSidecar در همان محیط اجرایی اپلیکیشن اصلی اجرا می‌شود و lifecycle مشترکی با آن دارد. این موضوع باعث می‌شود بتوان بدون تغییر کد اپلیکیشن، قابلیت‌های جدیدی به آن اضافه کرد. 🔌
⚙️ نحوه کار (How it works):
یک sidecar container در کنار container اصلی اپلیکیشن و در همان container یا host اجرا می‌شود 🧱
هر دو container از یک network namespace مشترک استفاده می‌کنند و می‌توانند از طریق localhost با هم ارتباط برقرار کنند 🌐
ءSidecar می‌تواند ترافیک ورودی و خروجی را intercept کند و مسئول cross-cutting concernهایی مانند logging، جمع‌آوری metrics یا قابلیت‌های service mesh باشد 📊
ارتباط بین اپلیکیشن و sidecar از طریق local network calls انجام می‌شود 🔄
قابلیت‌های sidecar می‌توانند مستقل از اپلیکیشن به‌روزرسانی شوند، بدون نیاز به تغییر یا redeploy کد اصلی ♻️
امکان اتصال چند sidecar به یک اپلیکیشن واحد برای اهداف مختلف وجود دارد 🧩🧩
✅ مزایا (Benefits):
جداسازی دغدغه‌های زیرساختی از کد اپلیکیشن و تمرکز کد بر business logic 🧠
پشتیبانی از polyglot architecture، چون sidecar مستقل از زبان یا framework اپلیکیشن عمل می‌کند 🌍
ساده‌سازی توسعه اپلیکیشن با استفاده از کامپوننت‌های زیرساختی قابل استفاده مجدد ♻️
امکان به‌روزرسانی مستقل قابلیت‌های زیرساختی بدون redeploy اپلیکیشن 🚀
کاهش code duplication بین سرویس‌ها با متمرکز کردن قابلیت‌های مشترک در sidecar 📦
⚠️ معایب (Drawbacks):
افزایش مصرف منابع، چون هر instance اپلیکیشن یک یا چند sidecar اضافی اجرا می‌کند 💾
افزایش پیچیدگی در پیکربندی deployment و orchestration 🧩
احتمال افزایش latency به دلیل hopهای شبکه‌ای اضافی بین اپلیکیشن و sidecar ⏱️
🎯 موارد استفاده (Use cases):
• پیاده‌سازی Service Mesh برای مدیریت ترافیک، امنیت و observability 🔐📈
• ءCentralized logging که در آن sidecar لاگ‌های اپلیکیشن را جمع‌آوری و به سیستم‌های logging ارسال می‌کند 📝
• ءConfiguration management که sidecar پیکربندی‌ها را به‌صورت داینامیک دریافت و به‌روزرسانی می‌کند ⚙️
• یکپارچه‌سازی Event-driven که در آن sidecar مدیریت messaging را از طریق queueهای قابل تعویض (مثل Kafka، RabbitMQ، Azure Service Bus) انجام می‌دهد و امکان تغییر آن‌ها بدون دست زدن به کد اپلیکیشن را فراهم می‌کند (برای مثال با استفاده از Dapr) 🔄