امین باقری
امین باقری
خواندن ۲۱ دقیقه·۳ سال پیش

بررسی معماری های مبتنی بر میکروسرویس

چكيده

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

كلمات كليدي

میکروسرویس، معماری میکروسرویس، سبک معماری، الگوی معماری

۱- مقدمه

معماری میکروسرویس در چندسال اخیر به شدت در حال گسترش و فراگیری در میان توسعه دهندگان و معماران است. اگرچه اولین اشاره مستقیم به واژه "میکروسرویسها" به سال 2011 و در یک کارگاه معماری نرم افزار برمی گردد، اما داغ شدن این موضوع در طی سالهای 2014 و 2015 بود؛ هم اکنون میکروسرویس ها یکی از موضوعات جذاب در دنیای نرم افزار و معماری محسوب می شود و هرماه مقالات، کتاب ها و ارائه های جدیدی از آن منتشر می شود و در کنفرانس ها یا سمینارهای تجاری-علمی نیز علاقه مندان زیادی را به خود جذب می کند؛ حتی بر اساس گزارش های گوگل از میزان رشد جستجوی عبارات مرتبط با میکروسرویس، می توان به نقش محوری آن در معماری و توسعه سیستم ها پی برد.

در دنیای تجاری نیز شرکت های مطرحی پیشگام پیاده سازی و استقرار این معماری بوده اند که می توان به شرکت های Uber ،Netflix ، Amazon ،Ebay و Sound Cloud اشاره نمود.

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

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

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

2- روش تحقیق

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

برای جستجوری مقالات، از کلیدواژه های زیر استفاده شده است:

  • میکروسرویس ها
  • معماری میکروسرویس
  • الگوهای معماری میکروسرویس
  • سبک های معماری

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

3- مقایسه معماری میکروسرویس با معماری های یکپارچه و سرویس گرا

در این بخش به تعریف و بیان ویژگی های کلیدی معماری های میکروسرویس و یکپارچه، در مقایسه با یکدیگر می پردازیم و مزایا و معایب معماری های میکروسرویس را شرح می دهیم؛ همچنین به به اختصار، تفاوت های مهم معماری میکروسرویس و معماری سرویس گرا را ذکر می کنیم.

1-3- معماری یکپارچه

معماری یکپارچه (Monolith Architecture)، یک معماری برای برنامه های کاربردی است که در آن ماژول ها نمی توانند به صورت مستقل از هم اجرا شوند. مشکلاتی که در معماری یکپارچه با آن ها مواجه هستیم عبارت اند از:

  • نگهداری و تکامل برنامه های مبتنی بر معماری یکپارچه به دلیل پیچیدگی، دشوار است؛ ردیابی باگ های برنامه نیز بسیار دشوار و زمان بر است.
  • سیستم های یکپارچه، از «جهنم وابستگی» رنج می برند [1] که در آن، افزودن و یا به روزرسانی کتابخانه ها، منجر به سیستم های ناسازگاری می شود که کامپایل یا اجرا نمی شوند و یا بد اجرا می شوند.
  • هر تغییری در یک ماژول برنامه یکپارچه، نیاز به راه اندازی مجدد کل برنامه دارد؛ برای پروژه های بزرگ، راه اندازی مجدد، معمولا مستلزم خرابی های قابل توجهی است که مانع توسعه، تست و نگهداری پروژه می شود.
  • یکپارچگی، توسعه دهندگان را مجبور می کند که از تکنولوژی های یکسان شامل زبان برنامه نویسی و فریمورک، برای توسعه تمام برنامه استفاده کنند.
  • مقیاس پذیری را محدود می کند؛ استراتژی معمول برای رسیدگی به درخواست‌ها برای تغییر برنامه، ایجاد نمونه‌های جدید از همان برنامه و تقسیم بار بین نمونه‌ها است.

سبک معماری میکروسرویس [2] برای مقابله با چنین مشکلاتی پیشنهاد شده است. در تعریف میکروسرویس، ما از اصطلاح «منسجم» (Cohesive) [3] استفاده می‌کنیم تا نشان دهیم که یک سرویس، تنها عملکردهایی را پیاده‌سازی می‌کند که کاملا مرتبط با دغدغه هایی هستند که قرار است مدل‌ کند.

2-3- میکروسرویس

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

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

شکل 3-1 نمونه سیستم ساده فروش اینترنتی مبتنی بر معماری میکروسرویس
شکل 3-1 نمونه سیستم ساده فروش اینترنتی مبتنی بر معماری میکروسرویس

