// chapter_01.md

مقدمه و مفاهیم میکروسرویس

معماری میکروسرویس‌ها (Microservices Architecture) یکی از مهم‌ترین تحولات در طراحی نرم‌افزارهای مدرن است. در این فصل با مفاهیم پایه آشنا می‌شویم و درک می‌کنیم که چه زمانی این معماری انتخاب درستی است.

۱.۱ مقدمه

هدف این فصل: پس از مطالعه این فصل، تفاوت Monolith و Microservice را درک می‌کنید، می‌دانید چه زمانی از کدام استفاده کنید، و با اصطلاحات کلیدی این حوزه آشنا می‌شوید.

۱.۲ میکروسرویس چیست؟

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

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

تعریف Martin Fowler

طبق تعریف معروف Martin Fowler و James Lewis: «میکروسرویس‌ها یک رویکرد طراحی نرم‌افزار هستند که در آن یک برنامه واحد به عنوان مجموعه‌ای از سرویس‌های کوچک ساخته می‌شود، که هر کدام در پروسس خود اجرا شده و از طریق مکانیزم‌های سبک ارتباط برقرار می‌کنند.»

۱.۳ Monolith در مقابل Microservice

معماری Monolithic چیست؟

در معماری مونولیتیک، تمام قابلیت‌های یک برنامه در یک کدبیس واحد قرار دارند و به عنوان یک واحد یکپارچه deploy می‌شوند. مثلاً یک فروشگاه آنلاین مونولیتیک شامل ماژول‌های کاربر، محصول، سفارش، پرداخت و… همه در یک پروژه Django هستند.

مقایسه دقیق

ویژگی	Monolith	Microservice
کدبیس	یک پروژه واحد	چندین پروژه مستقل
پایگاه داده	یک DB مرکزی	هر سرویس DB خود را دارد
Deployment	یکپارچه (همه با هم)	مستقل (هر سرویس جداگانه)
مقیاس‌پذیری	کل برنامه با هم scale می‌شود	هر سرویس مستقل scale می‌شود
تکنولوژی	یک Stack ثابت	Polyglot (هر سرویس می‌تواند متفاوت باشد)
پیچیدگی توسعه اولیه	کم	زیاد
پیچیدگی عملیاتی	کم	زیاد (نیاز به DevOps قوی)
زمان عرضه	سریع برای پروژه‌های کوچک	سریع برای پروژه‌های بزرگ
تست	ساده‌تر	پیچیده‌تر (نیاز به integration test)
Debugging	ساده (یک پروسس)	دشوار (distributed)
Fault Isolation	ضعیف (یک خطا کل برنامه را می‌اندازد)	قوی (خطا در یک سرویس)
تیم	یک تیم بزرگ	چند تیم کوچک مستقل

۱.۴ مثال عملی: یک فروشگاه آنلاین

نسخه Monolithic

در یک فروشگاه مونولیتیک با Django:


# project/settings.py
INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    # همه ماژول‌ها در یک پروژه
    'apps.users',        # مدیریت کاربران
    'apps.products',     # محصولات
    'apps.orders',       # سفارش‌ها
    'apps.payments',     # پرداخت
    'apps.shipping',     # ارسال
    'apps.inventory',    # موجودی
    'apps.notifications',# اطلاع‌رسانی
]

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql',
        'NAME': 'shop_db',  # یک پایگاه داده برای همه
        'HOST': 'localhost',
    }
}

نسخه Microservice

همان فروشگاه به صورت میکروسرویس:


┌─────────────────────────────────────────────────────────┐
│                    API Gateway (Kong)                    │
│                  https://api.shop.com                    │
└──────┬──────────────────────────────────────────────────┘
       │
       ├──────► User Service (Django)        :8001  → users_db
       │
       ├──────► Product Service (FastAPI)    :8002  → products_db
       │
       ├──────► Order Service (Django)       :8003  → orders_db
       │
       ├──────► Payment Service (FastAPI)    :8004  → payments_db
       │
       ├──────► Shipping Service (FastAPI)   :8005  → shipping_db
       │
       ├──────► Inventory Service (Django)   :8006  → inventory_db
       │
       └──────► Notification Service (Celery):8007  → (RabbitMQ)
       
       همه از طریق RabbitMQ با هم event می‌فرستند

هر سرویس:

پایگاه داده مستقل خود را دارد
مستقل deploy می‌شود
تیم اختصاصی می‌تواند داشته باشد
بر اساس نیاز scale می‌شود (مثلاً Product Service که بیشترین ترافیک دارد)

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

🚀 مقیاس‌پذیری مستقل

