میکروسرویس ها، کانتینرها و ارتباط این دو باهم

کمی تاریخچه

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

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

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

مارتین فاولر، دانشمند نرم‌افزار، نویسنده و سخنران مشهور در جامعه توسعه نرم‌افزار است. او برای تخصص خود در الگوهای طراحی نرم‌افزار و معماری شناخته می‌شود و نوشته های بی‌نظیری در این زمینه دارد. از معروف ترین نوشته های او میتوان به "Refactoring: Improving the Design of Existing Code" و "Patterns of Enterprise Application Architecture" اشاره کرد که خواندن آنها برای هر توسعه دهنده و هر معمار نرم افزاری واجب است. همچنین او عضو پیشرو در توسعه روش های Agile است. مارتین فاولر به عنوان یکی از شخصیت‌های مهم در صنعت توسعه نرم‌افزار است و به پیشرفت توسعه نرم‌افزار در چارچوب کارآمد، کمک زیادی کرده است.

حالا که به صورت خیلی خلاصه به مرور تاریخی ماکروسرویس ها پرداختیم، به سراغ توضیحات تکمیلی و فنی آن می رویم

میکروسرویس چیست؟

میکروسرویس یک سبک معماری برای ساخت نرم‌افزارهای کاملاً مقیاس پذیر و flexible، بر پایه ایده تقسیم یک برنامه بزرگ و مونولیتیک به سرویس‌های کوچک‌تر و مستقل، که با هم با استفاده از API ها در تعامل هستند، معرفی می شود.

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

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

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

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

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

یکپارچه سازی و استقرار مداوم یا CI/CD یک روش توسعه نرم افزار است که هدف آن خودکارسازی ساخت، آزمایش و استقرار برنامه های کاربردی نرم افزار است. هدف CI/CD این است که سازمان‌ها را قادر سازد تا به‌روزرسانی‌ها و ویژگی‌های نرم‌افزار را به دفعات و با کیفیت بالاتر به مشتریان ارائه دهند.
در معماری میکروسرویس، CI/CD اهمیت ویژه ای دارد، زیرا هر میکروسرویس جزء مجزا و مستقلی از برنامه کلی است. با CI/CD، تیم‌ها می‌توانند فرآیند ساخت، آزمایش و استقرار میکروسرویس‌ها را خودکار کرده، خطر خطاها را کاهش داده و سرعت تحویل را افزایش دهند.
در CI/CD، هرگاه تغییری در یک پایگاه کد میکروسرویس ایجاد شود، pipeline به طور خودکار فرآیند build و آزمایش را آغاز می کند. در صورت موفقیت آمیز بودن آزمایشات، میکروسرویس سپس در محیط production مستقر می شود. این به تیم‌ها امکان می‌دهد تا به سرعت و به آسانی تغییرات در میکروسرویس‌ها را تأیید کرده، آن تغییرات را پیاده‌سازی کنند، بازخورد سریع ارائه دهند و کیفیت کلی برنامه را بهبود بخشند.
به طور خلاصه، استفاده از CI/CD در معماری میکروسرویس، سازمان ها را قادر می سازد تا نرم افزار را سریعتر، با کیفیت بالاتر و با ریسک کمتر ارائه دهند. همچنین انعطاف پذیری بیشتری را برای تیم ها فراهم می کند، زیرا می توانند به طور مستقل تغییراتی در میکروسرویس ها ایجاد کنند و آن تغییرات را به طور لحظه ای اعمال کنند.

حال برای درک بهتر کمی به سراغ مقایسه می رویم.

مقایسه با دیگر معماری های معروف

میکروسرویس ها اغلب با سایر سبک های معماری از جمله معماری یکپارچه(monolithic) و معماری سرویس گرا (SOA) مقایسه می شوند.

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

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

حال به سراغ دیگر معماری مهم می رویم.

معماری سرویس گرا (SOA) یکی دیگر از سبک های معماری است که شامل تجزیه یک برنامه یکپارچه به سرویس های کوچکتر و مستقل است. با این حال، سرویس‌های SOA معمولاً بزرگ‌تر و تمرکز کمتری نسبت به میکروسرویس‌ها دارند، و اغلب به‌طور محکمی با هم مرتبط هستند، به این معنی که تغییرات در یک سرویس می‌تواند بر بسیاری دیگر تأثیر بگذارد. میکروسرویس و SOA شباهت‌هایی دارند، مانند استفاده از API برای برقراری ارتباط بین سرویس‌ها و تمرکز بر تجزیه یک برنامه یکپارچه به اجزای کوچک‌تر. با این حال، میکروسرویس‌ها معمولاً کوچک‌تر، متمرکزتر و کمتر از سرویس‌های SOA متصل هستند، که باعث انعطاف‌پذیری بیشتر و اصلاح پذیری آنها می‌شود.هر دوی اینها، رویکردهایی برای ساخت و استقرار سیستم های نرم افزاری هستند، اما تفاوت های کلیدی بین این دو وجود دارد.

