الگوی Sidecar: گسترش خدمات میکرو بدون تغییر کد

در سیستم‌های ابری مدرن، انتظار می‌رود که میکروسرویس‌ها بسیار بیشتر از اجرای منطق تجاری انجام دهند. آنها باید ورود به سیستم را مدیریت کنند، گواهی‌های SSL/TLS را مدیریت کنند، معیارها را جمع‌آوری کنند، مکانیسم‌های امتحان مجدد را پیاده‌سازی کنند، و ارتباطات امن را با سایر سرویس‌ها هماهنگ کنند.

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

اینجاست که Sidecar Pattern وارد می‌شود. در این راهنما، الگوی Sidecar چیست، چرا برای معماری‌های میکروسرویس مدرن ضروری است و چگونه با استفاده از قیاس‌های ساده و نمونه‌های پیکربندی Kubernetes کار می‌کند، توضیح خواهیم داد.

قیاس دنیای واقعی: موتور سیکلت کناری

ساده ترین راه برای درک این الگو، فکر کردن به یک موتور سیکلت با یک درب کناری است.

تصور کنید یک موتورسیکلت با کارایی بالا دارید. این برای انجام یک کار فوق العاده خوب طراحی شده است: حمل و نقل سریع یک سوار. حال، فرض کنید باید چمدان مسافر را حمل کنید یا یک صندلی اضافی اضافه کنید.

می‌توانید قاب، موتور و چرخ‌های موتورسیکلت را کاملاً دوباره طراحی کنید تا آن را به خودرو تبدیل کنید. با این حال، این نیاز به تلاش گسترده دارد، سادگی دوچرخه را از بین می برد و نگهداری آن را سخت می کند.

درعوض، یک ماشین کناری را وصل می کنید.

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

در معماری نرم افزار:

• موتورسیکلت محفظه برنامه اصلی شماست (که منطق اصلی کسب و کار شما را اجرا می کند، مانند تسویه حساب یا تأیید اعتبار کاربر).
• Sidecar یک کانتینر کمکی جداگانه است (وظایف ابزار کاربردی مانند خاتمه SSL، نظارت یا ارسال گزارش را در حال اجرا می کند).
• سفر چرخه حیات استقرار است (به عنوان مثال، یک Kubernetes Pod).

مشکل: نگرانی های متقاطع و نفخ کد

قبل از سایدکارها، توسعه دهندگان باید کتابخانه های کمکی را مستقیماً در کد برنامه خود قرار می دادند. برای مثال، اگر می‌خواهید گزارش‌ها را به یک سرور مرکزی ارسال کنید، یک کتابخانه ورود به سیستم وارد کرده‌اید. اگر به معیارهایی نیاز داشتید، یک SDK معیارها اضافه کرده‌اید.

این رویکرد مبتنی بر کتابخانه چندین چالش مهم ایجاد کرد:

• قفل زبان: اگر کتابخانه مانیتورینگ فقط در Go نوشته شده باشد، نمی توانید به راحتی از آن در میکروسرویس پایتون یا جاوا استفاده کنید. شما باید برای هر زبان موجود در پشته خود یک کتابخانه پیدا کنید یا بسازید.
• آلودگی کد: منطق کسب و کار با کدهای زیرساخت خاص برای تلاش های مجدد، کشف سرویس، رمزگذاری و ثبت نام درهم می شود.
• به‌روزرسانی‌های پیچیده: اگر آسیب‌پذیری امنیتی در کتابخانه ارتباطی پیدا شود، هر میکروسرویس باید وابستگی خود را به‌روزرسانی کند، دوباره کامپایل کند و مجدداً مستقر کند.
• تضاد منابع: کد کمکی در همان فرآیند زمان اجرا برنامه اصلی اجرا می شود، به این معنی که نشت حافظه در لاگر می تواند کل برنامه اصلی شما را خراب کند.

راه حل: الگوی ماشین کناری

Sidecar Pattern این مشکلات را با خارج کردن وظایف کمکی از فرآیند اصلی برنامه و قرار دادن آنها در یک فرآیند جداگانه و مستقل که درست در کنار برنامه اجرا می شود، حل می کند.

در محیط‌های کانتینری مانند Kubernetes، کانتینر برنامه و ظرف کناری در داخل یک پاد اجرا می‌شوند. زیرا آنها Pod یکسانی دارند:

