مقایسه معماری Monolithic و Microservices؛ بررسی کامل مزایا، معایب، تفاوت‌ها و زمان مناسب استفاده

معماری نرم‌افزار یکی از مهم‌ترین تصمیماتی است که هر تیم توسعه در ابتدای پروژه باید بگیرد. انتخاب بین معماری Monolithic (مونولیت) و Microservices (میکروسرویس) می‌تواند سرنوشت پروژه را برای سال‌ها تعیین کند. این تصمیم صرفاً یک انتخاب فنی نیست؛ بلکه تأثیر مستقیمی بر سرعت توسعه، هزینه‌های زیرساخت، مقیاس‌پذیری و حتی ساختار تیم دارد.

در این مقاله جامع، به بررسی عمیق هر دو معماری می‌پردازیم. از تاریخچه و نحوه کار گرفته تا مزایا، معایب، الگوهای طراحی، ابزارهای مرتبط و نمونه‌های واقعی تولید. این مقاله برای مهندسان Backend، توسعه‌دهندگان Django، مهندسان DevOps، معماران نرم‌افزار و دانشجویان دانشگاه نوشته شده است.

اگر تا به حال سوال کرده‌اید که آیا پروژه من به میکروسرویس نیاز دارد؟ یا چه زمانی باید از مونولیت به میکروسرویس مهاجرت کنم؟، این مقاله دقیقاً همان چیزی است که نیاز دارید.

---

فهرست مطالب

1. معماری نرم‌افزار چیست؟
2. معماری Monolithic (مونولیت) چیست؟
3. تاریخچه معماری مونولیت
4. نحوه عملکرد معماری مونولیت
5. مزایای معماری مونولیت
6. معایب معماری مونولیت
7. نمونه واقعی Django مونولیت
8. ساختار پوشه‌ها
9. فرآیند استقرار
10. استراتژی مقیاس‌پذیری
11. معماری Microservices (میکروسرویس) چیست؟
12. تاریخچه میکروسرویس
13. نحوه عملکرد میکروسرویس
14. ارتباط بین سرویس‌ها
15. مزایای میکروسرویس
16. معایب میکروسرویس
17. Database per Service
18. تراکنش‌های توزیع‌شده و الگوی Saga
19. معماری Event-Driven
20. API Gateway
21. Service Discovery
22. کانتینرسازی با Docker
23. ارکستراسیون کانتینر با Kubernetes
24. Logging، Monitoring و Tracing
25. احراز هویت: JWT، OAuth2، OpenID Connect
26. چالش‌های امنیتی
27. CI/CD در میکروسرویس
28. استراتژی‌های استقرار
29. نمونه‌های واقعی تولید
30. جدول مقایسه جامع
31. کی مونولیت انتخاب کنیم؟
32. کی میکروسرویس انتخاب کنیم؟
33. اشتباهات رایج
34. استراتژی مهاجرت
35. نمونه Django از مونولیت تا میکروسرویس
36. سوالات متداول
37. نتیجه‌گیری

---

۱. معماری نرم‌افزار چیست؟

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

به بیان ساده‌تر، معماری نرم‌افزار پاسخ به این سوالات است:

• چه اجزایی سیستم را تشکیل می‌دهند؟
• این اجزا چگونه با هم ارتباط برقرار می‌کنند؟
• کجا داده‌ها ذخیره و پردازش می‌شوند؟
• چگونه سیستم در برابر خطاها مقاومت می‌کند؟
• چگونه سیستم مقیاس‌پذیر می‌شود؟

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

دو پارادایم اصلی که در معماری Backend مدرن با آن‌ها مواجه هستیم Monolithic و Microservices هستند. این دو رویکرد مکمل نیستند و هر کدام برای سناریوهای خاصی مناسب‌ترند.

---

۲. معماری Monolithic (مونولیت) چیست؟

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

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

تقریباً تمام پروژه‌هایی که امروز به عنوان "اپلیکیشن وب" می‌شناسیم — از وب‌سایت‌های ساده گرفته تا سیستم‌های پیچیده سازمانی — در ابتدا به صورت مونولیت شروع شده‌اند. حتی شرکت‌هایی مانند Netflix و Amazon که امروز از میکروسرویس استفاده می‌کنند، روزی با یک مونولیت شروع کردند.

مزیت اصلی مونولیت سادگی است. یک توسعه‌دهنده می‌تواند کل کد را در ذهن خود نگه دارد، تغییرات را به راحتی اعمال کند و سیستم را به سرعت مستقر کند. اما این سادگی وقتی سیستم بزرگ‌تر می‌شود، به یک محدودیت جدی تبدیل می‌شود.

---

۳. تاریخچه معماری مونولیت

تاریخ معماری مونولیت به دهه ۱۹۶۰ میلادی بازمی‌گردد، زمانی که اولین سیستم‌های کامپیوتری بزرگ توسعه داده شدند. در آن دوران، تمام نرم‌افزار روی یک ماشین واحد اجرا می‌شد و مفهوم جدا کردن اجزا به شکل امروزی وجود نداشت.

با ظهور زبان‌های برنامه‌نویسی سطح بالا مانند COBOL و Fortran، اپلیکیشن‌های مونولیت پیچیده‌تر شدند. اما تا دهه ۱۹۹۰ و معرفی وب، معماری مونولیت شکل مدرن خود را پیدا کرد. اپلیکیشن‌های وب اولیه مانند CGI و سپس Java EE و PHP همگی رویکرد مونولیت را دنبال می‌کردند.

دهه ۲۰۰۰ با ظهور Ruby on Rails و Django نقطه عطفی در تاریخ مونولیت بود. این فریم‌ورک‌ها نشان دادند که یک اپلیکیشن مونولیت می‌تواند هم ساده باشد و هم قدرتمند. فلسفه "Convention over Configuration" باعث شد توسعه‌دهندگان بتوانند با سرعت بالایی اپلیکیشن بسازند.

امروزه، با وجود محبوبیت میکروسرویس، بسیاری از پروژه‌ها هنوز با معماری مونولیت شروع می‌شوند — و این کاملاً صحیح است. حتی تیم‌هایی که در نهایت به میکروسرویس مهاجرت می‌کنند، معمولاً از یک مونولیت شروع کرده‌اند.

---

۴. نحوه عملکرد معماری مونولیت

در یک اپلیکیشن مونولیت، تمام لایه‌های سیستم در یک پروژه واحد قرار دارند:

┌─────────────────────────────────────────────┐
│              Application Layer              │
│  ┌───────────────────────────────────────┐  │
│  │           Presentation (UI)           │  │
│  ├───────────────────────────────────────┤  │
│  │       Business Logic Layer            │  │
│  │  ┌─────────┬──────────┬────────────┐  │  │
│  │  │  Users  │  Orders  │  Payments  │  │  │
│  │  └─────────┴──────────┴────────────┘  │  │
│  ├───────────────────────────────────────┤  │
│  │       Data Access Layer               │  │
│  └───────────────────────────────────────┘  │
│                   │                         │
│                   ▼                         │
│          ┌──────────────┐                   │
│          │   Database   │                   │
│          └──────────────┘                   │
└─────────────────────────────────────────────┘

وقتی یک درخواست HTTP از کلاینت (مرورگر یا موبایل) به سرور می‌رسد، فرآیند زیر اتفاق می‌افتد:

1. Router: درخواست به مسیر مناسب هدایت می‌شود (مثلاً /api/orders/)
2. View/Controller: درخواست پردازش شده و منطق کسب‌وکار اعمال می‌شود
3. Model: داده‌ها از پایگاه داده خوانده یا نوشته می‌شوند
4. Response: پاسخ به صورت JSON یا HTML به کلاینت برگردانده می‌شود

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

---

۵. مزایای معماری مونولیت

مزیت	توضیح
سادگی توسعه	شروع کار بسیار ساده است. یک پروژه، یک کد بیس، یک دیتابیس. نیازی به مدیریت ابزارهای پیچیده نیست.
سرعت توسعه اولیه	قابلیت MVP در کوتاه‌ترین زمان. تیم می‌تواند به سرعت ایده‌ها را پیاده‌سازی و تست کند.
سادگی استقرار	فقط یک اپلیکیشن را مستقر کنید. نیازی به مدیریت ده‌ها سرویس نیست.
اشکال‌زدایی آسان (Debugging)	هنگام بروز مشکل، لاگ‌ها و کدها در یک مکان قرار دارند؛ بنابراین ردیابی و رفع خطا بسیار ساده‌تر است.
تست یکپارچه	تست‌های end-to-end به راحتی اجرا می‌شوند. نیازی به mock کردن سرویس‌های خارجی نیست.
هزینه زیرساخت پایین	فقط به یک سرور و یک دیتابیس نیاز دارید. هزینه اولیه بسیار کم است.
TRANSACTIONS ساده	تراکنش‌های دیتابیسی ساده هستند. نیازی به الگوهای پیچیده مانند Saga نیست.
یادگیری آسان	منحنی یادگیری برای توسعه‌دهندگان جدید بسیار کمتر است.

توضیح مفصل مزایا

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

سرعت توسعه اولیه نیز بسیار مهم است. در مراحل اولیه پروژه، مهم‌ترین چیز ایده در بازار است. معماری مونولیت به شما اجازه می‌دهد به سرعت MVP (Minimum Viable Product) بسازید و بازخورد کاربران را جمع‌آوری کنید — بدون اینکه نگران پیچیدگی‌های زیرساخت باشید.

هزینه زیرساخت پایین یک مزیت عملی است. اجرای یک مونولیت ساده می‌تواند روی یک سرور ارزان‌قیمت VPS انجام شود. در مقایسه، یک سیستم میکروسرویس ممکن است به ده‌ها کانتینر، سرویس ارکستراسیون، و زیرساخت‌های اضافی نیاز داشته باشد.

---

۶. معایب معماری مونولیت

عیب	توضیح
مقیاس‌پذیری محدود	نمی‌توان بخش‌های خاصی را جداگانه مقیاس داد. کل اپلیکیشن باید scale شود.
استقرار خطرناک	تغییر در یک بخش ممکن است بخش‌های دیگر را خراب کند. ریسک deploy بالاست.
point single failure	اگر یک بخش crash کند، کل اپلیکیشن از کار می‌افتد.
تداخل تیم‌ها	تیم‌های مختلف مجبورند روی یک کد بیس کار کنند. تداخل و تعارض اجتناب‌ناپذیر است.
فناوری یکپارچه	مجبورید از یک stack فناوری واحد استفاده کنید. امکان استفاده از بهترین ابزار برای هر مشکل وجود ندارد.
زمان build طولانی	با بزرگ‌تر شدن پروژه، زمان کامپایل و تست به شدت افزایش می‌یابد.
پیچیدگی کد	وقتی پروژه بزرگ می‌شود، کد بیس غیرقابل مدیریت می‌شود. Dependencies بین ماژول‌ها زیاد می‌شوند.
محدودیت مقیاس تیم	تیم‌های بزرگ نمی‌توانند به صورت موازی روی یک مونولیت کار کنند.

توضیح مفصل معایب

مشکل مقیاس‌پذیری مهم‌ترین عیب مونولیت است. فرض کنید اپلیکیشن شما سه بخش دارد: کاتالوگ محصولات، سبد خرید، و پردازش پرداخت. اگر بخش پرداخت بار زیادی تحمل کند (مثلاً در ر.Black Friday)، شما مجبورید کل اپلیکیشن را scale کنید — حتی اگر بخش کاتالوگ اصلاً بار اضافی نداشته باشد.

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