• اندازه سرویس: در SOA، سرویس‌ها بزرگ‌تر و جامع‌تر هستند و چندین عملکرد تجاری را انجام می‌دهند. از سوی دیگر، میکروسرویس‌ها کوچک‌تر و متمرکزتر هستند و یک عملکرد تجاری خاص را انجام می‌دهند.
• اتصال: سرویس‌های SOA معمولاً به‌طور محکم با هم مرتبط هستند، به این معنی که تغییرات در یک سرویس می‌تواند بر بسیاری دیگر تأثیر بگذارد. این می‌تواند تغییر یا به‌روزرسانی سرویس‌ها را بدون تأثیر بر کل سیستم دشوار کند. از طرف دیگر، میکروسرویس‌ها به گونه‌ای طراحی شده‌اند که به‌طور آزادانه جفت شوند، به این معنی که تغییرات یک سرویس بر سایر خدمات تأثیری نمی‌گذارد و اصلاح یا به‌روزرسانی سرویس‌ها را آسان‌تر می‌کند.
• توسعه و استقرار: در SOA، توسعه و استقرار معمولاً متمرکزتر و هماهنگ تر است و یک تیم واحد، مسئول نظارت بر کل سیستم است. در میکروسرویس‌ها، توسعه و استقرار غیرمتمرکزتر است و تیم‌های جداگانه مسئول هر سرویس هستند.
• مقیاس‌پذیری: مقیاس‌پذیری سیستم‌های SOA ممکن است دشوار باشد، زیرا تغییرات در یک سرویس می‌تواند بر بسیاری دیگر تأثیر بگذارد. از سوی دیگر، میکروسرویس ها برای مقیاس پذیری طراحی شده اند و هر سرویس می تواند به طور مستقل مقیاس پذیر باشد.
• پشته فنی: سیستم‌های SOA معمولاً از یک پشته فنی مشترک استفاده می‌کنند که همه سرویس‌ها با استفاده از زبان‌ها، ابزارها و فناوری‌های برنامه‌نویسی یکسان توسعه یافته‌اند. از سوی دیگر، میکروسرویس‌ها را می‌توان به زبان‌های برنامه‌نویسی مختلف نوشت و بر روی پلتفرم‌های مختلف اجرا کرد. این مسئله میکروسرویس را برای طیف وسیعی از موارد استفاده مناسب می‌کند.

برای جمع بندی میتوان گفتSOA و میکروسرویس ها نقاط قوت و ضعف خاص خود را دارند و انتخاب بین این دو به نیازهای خاص یک پروژه بستگی دارد. SOA برای پروژه هایی که نیاز به یک رویکرد متمرکز و هماهنگ برای توسعه و استقرار دارند، مناسب است، در حالی که میکروسرویس ها برای پروژه هایی که به انعطاف پذیری، مقیاس پذیری و کنترل غیرمتمرکز نیاز دارند، مناسب هستند. اگر بخواهیم مثال هایی برای کاربرد SOA بزنیم:

• سیستم های مدیریت فرآیند کسب و کار (BPM): سیستم های BPM به سازمان ها کمک می کند تا فرآیندهای تجاری را خودکار و مدیریت کنند. SOA می تواند برای ادغام سیستم های BPM با سایر برنامه های نرم افزاری مانند سیستم های ERP یا CRM استفاده شود تا راه حلی جامع برای مدیریت فرآیند ارائه دهد.
• میان‌افزار یا middleware: میان‌افزار برای ادغام نرم‌افزارها و سیستم‌های مختلف در یک سازمان استفاده می‌شود. SOA می‌تواند برای تعریف رابط‌های بین این سیستم‌ها مورد استفاده قرار گیرد که امکان تبادل یکپارچه داده‌ها و عملکرد را فراهم می‌کند.

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

فقط جدا کردن سرویس ها یا نحوه دیگری از تفکر معماری؟

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

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

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

علاوه بر گستردگی موضوعی که باید در نظر بگیرید، چالش دیگری نیز وجود دارد که همه این عناصر به هم مرتبط هستند. تغییر در یک قسمت از سیستم می‌تواند تأثیر پیش‌بینی‌نشده‌ای بر قسمت دیگر داشته باشد. به عنوان مثال، تغییر اندازه یک تیم پیاده سازی می تواند تأثیر عمیقی بر کاری که تیم پیاده سازی تولید می کند داشته باشد.

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

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

