معرفی و بررسی Monolithic و Microservice (بخش 3)

قسمت دوم

 

 

Componentization via Services

تعریف ما از component واحدی از نرم افزار است که به تنهایی قابلیت جایگزین شدن و بروزرسانی را دارد. همانطور که در قسمت‌های قبل توضیح دادیم، microservice ها، یک نرم افزار را به سرویس‌های کوچکتری تقسیم می‌کنند که به تنهایی قابل توسعه دادن می‌باشد. ما تمامی کتابخانه‌ها را به عنوان component در نظر میگیریم که این component ها به نرم افزار ما وابسته هستند و به وسیله فراخوانی توابع در پروسه نرم افزار قابل استفاده می‌باشند. در حالیکه سرویس‌ها، component های هستند که خارج از پروسه نرم افزار هستند و به وسیله مکانیزم‌های ارتباطی مانند Web Service Request و Remote Procedure Call قابل دسترسی هستند.
اگر بخواهیم در یک component در سیستم‌های یکپارچه‌ای که از چندین component تشکیل شده اند و این component ها در طول یک پروسه با یکدیگر در ارتباط هستند، تغییراتی ایجاد کنیم، این تغییر نیازمند استقرار کل سیستم است. در حالیکه در معماری micro service این اتفاق رخ نخواهد داد و کافی است تا سرویس یا component ای که تغییر کرده، دوباره مستقر شود و سایر بخش‌ها، دچار تغییر نخواهند شد.

Technology Heterogeneity

سیستمی را در نظر بگیرید که از همکاری چندین سرویس تشکیل شده است. در این حالت می‌توانیم تصمیم بگیریم که برای هر سرویس از چه فناوری خاصی استفاده کنیم. این ویژگی به ما این امکان را می‌دهد که برای رفع هر مشکل، از بهترین ابزار موجود استفاده کنیم. این امر برخلاف سیستم‌هایی که صرفا امکان استفاده از تکنولوژی تعریف شده در آن سیستم را دارند، انعطاف پذیری زیادی به سیستم ما خواهد داد. برای درک بهتر این موضوع، یک مثال را با هم مرور می‌کنیم. فرض کنید میخواهیم عملکرد بخشی از سیستم خود را افزایش دهیم. برای این منظور می‌توانیم از هر فناوری و تکنولوژی که می‌تواند کمک کننده باشد، استفاده کنیم. به طور مثال می‌توانیم در سیستم یک شبکه اجتماعی، اطلاعات مربوط به کاربران و ارتباطات آنها را در یک دیتابیس مبتنی بر گراف و اطلاعات مربوط به پست‌ها و نظرات کاربران را در یک دیتابیس سندگرا ذخیره کنیم. مشاهده می‌کنید که نیازی به استفاده از تکنولوژی خاصی نداریم و می‌توانیم بر اساس نیاز خود، از تکنولوژی مدنظرمان استفاده کنیم.

microservice ها به ما امکان انتخاب در بین تکنولوژی‌های جدید را می‌دهند. یکی از بزرگترین موانعی که در استفاده از تکنولوژی‌های جدید وجود دارد، ایجاد وابستگی سیستم به آنهاست. در یک سیستم یکپارچه، در صورتی که بخواهیم زبان مورد استفاده یا دیتابیس سیستم و یا فریم ورک‌ها را تغییر دهیم، کل سیستم متحمل این تغییرات خواهد شد اما در microservice ها، می‌توانیم این تغییرات را با کمترین هزینه و وقت ممکن انجام دهیم. توجه به این نکته ضروری است که استفاده از تکنولوژی جدید، چالش‌های مخصوص به خود را دارد و برای استفاده از آن نیازمند بررسی‌های کارشناسی و دقیق هستیم.

Resilience

در صورتی که یکی از سرویس‌ها دچار مشکل شود و این مشکل به صورت زنجیره‌ای به تمام سرویس‌ها نرسد، با جدا کردن آن سرویس از سیستم، در روند کار سیستم اختلالی ایجاد نمی‌شود و سیستم بدون کوچکترین مشکلی به کار خود ادامه می‌دهد. این بدان معنا است که محدوده یک سرویس، مانند دیواری بین سرویس و سایر بخش‌ها است و مانع از تاثیر پذیری آنها می‌شود. در سیستم‌های یکپارچه، چنانچه یک سرویس دچار اشکال شود، سایر بخش‌های سیستم غیر قابل استفاده خواهند شد. البته می‌توان با نصب نسخه‌های متفاوتی بر روی ماشین‌های متفاوت، تاثیر این مشکلات را تا حدی کاهش داد. به وسیله microservice ها، می‌توانیم سیستم‌های را طراحی کنیم که در مقابل خطاهای ایجاد شده در سیستم، به گونه‌ای رفتار کنند که در روند کار سیستم، اختلالی ایجاد نشود.

