https://virgool.ir/feed/@msdehghan77دانشجوی کارشناسی ارشد نرم‌افزار دانشگاه شهید بهشتی. عاشق برنامه‌نویسیfa2026-11-12 02:27:12https://files.virgool.ir/upload/users/18102/avatar/FRf26a.jpeghttps://virgool.ir/@msdehghan77https://virgool.ir/@msdehghan77/metrics-based-on-code-review-yj2k3og5jvsnمقدمهیکی از دغدغه‌ها و نگرانی‌های هر سازمان نرم‌افزاری، نگهداری و توسعه‌ی نرم‌افزارها به گونه‌ای مفید و کارآمد است. مدیران دوست دارند در عین اینکه نرم‌افزار رشد و توسعه پیدا می‌کند، هزینه‌های توسعه‌ی آن نیز کم باشد و هزینه‌ی توسعه با گذشت زمان زیاد نشود. در این پروژه ما سعی میکنیم با جمع‌آوری داده و معرفی سنجه های مختلف، معمار نرم‌افزار و مدیران را در این مسیر یاری کنیم.چرا اطلاع داشتن از سنجه‌های توسعه نرم‌افزار برای توسعه‌ی بهتر حیاطی است؟هرچقدر از عمر یک نرم‌افزار می‌گذرد، تعداد مولفه‌ها و حجم کدهای آن بیشتر می‌شود و نگهداری آن‌ها نیز سخت‌تر می‌شود. با زیاد شدن حجم کد، تعداد افرادی که به کل کدها مسلط هستند کمتر می‌شود. همچنین ریسک جدا شدن یک یا چندنفر از تیم نیز اگر مدیریت نشود ممکن است برای پروژه به ایجاد بجران منجر شود. با گذشت زمان اضافه کردن قابلیت‌های جدید به نرم‌افزار دشوارتر می‌شود چراکه برنامه‌نویس باید درک درستی از کدها داشته باشد و مکان قابلیت جدید در کدها را به خوبی جانمایی کند و سپس به توسعه‌ی کدها در محل لازم بپردازد.در صورتی که به توسعه‌ی نرم‌افزار و فرایند آن به اندازه‌ی کافی توجه نشود، با گذشت زمان رضایت برنامه‌نویسان و مدیران از محصول پایین می‌آید. برنامه نویسان هرچقدر تلاش می‌کنند نمی‌توانند قابلیت جدید را با سرعت دلخواه به سیستم اضافه کنند و با اینکه کسی کم‌کاری نمی‌کند و همه در حال کار کردن هستند اما سرعت توسعه‌ی قابلیت‌های جدید به مرور کمتر می‌شود.رضایت مدیران از محصول به این دلیل کاهش می‌یابد که به نسبت هزینه‌ای که برای محصول می‌کنند، خروجی مناسب دریافت نمی‌کنند. برای مثال اگر یک نرم‌افزار در ابتدای شروع کار با یک تیم سه نفره به سرعت قابلیت و ویژگی‌های جدید پیاده‌سازی می‌کرده است، الان با یک یا چند تیم ده نفره نمی‌تواند به سرعت قبل قابلیت اضافه کند. مدیران باید هزینه‌ی بیشتری کنند در عین اینکه خروجی متناسبی دریافت نمی‌کنند.امروزه در دنیا نرم‌افزارهایی هستند که بیش از ۲۰ سال است که درحال توسعه هستند. زنده و سالم نگه‌داشتن چنین محصولاتی نیاز مند به توجه و داشتن درک صحیح از وضعیت پروژه و محصول است. مدیر و معمار نرم‌افزار باید هرازگاهی وضعیت تیم را بررسی کنند و مسیر حرکت محصول را با توجه به آن ارزیابی کنند. برای پیدا کردن درک صحیح از وضعیت محصول، معمار نرم‌افزار نیازمند متریک‌ها و سنجه‌های مختلفی از عملکرد تیم است تا بتواند دیدکلی از وضعیت و روند توسعه‌ی محصول و تیم پیدا کند.در این پروژه سعی کرده ایم اطلاعات چند پروژه نرم‌افزاری را دریافت کرده و بر مبنای آن تحلیل‌های مختلفی را در خدمت معمار و مدیر پروژه قرار دهیم.اهمیت اطلاعات بازبینی‌کد در ارائه‌ی سنجه‌های مختلفامروزه استفاده از بازبینی‌کد در توسعه‌ی نرم‌افزار به عنوان یکی از به‌روش‌(Best Practice) های بسیار کارآمد شناخته می‌شود. این امر در دهه‌ی اخیر بین پروژه‌ها و شرکت‌های نرم‌افزاری به صورت جدی دنبال می‌شود. اهمیت بازبینی کد به حدی است که سرویس‌های معروفی مثل GitHub و GitLab نیز این خدمات را به صورت رایگان در اخیار کاربران خود قرار می‌دهند.بازبینی‌کد باعث کاهش خطا و تضمین کیفیت نرم‌افزار می‌شود. به صورت کلی بازبینی‌کد به فرایند توسعه‌ای گفته می‌شود که تمامی کدهای نوشته شده در یک محصول توسط فردی به جز نویسنده‌ی اصلی، بررسی و بازبینی شده و سپس با تایید بازبین کد، تثبیت شده و در محصول قرار گیرد.اطلاعات حاصل از بازبینی‌کد مرجع بسیار خوبی برای انجام تحلیل و استخراج سنجه‌های مختلف از عملکرد تیم و فرایندهای آن است. باتوجه به اینکه تمامی کدهای محصول از فرایند بازبینی‌کد رد شده و بازبینی می‌شوند، اطلاعات حاصل از بازبینی کد در گذر زمان می‌تواند به ما دید بسیار خوبی از نحوه‌ی توسعه‌ی نرم‌افزار و تیم بدهد.با تحلیل این اطلاعات ما میتوانیم در هر زمان برای تیم و محصول سنجه‌های مختلفی تولید کنیم و با مقایسه‌ی این سنجه ها با دیگر پروژه‌ها یا با گذشته‌ی پروژه خودمان، متوجه مسیر طی شده شویم. برای مثال اگر سنجه‌ها نسبت به سال قبل بهتر شده‌اند پس تیم در مسیر درستی در حرکت است ولی اگر این سنجه‌ها بدتر شده‌اند، زنگ خطری برای مدیر تیم و معمار نرم‌افزار است که تیم در جهت درستی حرکت نمی‌کند.معرفی سیستم بازبینی کد Gerritگریت یکی از ابزارهای معروف و متن‌باز در زمینه‌ی بازبینی کد است که عمدتا توسط گوگل توسعه داده می‌شود. محصولات بسیار معروفی از جمله Android و GoLang و ... با گریت توسعه داده می‌شوند. در این پروژه Gerrit را به عنوان سیستم هدف خود قرار داده و سعی کردیم داده‌های گریت را به خوبی استحراج کنیم.نمونه‌ای از محصولاتی که از گریت استفاده می‌کنند:مجموعه‌ی Eclipseمجموعه‌ی OpenStackمدیاویکیپروژه‌ی Qtیک درخواست بازبینی در گریت Eclispeجمع‌آوری اطلاعاتدر این پروژه، crawlerای برای گریت نوشتیم تا بتوانیم اطلاعات پروژه‌های مختلف را دریافت و ذخیره‌سازی کنیم. در این مدت اطلاعات دو مخزن Eclispe و Qt جمع‌آوری شدند. از مخزن اکلیپس ۴۹ هزار درخواست‌ بازبینی دریافت شد که شامل اطلاعات کامل بازبینی‌ها از سال 2019 تا 2022 می‌شود. همچنین برای نمونه تاریخچه‌ی کامل پروژه‌ی JGit که یکی از محصولات اکلیپس است را جمع‌آوری کردیم که شامل اطلاعات تمامی درخواست‌های بازیبنی از سال ۲۰۱۰ تاکنون است. از مخزن Qt نیز ۵۲ هزار درخواست بازبینی جمع‌آوری شد که شامل درخواست‌های بازبینی از سال 2021 تا 2022 است. برای نمونه از محصولات Qt نیز QtCreator انتخاب شد و تاریخچه‌ی آن به صورت کامل از بتدا تاکنون استحراج شد. این تاریخچه شامل اطلاعات بازبینی کد از سال ۲۰۱۳ تاکنون است.در این گزارش به صورت خاص بر روی دو محصول JGit و QtCreator کار کردیم و سعی کردیم سنجه‌های مناسبی را از این اطلاعات استخراج کنیم. برای هر سنجه دلیل انتخاب آن و تحلیلی که می‌توان از آن داشت را نیز ارائه داده‌ایم. امید داریم که این سنجه‌ها بتواند در عمل دید مناسبی به معماران و مدیران پروژه بدهد و آن‌ها را در راهبرد پروژه یاری دهد.اطلاعات جمع‌آوری شده و نحوه‌ی ذخیره‌ی آن‌هابعد از جمع‌آوری اطلاعات به صورت فایل‌های JSON، سعی کردیم اطلاعات آن‌را به صورت SQL مدل کنیم و برای آن شمای مناسبی استخرراج کنیم و تمامی اطلاعات جمع‌آوری شده را در پایگاه‌داده‌ی MySQL ذخیره کنیم. عکس زیر شمای کاملی از اطلاعات پایگاه داده را نشان می‌دهد.شمای پایگاه‌داده‌ی اطلاعات جمع‌اوری شده از مخازن بازیبنی‌کدهمانطور که در شما نیز مشخص است، به ازای هر درخواست بازبینی ،اطلاعاتی شامل تعداد خط‌های تغییر کرده، تعداد کامنت‌ها و تاریخ دقیق شروع و پایان استخراج شده است. همچنین لیست کامل تغییرات به همراه فایل‌های تغییر کرده در هر نسخه موجود است. از دیگر اطلاعات مهم می‌توان به لیست افراد بازبین و امتیازهایی که به هر درخواست داده اند اشاره کرد.ارائه‌ی سنجه و تحلیلپس از اینکه این اطلاعات به صورت کامل جمع‌آوری و ذخیره شدند، بر روی آن‌ها تحلیل‌هایی ارائه کردیم که در زیر آورده شده اند.تعداد چنج‌های ثبت شده در هر سالتعداد درخواست های بازبینی ثبت شده به تفکیک سال در پروژه‌ی JGitشکل بالا تعداد درخواست های بازبینی ثبت شده به تفکیک سال در پروژه‌ی JGit را نشان می‌دهد. همانطور که مشخص است این پروژه از سال ۲۰۱۲ رشد خود را شروع کرده و در سال ۲۰۱۸ به اوج خود رسیده است اما ناگهان در سال ۲۰۱۹ شروع به افت کرده و در سال ۲۰۲۰ تعداد درخواست‌های ثبت شده به کمتر از نصف رسیده است به گونه‌ای که تعداد درخواست های ثبت شده در ۲۰۲۰ حتی از سال ۲۰۱۵ نیز کمتر شده است! اما چه چیزی ممکن است چنین تاثیر بزرگی بر پروژه بگذارد؟متاسفانه در سال ۲۰۱۸ یکی از اصلی‌ترین برنامه‌نویس های پروژه‌ی JGit از دنیا می‌رود. با مرگ ناگهانی یک برنامه‌نویس حرفه‌ایی و قدیمی فشار زیادی به دیگر اعضای تیم وارد می‌شود چرا که دیگران به اندازه او به کدها مسلط نیستند و درخواست‌های بازبینی بیش از اندازه طول می‌کشند. از اکثر وقت توسعه دهندگان به ریویو و مسلط شدن به کدهای پروژه می‌گذرد و دیگر وقتی برای اضافه کردن قابلیت برای آن‌ها نمی‌ماند و همین باعث می‌شود که توسعه‌ی این پروژه به صورت قابل توجهی کند شود! واضح است که رفتن یک برنامه نویس چه تاثیر عظیمی بر یک پروژه نرم‌افزاری بزرگ و قدیمی دارد.حجم کد اضافه شده و کم شده در هر سالنمودار تعداد خط کدهای اضافه شده(آبی) و حذف شده(قرمز) از پروژه JGIT به تفکیک سالنمودار بالا تعداد خط های اضافه شده و کم شده در هر سال در پروژه‌ی JGit را نشان می‌دهد. همانطور که مشخص است تعداد خط‌های اضافه شده با شیب نسبتا خطی در حال زیاد شدن که نشان از سلامت و چابکی پروژه دارد.اگر به نمودار دقت کنید متوجه می‌شوید که در سال ۲۰۲۰ تعداد زیادی کد از پروژه به صورت غیر عادی حذف شده است. با توجه به نمودار احتمالا در سال ۲۰۲۰ یک تغییر معماری یا ریفکتور کردن بزرگی اتفاق افتاده است. این احتمال نیز می‌رود که برخی از مولفه‌های قدیمی، منقضی شده و از پروژه حذف شده باشند.تعداد برنامه‌نویسان و بازبین‌ها در هر سالنمودار تعداد برنامه‌نویس(سبز) و بازبین(آبی) به تفکیک سال در پروژه JGitنمودار بالا تعداد برنامه‌نویس‌ها و بازبین‌ها در هر سال را نشان می‌دهد. این پروژه تا سال ۲۰۱۹ به خوبی پیش رفته و هر سال تعداد افرادی که به پروژه contribute می‌کردند بیشتر شده است. در سال ۲۰۱۹ این عدد ریزش جدی داشته اشت. پروژه در سال ۲۰۱۹ توانسته برنامه‌نویس‌های بیشتری را جذب کند.یکی از ریسک‌های جدی برای این پروژه تعداد افراد فعال در آن است. همانطور که مشخص است هم تعداد برنامه‌نویس‌ها و هم تعداد بازبین‌های کد از سال ۲۰۱۹ در حال کاهش است و این کاهش ریسک پروژه را هر ساله بیشتر و بیشتر می‌کند. برای همین بهتر این پروژه به دنبال جذب برنامه‌نویس باشد.میزان زمانی که طول می‌کشد تا یک درخواست تثبیت شودنمودار Box Plot از میزان زمانی(ساعت) که طول می‌کشد یک درخواست تثبیت شود در پزوژه‌ی JGitنمودار Box Plot بالا به تفکیک سال، زمانی که طول می‌کشد تا یک چنج تثبیت شود به ساعت را نشان می‌دهد. هرچقدر این زمان کمتر باشد، چنج‌ها سریع‌تر ثبت شده و بهتر است. هماطور که در نمودار مشخص است در سال ۲۰۱۸ بهترین عملکرد را شاهد بودیم به گونه‌ای که ۵۰ درصد درخواست‌ها زیر یک روز و ۷۵ درصد درخواست‌ها زیر دو روز ثبت شده اند.میانه‌ی این اعداد در سال‌های مختلف تقریبا ثابت بوده است و به طور متوسط نصف تغییرات زیر یک روز ثبت می‌شوند. اما چهارک سوم تغییرات زیادی به خود دیده به گونه‌ایی که از سال ۲۰۱۸ تا ۲۰۲۰ از عدد ۴۰ به ۲۰۰ ساعت رسیده است که این به معنای پسرفت پروژه در فرایند بازبینی کد است. بهتر است تغییرات به گونه‌ای باشند که کمتر طول بکشند و اگر تغییری خیلی بزرگ است، بهتر است آن‌را به تغییرات کوچک‌تر بشکنیم.نسبت تعداد خط‌های تغییر یافته به تعداد افرادنمودار بالا نسبت تعداد خط کدهای تغییر پیدا کرده به تعداد برنامه‌نویس‌های فعال را به تفکیک سال نشان می‌دهد. همانطور که مشخص است هرچقدر زمان گذشته، به طور متوسط افراد تغییرات بیشتری را در پروژه داده‌اند که البته طبیعی است چرا که بیشتر به کد مسلط می‌شوند و سریع‌تر می‌توانند تغییرات را انجام دهند.اما قضیه از آنجایی خطرناک می‌شوند که تعداد برنامه نویسان هز سال کمتر شده ولی این نسبت تغییری نکند یا بزرگ تر شود. برای مثال در نمودارهای قبلی دیدیم که سه سال آخر تعداد برنامه‌نویسان فعال بسیار کم شده است اما در اینجا مشخص است که حجم کد تغییر یافته بیشتر شده است! این بدان معنی است که تعداد کمی آدم‌های باتجربه در پروژه هستند که تغییرات بسیار بزگی می‌دهند و هرکدام از این افراد که از پروژه جدا شود آسیب سنگینی به پروژه وارد خواهد شد.جمع‌بندیدر این مقاله به اهمیت توجه به نگهداری و توسعه‌ی نرم‌افزار پرداختیم و دیدیم که اگر برای توسعه‌ی نرم‌افزار برنامه ریزی نداشته باشیم ممکن است هزینه‌های سنگینی را متحمل شویم. به همین دلیل داشتن دیدکلی از پروژه و در دست داشتن سنجه‌های به عنوان معیار اندازه گیری لازم است. سپس به معرفی بازبینی کد و اهمیت داده‌های بازبینی در توسعه‌ی پروژه پرداختیم و با تحلیل این داده‌ها پنج سنجه‌ی کاربردی را ارائه کردیم.این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است.منابعhttps://git.eclipse.org/r/https://www.gerritcodereview.com/Martin, Robert C. Clean Architecture : A Craftsman’s Guide to Software Structure and Design. Boston Columbus Indianapolis New York San Francisco Amsterdam Cape Town Dubai London Madrid Milan Munich Paris Montreal Toronto Delhi Mexico City São Paulo Sydney Hong Kong Seoul Singapore Taipei Tokyo, Prentice Hall, 2018.محمدصادق دهقانمحمدصادق دهقانSun, 13 Feb 2022 00:51:01 +0330https://virgool.ir/@msdehghan77/message-queue-zbnggw4wl4gaمقدمهاگر در زمینه‌ی سیستم‌های توزیع‌‌شده کار کرده باشید حتما اسم صف و Message Queue به گوشتان خورده است. امروزه نقش Message Queue ها در نرم‌افزارهای بزرگ و توزیع شده بسیار پررنگ شده است به گونه‌ایی که اکثر شرکت‌های بزرگ نرم‌افزاری از جمله Google، LinkedIn و ... از Message Queue های مختلفی استفاده می‌کنند یا Message Queue مخصوص خود را توسعه داده‌اند.در این مقاله با مفهوم صف و Message Queue آشنا می‌شویم و انواع و کاربردهای آن را می‌بینیم. همچنین به معرفی دو ابزار خیلی معروف و مهم در این حوزه می‌پردازیم و مزایا و معایب هرکدام را بررسی می‌کنیم.صف یا Message Queue چیست؟یک Message Queue ابزاری است که به عنوان صفی از پیام‌های مختلف که بین چند سرویس محتلف ارسال می‌شود استفاده می‌شود. این ابزار نوعی ارتباط سرویس به سرویس از جنس async را ارائه می‌دهد که معمولا در سیستم‌های توزیع شده مثل معماری مایکروسرویس و یا معماری Server less کاربرد دارد. در Message Queue ها ارسال کننده‌ی پیام و دریافت کننده‌ی آن نیازی ندارند که باهم در یک زمان ارتباط برقرار کنند و پاسخ یکدیگر را بدهند بلکه ارسال کننده می‌تواند پیام‌های خود را درون صف بگذارد و مصرف کننده هر زمان که لازم بود بیاید و این پیام‌ها را از صف بخواند و پردازش کند.در ترمینولوژی Message Queue ها به سرویسی که پیام‌ها را ارسال می‌کند producer و به سرویسی که روی صف منتظر پیام جدید می‌ماند و پیام‌های جدید را مصرف می‌کند Consumer می‌گویند. در واقع ارتباط بین producer و comsumer بدین گونه است که یک سرویس پیام‌ها را در صف ارسال می‌کند و دیگری روی صف گوش می‌دهد و منتظر پیام جدید می‌ماند. زمانی که پیام جدید برسد مصرف کننده آن‌را دریافت کرده و به Message Queue خبر می‌دهد که پیام پردازش شده است.کاربردهای Message Queueابزارهای Message Queue استفاده‌های مختلفی دارند. یکی از استفاده‌های آن‌ها برای زمانی است که سرعت تولید داده با سرعت پردازش‌ آنها یکسان نیست و ممکن است زمان‌هایی سرعت تولید از مصرف بیشتر شود. در چنین سناریوهایی از Message Queue ها به عنوان بافر استفاده می‌شود. تولید کننده می‌تواند پیام‌ها را به صف ارسال کند و منتظر پردازش داده نماند و به کار خود ادامه بدهد. از طرفی مصرف کننده نیز می‌تواند با سرعت لازم پیام‌ها را مصرف کند. در این صورت در زمان‌هایی که سرعت تولید داده از مصرف بیشتر است پیام‌ها در صف باقی می‌مانند تا اینکه مصرف کننده به آن‌ها برسد و زمانی که سرعت تولید داده کمتر از مصرف بشود، مصرف کننده می‌تواند صف را خالی کند و کل پیام‌ها را پردازش کند. به اصطلاح برای جاهایی که spikey load داریم استفاده از Message Queue ها می‌تواند مفید باشد.کاربرد دیگر Message Queue ها برای پردازش دسته‌ایی یا Batch by batch داده‌ها است. بدین گونه که داده‌ها درون Message Queue اضافه می‌شوند و زمانی که به حد مشخصی برسند توسط مصرف کننده به صورت یکجا و دسته‌ایی پردازش می‌شوند. پردزاش دسته‌ایی معمولا برای بالا بردن Throughput و سرعت و عملکرد بهینه کاربرد دارد.همچنین در فضاهای ابری و برنامه‌هایی که به صورت توزیع شده کار می‌کنند، Message Queue ها کاربردی هستند. در این فضاها برای انتقال پیام از یک سرویس به سرویس دیگر می‌توان از صف استفاده کرد. استفاده از صف امکان fault tolerance را نیز به ما می‌دهد بدین گونه که اگر یکی از سرویس‌های پردازش داده‌ی ما قطع بشود، دیگر تولید کننده از این موضوع بی اطلاع است و می‌تواند به کار خود ادامه بدهد. همچنین زمانی که مشکل مصرف کننده برطرف شد و به مدار برگشت می‌تواند کار خود را از جایی که متوقف کرده بود ادامه دهد.به طور کلی ابزارهای Message Queue در تکنیک‌ها و الگوهای معماری نیز نقش دارند. برای مثال برای پیاده‌سازی تکنیک Event Sourcing و یا Stream Processing معمولا به یک Message Queue نیاز داریم.مزیت‌های استفاده از Message Queueکارایی بیشترابزارهای Message Queue ارتباط غیرهمزمان را برای ما فراهم می‌کنند که به این معناست که سرویس‌های مختلف با صف و با Message Queue ارتباط برقرار می‌کنند نه با یکدیگر و این بدین معناست که وضعیت و سرعت یکی از سرویس‌ها بر دیگری تاثیر ندارد. هیچ سرویسی در سیستم هیچ وقت stall نمی‌شود و منتظر دیگیری نمی‌ماند و این یعنی جریان داده‌ی ما بهینه شده است.اتکاپذیری بیشترMessage Queue ها داده‌ی ما را ثبت و ذخیره می‌کنند و این باعث می‌شود که اگر سرویسی در دسترس نبود داده‌ی آن از دست نرود و از طرفی تولید کننده متوجه نشود. همین باعث افزایش دسترس پذیری و اتکا پذیری می‌شود و تحمل خطا در سیستم ما را افزایش می‌دهد. حتی خود Message Queue و پیام‌ها نیز می‌توانند redundancy داشته باشند تا اتکا پذیر باشند.مقیاس پذیری بیشترزمانی که داده‌های شما زیادتر از حد معمول می‌شود، تولید کننده‌های شما بدون اینکه نگران بقیه‌ی سیستم باشند می‌توانند داده تولید کرده و در صف بگذارند. همچنین ابزارهای Message Queue معمولا به صورت افقی مقیاس پذیر هستند و اگر طول صف شما زیاد شد می‌توانید سرورهای Message Queue را بیشتر کنید تا ظرفیت آن افزایش یابد. مصرف کننده ها و تولید کننده ها و حتی خود Message Queue می‌توانند در زمان نیاز کم یا بیشتر شوند و این یعنی مقایس پذیری افقی برای مولفه‌های مختلف راحت تر به دست می‌آید.جداسازی مولفه‌ها(decoupling)استفاده از Message Queue ها باعث می‌شود که مولفه‌های مختلف به هم وابستگی نداشته باشند و بتوانند به صورت مستقل از هم کار کنند و این امر به صورت چشم گیری برنامه‌نویسی این مولفه‌ها را ساده‌تر می‌کند. به جای اینکه در هر مولفه حجم زیادی کد برای ارتباط بین این مولفه با دیگر مولفه‌ها بزنیم، می‌توانیم تمرکز خود را بر روی بیزینس اصلی متمرکر کنیم و کمتر به بخش های‌ حاشیه‌ایی بپردازیم.انواع Message Queue هااین ابزارها به دو بخش Point to point و publish subscribe تقسیم می‌شوند. در ارتباط نقطه به نقطه، یک تولیدکننده پیام‌های خود را از طریق صف برای یک مصرف کننده‌ی دیگر ارسال می‌کند. ممکن است چندین مصرف کننده بر روی صف گوش دهند ولی فقط یکی از آن‌ها این پیام را باید مصرف کند. به همین دلیل به این نوع ارتباط نقطه به نقطه می‌گویند.از طرف دیگر Publish Subscribe به مدلی گفته می‌شود که پیام از طریق یک صف یا Topic به چندین مصرف کننده ارسال می‌شود. این Topic لینکی بین تولید کننده و مصرف‌کننده‌ها است.معرفی ابزارهای معروف این حوزهKafkaکافکا یکی از ابزارهای Message Queue معروف در این حوزه است که در ابتدا توسط LinkedIn توسعه داده شده و سپس به بنیاد آپاچی اهدا شده است. کافکا بیشتر از مدل PubSub تبعیت می‌کند. هدف از کافکا داشتن صفی با کارایی و throughput بالا بوده است و به همین دلیل از کافکا در سیستم‌هایی که نیاز به stream processing دارند زیاد استفاده می‌شود. در این ابزار به هر صف Topic می‌گوییم. هر تاپیک به تعدادی partition تقسیم می‌شود و پیام ها بین این پارتیشن‌ها تقسیم می‌شوند. پیام‌ها درون هر پارتیشن ترتیب دارند ولی در یک تاپیک و بین پارتیشن های مختلف ترتیبی وجود ندارد. تولید کننده ها پیام‌های خود را به تاپیک می‌فرستند و مصرف کننده ها می‌توانند روی یک یا چند تاپیک گوش دهند و پیام‌های مختلفی را دریافت کنند.RabbitMQاز دیگر ابزارهای معروف در این حوزه می‌توان به RabbitMQ اشاره کرد. این ابزار در سال 2004 به صورت متن‌باز به بازار ارائه شده است و از پروتوکل‌های مختلفی مثل AMQP، MQTT و STOMP پشتیبانی می‌کند. در RabbitMQ مفهومی به اسم Exchange و routing وجود دارد که این مفاهیم در کافکا وجود ندارند. در RabbitMQ می‌توان برای پسام‌های مختلف Route های مختلفی تعریف کرد تا به دست مصرف کننده برسند. همچنین از مزیت های RabbitMQ می‌تولن به داشتن UI تحت وب و کاملی اشاره کرد که تمامی اقدامات لازم در ان در دسترس است.شرکت‌های ایرانی مشغول در این حوزهشرکت سحاب پرداز یکی از شرکت‌های داخل ایران است که به صورت حرفه‌ایی بر روی کلان‌داده کار می‌کند و سال‌هاست که از نسخه‌های مختلف Kafka و در ابعاد مختلف استفاده می‌کند. برای راه‌اندازی و یا بهینه‌ سازی کافکا می‌توانید با گروه مشاوران سحاب ارتباط برقرار کنید.یکی دیگر از شرکت‌هایی که خدمات Message Queue ارائه می‌دهد، ابرآروان است. در ابر آروان شما می‌توانید به راحتی کافکا یا RabbitMQ را راه‌اندازی کنید. همچنین در بلاگ این شرکت توضیحات خوبی برای این تکنولوژي‌ها آورده شده است.خلاصهدر این مقاله به معرفی Message Queue ها و کاربردهای آن‌ها پرداختیم. سپس مزیت استفاده از Message Queue را برشمردیم و در نهایت دوتا از معروف ترین Message Queue های موجود را معرفی کردیم.این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است.منابعhttps://www.instaclustr.com/blog/rabbitmq-vs-kafka/https://medium.com/tech-sauce/introduction-to-message-queuing-4a7ab8968b59https://betterprogramming.pub/introduction-to-message-queue-with-rabbitmq-python-639e397cb668محمدصادق دهقانمحمدصادق دهقانSat, 25 Dec 2021 00:48:06 +0330https://virgool.ir/@msdehghan77/api-gateway-tdghn0sxckjzمقدمهدر این مقاله با مفهوم API Gateway آشنا شده و مزیت‌ها و معایت آن‌ را بررسی می‌کنیم. همچنین گریزی به معماری مایکروسرویس زده و نقش API Gateway را در این معماری بررسی می‌کنیم. درنهایت به معرفی ابزارهای معروف این حوزه پرداخته و ویژگی‌های هرکدام را برمی‌شماریم.معماری مایکروسرویس چیست؟در گذشته معمولا نرم‌افزارها به صورت monolithic توسعه داده می‌شدند. بدین صورت که ما یک فایل اجرایی برای نرم‌افزار داشتیم که تمامی API ها و endpoint را دارا بود و تمامی درخواست‌ها را پردازش می‌کرد. در چنین نرم‌افزاری هر تغییری نیازمند استقرار دوباره‌ی کل سیستم بود. همچینین تمامی کدهای سیستم به هم وابسته بودند و باهم اجرا می‌شدند. طبیعتا چنین نرم‌افزاری به صورت افقی مقیاس پذیر نیست و برای مقایس پذیری باید سرورها را قوی‌تر کنیم و به آن‌ها منابع اضافه کنیم. همچنین در چنین برنامه‌هایی تیم‌های مختلف نمی‌توانند قسمت‌های مختلف را به صورت مستقل پیش ببرند و همه‌ی قسمت‌های نرم‌افزار به هم couple می‌شود.به دلایل گفته شده در بالا معماری مایکروسرویس به وجود آمد. در این معماری به جای اینکه یک برنامه‌ی بسیار بزرگ داشته باشیم، برنامه‌های کوچکی داریم که هر کدام وظیفه‌ی مشخصی دارند و به دیگر برنامه‌ها سرویس مشخصی را ارائه می‌دهند. این برنامه‌های اجرایی برای ارتباط با یکدیگر از API های مشخص و قبل تعیین شده استفاده می‌کنند. در این معماری به هرکدام یک از این برنامه‌های اجرایی یک مایکروسرویس گفته می‌شود.هر مایکروسرویس API و protocol مخصوص به خود را دارد و دیگر مایکروسرویس‌ها از این طریق با این مایکروسرویس ارتباط برقرار می‌کنند. مزیت جداسازی قسمت‌های مختلف نرم‌افزار این است که هر قسمت از نرم‌افزار می‌تواند مستقلا توسعه داده شده و مسقر شود. همچنین برای بروزرسانی یا رفع خطا نیز لازم نیست کل سیستم را دوباره مسقر کنیم بلکه کافی است فقط مایکروسرویس مربوطه را بروزرسانی کنیم.مزیت دیگر استفاده از معماری مایکروسرویس این است که سیستم به صورت افقی قابل مقایس پذیری می‌شود. هر مایکروسرویس را می‌توان روی سرورهای مجزا اجرا کرد و این مایکروسرویس ها فقط از طریق پروتوکل‌های مشخص شده و API های لازم باهم ارتباط برقرار کنند.چرا به API Gateway نیاز داریم؟در معماری مایکروسرویس هر مولفه API های خودش را پیاده‌سازی می‌کند و دیگر مولفه‌ها برای گرفتن این اطلاعات باید به مایکروسرویس مشخص شده مراجعه کنند. در اینصورت کلاینت‌های برنامه نیز مجبورند به چندین آدرس و URL درخواست بزنند تا بتوانند عملیات خود را انجام دهند. برای مثال در یک برنامه‌ی نسبتا بزرگ، کلاینت برای نشان دادن یک صفحه ممکن است مجبور شود چند ده درخواست به آدرس‌های مختلف بزند تا تمامی اطلاعات را کسب کند. همچنین ممکن است مایکروسرویس‌های ما از تکنولوژی و پروتکل‌های متفاوتی استفاده کرده باشند. برای مثال کی مایکروسرویس از SOAP و دیگری از REST استفاده کرده باشد. در این صورت کلاینت مجبور است که بتواند با تمامی این پروتکل‌ها ارتباط برقرار کرده و درخواست لازم را به فرمت مورد نیاز خود تبدیل کند.این امر سربار بسیار زیادی دارد و زمان بارگذاری برنامه را نیز به شدت افزایش می‌دهد. از طرفی اگر بخواهیم API هرکدام از مایکروسرویس‌ها را عوض کنیم یا تغییری در پروتکل آن‌ها بدهیم تمامی مشتریان از این تغییر با خبر شده و مجبوریم نسخه‌های کلایت جدیدی را به بازار عرضه کنیم.علاوه بر موارد گفته شده در بالا ممکن است بعضی از endpoint های مایکروسرویس‌های ما خصوصی باشند و فقط برای استفاده از داخل کلاستر تعبیه شده باشند که در اینصورت ریسک لو رفتن یا مشخص شدن این API ها نیز زیاد است و خود نیاز به مدیریت دارد.باتوجه به دلایل بالا لازم است تا مولفه‌ایی جدید به اسم API Gateway را اضافه کنیم تا درخواست‌های ورودی سیستم را مدیریت کرده و هر درخواست را به قسمت لازم بفرستد. API Gateway در واقع نقطه‌ی ورود به سیستم ما است و تمامی درخواست‌های دیگران از طریق این مولفه به کلاستر ما می‌رسد.با استفاده از API Gateway کلاینت فقط لازم است که درخواست‌های خود را به API Gateway بزند و سپس این مولفه می‌تواند به مایکروسرویس‌های مختلف متصل شده و داده‌های لازم را جمع آوری کند و به سمت کلاینت بفرستد. همچنین کلاینت فقط باید پروتکل API Gateway را بلد باشد و لازم نیست تمامی پروتکل‌های استفاده شده توسط مایکروسرویس‌های مختلف را بلد باشد. با توجه به موارد گفته شده سربار استفاده از مایکروسرویس بسیار کمتر شده و کد کلاینت نیز کمتر و تمیزتر می‌شود.مزایای استفاده از API Gatewayمولفه‌ی API Gateway کاربردهای دیگری نیز دارد که در زیر به آن اشاره می‌کنیم.از طریق API Gateway ما به راحتی می‌توانیم تعداد درخواست‌ها و latency هر مایکروسرویس را اندازه‌گیری و مانیتور کنیم. همچنین باتوجه به اینکه به کدام یک از مایکروسرویس‌ها درخواست بیشتری می‌آید می‌توانیم تعداد هر مولفه‌ را کم یا زیاد کنیم.استفاده از API Gateway باعث می‌شود که مدیریت Cross cutting concerns راحتتر شود. برای مثال کارهایی مثل چک کردن Authentication یا لاگ زدن را می‌توان فقط در API Gateway انجام و بدین صورت هر مایکروسرویس فقط روی بیزینس اصلی خودش تمرکز کند و نیازی به چک کردن لاگین یا لاگ زدن اطلاعات درخواست نداشته باشد.مزیت دیگر استفاده از API Gateway تغییر پذیری ساده‌تر است. با استفاده از API Gateway ما می‌توانیم قسمت داخلی سیستم را از کاربر مخفی نگه داریم و به راحتی تغییر دهیم. برای مثال می‌توانیم پروتکل تمامی مایکروسرویس‌ها را از SOAP به REST تغییر دهیم ولی API Gateway ما همچنان با پروتکل قبلی با کاربر صحبت کند و بدین صورت تغییرات را از دید کاربر مخفی کنیم.مزیت دیگر استفاده از API Gateway قابلیت Fault Tolerance است. اگر یکی از مایکروسرویس‌ها در دسترس نباشد، API Gateway می‌تواند پیام مناسبی را به کاربر نشان دهد یا آن بخش از درخواست که به آن مایکروسرویس مربوط است را با پیام مناسب پر کند ولی بقیه اطلاعات را به صورت کامل برگرداند. در این صورت کاربر دریک صفحه تمامی اطلاعاتی که در دسترس است را می‌تواند مشاهده کند و فقط قسمتی که در دسترس نیست از کار می‌افتد.یکی دیگر از قابلیت‌های بسیار مهم API Gateway امکان Caching می‌باشد. با استفاده از این قابلیت می‌توانیم با توجه به قابلیت‌ها و بیزینس هر مایکروسرویس، درخواست‌های زده شده به یک یا چند مایکروسرویس را کش کرده و از این پس آن درخواست‌ها را به سرعت و بدون نیاز به برقراری ارتباط با مایکروسرویس مربوطه پاسخ دهیم. این قابلیت می‌تواند فشار را بر روی مایکروسرویس‌های مختلف کاهش داده و باعث افزایش سرعت شود.معایب استفاده از API Gatewayهمانند هر تکنیک دیگری استفاده از مایکروسرویس نیز می‌تواند مشکلات خاص خود را داشته باشد.اولین مشکل به وجود امدن Single Point Of Failure است. کل کارکرد سیستم ما به بالا بودن و کارکرد صحیح API Gateway وابسته است و اگر این مولفه از دسترس خارج شود یا دچار باگی باشد کلیه‌ی کارکرد سیستم می‌تواند دچار خطا شود. برای همین نگهداری و High Availability این مولفه از اهمیت خاصی برخوردار است.تمامی سیستم ما به این مولفه نیاز دارد. با هر تغییر در API یا کارکرد هر مایکروسرویس لازم است که تنظیمات API Gateway نیز عوض شده و این مولفه دوباره مستقر شود. به همین دلیل نرخ استقرار برای این مولفه زیاد خواهد بود.همچنین این مولفه یک گره‌ی جدید در مسیر درخواست کاربر اضافه می‌کند و درخواست‌ها مستقیما به سرویس مربوطه نمی‌رسند. به همین دلیل ممکن است سربار این درخواست نیز قابل توجه باشد و درخواست‌های ساده را مقداری کند بکند. همچنین اگر load balance برای مولفه‌های API Gateway به خوبی انجام نشود این مولفه ممکن است به گلوگاه سرویس ما تبدیل شود.معرفی ابزارهای معروف این حوزهSpring API Gatewayاین ابزار توسط تیم اسپرینگ ارائه شده است و با زبان جاوا و فریم‌ورک Spring WebFlux نوشته شده است. یکی از مزیت‌های این ابزار Reactive بودن و استفاده از Async API هاست. به همین دلیل سربار بسیار کمی دارد و درخواست‌های بسیار زیادی را می‌تواند پردازش کند. این ابزار تقریبا تمامی اطلاعات لازم را می‌تواند از طریق فایل کانفیگ دریافت کند و درخوست‌ها را براساس آن هدایت کند. به همین دلیل بسیار منعطف است و کارکرد ساده‌ایی دارد. علاوه بر همه‌ی این ها تیم Spring Cloud به خوبی این مولفه را پشتیبانی می‌کند.Apache APISIXاین ابزار توسط بنیاد Apache ارائه شده است. این ابزار در اصل در یک شرکت چینی توسعه پیدا کرده‌ است و سپس به بیاد Apache اهدا شده است. یکی از مزیت‌های این ابزار داشتن داشبورد بسیار قوی و خوب است. از مزیت‌های دیگر آن قابلیت اضافه کردن پلاگین‌های مختلف و اجرای آن‌ها بدون نیاز به استقرار مجدد می‌باشد.خلاصهدر این مقاله به معرفی اجمالی معماری مایکروسرویس پرداختیم. همچنین توضیح دادیم چرا در این معماری استفاده از API Gateway لازم است. سپس به بررسی مزایا و معایب API Gateway پرداختم و هر مورد را شرح دادیم. در انتها به معرفی دو ابزار معروف در این حوزه پرداختیم و در نهایت شرکت‌های معروف این حوزه در ایران را معرفی کردیم.این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است.منابعhttps://docs.microsoft.com/en-us/dotnet/architecture/microservices/architect-microservice-container-applications/direct-client-to-microservice-communication-versus-the-api-gateway-patternhttps://whatis.techtarget.com/definition/API-gateway-application-programming-interface-gatewayhttps://tyk.io/blog/microservices-api-gateway/محمدصادق دهقانمحمدصادق دهقانSat, 25 Dec 2021 00:41:52 +0330https://virgool.ir/@msdehghan77/container-docker-kubernetes-tlk1wx8guikvمقدمهامروزه اکثر شرکت‌های نرم‌افزاری به نحوی از container ها استفاده می‌کنند و یا در حال حرکت به سمت استفاده از container ها هستند. تعداد نرم‌افزارهایی که برای اجرا نیاز به تکنولوژی‌های کانتینر دارند روز به روز بیشتر می‌شود و کمتر برنامه‌نویسی است که اسم docker یا Kubernetes به گوشش نخورده نباشد. آشنایی به container ها کم کم به پای ثابت آگهی‌های شغلی تبدیل شده است. در این مقاله به معرفی containerization و orchestration می‌پردازیم و برخی از ابزارهای معروف این حوزه را بررسی می‌کنیم.کانتینر چیست؟به طور کلی کانتینر مجموعه‌ایی ایزوله شده، قابل جابجایی و قابل اجراست که متشکل است از فایل اجرایی برنامه، کتابخانه‌های سیستمی مورد نیاز و هر فایلی که برای اجرای برنامه مورد نیاز است. یک کانتینر را می‌توان به راحتی بین سیستم‌های مختلف جابجا کرد و مستقل از محیط اجرا کرد. اما چه نیازی به کانتینر داریم و چرا کانتینرها به وجود آمده اند؟ بهتر است نگاهی به گذشته و فرایند استقرار نرم‌افزارها در گذشته بیاندازیم.چرا به کانتینر نیاز داریم؟برای اینکه احتمال رخ دادن خطا در محیط عملیاتی را کمتر کنیم لازم است که محیط توسعه را تا حد امکان با محیط اجرا یک شکل کنیم. اما چرا اینکار باعث کاهش خطا می‌شود؟ برای مثال فرض کنید که برنامه‌نویسان نرم‌افزار را بر روی لپتاپ خود توسعه می‌دهند پ تست می‌کنند. به دلیل اینکه سیستم‌عامل و کتابخوانه‌های نصب شده در سیستم برنامه‌نویس با سرور های محیط عملیاتی یکی نیست، ممکن است زمان استقرار برنامه در محیط عملیاتی به خطاهای عجیب و غریب بخوریم. برای اینکه شاهد چنین اتفاقاتی نباشیم دوست داریم که نرم‌افزار در محیط اجرا و تست شود که تا حد امکان شبیه به محیط عملیاتی باشد.اما نه تنها سیستم‌های برنامه‌نویس‌ها با سرورها متفاوت است بلکه خود سرورهای محیط عملیاتی نیز ممکن است باهم متفاوت باشند. برای مثال بعضی از سرورها دارای اوبنتو باشند و بعضی دیگر CentOS، بعضی جدیدتر خریداری شده اند و به کلاستر اضافه شده اند و سخت افزار متفاوتی دارند و ... . یا ممکن است سیستم‌های محیط staging با production متفاوت باشد. برای مثال تیم امنیت به طور پیوسته سرورها را آپگرید می‌کند و آخرین پچ‌های نرم‌افزاری را نصب می‌کند و ممکن است فرایند نصب پچ ها در محیط staging همگام با production نباشد.علاوه بر همه‌ی این‌ها بر روی هرسرور ممکن است چندین نرم‌افزار اجرا شوند که هرکدام توسط تیم‌های مختلف توسعه داده شده است. یکی کردن محیط توسعه و اجرا در چنین شرایطی بسیار دشوار است.از طرفی ممکن است برنامه‌های اجرا شده بر روی یک سرور نیازمندی‌های متفاوت و بعضا متناقضی داشته باشند. برای مثال یک نرم‌افزار به نسخه 5 یک کتابخوانه نیاز دارد اما نرم‌افزار دیگر به نسخه‌ی 6 آن نیاز دارد. یک نرم‌افزار به اوبنتو 16 نیاز دارد و دیگری حتما به 18 نیاز دارد. در چنین شرایطی برای اینکه بتوانیم برنامه‌ها را بر روی یک سرور اجرا کنیم لازم است که آن‌ها را ایزوله کرده و به صورت ایزوله شده اجرا کنیم.قابلیت جابجایی از دیگر نیازمندی‌های مهم نرم‌افزار است. اگر یکی از سرورها خراب بشود لازم است که بتوانیم به سرعت آن را جابجا کرده و در سرور دیگری اجرا کنیم. اگر برنامه به صورت مستقل قابل اجرا باشد و همه‌ی نیازمندی‌های خود را داشته باشد اینکار بسیار ساده خواهد بود اما اگر لازم باشد که تمامی نیازمندی‌ها از ابتدا روی سرور جدید نصب بشوند زمان زیادی را از دست خواهیم داد. همچنین اگر بخواهیم نرم‌افزار را به برنامه‌نویسان دیگر بدهیم تا اجرا یا تست کنند قابلیت جابجایی یا همان Portability برای ما بسیار مهم خواهد بود. به همین دلیلی نرم‌افزاری که به صورت ایزوله شده تمامی وابستگی‌های مورد نیاز و سازگار با خودش را دارد بسیار ارزشمند است.نکته‌ی بسیار مهم دیگر تاثیر پذیری نرم‌افزارها از یکدیگر و بحث امنیت است. برای مثال اگر یکی از نرم‌افزارهای درحال اجرا دچار fault شود آیا این fault باید روی بقیه‌ی نرم‌افزارهای در حال اجرا اثر بگذارد؟ مسلماً خیر. یا اگر یکی از نرم‌افزارها دچار مشکل امنیتی شود ما دوست داریم محدوه‌ی این حمله تا حد امکان کوچک بوده و بر روی خود سرور یا دیگر نرم‌افزارهای درحال اجرا اثر نگذارد.به تمامی دلایل گفته شده در بالا نیاز داریم تا نرم‌افزارما به صورت ایزوله و مستقل از محل اجرا باشد و قابلیت جابجایی داشته باشد. تمامی مواردی که در بالا گفته شد را می‌توان با استفاده از ماشین مجازی هم برطرف نمود، پس مزیت استفاده از کانتینر چیست و فرق آن با ماشین مجازی در چیست؟تفاوت کانتینر با ماشین مجازیهر ماشین مجازی در داخل خودش یک سیستم‌عامل کامل و مجزا دارد. زمانی که شما چند ماشین مجازی را روی یک سرور اجرا می‌کنید، چندین سیستم‌عامل کاملا مجزا بر روی سرور اجرا می‌شوند که هرکدام هسته و فرایندهای مخصوص به خود را دارند. در زیر این ماشین های مجازی قسمتی به اسم Hypervisor قرار دارد که وظیفه‌ی آن تقسیم سخت‌افزار موجود بین ماشین‌های مجازی اجرا شده می‌باشد.برنامه‌هایی که درون ماشین‌مجازی اجرا شده اند فراخوانی‌های سیستمی خود را از طریق هسته‌ی سیستم‌عامل موجود در ماشین مجازی انجام می‌دهند و آن هسته از طریق Hypervisor دستورات را مستقیما بر روی CPU ی موجود در سرور اجرا می‌کند. همچنین CPU ی استفاده شده نیز باید قابلیت Virtualization را دارا باشد و بتواند مجازی سازی را به خوبی انجام دهد. در هر ماشین مجازی علاوه بر برنامه‌ی مورد نظر، تمامی فرایندهای یک سیستم‌عامل به صورت همزمان در حال اجرا هستند و همین باعث می‌شود که ماشین‌های مجازی بسیار سنگین‌تر و حجیم‌تر از کانتینر باشند.از طرف دیگر هر کانتینر چیزی نیست جز فرایندی که بر روی سیستم‌عامل اصلی سرور درحال اجراست و تنها تفاوت آن با دیگر فرایندها این است که کرنل این فرانید را به صورت ایزوله اجرا کرده است. در واقع کانتینرها همگی از هسته‌ی سیستم‌عامل موجود استفاده می‌کنند و این هسته بین تمامی کانتینرها مشترک است. فرایندی که داخل کانتینر در حال اجراست تمامی فراخوانی‌های سیستمی خود را از طریق هسته‌ی سیستم‌عامل سرور انجام می‌دهد و خبری از سیستم‌عامل جدیدی در این بین نیست. تنها تفاوت فرایندهای داخل کانیتر این است که هسته‌ی سیستم‌عامل این فرایندها را به صورت ایزوله اجرا کرده است و برای هرکدام namespace مخصوص به خود را در نظر گرفته است.چون کانتینرها در داخل خود فایل‌های یک سیستم‌عامل کامل(از جمله هسته‌ی سیستم‌عامل) را ندارند، به طور چشم گیری نسبت به ماشین‌های مجازی سبک‌تر هستند و به همین دلیل جابجایی آن‌ها آسان‌تر است. از طرفی چون تمامی فرایندهای داخل هر کانتینر در سیستم‌عامل اصلی اجرا می‌شوند، اجرا کردن آن‌ها نیز بسیار سریع‌تر است. علاوه بر همه‌ی اینها در کانتینرها CPU لازم نیست مجازی‌سازی انجام بدهد و در کل سربار بسیار کمتر است.البته ناگفته نماند که از نظر امنیت کانیترها ممکن است ریسک بیشتری داشته باشند چراکه همگی سیستم‌عامل اصلی سرور را به اشتراک می‌گذارند و از یک هسته‌ی واحد استفاده ‌می‌کنند اما در ماشین‌های مجازی همه‌چیز به صورت کامل ایزوله است حتی هسته‌ی سیستم‌عامل.اگر سیستم ما از تعداد کمی قسمت مستقل ولی بزرگ و سنگین تشکیل شده باشد استفاده از ماشین مجازی ممکن است توجیه داشته باشد اما هرچقدر تعداد قسمت‌های مختلف یک سیستم بیشتر می‌شود آن‌ها کوچک تر می‌شوند، استفاده از ماشین مجازی پرهزینه‌تر و غیرقابل توجیه می‌شود. باتوجه به مطالب گفته شده در بالا امروزه بسیاری از برنامه‌نویسان به جای ماشین مجازی از کانتینر استفاده می‌کنند.Container Orchestrationزمانی که شما چندین سرور و مولفه‌ی قابل اجرا دارید(مثل معماری مایکروسرویس)، تعداد دفعاتی که باید استقرار را انجام دهید بسیار بیشتر خواهد شد. همچنین مدیریت تعدادی زیادی کانتینر به مراتب سخت‌ تر خواهد بود. برای مثال ما میخواهیم اگر یکی از سرورها خاموش شد به صورت خودکار نرم‌افزارهای آن سرور به دیگر سرورها انتقال یابند و با downtime بسیار کمی نرم‌افزار دوباره قابل استفاده باشد. انجام چنین عمل‌هایی به صورت دستی بسیار سخت است. به همین دلیل سیستم‌هایی برای Container Orchestration به وجود آمده‌اند که به ما در مدیریت و نگهداری کانتینرها کمک می‌کنند.در واقع ابزارهای Orchestration به ما این امکان را می‌دهند که تمرکز خود را بر روی توسعه‌ی محصول بگذاریم و کمتر درگیر زیرساخت باشیم. با استفاده از این ابزارها ما می‌توانیم تمامی سخت‌افزارها و زیرساخت را به صورت یکپارچه و به عنوان یک منبع پردازشی نگاه کنیم.ابزارهای Orchestration به ما کمک می‌کنند که بین کانتینرهای مختلف load balancing انجام بدهیم تا درخواست‌ها بین کانتینرهای مختلف تقسیم شوند. این ابزارها معمولا برای بروزرسانی و و یا مقایس‌پذیری نیز امکانات گسترده‌ایی را دارند. یکی دیگر از امکانات بسیار مهم این ابزارها قابلیت های مربوط به تحمل خطا و یا recovery است. این ابزارها می‌توانند در صورت بروز خرابی در هر یک از سرورها، آن سرور را به صورت خودکار از کلاستر خارج کرده و برنامه‌ها را بر روی سرور جدیدی انتقال دهند. همچنین می‌توانند مولفه‌های در حال اجرا را به طور پیوسته پایش کنند و در صورتی که هرکدام از آن‌ها قابلیت پیشروی نداشت، آن را دوباره راه‌اندازی کنند.معرفی ابزارهای مطرح در این حوزهداکرداکر یکی از معروف‌ترین ابزارهای تولید و اجرای کانتینر است. قبل از داکر تکنولوژی‌های مختلفی برای Containerazion وجود داشت اما داکر اولین ابزاری بود که امکان جابجایی کانتینرها بر روی سیستم‌های مختلف را به راحتی فراهم می‌کرد. همچنین داکر فرایند ساخت کانتینر را بسیار ساده‌تر می‌کرد و همه‌ی این‌ها باعث موفقیت چشم‌گیر داکر شد. تا حدی که امروزه بسیاری تا اسم از کانتینر می‌شود داکر را به خاطر می‌آورند.راک ایت - Rktابزار rkt یکی دیگر از تکنولوژی‌های مدیریت کانتینر در لینوکس است و به نوعی یکی از جایگزین‌های داکر به حساب می‌آید. بعد از موفقیت داکر گروهی به اسم OCI به وجود آمد و استانداردهایی را برای کانتینرهای لینوکس تدوین کرد. داکر و rkt هردو عضو این مجموعه هستند و از این استانداردها تبعیت می‌کنند. تمرکز اصلی rkt بر امنیت، ترکیب‌پذیری و تبعیت از استانداردهاست.کوبرنتیزکوبرنتیز معروف‌ترین ابزار Container Orchestration در حال حاضر است که توسط شرکت‌های مختلفی در جای جای دنیا استفاده می‌شود. این ابزار در ابتدا توسط گوگل توسعه داده شده و سپس به صورت OpenSource منتشر شده است. امروزز community بسیار بزرگی از کوبرنتیز پشتیبانی می‌کنند و ابزار قابل اتکایی به شمار می‌آید.کوبرنتیز به شما این امکان را می‌دهد تا وضعیت مورد نظر خود را از طریق فایل های YAMLیا JSON تعریف کنید(declare). این وظیفه‌ی کوبرنتیز است تا وضعیت را به حالت دلخواه شما درآورد و همانگونه نگهداری کند. در صورت خرابی یا هر اتفاقی کوبرنتیز سعی می‌کند تا حد امکان خطا را مدیریت کرده و وضعیت را به حالت خواسته شده درآورد.در کوبرنتیز کوچیک‌ترین واحد قابل استقرار pod نام دارد. هر pod می‌تواند شامل چندین کانتینر باشد که باهم در ارتباط هستند. این کانتینرها به پورت‌ها و filesystem یکدیگر دسترسی دارند و بین آن‌ها isolation کمتری وجود دارد. به همین دلیل فقط و فقط کانتینرهایی که لازم هست همیشه کنارهم باشند و ارتباط تنگاتنگی باهم دارند را باید در یک pod قرار دهید. اکثر اوقات هر pod شامل یک کانتینر است.معرفی شرکت‌های ایرانی در ارتباط با این حوزهشرکت همروش:شرکت همروش یکی از شرکت‌های معروف در ایران است که به شما کمک‌ می‌کند کانتینرهای خود را مستقر کنید. این شرکت با ارائه‌ی پلتفرم ابری «دارکوب» به شما اجازه می‌دهد که کانتینرهای خود را مستقر کنید و منابعی که نیاز دارید را مشخص کنید. همچنین درصورت نیاز می‌توانید از سرویس‌های آماده مانند پایگاه داده‌ نیز استفاده کنید. این شرکت امکانات مختلفی برای جمع‌آوری لاگ‌ها و پایش را نیز در اختبار شما قرار می‌دهد.ابرآروان:ابرآروان از دیگر ارائه دهنده‌های سرویس کانتیر ابری است که به شما کمک می‌کند کانتینرهای خود را بر فضای ابری اجرا و مدیریت کنید. علاوه بر امکان اجرا، ابرآروان به شما یک private repo برای نگهداری کانتینرها و مدیریت آن‌ها نیز می‌دهد.این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است.منابع:Kubernetes In Action Book Edition 1https://www.ibm.com/cloud/learn/containerizationمحمدصادق دهقانمحمدصادق دهقانSat, 25 Dec 2021 00:37:37 +0330https://virgool.ir/@msdehghan77/static-code-analysis-qbywokm6dzcjمقدمهاحتمالا تاکنون اسم ابزارهایی مثل Sonarqube یا Codacy به گوش شما خورده است. این ابزارها در دسته‌ی تحلیل ایستای کد جای می‌گیرند(Static Code Analysis). این ابزارها می‌توانند با تحلیل کدهای نوشته، به صورت خودکار بعضی از باگ‌های موجود و اشتباهات رایج را پیدا کرده و گوشزد کنند. در این مقاله به معرفی Static code analysis پرداخته و مزایا و معایب آن‌ها را بررسی می‌کنیم. همچنین چندین مثال و چندین ابزار را معرفی می‌کنیم و نحوه‌ی کارکردن و ویژگی‌های هر کی را برمی‌شمریم.معرفی Static Code Analysisافزایش کیفیت و نوشتن نرم‌افزارهای عاری از باگ همیشه آرزوی برنامه‌نویسان بوده است. برای نوشتن نرم‌افزار با کیفیت نیاز داریم تا تمامی برنامه‌نویسانی که روی مخزن کد کار می‌کنند با خوبی با امکانات و باگ‌های رایج در آن زبان آشنا باشند تا بتوانند از آن‌ها جلوگیری کنند. همچین نیاز داریم تا برنامه‌نویس‌ها با انواع مشکلات امنیتی و نحوه‌ی ایجاد آن‌ها در کد آشنا باشند. در صورتی که تمامی برنامه‌نویسان پروژه از چنین دانشی برخوردار باشند می‌توانند از باگ‌ها و مشکلات امنیتی جلوگیری کرده و احتمال تولید کد‌های باکیفیت بالاتر می‌رود.متاسفانه خیلی کم پیش می‌آید که تمام برنامه‌نویسان یک پروژه دانش بسیار کاملی از زبان برنامه نویسی، مشکلات امنیتی رایج و باگ‌های رایج داشته باشند. علاوه بر آن حتی این چنین برنامه‌نویس‌هایی نیز ممکن است اشتباه کنند و باگ‌های ساده و عجیب غریب در کد بگذارند. خیلی از برنامه‌نویس‌ها با سررسید‌(Dead line) کارفرما یا پروژه مواجه هستند و بعضی از اوقات مجبور می‌شوند تحت فشار کار کنند. حتی در شرایط عادی نیز ممکن است خطای سهوی یا بی دقتی رخ دهد. به همین دلیل امکان بروز خطاهای رایج و واضح حتی توسط برنامه‌نویس‌های باتجربه و حرفه‌ایی نیز وجود دارد.یکی از راه‌های بسیار خوب برای حل این مشکلات و افزایش کیفیت نرم‌افزار بازبینی‌کد (Code Review) است. در بازبینی‌کد، تمامی کدهای نوشته در پروژه، توسط فردی به جز نویسنده‌ی اصلی کدها بررسی شده و خطاهای احتمالی کشف می‌شود. بازبین‌کد معمولا یکی از افراد باتجربه‌ی تیم است که بر روی پروژه مسلط است. بازبین بر روی کدها نظر میدهد و نویسنده‌ی کدها در صورت لزوم اشتباهات احتمالی را اصلاح می‌کند.بررسی کدها توسط یک نفر دیگر تا حد خوبی امکان خطا را پایین می‌آور اما صفر نمی‌کند. علی‌الخصوص که چک کردن بعضی از مشکلات ممکن است حوصله سربر و زمان بر باشد. برای مثال در کدهای جاوا import کردن کلاس‌هایی که اصلا استفاده نشده است یک bad smell است و باید اصلاح شود. بررسی کردن تمامی import ها در تمامی فایل‌ها توسط بازبین‌کد کاری بسیار دشوار و سخت است. از طرفی ابزارها می‌توانند به صورت خودکار و دقیق و سریع این نوع قوانین را چک کنند و هشدار بدهند.ابزارهای تحلیل ایستای کد (Static code analysis)، با بررسی خودکار کدها می‌توانند جلوی بسیاری اشتباهات و مشکلات امنیتی را بگیرند. دلیل اینکه به این ابزارها ایستا می‌گوییم این است که این ابزارها بدون اجرای کدها و فقط با بررسی محتوای فایل‌ها، کدها را بررسی می‌کنند. در این ابزارها قوانین مختلفی تعریف می‌شود که ابزار می‌تواند آن را روی کدها بررسی کند. برای مثال قانون نداشتن import های بلا استفاده. یا قانون جلوگیری از حمله SQL injection و ... . هر ابزار صدها بلکه هزاران قانون مختلف به صورت پیش‌فرض برای هر زبان دارد که بسیار کاربردی است و می‌تواند جلوی بسیاری از مشکلات را بگیرد.مزیت دیگر این ابزارها این است که قوانین خود را به صورت مرتب بروزرسانی می‌کنند و یا بهبود می‌دهند. معمولا پشت هر ابزار، تیمی از برنامه‌نویسان باتجربه قراردارند که کارشان بهبود و تعریف قانون جدید برای این ابزارهاست. همین باعث می‌شود که ما با بروزرسانی ابزار تحلیل خود و با هزینه‌ی بسیار پایین از قوانین جدید بهره ببریم و بتوانیم کدهای بهتری تولید کنیم.در این ابزارها این امکان وجود دارد که قوانین شخصی سازی بشوند و تا احد امکان با نیاز تیم ما و استانداردهای ما سازگار بشوند. همچنین می‌توان به سادگی برای این ابزارها افزونه نوشت و قوانین جدید به آن‌ها اضافه کرد. این قابلیت کمک می‌کند تا بتوانیم بسازی از چک‌های روتین را خودکار کنیم و فرایند توسعه را سریع کنیم.یکی از قابلیت‌های بسیار کاربردی این ابزارها وجود Quality Gate برای کدهاست. بدین صورت که شما می‌توانید حداقل‌های لازم برای کدهای پروژه را مشخص کنید و این ابزارها به صورت خودکار ان حداقل‌ها را چک کنند. برای مثال فرض کنید در پروژه میخواهیم جلوی ثبت شدن کدهایی که حداقل 70 درصد پوشش خط در تست‌ها ندارند را بگیریم. در این صورت به راحتی می‌توانیم در ابزار تحلیل کد Quality Gate تعریف کنیم تا اگر کدی با این شرایط وجود داشت خطا بدهد.از مزیت دیگر این ابزارها سازگاری بسیار خوب آن‌ها با سیستم‌های CI/CD است. به راحتی در چرخه‌ی اجرای پروژه می‌توانیم این تحلیل‌ها را اجرا کنیم و به برنامه‌نویس فیدبک بدهیم. در این صورت تا زمانی که بر روی تمامی کدها Quality Gate برقرار نشود، کدی نمی‌تواند ثبت شود و بدین گونه کیفیت نرم‌افزار را تضمین کرده و بالاتر می‌بریم.همچنین این ابزارها فرایند بازیبنی‌کد را نیز بسیار کاراتر و سریع‌تر می‌کنند. بسیاری از قوانینی که قبلا لازم بود توسط بازبین کد به صورت دستی چک بشود اکنون قابلیت خودکارسازی دارد و بازبین کد می‌تواند تمرکز خود را بر روی قسمتم‌های بیزینسی و مهم کد بگذارد. از طرفی خیال بازبین راحت است که ابزار تحلیل کدها، به صورت سریع و خودکار تمامی خطاهای موجود را پیدا می‌کند و دیگر نیازی به بررسی دستی نیست.از طرفی وجود این ابزارها فرایند بازخورد به برنامه‌نویس را بسیار سریع‌تر می‌کند. برنامه نویس می‌تواند بلافاصله بعد از اتمام کد زدن یا حتی در حین کد زدن از سیستم static analysis بازخورد دریافت کند و دیگر لازم نیست چندین ساعت منتظر بازبینی کد توسط فرد دیگری بماند که این خود فرایند بازبینی را بسیار تسریع می‌کند.این ابزارها برای برنامه‌نویس‌های کم تجربه تر نیز از این جهت خوب است که باعث یادگیری آن‌ها می‌شود. ابزارهای Static analysis معمولا برای باگ‌های رایج یا مشکلات امنیتی توضیحات بسیار کاملی دارند که برای برنامه‌نویس‌های تازه‌کار می‌تواند یادگیری خوبی با هزینه کم داشته باشد.یکی از معایب ابزارهای Static analysis وجود خطاهای False positive است. این نوع خطاها، خطاهایی هستند که سیستم های static analysis به اشتباه از کد کشف کرده و گزارش می‌دهند. برای مثال اگر کدی پیچده یا تودرتو شود ممکن است ابزار تحلیل کد گیج شده و خطاهای اشتباهی را گزارش کند. همچنین هرچقدر ابزارها امکانات پیشرفته‌تری را ارائه می‌کنند امکان اشتباه نیز بیشتر است. برای مثال ابزاری که سع می‌کند خطاهای کدهای همروند را کشف کند احتمال اینکه FP داشته باشد خیلی بیشتر است.این نوع خطاها گاه می‌توانند بسیار اذیت کننده شوند اما معمولا ابزارهای مختلف برای این نوع خطاها نیز چاره‌ اندیشیده‌اند. معمولا شما می‌توانید بعضی از خطاها را silent کنید یا به عنوان won’t fix نشان کنید. یا اینکخه برای بخشی از کد یک خطا را غیرفعال کنید تا FP تولید نشود.ابزارهای معروف این حوزهسونارکیوب(SonarQube)سونارکیوب یکی از قدیمی‌ترین و معروف‌ترین ابزارهای این حوزه است. هسته‌ی اصلی سونارکیوب کاملا متن‌باز و قابل دسترس است و اکثر امکانات لازم را دارا است اما نسخه‌های پولی نیز دارد که امکانات بیشتری دارند. نسخه‌های پولی امکاناتی مثل تحلیل جریان داده(Flow analysis)، تحلیل‌های پیشرفته‌ی امنیتی و گزارش‌های بیشتری را اضافه بر نسخه‌ی رایگان دارند.سونارکیوب به طور کلی از دو بخش سرور و کلاینت تشکیل شده است. سمت سرور یک Web Apploication است که وظیفه‌ی نگهداری اطلاعات کدها و تاریخچه‌ی اسکن‌های مختلف را دارد. همچنین وظیفه‌ی نشان دادن این اطلاعات از طریق UI با سرور است. سمت کلاینت از طریق maven یا gradle در pipeline اجرا شده و کدها را اسکن می‌کند و نتایج را به سرور سونارکیوب می‌فرستد.همچنین در سونارکیوب می‌توانید بر روی پروژه‌های مختلف Quality Gate تعریف کنید و اگر این شرط‌ها برقرار نباشد Gate پروژه شما fail می‌شود. بر اساس گیت پایپلاین را نیز می‌توانید fail کنید و مانع از ثبت شدن کدها بشوید. سونارکیوب مفهوم Branch و Pull-Request را به خوبی میفهمد و می‌تواند به ابزارهایی مثل گیت‌هاب و گریت متصل شود که از این جهت نیز کار شما را بسیار ساده می‌کند.همچنین سونارکیوب انواع زبان‌های مختلف از VB گرفته تا TypeScript را متوجه می‌شود و حتی پروژه‌های ترکیبی را نیز می‌تواند اسکن کند که این نقطه‌ی قوت است.سونارکلود(SonarCloud)سونارکلود نسخه‌ی ابری سونارکیوب است که به صورت رایگان به شما سرویس می‌دهد. فقط کافی است که از سمت کلاینت شما کدهای خود را اسکن کنید تا سونارکلود نتایج را به شما نشان دهد و تحلیل‌های مختلفی را ارائه دهد. همچنین سونارکلود به صورت خودکار می‌تواند به گیتهاب و گتلب وصل شده و روی پول ریکوئست های مختلف کامنت بدهد یا کامنت های قدیمی را حذف کند.مزیت استفاده از سونارکلود این است که به صورت سرویس ارائه می‌شود و هزینه‌ی نگهداری یا نصب برای تیم استفاده کننده ندارد. از طرفی به صورت خودکار بروزرسانی می‌شود و بعضی قابلیت های نسخه‌ی پولی سونارکیوب نیز در سونارکلود فعال است. یکی از عیب های سونارکلود این است که اطلاعات کدهای شما از جمله سورس‌کدها به سرورهای سونارکلود ارسال می‌شوند و اگر پروژه‌ی شما خصوصی باشد یا به هردلیلی قابلیت انتشار نداشته باشد، احتمالا نمی‌خواهید از یک سرویس دهنده‌ی عمومی استفاده کنید و ریسک کنید و به همین علت باید یک سرور داخلی سونارکیوب نصب کنید.کداسی(Codacy)کداسی نیز ابزاری است که تحلیل ایستای کد را به صورت سرویس ارائه می‌دهد. این سرویس نسبت به سونارکیوب جدیدتر ارائه شده و بین برنامه‌نویسان کمتر شناخته‌ شده است. این ابزار برای کدهای اوپن سورس رایگان است اما قابلیت نصب on-premise به صورت رایگان را ندارد.کداسی یکی از مزیت های خود را UI کامل و بهتر می‌داند. در کداسی شما به معیارهای مختلف و بسیاری از کدهای خود دسترسی دارید و همچنین روند این معیارها از طریق نمودارهای مختلفی به شما نشان داده می‌شود. همچنین کداسی همانند سونارکیوب می‌تواند کدها را از نظر امنیتی نیز تحلیل کند و گزارش‌های خوبی را ارائه دهد.باتوجه به اینکه این ابزار عمر کمتری نسبت به سونارکیوب دارد تعداد مقالات و community پشت آن نیز کمتر است.شرکت‌های ایرانی ارائه دهنده‌ی این خدماتhttps://www.mohandespishegan.com/tools/code-analysis/sonarشرکت مهندس پیشگان یکی از شرکت‌های ایرانی است که در زمینه ارائه خدمات مربوط به آزمون نرم‌افزار و تحلیل ایستای کد فعالیت می‌کند. یکی از ابزارهای ارائه شده توسط این شرکت ابزار سونارکیوب می‌باشد. این شرکت همچنین ابزارهای دیگری برای تحلیل ایستای کد مثل JTest و dotTest را نیز ارائه می‌کند.شرکت کوالاتک نیز شرکتی دانش بنیان است که در زمینه آزمون نرم افزار و تضمین کیفیت نرم‌افزار فعالیت می‌کند. این شرکت نیز در زمینه راه اندازی ابزار تحلیل ایستا و افزایش کیفیت نرم‌افزار مشاوره می‌دهد. همچنین این شرکت در زمینه هماهنگ سازی CI با ابزار تحلیل ایستا و خودکار سازی این فرایند نیز فعالیت می‌کند که حائز اهمیت است.https://qualatech.ir/source-code-analysis/جمع بندیدر این مقاله به معرفی تحلیل ایستای کد پرداختیم و بعضی از ابزارهای معروف در این حوزه را نیز بررسی کردیم. به اینکه چرا باید از این ابزارها استفاده کنیم اشاره کردیم و برخی از مزیت‌های آن‌ها را برشمردیم. در نهایت دو شرکت ایرانی که در این حوزه فعالیت می‌کردند را معرفی کردیم.این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی استمنابع:https://www.codacy.com/products/sonarqube-alternativeshttps://sdtimes.com/test/5-ways-static-code-analysis-can-save-you/https://en.fasoo.com/top-10-reasons-why-you-should-use-static-code-analysis/https://www.appknox.com/blog/static-code-analysishttps://docs.sonarqube.org/latest/محمدصادق دهقانمحمدصادق دهقانSat, 25 Dec 2021 00:27:20 +0330https://virgool.ir/@msdehghan77/monitoring-eirgzx9b6ojqمقدمهاگر برنامه‌نویس هستید یا در یک شرکت نرم‌افزاری کار می‌کنید حتماً اسم پایش (مانیتورینگ) به گوشتان خورده است. امروزه پایش (مانیتورینگ) یکی از بخش‌های مهم و پرچالش هر پروژه‌ی نرم‌افزاری است. در این مطلب به معرفی پایش و مفاهیم آن می‌پردازیم. ابتدا به اهمیت و لزوم پایش نرم‌افزارها اشاره می‌کنیم. سپس مفاهیم آن را بیان می‌کنیم و در نهایت ابزارهای موجود را معرفی کرده و به‌اختصار بررسی می‌کنیم.چرا به پایش نیاز داریم؟برای اینکه سرویس یا نرم‌افزار با کیفیتی ارائه دهیم نیاز داریم که همیشه وضعیت سلامت سرویس خود را در اختیار داشته باشیم و به‌محض اینکه مشکلی برای سیستم پیش آمد از آن باخبر شویم و آن را برطرف کنیم. برای ما به‌عنوان سرویس‌دهنده اصلاً خوشایند نیست که کاربر نهایی سرویس متوجه اشکال در سیستم شود یا نتواند از سرویس ما استفاده کند. بسته به نوع نرم‌افزار یا سرویسی که ارائه می‌شود، هر لحظه خرابی یا وجود اشکال در سیستم ممکن است خسارت‌های زیادی به اعتبار کسب‌وکار بزند.برای بازیابی و رفع اشکال و همچنین پیداکردن ریشه‌ی مشکل نیز نیاز داریم تا وضعیت سرویس و زیرساخت را در لحظه‌ی رخ‌دادن حادثه بدانیم. برای مثال باید بفهمیم برنامه‌ی ما به دلیل کمبود پهنای باند دچار حادثه شده است یا به دلیل کمبود حافظه. در زمان حادثه چه تعداد تراکنش در دقیقه را پردازش می‌کرده‌ایم و ... .همچنین برای ما بسیار مطلوب است اگر قبل از بروز حادثه و قطع شدن سرویس از آن باخبر شویم. برای مثال با بروز اولین نشانه‌های خرابی یا کندی و قبل از اینکه سرویس کاملاً از کار بیفتد بتوانیم از آن باخبر شویم و برای آن چاره‌ای پیدا کنیم یا از بروز حادثه جلوگیری کنیم تا کاربر سرویس متوجه مشکل نشود.علاوه بر همه‌ی اینها برای بهبود کارایی برنامه نیز نیاز داریم تا به‌صورت منظم به وضعیت زیرساخت و سرویس دسترسی داشته باشیم. برای مثال می‌خواهیم نرخ تراکنش‌های پردازش شده در ثانیه را بهبود دهیم. برای این کار لازم است بفهمیم که چه منبعی در حال حاضر گلوگاه برنامه‌ی ماست. آیا منابع پردازشی را باید بیشتر کنیم یا اینکه سوئیچ‌های شبکه را بهبود دهیم؟پایش کردن نرم‌افزار می‌تواند در تمامی موارد گفته شده در بالا به ما کمک کند.آشنایی با مفاهیم پایشسیستم پایش (monitoring system)، سیستمی است که با جمع‌آوری و ذخیره‌سازی اطلاعات مختلف از سرویس‌ها و نرم‌افزارهای ما، کمک می‌کند دید خوبی نسبت به وضعیت سلامتی نرم‌افزار پیدا کرده و درک خود را از رفتار نرم‌افزار و اثرات تغییرات خود بهبود دهیم. همچنین این در این سیستم می‌توانیم قوانین مختلفی را تعریف کنیم تا درصورتی‌که نرم‌افزار رفتار عادی نداشت به ما هشدار بدهد و ما را از وضعیت نرم‌افزار در اولین فرصت ممکن مطلع کند.سنجه (metric)، پایش (monitoring)و هشداردهی (alerting) سه تا از اساسی‌ترین مفاهیم یک سرویس پایش (monitoring systrm) هستند.سنجه به مقدار اندازه‌گیری شد‌ه‌ی خامی گفته می‌شود که قابل جمع‌آوری از نرم‌افزار است و معمولاً مصرف یک منبع یا رفتار خاصی در سیستم را نشان می‌دهد. برای مثال میزان رم استفاده شده توسط نرم‌افزار یک سنجه است. سنجه‌ها ممکن است سطح پایین یا سطح بالا باشند. برای مثال اطلاعات منابع سیستم‌عامل یا سرور (رم، سی‌پی‌یو، حافظه و ...) به‌عنوان سنجه‌های سطح پایین شناخته می‌شوند. از طرف دیگر سنجه‌هایی عملکرد خاصی در نرم‌افزار را نشان می‌دهند مثل تعداد درخواست پردازش شده در دقیقه برای وب سرور یا تعداد کاربران ثبت‌نام‌شده در روز به‌عنوان سنجه‌های سطح بالا به‌حساب می‌آیند.معمولاً سنجه‌هایی که توسط سیستم‌عامل در اختیار قرار می‌گیرند از ساده‌ترین و اولین سنجه‌هایی هستند که می‌توان جمع‌آوری کرد. این سنجه‌ها میزان استفاده از منابع فیزیکی را نشان می‌دهند. ابزارهای پایش معمولاً بلدند با هزینه کم اطلاعات سرورها و زیرساخت را جمع‌آوری کنند و نشان دهند. همچنین بعضی از آن‌ها به‌صورت پیش‌فرض برای منابع سرور هشدار و قوانینی تعریف کرده‌اند که می‌تواند کاربردی باشد و با هزینه کم، پایش خوبی از زیرساخت را فراهم کند.همچنین بسیاری از پایگاه‌‌داده‌ها و وب سرورها، سنجه‌های استانداردی را تعریف کرده‌اند و به‌راحتی سیستم‌های پایش می‌توانند اطلاعات آن‌ها را نمایش دهند. برای برنامه‌های دیگر باید خود برنامه‌نویس‌ها سنجه‌های لازم را تعریف کنند. برای مثال اگر ما در حال نوشتن برنامه‌ی یک فروشگاه آنلاین هستیم، لازم است که سنجه‌های مختلفی را تعریف کنیم تا وضعیت نرم‌افزار را نشان دهند. برای مثال تعداد خریدهای انجام شده در دقیقه یا تعداد درخواست‌های دارای خطا و ... .پایش چیست؟پایش، فرایند جمع‌آوری، تجمیع و تحلیل مقادیر سنجه‌های مختلف در سیستم است که آگاهی ما را از مؤلفه‌های مختلف سیستم بالا می‌برد. داده از مکان‌های مختلف در سیستم جمع‌آوری شده در سیستم پایش ذخیره می‌شوند. اینم سیستم پایش است که مسئول نگهداری داده‌ها و انجام پرس‌وجو بر روی آن‌هاست.سیستم‌های پایش کارهای مختلفی انجام می‌دهند. اولین وظیفه‌ی آن‌ها جمع‌آوری و ذخیره‌ی مقدار فعلی سنجه‌های مختلف است. با اینکه دانستن مقادیر سنجه‌های مختلف در حال حاضر قابلیتی کاربردی است اما ما برای استفاده‌ی بهتر نیاز داریم تا بتوانیم مقادیر سنجه‌های مختلف درگذشته را نیز بدانیم و این وظیفه‌ی سیستم پایش است که مقادیر سنجه‌های مختلف در گذر زمان را نگهداری کرده و بتواند به ما نشان دهد.با اینکه دیدن مقادیر عددی سنجه‌های مختلف کاربردی است اما ما انسان‌ها معمولاً با دیدن نمودارها راحت‌تر هستیم و اطلاعات بیشتری را می‌توانیم از نمودار استخراج کنیم. اغلب سیستم‌های پایش امکاناتی برای مصورسازی سنجه‌ها و شخصی‌سازی آن‌ها دارند که بسیار کاربردی است.بعضی از سیستم‌های پیشرفته امکاناتی مثل پیداکردن الگو بین سنجه‌ها و همچنین کوریلیشن بین آن‌ها را نیز دارند که در سیستم‌های پیچیده و بزرگ بسیار کارآمد است. اکثر سیستم‌های رایگان دارای چنین قابلیت‌هایی نیستند.هشداردهی در سیستم‌های پایشیکی از قابلیت‌های بسیار کاربردی سیستم‌های پایش، هشداردهی است. ما می‌خواهیم که در اولین فرصت ممکن از حادثه‌ها یا وضعیت بد سرویس مطلع شویم. در واقع برنامه‌نویس‌ها و مسئولان نگهداری هر سرویس باید اولین افرادی باشند که متوجه وضعیت غیرعادی می‌شوند. به همین دلیل لازم است که سیستم پایش به طور مرتب وضعیت سرویس را بررسی کرده و در صورت لزوم به افراد لازم اطلاع دهد.معمولاً در سیستم‌های پایش این قابلیت وجود دارد که چندین قانون برای هشداردهی تعریف شود. این قوانین برحسب نیاز و به صلاح دید برنامه‌نویس‌های سیستم تعریف می‌شوند. این وظیفه‌ی سیستم پایش است که این قوانین را مرتب بررسی کرده و درصورتی‌که هر قانون برقرار شد هشداری را به افراد لازم بفرستد. با استفاده از این قابلیت مسئولان نگهداری سرویس می‌توانند قوانینی طراحی کنند تا درصورتی‌که اوضاع سیستم به‌صورت غیرعادی بود، هشدار دریافت کنند و هرچه سریع‌تر مشکل را برطرف کنند.همچنین سیستم‌های پایش می‌توانند به جز هشداردهی عملیات‌های دیگری را نیز انجام بدهند. برای مثال اگر تعداد درخواست‌ها زیاد بشود می‌توانند به Orchestrator پیام بدهند تا تعداد نرم‌افزارها را به‌صورت اتوماتیک بیشتر کند.محتوای هشدارهایی که به افراد ارسال می‌شوند باید به‌گونه‌ای باشد که مشخص کند چه چیزی مشکل پیدا کرده و کجا باید دنبال مشکل بگردند. یکی از چالش‌های موجود در این حوضه این است که چگونه در عین تعریف هشدارهای کم به نتیجه‌ی مطلوب دست پیدا کنیم. برای مثال اگر ما 1000 سرور داشته باشیم و شبکه‌ی کلاستر برای مدتی قطع شود ممکن است 1000 هشدار ارسال شود و افراد را اذیت کند. به همین دلیل یکی از قابلیت‌های سیستم‌های پایش alert correlation است. با این قابلیت سعی می‌شوند هشدارهایی که به هم مربوط هستند شناسایی شوند و تعداد هشدارها کم بشود. برای مثال اگر هشدار قطع شدن نتورک کلاستر به وجود آمد دیگر به‌ازای تک‌تک سرورها نباید هشدار بیاید.در پروژه‌های نرم‌افزاری بهتر است که از همان اول به فکر پایش آن باشیم و نرم‌افزار را با این دید طراحی کنیم. اضافه‌کردن پایش به سیستمی که با این دید طراحی نشده است ممکن است کار پرهزینه و سخت‌تری باشد. همچنین اضافه‌کردن پایش از همان اول به ما کمک می‌کند سیستم را بهتر تحلیل کنیم و دید مناسبی از فرایند توسعه و پیشرفت آن داشته باشیم.معرفی ابزارهای موجود برای مانیتورینگزبیکس (Zabbix)زبیکس یکی از قدیمی‌ترین سیستم‌های پایش متن‌باز است که هسته‌ی اصلی آن با زبان C نوشته شده است و فرانت‌اند آن با PHP کار می‌کند. زبیکس درگذشته بسیار محبوب بود اما با آمدن ابزارهای جدید و پردازش‌های ابری از محبوبیت آن کاسته شد. زبیکس برای ذخیره‌سازی سازی داده از RDBSها استفاده می‌کند و همین یکی از دلایلی است که به‌خوبی scale نمی‌شود و نمی‌تواند روی داده‌های بسیار حجیم با سرعت خوبی کار کند. نکته‌ی قوت زبیکس UI بسیار کامل و جذاب آن است به‌گونه‌ای که تمامی تنظیمات از طریق یوآی قابل انجام است و همچنین نمودارهای خوبی می‌کشد. در زبیکس مؤلفه‌ای وجود دارد به اسم Zabbix agent که بر روی سرورهای مختلف نصب می‌شود و زبیکس می‌تواند از ایجنت خود داده‌های آن سرور را دریافت کند. یکی دیگر از مزیت‌های زبیکس نداشتن قابلیت query زدن ساده بر روی تمامی سنجه‌ها هست.پرومتئوس (Prometheus)پرومتئوس یکی از ابزارهای قدرتمند، معروف و متن‌باز موجود برای پایش است. این ابزار در ابتدا در شرکت SoundCloud ساخته شد و اکنون به‌صورت مستقل و متن‌باز توسعه داده می‌شود. در اصل پرومتئوس ازروی سیستم مانیتورینگ گوگل به اسم Borgmon ساخته شده است و با زبان Go برنامه‌نویسی شده است. این سیستم در حال حاضر یکی از بهترین گزینه‌های رایگان برای پایش است. پرومتئوس دیتابیس time-series مخصوص خودش را دارد و داده‌ها را با فرمت خودش ذخیره می‌کند. یکی از مزیت‌های این کار این است که پرومتئوس به نسبت زبیکس پرفورمنس بسیار بهتری را ارائه می‌دهد و داده‌های بیشتری را می‌تواند ذخیره کند. همچنین پرومتئوس زیان پرس‌وجوی مخصوص به خود به اسم PromQL را ارائه داده است که اجازه می‌دهد بر روی تمامی متریک‌ها پرس‌وجو انجام شده و آن‌ها را به‌صورت سرپایی بررسی کنید. این قابلیت یکی از مزیت‌های بسیار جدی پرومتئوس به نسبت زبیکس است.پرومتئوس با پروتکل HTTP کار می‌کند و به‌طورکلی pull-based است. این ابزار برای جمع‌آوری نیاز دارد تا مؤلفه‌های مختلف روی port مشخص و با فرمت مشخص شده با پروتکل HTTP سنجه‌های خود را ارائه دهند. پرومتئوس بر اساس کانفیگ انجام شده هرچند لحظه یکبار این اندپوینت‌ها را بررسی کرده و آخرین سنجه‌ها و مقادیر آن‌ها را ذخیره می‌کند.خیلی از برنامه‌ها به‌صورت پیش‌فرض اندپوینتی مخصوص پرومتئوس دارند اما برای آن‌هایی که به‌صورت پیش‌فرض اندپونت پرومتئوس ندارند باید برنامه‌ای به اسم exporter نوشته شود تا مقادیر را از برنامه‌ی لازم گرفته و به فرمت لازم ارائه دهد. یکی از نقاط قوت پرومتئوس داشتن کامیونیتی قوی و exporterهای زیاد است.همچنین پرومتئوس یک exporter به اسم node_exporter دارد که روی سرور نصب می‌شوند و می‌تواند سنجه‌های بسیار کاملی را از سرور ارائه دهد. علاوه بر همه‌ی اینها پرومتئوس مؤلفه‌ای به اسم alertmanager دارد که وظیفه‌ی آن مدیریت هشدار‌ها و ارسال هشدارها به افراد است. همچنین این مؤلفه می‌تواند هشدارها را گروه‌بندی کند و هشدارهای تکراری را حذف کند یا رابطه‌ی بین هشدارها را گرفته و بر اساس آن تشخیص بدهد چه هشداری را باید ارسال کند.معرفی شرکت‌های موجود در ایرانشرکت همروش یکی از شرکت‌های موجود در ایران است که خدمات ابری ارائه می‌دهد. بر اساس اطلاعات ارائه شده در سایت این شرکت، نرم‌افزارهای استقراریافته در پلتفرم این شرکت با استفاده از پرومتئوس پایش می‌شوند و کاربران نیز می‌توانند از این اطلاعات استفاده کنند. همچنین این شرکت سرویس آپداموس را نیز ارائه می‌دهد که برای مانیتور کردن وب‌سایت‌ها و بالا بودن آن‌هاست.شرکت سحاب پرداز نیز از دیگر شرکت‌هایی است که در این زمینه فعال است. این شرکت در حوزه‌ی big data فعالیت می‌کند و با تجربه‌ی چندین‌ساله در پایش سرورها می‌تواند خدمات مشاوره‌ای خوبی در این زمینه ارائه دهد.جمع‌بندیدر این مقاله به معرفی پایش و اهمیت آن پرداختیم و با مفاهیم اصلی آن آشنا شدیم. همچنین به معرفی دوتا از ابزارهای بسیار معروف در این حوزه پرداختیم و نقاط قوت و ضعف هرکدام را بررسی کردیم. در نهایت دوتا از شرکت‌های نرم‌افزاری ایران که در این حوزه فعال هستند را معرفی کردیم.این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است.منابعhttps://www.digitalocean.com/community/tutorials/an-introduction-to-metrics-monitoring-and-alertinghttps://www.ibm.com/cloud/learn/application-performance-managementمحمدصادق دهقانمحمدصادق دهقانSat, 25 Dec 2021 00:22:39 +0330https://virgool.ir/@msdehghan77/c4-model-arch-petzp9f7080rما برنامه‌نویس‌ها معمولاً برای اینکه با ساختار کلی یک نرم‌افزار آشنا شویم، ابتدا به سراغ مستندات معماری آن نرم‌افزار می‌رویم. مستند معماری هر نرم‌افزار سندی است که کمک می‌کند ذی‌نفعان مختلف یک پروژه فهم مشترکی از نقاط کلیدی و روش عملکرد آن پروژه پیدا کرده و به درک یکسانی از پروژه برسند. در فرایند توسعه‌ی یک پروژه نرم‌افزاری، ذی‌نفعان مختلفی مثل مدیر پروژه، کاربر، کارفرما، برنامه‌نویس، مدیر فنی و ... با تخصص‌ها و پیشینه‌های مختلفی وجود دارند. مستند معماری باید برای تمامی این افراد قابل‌فهم باشد و به‌نوعی یک نقطه‌ی ارتباطی این افراد باشد.اگر به تیم‌های نرم‌افزاری مختلف رجوع کنید و از آن‌ها بخواهید که نمودار معماری نرم‌افزار خود را بکشند، معمولاً با نمودارهایی پر از خطوط و اشکال مختلف روبرو خواهید شد که اغلب نامفهوم، بدون اسم‌گذاری‌های صحیح و همچنین دارای نشانه‌گذاری‌های ناسازگارند. نکته‌ی جالب این است که اگر نمودار معماری نرم‌افزار یک تیم را به تیم دیگری بدهید، به‌احتمال بالا اعضای آن نمی‌توانند معماری نرم‌افزار را به‌درستی بفهمند و درک کنند و با نمودار ارتباط برقرار کنند.یک نمودار معماری نرم‌افزار!برای اینکه نمودار معماری نرم‌افزار توسط ذی‌نفعان مختلف قابل‌فهم باشد، نیازمند به نمادها و نشانه‌گذاری‌های یکسان و البته ساده‌ای هستیم تا که توسط اکثر افراد قابل‌فهم باشد. در طول زمان در صنعت نرم‌افزار نماد‌ها و استانداردهای مختلفی برای کشیدن نمودارها به وجود آمده‌اند. یکی از نمونه‌های معروف در این زمینه، نمودارهای UML است. نمودارهای UML در گذشته پراستفاده‌تر و رایج‌تر از امروز بودند اما رفته‌رفته از محبوبیت آن‌ها کاسته شد. یکی از دلایلی که باعث شده است تیم‌های نرم‌افزاری UML را کنار بگذارند، پیچیدگی و تنوع زیاد نمادها و نشانه‌گذاری‌ها است. ضعف دیگر UML کمبود لایه‌های مختلف انتزاع برای نشان‌دادن معماری است. افراد مختلف برای فهم نرم‌افزار نیازمند به سطوح مختلفی از انتزاع هستند و روش ما برای مدل کردن معماری نرم‌افزار باید به‌خوبی این سطوح را مدل کند.معرفی C4 modelمدل C4 یکی از مدل‌های معروف برای مستند کردن و مدل کردن معماری نرم‌افزار است. در این مدل توجه ویژه‌ای به لایه‌های مختلف انتزاع شده است. همچنین سعی شده است که نمادها و علائم این مدل تاحدامکان ساده و قابل‌فهم برای عموم باشد. بر خلاف بعضی از مدل‌های دیگر، در این مدل توصیه می‌شود که برای هر نماد عنوان و توضیح کوتاهی نوشته شود. به همین دلیل معمولاً نمودارهای C4 متن بیشتری نسبت به دیگر نمودارها دارند.نمایش کلی از مدل C4همان‌طور که در اسم مدل نیز مشخص است، مدل C4 از چهار لایه‌ی انتزاع تشکیل شده است که عبارت‌اند از Component، Container ، Context و Code. در ادامه به توضیح مختصری از این لایه‌ها می‌پردازیم و نمونه‌ای از هرکدام را می‌آوریم.لایه‌ی Contextاین لایه بالاترین سطح انتزاع در مدل ماست که طرح کلی نرم‌افزار را نشان می‌دهد. در این لایه به بازیگران و سیستم‌های خارجی و نحوه‌ی ارتباط آن‌ها با سیستم خودمان می‌پردازیم و از جزئیاتی مثل پروتکل‌ها و تکنولوژی‌های استفاده شده صرف‌نظر می‌کنیم. مخاطب این لایه همه‌ی افراد اعم از فنی و غیرفنی هستند.نمونه‌ای از نمودار Context در مدل C4لایه‌ی Containerهر Container نشان‌دهنده‌ی یک نرم‌افزار قابل‌اجرا و یا یک پایگاه ذخیره‌سازی داده است. کانتینر بخشی از نرم‌افزار است که به‌صورت جداگانه قابل استقرار (deploy) است و اجرا شدن آن برای کارکرد کلی سیستم لازم است. برای مثال یک Web application، پایگاه‌داده یا یک برنامه‌ی موبایلی مثال‌هایی از یک Container هستند.این لایه از سطح انتزاع کمتری نسبت به Context برخوردار است و در واقع مولفه‌های داخلی سیستم، نحوه‌ی ارتباط آن‌ها، نحوه‌ی تقسیم وظایف بین آن‌ها، تصمیم های اصلی معماری و تکنولوژی های انتخاب شده را نشان می‌دهد. مخاطب اصلی این لایه افراد فنی داخل و خارج از سازمان هستند. دقت شود که در این نمودار از نحوه‌ی استقرار و یا کلاستر شدن اجزا حرفی نمی‌زنیم.نمونه‌ای از نمودار Components در مدل C4لایه‌ی Componentدر این لایه سطح انتزاع بازهم کاهش می‌یابد و اجزا داخل یک Container نمایش داده می‌شود. در اینجا منظور از Componentمجوعه‌ایی از کدهاست که پشت که واسط(API) مناسب و مستند شده قرار گرفته اند. معمولا کل Componentهای داخل یک Containerداخل یک processاجرا می‌شوند. نکته‌ی حائز اهمیت در اینجا این است که Component ها به تنهایی قابل استقرار و اجرا نیستند و یک واحد کاملا مستقل به حساب نمی‌آیند.این لایه شامل وظایف بخش‌های داخل یک Container، وظایف هرکدام و جزئیات تکنولوژی‌ها و پیاده‌سازی آنها است. مخاطب این لایه برنامه‌نویسان و معمار داخلی هر تیم است. همچنین توصیه می‌شود که این نمودار به‌صورت خودکار از داخل کد تولید شود.نمونه‌ای از نمودار Components در مدل C4لایه‌ی Codeدر نهایت جزئی‌ترین لایه در مدلC4 لایه‌ی کد است. این لایه شامل نمودار UML یا نمودارEntity relationship یک Component است و شامل جزئیات پیاده‌سازی است. این لایه معمولاً به‌صورت خودکار توسط IDEها قابل تولید است و پیشنهاد می‌شود که از این لایه مگر برای بخش‌های خیلی مهم و پیچیده استفاده نشود. همچنین در نمودار UML نیز فقط ویژگی‌ها و اجزای که برایمان اهمیت دارند و قرار است آن‌ها را توضیح دهیم را نمایش می‌دهیم. مخاطب این نمودار برنامه‌نویسان و طراح معماری داخل تیم است.نمونه‌ای از یک نمودار UML برای لایه‌ی کد در مدل C4نمادگذاریهمان‌طور که در ابتدا گفتیم یکی از اهداف مدل C4 استفاده نمادگذاری ساده و قابل‌فهم است تا یادگیری و به‌یادسپاری را تسهیل کند. مدل کشیده باید به‌گونه‌ای باشد که حتی با استفاده از ساده‌ترین اشکال نیز قابل‌فهم باشد. نمونه‌ای چند شکل پراستفاده در مدل C4 در زیر آورده شده است:بعضی از علائم رایج در مدل C4جمع‌بندیمدل C4 یکی از روش‌های مستند کردن و مدل کردن معماری نرم‌افزار است. در این مدل می‌توان متناسب با سطح مخاطب لایه‌های مختلف انتزاع را در نظر گرفت و مدل کرد. همچنین بر خلاف دیگر روش‌ها، مدل C4 از علائم و نشانه‌گذاری بسیار ساده‌ای بهره می‌برد.این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است.منابع https://c4model.com/ https://www.youtube.com/watch?v=Ym9nhVZs89ohttps://www.youtube.com/watch?v=x2-rSnhpw0gمحمدصادق دهقانمحمدصادق دهقانSun, 21 Nov 2021 00:12:43 +0330