معماری میکروسرویس ( Microservices Architecture ) چیست؟

«نسخه کامل و جامع این مقاله به همراه جزئیات بیشتر، درImaniNova.ir منتشر شده است. در ادامه قطعه ای از این مقاله را مشاهده می کنید.»

تعریف میکروسرویس

میکروسرویس (Microservice Architecture) یک استراتژی توسعه نرم افزار است که در آن اپلیکیشن به صورت مجموعه ای از سرویس های مستقل و متمرکز بر دامنه (Domain-focused) ساخته می شود. اما نکته ای که بسیاری از پروژه ها را به شکست می کشاند، درک نادرست از این تعریف است. برای اینکه سیستمی را میکروسرویس بنامیم، رعایت این «هسته سخت» الزامی است:

رای اینکه میکروسرویس را نه به عنوان یک «مد» تکنولوژیک، بلکه به عنوان یک تغییر بنیادین در فلسفه مهندسی درک کنیم، باید به لایه های زیرین آن نفوذ کنیم. در واقع، تعریف میکروسرویس در یک جمله خلاصه نمی شود؛ میکروسرویس حاصل ترکیب سه ستون اصلی است که اگر هر کدام نباشد، کل معماری فرو می ریزد.

در اینجا میکروسرویس را از دیدگاه «توزیع»، «مالکیت» و «عملیات» کالبدشکافی می کنیم:

۱. میکروسرویس به مثابه یک «سیستم توزیع شده» (The Distributed Nature)

در مونولیت، تمام اجزای سیستم در یک حافظه (Memory Space) مشترک زندگی می کنند. وقتی متدی را صدا می زنید، کنترل برنامه مستقیما به آن آدرس در حافظه می رود. در میکروسرویس، این سد حافظه شکسته می شود.

• پیامد فنی: شما از «فراخوانی محلی» (Local Call) به «فراخوانی راه دور» (Remote Call) مهاجرت می کنید. این یعنی با مفاهیمی مثل تاخیر شبکه (Network Latency)، قطعی های ناگهانی (Network Partitioning) و سریال سازی داده ها روبرو هستید.
• نکته کلیدی: در این معماری، شبکه دیگر یک «بستر عبور» نیست؛ شبکه بخشی از «کد» شماست. باید فرض کنید هر درخواست بین سرویسی ممکن است شکست بخورد، پس باید از مکانیزم هایی مثل Retry، Circuit Breaker و Timeout استفاده کنید تا خرابی یک سرویس، مثل یک دومینو کل سیستم را زمین نزند.

۲. اصل «مالکیت دامنه» (Domain Ownership)؛ قلب تپنده

بزرگترین اشتباه در درک میکروسرویس، خرد کردن سیستم بر اساس «تکنولوژی» (مثلا: یک سرویس برای دیتابیس، یک سرویس برای کش، یک سرویس برای لاگ) است. میکروسرویس واقعی باید بر اساس دامنه های تجاری (Business Domains) خرد شود.

• تغییر دیدگاه: در سازمان شما، «سبد خرید»، «موجودی کالا»، «حمل ونقل» و «مدیریت کاربران» دامین های متفاوتی هستند. هر کدام از این ها باید تیم مهندسی اختصاصی، دیتابیس اختصاصی و حتی چرخه حیات نرم افزاری مخصوص به خود را داشته باشند.
• چرا این مهم است؟ وقتی دامین ها ایزوله باشند، تغییرات در «منطق قیمت گذاری» هیچ نیازی به لمس کردن «منطق لاگین» ندارد. این همان «استقلال عملیاتی» است که سرعت تیم شما را به ۱۰ برابر می رساند.

۳. استقلال دیتابیس؛ جایی که بیشترین شکست ها رخ می دهد

میکروسرویس «واقعی» دارای الگوی Database-per-Service است.

• چالش: در مونولیت، شما یک JOIN ساده می زدید تا اطلاعات کاربر را با سفارشاتش ترکیب کنید. در میکروسرویس، شما دیتابیس سفارشات را نمی توانید به دیتابیس کاربران JOIN کنید، چون این دو دیتابیس در دو سرویس مختلف هستند و شاید حتی از دو نوع تکنولوژی متفاوت (مثلا SQL برای یکی و NoSQL برای دیگری) استفاده کنند.
• راهکار: اینجا باید یاد بگیرید که داده ها را «همگام» کنید. شما باید مفاهیمی مثل Eventual Consistency را بپذیرید. یعنی برای لحظاتی، داده های سیستم ممکن است ۱۰۰٪ منطبق نباشند، اما در نهایت (و در کوتاه ترین زمان) همگام می شوند. این قیمت سنگینی است که برای مقیاس پذیری بی نهایت پرداخت می کنیم.

۴. میکروسرویس به مثابه «فرهنگ DevOps»

میکروسرویس بدون ابزارهای اتوماسیون (CI/CD)، یک خودکشی است. اگر برای دیپلوی کردن ۱۰ سرویس مجبور باشید ۱۰ بار به صورت دستی روی سرورها کار کنید، شما در جهنم گیر افتاده اید.

• زیرساخت کد محور (IaC): محیط عملیاتی باید به قدری هوشمند باشد که بتواند سرویس ها را مدیریت کند، آن ها را مانیتور کند و در صورت نیاز، نسخه های قبلی را برگرداند. میکروسرویس شما را مجبور می کند که به سمت Containerization (مثل داکر) و Orchestration (مثل کوبرنتیز) حرکت کنید.

چرا میکروسرویس "سخت" است؟

میکروسرویس، پیچیدگی را از درون کد (مونولیت) به فضای میان سرویس ها (زیرساخت و ارتباطات) منتقل می کند. اگر شما در یک مونولیت با پیچیدگی درهم تنیدگی کدها می جنگیدید، در میکروسرویس باید با پیچیدگی مدیریت توزیع بجنگید.

این معماری برای کسی است که می خواهد سیستمی بسازد که:

1. هرگز متوقف نشود (High Availability).
2. به صورت نامحدود رشد کند (Scalability).
3. به تیم های متعدد اجازه دهد بدون برخورد با هم، کد بزنند (Development Velocity).

بسیار عالی. حالا که درک کردیم میکروسرویس چیست و چه بهایی دارد، باید به اولین و حیاتی ترین مرحله برسیم: «هنر مرزبندی».

بزرگترین شکست های پروژه های میکروسرویسی در همین مرحله رخ می دهد؛ جایی که معماران، سیستم را به اشتباه خرد می کنند. اگر مرزهای شما (Boundaries) غلط باشد، با چیزی به نام «نانوسرویس» یا «مونولیت توزیع شده» روبرو می شوید؛ سیستمی که نه مزایای مونولیت را دارد و نه انعطاف میکروسرویس را، بلکه فقط پیچیدگی شبکه را به جان توسعه دهندگان می اندازد.

ادمه مقاله در

https://imaninova.ir/ArticleView?microservices-architecture-guide-challenges-patterns