point single failure یک مشکل حیاتی است. در معماری مونولیت، اگر یک Thread Pool تمام شود یا حافظه بخشی از اپلیکیشن تمام شود، کل سیستم ممکن است crash کند. این در مقایسه با میکروسرویس که در آن خرابی یک سرویس بقیه سیستم را تحت تأثیر قرار نمی‌دهد، بسیار نگران‌کننده است.

---

۷. نمونه واقعی Django مونولیت

فرض کنید در حال توسعه یک پلتفرم فروشگاه آنلاین با Django هستید. در معماری مونولیت، کل سیستم در یک پروژه Django واحد قرار می‌گیرد:

# myproject/settings.py
INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    
    # تمام اپلیکیشن‌ها در یک پروژه واحد
    'apps.accounts',      # مدیریت کاربران
    'apps.products',      # کاتالوگ محصولات
    'apps.orders',        # مدیریت سفارشات
    'apps.payments',      # پردازش پرداخت
    'apps.inventory',     # مدیریت انبار
    'apps.notifications', # سیستم اعلان‌ها
    'apps.reviews',       # نظرات و امتیازات
    'apps.analytics',     # تحلیل و گزارش‌ها
]

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql',
        'NAME': 'ecommerce_db',
        'USER': 'admin',
        'PASSWORD': 'secure_password',
        'HOST': 'localhost',
        'PORT': '5432',
    }
}

# apps/orders/views.py
from django.shortcuts import render, redirect
from django.contrib.auth.decorators import login_required
from django.contrib import messages
from .models import Order, OrderItem
from apps.products.models import Product
from apps.payments.services import PaymentService
from apps.inventory.services import InventoryService
from apps.notifications.services import NotificationService

@login_required
def create_order(request):
    """ایجاد سفارش جدید"""
    if request.method == 'POST':
        cart = request.session.get('cart', {})
        
        # بررسی موجودی محصولات
        inventory_service = InventoryService()
        for product_id, quantity in cart.items():
            product = Product.objects.get(id=product_id)
            if not inventory_service.check_stock(product, quantity):
                messages.error(request, f'محصول {product.name} موجود نیست')
                return redirect('cart')
        
        # ایجاد سفارش
        order = Order.objects.create(
            user=request.user,
            total_amount=sum(
                Product.objects.get(id=pid).price * qty 
                for pid, qty in cart.items()
            )
        )
        
        # اضافه کردن آیتم‌ها
        for product_id, quantity in cart.items():
            product = Product.objects.get(id=product_id)
            OrderItem.objects.create(
                order=order,
                product=product,
                quantity=quantity,
                price=product.price
            )
        
        # پردازش پرداخت
        payment_service = PaymentService()
        payment_result = payment_service.process_payment(
            order=order,
            payment_method=request.POST.get('payment_method')
        )
        
        if payment_result.success:
            # کاهش موجودی انبار
            inventory_service.reduce_stock(order)
            
            # ارسال اعلان
            NotificationService.send_order_confirmation(order)
            
            # پاک کردن سبد خرید
            request.session['cart'] = {}
            
            messages.success(request, 'سفارش با موفقیت ثبت شد')
            return redirect('order_detail', order_id=order.id)
        else:
            order.delete()
            messages.error(request, 'خطا در پردازش پرداخت')
    
    return redirect('cart')

همانطور که می‌بینید، یک ویوی ساده Django ممکن است با ماژول‌های مختلفی ارتباط داشته باشد: محصولات، سفارشات، پرداخت، انبار، و اعلان‌ها. در یک مونولیت، تمام این ارتباطات به صورت مستقیم (function calls) انجام می‌شوند — که هم ساده است و هم سریع.

---

۸. ساختار پوشه‌ها

ساختار پوشه‌های یک اپلیکیشن Django مونولیت معمولاً به این شکل است:

myproject/
├── manage.py
├── requirements.txt
├── Dockerfile
├── docker-compose.yml
├── nginx/
│   └── nginx.conf
├── myproject/
│   ├── __init__.py
│   ├── settings.py
│   ├── urls.py
│   └── wsgi.py
├── apps/
│   ├── __init__.py
│   ├── accounts/
│   │   ├── __init__.py
│   │   ├── models.py
│   │   ├── views.py
│   │   ├── urls.py
│   │   ├── serializers.py
│   │   ├── admin.py
│   │   ├── tests.py
│   │   └── migrations/
│   ├── products/
│   │   ├── __init__.py
│   │   ├── models.py
│   │   ├── views.py
│   │   ├── urls.py
│   │   ├── serializers.py
│   │   ├── admin.py
│   │   ├── tests.py
│   │   └── migrations/
│   ├── orders/
│   │   ├── __init__.py
│   │   ├── models.py
│   │   ├── views.py
│   │   ├── urls.py
│   │   ├── services.py
│   │   ├── admin.py
│   │   ├── tests.py
│   │   └── migrations/
│   ├── payments/
│   │   ├── __init__.py
│   │   ├── models.py
│   │   ├── views.py
│   │   ├── services.py
│   │   ├── gateways/
│   │   │   ├── stripe.py
│   │   │   └── paypal.py
│   │   ├── admin.py
│   │   └── tests.py
│   ├── inventory/
│   │   ├── __init__.py
│   │   ├── models.py
│   │   ├── services.py
│   │   └── tests.py
│   └── notifications/
│       ├── __init__.py
│       ├── models.py
│       ├── services.py
│       ├── email_service.py
│       └── sms_service.py
├── templates/
│   ├── base.html
│   ├── accounts/
│   ├── products/
│   ├── orders/
│   └── payments/
├── static/
│   ├── css/
│   ├── js/
│   └── images/
├── media/
├── locale/
│   └── fa/
└── tests/
    ├── test_accounts.py
    ├── test_products.py
    ├── test_orders.py
    └── test_payments.py

این ساختار تمیز و منظم است. هر اپلیکیشن در پوشه خودش قرار دارد، اما همه در یک پروژه واحد ادغام شده‌اند. مزیت این ساختار این است که توسعه‌دهندگان می‌توانند به راحتی بین ماژول‌ها حرکت کنند و کل سیستم را درک کنند.

---

۹. فرآیند استقرار

استقرار یک مونولیت Django نسبتاً ساده است. در اینجا یک مثال با Docker و Docker Compose می‌بینید:

# Dockerfile
FROM python:3.11-slim

ENV PYTHONDONTWRITEBYTECODE=1
ENV PYTHONUNBUFFERED=1

WORKDIR /app

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY . .
RUN python manage.py collectstatic --noinput

EXPOSE 8000

CMD ["gunicorn", "myproject.wsgi:application", \
     "--bind", "0.0.0.0:8000", \
     "--workers", "4", \
     "--threads", "2"]

# docker-compose.yml
version: '3.8'

services:
  web:
    build: .
    ports:
      - "8000:8000"
    environment:
      - DEBUG=False
      - DATABASE_URL=postgres://admin:password@db:5432/ecommerce_db
      - REDIS_URL=redis://redis:6379/0
      - SECRET_KEY=your-secret-key
    depends_on:
      - db
      - redis
    restart: always

  db:
    image: postgres:15
    environment:
      POSTGRES_DB: ecommerce_db
      POSTGRES_USER: admin
      POSTGRES_PASSWORD: password
    volumes:
      - postgres_data:/var/lib/postgresql/data
    ports:
      - "5432:5432"

  redis:
    image: redis:7-alpine
    ports:
      - "6379:6379"

  nginx:
    image: nginx:alpine
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx/nginx.conf:/etc/nginx/nginx.conf
      - ./static:/app/static
      - ./media:/app/media
    depends_on:
      - web

volumes:
  postgres_data:

# nginx/nginx.conf
events {
    worker_connections 1024;
}

http {
    upstream django {
        server web:8000;
    }

    server {
        listen 80;
        server_name example.com;

        location /static/ {
            alias /app/static/;
        }

        location /media/ {
            alias /app/media/;
        }

        location / {
            proxy_pass http://django;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
        }
    }
}

در این مثال، ما فقط چهار سرویس داریم: اپلیکیشن Django، PostgreSQL، Redis و Nginx. این سادگی استقرار یکی از بزرگ‌ترین مزایای مونولیت است.

---

۱۰. استراتژی مقیاس‌پذیری

مقیاس‌پذیری در معماری مونولیت به دو شکل انجام می‌شود:

مقیاس عمودی (Vertical Scaling)

ساده‌ترین روش افزایش منابع سرور است: RAM بیشتر، CPU قوی‌تر، دیسک سریع‌تر. این روش برای پروژه‌های کوچک تا متوسط کافی است.

مقیاس افقی (Horizontal Scaling)

در این روش، چند نمونه از اپلیکیشن پشت یک load balancer قرار می‌گیرند:

┌─────────────┐
│    Client    │
└──────┬──────┘
       │
       ▼
┌─────────────┐
│ Load Balancer│
└──────┬──────┘
       │
  ┌────┴────┐
  ▼         ▼
┌─────┐  ┌─────┐
│App 1│  │App 2│
└──┬──┘  └──┬──┘
   │        │
   ▼        ▼
┌──────────────┐
│   Database   │
│  (Master/    │
│   Replica)   │
└──────────────┘

مشکل اصلی مقیاس افقی مونولیت این است که تمام اجزا با هم مقیاس می‌یابند. اگر فقط بخش پرداخت نیاز به مقیاس دارد، مجبورید کل اپلیکیشن را تکثیر کنید. این از نظر منابع بهینه نیست.

---

۱۱. معماری Microservices (میکروسرویس) چیست؟

معماری میکروسرویس (Microservices Architecture) رویکردی است که در آن یک اپلیکیشن بزرگ به مجموعه‌ای از سرویس‌های کوچک، مستقل و قابل استقرار تقسیم می‌شود. هر سرویس یک مسئولیت مشخص دارد، به صورت مستقل توسعه و استقرار می‌یابد، و معمولاً API ساده‌ای (معمولاً REST یا gRPC) برای ارتباط با سایر سرویس‌ها ارائه می‌دهد.

مفهوم میکروسرویس اولین بار در حدود سال ۲۰۱۱ در کنفرانس‌هایی مانند QCon مطرح شد، اما تا سال ۲۰۱۴-۲۰۱۵ به صورت گسترده پذیرفته نشد. مقاله معروف Sam Newman با عنوان "Building Microservices" و تجربه شرکت‌هایی مانند Netflix، Amazon و Spotify در پذیرش این معماری، نقش بسیار مهمی در محبوبیت آن داشت.

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

• مسئولیت مشخصی دارد (Single Responsibility)
• می‌تواند به زبان و فریم‌ورک متفاوتی نوشته شود
• پایگاه داده مستقل خود را دارد
• به صورت مستقل مستقر و scale می‌شود
• توسط یک تیم کوچک توسعه و نگهداری می‌شود

---

۱۲. تاریخچه میکروسرویس

اگرچه مفهوم میکروسرویس به عنوان یک اصطلاح نسبتاً جدید است (حدود ۲۰۱۱)، اما ایده‌های پشت آن ریشه در تاریخچه طولانی دارند:

• دهه ۱۹۹۰: مفهوم SOA (Service-Oriented Architecture) مطرح شد. SOA ایده تقسیم سیستم به سرویس‌های مستقل را معرفی کرد، اما اجرای آن معمولاً پیچیده و سنگین بود (فناوری‌هایی مانند SOAP و ESB).
• دهه ۲۰۰۰: ظهور وب‌سرویس‌های RESTful و HTTP ساده، پایه فنی میکروسرویس را فراهم کرد.
• ۲۰۰۶: Amazon تصمیم گرفت سیستم مونولیت خود را به سرویس‌های مستقل تقسیم کند. این یکی از اولین و بزرگ‌ترین مهاجرت‌ها از مونولیت به میکروسرویس بود.
• ۲۰۰۹: Netflix شروع به بازنویسی سیستم مونولیت خود با معماری میکروسرویس کرد.
• ۲۰۱۱: اصطلاح "Microservices" برای اولین بار در کنفرانس QCon استفاده شد.
• ۲۰۱۴: انتشار کتاب "Building Microservices" توسط Sam Newman که به یکی از مرجع‌های اصلی این حوزه تبدیل شد.
• ۲۰۱۵-امروز: ابزارهایی مانند Docker و Kubernetes محبوبیت میکروسرویس را به شدت افزایش دادند.

---

۱۳. نحوه عملکرد میکروسرویس

در یک معماری میکروسرویس، هر سرویس به صورت مستقل اجرا می‌شود و از طریق API با سایر سرویس‌ها ارتباط برقرار می‌کند. در اینجا یک نمودار کلی می‌بینید:

                          ┌─────────────┐
                          │   Clients   │
                          │  (Web/Mobile)│
                          └──────┬──────┘
                                 │
                                 ▼
                        ┌────────────────┐
                        │  API Gateway   │
                        └───────┬────────┘
                                │
          ┌─────────────────────┼─────────────────────┐
          │                     │                     │
          ▼                     ▼                     ▼
   ┌─────────────┐    ┌──────────────┐    ┌──────────────┐
   │   User      │    │   Product    │    │   Order      │
   │  Service    │    │   Service    │    │   Service    │
   │  (Python)   │    │   (Go)       │    │   (Java)     │
   └──────┬──────┘    └──────┬───────┘    └──────┬───────┘
          │                   │                   │
          ▼                   ▼                   ▼
   ┌─────────────┐    ┌──────────────┐    ┌──────────────┐
   │  User DB    │    │  Product DB  │    │  Order DB    │
   │ (PostgreSQL)│    │  (MongoDB)   │    │ (PostgreSQL) │
   └─────────────┘    └──────────────┘    └──────────────┘

نکات کلیدی این معماری:

• هر سرویس پایگاه داده مستقل خود را دارد
• هر سرویس می‌تواند با فناوری متفاوتی نوشته شود
• ارتباط بین سرویس‌ها از طریق API یا Message Broker انجام می‌شود
• هر سرویس به صورت مستقل scale می‌شود
• خرابی یک سرویس کل سیستم را از کار نمی‌اندازد

---

۱۴. ارتباط بین سرویس‌ها

یکی از پیچیده‌ترین جنبه‌های معماری میکروسرویس، نحوه ارتباط بین سرویس‌ها است. در اینجا، الگوهای مختلف ارتباطی را بررسی می‌کنیم.

۱۴.۱ ارتباط REST

REST (Representational State Transfer) محبوب‌ترین الگوی ارتباطی در میکروسرویس است. از HTTP به عنوان پروتکل انتقال و JSON به عنوان فرمت داده استفاده می‌کند.

# user_service/views.py
from fastapi import FastAPI, HTTPException
from pydantic import BaseModel

app = FastAPI()

class User(BaseModel):
    id: int
    name: str
    email: str

@app.get("/users/{user_id}")
async def get_user(user_id: int):
    user = await db.users.find_one({"id": user_id})
    if not user:
        raise HTTPException(status_code=404, detail="User not found")
    return user

@app.post("/users/")
async def create_user(user: User):
    result = await db.users.insert_one(user.dict())
    return {"id": result.inserted_id, "status": "created"}

مزایای REST:

• سادگی پیاده‌سازی و درک
• پشتیبانی گسترده از ابزارها و کتابخانه‌ها
• سازگاری با HTTP و استانداردهای وب
• مناسب برای CRUD operations

معایب REST:

• سرعت کمتر نسبت به gRPC
• ندانستن тип داده‌ها (.Contract-first نیست)
• Overhead اضافی HTTP

۱۴.۲ ارتباط gRPC

gRPC توسط Google توسعه داده شده و برای ارتباط بین سرویس‌ها بهینه شده است. از Protocol Buffers برای serialization و HTTP/2 برای انتقال استفاده می‌کند.

// user_service/proto/user.proto
syntax = "proto3";

service UserService {
    rpc GetUser (GetUserRequest) returns (UserResponse);
    rpc CreateUser (CreateUserRequest) returns (CreateUserResponse);
    rpc ListUsers (ListUsersRequest) returns (stream UserResponse);
}

message GetUserRequest {
    int32 user_id = 1;
}

message UserResponse {
    int32 id = 1;
    string name = 2;
    string email = 3;
    string created_at = 4;
}

message CreateUserRequest {
    string name = 1;
    string email = 2;
}

message CreateUserResponse {
    int32 id = 1;
    string status = 2;
}

message ListUsersRequest {
    int32 page = 1;
    int32 per_page = 2;
}

# order_service/client.py
import grpc
from proto import user_pb2, user_pb2_grpc

class UserServiceClient:
    def __init__(self, host="user-service:50051"):
        self.channel = grpc.insecure_channel(host)
        self.stub = user_pb2_grpc.UserServiceStub(self.channel)
    
    def get_user(self, user_id: int) -> dict:
        request = user_pb2.GetUserRequest(user_id=user_id)
        response = self.stub.GetUser(request)
        return {
            "id": response.id,
            "name": response.name,
            "email": response.email
        }
    
    def create_user(self, name: str, email: str) -> dict:
        request = user_pb2.CreateUserRequest(name=name, email=email)
        response = self.stub.CreateUser(request)
        return {"id": response.id, "status": response.status}

مزایای gRPC:

• سرعت بسیار بالا (HTTP/2 + binary serialization)
• Contract-first با استفاده از Protocol Buffers
• پشتیبانی از streaming
• تایپ امن (Type-safe)

۱۴.۳ ارتباط GraphQL

GraphQL یک زبان پرس‌وجوی API است که توسط Facebook توسعه داده شده. در معماری میکروسرویس، معمولاً به عنوان API Gateway استفاده می‌شود تا چندین سرویس backend را در یک API واحد ادغام کند.

# api_gateway/schema.py
import graphene
from graphene_django import DjangoObjectType
import httpx

class UserType(graphene.ObjectType):
    id = graphene.Int()
    name = graphene.String()
    email = graphene.String()

class OrderType(graphene.ObjectType):
    id = graphene.Int()
    total_amount = graphene.Float()
    status = graphene.String()
    user = graphene.Field(UserType)

class Query(graphene.ObjectType):
    user = graphene.Field(UserType, user_id=graphene.Int(required=True))
    order = graphene.Field(OrderType, order_id=graphene.Int(required=True))

    async def resolve_user(self, info, user_id):
        async with httpx.AsyncClient() as client:
            response = await client.get(f"http://user-service:8001/users/{user_id}")
            return UserType(**response.json())

    async def resolve_order(self, info, order_id):
        async with httpx.AsyncClient() as client:
            response = await client.get(f"http://order-service:8002/orders/{order_id}")
            order_data = response.json()
            
            # دریافت اطلاعات کاربر از User Service
            user_response = await client.get(
                f"http://user-service:8001/users/{order_data['user_id']}"
            )
            order_data['user'] = UserType(**user_response.json())
            
            return OrderType(**order_data)

schema = graphene.Schema(query=Query)

۱۴.۴ RabbitMQ

RabbitMQ یک message broker قدرتمند است که ارتباط غیرهمزمان (async) بین سرویس‌ها را ممکن می‌سازد. از الگوی publish/subscribe و point-to-point پشتیبانی می‌کند.

# order_service/producer.py
import pika
import json

class OrderEventProducer:
    def __init__(self):
        self.connection = pika.BlockingConnection(
            pika.ConnectionParameters('rabbitmq:5672')
        )
        self.channel = self.connection.channel()
        self.channel.exchange_declare(
            exchange='order_events',
            exchange_type='topic'
        )
    
    def publish_order_created(self, order_data: dict):
        self.channel.basic_publish(
            exchange='order_events',
            routing_key='order.created',
            body=json.dumps(order_data),
            properties=pika.BasicProperties(
                delivery_mode=2,  # persistent
                content_type='application/json'
            )
        )
    
    def publish_order_cancelled(self, order_data: dict):
        self.channel.basic_publish(
            exchange='order_events',
            routing_key='order.cancelled',
            body=json.dumps(order_data),
            properties=pika.BasicProperties(
                delivery_mode=2,
                content_type='application/json'
            )
        )

# inventory_service/consumer.py
import pika
import json

class InventoryEventConsumer:
    def __init__(self):
        self.connection = pika.BlockingConnection(
            pika.ConnectionParameters('rabbitmq:5672')
        )
        self.channel = self.connection.channel()
        
        # ایجاد exchange و queue
        self.channel.exchange_declare(
            exchange='order_events',
            exchange_type='topic'
        )
        self.channel.queue_declare(queue='inventory_queue', durable=True)
        self.channel.queue_bind(
            exchange='order_events',
            queue='inventory_queue',
            routing_key='order.created'
        )
    
    def start_consuming(self):
        self.channel.basic_qos(prefetch_count=1)
        self.channel.basic_consume(
            queue='inventory_queue',
            on_message_callback=self.handle_order_created
        )
        self.channel.start_consuming()
    
    def handle_order_created(self, ch, method, properties, body):
        order_data = json.loads(body)
        # کاهش موجودی انبار
        self.reduce_inventory(order_data['items'])
        ch.basic_ack(delivery_tag=method.delivery_tag)
        print(f"Inventory updated for order {order_data['order_id']}")

مزایای RabbitMQ:

• ارتباط غیرهمزمان — سرویس‌ها مستقل از یکدیگر هستند
• Queueing — درخواست‌ها در صف قرار می‌گیرند و از دست نمی‌روند
• مکانیسم‌های مختلف routing (topic, fanout, direct)
• Confirmations — تایید رسیدن پیام

۱۴.۵ Kafka

Apache Kafka یک پلتفرم انتقال داده توزیع‌شده است. برخلاف RabbitMQ که یک message broker سنتی است، Kafka یک event streaming platform است که برای حجم بالای داده طراحی شده.

# order_service/kafka_producer.py
from kafka import KafkaProducer
import json

class OrderEventProducer:
    def __init__(self):
        self.producer = KafkaProducer(
            bootstrap_servers=['kafka:9092'],
            value_serializer=lambda v: json.dumps(v).encode('utf-8'),
            key_serializer=lambda k: k.encode('utf-8') if k else None,
            acks='all',
            retries=3
        )
    
    def publish_order_created(self, order_id: str, order_data: dict):
        self.producer.send(
            topic='order-events',
            key=str(order_id),
            value={
                'event_type': 'order_created',
                'order_id': order_id,
                'data': order_data,
                'timestamp': datetime.utcnow().isoformat()
            }
        )
        self.producer.flush()
    
    def publish_order_updated(self, order_id: str, status: str):
        self.producer.send(
            topic='order-events',
            key=str(order_id),
            value={
                'event_type': 'order_updated',
                'order_id': order_id,
                'status': status,
                'timestamp': datetime.utcnow().isoformat()
            }
        )
        self.producer.flush()

