اصول طراحی میکروسرویس

۲.۱ مقدمه

طراحی صحیح میکروسرویس‌ها مهم‌ترین عاملی است که موفقیت یا شکست این معماری را تعیین می‌کند. در این فصل با اصولی که هر میکروسرویس باید رعایت کند آشنا می‌شویم.

۲.۲ Domain-Driven Design (DDD)

Domain-Driven Design رویکردی است که توسط Eric Evans در کتاب معروف ۲۰۰۳ معرفی شد. این رویکرد به ما کمک می‌کند نرم‌افزار را حول دامنه تجاری (Business Domain) طراحی کنیم.

چرا DDD برای میکروسرویس مهم است؟

بزرگترین چالش میکروسرویس، تشخیص مرزهای صحیح بین سرویس‌هاست. DDD به ما ابزار فکری برای این کار می‌دهد. اگر مرزها اشتباه تعریف شوند، با یک «Distributed Monolith» (بدترین حالت ممکن) مواجه می‌شویم.

مفاهیم کلیدی DDD

۲.۳ Bounded Context — مهم‌ترین مفهوم

یک Bounded Context یک مرز منطقی است که در آن یک مدل خاص معنا دارد. مفهوم «Customer» در context فروش با «Customer» در context ارسال متفاوت است.

مثال: یک فروشگاه آنلاین

کلمه «Product» در context های مختلف معانی متفاوتی دارد:

هر context ممکن است product_id مشترک داشته باشد، اما مدل داده هر کدام مستقل است. این مرزها معمولاً همان مرزهای میکروسرویس‌ها هستند.

Context Map — نقشه روابط

┌──────────────────┐         Upstream/Downstream      ┌──────────────────┐
│                  │ ─────────────────────────────────►│                  │
│  Catalog Context │                                   │  Order Context   │
│                  │      Customer-Supplier            │                  │
└──────────────────┘                                   └──────────────────┘
        │                                                       │
        │                                                       │
        │  Conformist                                           │  Anti-Corruption Layer
        ▼                                                       ▼
┌──────────────────┐         Shared Kernel            ┌──────────────────┐
│                  │ ◄─────────────────────────────► │                  │
│ Inventory Context│                                   │ Shipping Context │
│                  │                                   │                  │
└──────────────────┘                                   └──────────────────┘
    

الگوهای رابطه بین Context ها:

• Customer-Supplier: یکی به دیگری وابسته است (مثلاً Order به Catalog)
• Conformist: یک تیم بدون چون و چرا از مدل تیم دیگر پیروی می‌کند
• Anti-Corruption Layer (ACL): یک لایه واسطه که مدل خارجی را به مدل داخلی ترجمه می‌کند
• Shared Kernel: دو context بخشی از مدل را به اشتراک می‌گذارند (با احتیاط استفاده شود!)
• Open Host Service: یک API استاندارد که چندین context از آن استفاده می‌کنند
• Published Language: یک زبان (schema) مشترک برای ارتباط (مثل JSON Schema)

۲.۴ اصل Single Responsibility

هر میکروسرویس باید یک مسئولیت اصلی داشته باشد. این اصل به سادگی می‌گوید: «دلیل تغییر سرویس باید یک چیز باشد.»

چگونه بفهمیم سرویس مسئولیت‌های زیادی دارد؟

مثال درست و غلط

۲.۵ Database per Service

این یکی از اصول بنیادین میکروسرویس است: هر سرویس باید پایگاه داده مستقل خود را داشته باشد. سرویس‌های دیگر هیچ‌گاه نباید مستقیماً به database سرویس دیگری دسترسی داشته باشند.

چرا؟

• Encapsulation: ساختار داخلی داده‌ها مخفی می‌ماند و می‌توانید بدون تأثیر روی سایر سرویس‌ها schema را تغییر دهید
• Loose Coupling: سرویس‌ها به جزئیات یکدیگر وابسته نیستند
• Polyglot Persistence: هر سرویس می‌تواند بهترین DB را برای کار خود انتخاب کند (PostgreSQL، MongoDB، Redis، Elasticsearch)
• Scalability: هر DB مستقل scale می‌شود
• Fault Isolation: اگر یک DB down شود، سایر سرویس‌ها مشکلی ندارند

الگوهای پیاده‌سازی

User Service     ──► postgres-users:5432    (DB: users_db)
Order Service    ──► postgres-orders:5432   (DB: orders_db)
Product Service  ──► mongodb-products:27017 (DB: products)
        

-- یک PostgreSQL Server
CREATE DATABASE users_db;
CREATE DATABASE orders_db;
CREATE DATABASE products_db;

-- هر سرویس فقط به DB خودش دسترسی دارد
GRANT ALL ON users_db.* TO 'user_service'@'%';
GRANT ALL ON orders_db.* TO 'order_service'@'%';
        

مشکل: چگونه داده‌های سرویس دیگر را بخوانیم؟

وقتی Order Service نیاز به اطلاعات Product دارد، چه باید کرد؟

۲.۶ اندازه مناسب یک میکروسرویس

یکی از پرتکرارترین سوالات: «اندازه میکروسرویس چقدر باید باشد؟» پاسخ کوتاه: اندازه ثابتی وجود ندارد.

معیارهای اندازه‌گیری

۲.۷ چک‌لیست طراحی میکروسرویس

قبل از شروع کدزنی هر میکروسرویس، این سوالات را پاسخ دهید:

۲.۸ الگوهای طراحی کلیدی

۱. Strangler Fig Pattern (مهاجرت تدریجی)