3-3- معماری میکروسرویس

تعاریف مختلفی تاکنون برای معماری میکروسرویس ارائه شده است که در ادامه، ۳ تعریف که توسط مراجع معتبر ارائه شده است را مرور می کنیم:

  • سبک معماری مایکروسرویس، رویکردی برای توسعه یک نرم افزار متشکل از تعدادی سرویس کوچک و مستقل است که هر سرویس به اتکاء منابع و زیرساخت خودش اجرا شده و از طریق پروتکل های سبک مبتنی بر HTTP با دیگران ارتباط دارد. این سرویس ها براساس قابلیت های کسب وکار، طراحی و ساخته می شوند و بر بسترهای فناوری با زبان های برنامه نویسی مختلفی قابل استقرار هستند. این سرویس ها حداقل نیاز به مدیریت متمرکز را دارند و هر سرویس پایگاه داده مخصوص به خود را مدیریت می کند [2].
  • معماری مایکروسرویس یک رویکرد مهندسی مبتنی بر شکست نرم افزار به ماژول های تک کارکردی است که مستقل تولید و مستقر می شوند و با واسط های خوش تعریف با دیگر سرویس ها ارتباط دارند. این سرویس ها توسط تیم های کوچکی تولید و پشتیبانی می شوند که از تمام چرخه حیات سرویس پشتیبانی می کند [4].
  • مایکروسرویس ها یک تکنیک توسعه نرم افزار مشتق شده از سبک معماری سرویس گرا است که از مجموعه ای از سرویس های خوش تعریف تشکیل شده است. در معماری مایکروسرویس پروتکل های ارتباطی، سبک و مستقل از پلتفرم هستند و سرویس ها دامنه و مسئولیت معین و مشخصی دارند؛ مزایای این معماری بهبود ماژولاریتی سیستم و تسهیل توسعه، استقرار و تست سیستم است؛ همچنین سیستم توسعه یافته دارای مقیاس پذیری بالا و سرعت بالاتر اعمال تغییر است. این معماری با رویکرد DevOps در توسعه و پشتیبانی نرم افزارها هماهنگی دارد [5].

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

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

اصل معماری میکروسرویس، به مدیران و توسعه دهندگان پروژه کمک می کند تا یک خط راهنما برای طراحی و اجرای برنامه های کاربردی توزیع شده داشته باشند؛ با پیروی از این اصل، توسعه دهندگان، بر پیاده‌سازی و تست چند قابلیت منسجم، تمرکز می کنند. این اصل همچنین برای میکروسرویس‌های سطح بالاتر که به هماهنگ کردن عملکردهای میکروسرویس‌های دیگر کمک می کنند، صدق می‌کند. در شکل 3-2 ساختار رایج معماری میکروسرویس و معماری یکپارچه را مشاهده می کنید.

شکل 3-2 مقایسه معماری میکروسرویس با معماری یکپارچه
شکل 3-2 مقایسه معماری میکروسرویس با معماری یکپارچه


در ادامه به طور خلاصه به برخی از تفاوت های مهم معماری میکروسرویس با معماری سرویس گرا اشاره می کنیم:

  • در معماری سرویس گرا، سیستم به چند سرویس که کارکرد های تجاری (Business Functionalities) و درشت دانه سیستم را برمی‌گیرند شکسته می شود؛ اما در معماری میکروسرویس، سیستم با توجه به مفاهیم DDD و Bounded By Context به میکروسرویس هایی که هریک از آنها کوچکترین کارکرد ها را در برمی گیرند شکسته می شود.
  • در میکروسرویس بر استقرار مستقل هر میکروسرویس تاکید بسیار زیادی وجود دارد.
  • در معماری میکروسرویس استفاده از API Gateway اما در معماری سرویس گرا، استفاده از ESB رایج است.
  • در معماری سرویس گرا، برای ارتباط هر سرویس با EBS، از پروتکل های مختلفی می توان استفاده کرد اما در معماری میکروسرویس از یک پروتکل ارتباطی یکسان و سبک وزن، استفاده می شود.
  • میکروسرویس ها برخلاف ها سرویس ها معمولا منطق داده ای مستقلی دارند.

در ادامه به طور مختصر، برخی از مزایا و معایب این معماری را بررسی می کنیم [6]:

1-3-3- مزایای معماری میکروسرویس

  • به دلیل امکان توسعه و استقرار هر میکروسرویس به طور مستقل از سایر میکروسرویس ها و امکان توسعه هر میکروسرویس توسط یک تیم توسعه، زمان آماده شدن برنامه کاربردی برای ارائه به بازار (Time to Market)، کاهش می یابد.
  • هر تیم برای توسعه میکروسرویس، از تکنولوژی های دلخواه خود می تواند استفاده کند و نیاز به یکسان بودن تکنولوژی های مورد استفاده در توسعه میکروسرویس ها نیست.
  • میکروسرویس ها قابلیت مقیاس پذیری بالایی دارند؛ از آنجایی که هر سرویس مستقل است، افزودن نمونه های سرویس به صورت پویا ساده است. به این ترتیب عرضه خدمات به راحتی با تقاضا، تطبیق داده می شود.

2-3-3- معایب معماری میکروسرویس

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

4- معماری های میکروسرویس در دامنه های موضوعی خاص

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

در شکل 4-1، دسته بندی حاصل از معماری های میکروسرویس مطالعه شده در مقالات را در قالب یک درخت موضوعی مشاهده می کنید.

شکل ۴-۱ درخت موضوعی معماری های میکروسرویس مطالعه شده
شکل ۴-۱ درخت موضوعی معماری های میکروسرویس مطالعه شده

1-4- سیستم های توزیع شده

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

1-1-4- رایانش ابری

[7] در مورد استفاده از میکروسرویس ها برای ارائه خدمات شبکه در مراکز داده ابری بحث کرده است. سیستم پیشنهادی، از میکروسرویس ها در سطوح مختلف که با Data Plane در ارتباط هستند، برای انجام فعالیت های امنیتی شامل نظارت بر ترافیک شبکه و گزارش تهدید های امنیتی استفاده می کند.

[8] روش BigVM را برای کاهش بار مسئولیت توسعه دهندگان SaaS، با خودکارسازی توسعه برنامه های کاربردی SaaS مبتنی بر میکروسرویس ها ارائه دادند. BigVM می تواند کارایی سیستم را با افزودن مولفه های خاص از جمله یک موتور ارکستراسیون میکروسرویس برای هماهنگی میکروسرویس ها و یک موتور گردش کار که بوسیله آن، می‌توان ریزسرویس‌ها را در طول زمان اجرا طراحی و به صورت پویا سفارشی کرد، افزایش دهد. BigVM بر شناسایی میکروسرویس هایی تمرکز دارد که در کاربردهای متعدد به شدت مورد استفاده مجدد قرار می گیرند. مجموعه ای از رابط های مؤلفه استاندارد شده و پروتکل های ارتباطی سرویس به گونه ای پیاده سازی شده اند که این میکروسرویس ها می توانند به طور کامل در BigVM نگهداری شوند. علاوه بر این، BigVM یک سلسله مراتب میکروسرویس چند لایه را فعال می کند که در آن میکروسرویس های لایه پایین به عنوان "جعبه سیاه" مشخص می شوند؛ به طوری که توسعه دهندگان SaaS فقط باید با سفارشی سازی خودکار میکروسرویس های لایه پایین تر، با میکروسرویس های لایه بالاتر سروکار داشته باشند. در نتیجه، توسعه‌دهندگان SaaS می‌توانند از استقرار تعدادی از میکروسرویس ها، به عنوان مثال، میکروسرویس‌های مبتنی بر منابع سیستم‌عامل خودداری کنند. در شکل 4-1 ساختار معماری به روش BigVM را مشاهده می کنید.

شکل 4-1 معماری BigVM و محیط استقرار
شکل 4-1 معماری BigVM و محیط استقرار


[9] یک platform-as-a-service در ابر و مبتنی بر میکروسرویس هایی که در کانتینر ها اجرا می شوند، پیشنهاد کرد. این پلتفرم می تواند توسط توسعه دهندگان برای ساخت سرویس ها در ابر استفاده شود. [10] یک سیستم نظارتی مبتنی بر معماری میکروسرویس برای محیط های ابری پیشنهاد کرد؛ بدین صورت که هر عامل نظارتی به عنوان میکروسرویس هایی بر روی کانتینر ها اجرا می شود.

2-1-4- سیستم های ذخیره سازی توزیع شده

