معماری میکروسرویس نسل جدیدی از معماری‌های نرم‌افزاری است که خیلی جدیدا راجع بهش میشنویم، مثل خیلی چیزهای جدید که اسمی برای خودشون دارند. در این نوشته، به این معماری به اختصار اشاره خواهیم کرد و کارهایی که در آویهنگ در این حوزه انجام شده و دستاوردهاش رو بیان میکنیم.
معماری میکروسرویس چیست؟
معماری میکروسرویس عموما در مقابل معماری monolithic اسم برده میشه. خوب حالا سوال پیش میاد که معماری monolithic چی هست؟
نرم افزاری رو تصور کنید که از ماژول‌های مختلف که توی هرکدومش کامپوننت‌های گوناگونی در کنار هم نشستن رو، دارید با تیم خودتون طراحی میکنید یا توسعه میدید، یا پشتیبانی میکنید. این نرم‌افزار رو میتونیم مثل یک کشتی خیلی خیلی بزرگ که از طبقات مختلف و بخش‌های گوناگون، از موتورخانه خیلی خیلی بزرگ و منبع سوخت بسیار حجیم و کارکنان مختلف تصور کنیم. خوب پس با این شرایط باید یک کشتی خیلی خیلی بزرگ رو اول طراحی کنیم، با یک تیم که المانهای مختلف این کشتی رو شناختن در فاز اول، همراه بشیم، بعد این تیم رو مدیریت کنیم تا در نهایت این کشتی رو تولید کنه. خوب یک روشی که خیلی‌ها میدونن، این هست که در نهایت این کشتی شکسته میشه به بخش‌های کوچکتر و بخش‌های کوچکتر تولید میشن. بعد این بخش‌ها در کنار هم دوباره قرار میگیرن و در دنیای نرم‌افزار، این بخش‌ها با هم integrate میشن و حالا تست‌های مختلف integration هم انجام میشه و در نهایت کشتی، بعد از مثلا 6 ماه یا بعد از یکسال، آماده به آب انداختن میشه.
حالا انشالله که وقتی کشتی رو به آب انداختیم اجزائش در همون ضربه اولی که از آب دریافت میکنه از هم متلاشی نشه با این آرزو کشتی به آب انداخته خواهد شد و در واقع نرم‌افزار در محیط عملیاتی مستقر خواهد شد. خوب شاید تا اینجا بگیم روال همینه و مشکلی نیست.
- هر قایق تندرو رو بدی یک تیم جدا توسعه بده یا شاید دقیقترش اینکه هر کشتی تندرو رو بدی یک دولوپر توسعه بده!!! (سوالهایی پیش میاد که آقا مگه میشه یک دولوپر همه کار یک قایق تندرو رو انجام بده؟)
- هر قایق تندرو رو میشه جداگانه تستش کرد.
- هر قایق تندرو المانهای مستقل خودش رو داره، از جمله موتور جدا، باک جدا، بدنه جدا و ...
- مطمئننا به آب انداختن یک قایق کوچک (استقرار یک قایق) بسیار ساده‌تر از به آب انداختن یک کشتی اقیانوس‌پیماست.
حالا فرض میکنیم که همه اون بار کشتی بزرگ رو تقسیم کردیم به کشتی های کوچکتر:
-
فرض میکنیم که در شرایط مشابه یکی از قایق‌ها با مشکلی در باکش یا موتورش مواجه شده. در این حالت چه اتفاقی میفته؟ بقیه قایق‌ها یا در واقع المان‌ها دارن همچنان به کار خودشون ادامه میدن و به سمت مقصد حرکت میکنند. توی این مدل یک مفهوم دیگه رو هم توضیح بدیم و اون redundancy یا افزونگی هست. به چه معنی؟ به این معنی که فرض میکنیم برای حمل 20 تا جعبه، به جای اینکه هر 20 تا رو توی یک قایق بذاریم، اینها رو در دو قایق به صورت 10 تایی تقسیم میکنیم (load balancing) و این دو قایق با هم و در کنار هم به سمت مقصد حرکت میکنند. حالا اگر یکی از قایق‌ها به هر دلیلی دچار مشکل بشه، میشه 10 تا جعبه‌اش رو به قایق دوم منتقل کرد و اون قایق بره برای تعمیر و هر وقت برگشت، دوباره تقسیم بار انجام بشه. حالا ممکنه در این حالت قایقی که داره 20 تا جعبه رو میبره، نتونه با سرعتی که 10 تا جعبه رو میبرد حرکت کنه (طبیعی هست) ولی مهم اینه که سرویس‌دهی متوقف نشده و در این حالت سرویس شما همچنان کار میکنه، اما کمی کندتر.
معماری میکروسرویس، مزایای مختلفی رو به همراه داره. اما یادمون باشه که هر نرم‌افزار بر اساس نیازمندی‌ها (عموما non functional) و عرض و عمقش، معماری مختص خودش رو خواهد داشت و یک تجویز نمیتونه همه بیماری‌ها رو درمان کنه.
در مقالات دیگه، سایر المانهای معماری‌های میکروسرویس رو توضیح خواهم داد.
