میکروسرویس چیست؟

تا حالا اسم میکروسرویس به گوشتون خورده؟ اصلن میکروسرویس چیه و چجوری توی scaling ازش استفاده میشه؟ (خودمم نمیدونم باور کنید بریم با هم یاد بگیریم!)

برای اینکه یه ذهنیتی از میکروسرویس داشته باشیم بهتره درک کنیم که چجوری میشه یک برنامه یکپارچه رو به اجزای کوچیکتر(حالا این کوچیکی میتونه یه ذره باشه یا یه هکتار) تقسیم کنیم و هرکدوم رو جداگانه نصب و راه اندازی کنیم!

توی این مقاله یاد میگیریم:

• چرا باید از میکروسرویس استفاده کرد؟
• میکروسرویس چیه؟
• ویژگی های معماری میکروسرویس چیه؟
• مزایای معماری میکروسرویس چیه؟
• بهترین روشهای طراحی میکروسرویس چیاس؟

چرا باید از میکروسرویس استفاده کرد؟

قبل از اینکه راجع به میکروسرویس بخایم حرف بزنیم بزارید ساختار برنامه های monolithic رو که قبل از میکروسرویس رایج بودن رو با هم ببینیم که به چه شکل بوده!

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

مواردی که توی برنامه های یکپارچه باهاشون چالش داریم:

• عدم انعطاف پذیری: برنامه های یکپارچه رو نمیتونیم با استفاده از تکنولوژی های متفاوتی ایجاد کنیم چون بلخره داریم از یه استک(مجموعه ابزار و زبان) خاص استفاده میکنیم و همین و بس...
• غیر قابل اعتماد بودن: اگر حتی یک بخش کوچک از برنامه دچار مشکل بشه کل برنامه کار نمیکنه و به قول معروف میریم تو باقالیا
• مقیاس پذیر نبودن: برنامه هارو نمیشه راحت توسعه داد چون به ازای هر تغییر کل برنامه باید مجددا کامپایل بشه (حالا نیاید بگید php و... اگر باشه کامپایل نمیخاد منظورم روال یکپارچه سازی و توسعه س که باید به ازای هر تغییر دوباره روی کل برنامه اجرا بشه)
• توالی توسعه نرم افزار(معنی بهتری برای continuous development پیدا نکردم بخدا) رو مسدود میکنند: بسیاری از ویژگی های برنامه رو نمیشه همزمان توسعه و انتشار داد چون خیلی به هم وابسته هستن و نیاز هست که قدم به قدم هر کدوم رو طراحی کنیم و بعد بریم مرحله بعد!
• روال توسعه را کند میکنند: روال توسعه توی این برنامه ها کنده چون قسمت های مختلف برنامه باید به ترتیب ایجاد بشن و همین باعث میشه برای اضافه کردن یک ویژگی به برنامه نیاز باشه منتظر طراحی پیش نیاز های اون بخش بشیم.
• برای برنامه های پیچیده مناسب نیستند: امکانات برنامه های یکپارچه خیلی به هم وابسته هستن و این وابستگی ها کار توسعه رو سخت میکنه (خدایی تا کجا میتونیم پیش بریم یه جایی بلخره میریم تو دیوار)

چالشهایی که بالا گفتیم باعث شد کم کم بریم(البته باید بگیم باعث شد بروند :دی) به سمت میکرویس ها...

میکروسرویس چیه؟

یه سبک خاص معماریه که با استفاده از اون یه برنامه کاربردی رو به مجموعه ای از سرویس های مستقل تقسیم میکنیم که حول یه بیزنس دامین قرار میگیرن!

اگر بخایم راحت تر بگیم اینجوری میشه که، برنامه رو خورد میکنیم به یه سری سرویس که هر کدوم کار خودش رو انجام میده ولی در نهایت با قرار دادن اینا کنار هم به یه برنامه واحد میرسیم! (فکر کنم رو شکل راحت تر بشه درکش کرد).

توی معماری میکروسرویس هر سرویس self-contained (خود مختار) هستش و یک قابلیت خاص رو پیاده سازی میکنه.

تفاوت میکروسرویس و معماری های سنتی(مرسوم)

برای درک این موضوع بیاید یک برنامه E-commerce رو در نظر بگیریم (شکل زیر رو ببینید)

اولین تفاوتی که توی شکل بالا به چشم میاد اینه که توی معماری یکپارچه همه بخش های پروژه توی یه instance قرار گرفتن و به طبع یه دیتابیس واحد هم دارن ولی توی معماری میکروسرویس هر سرویس جداگانه داره کار میکنه و داده های خودش رو خودش نگهداری میکنه و قطعا هرکدوم داره کار خودش رو انجام میده و توی بقیه بخش ها دخالت مستقیمی نداره.

حالا یه نگاهی میندازیم به شکل زیر که معماری میکروسرویس رو دقیقتر متوجه بشیم

حالا با هم ببنیم ویژگی های این معماری چیه!؟

• کلاینت های مختلف میخواهند از سرویس های مختلفی مثل جستجو، پیکربندی، مکان یابی و... استفاده کنن
• همه سرویس ها بر اساس عملکرد و دامنه(حوزه کاری) از هم جدا شدن و به میکروسرویس های جداگانه ای تقسیم شدن
• این میکروسرویس ها داخل خودشون شامل load balancer و محیط اجرایی اختصاصی هستن تا بتونن کارهای خودشون رو انجام بدن و داده های خودشون رو داخل خودشون نگهداری کنن
• همه میکروسرویس ها از طریق یک سرور stateless که حالا میتونه REST باشه یا Message Bus با هم ارتباط برقرار میکنن
• برای اینکه میکروسرویس ها مسیر ارتباطی خودشون رو متوجه بشن از Service Discovery استفاده میکنن و کارهایی مثل اتوماسیون و مونیتورینگ را انجام میدن
• کلاینت برای ارتباط با تمامی میکروسرویس ها از یک API-Gateway استفاده میکنه
• تمامی نقاط داخلی(میکروسرویس ها) به API-Gateway متصل هستن پس کلاینت بعد از اتصال به این نقطه میتونه به سرویس ها دسترسی پیدا کنه (درواقع دروازه شهر میکروسرویس هامون میشه)

ویژگی های معماری میکروسرویس چیه؟

حالا یه نگاهی میندازیم به شکل زیر که ویژگی های معماری میکروسرویس رو متوجه بشیم

• جداسازی (Decoupling): سرویس های داخل یک سیستم تا حد زیادی از هم جدا میشن و این باعث میشه مراحل ایجاد، تغییر و مقیاس دهی سرویس آسون تر بشه
• مولفه سازی (Componentization): میکروسرویس ها به صورت کامپوننت های کاملا مجزا عمل میکنن پس راحت میشه اونهارو جایگزین کرد یا ارتقا داد
• توانایی های تجاری (Business Capabilities): میکروسرویس ها خیلی ساده عمل میکنن و تنها روی یک قابلیت تمرکز میکنن و تا جایی که میشه پیچیدگی رو توی خودشون به حد اقل میرسونن
• استقلال (Autonomy): توسعه دهنده ها و تیم به راحتی میتونن بدون هیچ وابستگی به دیگران کار خودشون رو انجام بدن و این باعث میشه سرعت توسعه بالا بره
• تحویل مداوم (Continous Delivery): چون میکروسرویس ها جدای از هم توسعه داده میشن این باعث میشه بتونیم مدام نسخه های جدیدی رو منتشر کنیم و با استفاده از اتوماسیون نرم افزار رو تست کنیم و اشکالات رو رفع کنیم و به مشتری تحویل بدیم
• پاسخگویی (Responsibility): از اونجایی که میکروسرویس ها رو تمام قابلیت های پروژه تمرکز نمیکنن پس راحت تر میتونن روی کار خودشون تمرکز کنن و خروجی مناسب رو داشته باشن
• حاکمیت غیر متمرکز (Decentralized Governance): توی میکروسرویس تمرکز روی استفاده از ابزار مناسب برای کار مناسب هست، یعنی اینکه هیچ الگو و تکنولوژی واحدی وجود نداره که مجبور باشیم از اون استفاده کنیم؛ پس توسعه دهنده مجازه از هر ابزاری که مناسب کار هست استفاده کنه

مزایای معماری میکروسرویس چیه؟

• توسعه مستقل (Independent Development): تمامی میکروسرویس ها میتونن به صورت جداگانه (بر اساس عملکردشون) توسعه داده بشن
• استقرار مستقل (Independent Deployment): بر اساس سرویسی که دارن ارائه میدن، میتونن تو هر برنامه ای مستقر بشن
• جداسازی خطا (Fault Isolation): اگر یک یا چند سرویس کار نکنند خللی در روال کار سایر سرویس ها ایجاد نمیکنه
• ترکیب تکنولوژی ها (Mixed Technology Stack): خیلی راحت میشه از زبان های برنامه نویسی و ابزارهای مختلف استفاده کرد، پس برنامه میتونه با n تا زبان و ابزار ساخته بشه
• مقیاسدهی ریزدانه (Granular Scaling): هر کدام از سرویس ها به صورت جداگانه میتونه مقیاس دهی بشه و نیازی نیست بقیه اجزا مقیاس دهی بشه

بهترین روشهای طراحی میکروسرویس چیاس

توی دنیای امروزه برنامه ها در حال بزرگ شدن هستن و به ناچار دارن پیچیده میشن. معماری میکروسرویس این نوید رو به ما میده که میتونیم عملکرد و مقیاس تیم و پروژه مون رو به راحتی مدیریت کنیم.

نمودار زیر لیست بهترین روشهای طراحی میکروسرویس رو نشون میده

حالا یه مثال از یک سبد خرید میزنیم که معماری میکروسرویس رو بهتر درکش کنیم

وقتی برنامه سبد خرید رو باز میکنید، تمام چیزی که میبینیم یک وبسایته. اما توی پس زمینه سرویس هایی مثل پرداخت، مدیریت کاربران، مدیریت محصولات و... وجود داره.

حالا بیاید فرض کنیم که این برنامه با یک فریمورک یکپارچه طراحی شده است که شکلش رو پایین میتونید ببینید

با توجه که چیزی که توی شکل میبینیم متوجه میشیم که همه قسمت های برنامه کنار هم قرار گرفتن و از یه دیتابیس واحد دارن استفاده میکنن.

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

به همین خاطر حالا توسعه دهنده ها تصمیم میگرن برن سراغ میکروسرویس تا بتونن نیازهای بعدی رو هم راحت پوشش بدن. برای اینکه دید مناسبی به معماری جدیدشون داشته باشیم میتونید شکل زیر رو بررسی کیند.

چیزی که از شکل بالا میشه فهمید اینه که توسعه دهنده ها بجای اینکه بیان سرویس هاشونو به میکروسرویس وب، میکروسرویس لاجیک یا میکروسرویس دیتابیس تجزیه کنن در عوض میان میکروسرویس های جستجو، پیشنهادات، مدیریت مشتریان و... رو پیاده سازی میکنن.

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

ادامه دارد...

دوستان بنده هیچ ادعایی روی درستی مطلق این مطالب ندارم و خوشحال میشم اگر اشتباهی چیزی هست رو بهم گوشزد کنید که اصلاح کنم. چون خودم دارم یاد میگیرم...