مونولیت در برابر میکروسرویس

معماری مونولیتیک چیست؟

در معماری مونولیتیک (Monolith)، کل برنامه به‌صورت یک واحد نرم‌افزاری واحد نوشته، build و اجرا می‌شود. رابط کاربری، منطق کسب‌وکار و دسترسی به داده همگی در یک codebase و یک فرایند (process) قرار دارند. این معماری برای پروژه‌های کوچک تا متوسط بسیار مناسب است: توسعه‌ی اولیه ساده‌تر، تست کردن راحت‌تر و دیپلوی یک‌مرحله‌ای است.

اما با رشد تیم و پیچیدگی پروژه، مونولیت با مشکلاتی روبه‌رو می‌شود: هر تغییر کوچک نیاز به build و دیپلوی کل برنامه دارد، تیم‌های مختلف روی یک codebase مشترک تداخل پیدا می‌کنند، مقیاس‌پذیری فقط به‌صورت افقی و کامل ممکن است (نمی‌توان فقط بخش پرترافیک را مقیاس داد)، و با گذشت زمان کد به‌شدت به هم وابسته و «مونولیت بزرگ گِلی» (Big Ball of Mud) می‌شود.

معماری میکروسرویس

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

اما این آزادی رایگان نیست: میکروسرویس پیچیدگی جدیدی به نام پیچیدگی توزیع‌شده وارد می‌کند که در فصل‌های بعد با جزئیات بررسی می‌کنیم.