هر سرویس می‌تواند به طور مستقل و بر اساس نیاز خود مقیاس شود. مثلاً اگر سرویس محصولات ترافیک بالایی دارد، می‌توانید فقط آن را scale کنید بدون اینکه نیاز باشد سایر سرویس‌ها را هم scale کنید.

🛠️ آزادی تکنولوژی (Polyglot)

هر سرویس می‌تواند با بهترین زبان و فریم‌ورک برای کار خود نوشته شود. مثلاً سرویس ML با Python، سرویس real-time با Go، و سرویس‌های CRUD با Django.

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

هر تیم می‌تواند روی سرویس خود کار کند بدون اینکه نیاز به هماهنگی با سایر تیم‌ها داشته باشد. این موضوع سرعت توسعه را به شدت افزایش می‌دهد.

🔄 Deployment مستقل

می‌توانید یک سرویس را به‌روزرسانی کنید بدون اینکه کل سیستم را restart کنید. این باعث افزایش availability و کاهش downtime می‌شود.

🛡️ Fault Isolation

اگر یک سرویس crash کند، کل سیستم از کار نمی‌افتد. می‌توانید با استفاده از Circuit Breaker و Fallback، تجربه کاربری قابل قبولی حتی در صورت خرابی سرویس‌ها داشته باشید.

📦 Reusability

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

۱.۶ معایب و چالش‌های میکروسرویس

هشدار: میکروسرویس یک silver bullet نیست! پیچیدگی‌های زیادی به همراه می‌آورد که باید آماده مدیریت آن‌ها باشید.

⚠️ پیچیدگی Distributed System

شبکه غیرقابل اعتماد است (Network is unreliable). باید با تأخیر، قطع ارتباط، timeout و partial failure مقابله کنید. مفاهیم CAP theorem و eventual consistency باید کاملاً درک شوند.

⚠️ پیچیدگی عملیاتی

به جای یک سرویس، باید ده‌ها سرویس را monitor، deploy و مدیریت کنید. نیاز به DevOps قوی، CI/CD، Kubernetes یا ابزار orchestration دارید.

⚠️ Distributed Transactions

تراکنش‌های ACID که در Monolith ساده هستند، در میکروسرویس بسیار پیچیده می‌شوند. باید از الگوهایی مثل Saga یا Two-Phase Commit استفاده کنید.

⚠️ Debugging سخت

پیگیری یک درخواست که از چندین سرویس عبور کرده دشوار است. نیاز به Distributed Tracing (Jaeger، Zipkin) و Centralized Logging (ELK) دارید.

⚠️ Data Consistency

به دلیل اینکه هر سرویس DB خود را دارد، حفظ سازگاری داده‌ها چالش بزرگی است. باید با Eventual Consistency کنار بیایید و الگوهای Outbox و CQRS را پیاده کنید.

⚠️ هزینه زیرساخت

اجرای ده‌ها container و سرویس به منابع سخت‌افزاری بیشتری نیاز دارد. هزینه infrastructure معمولاً ۲ تا ۳ برابر Monolith است.

⚠️ Team Coordination

تعریف API contract بین سرویس‌ها، مدیریت ورژن‌ها، و هماهنگی تیم‌ها برای تغییرات breaking نیاز به فرآیندهای دقیق دارد.

⚠️ Network Latency

به جای function call، شما در حال HTTP request هستید. این باعث افزایش latency و کاهش throughput می‌شود. باید با تکنیک‌هایی مثل caching، gRPC و bulk endpoints به این مشکل بپردازید.

۱.۷ چه زمانی از میکروسرویس استفاده کنیم؟

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

تیم بزرگ: بیش از ۲۰ توسعه‌دهنده که نیاز به کار موازی دارند
پروژه پیچیده: با domain های متعدد و مرزهای مشخص
نیازهای مقیاس‌پذیری متفاوت: برخی بخش‌ها ترافیک ۱۰۰ برابر بیشتر از بقیه دارند
زمان طولانی توسعه: پروژه‌های ۲+ ساله که قرار است طولانی‌مدت توسعه یابند
نیاز به تکنولوژی متنوع: ML، real-time، batch processing در یک سیستم
تیم DevOps قوی: امکان اجرای Kubernetes، monitoring پیشرفته
الزامات availability بالا: 99.99% uptime که نیاز به fault isolation دارد

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

تیم کوچک: کمتر از ۱۰ نفر
MVP و Startup: در مرحله اعتبارسنجی ایده هستید
پروژه‌های کوچک: CRUD ساده با چند ماژول
نبود تخصص DevOps: تیم تجربه Docker و Kubernetes ندارد
محدودیت بودجه: هزینه زیرساخت برای چندین سرویس قابل تأمین نیست
نیاز به consistency قوی: سیستم‌های مالی پیچیده با تراکنش‌های متعدد