# inventory_service/kafka_consumer.py
from kafka import KafkaConsumer
import json

class OrderEventConsumer:
    def __init__(self):
        self.consumer = KafkaConsumer(
            'order-events',
            bootstrap_servers=['kafka:9092'],
            group_id='inventory-service',
            auto_offset_reset='earliest',
            value_deserializer=lambda m: json.loads(m.decode('utf-8'))
        )
    
    def start_consuming(self):
        for message in self.consumer:
            event = message.value
            
            if event['event_type'] == 'order_created':
                self.handle_order_created(event)
            elif event['event_type'] == 'order_cancelled':
                self.handle_order_cancelled(event)
    
    def handle_order_created(self, event):
        order_data = event['data']
        for item in order_data['items']:
            self.reduce_stock(item['product_id'], item['quantity'])
        print(f"Stock reduced for order {event['order_id']}")

تفاوت‌های کلیدی Kafka و RabbitMQ:

ویژگی	Kafka	RabbitMQ
مدل	Event Streaming	Message Broker
ذخیره‌سازی	Persistent log	Queue (پس از مصرف حذف می‌شود)
مقیاس‌پذیری	بسیار بالا (millions msgs/sec)	بالا (hundreds of thousands)
Replay	بله — می‌توانید دوباره پیام‌ها را بخوانید	خیر — پیام پس از مصرف حذف می‌شود
الگوی مصرف	Consumer Groups	Work Queues / Pub-Sub
پیچیدگی	بالاتر	متوسط
مناسب برای	Event sourcing, data pipelines	Task queues, RPC

۱۴.۶ Redis Pub/Sub

Redis Pub/Sub ساده‌ترین راه برای ارتباط غیرهمزمان بین سرویس‌ها است. مناسب پروژه‌های کوچک و متوسط است.

# notification_service/publisher.py
import redis
import json

class NotificationPublisher:
    def __init__(self):
        self.redis = redis.Redis(host='redis', port=6379, db=0)
    
    def publish_notification(self, user_id: int, message: str):
        self.redis.publish(
            'notifications',
            json.dumps({
                'user_id': user_id,
                'message': message,
                'type': 'info'
            })
        )
    
    def publish_order_update(self, order_id: int, status: str):
        self.redis.publish(
            'order_updates',
            json.dumps({
                'order_id': order_id,
                'status': status
            })
        )

# notification_service/subscriber.py
import redis
import json

class NotificationSubscriber:
    def __init__(self):
        self.redis = redis.Redis(host='redis', port=6379, db=0)
        self.pubsub = self.redis.pubsub()
    
    def subscribe(self, channel: str):
        self.pubsub.subscribe(**{
            channel: self.handle_message
        })
        self.pubsub.run_in_thread(sleep_time=0.001)
    
    def handle_message(self, message):
        data = json.loads(message['data'])
        # ارسال اعلان به کاربر
        self.send_notification(data)

۱۴.۷ الگوی Event-Driven

در الگوی Event-Driven، سرویس‌ها به جای فراخوانی مستقیم یکدیگر، رویدادها (Events) را منتشر می‌کنند و سرویس‌های دیگر به این رویدادها واکنش نشان می‌دهند. این الگو ارتباطات بین سرویس‌ها را به شدت کاهش می‌دهد.

# order_service/events.py
from dataclasses import dataclass
from datetime import datetime
from typing import Optional

@dataclass
class OrderCreatedEvent:
    order_id: str
    user_id: int
    items: list
    total_amount: float
    timestamp: datetime = field(default_factory=datetime.utcnow)

@dataclass
class OrderCancelledEvent:
    order_id: str
    user_id: int
    reason: str
    timestamp: datetime = field(default_factory=datetime.utcnow)

class EventBus:
    def __init__(self):
        self.subscribers = {}
    
    def subscribe(self, event_type: str, handler):
        if event_type not in self.subscribers:
            self.subscribers[event_type] = []
        self.subscribers[event_type].append(handler)
    
    def publish(self, event):
        event_type = type(event).__name__
        if event_type in self.subscribers:
            for handler in self.subscribers[event_type]:
                handler(event)

---

۱۵. مزایای میکروسرویس

مزیت	توضیح
مقیاس‌پذیری مستقل	هر سرویس به صورت جداگانه scale می‌شود. فقط سرویس‌هایی که بار زیادی دارند افزایش منابع دریافت می‌کنند.
انعطاف‌پذیری فناوری	هر سرویس می‌تواند با زبان و فریم‌ورک متفاوتی نوشته شود. از بهترین ابزار برای هر مشکل استفاده کنید.
استقرار مستقل	تغییر در یک سرویس بدون تأثیر بر سایر سرویس‌ها مستقر می‌شود. CI/CD ساده‌تر و سریع‌تر.
مقاومت در برابر خطا	خرابی یک سرویس کل سیستم را از کار نمی‌اندازد. سایر سرویس‌ها به کار خود ادامه می‌دهند.
تیم‌های مستقل	هر تیم مسئولیت یک سرویس را بر عهده دارد. استقلال بیشتر و سرعت توسعه بالاتر.
نگهداری آسان‌تر	کد بیس هر سرویس کوچک و قابل مدیریت است. درک و تغییر کد آسان‌تر است.
امکان استفاده مجدد	سرویس‌ها می‌توانند توسط چندین اپلیکیشن مورد استفاده قرار گیرند.
سازگاری با تیم‌های بزرگ	تیم‌های بزرگ می‌توانند به صورت موازی و بدون تداخل کار کنند.

---

۱۶. معایب میکروسرویس

عیب	توضیح
پیچیدگی عملیاتی	مدیریت ده‌ها سرویس بسیار پیچیده‌تر از یک مونولیت است. نیاز به ابزارهای ارکستراسیون، مانیتورینگ و logging دارید.
توزیع داده	هر سرویس پایگاه داده مستقل دارد. نگهداری ثبات داده‌ها (Data Consistency) پیچیده است.
تراکنش‌های توزیع‌شده	انجام عملیاتی که چندین سرویس را در بر می‌گیرد بسیار پیچیده‌تر از یک تراکنش ساده دیتابیسی است.
اشکال‌زدایی دشوار (Debugging)	ردیابی یک درخواست از طریق چندین سرویس دشوار است. نیاز به ابزارهای distributed tracing دارید.
هزینه زیرساخت بالا	هر سرویس به منابع خود نیاز دارد. هزینه‌های سرور، دیتابیس و ابزارها به شدت افزایش می‌یابد.
تست پیچیده	تست end-to-end بسیار دشوارتر است. نیاز به mock کردن سرویس‌های وابسته دارید.
منحنی یادگیری تند	تیم باید با ابزارهای زیادی آشنا شود: Docker, Kubernetes, Service Mesh, API Gateway و غیره.
نیاز به تیم DevOps	مدیریت زیرساخت میکروسرویس نیاز به تیم DevOps ماهر و اختصاصی دارد.

---

۱۷. Database per Service

یکی از اصول بنیادین معماری میکروسرویس این است که هر سرویس پایگاه داده مستقل خود را داشته باشد. این اصل به "Database per Service" معروف است و دلایل مهمی دارد:

1. انعطاف‌پذیری: هر سرویس می‌تواند نوع دیتابیس مناسب خود را انتخاب کند. User Service ممکن است از PostgreSQL، Product Service از MongoDB، و Session Service از Redis استفاده کند.
2. استقلال: تغییر Schema در یک سرویس روی سرویس‌های دیگر تأثیر نمی‌گذارد.
3. مقیاس‌پذیری: هر دیتابیس به صورت مستقل scale می‌شود.
4. ایزولاسیون: مشکلات عملکردی یک دیتابیس بقیه سیستم را تحت تأثیر قرار نمی‌دهد.

# user_service/config.py
DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql',
        'NAME': 'user_service_db',
        'USER': 'user_svc',
        'PASSWORD': os.environ.get('DB_PASSWORD'),
        'HOST': 'user-db',
        'PORT': '5432',
    }
}

# product_service/config.py
DATABASES = {
    'default': {
        'ENGINE': 'djongo',
        'NAME': 'product_service_db',
        'CLIENT': {
            'host': 'product-db:27017',
            'username': 'product_svc',
            'password': os.environ.get('DB_PASSWORD'),
        }
    }
}

# session_service/config.py
CACHES = {
    'default': {
        'BACKEND': 'django_redis.cache.RedisCache',
        'LOCATION': 'redis://session-db:6379/0',
        'OPTIONS': {
            'CLIENT_CLASS': 'django_redis.client.DefaultClient',
        }
    }
}

چالش اصلی این مدل، حفظ ثبات داده‌ها بین سرویس‌ها است. وقتی یک عملیات نیاز دارد به چندین دیتابیس دسترسی داشته باشد، باید از الگوهایی مانند Saga استفاده کنید.

---

۱۸. تراکنش‌های توزیع‌شده و الگوی Saga

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

الگوی Saga راه‌حلی برای این مشکل است. در Saga، یک تراکنش بزرگ به مجموعه‌ای از تراکنش‌های کوچک‌تر تقسیم می‌شود. هر تراکنش کوچک یک عملیات محلی انجام می‌دهد و اگر موفق بود، تراکنش بعدی اجرا می‌شود. اگر هر مرحله‌ای شکست بخورد، مراحل قبلی با Operationهای معکوس (Compensating Transactions) لغو می‌شوند.

فرض کنید فرآیند ثبت سفارش شامل مراحل زیر است:

1. ایجاد سفارش (Order Service)
2. کاهش موجودی انبار (Inventory Service)
3. پردازش پرداخت (Payment Service)
4. ارسال اعلان (Notification Service)

اگر مرحله ۳ (پرداخت) شکست بخورد، باید مرحله ۲ (موجودی) نیز لغو شود.

# saga_orchestrator.py
from enum import Enum
from typing import List, Callable
import logging

class SagaStatus(Enum):
    PENDING = "pending"
    RUNNING = "running"
    COMPLETED = "completed"
    FAILED = "failed"
    COMPENSATING = "compensating"
    COMPENSATED = "compensated"

class SagaStep:
    def __init__(
        self,
        name: str,
        action: Callable,
        compensation: Callable
    ):
        self.name = name
        self.action = action
        self.compensation = compensation

class OrderSaga:
    def __init__(self):
        self.steps: List[SagaStep] = []
        self.status = SagaStatus.PENDING
        self.completed_steps: List[str] = []
    
    def add_step(self, step: SagaStep):
        self.steps.append(step)
    
    async def execute(self, context: dict):
        self.status = SagaStatus.RUNNING
        
        for step in self.steps:
            try:
                logging.info(f"Executing step: {step.name}")
                await step.action(context)
                self.completed_steps.append(step.name)
                
            except Exception as e:
                logging.error(f"Step {step.name} failed: {e}")
                self.status = SagaStatus.FAILED
                
                # اجرای مراحل معکوس
                await self.compensate(context)
                raise
        
        self.status = SagaStatus.COMPLETED
        return {"status": "success", "saga": self.status}
    
    async def compensate(self, context: dict):
        self.status = SagaStatus.COMPENSATING
        
        for step_name in reversed(self.completed_steps):
            step = next(s for s in self.steps if s.name == step_name)
            try:
                logging.info(f"Compensating step: {step.name}")
                await step.compensation(context)
            except Exception as e:
                logging.error(f"Compensation failed for {step.name}: {e}")
                # لاگ خطا اما ادامه فرآیند
        
        self.status = SagaStatus.COMPENSATED

