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

 

من ارسلان میربزرگی، در این مقاله قصد دارم تا شما را با معماری Microservice ها و مزایا و ویژگی‌های این نوع معماری و همینطور مدیریت داده در معماری Microservice و اینکه چه زمانی و در کجا از این معماری استفاده می‌کنیم در سه بخش:معرفی و بررسی Monolithic و Microservice بخش 1،  معرفی و بررسی Monolithic و Microservice بخش 2 و معرفی و بررسی Monolithic و Microservice بخش 3 آشنا کنم. با من همراه باشید.

مقدمه‌ای از Monolithic و Microservice

امروزه با توجه به نیازهای فراگیر و رو رشدی که به برنامه و اپلیکیشن‌های Enterprise ایجاد شده است، بحث جدیدی در مورد microservice در حوزه توسعه نرم افزارها باز شده است. دلیل این موضوع نیز این است که توسعه دهندگان برای گسترش سیستم‌های تجاری بزرگ، ناچار به استفاده از معماری microservice ها هستند.

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

در طی این مدت، مقالات و بحث‌های فوق العاده زیادی نیز در این مورد مطرح شده تا جایی که بسیاری از شرکت‌ها و کمپانی‌های مطرحی مانند Netflix ، Sound Cloud ، Amazon و… نیز به صورت گسترده‌ای از معماری microservice ها استفاده می‌کنند.

می‌دانیم که برنامه‌های سمت سرور با کاربران و داده‌های بسیار زیادی که از سمت آنها به سرور وارد می‌شود و همچنین پاسخگویی به این داده‌ها و فراهم کردن وب سرویس‌ها، درگیر هستند.

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

معماری Monolithic

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

در این وضعیت، کل سیستم به شکل یک نرم افزار یکپارچه، اجرا می‌شود. برای درک ماهیت microservice ها، بهتر است ابتدا با عملکرد معماری Monolithic آشنا شویم. در این نوع معماری، سه لایه وجود دارد. لایه Model یا منطق برنامه، لایه View یا خروجی برنامه و لایه Controller یا رابط بین منطق و خروجی برنامه.

مشکلات معماری Monolithic

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

وظیفه توزیع برنامه بر روی سرورهای مختلف بر عهده بخشی تحت عنوان Load Balancer است.در واقع طبق توضیح مربوط به معماری Monolithic، بر روی هر سرور، کل برنامه با تمام بخش‌های آن و بدون در نظر گرفتن اینکه به این بخش‌ها نیازی هست و یا نه، اجرا می‌شود.

معماری Monolithic که به عنوان معماری MVC نیز شناخته می‌شود، دارای معایبی نیز هست. یکی از این معایب، ارتباط بسیار نزدیک سه لایه این معماری است به طوری که مثال نمی‌توان لایه Model یک برنامه که با معماری MVC نوشته شده را برداریم و در یک پروژه دیگر مورد استفاده قرار دهیم.

هسته مرکزی در معماری Monolithic

همانطور که در تصویر بالا مشاهده می‌کنید، در معماری Monolithic، یک هسته مرکزی برای ارتباط کاربران و سایر سرویس‌ها با آن وجود دارد.

این هسته مرکزی با وجود ماژولار بودن ( دارای بخش بندی بودن )، تمام ماژول‌ها تحت نظر یک پلتفرم و سیستم واحد در کنار هم قرار دارند و امکان جدا سازی ماژول‌ها از یکدیگر، به دلیل دشواری بیش از حد آن، تقریبا وجود ندارد. با وجود اینکه در معماری MVC، برخلاف گذشته که مفهوم ماژولاری وجود نداشت و تمامی فایل‌ها در یک پوشه بودند، کدها ماژولار هستند اما این ماژول‌ها برای داشتن عملکرد مناسب، به سایر ماژول‌ها نیاز دارند و نمی‌توان آن‌ها را از یکدیگر جدا کرد.

اگر بخواهیم مشکلات مربوط به معماری Monolithic را دسته بندی کنیم، می‌توانیم به موارد زیر اشاره کنیم.

