امروزه با توجه به نیاز روبه‌رشدی که در اپلیکیشن‌های بزرگ سازمان‌ها به‌وجودآمده است، مفهومی تحت عنوان میکروسرویس هم در صنعت توسعه نرم‌افزار رواج یافته ،چراکه توسعه‌دهندگان برای توسعه سیستم‌های بزرگ تجاری چاره‌ای به‌جز بکارگیری از معماری میکروسرویس را ندارند. معماری میکروسرویس به یک سبک معماری برای توسعه اپلیکیشن‌ها اطلاق می‌شود که بر روی انواع سرور مجازی و سرور ابری قابل پیاده‌سازی می‌باشد. درواقع معماری میکروسرویس(Microservices Architecture)رویکردی در زمینه توسعه برنامه‌های کاربردی است که در آن یک برنامه کاربردی بزرگ به مؤلفه‌ها یا سرویس‌های ماژولار شکسته می‌شود، به‌طوری‌که هر ماژول مسئول اجرای یک وظیفه است، رابط کاربری ساده‌ای دارد و از طریق واسط های برنامه‌نویسی کاربردی(API) با سرویس‌های دیگر ارتباط برقرار میکند. مارتین فاولر، توسعه‌دهنده‌ی مشهور نرم‌افزار، اولین فردی بود که فلسفه شکستن برنامه‌های بزرگ به سرویس‌ها و ماژول های کوچک و گذر از معماری سرویس گرا(SOA)به معماری میکروسرویس ها را مطرح کرد. این روزها مهاجرت به سبک و سیاق میکروسرویس‌ها امری حساس و خطیر تلقی می‌شود. بسیاری از شرکت‌ها و سازمان‌های عظیم مشغول ریفکتورینگ سیستم‌های سمت سرور خود هستند تا با آسانی های پارادایم جدید میکرو سرویس‌ها خود را تطبیق دهند. درحالی که سازمان‌هایی هم هستند که از همان ابتدا توسعه نرم‌افزاری خود را مطابق با معماری میکروسرویس ها بنا نهادند.
اصطلاح میکرو سرویس به‌طور گسترده از مارچ ۲۰۱۲ مطرح شد و به مجموعه‌ای از سرویس‌های نسبتاً کوچک، پایدار، مجرد و خودمختار اشاره داشت که به‌طور مستقل با یک هدف مشخص و از پیش تعیین‌شده استقرار می‌یابند،امروزه میکرو سرویس‌ها یکی از موضوعات جذاب در دنیای نرم‌افزار و معماری محسوب میشوند و در دنیای تجاری نیز شرکت‌های مطرحی از جملهSound Cloud،Ebay،Amazonو... پیشگام پیاده‌سازی و استقرار آن بوده‌اند.معماری میکروسرویس یک رویکرد مهندسی مبتنی بر شکست یک نرم‌افزار به ماژول های تک_ کاربردی است که مستقلاً تولید و مستقر میشوند و با واسطه‌های خوش تعریف با دیگر سرویس‌ها ارتباط دارند. این سرویس‌ها توسط تیم‌های کوچکی تولید و پشتیبانی میشوند که از تمام چرخه حیات سرویس پشتیبانی میکند.بهترین راه استقرار برنامه‌های مبتنی بر میکروسرویسContainerها می‌باشند. کانتینرها که بر بسترDocker قرار می‌گیرند به توسعه‌دهندگان وتیم های Devops این اجازه را می‌دهند تا تمام بخش‌های مورد نیاز مانند کتابخانه‌ها و دیگر وابستگی‌ها را بسته‌بندی کرده و به‌عنوان یک پکیج مستقل روی سیستم‌های دیگر استفاده کند.
در ابتدا لازم است با برخی تعاریف و اصطلاحات کلیدی در رابطه با مقاله آشنا شویم.
_ معماری نرم‌افزار : به فرایند تعریف یک راهکار ساختاری که تمامی نیازمندی‌های عملیاتی و فنی نرم‌افزار را برطرف می‌سازد ، اطلاق می شود که به بهبود ویژگی‌های کیفی نرم‌افزار ازجمله امنیت و عملکرد می‌پردازد . درواقع معماری نرم‌افزار توصیفی از زیرسیستم‌ها و مؤلفه‌های یک سیستم نرم‌افزاری و ارتباطات بین آن‌هاست.
_ سبک معماری : توصیفی از انواع مؤلفه‌ها و توپولوژی آن‌هاست. همچنین به تشریح الگوی داده و کنترل تعامل بین مؤلفه‌ها می‌پردازد و توصیفی غیررسمی از مزایا و معایب استفاده از یک سبک بخصوص در معماری است.
_ میکروسرویس : میکروسرویس راهکاری برای تقسیم یک برنامه کاربردی به بخش‌ها یا سرویس‌های کوچک، سبک، مستقل از یکدیگر و قابل مدیریت است. به بیان دقیق‌تر، میکروسرویس یک معماری توسعه نرم‌افزار توزیع‌شده (Distributed) است. برای درک بهتر مفهوم میکروسرویس به شکل زیر دقت کنید.
این سرویس‌ها تنها برای مدیریت یک وظیفه خاص طراحی شده‌اند ؛
به‌عنوان مثال یک سرویس وظیفه مدیریت کاربران را برعهده دارد درحالی‌که سرویس دیگر برای جستجو در سایت طراحی‌شده است و با توجه به اینکه میکرو سرویس‌ها مجزا و مستقل از یکدیگر هستند ، امکان نوشتن آن‌ها به زبان‌های برنامه‌نویسی مختلف وجود دارد و در اصطلاح معروف Language _agnostic هستند و می‌توانند توسط تیم‌های گوناگون با سبک و سیاق خاص خودشان مورد استفاده قرار گیرند. همچنین، برای ذخیره‌سازی داده‌های مرتبط با آن‌ها، امکان استفاده از سیستم‌های مدیریت بانک‌های اطلاعاتی مختلف وجود دارد.
به بیان دقیق‌تر برای برخی از سرویس‌ها امکان ذخیره‌سازی سنتی داده‌ها در پایگاه داده‌ای مثل MYSQL وجود دارد و در شرایط دیگری که ساختار غیر قابل‌پیش‌بینی از داده‌ها داریم، امکان استفاده از بانک‌های اطلاعاتیNOSQL وجود دارد.و محاوره‌هایی از نوع پروتکل HTTP و یکسری واسطه‌های کاربردی مبتنی بر الگوی طراحیRestful مسئولیت برقراری ارتباط را برعهده دارند.
_ سبک معماری میکروسرویس : مارتین فاولر معتقد است سبک معماری میکروسرویس رویکردی برای توسعه یک نرم‌افزار متشکل از تعدادی سرویس کوچک و مستقل است که هر سرویس به اتکاء منابع و زیرساخت خودش اجرا شده و از طریق پروتکل‌های سبک مبتنی بر HTTP با دیگران ارتباط دارد. این سرویس‌ها براساس قابلیت‌های کسب‌وکار طراحی و ساخته میشوند و بر بسترهای فناوری با زبان‌های برنامه‌نویسی مختلفی قابل استقرار هستند. این سرویس‌ها حداقل نیاز به مدیریت متمرکز را دارند و هر سرویس پایگاه داده مخصوص به خود را مدیریت میکند.
_ معماری میکروسرویس : به‌طورکلی می‌توان گفت که معماری میکروسرویس سبک خاصی از معماری نرم‌افزار و مشتق شده از معماری سرویس گرا است که هدف آن خودمختاری بالای سرویس‌ها از نظر منطق کارکردی_ داده‌ای و نیز پلتفرم و پیاده‌سازی و اجرا است. این سبک معماری علاوه‌بر معماری سرویس گرا از مفاهیم معماری رخداد محور و سیستم‌های توزیع شده نیز بهره برده است.
معماری میکروسرویس (Microservices Architecture)دربرابر معماری یکپارچه(Monolithic) : منظور از یکپارچگی برنامه‌ای نرم‌افزاری تشکیل شده از ماژول هایی که نمی‌توانند به‌طور مجزا و مستقل اجرا شوند. این عدم توانایی، بکارگیری معماری یکپارچه در محیط‌های توزیع شده بدون وجود چارچوب با مشکل روبرو میکند.
۱ ) حجم زیاد کد برنامه، بهره‌وری را کاهش میدهد و ازآن‌جایی‌که در برنامه‌های مبتنی بر یکپارچگی اعضای تیم از کارکردن به‌صورت مستقل منع میشوند و تمامی تیم می‌بایست امر توسعه و استقرار مجدد را به‌صورت هماهنگ با هم انجام دهند ،همین مسئله نیز باعث افت سرعت خواهد شد.
۲) فهم و تغییر برنامه سخت خواهد شد. و زمانی‌که برنامه بزرگتر می‌شود ،افزودن توسعه‌دهندگان جدید و جابجایی اعضای تیم مشکل خواهد بود.
۳) تغییر پشته فناوری برنامه در معماری یکپارچه به‌شدت مشکل و تقریباً غیرممکن است. چراکه تمام مؤلفه‌های وابسته به برنامه با همان تکنولوژی که از ابتدای برنامه بر مبنای آن شروع شده اند، هماهنگ شده و تقریباً هیچ راهی برای تغییر در چارچوب برنامه وجود ندارد. لذا انطباق برنامه با یک فناوری جدید بسیار سخت خواهد بود.
۴) توسعه مداوم مشکل خواهد داشت. برنامه‌های یکپارچه مانعی برای بروزرسانی‌های متنوع و پی‌درپی خواهند بود. بدین صورت که اگر بخواهیم چند مؤلفه کوچک را بروزرسانی کنیم باید کل برنامه را به‌صورت یکجا مجدداً استقرار دهیم.
۵) مقیاس پذیری برنامه با سختی روبرو خواهد شد، چراکه برنامه یکپارچه تنها در یک بعد مقیاس داده می‌شود. اگرچه می‌توانیم حجم تبادلات میان برنامه را از طریق اجرای کپی‌های متعدد افزایش دهیم اما از طرف دیگر این نوع معماری نمی‌تواند توسط افزایش حجم داده‌ها مقیاس پذیر باشد. و این بدین دلیل است که هر نمونه از کپی‌های برنامه به تمام داده‌ها دسترسی دارد و همین مسئله سبب افت تأثیرگذاری عملیات ذخیره‌سازی می‌شود.
ازسویی‌دیگر افزایش مصرف حافظه و بدنبالش افزایش ترافیک ورودی و خروجی برنامه را به‌همراه خواهد داشت بنابراین در معماری یکپارچه مقیاس پذیری مؤلفه‌ها به‌صورت مجزا غیرممکن خواهد بود. بطور کلی با توجه به مشکلاتی که برای معماری یکپارچه بیان شد و اینکه در سیستم‌های یکپارچه مجموعه مؤلفه‌ها، سرویس‌ها، داده‌ها چنان درهم آمیخته است که نمی‌توان بلوک‌های سازنده این سیستم‌ها را مستقلاً از هم جدا کرده و یا تغییر داد ولی در معماری میکروسرویس هدف این است که یک سیستم به مجموعه‌ای از ماژول (سرویس) کاملاً مستقل(خودمختار ) تقسیم می‌شود که هر سرویس همه محاسبات، داده‌ها و قوانین مورد نیاز را در خود داشته باشد و برای اجرا به سایر سرویس‌ها نیاز نداشته باشد یا حداقل وابستگی وجود داشته باشد.
امروزه ماژولار بودن یک مزیت رقابتی بزرگ در دنیای توسعه نرم‌افزار به شمار می‌رود. به‌طوری‌که تجهیزات گران‌قیمت دنیای فناوری اطلاعات مثل سرورها نیز به سمت ماژولار بودن متمایل شده‌اند. میکروسرویس ها با این هدف به دنیای نرم‌افزار وارد شدند تا به توسعه‌دهندگان اجازه دهند برنامه‌های کاربردی خود را بر مبنای مؤلفه‌ها یا سرویس‌هایی که مستقل از یکدیگر هستند و به‌سادگی قابل تغییر، حذف و بروزرسانی هستند توسعه دهند؛ بدون اینکه ساختار کلی برنامه با مشکل روبه‌رو شود. طراحی‌ها و استقرار میکروسرویس‌ها به لطف ابر و کانتینرسازی رشد قابل‌توجهی کرده‌اند. در مجموع باید بگوییم که میکرو سرویس‌ها مزایای قابل‌توجهی در اختیار توسعه‌دهندگان نرم‌افزار قرار داده‌اند که ازجمله آن می‌توان به موارد زیر اشاره کرد:
_ زمان توسعه بدلیل امکان توسعه و استقرار هر میکروسرویس به‌طور مستقل از سایر میکروسرویس‌ها و امکان توسعه هر میکروسرویس توسط یک تیم توسعه، کاهش می‌یابد.
_ میکروسرویس‌ها در فرایند گسترش پذیری سرعت بیشتری ایجاد کرده و فرآیند اشکال زدایی را تسهیل می بخشند.
_ یکی از اهداف اصلی از توسعه سرویس‌ها همانند معماری سرویس گرا امکان استفاده مجدد و ترکیب سرویس‌های موجود برای ایجاد سرویس‌های جدید است.
_ در معماری میکرو سرویس امکان مقیاس پذیری مؤثر به ازای هر سرویس دلخواه میسر است. بنابراین هر بخش از سیستم که بار کاری بیشتری داشته باشد، به تناسب می‌تواند منابع پردازشی بیشتری نیز در اختیار گیرد و نیازی نیست برای همه مؤلفه‌های سیستم مقیاس پذیری یکنواخت انجام شود.
_ در معماری میکروسرویس می‌توان از ابزارها و فناوری‌های متنوعی برای تیم‌های طراحی و پیاده‌سازی استفاده کرد به صورتی که می‌توان در فرآیند تولید یک سیستم، برای میکروسرویس‌های مختلف از ابزارهای مختلفی استفاده کرد، بدون اینکه نگرانی از مشکلات بعدی یکپارچگی وجود داشته باشد.
_ در معماری میکروسرویس بدلیل خودمختاری و عدم وابستگی سرویس‌ها امکان ادامه فعالیت سایر سرویس‌ها در صورت از کار افتادن یک سرویس و در صورت نیاز جایگزینی سرویس ازکارافتاده با نمونه مشابه یا پشتیبان وجود دارد، همچنین می‌توان یک سرویس را که عملکردش مناسب نبوده را با نمونه بهتر جایگزین نمود یا یک سرویس را به‌تنهایی به یک محیط دیگر منتقل کرد.
در شرایطی که میکرو سرویس‌ها مزایای درخشانی در اختیار ما قرار می‌دهند اما معایبی نیز دارند که عبارتنداز:
_ فرایند آزمایش آن‌ها پیچیده و نیز فرآیند مدیریت آن‌ها به زمان بیشتری نیاز دارد.
_ با توجه به اینکه ارتباط سرویس‌ها با یکدیگر از طریق API است، تعدادrequestها نسبت‌به یک معماریmonolithic به‌مراتب بیشتر خواهد بود.
_ ازآن‌جاکه هر سرویس مسئول انجام task خاصی است، در اپلیکیشن‌های بسیار بزرگ تعداد سرویس‌های بیشماری خواهیم داشت و ازهمین‌رو برقراری ارتباط مابین این سرویس‌ها و از همه مهم‌تر مانیتور کردن آن‌ها کاری بسیار دشوار خواهد بود.
_ با توجه به اینکه ممکن است از چندین زبان برنامه‌نویسی و تکنولوژی مختلف در چنین اپلیکیشن هایی استفاده شود، هزینه‌ی نگهداری چنین سیستم‌هایی گاهی اوقات زیاد می شود.
_ ازآن‌جایی‌که برطبق ماهیت مستقل هر ماژول، سرویس‌ها باید به‌طور کامل مستندسازی شوند درنتیجه مستندسازی چنین اپلیکیشن‌هایی مشکل‌تر است.
_ با توجه به اینکه سرویس‌ها برای برطرف کردن نیازهای خود دیگر سرویس‌ها را فراخوانی می‌کنند، رصد کردن آن‌ها و بالطبع فرآیند دیباگینگ بسیار دشوار خواهد شد .
_ اپلیکیشن‌هایی که با استفاده از معماری میکرو سرویس طراحی‌شده اند را به‌سختی می‌توان به‌صورت دستی Deploy کرد و در چنین شرایطی نیاز به ابزارهای اتوماسیون پیشرفته خواهد بود.
_ امروزه اکثر اپلیکیشن‌ها نیاز دارند تا در لحظه چندین رکورد را در دیتابیس حذف یا بروزرسانی کنند. در چنین مواقعی باتوجه به اینکه در معماریmonolithic صرفاً یک دیتابیس وجود دارد، این کار به‌سادگی صورت خواهد گرفت اما در میکرو سرویس‌ها چندین حذف یا بروزرسانی ها چالشهای خواهند داشت چراکه ممکن است رکوردی در دیتابیس یکی از سرویس‌ها در یک سرور خاص به‌همراه رکورد دیگری در سرویس دیگری روی سرور دیگری بخواهند با یکدیگر سینک شوند.
_ نسخه بندی میکرو سرویس‌ها باید به شکل مجزا از یکدیگر انجام شود درنتیجه به راهکار نیاز داریم تا مشخص کنیم کدام نسخه سرویس با کدام نسخه سرویس دیگر باید ارتباط برقرار کند و مستقر شود.
_ هر سرویس لاگ گیری اختصاصی خود را داراست و ازهمین‌رو هیچ سیستم مانیتورینگ مرکزی برای بررسی لاگ ها وجود ندارد و در چنین شرایطی نیاز به یک سیستم مدیریت لاگ مرکزی وجود خواهد داشت.
بنابراین با توجه به مطالب ذکرشده می‌توان چالشهای پیاده‌سازی معماری میکرو سرویس را در سه دسته چالشهای معماری، چالشهای سازمانی و چالشهای فناوری و ابزار طبقه‌بندی نمود.
_ بدلیل اینکه هر میکرو سرویس خودمختاری بالایی دارد، حجم زیادی از دوباره کاری در برنامه‌نویسی هر سرویس برای اعمال مکانیزمهای کنترلی_ امنیتی_ مشترک باید انجام شود.
_ پیاده‌سازی معماری‌های توزیع‌شده نیاز به ابزارها و متدهای پیچیده‌تری برای پیاده‌سازی و نگهداشت دارد.
_ مانیتورینگ ، مدیریت نسخه‌ها، تضمین امنیت و کنترل میکرو سرویس‌ها به‌مراتب سخت‌تر از سایر معماری‌ها و سیستم‌های متمرکز یا لایه‌ای است.
_ انتخاب سبک مناسب معماری بنابر نیاز هر سازمان یکی از چالشهای قدیمی است. هر صورت مسئله نیاز به راهکار مناسب خود دارد و قرار نیست هر سیستم کوچک یا بزرگ مبتنی بر میکرو سرویس باشد.انتخاب بین معماری‌ها-راهکارهای مختلف و نحوه یکپارچگی بین آن‌ها ازجمله دغدغه‌های مدیران و تصمیم‌گیران است.
_ پیاده‌سازی معماری میکرو سرویس نیازمند نیروی انسانی بسیار ماهر و توانمند است که تأمین آن برای هر سازمانی ممکن نیست.
_ ساختار سازمانی بیشتر واحدهای فناوری اطلاعات و تیم‌های توسعه نرم‌افزار مبتنی بر تقسیم افقی فناوری‌ها-ابزار ها (UI_Application_Database )شکل‌گرفته است و تغییر این ساختار به تیم‌های مبتنی برDevops با یک دامنه محدود کسب‌وکار سخت و زمان‌بر است.
_ معماری میکرو سرویس مجموعه جدیدی از ابزار و فناوری‌ها را برای پشتیبانی از نیازمندی‌های خود معرفی کرده‌است که خود باعث افزایش پیچیدگی و افزایش زمان و هزینه تولید سیستم می‌شود.
_ابزارهای جدید به‌سرعت ارائه میشوند و توسط برنامه نویسان در پروژه‌های واقعی مورد استفاده قرار می‌گیرند درحالی‌که مسائل مهمی مانند امنیت و پایداری این ابزارها به‌صورت کامل ارزیابی نشده است .
_تنوع بیش‌ازحد ابزارها و فناوری‌های جدید اگرچه یک مزیت است اما از نگاه دیگر تهدیدی برای تیم‌های برنامه‌نویسی است که تا مهارت کافی برای استفاده از یک ابزار را به دست می‌آورند،، ابزارها و فناوری‌های جدیدی ظهور کرده و فرصت مسلط شدن کافی روی یک ابزار را از دست می‌دهند.
اگر بخواهیم به بررسی دلایل مهاجرت به معماری میکرو سرویس بپردازیم با مسائلی چون قابلیت نگهداری بالا، مقیاس پذیری، مهاجرت سازمان‌های عظیم به این سبک معماری، تحمل خطا، آزمایش آسان فناوری و مسئولیت های نرم‌افزاری مجزا روبرو می‌شویم و با بررسی بیشتر متوجه خواهیم شد که علت اصلی مهاجرت به میکرو سرویس‌ها مزیت بهبود قابلیت نگهداری است. وقتی پیچیدگی سیستم پایین باشد درنتیجه قابلیت نگهداری هم بهبود پیدا میکند.
مورد بعدی افزایش عملکرد سیستم است چراکه طبیعت بیشتر سیستم‌های نوظهور مبتنی بر ابر می‌باشد و بدین‌جهت مقیاس پذیری هم افزایش پیدا میکند. همچنین سیستم‌های مبتنی بر میکروسرویس‌ها در اجرای بلندمدت به نسبت‌به سیستم‌های یکنواخت هزینه کمتری خواهند داشت. اما در کوتاه‌مدت نتیجه برعکس خواهد بود.
معماری سرویس گرا رهیافتی برای ساخت سیستم‌های توزیع شده‌است که کارکردهای نرم‌افزاری را در قالب سرویس ارائه میکند. این سرویس‌ها هم توسط دیگر نرم‌افزارها قابل فراخوانی هستند و هم برای ساخت سرویس‌های جدید مورداستفاده قرار می‌گیرند، این رهیافت برای یکپارچه‌سازی فناوری در محیطی که انواع مختلفی از سکوهای نرم‌افزاری و سخت‌افزاری وجود دارد ایده‌آل است.
معماری سرویس گرا در یک دهه‌ی گذشته، مورد توجه تیم‌های نرم‌افزاری قرار داشته است، اما انعطاف‌پذیری خیلی زیادی ندارد. درحالی‌که میکرو سرویس نسبت‌به معماری سرویس گرا انعطاف‌پذیرتر است، زیرا به‌سادگی می‌توان یک سرویس یا ماژول را از پروژه‌ای برداشت و بدون اعمال تغییرات خاصی آن را به پروژه‌ی دیگری انتقال داد. همچنین معماری سرویس گرا خود در معماری monolithic پیاده‌سازی می‌شود. به بیان دقیق‌تر در معماری سرویس گرا، مؤلفه‌ها یا ماژول هایی داریم که سرویس‌هایی در اختیار مؤلفه‌هایی دیگر قرار می‌دهند. این مؤلفه‌ها می‌تواند منحصر به یک برنامه کاربردی خاص باشند. در معماری میکرو سرویس این مؤلفه‌ها به‌عنوان سرویس‌های مستقلی هستند که امکان استقرار آن‌ها به شکل منفرد وجود دارد ،همچنین اندازه سرویس‌ها یا ماژول های میکرو سرویس‌ها کوچک‌تر از ماژول های سرویس گرا است که مدیریت آن‌ها را ساده‌تر میکند.
معماری سرویس گرا یک معماری نرم‌افزاری است که در آن هر یک از سرویس‌ها از پروتکل‌هایی برای برقراری ارتباط با یکدیگر استفاده می‌کنند .
اگرچه معماری سرویس گرا نزدیک به دو دهه به‌عنوان یک روش استاندارد توسعه به رسمیت شناخته می‌شد، با این حال در تعامل با رایانش ابری با چالش‌هایی روبرو شد ، به‌عنوان مثال قادر به پشتیبانی از مقیاس پذیری نبوده و پاسخگویی دیرهنگام نسبت‌به تغییرات دارد که روند توسعه‌ی برنامه را محدود میکند.بیشتر توسعه‌دهندگان بر این باورند که میکرو سرویس‌ها مکانیزم دقیق‌تری نسبت‌به معماری سرویس گرا ارائه می‌دهند. همچنین آن‌ها معتقدند که معماری میکرو سرویس تکامل طبیعی معماری سرویس گرا است که برای تطابق با رایانش ابری و پاسخگویی به تقاضاهای فزاینده‌ی چرخه‌های توسعه نرم‌افزار پدید آمده‌است.
معماری میکرو سرویس ها از مؤلفه‌ها و سرویس‌های مجزایی تشکیل شده که نیازمند کانال‌های ارتباطی برای برقراری ارتباط و تبادل داده‌ها هستند. به‌طورکلی، برنامه‌های مبتنی بر معماری میکرو سرویس ها یکسری ویژگی‌های مشترک دارند که عبارتند از :
_ منحصربه‌فرد هستند : به‌گونه‌ای که یک سرویس برای انجام یک کار خاص طراحی و نصب می‌شود.
_ غیرمتمرکز هستند : در حالت ایده‌آل، سرویس‌ها وابستگی های کمی دارند، البته برای انجام برخی فرآیندها و به‌ویژه اتصال به اینترنت به وابستگی‌های مختلفی نیاز دارند .
_ ارتجاعی هستند : بزرگترین ویژگی معماری میکرو سرویس آستانه تحمل خطای آن است. به بیان دقیق‌تر، اگر یک سرویس با خرابی روبرو شود، برنامه هنوز هم قادر به اجرا است.
_ توانایی تفکیک داده ها : هر سرویس به پایگاه داده یا فضای ذخیره‌سازی مخصوص به خود دسترسی دارد.
_ از واسط های برنامه‌نویسی کاربردی استفاده میکند : یک معماری میکرو سرویس به‌شدت به واسط های برنامه‌نویسی کاربردی وAPI Gatewayها برای تسهیل ارتباطات متکی است.
در معماری میکرو سرویس مهم‌ترین مسئله نحوه‌ی استخراج و دانه بندی سرویس ها است، به‌گونه‌ای که سرویس‌ها کاملاً خودمختار بوده و حداقل نیاز به مدیریت مرکزی در سیستم وجود داشته باشد. برای استخراج سرویس و انتخاب دامنه‌ها در معماری میکرو سرویس معمولا از چندین روش و تکنیک استفاده می‌شود که معروف‌ترین آن‌ها طراحی مبتنی بر دامنه (Domain Driven Design) است، به‌گونه‌ای که دامنه متشکل از چندین زیر دامنه است و هر کدام از این زیر دامنه‌ها معادل یکی از بخش‌های آن کسب‌وکار است .
زیر دامنه‌ها می‌توانند به‌صورت زیردسته بندی شوند:
_ هسته : وجه تمایز کسب‌وکار از دیگر کسب‌وکارها به شمار می‌رود که به نوعی باارزش‌ترین بخش آن نرم‌افزار است .
_ پشتیبان‌ها : بخش‌هایی که برای سرویس‌دهی هسته مورد نیاز هستند، اما بخش مختص به کسب‌وکار شما نیستند. این بخش‌ها می‌توانند به‌صورت داخلی پیاده‌سازی یا برون سپاری شوند.
_ بخش‌های عمومی : این بخش‌ها مخصوص کسب‌وکار نیستند و به‌صورت ایده‌آل توسط نرم‌افزارها یا سرویس‌های آماده پیاده‌سازی می‌شود .
به‌طورکلی طراحی مبتنی بر دامنه(DDD) پیچیدگی‌های قواعد و منطق کسب‌وکار را درون تعدادی مدل پنهان میکند و هدف اصلی آن مدیریت پیچیدگی‌ها است که یکی از پیچیدگی‌ها نحوه پیاده‌سازی دامنه برنامه است که به روشی باید برنامه را توضیح دهیم که برای نیازهای آینده قابل توسعه باشد مدل‌های مختلفی همانند Rich Domain modelوActive Record برای پیاده‌سازی دامنه وجود دارد.
تیمAzureCATدر پایگاه معماریAzure تعداد۹ الگو را به‌طور خاص به‌منظور طراحی میکرو سرویس‌ها منتشر کرده‌اند. علت اصلی مستندسازی این الگوها، افزایش میل و رغبت به سمت این سبک معماری در صنعت بوده‌است. هدف اصلی معماری میکرو سرویس ها افزایش سرعت انتشار نرم‌افزار عنوان شده‌است و این سرعت را با تجزیه سازی یک برنامه به سرویس‌های کوچک خودمختار انجام می دهد که می‌توانند به‌تنهایی و بدون هیچ‌گونه وابستگی استقرار یابند. یک معماری میکرو سرویس همانند بسیاری نوآوری‌های دیگر چالش‌هایی را با خود همراه دارد که الگوهای نه‌گانه سبب کاهش این چالش‌ها می‌شود.
این الگوها عبارتند از:
ا(1) Gateway Aggregation : درخواست‌های ارسالی به سوی میکرو سرویس‌های چندگانه مستقل را درون یک درخواست واحد تجمیع میکند که همین امر باعث کاهش تبادل بین مصرف‌کننده و سرویس‌های مربوطه می‌شود.
ا(2)Gateway Routing : درخواست مسیرها به میکرو سرویس‌های مختلف از طریق یک نقطه‌ی انتهایی منفرد انجام می‌شود. به‌همین جهت مصرف‌کننده نیاز ندارد تا تعداد زیادی از نقاط انتهایی پایانی را مدیریت کند.
ا(3)Anti_Corruption layer : یک جبهه بین برنامه جدید و برنامه موروثی ایجاد میکند تا مطمئن شود طراحی یک برنامه جدید محدود به وابستگی‌هایش به سیستم‌های موروثی نیست.
ا(4)Bulkhead : منابع حیاتی سیستم مانند مخزن اتصالات، حافظه، واحد پردازش مرکزی را برای هر سرویس یا بار کاری به‌صورت جدا از هم ایزوله میکند. با استفاده از این الگو، یک‌بار کاری تمامی منابع سیستم را به‌تنهایی مصرف نمی‌کند تا دیگران دچار قحطی و گرسنگی در دسترسی به منابع شوند و با پیشگیری از خطاهای دنباله‌داری که توسط یک سرویس رخ میدهد، باعث انعطاف‌پذیری سیستم می‌شود.
ا(5)Backends for frontends : سرویس‌های سمت سرور مجزا برای انواع مختلف کلاینت می‌سازد مانند دستگاه و موبایل. دراین‌صورت یک سرویس سمت سرور منفرد نیاز ندارد تا تمامی نیازمندی‌های پیچیده انواع مختلف کلاینت را پوشش دهد. این الگو همچنین با جداسازی دغدغه‌های اختصاصی کلاینت باعث می‌شود هر میکرو سرویس را به‌طور ساده و به‌دور از پیچیدگی نگهداری کرد.
ا(6)Gateway Offloading : میکرو سرویس‌ها را قادر می‌سازد تا عملکرد اشتراکی سرویس راOffload کنند، مانند استفاده از گواهینامه امنیتیSSL به جهت ارائه به دروازه رابط برنامه‌نویسیAPI Gateway
ا(7)Strangler : از مهاجرت افزایشی به‌وسیله‌ی جداسازی قسمت‌های خاص یک خدمت به‌همراه سرویس‌های جدید پشتیبانی میکند.
ا(8)Sidecar : استقرار مؤلفه‌های کمکی یک برنامه را به‌عنوان کانتینرها یا پردازش‌های جداگانه به‌منظور ایزوله سازی و کپسوله کردن را برعهده دارد.
ا(9) Ambassador : به‌منظورOffload وظایفی مانند نظارت، مسیریابی و امنیت مانند TLS(امنیت لایه انتقال) استفاده می‌شود.
به‌تازگی الگوی جدیدی هم تحت عنوانDatabase_Is_the service patternارائه‌شده است که در آن سیستم مدیریت پایگاه داده غیر رابطهای درون یک خوشه به‌همراه منطق کاری ارائه‌شده است.
زبان برنامه‌نویسیJolie زبانی است که به‌صورت کاملاًNative از این نوع معماری پشتیبانی میکند. در این زبان هر برنامه یک میکرو سرویس است که تشریح و توصیف آن توسط یک رفتار خاص و یک سری اطلاعات استقراریافته ساخته و ارائه می‌شود که در تلاشند تا چگونگی برقراری ارتباطشان را با دیگر میکرو سرویس‌ها ممکن سازند. باید توجه داشت که مفهوم توزیع جزء جدایی‌ناپذیر برنامه می‌باشد و ازآن‌جایی‌که هر برنامه قادر است ویژگی‌ها و عملکردش را در قالب یک URL بخصوص داشته باشد که این آدرس خاص می‌تواند توسط دیگر میکرو سرویس‌ها فراخوانی شود. مقیاس پذیری غیر یکنواخت هم به‌خوبی قابل‌مشاهده است. به‌هرحال میکرو سرویس‌هایJolie به‌آسانی قابل پیاده‌سازی و استقرار درDocker هستند همچنین Jolie مکانیزمهای پیشرفته‌ای را در ارتباط با آگاه‌سازی خطاهایی که فی‌مابین میکرو سرویس ها رخ میدهد را ایجاد می کند.
ا API Gateway :
در مفهومAPI Gateway یک واسط کاربری است که میان کلاینت و سرویس قرار می‌گیرد و سطح انتزاعی را بین آن‌ها ایجاد میکند و با وجود آن دیگر نیازی نیست که کلاینت برای دریافت داده‌های مورد نیاز با چندین سرویس تعامل کند. بطورکلی با اینکه هر سرویس با حداکثر خودمختاری مسئول انجام یک کارکرد مشخص در دامنه سیستم است اما مدیریت کل سیستم و انجام اموری مثل احراز هویت، تقسیم بار، مجوزدهی، لاگ گیری، مانیتورینگ و غیره نیاز به مدیریت و ابزار متمرکز غیر از سرویس ها دارد که می‌تواند توسطAPI Gateway پیاده‌سازی شود.
درصورتی‌که این الگو استفاده نشود کلیه موارد مدیریتی ذکر شده به‌صورت کاملاً توزیع شده توسط سرویس‌ها مدیریت خواهد شد.
بزرگترین مزیت استفاده ازAPI Gateway ، از بین بردن معایب روش دسترسی مستقیم است. عدم وابستگی به معماری داخلی سیستم ما باعث می‌شود کارRefactoringساده‌تر قابل اجرا باشد و دیگر برای ترکیب یا تجزیه سرویس‌های مختلف دغدغه‌های قبل را نداشته باشیم، اما بزرگترین ایراد این روش اضافه شدن یک ماژول بزرگ به سیستم است که باید همیشه آنلاین باشد و درصورتی‌که عملکرد درستی ارائه نکند کل سیستم با مشکل مواجه خواهد شد . با توجه به اینکه تعامل با هر کدام از میکرو سرویس‌ها باید درAPI Gateway پیاده‌سازی شود و به ازای هر کلاینت هم نیاز داریم که پیاده‌سازی اختصاصی داشته باشیم، این احتمال وجود دارد که همین API Gateway به سدی برای تیم توسعه تبدیل شود.
یک بسته نرم‌افزاری منفرد و اجرایی است که شامل تمام وابستگی‌های مورد نیاز یک برنامه کاربردی است. کانتینرها با ارائه یک مکانیزم ایزوله و منفرد اجازه استقرار انواع مختلفی از کانتینرها در یک محیط تولیدی را می‌دهند. در معماری میکرو سرویس، هر سرویس به شکل جداگانه از سرویس‌های دیگر در محیط مستقر می‌شود.
کانتینرها، نرم‌افزار را از محیط اجرا ایزوله می‌کنند و این اطمینان را می‌دهند که برنامه‌های یکنواخت و بی‌نقص در هنگام توسعه و ساختاربندی کار کنند. از خصوصیات کانتینرها می‌توان به مواردی چون استاندارد واحد، سبکبالی، چابکی در ایجاد و استقرار اپلیکیشن‌ها و جداسازی منابع اشاره کرد.
_ سازنده (builder) : فناوری مورد استفاده برای ساخت کانتینر
_ موتور (Engine) : فناوری مورداستفاده برای راه‌اندازی کانتینر
_ تنظیم(Orchestration) : فناوری مورداستفاده برای مدیریت و تنظیمات کانتینر
_ Kubernetes
_ Docker Swarm
_ Amazon ECS
_ Azure service Fabric
_ Cloud Foundry
_ Google Cloud Functions
_ IBM Bluemix OpenWhisk
_ Oracle Application Container
به‌صورت مجازی یک اکوسیستم سخت‌افزاری را ایجاد میکند که سیستم‌عامل روی آن مستقر و یک یا چند برنامه کاربردی را اجرا میکند.ماشین مجازی می‌تواند به‌عنوان جایگزینی برای کانتینرها برای ساخت میکرو سرویس‌ها استفاده شود. در این حالت، هر سرویس می‌تواند از یک ماشین مجازی برای میزبانی یک ویژگی استفاده کند. بااین‌حال، ماشین‌های مجازی ممکن است برای میکروسرویس ها ایده‌آل نباشند، زیرا هر کدام به یک سیستم‌عامل جداگانه نیاز دارند و هزینه‌های سرباری زیادی را به وجود می‌آورند. کانتینرها از نظر صرف منابع بسیار کارآمدتر هستند ،زیرا فقط به کد زیربنایی و وابستگی‌های مربوط برای اجرای سرویس نیاز دارند.آن‌ها محیط‌های اجرایی را جدا کرده و هسته سیستم‌عامل را به اشتراک می‌گذارند ،همچنین خیلی سریع قابلیت اجرا پیدا می‌کنند.
ابزاری متن باز جهت ساده‌سازی در ساخت و اجرای برنامه‌ها با استفاده از کانتینرها می‌باشد و این اجازه را به ما میدهد تا برنامه و تمام کامپوننت های آن را به شکل یک بسته درآورده و در هر ماشینی بدون نیاز به انجام تنظیماتی که ماشین مبدأ داشته آن را اجرا کنیم. مهم‌ترین هدف ایجاد داکر این بود که کاربران به‌راحتی بتوانند با کانتینر ارتباط برقرار کنند یا به نوعی دیگر با آن تعامل داشته باشند باید توجه داشت که کانتینرها قبل‌از پدید آمدن داکر نیز وجود داشتند اما این داکر بود که مفهوم کانتینر را متحول کرد.
از جمله ویژگی‌های داکر می‌توان به مواردی چون قابلیت حمل‌ونقل و بهبود یکپارچه، حجم کم و بروزرسانی بسیار دقیق و صرفه‌جویی در هزینه ،امنیت، مدیریت قدرتمند مصرف منابع اشاره نمود.
ا(۱) Docker Daemon ( مدیر و مجری محفظه‌ها ) : براساس دستورات، تصاویر و کانتینرهای داکر را ایجاد و مدیریت میکند. این سرویس به‌عنوان مرکز کنترل اجرایی داکر عمل می کند.
ا(۲) Docker CLI ( رابطه دستوری مرتبط باDaemon ) : شرایط لازم برای تعامل کاربر با اپلیکیشن های کانتینری را فراهم میکند. با استفاده از یکCLI میزبان داکر را کنترل میکند و دستورات لازم را وارد میکند.
ا(۳) Docker Image ( Imageهای برنامه مربوطه) : تصاویر داکر حاوی سورس کد اپلیکیشن و تمام ابزارها، کتابخانه‌ها و بسته‌های مورد نیاز هستند که همه این‌ها برای اجرا به محیط ایزوله یا همان کانتینر نیاز دارند.
اگر در مقیاس بزرگ تعداد بسیار زیادیDocker و با انواع مختلفی داشته باشیم و بخواهیم آن‌ها را مدیریت کنیم، ابزارهای سازماندهی کانتینرها برای خودکارسازی فرایندها به کمک ما می‌شتابند. ابزارهای مدیریت و سازماندهی کانتینرها که لغت ارکستراسیون کانتینرها نیز برای آن‌ها بکار می‌رود، فرایند مدیریت، مقیاس پذیری، نگهداری و استقرار کانتینرها خودکارسازی میکند. این ابزارها می‌تواند برای زمانبندی اجرا و ساخت کانتینرها، نحوه‌ی اختصاص منابع به آن‌ها، میزان سلامت هر یک از کانتینرها، نحوه مقیاس پذیری آن‌ها و راه‌اندازی دوباره‌ی هر کانتینر، نحوه توزیع بار، کاهش خطای انسانی در مدیریت داکرها، ساده‌سازی عملیات‌های مرتبط با داکرها و بسیاری موارد دیگر بکار روند.
یکی از موارد مهم و پرکاربرد ابزارهای ارکستراسیون کانتینرها Kubernetesمی باشد که در ادامه درباره این ابزار صحبت خواهد شد.
ا Kubernetesیک سیستم ارکستراسیون منبع باز برای خودکار کردن مدیریت، قرار دادن، مقیاس گذاری و مسیریابی کانتینرهایی است که در سال‌های اخیر مورد توجه توسعه‌دهندگان و تیم‌های عملیاتی فناوری اطلاعات قرار گرفته است.کوبرنتیز به پلتفرم استاندارد ارکستراسیون کانتینرها تبدیل شده‌است. تمام ارائه‌دهندگان اصلی ابر از آن پشتیبانی می‌کنند، و این گزینه منطقی برای سازمان‌هایی است که به‌دنبال انتقال برنامه‌های بیشتر به ابر هستند.
کوبرنتیز یک فریمورک مشترک برای اجرای سیستم‌های توزیع‌شده ارائه میدهد تا تیم‌های توسعه زیرساخت‌های ثابت و غیرقابل تغییر از توسعه تا تولید برای هر پروژه داشته باشند. در واقع کوبرنتیز می‌تواند نیازهای مقیاس بندی، در دسترس بودن، خرابی سیستم، الگوهای استقرار و موارد دیگر را مدیریت کند.کوبرنتیز قابلیت‌هایی نظیر خدمات و تعریف فرایند، کشف خدمات و توازن بار، ارکستراسیون ذخیره‌سازی، مدیریت منابع درسطح کانتینر، استقرار و بازگشت خودکار،مدیریت سلامت کانتینر و مدیریت پیکربندی را دارد. در تصویر زیر کانتینرها و ماشین‌های مجازی در یک معماری هیبریدی به‌کارگرفته شدند یک اپلیکیشن که با کانتینر ایزوله شده در یک کلاستر ماشین‌های مجازی در حال استقرار و بروزرسانی است. در چنین معماری نیاز به یک هماهنگ ساز دارید تا مدیریت، استقرار، اسکیل ،شبکه و دسترسی پذیری یک اپلیکیشن کانتینر شده را به‌عهده بگیرد، اینجاست که کوبرنتیز وارد می‌شود و بسیاری از روندها را خودکار کرده و خودکارسازی های مورد نیاز را منظم و به‌ترتیب و در بهینه ترین حالت اجرا میکند.
زمانی‌که کوبرنتیز را مستقر می‌کنید یک Cluster (مجموعه‌ای از چندین گره که در کنار هم قرار می‌گیرند و معمولاً اگر یکی از گره‌ها دچار مشکل شود نرم‌افزار از طریق بقیه گره‌ها همچنان می‌تواند بدون مشکل کار کند) خواهید داشت. کوبرنتیز با استفاده از یک شبکه مشترک برای برقراری ارتباط بین هر سرو، ماشین‌های مجازی یا فیزیکی جداگانه را در یک کلاستر جمع میکند. این مجموعه، یک بستر فیزیکی است که در آن تمام اجزایKubernetes، قابلیت‌ها وWorkload ها پیکربندی شده‌است.
معماری میکرو سرویس در چند حوزه کاربردی مورداستفاده قرار می‌گیرد که دراین‌رابطه محققان تلاش‌هایی برای ادغام مفاهیم میکرو سرویس با برنامه‌های کاربردی در دامنه های مختلف از جمله اینترنت اشیاء و رایانش ابری انجام داده‌اند.
سیستم‌های توزیع شده:
معماری میکرو سرویس مورد پذیرش جامعه محاسبات توزیع‌شده قرار گرفت؛ رایانش ابری و سیستم‌های ذخیره‌سازی توزیع شده از مزایای معماری‌های میکرو سرویس می‌توانند بهره ببرند.
رایانش ابری :
در رابطه با استفاده از میکرو سرویس‌ها برای ارائه خدمات شبکه در مراکز داده ابری تحقیقاتی صورت‌گرفته است. روشBigVM برای کاهش مسئولیت توسعه‌دهندگانSaaS با خودکارسازی توسعه برنامه‌های کاربردیSaaS مبتنی بر میکرو سرویس ارائه‌شده است BigVM می‌تواند کارایی سیستم را با افزودن مؤلفه‌های خاص ازجمله یک موتور ارکستراسیون میکرو سرویس برای هماهنگی میکرو سرویس‌ها و یک موتور گردش کار که به وسیله آن، می‌توان ریزسرویس‌ها را در طول زمان اجرا ،طراحی و به‌صورت پویا سفارشی کرد ؛ افزایش دهد. BigVM بر شناسایی میکرو سرویس هایی تمرکز دارد که در کاربردهای متعدد به‌شدت مورد استفاده مجدد قرار می‌گیرند. مجموعه‌ای از رابطهای مؤلفه استاندارد شده و پروتکل‌های ارتباطی سرویس به‌گونه‌ای پیاده‌سازی شده‌اند که این میکرو سرویس تا می‌توانند به‌طور کامل درBigVM نگهداری شوند. علاوه‌بر این، BigVM یک سلسله‌مراتب میکرو سرویس چندلایه را فعال میکند که در آن میکرو سرویس‌های لایه پایین به‌عنوان جعبه سیاه مشخص میشوند؛ به‌طوری‌که توسعه‌دهندگان SaaSفقط باید با سفارشی‌سازی خودکار میکرو سرویس‌های لایه پایین‌تر، با میکرو سرویس‌های لایه بالاتر سروکار داشته باشند .در نتیجه، توسعه‌دهندگان SaaS می‌توانند از استقرار تعدادی از میکرو سرویس‌ها به‌عنوان مثال میکرو سرویس‌های مبتنی بر منابع سیستم‌عامل خودداری کنند.
سیستم‌های ذخیره‌سازی توزیع شده :
سیستم‌های فایل توزیع شده مانند Azure Data lake store برای ارائه خدمات سیستم فایل، به معماری‌های میکرو سرویس متکی هستند. میکرو سرویس‌های مختلفی برای ارائه عملکردهای مدیریتی برای پشتیبانی از عملیات تجزیه‌وتحلیل داده ها درBig Data استفاده میشوند. میکرو سرویس‌هایAzure Data lake store با ارائه‌دهندگان سیستم‌های ذخیره‌سازی برای انجام عملیات بر روی داده‌های ذخیره‌شده در سیستم فایل ارتباط برقرار می‌کنند.
اینترنت اشیاء:
با توسعه فناوری اینترنت اشیاء، معماری سنتی نمی‌تواند الزامات سیستم‌های ناهمگن، قابل همکاری، سفارشی‌سازی و مقیاس پذیر را برآورده کند. برای مقابله با چالش فوق یک چارچوب باز اینترنت اشیاء را با تجزیه سیستم اینترنت اشیاء به میکرو سرویس‌ها برای انجام انواع مختلف وظایف ارائه میکند. با استفاده از ارتباط پیام محور و مکانیسم رجیستری ،کشف در سرویس اصلی، چارچوب به‌راحتی می‌تواند برنامه‌های شخص ثالث را برای پشتیبانی از قابلیت همکاری و مقیاس پذیری گسترش و تکامل داده و ادغام کند. علاوه‌بر این، سیستم از پلاگین های دستگاه برای محافظت از تفاوت امکانات سخت‌افزاری به‌منظور پشتیبانی از پلتفرم‌های ناهمگن تر استفاده میکند. به‌ویژه، همان‌طور که با یک سری ازریز سرویس‌های یکپارچه شده‌است، این چارچوب مکانیسم قوی برای ترکیب داده‌های ناهمگن از طریق پیش‌پردازش سلسله‌مراتبی داده‌های حسگرهای انبوه ارائه میدهد.
مراقبت‌های پزشکی :
به عنوان نمونه پلتفرمSPIDEP برای استفاده از میکرو سرویس‌ها در سناریوهای پزشکی بیماری‌های عفونی ارائه‌شده است. هدف این پلتفرم، تفسیر تغییرات در علایم حیاتی افراد مسن ساکن در مراکز مسکونی است؛ بنابراین تیم پزشکی را قبل‌از عفونت‌های احتمالی آگاه میکند. این پلتفرم، دارای یک سیستم توصیه کننده برای بهبود پشتیبانی تصمیم در پیش تشخیص بیماری‌های عفونی می‌باشد. معماری این پلتفرم شامل معماری لبه، ارتباط با کاربر و معماری ابر می‌باشد.
معماری لبه :
وظیفه جمع‌آوری، پیش‌پردازش و ارسال داده از حسگرهای بیومتریک مختلف مانند ECG، فشارخون و غیره را برعهده دارد. از داده‌های جمع‌آوری‌شده به‌صورت محلی نسخه پشتیبان تهیه می‌شود .
ارتباط با کاربر:
مکانیسم‌های لازم را برای ارتباط صحیح بین لایه‌ها و زیرلایه‌های مختلف فراهم میکند این ارتباط از طریق پروتکلREST بدست می‌آید بااین‌حال این پروتکل نیاز به استفاده از یک دروازه API دارد.
معماری ابر :
خدماتی را برای کاربران نهایی در قالب میکرو سرویس‌های اصلی و کمکی، با توجه به نیازهای آن‌ها و سطوح نقش‌ها و مجوزهای آن‌ها، فراهم میکند. به‌علاوه داده‌ی ذخیره‌شده در پایگاه‌های داده اختصاصی میکرو سرویس‌ها را برای رساندن مزایایی به کاربران هدف ازجمله بیماران، پرسنل پزشکی و مقامات بهداشتی، مدیریت میکند.
برنامه‌های زندگی هوشمند :
امکان استفاده از معماری میکرو سرویس و محاسبات مه برای فراهم‌سازی امکان استفاده از توابع مرجع صدور گواهی، سیستم مدیریت بلیط راه‌آهن و غیره استفاده می‌شود. از طریق آن، سطوح حمله و تأخیر احراز هویت را به حداقل رسانده و منجر به طرحی سریع و مقیاس پذیری در احراز هویت حجم زیادی از دستگاه‌ها با منابع محدود می‌شود. سپس پروتکل‌های سبک‌وزنی را برای رسیدن به سطح بالایی از امنیت و بارهای محاسباتی کم، ارائه میدهد.ارزیابی‌ها، کارایی و اثربخشی طرح ارائه‌شده در رسیدگی و احراز هویت تعداد زیادی گره را نشان میدهد و درعین‌حال از آن‌ها در برابر تهدیدات مختلف در زندگی هوشمند، محافظت میکند.
«این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است»
«معماری_نرم_افزار_بهشتی»
منابع :
2. Thönes, J., Microservices . IEEE Software,2015.32(1):.116_116.
3. Taibi, D.,V.Lenarduzzi, and C. Pahl,Processes, Motivations and Issues for Migrating to Microservices Architectures: AnEmpirical Investigation. IEEE Cloud Computing, 2017.
4. Mazzara .M., et al.,Towards Microservices and Beyond.2017 at https:/arxiv.org/abs/1610.01778
5. https://martinfowler.com/articles/microservices.html
6. Abbott, Martin L., and Michael T. Fisher. The art of Scalability: Scalable web architecture, Processes, and organizations for The Modern enterprise. pearson Education, 2009.
7. https://www.nginx.com/learn/microservices
8. https://articles.microservices.com/monolithic-vs-microservices-architecture-5c4848858f59
9. Wasson, M., Design patterns for Microservices, in Microsoft, https:/azure.Microsoft.Com/en_us/blog/design_patterns_for_Microservices/2017.
10. Dragoni , N., et al.,Microservices: How to Make your application Scale. arXiv preprint arXiv:1702.07149,2017.
11. Merkel, D., Docker: lightweight Linux Containers for Consistent development and deployment. Linux Journal, 2014. 2014(239): 2.
12. Microservices:The Journey So Far and challenges Ahead, Pooyan Jamshidi, C. Pahl,N. mendonca,J.Lewis, S. Tilkov(2018)
14. https://codezup.com/what-is-domain-driven-design-ddd-pros-cons/
15. https://www.docker.com/resources/what-container/
16. https://avinetworks.com/what-are-microservices-and-containers/
17. https://www.redhat.com/en/topics/containers/what-is-container-orchestration
18. https://www.docker.com/solutions/microservices
19. https://docs.docker.com/get-started/overview/
21. https://containerjournal.com/topics/container-ecosystems/kubernetes-vs-docker-a-primer/
22. https://www.cloudfoundry.org/microservices
23. Guidi, C., et al.,Dynamic error handling in service Oriented applications. Fundamenta Informaticae, 2009. 95(1): P. 73_102.
24. Zheng T, Zhang Y, ZhengX, 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.
25. 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 (INDID)(PP. 1659_1664). IEEE.
26. 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 ananlytics .In Proceedings Of the 2017 ACM International Conference on management of Data (PP.51_63).
27. Sun, L., Li, Y., & memon, R. A .(2017).An open IOT framework based on Microservices architecture. china Communications, 14(2) , 154_162.
28. 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.
29. 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.
30. Baldominos, A., Ogul, Colomo-Palacios, R., Sanz-Moreno, J., & Gómez-pulido, J. M.(2020). Infection Predication Using Physiological and Social data in Social environments. Information Processing & Management, 57(3) , 102213.