سیستم های فایل توزیع شده مانند Azure Data Lake Store برای ارائه خدمات سیستم فایل، به معماری های میکروسرویس متکی هستند [11]. میکروسرویس های مختلفی برای ارائه عملکردهای مدیریتی برای پشتیبانی از عملیات تجزیه و تحلیل داده ها در Big Data استفاده می شوند. میکروسرویس های Azure Data Lake Store با ارائه دهندگان سیستم های ذخیره سازی (Storage) برای انجام عملیات بر روی داده های ذخیره شده در سیستم فایل ارتباط برقرار می کنند. سیستم پایگاه داده مرکز داده تحقیقاتی Nevada برای پیروی از معماری میکروسرویس ها مجدداً طراحی شد [12]. یکی از پروژه های مرکز داده تحقیقاتی نوادا، قصد گسترش بهره برداری از انرژی منابع تجدیدپذیر و به حداقل رساندن پیامدهای آن بر محیط اطراف خود، مانند سطح آب و حیات وحش را دارد. بنابراین پروژه شامل تحویل مقادیر زیادی از داده ها و انجام عملیات تحلیلی بر روی آن ها برای استخراج اطلاعات مفید است.

2-4- اینترنت اشیا

رویکرد های معماری میکروسرویس، برای توسعه برنامه های کاربردی اینترنت اشیا، به دلیل اهداف طراحی مشابه، ایده آل هستند [13].

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

1-2-4- برنامه های زندگی هوشمند

اخیرا تعداد محققانی که بر روی برنامه های زندگی هوشمند تمرکز کرده اند، افزایش یافته است. [15] امکان استفاده از معماری میکروسرویس برای سیستم مدیریت بلیط راه آهن آلمان را مطالعه می کند.

[16] از محاسبات مه و میکروسرویس ها برای فراهم سازی امکان استفاده از توابع مرجع صدور گواهی (Certificate Authority (CA) Functions) در نزدیکی منابع استفاده می کند. از طریق آن، سطوح حمله و تأخیر احراز هویت را به حداقل رسانده و منجر به طرحی سریع و مقیاس‌پذیر در احراز هویت حجم زیادی از دستگاه‌های با منابع محدود می شود. سپس پروتکل های سبک وزنی را برای رسیدن به سطح بالایی از امنیت و بارهای محاسباتی کم، ارائه می دهد. ارزیابی ها، کارایی و اثربخشی طرح ارائه شده در رسیدگی به احراز هویت تعداد زیادی گره را نشان می دهد و در عین حال از آن ها در برابر تهدیدات مختلف در زندگی هوشمند، محافظت می کند.

2-2-4- مراقبت های پزشکی

[17] یک رویکرد مبتنی بر میکروسرویس برای سیستم های توانبخشی فیزیکی از راه دور (PTS) پیشنهاد کردند که در آن بیماران می توانند از راه دور به امکانات پزشکی دسترسی داشته باشند. در شکل ۴-۲ معماری میکروسرویس پیشنهادی برای این سیستم را مشاهده می کنید.

شکل 4-2 پلتفرم مجهز به اینترنت اشیا – معماری میکروسرویس
شکل 4-2 پلتفرم مجهز به اینترنت اشیا – معماری میکروسرویس


[18] یک پلتفرم پیشنهادی به نام SPIDEP برای استفاده از میکروسرویس ها در سناریو های پزشکی بیماری های عفونی، ارائه می کند. هدف این پلتفرم، تفسیر تغییرات در علائم حیاتی افراد مسن ساکن در مراکز مسکونی است؛ بنابراین تیم پزشکی را قبل از عفونت های احتمالی آگاه می کند. با این حال این پلتفرم، دارای یک سیستم توصیه کننده برای بهبود پشتیبانی تصمیم در پیش تشخیص بیماری های عفونی می باشد [19].

در شکل 4-3 معماری پلتفرم SPIDEP را مشاهده می کنید که در ادامه به طور خلاصه، ارتباط جریان پلتفرم SPIDEP با میکروسرویس ها را توضیح خواهیم داد:

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

ارتباط با کاربر: مکانیسم‌های لازم را برای ارتباط صحیح بین لایه‌ها و زیرلایه‌های مختلف (مانند داده‌ها، اعتبارسنجی یا موارد دیگر) فراهم می‌کند. این ارتباط از طریق پروتکل REST بدست می آید. با این حال، این پروتکل نیاز به استفاده از یک دروازه API دارد.