1.  از آنجایی که تنها یکی سورس کد اصلی وجود دارد، تمامی اعضای تیم شامل توسعه دهنده فرانت اند، برنامه نویس‌های سمت سرور و …، باید بر روی یک سورس کد کار کنند. به طور مثال اگر یکی از اعضای تیم بخواهد بر روی بخش مدیریت کاربران کار کند، باید کل پروژه را دریافت کرده، یک لوکال هاست ایجاد کند و بر روی پروژه کار کند.
2.  اعمال هرگونه تغییر در یکی از ماژول‌ها، ممکن است باعث تغییر عملکرد سایر ماژول‌ها شود.
3. در طول کار کردن با برنامه‌ای که بر پایه معماری MCV کار می‌کند، به علت نزدیکی و ارتباط بیش از حد لایه‌ها با یکدیگر، عملا تشخیص این لایه‌ها از یکدیگر بسیار دشوار خواهد بود.
4. در برنامه‌ای که از این نوع معماری استفاده می‌کند، نمی‌توان کامپوننت‌ها را به راحتی با یکی معماری جدیدتر و بهینه‌تر جایگزین کرد زیرا در این صورت کل معماری برنامه تغییر خواهد کرد.
5.  وجود هر نوع باگ در یکی از ماژول‌ها، با احتمال قوی، بر روی کل پروژه تاثیر خواهد گذاشت.
6.  در صورت استفاده از معماری در یک برنامه، تنوع زبان‌های برنامه نویسی، دیتابیس‌های مختلف، لایبرری و فریم ورک‌های مختلف دیگر وجود ندارد چرا که برقراری ارتباط بین آنها با وجود معماری MCV، بسیار سخت خواهد شد.

با وجود همه این مشکلات در مورد معماری MCV، کمپانی‌های بزرگی مانند مطرحی مانند Netflix یاAmazon ترجیح می‌دهند تا از معماری microservice استفاده کنند.

معماری سرویس گرا یا service-oriented Architecture

قبل از شروع صحبت در مورد معماری سرویس گرا یا SOA، ابتدا در مورد دو مفهوم منطق کسب و کار یا Business Logic و زیر ساخت یا Plumbing کمی صحبت می‌کنیم.

برای ساخت یک برنامه کاربردی، ابتدا باید مشخص کنیم که از برنامه چه چیزی را انتظار داریم و کامپیوتر چطور قرار است آن را انجام دهد؟ برنامه‌های کاربردی در زمینه کسب و کار، شامل مجموعه‌ای از کدهای نوشته شده به وسیله برنامه نویسان هستند که در واقع کارهایی را که کامپیوتر باید انجام دهد. به زبان قابل فهم برای کامپیوتر تبدیل می‌کند.

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

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

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

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

معماری SOA، روشی جدید و در حال رشد و تکامل برای ساخت برنامه‌های توزیع شده با Distributed Application است.

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

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

مثال:

شخصی که از سایت‌های فروشگاهی خرید آنلاین انجام داده باشد، با مفهوم سرویس‌ها تقریبا آشنایی دارد.

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

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

همانند سایر معماری‌های توزیع شده، معماری SOA نیز، امکان ساخت برنامه‌های کاربردی با استفاده از اجزایی که در دامنه‌های جدا از هم قرار دارند را امکان پذیر می‌کند. معماری SOA از سرویس‌های وب به عنوان نقاطی برای ورود برنامه کاربردی استفاده می‌کند که این مورد از لحاظ مفهومی مشابه همان اجزای proxy و stub در سیستم‌های توزیع شده قدیمی مبتنی بر اجزا است با این تفاوت که در اینجا، ارتباط بین کاربر و سرویس وب، بسیار آزادانه‌تر و دارای استقلال بیشتری است.

علاوه بر این، معماری SOA به دلیل دارا بودن فاکتورهای پراهمیتی مانند قابلیت اطمینان سرویس، جامعی بودن پیام، یکسانی تراکنش و امنیت پیام رسانی، منحصر به فرد است.

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

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

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