# استفاده از Saga
async def create_order_saga(order_data: dict):
    saga = OrderSaga()
    
    saga.add_step(SagaStep(
        name="create_order",
        action=lambda ctx: order_service.create(ctx['order_data']),
        compensation=lambda ctx: order_service.cancel(ctx['order_id'])
    ))
    
    saga.add_step(SagaStep(
        name="reduce_inventory",
        action=lambda ctx: inventory_service.reduce(ctx['items']),
        compensation=lambda ctx: inventory_service.restore(ctx['items'])
    ))
    
    saga.add_step(SagaStep(
        name="process_payment",
        action=lambda ctx: payment_service.charge(ctx['payment_info']),
        compensation=lambda ctx: payment_service.refund(ctx['payment_id'])
    ))
    
    saga.add_step(SagaStep(
        name="send_notification",
        action=lambda ctx: notification_service.send(ctx['order_id']),
        compensation=lambda ctx: None  # اعلان نیاز به جبران ندارد
    ))
    
    return await saga.execute(order_data)

دو نوع اصلی Saga وجود دارد:

• Choreography: هر سرویس خودش تصمیم می‌گیرد مرحله بعدی چیست. مناسب سیستم‌های ساده‌تر.
• Orchestration: یک Orchestrator مرکزی تمام مراحل را مدیریت می‌کند. مناسب سیستم‌های پیچیده‌تر.

---

۱۹. معماری Event-Driven

معماری Event-Driven رویکردی است که در آن سرویس‌ها از طریق رویدادها (Events) با یکدیگر ارتباط برقرار می‌کنند. به جای فراخوانی مستقیم سرویس‌ها، هر سرویس رویدادهای مربوط به کار خود را منتشر می‌کند و سرویس‌های دیگر به این رویدادها واکنش نشان می‌دهند.

این الگو چندین مزیت حیاتی دارد:

• Decoupling: سرویس‌ها از یکدیگر جدا هستند و نیازی نیست یکدیگر را بشناسند
• Scalability: سرویس‌ها می‌توانند به صورت مستقل scale شوند
• Resilience: اگر یک سرویس در دسترس نباشد، رویدادها در Queue ذخیره شده و بعداً پردازش می‌شوند
• Auditability: تمام رویدادها ثبت می‌شوند و قابل ردیابی هستند

---

۲۰. API Gateway

API Gateway نقطه ورود واحد برای تمام درخواست‌های کلاینت است. تمام درخواست‌ها ابتدا به API Gateway می‌رسند و سپس به سرویس‌های backend هدایت می‌شوند.

API Gateway وظایف زیر را انجام می‌دهد:

• Routing: هدایت درخواست‌ها به سرویس مناسب
• Authentication: احراز هویت و مجوزدهی
• Rate Limiting: محدود کردن تعداد درخواست‌ها
• Load Balancing: توزیع بار بین نمونه‌های مختلف یک سرویس
• Caching: کش کردن پاسخ‌ها برای کاهش بار سرویس‌ها
• SSL Termination: مدیریت اتصالات HTTPS
• Request/Response Transformation: تبدیل فرمت درخواست و پاسخ

# nginx/api-gateway.conf
upstream user_service {
    server user-service-1:8001;
    server user-service-2:8001;
}

upstream product_service {
    server product-service-1:8002;
    server product-service-2:8002;
}

upstream order_service {
    server order-service-1:8003;
    server order-service-2:8003;
}