Scaling

فرض کنید در بخشی از یک سیستم، مشکلی برای عملکرد یک بخش ایجاد شده است. در صورتی که سیستم ما از معماری یکپارچه استفاده کند، ناچار خواهیم بود که کل سیستم را scale کنیم در صورتی که این مشکل تنها در بخش کوچکی از سیستم رخ داده است. در مقابل این قضیه، در صورتی که بر روی سیستم از معماری microservice استفاده کنیم، می‌توانیم صرفا همان سرویس یا بخشی که دچار مشکل شده را scale کرده و بقیه بخش‌های سیستم بدون تغییر می‌مانند.
Gilt یک فروشگاه آنلاین پوشاک است که به خاطر مشکلات ناشی از عملکرد سیستم، از معماری microservice استفاده می‌کند. این فروشگاه در سال 2007 کار خود را با یک نرم افزار یکپارچه شروع کرد اما پس از 2 سال سیستم دیگر قادر به پوشش دهی ترافیک سایت نبود بنابراین تصمیم گرفتند با تقسیم‌بندی قسمت‎‌‌های اصلی سیستم به microservice ها، نتیجه بهتر و موثرتری را با حجم ترافیک دریافتی داشته باشند. در حال حاضر سیستم Gilt از حدود 450 microservice تشکیل شده که هر کدام از آنها بر روی چندین ماشین مختلف در حال اجرا هستند.

Ease of Deployment

تغییر یک خط از کدهای برنامه‌ای که از میلیونها خط کد تشکیل شده است، برنامه نویسان را ملزم به استقرار مجدد کل سیستم و انتشار نسخه‌های جدید برنامه می‌کند. این استقرار مجدد، می‌تواند ریسک بالایی داشته باشد و برنامه نویسان را مجبور به تغییرات بیشتر و انتشار نسخه‌های دیگر کند و این حجم از تغییرات می‌تواند باعث ضربه زدن به برنامه ارائه شده شود. اما در microservice ها، تغییرات کوچک بر روی کل سیستم تاثیر گذار نیستند و تغییرات صرفا بر روی سرویس مورد نظر اعمال می‌شود و در صورت بروز مشکل در سیستم، منشا این مشکلات مشخص است و می‌توان سریعتر سیستم را به وضعیت بهتری برگرداند. این ویژگی یکی از دلایلی است که کمپانی‌های مطرحی مانند Netflix و Amazon به استفاده از معماری microservice روی آورده اند.

Organizational Alignment

بسیاری از ما مشکلات مربوط به پروژه‌های بزرگ و تیم‌های بزرگ را تجربه کرده‌ایم و این مشکلات، بخصوص در زمانیکه اعضای تیم به صورت متمرکز در کنار هم فعالیت نداشته باشند، افزایش خواهد یافت. این موضوع را می‌دانیم که اگر یک تیم کوچک، بر روی قطعه کد کوچکتری کار کند، بسیار موثرتر از زمانی است که یک تیم بزرگ درگیر کار بر روی یک کد بزرگ باشند. micro service ها این امکان را به ما می‌دهند تا معماری خود را با ساختار سازمانی خود در یک راستا قرار دهیم و به ما کمک می‌کنند تا با تقسیم ساختار برنامه به بخش‌های کوچکتر و ایجاد تیم‌های کوچکتر مختص هر بخش، بازدهی و تاثیر تیم‌ها را در سازمان افزایش دهیم.

Composability

یکی از ویژگی‌های کلیدی که در سیستم‌های توزیع شده و سرویس‌گرا وجود دارد، قابلیت استفاده مجدد از functionality های سیستم است. microservice ها این امکان را برای ما فراهم می‌کنند تا functionality های سیستم، به صورت‌های مختلف و با اهداف گوناگونی مورد استفاده قرار گیرند. این موضوع که کاربران، چگونه از نرم افزار ما استفاده می‌کنند، برای ما اهمیت دارد. در حال حاضر ما باید درباره روش‌های مختلفی که می‌توانند قابلیت‌های سیستم را با هم ترکیب کنند تا در برنامه‌های وب، موبایل و یا سایر ابزارها، فکر کنیم. در microservice ها، عمده تفکر ما این است که بخش‌های مختلف سیستم را از هم جدا کرده و علاوه بر آن، این بخش‌ها از بیرون قابل دسترسی بوده تا بتوانیم با تغییر شرایط، بخش‌های گوناگونی را بسازیم.

