Monolith در برابر Microservices: کدام را انتخاب کنیم؟

بحث Monolith (یکپارچه) در برابر Microservices (ریزسرویس‌ها) اغلب به جنگ هواداری تبدیل می‌شود. یک طرف سادگی را می‌ستاید؛ طرف دیگر مقیاس تیم و استقرار مستقل را. هر دو درست می‌گویند — برای مسئله‌های متفاوت.

Martin Fowler در Monolith First می‌نویسد میکروسرویس‌ها مفیدند ولی Premium پیچیدگی دارند و برای سیستم‌های ساده‌تر مونولیت مناسب‌تر است؛ بسیاری از داستان‌های موفق از شکستن مونولیت بالغ آمده‌اند. در Microservice Premium تأکید می‌کند تا وقتی پیچیدگی سیستم از آستانه نگذشته، سراغ جداسازی سرویس نروید.

این مقاله معیار تصمیم می‌دهد، نه برچسب شیک برای اسلاید سرمایه‌گذار.

پاسخ کوتاه

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

مونولیت بد = کد درهم بدون مرز. میکروسرویس بد = توزیع پیچیدگی بدون نظم. هدف، معماری متناسب است نه مد.

اگر نمی‌توانید مونولیت را ماژولار نگه دارید، مجموعهٔ سرویس‌ها را هم مرتب نگه نخواهید داشت.

تعریف عملی بدون شعار

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

Fowler یادآوری می‌کند این دو برچسب طیف‌اند نه افراز کامل فضای معماری. سیستم‌های هیبرید و ماژولارِ تک‌استقرار هم وجود دارند.

جدول تصمیم

Premium میکروسرویس چیست؟

طبق Fowler، هزینهٔ مدیریت مجموعهٔ سرویس‌ها — تأخیر شبکه، سازگاری نسخه، تست قرارداد، ردیابی درخواست، و شکست جزئی — می‌تواند تیم را کند کند مگر پیچیدگی مسئله آن را جبران کند. Microservice Trade-Offs همین بده‌بستان را باز می‌کند: استقلال و مقیاس در برابر پیچیدگی عملیاتی و سختی مرز اشتباه.

• هر سرویس یعنی مسیر deploy، پیکربندی، و مالکیت on-call.
• تراکنش کسب‌وکار بین سرویس‌ها دیگر یک BEGIN/COMMIT ساده نیست.
• مرز غلط گران‌تر از مونولیت کمی شلوغ اصلاح می‌شود.

چرا Monolith First هنوز استدلال قوی است؟

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

استثنای محتمل: جایگزینی سیستمی که دامنهٔ آن خوب شناخته شده و تیم تجربهٔ توزیع‌شده دارد. حتی آن‌جا هم قرارداد و مشاهده‌پذیری پیش‌نیاز است نه پس‌نیاز.

مونولیت ماژولار: راه میانی مفید

قبل از شکستن فرآیندها، مرزهای ماژول داخل یک استقرار را سخت کنید: پوشه‌ها/پکیج‌های دامنه، ممنوعیت import مخالف جریان، و API داخلی روشن. اگر تیم نتواند این انضباط را در یک ریپو نگه دارد، شبکه آن را معجزه‌آسا درست نمی‌کند.

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

نشانه‌های وقت استخراج

1. صف استقرار یک بخش، بخش دیگر را همیشه معطل می‌کند.
2. نیاز مقیاس یک قابلیت با بقیه هم‌خوان نیست و هزینه می‌سازد.
3. دو تیم جدا بدون قرارداد پایدار روی هم پا می‌گذارند.
4. خرابی یک قابلیت غیرحیاتی کل واحد را پایین می‌آورد و جداسازی ارزش دارد.

نشانهٔ ضعیف: «در رزومه میکروسرویس نداریم» یا «فلان شرکت بزرگ این کار را کرد». شرکت بزرگ درد و پرسنل متفاوتی دارد.

پیش‌نیازهایی که قبل از توزیع باید داشته باشید

• CI/CD قابل تکرار (مقالهٔ ۱۱۲).
• لاگ و ردیابی و مانیتورینگ (۱۱۳، ۱۱۴).
• قرارداد API و نسخه‌بندی.
• فرهنگ مالکیت سرویس و on-call.

بدون این‌ها، میکروسرویس فقط مونولیت توزیع‌شده با latency بیشتر است.

جمع‌بندی

مونولیت پیش‌فرض درست برای بیشتر محصول‌های در حال کشف دامنه است — اگر ماژولار بماند. میکروسرویس وقتی پیچیدگی سازمانی و فنی از Premiumش بیشتر شد ارزش پیدا می‌کند. با Fowler بخوانید: اول سادگی قابل‌نگهداری، بعد توزیع آگاهانه.

منابع و مراجع

• Martin Fowler — Monolith First: https://martinfowler.com/bliki/MonolithFirst.html
• Martin Fowler — Microservice Premium: https://martinfowler.com/bliki/MicroservicePremium.html
• Martin Fowler — Microservices Guide: https://martinfowler.com/microservices/
• Martin Fowler — Microservice Trade-Offs: https://martinfowler.com/articles/microservice-trade-offs.html

اگر امروز مرزها را روی کاغذ نمی‌توانید بکشید، سرویس جدا deploy نکنید؛ ماژول داخل مونولیت بسازید.