بسیاری از برنامه نویسان و طراحان نرم افزار خاطره خوشی از معماری سرویس‌گرا ندارند. این مسأله دلایل بسیاری دارد که از جمله آنها می توان به پیچیدگی‌های فراوان ESB (Enterprise Service Bus) ها اشاره کرد. معماری سرویس‌گرا تلاشی بود برای جلوگیری از مشکلاتی که معماری یکپارچه (Monolithic) به تیم و محصول تحمیل می‌کرد. هرچند معماری سرویس‌گرا اقبال خوبی از سمت سازمان‌ها و شرکت‌های بزرگ کسب کرد ولی عمر زیادی نداشت و امروز از توجه کمتری برخوردار است. از طرفی محصولات یکپارچه بزرگ سازمانی و مشکلاتشان همچنان وجود دارند.
میکرو سرویس مفهمومی است که سعی میکند با استفاده از تجربه معماری سرویس‌گرا نقص‌های آن را برطرف کرده و به کمک طراحان بیاید.
در معماری میکروسرویس سیستم به اجزاء کوچکتری تقسیم میشود که هرکدام به طور مستقل عمل می‌کنند و یک عمل خاص را به خوبی انجام می‌دهند. این میکروسرویس‌ها درکنار همدیگر همان کار یک نرم افزار یکپارچه را انجام خواهند داد، آنها توانایی این را دارند که زندگی را برای طراحان ساده‌تر و زیباتر کنند!
معماری میکرو سرویس (Microservice) در سایت های بزرگ با ترافیک بالا مورد استفاده قرار می گیرد. به این ترتیب که سایت اصلی تبدیل می شود به مجموعه ای از سایت های کوچک با دیتابیس جدا که می توانند در سرور مستقل اجرا شوند.
میکرو سرویس چیست؟
وقتی بازدید یک سایت بالا می رود دیگر یک سرور جوابگوی ترافیک بوجود آمده نیست. در این مواقع اولین راه حل استفاده از سرورهای قوی تر است. اما هزینه سرورهای قوی تر رشد تساعدی دارد و در میزان ظرفیت آنها هم محدودیت وجود دارد. در دراز مدت تنها چاره استفاده از چند سرور برای پاسخگویی به کاربران است. اینجا MicroService ها مهم می شوند.
تیم برنامه نویسی قسمت هایی از سایت که ترافیک بالایی دارند را به سایت های کوچک با دیتابیس مجزا می شکند و آنها را در سرورهای مستقل قرار می دهد. مثلا سیستم آپلود فایل در یک سایت فروش فایل یا سیستم ارسال Notification در یک شبکه ی اجتماعی می تواند جدا سازی شود و حجم زیادی از ترافیک سرور اصلی را کم کند.
هر کدام از Microservice ها می توانند با تکنولوژی متفاوتی پیاده شوند که دست برنامه نویسان را برای انتخاب بهترین ها باز می گذارد. مثلا می شود سایتی داشت که همزمان از ASP و PHP و Node استفاده کند و دیتابیس های آن هم ترکیبی از SQL Server و NoSQL و MangoDB باشد.
این جدا سازی باعث می شود بتوان یک قسمت از سایت را بدون درگیر کردن سایر قسمت ها بروز رسانی کرد و در صورت بروز مشکل در یک قسمت کل سایت از کار نمی افتد.
استفاده از میکروسرویس ها چالش های زیادی هم دارد. بعد از جدا کردن فریم ورک ها و دیتابیس ها باید راهی برای برقراری ارتباط بین آنها ایجاد کرد. معمولا از سیستم های پیام رسان استفاده می شود که پیاده سازی پیچیده ای دارند.
از منظری دیگر این معماری با پیاده سازی سرویس‌های متعدد و غیروابسته، پیاده‌سازی تغییرات در نرم افزار را ساده‌تر می نمایند. در این معماری Microservice ها به دو شکل متداول با هم ارتباط دارند، یکی از طریق REST و دیگری از طریق Messaging. پیاده سازی بصورت Messaging از بهم تنیدگی کدها می‌کاهد و وابستگی بین سرویس‌ها را به حداقل می‌رساند. برای این نوع پیاده سازی در .NET می توان از کتابخانه MassTransit استفاده نمود. MassTransit یک Service Bus می‌باشد که از تکنولوژی‌های RabbitMQ و Azure ServiceBus در پشت صحنه بهره می‌برد و کمک میکند تا بتوان راحت‌تر معماری Microservice را بطور صحیح پیاده سازی نمود.
مقایسه Microservices و Service-Oriented Architecture
هر دو معماری microservices و SOA در ذیل معماری service based در نظر گرفته می شود. به این معنا که تاکید اصلی هردو این معماری ها بر این است که پیاده سازی عملکردهای کسب وکاری می بایست در قالب سرویس انجام گردد.این دومعماری درحالیکه تفاوتهای زیادی بایکدیگر دارند در عین حال دارای خصوصیات مشترکی نیز هستند.
یک خصوصیت مشترک بین تمام معماری های مبتنی بر سرویس بحث توزیع شدگی است به این معنا که مولفه های سرویس ها با پروتکل هایی ازراه دور قابل استفاده می باشندبطورمثال پروتکل های:
- REST
- Simple Object Access Protocol (SOAP)
- Advanced Message Queuing Protocol (AMQP)
- Java Message Service (JMS)
- Microsoft Message Queuing (MSMQ)
- Remote Method Invocation (RMI)
- NET Remoting. Distributed architectures
معماری های توزیع مزایای بیش از معماریهای یکپارچه و layered-based دارد از جمله مقیاس پذیری بهتر، decoupling بهتر، و کنترل بهتر توسعه، تست، و استقرار.
مولفه هادر یک معماری توزیع شده تمایل بیشتر به self-contained دارند که این امر اجازه می دهد کنترل تغییر بهتر و تعمیر و نگهداری آسان ترداشته باشند که به نوبه خود منجر به برنامه های کاربردی که قوی تر می شود.
معماری توزیع شده بطور کلی سبب می شود برنامه های کاربرودی loosely coupled بهتر وماژولاریتی قویترداشته باشند.
در زمینه معماری مبتنی بر سرویس، درعمل پیمانه ای که مورد نظر است در واقع کپسوله سازی بخش هایی از نرم افزار درقالب سرویس است که می تواند به صورت جداگانه طراحی، توسعه، تست و مستقر گردد و وابستگی کم و یا هیچ بادیگر اجزاء یا خدمات را داشته باشد.
از دگرسو در دنیای ما همه چیزها علاوه بر مزایا دارای چالش هایی می باشد از جمله چالش های استفاده از معماری مبتنی برسرویس می توان به موارد ذیل اشاره نمود :
- افزایش پیچیدگی ها وهزینه های مرتبط
- هزینه نگهداری و تغییرات service contracts
- انتخاب پروتکل مناسب دسترسی از راه دور
- امنیت remote services
- مدیریت distributed transactions
در حقیقت Microservices روشی برای توسعه برنامه های کاربری است که در آن یک برنامه بزرگ و پیچیده به مجموعه ای از سرویس های کوچکتر و مستقل از یکدیگر تقسیم می شود. هر یک از سرویس ها هدف مستقلی را دنبال میکند و با استفاده از رابط های بسیار سبک و سریعی با سایر سرویس ها تعامل دارد، همچنین عموما از API ها با منبع HTTP در توسعه آن ها استفاده شده است. به طور مثال یک برنامه فروش یا حسابرسی را می توانیم با ساختارMicroservices به گونه ای توسعه داد که در آن یک سرویس مسئول احراز هویت باشد، سرویس دیگر مسئول نگهداری داده ها، سرویس دیگر انجام پردازش ها و به همین ترتیب در آینده نیز با توسعه سرویس های مستقلی میتوان آنرا به صورت کاملا ماژولار توسعه داد.
محاسن Microservice ها:
🔻 گسترش و توسعه آسان در مقایسه با روش های کلاسیک
🔻افزایش قابل توجه سرعت و چابکی در تولید
🔻مقیاس پذیری و انعطاف پذیری برنامه ها
🔻 قابلیت استفاده مجدد از سرویس ها در سایر پروژه ها
🔻 قابلیت استفاده تحت زیرساخت های مبتنی بر رایانش ابری
🔻قابلیت بالا در کار با تکنولوژی کانتینرها مانند #docker
در حالی که استفاده از Microservices مزایای قابل توجهی دارد اما از طرف دیگر با چالش هایی هم مواجه می شویم:
▫️ استفاده از تعداد زیادی جزء کوچک در عملکرد با یکدیگر این پتانسیل را دارد که ساختاری در پیش روی ما قرار دهد که رفع خطا یا بهبود عمکلرد کلی برنامه را با دشواری مواجه کند.
▫️ امکان بروز مشکل Latency زیاد است
▫️تست برنامه فرآیند ساده ای نخواهد بود
مقایسه معماری Monolithic و Microservices
در معماری Monolithic بخش‌های مختلف برنامه سمت سرور از جمله پردازش پرداخت آنلاین، مدیریت حساب‌ها، اعلان‌ها و سایر بخش‌ها همگی در یک واحد منفرد جمع شده‌اند. به عبارتی اگر برنامه تحت وب که در سرور قرار دارد به صورت یک جا با تمام متعلقات خود برای پاسخ به درخواست‌های سمت کلاینت، کار با پایگاه داده و انجام سایر الگوریتم‌ها اجرا شود، این برنامه از معماری Monolithic استفاده میکند.
معماری Microservices راه نجات از مشکلات معماری Monolithic است. در معماری Microservices، برنامه سمت سرور به سرویس‌های مختلفی تقسیم میشود. هر سرویس یک فرآیند پردازشی مستقل است که به عنوان یکی از قابلیت‌های خاص برنامه سمت سرور به حساب می‌آید. به عنوان مثال یک سرویس وظیفه پرداخت‌ها را به عهده دارد و دیگری بطور مستقل برای مدیریت حساب‌ها استفاده میشود. برنامه‌های نوشته شده با این معماری اجباری برای اجرا شدن در سرورهای جداگانه را ندارند، مگر اینکه یک سرویس، شرایط خاصی از جمله مصرف بالای RAM یا نیاز به پردازش ویژه و زیاد در CPU را داشته باشد. در اینصورت بهتر است که سرویس از یک سرور مجزا اجرا شود. لازم است که سرویس‌ها در بستر شبکه با یکدیگر در ارتباط باشند.
خلاصه:
زمانی که شما به عنوان یک Software Architecture یا SysAdmin یا DevOps و یا هر عنوان دیگه ای سعی می کنید تا یک برنامه رو طراحی ، توسعه و یا پیاده سازی کنید نیاز دارید تا در مورد خصوصیات آن نرم افزار اطلاعاتی داشته باشید مثلا این نرم افزار به چه نرم افزار های دیگر یا کتابخانه هایی نیازمند است، چه نوع سیستمی برای میزبانی آن مناسب است و … . یکی از مهم ترین موضوعاتی که شاید کمتر به آن پرداخته میشود تفاوت انواع معماری های نرم افزار از نظر تعامل با سایر اجزا است.
به طور کلی می توان معماری نرم افزار ها را از نظر تعامل با سایر برنامه ها به سه دسته تقسیم بندی کرد:
1- Monolithic
2- SOA (Service Oriented Architecture)
3- Micro Service
ساده ترین و رایج ترین نوع معماری نرم افزار قبل از فراگیر شدن کانتینر ها نرم افزار های Monolithic یا یکپارچه بود اند. در این نوع معماری تمام بخش های نرم افزار در ازتباط با یک هسته ی مرکزی است و تمام اجزاء به صورت جدایی ناپذیری (ماژولار نیست! واگر هم باشد به سختی امکان پذیر است) با یکدیگر کار می کنند برای مثال یک نرم افزار تحت وب را درنظر بگیرید که Web UI , mysql adapter , REST APPI و … همگی در یک نرم افزار بزرگ قرار داشته باشند.
در مقابل دیدگاه Monolithic دیدگاه Micro Service قرار دارد که سعی می کند تمام اجزا را تا حد ممکن از یکدیگر جدا کند و یک نرم افزار توزیع پذیر و ماژولار بسازد که تمامی اجزا از طریق API با یکدیگر در ارتباط باشند. در این طراحی هر جزء تنها وظیفه ی انجام یک کار را دارد برای مثال یک وبسایت را در نظر بگیرید که بر اساس میکرو سرویس ها توسعه داده شده یک میکروسرویس مسئول نگه داری مطالب ، دیگری نگه درای کاربران ، دیگری جستوجو و … و چون تمام این اجزا از هم مستقل هستند می توانید هر کدام را با یک زبان برنامه نویسی توسعه دهید و به صورت جداگانه به روز رسانی کنید.
شاید شما هم فکر کنید که SOA ( معماری سرویس گرا ) با Micro Service ندارد! اما این طور نیست در حقیقت میکروسرویس ها را می توان بدون هیچ تغییری در هر پروژه ای استفاده کرد مثلا sql adapter را از یک پروژه برداشت و در پروژه ی دیگر به راحتی استفاده کرد اما SOA ها برای هر اپلیکیشن منحصر به فرد خواهند بود. تفاوت دیگر اختلاف اندازی برنامه ها است که در میکروسرویس ها به شکل محسوسی بسیار کم است.
در حقیقت می توان SOA را ما بین معماری Monolithic و Micro Service قرارداد و این گونه در نظر گرفت که یک نرم افزار ماژولار است که هر ماژول آن به صورت Monolithic توسعه داده شده. برای مثال می توان یک نرم افزار مانتیتورینگ را در نظر گرفت که داری ماژول های مختلفی از جمله Alerting است که خود Alerting یک ساختار یکپارچه دارد از اجزاء EMail Sender , SMS Sender , Push Notification و …