پس چه میتوان کرد؟ همان کاری که دانشمندان در زمان مواجه با یک مشکل می کنند. مدل طراحی می کنیم.

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

• سرویس :‌ پیاده سازی میکروسرویس ها و API های خوب طراحی شده برای یک سیستم میکروسرویس ضروری است. در یک سیستم میکروسرویس، سرویس ها، بلوک‌های ساختمان را تشکیل می‌دهند که کل سیستم از آن ساخته می‌شود. اگر بتوانید طراحی، محدوده و جزئیات سرویس ها را به درستی انجام دهید، می‌توانید رفتارهای پیچیده‌ای را از مجموعه‌ ی ساده ای از سرویس ها دریافت کنید
• راه حل: معماری راه حل از طراحی سرویس های مجزا متمایز است، زیرا به نوعی نمای کلان سیستم ما را نشان می دهد. هنگام طراحی یک میکروسرویس خاص، تصمیمات شما با نیاز به تولید یک خروجی، خروجی خود سرویس، محدود می شود. برعکس، هنگام طراحی یک معماری راه حل، تصمیمات شما با نیاز به هماهنگی همه ورودی ها و خروجی های چند سرویس هماهنگ می شود. این دیدگاه در سطح کلان از سیستم به طراح اجازه می دهد تا سیستم مطلوب تری را ایجاد کند. به عنوان مثال، یک معماری راه حل که ویژگی های توسعه، ایمنی و مسیریابی را فراهم می کند، می تواند پیچیدگی هر سرویس را کاهش دهد.
• فرایندها و ابزار:‌ سیستم میکروسرویس فقط یک محصول جانبی از اجزای سرویس نیست که درخواست ها را در زمان اجرا مدیریت می کنند. رفتار سیستم همچنین نتیجه فرآیندها و ابزارهایی است که در سیستم برای انجام کار استفاده می شود. در سیستم میکروسرویس، این معمولا شامل ابزار و فرآیندهای مربوط به توسعه نرم افزار، استقرار کد، نگهداری و مدیریت محصول می شود. انتخاب فرآیندها و ابزارهای مناسب عامل مهمی در ایجاد رفتار درست و مناسب سیستم میکروسرویس است. به عنوان مثال، اتخاذ فرآیندهای استاندارد مانند DevOps و Agile یا ابزارهایی مانند کانتینرهای Docker می تواند تغییرپذیری سیستم را افزایش دهد.
• سازمان: نحوه کار ما اغلب محصول این است که با چه کسی کار می کنیم و چگونه ارتباط برقرار می کنیم. از دیدگاه میکروسرویس، طراحی سازمانی شامل ساختار، جهت اختیارات، جزئیات و ترکیب تیم ها می شود. بسیاری از شرکت هایی که در معماری میکروسرویس موفق بوده اند به طراحی سازمانی خود به عنوان یک عنصر کلیدی اشاره می کنند.
• فرهنگ:‌ در میان همه حوزه‌های سیستم میکروسرویس، فرهنگ شاید ناملموس‌ترین حوزه باشد، اما میتوان گفت مهم‌ترین آنها نیز هست. ما می‌توانیم فرهنگ را به‌عنوان مجموعه‌ای از ارزش‌ها، باورها یا ایده‌آل‌ها تعریف کنیم که بین همه کارکنان یک سازمان مشترک است. فرهنگ سازمان مهم است زیرا تمام تصمیماتی که افراد درون سیستم می گیرند را شکل می دهد. این دامنه نفوذ زیاد همان چیزی است که آن را به ابزار قدرتمندی در طراحی سیستم شما تبدیل می کند. هر طور که آن را بسنجید، فرهنگ اغلب نشانه ای از تأثیر سایر بخش های سیستم بر همدیگر است. ایده‌آل‌های مشترک، نحوه انجام کار افراد را شکل می دهد. این ماهیت به هم پیوسته سیستم است.

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

حال به سراغ ابزارها می رویم و سعی می کنیم آشنایی کلی و خلاصه واری از آنها بدست بیاوریم.

ابزارها

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