• Same Network Namespace: آدرس IP و پورت های شبکه یکسانی دارند. آن‌ها می‌توانند فوراً با localhost با تاخیر تقریباً صفر با یکدیگر صحبت کنند.
• حجم‌های ذخیره‌سازی مشترک: آنها می‌توانند دقیقاً به همان فضای ذخیره‌سازی دیسک دسترسی داشته باشند و به سایدکار اجازه می‌دهد فایل‌های گزارش را بخواند یا فایل‌های پیکربندی نوشته شده توسط برنامه اصلی را بارگیری کند.
• چرخه حیات یکسان: چرخ کناری در کنار برنامه اصلی مستقر شده، راه اندازی شده، متوقف می شود و مقیاس بندی می شود.

موارد استفاده کلیدی از الگوی سایدکار

سایدکارها فوق العاده همه کاره هستند. برخی از رایج ترین برنامه ها عبارتند از:

1. Proxying Mesh Service (به عنوان مثال، Envoy، Linkerd)

به جای اینکه برنامه شما تماس مستقیم HTTP با سرویس های دیگر برقرار کند، درخواست ها را به پراکسی سایدکار محلی خود ارسال می کند. پروکسی sidecar مسیریابی، تلاش مجدد، متعادل کردن بار، قطع مدار و رمزگذاری متقابل TLS (mTLS) را کنترل می کند، سپس درخواست را ارسال می کند. برنامه کاملاً از این پیچیدگی های شبکه بی اطلاع است.

2. جمع‌آوری و ارسال گزارش (مثلاً فلوئنت بیت)

برنامه شما به سادگی بیانیه های گزارش خود را در خروجی استاندارد یا یک فایل گزارش محلی می نویسد. ظرف کناری آن فایل را نظارت می کند، گزارش ها را تجزیه می کند و آنها را به یک موتور تجزیه و تحلیل مرکزی مانند Elasticsearch یا Datadog ارسال می کند.

3. پیکربندی و بارگذاری مجدد مخفی

یک ماشین کناری می‌تواند یک سرور راه دور (مانند کنسول یا Vault) را برای به‌روزرسانی‌های پیکربندی یا چرخش کلید رمزنگاری تماشا کند. هنگامی که تغییری شناسایی می شود، فایل های جدید را در یک حجم مشترک دانلود می کند و به برنامه اصلی سیگنال می دهد تا آنها را دوباره بارگیری کند، بدون نیاز به راه اندازی مجدد.

مثال پیاده سازی Kubernetes

در Kubernetes راه‌اندازی یک صندلی کناری کار ساده‌ای است. در اینجا یک پیکربندی ساده YAML وجود دارد که یک کانتینر برنامه را نشان می‌دهد که گزارش‌ها را در یک حجم مشترک می‌نویسد، و یک کانتینر کناری فلوئنت بیت که آن گزارش‌ها را می‌خواند و ارسال می‌کند:

apiVersion: v1
kind: Pod
metadata:
  name: app-with-logging-sidecar
  labels:
    app: billing-service
spec:
  containers:
    # 1. Primary Application Container
    - name: web-app
      image: node:18-alpine
      command: ["/bin/sh", "-c"]
      args:
        - >
          while true; do
            echo "$(date) [INFO] Transaction processed successfully" >> /var/log/app/output.log;
            sleep 5;
          done
      volumeMounts:
        - name: shared-logs
          mountPath: /var/log/app

    # 2. Sidecar Container (Log Shipper)
    - name: log-shipper
      image: fluent/fluent-bit:latest
      volumeMounts:
        - name: shared-logs
          mountPath: /var/log/app
      # In a real setup, Fluent Bit config would read /var/log/app/output.log
      # and forward it to an external logging system.

  # Shared disk storage accessible by both containers
  volumes:
    - name: shared-logs
      emptyDir: {}

مزایا و معایب الگوی ماشین جانبی

مانند هر الگوی طراحی، کرکره‌های جانبی دارای معاوضه‌هایی هستند:

نتیجه گیری

الگوی Sidecar یک واحد ساختمانی اساسی از معماری‌های مدرن ابری است. با جدا کردن نگرانی های مقطعی - مانند پروکسی شبکه، امنیت، ورود به سیستم و مدیریت پیکربندی - در یک فرآیند همراه جداگانه، به توسعه دهندگان این امکان را می دهد که صرفاً روی ایجاد ارزش تجاری تمرکز کنند.

در حالی که سربار منابع اضافی را معرفی می‌کند و برای مدیریت مؤثر به پلتفرم‌های ارکستراسیون کانتینری مانند Kubernetes نیاز دارد، مزایای پایگاه‌های کد پاک‌تر، انعطاف‌پذیری زبان، و مقیاس‌بندی مستقل آن را به یک الگوی ضروری برای میکروسرویس‌های سازمانی تبدیل می‌کند.

درباره توسعه نرم‌افزار بیشتر و بینش‌های مهندسی باطن در Ghaznix Blog →