https://virgool.io/feed/@amir-mohammad fa 2026-06-16 06:03:28 https://files.virgool.io/upload/users/12772/avatar/Y73A2N.jpeg?height=120&width=120 https://virgool.io/@amir-mohammad https://virgool.io/@amir-mohammad/%D8%A8%D8%B1%D8%B1%D8%B3%DB%8C-%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D8%A8%D8%AF%D9%88%D9%86-%D8%B3%D8%B1%D9%88%D8%B1-%D8%AF%D8%B1-%D9%85%D8%AD%DB%8C%D8%B7-%D9%87%D8%A7%DB%8C-%D8%A7%D8%A8%D8%B1%DB%8C-kzt3evfndpez امیرمحمد کرم‌زاده - مجتبی مرادیچکیده پذیرش ابر و رایانش‌ابری در سرتاسر جهان شتاب بسیاری به خود گرفته‌است. شرکت‌ها برای مهاجرت برنامه‌های کاربردی خود به ابر، توسعه بر اساس معماری‌های بومی ‌ابری را در دستور کار خود قرار داده‌اند. امروزه توسعه‌دهندگان دنبال راهکارهایی هستند که تمرکز خود را از مسائل جانبی بردارند و تنها دغدغه‌شان توسعه کسب‌وکار خودشان باشد. با توجه به این دغدغه‌ها، محاسبات بدون سرور به طور پیوسته در حال تبدیل شدن به انتخاب اول توسعه‌دهندگان برای منطق برنامه‌هایشان است. با این وجود، به علت نو بودن مباحث معماری بدون‌سرور استقبال قابل قبولی از آن صورت نگرفته است. البته ریشه‌های این مشکل می‌تواند کمبود تجربه معماران نرم‌افزار در پیاده‌سازی سیستمی با معماری بدون‌‌سرور، نگرانی‌های امنیتی از بابت استفاده ‌از یک زیرساخت عمومی برای پیاده‌سازی کد اختصاصی کسب‌ وکار و مشکلات کارایی در برنامه‌هایی که تحت معماری بدون‌سرور ایجاد می‌شوند باشد.مقدمهتاریخ بروز رایانش‌ابری را می‌توان پس از تصبیت فناوری‌های مجازی‌سازی دانست. با تثبیت مجازی‌سازی، ارائه‌دهندگان خدمات اقدام به توسعه خدمات و سرویس‌هایی بر این بستر کرده‌اند. مشهورترین خدمت بر بستر سامانه‌های مجازی شده، رایانش ابری است. استفاده‌ از ابر مزایای بسیاری برای ما به ارمغان می‌آورد که از بین آن‌ها می‌توان پرداخت به ازای مصرف و تمرکز بیشتر بر کسب‌ وکار اشاره کرد.به طور کلی، خدمات رایانشی در ابر را می‌توان به ۳ دسته تقسیم کرد: نرم‌افزار به عنوان سرویس (SaaS)، سکو به عنوان سرویس (PaaS) و زیرساخت به عنوان سرویس (IaaS). در SaaS، ارائه‌دهندگان ابر انواع مختلفی از نرم افزارها را به عنوان خدمات به کاربران ارائه می‌دهند. به عنوان مثال، Google برنامه‌های بسیاری را به عنوان یک سرویس ارائه می‌دهد (برای مثال، Gmail، Google Docs، Google Sheets و Google forms). در این نوع ابر، کاربر مسئولیتی در قبال توسعه، استقرار و مدیریت خدمات ندارد. کاربر در اینجا فقط از آنها استفاده می‌کند بدون اینکه نگران تنظیمات باشد. در PaaS، شرکت‌های ابری خدماتی مانند ذخیره‌سازی، سرورها و سیستم‌عامل‌ها را برای توسعه دهندگان ارائه می‌دهند. توسعه‌دهندگان برای استقرار، اجرا و مدیریت برنامه‌های خود به این خدمات دسترسی دارند. در این نوع ابر، توسعه دهنده مسئول استقرار و مدیریت (تنظیمات و تنظیمات) نرم افزار خود است تا اطمینان حاصل کند که برنامه در حال اجرا است. در نهایت، در دسته IaaS، مصرف کنندگان ابر خدماتی مانند دسترسی به شبکه، سرورها، سیستم عامل‌ها و ذخیره سازی را کنترل و مدیریت می‌کنند و تقریبا تمامی وظایف مانند کارهای نظارتی و ... برعهده مشتریان است.مدیریت خدمات ابری اصلا کار ساده ای نیست. این‌ چالش‌ها می‌توانند دسترس‌پذیری، تعادل بار، مقیاس‌پذیری خودکار، امنیت، نظارت و ... باشد. برای مثال، کاربر ابر این انتظار را دارد که سرویس‌ابری همیشه در دسترس باشد و برنامه‌اش همیشه در دسترس باشد. چالش دیگر تعادل بار است. در این حالت، کاربر ابری باید اطمینان حاصل کند که درخواست‌های سرویس‌ها بین منابع مختلف به صورت متعادل توزیع می‌شوند.وجود این چالش‌ها منجر به معرفی مدل دیگری از رایانش ابری شده است که محاسبات ابری بدون‌سرور نامیده می‌شود. محاسبات ابری بدون‌سرور با backend به عنوان سرویس (BaaS) و تابع به عنوان یک سرویس (FaaS) ارائه می‌شود. این مفاهیم را در قسمت‌های بعدی توضیح خواهیم داد. از FaaS به عنوان غالب ترین مدل بدون سرور یاد می‌شود و همچنین به عنوان "تابع‌های رویداد محور" شناخته می‌شوند.رایانش بدون سرور مزایای بسیاری دارد. مهم‌ترین مزیت رایانش بدون‌سرور، مقیاس‌پذیری خودکار است. مقیاس‌پذیری در رایانش بدون‌سرور می‌تواند عمودی یا افقی باشد. در محاسبات بدون سرور، برنامه‌ها به‌طور خودکار بر حسب تقاضا، افزایش و کاهش می‌یابند، و توسعه‌دهنده نیازی به نگرانی در مورد مسائل مقیاس‌بندی ندارد. به عنوان مثال، هنگامی که یک برنامه کاربردی روی یک ابر بدون‌سرور اجرا می‌شود، زمانی که درخواست های برنامه افزایش می‌یابد، به طور خودکار نمونه‌های آن افزایش می‌یابد. یکی دیگر از ویژگی های محاسبات بدون‌سرور، پرداخت به ازای استفاده از منبع است. این الگوی رایانش ابری بر اساس استفاده واقعی از منابع، هزینه‌ای از توسعه‌دهندگان دریافت می‌کند. به عنوان مثال، در مواردی که برنامه بیکار است، استقرار یک برنامه برای توسعه دهنده هزینه‌ای ندارد و ارائه دهنده بدون سرور تنها زمانی هزینه‌ را محاسبه می‌کند که برنامه از منبع استفاده می‌کند.با وجود مزایا و معایب متعدد رایانش بدون‌سرور، وجود راهنمایی برای معماران جهت آشنایی مقدماتی با معماری بدون سرور احساس شد. بنابراین هدف این تحقیق پاسخ به برخی از سؤالات تحقیقاتی حیاتی مرتبط با رایانش ابری بدون سرور و در نتیجه کمک به محققان و توسعه دهندگان برای درک بهتر معماری بدون‌سرور و کمک به توسعه آن است.ساختار این پژوهش به این شکل است: در بخش معماری بدون‌سرور، ابتدا مفهوم «بدون‌سرور» را تعریف می‌کنیم؛ سپس مزایا و معایب آن را شرح می‌دهیم. در بخش مقایسه با سایر معماری‌ها، معماری بدون‌سرور را با سایر معماری‌های مطرح روز مقایسه می‌کنیم. در بخش ارائه‌دهندگان خدمات بدون‌سرور با شرکت‌های مطرحی که خدمات بدون‌سرور به مشتریانشان ارائه می‌دهند، آشنا‌ می‌شویم. در سکو‌های ارائه خدمات بدون سرور، سکو‌های نرم‌افزاری برای استقرار برنامه‌های بدون‌سرور در محیط ابری معرفی می‌شوند. این سکو‌ها هم می‌توانند متن‌باز باشند و هم تجاری. در بخش چارچوب‌های بدون‌سرور نیز چارچوب‌های نرم‌افزاری برای توسعه برنامه‌ها در محیط بدون‌سرور معرفی می‌شوند. در بخش پایش برنامه‌ها در معماری بدون سرور به معرفی ابزارها و راهکارها برای پایش یک برنامه بدون‌سرور خواهیم پرداخت. در بخش مهاجرت به معماری بدون سرور به ارائه مثالی از مهاجرت یک سرویس با معماری یک‌تکه به معماری بدون‌سرور و تاثیرات معماری جدید بر کارایی برنامه خواهیم پرداخت. ما در بخش الگو‌های معماری بیش از ۲۰ الگوی معمارانه برای پیاده‌سازی یک سامانه بدون‌سرور پرداخته‌ایم. در این الگو‌ها ابتدا مشکل و زمینه را ذکر کرده و معماری پیشنهادی را پیشنهاد می‌دهیم. در بخش مثال‌هایی از استفاده از خدمات بدون سرور، مثال‌هایی از برنامه‌هایی که به معماری بدون‌سرور مهاجرت کرده‌اند را ذکر می‌کنیم. در نهایت در فاز جمع‌بندی و نتیجه‌گیری، به بیان خلاصه‌ و نتایج این تحقیق می‌پردازیم.معماری بدون‌سرورمتاسفانه تعریف دقیقی برای توضیح رایانش بدون‌ سرور وجود ندارد. رایانش بدون سرور نیز مانند بسیاری از مفاهیم دیگر در مهندسی کامپیوتر از جنبه‌های متفاوتی قابل بررسی و ارزیابی است. بنابراین ممکن نیست که بتوان برای آن تعریف واحدی را ارائه داد که تمامی جنبه‌های آن را پوشش دهد؛ بلکه تعاریف مختلف سعی می‌کنند که تنها قسمت‌هایی از رایانش بدون سرور را پوشش دهند. برای شروع می‌خواهیم دو جنبه از رایانش بدون سرور را توضیح دهیم [1].بدون‌سرور برای توصیف معماری برنامه‌های‌کاربردی به کار برده می‌شود که سرویس‌هایشان را به طور کامل یا قابل توجهی بر روی ساختار یک ارائه‌دهنده خدمات ابری مستقر کرده‌اند. در این معماری، مدیریت سرویس‌ها به طور کامل برعهده ارائه‌دهندگان سرویس می‌باشد. شرکت‌های ارائه‌دهنده خدمات بدون سرور برنامه‌ها و سرویس‌های ثالثی را توسعه داده‌اند که برنامه‌نویس می‌تواند از آن‌ها استفاده کند (از سرویس‌ احراز هویت گرفته تا سرویس ارسال ایمیل و سرویس‌های پردازش تصویر در آمازون و مایکروسافت). این سرویس‌ها را اصطلاحا Backend-as-a-Service یا به اختصار BaaS می‌نامیم.کاربرد دیگری که برای رایانش بدون سرور می‌توان متصور شد این است که برنامه‌ بدون‌سرور برنامه‌ای است که برای اجرای منطق برنامه، باید آن را به سرویس‌های کوچکتری بشکنیم و توابعی را در حالت بدون حالت (Stateless) اجرا کنیم. این ویژگی رایانشی در معماری بدون سرور را Function-as-a-Service یا به اختصار FaaS می‌نامیم.پس تا اینجا متوجه‌ شده‌ایم که معماری بدون سرور به معنای نداشتن سرور نیست؛ بلکه به معنای معماری ‌است که کنترل و مدیریت سرور برعهده ارائه‌دهندگان سرویس‌های ابری است. در مورد مزایا و معایب معماری بدون سرور در قسمت‌های آتی بحث خواهیم کرد. بدون سرور را می‌توان یک مدل اجرایی در رایانش ابری نامید که در قالب‌های BaaS و FaaS پیاده‌سازی شده است. زمینه کلی برنامه‌های بدون سرور در شکل ۱ نمایش داده شده است.شکل 1 زمینه معماری بدون سرورشکل فوق زمینه کلی معماری بدون سرور را نمایش می‌دهد. جایی که یک خدمت ابری بدون سرور را جایی بین PaaS و SaaS می‌دانند. در میانه شکل ۱ همانگونه که مشاهده می‌کنید، serverless قرار گرفته است که یک زیرساخت اشتراکی بین تمامی کاربران سرویس داریم که در آن کد‌های اختصاصی خود را بارگذاری و پیاده‌سازی می‌کنیم. در طرف راست تصویر، SaaS قرار دارد که در آن زیرساخت و کدی که کاربران با آن تعامل دارند، هردو اشتراکی است و در طرف چپ این تصویر، کد و زیرساخت در PaaS‌هر دو اختصاصی است [۲].اما معماری کلی یک برنامه بدون سرور چگونه است؟ این معماری در شکل ۲ نشان داده شده است [۳].شکل 2 معماری کلی یک برنامه بدون سرورهمانگونه که شکل ۲ نشان می‌دهد، معماری کلی یک برنامه بدون سرور به شکل فوق است. منطق برنامه در قالب توابعی در سرورهای ابری پیاده‌سازی می‌شوند. این سرویس‌ها ممکن است از سرویس‌هایی مانند دلال پیام (message Broker) یا پایگاه‌داده استفاده کند. بنابراین، برخی از سرویس‌های BaaS در تعامل با سرویس FaaS هستند تا عملکرد کامل و مطمئن آن را تضمین کنند. اما برای فراخوانی توابع باید کاربران از طریق دروازه‌های پیام اقدام به فراخوانی توابع کنند. درواقع سرویس‌های FaaS به خاطر معماری میکروسرویس و توانایی مقیاس‌پذیری آن‌ها به صورت مستقیم فراخوانی نمی‌شوند، بلکه باید این کار از طریق واسطی به نام API Gateway صورت بگیرد.اما اکنون که با مفهوم بدون‌سرور آشنا شدیم، برای درک بهتر چند ویژگی ‌از آن را مجددا مرور کنیم. یک سرویس بدون سرور، خدمتی است که ویژگی‌های زیر را دارا می‌باشد.محیط اجرایی از مشتری مخفی نگه ‌داشته می‌شود. در مدل بدون سرور لازم نیست مشتری اطلاعی از جزئیات اجرای برنامه‌ مانند محیط نگه‌داری کد‌ها، اطلاعات ماشین مجازی، کانتینر و سیستم‌عامل اجرا کننده کد داشته باشد. از نظر بازبودن (openness) معماری بدون‌سرور اطلاعات اندکی به مشتریان می‌دهد.ارائه‌دهنده باید قابلیت مقیاس‌پذیری خودکار (autoscaling) برای سرویس‌های خود را فعال کرده‌باشد. منابع به ازای درخواست، قابلیت افزایش داشته باشند.مکانیسم پرداخت در سرویس‌های بدون سرور از نوع Pay-as-you-go یا همان پرداخت به ازای استفاده است.ارائه‌دهنده خدمات ابری، مانند تمامی سرویس‌های ابری دیگر خود را ملزم به رعایت توافق‌نامه سطح سرویس (Service Leven Agreement) بداند.عناصر پایه‌ای در معماری بدون‌سرور توابع هستند که لازم است منابعشان از ارائه‌دهنده خدمات مخفی بماند.مزایا و معایبمعماری بدون‌سرور نیز مانند معماری‌های دیگری که در دنیای مهندسی نرم‌افزار وجود دارد، دارای معیاب و مزایایی می‌باشد. در [1،2 و 3] این موارد ذکر شده‌اند. مزایایی که برای رایانش بدون‌سرور می‌توان در نظر گرفت عبارتند از:مقیاس‌پذیری خودکار: کاربران لازم نیست دغدغه‌ای بابت مقیاس‌پذیر بودن برنامه‌خود در محیط ابری داشته باشند؛ بلکه این ارائه‌دهنده خدمات است که بر اساس ترافیک و تقاضایی که برای یک تابع وجود دارد، آن تابع را مقیاس‌پذیر کند و تضمین این مورد را نیز در sla به صراحت ذکر کرده است.پیاده‌سازی آسان:‌ کاربر برای پیاده‌سازی برنامه‌ خود کافی است تا برنامه‌ را در پنل مربوطه بارگذاری کند یا این کار را با چند دستور cli انجام دهد.کاهش هزینه مقیاس‌پذیری در مقایسه با روش‌های دیگرکاهش زمان انتشار محصول (Time to Market)رایانش سبز‌تر: با توجه به قوانین سخت‌گیرانه احداث و استفاده از مراکز داده؛ این مراکز باید کاملا در مصرف انرژی بهینه باشند.در ادامه معایب رایانش بدون سرور را مورد بحث قرار خواهیم داد:‌مشکل تاخیر شروع سرد: تاخیر شروع سرد باعث می‌شود تا بلافاصله بعد از فراخوانی توابع، توابع اجرا نشوند. تاخیر شروع سرد یکی از اصلی ترین چالش‌های رایانش بدون سرور برای پیاده‌سازی عملی بسیاری از سرویس‌ها مخصوصا سرویس‌های درلحظه (Real Time) که تاخیر شروع سرد بسیار اندکی را طلب می‌کنند.اجرای طولانی مدت توابع: در مدل بدون سرور توابع نمی‌توانند به مدت طولانی در حال اجرا باشند. توابع در مدل بدون‌سرور اجرای کوتاه‌ مدتی دارند و باید منابع محدودی را مصرف کنند.تست و اشکال‌یابی توابع: از آنجایی که توابع در کانتینر‌ها یا ماشین‌های مجازی جعبه ‌سیاهی اجرا می‌شوند، عملیات اشکال‌زدایی و تست نرم‌افزار تنها باید به صورت جعبه ‌سیاه صورت بپذیرد و دسترسی به کد پروژه وجود ندارد.مشکل vendor lock-in: این مشکل زمانی به وجود می‌آید که برنامه در بستر ابری یک ارائه‌دهنده آنقدر توسعه پیدا کرده‌است که دیگر مهاجرت از آن ارائه‌دهنده خدمات ابری به ارائه‌دهندگان دیگر بسیار سخت یا غیرممکن باشد. در این حالت توسعه‌دهنده محکوم به استفاده از آن سرویس ‌ابری هستند.توابع بدون حالت (Stateless Functions):‌ در معماری بدون‌سرور، توابع باید به صورت بدون حالت اجرا شوند و حالت‌های قبلی را نگه ندارند. اگرچه بسیاری از به‌روش‌های معماری نرم‌افزار به سمت استفاده از الگو‌های بدون حالت حرکت کرده، اما اگر بخواهیم یک برنامه‌ حالت‌دار (Stateful) را به معماری بدون‌سرور مهاجرت دهیم، قطعا با چالش‌های بسیاری مواجه خواهیم شد.چالش‌هامواردی که در قسمت قبلی ذکر شد اگرچه نقاط ضعف معماری‌های بدون سرور را مورد بحث قرار می‌داد، بلکه می‌توانست به عنوان چالش‌هایی برای مهاجرت به معماری‌های بدون‌سرور نیز فرض شود. در [۴] سه چالش‌ اصلی برای معماری بدون‌سرور مورد بحث قرار گرفته‌است. این چالش‌ها به طور کلی چالش‌های مطرح در مهندسی نرم‌افزار مانند کمبود تجربه در توسعه معماری‌های بدون سرور، چالش‌های اجرایی (operational) مانند حل مشکلات برنامه‌های با زمان اجرای بالا یا منابع محدود و چالش‌هایی برای مهندسی کارایی در سطح برنامه، مانند مدیریت بارهای‌کاری سیستم است. در [۵] چالش‌های معماری بدون سرور در دامنه یک مسئله اینترنت اشیا که از معماری بدون سرور استفاده‌ می‌کند، مطرح شده است. چالش‌های آن سیستم اینترنت اشیا مورد بحث عبارت بودند از زمان پاسخ و Jitter بالا. راه‌حل مقاله، استفاده از وب‌اسمبلی در سیستم بدون سرور بود تا هم زمان پاسخ و هم Jitter کاهش یابد. به علاوه، با استفاده از وب‌اسمبلی، حجم کانتینر و زمان شروع سرد نیز کاهش می‌یافت.در [۶] نیز چالش‌های دیگر معماری بدون سرور مورد بحث قرار گرفته است که یکی از همین چالش‌ها، برنامه‌ریزی برای اجرای کانتینر‌ها توسط ارائه‌دهنده سرویس ابری بود. برنامه‌ریزی در این محیط‌ها می‌تواند بر اساس مصرف انرژی، مصرف منابع، نوع و طول جریان‌کاری یا جریان‌های داده‌ای باشد. در [۷] مشکل دیگر و مهم رایانش ‌بدون سرور مطرح شد. از آنجایی که تمامی کد‌های کاربران توسط ارائه‌دهنده خدمات ابری نگهداری و اجرا می‌شود. لذا کد‌ها باید در فضای ایزوله‌ای اجرا شوند. این درحالی بوده که کانتینر‌ها این اطمینان از ایزوله‌ بودن کد را نمی‌دهند. در نقطه مقابل ماشین‌های مجازی شروع سرد بسیار طولانی داشتند. ایده مقاله استفاده از ماشین‌های مجازی سبک و کوچک کردن هسته سیستم‌عامل لینوکس تا حدی که تنها برای اجرای یک تابع مناسب باشد، بود.مقایسه با سایر معماری‌هادر [۸] مقایسه دو معماری بدون سرور و میکروسرویس مورد بحث قرار گرفته است. این دو معماری اگرچه در مفاهیم و جزئیات با یکدیگر متفاوت هستند اما هر دو یک‌دیگر را تقویت می‌کنند. معماری میکروسرویس این قابلیت را به وجود آورده که تیم‌های کوچکی از توسعه‌دهندگان شرکت هرکدام برروی جنبه‌هایی از برنامه تمرکز کنند. در واقع، معماری میکروسرویس این امکان را به وجود آورده است تا یک برنامه خیلی بزرگ‌ را بتوانیم به چندین برنامه کوچک‌تر بشکنیم. معماری بدون سرور هم این کمک را می‌کند تا با کمترین زحمت و هزینه، میکروسرویس‌ها را در محیط ابری اجرا و مقیاس‌پذیر کنیم. در معماری میکروسرویس استفاده از توابع و سرویس‌های بدون‌حالت (stateless) یک به‌روش است در حالی‌که استفاده از توابع بدون حالت در معماری بدون‌سرور یک اجبار است. از این نظر دو معماری با یکدیگر شبا‌هت دارند. استفاده از معماری بدون‌سرور در یک محیط ابری بدون‌سرور (همان ترکیب معماری‌های بدون‌سرور و میکروسرویس)، باعث می‌شود تا معماری مقاومی در برابر خرابی‌ها داشته باشیم، معماری مقیاس‌پذیری خودکار داشته باشد و نگرانی از مسائل پایه‌ای امنیتی در معماری خود نداشته باشیم. در ادامه در جدول ۱، مواردی که بهتر است از معماری میکروسرویس یا بدون‌سرور استفاده کنیم، ذکر شده است.جدول 1 مقایسه موارد استفاده از معماری بدون سرور یا میکروسرویسارائه‌دهندگان خدمات بدون سرورارائه‌دهندگاه خدمات ابری در سراسر جهان اقدام به ارائه خدمات بدون‌سرور برای راحتی توسعه‌ معماری‌ بدون‌سرور کرده‌اند. متاسفانه هیچ‌کدام از این سرویس‌ها در کشور ایران قابل دسترسی نیست. در لیست زیر تعدادی از ارائه‌دهندگان خدمات بدون‌سرور ذکر شده‌اند.آمازون: شرکت آمازون را می‌توان بزرگترین ارائه‌دهنده خدمات ابری در دنیا نامید. این شرکت در سال ۲۰۱۴ برای اولین بار مفهوم رایانش بدون‌سرور را مطرح کرد و با انتشار سکوی بدون‌سرور خود یعنی AWS Lambda باعث انقلابی در عرصه رایانش ابری شد و داستان رایانش بدون‌سرور را آغاز کرد. سرویس AWS Lambda را می‌توان کامل‌ترین سرویس رایانش بدون سرور در دنیا نامید که از زبان‌های برنامه‌نویسی بسیاری مانند C#، جاوا، پایتون، گو و جاوااسکریپت پشتیبانی می‌کند. همچنین سرویس AWS سرویس‌های آماده‌ای جهت پردازش فایل‌ها و تصاویر، احراز هویت، ارسال notification، تحلیل‌داده‌ها در سطح اینترنت اشیا و ... دارد [9].گوگل: شرکت گوگل به عنوان یک غول در صنعت IT در حوزه رایانش بدون‌سرور نیز فعال است. این شرکت در سال ۲۰۱۶ با معرفی سرویس Google Cloud Functions وارد عرصه رقابت در حوزه رایانش بدون سرور شده است. یکی از مواردی که سکوی بدون‌سرور گوگل برروی آن تاکید بسیاری دارد، عدم امکان vendor lock-in پس از مهاجرت به سرویس‌های ابری گوگل است. زیرا، سرویس بدون‌سرور گوگل برپایه سکوی متن‌باز knative توسعه داده می‌شود [10].مایکروسافت: مایکروسافت به عنوان غول صنعت نرم‌افزار چندسالی است که با توسعه پلتفرم Microsoft Azure وارد صنعت رایانش ابری شده است. مایکروسافت سرویس‌های بدون سروری را تحت عنوان Microsoft Serverless پیاده‌سازی کرده که شامل سرویس FaaS، سرویس Kubernetes و سرویس BaaS می‌شود [11].اوراکل: شرکت اوراکل نیز جز شرکت‌هایی است که خدماتی مبنی بر معماری بدون سرور را به فروش می‌رساند. این شرکت راهکا‌رهایی برای ارائه خدمات در قالب کانتینر‌های داکری ارائه می‌دهد. یکی از مزایایی که اوراکل در مورد سرویس‌های خود ادعا می‌کند این است که درصورت استفاده از سرویس‌های اوراکل خطر vendor lock-in متوجه کاربران و کسب‌وکارها نیست زیرا سرویس های بدون‌سرور توراکل بر پایه پروژه متن‌ باز Fn توسعه داده شده است. این سرویس انتخاب مناسبی برای کسب‌وکارهایی است که به دنبال یک ارائه‌دهنده که از کانتیرها استفاده می‌کند، هستند [12].کلودفلر: شرکت cloudflare به خاطر سرویس‌های CDN معروف خود، در جهان رایانش ابری بسیار خوشنام است. اما سرویس Cloudflare workers آخرین تلاش این شرکت برای بدست آوردن جایگاهی در رایانش بدون‌سرور است. این شرکت در ۹۰ کشور و بیش ‌از ۲۰۰ شهر جهان مراکز داده‌ای احداث کرده‌است که باعث شده این توانایی را داشته باشد تا با کمترین تاخیر پاسخ درخواست کاربران را بدهد. این شرکت ادعا می‌کند که به ازای استفاده از سرویس بدون‌سرور خود، کاربر شروع سردی بیش از چند میلی‌ثانیه را تجربه نخواهد کرد [13].شرکت IBM: سرویس IBM Cloud Functions نیز آخرین تلاش شرکت بزرگ IBM برای رقابت در حوزه معماری بدون سرور است، این مشرکت برپایه پروژه متن ‌باز خود در حوزه رایانش بدون سرور، یعنی OpenWhisk‌ اقدام به معرفی سرویس‌های ابری خود در حوزه رایانش بدون سرور مانند IBM Function Sequences و openwhisk‌ کرده است [14].سکو‌های (Platform) ارائه خدمات بدون سروربرای ارائه خدمات بدون‌سرور سکو‌های بسیاری برای اجرای برنامه‌ها تحت معماری بدون‌سرور توسعه داده شده است. این پلتفرم‌ها می‌توانند با هدف تجاری و اجرای برنامه‌های تجاری عرضه ‌شده باشند یا مقاصد تحقیقاتی داشته باشند.سکو‌های تجاری: این سکو‌ها مقاصد تجاری دارند و هدف از ارائه آن‌ها پیاده‌سازی معماری بدون‌سرور برای برنامه‌های تجاری در بستر این سکوها است. این سکو‌ها عمدتا یا توسط ارائه‌دهندگان خدمات ابری ارائه شده که پشتیبانی نسبتا خوبی دارند. همانگونه که دربخش قبلی نیز بحث کردیم، شرکت‌هایی مانند آمازون، گوگل و مایکروسافت از بازیگران اصلی این صنعت هستند. دسته‌ی دیگری از سکو‌ها توسط شرکت‌ها یا انجمن‌ها به مقاصدی به صورت متن ‌باز منتشر شده است.سکو‌های متن‌بستهAWS Lambda FunctionsGoogle Cloud FunctionsIBM Cloud FunctionsAzure Serverlessسکو‌های متن‌بازKnativeOpenFaaSOpenWhiskFissionبسیاری از سکو‌های متن ‌باز در سکو‌های تجاری شرکت‌های بزرگ استفاده می‌شوند. برای مثال، از سکوی Knative در سرویس بدون‌سرور شرکت گوگل استفاده می‌شود.سکو‌های با مقاصد آموزشی یا تحقیقاتی: بسیاری از پژوهشکده‌ها و دانشگاه‌ها با اهداف متنوعی اقدام به توسعه سکو‌های بدون‌سرور می‌کنند. برای مثال در [15] سرویس OpenLambda با اهداف آموزشی و حل بسیاری از مشکلات پایه‌ای در رایانش بدون‌سرور توسط محققین در آینده، توسعه داده شد و چندین سال است که دیگر از آن پشتیبانی نمی‌شود.سکوی TinyFaas یکی دیگر از سکو‌های توسعه‌داده شده در رایانش بدون سرور بود که هدف از توسعه‌ آن، حل مشکلات موجود در سرویس‌های لبه در رایانش ابری بود. یکی از این مشکلات زمان بالای استقرار و حجم بالای کانتینری بود که در لایه لبه سرویس‌های اینترنت اشیا که از معماری ابری و بدون‌سرور استفاده می‌کنند، بود [16].یکی از موارد بالقوه استفاده از سرویس‌های بدون‌سرور، استفاده از این معماری در توسعه برنامه‌های کاربردی مبتنی بر یادگیری ماشین بوده است. در [17] تلاش شده است تا با توسعه‌ cirrus سکویی مناسب اجرای برنامه‌های با قابلیت یادگیری ماشین در معماری بدون‌سرور فراهم شود.در [18] این مشکل توسط محققان مورد توجه‌ قرار گرفته است که برنامه‌های کاربردی که در محیط ابری توسعه‌داده می‌شوند شامل تعدادی از توابع هستند که به صورت زنجیره‌ای اجرا می‌شوند. حال فراخوانی زنجیره‌وار این توابع ممکن است موجب شروع سرد آبشاری شود. شکل ۳، شروع سرد آبشاری را نمایش می‌دهد.شکل 3 شروع‌سرد آبشاریبا توجه به شکل ۳، می‌بینیم برای اجرای یک جریان‌کاری متشکل از ۴ تابع، به ترتیب توابع دچار شروع سرد شده و پس از اجرای آخرین تابع، مجموع زمان اجرای تابع برابر خواهد شد با مجموع زمان اجرای توابع با مجموع زمان شروع‌سرد برای هر تابع. ایده‌ی Xanadu این است که با شناسایی مسیری که بیشترین احتمال اجرا را دارد و شروع سرد را در اجرای توابع موجود در جریان‌های کاری توابع کاهش‌ دهد تا از این طریق، زمان اجرای کل جریان کاری کاهش یابد.در [19] نیز سکویی برای توسعه برنامه‌های بدون‌سرور مبتنی بر بلاک‌چین معرفی و معرفی شده است که سعی می‌کند بلاک‌های بلاک‌چین را در نودهای مختلف اجرا‌کننده توزیع کند.مقایسه سکو‌هادر [20] سکو‌های بدون‌سرور مورد مقایسه قرار گرفته‌اند. نویسندگان مقاله مجموعه تست‌های بنچمارکی به نام FaaSDOM Benchmark Suit توسعه داده‌اند که معیاری برای مقایسه و آزمون سکو‌های بدون سرور است. اولین معیار مقایسه در FaaSDOM بر اساس زبان‌های پشتیبانی شده در سکو‌های بدون سرور است که در شکل ۴ مشخص شده است.شکل 4 مقایسه زبان‌های پشتیبانی شده در سکو‌های بدون سرور توسط FaaSDOMشکل 5 پنل برنامه FaaSDOMدر پنل برنامه FaaSDOM که در شکل ۵ آمده است، می‌توان نوع تست، حافظه مدنظر برای اجرای تست، زمان Timeout، نوع زیرساخت‌ ابری، زبان برنامه‌نویسی و مکان سرویس‌های ابری را برای انجام تست در نظر گرفت و سپس براساس مقادیر مشخص شده، سامانه را تست کرد. FaaSDOM برای تولید بار‌های کاری از مجموعه‌ی داده‌های wrk2 برای تولید داده‌های faas استفاده می‌کند. سپس نتایج در پایگاه‌داده برنامه که از نوع influx DB‌ است ذخیره شده و نمایش اطلاعات نیز در پنل گرافانا صورت می‌گیرد.شکل ۶ یک نمونه از نتایج اجرا در FaaSDOM را نشان می‌دهد که سنجش براساس تاخیر برنامه ‌بوده و نتایج هر ۵ ثانیه یکبار لاگ شده‌اند. از موارد برتری FaaSDOM نسبت به سایر مجموعه‌های آزمون، امکان مقایسه قیمت‌های تمام‌ شده به ازای موارد انتخاب شده است. توسعه‌دهندگان FaaSDOM معیار قیمت را براساس معیاری که خود مشخص‌کرده‌اند استخراج می‌کنند که دقت چندان بالایی ندارد.شکل 6 نتایج اجرا در FaaSDOMدر [21] نیز ۴ سکوی ابری azure، AWS، Google Cloud Functions و IBM OpenWhisk مورد بررسی قرار گرفته‌اند. این مجموعه‌ی آزمون شامل بررسی و مقایسه مواردی ازجمله شیوه اعتبارسنجی و تعیین حق دسترسی، مقیاس‌پذیری، حداکثر تعداد توابع سکو‌های ابری، حداکثر تعداد اجراهای موازی توابع، حداکثر زمان اجرای یک تابع، حداکثر حجم کدها و شیوه‌های ذخیره‌سازی توابع است.چارچوب‌های (Framework) بدون‌سرورچارچوب‌های بسیاری برای توسعه برنامه‌ها براساس معماری بدون‌سرور توسعه داده شده است. این چارچوب‌ها در راستای سازگاری بهتر و راحتتر معماری برنامه توسعه‌داده شده با سکوی ‌بدون‌سرور، یا ساختاردهی به برنامه‌های توسعه‌داده شده با معماری بدون سرور است. یکی از این تلاش‌ها، چارچوب توسعه داده شده برای سکوی نودجی‌اس به نام Claudia است که سعی می‌کند با ساختاردهی به پروژه توسعه داده‌شده با نود‌جی‌اس، تعامل بین سرویس AWS Lambda و توسعه‌دهنده را تسهیل کند [22].در [23] نیز معماری چارچوب Kappa مورد بحث قرار گرفته است. هدف این چارچوب ارائه یک بستر مقیاس‌پذیر برای محاسبات عمومی با قابلیت اجرای بلند مدت توابع است. قابلیت اجرای توابعی که اجرای بلند مدت دارند در توسعه‌ برنامه‌های یادگیری ماشین، بیگ‌دیتا، کراولر و آنالیز استریم‌ها کاربرد دارد. با استفاده از چارچوب کاپا می‌توان در کد چک ‌پوینت‌هایی برای ذخیره حالت برنامه مشخص کرد. پس از اتمام مدت زمان مجاز اجرای برنامه، برنامه با مراجعه به حالت ذخیره‌شده تابع، اجرا را از همان‌جایی که چک ‌پوینت برای آن در نظر گرفته‌شده بود، ادامه می‌دهد.چارچوب‌های مختلفی جهت توسعه برنامه‌های بدون‌سرور با زبان‌های مختلف توسعه داده شده است. یکی از این چارچوب‌ها Kotless نام‌ دارد [24] که هدف آن، توسعه برنامه‌های موبایل با زبان کاتلین در محیط‌های بدون‌ سرور است و با سکوی AWS Lambda سازگاری مناسبی دارد.پایش برنامه‌ها در معماری بدون سروربه علت نو بودن مباحث رایانش بدون‌سرور ابزار‌های اندکی برای پایش و خطایابی توابع در رایانش‌ بدون‌سرور وجود دارد. با این وجود ابزار‌های تجاری مانند Dashbird، Thundra.io یا CloudWatch سعی‌کرده‌اند پایش‌ معماری سامانه‌های بدون‌سروری که در سکوی ابری AWS Lambda پیاده‌سازی شده‌اند را فراهم آورد. پایش و خطایابی در معماری بدون‌سرور موضوع برخی از پژوهش‌ها و پروژه‌های تحقیقاتی در شرکت‌ها و دانشگاه‌ها بوده است. برای مثال در [25] پروژه SeMode معرفی شده‌ است که رویکرد‌های پایش و خطایابی در معماری بدون‌سرور را ترکیب‌کرده است تا این دو مورد را در کنار یکدیگر داشته باشد. ایده SeMoDeترکیبی بین یک محیط شبیه‌سازی و محک است که قبلاً منتشر شده است. همچنین علایق تحقیقاتی بیشتر، مانند اندازه‌گیری عملکرد و غیره، در این ابزار ادغام شده‌اند تا ابزاری برای اهداف و پلتفرم‌های مختلف ارائه دهند. SeMode برای پروژه‌هایی مناسب است که بر بستر سیستم AWS Lambda میزبانی می‌شوند و قالب‌هایی برای تولید تست خودکار برای برنامه به صورت آماده دارد که آماده فراخوانی و تغییر پارامتر جهت تست‌ برنامه هستند. یک مثال از قالب‌های تست SeMoDe در شکل ۷ نمایش داده شده است.شکل 7 تست برنامه در فریمورک SeMoDeمهاجرت به معماری بدون سرورمهاجرت از سایر معماری‌ها به معماری بدون‌سرور موضوع بسیاری از پژوهش‌ها در حوزه معماری بدون‌سرور بوده است. در [26] نویسندگان قصد دارند تا یک برنامه تبدیل فایل‌های تصویری به متن را به معماری بدون‌سرور مهاجرت دهند. این برنامه تعدادی فایل تصویری با پسوند pdf را از کاربر دریافت کرده، با استفاده از تکنیک‌های یادگیری ماشین و شبکه‌های عصبی متن آن را استخراج کرده و در نهایت، فایل متنی را به pdf تبدیل می‌کند. بعلاوه، متن‌های استخراج‌شده توسط الگوریتم OCR‌ خود را در پایگاه‌داده جهت کارهای آتی ذخیره می‌کند. مهاجرت از معماری یک‌تکه به معماری بدون‌سرور برای نویسندگان این مقاله ۲ چالش داشته است.1. محدودیت استفاده از منابع: همانطور که می‌دانیم استفاده از منابع در معماری بدون‌سرور دارای محدودیت‌هایی است. این برنامه از یک الگوریتم شبکه‌عصبی استفاده می‌کند تا طبقه‌بندی اطلاعات را صورت بدهد. این الگوریتم منابع عظیمی را مصرف می‌کند. راهکار نویسندگان مقاله، تقسیم این الگوریتم به ۲ تابع جهت دورزدن این محدودیت است.2. چالش دوم زمان بالای اجرای توابع و برنامه بود. نویسندگان در معماری جدید، سعی کرده‌اند تا هنگامی که برنامه می‌تواند منتظر پاسخ فراخوانی تابع نماند به کار دیگری مشغول شود. برای این منظور بسیاری از فراخوانی‌ها از نوع آسنکرون بوده تا زمان اجرای برنامه تا حد قابل قبولی پایین بیاید.شکل 8 معماری جدید برای سیستم تبدیل عکس به متندر شکل ۸، معماری این سیستم نمایش داده شده است. این سیستم از ۵ جز اصلی تشکیل شده است:سرویس Dispatcher: یک پیام pub/sub را دریافت می‌کند که حاوی لینکی از آن سطل (Bucket)ای است که سند‌های تصویری در آن‌ قرار دارند. هر کدام از این سد‌ها توسط Dispatcher به یک Coordinator وصل می‌شود.سرویس Coordinator: نقش همنواساز (Orchestrator) در جریان تبدیل فایل تصویری به متنی را دارد. همنواساز مسئول کنترل خط لوله اجرای برنامه‌است و قسمت‌های مختلف را به یک‌دیگر متصل می‌کند.سرویس Page Classifier 1&2: وظیفه‌ی دسته‌بندی سند‌ها را برعهده دارند. هر page Classifier مسئول دسته‌بندی یک صفحه از سند است. برای راحتی و رعایت محدودیت‌های معماری بدون‌سرور، page classifier به دو تابع شکسته شده است.سرویس OCR: براساس دسته‌بندی خروجی از page classifier، محتوای متن را از تصویر استخراج می‌کند و برای coordinator‌ ارسال می‌کند.جدول 2 مقایسه هزینه معماری بدون‌سرور در مقایسه با معماری یک‌تکهجدول ۲ نتیجه مهاجرت به این معماری را نشان می‌دهد. این نتیجه نشان می‌دهد که ارسال ۱۰۰ سند تصویری همزمان به برنامه تحت معماری‌های بدون‌سرور و یک‌تکه است. همانگونه که مشاهده می‌شود برنامه‌ یک‌تکه‌ای که در ماشینی با ۴cpu و ۱۵ گیگابایت رم مستقر شده است، عملیات را در بیش از ۶ ساعت انجام می‌دهد و برای کاهش ۱ ساعته زمان اجرا باید برنامه را به ماشینی ببریم که 96 CPUو ۳۶۰ گیگابایت حافظه دارد. در حالی‌که با استفاده از معماری بدون‌سرور و استقرار بر سکوی AWS Lambda این کار تنها در 4 دقیقه انجام شده و هزینه آن کمتر از 2.5 دلار در ساعت شده است.الگو‌های معماریالگو‌های معماری مجموعه‌ای از جواب‌هایی به مسائل عمومی (general) و تکرار شونده در حوزه معماری نرم‌افزار هستند. معماری بدون سرور به عنوان یک معماری نوظهور درگیر بسیاری از مسائل و مشکلات در سطح معماری نرم‌افزار است. بنابراین، خبرگان معماری نرم‌افزار اقدام به جمع‌آوری تعدادی از راه‌حل‌های بهینه برای حل مسائل معماری یک سامانه نرم‌افزاری، کرده‌اند.در [27، 28 و 29] تعدادی از الگو‌های معماری نرم‌افزار جمع‌آوری شده‌اند که آن‌ها را می‌توان در ۵ دسته کلی همنوا‌سازی و تجمیع (Orchestration and aggregation)، مدیریت رویداد (event management)، دسترس‌پذیری(Availability)، ارتباطات (Communication) و تعیین حق‌دسترسی (authorization) دسته‌بندی کرده‌ایم.الگو‌های همنواسازی و تجمیع: یکی از به‌روش‌های تولید نرم‌افزار‌ها با روش بدون‌سرور این است که توابعی که ایجاد می‌کنیم تنها یک کار را انجام دهند. از طرفی جریان‌های کاری درخواستی در برنامه‌های ما می‌توانند کارهای پیچیده‌ای انجام دهند. بنابراین، باید این توابع توانایی ترکیب و همنواسازی را داشته باشند تا بتوانیم یک جریان کاری پیچیده را به مجموعه ‌کارهای ساده‌ای تبدیل کنیم. برای این‌کار الگو‌هایی طراحی شده است که هدف آن‌‌ها ایجاد میکروسرویس‌ها است.الگوی Aggregator : گاهی اوقات می‌خواهیم با فراخوانی یک api تعدادی سرویس را به صورت همزمان یا غیرهمزمان فراخوانی کنیم. در این حالت توصیه می‌شود که از الگوی Aggregator استفاده کنیم. راه حل این است که یک سرویس به طور جداگانه اقدام به صدا زدن سرویس‌ها کند. در نهایت آن سرویس نتایج را جمع‌آوری کرده و ادغام کند و در معرض نمایش قرار دهد.شکل 9 الگوی aggregatorالگوی دریاچه داده (DataLake): گاهی اوقات باید پردازش‌های مختلفی برروی داده‌هایی که در اختیار داریم انجام دهیم. این پردازشات بعضا می‌توانند با یکدیگر درتناقض نیز باشند. همانگونه که در شکل 10 نیز مشاهده می‌شود، داده‌های خام در یک حافظه فیزیکی ذخیره شده و اگر بخواهیم پردازشی بر روی آن‌ها انجام دهیم، transformation این‌داده‌ها دیگر جایگزین‌ داده‌های جدید نخواهد شد.شکل 10الگوی datalakeالگوی fan-in/fan-out : کارها یا کارهای بزرگ به راحتی می‌توانند از محدودیت زمانی اجرا در توابع لامبدا تجاوز کنند. استفاده از استراتژی تقسیم و غلبه می‌تواند به کاهش این مشکل کمک کند.کار بین کارگران مختلف لامبدا تقسیم می شود. هر کارگر کار را به صورت ناهمزمان پردازش می‌کند و زیرمجموعه نتیجه خود را در یک مخزن مشترک ذخیره می‌کند. نتیجه نهایی را می‌توان با فرآیند دیگری جمع‌آوری و به هم متصل کرد. الگوی fan-in fanout در واقع دو الگو هستند که با هم استفاده می‌شوند. پیام‌های الگویFan-out به توابع تحویل داده می‌شود و هر کدام یک زیرکار تقسیم‌بندی شده از وظایف اصلی را دریافت می‌کنند. الگوی Fan-in نتیجه همه توابع را جمع آوری می‌کند، آن را جمع می کند، ذخیره می‌کند، و یک رویداد ارسال می‌کند که نشان می‌دهد کار انجام شده است.شکل 11 الگوی fan-in fan-outالگوی زنجیره توابع (function chain): همانطور که قبلا ذکر کرده‌ایم، یکی از مشکلات معماری بدون‌سرور این است که نمی‌توانیم توابع را به صورت طولانی مدت اجرا کنیم. بنابراین، یک راه‌حل شکستن یک تابع بسیار طولانی به توابع کوچک‌تر برای تقسیم‌کار و رعایت محدودیت سقف زمانی و پردازشی توابع در رایانش بدون‌سرور هستیم.شکل 12 الگوی زنجیره توابعالگوی پروکسی (Proxy): گاهی می‌خواهیم در توابع بدون‌سرور از برنامه‌ها و سرویس‌های قدیمی استفاده کنیم و داده‌هایی که برگردانده می‌شود، ممکن است طبق پروتکل‌ استانداردی نباشد یا اینکه پاسخ بسیار بیش از حد باشد. بنابراین همانگونه که در شکل ۱۳ دیده می‌شود، باید از یک سرویس میانی (middleware) استفاده‌کنیم که عمل ترجمه و فیلتر داده‌ها را برای ما انجام می‌دهد. بنابراین آن‌چه که در نتیجه خواهیم داشت یک API تمیز با دسترسی آسانتر برای مشتریانی است که می‌خواهند از یک یا چند سرویس قدیمی استفاده کنند.شکل 13 الگوی proxyالگوی The Frugal Consumer:‌ در سیستم‌های ما برخی سرویس‌ها کمتر مقیاس‌پذیر هستند. یعنی در معماری سعی می‌کنیم که که یک سرویس کمترین نمونه ممکن را داشته باشد، این درحالی رخ می‌دهد که مثلا سرویس‌های زیادی سعی بر فراخوانی آن تابع دارند. بنابرین در این حالت می‌تواند نمونه‌های بسیاری از آن سرویس ایجاد شود. راه‌حل این است که این سرویس‌ها درخواست‌های خود را برای یک تابع بفرستند و آن تابع درخواست‌ها را به ترتیب به صف پیام ارسال کند.شکل 14 الگوی the frugal consumerالگوی API قوی: بهتر است هر سرویسی که می‌خواهد توسط مشتری فراخوانی شود، از API Gateway عبور کند تا سرویس‌دهی با اطمینان ایجاد شود. البته این کار ممکن است پیچیدگی را افزایش دهد.شکل 15 الگوی Robust APIالگوی State Machine: معمولا معماری‌های بدون سرور نیاز به همنواسازی دارند. بدون شک AWS Step Functions بهترین راه برای مدیریت ارکستراسیون در برنامه‌های بدون سرور AWS است که از ماشین‌های حالت استفاده می‌کند. ماشین‌های حالت برای هماهنگ کردن چندین کار و حصول اطمینان از تکمیل صحیح آن‌ها با اجرای تلاش‌های مجدد و تایمرهای انتظار، عالی هستند. با این حال، استفاده از StepFunction محدودیت‌هایی دارد مثلا فراخوانی‌ها آسنکرون هستند، به این معنی که شما نمی‌توانید منتظر نتیجه یک تابع Step باشید و سپس به یک درخواست همزمان پاسخ دهید.الگوی Router: الگوی State Machine قدرتمند است زیرا ابزارهای ساده‌ای را برای مدیریت پیچیدگی، موازی سازی، مدیریت خطا و موارد دیگر در اختیار ما قرار می‌دهد. با این حال، استفاده از step functions رایگان نیست و اگر از آن برای همه چیز استفاده کنید، احتمالاً صورتحساب های هنگفتی دریافت خواهید کرد. برای همنواسازی‌های ساده‌تر که کمتر نگران انتقال حالت هستیم، می‌توانیم آنها را با استفاده از الگوی روتر مدیریت کنیم. برای این‌کار می‌توان تابعی ایجاد‌ کرد که وظیفه‌ی سیستم همنواساز برای فراخوانی توابع را در نظر گرفت.شکل 16 الگوی معماری routerالگوی Thick Client: این الگو بیان می‌کند که گاهی اضافه‌کردن لایه‌ها و سرویس‌هی مختلف برای پاسخ به درخواست مشتریان می‌تواند زمان پاسخ را به حد بسیاری افزایش دهد. بنابراین، یک راه می‌تواند این باشد که تا جای ممکن از اضافه کردن لایه‌ها و سرویس‌های مختلف پرهیز کنیم و اجازه دهیم کاربران مستقیما به سرویس‌ها دسترسی داشته باشند.شکل 17 الگوی Thick Clientالگو‌های مدیریت رویداد: در حوزه معماری بدون‌سرور، مشکلات بسیاری در حوزه ارتباطات بین توابع وجود دارد. این دسته از الگو‌های معماری سعی بر حل مشکلات ارتباطی بین توابع را دارند.الگوی تفکیک مسئولیت: گاهی اوقات یک تابع هم وظیفه خواندن داده‌ها را دارد و هم تغییر و ایجاد داده‌ها در پایگاه‌داده. این روش در معماری بدون‌سرور روش استانداردی نیست. بهتر است در معماری بدون سرور توابعی که وظیفه خواندن داده‌ها را دارند و توابعی که وظیفه نوشتن داده‌ها در پایگاه داده را دارند، در قالب یک تابع یا کانتینر بسته‌بندی نشوند. شکل 18 الگوی تفکیک مسئولیتالگوی Distributed Triggers : گاهی نیاز تابع فراخوانی کننده ممکن است چندین سرویس‌ را فراخوانی کند و هر کدام از این درخواست باید در صف‌هایی قرار بگیرند تا نوبت سرویس‌دهی به آن‌ها برسد. برای این کار بهتر است که صف‌های مختلفی برای فراخوانی هر سرویس به طور مجزا وجود داشته باشد.شکل 19الگوی Distributed Triggersالگوی internal hand-off: گاهی از فراخوانی (رویداد) برای یک رویداد ناهمزمان استفاده می‌کنیم. پس از اتمام اجرا، تابع به طور خودکار متوقف می‌شود و در صورت نیاز به طور خودکار دوباره تلاش می‌کند. گاهی نیز در عملکرد تابع خطاهایی به علت‌ نقص تابع وجود دارد که بهتر است این موارد بررسی شوند. در این حالت بهتر است لاگ‌های این چنینی برای صفی ارسال شوند تا failureهای برنامه جمع‌آوری و در صورت لزوم بررسی شوند.شکل 20 الگوی internal hand-offالگوی فراخواننده دوره‌ای (periodic invoker): گاهی برخی توابع باید به صورت دوره‌ای اجرا شوند. برای این کار بهتر است از سرویس‌های شخص ثالثی که از بیرون توابع را فراخوانی می‌کنند استفاده کنیم. ابزار Cloudwatch یا google scheduler‌ مثال‌های خوبی برای این‌کار هستند.الگو‌های دسترس‌پذیری: این گروه از الگوها به حل مشکلات در دسترس بودن، کاهش زمان گرم کردن و خرابی های احتمالی کمک می‌کند.الگوی bulkhead: گاهی خرابی یک تابع مهم ممکن است کل عملکرد برنامه را تحت تاثیر خود قرار دهد. برای حل چنین مشکلی بهتر است هنگامی که می‌خواهیم جریان‌های کاری خود را ایجاد کنیم، از poolهای مختلف استفاده کنیم تا بارهای کاری را به نحوی پارتیشن‌بندی کرده باشیم.شکل 21 الگوی معماری bulkheadالگوی Circuit Breaker:‌ گاهی درخواست‌هایی که برای برنامه‌ می‌آیند دچار خطا و شکست می‌شوند و پاسخی برای آن‌ها دریافت نمی‌شود. برای این‌کار باید ماژول یا سرویسی مسئول پی‌گیری درخواست‌های در شبکه باشند که اگر تعداد خطاها از تعداد معینی بیشتر شد، تمامی درخواست‌ها را بلاک ‌می‌کند و سپس به مرور زمان مدار را به حالت نیمه‌ باز برمی‌گرداند تا تنها تعدادی از درخواست‌‌ها را جواب دهد و اگر تمامی درخواست‌ها با موفقیت بازگردانده شد مدار را می‌بندد تا سیستم به سرویس‌دهی بارکاری گذشته خود برگردد.شکل 22 الگوی circuit breakerتوابع کامپایل شده: در رایانش ابری هرچقدر حجم تابع کمتر و تکنولوژی زبان تابع سریعتر باشد، تابع زودتر پاسخ داده می‌شود. بنابراین یک به‌روش در پیاده‌سازی معماری بدون‌سرور در سامانه‌هایی که نیاز به زمان پاسخ سریع دارد، استفاده از زبان‌ها و تکنولوژی‌هایی است که در آن توابع را باید کامپایل کنیم. نکته مهم این است که این توابع باید گرم بمانند زیرا در این صورت باید بعد از up کردن توابع مدت‌ زمانی را درگیر کامپایل توابع کنیم که از نظر شروع سرد اصلا به صرفه نیست.الگوی گرم‌کننده توابع (Function Warmer): گاهی اوقات به دلیل محدودیت‌هایی که داریم می‌خواهیم تابع دچار مشکل شروع سرد نشود. از آنجایی که هر تابع مدت‌ زمان اندکی پس از اجرا گرم می‌ماند و اگر فراخوانی نشد منابع آن گرفته ‌می‌شود، بنابراین باید به نحوی این مشکل را دور زد. یک راه حل قدیمی که به عنوان الگویی برای معماری سامانه‌های بدون‌سرور در آمده‌است، الگوی گرم‌کننده توابع است. این الگو اینگونه عمل می‌کند که تابعی به صورت دوره‌ای و در intervalای مشخص، اقدام به صدا زدن توابع می‌کند تا آن‌ها اصطلاحا سرد نشوند. ابزارهایی مانند Amazon Cloudwatch چنین امکانی در اختیار کاربران قرار می‌دهند. البته این راه‌کار از نظر هزینه اصلا بهینه نیست و در معماری سامانه‌های بدون‌سرور به هیچ‌عنوان یک به‌روش محسوب نمی‌شود.شکل 23 الگوی function warmerتوابع بزرگ (oversized function): در رایانش بدون سرور، امکان انتخاب نوع و تعداد cpu و حافظه به طور مجزا را نداریم. طبق قاعده‌ای کلی تعداد cpuها به ازای ۲ برابر شدن حافظه بزرگتر می‌شوند. بنابراین حین درخواست تابعی که مثلا cpu زیادی تب می‌کند، باید حافظه‌ را بزرگ درنظر گرفت حتی اگر این میزان از حافظه نیاز نباشد.الگوی Read-heavy report engine: گاهی اوقات داده‌هایی که باید خوانده شوند که یا درخواست‌های خواندن زیادی برای آن‌ها وجود دارد یا پاسخ‌دادن به آن بسیار سنگین و زمانبر است. بنابراین همچون معماری‌هایی مانند میکروسرویس، بهتر است از یک حافظه کش برای پاسخ‌ دادن به درخواست‌ها استفاده کنیم. این کار باعث افزایش بهره‌وری و کاهش زمان‌پاسخ نیز می‌شود.شکل 24 الگوی Read-Heavy Report Engineالگوی timeout: گاهی مدت‌ زمان بالای timeout برای یک سرویسی که قرار نیست پاسخی به ما بدهد، تجربه بدی برای کاربر خواهد بود. بهتر است معماری سیستم به‌ گونه‌ای باشد که پاسخ درخواست‌ها کمتر از ۲-۳ ثانیه طول بکشد. اگر سرویس چنین مهمی را رعایت کند، زمان timeoutای حدود ۳۰ ثانیه برای یک سرویس gateway کاملا بی‌معنی است. یعنی علاوه‌ بر اینکه کاربر باید مدت ‌زمان بسیاری را متنظر بماند، درنهایت پاسخ خود را دریافت نخواهد کرد. بنابراین باید timeout سرویس‌های مختلف به صورت متناسب انتخاب شود.الگو‌های ارتباطی: این الگو‌ها، الگو‌های معماری برای ارتباط بین توابع هستند.الگوی جریان‌ها و خط‌ لوله‌ها: یکی از ویژگی‌های مهمی که اغلب می‌بینیم، پردازش جریان‌های داده است، به همان سرعتی که داده‌ها تولید می‌شوند و به سرعت مقیاس می‌شوند تا تقاضای حجم زیادی از رویدادها را برآورده کنند. سرویس‌های پایین دست جریان را دریافت می‌کنند و منطق تجاری را برای تبدیل، تجزیه و تحلیل یا توزیع داده‌ها اعمال می‌کنند. نمونه‌های متداول، ثبت رفتار کاربر مانند جریان‌های کلیک و تعاملات رابط کاربری است. مواردی از استفاده شامل داده‌ها برای تجزیه و تحلیل داده‌های حسگرهای اینترنت اشیا و غیره است. سرویس Kinesis Analytics داده‌های جستجوی سریع را در جریان در زمان واقعی ارائه می‌دهد. با ادغام S3 تمام داده‌ها برای تجزیه و تحلیل آینده و بینش واقعی ذخیره می‌شوند. آتنا برای تمام داده‌های تاریخی پرس و جو فراهم می‌کند. در واقع پردازش چنین جریاناتی با استفاده از ابزار‌هایی انجام می‌گیرد که ارائه‌دهنده در اختیار کاربران قرار داده است که در اینجا ما از سرویس AWS Lambda برای پردازش جریانات داده‌ای استفاده کرده‌ایم. همه ارائه دهندگان ابر برای خطوط لوله داده، پردازش جریان، و تجزیه و تحلیل پیشنهاداتی دارند، اما ممکن است به خوبی با خدماتی که بخشی از اکوسیستم آنها نیستند، ادغام شوند. این راه‌کار اگرچه مناسب است اما خطر vendor lock-in را هم دارد.حالت خارجی (External State):‌ گاهی اوقات چند تابع در حال اجرا نیاز دارند که وضعیت خود را با دیگر توابع به اشتراک بگذارند. راه‌حل این است که پایگاه‌داده واسطه‌ای وجود داشته باشد تا مسئول این باشد تا ارتباط توابع از طریق ثبت و خواندن وضعیت توابع در آن اتفاق بیافتد.شکل 25 الگوی حالت خارجیالگوی pub/sub: گاهی می‌خواهیم برای سرویس‌های داخلی که در سامانه‌ خود داریم، اعلان‌هایی را ارسال کنیم. راه‌حل بهینه این است که در صف ارسال پیام یک topic ویژه ایجاد کنیم که مخصوص این‌کار است و در آن صف گیرنده‌های مجاز مشخص شده باشد. این topic بهتر است که مجزا و ایزوله از بقیه topicها باشد. این کار برای سیستم‌هایی است که از معماری رویداد-محور استفاده می‌کنند. این تاپیک‌ها قابلیت ایجاد در سرویس‌هایی مانند kenesis، kafka یا Google's Cloud Pub/Sub را دارد.الگو‌های تعیین حق‌دسترسی (Authorization):الگوی دروازه‌بان (the GateKeeper): گاهی سرویس‌ها سرویس‌هایی را فراخوانی می‌کنند که حق دسترسی به آن‌ها را ندارند. بهتر است در مسیر فراخوانی سرویس‌ها یک سرویس GateKeeper‌ پیاده‌سازی شود که وظیفه‌ آن بررسی header‌ درخواست‌ها و رد یا پذیرش آن‌ها براساس سیاست‌های تعیین حق دسترسی است باشد.شکل 26 الگوی تعیین حق دسترسیمثال‌هایی از استفاده از معماری بدون سرورپژو‌هش‌های بسیاری حول استفاده از معماری بدون‌سرور در سامانه‌های ابری انجام گرفته است. در [30] نویسندگان مقاله سعی کرده‌اند تا یک وب‌اپلیکیشن یکپارچه برای رمزگذاری و رمزگشایی پیام‌ها را تحت معماری بدون‌سرور پیاده‌سازی کنند. این برنامه دو بخش به نام createDocument‌ و ReadDocument دارد.شکل 27 متد createDocumentدر شکل ۲۷ متد createDocument نشان داده شده‌است. برطبق این متد، در ابتدا متن وارد شده، سپس الگوریتم رمزنگاری داده‌ها مشخص شده و یک عبارت به عنوان کلید رمزنگاری مشخص می‌شود. پس از مشخص‌ شدن این موارد، سند باید فشرده شود، سپس رمزگذاری شود و در قالب یک URL دربیاید. در مرحله آخر نیز این فایل URL در حافظه کپی شود.شکل 28متد ReadDocumentشکل ۲۸، شیوه خواندن URL و رمزگشایی را نشان می‌دهد. پس از وارد کردن یک URL معتبر، صفحه‌ای می‌آید تا عبارت کلید رمزگشایی را وارد کنیم. سپس در صورت معتبربودن کلید، عبارت رمزگشایی و پس از آن Decompress می‌شود. در مرحله‌نهایی یک عبارت رمزگشایی شده به رندر گرفته می‌شود و به کاربر نشان داده می‌شود.شکل 29 رمزنگاری متنشکل 30تصویری از متن رمزگشایی شدهدر [31] نویسندگان اقدام به توسعه‌ چت‌بات با پشتیبانی از صدا با معماری بدون‌سرور کرده‌اند. این سیستم از APIهای IBM Watson برای هماهنگی و انجام کارهای محول‌شده استفاده می‌کند. کارهایی که این سیستم پشتیبانی می‌کند، عبارتند از تعریف لطیفه و جوک، وضعیت آب‌وهوای شهر‌ها، آموزش موسیقی و یادآوری تاریخ‌ها و مناسبت‌ها است. دلایل مهاجرت توسعه‌دهندگان این سامانه به معماری بدون سرور، مقیاس‌پذیری خودکار و دسترس‌پذیری بالای سامانه‌های ابری بوده و از سکوی Apache Openwhisk برای میزبانی برنامه‌ خود استفاده کرده‌اند. شکل ۳۱ بخش‌های مختلف این برنامه را نمایش می‌دهد.شکل 31 سرویس‌های مختلف برنامه chatbotطبق شکل ۳۱، این برنامه از سرویس‌های زیر تشکیل شده است:سرویس Audio I/O‌: این سرویس مسئول تبدیل صدا به متن و بالعکس است و یکی از APIهای سرویس IBM Watson است.سرویس Text I/O: این سرویس مسئول این است تا موضوع اصلی دیالوگی که برقرار شده است را پیدا کند و آن را در یکی از دسته‌بندی‌های موجود قرار دهد.سرویس Speech-to-Action: این سرویس از Watson Alchemy استفاده می‌کند تا سرویس مربوطه را فراخوانی کند.سرویس Abilities: این سرویس با استفاده از پارامتر‌هایی که در بخش Speech-to-Action مشخص شده، توابعی در محدوده توانایی‌های خودش فراخوانی می‌کند.سرویس‌های شخص ثالث: سرویس‌هایی هستند که عملیات مورد نظر از آن‌ها درخواست می‌شود.برای مثال، اگر بخواهیم یک سرویس اعلام دمای آب و هوا از روی صدا را مورد مطالعه قرار دهیم، جریان کاری آن به شکل ۳۲ می‌شود.شکل 32 جریان کاری یک سرویس دریافت آب و هوادر ابتدا با استفاده از API‌ سرویس Watson Stt صوت تبدیل به متن می‌شود. در مرحله بعدی دسته‌بندی دیالوگ از روی الگو‌های دیالوگ مشخص می‌شود. حال که مشخص شد سرویس از نوع درخواست آب و هوا بر اساس نام شهر است؛ باید ابتدا نام ‌شهر استخراج شود. سپس با استفاده از API سرویس آب‌وهوا موقعیت lat & lon شهر استخراج شود و از روی مختصات جغرافیایی گزارش آب و هوا استخراج شود. در نهایت سرویس TTS این گزارش را به صوت تبدیل می‌کند و برای کاربر می‌خواند.یکی دیگر از کارهایی که در حوزه معماری بدون‌سرور انجام گرفته است، معماری بدون‌سرور در بستر یک سیستم اینترنت اشیا است. از نظر نویسندگان مقاله [32] یک معماری خوب باید قابل اطمینان باشد، محاسبات ایمن داشته باشد، مزیت رقابتی‌ برنامه و کسب‌وکار را بتواند به راحتی پیاده‌سازی کند و امنیت را در ابعاد گوناگون معماری سامانه پیاده‌سازی کند. امنیت در سامانه‌های اینترنت اشیا شامل امنیت در برابر هک سامانه و مکانیزم‌هایی برای مقابله با آسیب‌پذیری‌ها و یا بازیابی سیستم پس از خطا‌های عامل انسانی است. معماری پیشنهادی [32] سامانه‌ای متشکل از ۳ لایه فیزیکی، لبه/مه و ابری است. معماری سامانه در شکل ۳۳ مشخص شده است.شکل 33 معماری سامانه اینترنت اشیا بدون سروربلوک‌های بلاک‌چین می‌تواند در نود‌های مختلف میزبان در لایه‌های ابری یا مه قرار داشته باشد. بلاک‌چین در اینجا دیتابیس‌های غیرقابل تغییر درنظر گرفته‌شده‌اند. داده‌های بلاک‌چین نیز قابلیت orchestrate شدن حین کم و زیاد شدن ماشین‌های مجازی را دارند.کار دیگری که در حوزه معماری بدون‌سرور در اینترنت اشیا صورت گرفته مدل CSPOT [33] است که هدف آن ارائه مدلی ایمن و سریع است که با سیستم AWS Lambda IOT قابلیت رقابت داشته باشد. از نظر نویسندگان مقاله به دلیل ماهیت فراخوانی براساس رخداد‌ها، اینترنت اشیا و معماری بدون‌سرور بریکدیگر منطبق هستند. بلوک‌های پایه‌ای در CSPOT اشیا حافظه‌داری به نام WOOF است که حالت‌های برنامه را در خودنگه می‌دارند. با فراخوانی رویداد‌ها یک شئی WOOF برای هر تابع ساخته و اطلاعات وضعیت برنامه در آن نگه‌داری می‌شود. توسعه‌دهندگان CSPOT آن را برروی کانتنر‌های داکر و سیستم همنواساز Docker Swarm ایجاد کرده‌اند. سپس آن را در یک سناریو ارزیابی دمای گلخانه‌های کشاورزی توسط نودهایی که برروی رزبری‌پای پیاده‌سازی کرده‌اند، بررسی می‌کنند. در جدول ۳ مقایسه زمان‌پاسخ AWS Lambda IOT با CSPOT ذکر شده است.جدول 3 مقایسه CSPOT با AWS Lambda IOTدر [35] محققین اقدام به پیاده‌‌سازی برنامه‌های پردازش ویدیو‌ در معماری بدون‌سرور کرده‌اند. معماران این سیستم با استفاده از الگوی pipe and filter اقدام به پیاده‌سازی ۲ جریان‌کاری برای این برنامه کرده‌اند. جریان کاری اول، اعمال فیلتر‌های تصویری مختلف بر ویدیو است که جریان‌کاری آن در شکل ۳۴ نمایش داده شده است.شکل 34 جریان‌کاری در اعمال فیلتر تصویری بر ویدیو‌هادر این جریان ویدیو‌ها در ابتدا decodeمی‌شوند، سپس فیلتر مربوطه بر آن‌ها اعمال شده و سپس encode‌ می‌شوند. در نهایت، خروجی با فرمت دلخواه داده ‌می‌شود. جریان کاری دیگر هنگامی‌ است که بخواهیم در یک فیلم به دنبال سکانس‌هایی باشیم که فرد خاصی در آن حضور دارد (مثلا سکانس‌هایی که در یک فیلم از حیاط مدرسه که کودک مشخصی در آن حاضر است). جریان‌کاری این برنامه در شکل ۳۵ نمایش داده شده است.شکل 35 جریان‌کاری تشخیص صورت در ویدیو‌هاهمانطور که شکل ۳۵ نشان می‌دهد، برای ساخت یک ویدیو جدید در یک جریان کاری مجزا، نام فرد وارد می‌شود و تصویر مدنظر را انتخاب می‌کنیم. سپس در ویدیو‌ مجزایی فایل ویدیویی decodeشده، scene صحنه از بین صحنه‌های موجود تغییر داده می‌شود تا بهترین وضعیت شناسایی فرد صورت گیرد؛ سپس، صورت شناسایی می‌شود و بر روی فیلم علايمی جهت شناسایی فرد کشیده می‌شود. در نهایت فایل ویدیویی encode شده و به فرمت دلخواه در‌می‌آید. این برنامه قابلیت‌های دیگری مانند Streaming را نیز در اختیار کاربران گذاشته‌است.در [36] یک معماری برای data lake که در توصیف داده‌های بزرگ کاربرد دارد ارائه شده‌است. چالش این معماری این است که داده‌ها حجم عظیمی دارند و مدیریت این میزان از داده‌ها بسیار چالش برانگیز است. در این معماری سعی شده‌ است که ذخیره‌سازی و پردازش داده‌ها با هم به کار برده شود. معمای این برنامه در شکل ۳۶ نشان داده ‌شده است.شکل 36 معماری پیشنهادی برای آنالیز‌داده‌های حجیم در معماری بدون‌سرور دریاچه داده (Data Lake) چیست؟ دریاچه‌داده یک مخزن است که در آن ما شروع به آوردن کل داده های سازمانی در یک مکان مرکزی می کنیم. این امر حیاتی است زیرا کسب‌وکارها یا سازمان‌ها با انواع مختلفی از داده‌ها سروکار دارند که هم داخلی و هم خارجی را شامل می‌شود. علاوه بر این، داده ها می توانند در قالب های متعددی باشند.در طراحی دریاچه‌داده ۴ لایه در نظر گرفته شده است:1. منطقه خام: برای آوردن داده ها چگونه می توانیم داده‌ها را از منابع خارجی مختلف به ساختار یا سیستم خود بیاوریم و ذخیره کنیم؟ چگونه می توانیم داده های ارتباطی یا رسانه های اجتماعی را بیاوریم؟ چگونه می توانیم داده های مشتری خود را بیاوریم؟ اولین قدم ما آوردن و ذخیره داده ها از همه منابع خارجی است.2. منطقه انتخاب شده: برای استانداردسازی داده‌ها چگونه می توانیم داده‌ها را مدیریت کنیم؟ همانطور که داده‌هایی که ما آورده‌ایم از منابع مختلف است و به همین دلیل است که وجود آن در قالب‌های مختلف آشکار است.3. منطقه اکتشافی: برای کاوش الگوهای داده های پنهان چیزهای ناشناخته زیادی در داده‌ها وجود دارد. به عنوان مثال، چگونه یک پلت فرم رسانه‌های اجتماعی، توییتر بر قیمت سهام تأثیر می‌گذارد. در لایه سوم دریاچه داده، ما در تلاشیم تا به چیزهای پنهان موجود در داده‌ها پی ببریم.4. منطقه تامین: برای تولید داده‌ها لایه چهارم دریاچه داده در حال تولید است. اکنون، ما برنامه های تجاری یا شرکتی خود را اجرا می‌کنیم. همچنین به عنوان منطقه تامین کننده شناخته می شود که داده‌هایی را برای توانمندسازی برنامه‌های تجاری ارائه می‌دهد.همانگونه که در شکل ۳۶ نشان داده شده است، معماری این سیستم کاملا وابسته به سکوی AWS Lambda است و از سرویس‌های آن استفاده می‌کند. در لایه اول، مسئله این است که چگونه می‌توانیم به منابع خارجی مختلف متصل شویم تا داده‌های کامل را به منطقه خام بیاوریم. در مرحله دوم، با استفاده از خدمات Glue، داده‌های خام را به داده‌های انتخاب شده تغییر دادیم. مرحله سوم ارتقای داده‌ها برای کشف است. در اینجا، کشف به این معنی است که ما نگاهی دقیق به داده‌های انتخاب شده می‌کنیم و برای اینکار از سرویس Amazon SeigeMaker استفاده شده است. در نهایت، در منطقه ارائه، از طیف آمازون آتنا استفاده می‌کنیم. هر دوی این سرویس ها دارای قابلیت ذخیره‌سازی داده هستند. با استفاده از این خدمات، می‌توان جداول فرآیند را برای تقویت برنامه‌های تجاری خود ساخت.در [37] کاری مشابه [26] انجام شده است که در آن از FaaS و معماری بدو‌ن‌سرور برای تبدیل سند‌های متنی استفاده شده است. معماری این سیستم این بار بر پایه AWS Lambda است و این بار از سرویس‌های پایه‌ای آن استفاده می‌کند.شکل 37 معماری سیستم تبدیل تصویر به نوشتهمزیت این معماری نسبت به معماری‌های قبلی در هزینه به ازای درخواست و سرعت بالاتر اجرای درخواست‌هاست. تا جایی که در شکل ۳۸ نیز این محاسبه به خوبی انجام شده است.شکل 38 مقایسه هزینهیکی دیگر از کار‌های انجام شده به کمک محاسبات بدون سرور، ایجاد توابع شبکه (NF) به عنوان یک سرویس (NFaaS) است [38]. امروزه با کمک تکنیک مجازی سازی می‌توانیم از توابع شبکه استفاده کنیم ولی حجم بار کاری این مجازی سازی، هزینه‌ها، مقیاس پذیری و برنامه نویسی برای توابع برای ما چالش برانگیز است و با کمک محاسبات بدون سرور مجموعه‌ایی کلیدی از بلوک‌ها برای رسیدگی به این مسائل NFV فراهم می‌شود.ایده این مقاله بدین صورت است که تخصیص کارها و بحث‌های برنامه نویسی برای بسته‌هایی که از طریق جریان‌های مختلف به ما میرسد را از هم جدا کنیم. یعنی ما رسیدن یک جریان را به عنوان یک رویداد تلقی کنیم و سپس براساس نیاز آن جریان را به تابع مناسب هدایت کنیم.ایده دومی که این مقاله بررسی کرده است، بحث تاخیر و زمان پردازش بسته‌هاست و با اینکه در این حوزه کارهای زیادی صورت گرفته ولی ما همچنان شاهد ایجاد صف انتظار در پردازش بسته‌ها هستیم. این چالش به کمک مفهوم شروع گرم محاسبات بدون سرور تا حد زیادی پوشش داده شده است به طوری که زمان از سرگیری پردازش بسته‌ها نسبت به قبل تا حد قابل توجهی کم شده است.در معماری پلتفرم NFaaS بدون سرور SNF ما دو جز اصلی داریم: 1- کنترل کننده، 2-زمان اجرا NFهادر کنترل کننده ما 3 جز مجزا داریم:1- جداسازی و دانه بندی بسته‌ها و بار‌های کاری دریافت شده(WG) 2- تخصیص بسته‌ها به توابع مناسب(WA) 3 - مدیریت حالت بسته‌ها (SM).همانطور که میدانیم در Faas ما نیاز به توابع بدون حالت داشتیم و هدف از استفاده از SM این است که ما بتوانیم توابع بدون حالت را در معماری بدون سرور پیاده سازی کنیم در صورتی که برای انجام پردازش به حالت‌های آن نیاز داریم و SM این حالت‌ها را برای ما مدیریت می‌کند و این کار را به کمک یک سری حافظه و remote control انجام می‌دهد تا در صورت نیاز به آن مراجعه شود.زمان اجرا NFها وظیفه‌ی مدیریت حالت هر واحد محاسباتی را برعهده دارد.لازم به ذکر است ایده‌ایی که در این مقاله مطرح شده است توسط ارائه دهنده‌های کمی پشتیبانی شده و محدودیت‌های خیلی زیادی برای استفاده از آن اعمال شده است.جمع‌بندی و نتیجه‌گیریدر این پژوهش سعی کرده‌ایم تا هر آنچه‌ که یک معماری نرم‌افزار برای مهاجرت به معماری ابری نیاز دارد را جمع آوری کرده تا بتواند تصمیم بهتری برای مهاجرت به معماری بدون‌سرور داشته باشد. مواردی که در این گزارش ذکر شد شامل مفاهیم رایانش‌ بدون‌سرور، FaaS، BaaS، ارائه‌دهندگان خدمات بدون‌سرور، سکو‌های بدون سرور، مقایسه‌ بین آن‌ها از جنبه‌های مختف، الگو‌های معماری سامانه‌های بدون سرور و مثال‌هایی برای مهاجرت به معماری بدون‌سرور بوده است.متاسفانه معماری بدون‌سرور آن‌چنان که شایسته است در کشور ما جا نیافتاده است. البته این موضوع می‌تواند دلایل مختلفی از جمله تازگی این مبحث و تحریم‌ تمامی ارائه‌دهندگان خدمات ابری علیه ایرانیان باشد. در پژوهش‌های آتی در این حوزه قصد داریم به راه‌های کاهش شروع سرد در معماری‌های بدون‌سرور بپردازیم و مثال‌هایی از مهاجرت به معماری بدون سرور را ارائه‌دهیم.مراجع و منابع[1] Roberts, M. (2016). Serverless architectures. https://martinfowler. com/articles/serverless.html, 4.[2] Shafiei, H., Khonsari, A., & Mousavi, P. (2019). Serverless computing: A survey of opportunities, challenges and applications. arXiv preprint arXiv:1911.01296.[3] Hassan, H. B., Barakat, S. A., & Sarhan, Q. I. (2021). Survey on serverless computing. Journal of Cloud Computing, 10(1), 1-29.[4] van Eyk, E., & Iosup, A. (2018). Addressing performance challenges in serverless computing. In Proc. ICT. OPEN.[5] Gadepalli, P. K., Peach, G., Cherkasova, L., Aitken, R., & Parmer, G. (2019, October). Challenges and opportunities for efficient serverless computing at the edge. In 2019 38th Symposium on Reliable Distributed Systems (SRDS) (pp. 261-2615). IEEE.[6] Shafiei, H., Khonsari, A., & Mousavi, P. (2019). Serverless computing: A survey of opportunities, challenges and applications. arXiv preprint arXiv:1911.01296.[7] Manco, F., Lupu, C., Schmidt, F., Mendes, J., Kuenzer, S., Sati, S., ... & Huici, F. (2017, October). My VM is Lighter (and Safer) than your Container. In Proceedings of the 26th Symposium on Operating Systems Principles (pp. 218-233).[8] Jambunathan, B., & Yoganathan, K. (2018, March). Architecture decision on using microservices or serverless functions with containers. In 2018 International Conference on Current Trends towards Converging Technologies (ICCTCT) (pp. 1-7). IEEE.[9] https://aws.amazon.com/lambda/[10] https://cloud.google.com/functions[11] https://azure.microsoft.com/en-us/services/functions/[12] https://www.oracle.com/cloud-native/functions/[13] https://developers.cloudflare.com/pages/platform/functions[14] https://cloud.ibm.com/functions/[15] Hendrickson, S., Sturdevant, S., Harter, T., Venkataramani, V., Arpaci-Dusseau, A. C., & Arpaci-Dusseau, R. H. (2016). Serverless computation with openlambda. In 8th {USENIX} Workshop on Hot Topics in Cloud Computing (HotCloud 16).[16] Pfandzelter, T., & Bermbach, D. (2020, April). tinyfaas: A lightweight faas platform for edge environments. In 2020 IEEE International Conference on Fog Computing (ICFC) (pp. 17-24). IEEE.[17] Carreira, J., Fonseca, P., Tumanov, A., Zhang, A., & Katz, R. (2019, November). Cirrus: A serverless framework for end-to-end ml workflows. In Proceedings of the ACM Symposium on Cloud Computing (pp. 13-24).[18] Daw, N., Bellur, U., & Kulkarni, P. (2020, December). Xanadu: Mitigating cascading cold starts in serverless function chain deployments. In Proceedings of the 21st International Middleware Conference (pp. 356-370).[19] Ghaemi, S., Khazaei, H., & Musilek, P. (2020). ChainFaaS: An open blockchain-based serverless platform. IEEE Access, 8, 131760-131778.[20] Maissen, P., Felber, P., Kropf, P., & Schiavoni, V. (2020, July). Faasdom: A benchmark suite for serverless computing. In Proceedings of the 14th ACM International Conference on Distributed and Event-based Systems (pp. 73-84).[21] Martins, H., Araujo, F., & da Cunha, P. R. (2020). Benchmarking serverless computing platforms. Journal of Grid Computing, 18(4), 691-709.[22] https://claudiajs.com/[23] Zhang, W., Fang, V., Panda, A., & Shenker, S. (2020, October). Kappa: A programming framework for serverless computing. In Proceedings of the 11th ACM Symposium on Cloud Computing (pp. 328-343).[24] Tankov, V., Golubev, Y., & Bryksin, T. (2019, November). Kotless: A serverless framework for kotlin. In 2019 34th IEEE/ACM International Conference on Automated Software Engineering (ASE) (pp. 1110-1113). IEEE.[25] Manner, J., Kolb, S., & Wirtz, G. (2019). Troubleshooting serverless functions: a combined monitoring and debugging approach. SICS Software-Intensive Cyber-Physical Systems, 34(2), 99-104.[26] Goli, A., Hajihassani, O., Khazaei, H., Ardakanian, O., Rashidi, M., & Dauphinee, T. (2020, April). Migrating from monolithic to serverless: A fintech case study. In Companion of the ACM/SPEC International Conference on Performance Engineering (pp. 20-25).[27] https://medium.com/@taibi.davide/serverless-patterns-e1fb3f1d753e[28] https://www.infoq.com/articles/design-patterns-for-serverless-systems/[29] https://medium.com/@eduardoromero/serverless-architectural-patterns-261d8743020[30] Prasetyadi, G., Hantoro, U. T., Mutiara, A. B., Muslim, A., & Refianti, R. (2019, October). Heresy: A serverless web application to store compressed and encrypted document in the form of url. In 2019 Fourth International Conference on Informatics and Computing (ICIC) (pp. 1-5). IEEE.[31] Yan, M., Castro, P., Cheng, P., & Ishakian, V. (2016, December). Building a chatbot with serverless computing. In Proceedings of the 1st International Workshop on Mashups of Things and APIs (pp. 1-4).[32] Benedict, S. (2020). Serverless blockchain-enabled architecture for iot societal applications. IEEE Transactions on Computational Social Systems, 7(5), 1146-1158.[33] Wolski, R., Krintz, C., Bakir, F., George, G., & Lin, W. T. (2019, November). Cspot: Portable, multi-scale functions-as-a-service for iot. In Proceedings of the 4th ACM/IEEE Symposium on Edge Computing (pp. 236-249).[35] Ao, L., Izhikevich, L., Voelker, G. M., & Porter, G. (2018, October). Sprocket: A serverless video processing framework. In Proceedings of the ACM Symposium on Cloud Computing (pp. 263-274).[36] Rahman, M. M., & Hasan, M. H. (2019, October). Serverless architecture for big data analytics. In 2019 Global Conference for Advancement in Technology (GCAT) (pp. 1-5). IEEE.[37] Chahal, D., Ojha, R., Ramesh, M., & Singhal, R. (2020, October). Migrating large deep learning models to serverless architecture. In 2020 IEEE International Symposium on Software Reliability Engineering Workshops (ISSREW) (pp. 111-116). IEEE.[38] Singhvi, A., Khalid, J., Akella, A., & Banerjee, S. (2020, October). Snf: Serverless network functions. In Proceedings of the 11th ACM Symposium on Cloud Computing (pp. 296-310).«این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است» Amirmohammad Amirmohammad Sat, 12 Feb 2022 02:21:41 +0330 https://virgool.io/@amir-mohammad/%D8%A2%D8%B4%D9%86%D8%A7%DB%8C%DB%8C-%D8%A8%D8%A7-%D9%85%D8%AF%DB%8C%D8%B1%DB%8C%D8%AA-%D9%84%D8%A7%DA%AF-d5o0nyhb2t3j چه یک توسعه دهنده یا یک مهندس DevOps باشید، دیر یا زود باید گزارش‌هایی که کدتان تولید می‌کند و معمولاً در سرورهای مختلف توزیع شده‌اند را، بررسی کنید. چیزی که وضعیت را پیچیده می کند این است که وقتی حجم داده ها شروع به رشد می کند، مدیریت و نگهداری محیط می تواند بسیار بیشتر از آنچه شما می‌خواهید طول بکشد. علاوه بر این، جریان‌های داده بزرگ‌تر منجر به بینش تاخیری در مورد وضعیت پروژه شما می‌شود. در این مرحله، یک سؤال مطرح می شود: چه کاری می توانم انجام دهم تا همه چیز را کنترل کنم؟ در این مقاله، می‌خواهیم به بررسی ابزارهایی بپردازیم که مدیریت این وضعیت پیچیده را برای ما ساده‌تر می‌کنند. مدیریت لاگ چیست؟ مدیریت گزارش (Log Management) فرآیند مدیریت رویدادهای گزارش است که توسط همه برنامه‌های نرم‌افزاری و زیرساخت‌هایی که روی آن اجرا می‌شوند تولید می‌شوند. این شامل جمع‌آوری گزارش، تجمیع، تجزیه، ذخیره‌سازی، تجزیه و تحلیل، جستجو و بایگانی است، هدف مدیریت لاگ‌ها استفاده از داده‌ها برای عیب‌یابی و به‌دست آوردن بینش‌های تجاری، و در عین حال تضمین انطباق و امنیت برنامه‌ها و زیرساخت‌ها. گزارش‌ها معمولاً در یک یا چند فایل گزارش ثبت می‌شوند. مدیریت گزارش به شما این امکان را می‌دهد که داده‌ها را در یک مکان جمع‌آوری کنید و به‌جای موجودیت‌های جداگانه به آن‌ها به عنوان بخشی از یک کل نگاه کنید. به این ترتیب، می‌توانید داده‌های گزارش جمع‌آوری‌شده را تجزیه و تحلیل کنید، مسائل و الگوها را شناسایی کنید تا بتوانید تصویر واضح و بصری از عملکرد همه سیستم‌های خود در هر لحظه ارائه دهید. ورود به سیستم به بخشی جدایی ناپذیر از هر تیم DevOps تبدیل شده است.آیا لاگ‌گرفتن از سیستم‌ها اهمیت دارند؟ ۱۰۰ درصد! مدیریت لاگ در مورد سلامت و انطباق سیستم ها و برنامه های شما دید کلی ارائه می‌دهد. بدون آن، به امید یافتن منابع مشکلات عملکرد، اشکالات، رفتار غیرمنتظره و سایر مسائل مشابه، در تاریکی دست و پا می‌زدید. هنگام تلاش برای عیب‌یابی مشکلات تولید، مجبور خواهید بود چندین فایل گزارش را به صورت دستی بازرسی کنید. این به طرز دردناکی کند، مستعد خطا، گران است و مقیاس‌پذیر نیست. مدیریت لاگ به دلیل ماهیت پویا و توزیع شده آنها برای اپلیکیشن‌هایی که در ابر مستقر شده‌اند، مهم است. بر خلاف برنامه‌های کاربردی سنتی، برنامه‌های Cloud Native اغلب در کانتینرها اجرا می‌شوند و به‌جای نوشتن گزارش‌ها در فایل‌های گزارش، گزارش‌ها را به خروجی استاندارد منتشر می‌کنند. این به این معنی است که شما "گزینه پیش فرض" ثبت دستی گزارش ها را ندارید. به طور معمول، شما لاگ ها را ضبط می کنید و آنها را به یک پایگاه متمرکز مدیریت گزارش ارسال می کنید. به طور خلاصه، مدیریت لاگ به اپراتورهای برنامه و زیرساخت (توسعه دهندگان، DevOps، SysAdmins و غیره) امکان عیب‌یابی مشکلات را می‌دهد و به سهامداران تجاری (مدیران محصول، بازاریابی، BizOps و غیره) اجازه می دهد تا راحتتر محصول و مشکلات و نیازمندی‌های آن محصول را درک کنند. از خلال این گزارش‌ها حتی می‌توان تهدیدات موفق و ناموفق مانند ورود‌های ناموفق و موفق به سیستم، نشت اطلاعات و ... را به راحت‌تر متوجه شد.لاگ گیری چه مزایایی دارد؟‌مانیتورینگ و عیب‌یابی آسان‌تر:‌ رایج‌ترین و اصلی‌ترین مورد استفاده مدیریت لاگ، عیب‌یابی نرم‌افزار و زیرساخت است. رویدادهای گزارش با نظارت برنامه و نظارت سرور به دست می‌آیند. توسعه‌دهندگان، DevOps، SysAdmins و SecOps از این معیارها و گزارش‌ها استفاده می‌کنند تا در مورد عملکرد برنامه‌ها و زیرساخت‌ها و مشکلات امنیتی اطلاعات به‌دست بیاورند، علت مشکلات را بیابند و معیار‌های کیفی برنامه را بهینه کنند. داشتن ابزارهای مدیریت لاگ خوب به کاهش MTTR (Mean Time To Recovery) کمک می کند. خرابی های طولانی مدت یا حتی برنامه ها و زیرساخت هایی که عملکرد ضعیفی دارند نیز می توانند باعث خسارت‌های مالی و ازدست رفتن اعتماد مشتریان به سیستم‌ شوند. بنابراین، نرم‌افزار مدیریت لاگ نقش مهمی در کاهش MTTR ایفا می‌کند. با این حال، گزارش‌ها ارزشی فراتر از عیب‌یابی ارائه می‌کنند. اصطلاحا گفته می‌شود ابرداده‌ها یکی از نتایج مدیریت و ساختاربندی مناسب سیستم لاگینگ است. با تحلیل این داده‌ها می‌توانیم مثلا بفهمیم روی چه بخش‌ها یا جنبه‌های تجاری سرمایه‌گذاری کنیم زیرا مثلا در فروشگاه اینترنتی ما مشتریان به کررات محصولی را جستجو کرده‌اند که اصلا در حوزه کاری ما نیست پس آیا با موجود کردن محصول سود سرشاری حاصل می‌شود؟ برخی سوالات و نتایج کمک می‌کنند که حتی معماری سیستمرا نیز ارزیابی کنیم. اگر ارتباط با بخش مدیریت لاگ به خوبی پیش برود، سیستمی پایدارتر، سریع تر و مقرون به صرفه تر خواهیم داشت.عملیات بهبود یافته:‌ همانطور که برنامه ها و سیستم ها پیچیده‌تر و پیچیده‌تر می‌شوند، اندازه و دشواری عملیات شما نیز افزایش می‌یابد. با وجود نقش‌های متفاوت و بعضا درتداخلی مثل SecOps، SysAdmins و DevOps نظارت دستی همه چیز را دشوارتر خواهند داشت، بنابراین به زمان و منابع مالی بیشتری نیاز دارند تا ارزیابی‌های بهینه‌ای از سیستم اعمال کنند. با استفاده از سیستم مدیریت لاگ‌ها، می‌توانید روندها را در کل زیرساخت شرکت خود شناسایی کنید، به شما این امکان را می دهد که زودتر با آن سازگار شوید و راه حل هایی ارائه دهید که جلوی اتفاق مشکلات پیش از وقوع گرفته‌شود.استفاده بهتر از منابع: وقتی صحبت از مشکلات عملکرد سیستم می شود، اضافه بار سیستم همیشه مانند ابر تاریکی است که در حال ظهور است. با این حال، باید به خاطر داشته باشید که همیشه مقصر نرم‌افزار شما نیست، بلکه درخواست‌هایی که روی سرور خود دارید، مقصر است. چه تعداد آنها زیاد باشد و چه بسیار پیچیده، سیستم شما ممکن است در برخورد با آنها با مشکل مواجه شود. در این مورد، کاری که مدیریت لاگ انجام می‌دهد، کمک به پیگیری استفاده از منابع است. یعنی اینکه ببینید در چه زمان‌هایی سیستم شما نزدیک به بارگذاری بیش از حد است تا بتوانید منابع خود را بهتر تخصیص دهید. نظارت بر عملکرد می‌تواند به شما اطلاع دهد که آیا مشکلات عملکرد وجود دارد یا خیر. به عنوان مثال، ممکن است متوجه شوید که IO زمانی که درخواست‌ها کند هستند، بیش از حد بارگذاری می‌شود. با این اوصاف، برای دریافت درک بهتر و عمیق‌تری در مورد علت بالا رفتن بیش از حد درخواست IO در آن زمان مشخص، به گزارش‌های پرس‌و‌جو نیاز دارید. برخلاف معیارها، با گزارش‌ها، شما متادیتای بیشتری برای فیلتر کردن و تجسم دارید.تجربه ی کاربر: یکی از بزرگ‌ترین دغدغه‌هایی که افرادبرای کار با سیستم می‌تواند انتظار بیش از حد برای سرعت کار با سیستم است. مدیریت گزارش به شما این امکان را می‌دهد که درخواست‌ها را در هر سطحی (API، پایگاه داده و غیره) نظارت کنید و ببینید کدام یک از آنها میانگین پاسخ بالاتری از حد مجاز تعیین شده (SLA) دارند و پس از رفع مشکلات آن، تجربه کاربر از کار با سیستم را بهبود دهیم. درک رفتار بازدیدکنندگان سایت: مدیریت لاگ‌ها می‌تواند با ردیابی حرکات کاربران در سایت یا پلتفرم کمک کند تا بتوانید درک بهتری از رفتار آنها به دست آورید و تجربه آنها را بهبود بخشید. در اینجا، مدیریت گزارش و نظارت بر کاربر واقعی (RUM) مکمل یکدیگر هستند. ابزارهای RUM دسترسی به دیدگاه کاربر، مانند تعداد بازدیدکنندگانی که در سایت خود داشته‌اید، صفحاتی که بیشترین زمان را در آن صرف کرده‌اند و موارد دیگر را فراهم می‌کنند. از تجمیع و مدیریت لاگ‌ها، به ابرداده‌هایی در مورد منطق کسب‌وکارتان دسترسی دارید: تعداد کاربرانی که در نهایت پرداخت کردند، درخواست‌های پشتیبان چگونه به نظر می‌رسیدند، و .... با بررسی این داده‌ها، می‌توانید فرصت‌هایی مانند زمان عرضه یک محصول جدید را شناسایی کنید چه زمانی سایت خود را برای تعمیر و نگهداری ببندید یا چه زمانی تخفیف ارائه دهید.امنیت بیشتر: تحلیل گزارش‌ها و لاگ‌های در سطح شبکه یا سرویس‌های مختلف به ما می‌توانند درکی از سطح امنیت در سیستم، علایق هکرها و نقاط قابل بهبود ارائه کنند: ناهنجاری ها در لاگ‌ها یا رفتار‌های کاربران ممکن است نشانه حمله باشد. گزارش‌ها به مدیران امنیتی کمک می‌کنند تا با ارائه جریانی زنده از رویدادهای گزارش، ناهنجاری‌ها را در بلافاصله تشخیص دهند. بنابراین، هر زمان که کسی تلاش می کند امنیت سیستم‌های شما را به چالش بکشد - چه از داخل باشد یا یک تهدید خارجی، درک بیشتری نسبت به آنچه واقعاً اتفاق افتاده است خواهید داشت. همچنین می توانید قبل از وقوع ناهنجاری ها هشدار دریافت کنید، بنابراین می توانید قبل از تشدید مسائل واکنش نشان دهید.ابزارهای مدریت لاگامروزه ابزار‌های بسیاری به منظورهای مختلفی برای مدیریت لاگ در بازار عرضه شده‌اند که اهداف و جنبه‌های مشترک و مختلفی را تحت پوشش خود قرار می‌دهند. ما نیز برخی از معروف‌ترین ابزار‌های مدیریت لاگ را معرفی می‌کنیم: پشته ELK : پشته ELK ترکیبی از سه سرویس جداگانه است که همه آنها منبع باز هستند و توسط یک تیم توسعه یافته اند. Elasticsearch یک موتور جستجوی بسیار قدرتمند و بسیار مقیاس پذیر است که می‌تواند حجم زیادی از داده‌ها را ذخیره کند و به عنوان یک خوشه مورد استفاده قرار گیرد. Logstash ابزاری برای واکشی داده‌ها از/به یک مکان خاص است. دارای تنوع گسترده ای از پلاگین ها و یک جامعه کاربری بزرگ است. Kibana یک رابط کاربری گرافیکی است که به شما امکان جستجو، تجزیه و تحلیل و تجسم مقادیر زیادی از داده های پیچیده از پایگاه داده Elasticsearch را می‌دهد. در بیشتر موارد، پشته ELK از Filebeat استفاده می کند. هدف این ابزار تحویل لاگ ها به یک سرور خاص است. پس از اینکه با Filebeat تحویل داده شدند و با Logstash پردازش شدند، در کلاستر ElasticSearch قرار می گیرند. از آنجا، لاگ ها برای نمایش نتایج توسط کیبانا گرفته می شوند.در کل پشته ELK یک پشته همه‌کاره برای مدیریت و دیدن لاگ‌های سیستم است. پشته را می توان به عنوان یک برنامه کاربردی مستقل استفاده کرد یا با برنامه های موجود برای دریافت به روزترین داده ها یکپارچه شد.ابزار Graylog:‌ Graylog یک ابزار قدرتمند برای مدیریت گزارش‌ها است که گزینه‌های زیادی برای تجزیه و تحلیل گزارش‌های ورودی از سرورهای مختلف در اختیار شما قرار می‌دهد. روش کار Graylog تقریباً شبیه به ELK است. علاوه بر سرور Graylog که از برنامه کاربردی و سرور رابط وب تشکیل شده است، برای اینکه بتوانید کل پشته را به طور کامل قابل اجرا کنید، باید دیتابیس MongoDB و Elasticsearch را نیز داشته باشید. پنل graylogهمانطور که گفتیم، Graylog گزینه های مدیریتی واقعاً خوبی را در اختیار شما قرار می دهد: شما می توانید تمام آدرس های IP مسدود شده توسط فایروال در هفته گذشته را جستجو کنید، تمام ورودهای ناموفق SSH. علاوه بر این، می توانید فیلترهایی را بر اساس پارامترهای مشخص شده ایجاد کنید. البته این ابزار باید روی بهبود گزارش‌های خود کارهای جدی کند. ابزار Data dog: یک ابزار نظارت و تجزیه و تحلیل برای تیم‌های فناوری اطلاعات (IT) و DevOps است که می‌تواند برای تعیین معیارهای عملکرد و همچنین نظارت بر رویدادها برای زیرساخت‌ها و خدمات ابری استفاده شود. این نرم افزار می تواند سرویس‌هایی مانند سرورها، پایگاه های داده و ابزارها را نظارت کند. نرم افزار مانیتورینگ و مدیریت لاگ Datadog برای استقرار در محل یا به عنوان یک نرم افزار به عنوان سرویس (SaaS) در دسترس است. Datadog از سیستم عامل های ویندوز، لینوکس و مک پشتیبانی می کند. پشتیبانی از ارائه دهندگان خدمات ابری شامل AWS، Microsoft Azure، Red Hat OpenShift و Google Cloud Platform است. Datadog از یک عامل نوشته شده با Go استفاده می کند و بک‌اند آن از Apache Cassandra، PostgreSQL و Kafka ساخته شده است و از یک رابط برنامه کاربردی Rest (API) برای اجازه دادن به Datadog برای ادغام با خدمات، ابزارها و زبان های برنامه نویسی متعدد استفاده می‌شود.شرکت آتین آتیه اندیش: شرکت آتین آتیه اندیش واقع در پارک علم و فناوری دانشگاه تهران در سال ۱۳۹۶ خدمات خود را آغاز کرده است و با معرفی محصولاتی در حوزه مدیریت لاگ‌های سیستم و سامانه مدیریت هویت دنبال جایگاه مناسبی در صنعت IT ایران است. آتین یک سرویس مدیریت هویت و دسترسی است که با تمرکز ویژه بر رضایت مشتری بر بستر زیرساخت ابری توسعه یافته است. با استفاده از سامانه آتین مراکز و سرویس دهنده های فناوری اطلاعات به راحتی می توانند دسترسی دستگاه های مختلف داخل سازمان یا اشخاصی از جمله کارمندان، شرکای تجاری و مشتریان را به تمامی سامانه ها به صورت متمرکز مدیریت نمایند. آتین تضمین می کند که دسترسی همه کاربران بر اساس سیاست واحد صورت گیرد و تمامی افراد و سرویس ها، احراز هویت، مجوزدهی و نظارت شوند. یکی از محصولات این شرکت سامانه مدیریت لاگ است که خدمتی‌ اضافه بر سامانه مدیریت هویت و دسترسی ارائه می‌کند. این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی استمنابع https://sematext.com/guides/log-management/ https://expertise.jetruby.com/log-management-graylog-vs-elk-d6e8f0492323 https://dzone.com/articles/why-is-log-management-so-important-and-how-can-it https://dzone.com/articles/why-is-log-management-so-important-and-how-can-it https://www.datadoghq.com/ https://authin.ir/ Amirmohammad Amirmohammad Thu, 23 Dec 2021 22:49:58 +0330 https://virgool.io/@amir-mohammad/%D8%A2%D8%B4%D9%86%D8%A7%DB%8C%DB%8C-%D8%A8%D8%A7-%D9%85%D9%81%D9%87%D9%88%D9%85-%D8%AA%D8%AD%D9%88%DB%8C%D9%84-%D9%85%D8%AF%D8%A7%D9%88%D9%85-continuous-delivery-pvqltinyed0c مفهوم تحویل مستمر از جمله مفاهیمی در حوزه دوآپس و مهندسی نرم‌افزار است که مکررا شنیده می‌شود. البته تحویل مستمر بیشتر در کنار ادغام مستمر به صورت CI/CD به کار برده می‌شود. در این مقاله قصد داریم به بررسی مفهوم تحویل مداوم بپردازیم، مزایای آن را ذکر کنیم و بگوییم چرا در سازمان یا شرکتمان به آن نیاز داریم. تحویل مداوم چیست؟ اگرچه تعاریف متعددی برای CD در اینترنت موجود است، اما این تعاریف تقریبا بیان مشترکی دارند. یکی از این تعاریف چنین است.تحویل مداوم (CD) به عنوان توانایی ارائه به‌روزرسانی‌های محصول به مشتریان در سریع‌ترین زمان ممکن و مکرر تعریف می‌شود. چه این به‌روزرسانی‌ها شامل رفع اشکال ساده، عملکرد بهبودیافته یا یک رابط جدید طراحی شده باشد، CD فرآیند و پروتکل‌هایی را برای ارسال سریع کد در کوتاه‌ترین زمان ممکن تعریف می‌کند.تحویل مستمر چه هنگامی به وجود آمد؟ هنگامی که توسعه نرم افزار برای اولین بار به عنوان یک زمینه ظهور کرد، بسیاری از تیم ها برای چرخه عمر توسعه نرم افزار خود (SDLC) به روش آبشاری تکیه کردند. توسعه‌ی آبشاری به مرور زمان و توسعه صنعت نرم‌افزار دیگر پاسخگو نبود و در دهه 90 به لطف شیوه‌های توسعه چابک نرم‌افزار تغییر کرد، که به تیم‌ها قدرت می‌داد تا به جای توسعه یک محصول کامل، محصول را کم کم توسعه بدهند و به تکامل برسانند :))با داشتن توانایی ایجاد تغییرات در سطوح مختلف، چارچوب های جدید مبتنی بر اصول چابک به سرعت برای بسیاری از تیم ها عادی شد. این چارچوب‌ها شامل رویکردهایی مانند تحویل مداوم، DevOps و استقرار مستمر بودند که از آن زمان بسیار مورد استفاده قرار گرفته‌اند. بنابراین استارت بحث تحویل مداوم را می‌توانیم از دهه 90 میلادی و توسعه‌ی روش‌های چابک بدانیم. تحویل مستمر چه ارتباطی با دواپس دارد؟ برای اینکه بفهمیم دوآپس چیست بگذارید اشاره‌ای به تعریف آن داشته باشیم. دواپس ترکیبی از فلسفه‌ها، شیوه‌ها و ابزارهای فرهنگی است که توانایی سازمان را برای ارائه برنامه‌ها و خدمات با سرعت بالا افزایش می‌دهد. توسعه و بهبود محصولات با سرعتی سریع‌تر از سازمان‌هایی که از فرآیندهای توسعه نرم‌افزار سنتی و مدیریت زیرساخت استفاده می‌کنند، با فرهنگ دواپس انجام می‌شود. این سرعت سازمان ها را قادر می سازد تا به مشتریان خود خدمات بهتری ارائه دهند و به طور موثرتری در بازار رقابت کنند.اگر DevOps فرهنگی است به دنبال تسریع در ارائه خدمات جدید و با کیفیت است، مطمئناً تحویل مداوم همان چیز است، اینطور نیست؟ اگر به توسعه‌ی نرم‌افزار به عنوان یک خط تولید تولید نگاه کنیم، DevOps ماشینی است که محصول را ایجاد می کند، در حالی که تحویل مداوم تسمه نقاله‌ای است که محصول را از خط تولید خارج می کند.گارتنر تمایز بین DevOps و تحویل مستمر را با بیان می‌کند: "DevOps یک بازار و شیوه تجاری نیست، بلکه یک فلسفه ابزار محور است که از زنجیره تحویل مداوم پشتیبانی می کند." این تحلیلگر استدلال می کند که استراتژی های کسب و کار دیجیتال تقاضا برای بهبود سرعت و اثربخشی تحویل نرم‌افزار را تحریک می کند.بنابراین می‌توان تحویل مداوم را بخشی از فرهنگ دواپس نامید. تحویل مداوم و DevOps ویژگی‌های مشترکی دارند. هدف هر دو روش تفکر چابک و ناب است: هر کدام تغییرات کوچک و سریعی را ارائه می دهند. با این حال، هدف DevOps ادغام نقش های توسعه دهنده و عملیاتی با یکدیگر - و فرآیندهایی که آنها مدیریت می کنند - برای دستیابی به اهداف تجاری است. همه چیز در مورد یک فرهنگ مشترک، مشترک و همکاری پیشرفته است. در مورد فرآیندهای تجاری به وضوح تعریف شده است.ارتباط تحویل مداوم با ادغام مداوم و استقرار مداوموقت آن رسیده تا مفهوم CI/CD را بیان کنیم :)) CI و CD دو نام اختصاری هستند که اغلب در شیوه های توسعه مدرن و DevOps استفاده می شوند. CI مخفف یکپارچه‌سازی مداوم است، یکی از best practiceهای اساسی DevOps که در آن توسعه دهندگان اغلب تغییرات کد را در یک ریپازیتوری اصلی که در آن ساخت و آزمایش های خودکار اجرا می شود، ادغام می کنند. اما CD می تواند به معنای تحویل مداوم یا استقرار مداوم باشد. ابتدا بهتر است هر مفهموم را تعریف کنیم و سپس مقایسه را انجام دهیم. ادغام مداوم:‌در توسعه اپلیکیشن‌های مدرن، هدف این است که چندین توسعه‌دهنده به طور همزمان روی ویژگی‌های مختلف یک برنامه کار کنند. با این حال، اگر بخواهیم همه‌ی شاخه‌ها را در یک روز باهم ادغام کنیم این کار هم زمانبر می‌تواند باشد و هم خطرناک. این به این دلیل است که وقتی توسعه‌دهنده‌ای که به صورت مجزا کار می‌کند، تغییری در یک برنامه ایجاد می‌کند، این احتمال وجود دارد که با تغییرات مختلفی که به‌طور همزمان توسط توسعه‌دهندگان دیگر ایجاد می‌شوند، تضاد داشته باشد. اگر هر توسعه دهنده محیط توسعه یکپارچه محلی (IDE) خود را سفارشی کرده باشد، این مشکل می تواند بیشتر شود، به جای اینکه تیم بر روی یک IDE مبتنی بر ابر توافق کند.یکپارچه‌سازی پیوسته (CI) به توسعه‌دهندگان کمک می‌کند تا تغییرات کد خود را به یک "Trunk" بیشتر ادغام کنند - گاهی اوقات حتی روزانه. هنگامی که تغییرات یک برنامه‌نویس در یک برنامه ادغام می‌شوند، این تغییرات با ساخت خودکار برنامه و اجرای سطوح مختلف آزمایش خودکار، معمولاً تست‌های واحد و یکپارچه‌سازی، تأیید می‌شوند تا اطمینان حاصل شود که تغییرات برنامه را خراب نکرده است. این به معنای آزمایش همه چیز از کلاس ها و عملکردها گرفته تا ماژول های مختلف است که کل برنامه را تشکیل می دهند. اگر آزمایش خودکار مشکلی بین کد جدید و کد موجود را کشف کند، CI رفع سریع و مکرر آن اشکالات را آسان‌تر می‌کند.استقرار مستمراستقرار مستمر یک گام فراتر از تحویل مداوم (CI) است. با این عمل، هر تغییری که تمام مراحل خط لوله تولید شما را پشت سر بگذارد برای مشتریان شما منتشر می شود. هیچ دخالت انسانی وجود ندارد، و تنها یک آزمایش ناموفق مانع از اعمال تغییرات جدید در تولید می شود. استقرار مستمر یک راه برای تسریع حلقه بازخورد با مشتریان و کاهش فشار از تیم است زیرا دیگر روز انتشار وجود ندارد. توسعه‌دهندگان می‌توانند بر روی ساختن نرم‌افزار تمرکز کنند و چند دقیقه پس از پایان کار بر روی آن، کار خود را زنده می‌بینند.تصویر زیر مقایسه تحویل مداوم و استقرار مداوم را نشان می‌دهد. مقایسه تحویل مداوم با استقرار مداومبه بیان ساده، ادغام مداوم بخشی از تحویل مداوم و استقرار مداوم است. و استقرار مداوم مانند تحویل مداوم است، با این تفاوت که انتشار در استقرار مداوم به طور خودکار اتفاق می افتد. تحویل مداوم برای ما چه مزایایی دارد؟ بسیاری از مقالات مزایای CD را در کنار CIبررسی کرده‌اند تا مزایای آن برای همگان بسیار ملموس شود. برای راحتی در کار نیز ما هم همین کار را می‌کنیم :))زمان سریعتر برای بازارمزیت مهم تجاری یکپارچه سازی مداوم و تحویل مستمر، سرعت بخشیدن به کل فرآیند توسعه با توسعه دهندگان فین‌تک است. اگر مجبور به راه اندازی یک برنامه فین‌تک در مدت زمان کوتاهی هستید، CI/CD مناسب خواهد بود. به گفته مک کینزی، با CI/CD، شرکت ها می توانند کد را به جای 89 روز به طور متوسط ​​در 15 روز به انتشار برسانند.انعطاف پذیری و پاسخگوییواقعیت این است که CI/CD نه تنها به صورت هفتگی، بلکه حتی روزانه اجازه انتشار نرم افزار را می دهد. تحویل مداوم در فین‌تک به‌روزرسانی برنامه‌ها را سریع‌تر می‌کند. و این باعث می شود که معرفی ویژگی‌های جدید آسان‌تر شود. مهمتر از آن، با CI/CD، توسعه دهندگان می توانند مشکلات را به سرعت برطرف کنند. در صورت عدم موفقیت برنامه، توسعه دستی سنتی گزینه ای برای یک شرکت فین‌تک نیست. واضح است که وقتی یک برنامه نیاز به یک اصلاح اساسی دارد، تاخیر در صنعت مالی قابل قبول نیست. راه حل در پیاده سازی خط لوله CI/CD نهفته است که امکان تحویل سریع نرم افزار را فراهم می کند. این عمل به شرکت‌های فین‌تک کمک می‌کند تا انعطاف‌پذیر و پاسخ‌گو باشند، یعنی مشتریان راضی‌تر.بهره‌وری بیشترپیاده سازی CI/CD به تیم توسعه اجازه می دهد تا بهره‌وری بیشتری داشته باشند. CI/CD در فین‌تک کار مجدد و زمان انتظار را حذف می‌کند. به لطف اتوماسیون فرآیندهای معمول، توسعه دهندگان نرم افزار می توانند روی سایر وظایف مهم تر، مانند اطمینان از کیفیت و امنیت کد، تمرکز کنند.تلاش کمتری برای رساندن محصول به پروداکشن لازم است: همه چیز قبلا automate شده است :))فشار کمتر بر توسعه دهنده: زیرا تغییرات کوچکتر هست و پس از اعمال تغییرات سریع مشکلات و منبع مشکلات شناسایی می‌شود. فاز‌های یک پایپلاین تحویل مداوماگر کد تغییر کند، خط لوله تحویل پیوسته راه اندازی می شود و فرآیند آزمایش اجرا می شود. اینها فازهایی هستند که خط لوله تحویل مداوم از آن عبور می کند:خط لوله تحویل مستمرمرحله کامیت: در این مرحله آزمایش اول، نسخه نرم افزار بررسی می شود، اجزای نرم افزار ساخته یا کامپایل می‌شوند و یونیت تست‌های لازم انجام می‌شود. پس از آزمایش موفقیت آمیز، مرحله تکمیل می شود. نتایج کامپایل که معمولا مخزن ذخیره می شوند. این بسته سپس عملکرد خط لوله را تعیین می کند زیرا وضعیت نرم افزار را تعیین می کند. در نهایت، بسته شامل مقدار داده ای است که بعداً روی سیستم هدف نصب می‌شود. مرحله آزمون قبولی (Acceptance Test): در مرحله آزمون دوم، آزمون‌های قبولی انجام می‌شود. این شامل تست های یکپارچه‌سازی (آیا تعامل اجزا کار می کند؟) و همچنین تست های سیستم لازم (آیا نرم افزار در سمت کاربر کار می کند؟). برخی از آزمون‌های اختیاری نیز وجود دارد که در مرحله آزمون پذیرش ادغام می‌شوند، مانند آزمون‌های عملکرد و سایر آزمون‌هایی که الزامات غیر کاربردی نرم‌افزار را بررسی می‌کنند. برای مرحله آزمون پذیرش، باندل ایجاد شده در مرحله قبل مجددا مورد استفاده قرار می گیرد و در محیط آزمون مناسب نصب می شود.هر گونه خطا یا عوارض در این مراحل مستند شده و در صورت لزوم به عنوان بازخورد برای توسعه دهنده ارسال می‌شود. از آنجا که خط لوله با هر تغییر کد فعال می شود، پیام های خطا یا رگرسیون همیشه به آخرین تغییر در اینجا اشاره می کنند. این به توسعه‌دهنده اجازه می‌دهد تا سریع و کارآمد واکنش نشان دهد و هر گونه باگ یا کد باگی را برطرف کند.در فاز بعدی آزمایشات دستی در صورت نیاز انجام می شود. برای این تست‌ها نیز خط لوله از فاز اول باندل استفاده می کند و آن را در محیط آزمایشی مناسب نصب می کند.اگر تمام تست ها با بازخورد مثبت کامل شوند، بسته را می توان به صورت دستی بر روی سیستم هدف نصب کرد. این معمولاً فقط به "فشردن یک دکمه" نیاز دارد. اگر این مرحله خودکار باشد، به آن استقرار پیوسته می گویند.چالش‌های موجود در تحویل مداومبا بزرگ‌تر شدن تیم‌ها و انجام وظایف بلندپروازانه‌تر، پیاده‌سازی CD - تحویل واقعی در تحویل مداوم - می‌تواند یک چالش باشد. تأخیرها به دلایل متعددی اتفاق می‌افتد و تیم‌های DevOps پیوسته در حال مبارزه برای حفظ پروژه‌ها در مسیر هستند. از مقیاس‌بندی خیلی سریع تا سازمان‌دهی ضعیف، در اینجا فقط چند مورد از رایج‌ترین چالش‌هایی که تیم‌ها با آن‌ها مواجه هستند، و همچنین تکنیک‌هایی که رهبران DevOps می‌توانند برای کاهش نقاط درد به کار ببرند، آورده شده است:ارتباط ضعیف بین تیم ها همانطور که تحویل مستمر به اجزای عملیاتی مختلف برای اطمینان از کد قابل اعتماد نیاز دارد، کسب و کار نیز برای موفقیت به همکاری بین تیم ها نیاز دارد. ارتباطات ضعیف بین تیم‌ها، چه محصول خاص و چه در کل کسب‌وکار، می‌تواند منجر به تجدید نظر و تأخیر قابل توجه در استقرار شود. تیم‌ها باید هم فرآیندهای عملیاتی و هم ابزارهای تولیدی خود را در سراسر سازمان خود ارزیابی کنند - و یک بار دیگر برنامه و نقشه راه مشترکی داشته باشند که قابل اعتماد و دقیق باشد. با ظهور مشکلات و تغییرات در پروژه، چه داخلی و چه در بازار، تیم های DevOps باید بتوانند به سرعت و شفاف در بخش های مربوطه پاسخ دهند.هزینه های زیرساختیتوسعه دهندگان موفق باید ابزارهای لازم را داشته باشند تا نه تنها از محصولات کسب و کار پشتیبانی کنند، بلکه از تیم های داخلی خود نیز پشتیبانی کنند. تیم هایی که با DevOps مقیاس بندی می شوند باید بودجه لازم را برای ایجاد زیرساخت های مورد نیاز برای تیم ها برای ساخت محصولات جاه طلبانه تر و جمع آوری مقادیر بیشتری از داده ها داشته باشند. تیم هایی که سعی می کنند خیلی سریع مقیاس شوند، اغلب در این تنگنا گرفتار می شوند و کیفیت محصول یا زیرساخت داخلی خود را قربانی می کنند. این به جای استقرار به تاخیرهای مداوم منجر می شود و اگر عاقلانه برخورد نشود، این موضوع می تواند گلوله برفی داشته باشد. تیم‌ها باید قبل از اینکه تلاش‌های CD خود را افزایش دهند، این را در نظر بگیرند: «این موضوع چگونه بر زیرساخت‌ها و فرآیندهایی که امروز در اختیار دارم تأثیر می‌گذارد؟» قبل از اجرای یک فرآیند جدید، مطمئن شوید که چگونه فرآیندهای گردش کار فعلی شما می تواند تحت تأثیر قرار گیرد. صرف زمان برای ادغام جریان های کاری مناسب، انتقال را هموارتر می کند و از متورم شدن این تنگنا به تاخیر جدی جلوگیری می کند.تست ضعیفیک تیم اختصاصی تست اتوماسیون موتور محصول را روشن نگه می‌دارد، اما در طول چرخه عمر به نظم و انضباط قوی نیاز دارد. اولاً، این مستلزم این است که همه به توافق برسند. رهبران DevOps باید مطمئن شوند که همه تیم‌ها در مورد فرآیندی که انتخاب می‌کنید، خواه این فرآیند توسعه رفتار محور یا چابک باشد، موافق باشند. و از همه مهمتر، فرآیندهای سایه CI را در گذشته رها کنید تا اطمینان حاصل شود که تیم ها به یک نمای واحد از کد محصول شما دسترسی دارند. در کل فرآیند تست باید جدی گرفته‌شود و تست‌ها پوشش لازم را داشته باشند. اتکای بیش از حد به اتوماسیوناتوماسیون ابزارهای DevOps می تواند ساعت های بی شماری را ذخیره کند و برنامه های CD را به موقع نگه دارد. با این حال، از آنجایی که مسئولیت‌های تیم شما تغییر می‌کند و وظایف جدید به وجود می‌آیند، خودکار کردن فرآیندها خیلی زود فقط به خاطر زمان آسان است. اتوماسیون یک فرآیند با طراحی ضعیف ممکن است در کوتاه مدت باعث صرفه جویی در زمان شود، اما دراز مدت می تواند به یک گلوگاه بزرگ تبدیل شود که رفع آن دشوار است. برای مبارزه با این، تیم‌ها باید قبل از خودکارسازی، گلوگاه‌های فرآیند را حل کنند. توسعه دهندگان باید به طور مداوم ممیزی پروتکل های خودکار خود را انجام دهند تا اطمینان حاصل کنند که آنها به طور مداوم دقیق هستند، در حالی که فرآیندهای فعلی را برای کارایی آزمایش می کنند.ابزار‌ها و تکنولوژی‌های متن‌بازابزار Jenkins: این ابزار یکی از معروف‌ترین (یا شاید بهتر باشد بگوییم معروف‌ترین) ابزار تحویل مدام است که با هر تغییر در متن برنامه، مراحل متعدد ساخت و ارزیابی کیفیت نرم‌افزار را اجرا می‌کند. به عبارت دیگر، Jenkins یک ابزار ایده‌آل برای ادغام و تحویل مداوم در فرآیند  DevOps است. پنل جنکینزابزار fluxcd: Flux CD یک ابزار تحویل مداوم است که به سرعت در حال محبوبیت است. Weaveworks در ابتدا این پروژه را توسعه داد و آن را به صورت منبع باز در اختیار بنیاد Cloud Native Computing قرار داد. دلایل موفقیت آن این است که بسیار با کوبرنتیز ادغام شده است و راه اندازی آن ساده است. امیدوار کننده ترین ویژگی ارائه شده این است که به تیم ها اجازه می دهد تا استقرارهای Kubernetes خود را به صورت اعلامی مدیریت کنند. Flux CD مانیفست‌های Kubernetes ذخیره‌شده در مخزن کد منبع را با خوشه Kubernetes از طریق نظرسنجی دوره‌ای مخزن همگام‌سازی می‌کند، بنابراین تیم‌ها نیازی به نگرانی در مورد اجرای دستورات kubectl و نظارت بر محیط ندارند تا ببینند آیا بارهای کاری مناسب را مستقر کرده‌اند یا خیر. در عوض، Flux CD تضمین می کند که خوشه Kubernetes همیشه با پیکربندی تعریف شده در مخزن کد منبع همگام است.FluxCDابزار ArgoCD: ابزار Argo نیز دیگر ابزار مشهوری است که پیکربندی محیط ما را (نوشته شده به عنوان نمودار فرمان، شخصی سازی فایل ها، فایل های jsonnet یا یاml ساده) از مخزن git می خواند و آن را در فضای نام Kubernetes شما اعمال می کند. این ابزار بسیار با کوبرنتیز ادغام یافته و برای استقرار برنامه‌های cloud native مناسب است. ArgoCDابر آروان: ابر آروان نیز یکی از مشهورترین ارائه‌دهندگان خدمات ابری در ایران است که قابلیت تحویل مداوم را در سطح PaaS برای محصولات خود فعال کرده است. تحویل مداوم در سناریو فروشگاه ساده با مدل CD ابرآروانمنابع WhatIsContinuousDelivery(CD)?Definition,HistoryandBenefits(airfocus.com) DevOpsandContinuousDelivery:NottheSame-DevOps.com https://virgool.io/d/pvqltinyed0c/WhatisDevOps?-AmazonWebServices(AWS) Continuousintegrationvs.continuousdeliveryvs.continuousdeployment(atlassian.com) WhatisCI/CD?(redhat.com) https://virgool.io/d/pvqltinyed0c/6CommonChallengesSlowingDownContinuousDelivery%E2%80%93Stackify Flux(fluxcd.io) Amirmohammad Amirmohammad Thu, 23 Dec 2021 14:16:46 +0330 https://virgool.io/@amir-mohammad/%D8%A2%D8%B4%D9%86%D8%A7%DB%8C%DB%8C-%D8%A8%D8%A7-%D9%85%D8%A7%D9%86%DB%8C%D8%AA%D9%88%D8%B1%DB%8C%D9%86%DA%AF-%D8%B3%DB%8C%D8%B3%D8%AA%D9%85-%D9%87%D8%A7-z2lw8xftvuh6 در این مقاله قرار است به طور خلاصه مانیتورینگ سیستم‌ها را مورد بحث قراردهیم و با تعدادی از ابزار‌های معروف در این حوزه آشنا شویم. نرم‌افزار‌های مانیتورینگ چه هستند؟ نرم‌افزارهای مانیتورینگ عملیات و فعالیت‌های کاربران در سیستم، برنامه های کاربردی و سرویس‌های شبکه را در رایانه یا سیستم‌های سازمان ما مشاهده، پایش و ردیابی می‌کند. این نرم‌افزارها بر حسب طراحی سیستم کاربران را پایش می‌کنند و امکاناتی برای نمودارسازی و بصری‌سازی داده‌ها در سیستم نیز دارند. چرا برای پایش سیستم خود باید از این نرم‌افزارها استفاده کنیم؟ تصور کنید در حال حل یک معمای ماز هستیم.این ماز پر از بن‌بست‌ها و مسیرهای گیج کننده است، و گاهی اوقات مسیرها نیز تغییر می کنند. جایی که زمانی مسیری بود که به سمت انتها رفته‌ایم، اکنون مسدود شده است. بنابراین، رسیدن به خروجی، یا پایان، بسیار مشکل است. حالا تصور کنید بخواهید با چشمان بسته از همان پیچ و خم عبور کنید، این کار تقریبا برای شما غیرممکن خواهد بود.بیایید این مسئله را درحوزه فناوری اطلاعات بررسی کنیم، حال می‌خواهیم یک بخش فناوری اطلاعات را اداره کنیم و خدمات فناوری اطلاعات را ارائه و پشتیبانی کنیم. انجام این کار بدون ابزار نظارت مانند واردشدن به داخل آن ماز با چشم بند است – بدون مانیتورینگ فرآیند‌ها و اتفاقاتی که در سیستم‌ می‌افتد، انجام کار سخت را سخت‌تر نیز کرده‌ایم. وقتی نمی‌توانیم ببینیم با چه چیزی کار می‌کنیم، چگونه می‌توانیم انتظار داشته باشیم که به چه مسائل رسیدگی کنیم و عملکرد چه بخشی را بهبود ببخشیم؟برای بیان اهمیت مانیتورینگ 5 دلیل را ذکر می‌کنیم: این ابزار‌ها معیار عملکرد سازمان ما را مشخص می‌کنند. بدون معیار، چگونه بخش فناوری‌اطلاعات سازمان ما می‌داند که چه توانایی‌هایی دارد یا در حال بهبود چه شاخص‌هایی است؟ خیلی ساده، چیزی نمیداند! زمانی که ندانیم زیرساخت فناوری اطلاعات فعلی ما چه کاری می‌تواند انجام دهد یا اینکه بخش شما چقدر خوب عمل می کند، رسیدن به اهدافی که مدیران سیستم برای ما معین کرده‌اند بسیار دشوار خواهد بود. اگر سازمان یا سیستمی بدون استفاده از مانیتورینگ و به صورت حدسیات جلو برود، به احتمال زیاد در خطر بزرگی است. این امر می‌تواند منجر به فشار بیش از حد بر کارکنان، کاهش روحیه در صورت عدم دستیابی به اهداف، کاهش بودجه و آسیب دیدن شهرت شود. ابزارهای مانیتورینگ به ما تجزیه و تحلیل بلادرنگ می‌دهند، بنابراین می‌توانیم با استناد به ارقام تصویر واضحی از نحوه عملکرد برنامه‌ها و زیرساخت‌های خود دریافت کنیم. با استفاده از این اطلاعات، می‌توانیم استراتژی‌های مناسب‌تری ایجاد کنیم، اهداف واقع‌بینانه تعیین کنیم، بهبود‌های سیستم را مشخص کنیم و عملکرد را در طول زمان پیگیری کنیم تا تاببینیم آیا در مسیر درستی حرکت می‌کنیم؟ ابزارهای مانیتورینگ به بهبود عملکرد سازمان کمک بسیاری می‌کنند. ابزارهای نظارتی برای نشان دادن وضعیت IT و سلامت سازمان عالی هستند، اما به همین جا ختم نمی شوند. این که همه چیز کار می کند به این معنی نیست که همه چیز به خوبی کار می‌کند. ابزارهای مانیتورینگ به سازمان ما این امکان را می دهند که زیرساخت های خود را درک کنند، به طوری که بتوانیم بر روی مناطقی تمرکز کنید که ممکن است سازمان را در معرض خطر قرار دهد. سپس نقاط بحرانی را مورد توجه قرار دهیم و قبل از وقوع حوادث آن‌ها را برطرف کنیم. بنابراین نه‌تنها عملکرد را بهبود بخشیده‌ایم بلکه سازمان ما مقاوم‌تر شده است.ابزارهای مانیتورینگ به ما کمک می‌کنند تلاش‌های دستی خود را کاهش دهیم. برخی از ابزارهای مانیتورینگ این قابلیت را دارند که نه تنها مشکلات را شناسایی کنند، بلکه می توانند به طور خودکار مشکلات را نیز با استفاده از طیف متنوعی از تکنیک‌ها مانند یادگیری ماشین برطرف کنند. علاوه بر این، با استفاده از قوانین و تکنیک‌های یادگیری ماشینی، ابزارهای مانیتورینگ می‌توانند رفتار برنامه و سرویس‌های ما را بفهمند تا در هنگامی که چیزی سر جایش نیست، به جای اینکه فقط به تیم‌فنی در مورد خرابی احتمالی هشدار دهند، اصلاحاتی را اعمال کنند. بنابراین، ابزارهای مانیتورینگ، مداخلات دستی ما مربوط به نظارت و پشتیبانی از زیرساخت فناوری اطلاعات را کاهش خواهند داد. حذف این وظایف کوچک‌، اما مکرر به این معنی است که تیم فنی زمان بیشتری برای تمرکز بر مسائل مهم‌تر دارد.مانیتورینگ به تخمین هزینه‌ها می‌تواند کمک کند. هنگامی که از ابزارهای نظارتی استفاده می‌کنیم، می‌توانیم ببینیم که همه چیز در محیط چقدر خوب کار می‌کند. با نظارت بر عملکرد، پیش‌بینی‌های دقیق‌تری خواهید داشت که کدام عناصر ممکن است نیاز به ارتقا یا حتی جایگزینی داشته باشند. بنابراین، ابزارهای نظارت به ما این امکان را می‌دهند که بودجه محدود خود را بسیار مؤثرتر مدیریت کنیم و از افزایش هزینه‌های غیرمنتظره جلوگیری کنیم. ابزار‌های مانیتورینگ به پایداری سرویس کمک می‌کنند. ابزار‌های نظارتی می‌توانند به گونه‌ای تنظیم شوند که قبل از تاثیرگذاری بر پایگاه مشتریان، ما را آگاه کنند. بنابراین، قبل از اینکه مشکلاتی برای مشتریانمان ایجاد شود، آن‌ها را برطرف می‌کنیم. شناسایی و رفع مشکلات قبل از وقوع خرابی‌ها فواید متعددی دارد. برای مثال، سازمان در زمان و هزینه صرفه جویی می‌کند، از خرابی سیستم جلوگیری می‌شود (و اثرات نامطلوب آن، که ممکن است در سطح کسب و کار باشد)، و از مشتریان ناراضی جلوگیری می‌شود. همه اینها از اعتبار سازمان ما محافظت می کند.انواع مانیتورینگ؟‌انواع مختلفی از مانیتورینگ در سیستم‌ها می تواند به صورت استراتژیک برای به دست آوردن حداکثر داده‌ها از عملکرد سازمان و کسب و کار استفاده شود. انواع مانیتورینگ در IT می تواند بسیاری از وظایف سازمان فناوری اطلاعات را در بربگیرد. در زیر مواردی از انواع مانیتورینگ در سیستم‌ها را شرح می‌دهیم. پایش سیستم: پایش سیستم عملکرد اجزای زیرساخت را در لایه فیزیکی شبکه ارزیابی می کند. مثلا هر سرور به صورت جداگانه نظارت می شود و اطلاعات جمعی از سرور‌های موجود در شبکه بیشتر تجزیه و تحلیل می شود تا تأثیر آن بر عملکرد شبکه ارزیابی شود. سپس، مشکلات مربوط به اجزای سخت‌افزاری شناسایی و بر اساس آن رسیدگی می‌شود. نظارت سیستم همچنین به عنوان نظارت بر در دسترس بودن (availability) نیز شناخته می شود که با معیارهایی مانند زمان کارکرد سرور و عملکرد CPU سروکار دارد. نظارت بر وابستگی:‌ برنامه‌هایی که روی زیرساخت فناوری اطلاعات توزیع شده اجرا می‌شوند می‌توانند به انواع سرویس‌ها یا پایگاه‌های داده توزیع‌شده در شبکه وابسته باشند. مصرف منابع در گره‌های خاص می‌تواند نحوه واکنش اجزای سرور داخلی به عملکرد برنامه و ترافیک داده ورودی آن را تعیین کند. این اطلاعات به شناسایی وابستگی های معماری اساسی بین برنامه‌ها، سخت‌افزار و سرویس‌ها کمک می‌کند.پایش عملکرد وب: این نوع از پایش، بخش‌های سرویس مبتنی بر وب کسب و کار یا سازمان، مانند وب‌سایت‌ها را ارزیابی می‌کنیم، به‌ویژه اینکه این سرویس چگونه به درخواست کاربر در سمت مشتری شبکه پاسخ می‌دهد. اندازه گیری‌ها شامل سرعت بارگذاری صفحات، خطاهای انتقال داده، خطاهای بارگذاری و موارد دیگر می باشد. بر اساس تحقیقات انجام شده، تصمیم گیری در مورد استفاده از یک وب سایت برای کاربران اینترنت 50 میلی ثانیه (0.05 ثانیه) طول می‌کشد. زمانی که بارگذاری صفحه بیش از حد طول می‌کشد، کاربران به سرعت به یک وب سرویس رقیب که عملکرد سریع تری ارائه می دهد سوئیچ می‌کنند.نظارت بر عملکرد برنامه (APM): اپلیکیشن‌ها تا بخش بسیار تاثیرگذاری از تجارت IT در جهان امروز هستند. APM مشاهده می کند که برنامه‌ها در وضعیت فعلی محیط IT چقدر خوب عمل می کنند. دامنه نظارت به مؤلفه‌ها و وابستگی‌های زیرساختی گسترش یافته است. APM داده‌های شبکه ورودی را جمع‌آوری و تجزیه و تحلیل می‌کند تا وضعیت محیط را ارزیابی کند و علت اصلی مشکل را در زمانی که برنامه‌ها عملکرد نامناسبی دارند شناسایی کند. معیارهای APM مصرف منابع، میزان خطا در سطح نرم‌افزار، زمان پاسخگویی برنامه و نرخ درخواست در سناریو‌های مختلف و تجربه ی مشتری است. نظارت بر امنیت سیستم:‌ حملات امنیتی و نقض شبکه بر جریان ترافیک داده و رفتار شبکه تأثیر می‌گذارد. فعالیت های غیرمعمول را می توان بر اساس سیاست های تعریف شده دسترسی و مجوز به اطلاعات ردیابی کرد. با استفاده از راه‌حل‌های پیشرفته مبتنی بر هوش مصنوعی، داده‌های گزارش شبکه نظارت شده را می‌توان برای رفتار غیرعادی قبل از اینکه تهدیدات بالقوه بر تجارت تأثیر بگذارد، تجزیه و تحلیل کرد.در مانیتورینگ سازمان با چه چالش‌هایی روبرو هستیم؟‌اما مانیتورکردن سازمان و سامانه‌ها همیشه بدون چالش نیست. بنابراین لیستی از چالش‌هایی که در پایش سیستم ممکن است روبرو شویم را به شما نشان می‌دهیم. تمام داده‌هایی که مانیتور می‌شوند، قابل اطمینان نیستند. علت این امر می‌تواند اشتباه ما برای نوشتن اسکریپت‌های داده یا تاثیر فرآیند‌های سیستم روی یکدیگر یا به وجود آمدن یک شرایط غیرعادی در سرورها باشد. زیرساخت ما بسیار بزرگ است. رایج‌ترین مشکل نظارت بر زیرساخت، افزایش حجم دستگاه‌ها و شبکه‌های نظارتی است. با رشد سازمان، زیرساخت های آن نیز رشد می کند. پیگیری دستگاه ها و برنامه هایی که اکوسیستم فناوری اطلاعات سازمان را تشکیل می دهند به خودی خود یک چالش است. راه حلاین موضوع این است که از راهکار‌های مقیاس پذیر برای مانیتور کردن سرویس‌ها استفاده کنیم. در واقع، ما به راه‌حلی نیاز داریم که بتواند سرویس ها را به صورت سرتاسری ردیابی و نظارت کند و تمام داده ها را از همه منابع در یک کنسول مرکزی جمع کند. این اساساً به این معنی است که ما به یک نرم‌افزار نظارتی نیاز دارید که چندین ابزار نظارتی خاص را در درون خود داشته باشد، که همه آنها برای ایجاد تصویر بزرگ در کنار هم قرار می‌گیرند.افزایش هزینه‌ها: برای بسیاری از شرکت‌ها، افزایش هزینه‌های زیرساخت نیز یک مسئله بزرگ است. در برخی از سازمان‌ها، هزینه‌ی سیستم مانیتورینگ برای سازمان بسیار سنگین است. در این حوزه تحقیقات بسیاری انجام شده است. به عنوان مثال، یکی از انواع تحقیقات انجام شده این است که چگونه می توان کارایی سیستم های مختلف را بهبود بخشید و هزینه ها را کاهش داد؟چه ابزار‌های معروفی برای مانیتور کردن زیرساخت وجود دارد؟ در صنعت فناوری اطلاعات و به خصوص حوزه دوآپس، ابزار‌های مختلفی برای مانیتور کردن سرویس‌ها و زیرساخت وجود دارد. برخی از این ابزار به طور گسترده‌ای درصنعت استفاده می‌شوند و اصطلاحا عام‌منظوره هستند و برخی دیگر نیز کاربرد محدود‌تری دارند و برای اهداف‌ خاصی توسعه داده‌شده اند. در ادامه برخی از معروف‌ترین ابراز‌های منبع باز در حوزه پایش سیستم را معرفی می‌کنیم:ابزار Zabbix :Zabbix یک ابزار نرم‌افزاری مانیتورینگ منبع باز برای اجزای مختلف فناوری اطلاعات، از جمله شبکه‌ها، سرورها، ماشین‌های مجازی و سرویس‌های ابری است. Zabbix معیارهای نظارتی، از جمله استفاده از شبکه، بار CPU و مصرف فضای دیسک را ارائه می دهد. زبیکس تحت لایسنس GPL2 عرضه شده و اپن سورس است. پنل اصلی زبیکس در نسخه 4.3زبیکس به زبان C و قسمت وب با زبان PHP نوشته شده است. Zabbix چندین ویژگی نظارتی را ارائه می دهد: بررسی های ساده می تواند در دسترس بودن و پاسخگویی سرویس های استاندارد مانند SMTP یا HTTP را بدون نصب هیچ نرم افزاری بر روی هاست نظارت شده تأیید کند. یک عامل Zabbix همچنین می تواند بر روی هاست‌های یونیکس و ویندوز نصب شود تا آمارهایی مانند بار CPU، استفاده از شبکه، فضای دیسک و غیره را نظارت کند. به عنوان جایگزینی برای نصب یک عامل بر روی هاست، Zabbix شامل پشتیبانی از نظارت از طریق بررسی های SNMP، TCP و ICMP، و همچنین از طریق IPMI، JMX، SSH، Telnet و استفاده از پارامترهای سفارشی است. Zabbix از انواع مکانیسم های اطلاع رسانی در زمان واقعی، از جمله XMPP پشتیبانی می کند.پرومتئوس: Prometheus یک جعبه ابزار مانیتورینگ و هشدار سیستم منبع باز است که در ابتدا در SoundCloud ساخته شد. از زمان شروع آن در سال 2012، بسیاری از شرکت ها و سازمان ها Prometheus را پذیرفته‌اند و این پروژه دارای یک جامعه توسعه‌دهندگان و کاربران بسیار فعال است. اکنون یک پروژه منبع باز مستقل است و مستقل از هر شرکتی نگهداری می شود. برای تاکید بر این موضوع و برای روشن شدن ساختار مدیریتی پروژه، پرومتئوس در سال 2016 به عنوان دومین پروژه میزبان پس از Kubernetes به بنیاد cloud native computing پیوست.معماری نرم‌افزار پرومتئوسپرومتئوس معیارهای خود را به عنوان داده‌های سری زمانی جمع آوری و ذخیره می کند، یعنی اطلاعات متریک با timestampای که در آن ثبت شده است، به صورت داده‌های کلید-مقدار ذخیره می‌شود.شرکت نت‌نگار: شرکت پدید آوران رویای سریع ارتباطات در سال 89 با هدف ایجاد بستر مناسب و ارائه راحل های مبتنی بر سیستم ها و متدهای دنیا IT مطرح و در سال 90 به صورت رسمی به ثبت رسید. این مجموعه تلاش می کند با ارائه مشاوره علمی و انجام اقدامات مناسب در جهت امکان سنجی واحدهای کارفرمایان , راه‌حل‌های مناسب و مقرون به صرفه‌ای را برای کاهش هزینه‌ها و افزایش راه‌های تبلیغاتی توسط بستر مناسب وب به کارفرمایان ارائه کند. از ویژگی‌های سیستم مانیتوریگ این شرکت می‌توان به پوشش سراسری دیتاسنتر‌های ایرانی، سیستم نوتیفیکیشن و عیب‌یابی آسان اشاره کرد. وبسایت ایرانی servermonitoring:‌ این وبسایت از دسته وب‌سایت های فارسی و ساده‌ای است که خدمات پایه‌ای مانیتورینگ برای کسب و کارها را فراهم می‌آورد. این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی استمنابع https://www.techopedia.com/definition/4313/monitoring-software shorturl.at/ghwFS https://www.sysaid.com/blog/service-desk/5-reasons-why-you-need-monitoring-tools https://www.bmc.com/blogs/it-monitoring/ https://www.virtualmetric.com/blog/infrastructure-monitoring-challenges https://www.zabbix.com/features https://prometheus.io/docs/introduction/overview/ https://netnegar.io/services/%D8%B3%D8%B1%D9%88%DB%8C%D8%B3-%D9%85%D8%A7%D9%86%DB%8C%D8%AA%D9%88%D8%B1%DB%8C%D9%86%DA%AF.html http://www.servermonitoring.ir/%D8%B3%D8%B1%D9%88%DB%8C%D8%B3-%D9%85%D8%A7%D9%86%DB%8C%D8%AA%D9%88%D8%B1%D9%86%DA%AF-%D8%B1%D8%A7%DB%8C%DA%AF%D8%A7%D9%86-%D8%B3%D8%B1%D9%88%D8%B1/ Amirmohammad Amirmohammad Wed, 22 Dec 2021 22:30:13 +0330 https://virgool.io/@amir-mohammad/%D8%B3%DB%8C%D8%B3%D8%AA%D9%85-%D9%87%D8%A7%DB%8C-%D9%85%D8%AF%DB%8C%D8%B1%DB%8C%D8%AA-%D9%81%D8%B1%D8%A2%DB%8C%D9%86%D8%AF-%D9%87%D8%A7%DB%8C-%DA%A9%D8%B3%D8%A8-%D9%88-%DA%A9%D8%A7%D8%B1-bpms-la3ioancgdtl مقدمه احتمالا برای شما پیش آمده باشد تا در اداره یا سازمانی سرگردان شده باشید و پس از رفع سرگردانی صف‌های طولانی و فرآیند‌های بسیاری برای انجام یک کار تقریبا ساده را طی کرده باشید. این فرآیند‌ها اغلب موجب عصبانیت و انتقاد مراجعین از ادارات و سازمان‌ها می‌شود. فرآیند‌های کسب و کار را می‌توان مجموعه اقدامات و فعالیت‌هایی که هر سازمان و کسب و کاری به اجرا در می‌آورد تا به اهداف مشخص شده دست پیدا کند، تعریف کرد. اما سؤال اصلی مدیران و خبرگان آن سازمان این است که چه روش‌هایی برای بهینه‌سازی فرآیند‌ها در سازمان ما وجود دارد؟ چه ابزارها و شبیه‌سازهایی برای تحلیل فرآیند‌های سازمانی و بهبود آن‌ها داریم؟ این ابزارها را که در آن فرآیند‌ها را از نظر عملکردی بررسی و شبیه‌سازی می‌کنیم را سیستم های مدیریت فرآیند‌های کسب و کار یا Business Process Management Systems یا به اختصار BPMS گوییم. هدف این سیستم‌ها این است که فرآیند‌های موجود در سازمان همگرا و یکپارچه شوند تا در نتیجه افزایش رضایت کاربران را داشته باشیم. مدیریت فرآیند کسب و کار یا bpm چیست؟ حال که فهمیدیم BPMS یک سیستم مدیریت BPM است، سؤال پیش می‌آید که اصلا مدیریت فرآیند کسب و کار (BPM) یعنی چه؟ وبسایت kissflow که از پیشگامان مدیریت فرآیند‌های کسب و کار است، bpm را اینگونه تعریف می‌کند: مدیریت فرآیند کسب و کار (BPM) یک رشته سازمانی است که در آن یک شرکت یک گام به عقب برمی‌دارد و به همه این فرآیندها به طور کلی و جداگانه نگاه می‌کند، وضعیت فعلی را تجزیه و تحلیل می کند و زمینه های بهبود را برای ایجاد یک سازمان کارآمدتر و مؤثرتر شناسایی می کند. مدیریت فرآیند کسب و کار (BPM) یعنی چگونه یک سازمان فرآیند‌ها را ایجاد، ویرایش و تجزیه تحلیل می‌کند. این وظایف بین قسمت‌های مختلف سیستم تقسیم می‌شود و هر دپارتمان سازمان وظیفه کار بر روی داده‌ها را دارد. آیا BPM یک فرآیند مدیریت تسک یا پروژه است؟‌در جواب باید گفت خیر، BPM نه مدیریت تسک‌ها است (که بر وظایف فردی متمرکز است) و نه مدیریت پروژه (که جریان های یکباره یا غیرقابل پیش بینی را مدیریت می کند). مدیریت وظیفه در مورد مدیریت یا سازماندهی مجموعه ای از فعالیت هایی است که از یک پروژه ناشی می شود. این پروژه ها اغلب یک بار و غیرقابل تکرار هستند. هنگامی که این پروژه ها مانند کارهای ساختمانی به خوبی سازماندهی شده باشند، از یک نرم‌افزار مدیریت پروژه مانند "Microsoft Project" استفاده می‌شود. Trello، Asana یا Kissflow Project ابزارهای خوبی برای مدیریت وظایف در پروژه هستند. مدیریت فرآیند کسب و کار بیشتر بر فرآیندهای تکراری و مستمری متمرکز است که از یک الگوی قابل پیش بینی یا مدیریت فرآیند پیروی می کنند.چرا سازمان‌ها باید به سمت BPM حرکت کنند؟ مدیریت فرآیند‌های سازمانی دغدغه هر مدیری در سازمان است و اگر ابزار و روشی برای همسوسازی فرآیند‌های سازمانی وجود داشته باشد، مدیران با آغوش باز به استقبال آن‌ خواهند رفت. بنابراین استقبال از BPMS اصلا جای تعجبی ندارد. برای تاکید روی ضرورت استفاده از BPM ما برخی موارد را ذکر کرده‌ایم. فرآیند‌های غیرمتمرکز: در یک سیستم مدیریت متمرکز، قدرت به یک فرد یا گروهی از افراد، مثلا مدیرعامل یا اعضای هیئت مدیره محدود می‌شود. وقتی قدرت تصمیم‌گیری غیرمتمرکز باشد، سطوح پایین‌تری از مدیریت بیشتر در فرآیند تصمیم‌گیری درگیر می‌شوند و در نتیجه کیفیت کلی فرآیند بهبود می‌یابد. منطقی است که افرادی را که در واقع از فرآیندها استفاده می کنند در تصمیم‌گیری در مورد این فرآیندها بگنجانیم. این مهم است زیرا اطلاعات یک مدیر میانی می تواند برای تصمیم‌گیری یک مدیر ارشد مهم باشد. با تصمیمات متمرکز، ممکن است نظرات یا دیدگاه‌های بسیاری از متخصصین در سازمان نادیده گرفته شود.کشف جریان‌های کاری ناکارآمد:اولین کاری که باید پس از استفاده از BPM انجام دهیم این است که کشف کنیم در شرکت چه می‌گذرد. با انجام این کار، ممکن است متوجه شویم که داده‌ها یا فرآیند‌هایی تکراری در سیستم سازمان ما وجود دارد. به عنوان مثال، اگر یکی از اعضای شرکت نیاز به جستجوی چیزی داشته باشد و چندین ورودی مربوط به آنچه نیاز دارد پیدا کند، ممکن است گیج کننده باشد. با BPM یک شرکت می تواند این داده‌ها را تطبیق دهد. به جای حذف دستی، این ورودی‌ها را می‌توان در یک ورودی ادغام شود و افراد از سردرگمی‌ها نجات یابند.حذف کارهای تکراری:همانطور که در بخش قبلی اشاره شد، یکی از اهداف BPM بهبود و بهینه‌سازی فرآیند‌های سازمانی است. یکی از راه های انجام این کار استفاده از تجزیه و تحلیل برای حذف سیستم های تکراری غیر ضروری است. BPM به همگام سازی کارمندان کمک می کند. در واقع، BPMS به تجزیه و تحلیل عملیات یک کسب و کار کمک می کند و به جزئیاتی مانند هزینه های سیستم های متعدد توجه می کند. از آنجا، می‌توانیم با حذف سیستم‌های تکراری و ادغام بخش‌ها و تیم‌ها در همان سیستم‌های فناوری اطلاعات، به روش‌هایی برای بهبود و بهینه‌سازی این فرآیندها برسیم. این نه تنها باعث صرفه جویی در منابع می‌شود، بلکه گردش‌کار در سازمان کوتاه شده و ارتباطات در سطح سازمان را بسیار آسان تر می‌کند.افزایش شفافیتجمع آوری اطلاعات با BPM همچنین به ما کمک می‌کند تا شفافیت بین دپارتمان‌های سازمان را بهبود بخشید. فرض کنیم در سازمان ما دپارتمان A دستوراعمل‌هایی می‌دهد که دپارتمان B‌و C ملزم به رعایت آن‌ها هستند. درصورتی که ارتباط بین دپارتمان‌ها شفاف نباشد احتمالا هماهنگی کامل بین دپارتمان‌های سازمان ما نیز به وجود نیاید. BPM می‌تواند وضعیت را تجزیه و تحلیل کند و دستورالعمل هایی را برای هر دو بخش اجرا کند. این به آنها اجازه می دهد تا عملکرد منسجم تری در سازمانمان داشته باشیم و خروجی‌های بهتری داشته باشیم.مخزن اسناد یکپارچه: کسب‌وکاری که دارای یک مخزن اسناد بزرگ است ممکن است در درست نگه‌داشتن همه چیز مشکل داشته باشد - به‌ویژه در دوره‌های رشد سریع. چند دلیل وجود دارد که مجموعه BPM می تواند در این مورد به سازمان ما کمک کند. اول، می‌تواند به ذخیره و سازماندهی اسناد کمک کند و در عین حال امکان دسترسی با سطوح مختلف دسترسی به آنها را برای ویرایش فراهم کند. این اسناد معمولاً در ابر یا یک سیستم مرکزی نیز ذخیره می‌شوند و به کارمندان در سراسر بخش‌ها اجازه می‌دهند به آنچه نیاز دارند دسترسی داشته باشند. به طور همزمان، یک تجارت همچنین می‌تواند مراحل احراز هویت را برای محافظت از اسنادی اضافه کند که برای دیدن یا استفاده هر یک از اعضای شرکت در نظر گرفته نشده است.حال که فهمیدیم BPM و BPMS چیست بهتر است به مبحث اصلی برگردیم :))سیستم های مدیریت فرآیند‌های کسب و کار (BPMS) چه کارهایی می‌توانند انجام دهند؟ ایجاد فرآیندهای تجاری پیچیده را در بخش ها و مکان های مختلفپایش فرآیند‌های جاری در سازمان و محاسبه‌بهره‌وری فرآیندو درصورت امکان ایجاد تغییراتی برای افزایش بهره‌وری چگونه یک BPMS موفق ایجاد کنیم؟‌موفقیت در همگرایی فرآیند سازمان تنها با انتخاب سیستم مناسب به وجود نمی‌آید، بلکه پیاده‌سازی موثر و درست ما بیان می‌کن تا چه میزان BPMS موجب موفقیت درهمگرایی فرآیند‌های سازمان شده‌است. در ادامه چند مورد را ذکر می‌کنیم تا قبل از پیاده‌سازی یک BPMS بررسی کنیم. پلتفرم مورد استفادهفرآیندی که در سازمان‌های ما وجود داردفرآیند‌ها مربوط به چه سازمانی است و مالکیت آن برعهده کیست؟‌چه معیار‌هایی در سازمان وجود دارد؟‌گردش کار سازمان به چه صورت است و چه نمودارهایی دارد؟ همه ذی‌نفعان در سازمان درگیر فرآیند هستند؟ (چه میزان درگیر هستند؟)ادغام فرآیندها چقدر آسان و شدنی است؟ (قاعدتا هر چه آسانتر باشد بهتر است)کاربران چه میزان آموزش اولیه لازم دارند؟ (آیا در حین تعامل با سازمان آموزش داده می‌شوند؟)چگونه BPMS را ارزیابی کنیم؟ ارزیابی کارایی BPMS سازمان‌ما به المان‌های بسیاری وابسته است و برای این موضوع می‌توان شاخص‌های بسیاری را مدنظر قرار دهیم. اما برای نمونه ما ۳ مورد را ذکر می‌کنیم:‌مدلسازی انسان‌محور است یا برنامه‌نویسی-محور است؟ نرم‌افزار‌های انسان محور مانند Kissflow از یک رابط گرافیکی ساده استفاده می کند که به مدیران فرآیند غیرفنی اجازه می دهد فرآیند را به ساده ترین شکل ممکن ایجاد کند. مدیریت فرآیند‌ها در این‌گونه نرم‌افزارها در پس‌زمینه و توسط خود نرم‌افزار صورت می‌پذیرد. BPMN یک سیستم نشانه گذاری است که از نمادهای استانداردی برای نشان دادن رویدادها، فعالیت ها، وظایف، اتصالات و غیره استفاده می کند. تنها باید مدیر فرآیند‌ها این نماد‌ها را بشناسد و سیستم را براساس آن‌‌ها ایجاد کند. در ایجاد فرآیند به صورت برنامه‌نویسی، برنامه‌نویس کدی را توسعه می‌دهد تا بتوان فرآیند‌ها را ایجاد و مدیریت کند. این کار مهارت بالاتری نسبت به موارد قبلی را طلب می‌کند ولی درعوض امکان مدیریت پیچیدگی در فرآیند‌ها بسیار بالاتر می‌رود. سیستم‌ ابری است یا onpromise؟ نرم افزار ابری بر روی سرورهایی میزبانی می شود که از طریق یک مرورگر وب یا نرم‌افزار موبایلی از هر مکانی قابل دسترسی است. جدا از قابلیت دسترسی، BPMS مبتنی بر ابر مسئولیت مدیریت نرم افزار را نیز بر عهده فروشنده می گذارد. راه حل های ابری معمولاً در لایه SaaS ارائه می شوند. نرم افزارهای غیرابری بر روی یک سرور خاص نصب می شود. مزیت اصلی در محل این است که تمام داده های یک شرکت در داخل ذخیره می شود و به شرکت توانایی بیشتری برای محافظت و دسترسی به آن داده ها می‌دهد.نرم‌افزار اپن‌سورس است یا باید لایسنس خریداری کنیم؟‌ در راه‌حل منبع باز، نرم‌افزار کد را در اختیار عموم قرار‌داده است و با رعایت لایسنس نرم‌افزاری می‌توان سورس پروژه را تغییر داد و آن را مخصوص سازمان خود استفاده کرد و آن را در اختیار عموم قرار داد. در نقطه مقابل، نرم‌افزارهای غیررایگان وجود دارد که لایسنس آن‌ها حتما باید خریداری شود. یک BPMS چه ویژگی‌هایی باید داشته باشد؟ نمایش نمودار‌ها: گاهی بصری‌سازی داده‌ها به صورت نمودارها می‌تواند بهتر از هرچیز دیگری معنای اعداد را به مدیران و ذی‌نفعان سازمان انتقال دهد.قابلیت drag-and-drop: این ویژگی طراحی فرآیندهاو فرم‌ها را بسیار آسان می‌کند. کنترل دسترسی: در سازمان ذی‌نفعان متفاوت با سطوح مختلف دسترسی وجود دارد. وظیفه‌ یک BPMS این است که براساس سطح دسترسی افراد اطلاعات را برای نمایش یا تغییر در اختیار افراد قرار دهد. پشتیبانی از انواع دستگاه‌ها مثل تلفن‌های همراه: امروزه تلفن‌های هوشمند بسیار فراگیر و کارآمد شده است و لازم است BPMSها اتصال از طریق تلفن‌های هوشمند را پشتیبانی کنند. ابزارهای BPSMابزارهای خارجی: ابزار Kissflow: یک نرم‌افزار ساده است که بدون دانش برنا‌مه‌نویسی خاصی امکان ایجاد فرآیند‌ها و مدیریت آن‌ها را برای ما فراهم می‌کند. از قابلیت‌های آن می‌توان به داشبورد کاربر پسند، قالب‌های گزارش قابل تنظیم و طراحی فرم پیشرفته، اشاره کرد.ابزار process maker : ابزار process maker‌نیز امکان ایجاد و مدیریت فرآیند‌ها را بدون دانش برنامه‌نویسی خاصی برای افراد فراهم می‌آورد. چیزی که باعث تمایز در این ابزار می‌شود این است که قابلیت استقرار در ابر یا به صورت محلی در سرور‌های سازمان را دارا می‌باشد. ابزار Bizagi: ابزاری مبتنی بر نشانه‌گذاری‌های ‌BPMN است و براساس ابعاد و اهداف سازمان محصولاتی برای مدیریت فرآیندها پیشنهاد می‌دهد. این ابزار قابلیت استقرار در ابر و به صورت محلی را دارا است.ابزار‌های داخلی:مدیریت فرآیندهای کسب و کار بهفا: شرکت مشاوره مدیریتی بهین سازان فرآیند امین (بهفا) از ابتدای سال ۱۳۸۹ به منظور انجام پروژه‌های مشاوره و مدیریتی در سازمان‌های دولتی و خصوصی در قالب گروهی سازمان‌یافته با مدیریت دکتر مهرداد کرمانی فعالیت‌های خود را آغاز نمود. در سال‌های اخیر فعالیت‌های این گروه با ثبت شرکت بهفا گسترش پیدا کرده و پروژه‌های موفقیت‌آمیزی را انجام داده است. یکی از ابزار‌های موفق این گروه، ابزار مدیریت فرآیند‌های کسب و کار بهفا است که با ابزار اختصاصی و مشاوران این شرکت، BPM در سازمان به نحو شایسته‌ای پیاده‌سازی خواهد شد. این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی استمنابع https://kissflow.com/workflow/bpm/business-process-management-overview/ https://kissflow.com/workflow/bpm/business-process-management-overview/ https://www.process.st/bpms/ https://kissflow.com/workflow/bpm/business-process-management-systems-top-features/ https://kissflow.com/workflow/bpm/what-is-bpms/ https://kissflow.com/workflow/bpm/best-bpm-software/ Amirmohammad Amirmohammad Wed, 22 Dec 2021 19:03:53 +0330 https://virgool.io/@amir-mohammad/%D8%A2%D8%B4%D9%86%D8%A7%DB%8C%DB%8C-%D8%A8%D8%A7-%D8%AF%D8%A7%DA%A9%D8%B1-%D9%88-%DA%A9%D9%88%D8%A8%D8%B1%D9%86%D8%AA%DB%8C%D8%B2-vascpjytgskn مقدمهامروزه در هرجایی صحبت از داکر و کوبرنتیز درمیان است. بسیاری از شرکت‌ها به استفاده از این ابزار‌ها روی آورده‌اند و نیازمندیبسیاری از آگهی‌های استخدامی، تسلط بر این ابزار‌هاست. اما این ابزارها چیستند و چه کاری می‌کنند؟کانتینرو ماشین‌های مجازیقبل از شروع بهتر است تا مفهومی به نام کانتینر‌ آشنا شویم. کانتینر یک فرآیند (process) ایزوله شده‌است که کد و تمام دیپندنسی‌های کد راآن را ایزوله می‌کند تا برنامه به سرعت و با اطمینان از یک محیط اجرابه محیط دیگر اجرا، منتقلشود. برای درک کانتینر‌ها بیایید آن‌ها را با ماشین‌ها مجازی مقایسه کنیم. امروزه برای توسعه‌ی چابک‌تر سرویس‌ها به استفاده از میکروسرویس‌ها روی آورده‌ایم که در آن هر سرویس در یک بسته‌ ایزوله‌شده از بقیه اجرا می‌شود. در قدیم هر میکروسرویس را در یک ماشین مجازی اجرا می‌کردیم. ماشین مجازی یک کامپیوتر مجازی است که باعث می‌شود در یک کامپیوتر، تعدادی ماشین کوچکتر اجرا کنیم به گونه‌ای که تفاوت خاصی با کامپیوتر‌های فیزیکی نداشته باشد. استفاده از ماشین‌های مجازی مزیت‌هایی مثل clone کردن سریع یک ماشین یا عدم نگرانی از خرابی ماشین‌های مجازی (چون خرابی ماشین‌های مجازی هزینه‌ چندانی برای ما ندارد)، امکان بهینه‌سازی منابعو پایین آمدن هزینه‌نگه‌داری داشت، شرکت‌ها می‌توانندبا خرید سرور و نصب hypervisor بر روی آن، چندیدن ماشین همزمان برای خود داشته باشند. از آنجایی که این مرحله، ایجاد یک ماشین ارزانبود،هر سرویس در محیط مختص به خود اجرا می‌شدواز محیطی که توسط یک یا دو سرور تشکیل شده بود (همه در یک یا پایگاه داده + وب سرور) به معماری پیچیده‌تریحرکت کرده‌ایم. امروزه دسترسی به تعداد خدمات مرتبط در یک برنامه وب آسان است. پایگاه داده، API Backend، SPA Frontend، سرور ذخیره‌سازی، و داشتن ده سرویس بسیار مرسوم است. پس اگرچه ماشین مجازی راه حل خوبی است، اما راه حل بهینه‌ای نیست. اکنون ما به انعطاف بیشتر و مصرف کمتر منابع سخت‌افزاری به همراه توزیع وسیع‌تر نیاز داریم تا هزینه‌های کمتری متحمل شویم! برای پاسخ به این مسئله، ایده‌کانتیرها مطرح شد. مشکل این بود هر سرویس باید در سیستم‌عامل جدایی اجرا می‌شد که همین باعث می‌شد یک سرویس ساده فضای بسیاری را آشغال کند. همچنین گرفتن instanceها سریع نبود. ایده کانتیر این است که هر سرویس در یک یا چند پراسس ایزوله شده در سطح سیستم عامل اجرا شود تا هدر رفت منابع کاهش یابد و ساختن نمونه سریع‌تر صورت گیرد. داکر مفهوم کانتیر را اینگونه تعریف می‌کند:کانتینر یک واحد استاندارد نرم افزار است که کد و تمام وابستگی‌های آن را بسته بندی می کند تا برنامه به سرعت و با اطمینان از یک محیط به محیط دیگر اجرا شود. یک ایمیج Docker یک بسته نرم افزاری سبک وزن، مستقل و قابل اجرا است که شامل همه چیزهایی است که برای اجرای یک برنامه لازم است: کد، ران‌تایم،،کتابخانه های سیستم و تنظیمات.به عبارت ساده‌تر می‌توان گفت‌:کانتینر چیزی جز یک پراسس ایزوله شده نیست.در واقع ما در مفهوم کانتیر‌ها معتقدیم جداسازی در سطح سیستم‌عامل اتفاق بیافتد نه سخت‌افزار.مقایسه ماشین‌های مجازی و کانتیر‌هاماشین مجازی در مقابل کانتیراز نظر شخصی من این مقایسه چندان مناسب نیست. زیرا scopeهای متفاوتی هستند و بر هر حال کانتینر‌ها پراسس‌های یک ماشین مجازی می‌توانند باشند ولی از نظر امنیت و موارد دیگری، مقایسه را می‌توان انجام داد:‌+ سربار کمتر: از آنجایی که کانتینرها در یک سیستم عامل میزبان اجرا می‌شوند و از منابع و پراسس‌های آن استفاده می‌کنند، بنابراین سربار حافظه‌ و اجرای کمتری خواهند داشت. + زمان شروع کمتر: در کانتنر‌ها زمان شروع در حد میلی‌ثانیه است در حالی‌که در ماشین‌های مجازی این زمان شروع می‌تواند به دقیقه کشیده شود. -امنیت کمتر: به دلیل اینکه جداسازی در سطح سیستم‌عامل اتفاق می‌افتد. پس یک پراسس مخرب می‌تواند پراسس‌های درحال اجرا در سیستم عامل را ببیند و درصوت داشتن دسترسی آن پراسس را بکشد. یا اگر یک پراسس در حال اجرا باشد با آسیب‌پذیری‌هایی مثل فرار از کانتینر (Container Escape) از محیط ایزوله خود فرار کند (در مورد katacontainers و google gvisor بهتر است مطالعه کنید). داکر چیست؟‌داکر پرتکرارترین واژه‌ای است که امروزه در ارتباط با کانتینرها می‌شنویم. شرکت آمازون داکر را اینگونه تعریف می‌کند:داکر یک پلتفرم نرم‌افزاری است که به شما امکان می دهد تا برنامه ها را به سرعت بسازید، آزمایش کنید و اجرا کنید. Docker نرم‌افزار را در واحدهای استانداردی به نام کانتینرها بسته‌بندی می‌کند که همه چیزهایی را که نرم‌افزار برای اجرا نیاز دارد از جمله کتابخانه‌ها، ابزارهای سیستم، کد و زمان اجرا دارد. با استفاده از Docker، می توانید به سرعت برنامه ها را در هر محیطی استقرار و مقیاس بندی کنید و بدانید که کد شما اجرا خواهد شد.بنابراین داکر نرم‌افزاری است که از مفهوم کانتینر‌ها برای بالا بردن isolation ، قابلیت انعطاف و قابلیت حمل استفاده می‌کند. معماری داکر معماری داکرهمانگونه که در تصویر بالا می‌بینید، معماری داکر به صورت کلاینت-سرور است. که مشتری می‌تواند یک اپلیکیشن CLI باشد یا یک اپ تحت وب یا دسکتاپ که ارتباط از طریق REST API فراهم شده باشد. سرور داکر را اصطلاحا Docker Daemon نیز می‌گوییم. کلاینت و سرور می‌توانند در یک سیستم اجرا شوند و هم می‌توانند دو دوسرور متفاوت اجرا شود. در این مورد محدودیتی نداریم!مشتریان متفاوتی برای daemon وجود دارد که از بین آن‌‌ها می‌توانیم به docker build، docker pull برای دانلود و ساخت یک کانتینر داکری یا docker compose که برای ساخت و مدیریت مجموعه‌ای از کانتینرها در سیستم است، اشاره‌ کنیم. سرور (Daemon) داکربه درخواست‌های Docker API گوش می‌دهد و اشیایی که در داکر تعریف شده است مانند تصاویر، کانتینرها، شبکه‌ها و حجم‌ها را مدیریت می‌کند. یک دیمون همچنین می تواند برای مدیریت سرویس های Docker با دیگر دیمون ها ارتباط برقرار کند.مشتری مشتری داکر راه اصلی تعامل بسیاری از کاربران با سرور داکر است. وقتی از دستوراتی مانند docker run استفاده می کنید، کلاینت این دستورات را به dockerd می فرستد که آنها را اجرا می کند. دستور docker از Docker API استفاده می کند. مشتری داکر می تواند با سرورهای متفاوتی ارتباط برقرار کند.رجیستری رجیستری داکر ایمیج‌های داکر را ذخیره می کند. داکر هاب یک رجیستری عمومی است که همه می توانند از آن استفاده کنند و داکر به طور پیش فرض برای جستجوی تصاویر در داکر هاب پیکربندی شده است. شما حتی می توانید رجیستری خصوصی خود را اجرا کنید. این رجیستری برای ایران تحریم شده است و اگر قصد استفاده از رجیستری را دارید باید از فیلترشکن یا dns serverهای عمومی مثل شکن استفاده کنید. :))هنگامی که از دستورات docker pull یا docker run استفاده می کنیم، تصاویر مورد نیاز از رجیستری لوکال ما خارج می شوند. هنگامی که از دستور docker pull استفاده می‌کنیم، تصویر ما به رجیستری پیکربندی شده شما منتقل می شود و به صورت عمومی یا خصوصی در دسترس قرار خواهد گرفت. مولفه‌های داکرایمیج‌هاایمیج‌ها بلوک سازنده کانتینرهای داکری هستند. در واقع ایمیج‌ها پراسس‌های ایزوله‌شده ای هستند که در فضای‌نام خود می‌توانند تعدادی فایل یا پوشه یا حتی روت‌فایل‌های یک سیستم‌عامل را ببینند. راه‌هایی برای استفاده از ایمج‌ها است ولی در اینجا می‌خواهم به کاربرد Dockerfile اشاره کنم که برای ساخت یک ایمیج داکری به کار می‌رود. Dockerfile یک فایل متنی است که شامل تمام دستوراتی است که می‌توانیم در خط فرمان برای ساخت یک تصویر فراخوانی کنیم. با استفاده از docker build، کاربران می‌توانیم یک بیلد خودکار ایجاد کنند که چندین دستورالعمل خط فرمان را پشت سر هم اجرا می کند. نکته‌ مهم درباره ایمیج‌های داکر این است که این ایمیج‌ها فقط-خواندنی و به صورت لایه‌ای هستند. یعنی هنگامی که یک وب سرور node را در کانتینر اجرا می‌کنید. در لایه زیرین rootfs سیستم‌عامل قرار دارد و در لایه بالاتر node runtime نصب می‌شود و سپس در لایه‌های بالاتر از آن نیز اپلیکیشن ساخته می‌شود. کانتینر‌ها کانتینر یک نمونه قابل اجرا از یک ایمیج داکری است. می‌توانیم با استفاده از Docker API یا CLI یک کانتیر ایجاد، شروع، توقف، حرکت یا حذف کنیم یا یک کانتینر را به یک یا چند شبکه متصل کنیم. به طور پیش فرض، یک کانتینر به از سایر کانتینرها ایزوله شده و توانایی ارتباط با آن‌ها را ندارد برای ایجاد ارتباط لازم است یک شبکه مجازی ایجاد شود تا کانتینرها بتوانند یکدیگر را ببینند. نکته‌ای که درمورد کانتینر‌ها وجود دارد این است که حافظه‌ی تخصیص داده شده به آن‌ها پایدار نیست و با حذف شدن حافظه از بین می‌رود و برای ذخیره در سیستم‌عامل یا استفاده از حافظه مشترک توسط کانتینر‌ها باید volume ساخته شود. کوبرنتیزکوبرنتیز اصطلاحا یک پلتفرم Container Orchestration است که وظیفه‌ی مدیریت بارهای کاری را برعهده دارد. یک گروه ارکستر را در نظر بگیرید که وظایف مختلف و نقش‌های متفاوتی وجود دارد. وظیفه رهبر ارکستر این است که این هماهنگی را بین نقش‌های مختلف به وجود بیاورد تا در موقعیت هر نقش کار خودش را انجام دهد. بعضی وقت‌ها برخی نقش‌ها باید بیکار باشند یا با تمام قوا فعالیت کنند. کوبرنتیز برای مجموعه‌ای از کانتینر‌ها که در سیستم فعالیت می‌کنند چنین نقشی دارد. وبسایت کوبرنتیز خودش را اینگونه تعریف می‌کند. کوبرنتیز یک پلتفرم قابل حمل، توسعه پذیر و منبع باز برای مدیریت بارهای کاری و خدمات کانتینری است که هم پیکربندی و هم اتوماسیون را تسهیل می کند. چرا باید از کوبرنتیز استفاده کنیم؟ کانتینرها راه خوبی برای ایزوله کردن و اجرای برنامه های ما هستند. در محیط پروداکشن، باید کانتینرهایی را که برنامه ها را اجرا می کنند مدیریت کنیم و اطمینان حاصل کنیم که هیچ خرابی وجود ندارد. برای مثال، اگر ظرفی اصطلاحا down شود، ظرف دیگری باید راه‌اندازی شود. آیا اگر این رفتار توسط یک سیستم مدیریت شود، آسانتر نخواهد بود؟ به این ترتیب کوبرنتیز به کمک می آید! کوبرنتیز چارچوبی برای اجرای انعطاف‌پذیر سیستم های توزیع شده در اختیار ما قرار می‌دهد. از برنامه را به صورت خودکار scale می‌کند و مراقب خطاهایی که برنامه ما با آن‌ها مواجه می‌شود نیز هست، همچنین می‌توانیم برای استقرار اپ‌‌ها الگوهایی تعریف کنیم. به عنوان مثال، Kubernetes می تواند به راحتی یک سناریو استقرار به صورت rolling upgrade را برای سیستم ما مدیریت کند.چه قابلیت‌هایی از کوبرنتیز آن را با سایر پلتفرم‌های ارکستریشن متفاوت می‌کند؟ شناسایی سرویس (Service Discovery) و توزیع بار (Load Balancing): Kubernetes می تواند یک کانتینر را با استفاده از نام DNS یا با استفاده از آدرس IP خود در معرض نمایش قرار دهد. البته در این بین ابزار‌های معروفی برای آسانتر و موثرتر بودن این فرآیند به کمک آمده اند (برای مثال می‌توانید در مورد Istio مطالعه کنید). اگر ترافیک به یک کانتینر زیاد باشد، Kubernetes می‌تواند ترافیک شبکه را با بالاآوردن نمونه‌های دیگری توزیع کند تا استقرار پایدار باشد.حافظه‌ ذخیره‌سازی توزیع شده: Kubernetes به ما این امکان را می‌دهد که به طور خودکار یک سیستم ذخیره‌سازی مورد نظر خود را نصب کنیم، مانند ذخیره‌سازی های محلی، ارائه دهندگان ابر عمومی و موارد دیگر تا بتوانیم سناریو‌هایی برای ذخیره‌سازی داده‌ در سطح کلاستر داشته باشیم مانند ذخیره‌سازی توزیع شده یا گرفتن بک‌آپ از داده‌های ذخیره شده . عرضه و بازگشت خودکار (Automated rollouts and rollbacks ): می‌توانیم با استفاده از Kubernetes وضعیت مورد نظر را برای کانتینرهای مستقر شده خودمان را توصیف کنیم، و می‌توانیم این کار را به مرور انجام دهیم. هنگامی که بخواهیم به وضعیت قبلی نیز برگردیم می‌توانیم به صورت یک دفعه یا به مرور وضعیت برنامه را تغییر دهیم. به عنوان مثال، می‌توانیم Kubernetes را خودکار کنیم تا کانتینرهای جدیدی را برای استقرار خود ایجاد کند، کانتینرهای موجود را حذف کند و تمام منابع آنها را در کانتینر جدید بکار ببرد.خودترمیمی (Self-healing): Kubernetes کانتینرهایی را که از کار می‌افتند، مجدداً راه‌اندازی می‌کند، کانتینرها را جایگزین می‌کند، کانتینرهایی را که به بررسی سلامت (health check) تعریف‌شده توسط کاربر پاسخ نمی‌دهند، می‌کشد و تا زمانی که مشتریان آماده خدمت نیستند، آنها را برای مشتریان اکسپوز نمی‌کند.معماری کوبرنتیزمعماری یک کلاستر کوبرنتیزکوبرنتیز شامل یک یا چند نود مستر و تعدای نود کارگر است. نود‌های مستر در واقع مغز متفکر سیستم و مسئول توزیع‌بار یا اجرای سایر سناریو‌ها در سطح کلاستر ما هستند. کنترلر یا Control Plane: نام دیگر مستر control plane است که به وظایف کنترلی آن اشاره دارد. control plane از کامپوننت‌های متعددی تشکیل شده است که به شرح زیر است: سرور API‌ یا kube api server: همانگونه که از نامش مشخص است کامپوننتی برای برقراری نود‌های کارگر با سرور مستر از طریق این درگاه(gateway) استفاده می‌کنند. زمانبند (scheduler): زمانبند کوبرنتیز داده‌هایی منابع استفاده می‌کنند را ذخیره سازی می‌کند. سپس، تعیین می کند که آیا یک خوشه سالم است یا خیر. تعیین می کند که آیا کانتینرهای جدید باید مستقر شوند، و اگر چنین است، کجا باید قرار گیرند. زمانبند، سلامت نودهای خوشه و وضعیت منابع در هر یک را محاسبه می‌کند. در صورت نیاز به استقرار یا حذف یک نمونه، مورد مناسب را تعیین می‌کند.مدیر کنترل: به طور خلاصه کنترولر سروی است که خوشه کوبرنتیز را اجرا می‌کند، آن را مانیتور می‌کند و از طریق سرور API وضعیت مورد نظر و وضعیت فعلی آنها را مشاهده می کند. اگر وضعیت فعلی و مورد نظر اشیاء مدیریت شده مطابقت نداشته باشند، کنترل کننده اقدامات اصلاحی را انجام می دهد تا وضعیت آبجکت را به سمت وضعیت مطلوب ببرد.دیتابیس etcd :‌etcd یک پایگاه‌داده برای ذخیره‌سازی کلید-مقداری است که داده‌های پیکربندی و اطلاعات مربوط به وضعیت کلاستر را ذخیره می‌کند. etcd ممکن است به صورت خارجی پیکربندی شود.نودها: یک خوشه کوبرنتیز باید حداقل یک نود داشته باشد. نودها هماهنگ و برنامه‌ریزی شده‌اند تا روی گره‌ها اجرا شوند. نودها می‌توانند سرور‌های فیزیکی یا ماشین‌های مجازی در دیتاسنتر ما باشند. ران‌تایم‌ها: هر نودچرخه های عمر کانتینر را با استفاده از یک موتور زمان اجرا کانتینر اجرا و مدیریت می کند. از انواع ران‌تایم در کوبرنتیز استفاده می‌شود ولی معروف‌ترین ران‌تایم های حوزه کوبرنتیز عبارتند از docker، contaienrd و crio. کامپوننت kubelet: هر نود شامل یک Kubelet است، kubelet در واقع عاملی است که با کنترلر ارتباط برقرار می‌کند تا اطمینان حاصل شود که کانتینرهای یک pod در حال اجرا هستند. هنگامی که کنترلر نیاز به انجام یک عمل خاص در یک گره دارد، kubelet مشخصات pod را از طریق سرور API دریافت کرده و عمل را اجرا می کند. سپس تضمین می کند که کانتینرهای مرتبط سالم و در حال اجرا هستند.سرویس kube-proxy: هر نود حاوی یک کامپوننت پروکسی شبکه به نام kube-proxy است که خدمات شبکه کوبرنتیز را تسهیل می کند. kubeproxy مسئول فروارد کردن ترافیک برای پادهای در حال اجرا در شبکه است. پاد‌ها: پاد‌ها کوچکتر جز در معماری کوبرنتیز است. یک پاد یک نمونه از یک برنامه کاربردی و ساده ترین واحد را در کوبرنتیز نشان می دهد. با این حال، پادها برای کوبرنتیز مرکزی و حیاتی هستند. هر پاد از یک یا چند کانتینر تشکیل شده است که به طور منطقی با هم همراه هستند. در پادها قوانینی برای تعیین نحوه ارتباط و عملکرد کانتینر‌ها در آن داریم. این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهید بهشتی است.منابع https://www.docker.com/ https://www.backblaze.com/blog/vm-vs-containers/ https://www.netapp.com/devops-solutions/what-are-containers/ https://aws.amazon.com/docker/ https://docs.docker.com/get-started/overview/ https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/ https://avinetworks.com/glossary/kubernetes-architecture/ Amirmohammad Amirmohammad Mon, 20 Dec 2021 22:23:33 +0330 https://virgool.io/@amir-mohammad/%D8%A2%D8%B4%D9%86%D8%A7%DB%8C%DB%8C-%D8%A8%D8%A7-%D9%85%D8%AF%D9%84-c4-%D8%AC%D9%87%D8%AA-%D9%85%D8%B3%D8%AA%D9%86%D8%AF%D8%B3%D8%A7%D8%B2%DB%8C-%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-buknstsgqoeu مدل مستندسازی C4 برای اولین بار در سال 2006 توسط يکي از معماران نرم‌افزار به نام آقای سایمون براون ابداع شد. او ایده‌هایی برای بصری سازی معماری نرم‌افزار داشت، که در این مقاله به بررسی اجمالی آن‌ها خواهیم پرداخت.آقای سامون براون (Simon Brown) مبدع روش C4برای مستندسازی معماری نرم‌افزار چه مشکلاتی داشتیم؟‌در چرخه توسعه‌ی یک نرم‌افزار، بیشترین تمرکز بر روی کد پروژه است و این کاملاً منطقی است. چرا که خروجی آن همان محصولی است که تحویل مشتری داده‌ می‌شود. اما آیا اين منطقی است که توضیح یک سیستم را از کد آن شروع کنیم؟‌پرواضح است که شروع توضیح معماری سیستم از روی کد ایده چندان مناسبي نيست. از اين رو به‌جای کد، معماران شروع به توضیح معماری توسط علایم و اشکالی مانند نمودارهاي UML می‌کنند تا بتوانند معماری سيستم خود را به دیگران (و خودشان) بهتر بفهمانند. اما نمودارهای UMLمشکلاتی هم دارند، که از آن جمله مي توان به عدم آشنايي بسیاری از اعضای تیم با علایم UML نام برد. به همين دليل، معماران نرم‌افزار تلاش کردند تا طرح‌های ابتکاری خودشان بر روی کاغذ ارائه دهند. اما آیا این نمودارها برای تمامي افرادي که در پروژه نرم‌افزاری مشارکت دارند (اعم از برنامه‌نویس، طراح، مدیرمحصول و ...) قابل فهم هستند؟آیا معماری این سامانه نرم‌افزاری را به راحتی متوجه می‌شوید؟ اگرچه ممکن است خروجی این دیاگرام‌ها زیبا و شکیل باشد، اما همچنان برای درک سیستم کمک چندانی به ما نمی‌کند.بسیاری از نمودارهای معماری نرم‌افزار، اگرچه زیبا هستند اما در عمل کاربرد ندارند.بنابراین مي توان اينگونه برداشت کرد که نمودارهایی که امروزه برای بیان معماری نرم‌افزار گفته می‌شوند، چندان کاربردی نیستند و چه بسا باعث سردرگمی ديگران نیز بشوند.ایده آقای براون برای مستند‌سازی معماری نرم‌افزاراز نظر آقای براون ضرورتي ندارد که تمامي افرادی که درگیر یک پروژه معماری هستند به یک اندازه از معماری سیستم اطلاع داشته باشند. برای مثال برنامه‌نویس با توجه به اینکه درگیر پیاده‌سازی است، نیاز دارد تا بیشترین اطلاعات را از معماری سیستم داشته باشد. درحالی‌که لزومی ندارد تا مالک محصول بسیاری از جزئیات معماری نرم‌افزار را بداند. پس بهتر است معماری نرم‌افزار در قالب سطوح مختلفی بیان شود.از نظر آقای براون، زمینه فعالیت (context) ما یک سامانه نرم‌افزاری است که این سامانه از تعدادی کانتینر تشکیل شده است. در اینجا کانتینر به معنای فرآیند ایزوله شده در سطح سیستم‌عامل - همان مفهومی که داکر بیان می‌کند- نیست. بلکه به معنای یک اپلیکیشن مستقل است که تحت این سامانه فعالیت می‌کند(مانند یک وب اپلیکیشن یا موبایل اپلیکیشن). درون هر کانتینر نیز تعدادی کامپوننت درون فعالیت‌ هستند که تجمیع آن‌ها برابر با عملکرد کانتینر است. مثل میکروسرویس‌هایی که درون یک وب اپلیکیشن اجرا می‌شوند. اما خود این کامپوننت ها نیز از قطعه‌های کد تشکیل شده اند. این قطعات می‌توانند توابع یا کلاس‌ها باشند.سطوح معماری نرم‌افزار از نظر سایمون براونبراون سیستم‌ نرم‌افزاری را به ۴ سطح از انتزاع تقسیم می‌کند که هر سطح دانه‌بندی متفاوتی با سطح دیگر در بیان معماری نرم‌افزار دارد. او این ایده در توصیف معماری سیستم را به نام مدل C4، یعنی Context، Container، Component و Code تقسیم کرد.خلاصه مدل C4مدل مستندسازی C4تصویر فوق، نمایانگر سطوح انتزاع در مدل C4 است که خلاصه آن به شرح زیر است:‌ زمینه (Context): یک نمودار با سطح انتزاع بالا است که برای ما اسکوپ پروژه را مشخص می‌کند و نیازمندی‌ها و بازیگران اصلی سیستم را به ما نشان می‌دهد و سعی می‌کند به این سؤالات پاسخ دهد : سیستم‌ نرم‌افزاری که می‌خواهیم بسازیم چیست؟چه کسانی از این سیستم استفاده می‌کنند؟سیستمی که قرار است ساخته شود در کجای کسب و کار ما قرار می‌گیرد؟کانتینر (Container): در لایه‌ي container یک قسمت از سیستم که در سطح context نمایش داده شده است، تشریح می‌شود. یک کانتینر دیاگرام تاحدی مشخص می‌کند که از چه تکنولوژی‌هایی در پروژه استفاده کرده‌ایم، مسئولیت‌ها چگونه توزیع شده‌است و کانتینرها چگونه با یکدیگر ارتباط برقرار می‌کنند. نمودار کانتینر سعی دارد که به این سؤالات پاسخ دهد:معماری کلی سیستم چیست؟چه تصمیمات سطح بالایی اتخاذ شده است؟چگونه وظایف در سیستم توزیع شده است؟کانتینر‌ها چگونه با هم ارتباط برقرار می‌کنند؟هر ویژگی باید در کجا پیاده‌سازی شود؟کامپوننت (Component): هر کانتینر از چندین کامپوننت تشکیل شده‌ است. در سطح مولفه، جزئیات کامپوننت را موشکافانه بررسی می‌کنیم. این بررسی شامل شناسایی اجزای اصلی یک کامپوننت و روابط بین آن‌ها می‌شود. سطح کامپوننت سعی در پاسخ‌گویی به این سؤالات دارد:سیستم از چه اجزا و خدماتی تشکیل شده است؟روشن است که چگونه سیستم در سطح بالا کار می کند؟کد (Code): هر کامپوننت توسط واحد‌های کد پیاده‌سازی می‌شود که پایین‌ترین سطح انتزاع در مدل C4 است. کدها معمولاً در قالب نمودار‌های UML بیان می‌شوند و سطح پیچیدگی این نمودارها به درجه سختی پروژه یا تجربه تیم بستگی دارد.براي درک بهتر موارد فوق را به مثال زير توجه کنيد:فرض کنيد مي خواهيم معماری یک سیستم بانکی انتزاعی را با C4 نمایش دهیم.زمینه (Context):نمودار زمینه برای یک سیستم اینترنت بانک فرضیهمانطور که گفتیم، سطح context بالاترین سطح انتزاع را بین بازیگران سیستم مشخص می‌کند. تصویر بالا، ارتباط مشتریان با سیستم بانکی که جهت انجام امور مختلف مانند نمايش صورت حساب و پرداخت استفاده می‌شود را نشان مي دهد. برای این‌کار نرم‌افزار بانکداری اینترنتی از سامانه mainframe بانک که از قبل پیاده‌سازی شده است، استفاده می‌کند. برای ارسال ایمیل نیز، از یک سامانه ارسال ایمیل استفاده شده که قبلاً پیاده‌سازی شده است. این را از رنگ‌های اشکال در جدول متوجه می‌شویم. رنگ خاکستری به معنای سامانه‌های از قبل پیاده‌سازی شده است و رنگ آبی به معنای سامانه‌ای است که قرار است پیاده‌سازی شود.کانتینر (Container):در سطح کانتینر، قسمتی از سیستم بانکداری را باز می‌کنیم. سامانه بانکداری از کانتینر‌های متفاوتی تشکیل شده است. کانتینر در اینجا به معنای برنامه‌های موبایل، کنسول، وب یا … است.دیاگرام کانتینر برای سامانه بانکداری اینترنتیبرای مثال، سامانه بانکداری ما از موبایل اپ، اپلیکیشن تک صفحه‌ای (SPA) ، پایگاه‌ داده و API اپلیکیشن تشکیل شده است. هر کدام از این موارد یک کانتینر هستند و روابط بین آن‌ها نیز در نمودار مشخص شده است. برای مثال کانتینر موبایل اپ اینترفیسی برای کار با سیستم بانکداری اینترنتی برای مشتریان فراهم می‌کند و برای پرداخت یا ارسال ایمیل، از کانتینر API استفاده می‌کند. برای ادامه در سطوح پایینتر، کانتینر API را مورد بررسی قرارمی‌دهیم.مولفه (Component):اجزای دیاگرام مولفه در کانتینر API Application همانطور که مشاهده می‌شود، کانتیر API Application از چندین کامپوننت شامل، کامپوننت‌های ایمیل، امنیتی، ارتباط با سامانه Mainframe و … تشکیل شده است که ارتباط این کامپوننت‌ها در سطح کامپوننت نشان داده می‌شود.کد (Code):دیاگرام کد، بزرگنمایی محتویات درون یک کامپوننت استجزئیات سطح کد شیوه پیاده‌سازی کامپوننت را مشخص می‌کند. سطح کد معمولاً با نمودار‌های UML نمایش داده می‌شود. به توصیه طراح C4، این سطح از جزئیات تنها براي مهم ترین یا پیچیده ترین اجزا توصیه می‌شود. تصویر فوق، شیوه پیاده‌سازی کامپوننت ارتباط با Mainframe بانک در کانتینر API Application را نشان می‌دهد.نشانه‌گذاری ها در C4:مدل C4 نمادی رسمی برای نشانه‌گذاری ندارد. C4 سعی در ساده کردن نماد‌ها دارد تا بتوان در هر جا معماری را به سادگی رسم کرد. البته تیم‌ها می‌توانند با استفاده از نشانه‌های UML یا نشانه‌های ابداعی خودشان در سطوح مختلف، مستندسازی معماری نرم‌افزار را انجام دهند.نشانه‌گذاری‌های پیشنهادی توسط C4در C4 تنها الزام به نوشتن نام نمودارها است اما بسیار توصیه می‌شود که برای هر نمودار توضیحی ذکر شود. ضمناً اگر برای توصیف نمودار از اشکال قراردادی استفاده می‌کنیم، لازم است حتما توضیحی برای آن‌ها نوشته شود.چه ابزار‌هایی جهت رسم دیاگرام‌ها وجود دارد؟‌تقریبا تمامی ابزارهای عام منظوره جهت رسم نمودار‌های مهندسی نرم‌افزار. منتها توصیه می‌شود که از ابزارهای عام‌منظوره‌ای مانند draw.io، gliffy یا visio استفاده نشود. به جای آن ابزار‌های خاص منظوره‌ای که معرفی می‌کنیم استفاده کنید. C4 Plant UMLStructurizrاین مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهید بهشتی است.منابع: https://c4model.com/ https://www.infoq.com/articles/C4-architecture-model/ https://www.youtube.com/watch?v=x2-rSnhpw0g https://structurizr.com/ Software Architecture for Developers [Vol 1 - 2015 Edition] Amirmohammad Amirmohammad Thu, 18 Nov 2021 00:37:21 +0330