توصیه طلایی: Monolith First

توصیه شخصیت‌هایی مانند Martin Fowler و Sam Newman این است: «با Monolith شروع کنید». وقتی domain شما بالغ شد، مرزها مشخص شدند و تیم بزرگ شد، آنگاه به تدریج (با الگوی Strangler Fig) به میکروسرویس مهاجرت کنید.

۱.۸ اصطلاحات کلیدی

Service

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

API Gateway

یک نقطه ورود مرکزی برای همه درخواست‌ها که آن‌ها را به سرویس مناسب route می‌کند. مسئولیت‌هایی مثل authentication، rate limiting و logging دارد.

Service Discovery

مکانیزمی که به سرویس‌ها امکان می‌دهد یکدیگر را در محیط داینامیک پیدا کنند. ابزارهای رایج: Consul، Eureka، Kubernetes DNS.

Message Broker

یک سرویس واسطه که پیام‌ها را بین سرویس‌ها رد و بدل می‌کند. مثال‌ها: RabbitMQ، Apache Kafka، Redis Streams.

Bounded Context

مفهومی از Domain-Driven Design که مرزی مشخص بین domain های مختلف یک سیستم تعریف می‌کند. هر میکروسرویس معمولاً یک Bounded Context را پیاده‌سازی می‌کند.

Saga Pattern

الگویی برای مدیریت تراکنش‌های توزیع‌شده با تجزیه آن‌ها به مجموعه‌ای از تراکنش‌های محلی و تعریف عملیات جبرانی (compensation) برای رفع خطا.

Circuit Breaker

الگویی برای جلوگیری از cascading failure. وقتی یک سرویس بارها fail می‌کند، circuit breaker «باز» می‌شود و درخواست‌های بعدی بدون تماس با سرویس fail می‌کنند.

Eventual Consistency

مدلی از consistency که در آن داده‌ها در طول زمان به حالت سازگار می‌رسند، نه فوراً. این مدل برای میکروسرویس‌ها متداول است.

Container

واحد packaging سبک‌وزن که سرویس و وابستگی‌هایش را با هم بسته‌بندی می‌کند. Docker رایج‌ترین تکنولوژی containerization است.

Orchestration

فرآیند مدیریت container ها در مقیاس بزرگ. Kubernetes استاندارد industry برای container orchestration است.

Service Mesh

لایه‌ای از زیرساخت که ارتباط بین سرویس‌ها را مدیریت می‌کند. ویژگی‌هایی مثل mTLS، load balancing و retry را به صورت خودکار فراهم می‌کند. مثال: Istio، Linkerd.

Observability

توانایی درک حالت داخلی سیستم از روی خروجی‌های آن. سه ستون آن: Logging، Metrics و Tracing است.

۱.۹ تاریخچه مختصر

۲۰۰۵

Service-Oriented Architecture (SOA)

پیش از میکروسرویس، SOA با ESB های سنگین رایج بود. مشکلات: پیچیدگی، vendor lock-in، performance ضعیف.

۲۰۰۹

Netflix به سمت میکروسرویس

Netflix پس از یک قطعی بزرگ تصمیم گرفت از datacenter به cloud (AWS) مهاجرت کند و معماری خود را به میکروسرویس تغییر دهد. ابزارهایی مثل Eureka و Hystrix از این مهاجرت متولد شدند.

۲۰۱۱

اصطلاح “Microservices”

اولین بار در یک workshop در Venice مطرح شد. در ۲۰۱۲ Adrian Cockcroft از Netflix آن را عمومی کرد.

۲۰۱۳

Docker معرفی شد

ظهور Docker، containerization را به جریان اصلی توسعه آورد و میکروسرویس را عملی‌تر کرد.

۲۰۱۴

مقاله معروف Martin Fowler

Martin Fowler و James Lewis مقاله‌ای جامع درباره میکروسرویس‌ها منتشر کردند که این رویکرد را به جریان اصلی صنعت آورد. همچنین Kubernetes توسط Google معرفی شد.

۲۰۱۸+

Service Mesh و Serverless

Istio (2017) و Linkerd ظهور کردند. سپس Serverless و FaaS به عنوان evolution بعدی میکروسرویس‌ها مطرح شدند.

۲۰۲۲+

دوران بازنگری

شرکت‌هایی مثل Amazon Prime Video و دیگران از میکروسرویس به سمت “Modular Monolith” برگشتند. درس مهم: میکروسرویس برای همه پروژه‌ها مناسب نیست.