معماری ابر: خدماتی را برای کاربران نهایی در قالب میکروسرویس های اصلی یا کمکی، با توجه به نیاز های آن ها و سطوح نقش ها و مجوز های آن ها، فراهم می کند. به علاوه، داده ذخیره شده در پایگاه های داده اختصاصی میکروسرویس ها [20] را برای رساندن مزایایی به کاربران هدف از جمله بیماران، پرسنل پزشکی و مقامات بهداشتی، مدیریت می کند [21].

شکل 4-3 ماری پلتفرم SPIDEP
شکل 4-3 ماری پلتفرم SPIDEP


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

۵- الگو های مورداستفاده در معماری های میکروسرویس

هر معماری میکروسرویس از تعدادی الگوی معماری تشکیل می شود. شناخت الگو های معماری، به توسعه دهندگان کمک می کند که از مناسب ترین معماری برای سیستم خود استفاده کنند. در جدول ۵-۱، الگو هایی که در معماری های میکروسرویس مطالعه شده در مقالات یافت شدند را دسته بندی کرده ایم؛ همچنین مزایا و معایب هر الگو نیز آورده شده است. طبق مطالعه انجام شده، برای orchestration و هماهنگی میان میکروسرویس ها، در معماری های جدید، API Gateway الگوی محبوب و رایجی محسوب می شود. برای نحوه استقرار سرویس ها در زیرساخت، الگوی Multiple service per host الگوی بسیار پرکاربردی می باشد. در بحث ذخیره سازی اطلاعات مربوط به سرویس ها، ۳ الگو داریم که در برنامه های کاربردی جدید، الگوی تخصیص پایگاه داده مجزا به هر سرویس، الگوی پرکاربردتری می باشد. اما برای برنامه هایی که از معماری یکپارچه به معماری میکروسرویس مهاجرت کرده اند، به جهت کاهش Failure های احتمالی و سهولت مهاجرت، معمولا از الگوی استفاده از پایگاه داده مشترک برای سرویس ها استفاده می شود.

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

جدول ۵-۱ دسته بندی الگوهای به کار رفته در معماری های میکروسرویس مطالعه شده
جدول ۵-۱ دسته بندی الگوهای به کار رفته در معماری های میکروسرویس مطالعه شده

جمع بندی

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

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

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

هنگام مطالعه مقالات، الگو های به کار رفته در معماری ها را نیز در قالب جدول، دسته بندی کردیم؛ با مشاهده این جدول و مطالعه مزایا و معایب هر الگو، می توان تا حدودی موارد کاربرد هر الگو را متوجه شد و طراحی معماری های میکروسرویس را تسهیل بخشید. همچنین دریافتیم که چه الگو هایی در معماری میکروسرویس، پرکاربردتر هستند؛ برای مثال، در سال های اخیر الگو های API Gateway و Multiple service per host الگو های رایج و پر استفاده ای بوده اند.

«این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است»

مراجع

[1] Dirk Merkel. Docker: Lightweight linux containers for consistent development and deployment. Linux J., 2014(239), March 2014.

[2] Martin Fowler and James Lewis. Microservices, 2014. http://martinfowler.com/articles/microservices.html.

[3] Dhama, H. (1995). Quantitative models of cohesion and coupling in software. Journal of Systems and Software, 29(1), 65-74.

[4] https://developer.ibm.com/technologies/microservices

[5] https://en.wikipedia.org/wiki/Microservices

[6] Dragoni, Nicola, et al. "Microservices: yesterday, today, and tomorrow." Present and ulterior software engineering (2017): 195-216.

[7] Ahuja RPS, Nedbal M, inventors: ShieldX Networks Inc, assignee. Dynamic, load-based, auto-scaling network security microservices architecture. US Patent 9,716,617. July 25, 2017.

[8] Zheng T, Zhang Y, Zheng X, Fu M, Liu X. BigVM: a multi-layer-microservice-based platform for deploying SaaS. Paper presented at: Fifth International Conference on Advanced Cloud and Big Data (CBD); 2017; Shanghai, China.

[9] Guo, D., Wang, W., Zeng, G., & Wei, Z. (2016, March). Microservices architecture based cloudware deployment platform for service computing. In 2016 IEEE Symposium on Service-Oriented System Engineering (SOSE) (pp. 358-363). IEEE.

[10] Ciuffoletti, A. (2015). Automated deployment of a microservice-based monitoring infrastructure. Procedia Computer Science, 68, 163-172.