Optimizing for Replaceability

اگر شما در یک سازمان متوسط یا بزرگ، مشغول به کار باشید، ممکن است با یک سیستم قدیمی که در قسمتی از این سازمان در حال فعالیت است و کسی حوصله نزدیک شدن به آن یا اعمال تغییرات در آن را با بهانه اینکه، این کار پر دردسر و پر ریسک است، ندارد، مواجه شده باشید. با استفاده از معماریmicroservice ، هزینه این تغییرات کمتر است و این تغییرات با ریسک کمتری اعمال می‌شود.

چه زمانی از معماری microservice استفاده می کنیم؟

•  در صورتی که سورس کد پروژه شما به قدری حجیم باشد که توسعه آن به صورت لوکال ( مانند لود کردن کل پروژه در داخل یک IDE ) دشوار باشد، در این حالت بهتر است از معماری microservice استفاده کنید چرا که فرایند بیلد کردن برخی از پروژه‌ها بزرگ که از معماری Monolithic استفاده می‌کنند، گاهی ده ها دقیقه طول می‌کشد.
•  صرفا بعضی از بخش‌های برنامه نیاز به توسعه دارند و در صورتی که از معماری Monolithic استفاده کرده باشید، الزاما باید کل سیستم را ارتقا دهید در صورتی که نیاز به ارتقا کل سیستم ندارید.
•  در صورتی که توسعه دهنده‌ها در کنار هم نیستند و نمی‌توانند به صورت مستقل بر روی پروژه کار کنند.

 

 

در واقعه قاعده مشخصی برای انتخاب بین معماری microservice و معماری Monolithic وجود ندارد و بهترین دلیل برای استفاده از معماری microservice به جای معماری Monolithic ، ترجیح تیم برای اجتناب از مشکلاتی است که معماری Monolithic به وجود می‌آورد.اگر تیم توسعه دهنده تصمیم بگیرد که از معماری Monolithic به معماری microservice تغییر مسیر دهد، نیازی به نوشتن کل برنامه از ابتدا نیست. در این حالت، صرفا کامپوننت‌هایی که دردسر ساز شده‌اند، به نوع سرویسی آن تبدیل خواهند شد. به این نوع از برنامه‌های سمت سروری که بخش اصلی آنها به صورت Monolithic ولی برخی از عملکردهای خاص آنها به صورت سرویسی نوشته شده باشد، اصطلاحا microservice با هسته Monolithic می‌گویند.

 

تفاوت های معماری های Monolithic ، Microservice و SOA

 

زمانی که در مورد میکروسرویس‌ها صحبت می‌کنیم، ای سوال مطرح می‌شود که آیا این معماری همان معماری سرویس‌گرا است که یک دهه قبل مطرح شده یا نه؟ به علت شباهت، این دو نوع معماری را می‌توان واجد شرایط دارا بودن مزایای مورد علاقه طرفداران معماری سرویس‌گرا در معماری micro servic دانست. تعاریف بسیاری از معماری سرویس‌گرا وجود دارد و معمولا این نوع معماری با معماری‌های شامل چندین سرویس یکپارچه اشتباه گرفته می‌شود.
واضح است که پیاده سازی‌های شکست خورده‌ای از معماری سرویس‌گرا و با تمرکز بر کاهش پیچیده‌گی‌های FBS وجود دارد که علی رغم صرف هزینه‌های گزاف، به خروجی‌های مطلوبی منجر نشده است. بسیاری از تکنیک‌های به کار رفته در معماری microservice از تجارب توسعه دهندگان سرویس‌های یکپارچه در سازمان‌های بزرگ به دست آمده است. در واقع استفاده از بستر وب و همچنین پروتکل‌های ساده ارتباطی، پاسخی برای استانداردهای متمرکز و پیچیده است.
در نهایت مشکلات مدیریت متمرکز در معماری سرویس‌گرا، باعث شده است تا طرفداران معماری microservice، معماری SOA را به صورت کامل کنار بگذارند. هر چند که دیگران، معماری micro service را حالتی از معماری سرویس‌گرا در نظر می‌گیرند.