الگوی نام‌گذاری شده توسط Martin Fowler از درخت انجیر strangler. به جای بازنویسی کامل Monolith، به تدریج قابلیت‌ها را به میکروسرویس منتقل می‌کنیم تا monolith قدیمی «خفه» شود.

مرحله ۱: همه ترافیک به Monolith می‌رود
[Client] ──► [Monolith]

مرحله ۲: یک قابلیت جدید در میکروسرویس ساخته می‌شود
[Client] ──► [API Gateway] ──┬──► [Monolith]
                              └──► [New Microservice]

مرحله ۳: قابلیت‌های بیشتر منتقل می‌شوند
[Client] ──► [API Gateway] ──┬──► [Monolith (کوچک‌تر)]
                              ├──► [Service A]
                              ├──► [Service B]
                              └──► [Service C]

مرحله ۴: Monolith کاملاً حذف می‌شود
[Client] ──► [API Gateway] ──┬──► [Service A]
                              ├──► [Service B]
                              ├──► [Service C]
                              └──► [Service D]
    

۲. Backend for Frontend (BFF)

هر نوع client (موبایل، وب، دسکتاپ) BFF مخصوص خود دارد که داده‌های لازم برای آن client را جمع می‌کند.

[Mobile App]    ──► [Mobile BFF]    ─┐
                                      ├──► [Microservices]
[Web App]       ──► [Web BFF]       ─┤
                                      │
[Admin Panel]   ──► [Admin BFF]     ─┘
    

۳. Saga Pattern

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

۴. CQRS (Command Query Responsibility Segregation)

جدا کردن مدل خواندن (Query) از مدل نوشتن (Command). هر کدام می‌توانند DB متفاوتی داشته باشند. (در فصل ۸ به طور کامل بررسی می‌شود.)

۵. Event Sourcing

به جای ذخیره وضعیت فعلی، تمام تغییرات (Events) ذخیره می‌شوند و وضعیت فعلی با reply کردن آن‌ها بازسازی می‌شود.

۶. Anti-Corruption Layer (ACL)

وقتی با یک سیستم legacy یا third-party کار می‌کنید، یک لایه واسطه ایجاد کنید که مدل خارجی را به مدل داخلی ترجمه کند تا مدل شما “آلوده” نشود.

۲.۹ آنتی‌پترن‌ها (الگوهای اشتباه)

۲.۱۰ مثال عملی: طراحی فروشگاه آنلاین

بیایید یک فروشگاه آنلاین کالاهای دیجیتال را طراحی کنیم.

گام ۱: شناسایی Subdomain ها

• Core: Catalog، Order، Pricing (مزیت رقابتی)
• Supporting: Notification، Review، Recommendation
• Generic: Auth، Payment Gateway، Email Service

گام ۲: تعریف Bounded Context ها

┌─────────────────────────────────────────────────────────────┐
│                    فروشگاه آنلاین (Domain)                    │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐         │
│  │  Identity   │  │   Catalog   │  │  Inventory  │         │
│  │  Context    │  │  Context    │  │  Context    │         │
│  └─────────────┘  └─────────────┘  └─────────────┘         │
│                                                             │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐         │
│  │   Pricing   │  │    Order    │  │   Payment   │         │
│  │  Context    │  │  Context    │  │  Context    │         │
│  └─────────────┘  └─────────────┘  └─────────────┘         │
│                                                             │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐         │
│  │  Shipping   │  │Notification │  │    Review   │         │
│  │  Context    │  │  Context    │  │  Context    │         │
│  └─────────────┘  └─────────────┘  └─────────────┘         │
│                                                             │
└─────────────────────────────────────────────────────────────┘
    

گام ۳: تعریف هر سرویس

(و به همین ترتیب برای سایر سرویس‌ها)

گام ۴: تعریف Context Map

چه کسی به چه کسی وابسته است؟ چه ارتباطی sync و چه ارتباطی async است؟

                ┌──────────┐
                │ Identity │
                └────┬─────┘
                     │ JWT validates all requests
                     ▼
            ┌────────────────────┐
            │   API Gateway      │
            └─┬──────────────────┘
              │
    ┌─────────┴───────────────────────┐
    ▼                                 ▼
┌─────────┐    sync(REST)      ┌──────────┐
│ Catalog │ ◄───────────────── │  Order   │
└────┬────┘                    └────┬─────┘
     │                              │
     │ async(events)                │ async(events)
     ▼                              ▼
[RabbitMQ Event Bus] ◄─────► [All Services Subscribe]
    

۲.۱۱ بهترین تجربیات (Best Practices)

1. قبل از تقسیم، Domain را عمیق درک کنید. Event Storming یک تکنیک عالی برای این کار است.
2. با Modular Monolith شروع کنید. وقتی مرزها پایدار شدند، به میکروسرویس مهاجرت کنید.
3. هر سرویس باید independently deployable باشد. اگر این نیست، تقسیم اشتباه است.
4. هیچ‌گاه DB را به اشتراک نگذارید. این قانون طلایی است.
5. API ها را از ابتدا versioned طراحی کنید. /api/v1/products
6. از Domain Events استفاده کنید. این event ها را به عنوان first-class citizen بدانید.
7. Backward compatibility را حفظ کنید. هیچ‌گاه breaking change به API نزنید.
8. Documentation را خودکار کنید. از OpenAPI/Swagger استفاده کنید.
9. برای failure طراحی کنید. فرض کنید همه چیز fail می‌شود.
10. Observability از روز اول. Logging، Metrics، Tracing را همان ابتدا اضافه کنید.

۲.۱۲ خلاصه فصل