اگر یک سیستم، توانایی‌های خود را به صورت یک سرویس وب ارائه دهد، در این صورت باید نحوه فراخوانی آن سرویس نیز به طور واضح مستند سازی و اعلام شود.

بسیاری از مسائلی که در رابطه با دسترسی و مقیاس پذیر بودن برنامه‌های کاربردی در گذشته مطرح بود، امروزه با وجود معماری SOA حل شده اند که البته احتمال نقض آنها در هر مرحله ای از روند کار برنامه، وجود دارد.

در معماری SOA، فرض را بر این موضوع می‌گذاریم که خطا وجود دارد و میتواند اتفاق بیافتد. بنابراین استراتژی‌ها و راهکارهایی تدوین شده است.

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

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

در معماری SOA به این نکته نیز توجه شده است که سیستم های با اهمیت زیاد که بر مبنای تکنولوژی‌های توزیع شده، ساخته می‌شوند باید تضمین‌های خاصی را تامین کنند.

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

SOA نوعی معماری است که یک سرویس را به منظور ساده کردن فعالیت های یکپارچه سازی و همچنین استفاده از اجزا با قابلیت استفاده مجدد به روش اتصال سست و به شکل یک بلوک ساختمانی، به خدمت در می‌آورد.

در واقع معماری SOA نوعی الگوی طراحی است. این الگو برای ارائه خدمات از طریق پروتکل به برنامه‌های دیگر طراحی شده است.

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

طبیعتا کسی طرفدار یک نرم افزار کند یا غیر قابل انعطافی که نیازهای عملی را تامین نمی‌کند، نیست اما در واقعیت، افراد نظری برخلاف این تفکر دارند و با وجود سازگاری و سرعتی که معماری SOA دارد، طرفداران زیادی برای آن وجود ندارد.

ویژگی های سرویس و محاسبات سرویس گرا

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

سرویس‌ها عناصری هستند که از پلتفرم‌ها مجزا هستند و وظیفه کمک رسانی در ساخت سیستم‌های توزیع سریع و ارزان قیمت را بر عهده دارند.

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

1. باید سرویس‌ها مستقل از تکنولوژی باشند. این جمله به این معنی اسن که به کارگیری و فراخوانی سرویس‌ها باید از طریق تمام محیط‌ها ( سیستم عامل‌های مختلف و زبان‌های برنامه نویسی متفاوت ) انجام شود و به پلتفرم خاصی وابسته نباشد.
2. باید بین درخواست کننده و ارائه دهنده سرویس، کمترین ارتباط وجود داشته باشد. به عبارت دیگر، نباید درخواست کننده نیازی به دانستن ساختار داخلی و یا نحوه پیاده سازی سرویس داشته باشد. به این منظور، فراخوانی سرویس یه جای فراخوانی API، از طریق به کارگیری مکانیزم پیغام یا Message انجام می‌شود.
3. نباید درخواست کننده نیازی برای اطلاع از محل قرارگیری سرویس داشته باشد. به عبارت دیگر، معماری سرویس گرا باید از قابلیت Location Transparency پشتیبانی کند. در این قابلیت، محل قرار گیری سرویس و مشخصات آن در مخزنی قرار می‌گیرد و درخواست کننده، محل و اطلاعات لازم را از طریق فراخوانی آن از این مخزن به دست می‌آورد.

و در آخر

سرویس‌ها می‌توانند از طریق دو شکل ساده و ترکیبی ارائه شوند. سرویس‌های ترکیبی، سرویس‌هایی هستند که بر اساس بکارگیری چند سرویس ساده و یا ترکیبی با یکدیگر ایجاد می‌شوند.

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

سیستم های ساخته شده بر اساس سرویس، اجتماعی از سرویس های مستقل هستند که عملکردهای خود را از طریق رابط های تعریف شده ای در اختیار کاربران قرار می دهند.
WSDL یا Description Language Web Service یکی از راه‌هایی است که به صورت گسترده برای تعریف این رابط ها به کار می‌رود و به وسیله آنها، جزییات لازم برای اتصال درخواست کننده به ارائه دهنده سرویس تعریف می‌شود.

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