خیلی از شرکتها با شنیدن مزایای میکروسرویسها (مثل مقیاسپذیری و سرعت توسعه بیشتر) سریع میگن: "بریم سمت میکروسرویس!" اما بدون برنامهریزی، این کار میتونه به یک کابوس واقعی تبدیل بشه! طبق آمار، ۶۲٪ از سازمانها با مدیریت وابستگیهای بین سرویسها مشکل دارن.
لینک منبع این حرف:
https://www.opslevel.com/resources/challenges-of-implementing-microservice-architecture
تقلید کورکورانه
چون شرکتهای بزرگ استفاده میکنن، ما هم بریم سمت میکروسرویس! این ذهنیت اشتباهیه که عموم برنامه نویس ها و تصمیم گیرهای تکنولوژی در تیم های مختلف دارند و کمتر پیش اومده که برن سراغ معماری ها و راه حل هایی که متناسب با مسئله و نیاز کسب و کار باشه. خیلی ساده بخواییم نگاه کنیم این حجم از حرکت به سمت میکرو سرویس حتی برای شرکت های کوچیک اصلا منطقی به نظر نمیاد و جز چالش و دردسر در پیاده سازی و نگهداری برای شرکت های متوسط و کوچیک چیزی نداره.
عدم طراحی درست
وقتی تعریف دومین ها در پیاده سازی سرویس ها دقیق و با مرزهای مشخص نباشه، سرویسها به هم وابسته میشن (به صورت غیر اصولی) و سیستم تبدیل به یک آش شله قلمکار توزیعشده میشه. مرحله ای پیش از پیاده سازی رو باید جدی گرفت چون این دقیقا همون نقشه ای هتس که قراره طبق اون پیاده سازی ها انجام بشه و بین سرویس های هر تیم هماهنگی و مسیر درست رو ایجاد کنه.
فراموش کردن فرهنگ تیمی
توپولوژی تیم ها و بلوغ سازمان یا شرکتی که قراره بره سراغ میکروسرویس اهمیت بالایی داره و تاثیر مستقیمی روی عملکرد تیم ها و محصول نهایی میزاره. میکروسرویس فقط معماری نیست بلکه روش کار تیمها رو هم عوض میکنه و نحوه ارتباط بین اعضای تیم و همچنین بین تیم های مختلف رو هم تحت تاثیر قرار میده. مدل فعالیت و کار در معماری درست میکروسرویس تفاوت های قابل توجهی نسبت به سایر معماری ها داره که همین خودش نیازمند آشنایی با این نوع از ارتباط و مهارت ارتباطی درست و مناسب هست.
خیلی از تیمها بدون بررسی آمادگی سازمان، مهارت تیم یا زیرساختهای لازم، سریع به سمت میکروسرویس میروند و در نتیجه این تصمیم عجولانه و ناپخته، دچار دردسرهایی میشن که حل کردنشون زمان و منابع شرکت و تیم ها رو از بین میبره. از نشونه هایی که میشه تشخیص داد تصمیم میکروسرویس نادرست بوده:
افزایش دردسرهای عملیاتی
قطعیهای مکرر سرویسها
اعصابخردی و آشفتگی برنامه نویس ها
برای چنین تصمیمی با اثرگذاری بلند مدت، اول بهتره آمادگی تیم و سازمان رو ارزیابی کنیم بعد تصمیم بگیریم. برای شروع و با یک تیم کوچیک، انتخاب مونولیت قطعا هوشمندانه تر از یک میکروسرویس هست.
سیستم بدون درنظرگرفتن مرزهای دومین کسبوکار (Domain Boundaries) به سرویسهای خیلی کوچیک تقسیم میشه و موقع پیاده سازی تازه اشتباهات و وابستگی های بیش از حد، مشخص میشن و اینجا همون نقطه ای هست که کلی سرویس کوچیک با کاربرد های خیلی جزئی وجود داره که تفکیک کردنشون تا این حد ریز کار اشتباهی بوده.
خب اینجا این سوال پیش میاد که چطور تشخیص بدیم محدوده و اندازه سرویسمون رو اشتباه انتخاب کردیم؟
سرویسهای بیش از حد ریز و به هم وابسته
تاخیر زیاد در ارتباط بین سرویس ها
Distributed Monolith (میکروسرویسِ مونولیتی)
یک فروشگاه آنلاین رو درنظر بگیرید که برای "ورود کاربر" و "ثبت نام کاربر" دو سرویس جدا ساخته! نتیجهاش چی میشه؟ هر عملیات ساده نیاز به ۱۰ بار call بین سرویس داره و آپدیت نگهداشتن دیتابیس ها چالش بعدی میشه.
روشی که اینجا به عنوان راه حل شناخته شده ای هست، استفاده از اصول Domain-Driven Design (DDD) در تقسیم بندی مناسب سرویس ها است. این روش بهمون کمک میکنه تا سرویسها رو بر اساس قابلیتهای کسبوکار تقسیمبندی کنیم.
از موارد خیلی مهمی که توی پیاده سازی میکروسرویس اهمیتش خیلی زیاده، موضوع ابزارها و مانیتورینگ هست. برای مطلع بودن لحظه ای از وضعیت سرویس ها و ارتباطاتشون، ریلیزها و موارد دیگه ای که نیازه بدونیم، باید از ابزارها و روش های مدیریتی مناسب میکروسرویس ها استفاده بشه در غیر این صورت مواردی مثل دیباگ و آپتایم سرویس ها از بزرگترین چالش های تیم میشه.
مواردی که در تیم هایی با روش های نادرست مدیریتی و ابزار نامناسب دیده میشه:
تیمهای جداگانه که با هم همکاری نمیکنند
کارهای تکراری و هدررفت منابع
مشکلات امنیتی
اینجاست که تعریف استانداردهای تیمی و استفاده از ابزارهایی مثل Istio, Prometheus اهمیت خودشون رو برای حل چنین مشکلی نشون میدن.
مهاجرت سریع و بدون برنامه از مونولیت به میکروسرویس، دورهی گذار خیلی طولانی و طاقت فرسایی رو برای تیم و هزینه های نگهداری به شدت زیادی رو برای شرکت در پی داره که با توجه به مثال هایی که در اکوسیستم استارتاپی ایران دیده شده حتی بعضی شرکت ها چندین سال درگیر این دوره گذار میشن و حتی با رفت و آمد تیم های زیاد در شرکت، این کار زمان بیشتر و هزینه سنگین تری روی دست ذی نفعان میزاره.
از نشون های مهاجرت سریع و بدون برنامه میشه به این موارد اشاره کرد:
downtime طولانی
ناسازگاری دادهها
مهاجرت نیمهکاره
پیشنهاد منابع معتبر برای حل چنین چالشی استفاده از الگوی Strangler Fig و همچنین اولویت بندی درست بر اساس نیاز بیزنس و سرویس های با ارزش هست.
عدم مدیریت درست وابستگیهای بین سرویسها و توجه نکردن به عملکرد نهایی باعث میشه پرفورمنس محصول کاهش پیدا کنه و زمانی که سیستم داره توسعه پیدا میکنه، سرویس های جدیدی اضافه یا لود بیشتر میشه، عملکرد ضعیف سیستم بیزنس رو دچار مشکل جدی کنه. یکی از نمونه هاش سرویس های سنکرون هستن که فقط کافیه یکی از سرویس ها ریسپانس نده یا fail بشه تا به همین ترتیب زنجیره ریکوئست بیافته و از هم گسسته بشه.
نشونه های رایج از این مورد در سیستم:
خطاهای آبشاری (Cascading Failures)
عملکرد ضعیف سیستم
مشکل در مقیاسپذیری
برای حل چنین مشکل رایجی در میکروسرویس این روش ها در اکثر موارد راه حل خوبی بوده:
از ارتباط غیر همزمان (مثلاً با Kafka) استفاده کنید
Circuit Breaker پیادهسازی کنید
با ابزارهایی مثل Jaeger عملکرد رو مانیتور کنید
پیادهسازی میکروسرویسها علاوه بر اینکه مزیت های بسیار خوبی داره، چالش های بسیار جدی در پیاده سازی و مشکلات رایجی داره که شرکت های بزرگی مثل اوبر در مسیر پیاده سازی اون تجربه کردن و با توجه به مقیاس شرکت از پس حل این مشلات بر اومدن. نکته مهمی که حتما باید در نظر گرفت، موفقیت در چنین تصمیماتی در گرو پرهیز از اشتباهات رایج است. اینطوری هزینه های پیاده سازی کاهش چشمگیری داره.
