https://virgool.io/feed/@aminbagheri021 fa 2026-06-16 13:28:20 https://static.virgool.io/images/default-avatar.jpg https://virgool.io/@aminbagheri021 https://virgool.io/@aminbagheri021/%D8%A8%D8%B1%D8%B1%D8%B3%DB%8C-%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D9%87%D8%A7%DB%8C-%D9%85%D8%A8%D8%AA%D9%86%DB%8C-%D8%A8%D8%B1-%D9%85%DB%8C%DA%A9%D8%B1%D9%88%D8%B3%D8%B1%D9%88%DB%8C%D8%B3-cc4rsz6kvuub چكيدهدر سال های اخیر، تغییری محسوس در رویکرد مورد استفاده برای توسعه و ارائه برنامه های کاربردی و سرویس ها بوجود آمده است. سبک معماری میکروسرویس که به اختصار میکروسرویس گفته می شود، جایگاه خود را در صنعت نرم افزار بدست آورده است. معماری میکروسرویس، یک سبک معماری است که در آن، یک برنامه کاربردی از مجموعه ای از سرویس های کوچک با کمترین وابستگی نسبت به یکدیگر و قابل توسعه و استقرار به طور مستقل از هم تشکیل شده است. این معماری، تحویل سریع، مکرر و قابل اعتماد برنامه های کاربردی بزرگ و پیچیده را امکان پذیر می کند. معماری های میکروسرویس، بر مدل های رایانش ابری، رایانش مه و اینترنت اشیا نیز تاثیرگذار بوده اند. اين گزارش نمايانگر مطالعات انجام شده براي پروژه نهايي درس معاری نرم افزار است؛ این پروژه، رویکردی مروری داشته و در آن به مفهوم معماری میکروسرویس و مقایسه آن با معماری های یک تکه و سرویس گرا پرداخته، معماری های میکروسرویس ارائه شده در دامنه های موضوعی مختلف از جمله رایانش ابری و اینترنت اشیا را بررسی کرده و در نهایت به یک دسته بندی از الگو های مورد استفاده در معماری های میکروسرویس پرداخته مي شود.كلمات كليديمیکروسرویس، معماری میکروسرویس، سبک معماری، الگوی معماری۱- مقدمهمعماری میکروسرویس در چندسال اخیر به شدت در حال گسترش و فراگیری در میان توسعه دهندگان و معماران است. اگرچه اولین اشاره مستقیم به واژه "میکروسرویسها" به سال 2011 و در یک کارگاه معماری نرم افزار برمی گردد، اما داغ شدن این موضوع در طی سالهای 2014 و 2015 بود؛ هم اکنون میکروسرویس ها یکی از موضوعات جذاب در دنیای نرم افزار و معماری محسوب می شود و هرماه مقالات، کتاب ها و ارائه های جدیدی از آن منتشر می شود و در کنفرانس ها یا سمینارهای تجاری-علمی نیز علاقه مندان زیادی را به خود جذب می کند؛ حتی بر اساس گزارش های گوگل از میزان رشد جستجوی عبارات مرتبط با میکروسرویس، می توان به نقش محوری آن در معماری و توسعه سیستم ها پی برد.در دنیای تجاری نیز شرکت های مطرحی پیشگام پیاده سازی و استقرار این معماری بوده اند که می توان به شرکت های Uber ،Netflix ، Amazon ،Ebay و Sound Cloud اشاره نمود.معماری میکروسرویس، سبک خاصی از معماری نرم افزار و مشتق شده از معماری سرویس گرا (SOA) است که هدف آن خودمختاری بالای سرویس ها از نظر منطق کارکردی-داده ای و نیز پلتفرم پیاده سازی و اجرا است. این سبک معماری علاوه بر معماری سرویس گرا از مفاهیم معماری رخداد محور و سیستم های توزیع شده نیز بهره برده است.از معماری های مبتنی بر میکروسرویس در حوزه هاي مختلفي از جمله رایانش ابری، اینترنت اشیا، و... استفاده می شود.اين گزارش جهت مرور و بررسي مفاهیم معماری میکروسرویس، مزایا و معایب این معماری، دامنه های کاربرد آن و الگوهای مورد استفاده در این سبک از معماری تهیه شده است. در بخش دوم، روش تحقیق به کار گرفته شده برای گردآوری این گزارش شرح داده شده است؛ در بخش سوم به تعریف معماری میکروسرویس و مقایسه آن با معماری های یکپارچه و سرویس گرا پرداخته می شود. در بخش چهارم، به موارد کاربردی معماری میکروسرویس در حوزه های مختلف پرداخته می شود. در بخش پنجم، الگو های مورد استفاده در معماری های مبتنی بر میکروسرویس را بررسی کرده و در نهایت به جمع بندی و ذکر مراجع استفاده شده براي نوشتن اين گزارش می پردازیم.2- روش تحقیقهدف اصلی این پژوهش، طبقه بندی معماری های میکروسرویس ارائه شده در دامنه های موضوعی مختلف و همچنین دسته بندی الگو های به کار رفته در این نوع از معماری ها است.برای جستجوری مقالات، از کلیدواژه های زیر استفاده شده است: میکروسرویس ها معماری میکروسرویس الگوهای معماری میکروسرویس سبک های معماریاز میان مقالات جستجو شده با کلید واژه های ذکرشده، تعدادی از مقالات فیلتر شده و جهت مطالعه انتخاب شدند؛ با مطالعه مقالات انتخاب شده، یک طبقه بندی موضوعی از معماری های میکروسرویس و همچنین دسته بندی از الگوهای بکار رفته در این نوع از معماری ها حاصل شد. چند مقاله مروری نیز جهت آشنایی با تفاوت های معماری میکروسرویس با سایر سبک های معماری مطالعه شدند.3- مقایسه معماری میکروسرویس با معماری های یکپارچه و سرویس گرادر این بخش به تعریف و بیان ویژگی های کلیدی معماری های میکروسرویس و یکپارچه، در مقایسه با یکدیگر می پردازیم و مزایا و معایب معماری های میکروسرویس را شرح می دهیم؛ همچنین به به اختصار، تفاوت های مهم معماری میکروسرویس و معماری سرویس گرا را ذکر می کنیم.1-3- معماری یکپارچهمعماری یکپارچه (Monolith Architecture)، یک معماری برای برنامه های کاربردی است که در آن ماژول ها نمی توانند به صورت مستقل از هم اجرا شوند. مشکلاتی که در معماری یکپارچه با آن ها مواجه هستیم عبارت اند از: نگهداری و تکامل برنامه های مبتنی بر معماری یکپارچه به دلیل پیچیدگی، دشوار است؛ ردیابی باگ های برنامه نیز بسیار دشوار و زمان بر است. سیستم های یکپارچه، از «جهنم وابستگی» رنج می برند [1] که در آن، افزودن و یا به روزرسانی کتابخانه ها، منجر به سیستم های ناسازگاری می شود که کامپایل یا اجرا نمی شوند و یا بد اجرا می شوند.هر تغییری در یک ماژول برنامه یکپارچه، نیاز به راه اندازی مجدد کل برنامه دارد؛ برای پروژه های بزرگ، راه اندازی مجدد، معمولا مستلزم خرابی های قابل توجهی است که مانع توسعه، تست و نگهداری پروژه می شود.یکپارچگی، توسعه دهندگان را مجبور می کند که از تکنولوژی های یکسان شامل زبان برنامه نویسی و فریمورک، برای توسعه تمام برنامه استفاده کنند.مقیاس پذیری را محدود می کند؛ استراتژی معمول برای رسیدگی به درخواست‌ها برای تغییر برنامه، ایجاد نمونه‌های جدید از همان برنامه و تقسیم بار بین نمونه‌ها است.سبک معماری میکروسرویس [2] برای مقابله با چنین مشکلاتی پیشنهاد شده است. در تعریف میکروسرویس، ما از اصطلاح «منسجم» (Cohesive) [3] استفاده می‌کنیم تا نشان دهیم که یک سرویس، تنها عملکردهایی را پیاده‌سازی می‌کند که کاملا مرتبط با دغدغه هایی هستند که قرار است مدل‌ کند.2-3- میکروسرویسیک میکروسرویس، فرآیندی منسجم و مستقل است که از طریق پیام‌ با دیگر میکروسرویس ها در تعامل است.از نقطه نظر فنی، میکروسرویس ها باید مولفه های مستقلی باشند که به صورت مجزا مستقر شده و مجهز به ابزارهای اختصاصی ماندگاری حافظه (به عنوان مثال، پایگاه های داده) باشند. از آنجایی که تمام اجزای یک معماری میکروسرویس، میکروسرویس ها هستند، رفتار متمایز آن، از ترکیب و هماهنگی مولفه های آن از طریق پیام ها ناشی می شود. در شکل ۳-۱ نمونه ای از عناصر یک سیستم ساده فروش اینترنتی مبتنی بر معماری میکروسرویس نشان داده شده است.شکل 3-1 نمونه سیستم ساده فروش اینترنتی مبتنی بر معماری میکروسرویس 3-3- معماری میکروسرویستعاریف مختلفی تاکنون برای معماری میکروسرویس ارائه شده است که در ادامه، ۳ تعریف که توسط مراجع معتبر ارائه شده است را مرور می کنیم:سبک معماری مایکروسرویس، رویکردی برای توسعه یک نرم افزار متشکل از تعدادی سرویس کوچک و مستقل است که هر سرویس به اتکاء منابع و زیرساخت خودش اجرا شده و از طریق پروتکل های سبک مبتنی بر HTTP با دیگران ارتباط دارد. این سرویس ها براساس قابلیت های کسب وکار، طراحی و ساخته می شوند و بر بسترهای فناوری با زبان های برنامه نویسی مختلفی قابل استقرار هستند. این سرویس ها حداقل نیاز به مدیریت متمرکز را دارند و هر سرویس پایگاه داده مخصوص به خود را مدیریت می کند [2].معماری مایکروسرویس یک رویکرد مهندسی مبتنی بر شکست نرم افزار به ماژول های تک کارکردی است که مستقل تولید و مستقر می شوند و با واسط های خوش تعریف با دیگر سرویس ها ارتباط دارند. این سرویس ها توسط تیم های کوچکی تولید و پشتیبانی می شوند که از تمام چرخه حیات سرویس پشتیبانی می کند [4].مایکروسرویس ها یک تکنیک توسعه نرم افزار مشتق شده از سبک معماری سرویس گرا است که از مجموعه ای از سرویس های خوش تعریف تشکیل شده است. در معماری مایکروسرویس پروتکل های ارتباطی، سبک و مستقل از پلتفرم هستند و سرویس ها دامنه و مسئولیت معین و مشخصی دارند؛ مزایای این معماری بهبود ماژولاریتی سیستم و تسهیل توسعه، استقرار و تست سیستم است؛ همچنین سیستم توسعه یافته دارای مقیاس پذیری بالا و سرعت بالاتر اعمال تغییر است. این معماری با رویکرد DevOps در توسعه و پشتیبانی نرم افزارها هماهنگی دارد [5].به طور ساده می توان اینگونه بیان کرد که معماری میکروسرویس، یک برنامه کاربردی توزیع شده است که تمام ماژول های آن، میکروسرویس هستند.سبک معماری میکروسرویس، هیچ پارادایم برنامه نویسی خاصی را حمایت و یا منع نمی کند و در واقع یک دستورالعمل برای پارتیشن بندی اجزای یک برنامه کاربردی توزیع شده به موجودیت های مستقل ارائه می دهد که هر کدام به یکی از دغدغه های برنامه می پردازد؛ این بدان معنی است که یک میکروسرویس، به شرطی که عملکردهای خود را از طریق ارسال پیام ارائه دهد، می تواند به صورت داخلی با هر یک از زبان های برنامه نویسی، پیاده سازی شود.اصل معماری میکروسرویس، به مدیران و توسعه دهندگان پروژه کمک می کند تا یک خط راهنما برای طراحی و اجرای برنامه های کاربردی توزیع شده داشته باشند؛ با پیروی از این اصل، توسعه دهندگان، بر پیاده‌سازی و تست چند قابلیت منسجم، تمرکز می کنند. این اصل همچنین برای میکروسرویس‌های سطح بالاتر که به هماهنگ کردن عملکردهای میکروسرویس‌های دیگر کمک می کنند، صدق می‌کند. در شکل 3-2 ساختار رایج معماری میکروسرویس و معماری یکپارچه را مشاهده می کنید.شکل 3-2 مقایسه معماری میکروسرویس با معماری یکپارچهدر ادامه به طور خلاصه به برخی از تفاوت های مهم معماری میکروسرویس با معماری سرویس گرا اشاره می کنیم:در معماری سرویس گرا، سیستم به چند سرویس که کارکرد های تجاری (Business Functionalities) و درشت دانه سیستم را برمی‌گیرند شکسته می شود؛ اما در معماری میکروسرویس، سیستم با توجه به مفاهیم DDD و Bounded By Context به میکروسرویس هایی که هریک از آنها کوچکترین کارکرد ها را در برمی گیرند شکسته می شود.در میکروسرویس بر استقرار مستقل هر میکروسرویس تاکید بسیار زیادی وجود دارد.در معماری میکروسرویس استفاده از API Gateway اما در معماری سرویس گرا، استفاده از ESB رایج است.در معماری سرویس گرا، برای ارتباط هر سرویس با EBS، از پروتکل های مختلفی می توان استفاده کرد اما در معماری میکروسرویس از یک پروتکل ارتباطی یکسان و سبک وزن، استفاده می شود.میکروسرویس ها برخلاف ها سرویس ها معمولا منطق داده ای مستقلی دارند.در ادامه به طور مختصر، برخی از مزایا و معایب این معماری را بررسی می کنیم [6]:1-3-3- مزایای معماری میکروسرویسبه دلیل امکان توسعه و استقرار هر میکروسرویس به طور مستقل از سایر میکروسرویس ها و امکان توسعه هر میکروسرویس توسط یک تیم توسعه، زمان آماده شدن برنامه کاربردی برای ارائه به بازار (Time to Market)، کاهش می یابد. هر تیم برای توسعه میکروسرویس، از تکنولوژی های دلخواه خود می تواند استفاده کند و نیاز به یکسان بودن تکنولوژی های مورد استفاده در توسعه میکروسرویس ها نیست.میکروسرویس ها قابلیت مقیاس پذیری بالایی دارند؛ از آنجایی که هر سرویس مستقل است، افزودن نمونه های سرویس به صورت پویا ساده است. به این ترتیب عرضه خدمات به راحتی با تقاضا، تطبیق داده می شود.2-3-3- معایب معماری میکروسرویسبه دلیل تقسیم برنامه به تعدادی میکروسرویس، بار شبکه برای هماهنگی و ارتباط میان میکروسرویس ها افزایش می یابد و این موضوع باعث ایجاد سربار در شبکه می شود.آزادی هر تیم در انتخاب فناوری، خود هزینه دارد که سازمان باید آن فناوری‌ها و پایه تجربه مورد نیاز را داشته باشد و از آن نگهداری کند.طراحی سرویس ها برای داشتن مسئولیت های مناسب و سطح مناسبی از دانه بندی، یک کار طراحی دشوار است.4- معماری های میکروسرویس در دامنه های موضوعی خاصمعماری میکروسرویس در چندین حوزه کاربردی، مورد استفاده قرار می گیرد. محققان تلاش هایی برای ادغام مفاهیم میکروسرویس با برنامه های کاربردی در دامنه های مختلف از جمله اینترنت اشیا و رایانش ابری انجام داده اند که در این بخش به این موارد کاربردی می پردازیم.در شکل 4-1، دسته بندی حاصل از معماری های میکروسرویس مطالعه شده در مقالات را در قالب یک درخت موضوعی مشاهده می کنید.شکل ۴-۱ درخت موضوعی معماری های میکروسرویس مطالعه شده1-4- سیستم های توزیع شدهمعماری میکروسرویس مورد پذیرش جامعه محاسبات توزیع شده قرار گرفت؛ رایانش ابری و سیستم های ذخیره سازی توزیع شده از مزایای معماری های میکروسرویس می توانند بهره ببرند. بخش های فرعی زیر، رویکرد های مختلف در سیستم های توزیع شده را مورد بحث قرار می دهد.1-1-4- رایانش ابری[7] در مورد استفاده از میکروسرویس ها برای ارائه خدمات شبکه در مراکز داده ابری بحث کرده است. سیستم پیشنهادی، از میکروسرویس ها در سطوح مختلف که با Data Plane در ارتباط هستند، برای انجام فعالیت های امنیتی شامل نظارت بر ترافیک شبکه و گزارش تهدید های امنیتی استفاده می کند.[8] روش BigVM را برای کاهش بار مسئولیت توسعه دهندگان SaaS، با خودکارسازی توسعه برنامه های کاربردی SaaS مبتنی بر میکروسرویس ها ارائه دادند. BigVM می تواند کارایی سیستم را با افزودن مولفه های خاص از جمله یک موتور ارکستراسیون میکروسرویس برای هماهنگی میکروسرویس ها و یک موتور گردش کار که بوسیله آن، می‌توان ریزسرویس‌ها را در طول زمان اجرا طراحی و به صورت پویا سفارشی کرد، افزایش دهد. BigVM بر شناسایی میکروسرویس هایی تمرکز دارد که در کاربردهای متعدد به شدت مورد استفاده مجدد قرار می گیرند. مجموعه ای از رابط های مؤلفه استاندارد شده و پروتکل های ارتباطی سرویس به گونه ای پیاده سازی شده اند که این میکروسرویس ها می توانند به طور کامل در BigVM نگهداری شوند. علاوه بر این، BigVM یک سلسله مراتب میکروسرویس چند لایه را فعال می کند که در آن میکروسرویس های لایه پایین به عنوان "جعبه سیاه" مشخص می شوند؛ به طوری که توسعه دهندگان SaaS فقط باید با سفارشی سازی خودکار میکروسرویس های لایه پایین تر، با میکروسرویس های لایه بالاتر سروکار داشته باشند. در نتیجه، توسعه‌دهندگان SaaS می‌توانند از استقرار تعدادی از میکروسرویس ها، به عنوان مثال، میکروسرویس‌های مبتنی بر منابع سیستم‌عامل خودداری کنند. در شکل 4-1 ساختار معماری به روش BigVM را مشاهده می کنید.شکل 4-1 معماری BigVM و محیط استقرار[9] یک platform-as-a-service در ابر و مبتنی بر میکروسرویس هایی که در کانتینر ها اجرا می شوند، پیشنهاد کرد. این پلتفرم می تواند توسط توسعه دهندگان برای ساخت سرویس ها در ابر استفاده شود. [10] یک سیستم نظارتی مبتنی بر معماری میکروسرویس برای محیط های ابری پیشنهاد کرد؛ بدین صورت که هر عامل نظارتی به عنوان میکروسرویس هایی بر روی کانتینر ها اجرا می شود.2-1-4- سیستم های ذخیره سازی توزیع شدهسیستم های فایل توزیع شده مانند Azure Data Lake Store برای ارائه خدمات سیستم فایل، به معماری های میکروسرویس متکی هستند [11]. میکروسرویس های مختلفی برای ارائه عملکردهای مدیریتی برای پشتیبانی از عملیات تجزیه و تحلیل داده ها در Big Data استفاده می شوند. میکروسرویس های Azure Data Lake Store با ارائه دهندگان سیستم های ذخیره سازی (Storage) برای انجام عملیات بر روی داده های ذخیره شده در سیستم فایل ارتباط برقرار می کنند. سیستم پایگاه داده مرکز داده تحقیقاتی Nevada برای پیروی از معماری میکروسرویس ها مجدداً طراحی شد [12]. یکی از پروژه های مرکز داده تحقیقاتی نوادا، قصد گسترش بهره برداری از انرژی منابع تجدیدپذیر و به حداقل رساندن پیامدهای آن بر محیط اطراف خود، مانند سطح آب و حیات وحش را دارد. بنابراین پروژه شامل تحویل مقادیر زیادی از داده ها و انجام عملیات تحلیلی بر روی آن ها برای استخراج اطلاعات مفید است.2-4- اینترنت اشیارویکرد های معماری میکروسرویس، برای توسعه برنامه های کاربردی اینترنت اشیا، به دلیل اهداف طراحی مشابه، ایده آل هستند [13].به طور خلاصه، با توسعه فناوری اینترنت اشیا، معماری سنتی نمی‌تواند الزامات سیستم‌های ناهمگن، قابل همکاری، سفارشی‌سازی و مقیاس‌پذیر را برآورده کند. برای مقابله با چالش‌های فوق، [14] یک چارچوب باز اینترنت اشیا را با تجزیه سیستم اینترنت اشیا به میکروسرویس‌ها برای انجام انواع مختلف وظایف ارائه می کند. با استفاده از ارتباط پیام محور و مکانیسم رجیستری/کشف در سرویس اصلی، چارچوب به راحتی می تواند برنامه های شخص ثالث را برای پشتیبانی از قابلیت همکاری و مقیاس پذیری گسترش و تکامل داده و ادغام کند. علاوه بر این، سیستم از پلاگین های دستگاه برای محافظت از تفاوت امکانات سخت افزاری به منظور پشتیبانی از پلتفرم های ناهمگن تر استفاده می کند. به ویژه، همانطور که با یک سری از ریزسرویس ها یکپارچه شده است، این چارچوب مکانیزم قوی برای ترکیب داده های ناهمگن از طریق پیش پردازش سلسله مراتبی داده های حسگرهای انبوه ارائه می دهد.1-2-4- برنامه های زندگی هوشمنداخیرا تعداد محققانی که بر روی برنامه های زندگی هوشمند تمرکز کرده اند، افزایش یافته است. [15] امکان استفاده از معماری میکروسرویس برای سیستم مدیریت بلیط راه آهن آلمان را مطالعه می کند.[16] از محاسبات مه و میکروسرویس ها برای فراهم سازی امکان استفاده از توابع مرجع صدور گواهی (Certificate Authority (CA) Functions) در نزدیکی منابع استفاده می کند. از طریق آن، سطوح حمله و تأخیر احراز هویت را به حداقل رسانده و منجر به طرحی سریع و مقیاس‌پذیر در احراز هویت حجم زیادی از دستگاه‌های با منابع محدود می شود. سپس پروتکل های سبک وزنی را برای رسیدن به سطح بالایی از امنیت و بارهای محاسباتی کم، ارائه می دهد. ارزیابی ها، کارایی و اثربخشی طرح ارائه شده در رسیدگی به احراز هویت تعداد زیادی گره را نشان می دهد و در عین حال از آن ها در برابر تهدیدات مختلف در زندگی هوشمند، محافظت می کند.2-2-4- مراقبت های پزشکی[17] یک رویکرد مبتنی بر میکروسرویس برای سیستم های توانبخشی فیزیکی از راه دور (PTS) پیشنهاد کردند که در آن بیماران می توانند از راه دور به امکانات پزشکی دسترسی داشته باشند. در شکل ۴-۲ معماری میکروسرویس پیشنهادی برای این سیستم را مشاهده می کنید.شکل 4-2 پلتفرم مجهز به اینترنت اشیا – معماری میکروسرویس[18] یک پلتفرم پیشنهادی به نام SPIDEP برای استفاده از میکروسرویس ها در سناریو های پزشکی بیماری های عفونی، ارائه می کند. هدف این پلتفرم، تفسیر تغییرات در علائم حیاتی افراد مسن ساکن در مراکز مسکونی است؛ بنابراین تیم پزشکی را قبل از عفونت های احتمالی آگاه می کند. با این حال این پلتفرم، دارای یک سیستم توصیه کننده برای بهبود پشتیبانی تصمیم در پیش تشخیص بیماری های عفونی می باشد [19].در شکل 4-3 معماری پلتفرم SPIDEP را مشاهده می کنید که در ادامه به طور خلاصه، ارتباط جریان پلتفرم SPIDEP با میکروسرویس ها را توضیح خواهیم داد:معماری لبه: وظیفه جمع آوری، پیش پردازش و ارسال داده از حسگر های بیومتریک مختلف مانند ECG، فشار خون و... را برعهده دارد؛ از داده های جمع آوری شده، به صورت محلی، نسخه پشتیبان تهیه می شود.ارتباط با کاربر: مکانیسم‌های لازم را برای ارتباط صحیح بین لایه‌ها و زیرلایه‌های مختلف (مانند داده‌ها، اعتبارسنجی یا موارد دیگر) فراهم می‌کند. این ارتباط از طریق پروتکل REST بدست می آید. با این حال، این پروتکل نیاز به استفاده از یک دروازه API دارد.معماری ابر: خدماتی را برای کاربران نهایی در قالب میکروسرویس های اصلی یا کمکی، با توجه به نیاز های آن ها و سطوح نقش ها و مجوز های آن ها، فراهم می کند. به علاوه، داده ذخیره شده در پایگاه های داده اختصاصی میکروسرویس ها [20] را برای رساندن مزایایی به کاربران هدف از جمله بیماران، پرسنل پزشکی و مقامات بهداشتی، مدیریت می کند [21].شکل 4-3 ماری پلتفرم SPIDEP[22] یک رویکرد مبتنی بر میکروسرویس را برای پردازش داده‌های مراقبت‌های بهداشتی پیشنهاد کردند. با این حال، محققانی که این رویکرد را اتخاذ می‌کنند باید به مسائل مربوط به امنیت و حریم خصوصی نیز بپردازند. میکروسرویس هایی که داده های حساس را مدیریت می کنند باید به طور جداگانه توسط زیرساخت در هنگام تصمیم گیری مدیریت زیرساخت در نظر گرفته شوند.۵- الگو های مورداستفاده در معماری های میکروسرویسهر معماری میکروسرویس از تعدادی الگوی معماری تشکیل می شود. شناخت الگو های معماری، به توسعه دهندگان کمک می کند که از مناسب ترین معماری برای سیستم خود استفاده کنند. در جدول ۵-۱، الگو هایی که در معماری های میکروسرویس مطالعه شده در مقالات یافت شدند را دسته بندی کرده ایم؛ همچنین مزایا و معایب هر الگو نیز آورده شده است. طبق مطالعه انجام شده، برای orchestration و هماهنگی میان میکروسرویس ها، در معماری های جدید، API Gateway الگوی محبوب و رایجی محسوب می شود. برای نحوه استقرار سرویس ها در زیرساخت، الگوی Multiple service per host الگوی بسیار پرکاربردی می باشد. در بحث ذخیره سازی اطلاعات مربوط به سرویس ها، ۳ الگو داریم که در برنامه های کاربردی جدید، الگوی تخصیص پایگاه داده مجزا به هر سرویس، الگوی پرکاربردتری می باشد. اما برای برنامه هایی که از معماری یکپارچه به معماری میکروسرویس مهاجرت کرده اند، به جهت کاهش Failure های احتمالی و سهولت مهاجرت، معمولا از الگوی استفاده از پایگاه داده مشترک برای سرویس ها استفاده می شود.این جدول به معماران سیستم ها کمک می کند که بسته به کاربرد، شرایط و نیاز سیستم، الگو های مناسب را برای سیستم ها انتخاب کنند.جدول ۵-۱ دسته بندی الگوهای به کار رفته در معماری های میکروسرویس مطالعه شده جمع بندیدر این گزارش ابتدا به مفاهیم بنیادی معماری میکروسرویس پرداخته و این سبک معماری را با معماری های یکپارچه و سرویس گرا مقایسه کردیم؛ همچنین مزایا و معایب این معماری را بررسی کردیم. در ادامه به برخی از موارد کاربردی معماری های میکروسرویس پرداختیم و دیدیم که تا چه اندازه این معماری، در حوزه های مختلف، مورد استفاده قرار می گیرد و استفاده از آن روز به روز در توسعه نرم افزارها، عمومی تر می شود. در نهایت به دسته بندی و بررسی الگوهایی که در معماری های میکروسرویس مطالعه شده به کار رفته اند پرداختیم.دستاورد های اصلی ما از این پژوهش، رسیدن به یک دسته بندی از مقالات مطالعه شده در دامنه های موضوعی مختلف و همچنین جمع آوری الگو های به کار رفته در مقالات و تحلیل و نتیجه گیری از آن ها می باشد.با مطالعه مقالات، دریافتیم که در برنامه های کاربردی مبتنی بر اینترنت اشیا و رایانش ابری، معماری های میکروسرویس بسیار محبوب و پر استفاده هستند. برنامه های زندگی هوشمند و مراقبت های پزشکی، دو موضوع Trend در حوزه اینترنت اشیا هستند که در سال های اخیر مقالات بسیار زیادی در این حوزه ها به چاپ رسیده اند و در اکثر مقالات، معماری های سیستم ها، مبتنی بر میکروسرویس ها در نظر گرفته شده اند.هنگام مطالعه مقالات، الگو های به کار رفته در معماری ها را نیز در قالب جدول، دسته بندی کردیم؛ با مشاهده این جدول و مطالعه مزایا و معایب هر الگو، می توان تا حدودی موارد کاربرد هر الگو را متوجه شد و طراحی معماری های میکروسرویس را تسهیل بخشید. همچنین دریافتیم که چه الگو هایی در معماری میکروسرویس، پرکاربردتر هستند؛ برای مثال، در سال های اخیر الگو های API Gateway و Multiple service per host الگو های رایج و پر استفاده ای بوده اند.«این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است»مراجع[1] Dirk Merkel. Docker: Lightweight linux containers for consistent development and deployment. Linux J., 2014(239), March 2014.[2] Martin Fowler and James Lewis. Microservices, 2014. http://martinfowler.com/articles/microservices.html.[3] Dhama, H. (1995). Quantitative models of cohesion and coupling in software. Journal of Systems and Software, 29(1), 65-74.[4] https://developer.ibm.com/technologies/microservices[5] https://en.wikipedia.org/wiki/Microservices[6] Dragoni, Nicola, et al. "Microservices: yesterday, today, and tomorrow." Present and ulterior software engineering (2017): 195-216.[7] Ahuja RPS, Nedbal M, inventors: ShieldX Networks Inc, assignee. Dynamic, load-based, auto-scaling network security microservices architecture. US Patent 9,716,617. July 25, 2017.[8] Zheng T, Zhang Y, Zheng X, Fu M, Liu X. BigVM: a multi-layer-microservice-based platform for deploying SaaS. Paper presented at: Fifth International Conference on Advanced Cloud and Big Data (CBD); 2017; Shanghai, China.[9] Guo, D., Wang, W., Zeng, G., & Wei, Z. (2016, March). Microservices architecture based cloudware deployment platform for service computing. In 2016 IEEE Symposium on Service-Oriented System Engineering (SOSE) (pp. 358-363). IEEE.[10] Ciuffoletti, A. (2015). Automated deployment of a microservice-based monitoring infrastructure. Procedia Computer Science, 68, 163-172.[11] Ramakrishnan, R., Sridharan, B., Douceur, J. R., Kasturi, P., Krishnamachari-Sampath, B., Krishnamoorthy, K., ... & Venkatesan, R. (2017,May). Azure data lake store: a hyperscale distributed file service for big data analytics. In Proceedings of the 2017 ACM International Conference on Management of Data (pp. 51-63).[12] Le, V. D., Neff, M. M., Stewart, R. V., Kelley, R., Fritzinger, E., Dascalu, S. M., & Harris, F. C. (2015, July). Microservice-based architecture for the NRDC. In 2015 IEEE 13th International Conference on Industrial Informatics (INDIN) (pp. 1659-1664). IEEE.[13] Butzin B, Golatowski F, Timmermann D. Microservices approach for the Internet of Things. Paper presented at: 2016 IEEE 21st International Conference on Emerging Technologies and Factory Automation (ETFA); 2016; Berlin, Germany.[14] Sun, L., Li, Y., & Memon, R. A. (2017). An open IoT framework based on microservices architecture. China Communications, 14(2), 154-162.[15] Richter, D., Konrad, M., Utecht, K., & Polze, A. (2017, July). Highly-available applications on unreliable infrastructure: Microservice architectures in practice. In 2017 IEEE International Conference on Software Quality, Reliability and Security Companion (QRS-C) (pp. 130-137). IEEE.[16] Li, J., Jin, J., Lyu, L., Yuan, D., Yang, Y., Gao, L., & Shen, C. (2021). A fast and scalable authentication scheme in IOT for smart living. Future Generation Computer Systems, 117, 125-137.[17] Caporuscio M, Weyns D, Andersson J, Axelsson C, Petersson G. Iot-enabled physical telerehabilitation platform. Paper presented at: 2017 IEEE International Conference on Software Architecture Workshops (ICSAW); 2017; Gothenburg, Sweden.[18] Calderón-Gómez, H., Mendoza-Pittí, L., Vargas-Lombardo, M., Gómez-Pulido, J. M., Rodríguez-Puyol, D., Sención, G., & Polo-Luque, M. L. (2021). Evaluating Service-Oriented and Microservice Architecture Patterns to Deploy eHealth Applications in Cloud Computing Environment. Applied Sciences, 11(10), 4350.[19] Baldominos, A., Ogul, H., Colomo-Palacios, R., Sanz-Moreno, J., & Gómez-Pulido, J. M. (2020). Infection prediction using physiological and social data in social environments. Information Processing & Management, 57(3), 102213.[20] Akbulut, A., & Perros, H. G. (2019). Performance analysis of microservice design patterns. IEEE Internet Computing, 23(6), 19-27.[21] Ianculescu, M., Alexandru, A., Neagu, G., & Pop, F. (2019, November). Microservice-based approach to enforce an IoHT oriented architecture. In 2019 E-Health and Bioengineering Conference (EHB) (pp. 1-4). IEEE.[22] Esposito, C., Castiglione, A., Tudorica, C. A., & Pop, F. (2017). Security and privacy for cloud-based data management in the health network service chain: a microservice approach. IEEE Communications Magazine, 55(9), 102-108.[23] Dhama, H. (1995). Quantitative models of cohesion and coupling in software. Journal of Systems and Software, 29(1), 65-74.[24] Jaramillo, D., Nguyen, D. V., & Smart, R. (2016, March). Leveraging microservices architecture by using Docker technology. In SoutheastCon 2016 (pp. 1-5). IEEE.[25] Lin, J., Lin, L. C., & Huang, S. (2016, May). Migrating web applications to clouds with microservice architectures. In 2016 International conference on applied system innovation (ICASI) (pp. 1-4). IEEE.[26] Guo, D., Wang, W., Zeng, G., & Wei, Z. (2016, March). Microservices architecture based cloudware deployment platform for service computing. In 2016 IEEE Symposium on Service-Oriented System Engineering (SOSE) (pp. 358-363). IEEE.[27] O’Connor, R., Elger, P., & Clarke, P. M. (2016, May). Exploring the impact of situational context—A case study of a software development process for a microservices architecture. In 2016 IEEE/ACM International Conference on Software and System Processes (ICSSP) (pp. 6-10). IEEE. امین باقری امین باقری Sat, 12 Feb 2022 20:25:54 +0330 https://virgool.io/@aminbagheri021/%D8%AA%D8%AD%D9%88%DB%8C%D9%84-%D9%85%D8%AF%D8%A7%D9%88%D9%85-ynrbzrnigtgz تحویل مداوم اصطلاحی است که در سال 2010 و پس از گفتگوهایی در مورد Continuous Integration به وجود آمد. در سال 2006، مارتین فاولر از روش ادغام مداوم کد توسعه‌دهنده در پایگاه‌های کد به روشی خودکار، کارآمد و آزمایش‌شده برای کاهش خطاها و تسریع توسعه نرم‌افزار حمایت کرد.کتابی با عنوان Continuous Delivery توسط Jez Humble و David Farley تکنیک‌ها را به کل چرخه عمر توسعه نرم‌افزار گسترش داد، به‌ویژه در مورد قرار دادن کد در محیط‌های تولید (production) بحث کرد. در این کتاب، Jez Humble و David Farley، تحویل مداوم را این گونه تعریف می‌کنند: «عملی برای اطمینان از اینکه نرم‌افزار همیشه آماده استقرار است». به عبارت دیگر، CD فرآیند خودکار گذراندن یک محصول (Artifact) از مراحل مختلف برای در دسترس قرار گرفتن تغییرات نرم افزار در اختیار مصرف کننده است. این تغییرات در یک محیط تولید آماده، برای انتشار در آینده قرار می گیرند.هدف از تحویل مداوم، تحویل یک artifact بسته بندی شده به محیط تولید است. CD، کل فرآیند تحویل، از جمله فرآیند استقرار را خودکار می کند. مسئولیت‌های CD می‌تواند شامل تهیه زیرساخت، مدیریت تغییرات، استقرار artifact ها، تأیید و نظارت بر آن تغییرات، و اطمینان از عدم وقوع این تغییرات در صورت وجود هرگونه مشکل باشد.تحویل مداوم در مقابل ادغام مداومیکپارچه سازی مداوم (CI) یک فرآیند خودکار برای یکپارچه سازی مداوم تغییرات توسعه نرم افزار است. فرآیندهای CI، ساخت (build)، آزمایش و اعتبارسنجی کد منبع را خودکار می کنند. با کار کردن با قابلیت‌های CI، تیم‌های توسعه‌دهنده، چرخه‌های انتشار کد خود را تسریع می‌کنند و این امر باعث می‌شود که با چرخه‌های طولانی توسعه ویژگی‌ها و چالش‌های ناشی از آن، مانند تداخل ادغام (merge conflicts) و کد شکسته (broken code)، کمتر مواجه شوند.بنابراین CI در مورد ادغام ویژگی های جدید و تغییرات کد در یک آرتیفکت است. در یک گردش کار توسعه معمولی، یک توسعه دهنده:کد نویسی می کند.کد را با استفاده از سیستم کنترل نسخه / ابزار مدیریت پیکربندی بررسی می کند.این پایگاه کد جدید، یک فرآیند ساخت را طی می کند.این سازه در یک artifact بسته بندی می شود.و سپس artifact در یک مخزن ذخیره می شود.هدف CI تولید یک artifact بسته بندی شده است که آماده استقرار بر روی سرور یا ماشین است. نمونه ای از یک مصنوع می تواند یک تصویر کانتینر (container image)، فایل WAR/JAR یا هر کد بسته بندی شده اجرایی دیگری باشد. بنابراین، فعالیت های CI یک الزام برای CD است.اCI/CD یک اصطلاح کوتاه شده برای یکپارچه سازی مداوم و تحویل مداوم است. CI/CD یک روش DevOps شامل ترکیبی از اصول، روش‌ها و قابلیت‌هایی است که اجازه می‌دهد تا تغییرات نرم‌افزاری از هر نوع، به صورت سریع، مکرر و ایمن به دست کاربران برسد. این روش به توسعه دهندگان نرم افزار اجازه می دهد تا تغییرات ویژگی یا خدمات خود را به طور مداوم ادغام کنند و تیم های فناوری اطلاعات و عملیات بتوانند استانداردها، امنیت و اطمینان کسب و کارها را در فرآیند انتشار خود ارائه دهند.مولفه های تحویل مداومفرآیند تحویل مداوم یک artifact، به زیرساخت، مدیریت تغییرات، استقرار، تصدیق (Verification) و استراتژی های بازگشت (Rollback)/ شکست نیاز دارد.به طور کلی برای یک artifact که آماده استقرار است، شش مولفه برای یک خط لوله تحویل مداوم وجود دارد:دسترسی به محیط های ابری، on-premises یا ترکیبیتامین زیرساختمدیریت تغییر و تاییدیه هابه کارگیری یک استراتژی برای استقراربررسی کاراییتعریف یک استراتژی شکست یا بازگشتیک خط لوله CD، این فعالیت ها را خودکار می کند.مزایای تحویل مداومانتشار های کم خطر: هدف اصلی از تحویل مداوم، این است که استقرار نرم افزار، بدون دردسر و در قالب رویداد های کم خطری که بتوان در هر زمان و بنا به درخواست، انجام شود، صورت بگیرد. با استفاده از الگو هایی مانند استقرار آبی-سبز، دستیابی به استقرار های بدون توقف (zero-downtime deployments) که برای کاربران غیر قابل تشخیص هستند، نسبتا ساده است.رسیدن سریعتر به بازار: این که در رویکرد سنتی چرخه حیات تحویل نرم افزار، فاز ادغام و تست، هفته ها یا حتی ماه ها طول بکشد، مسئله ای دور از ذهن نیست. زمانی که تیم ها برای خودکار سازی ساخت و توسعه، فراهم سازی محیط و فرآیند های تست رگرسیون با هم کار می کنند، توسعه دهندگان می توانند ادغام و تست رگرسیون را در کار روزانه خود گنجانده و یا این مراحل را به طور کامل حذف کنند. ما همچنین از حجم زیاد دوباره کاری که رویکرد مرحله‌ای را کند می کند اجتناب می‌کنیم.کیفیت بالاتر: وقتی توسعه‌دهندگان، ابزارهای خودکاری دارند که در عرض چند دقیقه رگرسیون‌ها را کشف می‌کنند، تیم‌ها آزاد می‌شوند تا تلاش خود را بر روی تحقیقات کاربر و فعالیت‌های تست سطح بالاتر مانند تست اکتشافی، تست قابلیت استفاده مجدد، تست عملکرد و امنیت متمرکز کنند. با ایجاد یک خط لوله استقرار، این فعالیت ها می توانند به طور مداوم در طول فرآیند تحویل انجام شوند و اطمینان حاصل شود که از ابتدا کیفیت در محصولات و خدمات تعبیه شده است.هزینه های پایین تر: هر محصول یا خدمات نرم افزاری موفقی در طول عمر خود به طور قابل توجهی تکامل می یابد. با سرمایه‌گذاری در ساخت، آزمایش، استقرار و اتوماسیون محیطی، ما با حذف بسیاری از هزینه‌های ثابت مرتبط با فرآیند انتشار، هزینه ایجاد و ارائه تغییرات تدریجی در نرم‌افزار را به‌طور قابل ملاحظه‌ای کاهش می‌دهیم.ساخت محصول مناسب: انتشارات مکرر، به تیم های توسعه اجازه می دهد تا بازخورد کاربر را سریعتر دریافت کنند و فقط روی ویژگی های مفید کار کنند. اگر متوجه شوند که یک ویژگی مفید نیست، تلاش بیشتری برای آن نمی کنند. این به آنها کمک می کند محصول مناسبی بسازند.تیم های شادتر: تحقیقات، حاکی از این است که که تحویل مداوم باعث کاهش فرسودگی تیم می شود. علاوه بر این، هنگامی که ما به دفعات بیشتری انتشار را انجام می دهیم، تیم های تحویل نرم افزار می توانند فعالانه تر با کاربران درگیر شوند، یاد بگیرند که کدام ایده ها کار می کنند و کدام نه و نتایج کاری را که انجام داده اند از نزدیک ببینند. با حذف فعالیت‌های دردناک کم‌ارزش مرتبط با تحویل نرم‌افزار، می‌توانیم روی چیزی که بیشتر به آن اهمیت می‌دهیم تمرکز کنیم و به طور مداوم کاربران خود را خوشحال نگه داریم.غلبه بر چالش ها در تحویل مداومهمانطور که پیش تر اشاره شد، تعدادی چالش در تحویل مداوم از جمله در تست، مدیریت اسکریپت ها و تضمین امنیت وجود دارد.تست مداومایجاد تعادل بین کیفیت و تحویل، آسان نیست. بسیاری از ویژگی‌های جدید یا تغییرات کد، می‌توانند در صورت کمبود زمان یا منابع، بدون آزمایش باقی بمانند. تحویل مداوم بستگی به قابلیت های آزمایش و تأیید دارد. تست‌های خودکار می‌توانند در اندازه‌گیری و درک کارایی مفید باشند؛ به‌ویژه زمانی که در محیط‌های تولید اجرا می‌شوند.اسکریپت هافایل های اسکریپت مجموعه ای از دستورات هستند. در حالی که اسکریپت ها برای خودکارسازی سریع مفید هستند، اغلب برای خطوط لوله تحویل مداوم، مقیاس پذیر و یا ساده نیستند. اسکریپت خط لوله شما می تواند منجر به مشکلات پیکربندی، دانشی که نمی تواند برای تیم های دیگر به اشتراک گذاشته شود، و خطوط لوله شکننده که در برابر تغییر مقاوم هستند منجر شود.امنیتامنیت وظیفه همه است ایجاد پیاده‌سازی خط لوله CI/CD که سطح امنیت را تضمین می‌کند، زمانی که راه‌حل CD از راه‌حل‌های مدیریت کلیدی خارج از جعبه پشتیبانی نمی‌کند، می‌تواند چالش‌برانگیز باشد. حاکمیت و انطباق، یک گام به سوی تضمین امنیت خدمات در خط لوله CI/CD است.ابزار های CDابزار Argo CDArgo CD یک ابزار تحویل مداوم برای Kubernetes است.این ابزار از الگوی GitOps برای استفاده از مخازن Git به عنوان منبعی برای تعریف وضعیت برنامه مورد نظر استفاده می کند و استقرار وضعیت های برنامه را در محیط های هدف مشخص شده، خودکار می کند.Argo CD به‌عنوان یک کنترل‌کننده kubernetes پیاده‌سازی می‌شود و به طور مداوم برنامه‌های در حال اجرا را نظارت می‌کند و وضعیت فعلی و زنده را با حالت هدف مورد نظر (همانطور که در مخزن Git مشخص شده است) مقایسه می‌کند و یک برنامه مستقر شده که حالت زنده آن از حالت هدف منحرف می شود OutOfSync در نظر گرفته می گیرد. Argo CD تفاوت ها را گزارش کرده و نمایش می دهد؛ همچنین امکاناتی را برای همگام سازی (Sync) خودکار یا دستی حالت زنده به حالت هدف، فراهم می کند. هر گونه تغییری که در وضعیت هدف مورد نظر در مخزن Git ایجاد شود، می تواند به طور خودکار اعمال شود و در محیط های هدف مشخص شده منعکس شود.ابزار JenkinsJenkins یک ابزار اتوماسیون متن باز است که به خودکار سازی بخش های مرتبط با ساخت (build)، تست و استقرار در توسعه نرم افزار و تسهیل فرآیند CI/CD کمک می کند. از جنکینز می توان به عنوان محبوب ترین و پراستفاده ترین ابزار CI نام برد. از این ابزار به این صورت می توان استفاده کرد که پس از هر تغییر در کد، فرآیند های ساخت، تست و استقراری را که در تنظیمات آن در نظرگرفته ایم را به صورت خودکار انجام دهد.شرکت های ایرانی ارائه دهنده خدمات CDشرکت داده کاوان تصمیم یارشرکت داده کاوان تصمیم یار (کوالاتک) به شماره ثبت: 576694 و شناسه ملی: 14009978163 در زمینه ارائه ، مشاوره و آموزش خدمات نرم افزاری به سازمان‌های دولتی و خصوصی فعالیت می‌نماید. شرکت داده کاوان تصمیم یار خدمات مختلف نرم افزاری ارائه می‌دهد که یکی از آنها “تست اتوماتیک نرم افزار و تضمین کیفیت” می‌باشد.این شرکت، با بهره‌گیری از متخصصان ارشد حوزه QA و انجام ده‌ها پروژه مختلف آماده کمک به سازمان‌های مختلف برای راه اندازی فرایند CI/CD می‌باشد.کوالاتک با راه اندازی فرایند CD برای نرم افزار و اپلیکیشن شما، مانع بروز مشکلات بارگذاری های دستی توسط تیم فنی می‌شود.با اتوماتیک کردن بارگذاری نسخه‌های جدید نرم افزار، منافع متعددی نظیر تسریع در تحویل، صرفه جویی زمانی ، صرفه جویی مالی، کاهش چالش های نیروهای فنی و … بدست می آید که برای هر سازمانی بسیار مهم می باشد.برای دریافت اطلاعات بیشتر، به لینک زیر مراجعه نمایید:https://qualatech.ir/ci-cdابر آروانابر آروان شرکتی های‌تک در حوزه‌ی فناوری ابری است که کار خود را از سال ۱۳۹۴ آغاز کرده است و با ده‌ها محصول و قابلیت ابری مختلف مانند شبکه توزیع محتوا (CDN)، سرور ابری، پلتفرم ویدیویی، کانتینر ابری و آبجکت استوریج، زیرساخت کسب‌وکارهای آنلاین، سازمان‌ها و استارت‌آپ‌ها را تامین می‌کند.ابر آروان با در اختیار داشتن ۴۰ پاپ‌سایت در سراسر ایران و جهان، پاسخ‌گوی نیازهای زیرساختی بیش از ۶۰ هزار مشتری داخلی و خارجی است و تلاش می‌کند با قیمت‌گذاری اقتصادی و ارایه‌ی بسته‌های رایگان در هر محصول، از کسب‌وکارهای نوپا و در حال رشد نیز حمایت کند.سرویس‌دهی به بسیاری از پربازدیدترین وب‌سایت‌های ایرانی، پخش زنده‌ی مهم‌ترین رویدادهای ملی، ارایه‌ی خدمات امنیتی به سامانه‌های حساس دولتی و هم‌چنین جلوگیری از حملات سایبری به بسیاری از بانک‌ها و سامانه‌های کشور از جمله خدماتی است که این شرکت در اختیار کاربران قرار می‌دهد.در ابر آروان، امکان راه‌اندازی پایپ لاین ‏CI/CD‏ بر روی سرویس پلتفرم ابری آروان (در سطح PAAS) وجود دارد.برای دریافت اطلاعات بیشتر، به لینک زیر مراجعه نمایید:https://www.arvancloud.com/docs/%D9%BE%D8%A7%DB%8C%D9%BE%D9%84%D8%A7%DB%8C%D9%86-cicd-%D9%81%D8%B1%D9%88%D8%B4%DA%AF%D8%A7%D9%87-%D8%A2%D9%86%D9%84%D8%A7%DB%8C%D9%86-paas-%D8%A7%D8%A8%D8%B1%D8%A2%D8%B1%D9%88%D8%A7%D9%86/«این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است»مراجعhttps://harness.io/blog/what-is-continuous-deliveryhttps://continuousdelivery.comhttps://argo-cd.readthedocs.io/en/stablehttps://www.jenkins.iohttps://qualatech.ir/ci-cdhttps://www.arvancloud.com/docs/%D9%BE%D8%A7%DB%8C%D9%BE%D9%84%D8%A7%DB%8C%D9%86-cicd-%D9%81%D8%B1%D9%88%D8%B4%DA%AF%D8%A7%D9%87-%D8%A2%D9%86%D9%84%D8%A7%DB%8C%D9%86-paas-%D8%A7%D8%A8%D8%B1%D8%A2%D8%B1%D9%88%D8%A7%D9%86/ امین باقری امین باقری Fri, 24 Dec 2021 23:49:10 +0330 https://virgool.io/@aminbagheri021/%D8%AA%D8%AD%D9%84%DB%8C%D9%84-%D8%A7%DB%8C%D8%B3%D8%AA%D8%A7%DB%8C-%DA%A9%D8%AF-ngtui9u2n3ik تحلیل کد استاتیک، که به عنوان تست جعبه سفید نیز شناخته می شود، یک روش تست برنامه است که کد را در یک محیط غیر زمان اجرا (non-runtime environment) بررسی می کند. تجزیه و تحلیل کد استاتیک می تواند هم در طول چرخه حیات توسعه و هم پس از راه اندازی برنامه در فروشگاه های برنامه، انجام شود.این تجزیه و تحلیل (بسته به ابزار)، آسیب پذیری های متداول خارج از محیط اجرای برنامه را در یک حالت ایستا با استفاده از روش های تست مختلف، مانند جریان داده (Data Flow)، نمودار جریان کنترل (Control Flow Graph)، Taint و تجزیه و تحلیل واژگانی (Lexical Analysis) برجسته می کند.با توجه به قلمرو وسیع ناشناخته امنیت سایبری و افزایش سیاست‌های سختگیرانه دولت ها، کسب‌وکارها موظفند پارامترهای امنیتی خود را همیشه بررسی کنند؛ این دقیقاً به به روز رسانی تحلیل ایستای کد مبتنی بر جدید ترین آسیب پذیری ها برای کمک به توسعه‌دهنده، تحلیلگر امنیتی و کسب‌وکارها با جدیدترین آسیب‌پذیری‌ها، اشاره می کند.تحلیل گر کد استاتیک، به دنبال الگوهایی است که برای آنها به عنوان قوانین تعریف شده است و می تواند باعث آسیب پذیری های امنیتی یا سایر مشکلات مرتبط با کیفیت کد شود. با توجه به آنچه گفته شد، در ادامه به پنج دلیل برای نیاز به تست کد ایستا، پرداخته می شود.چرا تحلیل ایستای کد، مهم است؟یکی از دلایل اصلی اهمیت تحلیل ایستا این است که به شما اجازه تحلیل تمام کد، بدون نیاز به اجرای آن را می دهد؛ به همین دلیل است که تحلیل ایستا می تواند آسیب پذیری ها را در دورترین و بدون نظارت ترین بخش های کد، شناسایی کند.یکی دیگر از مزایای انجام تجزیه و تحلیل کد استاتیک، این است که می توان آن را با توجه به نیازهای خاص پروژه، تغییر داد و همچنین امکان همکاری آسان در کل تیم توسعه را فراهم می کند.همچنین به شما این امکان را می دهد که باگ ها را در مراحل اولیه چرخه توسعه پیدا کنید و در نتیجه هزینه مربوط به تعمیر را به شدت کاهش می دهد.۵ دلیل برا اینکه چرا کسب و کارها به تحلیل ایستای کد، احتیاج دارند:1. به طور مداوم تغییر می کند.وقتی اکوسیستم امنیت سایبری، چیزی جز تغییر مداوم نیست، به کسب‌وکارها کمک می‌کند تا یک استراتژی امنیتی چابک برای مقابله با این تغییر اتخاذ کنند. اکثر ابزارهای تجزیه و تحلیل کد ایستا به طور مداوم با تهدیدهای جدید به روز می شوند و به بررسی سالم بودن تست پیکربندی اولیه کمک می کنند.بسیاری از تحلیلگرهای کد استاتیک نیز موارد تست انطباق صنعت را در سیستم امنیتی خود گنجانده اند تا اطمینان حاصل کنند که رایج ترین و خطرناک ترین تهدیدها در نظر گرفته شده است.2. به تحلیلگران امنیتی کمک می کند.یک سناریوی ایده آل برای زمانی که تجزیه و تحلیل کد ایستا انجام می شود این است که درجه بالایی از اطمینان وجود داشته باشد که آنچه پیدا می شود در واقع یک نقص است (همچنین به عنوان مثبت کاذب (False Positives) نیز شناخته می شود). با این حال، این مورد در هر موقعیتی و حتی در مورد بسیاری از ابزارهای تحلیلگر استاتیک موجود نیست.با این حال، کاری که این ابزار انجام می دهد این است که به یک تحلیلگر امنیتی کمک می کند تا تهدیدات شناسایی شده را محدود کند، که در غیر این صورت شناسایی آنها چندین ساعت یا روز طول می کشد.سپس تحلیلگران می توانند به طور عمیق تر به تهدیدها نگاه کنند تا اطمینان حاصل کنند که آنها مثبت کاذب نیستند و اقدامات لازم را در قبال آن انجام دهند.3. سرعت توسعه و عرضه محصول به بازار را افزایش می دهد.در دنیای رقابت دائمی، ضروری است که پارامترهای امنیتی خود را به طور مداوم فعال و در حالت اجرا قرار دهید. همانطور که ممکن است این ایده آل به نظر برسد، اما امکان پذیر نیست مگر اینکه سرمایه گذاری و زیرساخت های لازم را در اختیار داشته باشید. تجزیه و تحلیل کد استاتیک، روشی ارزان برای اطمینان از امنیت اولیه برنامه شما است.گارتنر اعلام کرد که 75 درصد از برنامه ها در تست امنیتی اولیه شکست می خورند و این بسیار نگران کننده بود. انجام یک تست امنیتی اولیه با یک تحلیلگر امنیتی نه تنها هزینه زیادی دارد، بلکه فرآیندی زمان بر است.برخی از ابزارهای تحلیل کد استاتیک، سرعت این فرآیند را نزدیک به 75% افزایش می دهند. بدین ترتیب می‌توانید برنامه های کاربردی را با سرعت بالاتری توسعه داده و در نتیجه، برنامه های کاربردی بیشتری را روانه بازار کنید.4. باگ ها را در مراحل اولیه توسعه پیدا می کند.وقتی رقابت برای موفقیت، تماماً مربوط به هزینه در مقابل درآمد است، شناسایی اشکالات در مراحل اولیه توسعه می‌تواند میلیون‌ها دلار پیش‌بینی‌نشده برای کسب‌وکارها ذخیره کند.بسیاری از ابزارهای تحلیلگر استاتیک از فناوری یکپارچه سازی مداوم (Continuous Integration) استفاده کرده اند؛ فرآیندی که هر بار که یکی از اعضای تیم تغییراتی را در کنترل نسخه انجام می دهد، build و آزمایش کد را به صورت خودکار انجام می دهد.5. قوانینی را برای کمک به توسعه دهندگان، تعریف می کند.توسعه دهندگان معمولاً بدون دانش امنیتی در حین کدنویسی، روی پروژه های خاصی کار می کنند. تحلیلگرهای کد استاتیک به شما کمک می کنند قوانین خاص پروژه را تعریف کنید تا اطمینان حاصل کنید که همه توسعه دهندگان بدون هیچ گونه مداخله دستی یا ردیابی، از آنها پیروی می کنند.با استفاده از یک تحلیلگر کد استاتیک، از نیاز به یک متخصص امنیتی نیز صرفه جویی می کنید تا مطمئن شوید که همه کدها به درستی نوشته شده اند. به این ترتیب توسعه دهندگان می توانند از مسائل امنیتی آگاه باشند و خودشان این کار را انجام دهند.برخی از ابزارها در حال حرکت به سمت محیط های توسعه یکپارچه (IDE) هستند؛ برای حل مشکلاتی که می‌توانند در طول مرحله توسعه نرم‌افزار شناسایی شوند، می‌توان این ابزار را معرفی کرد، زیرا به توسعه‌دهنده در مورد مشکلاتی که ممکن است در طول توسعه کد به آنها برخورد کند، بازخورد فوری می دهد.این بازخورد فوری، در مقایسه با یافتن آسیب‌پذیری‌ها در مراحل بعدی چرخه توسعه، بسیار مفید است. همچنین به کسب‌وکار کمک می‌کند تا خود را از آسیب‌پذیری‌هایی که به طور بالقوه می‌توانند میلیون‌ها دلار هزینه برای آن‌ها داشته باشند، نجات دهد.ابزار های تحلیل ایستای کدابزار SonarQubeابزار متن‌باز و رایگان SonarQube که به اختصار به آن Sonar می گویند ابزاری است برای پایش مداوم و با کیفیت برنامه‌هایی که در حال توسعه دارید. Sonar مجموعه‌ای از ابزارهای تحلیل کد مانند PMD ، CPD ، CheckStyle و FindBugs را در در دل خود یکپارچه ساخته و ابزارهای دیگری مانند Squid را نیز به آنها افزوده است. علاوه بر این، Sonar دارای یک سرور، واسط وب، دیتابیس و قابلیت اتصال به ابزارهای دیگر (مانند Jenkins) است که مجموعاً آن را نسبت به سایر ابزارهای این حوزه متمایز میکند. این نرم‌افزار با بررسی خودکار کدها، کشف باگ‌ها و خطاهای برنامه‌نویسی و مشکلات آسیب‌پذیری کدها در بیش از ۲۰ زبان برنامه‌نویسی مانند Java، C#، JavaScript، C/C++ و PHP، ابزاری قدرتمند در دستان شماست. این برنامه همچنین قادر است آمار را رهگیری و نمودارهایی تهیه کند تا توسعه‌دهندگان بتوانند به‌سرعت مشکلات کدشان را بیابند.ابزار CodacyCodacy یک ابزار آنالیز خودکار برای بررسی کیفیت سورس‌کد است و این امکان را به دولوپرها می‌دهد تا نرم‌افزارهای خود را بهتر و سریع‌تر توسعه دهند. همچنین دولوپرها قادر خواهند بود تا با بهره‌گیری از این ابزار، استانداردهای کیفیت را بر سورس‌کد خود اعمال کنند و در زمان بازبینی کد صرفه‌جویی نمایند. علاوه بر این موارد، ابزار Codacy یکسری به اصطلاح Best Practice را نیز برای تأمین امنیت سورس‌کد ارائه کرده است. لازم به ذکر است که این ابزار به منظور نظارت بر کیفیت کد و توسط تمام دولوپرها از تیم‌های کوچک برنامه‌نویسی تا شرکت‌های بزرگ هم می‌تواند مورد استفاده قرار می‌گیرد.صرفه‌جویی در زمان بازبینی کدبا استفاده از این ابزار، دولوپرها می‌توانند آنالیزی استاتیک از کدهای خود، بررسی پیچیدگی‌های آن، مشخص کردن کدهای تکراری موجود در سورس‌کد و همچنین تغییرات اعمال شده در هر کامیت را داشته باشند. همچنین دولوپرها می‌توانند با ادغام این ابزار با ریپازیتوری گیت‌هاب خود، کیفیت کد به ازای تغییرات در Pull Request را آنالیز کنند.ادغام با وُرک‌فلو دولوپرCodacy بسیار انعطاف‌پذیر بوده و سازگار با فرایند بازبینی کد دولوپر است و نتایج بازبینی سورس‌کد را به صورت کامنت‌هایی در هر Pull Request در سورس‌کد می‌آورد یا به عنوان نوتیفیکیشن در کانال‌هایی همچون Slack یا Hipchat ارسال می‌کند.همچنین Codacy به خوبی می‌تواند با سایر ابزارهای CI در پروژه شما کار کند و به عنوان یک مکمل ایده‌آل برای مرحله Unit Test نرم‌افزار عمل کند.بررسی پیشرفت کیفیت کددولوپرها می‌توانند کیفیت سورس‌کد پروژه‌ٔ خود را بررسی کرده، پیشرفت کیفیت آن را در طول زمان دنبال کنند و به راحتی بدهی‌های فنی سورس‌کد را رفع نمایند. این ابزار در راستای بررسی کیفیت سورس‌کد، به سه سؤال پاسخ می‌دهد که عبارتند از:- کیفیت سورس‌کد پروژه شما در چه سطحی است؟- پیشرفت کیفیت آن در طول زمان چگونه بوده است؟- نقاط مهم یا نقاطی از سورس‌کد که زمان بیشتری را برای اجرا احتیاج دارند، کدام هستند؟شرکت های ایرانی ارائه دهنده خدمات تحلیل ایستای کدشرکت داده کاوان تصمیم یارشرکت داده کاوان تصمیم یار (کوالاتک) در زمینه ارائه، مشاوره و آموزش خدمات نرم افزاری به سازمان‌های دولتی و خصوصی فعالیت می‌نماید. این مجموعه، ارائه دهنده خدمات تخصصی تست نرم افزار و تضمین کیفیت می باشد که از جمله خدماتی که ارائه می دهند می توان به راه اندازی آنالیز سورس کد، تست اتوماتیک عملکردی، تست اتوماتیک کارایی و تست اتوماتیک امنیت اشاره کرد. مجموعه کوالاتک با استفاده از تکنولوژی‌های روز و به کارگیری استاندارد‌های بالا در کیفیت کد زبان‌های مختلف (Java, Html, JS, Php) ، می‌تواند CI و ابزارهای آنالیز ایستا را به نحوی کانفیگ نماید تا پس از هر تغییر در منبع کد اشکالات مربوط به Code Style، توسط ابزار‌های CI گزارش شود یا در صورتی که اشکال جدی در منبع کد مشاهده شود فرآیند CI به خطا ختم شود. یکی از نکات حائز اهمیت در این سرویس، آن است که با استفاده مناسب از آنالیز استاتیک کد در فرآیند CI به همراه جلسات دوره کد(Code Review) نه تنها سبب می‌شود که فرآیند توسعه تسریع گردد بلکه می‌تواند تاثیر به سزایی در رشد فنی تیم توسعه‌دهنده داشته باشد؛ چرا که به اعضای تیم فنی، خصوصا کارآموز‌های تیم روش صحیح برنامه‌نویسی (یا کد تمیز) را به طور ضمنی آموزش می‌دهد.برای دریافت اطلاعات بیشتر درمورد سرویس آنالیز سورس کد، به لینک زیر مراجعه نمایید:https://qualatech.ir/source-code-analysis/شرکت مهندس پیشگانشرکت مهندس پيشگان آزمون افزار ياس، زمینه اصلی فعالیتهای خود را بر روی تست و تضمين کيفيت نرم افزار متمرکز نموده است. همچنین این مجموعه، راهكارهایی را جهت حل مسائل و مشكلات غیركاركردی سیستم های نرم افزاری همچون كارایی، امنیت و قابلیت نگهداشت ارائه می نماید.این شرکت، ابزارهایی برای تحلیل ایستای کد از جمله JTest ،dotTest و SonarQube را ارائه می‌کند.برای دریافت اطلاعات بیشتر درمورد خدمات تحلیل ایستا، به لینک زیر مراجعه نمایید:https://www.mohandespishegan.com/tools/code-analysis/jtestما می‌دانیم که سرمایه‌گذاری روی چیزی که ممکن است هرگز به نفع شما نباشد دشوار است، اما آنهایی که آسیب‌پذیرترین هستند کسانی هستند که فکر می‌کنند هرگز هک نخواهند شد. برای آن دسته از مشاغلی که به دنبال اقداماتی برای افزایش امنیت هستند، ترکیب یک راه حل خوب برای تجزیه و تحلیل کد استاتیک ممکن است بهترین راه برای شروع باشد.«این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است»مراجعhttps://www.sonarqube.org/https://www.codacy.com/https://www.appknox.com/blog/static-code-analysishttps://qualatech.ir/source-code-analysis/https://www.mohandespishegan.com/tools/code-analysis/jtest امین باقری امین باقری Fri, 24 Dec 2021 23:45:20 +0330 https://virgool.io/@aminbagheri021/%D8%A2%D8%B4%D9%86%D8%A7%DB%8C%DB%8C-%D8%A8%D8%A7-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-%D9%87%D8%A7%DB%8C-%D9%85%D8%A7%D9%86%DB%8C%D8%AA%D9%88%D8%B1%DB%8C%D9%86%DA%AF-yxq84s7azhe7 نرم افزار مانیتورینگ (Monitoring Software) به چه معناست؟نرم افزار مانیتورینگ عملیات و فعالیت های کاربران، برنامه های کاربردی و خدمات شبکه را در رایانه یا سیستم های سازمانی مشاهده و ردیابی می کند. این نوع نرم افزار راهی برای نظارت بر فرآیندهای کلی که بر روی یک سیستم محاسباتی انجام می شود، فراهم می کند و خدمات گزارش دهی را به مدیر سیستم یا شبکه ارائه می دهد.نرم افزار مانیتورینگ با نام نرم افزار نظارت کامپیوتری (Computer Surveillance Software) نیز شناخته می شود.نرم افزار مانیتورینگ در درجه اول نوعی نرم افزار امنیتی و نظارتی است که بر روی یک سیستم فردی یا شبکه شرکتی نصب می شود و می تواند یک برنامه مستقل باشد یا به عنوان بخشی از نرم افزار یا سخت افزار فایروال، نرم افزار آنتی ویروس، یا مجموعه نرم افزار امنیت اطلاعات عمل کند. به طور کلی، نرم افزار مانیتورینگ، تمام ترافیک ورودی و خروجی شبکه، فرآیندها و تعاملات کاربر و فعالیت های برنامه کاربردی را ثبت (Log) و ضبط می کند. این سیستم ها، شامل قوانین، رویدادها و ترجیحات خاصی هستند که وضعیت ها و فعالیت های عادی و غیرعادی سیستم را توصیف می کنند. همچنین در صورت شناسایی هرگونه تخلف یا نقضی که منجر به رفتار غیرعادی سیستم، فعالیت کاربر یا جریان شبکه شود، به مدیر سیستم هشدار می دهد. علاوه بر این، چنین نرم افزاری برای جاسوسی از کارمندان یا فعالیت های کاربران در یک شبکه شرکتی نیز استفاده می شود.کنترل والدین (Parental Control)، نوعی نرم‌افزار نظارتی است که فعالیت‌های خاص کاربر را مسدود می‌کند و در صورت مشاهده هرگونه تخلف یا نقض تعهد، اطلاعیه‌ای را به مدیران ارسال می‌کند.هدف استفاده از نرم افزار مانیتورینگ چیست؟نرم افزار مانیتورینگ، عملکرد بالا را برای نرم افزار شما تضمین می کند. نظارت مداوم بر سیستم، به شما امکان مدیریت عملکرد و در دسترس بودن برنامه های نرم افزاری را می دهد که این منجر به زمان پاسخگویی سریع، بهبود فرآیندهای محاسباتی و رضایت مشتریان می شود. تجربه کاربر نهایی، یکی از اهداف اصلی هنگام برخورد با تعاملات واقعی کاربر و تراکنش های تجاری است.قابلیت های سیستم مانیتورینگنظارت، یک فعالیت فوق العاده گسترده و پیچیده است. این یک مفهوم بسته نیست، اما همانطور که بالاتر به آن اشاره کردیم سیستم مانیتورینگ، به نیازهای هر سیستم بستگی دارد. با این حال ، سیستم های نظارتی اغلب دارای تعدادی ویژگی مشترک هستند، از جمله موارد زیر:تجزیه و تحلیل در زمان واقعی. یک سیستم مانیتورینگ خوب یک نظارت مستمر را ارائه می دهد که هیچ تأخیری در آن صورت نمی گیرد یا این تأخیرها به صورت حداقل ممکن است.سیستم هشدار. سیستم مانیتورینگ قادر است در هنگام خطر، اطلاع رسانی های مورد نظر ما را انجام دهد. برای مثال در هنگام وقوع حادثه، این سیستم قادر است هشدار های خطر را طبق پروتکل های تعریفی از سوی ما به صدا در بیاورد.ارسال نوتیفیکشن.این سیستم قادر است برای اتفاق هایی که در محیط مورد پایش صورت می گیرد اعلان هایی به صورت پیامک، ایمیل و … برای اپراتور ارسال نماید.تهیه گزارش. به منظور ارائه داده ها به مسئولین مربوطه یا بخشهای مختلف شرکت، سیستم مانیتورینگ توانایی جمع آوری داده ها و ارائه گزارش را دارد.انواع مانیتورینگانواع مختلفی از مانیتورینگ بسته به نوع سیستم و کسب و کار می تواند استفاده شود.پایش سیستم: پایش سیستم، عملکرد اجزای زیرساخت شبکه را ارزیابی می کند. هر سرور به صورت جداگانه مانیتور می شود و اطلاعات جمع آوری شده از سرور‌های زیرساخت، تجزیه و تحلیل می شوند تا تأثیرات آن ها بر عملکرد شبکه ارزیابی شود.نظارت بر وابستگی:‌ برنامه‌هایی که بر روی زیرساخت های توزیع شده اجرا می‌شوند می‌توانند از انواع سرویس‌ها یا پایگاه‌های داده توزیع‌شده در شبکه، استفاده کنند. مصرف منابع در گره، می‌تواند نحوه واکنش اجزای سرور به عملکرد برنامه را مشخص کرده و ترافیک داده ورودی آن را تعیین کند. این اطلاعات به شناسایی وابستگی های معماری اساسی بین برنامه‌ها، سخت‌افزار و سرویس‌ها کمک می‌کند.پایش عملکرد وب: این نوع از پایش، بخش‌های سرویس مبتنی بر وب کسب و کار یا سازمان را ارزیابی می کند و چگونگی پاسخ سرویس به درخواست کاربر در سمت مشتری شبکه را ارزیابی می کند. اندازه گیری‌ها شامل سرعت بارگذاری صفحات، خطاهای انتقال داده، خطاهای بارگذاری و موارد دیگر می باشد.نظارت بر امنیت سیستم:‌ حملات امنیتی بر جریان ترافیک داده و رفتار شبکه تأثیر می‌گذارد. فعالیت های غیرمعمول را می توان بر اساس سیاست های تعریف شده دسترسی و مجوز به اطلاعات، ردیابی کرد. با استفاده از راه‌حل‌های پیشرفته مبتنی بر هوش مصنوعی، می توان داده‌های گزارش شده از مانیتورینگ را قبل از اینکه تهدیدات بالقوه بر تجارت تأثیر بگذارد، تجزیه و تحلیل کرد.ابزار های مانیتورینگابزار PrometheusPrometheus یک جعبه ابزار مانیتورینگ و هشدار سیستم متن باز است که در ابتدا در SoundCloud ساخته شد. از زمان شروع آن در سال 2012، بسیاری از شرکت ها و سازمان ها Prometheus را پذیرفته اند و این پروژه دارای یک جامعه توسعه دهندگان و کاربران بسیار فعال است. اکنون یک پروژه متن باز مستقل است و مستقل از هر شرکتی نگهداری می شود. برای تاکید بر این موضوع و برای روشن شدن ساختار مدیریتی پروژه، پرومتئوس در سال 2016 به عنوان دومین پروژه میزبان پس از Kubernetes به بنیاد محاسبات بومی ابری پیوست.ویژگی های اصلی پرومتئوس عبارتند از:یک مدل داده چند بعدی با داده‌های سری زمانی که با نام متریک و جفت‌های کلید/مقدار شناسایی شده‌اند.PromQL، یک زبان پرس و جوی انعطاف پذیر برای استفاده از مدل داده چند بعدیعدم وابستگی به ذخیره سازی توزیع شده؛ گره های تک سرور مستقل هستند.جمع آوری سری های زمانی از طریق یک مدل کششی روی HTTP اتفاق می افتد.حالت های مختلف نمودار و داشبورد را پشتیبانی می کند.نمودار زیر، معماری پرومتئوس و برخی از اجزای اکوسیستم آن را نشان می دهد.ابزار Zabbixبا استفاده از نرم افزار Zabbix می توانید سروری را به عنوان مانیتورنگ استفاده نمایید. زمانی که نرم افزار در سروری نصب می شود، حال می توانید سرورهای دیگر را به استفاده از Zabbix agent به سرور Zabbix متصل نمایید. با اتصال سرور agent به سرور Zabbix تمامی اطلاعات سرور agent مانند: میزان استفاده از رم، پردازشگر، سرعت آپلود و دانلودو بسیاری از فعالیت های سرور نشان داده می شود و شما به راحتی از راه دور قادر به کنترل سرورها می باشید. عملکرد سرور Zabbix به سه بخش تقسیم می شود: 1-  عملکرد سرور Zabbix ، عملکرد Frontend و عملکرد دیتا بیس. تمامی اطلاعات Zabbix در پایگاه داده سرور ذخیره می گردد. در نتیجه عملکرد آن برای سرور بسیار حیاتی می باشد. تمامی لاگ ها و اطلاعاتی که از سرورهای دیگر دریافت می کند را در خود ذخیره نگه دارد. عملکرد Frontend نیز برای این مهم است که زمانی که دیتا را دریافت می کند در یک UI قابل فهم و زیبا به کاربران نشان دهد. البته که پس از دریافت اطلاعات در سرور Zabbix حدودا 2 دقیقه زمان می برد تا جدول های آن آپدیت شود.Zabbix قابلیت این را دارد که با استفاده از ارسال ایمیل و یا SMS به کاربران، وضعیت سرور را اطلاع رسانی کند. زمانی که سروری از دسترس خارج می شود، گاها کاربران از این مورد بی اطلاع هستند. برای این که سرپرستان فنی بتوانند در زمان کوتاهی خود را به سرور برسانند و آن را از Down بودن نجات دهند، می توانند از سرویس های ایمیل و پیامک Zabbix استفاده کنند.شرکت های ایرانی ارائه دهنده خدمات مانیتورینگرایان پشتیبانشرکت رایان پشتیبان با تیم کار آزموده و تلاش برای گسترش تکنولوژی IT و به همچنین به منظور ارتقای سطح کیفی و کمی خدمات خود  سعی می نماید با بهره گیری ازکارشناسان مجرب و کار آزموده و با تکیه برسال ها تجربه در زمینه خدمات پشتیبانی شبکه و کامپیوتر، فعالیت خود را درعرصه فناوری اطلاعات همواره دنبال نماید. فعالیت آن ها در زمینه سخت افزار، نرم افزار و شبکه می باشد و در همین راستا با شرکت ها و نهاد ها و سازمانهای بسیاری در طول این سالها همکاری داشته و با ارائه خدمات مشاوره و پیاده سازی پروژه های شبکه و دیتا سنتر، اتوماسیون و سرویس و نگهداری تجربه بسیار بزرگی را کسب نموده است.عمده فعالیت این شرکت در زمینه پشتیبانی شبکه و پشتیبانی کامپیوتر میباشد. که بیش از 14 سال در این زمینه سابقه کاری دارد و در این مدت با بسیاری از شرکت ها و موسسات تجاری ، بازرگانی ، تولیدی ، کارخانجات و … قرارداد همکاری داشته و تجربه کسب نموده است. همچنین رایان پشتیبان در زمینه ارائه خدمات شبکه و نصب و راه اندازی شبکه نیز فعالیت دارد.معیارهای خدمات مانیتورینگ شبکه در شرکت رایان پشتیبان چگونه است؟انتخاب معیارهای مانیتورینگ شبکه درست به اندازه اجرای مانیتورینگ شبکه اهمیت دارد. خوشبختانه برای پایش شبکه، بسته به نیازتان، می‌توانید معیارهای مختلفی تعیین کنید. مهم‌ترین معیارهایی که برای خدمات مانیتورینگ شبکه مورد استفاده قرار می‌گیرند، عبارتنداز:۱- پهنای باند شبکهاگر می‌خواهید بدانید شبکه شرکت شما تا چه اندازه درست و بدون مشکل کار می‌کند، باید پهنای باندی که توسط مجموعه مورد استفاده قرار می‌گیرد را بررسی کنید. برخی مواقع ممکن است یک دستگاه حجم زیادی از پهنای باند را به خود اختصاص داده باشد و مانع از عملکرد درست سایر اجزای مجموعه شود. شرکت رایان پشتیبان با دقت و نظارت تمام این موارد را برایتان انجام خواهد داد.۲- عملکرد برنامه‌های شبکهبرای اجرا و راه اندازی شبکه، نیاز به استفاده از برنامه‌های مختلف در مجموعه‌های متفاوت می‌باشد. عملکرد هر یک از این برنامه‌ها در عملکرد نهایی سیستم تأثیر به سزایی دارد. به همین خاطر، بسته به تعداد و اهمیت هریک از برنامه‌های موجود در شبکه، بهتر است سرعت پاسخ برنامه‌ها و سرویس‌های مبتنی بر ابر را همواره سنجید.۳- عملکرد سرور شبکههرگز نباید از سرورهای ایمیل، وب وDNS غافل شد و همواره باید آن‌ها را جزو معیارهای اصلی کار قرار داده شوند و نحوه عملکرد هریک از آن‌ها را در شرکت مورد ارزیابی قرار داد۴- پیکربندی شبکهدر ساختار هر شبکه‌ای تعدادی تلفن‌ همراه، سیستم دسکتاپ و سرور وجود دارد که نظارت بر هریک از آن‌ها ضروری است. خوشبختانه برخی از ابزارهای مانیتورینگ شبکه به صورت خودکار هر دستگاهی که وارد شبکه شده و یا از آن خارج شود را شناسایی می‌کند. برخی از این ابزارها به اندازه‌ای پیشرفته هستند که اطلاعات دقیقی شامل نوع دستگاه، موقعیت فیزیکی و IP آدرس را نیز در اختیار شما قرار می‌دهند.آیا خدمات مانیتورینگ شبکه در شرکت رایان پشتیبان برای هر سیستمی قابل اجرا است؟شرکت رایان پشتیبان، امکانی فراهم کرده تا مانیتورینگ شبکه برای تمامی شبکه‌ها، از هر نوعی و در هر مقیاسی قابل اجرا باشد. بنابراین می‌توان گفت برای هر شبکه با هر میزان پیچیدگی، یک سیستم نظارتی وجود دارد. برخی از شبکه‌های تحت پوشش رایان پشتیبان عبارتند از: شبکه‌ی سیمی یا وایرلس، شبکه شرکتی، VPN و .WANدرحال حاضر برخی از پروتکل‌ها اخیراً به شبکه‌ها اضافه شده‌اند و موجب افزایش پیچیدگی این شبکه‌ها شده‌اند. ازجمله این پروتکل‌ها میتوان VoIP ، VOD، IPTV را نام برد. اما هیچ جای نگرانی نیست چراکه با توجه به پیشرفتی که در حوزه‌ی فناوری ایجاد شده است، نظارت بر هیچ یک از این سیستم‌ها غیر ممکن نیست.چینودشرکت مشاورین فناوری اطلاعات چینود با ارائه دانش و تخصص خود با هدف نظام مند کردن کسب و کار ها , در راستای ارائه ی خدمات شبکه گام برداشته است.بهره مندی از خدمات شبکه یکی از نیاز های اساسی کسب و کارهاست که با اشتراکی کردن منابع و جلوگیری از افزونگی اطلاعات و دیتاها کمک شایانی به کاهش هزینه ها می کند. خدمات شبکه چینود شامل نصب و راه اندازی شبکه , نصب و راه اندازی ویپ (VOIP) , خدمات مجازی سازی و مجازی سازی سرور , خدمات بکآپ , مانیتورینگ شبکه , خدمات میکروتیک , کنترل اینترنت و فایروال , پشتیبانی شبکه , فراهم آوردن امنیت شبکه و مشاوره رایگان در زمینه شبکه های کامپیوتری می شود.یکی از خدمات شبکه های کامپیوتری این شرکت، مانیتورینگ شبکه است. با استفاده از این سرویس می توانید بخش های مختلف شبکه خود را در بازه های زمانی مختلف، نظارت و بررسی کرده که علاوه بر بالا بردن کارایی کارمندان و صرفه جویی در هزینه های مجموعه تان، می تواند شبکه داخلی شما را برای پیدا کردن مشکلات اسکن و پایش کند.«این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است»مراجعhttps://www.techopedia.com/definition/4313/monitoring-softwarehttps://www.dynatrace.com/monitoring/resources/monitoring-softwarehttps://sepehranformatic.com/product/monitoring-sepehrhttps://www.chinvad.ir/https://rayanposhtiban.com/%D8%AE%D8%AF%D9%85%D8%A7%D8%AA-%D9%85%D8%A7%D9%86%DB%8C%D8%AA%D9%88%D8%B1%DB%8C%D9%86%DA%AF-%D8%B4%D8%A8%DA%A9%D9%87/https://prometheus.io/https://www.zabbix.com/ امین باقری امین باقری Thu, 23 Dec 2021 22:21:48 +0330 https://virgool.io/@aminbagheri021/%D9%85%D8%B9%D8%B1%D9%81%DB%8C-%D8%A7%D8%A8%D8%B2%D8%A7%D8%B1-%D9%87%D8%A7%DB%8C-%D9%85%D8%AF%DB%8C%D8%B1%DB%8C%D8%AA-log-lnfu6tfqchtf در این پست قصد داریم با مفهوم Log Management یا مدیریت لاگ (گزارش) آشنا شویم. مفهومی که این روزها بیشتر شنیده می‌شود و کاربردهای متفاوتی برایش تعریف می‌شود.مدیریت لاگ به چه معناست؟مدیریت لاگ، عبارت است از جمع‌آوری، ذخیره، پردازش، ترکیب و تحلیل داده‌ها از برنامه‌های کاربردی متفاوت به منظور بهینه‌سازی عملکرد سیستم، شناسایی مشکلات فنی، مدیریت بهتر منابع، تقویت امنیت و بهبود انطباق.لاگ یک فایل تولید شده توسط کامپیوتر است که فعالیت های درون سیستم عامل یا برنامه های نرم افزاری را ثبت می کند. فایل لاگ، به طور خودکار هر گونه اطلاعات طراحی شده توسط مدیران سیستم از جمله پیام ها، گزارش های خطا، درخواست های فایل و انتقال فایل را مستند سازی می کند، این فعالیت همچنین دارای زمان ثبت است که به متخصصان فناوری اطلاعات و توسعه دهندگان کمک می کند تا بفهمند چه اتفاقی و در چه زمانی رخ داده است.فعالیت هایی که در مدیریت لاگ انجام می شود را می توان به دسته های زیر تقسیم بندی کرد:جمع آوریجمع آوری اطلاعات از سیستم عامل، برنامه ها، سرورها، کاربران، نقاط پایانی یا هر منبع مرتبط دیگری در سازمان.مانیتورینگردیابی رویدادها و فعالیت ها و همچنین زمان وقوع آنها.تحلیلمجموعه لاگ ها را از سرور گزارش مرور می‌کند تا به طور فعال باگ‌ها، تهدیدات امنیتی یا سایر مسائل را شناسایی کند.نگهداریتعیین می‌کند داده‌های گزارش چه مدت باید در فایل گزارش نگهداری شوند.indexing و جستجوبه سازمان کمک می‌کند تا داده‌ها را در همه لاگ ها، فیلتر، مرتب‌سازی، تجزیه و تحلیل و یا جستجو کند.گزارشگزارش‌دهی از گزارش حسابرسی (Audit Log) را به‌عنوان ارزیابی عملیاتی، تخصیص منابع، امنیت یا انطباق با مقررات، خودکار می‌کند. سیستم های مدیریت لاگسیستم مدیریت گزارش (LMS)، یک راه حل نرم افزاری است که لاگ ها و گزارش رویدادها را از منابع مختلف در یک مکان متمرکز جمع آوری، مرتب سازی و ذخیره می کند. سیستم‌های نرم‌افزاری مدیریت گزارش، به تیم‌های فناوری اطلاعات، DevOps و متخصصان SecOps اجازه می‌دهند تا یک نقطه واحد را ایجاد کنند تا از آنجا به تمام داده‌های مربوط به شبکه و برنامه، دسترسی داشته باشند. به طور معمول، این فایل گزارش به طور کامل فهرست شده و قابل جستجو است، به این معنی که تیم فناوری اطلاعات می تواند به راحتی به داده هایی که برای تصمیم گیری در مورد سلامت شبکه، تخصیص منابع یا امنیت نیاز دارد، دسترسی داشته باشد.ابزارهای مدیریت گزارش، برای کمک به سازمان در مدیریت حجم بالای داده های گزارش تولید شده در سراسر سازمان، استفاده می شوند. این ابزارها به تعیین موارد زیر کمک می کنند:چه داده ها و اطلاعاتی باید ثبت شوند.قالبی که اطلاعات، باید در آن ثبت شود.دوره های زمانی که داده های گزارش باید ذخیره شوند.چگونه داده ها زمانی که دیگر مورد نیاز نیستند باید دور ریخته شده و یا از بین بروند.اهمیت مدیریت لاگیک سیستم و استراتژی مدیریت گزارش کارآمد، بینش بلادرنگ در مورد سلامت و عملیات سیستم را امکان پذیر می کند.یک راه حل موثر مدیریت لاگ، به سازمان ها، موارد زیر را ارائه می دهد:ذخیره سازی یکپارچه داده از طریق تجمیع گزارش متمرکزبهبود امنیت از طریق کاهش سطح حمله، نظارت به صورت Real-Time و بهبود زمان تشخیص و پاسخبهبود قابلیت مشاهده در سراسر شرکت از طریق یک گزارش رویداد مشترکافزایش تجربه مشتری از طریق تجزیه و تحلیل داده های گزارش و مدل سازی پیش بینیقابلیت‌های عیب‌یابی سریع‌تر و دقیق‌تر از طریق تجزیه و تحلیل شبکه پیشرفتهچالش های رایج مدیریت لاگانفجار داده‌ها که ناشی از تکثیر دستگاه‌های متصل و همچنین حرکت به سمت ابر است، پیچیدگی مدیریت گزارش را برای بسیاری از سازمان‌ها افزایش داده است.یک راه حل مدرن و موثر مدیریت لاگ، باید چالش های اصلی زیر را برطرف کند:استاندارد سازیاز آنجایی که سیستم مدیریت گزارش، داده‌ها را از برنامه‌ها، سیستم‌ها، ابزارها و میزبان‌های مختلف استخراج می‌کند، همه داده‌ها باید در یک سیستم واحد که از همان قالب پیروی می‌کند، ادغام شوند. این فایل گزارش، به متخصصان فناوری اطلاعات و امنیت اطلاعات کمک می‌کند تا به‌طور مؤثر، داده‌های گزارش را تجزیه و تحلیل کنند و نما هایی را تولید کنند که برای انجام خدمات حیاتی تجاری استفاده می‌شوند.حجم زیادداده ها با سرعت باورنکردنی تولید می شوند. برای بسیاری از سازمان‌ها، حجم داده‌هایی که به‌طور مداوم توسط برنامه‌ها و سیستم‌ها تولید می‌شوند، نیازمند تلاش زیادی برای جمع‌آوری، قالب‌بندی، تجزیه و تحلیل و ذخیره‌سازی مؤثر است. یک سیستم مدیریت گزارش باید برای مدیریت حجم بسیار زیاد داده ها و ارائه نمای به موقع، طراحی شود.تاخیرindexing در فایل لاگ، می تواند یک فعالیت محاسباتی بسیار پرهزینه باشد که باعث تاخیر بین داده هایی که وارد سیستم می شوند شده و سپس در نتایج جستجو و نمایش (Visualization)، گنجانده می شود. تأخیر، بسته به نحوه مدیریت لاگ و اینکه آیا سیستم مدیریت گزارش، داده ها را ایندکس گذاری می کند یا نه، افزایش می یابد.بار بالامدیریت لاگ، هنگامی که به صورت دستی انجام می شود، فوق العاده وقت گیر و پرهزینه است. ابزارهای مدیریت لاگ دیجیتال، به خودکارسازی برخی از این فعالیت‌ها و کاهش فشار بر روی متخصصان فناوری اطلاعات کمک می‌کنند.ابزاردر این بخش، می‌خواهیم دو راه‌حل محبوب متن باز را که برای ساده‌سازی فرآیند مدیریت گزارش‌ها استفاده می‌ شوند معرفی و با هم مقایسه کنیم: Graylog در مقابل ELK (Elasticsearch + Logstash + Kibana).ابزار ELKELK ترکیبی از سه سرویس جداگانه است که همه آن ها متن باز هستند و توسط همان تیم توسعه یافته اند.Elasticsearch یک موتور جستجوی بسیار قدرتمند و مقیاس پذیر است که می تواند حجم زیادی از داده را ذخیره کند و به عنوان یک خوشه مورد استفاده قرار دهد.Logstash ابزاری برای واکشی (Fetch) داده ها از/به یک مکان خاص است. دارای تنوع گسترده ای از پلاگین ها و یک جامعه کاربری بزرگ است.Kibana یک رابط کاربری گرافیکی است که به شما امکان جستجو، تجزیه و تحلیل و مصورسازی مقادیر زیادی از داده های پیچیده از پایگاه داده Elasticsearch را می دهد. فرآیند استقرار، بیش از 5 دقیقه طول نمی کشد.در بیشتر موارد، پشته ELK از Filebeat استفاده می کند. هدف این ابزار، تحویل لاگ ها به یک سرور خاص است. پس از اینک لاگ ها با Filebeat تحویل داده شدند و با Logstash پردازش شدند، در کلاستر ElasticSearch قرار می گیرند. از آنجا، لاگ ها برای مصورسازی توسط کیبانا، گرفته می شوند. تمامی مراحل ذکر شده در طرح زیر توضیح داده شده است.مزایای Logstash دلیل محبوبیت Logstash این است که می توان آن را به راحتی با سایر محصولات الاستیک ادغام کرد. علاوه بر این، یک دسته کامل از پلاگین ها وجود دارد که این ابزار را بسیار انعطاف پذیر می کند. همچنین با اسناد جامعی همراه است که همه چیز لازم را برای پیکربندی و استفاده از Logstash در تقریباً هر سناریویی دارد. مراحل نصب آن نیز بسیار ساده است.معایب Logstash نقطه ضعف Logstash همیشه عملکرد و مصرف منابع بوده است. اگرچه عملکرد آن در حال حاضر بسیار بهتر از چند سال پیش است، اما در مقایسه با راه حل های دیگر هنوز بسیار کند است. سرورهای Logstash در مقایسه با سرورهای Elasticsearch، برای استقرار ترافیک بالا، مشکل دارند. و آخرین اما نه کم‌اهمیت تزین مزیت Logstash، این است که فاقد رابط کاربری گرافیکی در نسخه خارج از جعبه است، بنابراین باید با تغییر فایل‌های پیکربندی، آن را به صورت دستی پیکربندی کنید.سرویس Kibanaصفحه زیر مکانی است که می توانید نوع نمایش داده را انتخاب کنید.پس از انتخاب نوع، از شما پرسیده می شود که از کدام فهرست می خواهید اطلاعات دریافت کنید. انتخاب شاخص بر اساس شاخص‌هایی است که در حال حاضر در خوشه ElasticSearch شما موجود است.در اسکرین شات زیر، می بینید که بسته به نوع داده ای که وجود دارد، باید فیلدهای داده یا مقدار را اضافه کنید. وقتی این کار تمام شد، کیبانا آمار را در قالب نمودار انتخاب شده خروجی و تجسم می کند.علاوه بر ذخیره داده ها و تجسم آنها، ما از کیبانا برای ارائه اطلاعات دقیق و آماری در مورد نحوه عملکرد برنامه های کاربردی مشتریان در محیط تولید، به آن ها، استفاده می کنیم.به طور کلی، ELK یک ترکیب همه کاره است. پشته را می توان به عنوان یک برنامه کاربردی مستقل استفاده کرد یا با برنامه های موجود برای دریافت به روزترین داده ها یکپارچه شد.ابزار GraylogGraylog یک ابزار قدرتمند برای مدیریت گزارش‌ها است که گزینه‌های زیادی برای تجزیه و تحلیل گزارش‌های ورودی از سرورهای مختلف در اختیار شما قرار می‌دهد. روش کار Graylog تقریباً شبیه به ELK است. علاوه بر سرور Graylog که از برنامه کاربردی و سرور رابط وب تشکیل شده است، برای اینکه بتوانید کل پشته را به طور کامل قابل اجرا کنید، باید MongoDB و Elasticsearch را نیز داشته باشید.برای استفاده در تولید، توصیه می کنیم تمام اجزا را روی سرورهای مختلف نصب کنید. این باعث بهبود ثبات و عملکرد خواهد شد.بنابراین موارد زیر، مواردی هستند که برای کار با Graylog به آن ها نیاز دارید:Elasticsearch MongoDBGraylog main serverGraylog web interfaceفرآیند پیکربندی شامل 2 مرحله است:ایجاد یک پیکربندی برچسب گذاری شده Graylog برای استفاده توسط مشتریان در سمت سرور.ارسال پیکربندی به مشتریانبه عنوان مثال، هنگامی که یک مشتری را سِت می کنید، فایل پیکربندی آن را با یک برچسب "production" علامت گذاری می کنید. پس از آن، تنظیمات دقیقی را روی سرور برای مشتریان، با تگ "production" ایجاد می کنید. اکنون به محض اعمال آن، همه تغییرات به طور خودکار از سرور دریافت می شود. هیچ تغییر دیگری لازم نیست در سمت مشتری انجام شود.مزایای Graylogرابط کاربری گرافیکی دوستانه ای دارد و از طیف گسترده ای از فرمت های داده پشتیبانی می کند. گزینه های خوبی برای کنترل احراز هویت و تعیین مجوزهای کاربر، در اختیار شما قرار می دهد. همچنین می توانید آن را برای دریافت هشدار، از طریق ایمیل پیکربندی کنید. Graylog از Good-ol REST API استفاده می کند.معایب GraylogGraylog نمی تواند از فایل های syslog بخواند، بنابراین شما باید پیام های خود را مستقیماً به Graylog ارسال کنید. از نظر مدیریت، داشبورد، به اندازه کافی دوستانه نیست. عملکرد گزارش، بسیار ضعیف است.Graylog یا ELK؟ کدام بهتر است؟هر دو ابزار از نظر مجموعه ای اساسی از ویژگی ها، بسیار مشابه هستند. با این حال، به عنوان طرفداران Elasticsearch، ما همچنان Graylog را به ELK ترجیح می دهیم، زیرا دارای رابط کاربری گرافیکی دوستانه است و به شما امکان می دهد مجوزها (permissions) را مدیریت کنید. همچنین کیبانا هیچ قابلیتی برای ایجاد کاربر ندارد. با این حال، این مشکل با تنظیم احراز هویت اولیه HTTP در Nginx حل شده است که یک سرور در حال اجرا بر روی یک پورت تصادفی است که درخواست ها را به رابط وب Kibana ارسال می کند.شرکت های ایرانی ارائه دهنده خدمات مدیریت لاگشرکت داده کاوان تصمیم یارشرکت داده کاوان تصمیم یار (کوالاتک) در زمینه ارائه، مشاوره و آموزش خدمات نرم افزاری به سازمان‌های دولتی و خصوصی فعالیت می‌نماید. شرکت داده کاوان تصمیم یار خدمات مختلف نرم افزاری ارائه می‌دهد که یکی از آنها راه‌ اندازی مدیریت لاگ است.برای دریافت اطلاعات بیشتر درمورد سرویس مدیریت لاگ کوالاتک، به لینک زیر مراجعه نمایید:https://qualatech.ir/log-management/شرکت دانش بنیان پلتکوپلتکو یک شرکت دانش بنیان است که در زمینه های مختلفی از جمله معماری و یکپارچه سازی، نظارت و کنترل، مستندسازی و گزارش دهی فعالیت می کند. یکی از محصولات این شرکت ابزار مدیریت لاگ است.مزایای نرم افزار مدیریت لاگ پلتکوذخیره سازی یکپارچهعیب یابی بهترسیستم نظارت و هشدارتجزیه فایل لاگبهبود امنیتآنالیز و تحلیل داده هابرای دریافت اطلاعات بیشتر درمورد نرم افزار مدیریت لاگ پلتکو، به لینک زیر مراجعه نمایید:https://platco.ir/services/monitoring/log-manager/«این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است»مراجعhttps://www.humio.com/glossary/log-managementhttps://expertise.jetruby.com/log-management-graylog-vs-elk-d6e8f0492323https://www.elastic.co/what-is/elk-stackhttps://www.graylog.org/https://qualatech.ir/log-management/https://platco.ir/services/monitoring/log-manager/ امین باقری امین باقری Thu, 23 Dec 2021 16:09:51 +0330 https://virgool.io/@aminbagheri021/%D8%A2%D8%B4%D9%86%D8%A7%DB%8C%DB%8C-%D8%A8%D8%A7-api-gateway-snqvj09anrjq طبق تعریف گارتنر: «میکروسرویس، یک مؤلفه کاربردی با محدوده محکم (Tightly Scoped)، محصور سازی شده، با حداقل وابستگی (Loosely Coupled)، قابل استقرار و مقیاس پذیر به طور مستقل است.»برخلاف برنامه های کاربردی یکپارچه (monolithic) که در آن ها ماژول ها بسیار به هم وابسته هستند و به عنوان یک تکه بزرگ منفرد، استقرار می یابند، هدف میکروسرویس ها، تجزیه و تقسیم کافی برنامه به تعدادی ماژول (میکروسرویس) با حداقل وابستگی نسبت به هم است. استفاده از معماری مبتنی بر میکروسرویس، به دلایل زیر مفید خواهد بود:هر میکروسرویس را می توان مستقل از سایر میکروسرویس های اپلیکیشن، استقرار، به روز رسانی، نگهداری و راه اندازی مجدد کرد.توسعه و استقرار چابک هر میکروسرویس توسط یک تیم مستقل.در توسعه هر میکروسرویس، از تکنولوژی های دلخواه و متفاوت با سایر میکروسرویس ها می توان استفاده کرد. مقیاس پذیریسرویس‌های مختلف مستقل، بر اساس نیازهای خاص خود مستقر می‌شوند که در آن هر سرویس، دارای مدل API دقیق خود برای ارائه خدمات به مشتریان مختلف (وب، موبایل و APIهای شخص ثالث) است.ارتباط مشتری با میکروسرویس هاارتباطات در میکروسرویس هابرای ارتباط مستقیم مشتری (Client) با هر یک از میکروسرویس های استقرار یافته، چالش های زیر را باید در نظر گرفت:در مواردی که میکروسرویس، API های ریز دانه را در معرض دید مشتری قرار می دهد، مشتری باید به هر میکروسرویس، درخواست بفرستد. در یک صفحه معمولی، ممکن است برای انجام درخواست، چندین سفر رفت و برگشت به سرور (multiple server round trips)، مورد نیاز باشد. این ممکن است حتی برای دستگاه های دارای شبکه کم کار، مانند تلفن همراه، بدتر باشد.پذیرش پروتکل های ارتباطی متنوع (مانند gRPC، thrift، REST، AMQP و غیره) موجود در میکروسرویس ها، برای مشتری چالش برانگیز و حجیم است.توابع عملکردی دروازه (Gateway) مشترک (مانند احراز هویت، مجوز ورود به سیستم)، باید در هر میکروسرویس پیاده سازی شوند.ایجاد تغییرات در میکروسرویس ها بدون ایجاد اختلال در اتصال مشتری، دشوار خواهد بود؛ به عنوان مثال هنگام ادغام یا تقسیم میکروسرویس ها، ممکن است نیاز به کدگذاری مجدد بخش مشتری باشد.API Gateway چیست؟برای رسیدگی به چالش‌های ذکر شده، یک لایه اضافی معرفی شده است که بین مشتری و سرور قرار می‌گیرد و به عنوان یک درخواست مسیریابی پروکسی معکوس، از مشتری به سرور عمل می‌کند. مشابه الگوی نما (Facade Pattern) در طراحی شی گرا، یک نقطه ورودی واحد برای API ها فراهم می کند که معماری سیستم زیرین را محصور می کند و به آن API Gateway می گویند.به طور خلاصه، دقیقاً به عنوان API Management عمل می کند، اما مهم است که API Management را با API Gateway اشتباه نگیرید؛ یک دروازه API، به سرور پراکسی فردی اشاره دارد، در حالی که مدیریت API به راه‌حل کلی مدیریت API ها در تولید اشاره دارد که شامل مجموعه‌ای از دروازه‌ های API که در یک خوشه عمل می‌کنند، رابط کاربری مدیریتی و... می باشد.دروازه API میکروسرویسقابلیت های API GatewayمسیریابیGateway با احاطه کردن سیستم زیربنایی و جدا شدن (Decoupling) از مشتریان، یک نقطه ورودی واحد را برای مشتری فراهم می‌کند تا با سیستم میکروسرویس ارتباط برقرار کند.بارگذاریدروازه API به جای اینکه هر میکروسرویس را پیاده سازی کند، قابلیت های لبه را یکپارچه می کند. برخی از این قابلیت ها عبارتند از:احراز هویت (Authentication) و تعیین مجوز (authorization)ادغام کشف خدمات (Service discovery integration)ذخیره پاسخدوباره امتحان کردن سیاست ها، قطع کننده مدار و QOSمحدود کردن نرخ و گلوگاهایجاد تعادل بارثبت رخداد ها، ردیابی و همبستگیهدرها، رشته های پرس و جو و تبدیل ادعاها (claims transformation)Whitelist کردن ipIAMثبت متمرکز رخداد ها (شناسه تراکنش در سرورها، خطا ها)ارائه دهنده هویت، احراز هویت و تعیین مجوزمزایای API Gatewayبه جای فراخوانی یک سرویس خاص، مشتری مستقیماً با دروازه API صحبت می کند.برای هر نوع مشتری، یک API خاص ارائه می کند.از آنجایی که دروازه API بین برنامه های کاربردی Front-end و میکروسرویس ها قرار می گیرد، به عنوان یک مانع امنیتی عمل می کند و مطمئن می شود که نقاط حساس انتهایی API، در معرض دید قرار نگرفته اند. همچنین API را از بردارهای حمله مخرب مانند حملات DoS، تزریق SQL و چندین حمله مشابه دیگر که از آسیب پذیری های API استفاده می کنند محافظت می کند.به جای پیاده سازی تکراری احراز هویت و تعیین مجوز در هر یک از سرویس ها، می توان این دو قابلیت را در API Gateway پیاده سازی کرد؛ اگر این دو قابلیت را در هر یک از سرویس ها به طور جداگانه قرار دهیم باعث کندی سیستم می شود؛ زیرا به تعداد سرویس های درخواستی از طرف یک مشتری، باید احراز هویت و تعیین مجوز انجام شود و در صورتی که بخواهیم تغییراتی را در قواعد این دو قابلیت اعمال کنیم، باید برای هر سرویس این تغییرات را انجام دهیم؛ بنابراین بهتر است که احراز هویت و تعیین مجوز را بر عهده دروازه API بگذاریم. علاوه بر مورد بالا، مواردی دیگری از جمله محدود کردن نرخ ورودی و مقیاس پذیری را می توان به دروازه API سپرد.API Gateway برای Monitoring و بررسی مواردی مرتبط با درخواست‌های ارسال شده به سرویس ها، میزان پاسخ دهی موفق به آن ها در شرایط متفاوت و... نمودار‌های مختلفی را در اختیار توسعه دهندگان قرار می دهد و از این رو آن ها می‌توانند به سرعت از مشکلات موجود، باخبر شده و برای رفع آن‌ها اقدام کنند.نقاط ضعف API Gatewayتنها نقطه ممکن برای Failure یا گلوگاهافزایش زمان پاسخ به دلیل پرش اضافی شبکه از طریق دروازه API خطر پیچیدگی به دلیل قرار گرفتن تعداد زیادی قانون در یک مکانابزار های متن باز در زمینه API Gatewayابزار KongKong Gateway یک دروازه API متن باز و سبک وزن است که برای میکروسرویس ها بهینه شده است و عملکرد تأخیر و مقیاس پذیری بی نظیری را ارائه می دهد. اگر فقط اصول اولیه را می خواهید، این گزینه برای شما کار خواهد کرد. با افزودن گره های بیشتر به راحتی به صورت افقی مقیاس پذیر است. از بارهای کاری بزرگ و متغیر با تأخیر بسیار کم پشتیبانی می کند.Kong Gateway را می توانید به صورت رایگان از لینک زیر دریافت کنید:https://github.com/Kong/kongابزار Akana API Gatewayدروازه Akana API، مولفه کلیدی پلتفرم Akana API است. Akana، ایجاد و مدیریت لایه تعامل API را آسان می کند و ساده ترین راه برای تبدیل ایمن، بدون کاهش سرعت را فراهم می کند؛ بنابراین، به راحتی می توانید در هر مکانی با امنیت قوی مستقر شوید.چرا از Akana استفاده کنیم؟قدرت: از داده های پشت API های خود، با اطمینان و بدون زحمت محافظت کنید.تاب آوری: اجازه دهید آکانا دروازه بان زمان اجرای شما باشد و کارهای سنگین را انجام دهد.انعطاف‌پذیری: دروازه Akana API را در هر مکانی قرار دهید و آن را به صورت مرکزی مدیریت کنید.انتخاب درست API Gatwayبرخی از پایه های رایج برای ارزیابی ابزار ها، عبارتند از: سادگی، متن باز در مقابل مناسب بودن، مقیاس پذیری و انعطاف پذیری، امنیت، قابلیت ها، میزان جمعیتی که از آن استفاده می کنند، مدیریتی و اجرایی (پشتیبانی، نظارت و استقرار)، تامین محیط (نصب، پیکربندی، ارائه میزبانی)، قیمت گذاری، و مستندات.شرکت های ایرانی ارائه دهنده خدمات API Gatewayابر درساابر درسا یک شرکت ارائه دهنده سرویس های ابری است که محصولات زیر را ارائه می کند:سرور ابریسرویس Dynamic CDNسرویس API Gateway ابریسرویس Payment Gateway ابریسرویس SMS Gateway ابریبرای کار با سرویس API Gateway، یک پنل در اختیار مشتری قرار می گیرد که از طریق آن مشتری می تواند تعیین کند که برای دسترسی به هر صفحه، به کدام سرور درخواست زده شود که برای اینکار نیز از الگوریتم های مختلفی استفاده کرد.سرویس API Gateway ابری درسا، قابلیت های زیر را دارد:از محیط های ناهمگن شبکه پشتیبانی می کند؛ سرویس Api Gateway ابری می تواند API های سیستم های تجاری شما را مدیریت کند، صرف نظر از اینکه سیستم های تجاری شما در ابر درسا ، در مراکز داده محلی یا ابرهای شخص ثالث مستقر شده اند یا خیر.ساخت انواع معماری فنی: معماری بدون سرور، ترکیبی از Function Compute و API Gateway به توسعه دهندگان امکان می دهد تا کد را کشف کرده و به سرعت خدمات کم هزینه، بسیار در دسترس و مقیاس پذیر در زمان واقعی را ایجاد کنند. این معماری توسعه مشاغل مرتبط با دستگاه های تلفن همراه، برنامه های وب، اینترنت اشیا (IoT) بازار ابر را تسهیل می کند. این معماری امکانات توسعه تجارت و مرزهای تجاری را گسترش می دهد. انعطاف پذیری ترکیبات محصول بهبود یافته است.معماری میکروسرویس: سرویس Api Gateway ابری به عنوان یک سرویس ابری بالغ عمل می کند که اجازه دسترسی به خوشه های برنامه Kubernetes را می دهد. این به طور قابل توجهی قابلیت های سرویس خوشه های برنامه Kubernetes را بهبود می بخشد. این معماری به عنوان معماری استاندارد برای برنامه های کاربردی اینترنت در مقیاس بزرگ عمل می کند.شرکت وصلپلتفرم مدیریت API سورنا، توسعه‌دهندگان را قادر می‌سازد تا برنامه‌هایی مرتبط با سامانه‌های داخلی سازمان/سرویس‌دهنده طراحی و پیاده‌سازی نمایند. همچنین APIها در تکنولوژی‌های مختلف نظیر اینترنت اشیا، رایانش ابری و داده‌های حجیم نقشی کلیدی را ایفا می‌نماید. پلتفرم مدیریت API سورنا، پایداری، امنیت و پشتیبانی ویژه ای ارائه می‌کند تا شرکت‌های طرف ثالث، همکاران، شرکا و حتی توسعه‌دهندگان آزاد، بتوانند با آسودگی خیال و اطمینان از آنها استفاده نمایند.جمع بندیدر این مقاله، مفهومی به نام API Gateway در معماری میکروسرویس را معرفی کرده و به آن پرداختیم؛ ابتدا چالش های ارتباط مشتریان با میکروسرویس ها را بیان کرده و به ضرورت استفاده از API Gateway در معماری میکروسرویس پی بردیم؛ در ادامه قابلیت هایی که دروازه API در اختیار ما می گذارد را معرفی کرده و به مزایا و معایب آن پرداختیم. در نهایت تعدادی از سرویس دهنده های ایرانی دروازه API و همچنین ابزار های متن باز برای استفاده از دروازه های API را معرفی کردیم.«این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است.»مراجعhttps://microservices.io/index.htmlhttps://dzone.com/articles/api-management-vs-api-gateway-and-where-does-api-ahttps://blog.devgenius.io/microservices-design-api-gateway-pattern-980e8d02bdd5https://github.com/Kong/konghttps://www.akana.com/products/api-platform/api-gatewayhttps://dorsacloud.comhttp://vasl.ir امین باقری امین باقری Wed, 22 Dec 2021 22:01:55 +0330 https://virgool.io/@aminbagheri021/event-sourcing-%DA%86%DB%8C%D8%B3%D8%AA-qwqrmayzdkdn Martin Fowler، منبع رویداد را که یک الگوی معماری است، به صورت زیر تعریف می کند:«ثبت تمام تغییرات در وضعیت یک اپلیکیشن به صورت دنباله ای از رویداد ها»برای این کار، از ابزار های مختلفی می توان استفاده کرد که روش انتخابی، باید متناسب با معماری نرم افزار و تکولوژی های مورد استفاده در آن، باشد. (این که از چه نوع پایگاه داده و مدلی برای ثبت تغییرات وضعیت نرم افزار استفاده کنیم.) نکته مهم در این زمینه، پیوستگی دیتای ثبت شده است؛ به این معنی که ثبت دیتا باید به گونه ای باشد که مسیر تغییر رفتارها قابل مشاهده و قابل تحلیل باشد.باید بتوان تشخیص داد که دقیقا در چه مرحله ای رفتار و عملکرد نرم افزار، اشتباه و غیر قابل انتظار بوده است. ES فواید زیادی دارد که از جمله مهمترین آن ها می توان به دیباگ منطقی پروژه و کنترل کیفی و رفتاری آن اشاره کرد.به عنوان مثال، در سامانه های مالی که به طور مستقیم با محاسبات مالی و پولی ارتباط دارند، پیاده سازی چنین فرایندی برای دنبال کردن مقادیر مالی و کشف کسورات در انتهای محاسبات و گزارشات، به شدت حائز اهمیت است. همچنین زمانی که یک نسخه جدید از پروژه ارائه می شود، انتظار می رود که تغییرات اعمال شده روی آن نسبت به نسخه قبلی، در رفتار پروژه نیز دیده شود که در این موارد، از منبع رویداد و مقایسه دیتای ضبط شده می توان استفاده کرد.منبع رویداد چگونه کار می کند؟ایده اساسی Event Sourcing این است که اطمینان حاصل شود هر تغییری که در وضعیت برنامه کاربردی ایجاد می شود، در یک شی رویداد ثبت می شود و این اشیاء رویداد، خودشان به ترتیب وقوع رویداد ها و به طور قابل بازگشت، در پایگاه داده ثبت می شوند. بیایید یک مثال ساده برای انجام اعلان های حمل و نقل در نظر بگیریم. در این مثال ما کشتی های زیادی در دریاهای آزاد داریم و باید بدانیم هر یک کجا هستند؛ یک راه ساده برای انجام این کار، داشتن یک برنامه کاربردی ردیابی با روش هایی است که به ما امکان می دهد بفهمیم کشتی چه زمانی به بندر می رسد و یا حرکت می کند.در این حالت، زمانی که سرویس فراخوانی می شود، کشتی مربوطه را پیدا کرده و مکان آن را به روز می کند. اشیاء کشتی، وضعیت شناخته شده فعلی کشتی ها را ثبت می کنند.معرفی Event Sourcing یک مرحله به این فرآیند اضافه می کند. اکنون این سرویس یک شی رویداد ایجاد می کند تا تغییر را ثبت کند و آن را برای به روز رسانی کشتی پردازش می کند.با نگاه به شکل بالا، شاید احساس کنیم که یک گام بیهوده به پروسه اضافه شده است. اما وقتی از بیرون (out of box) به آن نگاه کنیم، متوجه می شویم که چقدر دقت کاری نرم افزار، ارتقاء یافته است؛ طوری که کوچکترین تغییرات هم در این مدل، قابل پیگیری و کنترل هستند. فرض کنید:کشتی King Roy به سمت سنفرانسیسکو حرکت می کند.کشتی Prince Trevor به لس انجلس می رسد.کشتی King Roy به هنگ کنگ می رسد.اگر از منابع رویداد استفاده نکنیم، فقط وضعیت آخر هر کشتی را در اختیار خواهیم داشت. در صورتی که با استفاده از منابع رویداد، دقیقا متوجه می شویم که زمانی که X در یک مکان خاص بوده است، Y کجا بوده است و تمام این تغییرات و رویداد ها، دقیقا ثبت و نگهداری شده اند.وضعیت کشتی ها بدون منبع رویداد:وضعیت کشتی ها با منبع رویداد: مزایامنبع رویداد، یکی از چالش های بزرگ سیستم های رویداد محور (event driven) یعنی ثبت رویداد ها با اطمینان کامل پس از هر تغییر را حل کرد.یک تاریخچه (log) کامل از تغییرات اعمال شده بر روی نرم افزار را فراهم کرده و با استفاده از آن، می توان تغییرات اعمال شده در هر نسخه از نرم افزار بر یک قسمت خاص از برنامه را مشاهده کرد.منبع رویداد، مهاجرت از معماری monolith به microservice را سهولت می بخشد.معایبمنبع رویداد، یک الگوی خاص و ناآشنا بوده و برای یادگیری، پیاده سازی و درک مفهوم آن، تلاش زیادی لازم است.کوئری زدن به یک event store کار راحتی نبوده و باید از CQRS استفاده کرد و به همین دلیل، اندکی به پیچیدگی سیستم افزوده می شود.جمع بندیالگوی معماری Event Sourcing یا به طور مختصر ES، یک روش متفاوت برای Data storage می باشد.اکثرا ما از Data store‌ هایی که مدلی از دیتا را انعکاس می‌دهند استفاده می کنیم. ES از برنامه نویسان می خواهد که مدل سنتی CRUD را فراموش کرده و به جای آن، تغییراتی را که روی دیتا صورت گرفته، نیز درج نمایند. اینکار به وسیله‌ی یک دیتابیس Append-only انجام می شود که با نام Event Store شناخته می شود.در این معماری، همه‌ی تغییرات اعمال شده روی دیتا، به صورت رویداد های پشت سرهم و ترتیب دار و در قالب یک حالت از سیستم، ذخیره می شوند که بعدا می توان در صورت نیاز، به حالت های قبلی سیستم و object ها دسترسی پیدا کرد.این الگو برای پیدا کردن وضعیت گذشته یک شی کمک بزرگی می کند و این فرایند را تسهیل می بخشد؛ علاوه بر فواید ذکر شده، می توان از منبع رویداد به عنوان یک Logger استفاده نمود. به دلیل اینکه جز به جز تغییرات اعمال شده بر روی state سیستم، در آن ثبت شده است. از آنجایی که دیتا بصورت serialized ذخیره می شود، بارگذاری آن نیز با سرعت بالایی انجام خواهد شد.«این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است.»مراجعhttps://martinfowler.com/eaaDev/EventSourcing.htmlhttps://docs.microsoft.com/en-us/azure/architecture/patterns/event-sourcing امین باقری امین باقری Fri, 10 Dec 2021 23:14:02 +0330 https://virgool.io/@aminbagheri021/%D8%A7%D9%84%DA%AF%D9%88%DB%8C-%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-mvvm-%D9%88-%D9%85%D9%82%D8%A7%DB%8C%D8%B3%D9%87-%D8%A2%D9%86-%D8%A8%D8%A7-mvc-mrdjhtsxetwj مقدمهدر این پست، به معرفی الگوی معماری MVVM و همچنین MVC (جهت مقایسه با MVVM) می پردازیم، مولفه های تشکیل دهنده این الگو ها و نحوه ارتباط مولفه ها با هم را بررسی می کنیم و در ادامه این دو الگو را از جنبه های مختلف با هم مقایسه کرده و مزایا و معایب هریک را بررسی می کنیم.MVC چیست؟فریمورک MVC، یک الگوی معماری است که یک برنامه کاربردی را به سه مولفه منطقی اصلی Model، View و Controller تقسیم می کند؛ از این رو به اختصار، MVC گفته می شود و فرم کامل آن، Model View" Controller" است.در این معماری، یک مؤلفه برای رسیدگی به جنبه های خاص توسعه یک برنامه، ساخته شده است. MVC منطق تجاری (Business Logic) و لایه نمایش (Presentation Layer) را از یکدیگر جدا می کند. این الگوی معماری عمدتا برای رابط های کاربری گرافیکی دسکتاپ (GUI) استفاده می شود.MVVM چیست؟معماری MVVM، جداسازی توسعه رابط کاربری گرافیکی را با کمک زبان نشانه گذاری یا کد GUI تسهیل می کند. MVVM، مخفف عبارت Model–View–ViewModel است.بخش View Model از معماری MVVM، یک مبدل مقدار است؛ به این معنا که اشیاء داده ای از مدل را طوری نمایش می دهد که به آسانی قابل مدیریت و ارائه باشند.الگوی MVCسه مولفه اصلی MVC عبارتند از:Model: شامل تمام داده ها و منطق مربوط به آن ها.View: نمایش داده به کاربرController: رابطی بین مولفه های Model و View.در ادامه به برررسی هر یک از مولفه ها می پردازیم:مدل (Model)مولفه مدل، داده ها و منطق مربوط به آن را ذخیره می کند؛ مدل، نشان دهنده داده هایی است که بین مولفه های کنترل کننده یا هر منطق تجاری مرتبط دیگری منتقل می شود.به عنوان مثال، یک شی Controller به شما کمک می کند تا اطلاعات مشتری را از پایگاه داده بازیابی کنید؛ این شی، داده ها را دستکاری کرده و آن ها را به پایگاه داده باز گردانده یا آن ها را برای نمایش، تحویل می دهد.نما (View)نما، بخشی از برنامه است که نمایش داده ها را ارائه می دهد. نماها توسط داده های جمع آوری شده از مدل ها ایجاد می شوند. یک نما، برای ارائه اطلاعات، از مدل درخواست می کند تا خروجی را دوباره به کاربر ارسال کند.نما همچنین داده های نمودارها و جداول را ارائه می دهد. به عنوان مثال، هر نمای مشتری، شامل تمام اجزای رابط کاربری از جمله Text Box ها، Dropdown ها و... خواهد بود.کنترلر (Controller)کنترلر بخشی از برنامه است که تعامل با کاربر را برعهده دارد. کنترلر ورودی های ماوس و صفحه کلید را از کاربر دریافت کرده، تفسیر می کند و به مدل و نما، اطلاع می دهد که در صورت لزوم تغییر کنند.یک کنترلر دستوراتی را به مدل ارسال می کند تا وضعیت آن را به روز کند (به عنوان مثال، ذخیره یک سند خاص). کنترلر همچنین دستوراتی را به نمای مربوط به خود ارسال می کند تا نمایش View را تغییر دهد (به عنوان مثال، نمایش یک سند خاص).الگوی MVVMمعماری MVVM اتصال دو طرفه داده بین view و view-model را ارائه می دهد. همچنین به شما کمک می کند تا به طور خودکار، انتشار تغییرات در View-Model به view را انجام دهید. View-model از الگوی مشاهده گر (Observer Pattern) برای ایجاد تغییرات در view استفاده می کند.در ادامه به برررسی هر یک از مولفه ها می پردازیم:مدل (Model)مولفه مدل، داده ها و منطق مربوط به آن را ذخیره می کند؛ مدل، نشان دهنده داده هایی است که بین مولفه های کنترل کننده یا هر منطق تجاری مرتبط دیگری منتقل می شود.به عنوان مثال، یک شی Controller به شما کمک می کند تا اطلاعات مشتری را از پایگاه داده بازیابی کنید؛ این شی، داده ها را دستکاری کرده و آن ها را به پایگاه داده باز گردانده یا آن ها را برای نمایش، تحویل می دهد.نما (View)نما، بر پایه اجزای UI مانند HTML، CSS، jQuery و... است. در الگوی MVVM، نما مسئول نمایش داده هایی است که از مدل ویو به عنوان نتیجه دریافت می شود. این نما، همچنین مدل ها را به رابط کاربری (UI) تبدیل می کند.ویو مدل (View Model)ویو مدل، مسئول ارائه توابع، دستورات و متدها برای پشتیبانی از وضعیت نما است. همچنین مسئول اجرای مدل و فعال کردن رویدادها در نما است.ویژگی های MVCبرخی از ویژگی های مهم MVC عبارتند از:چارچوبی با قابلیت تست بالا، توسعه پذیر و قابل اتصالارائه کنترل کامل بر HTML همانند URL هاپشتیبانی از توسعه تست محور (Test Driven Development)این معماری، جداسازی منطق را ارائه می دهد.ارائه نقشه برای URL های قابل جستجوویژگی های MVVMMVVM برای برنامه های دسکتاپ با قابلیت اتصال داده نوشته شده است.ویو مدل برای اعمال تغییرات، از یک الگوی مشاهده گر استفاده می کند.مزایای MVCتوسعه مولفه های مختلف را می توان به صورت موازی انجام داد.با تقسیم یک برنامه به واحدهای جداگانه (MVC) از پیچیدگی جلوگیری می کند.بهترین پشتیبانی را برای توسعه تست محور ارائه می دهد.یک جداسازی تمیز از دغدغه ها (SoC) را فراهم می کند.همه کلاس ها و اشیاء، مستقل از یکدیگر هستند تا بتوانید آنها را جداگانه آزمایش کنید.امکان گروه بندی منطقی اقدامات مرتبط روی یک کنترلر را با هم فراهم می کند.مزایای MVVMجداسازی منطق تجاری از رابط کاربرینگهداری و تست آسانسهولت استفاده مجدد از مولفه هااتصال سستشما می توانید موارد تست واحد را برای هر دو لایه viewmodel و Model بدون نیاز به ارجاع به View بنویسید.معایب MVCمنطق تجاری با رابط کاربری، میکس است.استفاده مجدد و اجرای تست ها سخت است.عدم پشتیبانی از Formal Validationافزایش پیچیدگی و ناکارامدی داده هادشواری استفاده از MVC با رابط کاربری مدرنبرای استفاده از آن، دانش در چند فناوری مختلف، لازم است.معایب MVVMنگهداری از تعداد زیادی قطعه کد در کنترلربرخی از افراد بر این باورند که برای رابط های کاربری ساده، معماری MVVM می تواند زیادی باشد.اتصال محکمی بین نما و ویو مدل ارائه نمی دهد.تفاوت های بین MVVM و MVCچارچوب MVC یک الگوی معماری است که یک برنامه کاربردی را به سه مولفه منطقی Model، View و Controller تقسیم می کند. از طرف دیگر MVVM جداسازی توسعه رابط کاربری گرافیکی را با کمک زبان نشانه گذاری یا کد GUI تسهیل می کند.در MVC، کنترلر نقطه ورود به برنامه است، در حالی که در View ،MVVM نقطه ورود به برنامه است.مؤلفه مدل در MVC را می توان به صورت جدا از کاربر آزمایش کرد، در حالی که MVVM، انجام آزمایش واحد (Unit Test) به صوررت جداگانه را تسهیل می کند و کد آن، مبتنی بر رویداد (Event-Driven) است.معماری MVC دارای روابط "یک به چند" بین Controller و View است، در حالی که در معماری MVVC، روابط "یک به چند" بین View و View Model است.در MVC، نما ارجاعی به کنترلر ندارد اما در MVVM، نما ارجاعاتی به ویو مدل دارد.MVC یک مدل قدیمی است در حالی که MVVM یک مدل نسبتا جدید است.خواندن، تغییر، تست واحد و استفاده مجدد از مدل MVC، مشکل است در حالیکه در MVVM، فرآیند اشکال زدایی زمانی پیچیده خواهد شد که پیوندهای پیچیده داده ای داشته باشیم.جمع بندیالگوی Model-View-ViewModel کمک می کند تا منطق کسب و کار و ارائه یک برنامه کاربردی را از رابط کاربری (UI) آن جدا کنید. حفظ جدایی تمیز بین منطق برنامه و رابط کاربری به رفع مشکلات متعدد توسعه کمک می کند و می تواند آزمایش، نگهداری و تکامل یک برنامه را آسان تر کند. همچنین می‌تواند فرصت‌های استفاده مجدد از کد را تا حد زیادی بهبود بخشد و به توسعه‌دهندگان و طراحان رابط کاربری اجازه دهد تا در هنگام توسعه بخش‌های مربوطه خود از یک برنامه، راحت‌تر با یکدیگر همکاری کنند.با استفاده از الگوی MVVM، رابط کاربری برنامه و منطق ارائه و کسب و کار زیربنایی، به سه کلاس جداگانه تقسیم می‌شود: view، که UI و منطق UI را در بر می‌گیرد. ویو مدل، که منطق و حالت ارائه را در بر می گیرد. و مدلی که منطق تجاری و داده های برنامه را در بر می گیرد.«این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است.»مراجعhttps://docs.microsoft.com/en-us/xamarin/xamarin-forms/enterprise-application-patterns/mvvmEnterprise Application Patterns eBookhttps://www.guru99.com/mvc-vs-mvvm.html#2 امین باقری امین باقری Fri, 10 Dec 2021 19:20:59 +0330 https://virgool.io/@aminbagheri021/%D8%A7%D9%84%DA%AF%D9%88%DB%8C-%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-cqrs-vqnziwufufvw مقدمهCQRS یک الگوی معماری است که از کنار هم قرار دادن حروف اول عبارت Command Query Responsibility Segregation تشکیل شده است. این الگو، عملیات سیستم را به دو قسمت دستورات (Commands) و کوئری ها (Queries) تقسیم بندی می کند. CQRS با CQS که مخفف Command Query Separation است مرتبط بوده و از آن مشتق شده است.در این پست، ابتدا CQS را تعریف کرده و ارتباط آن با CQRS را بررسی می کنیم. سپس به توضیح CQRS می پردازیم و در ادامه اصول اصلی، مزایا و همچنین برخی از تصورات اشتباه در مورد این الگو را بررسی می کنیم.CQS چیست؟CQS یک الگوی طراحی است که از کنار هم قرار دادن حروف اول عبارت Command Query Separation تشکیل شده است. CQS یک مفهوم اولیه و اساسی است که برای عملیات انجام شده بر روی سیستم، دو نوع را تعریف می کند: دستوری که یک تسک را اجرا می کند و کوئری که اطلاعاتی را برمی‌گرداند، و تابعی نباید وجود داشته باشد که هر دوی این کارها را انجام دهد.این اصطلاح توسط Bertrand Mayer و در کتاب «ساخت نرم افزار شی گرا» در سال ۱۹۸۸ خلق شد؛ او آن را به عنوان بخشی از کار خود بر روی زبان برنامه نویسی Eiffel ایجاد کرد.CQRS اصل تعیین کننده CQS را می گیرد و آن را به اشیاٰء خاصی در سیستم گسترش می دهد، یکی در بازیابی داده و دیگری در تغییر داده. CQRS یک الگوی معماری گسترده و CQS، یک اصل عمومی رفتاری است.CQRS چیست؟CQRS تفکیک مسئولیت های دستورات و کوئری ها در یک سیستم است. این بدان معناست که ما منطق برنامه خود را به صورت عمودی برش می دهیم. علاوه بر این، پرش حالت (دستورالعمل فرمان) را از بازیابی اطلاعات (کنترل کوئری) جدا می کنیم.CQRS توسط Greg Young تعریف شد.Command and Query Responsibility Segregation از همان تعریف دستور (Command) و کوئری که Mayer استفاده کرد، استفاده می کند و این دیدگاه را حفظ می کند که آن دو باید خالص باشند. تفاوت اساسی این است که در CQRS، اشیا به دو شی تقسیم می شوند، یکی دستورات، و دیگری کوئری ها را شامل می شود. «اشیا» در تعریف اصلی، با ذخیره سازی (Storage) مرتبط نبوده بلکه با کنترل کننده ها (Handlers) مرتبط هستند. ما خطوط لوله (Pipelines) مختلفی را برای رفتار های تجاری متفاوت ایجاد می کنیم، نه برای ذخیره سازی جداگانه.اصول اصلیاصل اساسی CQRS، جداسازی دستورات و کوئری ها و کارهایی است که آن ها انجام می دهند. دستورات و کوئری ها، نقش‌های بسیار متفاوتی را در یک سیستم انجام می‌دهند و تفکیک آنها به این معنی است که هر کدام می‌توانند در صورت نیاز بهینه شوند که می‌تواند برای سیستم‌های توزیع‌شده بسیار مفید باشد.Alexey Zimarev، چگونگی تفاوت دستورات و کوئری ها را به صورت زیر تعریف کرده است:در سطح بالا، CQRS این حقیقت را بیان می‌کند که عملیات‌هایی که انتقال حالت را راه‌اندازی می‌کنند باید به‌عنوان دستور (Command) توصیف شوند، و هر بازیابی داده‌ای که به اجرای دستور نیاز نداشته باشد، باید یک پرس و جو (Query) نامیده شود. از آنجایی که مقررات عملیاتی برای اجرای دستورات و پرس و جوها اغلب متفاوت است، توسعه دهندگان باید استفاده از تکنیک های ماندگاری مختلف را برای رسیدگی به دستورات و پرس و جوها در نظر بگیرند؛ بنابراین باید آنها را از هم جدا کنند.در ادامه، به دستورات، کوئری ها و ارتباط آن ها با مدل های خواندن (Read) و نوشتن (Write)، می پردازیم.دستورات (Commands)به گفته برتراند مایر، Command یک فرمان است؛ دستوری برای انجام یک کار خاص که قصد دارد چیزی را تغییر دهد.یک دستور، یک کار را انجام می دهد اما نتیجه ای را بر نمی گرداند.یک دستور باید هدف کاربر را منتقل کند. طبق توضیح الکسی زیمارف، اجرای یک دستور باید منجر به یک تراکنش روی یک جمع شود. اساساً، هر دستور باید به وضوح یک تغییر کاملاً تعریف شده را بیان کند.دستورات، مدل نوشتن (Write Model) را تشکیل می دهند و مدل نوشتن باید تا حد امکان به فرآیندهای تجاری نزدیک باشد.کوئری ها (Queries)به گفته برتراند مایر، کوئری، یک درخواست برای اطلاعات است.یک کوئری، یک نتیجه بر می گرداند اما حالت را تغییر نمی دهد.کوئری، درخواستی برای دریافت اطلاعات و یا وضعیت اطلاعات از یک مکان مشخص است. هیچ چیزی در داده ها نباید با درخواست تغییر کند. از آنجایی که کوئری ها چیزی را تغییر نمی دهند، نیازی به درگیر کردن مدل دامنه (Domain Model) ندارند.کوئری ها مدل خواندن (Read Model) را تشکیل می دهند. مدل خواندن باید از مدل نوشتن مشتق شود. همچنین لازم نیست دائمی باشد. مدل‌های خواندن جدید را می‌توان بدون تأثیرگذاری بر مدل‌های موجود، به سیستم معرفی کرد. مدل های خواندن را می توان بدون از دست دادن منطق تجاری و یا اطلاعات، حذف و دوباره ایجاد کرد؛ زیرا در مدل نوشتن ذخیره می شوند.مزایای CQRSاستفاده از اصول CQRS در معماری، مزایای بسیاری را به همراه خواهد داشت:از بین بردن مرز های بین رفتار سیستم: راهنمایی به خصوصی در مورد ساخت برنامه در رابطه با رفتار، ارائه می دهد.نزدیک بودن به منطق تجاری: کد و معماری، بر اساس عملیات تجاریشان تفکیک شده اند و این کار، تمرکز بر روی مورد تجاری را آسان تر می کند.اتصال سست: منطق، مسنجم بوده و بخش های مختلف آن، کمتر به هم مرتبط هستند و در نتیجه ، ایجاد برنامه های ماژولار و قابل نگهداری را آسان تر می شود.کاهش بار شناختی: به دلیل جداسازی عمودی، کد های مرتبط،‌ در کنار هم نگه داشته می شوند. برای تغییر کد موجود و یا ایجاد کد جدید، نیازی به فهم تمام معماری و منطق تجاری نیست و در نتیجه، تمرکز بر روی یک وظیفه خاص، آسان تر می شود.مقیاس پذیری، بهینه سازی و تغییر در معماری به طور آسان تر: از آن جایی که کد ما در سیلو ها نگهداری می شود، تنظیم دقیق تنها یک پایپ لاین و دست نزدن به بقیه آن ها، آسان تر است و در نتیجه، تمرکز بر روی بهینه سازی های دقیق، در مکان هایی که Business-critical هستند را آسان تر می کند. قابل پیش بینی بودن: به علت جداسازی، شما قوانین عمومی ای برای رفتار عملیات دارید و از تغییر حالت برنامه به وسیله یک کوئری، متعجب نمی شوید؛ حفظ جداسازی بین منطق نوشتن و خواندن، احتمال تولید یک کد اسپاگتی را کاهش می دهد.موارد استفاده از CQRSاز الگوی CQRS در موارد زیر استفاده می شود:رابط های کاربری مبتنی بر وظیفه (Task-based user interfaces) که در آن کاربران از طریق یک فرآیند پیچیده به عنوان یک سری مراحل یا با مدل های دامنه پیچیده هدایت می شوند. مدل نوشتن دارای یک پشته پردازش کامل فرمان (full command-processing stack) با منطق تجاری، اعتبارسنجی ورودی و اعتبارسنجی تجاری است. مدل نوشتن ممکن است مجموعه‌ای از اشیاء مرتبط را به‌عنوان یک واحد یکتا برای تغییر دیتا در نظر بگیرد و اطمینان حاصل کند که این اشیاء همیشه در یک حالت ثابت هستند. مدل خواندن، هیچ منطق تجاری یا پشته اعتبار سنجی ندارد و فقط یک DTO را برای استفاده در یک view model برمی گرداند. مدل خواندن در نهایت با مدل نوشتن سازگار است.دامنه های مشارکتی که در آن بسیاری از کاربران به طور موازی به داده های مشابه دسترسی دارند؛ CQRS به شما اجازه می دهد تا دستوراتی را با جزئیات کافی برای به حداقل رساندن تضادهای ادغام (Merge conflicts) در سطح دامنه، تعریف کنید و تداخل هایی که به وجود می آیند را با دستور (Command) ادغام کنید.سناریوهایی که در آن ها عملکرد خواندن داده ها باید جدا از عملکرد نوشتن داده ها تنظیم شود، به خصوص زمانی که تعداد خواندن ها بسیار بیشتر از تعداد نوشتن ها باشد؛ در این سناریو می توانید مدل خواندن را کوچک کرده و مدل نوشتن را فقط در چند نمونه اجرا کنید. تعداد کمی از نمونه های مدل نوشتن نیز به حداقل رساندن وقوع تضادهای ادغام کمک می کنند.سناریوهایی که در آن یک تیم از توسعه دهندگان می تواند بر روی مدل دامنه پیچیده که بخشی از مدل نوشتن است تمرکز کرده و تیم دیگری می تواند بر روی مدل خواندن و رابط های کاربری تمرکز کند.سناریوهایی که در آن ها انتظار می‌رود سیستم در طول زمان تکامل یابد و ممکن است چندین نسخه از مدل را شامل شود یا سناریو هایی که در آن ها، قوانین تجاری به طور منظم تغییر می‌کنند.ادغام با سایر سیستم ها به ویژه در ترکیب با الگوی منبع رویداد که در آن خرابی موقت یک زیرسیستم نباید بر در دسترس بودن سایر زیر سیستم ها تأثیر بگذارد.الگوی CQRS برای موارد زیر، توصیه نمی شود:دامنه یا قوانین تجاری ساده هستند.یک رابط کاربری ساده به سبک CRUD: عملیات دسترسی به داده کافی است.استفاده از CQRS را به بخش هایی از سیستم خود محدود کنید که در آن ها بیشترین ارزش را خواهد داشت.چالش هابرخی از چالش های استفاده از این الگو، عبارتند از:پیچیدگی: ایده اصلی CQRS ساده است، اما می تواند منجر به پیچیدگی طراحی برنامه شود، به خصوص اگر شامل الگوی Event Sourcing باشد.پیام رسانی: اگرچه CQRS به پیام رسانی نیازی ندارد، استفاده از پیام رسانی برای پردازش دستورات و انتشار به روز رسانی ها معمول است. در این صورت، برنامه باید با دو مشکل خرابی پیام ها و پیام های تکراری مقابله کند.سازگاری نهایی: اگر پایگاه های داده خواندن و نوشتن را از هم جدا کنید، داده های خوانده شده ممکن است کهنه شود. مخزن مدل خواندن باید به روز شود تا تغییرات را در مخزن مدل نوشتن منعکس کند و تشخیص این که کاربر بر اساس داده های خوانده شده قدیمی، یک درخواست را انجام داده است، می تواند دشوار باشد.تصورات غلط در مورد CQRS«دستورات و کوئری ها باید در پایگاه های داده جداگانه اجرا شوند و همه چیز باید در پایگاه های داده جداگانه ذخیره شود.» این عبارت، لزوما درست نیست؛ فقط نیاز است که رفتار ها و مسئولیت های آن دو را از هم جدا کرد. این می تواند داخل کد، در ساختار یک پایگاه داده و یا پایگاه های داده مختلف باشد. CQRS حتی نیازی به استفاده از پایگاه داده ندارد؛ ممکن است از اکسل و یا هر چیز دیگر که حاوی داده است، استفاده شود. CQRS، برای رفتار یک سیستم کاربرد دارد، نه برای مکان ذخیره سازی داده. به خاطر داشته باشید که جمله کلیدی «CQRS به رفتار اشاره دارد و نه ذخیره سازی»، کلید استفاده موثر از CQRS است.«CQRS مشکلات سازگاری نهایی (Eventual Consistency) را ایجاد می کند.» جداسازی دستورات و کوئری ها و مدیریت متفاوت آنها می تواند یک سیستم در نهایت سازگار را تولید کند. این تصور غلط وجود دارد که سیستم های درنهایت سازگار به دلیل تاخیرهای زمانی، دقیق نبوده و با جداسازی دستورات و کوئری ها در CQRS، باید تاخیر ها و در نتیجه مشکلات سازگاری نهایی وجود داشته باشد.«سیستم های CQRS همیشه به صف های پیام (Messaging Queues) نیاز دارند.» صف های پیام مانند Kafka و RabbitMQ، بسته به شرایط به شما امکان ارسال پیام بین مدل های خواندن و نوشتن را می دهند. اگر مدل شما ساده بوده و با نماهای مختلف پایگاه داده شروع می شود، به صف های پیام نیازی نیست؛ به طور کلی، استفاده از آن، به نیازمان در آن زمینه تجاری خاص، بستگی دارد. ساخت سیستم با در نظر گرفتن CQRS به شما این امکان را می دهد که انواع مختلف پایگاه های داده را در تعامل با یکدیگر داشته باشید. صف های پیام رسانی برای نگه داری به روز مدل های خواندن در صورت تغییر مدل نوشتن، مفید خواهند بود.«فقط می تواند با DDD استفاده شود.»CQRS و DDD نسبت به هم، دو مفهوم مجزا و متعامد هستند و برای استفاده از DDD نیازی به استفاده از CQRS نیست و برعکس. DDD در اصل با CQRS هماهنگ است؛ اما این دو قطعاً به یکدیگر وابسته نیستند.جمع بندیالگوی معماری CQRS، روشی برای جداسازی رفتار نوشتن و خواندن داده‌ها از یکدیگر است. این روش، برای سیستم‌هایی که با تعداد درخواست‌های بسیار زیادی روی پایگاه‌های داده خود مواجه هستند مناسب است. CQRS در شرایط مناسب، باعث افزایش کارایی سیستم‌ و مقیاس پذیری بهتر آن می شود.لازم به ذکر است که استفاده از CQRS آسان نبوده و نیاز به نیروی متخصص دارد. جداسازی مدل‌های خواندن و نوشتن از یکدیگر، خطر ایجاد ناهماهنگی میان داده‌ها را بالا می برد؛ بنابراین از CQRS باید در موارد کاربردی خود و به طور سنجیده استفاده شود.«این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است.»مراجعhttps://bertrandmeyer.comhttps://www.eiffel.com/resources/faqs/eiffel-languagehttps://www.eventstore.com/cqrs-patternhttps://martinfowler.com/bliki/CQRS.htmlhttps://docs.microsoft.com/en-us/azure/architecture/patterns/cqrs امین باقری امین باقری Fri, 10 Dec 2021 04:53:18 +0330 https://virgool.io/@aminbagheri021/%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-%D8%A8%D8%A7-%D8%A7%D8%B3%D8%AA%D9%81%D8%A7%D8%AF%D9%87-%D8%A7%D8%B2-%D9%85%D8%AF%D9%84-c4-ygrenn7rhyd8 مقدمهنمودار های معماری، روشی برای برقراری ارتباط با نحوه ایجاد یک نرم افزار و یا نحوه عملکرد یک سیستم نرم افزاری موجود هستند. با این حال به احتمال زیاد، اکثر نمودار های معماری نرم افزاری که دیده اید، ترکیبی به هم ریخته از اشکال و خطوط هستند؛ یکی از عوارض ناگوار این نمودار های ناخوانا و شلوغ، این بوده است که بسیاری از تیم ها، تلاش های مستند سازی و نمودار سازی خود از جمله استفاده از UML را کاهش داده و یا متوقف کرده اند و به رسم نمودار های موردی روی تخته وایت برد و استفاده از ابزار هایی مانند Microsoft Visio روی آورده اند.مستند سازی نرم افزار باید به گونه ای باشد که برای تمام ذی نفعان که هریک از دیدگاه مختلفی به سیستم نگاه می کنند، قابل درک باشد. درک نمودار های UML، به دلیل پیچیدگی زیاد، برای افرادی که با نماد های آن آشنا نبوده و دانش فنی در این زمینه ندارند، دشوار خواهد بود.برای حل مشکلات ذکر شده، فردی به نام Simon Brown مدلی به نام C4 را ارائه کرد که در ادامه به شرح این مدل می پردازیم. مدل سازی C4 چیست؟مدل C4، معماری نرم افزار را در سطوح مختلف جزئیات، توصیف می کند. این مدل برگرفته از ۴ کلمه ، Components ،Containers ،Context و Code بوده و شامل مجموعه ای از نمودار ها است که مفاهیم سیستم، کانتینر ها، مولفه ها و کد یک نرم افزار را نمایش می دهند. سلسله مراتب این نمودارها به مخاطبان اجازه می دهد که معماری نرم افزار را در سطح جزئیات مورد نیاز خود، درک کنند. می توان از یک مدل C4 برای مایکرو سرویس ها، برای نمایش برنامه ریزی برای ساخت یک سیستم و یا توصیف یک سیستم موجود استفاده کنید. نمودار های C4، یک چارچوب جایگزین و ساده شده در مقایسه با نمودار های UML هستند و بر خلاف نمودار های معماری AWS، نمودار های معماری GCP و یا نمودار های معماری AZURE، می توانند چندین سیستم را توصیف کنند.مدل C4 توسط Simon Brown، نویسنده کتاب "معماری نرم افزار برای توسعه دهندگان"، در طی سال‌های 2006 تا 2011، بر پایه زبان مدل‌سازی واحد (UML) و مدل نمای معماری 4+1 ایجاد شد.سطوح مدل C4چهار نوع مدل C4 وجود دارد (شکل ۱) که هر کدام برای مخاطبان متفاوتی بوده و دارای سطح متفاوتی از جزئیات می باشند. مفاهیم سیستم (زمینه)،کانتینر ها، مولفه ها و نمودار های کد هستند که مدل معماری نرم افزار شما را می سازند.در ادامه، 4 سطح مدل را معرفی کرده و برای یک سیستم بانکداری اینترنتی، نمودار های مرتبط را مشاهده می کنیم.شکل ۱ ـ سطوح مدل C4سطح اول: نمودار مفاهیم سیستمنمودار مفاهیم سیستم، کلی ترین و سطح بالا ترین توصیف از سه مورد زیر را ارائه می دهد:سیستم چه کاری را انجام می دهد؟چه کسی از آن استفاده می کند؟ با چه سیستم های دیگری تعامل خواهد داشت؟یک نمودار زمینه به شما کمک می کند تا محدوده پروژه خود را توصیف کنید و مشخص کنید که کاربر چه کسی است و می خواهید چه مشکلی را حل کنید.شکل ۲، نمودار سطح اول سیستم بانکداری اینترنتی را نمایش می دهد؛ مشتریان، خدماتی از جمله پرداخت قبوض و انتقال وجه را از این سیستم دریافت می کنند. سیستم های Mainframe و E-mail، با سامانه ما در ارتباط هستند؛ Mainframe، وظیفه ذخیره اطلاعات مشتریان را داشته و سیستم بانکداری، اطلاعات مورد نیاز را از این سیستم دریافت می کند.سیستم E-mail، ارتباط سامانه با مشتریان را فراهم می کند.شکل ۲ ـ نمودار مفاهیم سیستمسطح دوم: نمودار های کانتینرنمودار کانتینر، اولین گام برای توصیف سیستم نرم افزاری را برداشته و API ها، برنامه های کاربردی، پایگاه های داده و مایکرو سرویس هایی که سیستم از آن ها استفاده خواهد کرد را نشان می دهد. هر یک از این برنامه های کاربردی و یا سرویس ها، با یک کانتینر نمایش داده شده و تعاملات بین آن ها به صورت سطح بالا (High-Level) نشان داده می شود.در شکل ۳، نمودار کانتینر سیستم بانکداری اینترنتی قابل مشاهده است. داخل باکسی که محدوده آن با خط چین مشخص شده است، کانتینر هایی قرار دارند که سیستم بانکداری از آن ها تشکیل شده است. در این نمودار، تکنولوژی های مورد استفاده برای ارتباط کانتینرها با یکدیگر و چگونگی تعامل سیستم بانکداری با سایر سیستم‌ها و کاربران، قابل مشاهده است.شکل ۳ ـ نمودار کانتینرسطح سوم: نمودار های مولفهیک گام عمیق تر از نمودار کانتینر، نمودار مولفه است که گروه های کدِ قرار گرفته شده در یک کانتینر را شرح می دهد. این مولفه ها، انتزاعی از بیس کد نرم افزار را نشان می دهند.این نوع نمودار، با نمودار مولفه UML قابل مقایسه است؛ با این تفاوت که نمودار مولفه UML، از مجموعه قوانین سخت گیرانه تری پیروی می کند.شکل ۴، مؤلفه‌های کانتینر API سیستم بانکداری را نشان می‌دهد. مخاطبان این نمودار، معماران و توسعه‌دهندگان نرم‌افزار هستند و به کمک آن، در مورد معماری سیستم در سطوح پایین، تبادل اطلاعات می کنند.شکل ۴ ـ نمودار مولفهسطح چهارم: نمایش کد با نمودار های کلاسآخرین سطح، به جزئیات زیادی نیاز دارد تا نشان دهد که چگونه کد یک مولفه، پیاده سازی می شود. برای نمودار این سطح، می‌توان از نمودار‌های UML، مانند نمودار کلاس استفاده کرد.شکل ۵، جزئیات پیاده سازی مؤلفه MainframeBankingSystemFacade و نمودار کلاس آن را نشان می‌دهد.شکل ۵ ـ نمودار کدنشانه گذاریبرای رسم نمودار های مدل C4، هیچ نشانه گذاری خاصی پیشنهاد نشده است و محدودیتی در این باره وجود ندارد، اما توصیه می شود که از نشانه گذاری های UML استفاده شود؛ تنها اهمیت این امر، انتقال درست و ساده مفاهیم به مخاطب است.در شکل ۶، نشانه گذاری پیشنهادی آقای Brown آورده شده است. شکل ۶ ـ نشانه گذاری پیشنهادی آقای Brownابزارروش های زیادی برای ایجاد نمودار های C4 وجود دارد که در ادامه به طور مختصر به بعضی از این روش ها می پردازیم:ابزار Structurizr توسط Simon Brown، سازنده مدل C4 ایجاد شده است که به ما اجازه رسم نمودار ها را به صورت دستی و یا کدنویسی آن ها با جاوا، #C و TypeScript را می دهد.استفاده از Draw.io می تواند روشی مناسب برای نگهداری و نسخه بندی نمودار های معماری در ریپازیتوری های مختلف باشد. همچنین می توانیم با استفاده از افزونه C4، نشانه گذاری C4 را در این ابزار فعال نماییم.از Gliffy، برای توصیف معماری نرم افزار بوسیله مدل C4 استفاده می شود. این ابزار، نمودار های UML، نمودار های Entity-Relationship و نمودار های معماری ابری را نیز پشتیبانی می کند. بخشی از محیط این ابزار، در شکل ۷ قابل مشاهده است.شکل ۷ ـ محیط ابزار Gliffyجمع بندیمدل C4 یک چارچوب ساده و منعطف برای برقراری ارتباط با سطوح مختلف معماری نرم افزار است که بسته به نیازهای مختلف، می توان به صورت متفاوتی از آن استفاده کرد؛ به عنوان نمونه،‌ معماران نرم افزار و توسعه دهندگان، از طریق نمودار های مولفه و یا نمودار های کانتینر با هم تبادل اطلاعات می کنند، اما برای نمایش ساختار کلی نرم افزار به مشتری و یا افرادی که دانش زیادی در حوزه فنی ندارند، از نمودار مفاهیم سیستم استفاده می کنیم. این مدل، مزایای زیادی دارد که برخی از آن ها در زیر آورده شده است:مزایای C4قابلیت نگهداری آسان: نگهداری آن سخت نبوده و نسبت به بسیاری از راه حل های دیگر، آسان تر می باشد.معماری را از دیدگاه های مختلفی نمایش می دهد.نه فقط برای کادر فنی، بلکه در سطح سازمانی می تواند مفید واقع شود.نماد های مبهم را حذف می کند.بعضی از قسمت ها می توانند به صورت خودکار تولید شوند. معایب C4مدل C4 در کنار مزایای زیادش، معایبی نیز دارد:مصور سازی ایستا: ما نمی دانیم که یک ارتباط، در چه زمان و چند مرتبه، اتفاق می افتد.انتزاعات سطح پایین، باید به طور منظم به روز رسانی شوند.«این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است»مراجعhttps://c4model.comhttps://www.youtube.com/watch?v=x2-rSnhpw0ghttps://www.infoq.com/articles/C4-architecture-model/https://www.gliffy.com/blog/c4-modelhttps://betterprogramming.pub/modeling-software-architecture-with-c4-243eb1f240c7https://github.com/plantuml-stdlib/C4-PlantUMLhttps://www.structurizr.comhttps://github.com/tobiashochguertel/c4-draw.io امین باقری امین باقری Thu, 18 Nov 2021 04:05:55 +0330