پاسخ کوتاه
پیش از انتخاب معماری، سناریوهای بار، سطح دسترسپذیری، مرز داده، اتصالها، روش استقرار و توان پشتیبانی را مستند کنید. اگر محصول هنوز در مرحله شناخت بازار است و یک تیم کوچک آن را توسعه میدهد، معماری ساده و ماژولار معمولاً هزینه و ریسک کمتری دارد. میکروسرویس زمانی ارزش بررسی دارد که دامنههای مستقل، تیمهای مستقل، انتشارهای پرتکرار یا نیاز به مقیاس جداگانه واقعاً وجود داشته باشد.
قبل از نام معماری، نیازهای غیرعملکردی را عددی کنید
دو سامانه با امکانات ظاهراً مشابه ممکن است معماری متفاوتی بخواهند. تعداد کاربران همزمان، ساعات اوج، حجم فایل و تراکنش، زمان پاسخ قابل قبول، مدت توقف مجاز، محل استقرار و روش بازیابی باید قبل از تصمیم ثبت شوند.
بار و رشد
- پرسش قابل اندازهگیری
- امروز و ۱۸ ماه بعد چند کاربر یا تراکنش داریم؟
- خروجی مورد انتظار
- سناریوی بار عادی، اوج و رشد
دسترسپذیری
- پرسش قابل اندازهگیری
- چه مدت توقف در ماه قابل تحمل است؟
- خروجی مورد انتظار
- هدف خدمت و سناریوی بازیابی
داده
- پرسش قابل اندازهگیری
- کدام داده حساس، حجیم یا نیازمند نگهداری است؟
- خروجی مورد انتظار
- مالکیت، پشتیبانگیری و دوره نگهداری
تغییر
- پرسش قابل اندازهگیری
- کدام بخشها مستقل و پرتکرار تغییر میکنند؟
- خروجی مورد انتظار
- مرز ماژول و برنامه انتشار
عملیات
- پرسش قابل اندازهگیری
- چه کسی استقرار، مانیتورینگ و رخداد را مدیریت میکند؟
- خروجی مورد انتظار
- مسئولیت و ابزار عملیاتی
گزینهها را بر اساس هزینه و پیچیدگی مقایسه کنید
لایهای یا مونولیت ساده
- مناسب برای
- دامنه روشن، تیم کوچک و انتشار یکپارچه
- هزینه یا ریسک اصلی
- وابستگی زیاد در صورت نبود مرز داخلی
مونولیت ماژولار
- مناسب برای
- محصول در حال رشد با ماژولهای کسبوکاری مشخص
- هزینه یا ریسک اصلی
- نیاز به انضباط در مرز و وابستگی ماژولها
Web-Queue-Worker
- مناسب برای
- پردازشهای طولانی، گزارش، فایل یا کار پسزمینه
- هزینه یا ریسک اصلی
- مدیریت صف، تکرار پیام و وضعیت کار
میکروسرویس
- مناسب برای
- دامنه پیچیده، تیمهای مستقل و مقیاس جداگانه
- هزینه یا ریسک اصلی
- شبکه، سازگاری داده، مشاهدهپذیری و DevOps
رویدادمحور
- مناسب برای
- IoT، اعلان یا جریان بلادرنگ بین چند بخش
- هزینه یا ریسک اصلی
- اشکالزدایی، ترتیب و تکرار رویدادها
نکته: معماری میتواند ترکیبی باشد؛ مثلاً هسته ماژولار بماند و فقط پردازش فایل یا اعلان به Worker جدا منتقل شود.
برای میکروسرویس یک دروازه تصمیم واقعی بگذارید
تقسیم یک سیستم به سرویسهای شبکهای، پیچیدگی را حذف نمیکند؛ آن را از داخل کد به ارتباط، داده و عملیات منتقل میکند. اگر سرویسها مالک داده مستقل ندارند یا همیشه با هم منتشر میشوند، جداسازی ممکن است فقط سربار ایجاد کند.
- آیا هر سرویس یک قابلیت کسبوکاری و مالک مشخص دارد؟
- آیا حداقل یک بخش باید مستقل از بقیه مقیاس یا منتشر شود؟
- آیا تیم CI/CD، مانیتورینگ، لاگ متمرکز و Trace توزیعشده دارد؟
- آیا Retry، Timeout، Circuit Breaker و پیام تکراری طراحی شدهاند؟
- آیا مدل سازگاری داده و جبران تراکنش شکستخورده روشن است؟
- آیا منفعت تصمیم از هزینه عملیاتی سهساله بیشتر است؟
از تیم فنی چه خروجیهایی تحویل بگیریم؟
- نمودار زمینه و اجزای اصلی با مرز سامانههای بیرونی
- فهرست تصمیمهای مهم معماری همراه با گزینههای ردشده و دلیل تصمیم
- مدل استقرار محیط آزمایش و تولید، وابستگیها و مالک حسابها
- مدل داده، مالکیت هر بخش و مسیر مهاجرت یا Export
- سناریوی خطا، Backup، بازیابی و بازگشت نسخه
- طرح مانیتورینگ شامل سلامت، خطا، کارایی و هشدارهای قابل اقدام
- آزمون بار متناسب با سناریوی واقعی و معیار پذیرش عددی
معماری را به قرارداد و هزینه مالکیت وصل کنید
نمودار معماری زمانی ارزش دارد که روی هزینه، زمان و مسئولیت اثر آن روشن باشد. سرویس ابری، صف، پایگاه داده، ابزار مانیتورینگ و محیطهای جدا هزینه جاری دارند و باید کنار هزینه توسعه دیده شوند.
- فرضهای بار و رشد را ضمیمه محدوده پروژه کنید.
- هزینه زیرساخت در حالت عادی و اوج را جدا برآورد کنید.
- مسئول Patch، Backup، رخداد و تمدید سرویسها را مشخص کنید.
- مالکیت کد، حساب ابری، دامنه، گواهی و Secretها را شفاف کنید.
- بازبینی معماری را در نقاط رشد محصول برنامهریزی کنید، نه در هر تغییر کوچک.
پرسشهای متداول
آیا میکروسرویس همیشه مقیاسپذیرتر است؟
امکان مقیاس مستقل میدهد، اما فقط با طراحی داده، شبکه و عملیات مناسب. برای بسیاری از سامانهها، چند نمونه از یک برنامه ماژولار سادهتر و کافی است.
مونولیت ماژولار چیست؟
یک برنامه واحد برای استقرار است که داخل آن قابلیتهای کسبوکار با مرز و قرارداد روشن جدا شدهاند. این الگو میتواند سادگی عملیات را با امکان تکامل تدریجی ترکیب کند.
آیا معماری را باید قبل از قرارداد نهایی کرد؟
تصمیمهای اثرگذار بر هزینه و ریسک باید روشن شوند، اما جزئیات میتوانند در مرحله شناخت تکمیل شوند. قرارداد باید خروجی این مرحله و نحوه تأیید آن را مشخص کند.
چه زمانی بازبینی معماری لازم است؟
هنگام تغییر جدی بار، تیم، مدل داده، الزامات دسترسپذیری یا اتصالهای حیاتی؛ نه صرفاً به دلیل انتشار یک فناوری جدید.
خدمت و راهنماهای مرتبط
برای ادامه مسیر، صفحه خدمت مرتبط، نمونهکار و راهنماهای مکمل را ببینید.
منابع و مبنای تدوین
این راهنما با استفاده از مستندات فنی و منابع تخصصی زیر تدوین شده است. تصمیم نهایی هر پروژه باید با دادهها، قرارداد و شرایط واقعی همان سازمان تطبیق داده شود.