[11] Ramakrishnan, R., Sridharan, B., Douceur, J. R., Kasturi, P., Krishnamachari-Sampath, B., Krishnamoorthy, K., ... & Venkatesan, R. (2017,

May). Azure data lake store: a hyperscale distributed file service for big data analytics. In Proceedings of the 2017 ACM International Conference on Management of Data (pp. 51-63).

[12] Le, V. D., Neff, M. M., Stewart, R. V., Kelley, R., Fritzinger, E., Dascalu, S. M., & Harris, F. C. (2015, July). Microservice-based architecture for the NRDC. In 2015 IEEE 13th International Conference on Industrial Informatics (INDIN) (pp. 1659-1664). IEEE.

[13] Butzin B, Golatowski F, Timmermann D. Microservices approach for the Internet of Things. Paper presented at: 2016 IEEE 21st International Conference on Emerging Technologies and Factory Automation (ETFA); 2016; Berlin, Germany.

[14] Sun, L., Li, Y., & Memon, R. A. (2017). An open IoT framework based on microservices architecture. China Communications, 14(2), 154-162.

[15] Richter, D., Konrad, M., Utecht, K., & Polze, A. (2017, July). Highly-available applications on unreliable infrastructure: Microservice architectures in practice. In 2017 IEEE International Conference on Software Quality, Reliability and Security Companion (QRS-C) (pp. 130-137). IEEE.

[16] Li, J., Jin, J., Lyu, L., Yuan, D., Yang, Y., Gao, L., & Shen, C. (2021). A fast and scalable authentication scheme in IOT for smart living. Future Generation Computer Systems, 117, 125-137.

[17] Caporuscio M, Weyns D, Andersson J, Axelsson C, Petersson G. Iot-enabled physical telerehabilitation platform. Paper presented at: 2017 IEEE International Conference on Software Architecture Workshops (ICSAW); 2017; Gothenburg, Sweden.

[18] Calderón-Gómez, H., Mendoza-Pittí, L., Vargas-Lombardo, M., Gómez-Pulido, J. M., Rodríguez-Puyol, D., Sención, G., & Polo-Luque, M. L. (2021). Evaluating Service-Oriented and Microservice Architecture Patterns to Deploy eHealth Applications in Cloud Computing Environment. Applied Sciences, 11(10), 4350.

[19] Baldominos, A., Ogul, H., Colomo-Palacios, R., Sanz-Moreno, J., & Gómez-Pulido, J. M. (2020). Infection prediction using physiological and social data in social environments. Information Processing & Management, 57(3), 102213.

[20] Akbulut, A., & Perros, H. G. (2019). Performance analysis of microservice design patterns. IEEE Internet Computing, 23(6), 19-27.

[21] Ianculescu, M., Alexandru, A., Neagu, G., & Pop, F. (2019, November). Microservice-based approach to enforce an IoHT oriented architecture. In 2019 E-Health and Bioengineering Conference (EHB) (pp. 1-4). IEEE.

[22] Esposito, C., Castiglione, A., Tudorica, C. A., & Pop, F. (2017). Security and privacy for cloud-based data management in the health network service chain: a microservice approach. IEEE Communications Magazine, 55(9), 102-108.

[23] Dhama, H. (1995). Quantitative models of cohesion and coupling in software. Journal of Systems and Software, 29(1), 65-74.

[24] Jaramillo, D., Nguyen, D. V., & Smart, R. (2016, March). Leveraging microservices architecture by using Docker technology. In SoutheastCon 2016 (pp. 1-5). IEEE.

[25] Lin, J., Lin, L. C., & Huang, S. (2016, May). Migrating web applications to clouds with microservice architectures. In 2016 International conference on applied system innovation (ICASI) (pp. 1-4). IEEE.

[26] Guo, D., Wang, W., Zeng, G., & Wei, Z. (2016, March). Microservices architecture based cloudware deployment platform for service computing. In 2016 IEEE Symposium on Service-Oriented System Engineering (SOSE) (pp. 358-363). IEEE.

[27] O’Connor, R., Elger, P., & Clarke, P. M. (2016, May). Exploring the impact of situational context—A case study of a software development process for a microservices architecture. In 2016 IEEE/ACM International Conference on Software and System Processes (ICSSP) (pp. 6-10). IEEE.








معماری_نرم_افزار_بهشتیمعماری میکروسرویسمیکروسرویس
شاید از این پست‌ها خوشتان بیاید