اجزای یک اپلیکیشن را در یک پردازش یا محفظه (container) جداگانه برای ایجاد جداسازی و کپسوله‌سازی قرار دهید. این الگو همچنین می‌تواند برنامه‌ها را قادر سازد که از اجزا و فناوری‌‌های ناهمگن(heterogeneous) تشکیل شده باشند.
این الگوی Sidecar نامیده می‌شود؛ زیرا شبیه یک‌کابین کناری متصل به موتورسیکلت است. در این الگو، Sidecar به یک برنامه والد متصل شده است و ویژگی‌های پشتیبانی را برای برنامه ارائه می‌دهد. سایدکار همچنین چرخه عمر یکسانی با برنامه والد دارد و در کنار والدین ایجاد و بازنشسته می‌شود. الگوی Sidecar گاهی اوقات به‌عنوان الگوی sidekick نامیده می‌شود و یک الگوی تجزیه (decomposition) است.
برنامه‌ها و سرویس‌ها اغلب به عملکردهای مرتبط مانند monitoring, logging, configuration و networking service نیاز دارند. این وظایف جانبی را می‌توان به‌عنوان اجزا یا سرویسهای جداگانه پیاده‌سازی کرد.
اگر عملکردهای گفته شده با برنامه ادغام شوند، می‌توانند در همان فرایند برنامه اجرا شوند و از منابع مشترک به‌صورت بهینه استفاده کنند. بااین‌حال، این بدان معناست که آنها به‌خوبی ایزوله نیستند و قطع‌شدن یکی از این اجزا می‌تواند سایر اجزا یا کل برنامه را تحت‌تأثیر قرار دهد. همچنین، معمولاً باید با استفاده از همان زبان برنامه والد پیاده‌سازی شوند. در نتیجه، مؤلفه و برنامه دارای وابستگی متقابل نزدیک به یکدیگر هستند.
اگر برنامه به سرویس‌‌هایی تجزیه شود، هر سرویس می‌تواند با استفاده از زبان‌ها و فناوری‌‌های مختلف ساخته یا نوشته شود. این حالت انعطاف‌پذیری بیشتری می‌دهد و به این معنی است که هر مؤلفه معمولاً وابستگی‌‌های خاص خود را دارد و برای دسترسی به پلتفرم زیربنایی، هر منبع مشترک که با برنامه والد به اشتراک گذاشته شده است به کتابخانه‌‌های Language-specific نیاز دارد. علاوه بر این، استقرار این ویژگی‌ها به‌عنوان سرویسهای جداگانه می‌تواند تأخیر زمانی خاصی را به برنامه اضافه کند. مدیریت کد و وابستگی‌ها برای این رابط خاص نیز می‌تواند پیچیدگی قابل‌توجهی را به‌خصوص برای hosting یا میزبانی، استقرار و مدیریت آن اضافه کند.
مجموعه ساختاریافته‌ای از تسک‌ها را در برنامه اصلی قرار دهید و آنها را در داخل process یا container خود قرار دهید و یک رابط همگن(homogeneous interface) برای platform services فراهم کنید.
یک سرویس sidecar لزوماً بخشی از برنامه نیست، بلکه به آن متصل است. هر جا که برنامه والد می‌رود به دنبال آن می‌رود. sidecarها processها یا سرویس‌‌هایی را پشتیبانی می‌کنند که با برنامه اصلی deploy می‌شوند. در موتورسیکلت، sidecar به یک موتورسیکلت متصل می‌شود و هر موتورسیکلت می‌تواند sidecar مخصوص به خود را داشته باشد. به همین ترتیب، یک سرویس sidecar در سرنوشت برنامه اصلی خود سهیم است. برای هر نمونه از برنامه، یک نمونه از sidecar مستقر شده و در کنار آن میزبانی می‌شود.
مزایای استفاده از الگوی سایدکار عبارت‌اند از:
- یک sidecar از نظر محیط اجرا و زبان برنامه‌نویسی از اپلیکیشن اولیه یا اصلی مستقل است، بنابراین نیازی به توسعه یک sidecar برای هر زبان ندارید.
- سایدکار می‌تواند به منابع مشابه برنامه اصلی دسترسی داشته باشد. برای مثال، یک سایدکار می‌تواند منابع سیستمی را که هم توسط سایدکار و هم برنامه اصلی استفاده می‌شود را مانیتور و نظارت کند.
- به دلیل نزدیکی آن به برنامه اولیه، هیچ تأخیر قابل‌توجهی در برقراری ارتباط بین آنها وجود ندارد.
- حتی برای برنامه‌هایی که سازوکار توسعه‌پذیری (extensibility) ارائه نمی‌دهند، می‌توانید از یک sidecar برای گسترش عملکرد با پیوست کردن آن به‌عنوان process خود در همان host یا sub-container برنامه اصلی استفاده کنید.
الگوی سایدکار اغلب با کانتینرها استفاده می‌شود و به آن کانتینر سایدکار یا کانتینر کناری می‌گویند.
- نوع و نحوه deployment و packaging را که برای deploy services و processها یا کانتینرها استفاده خواهید کرد را در نظر بگیرید. کانتینرها به‌ویژه با الگوی سایدکار متناسب هستند.
- هنگام طراحی یک سرویس سایدکار، در مورد سازوکار ارتباط بین فرایندی بادقت تصمیم بگیرید. سعی کنید از فناوری‌‌های مبتنی بر زبان یا framework استفاده کنید، مگر اینکه الزامات عملکردی خاصی آن را غیرعملی کند.
- قبل از قراردادن عملکردی در یک سایدکار، در نظر بگیرید که عملکرد موردنظر آیا به‌عنوان یک سرویسهای مجزا عملکرد بهتری از یک daemon (برای یادآوری daemon به فصل مقدمه رجوع کنید) سنتی دارد یا خیر؟
- همچنین در نظر بگیرید که آیا این عملکرد می‌تواند به‌عنوان یک کتابخانه پیاده‌سازی شود یا با استفاده از مکانیزم توسعه سنتی، کتابخانه‌‌های Language-specific ممکن است سطح عمیق‌تری از یکپارچگی به همراه سربار شبکه کمتری داشته باشند.
از این الگو زمانی استفاده کنید که:
- برنامه اصلی شما از مجموعه‌ای مختلفی از زبان‌ها و frameworkها استفاده می‌کند. یک مؤلفه (component) واقع در یک سرویس sidecar می‌تواند توسط اپلیکیشن نوشته شده به زبان‌های مختلف با استفاده از frameworkهای مختلف استفاده شود.
- یک مؤلفه متعلق به یک تیم با دسترسی ریموت یا سازمان دیگری است.
- یک مؤلفه یا ویژگی باید در همان host برنامه قرار گیرد.
- شما به سرویسی نیاز دارید که دوره حیاتی کلی برنامه اصلی شما را به اشتراک بگذارد، اما بتواند به طور مستقل به‌روزرسانی شود.
- شما به کنترل دقیقی بر resource limit برای یک منبع یا مؤلفه خاص نیاز دارید. برای مثال، ممکن است بخواهید مقدار حافظه استفاده شده از یک مؤلفه خاص را محدود کنید. می‌توانید مؤلفه را به‌عنوان یک سایدکار مستقر کنید و مصرف حافظه را مستقل از برنامه اصلی مدیریت کنید.
این الگو ممکن است مناسب نباشد:
- زمانی که ارتباطات بین فرایندی (interprocess) باید بهینه شود. ارتباط بین یک برنامه والد و سرویس sidecar شامل مقداری سربار است، به‌ویژه تأخیر زمانی در فراخوانی‌ها و این ممکن است یک trade-off مناسب برای [chatty interfaces] (https://l.vrgl.ir/r?ad=1&l=https%3A%2F%2Fwww.narendranaidu.com%2F2005%2F07%2Fchatty-interfaces-vs-chunky-interfaces.html&si=tamz0nilpyqb&st=post&k=D0IteyVK0OsTVVLSepofGzpq%2BlAwrTwL8U%2BsZqErtrs%3D) نباشد.
- برای اپلیکیشن‌‌های کوچک که در آن هزینه منابع برای deploy یک سرویس sidecar برای هر نمونه آن ارزش استفاده از مزایای ایزوله شدن را ندارد.
- زمانی که سرویس نیاز به مقیاس‌دهی یا scale متفاوت یا مستقل از برنامه‌های اصلی دارد. اگر چنین است، شاید بهتر باشد که این ویژگی را به‌عنوان یک سرویس جداگانه اجرا کنید.
الگوی sidecar برای بسیاری از سناریوها قابل‌استفاده است. چند مثال رایج:
- Infrastructure API. تیم توسعه زیرساخت یک سرویس ایجاد می‌کند که در کنار هر اپلیکیشن مستقر(Deploy) می‌شود، به‌جای یک کتابخانه کلاینت از نوع language-specific برای دسترسی به زیرساخت، این سرویس به‌عنوان سایدکار بارگیری می‌شود و یک‌لایه مشترک برای سرویس مربوط به زیرساخت، از جمله logging، environment data، configuration store، discovery، health checks، و watchdog services فراهم می‌کند. سایدکار همچنین محیط host برنامه والد و process (یا container) را مانیتور می‌کند و اطلاعات را در یک سرویس متمرکز ثبت می‌کند.
- مدیریت NGINX/HAProxy: همیشه NGINX را با یک سرویس sidecar استقرار دهید که وضعیت محیطی (environment) را مانیتور می‌کند، سپس فایل پیکربندی NGINX را به‌روزرسانی می‌کند و در صورت نیاز به تغییر وضعیت، فرایند را بازیابی می‌کند.
- Ambassador sidecar: یک سرویس Ambassador pattern را به‌عنوان یک sidecar مستقر یا Deploy کنید. برنامه از طریق Ambassador ارتباط می‌گیرد که ثبت request ها، logging، routing و circuit breaking و سایر ویژگی‌های مرتبط با اتصال را مدیریت می‌کند.
- Offload proxy: یک پروکسی NGINX را در مقابل یک نمونه سرویس node.js قرار دهید تا محتوای فایل‌‌های static را برای سرویس ارائه دهد.