راهنمای جدید TechForge هشدار میدهد که بسیاری از پروژههای نوپای میکروسرویس در نهایت به «مونولیتهای توزیعشده» (distributed monoliths) تبدیل میشوند که بدون هیچگونه مزیت مقیاسپذیری، تنها تأخیرِ فراخوانیهای شبکه را تحمیل میکنند. این مقاله از تیمهای مهندسی میخواهد که با یک مونولیت (monolith) مستحکم شروع کنند و تنها زمانی آن را تجزیه کنند که نیازهای مشخصی برای مقیاسپذیری یا مالکیت (ownership) ایجاد شود.
چرا تیمها برای ورود به دنیای میکروسرویسها عجله میکنند
جذابیت میکروسرویسها بدیهی است: سرویسهای مستقل، استقرارهای مجزا و وعده مقیاسپذیری هر بخش از اپلیکیشن به روشهای خود. فرهنگ استارتاپی و داستانهای موفقیت اخیر، این الگو را به نشانهای از مهندسی مدرن تبدیل کرده است. با این حال، تجزیه زودهنگام یک مونولیت اغلب نوع جدیدی از مونولیت را ایجاد میکند: دهها جزء شبکهای شده. هزینه آن چیست؟ تأخیر بیشتر، عیبیابی دشوارتر و هزینههای عملیاتی بالاتر، در حالی که مزایای اصلی همچنان دور از دسترس باقی میمانند.
اولین اشتباه: شروع با مونولیتی که فقط در نام مونولیت است
تیمها اغلب یک سیستم را «مبتنی بر میکروسرویس» برچسب میزنند، در حالی که همچنان از یک کدبیس واحد و یک پایگاه داده مشترک استفاده میکنند. نتیجه، مجموعهای از ماژولهای با وابستگی شدید (tightly coupled) است که همچنان از طریق HTTP یا RPC با یکدیگر ارتباط برقرار میکنند. این راهنما آن را «مونولیت توزیعشده» مینامد. نقاط درد مشابه یک مونولیت سنتی است — وابستگی شدید و دشواری در تغییر یک بخش بدون تأثیر بر سایر بخشها — به علاوه تأخیر اضافی ناشی از گامهای شبکه (network hops).
به جای آن چه باید کرد: ابتدا یک مونولیت تمیز بسازید. مرزهای ماژولار مشخصی تعریف کنید، لایه داده را یکپارچه نگه دارید و اطمینان حاصل کنید که اپلیکیشن میتواند به عنوان یک واحد واحد تست و مستقر شود. یک ماژول را تنها زمانی به سرویس مستقل خود تبدیل کنید که نیاز به مقیاسپذیری مستقل یا مالکیت توسط تیم مجزا داشته باشد.
تفکیک بر اساس لایههای فنی در مقابل قابلیتهای تجاری
یک خطای رایج دیگر، جدا کردن سرویسها بر اساس دغدغههای فنی — مانند رابط کاربری (UI)، منطق تجاری (business logic) یا دسترسی به دادهها — است. این کار باعث میشود یک درخواست برای انجام یک عملیات واحد، مجبور شود از زنجیرهای از سرویسها عبور کند که این امر زمان پاسخگویی را افزایش داده و یک گراف وابستگی شکننده ایجاد میکند.
رویکرد بهتر: سرویسها را حول قابلیتهای تجاری (business capabilities) مانند «سفارشها»، «پرداختها» یا «موجودی» سازماندهی کنید. اجازه دهید هر قابلیت، مالک دادهها و API خود باشد تا نیاز به پرش درخواستها بین لایهها از بین برود.
مالکیت دادهها اهمیت دارد
وقتی دو سرویس به یک جدول پایگاه داده مشترک مینویسند، دیگر مستقل نیستند. این راهنما تأکید میکند که یک سرویس هرگز نباید مستقیماً جداول سرویس دیگری را کوئری بگیرد؛ بلکه همیشه باید از طریق API عمومی آن سرویس اقدام کند. اشتراکگذاری یک پایگاه داده، سرویسها را به هم گره میزند، اصل جداسازی (isolation) را از بین میبرد و تغییرات طرحواره (schema) را به یک کابوس هماهنگی تبدیل میکند.
HTTP همگام (Synchronous) یک راهکار همگانی نیست
تکیه بر HTTP همگام برای هر تعامل، کل سیستم را در برابر یک سرویس کند، آسیبپذیر میکند. اگر سرویس A منتظر پاسخ سرویس B بماند تا بتواند پاسخ را به کلاینت برگرداند، هرگونه کندی در B به A و در نهایت به کاربر سرایت میکند.
الگوهای جایگزین: برای وظایفی که نیاز به پاسخ فوری ندارند، از پیامرسانی ناهمگام (asynchronous messaging) استفاده کنید. صفهای پیام (Message queues) یا وظایف پسزمینه (background jobs) به سرویسها اجازه میدهند کار را تحویل داده و به پردازش خود ادامه دهند که این امر باعث تابآوری بیشتر سیستم میشود.
پذیرش سازگاری نهایی (Eventual Consistency)
پایگاههای داده رابطهای سنتی به شما تراکنشهای ACID (اتمی بودن، سازگاری، جداسازی، پایداری) میدهند. در مرزهای سرویس، این تضمینها از بین میروند. تلاش برای اجبارِ استفاده از کامیت دو مرحلهای (two-phase commits) — پروتکلی که سعی میکند تراکنشهای توزیعشده را مانند تراکنشهای محلی رفتار کند — منجر به پیچیدگی و ناپایداری میشود.
این راهنما الگوی سگا (sagas - مجموعهای از اقدامات جبرانی) یا الگوی Outbox (جایی که یک سرویس رویدادها را در یک جدول محلی مینویسد و بعداً منتشر میشوند) را توصیه میکند. این رویکردها میپذیرند که دادهها ممکن است موقتاً از هم همگام نباشند و منطق تجاری را برای مدیریت این شکافها طراحی میکنند.
از روز اول برای شکست خوردن برنامهریزی کنید
یک باگ در یک سرویس نباید کل سیستم را از کار بیندازد. برای جلوگیری از انتظار بیپایان، از Timeoutها استفاده کنید؛ برای مدیریت شکستهای گذرا، از تلاش مجدد با بازگشت زمانی (retries with back-off) استفاده کنید؛ و از قطعکنندهها (circuit breakers) بهره بگیرید تا تماس با یک سرویس در حال خرابی را تا زمان بازیابی آن متوقف کنند. اضافه کردن این اقدامات حفاظتی پس از وقوع خرابی در محیط عملیاتی، بسیار دیر است؛ این موارد باید در طراحی اولیه باشند.
مشاهدهپذیری (Observability) غیرقابل مذاکره است
عیبیابی یک سیستم توزیعشده با لاگهایی که در کانتینرهای مختلف پراکنده شدهاند، تقریباً غیرممکن است. لاگگذاری متمرکز، متریکهای تجمیعشده و شناسههای همبستگی (correlation IDs) در سطح درخواست، به مهندسان اجازه میدهند یک درخواست کاربر را در حالی که از میان چندین سرویس عبور میکند، ردیابی کنند. ابزارهای ردیابی (Tracing tools)، گراف فراخوانی را بصریسازی میکنند و یافتن گلوگاههای عملکردی و خطاها را آسانتر میسازند.
در ابتدا زیرساخت را سبک نگه دارید
کوبرنتیز (Kubernetes)، با وجود قدرتمند بودن، منحنی یادگیری تند و بار عملیاتی سنگینی را به همراه دارد. برای تعداد محدودی از سرویسها، Docker Compose ارکستراسیون کافی برای راهاندازی کل استک به صورت محلی را فراهم میکند. تنها زمانی که الگوهای ترافیک، فرکانس استقرار یا اندازه تیم ایجاب کند، باید پلتفرم پیچیدهتری معرفی شود.
همسو کردن سرویسها با مالکیت تیم
میکروسرویسها تا حدی برای این ابداع شدند که به تیمهای کوچک و خودمختار اجازه دهند مالکیت کامل چرخه حیات یک سرویس را بر عهده بگیرند. اگر یک تیم واحد مسئول ده سرویس باشد، هزینههای هماهنگی به شدت افزایش یافته و مزایای مورد نظر را از بین میبرد. این راهنما پیشنهاد میکند که تیمهای کمتر از ده نفر ممکن است با یک معماری مونولیت (monolith) بهتر پاسخگویی شوند؛ این کار ضمن حفظ سادگی، اجازه توسعه ماژولار را نیز میدهد.
استدلال متقابل: زمانی که میکروسرویسها میدرخشند
این راهنما ادعا نمیکند که میکروسرویسها ذاتاً بد هستند. در محیطهایی که بخشهای مختلف یک اپلیکیشن نیازهای مقیاسپذیری بسیار متفاوتی دارند، یا در جایی که محدودیتهای نظارتی مستلزم جداسازی دقیق دادهها هستند، این الگو میتواند ارزش واقعی ایجاد کند. سازمانهای بزرگ با خطوط محصول متعدد اغلب درمییابند که سرویسهای مستقل، اصطکاک بینتیمی را کاهش داده و چرخههای انتشار سریعتری را ممکن میسازند.
نکته کلیدی، هدفمندی است. اگر تیمی به این دلیل میکروسرویسها را اتخاذ میکند که نیاز دارد میلیونها درخواست در ثانیه را برای یک ویژگی خاص مدیریت کند، یا به این دلیل که یک خط محصول جدید باید توسط یک واحد تجاری مجزا مدیریت شود، پیچیدگی اضافی توجیهپذیر است. هشدارهای این راهنما مواردی را هدف قرار میدهد که در آنها تصمیمگیری به جای نیازمندیهای ملموس، تحت تأثیر هیاهو و تبلیغات اغراقآمیز صورت گرفته است.
آنچه باید در آینده زیر نظر داشت
با پذیرش بیشتر استکهای cloud-native توسط شرکتها، ابزارهای مربوط به service mesh، distributed tracing و canary deployments خودکار به بلوغ خود ادامه میدهند. این پیشرفتها مانع عملیاتی را کاهش میدهند اما انتخابهای طراحی بنیادی که در این راهنما برجسته شدهاند را از بین نمیبرند. تیمها باید تکامل پلتفرمهای observability و فریمورکهای پیامرسانی ناهمگام (async messaging) را زیر نظر داشته باشند، اما همچنان باید با یک توجیه روشن برای هر سرویسی که راهاندازی میکنند، کار خود را شروع کنند.
نتیجهگیری
میکروسرویسها وسیلهای برای رسیدن به هدف هستند، نه خودِ هدف. با یک مونولیت خوشساخت شروع کنید، به هر سرویس مالکیت واقعی بر دادههای خود را بدهید، در صورت امکان از ارتباطات ناهمگام استفاده کنید و تابآوری و مشاهدهپذیری (observability) را از اولین خط کد در سیستم بگنجانید. زمانی که ضرورت تجاری آن روشن شد، سرویسها را آگاهانه جدا کنید؛ در غیر این صورت، معماری را تا همان حدی که مسئله ایجاب میکند، ساده نگه دارید.