۱.۱۰ شرکت‌های موفق در استفاده از میکروسرویس

🎬 Netflix

پیشگام میکروسرویس. بیش از ۷۰۰ سرویس مستقل دارد. هر روز هزاران deployment انجام می‌دهد. ابزارهای متن‌باز Netflix OSS (Eureka، Hystrix، Zuul) شکل‌دهنده اکوسیستم میکروسرویس بودند.

📦 Amazon

از اوایل دهه ۲۰۰۰ به میکروسرویس مهاجرت کرد. قانون “Two Pizza Team” — هر تیم باید کوچک باشد که با دو پیتزا سیر شود. AWS خود محصول این تجربه است.

🚗 Uber

بیش از ۲۲۰۰ میکروسرویس. اخیراً به سمت ساده‌سازی و تجمیع برخی سرویس‌ها رفته است (Domain-Oriented Microservice Architecture).

🎵 Spotify

مدل “Squad” برای تیم‌های مستقل. هر Squad مالک یک یا چند میکروسرویس است و آزادی کامل در انتخاب تکنولوژی دارد.

درس مهم: این شرکت‌ها پس از رشد بزرگ به میکروسرویس مهاجرت کردند، نه از ابتدا. Twitter با Ruby on Rails (Monolith) شروع شد. Facebook هنوز بسیاری از قسمت‌هایش Monolithic است (در PHP/Hack).

۱.۱۱ پیش‌نیازهای فنی

برای موفقیت در پیاده‌سازی میکروسرویس، تیم شما باید تخصص‌های زیر را داشته باشد یا کسب کند:

توسعه

Python (Django / FastAPI)
REST API و gRPC
Async programming
Testing (unit, integration)

پایگاه داده

PostgreSQL / MySQL
Redis (cache & queue)
NoSQL (MongoDB)
Database migration

زیرساخت

Linux administration
Docker و Compose
Kubernetes (پیشرفته)
Networking و DNS

DevOps

Git و GitHub Actions
CI/CD pipelines
Infrastructure as Code (Terraform)
Monitoring (Prometheus, Grafana)

امنیت

HTTPS و TLS
JWT و OAuth 2.0
API security (OWASP)
Secret management

معماری

Domain-Driven Design
Design Patterns
System Design
Distributed systems

۱.۱۲ مسیر یادگیری در این دوره

این دوره ۱۵ فصل دارد که به ترتیب زیر شما را از مفاهیم پایه تا پیاده‌سازی Production-grade می‌برد:

🌱 مرحله مفاهیم (فصل‌های ۱-۳)

درک پایه میکروسرویس، اصول طراحی DDD، و الگوهای ارتباطی Sync/Async

🔧 مرحله ابزارها (فصل‌های ۴-۶)

یادگیری API Gateway، Service Discovery، و Message Brokers (RabbitMQ، Kafka)

🎯 مرحله الگوها (فصل‌های ۷-۹)

الگوهای پیشرفته Saga، Event-Driven Architecture، و Resilience

🚀 مرحله استقرار (فصل‌های ۱۰-۱۲)

Docker، Kubernetes و Observability برای محیط Production

🛡️ مرحله enterprise (فصل‌های ۱۳-۱۴)

امنیت پیشرفته، Service Mesh و CI/CD برای میکروسرویس‌ها

🏆 پروژه عملی (فصل ۱۵)

پیاده‌سازی کامل یک سیستم e-commerce میکروسرویس از صفر

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

آنچه آموختیم:

میکروسرویس یک سبک معماری است که برنامه را به سرویس‌های کوچک مستقل تقسیم می‌کند
تفاوت‌های کلیدی Monolith و Microservice در کدبیس، DB، deployment و مقیاس‌پذیری
مزایا: مقیاس‌پذیری مستقل، آزادی تکنولوژی، fault isolation، تیم‌های مستقل
معایب: پیچیدگی distributed، نیاز به DevOps قوی، مشکل debugging و consistency
میکروسرویس برای پروژه‌های بزرگ با تیم‌های بزرگ مناسب است، نه برای MVP و startup
توصیه: «Monolith First» — با Monolith شروع کنید و در صورت نیاز مهاجرت کنید
اصطلاحات کلیدی: API Gateway، Service Discovery، Message Broker، Bounded Context، Saga، Circuit Breaker، Eventual Consistency، Service Mesh

در فصل بعد: با اصول طراحی میکروسرویس آشنا می‌شویم، شامل Domain-Driven Design، Bounded Context، اصل Single Responsibility، و الگوی «Database per Service».

صفحه اصلی
فصل بعد: اصول طراحی