Microservices چیست؟

Microservices یکی از بیشترین بدفهمی‌ها را در دنیای معماری نرم‌افزار دارد.
برای بعضی‌ها:

• Microservices یعنی «خیلی مدرن»

• برای بعضی یعنی «Kubernetes + Docker»

• برای بعضی یعنی «هر API یک سرویس»

اما واقعیت این است که بیش از ۶۰٪ پروژه‌هایی که با نام Microservices شروع می‌شوند، یا شکست می‌خورند یا به Distributed Monolith تبدیل می‌شوند.

دلیل اصلی؟
تعریف اشتباه Microservices.

در این مقاله قرار نیست Microservices را تبلیغ کنیم؛ قرار است دقیق، فنی و بدون اغراق آن را تعریف کنیم.

Microservices چیست؟

Microservices یک سبک معماری نرم‌افزار است که در آن:

سیستم به مجموعه‌ای از سرویس‌های مستقل تقسیم می‌شود
که هر سرویس مسئول پیاده‌سازی یک قابلیت مشخص از کسب‌وکار (Business Capability) است
و می‌تواند به‌صورت مستقل توسعه، تست، دیپلوی و مقیاس‌دهی شود.

این تعریف چند نکته‌ی بسیار مهم دارد که معمولاً نادیده گرفته می‌شوند:

1. تمرکز روی Business Capability

Microservice بر اساس نیاز بیزینس شکل می‌گیرد، نه بر اساس:

• Entity

• Table

• Controller

• API

مثلاً:

• «پرداخت»

• «ثبت سفارش»

• «مدیریت موجودی»

• «احراز هویت کاربر»

نه:

• PaymentController

• OrderTable

• UserAPI

2. استقلال واقعی، نه ظاهری

استقلال یعنی:

• وابستگی مستقیم به دیتابیس سرویس دیگر ندارد

• بدون دیپلوی بقیه سرویس‌ها می‌تواند تغییر کند

• خرابی آن، کل سیستم را Down نمی‌کند

اگر سرویس‌هایت بدون هم زنده نیستند، Microservice نیستند.

3. ارتباط از طریق شبکه

در Microservices:

• فراخوانی‌ها Local Method Call نیست

• همه چیز از طریق Network Call انجام می‌شود

• Latency، Timeout، Retry و Failure بخشی از واقعیت سیستم هستند

به همین دلیل:

Microservices ذاتاً پیچیده‌تر از Monolith است.

Microservices چه چیزی نیست؟

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

Microservices مخالف API زیاد

داشتن API زیاد هیچ ربطی به Microservices ندارد.

اگر:

• همه APIها در یک Repository هستند

• همه با هم Build می‌شوند

• همه به یک دیتابیس وصل‌اند

• یک تغییر کوچک نیاز به دیپلوی کل سیستم دارد

این Monolith است، حتی اگر اسمش Microservices باشد.

Microservices مخالف REST

REST فقط یک روش ارتباط است، نه تعریف معماری.

در دنیای واقعی Microservices:

• بعضی سرویس‌ها REST دارند

• بعضی فقط Event تولید می‌کنند

• بعضی فقط Message مصرف می‌کنند

• بعضی اصلاً API عمومی ندارند

Microservices مخالف Kubernetes

Kubernetes یک ابزار Orchestration است.

• Microservices بدون Kubernetes هم ممکن است

• Kubernetes بدون Microservices هم بسیار رایج است

ابزار ≠ معماری

تفاوت عمیق Microservices و Monolith

Monolith چگونه فکر می‌کند؟

• یک سیستم

• یک تیم

• یک دیتابیس

• یک دیپلوی

تغییر کوچک = ریسک بزرگ

Microservices چگونه فکر می‌کند؟

• چند سیستم کوچک

• تیم‌های مستقل

• دیتابیس‌های مستقل

• دیپلوی مستقل

تغییر کوچک = محدوده‌ی کنترل‌شده

اما با یک واقعیت مهم:

Microservices مشکل طراحی بد را حل نمی‌کند فقط آن را پخش می‌کند.

مثال واقعی: سیستم فروش آنلاین

فرض کن یک فروشگاه آنلاین داریم با این نیازها:

• کاربران ثبت‌نام می‌کنند

• محصولات را می‌بینند

• سفارش ثبت می‌کنند

• پرداخت انجام می‌دهند

معماری Monolith

در Monolith:

• همه ماژول‌ها داخل یک اپلیکیشن هستند

• Order مستقیم Payment را صدا می‌زند

• Product موجودی را Sync آپدیت می‌کند

• همه چیز به یک دیتابیس وصل است

مشکل کجاست؟

• تغییر در Payment باعث ریسک کل سیستم

• مقیاس Order باعث مقیاس کل سیستم

• باگ در Payment باعث Down شدن فروش

معماری Microservices

در Microservices:

• Order Service

  • فقط مسئول ثبت و مدیریت سفارش

• Payment Service

  • فقط مسئول پرداخت

• Product Service

  • فقط مسئول موجودی و قیمت

• User Service

  • فقط اطلاعات کاربر

ارتباط:

• Order یک Event ثبت می‌کند

• Payment آن را مصرف می‌کند

• بعد از پرداخت موفق، Event منتشر می‌شود

• Order وضعیت را به Paid تغییر می‌دهد

هیچ سرویس:

• دیتابیس دیگری را نمی‌بیند

• فرض نمی‌کند سرویس دیگر همیشه سالم است

Microservice ≠ REST API

فرض کن Payment Service:

• API عمومی ندارد

• فقط Event OrderCreated را گوش می‌دهد

• بعد از پرداخت Event PaymentCompleted منتشر می‌کند

این:

• کاملاً Microservice است

• حتی بدون REST

چرا تعریف درست Microservices حیاتی است؟

چون انتخاب اشتباه:

• هزینه زیرساخت را چند برابر می‌کند

• نیاز به DevOps قوی دارد

• Debug را سخت می‌کند

• نیاز به Monitoring حرفه‌ای دارد

Microservices برای:

• تیم بالغ

• محصول در حال رشد

• نیاز واقعی به Scale

• پیچیدگی بیزینس بالا

طراحی شده است.

جمع‌بندی نهایی

• Microservices یک سبک معماری بالغ است

• مناسب همه پروژه‌ها نیست

• پیچیدگی را حذف نمی‌کند، مدیریت می‌کند

• بدون نیاز واقعی، خطرناک است

و دقیقاً به همین دلیل، در مقاله بعدی بررسی می‌کنیم:

چه زمانی باید Microservices را انتخاب کنیم و چه زمانی نه؟