• رجیستری خدمات: رجیستری خدمات یک مخزن مرکزی است که فهرستی از تمامی سرویس های موجود و وضعیت فعلی آنها را نگهداری می کند. نمونه‌هایی از ثبت سرویس ها عبارتند از Netflix Eureka، Consul و Zookeeper
• دروازه API یا API Gateway: یک API Gateway سروری است که به عنوان یک نقطه ورودی برای همه میکروسرویس ها عمل کرده و مسیریابی درخواست، ترکیب و ترجمه پروتکل ها و غیره را مدیریت می کند. معروف ترین نمونه آن که بیشترین کاربرد در صنعت را دارد kong است
• Load Balancer: متعادل کننده بار ابزاری است که درخواست های دریافتی را در چندین نمونه از یک میکروسرویس توزیع می کند و به بهبود قابلیت اطمینان و مقیاس پذیری کمک می کند.
• نظارت و ثبت گزارش: ابزارهای پایش و ثبت گزارش به پیگیری سلامت و عملکرد میکروسرویس ها کمک می کنند. نمونه‌هایی از ابزارهای نظارتی عبارتند از New Relic، Datadog و Prometheus، در حالی که نمونه‌هایی از ابزارهای گزارش‌گیری شامل ELK Stack، Fluentd و Graylog هستند.
• سرور پیکربندی: سرور پیکربندی یک مخزن مرکزی برای داده های پیکربندی(configuration) است که توسط میکروسرویس ها استفاده می شود. نمونه‌هایی از سرورهای پیکربندی عبارتند از Spring Cloud Config، HashiCorp Vault و ZooKeeper.
• هماهنگ‌سازی کانتینر: ابزارهای هماهنگ‌سازی کانتینر به مدیریت استقرار، مقیاس‌بندی و مدیریت کانتینرها کمک می‌کنند، که جزء کلیدی میکروسرویس‌ها هستند. نمونه هایی از ابزارهای مدیریت کانتینر عبارتند از Kubernetes، Docker Swarm و Apache Mesos. در ادامه مقاله بحث کانتینرها و ارتباط آنها با میکروسرویس ها به تفصیل مورد بحث قرار می گیرد.
• Service Mesh: سرویس مش یک لایه زیرساخت قابل تنظیم برای میکروسرویس ها است که ویژگی هایی مانند مدیریت ترافیک، تعادل بار و امنیت را ارائه می دهد. نمونه هایی از ابزارهای مش خدمات عبارتند از Istio، Linkerd، و Consul Connect.

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

کانتینر چیست؟

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

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

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

یکی دیگر از مزایای مهم کانتینری سازی این است که به بهبود سازگاری و قابلیت اطمینان استقرار نرم افزار کمک می کند. کانتینرها به توسعه دهندگان این امکان را می دهند که یک برنامه کاربردی و وابستگی های آن را در یک image قرار دهند که می تواند در یک محیط کنترل شده آزمایش و تایید شود. این کمک می کند تا اطمینان حاصل شود که یک برنامه زمانی که در مرحله production استقرار می یابد همانطور که انتظار می رود اجرا شود.

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

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

حال که درک کلی از کانتینرها پیدا کردیم به سراغ ارتباط آن با میکروسرویس ها می رویم.

ترکیب کانتینرسازی و ماکروسرویس ها به طور کلی دارای فایده هایی ست:

