سرور، کلود و معماری مایکروسرویس

تاریخچه

در گذشته، سازمان‌ها ملزم به تهیه کامپیوترهای فیزیکی بسیار بزرگ و گران‌قیمت به نام Server بودند و می‌بایست آن‌ها را در محیط‌های مجهز به سیستم‌های خنک‌کننده نگهداری می‌کردند. با رشد کسب‌وکار، فرآیند خرید و راه‌اندازی تجهیزات جدید ماه‌ها به طول می‌انجامید. علاوه بر این، برنامه‌های نرم‌افزاری به صورت یکپارچه و حجیم (Monolithic) توسعه می‌یافتند؛ به طوری که ایجاد تغییر در بخش کوچکی از آن‌ها، ریسک از کار افتادن کل سیستم را به همراه داشت.

درک مفاهیم با تمثیل

برای درک بهتر این تحول، می‌توان راه‌اندازی یک رستوران را در نظر گرفت. در روش سنتی، تمام زیرساخت‌ها (ساختمان، تجهیزات پخت و میزها) باید خریداری شوند. اگر تقاضا کم باشد، سرمایه هدر رفته است و در صورت افزایش ناگهانی مشتریان، ظرفیت کافی برای پاسخگویی وجود ندارد.

فناوری Cloud (رایانش ابری) مشابه اجاره کردن یک زیرساخت انعطاف‌پذیر است؛ در صورت افزایش تقاضا، می‌توان در کوتاه‌ترین زمان ظرفیت را افزایش داد و تنها هزینه منابع استفاده‌شده پرداخت می‌شود. از سوی دیگر، در نرم‌افزارهای یکپارچه قدیمی، تمام فرآیندها به صورت متمرکز پردازش می‌شدند. اما در Microservice Architecture (معماری مایکروسرویس)، وظایف به بخش‌های تخصصی و مستقل تقسیم می‌شوند که هر یک وظیفه مشخصی را بر عهده داشته و به صورت ایزوله عمل می‌کنند.

مفاهیم تخصصی

• Server (سرور): یک کامپیوتر قدرتمند و همیشه در دسترس است که به شبکه متصل شده و وظیفه پاسخگویی به درخواست‌های سایر کامپیوترها (کلاینت‌ها) را بر عهده دارد.

• Cloud (رایانش ابری): اجاره سرورها و قدرت پردازشی از ارائه‌دهندگان بزرگ خدمات ابری بر بستر اینترنت، به عنوان جایگزینی برای خرید و نگهداری فیزیکی تجهیزات در محل سازمان.

• Microservice Architecture (معماری مایکروسرویس): یک الگوی طراحی معماری نرم‌افزار است که در آن، یک سیستم یکپارچه به سرویس‌های بسیار کوچک و مستقل شکسته می‌شود. هر یک از این سرویس‌ها مسئولیت یک کارایی خاص را بر عهده دارند و از طریق پروتکل‌های شبکه با یکدیگر ارتباط برقرار می‌کنند.

برای بررسی نحوه کارکرد این معماری، یک فایل پیکربندی YAML در ادامه آورده شده است. این فایل نحوه تقسیم یک پروژه به سه Microservice مجزا را نشان می‌دهد:

# A simple configuration showing Microservices
services:
  frontend-app: # سرویسی که ظاهر سایت را به کاربر نشان می‌دهد
    image: my-website-ui:latest
    ports:
      - "80:80"
 
  payment-service: # سرویس مستقلی که فقط وظیفه عملیات بانکی را دارد
    image: payment-api:v1.2
 
  database: # فضایی که اطلاعات کاربران در آن ذخیره می‌شود
    image: postgres:15

در این ساختار توزیع‌شده، در صورتی که سرویس payment-service با مشکل مواجه شود، سرویس frontend-app همچنان به کار خود ادامه داده و در دسترس خواهد بود. این ویژگی، پایداری و تاب‌آوری سیستم را در برابر خرابی‌های نقطه‌ای تضمین می‌کند.

یکی از خطاهای متداول در طراحی سیستم‌ها، رویکرد افراطی در استفاده از معماری مایکروسرویس است. گاهی اوقات یک نرم‌افزار بسیار ساده و با مقیاس کوچک، به ده‌ها بخش خرد تقسیم می‌شود. این اقدام منجر به پیچیدگی بی‌مورد و کاهش سرعت سیستم می‌گردد. در ادبیات مهندسی، این ضدالگو تحت عنوان Distributed Monolith شناخته می‌شود؛ سیستمی درهم‌تنیده و پیچیده که تنها ظاهری از معماری توزیع‌شده را به همراه دارد، اما در عمل مزایای آن را ارائه نمی‌دهد.

در محیط‌های تجاری و استارتاپی، تصمیم‌گیری برای انتخاب معماری مناسب بسیار حائز اهمیت است. فرض کنید در یک شرکت نوپا با ترافیک روزانه بسیار پایین (مثلاً ۱۰ بازدیدکننده)، پیشنهادی مبنی بر مهاجرت سیستم به ۲۰ Microservice مجزا بر روی محیط Cloud با هدف دستیابی به مقیاس‌پذیری مشابه سازمان‌های بزرگ مطرح شود.

از دیدگاه مهندسی قابلیت اطمینان سایت (SRE)، چنین تصمیمی برای یک پروژه در مقیاس کوچک، مصداق بارز پیچیدگی غیرضروری است. در این سطح از ترافیک، پیاده‌سازی یک معماری Monolithic کارآمدتر، اقتصادی‌تر و مدیریت آن بسیار منطقی‌تر از درگیری با چالش‌های شبکه و یکپارچه‌سازی در معماری توزیع‌شده است. معماری باید همواره متناسب با مقیاس و نیاز واقعی سیستم انتخاب شود و استفاده کورکورانه از الگوهای پیچیده صرفاً موجب اتلاف منابع خواهد شد.