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

در حال حاضر جایی که مقیاس پذیری دیگر یک انتخاب نیست، بلکه شرط بقاست، معماری نرم افزار از یک مهندسی ایستا به یک «هنر مدیریت پویای توزیع شده» تغییر ماهیت داده است. میکروسرویس ها صرفا مجموعه ای از سرویس های کوچک نیستند؛ آن ها پاسخی تهاجمی به تقاضای بی پایان بازارهای مدرن برای «سرعت بی وقفه» (Non-stop Velocity) هستند.

تصور کنید سیستمی دارید که نه یک موجودیت واحد، بلکه مجموعه ای از موجودیت های هوشمند و خودمختار است که هرکدام به تنهایی نفس می کشند، رشد می کنند و در صورت لزوم، بدون اینکه کل سیستم را به زانو درآورند، می میرند و دوباره متولد می شوند. در دنیای میکروسرویس ها، ما «فشار» را به جای خفه کردن یک هسته مرکزی، در سراسر شبکه پخش می کنیم. ما عملا با استفاده از الگوهایی مثل Event-Driven Architecture و Service Mesh، به سیستم مان اجازه می دهیم تا با ترافیک غیرقابل پیش بینی، نه با «مقاومت»، بلکه با «انعطاف» برخورد کند.

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

میکروسرویس برای کسانی که به دنبال راه حل های سریع و سرسری هستند، یک دام است. اما برای معمارانی که به دنبال ساختن زیرساخت هایی با طول عمر بالا و قابلیت توسعه نامحدود هستند، این تنها راه درست است. در این مقاله، قرار نیست به تعاریف تکراری بسنده کنیم. ما به سراغ عمق پیچیدگی ها می رویم: از طراحی دامین های استراتژیک گرفته تا جراحی های دقیق روی داده های توزیع شده و استراتژی های پیاده سازی سرویس هایی که واقعا "شیک، کلاسیک و فوق العاده" مقیاس پذیر هستند.

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

میکروسرویس (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