بازگشت به کتابخانهکتابخانه5.1Monolith تا Microservices
طراحی سیستم نرم‌افزاریSYSTEM DESIGNاز صفر تا تسلط
v1.0.0
01مبانی و تصویر بزرگ
02Scalability و ظرفیت
03لایه داده
04Cache، Queue و جریان
05معماری نرم‌افزار
06قابلیت اطمینان و عملیات
07متد طراحی
08Case Study های واقعی
09سیستم‌های توزیع‌شده عمیق
10مهندسی تولید: داده، امنیت و کارایی
11تمرین پیشرفته و کیس‌استادی‌های مکمل
12زیر کاپوت دیتابیس و معماری داده
13وب بلادرنگ و پروتکل‌های مدرن
14سیستم‌های توزیع‌شده پیشرفته
15SaaS ،SRE ،امنیت و شبکه پیشرفته
16طراحی سیستم در عصر AI
17Case Study های تکمیلی
LESSON 5.1فصل ۵معماری نرم‌افزار

Monolith تا Microservices

  • ~۱۱ دقیقه
  • ۴ پرسش
  • متن را انتخاب کن تا هایلایت شود

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

وقتی رستوران معروف شد، سه تیم جدا می‌خواهند مستقل کار کنند: یکی منو را عوض کند بدون اینکه صندوق بخوابد، یکی آشپزخانه را بزرگ کند بدون دست زدن به حسابداری. اگر هنوز همه در یک آشپزخانه باشند، هر تغییر کوچک کل سالن را معطل می‌کند. این‌جا وسوسه می‌شوی دیوار بکشی. اسم آن تکه‌های مستقل را Microservices می‌گذارند. برخلاف مُد، جواب پیش‌فرض هنوز همان آشپزخانه یک‌تکهٔ خوش‌ساخت است.

یک آشپزخانه که همه کارها را با هم انجام می‌دهد
آشپز، صندوق، شست‌وشو و پیک در یک اتاق. همه همدیگر را می‌بینند. Monolith یعنی همین ساختمان یک‌تکه — تا وقتی مرز تیم‌ها از دیوار آشپزخانه بزرگ‌تر نشده، دیوار نکش.

دو مدل، دو شغل

هر دو غذا می‌دهند. فرق‌شان در این است که تغییر، مقیاس و خرابی چقدر به هم سرایت می‌کند. اگر قاطی‌شان کنی، یا برای یک تیم شش‌نفره هزینهٔ یک فرودگاه می‌سازی، یا یک ساختمان را آن‌قدر بزرگ می‌کنی که کسی جرئت Deploy ندارد.

MonolithMicroservices
استقراریک واحد؛ یک Deploy کل رستوران را عوض می‌کندهر ایستگاه جدا بالا می‌آید؛ نیازمند اتوماسیون جدی
تراکنشیک دفتر، یک تراکنش — راحتچند دفتر جدا — سخت؛ باید Saga بنویسی
مقیاسکل ساختمان با هم بزرگ می‌شودهمان ایستگاهی را بزرگ می‌کنی که صف بسته
تیم‌هابا رشد تیم، همه روی یک میز کد می‌زنندهر تیم مالک ایستگاه خودش است و جدا Deploy می‌کند
دیباگیک stack trace، یک جاردپا بین چند ایستگاه؛ بدون Tracing گم می‌شوی

یک پله وسط، قبل از قیچی

لازم نیست روز اول دیوار بکشی. می‌توانی داخل همان ساختمان، ایستگاه‌ها را با خط‌کشی مشخص کنی — بدون اینکه سفارش از روی شبکه برود و بدون اینکه برای هر غذا یک پیک بین اتاق‌ها بفرستی.

Modular Monolith
یک واحد استقرار، ولی داخلش ماژول‌هایی با مرز سفت. شغلش این است که مرز را تمرین کنی، بی‌آنکه هزینه شبکه بدهی. بهترین نقطه شروع.
Conway
معماری آینهٔ ساختار حرف زدن سازمان است. شغل قانون Conway این است که یادت بدهد تیم‌بندی خودش یک تصمیم معماری است — سه تیم مستقل، سه تکه مستقل می‌سازند.

کی دیوار می‌کشی؟

دیوار را وقتی درد واقعی دیدی، نه وقتی مقاله خواندی. سه سیگنال کافی است؛ بقیه معمولاً بهانه است.

  • سیگنال واقعی: یک تغییر کوچک، Deploy کل شرکت را معطل می‌کند؛ تیم‌ها روی سر هم کد می‌زنند؛ یک بخش مقیاس یا تکنولوژی کاملاً متفاوت می‌خواهد — مثلاً جستجو.
  • راه درست: Strangler Fig. سرویس را یکی‌یکی از کنار Monolith بیرون می‌کشی و ترافیک را آرام منتقل می‌کنی. درخت انجیر سرخ‌پوستی تنهٔ میزبان را خفه می‌کند؛ تو هم همان کار را با کد قدیمی می‌کنی — نه بازنویسی بزرگ.
  • اشتباه مرگبار: Distributed Monolith. روی کاغذ چند سرویس داری، ولی همدیگر را sync صدا می‌زنند و باید با هم Deploy شوند. همه دردهای هر دو دنیا، هیچ مزیتی.

به زبان ساده

Monolith یعنی یک واحد استقرار؛ Microservices استقلال مقیاس و تیم می‌دهد — به قیمت شبکه و تراکنش توزیع‌شده. پیش‌فرض Modular Monolith است.

مثال واقعی

رستوران کوچک یک آشپزخانه دارد. وقتی سه تیم بخواهند مستقل کار کنند دیوار می‌کشی؛ ولی روز اول دیوار نکش. اول خط‌کشی داخل همان آشپزخانه.

دانش‌سنجی

آزمون درس

۴ Q
01
مزیت واقعی Microservices که Monolith ندارد چیست؟
02
Distributed Monolith چیست؟
03
Strangler Fig یعنی چه؟
04
طبق قانون Conway، سازمانی با ۳ تیم کاملاً مستقل به کجا میل می‌کند؟