میکروسرویس چیست؟ تفاوت با مونولیت در نرمافزار اختصاصی
اگر میپرسید میکروسرویس چیست، پاسخ کوتاه این است: شکستن یک محصول به چند سرویس کوچک که جدا مستقر میشوند، از راه شبکه حرف میزنند، و معمولاً تیم و دادهٔ جدا دارند — نه اینکه چند پوشه در یک پروژه را با اسم سرویس صدا بزنید. در مقابل، مونولیت یک واحد استقرار است: یک برنامه که ماژولهایش با هم کامپایل یا با هم منتشر میشوند. هیچکدام ذاتاً مدرن یا عقبمانده نیستند. سؤال درست این است کدام مدل با اندازهٔ تیم، دامنهٔ محصول و هزینهٔ عملیات شما میخواند.
جستوجوهایی مثل «میکروسرویس چیست»، «تفاوت با مونولیت»، «مونولیت ماژولار»، «چه پروژهای میکروسرویس میخواهد»، «هزینه عملیاتی» و «اشتباه شروع زودهنگام» از تیمی میآید که یا از اسلاید معماری ترسیده یا میخواهد از روز اول «مثل شرکت بزرگ» بسازد. در این راهنما تعریف را از تبلیغ جدا میکنیم، مونولیت ماژولار را بهعنوان مسیر میانی میگوییم، نشانهٔ نیاز به تجزیه را مینویسیم و هزینهٔ عملیات را بدون تعرفه نشان میدهیم. ساخت محصول را از حداقل محصول قابل عرضه شروع کنید و قرارداد ارتباط را در API چیست ببینید. اجرای معماری متناسب در خدمات توسعه نرمافزار روبینش است.
The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms.
میکروسرویس چیست و از کجا با ماژول فرق دارد؟
سرویس کوچک وقتی میکروسرویس است که بتواند جدا نسخه بگیرد، جدا مقیاس شود، و شکستش کل سیستم را لزوماً با یک کلیک نکشد — هرچند در عمل وابستگیها این استقلال را محدود میکنند. ارتباط معمولاً HTTP، صف پیام یا gRPC است. هر سرویس مدل دادهٔ خودش را دارد؛ به دیتابیس همسایه مستقیم وصل نمیشود. این جداسازی هزینه دارد: تراکنش توزیعشده سخت است، دیباگ چندلایه است، و نسخهٔ قرارداد بین تیمها باید مدیریت شود.
ماژول داخل یک برنامه این هزینهها را ندارد. پوشهٔ «سفارش» و پوشهٔ «کاربر» اگر با هم دیپلوی شوند، مونولیتاند حتی اگر نام سرویس روی اسلاید باشد. این بد نیست. برای تیم پنجنفره که یک محصول میسازد، فراخوانی تابع داخل فرآیند بسیار سادهتر از شبکه است. میکروسرویس را وقتی جدی بگیرید که مرز سازمانی یا بار عملیاتی واقعاً جدا شده باشد، نه وقتی که از کلمهٔ «مدرن» خوشتان آمده.
درگاه API، احراز هویت متمرکز و مشاهدهپذیری — لاگ، ردپا، متریک — پیشنیاز این سبکند نه مرحلهٔ بعد. بدون آنها چند سرویس فقط چند نقطهٔ شکست نامرئی میسازند. اتصال به پرداخت و پیامک را با تجزیهٔ داخلی قاطی نکنید؛ آنها یکپارچهسازی با سامانهٔ بیرونیاند و در راهنمای یکپارچهسازی سیستمها جدا شدهاند. معماری داخلی میتواند مونولیت بماند و در عین حال به درگاه وصل شود.
| مدل | استقرار | هزینهٔ هماهنگی |
|---|---|---|
| مونولیت ساده | یک واحد | کم در شروع، سخت در رشد نامنظم |
| مونولیت ماژولار | یک واحد، مرز ماژول روشن | متوسط؛ مسیر تجزیهٔ بعدی باز است |
| میکروسرویس | چند واحد | بالا؛ نیاز به پلتفرم و قرارداد |
مونولیت ماژولار یعنی چه و چرا اغلب نقطه شروع بهتری است؟
مونولیت ماژولار یک برنامه است با مرزهای داخلی سخت: ماژول فروش حق ندارد جدول انبار را مستقیم دستکاری کند؛ از API داخلی همان فرآیند استفاده میکند. وابستگیها یکطرفه و مشخصاند. تست ماژول ممکن است. وقتی روزی نیاز به جدا شدن باشد، مرز از قبل وجود دارد. این مدل از «یک فایل هزارخطی» فاصله دارد و از «ده سرویس بدون پلتفرم» هم فاصله دارد.
برای استارتاپ و سامانهٔ اختصاصی سازمانی متوسط، این معمولاً مسیر عقلی است. نسخهٔ اول باید فرضیه را بیازماید نه اینکه ارکستر کانتینر را اثبات کند. در برنامهنویسی اختصاصی چیست هم مسیر از تحلیل و نسخهٔ محدود شروع میشود. مونولیت ماژولار با همان فازبندی سازگار است: یک جریان، یک استقرار، مرزهای آماده برای فردا.
اشتباه رایج این است که مونولیت را با کد درهمتنیده یکی بدانید. مونولیت درهمتنیده بوی بد میدهد؛ مونولیت منظم میتواند سالها مقیاس معقول را تحمل کند. بسیاری از محصولات موفق دیر تجزیه شدند، وقتی تیم و ترافیک جدا شدن را توجیه کرد. زود تجزیه شدن، هزینهٔ پلتفرم را روی محصولی میگذارد که هنوز مشتری ثابت ندارد. اگر امروز سه نفر همهٔ کد را مینویسند، استقلال انتشار شعار است نه نیاز. اول مرز ماژول را در کد و تست سفت کنید تا فردا جدا کردن یک سرویس جراحی باشد نه بازسازی کامل.
معیار ماژولار بودن ساده است: آیا میتوانید ماژول انبار را بدون دست زدن به جداول فروش تغییر دهید؟ آیا تست واحد آن بدون بالا آوردن کل برنامه معنا دارد؟ اگر پاسخ منفی است، شبکه کردن همان کد فقط وابستگی را گرانتر میکند. زمان بگذارید وابستگیها یکطرفه شوند. این کار خستهکننده است و در دمو دیده نمیشود، اما همان جایی است که بعداً تجزیهٔ واقعی ممکن میشود. بدون آن، میکروسرویس فقط نام جدید برای همان گره است.
چه پروژهای واقعاً میکروسرویس میخواهد؟
نشانهٔ نیاز معمولاً فنیِ محض نیست. تیمهای جدا که باید مستقل منتشر شوند، بار خیلی متفاوت روی بخشها — مثلاً جستوجو در برابر صدور فاکتور — الزام قانونی جداسازی داده، یا مقیاس جغرافیایی. اگر یک تیم کوچک همهٔ کد را مینویسد و همه با هم منتشر میکنند، تجزیه استقرار سود کمی دارد و اصطکاک زیادی میآورد. «شاید بعداً ده میلیون کاربر» دلیل کافی نیست.
فروشگاه در حال رشد ممکن است روزی فهرست محصول را از تسویه جدا کند چون الگوی بار فرق دارد. کلینیک کوچک با نوبت و پرونده تقریباً هیچوقت از روز اول به این تجزیه نیاز ندارد. اگر مسئلهٔ شما دیده شدن مطب است، معماری سرویس آن را حل نمیکند؛ سئو سایت پزشکی نیت جداست. اگر مسئلهٔ شما سبد و موجودی روی وب است، اول سایت فروشگاهی و یک هستهٔ منسجم، بعد اگر بار جدا شد تجزیه.
سرویس بیرونی — درگاه، پیامک، نقشه — را با میکروسرویس داخلی اشتباه نگیرید. آنها همیشه «سرویس دیگران»اند. شما میتوانید در مونولیت به آنها وصل شوید. تجزیهٔ داخلی وقتی معنا دارد که مرز دامنهٔ خودتان پایدار شده باشد. دامنهای که هر هفته عوض میشود را شبکه نکنید؛ هزینهٔ عوض کردن قرارداد چندبرابر میشود.
هزینه عملیاتی میکروسرویس از کجا میآید؟
هزینه فقط سرور بیشتر نیست. هر سرویس یعنی خط لولهٔ انتشار، پیکربندی، رازها، سلامت، مقیاس، و کسی که ساعت سه شب بفهمد کدام قطعه خوابیده. مشاهدهپذیری توزیعشده، صف، و سیاست تلاش مجدد لازم میشوند. استخدام و آموزش هم عوض میشود: دیباگ یک درخواست که از چهار سرویس گذشته مهارت جدا میخواهد. اینها را در برآورد ببینید؛ جزئیات بدون عدد ساختگی در هزینه برنامهنویسی اختصاصی آمده است.
تراکنش کسبوکار که چند سرویس را درگیر میکند — کم کردن موجودی و ثبت پرداخت — در مونولیت یک تراکنش دیتابیس است و در میکروسرویس معمولاً داستان سازگاری تدریجی، پیام و جبران. اگر تیم این مدل را نشناسد، موجودی و پول از هم جدا میشوند. برای اتصال پرداخت، اول یکپارچهسازی درست مهمتر از خرد کردن سرویس است.
پلتفرم داخلی — کانتینر، مش، کاتالوگ سرویس — خودش یک محصول است. شرکت بزرگ این پلتفرم را با تیم جدا میسازد. کپی کردن ظاهر آن بدون تیم پلتفرم، یعنی برنامهنویس محصول نیمی از وقت را صرف YAML میکند. اگر ظرفیت پلتفرم ندارید، مونولیت ماژولار انتخاب مسئولانهتری است. سؤال عملی در برآورد این است: بعد از نیمه شب، چه کسی لاگ چهار سرویس را کنار هم میگذارد؟ اگر جواب «همان یک برنامهنویس محصول» است، هنوز برای تجزیه زود است.
هزینهٔ هماهنگی انسان را هم حساب کنید. هر سرویس یعنی جلسهٔ قرارداد، نسخهٔ فیلد، و منتظر ماندن تیم دیگر برای انتشار. در سازمان بزرگ این تقسیم کار است؛ در تیم کوچک این صف داخلی است. اگر انتشار شما هفتهای یکبار است و همه با هم منتشر میکنند، سود استقلال استقرار نزدیک صفر است. همان انرژی را روی تست، مشاهدهپذیری یک برنامه، و محدودهٔ نسخه اول بگذارید. معماری باید سرعت یادگیری را بالا ببرد نه اینکه تقویم را پر از کار زیرساختی کند.
اشتباه شروع زودهنگام با میکروسرویس چیست؟
شروع زودهنگام یعنی مرز دامنه هنوز مشخص نیست و شما آن را با شبکه قفل میکنید. هر تغییر محصول میشود تغییر قرارداد بین سرویسها. نسخهٔ اول که باید در هفتهها یاد بگیرد، در ماهها صرف هماهنگی میشود. تیم کوچک context switching بین چند مخزن را با بهرهوری اشتباه میگیرد. تست انتهابهانتها شکننده میشود و کسی جرئت تغییر نمیکند.
اشتباه دوم کپی کردن اسلاید شرکت اینترنتی بزرگ است. آنها ترافیک، تیم و سالها بدهی مونولیت داشتند که تجزیه را توجیه کرد. شما آن تاریخچه را ندارید. اشتباه سوم دیتابیس مشترک بین سرویسهاست: ظاهر میکروسرویس با واقعیت مونولیت پنهان. اگر جدا شدن داده سخت است، هنوز برای تجزیه زود است؛ اول مرز ماژول را سفت کنید.
اشتباه چهارم فراموش کردن تجربهٔ توسعه است. محیط لوکال با ده کانتینر برای بنیانگذار غیرفنی و حتی برای تیم کوچک فرساینده است. سرعت یادگیری محصول پایین میآید. معماری باید به نسخهٔ اول قابل عرضه خدمت کند نه اینکه آن را گروگان بگیرد. بعد از ثبات دامنه، یک سرویس را جدا کنید — معمولاً آن که بار یا تیم جدا دارد — نه همه را یکشبه.
اشتباهات رایج در انتخاب معماری
- نامیدن پوشهها بهعنوان میکروسرویس بدون استقرار جدا
- دیتابیس مشترک بین سرویسهای بهظاهر جدا
- شروع تجزیه قبل از محصول و تیم پایدار
- نادیده گرفتن لاگ، ردپا و مالکیت عملیات
- تراکنش توزیعشده بدون الگوی جبران
- کپی پلتفرم شرکت بزرگ بدون تیم پلتفرم
- وصل کردن معماری داخلی با هیجان به همهٔ APIهای ثالث از روز اول
معماری خوب به سؤال کسبوکار جواب میدهد: با این تیم، این دامنه، این ریسک عملیات، کدام مدل تغییر را ارزانتر میکند؟ پاسخ برای سامانهٔ داخلی پنجنفره معمولاً مونولیت ماژولار است. پاسخ برای بخشی با بار جدا و تیم جدا ممکن است یک سرویس جدا باشد، نه دوازده سرویس. تصمیم را روی کاغذ با نام تیم و الگوی بار بنویسید تا جلسه از سلیقه به مسیر برسد. اگر هنوز نسخهٔ اول مشتری ندارد، معماری تجزیه را عقب ببرید و همان انرژی را صرف تمام شدن یک جریان واقعی کنید.
چکلیست قبل از تجزیه به سرویسها
- مرز دامنه روی کاغذ پایدار است و چند ماه عوض نشده.
- دلیل تجزیه نوشته شده: تیم، بار، یا الزام — نه مد.
- مونولیت فعلی ماژولار است یا اول باید مرتب شود.
- مالک عملیات، لاگ و هشدار مشخص است.
- قرارداد API بین مرزها نسخهبندی دارد.
- الگوی پیام و جبران برای کار پولی و موجودی فکر شده است.
- محیط توسعه برای تیم قابل تحمل است.
- نسخهٔ اول محصول هنوز گروگان پلتفرم نشده است.
جمعبندی: مرز روشن، استقرار متناسب با تیم
میکروسرویس چیست؟ مجموعهای از سرویسهای کوچک با فرآیند و ارتباط شبکه، نه چند پوشه. مونولیت ماژولار برای بیشتر پروژههای اختصاصی نقطهٔ شروع بهتری است. تجزیه وقتی معنا دارد که تیم، بار یا قانون واقعاً جدا شده باشد. هزینهٔ عملیاتی از انتشار، مشاهدهپذیری و تراکنش توزیعشده میآید. شروع زودهنگام یادگیری محصول را کند میکند.
برای انتخاب معماری متناسب با فرآیند واقعی، صفحه برنامهنویسی اختصاصی روبینش و مشاوره را ببینید. اول محصول کوچک و مرز ماژول، بعد تجزیهٔ انتخابی. اسلاید شرکت بزرگ را با ظرفیت تیم خودتان عوض نکنید. یک جریان پایدار روی یک استقرار، از دوازده سرویس نیمهمستند برای شروع مفیدتر است.
سؤالات متداول
چند پوشه با نام سرویس همان میکروسرویس است؟
خیر. اگر با هم مستقر میشوند و دیتابیس مشترک دارند، مونولیتاند. میکروسرویس یعنی فرآیند جدا، قرارداد شبکه و معمولاً داده جدا.
استارتاپ باید از روز اول میکروسرویس بسازد؟
معمولاً نه. نسخه اول باید فرضیه بازار را بیازماید. مونولیت ماژولار برای تیم کوچک سریعتر است؛ تجزیه وقتی تیم، بار یا قانون جدا شد معنا دارد.
اتصال درگاه پرداخت یعنی باید میکروسرویس داشته باشیم؟
خیر. درگاه سرویس بیرونی است. مونولیت هم میتواند به پرداخت و پیامک وصل شود. تجزیه داخلی را با یکپارچهسازی ثالث قاطی نکنید.
هزینه میکروسرویس فقط سرور بیشتر است؟
خیر. انتشار جدا، مشاهدهپذیری، صف، دیباگ توزیعشده و مالک عملیات بخش بزرگ هزینهاند. بدون تیم پلتفرم این بار روی محصول میافتد.
انتخاب معماری را از کدام صفحه پیش ببریم؟
مسیر اجرا در صفحه برنامهنویسی اختصاصی روبینش است. این مقاله معیار انتخاب را میگوید تا اسلاید شرکت بزرگ جایگزین ظرفیت تیم نشود.