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

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

سیستم یکپارچه (Monolithic) چیست؟

سیستم های یکپارچه دارای یک سیستم خدمات رسان هستند که تمامی سیستمها (موبایل، وب و…) به آن متصل می شوند تا از آن خدمات دریافت کنند.

میکروسرویس (MicroService) چیست؟

سیستم های مبتنی بر میکروسرویس دارای چند سیستم خدمات رسان هستند که تمامی سیستمها (موبایل، وب و…) قسمت های مختلف خدمات را از چند سیستم جدا دریافت می کنند.

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

میکروسرویس‌ها بر مبنای معماری مبتنی بر سرویس ساخته شده‌اند.

معماری مبتنی بر سرویس یا «Services Oriented Architecture» (به اختصار SOA): به اپلیکیشن‌های مستقر در کامپیوتر ها(هاستهای) مختلف اجازه ی ارتباط با یکدیگر را می دهد تا بتوانند وظایفی را بر دوش یکدیگر قرار دهند.

مشکلاتی که میکروسرویس حل می کند.

نرم افزار ها دچار رشد بیش از حد هستند. واین رشد از جهت های زیادی وجود دارد:

1. رشد پایگاه داده
2. افزایش پیچیدگی پایگاه داده
3. رشد نیاز های موجود
4. رشد مصرف پهنای باند
5. رشد مصرف منابعی مثل (CPU  و RAM)
6. رشد تعداد کاربران استفاده کننده

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

سیستمی که از هرجهت رشد کند هزینه بیشتری برای موارد زیر نیاز خواهد داشت:

1. توسعه نرم افزار
2. نگهداری نرم افزار
3. خطایابی و تست نرم افزار
4. امکان دسترسی به نرم افزار از همه جا

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

نگهداری  نرم افزار

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

امنیت نگهداری داده ها

نگهداری داده ها در یکجا بسیار خطرناک است. گرفتن پشتیبان از داده های متمرکز بسیار سخت و طاقت فرسا است. فرض کنید قصد دارید از یک سیستم تنها با 500 گیگابایت فضای ذخیره سازی پشتیبان تهیه کنید. حال بنده سیستم هایی با بیش از 10 ترابایت فضا دیده ام که دچار رشد روز افزون بوده اند و صاحبان آنها دیگر نمیدانند با این سیستم چکار کنند. اگر سیستم از کار بیفتند کل داده ها از دسترس خارج می شوند.

کاربرد های رایج

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

وقتی دارید از طریق پنل پیامک یا ایمیل پیام خود را ارسال می کنید به یک میکروسرویس متصل هستید که تنها پیام را ارسال می کند.

اتصال نرم افزارهای توزیع شده

فرض کنید 5 نرم افزار داریم که هرکدام داده های متنوعی و در زمینه کاربردی خود تولید و ذخیره می کنند هم چنین از زبان ها و ابزار های متفاوتی برای تولید آنها استفاده شده است. حال فرض کنید درسطح مدیریت به بخشی از داده های این نرم افزار ها نیاز داریم. دو کار می شود کرد:

1. یک نرم افزار جدید طراحی و پیاده سازی نمایید و تمام امکانات 5 نرم افزار را وارد آن کنید. خیلی سخته درسته؟!
2. یک سناریو برای هرکدام از نرم افزار ها چیده و تحولی تیم توسعه آن نرم افزار می دهیم. تیم توسعه از طریق ابزار های تولیدی خود نرم افزار می تواند میکروسرویس و REST API برای نرم افزار (با یک پروتکل امنیتی مناسب) طراحی نماید. پس از آن یک نرم افزار جامع نوشته خواهد شد که داده های موجود را جمع آوری کرده و از آنها استفاده می کند.

روش دوم (استفاده از میکر سرویس) چه مزایایی دارد:

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

روش دوم (استفاده از میکر سرویس) چه معایبی دارد:

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

شکستن یک نرم افزار بزرگ به نرم افزار های کوچک

1. می توانی سیستم حساب کاربری را جدا نمایید و از طریق یک میکروسرویس به آن هدف دست پیدا کنید. (قسمت مدیریت کاربران یکی از سنگین ترین ماژول ها در سیستم های بزرگ می باشد.)
2. سیستم سفارشات در فروشگاه ها را میتوان به یک میکروسرویس جدا شکست.
3. سیستم مدیریت فروش در فروشگاه ها را میتوان به یک میکروسرویس جدا شکست.
4. …

چند فریمورک های طراحی میکروسرویس

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

Lumen

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

Spring Boot with Spring Cloud

اگر از فریمورک Spring استفاده می کنید پس این فریمورک راست کار شما است.

GoMirco (Golang Microservices framework)

اگر از فریمورک GO استفاده می کنید میتوانید GoMirco را امتحان کنید.

نتیجه

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