• قابلیت حمل: با بسته‌بندی هر میکروسرویس در کانتینر خود، توسعه‌دهندگان می‌توانند اطمینان حاصل کنند که هر سرویس می‌تواند روی هر سیستمی اجرا شود. این امر انتقال میکروسرویس ها را بین محیط های مختلف، از توسعه گرفته تا آزمایش و production، آسان می کند. تا قبل از کانتینرها، بسیار پیش می آمد که کدها بر روی لپ تاپ و یا سیستم توسعه دهنده کار کنند اما در زمان استقرار روی سرور به مشکل بخورند. این مشکلات عمدتا به دلیل عدم تطابق نسخه وابستگی های کد بود. اما با وجود کانتینرها، تمام وابستگی ها و پکیج های مورد نیاز هر سرویس، با خود آن در یک image قرار می گیرد
• مقیاس پذیری: کانتینرها مقیاس پذیری میکروسرویس ها را آسان می کنند، زیرا هر سرویس می تواند بر روی host جداگانه خود اجرا شود، یا چندین نمونه از همان سرویس را می توان در host های مختلف اجرا کرد. این به توسعه دهندگان این امکان را می دهد که به راحتی تعداد نمونه های یک سرویس را برای برآورده کردن تقاضاهای در حال تغییر، افزایش یا کاهش دهند.
• تاب آوری: میکروسرویس ها با تقسیم یک برنامه بزرگ به اجزای کوچکتر و مستقل، ایجاد یک سیستم انعطاف پذیرتر را آسان تر می کنند. اگر یکی از سرویس ها خراب شود، روی بقیه سیستم که می توانند به طور عادی به کار خود ادامه دهند تأثیری نخواهد داشت. علاوه بر این، کانتینرها به ایزوله کردن هر سرویس کمک می کنند، که خطر انتشار خرابی بین سرویس ها را کاهش می دهد.
• انعطاف‌پذیری: معماری میکروسرویس‌ها به شما امکان می‌دهد برنامه‌هایی بسازید که می‌توانند در طول زمان با آسان‌کردن افزودن، حذف یا به‌روزرسانی سرویس‌ها تکامل یابند. این امکان پاسخگویی سریع و کارآمد به نیازها و فناوری های در حال تغییر کسب و کار را فراهم می کند. کانتینرها بسته بندی و استقرار این خدمات را آسان می کنند و امکان اجرای آنها را در هر زیرساختی ممکن می سازند.
• سهولت استقرار: کانتینرها، بدون توجه به محیط، استقرار خدمات را به طور مداوم و قابل اعتماد آسان می کنند. آنها یک قالب استاندارد برای packaging برنامه ها ارائه می دهند که انتقال آنها از توسعه به production را آسان می کند. علاوه بر این، کانتینرها را می توان به راحتی مدیریت و سازماندهی کرد و امکان استقرار و مدیریت ماکروسرویس ها را به صورت خودکار فراهم می کند.
• بهبود استفاده از منابع: کانتینرها به شما امکان می دهند چندین سرویس را روی یک host واحد اجرا کنید که می تواند استفاده از منابع را بهبود بخشد و هزینه ها را کاهش دهد. کانتینرها همچنین مدیریت منابع مورد نیاز هر سرویس را آسان می کنند که به بهینه سازی استفاده از منابع کمک می کند.

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

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

• داکر( Docker ): داکر پرکاربردترین ابزار کانتینری‌سازی است. بستری برای ساخت، انتقال و اجرای کانتینرها فراهم می کند. داکر به شما امکان می دهد یک برنامه کاربردی و وابستگی های آن را در یک Dockerfile تعریف کنید و سپس یک image داکر بسازید که می تواند به عنوان یک کانتینر اجرا شود. داکر همچنین یک مخزن متمرکز برای ذخیره و به اشتراک گذاری image داکر فراهم می کند که توزیع و همکاری در کانتینرها را آسان می کند.
• Kubernetes: Kubernetes یک سیستم مدیریت کانتینر منبع باز است که برای مدیریت و خودکارسازی استقرار، مقیاس‌بندی و مدیریت کانتینرها استفاده می‌شود. Kubernetes یک صفحه کنترل متمرکز برای مدیریت کانتینرها و خودکارسازی استقرار، مقیاس‌بندی و مدیریت کانتینرها ارائه می‌کند.
• Apache Mesos: Apache Mesos یک سیستم مدیریت cluster منبع باز است که برای مدیریت کانتینرها و سایر برنامه ها استفاده می شود. Mesos یک پلتفرم مقیاس پذیر و مقاوم در برابر خطا برای اجرای کانتینرها و سایر برنامه ها ارائه می دهد و با ابزارهای محبوب کانتینری مانند Docker و Kubernetes ادغام می شود.

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

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

منابع

• کتاب فوق العاده Microservice Architecture نوشته Irakli Nadareishvili چاپ شده توسط انتشارات O'Reily. اگر میخواهید با تمام وجود همه چیز معماری میکروسرویس را درک کنید حتما این کتاب را بخوانید. میتوانید در سایت هایی مانند libgen نیز آن را دانلود کرده و لذت ببرید. کتاب تقریبا تکمیل است و دیدگاه بسیار کاملی از تمام جنبه های میکروسرویس به شما می دهد.
• لینک گذاشته شده مقاله مارتین فاولر در مورد میکروسرویس هاست. متن روانی دارد که تا آخر شما را همراه خود می برد و خیلی دقیق بیشتر مسائل را بیان کرده. برای شروع حتما متن مناسبی ست.
• این مقاله در سایت مدیوم خیلی روان مسئله کانتینرها را بررسی کرده و توضیحات خوبی را ارائه داده. توصیه میکنم برای شروع سراغ این مقاله بروید
• مقاله ای کوچک در مورد داکر و کوبرنتیس و نحوه یادگیری آنها. اگر قرار به یادگیری این دو دارید حتما این مطلب را بخوانید و به لینک های دیگری که ارجاع داده مراجعه کنید. دید کاملی از مسیر یادگیری اینها می دهد.

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