server {
    listen 443 ssl;
    server_name api.example.com;

    ssl_certificate /etc/ssl/certs/api.crt;
    ssl_certificate_key /etc/ssl/private/api.key;

    # Rate limiting
    limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;

    # User Service
    location /api/users/ {
        limit_req zone=api burst=20 nodelay;
        proxy_pass http://user_service;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }

    # Product Service
    location /api/products/ {
        limit_req zone=api burst=50 nodelay;
        proxy_pass http://product_service;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }

    # Order Service
    location /api/orders/ {
        limit_req zone=api burst=10 nodelay;
        proxy_pass http://order_service;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

---

۲۱. Service Discovery

در معماری میکروسرویس، سرویس‌ها باید بتوانند یکدیگر را پیدا کنند. از آنجایی که آدرس‌های IP سرویس‌ها مدام تغییر می‌کند (به خصوص در محیط‌های Container)، نیاز به یک مکانیسم Service Discovery داریم.

دو رویکرد اصلی وجود دارد:

• Client-Side Discovery: کلاینت لیست سرویس‌ها را از Service Registry دریافت و خودش load balancing را انجام می‌دهد
• Server-Side Discovery: یک Load Balancer مرکزی درخواست‌ها را به سرویس‌ها هدایت می‌کند

ابزارهای محبوب برای Service Discovery:

ابزار	توضیح
Consul	ابزار HashiCorp برای service discovery و configuration
Eureka	ابزار Netflix برای service discovery
Kubernetes DNS	سیستم DNS داخلی Kubernetes
Zookeeper	ابزار Apache برای هماهنگی توزیع‌شده

---

۲۲. کانتینرسازی با Docker

Docker استاندارد طلایی برای کانتینرسازی در معماری میکروسرویس است. هر سرویس در یک کانتینر Docker قرار می‌گیرد و به صورت مستقل اجرا می‌شود.

مزایای کانتینرسازی:

• ایزولاسیون: هر سرویس محیط اجرایی مستقل خود را دارد
• portability: کانتینرها روی هر سیستمی اجرا می‌شوند
• تکرارپذیری: محیط توسعه و تولید یکسان است
• سرعت: کانتینرها در مقایسه با VM بسیار سریع‌تر شروع به کار می‌کنند

# Dockerfile - User Service
FROM python:3.11-slim

WORKDIR /app

# نصب وابستگی‌های سیستمی
RUN apt-get update && apt-get install -y \
    gcc \
    libpq-dev \
    && rm -rf /var/lib/apt/lists/*

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY . .

EXPOSE 8001

CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8001"]

# Dockerfile - Product Service (Go)
FROM golang:1.21-alpine AS builder

WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download

COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -o main ./cmd/product-service

FROM alpine:latest
RUN apk --no-cache add ca-certificates
WORKDIR /root/
COPY --from=builder /app/main .

EXPOSE 8002
CMD ["./main"]

# docker-compose.yml - Multi-service setup
version: '3.8'

services:
  # API Gateway
  api-gateway:
    image: nginx:alpine
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx/api-gateway.conf:/etc/nginx/nginx.conf
    depends_on:
      - user-service
      - product-service
      - order-service
      - payment-service

  # User Service
  user-service:
    build: ./services/user-service
    environment:
      - DATABASE_URL=postgres://user:pass@user-db:5432/users
      - REDIS_URL=redis://redis:6379/0
    depends_on:
      - user-db
      - redis
    deploy:
      replicas: 2
      resources:
        limits:
          cpus: '0.5'
          memory: 512M

  # Product Service
  product-service:
    build: ./services/product-service
    environment:
      - MONGO_URL=mongodb://product-db:27017/products
    depends_on:
      - product-db
    deploy:
      replicas: 3
      resources:
        limits:
          cpus: '0.5'
          memory: 256M

  # Order Service
  order-service:
    build: ./services/order-service
    environment:
      - DATABASE_URL=postgres://order:pass@order-db:5432/orders
      - RABBITMQ_URL=amqp://guest:guest@rabbitmq:5672/
      - USER_SERVICE_URL=http://user-service:8001
      - PRODUCT_SERVICE_URL=http://product-service:8002
    depends_on:
      - order-db
      - rabbitmq
      - user-service
      - product-service
    deploy:
      replicas: 2

  # Payment Service
  payment-service:
    build: ./services/payment-service
    environment:
      - DATABASE_URL=postgres://payment:pass@payment-db:5432/payments
      - STRIPE_SECRET_KEY=${STRIPE_SECRET_KEY}
    depends_on:
      - payment-db
    deploy:
      replicas: 2

  # Databases
  user-db:
    image: postgres:15-alpine
    environment:
      POSTGRES_DB: users
      POSTGRES_USER: user
      POSTGRES_PASSWORD: pass
    volumes:
      - user-db-data:/var/lib/postgresql/data

  product-db:
    image: mongo:7
    volumes:
      - product-db-data:/data/db

  order-db:
    image: postgres:15-alpine
    environment:
      POSTGRES_DB: orders
      POSTGRES_USER: order
      POSTGRES_PASSWORD: pass
    volumes:
      - order-db-data:/var/lib/postgresql/data

  payment-db:
    image: postgres:15-alpine
    environment:
      POSTGRES_DB: payments
      POSTGRES_USER: payment
      POSTGRES_PASSWORD: pass
    volumes:
      - payment-db-data:/var/lib/postgresql/data

  # Message Broker
  rabbitmq:
    image: rabbitmq:3-management
    ports:
      - "15672:15672"
    environment:
      RABBITMQ_DEFAULT_USER: guest
      RABBITMQ_DEFAULT_PASS: guest

  # Cache
  redis:
    image: redis:7-alpine
    ports:
      - "6379:6379"

volumes:
  user-db-data:
  product-db-data:
  order-db-data:
  payment-db-data:

---

۲۳. ارکستراسیون کانتینر با Kubernetes

Kubernetes (K8s) استاندارد صنعتی برای ارکستراسیون کانتینرها است. وقتی تعداد سرویس‌ها و کانتینرها زیاد می‌شود، مدیریت دستی آن‌ها غیرممکن است و Kubernetes وارد میدان می‌شود.

وظایف اصلی Kubernetes:

• Container Orchestration: مدیریت چرخه حیات کانتینرها
• Auto-scaling: افزایش و کاهش خودکار تعداد کانتینرها بر اساس بار
• Self-healing: ریستارت خودکار کانتینرها در صورت خرابی
• Load Balancing: توزیع خودکار ترافیک
• Rolling Updates: بروزرسانی بدون downtime
• Service Discovery: پیدا کردن سرویس‌ها
• Secret Management: مدیریت رمزها و تنظیمات حساس

# k8s/user-service-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: user-service
  namespace: production
  labels:
    app: user-service
    version: v1.2.3
spec:
  replicas: 3
  selector:
    matchLabels:
      app: user-service
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  template:
    metadata:
      labels:
        app: user-service
        version: v1.2.3
    spec:
      containers:
      - name: user-service
        image: myregistry/user-service:v1.2.3
        ports:
        - containerPort: 8001
        env:
        - name: DATABASE_URL
          valueFrom:
            secretKeyRef:
              name: user-service-secrets
              key: database-url
        - name: REDIS_URL
          valueFrom:
            configMapKeyRef:
              name: user-service-config
              key: redis-url
        resources:
          requests:
            memory: "256Mi"
            cpu: "250m"
          limits:
            memory: "512Mi"
            cpu: "500m"
        livenessProbe:
          httpGet:
            path: /health
            port: 8001
          initialDelaySeconds: 30
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /ready
            port: 8001
          initialDelaySeconds: 5
          periodSeconds: 5
---
apiVersion: v1
kind: Service
metadata:
  name: user-service
  namespace: production
spec:
  selector:
    app: user-service
  ports:
  - port: 8001
    targetPort: 8001
  type: ClusterIP
---
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: user-service-hpa
  namespace: production
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: user-service
  minReplicas: 3
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 80

---

۲۴. لاگینگ (Logging)

در معماری میکروسرویس، لاگ‌ها در سرویس‌های مختلف پراکنده هستند. جمع‌آوری و تحلیل لاگ‌ها به یک سیستم متمرکز نیاز دارد.

Stack محبوب برای لاگینگ:

• ELK Stack: Elasticsearch + Logstash + Kibana
• EFK Stack: Elasticsearch + Fluentd + Kibana
• Loki: راه‌حل سبک‌تر توسط Grafana Labs

# logging_config.py
import logging
import json
from datetime import datetime

class JSONFormatter(logging.Formatter):
    def format(self, record):
        log_entry = {
            "timestamp": datetime.utcnow().isoformat(),
            "level": record.levelname,
            "service": "order-service",
            "message": record.getMessage(),
            "module": record.module,
            "function": record.funcName,
            "line": record.lineno,
        }
        
        if hasattr(record, 'extra_data'):
            log_entry.update(record.extra_data)
        
        return json.dumps(log_entry)

# استفاده
logger = logging.getLogger("order-service")
handler = logging.StreamHandler()
handler.setFormatter(JSONFormatter())
logger.addHandler(handler)
logger.setLevel(logging.INFO)

# لاگ کردن رویداد
logger.info("Order created", extra={
    "extra_data": {
        "order_id": "12345",
        "user_id": 67890,
        "total_amount": 150000
    }
})

---

۲۵. مانیتورینگ (Monitoring)

مانیتورینگ شامل جمع‌آوری و تحلیل متریک‌های سیستم مانند CPU، Memory، Request Rate و Error Rate است.

Prometheus

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

# prometheus.yml
global:
  scrape_interval: 15s
  evaluation_interval: 15s

scrape_configs:
  - job_name: 'user-service'
    static_configs:
      - targets: ['user-service:8001']
    metrics_path: '/metrics'

  - job_name: 'product-service'
    static_configs:
      - targets: ['product-service:8002']
    metrics_path: '/metrics'

  - job_name: 'order-service'
    static_configs:
      - targets: ['order-service:8003']
    metrics_path: '/metrics'

  - job_name: 'kubernetes-pods'
    kubernetes_sd_configs:
      - role: pod
    relabel_configs:
      - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
        action: keep
        regex: true

Grafana

Grafana ابزار بصری‌سازی و داشبورد است. متریک‌های Prometheus را به صورت نمودار و داشبورد نمایش می‌دهد.

---

۲۶. تریسینگ (Tracing)

Distributed Tracing فرآیند ردیابی یک درخواست از زمان ورود به سیستم تا خروج، از طریق تمام سرویس‌هایی که در پردازش آن نقش داشته‌اند.

Jaeger

Jaeger ابزار محبوب open-source برای distributed tracing است که توسط Uber توسعه داده شده.

# main.py - User Service with Jaeger tracing
from fastapi import FastAPI
from jaeger_client import Config
from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanExporter
from opentelemetry.exporter.jaeger.thrift import JaegerExporter

app = FastAPI()

# راه‌اندازی Jaeger
def init_tracer(service_name: str):
    config = Config(
        config={
            'sampler': {'type': 'const', 'param': 1},
            'local_agent': {'reporting_host': 'jaeger', 'reporting_port': 6831},
        },
        service_name=service_name,
    )
    return config.initialize_tracer()

tracer = init_tracer("user-service")

@app.get("/users/{user_id}")
async def get_user(user_id: int):
    with tracer.start_span('get-user') as span:
        span.set_tag('user_id', user_id)
        
        # دریافت کاربر از دیتابیس
        with tracer.start_span('db-query') as db_span:
            user = await db.users.find_one({"id": user_id})
            db_span.set_tag('db.system', 'postgresql')
            db_span.set_tag('db.statement', f'SELECT * FROM users WHERE id = {user_id}')
        
        return user

OpenTelemetry

OpenTelemetry استانداردی برای جمع‌آوری تریس، متریک و لاگ است. ابزاری یکپارچه فراهم می‌کند که با سیستم‌های مختلف مانیتورینگ سازگار است.

# opentelemetry_config.py
from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter
from opentelemetry.sdk.resources import Resource

# تعریف منبع
resource = Resource.create({
    "service.name": "order-service",
    "service.version": "1.2.3",
    "deployment.environment": "production"
})

# راه‌اندازی tracer
provider = TracerProvider(resource=resource)
processor = BatchSpanProcessor(
    OTLPSpanExporter(endpoint="jaeger-collector:4317")
)
provider.add_span_processor(processor)
trace.set_tracer_provider(provider)

tracer = trace.get_tracer(__name__)

ابزارهای تریسینگ مقایسه شده:

ابزار	توسعه‌دهنده	ویژگی خاص
Jaeger	Uber (CNCF)	سادگی استقرار، پشتیبانی از OpenTracing
Zipkin	Twitter	سبک و سریع، اکوسیستم بزرگ
OpenTelemetry	CNCF	استاندارد جامع، سازگاری با چندین backend

---

۲۷. احراز هویت: JWT، OAuth2، OpenID Connect

احراز هویت در معماری میکروسرویس یکی از پیچیده‌ترین چالش‌ها است. در اینجا سه استاندارد اصلی را بررسی می‌کنیم.

JWT (JSON Web Token)

JWT یک استاندارد باز (RFC 7519) برای انتقال اطلاعات به صورت امن بین دو طرف است. JWT شامل سه بخش است: Header، Payload و Signature.

# jwt_service.py
import jwt
from datetime import datetime, timedelta
from typing import Optional

class JWTService:
    def __init__(self, secret_key: str, algorithm: str = "HS256"):
        self.secret_key = secret_key
        self.algorithm = algorithm
    
    def create_access_token(
        self,
        user_id: int,
        roles: list,
        expires_delta: timedelta = timedelta(hours=1)
    ) -> str:
        payload = {
            "sub": user_id,
            "roles": roles,
            "iat": datetime.utcnow(),
            "exp": datetime.utcnow() + expires_delta,
            "iss": "auth-service"
        }
        return jwt.encode(payload, self.secret_key, algorithm=self.algorithm)
    
    def create_refresh_token(self, user_id: int) -> str:
        payload = {
            "sub": user_id,
            "type": "refresh",
            "iat": datetime.utcnow(),
            "exp": datetime.utcnow() + timedelta(days=7)
        }
        return jwt.encode(payload, self.secret_key, algorithm=self.algorithm)
    
    def verify_token(self, token: str) -> Optional[dict]:
        try:
            payload = jwt.decode(
                token,
                self.secret_key,
                algorithms=[self.algorithm]
            )
            return payload
        except jwt.ExpiredSignatureError:
            return None
        except jwt.InvalidTokenError:
            return None

OAuth2

OAuth2 یک پروتکل authorization است که به کلاینت‌ها اجازه می‌دهد به نمایندگی از کاربر، به منابع دسترسی پیدا کنند. در معماری میکروسرویس، OAuth2 معمولاً برای ارتباط بین سرویس‌ها و احراز هویت کاربران استفاده می‌شود.

# oauth2_service.py
from authlib.integrations.starlette_client import OAuth
from fastapi import FastAPI, Request
from fastapi.responses import RedirectResponse

app = FastAPI()

oauth = OAuth()
oauth.register(
    name='google',
    client_id=os.environ.get('GOOGLE_CLIENT_ID'),
    client_secret=os.environ.get('GOOGLE_CLIENT_SECRET'),
    server_metadata_url='https://accounts.google.com/.well-known/openid-configuration',
    client_kwargs={'scope': 'openid email profile'},
)

@app.get("/auth/google")
async def google_login(request: Request):
    redirect_uri = request.url_for('google_callback')
    return await oauth.google.authorize_redirect(request, redirect_uri)

@app.get("/auth/google/callback")
async def google_callback(request: Request):
    token = await oauth.google.authorize_access_token(request)
    user_info = token.get('userinfo')
    
    # ایجاد یا بروزرسانی کاربر
    user = await get_or_create_user(user_info)
    
    # ایجاد JWT
    jwt_token = jwt_service.create_access_token(
        user_id=user.id,
        roles=user.roles
    )
    
    return RedirectResponse(
        url=f"http://localhost:3000/auth/callback?token={jwt_token}"
    )

OpenID Connect (OIDC)

OpenID Connect لایه هویت روی OAuth2 است. در حالی که OAuth2 فقط authorization را مدیریت می‌کند، OIDC احراز هویت (Authentication) را نیز اضافه می‌کند.

OIDC چندین مزیت نسبت به OAuth2 خام دارد:

• اطلاعات کاربر (profile) در استاندارد ساده در دسترس است
• ID Token استاندارد برای احراز هویت
• Discovery endpoint برای پیکربندی خودکار
• سازگاری با ابزارهای مختلف

---

۲۸. چالش‌های امنیتی

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

چالش‌های امنیتی اصلی:

چالش	توضیح	راه‌حل
امنیت ارتباطات	ارتباط بین سرویس‌ها باید رمزنگاری شود	mTLS، Service Mesh (Istio)
مدیریت رمزها	هر سرویس رمزهای متفاوتی دارد	HashiCorp Vault، Kubernetes Secrets
احراز هویت بین سرویس‌ها	سرویس‌ها باید هویت یکدیگر را تایید کنند	Service Mesh، JWT بین سرویسی
سطح حمله	هر سرویس یک نقطه حمله جدید است	اصل حداقل دسترسی (Principle of Least Privilege)، Network Policies
اصل حداقل دسترسی (Principle of Least Privilege)، Network Policies	هر سرویس ممکن است داده حساس متفاوتی داشته باشد	Data classification، Encryption at rest

---

۲۹. CI/CD

CI/CD (Continuous Integration / Continuous Deployment) در معماری میکروسرویس بسیار مهم‌تر از مونولیت است. هر سرویس باید pipeline مستقل خود را داشته باشد.

# .github/workflows/user-service.yml
name: User Service CI/CD

on:
  push:
    branches: [main]
    paths:
      - 'services/user-service/**'
  pull_request:
    branches: [main]
    paths:
      - 'services/user-service/**'

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      
      - name: Set up Python
        uses: actions/setup-python@v4
        with:
          python-version: '3.11'
      
      - name: Install dependencies
        run: |
          cd services/user-service
          pip install -r requirements.txt
          pip install pytest pytest-cov
      
      - name: Run tests
        run: |
          cd services/user-service
          pytest tests/ -v --cov=src --cov-report=xml
      
      - name: Upload coverage
        uses: codecov/codecov-action@v3
        with:
          file: ./services/user-service/coverage.xml

  build-and-push:
    needs: test
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'
    
    steps:
      - uses: actions/checkout@v3
      
      - name: Build Docker image
        run: |
          cd services/user-service
          docker build -t myregistry/user-service:${{ github.sha }} .
      
      - name: Push to registry
        run: |
          docker push myregistry/user-service:${{ github.sha }}

  deploy:
    needs: build-and-push
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'
    
    steps:
      - name: Deploy to Kubernetes
        run: |
          kubectl set image deployment/user-service \
            user-service=myregistry/user-service:${{ github.sha }} \
            -n production

---

۳۰. استراتژی‌های استقرار

Rolling Update

در Rolling Update، نمونه‌های جدید به تدریج جایگزین نمونه‌های قدیمی می‌شوند. در هر لحظه بخشی از نمونه‌ها قدیمی و بخشی جدید هستند.

# k8s rolling-update.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: user-service
spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1        # حداکثر 1 نمونه اضافی
      maxUnavailable: 0   # هیچ نمونه‌ای غیرفعال نمی‌شود
  template:
    spec:
      containers:
      - name: user-service
        image: myregistry/user-service:v2.0.0

Blue/Green Deployment

در Blue/Green، دو محیط کاملاً یکسان (Blue و Green) وجود دارد. نسخه جدید در Green مستقر شده و پس از تست، ترافیک از Blue به Green منتقل می‌شود.

# k8s blue-green.yaml
# Blue (نسخه فعلی)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: user-service-blue
spec:
  replicas: 3
  selector:
    matchLabels:
      app: user-service
      version: blue
  template:
    metadata:
      labels:
        app: user-service
        version: blue
    spec:
      containers:
      - name: user-service
        image: myregistry/user-service:v1.0.0
---
# Green (نسخه جدید)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: user-service-green
spec:
  replicas: 3
  selector:
    matchLabels:
      app: user-service
      version: green
  template:
    metadata:
      labels:
        app: user-service
        version: green
    spec:
      containers:
      - name: user-service
        image: myregistry/user-service:v2.0.0
---
# Service - ابتدا به Blue وصل است
apiVersion: v1
kind: Service
metadata:
  name: user-service
spec:
  selector:
    app: user-service
    version: blue  # تغییر به green برای switch
  ports:
  - port: 8001
    targetPort: 8001

Canary Deployment

در Canary، درصد کوچکی از ترافیک به نسخه جدید هدایت می‌شود. اگر مشکلی پیش نیامد، درصد به تدریج افزایش می‌یابد.

# k8s canary.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: user-service-canary
spec:
  replicas: 1
  selector:
    matchLabels:
      app: user-service
      version: canary
  template:
    metadata:
      labels:
        app: user-service
        version: canary
    spec:
      containers:
      - name: user-service
        image: myregistry/user-service:v2.0.0
---
# Istio VirtualService for canary routing
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: user-service
spec:
  hosts:
  - user-service
  http:
  - route:
    - destination:
        host: user-service
        subset: stable
      weight: 90
    - destination:
        host: user-service
        subset: canary
      weight: 10

مقایسه استراتژی‌های استقرار:

استراتژی	Downtime	Rollback	هزینه	پیچیدگی
Rolling Update	صفر	آسان	کم	کم
Blue/Green	صفر	فوری	بالا (دو برابر منابع)	متوسط
Canary	صفر	آسان	کم	بالا

---

۳۱. نمونه‌های واقعی تولید

Netflix

Netflix یکی از اولین و موفق‌ترین نمونه‌های استفاده از میکروسرویس است. Netflix بیش از ۱۰۰۰ میکروسرویس دارد و روزانه میلیاردها درخواست را پردازش می‌کند. آن‌ها از ابزارهایی مانند Zuul (API Gateway)، Eureka (Service Discovery)، و Hystrix (Circuit Breaker) استفاده می‌کنند.

نکته مهم: Netflix با یک مونولیت شروع کرد. در سال ۲۰۰۹، یک باگ در سیستم مونولیت آن‌ها باعث قطعی چند روزه سرویس شد. همین اتفاق باعث شد آن‌ها تصمیم به مهاجرت به میکروسرویس بگیرند.

Amazon

Amazon در سال ۲۰۰۱ شروع به شکستن مونولیت خود به سرویس‌های مستقل کرد. امروزه Amazon از صدها سرویس مستقل تشکیل شده که هر کدام تیم مستقل خود را دارند. این ساختار به آن‌ها اجازه می‌دهد روزانه هزاران بار deploy کنند.

Uber

Uber ابتدا با یک مونولیت Python شروع کرد. با رشد سریع، این مونولیت غیرقابل مدیریت شد. آن‌ها به میکروسرویس مهاجرت کردند و امروزه بیش از ۴۰۰۰ میکروسرویس دارند. ابزارهای داخلی مانند Schemaless (database) و Ringpop (service discovery) توسعه دادند.

Spotify

Spotify از معماری میکروسرویس برای مدیریت میلیون‌ها کاربر و میلیون‌ها آهنگ استفاده می‌کند. آن‌ها از الگوی "Squad" استفاده می‌کنند — هر تیم کوچک (Squad) مسئولیت یک یا چند میکروسرویس را بر عهده دارد.

---

۳۲. جدول مقایسه جامع

ویژگی	Monolithic	Microservices
ساختار	یک اپلیکیشن واحد	چندین سرویس مستقل
استقرار	ساده و سریع	پیچیده و نیاز به ابزارهای ارکستراسیون
مقیاس‌پذیری	عمودی یا افقی (کل اپلیکیشن)	افقی (هر سرویس جداگانه)
توسعه	سریع در ابتدا، کند در ادامه	کند در ابتدا، سریع در ادامه
تست	ساده	پیچیده (نیاز به integration tests)
اشکال‌زدایی (Debugging)	آسان	دشوار (نیاز به distributed tracing)
تیم	کوچک تا متوسط	بزرگ با تیم‌های مستقل
فناوری	stack واحد	polyglot (چند زبان مختلف)
دیتابیس	مشترک	هر سرویس دیتابیس مستقل
امنیت	ساده‌تر	پیچیده‌تر
هزینه اولیه	بسیار کم	بالا
هزینه نگهداری	افزایشی با رشد پروژه	ثابت و قابل پیش‌بینی
مقاومت خطا	پایین (single point of failure)	بالا (fault isolation)
سرعت release	کند (deploy کل اپلیکیشن)	سریع (deploy هر سرویس جداگانه)
مناسب برای	پروژه‌های کوچک تا متوسط، MVP	سیستم‌های بزرگ، تیم‌های بزرگ
یادگیری	آسان	دشوار (ابزارهای زیاد)
زیرساخت	ساده	پیچیده (Kubernetes, Service Mesh, etc.)
لاگینگ	ساده (فایل لاگ محلی)	نیاز به ELK/Loki
مانیتورینگ	ساده	نیاز به Prometheus/Grafana
تریسینگ	غیرضروری	ضروری (Jaeger, OpenTelemetry)

---

۳۳. کی مونولیت انتخاب کنیم؟

انتخاب معماری مونولیت در موارد زیر کاملاً صحیح و منطقی است:

1. تیم کوچک (۱-۵ نفر): اگر تیم شما کوچک است، پیچیدگی میکروسرویس ارزشش را ندارد.
2. پروژه نوپا (Startup): در مراحل اولیه، مهم‌ترین چیز验证 ایده در بازار است. مونولیت به شما اجازه می‌دهد سریع MVP بسازید.
3. پروژه با دامنه محدود: اگر پروژه پیچیدگی زیادی ندارد، مونولیت کافی است.
4. محدودیت بودجه: هزینه زیرساخت میکروسرویس می‌تواند برای پروژه‌های با بودجه محدود سنگین باشد.
5. عدم تجربه کافی: اگر تیم با ابزارهای میکروسرویس آشنا نیست، مونولیت انتخاب بهتری است.
6. نیاز به سرعت توسعه بالا: مونولیت امکان توسعه سریع‌تر را فراهم می‌کند.
7. سیستم‌های با نیاز مقیاس‌پذیری کم: اگر انتظار ترافیک بالایی ندارید، مونولیت مناسب است.

به قول Martin Fowler:

"Almost all the successful microservice stories have started with a monolith that got too big and was broken up."

تقریباً تمام داستان‌های موفق میکروسرویس با یک مونولیت شروع شده‌اند که بیش از حد بزرگ شده و شکسته شده است.

---

۳۴. کی میکروسرویس انتخاب کنیم؟

میکروسرویس زمانی مناسب است که:

1. تیم بزرگ (۱۰+ نفر): تیم‌های بزرگ نیاز به استقلال دارند تا بتوانند بدون تداخل کار کنند.
2. دامنه پیچیده: سیستم‌های با دامنه کسب‌وکار پیچیده از تقسیم به سرویس‌های کوچکتر سود می‌برند.
3. نیاز به مقیاس‌پذیری بالا: اگر سیستم شما نیاز به scale بخش‌های مختلف به صورت مستقل دارد.
4. نیاز به تکنولوژی‌های مختلف: اگر بخش‌های مختلف سیستم نیاز به زبان‌ها یا فریم‌ورک‌های متفاوت دارند.
5. نیاز به استقرار مکرر: اگر نیاز دارید روزانه چندین بار deploy کنید.
6. تیم DevOps ماهر: اگر تیم DevOps قوی و با تجربه‌ای دارید.
7. بودجه کافی: هزینه‌های زیرساخت و نیروی انسانی میکروسرویس بالاتر است.

---

۳۵. اشتباهات رایج

اشتباه ۱: شروع با میکروسرویس بدون نیاز واقعی

بسیاری از استارتاپ‌ها فکر می‌کنند میکروسرویس "حرفه‌ای‌تر" است و از همان ابتدا آن را انتخاب می‌کنند. این یک اشتباه بزرگ است. میکروسرویس پیچیدگی عملیاتی زیادی دارد و در مراحل اولیه پروژه، این پیچیدگی باعث کندی توسعه می‌شود.

اشتباه ۲: شکستن بیش از حد (Over-Decomposition)

بعضی تیم‌ها سرویس‌های خیلی ریز ایجاد می‌کنند. مثلاً برای هر API endpoint یک سرویس جداگانه. این باعث افزایش پیچیدگی ارتباطات و هزینه‌های زیرساخت می‌شود بدون اینکه مزیت واقعی ایجاد کند.

اشتباه ۳: اشتراک‌گذاری دیتابیس بین سرویس‌ها

اشتراک‌گذاری دیتابیس بین سرویس‌ها مزیت اصلی میکروسرویس (استقلال) را از بین می‌برد. اگر دو سرویس یک دیتابیس مشترک دارند، تغییر Schema در یکی ممکن است دیگری را خراب کند.

اشتباه ۴: نادیده گرفتن Observability

بدون لاگینگ، مانیتورینگ و تریسینگ مناسب، debugging در میکروسرویس تقریباً غیرممکن است. بسیاری از تیم‌ها این ابزارها را نادیده می‌گیرند و بعداً با مشکلات جدی مواجه می‌شوند.

اشتباه ۵: مهاجرت شتابزده

مهاجرت از مونولیت به میکروسرویس باید تدریجی باشد. مهاجرت یکباره (Big Bang Migration) تقریباً همیشه شکست می‌خورد.

---

۳۶. استراتژی مهاجرت: Monolith → Modular Monolith → Microservices

بهترین استراتژی مهاجرت از مونولیت به میکروسرویس، یک فرآیند تدریجی سه مرحله‌ای است:

مرحله ۱: Monolith

شروع با یک مونولیت ساده. تمرکز روی توسعه سریع و validation ایده.

مرحله ۲: Modular Monolith

قبل از مهاجرت به میکروسرویس، ابتدا مونولیت را مدولار کنید. ماژول‌ها را با boundaryهای مشخص از هم جدا کنید، اما همه را در یک اپلیکیشن واحد نگه دارید.

# modular_monolith/
# هر ماژول boundary مشخصی دارد
# و فقط از API داخلی ماژول‌های دیگر استفاده می‌کند

apps/
├── __init__.py
├── users/
│   ├── __init__.py
│   ├── api.py          # API عمومی ماژول
│   ├── internal.py     # API داخلی (فقط برای ماژول‌های دیگر)
│   ├── models.py
│   ├── services.py
│   └── tests/
├── orders/
│   ├── __init__.py
│   ├── api.py
│   ├── internal.py
│   ├── models.py
│   ├── services.py
│   └── tests/
└── payments/
    ├── __init__.py
    ├── api.py
    ├── internal.py
    ├── models.py
    ├── services.py
    └── tests/

# ماژول orders از API داخلی ماژول users استفاده می‌کند
# نه مستقیماً از مدل‌ها یا سرویس‌های آن

مرحله ۳: Microservices

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

نکته مهم: هرگز مستقیماً از مرحله ۱ به مرحله ۳ نروید. مرحله ۲ (Modular Monolith) یک گام حیاتی است که boundaryهای سرویس‌ها را مشخص می‌کند.

---

۳۷. نمونه Django: از مونولیت تا میکروسرویس

فرض کنید یک اپلیکیشن فروشگاه آنلاین Django داریم و می‌خواهیم آن را به میکروسرویس مهاجرت دهیم.

مرحله ۱: مونولیت اولیه

# ecommerce/  (مونولیت اولیه)
# تمام اپلیکیشن‌ها در یک پروژه
INSTALLED_APPS = [
    'apps.accounts',
    'apps.products',
    'apps.orders',
    'apps.payments',
    'apps.shipping',
    'apps.notifications',
]

مرحله ۲: Modular Monolith

# ecommerce/  (Modular Monolith)
# هر ماژول boundary مشخصی دارد

# apps/orders/services.py
class OrderService:
    """سرویس سفارشات - فقط از API داخلی ماژول‌های دیگر استفاده می‌کند"""
    
    def __init__(self):
        # استفاده از API داخلی (نه مستقیم از مدل‌ها)
        from apps.accounts.internal import UserInternalAPI
        from apps.products.internal import ProductInternalAPI
        
        self.user_api = UserInternalAPI()
        self.product_api = ProductInternalAPI()
    
    def create_order(self, user_id: int, items: list):
        # دریافت اطلاعات کاربر
        user = self.user_api.get_user(user_id)
        
        # بررسی موجودی محصولات
        for item in items:
            product = self.product_api.get_product(item['product_id'])
            if product.stock < item['quantity']:
                raise InsufficientStockError(product.id)
        
        # ایجاد سفارش
        order = Order.objects.create(
            user_id=user_id,
            total=self.calculate_total(items)
        )
        
        return order

مرحله ۳: میکروسرویس

# ساختار نهایی میکروسرویس
services/
├── api-gateway/
│   ├── nginx.conf
│   └── Dockerfile
├── user-service/
│   ├── manage.py
│   ├── requirements.txt
│   ├── Dockerfile
│   └── apps/
│       └── users/
│           ├── models.py
│           ├── views.py
│           └── serializers.py
├── product-service/
│   ├── main.py  (FastAPI)
│   ├── requirements.txt
│   ├── Dockerfile
│   └── app/
│       ├── models.py
│       ├── routes.py
│       └── services.py
├── order-service/
│   ├── manage.py
│   ├── requirements.txt
│   ├── Dockerfile
│   └── apps/
│       └── orders/
│           ├── models.py
│           ├── views.py
│           └── events.py
├── payment-service/
│   ├── main.py
│   ├── requirements.txt
│   ├── Dockerfile
│   └── app/
│       ├── models.py
│       ├── routes.py
│       └── gateways/
├── k8s/
│   ├── namespace.yaml
│   ├── user-service.yaml
│   ├── product-service.yaml
│   ├── order-service.yaml
│   └── payment-service.yaml
└── docker-compose.yml

---

۳۸. سوالات متداول

۱. آیا هر پروژه‌ای باید از میکروسرویس استفاده کند؟

خیر. میکروسرویس فقط برای سیستم‌هایی با پیچیدگی و مقیاس بالا مناسب است. اکثر پروژه‌ها با یک مونولیت خوب شروع می‌شوند.

۲. هزینه زیرساخت میکروسرویس چقدر بیشتر است؟

هزینه بستگی به مقیاس دارد، اما به طور کلی ۲ تا ۵ برابر مونولیت است. این هزینه شامل سرورهای بیشتر، ابزارهای مانیتورینگ، و نیروی DevOps می‌شود.

۳. آیا Django برای میکروسرویس مناسب است؟

بله، Django می‌تواند برای میکروسرویس استفاده شود. با این حال، FastAPI برای سرویس‌های سبک‌تر و با performance بالاتر انتخاب بهتری است. بسیاری از تیم‌ها Django REST Framework را برای سرویس‌های اصلی و FastAPI را برای سرویس‌های real-time استفاده می‌کنند.

۴. چگونه بفهمم معماری فعلی من باید تغییر کند؟

علائم نیاز به تغییر: زمان build طولانی، deploy‌های پرریسک، تداخل تیم‌ها، نیاز به scale متفاوت بخش‌ها، و پیچیدگی غیرقابل مدیریت کد.

۵. Microservices همیشه از REST API استفاده می‌کنند؟

خیر. علاوه بر REST، از gRPC (برای ارتباط سریع بین سرویس‌ها)، GraphQL (برای API Gateway)، و message brokers مانند RabbitMQ و Kafka (برای ارتباط غیرهمزمان) نیز استفاده می‌شود.

۶. چگونه تراکنش‌های توزیع‌شده را مدیریت کنیم؟

از الگوهایی مانند Saga (Choreography یا orchestration)، Outbox Pattern، و Event Sourcing استفاده کنید. این الگوها پیچیدگی تراکنش‌های بین سرویسی را مدیریت می‌کنند.

۷. آیا میکروسرویس برای پروژه‌های شخصی مناسب است؟

معمولاً خیر. پروژه‌های شخصی معمولاً پیچیدگی و مقیاس کافی برای میکروسرویس ندارند. مونولیت برای این پروژه‌ها مناسب‌تر است.

۸. بهترین ابزار برای مانیتورینگ میکروسرویس چیست؟

ترکیب Prometheus (برای متریک) + Grafana (برای بصری‌سازی) + Jaeger یا OpenTelemetry (برای تریس) + ELK یا Loki (برای لاگ) محبوب‌ترین stack است.

۹. چگونه امنیت را در میکروسرویس تضمین کنیم؟

از mTLS برای ارتباطات، JWT برای احراز هویت، Kubernetes Network Policies برای ایزولاسیون شبکه، و HashiCorp Vault برای مدیریت رمزها استفاده کنید.

۱۰. آیا می‌توان از هر دو معماری همزمان استفاده کرد؟

بله. بسیاری از سازمان‌ها بخش‌های اصلی سیستم را مونولیت و بخش‌های حساس به مقیاس را میکروسرویس نگه می‌دارند. این رویکرد "Hybrid Architecture" نام دارد.

۱۱. Docker و Kubernetes چه تفاوتی دارند؟

Docker ابزار کانتینرسازی است (ساخت کانتینر). Kubernetes ابزار ارکستراسیون است (مدیریت هزاران کانتینر). Docker کانتینر می‌سازد، Kubernetes آن‌ها را اجرا و مدیریت می‌کند.

۱۲. چه تعداد سرویس میکروسرویس مناسب است؟

هیچ پاسخ ثابتی وجود ندارد. تعداد سرویس‌ها باید بر اساس boundaryهای دامنه (Domain Boundaries) تعیین شود. تعداد زیاد سرویس‌های ریز بدون دلیل، پیچیدگی اضافی ایجاد می‌کند.

۱۳. چگونه تست‌های end-to-end را در میکروسرویس اجرا کنیم؟

از ترکیب Contract Tests (Pact)، Integration Tests، و E2E Tests با ابزارهایی مانند Testcontainers استفاده کنید. هر سرویس تست‌های unit و integration مستقل خود را دارد.

۱۴. API Gateway چه مزیتی نسبت به مستقیم صدا زدن سرویس‌ها دارد؟

API Gateway مزایای زیادی دارد: احراز هویت متمرکز، Rate Limiting، Caching، SSL Termination، و مخفی کردن ساختار داخلی سرویس‌ها از کلاینت‌ها.

۱۵. چه زمانی باید از مونولیت به میکروسرویس مهاجرت کرد؟

زمانی که: (۱) تیم به اندازه کافی بزرگ شده و نیاز به استقلال دارد، (۲) بخش‌های مختلف نیاز به scale متفاوت دارند، (۳) زمان build و deploy بیش از حد طولانی شده، (۴) تداخل بین تیم‌ها به مشکل تبدیل شده.

۱۶. Service Mesh چیست و کی نیاز داریم؟

Service Mesh لایه زیرساختی است که ارتباطات بین سرویس‌ها را مدیریت می‌کند (load balancing، retry، circuit breaking، mTLS). ابزارهایی مانند Istio و Linkerd. زمانی مفید است که تعداد سرویس‌ها از حد خاصی فراتر رود.

۱۷. Event Sourcing چیست؟

Event Sourcing الگویی است که در آن state سیستم از تاریخچه رویدادها (Events) بازسازی می‌شود، نه از ذخیره state فعلی. مزایا: audit trail کامل، امکان بازسازی state در هر لحظه، و سازگاری با CQRS.

---

۳۹. نتیجه‌گیری

انتخاب بین معماری Monolithic و Microservices یکی از مهم‌ترین تصمیمات هر پروژه نرم‌افزاری است. هیچ کدام از این دو رویکرد به تنهایی "بهترین" نیستند — هر کدام برای شرایط خاصی مناسب‌ترند.

اگر در مراحل اولیه پروژه هستید، تیم کوچکی دارید، و بودجه محدودی دارید، مونولیت انتخاب صحیح است. سریع شروع کنید، MVP بسازید، و بازار را validate کنید.

اگر سیستم شما بزرگ شده، تیم‌های زیادی دارید، بخش‌های مختلف نیاز به scale متفاوت دارند، و تیم DevOps قوی دارید، میکروسرویس انتخاب مناسبی است. اما به یاد داشته باشید که مسیر مهاجرت باید تدریجی باشد: ابتدا Modular Monolith، سپس Microservices.

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

در نهایت، به قول Werner Vogels (CTO آمازون):

"You build it, you run it." — شما می‌سازید، شما اجرا می‌کنید.

چه مونولیت باشد چه میکروسرویس، مسئولیت سیستم بر عهده تیمی است که آن را ساخته. معماری خوب، معماری‌ای است که نیازهای کسب‌وکار را برآورده کند، تیم بتواند آن را نگهداری کند، و در بلندمدت قابل توسعه باشد.

---

کلمات کلیدی: معماری نرم‌افزار، Microservices، Monolithic، مونولیت، میکروسرویس، Docker، Kubernetes، RabbitMQ، Kafka، REST API، Django، Backend، System Design، Software Architecture، API Gateway، Distributed System