آن چه در این مقاله خواهید خواند:
معرفی MicroService
من ارسلان میربزرگی، در این مقاله قصد دارم تا شما را با معماری microservice ها و مزایا و ویژگی‌های این نوع معماری و همینطور مدیریت داده در معماری microservice و اینکه چه زمانی و در کجا از این معماری استفاده می‌کنیم در سه بخش:معرفی و بررسی Monolithic و Microservice بخش 1 ، معرفی و بررسی Monolithic و Microservice بخش 2 و معرفی و بررسی Monolithic و Microservice بخش 3 آشنا کنم. با من همراه باشید.
اگر قسمت اول رو نخوندین پیشنهاد میکنم اول قسمت یک رو بخونید:
در نرم افزار‌های Enterprise، چالش اصلی تیم، توسعه محصول نیست. این چالش بعد از اجرای نرم افزار ایجاد می‌شود. مواردی مانند مدیریت تغییرات و scaling و یا بازنویسی نرم افزار در صورت عدم توسعه صحیح، از جمله این چالش‌ها هستند. برای درک بهتر این موضوع، با یک مثال بحث را ادامه می‌دهیم.
فرض کنید یک نرم افزار جامع بیمه ( Core Insurance ) داریم که به شکل نرم افزاری یکپارچه و بر پایه معماری Monolithic است. بعد از چند سال، تصمیم گرفته شده که در بخش‌های این نرم افزار مانند بیمه عمر، بیمه مسافرتی و بیمه درمان، تغییراتی ایجاد شود.
در این حالت مثلا تغییرات مربوط به بیمه درمان سریع تر اعمال شده و آماده ارسال به مشتری است اما به دلیل یکپارچه بودن سیستم ، باید انتشار نسخه تغییر یافته تا اتمام تغییرات بخش‌های دیگر به تعویق بیفتد.
در یک مثال دیگر در نظر بگیرید که به دلیل افزایش تعداد کاربران در یکی سیستم، می‌خواهیم سیستم را scale out کنیم. در این حالت باید چند نسخه از کل سیستم را در پروسه‌های مستقل از یکدیگر قرار دهیم.
در این حالت به دلیل وابستگی‌های بخش‌های سیستم به یکدیگر، اینکار با کندی انجام می‌شود و هزینه‌های scale out نیز افزایش می‌یابد.
طبیعتا اگر این سیستم به زیر مجموعه‌های کوچکتری تقسیم بندی شود، هزینه‌ها و زمان scale out کاهش می‌یابد. حال فرض کنید هر کدام از این زیر مجموعه‌ها قابلیت کسب و کار را به صورت یک سرویس مجزا داشته باشند، در این حالت به نظر شما هزینه تعمیرات و نگهداری آنها چه تغییراتی خواهد داشت؟
جواب به این سوال را با یک مثال قابل درک‌تر خواهیم داد.
فرض کنید زیر مجموعه سیستم بیمه عمر به سه قسمت درخواست بیمه نامه، صدور بیمه نامه و بخش خسارت تقسیم می‌شود.
هر کدام از این قسمت‌ها نیز به صورت مجزا، قابل ارائه به مشتری هستند برای مثال درخواست بیمه نامه شامل پر کردن فرم پیشنهاد، بررسی اطلاعات وارد شده توسط پزشکان بیمه و اعلام نظر کارشناسان بیمه برای افزایش نرخ بیمه نامه بر اساس ریسک‌های پزشکی و شغلی فرد بیمه شده است که در نهایت پس از چند روز، فرم پیشنهادی به تایید کارشناسان رسیده و به بیمه نامه تبدیل می‌شود. در این حالت، اعمال تغییرات یا scaling نسبت به حالات قبلی، آسان‌تر و دارای هزینه کمتری است.
معماری Microservice
معماری microservice یا MSA، روش توسعه سیستم‌های نرم افزاری است که در طی چند سال گذشته به صورت چشمگیری در میان کاربران مورد استقبال قرار گرفته است.
اگرچه ارائه تعریف دقیقی برای آن کمی دشوار است اما بسیاری از توسعه دهندگان برنامه‌ها، استفاده از معماری microservice را برای ایجاد برنامه‌های کاربردی خود به روش‌های دیگر ترجیح می‌دهند. معماری microservice یک معماری سرویس گرا است و در ساخت برنامه‌ای به منظور ایجاد مجموعه‌ای متشکل از سرویس‌های مرتبط با هم که برای قابلیت‌های تجاری اجرا میشوند، استفاده می‌شود. این ویژگی، امکان تحویل مستمر برنامه‌های کاربردی پیچیده را فراهم می‌کند و به سازمان‌ها، توانایی گسترش فناوری‌هایشان را می‌دهد. معماری microservice در واقع یک رویکرد در حوزه توسعه نرم افزارهاست که در آن یک برنامه بزرگ، به شکل‌ای از خدمات ماژولار ساخته شده است.
هر ماژول در معماری microservice هدفی خاص را دنبال می‌کند و توسط یک رابط کاربری ساده و مناسب، با دیگر ماژول‌‌‌ها ارتباط دارد. معماری microservice راه حلی برای حل مشکلاتی است که در برنامه‌های پیچیده برای برنامه نویسان ایجاد می‌شود. در معماری microservice ها، هر microservice در طی یک فرایند منحصر به فرد اجرا می‌شود و دیتابیس مخصوص به خود را مدیریت می‌کند.
این امر هم موجب فراهم شدن امکان توسعه نرم افزار با رویکرد غیر متمرکز را فراهم می‌کند و هم اجازه می‌دهد تا هر سرویس به صورت مستقل اجرا و مدیریت شود. به عبارت دیگر، در این سرویس‌ها، کمترین میزان مدیریت متمرکز وجود دارد و هر سرویس می‌تواند با زبان برنامه نویسی متفاوتی نوشته شود یا دیتابیس متفاوتی داشته باشد.
کاربرد microservice
microservice روشی برای تقسیم بندی یک برنامه یا اپلیکیشن ( نه فقط اپلیکیشن موبایل ) به بخش‌ها و سرویس‌های کوچکتر، سبکتر و مستقل از یکدیگر و دارای قابلیت مدیریت مجزا است. به بیان دیگر، microservice ، یک معماری توسعه نرم افزار پخش شده یا Distributed است.
در معماری microservice ، برنامه در سمت سرور به سرویس‌های متفاوتی تقسیم بندی می‌شود و هر سرویس یک فرایند پردازشی مستقل است که به عنوان یکی از قابلیت‌های خاص برنامه در سمت سرور محسوب می‌شود.
این سرویس‌ها، صرفا با هدف مدیریت یک وظیفه خاص طراحی میشوند. به طور مثال، وظیفه یک سرویس فقط مدیریت کاربران است در صورتی که وظیفه سرویس دیگر، صرفا کنترل بخش جستجوی سایت است.
برنامه‌های نوشته شده با معماری microservice الزامی برای اجرا در سرورهای مجزا ندارند و این الزام صرفا در حالتی که میزان مصرف RAM بالا باشد یا اینکه احتیاجی به مصرف بالای قدرت پردازش CPU وجود داشته باشد.
در این حالت، بهتر است که هر سرویس از یک سرور مجزا استفاده کند اما در بستر شبکه، این سرویس‌ها با یکدیگر در ارتباط باشند.
در این حالت با توجه به اینکه تمامی microservice ها از یکدیگر مستقل هستند، به راحتی می‌توانیم تا از زبان‌های برنامه نویسی مختلف برای نوشتن آنها استفاده کنیم و یا دیتاهای هر یک را بر روی یک دیتابیس متفاوت ذخیره کنیم. به طور مثال برای ذخیر سنتی دیتاها از MySQL و برای ذخیره داده‌های با ساختار غیر قابل پیش بینی از دیتابیس‌های NoSQL استفاده کنیم.
در اینجا ممکن است برایتان سوال ایجاد شود که چطور سرویس‌های متفاوت در یک برنامه که از معماری microservice استفاده می‌کند، با یکدیگر ارتباط برقرار می‌کنند؟ پاسخ این سوال به این صورت است که برنامه‌ای که بر پایه معماری microservice است، ارتباط بین سرویس‌های مختلف از طریق ریکوئست‌ها یا درخواست‌های از جنس HTTP و API های RESTful برقرار می‌شود. در واقع معماری microservice حل کننده مشکلاتی است که استفاده از معماری Monolithic ایجاد می‌کند.
در معماری microservice، برنامه سمت سرور به سرویس‌های متفاوتی تقسیم می‌شود و هر سرویس دارای فرایند پردازشی متفاوتی است که این امر به عنوان یکی از قابلیت‌های خاص برنامه‌های سمت سرور محسوب می‌شود. به عنوان مثال یک سرویس وظیفه پرداخت‌ها و سرویس دیگر برای مدیریت‌های حساب‌ها استفاده می‌شود.
در دیاگرام بالا، می‌توان فرض کرد که service شماره 1، وب سرور است و با مرورگر برای دریافت درخواست‌ها از سمت کلاینت یا کاربر در ارتباط است و دو service دیگر به عنوان API برای عملیات‌های مختلف دیگر به کار برده میشوند.
فلسفه Microservice
فلسفه معماری microservice، شبیه به فلسفه Unix است. در فلسفه Unix سعی می‌شود تا یک چیز انجام شود اما به نحو احسن. در معماری microservice نیز
– سرویس‌ها کوچک هستند اما هدف تجاری و کاربردی خاصی را دنبال کرده و آن را به سرانجام می‌رسانند.
– فرهنگ سازمان یا کمپانی باید خودکار سازی deployment و تست نرم افزار را بپذیرد. علت این امر این است که در معماری microservice، چنین رویکردی مورد نیاز است و با انجام این کار، بار گذاشته شده بر روی مدیریت، مدیران سیستمی و مسئولان اجرایی کاهش پیدا خواهد کرد.
– فرهنگ و الگوهای طراحی باید در برگیرنده فرهنگ حل خطا و یا شکست باشند و به طور دائم در جهت بهبود سرویس‌ها تلاش کنند.
– سرویس‌ها باید انعطاف پذیر، واکنش‌گر و با قابلیت ترکیب شدن با سایر سرویس‌ها بوده و تنها وظیفه‌ای را که بر عهده دارند به طور کامل انجام دهند.
مزایای معماری Microservice
امروزه ماژولار بودن برنامه‌ها به مزیتی رقابتی در هر صنعت تبدیل شده است. ایده موجود در معماری microservice به توسعه دهنده‌ها این امکان را می‌دهد تا برنامه‌ها و اپلیکیشن‌های خود را بر مبنای اجزا و یا سرویس‌های مجزا از هم که به راحتی قابل تغییر، حذف و یا به روزرسانی هستند، توسعه دهند و در این حالت نیازی به درگیر کردن کل برنامه یا اپلیکیشن نباشد.
اگر بخواهیم مزایای معماری microservice را به صورت کلی مورد بررسی قرار دهیم می‌توانیم به موارد زیر اشاره کنیم.
– برخلاف معماری Monolithic، در برنامه‌ای که از معماری microservice استفاده می‌کند، سرویس‌ها بر اساس معماری microservice تقسیم بندی نمی‌شوند بلکه این تقسیم بندی بر اساس نوع وظیفه آن سرویس‌ها است.
به بیان دیگر، یک سرویس مانند آپلود یکی فایل، شامل بخش‌هایی مانند رابط کاربری، مدل‌های مرتبط با دیتابیس، کنترلر، سیستم لاگینگ و… خواهد بود ( در این حالت فرض می کنیم که توسعه دهنده، سرویسی با نام File Uploader را ایجاد کرده و پس از آن برای ساخت سرویس‌های مشابه در پروژه‌های دیگر نیز از آن استفاده می‌کند. )
– یکی دیگر از مزیت‌های معماری microservice باز گذاشتن دست برنامه نویسان در استفاده از زبان‌های برنامه نویسی متفاوت برای قسمت‌های مختلف پروژه است.
در واقع با توجه به اینکه امروزه بعضی از زبان‌های برنامه نویسی، در بخش‌ها و حوزه‌های خاص، به صورت تخصصی‌تر عمل می‌کنند و استفاده از زبانی که به صورت اختصاصی برای فعالیت خاصی طراحی شده است، عملکرد برنامه ما را بالاتر خواهد برد، توسط معماری microservice می‌توانیم برای هر سرویس از زبان برنامه نویسی جداگانه‌ای استفاده کنیم و عملکرد نهایی برنامه و اپلیکیشن خود را در سطح عالی قرار دهیم.
– معماری microservice ها اصطلاحا Scalable یا قابل توسعه هستند. ماهیت مستقل ماژول‌های مختلف در یک microservice ، این امکان را به ما می‌دهد تا با استفاده از زبان برنامه نویسی خاص، دیتابیس انحصاری و حتی سرور خاص، برنامه یا اپلیکیشن خود را توسعه دهیم و در صورت نیاز، صرفا منابع مربوط به همان پلتفرم را ارتقا دهیم.
یکی از مهمترین و با ارزش‌ترین قابلیت‌های معماری microservice مربوط به افزایش قسمت‌های یک سرویس ( مثلا سرویسی که تنها یک قسمت در حال اجرا دارد، به سرویسی با دو یا سه قسمت مجزا تبدیل شود ) بدون نیاز به اضافه کردن قسمت‌های سرویس‌های دیگری که با آن در ارتباط است، می‌باشد. این حالت را می‌توانید در شکل زیر مشاهده کنید.
در این دیاگرام همانگونه که مشاهده می‌کنید، از سرویس شماره 1، دو قسمت در دو سرور مجزا ایجاد شده است که ترافیک ورودی بین آنها توسط Load Balancer تقسیم می‌شود و سایر سرویس‌ها به همان تعدادی که بودند باقی می‌مانند.
مشکلات این معماری
– از آنجایی که برنامه های سمت سروری که با معماری microservice نوشته شده اند، به سرویس‌های مختلفی تقسیم میشوند، توسعه و تنظیمات هر یک از آنها می‌تواند سخت و وقت گیر باشد.
– ارتباط بین سرویس‌ها در معماری microservice در بستر شبکه انجام می‌شود، بنابراین باید انتظار کندی عملکرد سرویس‌ها را داشته باشید.
– به دلیل ارتباطات شبکه‌ای که در برنامه‌های استفاده کننده از معماری microservice وجود دارد، احتمال رخنه‌های امنیتی در این برنامه‌ها بیشتر است.
– نوشتن کدهای مربوط به سرویس‌هایی که در بستر شبکه با سرویس‌های دیگر در ارتباط هستند، مشکل است و برنامه نویسان در این شرایط، درگیر مسائلی مانند برقرار ارتباط، رمزگذاری داده‌ها و تبدیل آنها هستند.
– به دلیل مجزا بودن بخش‌های مختلف برنامه با یکدیگر، بررسی و نظارت و ردیابی عملکرد سرویس‌ها با یکدیگر از کارهای اصلی توسعه دهندگان یا استفاده کنندگان از برنامه‌های مبتنی بر معماری microservice است.
و در نهایت اینکه سرعت برنامه‌های نوشته شده با معماری microservice از برنامه‌های نوشته شده با معماری Monolithic کندتر است. علت این موضوع نیز به محیط اجرایی برنامه‌ها باز می‌گردد. برنامه‌های نوشته شده با معماری Monolithic بر روی حافظه سرور پردازش میشوند.
مدیریت داده در میکروسرویس
در معماری microservice ، هر سرویس می‌تواند دارای دیتابیس مختص خود برای ذخیره داده‌هایش باشد یا از دیتابیس مرکزی استفاده کند. استفاده از دیتابیس اختصاصی برای هر سرویس، مشکلات خود را دارد.
مشکلاتی مانند اینکه باید بین سرویس‌های مختلف، هماهنگی صورت بگیرد که در این حالت، اگر یکی از سرویس‌ها دچار مشکل شود یا غیر فعال شود، تمامی سرویس‌هایی که با آن در ارتباط هستند نیز دچار مشکل خواهند شد و این مشکل به صورت زنجیره‌ای به تمام سرویس‌هایی که به داده‌های در حال تبادل با این سرویس‌ها، وابسته هستند نیز سرایت خواهد کرد.
علاوه بر آن در معماری microservice داده‌های تکراری نیز وجود دارند و کدنویسی برای این سیستم مشکل خواهد بود.
در نتیجه بهتر است که سرویس‌ها با دیتابیس مرکزی سروکار داشته باشند و اگر سرویس خاصی نیاز داشته باشد که داده‌های خاصی را تولید کند که با سرویس‌های دیگر به اشتراک گذاشته نشود، می‌تواند از دیتابیس اختصاصی خود استفاده کند.
نکته مهم دیگر این است که نباید سرویس‌ها به صورت مستقیم با دیتابیس مرکزی در ارتباط باشند، بلکه به سرویسی مجزا به نام سرویس پایگاه داده که وظیفه فراهم کردن API های مخصوص کار با دیتابیس مرکزی را بر عهده دارد، نیاز است.
برای ادامه مقاله، قسمت سوم که قسمت آخر این مقاله هست رو ببینید:
