https://virgool.io/feed/@hamidhandid فلاتر دولوپر و فارغ‌التحصیل ارشد نرم‌افزار fa 2026-06-16 14:52:32 https://files.virgool.io/upload/users/185798/avatar/uG9OZz.png?height=120&width=120 https://virgool.io/@hamidhandid https://virgool.io/@hamidhandid/%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-%D9%88-%DA%A9%D8%A7%D9%86%D8%AA%DB%8C%D9%86%D8%B1%D9%87%D8%A7-jmqcfk0hyu3b چکیدهامروزه هر پروژه نرم‌افزاری دارای یک معماری خاص است حتی اگر به معماری آن فکر نشده باشد. معماری این پروژه‌های نرم‌افزاری بخش‌های مهم و ارتباط بین این بخش‌ها در این نرم‌افزارها را نشان می‌دهد. یک دسته از این معماری‌ها موسوم به معماری میکروسرویس هستند که با استفاده از سرویس‌های مستقل، امروزه تقسیم کردن بخش‌های مختلف یک سیستم یا نرم‌افزار بزرگ به واحدهای نسبتاً مستقل و قابل توسعه و تست، آسان‌تر از گذشته کرده‌اند. داکر ابزاری پرکاربرد است که در معماری میکروسرویس برای جدا کردن واحدهای مستقل با استفاده از مفهوم کانتینرها، تحولی در این راستا ایجاد کرد. این داکرها ممکن است در یک پروژه، پیچیده و زیاد شوند و به همین خاطر ابزارهایی مانند Docker Swarm و Kubernetes نیز وجود دارند که مدیریت داکرها را ساده‌تر می‌کنند. در این پروژه ابتدا به بررسی مفاهیم حوزه معماری میکروسرویس و سپس به معرفی و دسته‌بندی دو ابزار معروفی که در حوزه مدیریت‌ داکرها ذکر شد خواهیم پرداخت.کانتینرها!مقدمهدر این پروژه قرار است ابزارها و فناوری‌های مرتبط با معماری‌های مبتنی بر میکروسرویس را بررسی و تحلیل کنیم. قبل از این بررسی و تحلیل، ابتدا باید به عنوان پروژه بپردازیم. باید بدانیم هر کدام از واژه‌های استفاده شده در عنوان پروژه چه معنایی می‌دهد. باید بدانیم معماری‌های مبتنی بر میکروسرویس و کانتینرها به چه معناست. بنابراین برخی واژه‌های مهمی که در عنوان پروژه از آن استفاده شده را تعریف می‌کنیم. به ترتیب تعاریف معماری نرم‌افزار، میکروسرویس و کانتینر را مرور می‌کنیم. پس از آن می‌توانیم بفهمیم معماری میکروسرویس چیست و مزایا و معایب آن را بدانیم. سپس به سمت ابزارها و فناوری‌ها مانند داکر و کوبرنتیز می‌رویم و رویکرد آن‌ها برای پاسخ به برخی دغدغه‌ها و چالش‌هایی که در معماری میکروسرویس یا به طور کلی در معماری نرم‌افزار داریم را بررسی می‌کنیم.تعریف معماری نرم‌افزاردر قدم اول معماری نرم‌افزار را باید تعریف کنیم. معماری نرم‌افزار به گونه‌های مختلفی قابل تعریف است. می‌توان معماری نرم‌افزار را توصیف واحدهای اصلی سیستم و روابط آن‌ها و فعل و انفعال آن‌ها با یکدیگر دانست. البته معماری را فهم و درک مشترک توسعه‌دهندگان و طراحان از طراحی سیستم را نیز تعریف می‌کنند. تصمیم‌هایی که باید در معماری نرم‌افزار گرفته شوند، ممکن است هر چه دیرتر گرفته شوند هزینه‌های بیشتری برای تیم توسعه و طراحی نرم‌افزار به بار آورد.تعریف میکروسرویسمیکروسرویس به واحدهای مستقل نرم‌افزار گفته می‌شود که هر کدام از این واحدها می‌توانند توسعه و استقرار (deploy) داده شوند. این واحدها که از این به بعد به آن‌ها میکروسرویس‌ می‌گوییم می‌توانند از طریق رابط‌ها با میکروسرویس‌های دیگر می‌توانند ارتباط برقرار کنند. یک میکروسرویس قابلیت نگهداری آسان‌تری نسبت به یک نرم‌افزار بزرگ با واحدهای متعدد دارد و می‌تواند مستقلاً توسط تعدادی از توسعه‌دهندگان سیستم، توسعه و تست شود و سپس استقرار یابد.تعریف کانتینریک کانتینر (Container)، واحد استانداردی از نرم‌افزار است که کد و وابستگی‌های آن را به صورت یک بسته (Package) در خود دارد و به صورت ایزوله قابل استفاده است. بنابراین می‌توان یک میکروسرویس را در یک یا تعدادی کانتینر توسعه داد و تست و نگهداری کرد. هم‌چنین جابجایی کانتینرها بین محیط‌های مختلف و زیرساخت‌های گوناگون بسیار آسان است. امروزه داکر (Docker) برای استفاده از قابلیت‌های کانتینرها استفاده می‌شود.تفاوت کانتینر و ماشین مجازی (Virtual Machine)کانتینرها یک بسته نرم‌افزاری شامل وابستگی‌های خود بودند که می‌توانستند مستقلاً اجرا شوند. تفاوت اصلی کانتینرها با ماشین مجازی در اینجاست که تعداد زیادی کانتینر می‌توانند در یک سیستم عامل و یک ماشین اجرا شوند در حالی که ماشین مجازی یک سیستم عامل کامل مخصوص به خود را دارد. در واقع کانتینرهایی که در یک سیستم‌عامل در حال اجرا شدن هستند هسته (Kernel) سیستم عامل را با دیگر کانتینرهای موجود در آن ماشین، به اشتراک می‌گذارند. این کانتینرها به صورت فنی مانند پروسه‌های مستقل از هم در فضای کاربر (user space) هستند. کانتینرها فضای بسیار کمی در حد چند ده مگابایت به خود اختصاص می‌دهند که در مقایسه با فضایی که VM ها نیاز دارند بسیار کمتر است. از طرف دیگر VM ها یک ماشین مجازی هستند که هر یک سیستم‌عامل مخصوص به خود را دارند و در واقع این قابلیت را به توسعه‌دهندگان می‌دهند که یک سرور فیزیکی خود را به چندین سرور مجازی تبدیل کنند. هر یک از VM ها یک سیستم‌عامل کامل مخصوص به خود، اپلیکیشن و وابستگی‌ها و کتابخانه‌های مخصوص به خود را دارند. VM ها فضایی در حد چندین گیگابایت نیاز دارند.معماری مبتنی بر میکروسرویسدر این بخش معماری نرم‌افزار‌ مبتنی بر میکروسرویس و کانتینر را تعریف و بررسی می‌کنیم. بهتر است ابتدا بدانیم تفاوت آن با مدل‌های مرسوم دیگر و معماری‌های رایجی که استفاده می‌شود چیست. در ابتدا معماری یک‌تکه و سپس معماری میکروسرویس را مرور و بررسی می‌کنیم. در نهایت تفاوت‌ها و مزایا و معایب آن‌ها را می‌بینیم.معماری یک‌تکه (Monolithic)در معماری یک‌تکه، نرم‌افزار و سیستم مبتنی بر کدبیس واحد است. در معماری مونولیتیک یا یک‌تکه، سیستم معمولاً به سه بخش back-end، front-end و دیتابیس تقسیم می‌شود. در این معماری، این سه بخش سیستم ما را می‌سازند. در این معماری، این بخش‌ها به صورت یکپارچه توسعه داده می‌شوند و معمولاً هر چه سیستم بزرگتر شود کدبیس نیز بزرگتر و پیچیده‌تر شده و توسعه‌دهندگان باید قسمت‌های بیشتری از سیستم را تغییر دهند. در این معماری ممکن است که به صورت منطقی، ماژول‌های مختلفی داشته باشیم اما کل نرم‌افزار به عنوان یک بسته و یک‌تکه، استقرار می‌یابد.معماری میکروسرویس (Microservice)در معماری میکروسرویس، سیستم یا نر‌م‌افزار به تعدادی میکروسرویس کوچکتر تقسیم می‌شود که با یکدیگر در ارتباط هستند. این ارتباط می‌تواند مثلاً با استفاده از پروتکل‌های معروفی مانند HTTP انجام شود. در معماری میکروسرویس، هر میکروسرویس بخشی از سیستم را در خود دارد که باید تا حد امکان یک وظیفه مهم را انجام دهد. هر میکروسرویس به طور مستقل می‌تواند قابل توسعه باشد و با پیچیده‌شدن یکی از آن‌ها، بقیه میکروسرویس‌ها لزوماً پیچیده نخواهند شد. هر میکروسرویس می‌تواند خود به صورت یک معماری یک‌تکه باشد.تفاوت‌های معماری‌های یک‌تکه و میکروسرویس و مزایا و معایب هر کدام از آن‌هادر این بخش به تفاوت‌های معماری‌های یک‌تکه و میکروسرویس و مزایا و معایب آن‌ها نسبت به یکدیگر خواهیم پرداخت.تفاوت معماری یک‌تکه و میکروسرویس به روایت تصویرتفاوت معماری یک‌تکه و میکروسرویسهمان‌طور که از تعاریف هر کدام از معماری‌ها یک‌تکه و میکروسرویس مشخص است، معماری یک‌تکه به صورت سنتی استفاده می‌شود و برای سیستم‌های نه چندان پیچیده‌ای که بخش‌های متعددی ندارند، قابل استفاده است اما معماری میکروسرویس برای سیستم‌های پیچیده و بزرگی که دارای بخش‌های مختلف هستند که هر یک وظیفه و نقش مهمی در سیستم ایفا می‌کنند، بسیار مفیدتر است.در معماری یک‌تکه، یک دیتابیس واحد وجود دارد که هر بخش با آن دیتابیس ارتباط برقرار می‌کند اما در معماری میکروسرویس، هر میکروسرویس معمولاً یک دیتابیس مربوط به خود را داراست. در ادامه به صورت موردی تفاوت‌های این دو نوع معماری را به صورت خلاصه بیان می‌کنیم.معماری یک‌تکهنرم‌افزار یک کدبیس دارد و به صورت واحد استقرار می‌یابد.تغییر نرم‌افزار معمولاً به بخش‌های زیادی تغییر وارد می‌کند.معمولاً روی یک سرور یا ماشین مجازی استقرار می‌یابد.معمولاً دارای یک دیتابیس است.معماری میکروسرویسنرم‌افزار میکروسرویس‌های متعددی دارد که کدبیس‌های مختلفی دارند و هر کدام مستقلاً می‌توانند تولید شوند و استقرار یابند.تغییر نرم‌افزار معمولاً به صورت تغییر در یک میکروسرویس اتفاق می‌افتد که لزوماً به تغییر درمیکروسرویس‌های دیگر منجر نمی‌شود.معمولاً روی تعدادی کانتینر یا تعدادی ماشین مجازی برای هر میکروسرویس، استقرار می‌یابد.هر میکروسرویس می‌تواند دیتابیس خود را داشته باشد.مزایا و معایب معماری‌های یک‌تکه و میکروسرویسمزایای معماری یک‌تکه را مرور می‌کنیم. معماری یک‌تکه، به صورت آسان قابل توسعه است. استقرار آن معمولاً به صورت واحد قابل انجام است و نیازی به استقرار سرویس‌های متعدد نیست. هم‌چنین چون معمولاً به صورت یکپارچه است پس نیازمند پروتکل و راهی برای اتصال سرویس‌های گوناگون با هم نیست و ممکن است سرعت بالاتری داشته باشد.اکنون به معایب معماری یک‌تکه می‌پردازیم. در معماری یک‌تکه، اگر سیستم بزرگ و پیچیده شود و بخواهیم سیستم را مقیاس‌پذیر (Scalable) کنیم، کار سخت و دشواری داریم و مدیریت یک واحد کلی و مقیاس‌پذیری آن بسیار مشکل‌زا خواهد بود. به ازای هر تغییر در سیستم باید کل سیستم استقرار یابد. هم‌چنین احتمالاً توسعه‌دهندگان به کل سیستم مسلط نخواهند بود و این ممکن است به بخش‌های منطقی معماری یک‌تکه آسیب یا مشکل یا باگ وارد کند. هم‌چنین این معماری برای تیم‌های چابک، مناسب نخواهد بود چون کل سیستم در یک واحد قابل استقرار خلاصه شده و نمی‌توان به خوبی تقسیم وظایف انجام داد و مشخص کرد که یک بخش از سیستم دقیقاً یک کار انجام دهد.معماری میکروسرویس مشکلات معماری یک‌تکه را تا حد خوبی می‌تواند حل کند. میکروسرویس کردن معماری، مزایایی مانند کوچک‌تر شدن واحدهای نرم‌افزار، مشخص بودن وظیفه هر میکروسرویس برای انجام یک کار واحد، کمک به چابک بودن تیم‌های توسعه با انتساب هر میکروسرویس به یک تیم نسبتاً مستقل، استقرار مستقل هر میکروسرویس بدون نگرانی زیاد نسبت به در حال توسعه بودن بقیه میکروسرویس‌ها، مقیاس‌پذیری بالای سیستم، رفع خطا، باگ و مشکلات آسان‌تر و داشتن باگ‌های کمتر، امکان پایش (Monitoring) راحت‌تر، بخش‌های مستقل و قابل فهم‌تر و کوچک‌تر و به همین دلیل سریع‌تر و بسیاری موراد دیگر را دارد.البته معماری میکروسرویس ممکن است معایب و مشکلاتی مانند پیچیده‌کردن سیستم، مدیریت ارتباط میکروسرویس‌ها، توانایی استقرار هر میکروسرویس و پیچیدگی مستقل بودن این استقرار، کاهش سرعت نسبت به معماری یک‌تکه به علت ارتباط درونی میکروسرویس‌ها با هم، استفاده از زبان‌های برنامه‌نویسی و تکنولوژی‌های مختلف در هر میکروسرویس، سینک‌کردن داده و دیتابیس‌های مختلف که توسط هر میکروسرویس استفاده می‌شود، مدیریت پیچیده کانتینرها و مواردی دیگر از این دست را به سیستم تحمیل کند.معماری میکروسرویس، راه حل یا اضافه کردن پیچیدگی؟تاکنون فهمیدیم که معماری نرم‌افزار و معماری‌های یک‌تکه و میکروسرویس به چه معنا هستند. سوالی که باید اکنون از خود بپرسیم این است که استفاده از معماری میکروسرویس همیشه به تیم نرم‌افزار و به خود نرم‌افزار کمک می‌کند؟ اگر همیشه کمک نمی‌کند در چه شرایطی معماری میکروسرویس برای ما نامناسب خواهد بود؟برای پاسخ به این سوال (و اکثر سوال‌هایی که در این حوزه پرسیده می‌شود!) باید بگوییم که بستگی دارد که می‌خواهیم نرم‌افزار و معماری آن چگونه باشد. اگر تیم نرم‌افزاری کوچکی داریم و نرم‌افزارمان به گونه‌ای است که قرار نیست مقیاس زیادی داشته باشد و توسط تیم‌های مختلف توسعه داده شود، می‌توانیم از معماری یک‌تکه استفاده کنیم و نگران نباشیم. چه بسا اگر با چنین نرم‌افزاری به سمت میکروسرویس برویم، صرفاً به پیچیدگی‌های معماری خود افزوده باشیم و سودی برایمان نداشته باشد.اگر نرم‌افزاری داریم که قرار است توسعه‌پذیری آسان‌تر داشته باشد و توسط تیم‌های مختلف با حداقل وابستگی به یکدیگر و با هدف مینیمم کردن مشکلات عدم تطابق تیم‌های مختلف با یکدیگر باشد و هر یک از واحدهای سیستم را بتوانیم بشکنیم و به صورت جدا توسعه و تولید و استقرار دهیم، پس بهتر است به سمت معماری میکروسرویس برویم.چالش‌های میکروسرویسمیکروسرویس‌ها چالش‌هایی را حل می‌کنند و چالش‌هایی را به نرم‌افزار تحمیل می‌کنند. طبق این مقاله تا سال 2016 توزیع چالش‌های مهمی که در 33 مقاله‌ای که بررسی شده و مربوط به میکروسرویس بوده‌اند در نمودار زیر آمده است.توزیع مفاهیم و چالش‌های میکروسرویس در مقاله‌هادر نمودار بالا در هر قطعه تعداد مقاله‌های مرتبط با هر کلیدواژه در هر قطاع از نمودار دایره‌ای نوشته شده است.طبق نمودار بالا، مواردی مانند ارتباط و یکپارچگی، کارایی، تحمل خطا، امنیت، لاگ و پایش و هم‌چنین عملیات‌های توسعه از جمله‌ مهم‌ترین چالش‌ها و کلیدواژه‌های مرتبط با میکروسرویس هستند که در ادامه نیز بعضی از آن‌ها را بررسی میکنیم.چالش‌هایی که معماری میکروسرویس حل می‌کنداز زمانی که معماری میکروسرویس محبوب شد، شرکت‌های زیادی در ایران و سطح جهان به سمت آن مهاجرت کردند تا بتوانند چالش‌هایی که قبلاً با آن دست و پنجه نرم‌ می‌کردند را تا حد خوبی برطرف کنند. به عنوان مثال اضافه کردن یک ویژگی جدید و مقیاس‌پذیری نرم‌افزار همیشه جزو مشکلات بزرگ این شرکت‌ها بود که باعث می‌شد با حذف صورت مسئله یا استفاده از راه‌ حل‌های سخت‌تر مشکل خود را حل کنند. موارد زیر از جمله چالش‌هایی است که معماری میکروسرویس می‌تواند تا حد خوبی آن‌ها را به چالش‌هایی کم‌خطرتر تبدیل کند:مقیاس‌پذیری نرم‌افزارزمان عرضه به بازار (time to market) برای ویژگی‌های جدیدتوسعه و نگهداری نرم‌افزار در واحدهای مستقل در تیم‌های چابک (agile)تحمل خطا (fault tolerance) در معماری نرم‌افزاراستفاده از فرایندهای توسعه و تحویل مستمر (CI/CD) به صورت مستقل‌ برای هر میکروسرویساستفاده از سرویس‌های ابریامکان تست مستقل‌تر واحدهای نرم‌افزارامکان استقرار مستقل‌تر واحدهای نرم‌افزارو ...چالش‌هایی که معماری میکروسرویس اضافه می‌کندحرکت به سمت معماری میکروسرویس همیشه فقط سود نخواهد داشت. قطعاً در این مسیر باید منتظر چالش‌ها و عواقب آن نیز بود. به عنوان مثال فرض کنید که قرار باشد داده در تمام میکروسرویس‌ها با هم تطابق داشته باشد. اگر در معماری خود عملیات و انتقال پیام غیر همزمان (async) داشته باشیم، این تطابق و پایداری داده بسیار چالش برانگیز خواهد شد. چالش‌هایی که معماری میکروسرویس به نرم‌افزار اضافه می‌کند به طور خلاصه شامل موارد زیر است:سینک بودن و تمامیت داده در میکروسرویس‌هاآپدیت کردن داده در میکروسرویس‌هااضافه شدن پیچیدگی به سیستم و افزایش پیچیدگی عملیات‌هانحوه طراحی و استخراج میکروسرویس‌ها و محدوده آن‌هاطراحی نحوه ارتباط بین میکروسرویس‌هاچالش‌های مربوط به لاگ و پایش نرم‌افزاراستقرار میکروسرویس‌ها با توجه به وابستگی‌های آن‌هاو ...رابطه بین معماری میکروسرویس و ویژگی‌های کیفیویژگی‌های کیفی (Quality attributes) برخی ویژگی‌های غیرکارکردی نرم‌افزار مانند دردسترس بودن (Availability)، کارایی (Performance)، مقیاس‌پذیری (Scalability)، امنیت (Security) و چنین مواردی هستند که معمولاً با ارائه یک معیار می‌توان بررسی کرد که تا چه میزان در معماری سیستم به آن‌ها توجه شده و باید به این نیازمندی‌ها پاسخ داده شود. حرکت از سوی معماری یک‌تکه به سوی معماری میکروسرویس، معمولاً باعث می‌شود به علت جدا بودن میکروسرویس‌ها، مقیاس‌پذیری سیستم آسان‌تر شود، امنیت هر میکروسرویس افزایش یابد و قابلیت نگهداری سیستم نیز بهبود پیدا کند. ممکن است کمی سرعت پاسخگویی کاهش یابد اما اگر معماری میکروسرویس درست چیده شود و به تاکتیک‌های درست توجه شود سرعت پاسخگویی افزایش نیز خواهد یافت. آزمون‌پذیری و قابلیت استقرار سیستم بهتر می‌شود چون هر میکروسرویس را می‌توان جداگانه تست کرد و استقرار داد. دسترسی‌پذیری سیستم نیز اگر معماری با تاکتیک‌های مناسب مانند استفاده از سرورهای پشتیبان طراحی شود، بهبود خواهد یافت.رابطه بین معماری میکروسرویس و چابک بودن تیم نرم‌افزاریدر تیم‌های نرم‌افزاری، امروزه معماری میکروسرویس بسیار محبوب شده است. با توجه به اینکه هر میکروسرویس می‌تواند به صورت مستقل، تولید، تست، نصب و مستقر شود، وابستگی‌ میان تیم‌های مختلف موجود در یک سامانه به حداقل می‌رسد و به چابک (Agile) بودن تیم‌های نرم‌افزاری کمک می‌شود. دیگر تیم‌ها به صورت سنتی معطل بقیه تیم‌های نرم‌افزاری برای توسعه نخواهند ماند و دغدغه‌ آن‌ها معمولاً میکروسرویسی است که با آن سروکار دارند نه میکروسرویس‌های دیگر. هر تیم نرم‌افزاری مرتبط با سیستم که معمولاً با یک یا حداکثر چند میکروسرویس کار می‌کنند، متخصصان DevOps مربوط به خود را خواهد داشت تا فرایندهای CI/CD (یکپارچه‌سازی و تحویل مستمر) را نیز بهبود ببخشند. مواردی که ذکر شد قبل از وجود معماری میکروسرویس بسیار سخت‌تر و در واقع تا حد خوبی نشدنی بود.نحوه طراحی و استخراج میکروسرویس‌هایکی از مسائلی که برای تیم‌های نرم‌افزاری و معماران نرم‌افزار در هنگام مهاجرت به سمت میکروسرویس‌ها وجود دارد نحوه طراحی و یا استخراج هر میکروسرویس است. به تصویر زیر توجه کنید:استخراج میکروسرویس از یک سیستم یک‌تکهدر تصویر بالا همان طور که مشخص است کد و واحدهایی که می توانند به طور غیروابسته و با وظیفه‌ای مستقل کار کنند از هم جدا شده‌اند. هم‌چنین از API Gateway برای ارسال درخواست کلاینت‌ها به سمت هر سرویس استفاده شده است. هم‌چنین برای هر سرویس، دیتابیس مخصوص به خود استفاده شده است. پس می‌توان از این مثال نتیجه‌ گرفت که یکی از روش‌ها به این صورت است که ابتدا کد و بخش‌هایی که می‌توانند وظیفه‌ مستقل و واحدی داشته باشند از هم جدا شوند، سپس برای هر کدام از آن‌ها دیتابیس مجزا درنظر گرفته شود و دیتابیس قبلی به چند دیتابیس به ازای هر میکروسرویس تبدیل شود، اگر واحدهایی که تبدیل به میکروسرویس تبدیل می‌شوند وابستگی یا ارتباطی با هم دارند برای آن راه حلی مانند استفاده از پروتکل ارتباطی بین دو سرویس طراحی شود، سپس یک API Gateway در بین کلاینت و میکروسرویس‌ها و واحدها قرار داده شود. هم‌چنین در تمامی این مراحل باید به محدوده‌هایی که برای هر میکروسرویس درنظر داریم (Bounded Context) کاملاً توجه شود. نکته مهم دیگر این است که باید بدانیم که میکروسرویس‌های ما لزوماً به شکل بالا نخواهند بود و شاید در شبکه‌های مختلف وجود داشته باشند. در این حالت باید یک رجیستری سرویس (Service Registry) داشته باشیم که در واقع یک دیتابیس است که شامل آدرس شبکه از هر یک از میکروسرویس‌های نرم‌افزار است. با گذراندن این مراحل می‌توانیم تا حدودی اطمینان یابیم که میکروسرویس‌ها را درست استخراج کرده‌ایم.هم‌چنین برای طراحی میکروسرویس‌ها، یکی از روش‌های محبوب دیگر، استفاده از مفهوم DDD یاDomain Driven Design است. در روش DDD که ابتدا توسط Eric Evans معرفی شد باید متخصصانی به دامنه نرم‌افزار و سیستمی که قرار است توسعه داده شود تا حد خوبی مسلط باشند. در این رابطه خواندن این مقاله توصیه می‌شود.داکر، یکی از مفاهیم مهم معماری میکروسرویسبرای استفاده از معماری میکروسرویس، یکی از مهم‌ترین ابزارها و مفاهیم، داکر است که برای ساخت کانتینرها جهت استفاده در هر میکروسرویس به کار می‌رود. در ادامه بررسی می‌کنیم که داکر چیست.داکر چیست؟می‌خواهیم کمی فنی‌تر به سمت بررسی معماری میکروسرویس برویم. چون گفتیم که امروزه داکر برای ایجاد و استفاده از کانتینرها استفاده می‌شود ابتدا باید بدانیم داکر در این حوزه چه نقشی دارد و چه ابزاری است.داکر ابزاری است که امکان استفاده از کانتینرها (که قبلاً آن را تعریف کردیم) را به تیم‌های نرم‌افزاری می‌دهد. در واقع داکر می‌تواند برای ما کانتینرهایی بسازد و اجرا کند تا ما بتوانیم کدها و وابستگی‌های واحدهای نرم‌افزاری خود را به صورت مستقل و ایزوله از محیط سیستم، تولید و تست کنیم و سپس استقرار دهیم و در نهایت بتوانیم به راحتی داکرهای خود را با کمترین درد (!) یعنی بدون نیاز به نصب تعداد زیادی کتابخانه و وابستگی برای هر محیط، بین واحدها و سرورهای مختلف جابجا کنیم. البته باید بدانیم تا قبل از داکر نیز مفهوم کانتینرها وجود داشته اما این داکر بود که ساختن، جابجایی و اجرای کانتینرها را بسیار آسان‌تر از گذشته کرد.اجزای داکراکنون می‌خواهیم پا را کمی فراتر بگذاریم. می‌خواهیم بدانیم خود داکر چه قسمت‌هایی دارد و چگونه از این قسمت‌ها برای ساخت یک کانتینر بهره می‌برد. پس باید با اجزای مختلف یک داکر آشنا شویم.موتور داکر (Docker Engine)موتور داکر قسمتی از داکر است که کانتینر را می‌سازد و اجرا می‌کند. این موتور به صورت یک اپلیکیشن کلاینت و سرور کار می‌کند یعنی یک سرور می‌سازد که یک پروسه که به آن daemon می‌گوییم (و در ادامه در موردش توضیح می‌دهیم) را پیوسته اجرا می‌کند و کلاینت که مثلاً می‌تواند در ترمینال کاربر باشد به وسیله REST API ای که داکر دارد می‌تواند با آن daemon ارتباط برقرار کند.پروسه پس‌زمینه (Docker Daemon)داکر یک پروسه پس‌زمینه موسوم به daemon دارد که به ریکوئست‌های فرستاده شده از کلاینت داکر، گوش می‌دهد و اجزای مختلف داکر را مدیریت می‌کند. هم‌چنین یک daemon می‌تواند با daemon های دیگر در ارتباط باشد.کلاینت داکر (Docker Client)کلاینت داکر، راه اصلی برای استفاده از داکر توسط کاربرها است. در واقع وقتی کاربر، دستور docker run را در ترمینال می‌نویسد، کلاینت داکر به سمت daemon درخواستی برای ارتباط با آن می‌فرستد. کلاینت داکر می‌تواند با چند daemon در ارتباط باشد.ایمیج داکر (Docker Image)ایمیج داکر در واقع یک فایل و قالب غیرقابل تغییر است که شامل دستورهایی است برای ساخت یک کانتینر داکر استفاده می‌شود. برای ساختن یک ایمیج نیاز است که یک فایل داکر (Docker file) بسازیم که در آن توسط یک سینتکس ساده می‌توانیم مراحل و دستورات ساخت آن ایمیج و نحوه اجرا شدن آن را بنویسیم.حال می‌توانیم بفهمیم که یک کانتینر در داکر در واقع یک نسخه قابل اجرا از یک ایمیج است. با استفاده از API ای که داکر ارائه می‌دهد، می‌توان یک کانتینر را ساخت، start یا stop کرد، آن را منتقل نمود و یا آن را حذف کرد.رجیستری داکر (Docker Registry)رجیستری داکر، جایی است که ایمیج‌های داکر را ذخیره می‌کند. مثلاً Docker Hub یک رجیستری عمومی است که دارای داکر ایمیج‌های متعددی است و هر کاربری می‌تواند از آن استفاده کند. البته می‌توان رجیستری‌های خصوصی نیز تعریف کرد.مدیریت و سازماندهی کانتینرها و داکرهااگر تعداد داکرها برای توسعه یک نرم‌افزار افزایش یابد چگونه آن‌ها را می‌خواهیم مدیریت و سازماندهی کنیم؟ به صورت دستی آن‌ها را می‌خواهیم استقرار دهیم؟ اگر داکرهای مختلفی که در نرم‌افزار خود استفاده کرده‌ایم با داکرهای دیگر در ارتباط بودند چه؟ اگر در مقیاس بزرگ، تعداد بسیار زیادی داکر داشتیم آیا می‌خواهیم دستی مدیریت آن‌ها را انجام دهیم یا ابزارهایی جهت خودکارسازی مدیریت داکرها وجود دارد؟ اینجاست که ابزارهای سازماندهی کانتینرها (Container Orchestration) برای خودکارسازی این فرایند کمک بسیاری به ما می‌کنند.ابزارهای مدیریت و سازماندهی کانتینرها که لغت "ارکستراسیون کانتینرها" نیز برای آن‌ها به کار می‌رود، فرایند مدیریت، مقیاس‌پذیری، نگهداری و استقرار کانتینرها را خودکارسازی می‌کنند. این ابزارها می‌توانند برای زمان‌بندی اجرا و ساخت کانتینرها، نحوه اختصاص منابع به آن‌ها، میزان سلامت (health) هر یک از کانتینرها، نحوه مقیاس‌پذیری آن‌ها و راه‌اندازی دوباره هر کانتینر، نحوه توزیع بار (load balancing)، کاهش خطای انسانی در مدیریت داکرها، ساده‌سازی عملیات‌های مرتبط با داکرها و بسیاری موارد دیگر به کار روند.دو مورد از مهم‌ترین و پرکاربردترین ابزارهای ارکستراسیون کانتینرها Docker Swarm و Kubernetes هستند. در ادامه در مورد هر یک از این دو ابزار صحبت می‌کنیم و بررسی می‌کنیم هر کدام از چه مکانیزم‌ها و روش‌هایی برای مدیریت استفاده از کانتینرها استفاده می‌کنند و ارتباط آن با معماری میکروسرویس را بررسی خواهیم کرد.ابزار Kubernetesابزار kubernetes یا کوبرنتیز یک ابزار متن‌باز برای ارکستراسیون کانتینرهاست که با استفاده از آن می‌توان کانتینرها را مدیریت و اسکیل کرد و استقرار داد. این ابزار توسط گوگل ساخته شده است. به این ابزار به صورت مخفف k8s نیز گفته می‌شود.این ابزار وقتی به کار می‌آید که تعداد زیادی کانتینر که ممکن است در سرورهای مختلفی مستقر باشند داریم و می‌خواهیم آن‌ها را مدیریت کنیم. به این منظور کوبرنتیز به توسعه‌دهندگان و متخصصان دوآپس، یک API ارائه می‌دهد که می‌توان با آن کنترل کرد که هر کانتینر چگونه و کجا ران شود.این ابزار با توجه به میزان منابع موجود در هر سرور و اینکه هر کانتینر به چه میزان از منابع احتیاج دارد، آن‌ها را بین سرورها و ماشین‌های مجازی مختلف پخش و پیکربندی می‌کند. به گروهی از کانتینرها در ادبیات کوبرنتیس، نام pod داده می‌شود که در واقع واحد عملیاتی برای کوبرنتیز است یعنی کوبرنتیز یک یا چند کانتینر که در یک pod قرار گرفته‌است را می‌تواند اجرا کند نه اینکه کانتینر به صورت مستقل اجرا شود. کانتینرهای داخل یک pod می‌توانند منابع (resource) ها را با هم به اشتراک بگذارند. البته باید توجه کرد که کماکان کانتینرهای داخل یک pod از دیگر pod ها ایزوله هستند. هم‌چنین ابزار کوبرنتیز می‌تواند به صورت اتوماتیک مواردی مانند میزان منابع اختصاص داده‌شده و load سرورها را track کند. هم‌چنین می‌تواند بر این اساس عملیات پیکربندی کانتینرها را انجام دهد. هم‌چنین کوبرنتیز به صورت اتوماتیک میزان سلامت هر منبع را چک می‌کند و می‌تواند مثلا با restart کردن یک کانتینر سلامت آن را به حالت عادی برگرداند.در کوبرنتیز، یک گره یا node در واقع یک ماشین مجازی یا فیزیکی است که کوبرنتیز روی آن نصب شده است. در واقع یک یک گره جایی است که کانتینرهای داخل pod ها توسط کوبرنتیز اجرا می‌شوند.یک خوشه (Cluster) مجموعه‌ای از چندین گره است که در کنار هم قرار می‌گیرند. معمولاً اگر یکی از گره‌ها دچار مشکل شود، نرم‌افزار از طریق بقیه گره‌ها هم‌چنان می‌تواند بدون مشکل کار کند.ابزار Docker Swarmاین ابزار نیز مانند kubernetes برای مدیریت و پیکربندی و اسکیل container هاست. در واقع Docker Swarm یک گروه از VM ها یا ماشین‌های فیزیکی است که روی هر کدام از آن‌ها چندین داکر (کانتینر) اجرا می‌شود. این ابزار برای موتور داکر نوشته شده و API مخصوص به خود را دارد. تمام امکاناتی که در کانتینرهای داکر وجود دارد در Swarm نیز قابل استفاده است. در مقایسه با کوبرنتیز، کاستوم کردن موارد مختلف در Swarm ممکن است مشکل زا باشد و همه‌ امکانات کوبرنتیز را نیز ندارد.یک گره، یک نمونه از موتور داکر است. دو نوع گره در Swarm وجود داره. گره مدیر (Manager Node) که در واقع واحدهای کاری که به آن وظیفه (Task) گفته می‌شود را به گره‌های کارگر اختصاص می‌دهد. گره کارگر (Worker Node) وظایف را از گره مدیر دریافت می‌کند و به اجرای آن وظایف می‌پردازد.یک سرویس در واقع وظایفی است که روی یک گره مدیر یا کارگر باید اجرا شود.منابع و لینک‌های مفیدN Alshuqayran, N Ali, R Evans - A systematic mapping study in microservice architecture - 2016 IEEE 9th International 2016Microservices, The Journey So Far and Challenges Ahead, Pooyan Jamshidi, Claus Pahl, Nabor C. Mendonça, James Lewis, Stefan Tilkovhttps://martinfowler.com/architecture/https://articles.microservices.com/monolithic-vs-microservices-architecture-5c4848858f59https://www.docker.com/resources/what-containerhttps://avinetworks.com/what-are-microservices-and-containers/https://devops.com/microservices-vs-monoliths-which-is-right-for-your-enterprise/https://docs.docker.com/get-started/overview/https://www.redhat.com/en/topics/containers/what-is-container-orchestrationhttps://thenewstack.io/kubernetes-vs-docker-swarm-whats-the-difference/https://kubernetes.io/https://docs.docker.com/engine/swarm/https://containerjournal.com/topics/container-ecosystems/kubernetes-vs-docker-a-primer/https://martinfowler.com/articles/break-monolith-into-microservices.htmlhttps://www.nginx.com/blog/service-discovery-in-a-microservices-architecture/https://developer.ibm.com/articles/challenges-and-benefits-of-the-microservice-architectural-style-part-1/https://docs.microsoft.com/en-us/dotnet/architecture/microservices/architect-microservice-container-applications/distributed-data-managementاین مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است. Hamid Montazeri Hamid Montazeri Sat, 12 Feb 2022 19:11:44 +0330 https://virgool.io/@hamidhandid/log-management-d9asoodtp7ht احتمالاً اگر حتی یک توسعه‌دهنده ساده نیز بوده باشید از لاگ‌ها در برنامه خود استفاده کرده‌اید. مثلاً به صورت بسیار ساده یک عبارت را در کنسول چاپ کرده‌اید تا از درستی کد خود مطمئن شوید. لاگ‌ها اما به این موارد محدود نمی‌شوند. لاگ‌های بسیار با انواع مختلف و ابزارهای متعددی برای مدیریت آن‌ها وجود دارد که در این نوشته با هم ‌آن‌ها را مرور می‌کنیم.تعریف لاگ (log)در دنیای کامپیوتر، لاگ یک فایل است که هر بار اتفاق خاصی در سیستم رخ می‌دهد، درست می‌شود. فایل‌های لاگ معمولاً دارای برچسب زمانی هستند و ممکن است هر چیزی که مربوط به سیستم‌عامل یا اپلیکیشن‌های نرم‌افزاری در پشت صحنه اتفاق می‌افتد را ثبت کنند. به طور کلی، لاگ فایل‌ها همه چیز از سرور گرفته تا شبکه و سیستم‌عامل و اپلیکیشن را ثبت می‌کنند تا در آینده بتوان از آن‌ها استفاده کرد.لاگ‌ها می‌توانند هر نوع اتفاق (event) را که بین کاربرهای مختلف صورت می‌گیرد یا در هنگام بکاپ گرفتن اتفاق می‌افتند یا در هنگامی که سیستم خطا می‌دهد و متوقف می‌شود را ثبت کنند. این لاگ‌ها می‌توانند پیام‌ها یا تراکنش‌ (‌transaction) ها یا درخواست‌های مختلفی باشند که در سیستم ثبت می‌شود.پس همان طور که دیدیم لاگ‌ها از تعریف سنتی‌ای که در ذهن توسعه‌دهندگان کم‌تجربه وجود دارد و به معنای لاگ مثلاً برای ارور است بسیار فراتر است و می‌تواند حوزه بزرگی از اتفاقات رخ‌ داده در سیستم نرم‌افزاری را در بر گیرد.انواع لاگبعضی لاگ‌ها توسط انسان می‌توانند خوانده شوند ولی بعضی دیگر قابل خواندن توسط انسان نیستند. از نمونه لاگ‌هایی که می‌توان نام برد لاگ‌های مربوط به تراکنش‌ها، ارورها و پیام‌ها است. پسوند فایل‌های لاگ می‌تواند .log یا .txt یا پسوندی دیگر باشد. اگر این لاگ‌ها توسط انسان قابل خواندن باشند، این لاگ‌ها در ویرایشگر متنی عادی، قابل دیدن و باز شدن است. البته بعضی لاگ‌ها ممکن است وابسته به نرم‌افزار خاصی باشد و در یک نرم‌افزار خصا باز شود.چرا لاگ و مدیریت لاگ مهم است؟لاگ‌ها برای پایش سیستم، مشاهده اتفاقات مختلف در سیستم، مشاهده خطاها، مدیریت خطاها و حل کردن مشکلات و بسیاری موارد دیگر قابل استفاده است. به همین خاطر باید تمامی لاگ‌های سیستم ثبت شود و در هنگام بروز اتفاقات غیرمترقبه استفاده شود. البته لاگ به منظور پایش مستمر سیستم نیز قابل استفاده است و نباید محدود به مواردی مانند لاگ‌ ارورها شود.مدیریت لاگ (log management) یعنی چه؟مدیریت لاگ به معنای مجموعه فعالیت‌ها و فرایند‌هایی که برای تولید، جمع‌آوری، پارس کردن، ذخیره کردن، آرشیو کردن و دور انداختن لاگ‌ها انجام می‌شود است. ابزارهای مدیریت لاگ برای هندل کردن و مدیریت تمامی این لاگ‌ها که توسط محیط سیستم، شبکه، نرم‌افزار و کاربر تولید شده استفاده می‌شود. باید دقت داشت که این لاگ‌ها فقط توسط sys admin ها استفاده نمی‌شود بلکه توسط توسعه‌دهندگان سیستم نرم‌افزاری نیز قابل استفاده است.تصویر ۱ - مراحل مختلف مدیریت لاگقسمت های مختلف مدیریت لاگدر تصویر ۱ به صورت خلاصه بعضی از مراحل مدیریت لاگ آورده شده است.جمع آوری لاگاین مورد مربوط به این است که لاگ‌ها چگونه جمع‌آوری و چگونه ذخیره شوند. از کجا و از کدام واحدهای نرم‌افزار لاگ جمع‌آوری شود و در کجا ذخیره شود. در این مرحله مهم است که اگر دیتای تکراری وارد لاگ شد، آن را نادیده و اضافی درنظر نگیرید و همه‌ اطلاعات مفید مرتبط با لاگ را حتماً جمع آوری کنید. البته این مورد نیاز به trade-off دارد و بستگی دارد چه مقدار از لاگ‌ها و کدامشان برای یک سیستم، حیاتی باشد.جمع کردن لاگ‌ها به صورت مجتمعدر هنگام جمع‌آوری لاگ‌ها باید دقت شود که تمام آن‌ها در یکجا به صورت مجتمع نگه داری شوند. البته این کار مخاطراتی نیز دارد مثلاً میزان حافظه مورد نیاز در این فضای مجتمع بسیار مهم است. اگر این حافظه کم باشد در واقع نمی‌توان لاگ‌ها را به صورت مرکزی و مجتمع ذخیره کرد. هم‌چنین در ذخیره سازی مجتمع لاگ‌ها باید دقت کرد که هر نوع لاگی ممکن است بیاید و همه لاگ‌ها از یک نوع نیستند پس باید در هنگام ذخیره کردن مجتمع به آن دقت شود.تصویر ۲ - نمایی از جمع‌‌آوری لاگ به صورت مجتمعذخیره و نگهداری لاگ‌ها به مدت طولانیمرحله بعدی در مدیریت لاگ‌ها، ذخیره‌سازی طولانی مدت و نگهداری آن‌هاست. ممکن است سوال پیش بیاید که این "طولانی" یعنی چه؟ به چه مدت باید لاگ را نگه داشت؟ در پاسخ باید به این نکته دقت شود که سازمان از چه به‌روش‌هایی استفاده می‌کند و لاگ‌ها تا چه مدت برای سازمان اهمیت دارند. پاسخ به این سوال می‌تواند کمکی برای تخمین مدت زمان نگهداری لاگ‌ها باشد.تغییر وضعیت لاگدر واقع این مرحله، مشکلات مرحله قبلی را حل می‌کند. در این مرحله تصمیماتی مبتنی بر اینکه لاگ‌ها پس از چه زمانی حذف یا به یک فضای دیگر متنقل شوند یا اینکه فشرده‌سازی شوند، گرفته می‌شود. بهتر است لاگ‌ها مهم به صورت تجمعی ذخیره شود و لاگ‌هایی که پس از مدتی اهمیت خود را از دست داده‌اند به فضایی دیگر منتقل شوند.آنالیز لاگآنالیز و تحلیل لاگ یکی از مهم‌ترین مراحل مدیریت لاگ است چرا که هر دیتایی زمانی معنی پیدا می‌کند و مهم می‌شود که روی آن تحلیلی انجام شود. ابزارهای مدیریت لاگ به صورت خودکار، تحلیل‌های پرکاربردی ارائه می‌دهند که در تحلیل آسان‌تر توسعه‌دهندگان یا مدیر پایش سیستم بسیار می‌تواند موثر باشد.سرچ و گزارش لاگهر ادمین و کسی که با مقدار زیادی داده کار کند حتماً به سرچ و گزارش‌گیری نیاز دارد. مثلاً باید بتواند لاگ‌های یک بازه زمانی خاص یا مربوط به جای خاصی از سیستم یا بر حسب مقدار فضایی که اشغال کرده را دریافت کند و بتواند به راحتی در میان متن آن‌ها جستجو کند. در اینجا نیز ابزارهای مدیریت لاگ، کمک بسزایی می‌کنند.ابزارهای مهم مدیریت لاگ‌هاابزار Sentryاین ابزار برای مدیریت، لاگ‌گرفتن و تجمیع این لاگ‌ها در نرم‌افزارهای به خصوص اپلیکیشن‌های وب و موبایل استفاده می‌شود. این ابزار به تیم نرم‌افزاری کمک می‌کند که هر اروری که توسط زیرساخت اپ یا توسط کاربر یا موارد دیگر رخ داده را پایش و بررسی کنند. با استفاده از sentry بعید است که یک ارور حیاتی یا لاگ مهم، بسیار دیر توسط تیم نرم‌افزاری شناسایی شود و می‌تواند در بررسی میزان سلامت نرم‌افزار نیز موثر باشد. این ابزار دارای SDK های مختلف است که در پلتفرم‌های مختلف می‌تواند استفاده شود. هم‌چنین می‌تواند این ابزار را در سرور شخصی راه اندازی و استفاده کرد. این ابزار تا 10000 ارور در ماه برای نرم‌افزارها رایگان است.ویژگی‌های مهم Sentry را می‌توان در موارد زیر خلاصه کرد:گزارش ارور و باگ به صورت مفصل و با پارامترهای مختلف لازم برای تشخیص باگرابط کاربری گرافیکی برای شناسایی منشا ارورها و اینکه چگونه و در کجا باید آن‌ها را برطرف کرد.فرستادن notification و هشدار معمولاً به صورت هفتگی یا روزانه به یک ایمیل مشخصگزارش ارور به صورت real time و بلافاصله پس از استقرار نرم‌افزارابزارهای ELKکلمه ELK مخفف سه واژه Elasticsearch و Logstash و Kibana (الستیک سرچ، لاگ‌استش و کیبانا) است. هر کدام از این سه ابزار متن‌باز را در ادامه توضیح می‌دهیم. این ابزارها جزو محبوب‌ترین ابزارهای موجود برای مدیریت و آنالیز لاگ‌ها و داده‌های مختلف هستند.ابتدا در مورد Logstash صحبت کنیم. Logstash یک ابزار رایگان و متن‌باز است که لاگ‌ها را جمع‌آوری می‌کند و سپس یک پردازشگر برای خواندن دیتا و لاگ‌های مختلف و ذخیره آن در یک یا چند فضا استفاده می‌شود. این ابزار دارای ورودی‌ها، فیلترها، کدک‌ها و خروجی‌های متعدد است که می‌تواند دیتایی که ممکن است قابل تحلیل نباشد یا غیرقابل خواندن باشد را به دیتایی خوانا و با ارزش بسیار بالا تبدیل کند. این ابزار دارای پلاگین‌های متعدد و قوی است که می‌تواند لاگ‌های مختلف و دارای تایپ‌های گوناگون را آنالیز و جمع‌آوری کند.این ابزار برای تحلیل دیتای غیرساخت‌یافته بسیار پرکاربرد است. اکنون به Elasticsearch بپردازیم. Elasticsearch محبوب‌ترین موتورجستجویی است که امروزه استفاده می‌شود و در واقع مهم‌ترین بخش و قلب ELK است. این ابزار هم یک ابزار رایگان و متن‌باز است که با جاوا نوشته شده است و دارای API های متعدد HTTP برای استفاده آسان‌تر جهت جستجوی سریع و کارا بین لاگ‌ها یا داده‌های مختلف است. این ابزار در زبان‌های مختلفی مانند پی‌اچ‌پی، پایتون و سی‌شارپ قابل استفاده است.در میان ابزارهای ELK، ابزار Elasticsearch برای ایندکس کردن و ذخیره داده استفاده می‌شود به نحوی که خواندن از آن بسیار سریع و با نتایج مرتبط باشد. در واقع Elasticsearch را می‌توان یک دیتابیس NoSql دانست.در هنگام استفاده از Elasticsearch می‌توان از کوئری‌های مختلف جهت ساخت، حذف، مشاهده و تغییر دیتا استفاده کرد که در این لینک می‌توانید خلاصه‌ای از آن‌ها را ببینید. هم‌چنین این ابزار دارای API های مختلف برای چاپ، کلاستر کردن، ایندکس کردن و سرچ کردن میان داده‌ها و لاگ‌ها است. برای این ابزار نیز مانند ابزار Logstash پلاگین‌های مختلفی وجود دارد که می‌توانند مواردی که توسط این ابزار قابل انجام هستند را گسترش دهند. به عنوان مثال برای گسترش API ها، مدیریت بهتر آن‌ها، مدیریت آسان‌تر امنیت لاگ‌ها و ایجاد هشدار و از این دست موارد، پلاگین‌های متعددی برای elasticsearch وجود دارد.در نهایت به ابزار Kibana می‌رسیم. از این ابزار جهت داشتن داشبورد و هم‌چنین تحلیل و مشاهده و visual کردن لاگ‌ها و داده‌ها در میان ابزارهای ELK استفاده می‌شود. این ابزار برای نمایش داده و لاگ بسیار زیاد، مناسب‌ترین گزینه است و می‌تواند الگوها و قسمت‌های مختلف داده را تحلیل کند و بر مبنای تحلیل خود آن را نمایش دهد. هم‌چنین با استفاده از آن می‌توانید عملیات جستجو را انجام دهید که در واقع از elasticsearch برای این عمل استفاده می‌کند. امکان نمایش نمودارها و گراف‌های مختلف و امکان شخصی‌سازی آن به فردی که وظیفه بررسی لاگ‌ها را دارد امکان بررسی بسیار خوب و بصری لاگ‌ها و داده‌ها را می‌دهد.تصویر ۳ - فرایند جمع‌آوری، ذخیره و نمایش دیتا در ELKباید توجه داشت که ابزارهای دیگری مانند splunk نیز وجود دارند که در زمینه مدیریت و سرچ و جمع‌آوری لاگ‌ها و دیتاها کاربردی است اما این ابزار به صورت متن باز در دسترس نیست.شرکت‌های ایرانی خدمت دهنده در حوزه مدیریت لاگشرکت آتینشرکت دانش بنیان آتین آتیه اندیش، مستقر در پارک علم و فناوری دانشگاه تهران، در سال 1396 فعالیت خود را به طور تخصصی در حوزه ارائه خدمات احراز هویت آغاز کرد. مدیریت لاگ‌ها و ممیزی‌ها یکی از چندین محصولات مختلف این شرکت است. از ویژگی‌های محصول ارائه شده در حوزه مدیریت لاگ توسط این شرکت، می‌توان به موارد زیر اشاره کرد:ثبت خودکار رفتارهای کاربران و رخدادهای مرتبطثبت وقایع امنيتی تعریف شده در برنامه‌های کاربردیامکان پیگیری وقایع و گزارش‌گیریامکان نظارت بر عملکرد کلیه کاربرانمحفوظ ماندن فعاليت كاربران از سايرين به جز مدیران سامانهشرکت پلتکو‏شرکت داده کاوان تصمیم یار خدمات مختلف نرم افزاری ارائه می‌دهد که یکی از آنها “پلتکو” نام دارد که “پلتفرم یکپارچه سازی و مدیریت وب سرویس” می‌باشد. در این پلتفرم تکنولوژی‌های قدیم و جدید مدیریت چرخه زندگی وب سرویس ادغام شده و به صورت یک خروجی واحد و کاملا شخصی سازی شده در اختیار سازمان‌ها قرار داده می‌شود. از مزایای نرم افزار مدیریت لاگ‌ها می‌توان به موارد زیر اشاره کرد:امکان ذخیره‌سازی یکپارچه به منظور سهولت در تجزیه و تحلیل لاگ‌هاقابلیت سیستم هشدار برای ارسال هشدارهای قابل تنظیم در زمان واقعی به محض وقوع مشکلبهبود امنیت در برابر حملات هکرها به دلیل نظارت و هشدارهای آنی نرم افزار عیب‌یابی بهتر به دلیل دریافت گزارش‌های مختلفامکان تجزیه فایل لاگ و تقسیم آن به اطلاعات کوچک‌تر برای ذخیره‌سازی آسان‌ترامکان آنالیز و تحلیل داده‌هامنابع و لینک‌های مفیدhttps://sematext.com/guides/log-management/https://logz.io/learn/complete-guide-elk-stack/https://sematext.com/guides/elk-stack/https://www.graylog.org/post/what-is-log-management-a-complete-logging-guide https://www.elastic.co https://authin.ir/log-management-and-auditing/ https://platco.ir/services/monitoring/log-manager/ این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است. Hamid Montazeri Hamid Montazeri Fri, 24 Dec 2021 23:18:32 +0330 https://virgool.io/@hamidhandid/bpms-tni2p85aszdg در این مقاله قصد داریم پس از تعریف اولیه‌ای از مفاهیم BPM و BPMS و بررسی مزایای استفاده از آن‌ها، به معرفی چند ابزار متن‌باز برای مدیریت فرایندهای کسب و کار بپردازیم و در نهایت معرفی اولیه‌ای از شرکت‌های ایرانی که در خدمات خود نرم‌افزارهای BPMS را ارائه می‌دهند داشته باشیم.معرفی BPMمدیریت فرآیندهای کسب و کار یا همان Business Process Management که به اختصار به آن BPM گفته می‌شود، یک روش ساختارمند است که با هدف بهینه‌تر کردن فرایندها در یک سازمان مورد استفاده قرار می‌گیرد. یک فرایند در واقع می‌تواند مجموعه‌ای از فعالیت‌ها تعریف شود که توسط افراد و سیستم‌ها به شیوه‌ای سازمان‌دهی شده برای رسیدن به یک هدف خاص صورت می‌گیرد. تمامی سازمان‌ها مبتنی بر انجام فرایند هستند، اما در تمامی مواقع این فرایندها نمی‌توانند به طرز بهینه‌ای مدیریت و سازمان‌دهی شوند. BPM شامل 5 مرحله مختلف است که به آن چرخه حیات فرایند نیز گفته می‌شود. در ادامه شرح مختصری از هر مرحله ارائه شده است.مراحل مختلف BPMاین مراحل عبارتند از:مدل‌سازی: مرحله اول، مدل کردن فرایند به کمک اشیای گرافیکی و تعریف ویژگی برای هر کدام از این اشیا است. برای مثال، می‌توان مشخص کرد که چه کسی باید در هر مرحله چه وظایفی را انجام دهد.شبیه‌سازی: مرحله دوم که می‌تواند اختیاری نیز باشد، برای تست کردن مدل‌سازی انجام شده در مرحله قبل است.اجرا: این گام به معنای اجرای فرایند در محیط کار واقعی است.نظارت: این مرحله برای ارزیابی نتایج حاصل از گام اجرای فرایند است که معمولاً شامل نمودارهای آماری است.بهینه‌سازی: هدف از انجام گام آخر، ایجاد تغییرات ضروری در روند فرایند برای بهبود زمان، هزینه و منابع است. تصمیم‌های گرفته شده در این فاز، بر اساس نتایج به دست آمده در مرحله نظارت انجام می‌شود.معرفی BPMSنرم‌افزارهای مدیریتِ فرایندهای کسب و کار که به اختصار BPMS نامیده می‌شود، این امکان را به شرکت‌ها می‌دهد که به صورت خودکار بتوانند فرایندهای کسب و کار خود را مدیریت کنند. تمامی مراحل چرخه حیاتِ فرایند که در بخش قبل معرفی شد، به کمک این نرم‌افزارها، به صورت اتوماتیک قابل انجام هستند. همچنین، لازم به ذکر است که نرم‌افزارهای مدیریت فرایند کسب و کار، شکل جدید و پیش‌رفته‌ای به خود گرفته‌اند با عنوان iBPMS معرفی می‌شوند. حرف i از کلمه intelligent می‌آید و به معنای هوشمند است.مزایای BPMSدر دنیای رقابتی امروز، هر کسب و کاری برای اینکه بتواند پایدار بماند و پیشرفت کند نیاز دارد تا حد امکان کارآمد باشد. انجام فرایندها به صورت دستی و سنتی باعث می‌شود که زمان و هزینه زیادی صرف شود و سرمایه صاحبان کسب و کار هدر رود. از این رو، می‌توان با بهره‌گیری از BPMS حالت خودکار و اتوماتیک به مدیریت انجام فرایندها بخشید و در زمان و هزینه صرفه‌جویی قابل توجهی کرد.استفاده از ابزارهای مدیریت فرایندهای کسب و کار مزایای زیادی به همراه دارد که برای نمونه، می‌توان به موارد زیر اشاره کرد:افزایش هوش عملیاتی: BPMS با کاهش کارهای تکراری و پیش پا افتاده که تلاش و زمان بسیاری صرف انجام آن‌ها می‌شود، به بهبود کارایی فرایندهای تجاری کمک می‌کند. همچنین، به دلیل فراهم کردن بینش‌های مختلف در مورد چالش‌ها و تنگناهای هر فرایند، این امکان را ارائه می‌کند تا بتوان با گرفتن تصمیم‌های آگاهانه، میزان آن‌ها را کاهش داد و در نتیجه هوش عملیاتی را بهبود بخشید.چابکی سازمانی: فرایندهای تجاری انعطاف‌ ناپذیر باعث می‌شود تا یک سازمان در یک فضای رقابتی ناسالم غرق شود. یکی از پایه‌ای ترین عوامل برای بقای هر کسب و کاری چابکی است. اگر یک سازمان نتواند به سرعت تغییر کند و به نیازهای متغیر مشتریانش پاسخ دهد، ممکن است آن‌ها را از دست بدهد. BPMS این امکان را فراهم می‌کند تا بتوان به سرعت تغییرات جدید را اعمال کرد و نیازهای مشتریان را بدون هیچ زحمتی در کوتاه‌ترین زمان بررسی کرد و پاسخ داد.کاهش ریسک: معمولاً به دلیل تغییرات به وجود آمده در محیط کسب و کار، شرکت‌ها مستعد خطاهای سازمانی هستند ک ممکن است بعضاً کارایی آن‌ها را تحت تاثیر قرار دهد. داشتن یک ابزار BPMS به مدیران این امکان را می‌دهد تا بتوانند نظارت همه جانبه‌ای بر امور داشته باشند و اگر در جایی مشکلی به وجود آمد، در کوتاه‌ترین زمان از آن مطلع شده و آن را برطرف نمایند.بهینه‌تر کردن فرایندها: ابزارهای BPMS این امکان را به مدیران می‌دهند تا با یک نگاه و مرور کلی مستندات تولید شده، فرایندهای منسوخ و ناکارآمد را تشخیص دهند و به بهینه‌سازی آن‌ها بپردازند. از آنجایی که با استفاده از این ابزارها عملیات ویرایش به سادگی قابل انجام است، در مدت زمان خیلی کوتاهی می‌توان تغییرات لازم را در هر فرایند اعمال کرد. همچنین، لازم به ذکر است که بعضی از ابزارهای BPMS با ارائه دادن قابلیت کشیدن و رها کردن (Drag And Drop) می‌توانند زمان ویرایش فرایندها را به حداقل برسانند.بهبود همکاری: بسیاری از کسب و کارها با مشکل برقراری ارتباط بین بخش‌ها یا دپارتمان‌های مختلف در سازمان مواجه هستند. عدم داشتن ارتباط موثر با تمامی بخش‌ها می‌تواند بر روند همکاری در یک سازمان تاثیرگذار باشد. با استفاده از ابزارهای BPMS، می‌توان مشخص نمود که هر فرایند با چه فرد یا افرادی در ارتباط است و این موضوع به سادگی برای همگان قابل مشاهده است. از این رو، اگر در جایی مشکلی به وجود بیاید و یا نیاز به تغییر باشد، می‌توان با دنبال کردن افراد مسئول در یک فرایند، آن‌ها را پیدا کرد.رضایت کارکنان: از آنجایی که به واسطه استفاده از ابزار BPMS جزییات فرایندها، نقش‌ها، اهداف و مسئولیت‌ها به وضوح قابل مشاهده است، سردرگمی‌های کمتری برای کارکنان پیش‌ خواهد آمد. به صورت کلی، افراد در محیط‌های کاری با ساختارهای شفاف رضایت کاری بیشتری دارند و کمتر وظایف محول شده خود را زیر سوال می‌برند. به مدد ابزار BPMS اسناد، گزارش‌ها و فرایندهای تولید شده شفاف‌تر و ساختارمندترخواهند بود. در نتیجه، تغییرات به وجود آمده در حین انجام یک پروژه برای دیگر کارکنان سازمان بیشتر قابل درک خواهد بود.یک ابزار BPMS چگونه کار می‌کند؟همانطور که در بخش‌های قبلی توضیح داده شد، هدف از BPMS خودکارسازی مدیریت فرایندهای سازمان است که به صورت سنتی و دستی انجام می‌شود. تمامی ابزارهایی که با این هدف طراحی شده‌اند مراحل مشابهی را دنبال می‌کنند که عبارتند از: تعریف فرایندها، خودکارسازی آن‌ها و تحلیل و ارزیابی فرایندها که در ادامه به شرح جزییات هر کدام خواهیم پرداخت.تعریف فرایندهاقبل از ایجاد هرگونه خودکارسازی و اتوماسیون گردش کار، نیاز است تا فرایندها مستندسازی شوند. به این منظور، نیاز است تا در ابتدا بتوان یک برنامه‌ریزی اولیه انجام داد و ظاهر فرایندها را مشخص کرد. به عبارتی دیگر، هر ابزار BPMS در مرحله نخست این امکان را به سازمان‌ها می‌دهد تا بتوانند از فرایندهای مورد نظر یک مدل اولیه ایجاد کنند. سپس، مدل‌های ساخته شده از فرایندها توسط ذی‌نفعان مورد بازبینی و بررسی قرار می‌گیرد تا این اطمینان حاصل شود که مدل تعریف شده ایرادی ندارد و دقیق است. مدل‌های ایجاد شده از فرایندها را می‌توان به روش‌ها و فرمت‌های مختلفی منتشر کرد. در برخی از ابزارها امکان شبیه‌سازی و تست سناریوهای فرایند نیز وجود دارد. این گام معادل با دو مرحله مدل‌سازی و شبیه‌سازی است که کمی پیش‌تر در چرخه حیات فرایند مورد بررسی قرار گرفت.خودکارسازی و اتوماسیون کردن فرآیندهاجنبه اصلی خودکارسازی فرایندها، محول کردن بسیاری از کارهای معمولی روزانه کارکنان به سیستمی است که با قوانین کسب و کار برنامه‌ریزی شده است. ایجاد کردن این خودکارسازی، شامل جمع‌ آوری تسک‌ها و مکانیزم‌های ورودی برای تقلید از رفتار یک فرایند سازمانی به شیوه سنتی است. به عبارتی دیگر، تمامی مراحلی که به صورت سنتی و دستی از پیش انجام میشد، با قوانین سازمانی تعریف شده به صورت خودکار در می‌آید. این مرحله معادل با گام اجرا در چرخه حیات فرایند است.تحلیل و ارزیابی نتایجابزارهای BPMS سطوح مختلفی از گزارش‌های مختلف را برای تحلیل و ارزیابی عملکردهای مختلف فرایندها ارائه می‌دهند. معمولاً این گزارش‌ها شامل شاخص‌های کلیدی عملکرد هستند و داده‌هایی را در مورد عملکرد اقدامات فردی، فرایندها، اعضای هر فرایند و... ارائه می‌دهند.تجزیه و تحلیل این گزارش‌ها می‌تواند گلوگاه‌های هر فرایند را شناسایی کند و فرصت‌هایی را برای بهبود مستمر فرایندها فراهم نماید. این گام معادل با دو مرحله نظارت و بهینه‌سازی است که پیش‌تر در چرخه حیات مورد بررسی قرار گرفت.معرفی ابزارهای متن‌باز مدیریت فرایندهای کسب و کارابزارهای مختلفی برای مدیریت فرایندهای سازمانی به وجود آمده اند که اساس کار همه آن‌ها یکسان است، اما در برخی از ویژگی‌ها و امکانات با هم متفاوت هستند. در ادامه، به معرفی سه ابزار مختلف متن‌باز در این حوزه پرداخته شده است.ابزار Adobe LiveCycleنرم‌افزار Adobe LiveCycle یک نرم‌افزار سازگار با Adobe Cloud است که می‌توان از آن در سه پلت‌فرم دسکتاپ، تلفن هوشمند و تبلت‌ استفاده کرد. از ویژگی‌های بارز این ابزار می‌توان به موارد زیر اشاره کرد: پردازش اطلاعات و حفاظت موثر از اطلاعات حساستوسعه برنامه‌ها بر اساس تکنولوژی مدلسازیفعال‌سازی سرویس‌های Messaging با عملکرد بالابهره‌مندی از توسعه لایه لایه‌ایمدیریت داده‌ها در حالت عدم ارتباط با شبکهAdobe LiveCycleابزار Alfrescoنرم‌افزار Alfresco Process Service یکی از ابزارهای سبک با موتور پردازش فوق سریع و توسعه یافته شده به زبان جاوا می‌باشد. این ابزار، مجموعه‌ای قوی از ابزارهای مختلف را برای کاربر نهایی ارائه می‌دهد و با طیف وسیعی از ابزارهای مختلف همچون Google Drive قابل ادغام است. نرم افزار Alfresco برای انجام کارهای مختلف فنی و غیر فنی، تجزیه و تحلیل و مدل‌سازی فرایندهای سازمانی بهینه شده است. این نرم‌افزار در واقع نسخه تجاری ابزار Activity است که رابط کاربری و گرافیک ضعیفی دارد.Alfrescoابزار ARIS Expressاگر جزو آن دست افرادی هستید که برای اولین بار می‌خواهید با ابزار BPMS کار کنید، نرم‌افزار ARIS Express یکی از ایده‌آل ترین گزینه‌های موجود است. مدل‌سازی در این ابزار به واسطه رابط‌های کاربری بصری صورت می‌گیرد. همچنین، آموزش‌هایی که شامل ساختارهای سازمانی، فرایندها، سیستم‌های کاربردی، داده‌ها و... است، در بخش ARIS Community به صورت رایگان در دسترس همگان قرار گرفته است. این ابزار از نمادهای مدل‌سازی مختلف مانند BPMN2، EPC و... نیز پشتیبانی می‌کند. همچنین، امکان خروجی گرفتن نمودارها و دیاگرام‌ها در این نرم‌افزار به فرمت‌های مختلفی همچون PDF، JPEG، PNG، EMF و ADF امکان‌پذیر است. مشابه ابزار Alfresco، این نرم‌افزار نیز مبتنی بر زبان جاوا توسعه داده شده است.ARIS Express شرکت‌های ارائه‌دهنده BPMS در ایراندر کشور خودمان نیز شرکت‌های متعددی وجود دارند که ابزار BPMS را ارائه می‌دهند. در ادامه به بررسی سه شرکت ایرانی با محصولی در حوزه مدیریت فرایندهای سازمان خواهیم پرداخت.شرکت آی کنشرکت آی کن در سال 1379 تاسیس شده است و اولین محصول آن با هدف مدیریت اسناد در سال 1381 به کاربران عرضه شده است. در سال 1390 اولین ابزار مدیریت فرایندهای کسب و کار به محصولات این شرکت اضافه شده است که سازمان‌ها را قادر می‌سازد تا نرم‌افزارهای مورد نیاز خود را در حوزه‌های مختلف بر اساس تحلیل و سلیقه خود با استفاده از یک محیط کاملاً گرافیکی استاندارد تولید کنند. از ویژگی‌های اساسی ابزار مدیریت فرایندهای کسب و کار می‌توان به موارد زیر اشاره کرد:سیستم کاملاً مبتنی بر Ajaxامکان استفاده از کنترل‌های پیشرفته مانند Chart، Tree View و Grid Viewامکانات امنیتی برای محدود کردن زمان و مکان دسترسی، رمزنگاری اطلاعات و...شرکت آرمان دنیای فناوری اطلاعات تتیسشرکت تتیس با هدف تسهیل و ساده‌سازی طراحی و پیاده‌سازی فرایندهای سازمانی، خدمات الکترونیک و زیرسیستم‌های درون سازمانی تحت وب تاسیس گردید. یکی از محصولات این شرکت سیستم مدیریت فرایند تتیس نام دارد که از ویژگی‌های منحصر به فرد آن می‌توان موارد ذیل را نام برد:امکان طراحی گزارش‌های جدولی و نموداری با استفاده از ابزار گزارش‌سازامکان تعریف نقش‌های مختلف و کارتابل متناسب با آن‌هاقابلیت طراحی انواع فرم‌های الکترونیکی مورد نیاز هر سازمانشرکت شماران سیستمشرکت شماران سیستم که در سال 1367 تاسیس شده است، سرویس‌های متعددی را در زمینه طراحی، تولید، استقرار و پیاده‌سازی نرم‌افزار جامع و یکپارچه در حوزه‌‏‏‏‏‏‏ها‏‏‏ی مالی، اداری، بازرگانی، تولید و مهندسی ارائه می‌دهد. یکی از محصولات این شرکت در خصوص مدیریت فرایندهای کسب و کار است که در ادامه برخی از ویژگی‌های آن را مورد بررسی قرار خواهیم داد.بهره گیری از بستر متن باز Open Source با استفاده از پلت فرم .netcore مایکروسافتعدم وابستگی به سیستم‌ عامل و امکان استفاده از تمامی سیستم‌های عامل خانواده لینوکسامکان استفاده از بانک‌های اطلاعاتی مختلف مانند Oracle و SQLسرعت بارگذاری بالای صفحات بر بستر وب و ویندوز با متد MVCموارد گفته شده، برخی از ویژگی‌های محصول ارائه شده توسط شرکت شماران سیستم است که باعث تمایز آن از دیگر محصولات رقبای داخلی در حوزه تولید نرم‌افزارهای مدیریت فرایندهای سازمانی می‌شود.منابع و لینک‌های مفید https://www.youtube.com/watch?v=ld6E_PJXg_k https://kissflow.com/workflow/bpm/what-is-bpms/ https://www.integrify.com/what-is-bpms/ https://solutionsreview.com/business-process-management/the-top-15-free-and-open-source-bpm-software/ https://ebpm.ir/10242 https://softwarehut.com/blog/business/benefits-of-bpm این مطلب، بخشی از تمرین‌های درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است. Hamid Montazeri Hamid Montazeri Fri, 24 Dec 2021 21:27:13 +0330 https://virgool.io/@hamidhandid/docker-orchestration-wrzif6eg1f04 اگر یک فرد فعال در حوزه نرم‌افزار باشید حتماً می‌دانید که یکی از ترندهایی که از حدود ده سال پیش بسیار محبوب شده است مبحث کانتینرها و داکر است. در این نوشته می‌خواهیم به طور ساده بگوییم که یک Container چیست و Container Orchestration یا همان سازماندهی Container ها به چه معناست.کانتینر (Container) چیست؟کانتینر (Container) یک واحد نرم‌افزاری است که کد و تمام وابستگی‌های آن را در خود جای داده است. در واقع کانتینر یک بسته سبک‌وزن و مستقل نرم‌افزار است که می‌توان آن را اجرا کرد و تمام وابستگی‌ها را نیز در خود جای داده و از محیط بیرون خود ایزوله است.به این علت که کانتینرها ایزوله هستند می‌توان کدها و نیازمندی‌های هر بخش از کد (مثلاً هر میکروسرویس) را در یک کانتینر توسعه و نگهداری کرد. با وجود کانتینر دیگر نیازی به نصب سنگین پکیج‌هایی که لازم است روی سیستم اصلی نیست و داخل خود کانتینر تمام وابستگی‌های آن بسته نرم‌افزاری وجود دارد. بنابراین می‌توان کدها را بین سیستم‌های مختلف و محیط‌های با شرایط متفاوت و زیرساخت‌های گوناگون جابجا کرد و مشکلی پیش نیاید و بدون ایراد آن بسته نرم‌افزاری اجرا شود. کانتینرها تا قبل از پدید آمدن Docker نیز وجود داشتند اما این داکر بود که در واقع مفهوم کانتینرها را متحول کرد.تصویر 1 - ساختار Container هاچرا باید از کانتینرها استفاده کرد؟به صورت سنتی وقتی یک کد را یک تیم نرم‌افزاری می‌خواست بین دو محیط جابجا کند به علت کانفیگ متفاوت سیستم یا سرورها یا اینکه برخی پکیج‌ها روی یکی نصب بود و روی دیگری نبود، مشکلاتی به وجود می‌آمد. با آمدن کانتینرها یک زیرساخت نسبتاً سبک و ایزوله برای توسعه یک قسمت از نرم‌افزار به همراه وابستگی‌های لازم آن بخش فراهم شد. همه پروسه‌های یک بخش از نرم‌افزار مانند توسعه، نصب پکیج‌ها و وابستگی‌های مورد نیاز، تست و فرایند استقرار آن بخش توسط کانتینری که آن بخش را دارد قابل انجام است. هم‌چنین با استفاده از کانتینرها اگر به هر دلیلی یکی از این کانتینرها دچار مشکل شود، تقریباً به بقیه کانتینرها آسیبی نمی‌رسد و دچار خطا نمی‌شوند. به همین دلایل است که امروزه معمولاً در همه تیم‌های نرم‌افزاری استفاده از کانتینرها به یک فرهنگ متداول تبدیل شده است.تفاوت Container با Virtual Machineتا اکنون فهمیدیم که یک کانتینر چیست. حال ممکن است برای هر شخص در حوزه نرم‌افزار که به تازگی با این مفهوم آشنا شده سوال پیش بیاید که مگر قبلاً ماشین‌های مجازی (Virtual Machines) یک سیستم‌عامل مستقل نداشتند که میشد پکیج‌های مختلف روی آن به طور مستقل نصب کرد و سپس برای بیلد و استقرار نرم‌افزار نیز از آن استفاده کرد. پس کانتینرها چه مفهوم متفاوتی دارند؟برای پاسخ به این سوال باید کمی به مفاهیم فنی کانتینرها وارد شویم. همان طور که پیش از این گفتیم، کانتینرها یک بسته نرم‌افزاری شامل وابستگی‌های خود بودند که می‌توانستند مستقلاً اجرا شوند. تفاوت اصلی کانتینرها با ماشین مجازی در اینجاست که تعداد زیادی کانتینر می‌توانند در یک سیستم عامل و یک ماشین اجرا شوند. در واقع کانتینرهایی که در یک سیستم‌عامل در حال اجرا شدن هستند هسته (Kernel) سیستم عامل را با دیگر کانتینرهای موجود در آن ماشین، به اشتراک می‌گذارند. این کانتینرها به صورت فنی مانند پروسه (process) های مستقل از هم در فضای کاربر (user space) هستند. کانتینرها فضای بسیار کمی در حد چند ده مگابایت به خود اختصاص می‌دهند که در مقایسه با فضایی که VM ها نیاز دارند بسیار کمتر است.از طرف دیگر VM ها یک ماشین مجازی هستند که هر یک سیستم‌عامل مخصوص به خود را دارند و در واقع این قابلیت را به توسعه‌دهندگان می‌دهند که یک سرور فیزیکی خود را به چندین سرور مجازی تبدیل کنند. هر یک از VM ها یک سیستم‌عامل کامل مخصوص به خود، اپلیکیشن و وابستگی‌ها و کتابخانه‌های مخصوص به خود را دارند. VM ها فضایی در حد چندین گیگابایت نیاز دارند.همان‌طور که تفاوت کانتینر با ماشین مجازی را دیدیم، باید بدانیم که به علت سرعت بیشتر به علت عدم نیاز به boot شدن سیستم‌عامل (چون سیستم‌عامل مخصوص به خود ندارند اصلاً!)، مقدار فضای مورد نیاز کمتر و کارایی بهتر و راحت‌تر و سبک‌تر، اکنون کانتینرها از ماشین‌های مجازی محبوب‌تر و پراستفاده‌تر هستند. البته باید دقت کرد که ماشین‌های مجازی و کانتینرها می‌توانند در کنارهم استفاده شوند.تصویر 2 - نمایی از ماشین‌های مجازیدر ادامه به برخی مزایای کانتینرها اشاره می‌کنیم که باعث محبوب شدن آن شده‌اند:چابک بودن و کارایی بالاتوسعه‌دهندگان وقتی نرم‌افزار خود را در یک کانتینر به صورت مستقل توسعه می‌دهند در واقع مزیت کاهش هزینه‌های استقرار (deploy) نرم‌افزار خود روی سرورهایی که در اختیار دارند را به علت عدم وابستگی به واحدی دیگر و عدم داشتن دغدغه پلتفرم مناسب به دست می‌آورند. این مزیت کمک می‌کند که کارایی و چابکی تیم توسعه بالاتر برود و ارتباط راحت‌تری با تیم DevOps داشته باشند.قابل حمل و سبک بودنکانتینرها دارای یک فرمت استاندارد برای پکیج کردن یک نرم‌افزار و قرار دادن تمامی وابستگی‌ها در آن هستند. هم‌چنین این کانتینرها به صورت مستقل قابل اجرا، تست و استقرار هستند که باعث فراموشی مشکل سنتی اجرا نشدن بخشی از نرم‌افزار روی سروری دیگر شده‌اند. هم‌چنین با استفاده از کانتینرها دیگر پلتفرم و فضای ابری خاصی مورد نیاز نیست و قابل اجرا روی سیستم‌های گوناگون هستند.قابلیت اسکیل پذیری با سرعت بالا و نگهداری آسانبه این خاطر که کانتینرها مانند VM ها سنگین نیستند و نیاز به سیستم‌عامل مستقل ندارند، تعداد زیادی کانتینر می‌توانند صرفاْ روی یک ماشین، سیستم یا زیرساخت قابل اجرا باشند. این سبکی به توسعه‌دهندگان و افراد مرتبط با نرم‌افزار در حال توسعه کمک می‌کند که با سرعت بالایی بتوانند نرم‌افزار را اسکیل کنند یا حتی از اسکیل آن بکاهند.امنیتچون کانتینرها واحدهایی مستقل هستند که از محیط پیرامون خود ایزوله‌اند می‌توان امنیت بیشتری نسبت به VM ها برای آن‌ها متصور بود.سازماندهی کانتینرها (Container Orchestration) یعنی چه؟سازماندهی یا ارکستراسیون کانتینرها یعنی فرایند مدیریت، اسکیل پذیری، نگهداری و استقرار کانتینرها خودکار سازی شود. برای این منظور ابزارهای مختلفی که به آن‌ها سازمانده (orchestrator) گفته می‌شود مانند Kubernetes و Docker Swarm وجود دارد.به علت این که کانتینرها سبک هستند تعداد زیادی از آن‌ها می‌توانند روی یک سیستم نصب شوند که اگر این فرایند به صورت دستی انجام شود، در سیستم‌های بزرگ به علت پیچیدگی‌های متعدد، نگهداری و مدیریت این کانتینرها برای تیم‌های مختلف مخصوصاً تیم DevOps بسیار مشکل خواهد شد. این جاست که ابزارهایی مانند Kubernetes و Docker Swarm کمک می‌کنند که مدیریت این کانتینرها به صورت دستی انجام نشود بلکه خودکار سازی مدیریت و پیکربندی آن‌ها صورت پذیرد. البته باید دقت کرد که Orchestration می‌تواند شامل خودکارسازی چندین بخش باشد نه فقط خودکار سازی یک بخش و تفاوت آن با خودکارسازی صرف، در این موضوع است.مزایای استفاده از Container Orchestrationهمان طور که دیدیم در سیستم‌های بزرگ تقریباً بدون یک orchestrator نمی‌توان انواع کانتینرها را مدیریت و نگهداری کرد. اکنون می‌خواهیم بگوییم چرا باید از ابزارهایی مانند Docker Swarm استفاده کنیم.عملیات‌های ساده شدهمهم‌ترین دلیل و سود استفاده از ابزارهای مربوط به سازماندهی کانتینرها، همین ساده‌شدن عملیات‌هاست که بدون استفاده از آن‌ها پس از اضافه شدن هر کانتینر مقداری پیچیدگی به نرم‌افزار اضافه شده که ممکن است غیرقابل کنترل شود.قدرت تحمل و تاب آوریابزارهای سازماندهی کانتینرها می‌توانند به صورت اتوماتیک یک کانتینر را دوباره راه‌اندازی یا آن را اسکیل کنند.امنیت بیشتراین ابزارها می‌توانند به دلیل کاهش دخالت انسان در فرایند مدیریت داکرها از خطاها جلوگیری یا پیشگیری کنند و در واقع امنیت مضاعفی برای کانتینرها فراهم آورند.معرفی ابزارهای پیکربندی کانتینرها (Container Orchestration Tools)در این بخش با دو تا از مهم‌ترین ابزارهای مرتبط با سازماندهی و پیکربندی کانتینرها آشنا می‌شویم. اول درباره Kubernetes صحبت می‌کنیم و بعد سراغ Docker Swarm می‌رویم.ابزار Kubernetesابزار kubernetes یک ابزار متن‌باز برای orchestration کانتینرهاست که با استفاده از آن می‌توان کانتینرها را مدیریت و اسکیل کرد و استقرار داد. به این ابزار به صورت مخفف k8s نیز گفته می‌شود.این ابزار وقتی به کار می‌آید که تعداد زیادی کانتینر که ممکن است در سرورهای مختلفی مستقر باشند داریم و می‌خواهیم آن‌ها را مدیریت کنیم. به این منظور kubernetes به توسعه‌دهندگان و متخصصان DevOps، یک API ارائه می‌دهد که می‌توان با آن کنترل کرد که هر کانتینر چگونه و کجا ران شود.این ابزار با توجه به میزان منابع موجود در هر سرور و اینکه هر کانتینر به چه میزان از منابع احتیاج دارد، آن‌ها را بین سرورها و ماشین‌های مجازی مختلف پخش و پیکربندی می‌کند. به گروهی از کانتینرها در ادبیات kubernetes، نام pod داده می‌شود که در واقع واحد عملیاتی برای kubernetes است. هم‌چنین ابزار kubernestes می‌تواند به صورت اتوماتیک مواردی مانند میزان منابع اختصاص داده‌شده و load سرورها را track می‌کند و سپس می‌تواند بر این اساس عملیات پیکربندی کانتینرها را انجام دهد. هم‌چنین kubernetes به صورت اتوماتیک میزان سلامت هر منبع را چک می‌کند و می‌تواند مثلا با restart کردن یک کانتینر سلامت آن را به حالت عادی برگرداند.ابزار Docker Swarmاین ابزار نیز مانند kubernetes برای مدیریت و پیکربندی و اسکیل container هاست. این ابزار برای موتور داکر نوشته شده و API مخصوص به خود را دارد. به صورت بسیارعالی با docker compose یکپارچه می‌شود و تمام امکاناتی که در کانتینرهای داکر وجود دارد در Swarm نیز قابل استفاده است. البته کمی کاستوم کردن آن ممکن است مشکل زا باشد و همه‌ امکانات kubernetes را نیز ندارد. مثلاً docker swarm به طور پیش‌فرض امکانات پایش (monitoring) اتفاقاتی که می‌افتد را ندارد و باید از طریق کتابخانه‌ها این مورد به docker swarm اضافه شود در حالی که kubernetes این امکانات را داراست.معرفی شرکت‌های ارائه دهنده خدمات کانتینر و داکر در ایرانشرکت‌هایی مانند فندق، ابرآروان و ایران‌ هاست خدمات Docker ارائه می‌دهند.شرکت فندق با ارائه یک زیرساخت و سرویس‌های مدیریت شده به کاربران خود امکانات کامل و در عین حال ساده برای مدیریت می‌دهد.شرکت ابرآروان نیز با ارائه سرویس‌های ابری مبتنی بر داکر و کانتینرها، به استارتاپ‌ها و صاحبان کسب و کار اجازه می‌دهد که سیستم‌های امن و سریع مبتنی بر کانتینر ابری داشته باشند.شرکت ایران هاست نیز داکر اختصاصی ارائه می‌دهد که شامل اکثر image ها و برنامه‌های معروف و کاربردی است.منابع و لینک‌های مفیدhttps://www.docker.com/resources/what-containerhttps://azure.microsoft.com/en-us/overview/what-is-a-containerhttps://www.alibabacloud.com/knowledge/what-is-containerizationhttps://docs.docker.com/get-started/orchestration/https://azure.microsoft.com/en-us/topic/what-is-kubernetes/https://www.redhat.com/en/topics/containers/what-is-container-orchestration https://iranhost.com/blog/iranhost-docker/#gref https://www.fandogh.cloud/ این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است. Hamid Montazeri Hamid Montazeri Fri, 24 Dec 2021 20:04:01 +0330 https://virgool.io/@hamidhandid/continuous-delivery-xenlzym6yaaj اگر تا به حال در تیم نرم‌افزاری یا در تیم DevOps یک شرکت مشغول به کار بوده باشید یا اینکه حتی یک فرد علاقه‌مند به حوزه‌های مرتبط با نرم‌افزار باشید حتماً عباراتی مانند CI و CD به گوش شما خورده است. در این نوشته می‌خواهیم به بررسی بخش CD یا همان Continuous Delivery بپردازیم.تحویل مستمر (Continuous Delivery) چیست؟برای پاسخ به این سوال ابتدا باید یک مرحله به عقب برگردیم و بدانیم CI/CD چیست. ابتدا تعریف CI را مرور می‌کنیم. CI یا Continuous integration در واقع ادغام تغییرات کد نرم‌افزار به صورت مستمر در یک ریپازیتوری است. این عمل معمولاً سعی می‌شود که به صورت خودکار انجام شود. در عملیات CI معمولاً build شدن کد و اجرای تست‌ها و ادغام کد صورت می‌پذیرد. در واقع CI یک مکانیزم برای سازگاری مستمر میان تغییرات گوناگونی که توسط برنامه نویسان مختلف یک سیستم نرم‌افزاری انجام می‌شود است. هم‌چنین در این فرایند با استفاده از تست‌های مختلف طراحی شده مشکلات پیش آمده در ادغام کدها شناسایی می‌شود.تعریف Continuous Delivery و تفاوت آن با Continuous Deploymentحال می‌توانیم به تعریف CD یا همان Continuous Delivery یا همان تحویل مستمر بپردازیم. تحویل مستمر یعنی به صورت مستمر کدها و سامانه نرم‌افزاری بتواند منتشر شود. این انتشار ممکن است که صرفاً در دسترس تیم فنی یا تیم‌های دیگر مرتبط با محصول باشد. فرایند تحویل مستمر پس از CI صورت می‌گیرد.اکنون بیایید با مفهوم Continuous Deployment آشنا شویم. Continuous Deployment پس از Continuous Delivery یا همراه با آن انجام می‌شود. Continuous Deployment به معنی استقرار مستمر است یعنی پس از اینکه CI انجام شد و پس از آن در ریپازیتوری اصلی انتشار آن نسخه از برنامه که بیلد و تست شده صورت گرفت، این نرم‌افزار منتشر شده در سمت مشتریان اصلی استقرار یابد و این مشتریان بتوانند از نرم‌افزار منتشر شده استفاده کنند.معمولاً فرایندهای Continuous Delivery و Continuous Deployment آن قدر به‌هم‌تنیده و دارای مشترکات زیاد و مکمل هم هستند که خیلی اوقات یک فرایند در نظر گرفته می‌شوند. در تصویر ۱ فرایندهای CI/CD به خوبی به تصویر کشیده شده‌اند.تصویر ۱ - فرایندهای CI/CDمفهوم CI/CD pipeline یعنی چه؟خط لوله یا pipeline در CI/CD مجموعه‌ای از قدم‌ها است که باید برای انتشار و رسیدن نسخه جدید نرم‌افزار انجام شود. در واقع این pipeline به تیم نرم‌افزاری کمک می‌کند که فرایند انتشار و استقرار یافتن نرم‌افزار را پایش کنند و هم‌چنین بتوانند این فرایند را به طور خودکار انجام دهند. امروزه تقریباً اکثر شرکت‌های نرم‌افزاری این فرایندها را با استفاده از pipeline به صورت خودکار انجام می‌دهند.در مراحل مختلف تحویل مستمر در pipeline ابتدا در مرحله CI نرم‌افزار build و test می‌شود. سپس در مرحله Continuous Delivery نرم‌افزار داخل ریپازیتوری منتظر می‌شود و در نهایت با Continuous Deployment این نرم‌افزار منتشر شده deploy شده و به دست مشتری می‌رسد. البته ممکن است مراحلی مانند ارزیابی‌ (Validation) های مختلف نیز در هر یک از این مراحل یا پس از این مراحل انجام شود.تصویر ۲ - خط لوله CI/CDفرایند تحویل مستمر در کدام بخش از تیم نرم‌افزاری انجام می‌شود؟معمولاً فرایندهای مربوط به CI و CD که شامل تحویل مستمر هم می‌شود در تیم DevOps یک شرکت انجام می‌شود. کلمه DevOps از دو بخش Dev یعنی توسعه و Ops یعنی عملیات تشکیل شده است. همان طور که از این واژه پیداست، وظیفه تیم DevOps به طور کلی این است که با استفاده از فرایندها، متدها و ابزارهایی که برای یکپارچگی میان تیم توسعه، تیم عملیات و بررسی کیفیت و مشتری استفاده می‌شود، به طور مستمر محصول را به مشتریان عرضه کند. به صورت سنتی قبلاً تیم‌های توسعه و عملیات جدا بودند که امروزه لغت DevOps به ما این منظور را می‌رساند که تیم‌ها به تیم‌هایی دارای چندین تخصص و با مهارت‌های متفاوت تبدیل شده‌اند. امروزه در بسیاری از تیم‌ها دیگر تیم DevOps به صورت جدا وجود ندارد بلکی مختصصان DevOps در تیم اصلی توسعه نرم‌افزار نیز حضور دارند. فرایند تحویل مستمر به عنوان یکی از فرایندهایی که متخصصان DevOps انجام می‌دهند معمولاً توسط این تیم خودکارسازی می‌شود. این تیم هم‌چنین وظیفه دارد که اپلیکیشن به طور مداوم، سریع و مطمئن build و سپس منتشر شود و پس از آن استقرار یابد.البته ممکن است تیم DevOps در انجام فرایند نصب و تحویل مستمر دچار چالش‌هایی مانند سرعت پایین نصب و استقرار، کانفلیکت‌های زیاد، وابستگی به یک پلتفرم خاص جهت انجام فرایندها، عدم خودکار بودن بخشی از فرایند و مواردی از این دست شود که نسبت به مزایایی که استفاده از آن دارد قابل چشم‌پوشی است و می‌تواند با رعایت برخی نکات، این مشکلات را نیز برطرف کرد.مزایای استفاده از تحویل مستمراکنون که فهمیدیم Continuous Delivery به چه معناست باید به این فکر کنیم که این فرایند چرا انجام می‌شود و چه مزایایی برای یک تیم نرم‌افزاری دارد. در ادامه چند مورد از این مزایا را با هم مرور می‌کنیم.مصیبت انتشار نسخه جدید به صورت سنتیدر فصل ۱۴ از کتاب Clean Architecture، آقای Robert C. Martin که معروف به عمو باب یا Uncle Bob است در مورد سندرومی صحبت می‌کند که در فرایند انتشار و استفاده مشتری از نسخه جدید نرم‌افزار صورت می‌گرفت. به گفته او همه اعضای یک تیم باید دور هم آخر هفته یا آخر ماه یا هر چند ماه یکبار جمع می‌شدند و طی یک یا چند روز فرایند انتشار نسخه جدید را به صورت کاملاً دستی انجام می‌دادند. این توسعه‌دهنده‌ها و افراد مرتبط با نرم‌افزار، نه تنها باید کارهای مربوط به توسعه خود را متوقف می‌کردند بلکه حتی مجبور می‌شدند بیش از یک روز در شرکت خود بمانند تا نسخه جدید منتشر شود و باگ‌های بزرگ آن یا مشکلات مشتریان با نسخه جدید برطرف شود.صرفه جویی در زمان و وقت تیم نرم‌افزار و کاهش خطا در انتشار آنهمان‌طور که دیدیم فرایند انتشار نرم‌افزار و تحویل آن قبلاً کار آسانی نبوده و پر از مخاطرات مختلف برای یک تیم نرم‌افزاری بوده است. فرایند تحویل مستمر این مشکل را تا حد خوبی کم می‌کند تا حدی که امروزه در هر روز یا هر هفته ممکن است نسخه‌های مختلف برنامه منتشر شوند و به دست مشتری برسند و همزمان تیم توسعه نیز در حال توسعه امکانات برنامه است و مشکلی برای او پیش نمی‌آید و فرایند توسعه متوقف نمی‌شود. هم‌چنین وقت زیاد و بی‌استفاده‌ای از تیم مرتبط با انتشار نسخه جدید محصول گرفته نمی‌شود و در زمان آن‌ها صرفه‌جویی شده و در بهره‌وری‌شان بهبود قابل توجهی رخ می‌دهد. هم‌چنین ریسک انتشار محصول بسیار کاهش می‌یابد چون فرایند به صورت اتوماتیک انجام شده و احتمال خطای دستی در آن وجود ندارد.خودکار شدن فرایند انتشار نرم‌افزار نکته مهم در فرایند تحویل مستمر این است که این فرایند امروزه خودکارسازی (Automate) می‌شود. بدون اینکه نرم‌افزار به صورت سنتی منتشر شده و پس از آن به صورت دستی نسخه جدید نرم‌افزار در production مستقر شود تا مشتری‌ها بتوانند استفاده کنند، به طور خودکار فرایند انجام می‌شود و خطاهای احتمالی در این پروسه به مقدار قابل توجهی کاهش پیدا می‌کند. بازخورد سریع‌ و راحت‌تر کاربر و پاسخ سریع به نیازهای اواز جمله مواردی که در تحویل مستمر کمک می‌کند بازخورد راحت‌تر و بیشتر مشتری و کاربر نرم‌افزار است. چون به صورت مستمر و مداوم فرایند تحویل و انتشار انجام می‌شود، کاربر راحت‌تر و سریع‌تر تغییرات خواسته‌شده را مشاهده می‌کند و در صورتی که باگی وجود داشته باشد، امکان جدیدی در برنامه بخواهد یا اینکه منتظر یک امکان جدید باشد بسیار سریع می‌توان به نیازش پاسخ داد و از او بازخورد گرفت. البته همیشه لازم نیست به همه‌ کاربران یک نسخه جدید را انتشار داد. گاهی اوقات نیاز است که اگر امکان و فیچر جدیدی در برنامه داریم، به بخشی از کاربران آن را ارائه دهیم تا نتیجه و بازخورد آن را از سوی آنان ببینیم و تحلیل کنیم و پس از آن در مورد ارائه آن امکان به تمام مشتریان تصمیم‌گیری کنیم.نرم‌افزار بهتر و کاهش هزینههر نرم‌افزاری که فرایند تحویل مستمر را به صورت خودکار انجام‌دهد می‌‌تواند حتی در تیم‌های کوچک نرم‌افزاری بدون دغدغه و هزینه‌های بیهوده جهت انتشار نسخه جدید به کار خود ادامه دهد. هم‌چنین این نرم‌افزار در پروسه انتشار تست شده و پس از آن انتشار یافته پس قسمتی از باگ‌های آن در زمان تست و قبل از انتشار مشخص می‌شود. هزینه تیم نرم‌افزار نیز کاهش می‌یابد چون وقت کمتری از تیم نسبت به زمانی که دستی این فرایند را انجام می‌دادند گرفته می‌شود و تیم مرتبط با نرم‌افزار و انتشار آن می‌توانند به موارد مهم‌تر رسیدگی کنند و توسعه را ادامه دهند.کمک به چابک بودن تیم نرم‌افزاریبا استفاده از تحویل مستمر، به تیم‌های چابک (Agile) کمک می‌شود که به صورت سریع‌تر، چابک‌تر‌، کم‌خطاتر و کم‌هزینه‌تر نرم‌افزار را منتشر کنند. بخش‌های مختلف یک تیم‌ نرم‌افزاری چابک، دیگر نباید دغدغه انتشار یک نسخه جدید را به صورت سنتی داشته باشد و باید بداند ممکن است یک فیچر بسیار سریع توسعه و سپس به مشتری عرضه شود.ابزارهای متن باز پرکاربرد در فرایند تحویل مستمردر این بخش به معرفی چند ابزار متن‌باز پرکاربرد در حوزه تحویل مستمر می‌پردازیم. معمولاً ابزارهای حوزه CI و CD جدا نیستند و هر دو فرایند CI و CD در ابزاری مشترک انجام می‌شود. در ادامه برخی از این ابزارها را مرور می‌کنیم.ابزار Jenkinsاین ابزار متن‌باز با زبان جاوا نوشته شده است. این ابزار یکی از بهترین و اولین ابزارهایی بود که فرایند build و تحویل مستمر را ساده‌تر کرد. این ابزار می‌تواند به صورت real time تست‌ها را انجام دهد و سپس خطاها را گزارش کند تا توسعه‌دهندگان مشکلات کد و برنامه خود را هر چه سریع‌تر متوجه شوند. Jenkins در سیستم‌عامل‌های ویندوز، مک‌او‌اس و سیستم‌های دیگر مبتنی بر Unix مانند لینوکس قابل استفاده است. یکی از مزایای Jenkins پشتیبانی آن از پلاگین‌های مختلف است که کار انتشار نسخه جدید برنامه را ‌آسان‌تر می‌کنند. مزایای Jenkins را می‌توان در موارد زیر خلاصه کرد:نصب و آپدیت راحت در سیستم‌عامل‌های مختلفرابط کاربری راحت و مورد پسند کاربرقابل توسعه و گسترش با استفاده از پلاگین‌های ارائه شده توسط کامیونیتی آنکانفیگ آسان محیط با رابط کاربریپشتیبانی از build های توزیع شدهپشتیبانی از نوتیفیکشنو ...ابزار Circle CIاین ابزار یکی دیگر از ابزارهای مورد استفاده در حوزه CI و CD است که می‌تواند در محیط‌های مختلف اجرا شود. توسعه‌دهندگان با استفاده از این ابزار قدرتمند و API ای که خود CircleCI می‌دهد به قابلیت‌های این ابزار می‌تواند بیفزایند. برخی قابلیت‌های ابزار CircleCI را به صورت مختصر در زیر می‌آوریم:توانایی انتخاب محیط (Environment) برای build شدن نرم‌افزارپشتیبانی از اکثر زبان‌های برنامه نویسیپشتیبانی از داکر و کانتینرهاکنسل‌کردن اتوماتیک فرایند CI و CD قبلی به محض trigger شدن یک فرایند جدیداجرای تست‌ها در container های جدا و افزایش سرعت build به همین منظورامکان کش کردن و موازی‌سازی فرایندها به سادگی برای کارایی سریع‌ترامکان ایجاد دسترسی صرفاً برای ادمین‌های خاص برای تغییر موارد حساس در پروژهو ...ابزار Gitlab CIامروزه در بسیاری از شرکت‌ها از ابزار Gitlab CI استفاده می‌شود چرا که سورس‌کد بعضی سامانه‌ها در ریپازیتوری خصوصی در گیت‌لب است و به منظور یکپارچه بودن ابزار مورد استفاده در بخش ادغام و نصب و تحویل مستمر (CI/CD) هم از ابزار مخصوص گیت‌لب استفاده می‌شود. این ابزار دارای محیط‌ها، pipeline ها و امکان اجرای تست‌ها و داشتن Variable در بخش CI/CD است و هم‌چنین بسیاری امکانات دیگر نیز دارد. یکی از مهم‌ترین ویژگی‌های آن استفاده از Gitlab Runner است که با آن می‌شود یک Runner مثلاً روی سرور شخصی راه‌اندازی و استفاده کرد و آن را با ابزار Gitlab CI یکپارچه نمود.شرکت‌های ارائه‌دهنده خدمت تحویل مستمر (Continuous Delivery) در ایراندر این بخش سه شرکت فعال در حوزه تحویل مستمر در ایران را معرفی می‌کنیم.سرویس ابری لیارااین سرویس با پشتیبانی کامل از سیستم‌عامل‌های مختلف و توانایی ادغام با Gitlab یا Github و استفاده از تمامی امکانات آن‌ها یکی از سرویس‌هایی است که کسب و کارهای ایرانی می‌توانند برای فرایند نصب و تحویل مستمر از آن استفاده کنند. طبق گفته این شرکت در سایت خود، تمامی سرویس‌ها و قابلیت‌های این سرویس ابری، به صورت آنی قابل راه‌اندازی است و استقرار نرم‌افزار بدون هر گونه اخلال به دلایلی مانند تحریم اتفاق می‌افتد. هم‌چنین این سرویس امکان بازگشت آسان به نسخه‌های قبلی شما را به راحتی می‌دهد و با پشتیبانی از خط فرمان و گزارشات و لاگ‌های مختلف به مدیریت فرایند CI و CD نیز کمک زیادی می‌کند.سرویس کانتینر ابری ابرآروان با استفاده از سرویس ابری ابرآروان، تمام نیازمندی‌های زیرساختی مانند کنترل مداوم فرایند نصب و تحویل و استقرار در دسترس کاربر خواهد بود و نرم‌افزار مطابق با پیکربندی توسعه‌دهندگان build و مستقر می‌شود. هم‌چنین امکان افزایش منابع سخت‌افزاری به سادگی در این پلتفرم وجود دارد تا فرایند CI/CD سریع‌تر شود. با استفاده از سرویس ابری ابرآروان، مراحل build و deploy توسط خود ابرآروان و با استفاده از container ها می‌تواند انجام شود و تیم‌ نرم‌افزاری فقط به دغدغه کد خود بپردازد نه دغدغه نصب و تحویل مستمر نرم‌افزار.سرویس CI/CD فندقاین سرویس نیز با ابزارهایی مانند Gitlab CI به طور کامل قابل استفاده است.می‌توانید جهت مشاهده مستندات هر یک از سرویس‌های بالا به سایت ‌آن‌ها مراجعه کنید.منابع و لینک‌های مفیدhttps://www.redhat.com/en/topics/devops/what-is-continuous-deliveryhttps://martinfowler.com/bliki/ContinuousDelivery.htmlhttps://aws.amazon.com/devops/continuous-delivery/https://continuousdelivery.com/https://aws.amazon.com/devops/what-is-devops/https://www.katalon.com/resources-center/blog/ci-cd-tools/ https://www.arvancloud.com/fa/products/paas https://liara.ir/ این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است. Hamid Montazeri Hamid Montazeri Fri, 24 Dec 2021 17:02:26 +0330 https://virgool.io/@hamidhandid/%D8%A2%D8%B4%D9%86%D8%A7%DB%8C%DB%8C-%D8%A8%D8%A7-%D9%85%D9%81%D9%87%D9%88%D9%85-api-gateway-pvwmjsr4oplt اگر با مفهوم API آشنا باشید، می‌دانید که در یک نرم‌افزار یا کلاینت برای ارتباط با سرور معمولاً از API برای برقراری ارتباط استفاده می‌شود. در یک نرم‌افزار با تغییراتی که طی مدت توسعه در آن رخ می‌دهد، به مرور تعداد API ها افزایش می‌یابد و اگر این نرم‌افزار در سطح یک سازمان باشد چه بسا که این API های زیاد، باعث پیچیدگی‌های سنگین یا ناهماهنگی بین API های مختلف برنامه شود. حتی ممکن است یکی از API ها دارای مشکل شود و این مورد به API های دیگر نیز آسیب برساند. در این جاست که استفاده از مفهومی به نام API Gateway اهمیت پیدا می‌کند.گذرگاه API چیست؟گذرگاه API یا همان API Gateway یک ابزار مدیریت API است که بین کلاینت و سرویس‌های سرور یا backend قرار می‌گیرد. در واقع تمام ریکوئست‌های کلاینت به API Gateway فرستاده می‌شود و سپس این API Gateway است که تصمیم می‌گیرد این درخواست‌ را به کدام سرویس از backend برساند. هم‌چنین این سرویس‌ها در صورت استفاده از معماری میکروسرویس ممکن است یک میکروسرویس در سامانه نرم‌افزاری باشد. معمولاً API Gateway در معماری میکروسرویس استفاده می‌شود.هر وقت پاسخ آن سرویس آماده شود، API Gateway از سرویس مورد نظر پاسخ را دریافت می‌کند و به کلاینت می‌دهد. در تصویر ۱ شمایی از یک API Gateway را می‌بینید که با سرویس‌های مختلف backend در ارتباط است که البته خود این سرویس‌ها ممکن است با دیتابیس یا بخش‌های دیگر در ارتباط باشند. در واقع وقتی API Gateway داشته باشیم، هر دیوایسی که در سمت کلاینت باشد برای ارتباط با هر یک از سرویس‌های سرور باید از درِ API Gateway عبور کند و آن را استفاده کند نه اینکه برای هر سرویس API به طور جدا ارتباط برقرار کند. البته همیشه API Gateway به صورت یکتا نیست و ممکن است چند API Gateway داشته باشیم که البته معایب و مزایایی خواهد داشت که اکنون به بررسی آن‌ها نمی‌پردازیم.تصویر 1 - شمایی از API Gatewayدر معماری میکروسرویس، API Gateway ها ریکوئست‌ها را از هر کلاینت دریافت می‌کنند و سپس آن‌ را به سمت میکروسرویس مورد نظر می‌فرستند. در این بین باید به صورت مناسب مسیریابی کرده و در صورتی که چند سرویس برای ارائه آن خدمت موجود بود بهترین را انتخاب کند و نتیجه را به سمت کلاینت بفرستند.بسیاری از شرکت‌ها مشکل مدیریت API دارند و هم‌چنین در کسب و کار خود نمی‌توانند یک دروازه برای API طراحی کنند تا توسعه دهندگان آن شرکت بتوانند به آسانی و بدون سر و کار داشتن با پیچیدگی‌های هر میکروسرویس به کار با سیستم بپردازند. هم‌چنین ممکن است در میکروسرویس‌های مختلف یک معماری نرم‌افزار، پروتکل‌های مختلفی مانند Http یا gPRC استفاده شود که در هر کدام از آن میکروسرویس‌ها به خوبی عمل کند اما وقتی کار به تجمیع و ارتباط این زیرسیستم‌ها با هم می‌رسد، مشکل آغاز می‌شود. با استفاده از API Gateway این مشکل نیز تا حد خوبی برطرف می‌شود چون توسعه دهنده با API Gateway سر و کار خواهد داشت و لازم نیست هر بار بین پروتکل‌ها و میکروسرویس‌های مختلف سوییچ کند.در واقع وظیفه‌ یک API Gateway این است که درخواست‌ها را در معماری‌ای مانند معماری میکروسرویس سازماندهی کند و یک تجربه مناسب برای تیم توسعه بسازد. API Gateway مانند یک مترجم عمل می‌کند که هر نوع ریکوئستی را گرفته و می‌تواند آن‌ها را حتی ترکیب کنند و به سمت هر یک از میکروسرویس‌ها بفرستد. با این عمل هم پیاده‌سازی در قسمت کلاینت به علت اینکه صرفاً با این دروازه برای API سروکار دارد، آسان‌تر می‌شود و پیچیدگی‌های کمتری خواهد داشت و هم میکروسرویس‌های مختلف نگران کار و هماهنگی و تطابق با انواع اپلیکیشن‌ها و نحوه استفاده ‌آن‌ها از API نخواهند بود چون با وجود API Gateway می‌دانند که باید صرفاً با آن هماهنگ باشند و خود API Gateway به درخواست‌های کلاینت‌های مختلف رسیدگی خواهد کرد.مزایا و معایب API Gatewayممکن است از خود پرسیده باشید چرا باید یک پیچیدگی به معماری نرم‌افزار خود اضافه کنیم و API Gateway را بین کلاینت و سرویس‌های backend قرار دهیم.مزایای API Gatewayمفهوم وجود API Gateway به تیم توسعه نرم‌افزار کمک می‌کند که API های مختلف را بدون نگرانی زیاد بسازند و بسیار آسان‌تر نگهداری کنند چرا که API Gateway به عنوان یک واسط بین کلاینت و تمام سرویس‌های backend قرار خواهد گرفت و تیم توسعه می‌دانند که تمام درخواست‌هایی که از سمت کلاینت فرستاده می‌شود حتماً از آن عبور خواهد کرد. واضح است که مدیریت API Gateway به عنوان یک واسط بسیار آسان‌تر از مدیریت API های متعدد خواهد بود. هم‌چنین استفاده از API Gateway جهت مدیریت ترافیک، مدیریت دسترسی کلاینت‌ها، مدیریت امنیت سرویس‌های backend و هم‌چنین مشاهده و مدیریت لاگ‌ و مانیتورینگ ریکوئست‌های ارسال شده نیز بسیار مفید خواهد بود. به طور کلی مزایای API Gateway را در چند مورد زیر می‌‌توان خلاصه کرد:مدیریت ترافیک و load balancingمدیریت آسان لاگ‌ها و tracing راحت‌تر مشکلات APIمدیریت دسترسی کلاینت‌ها (Authentication و Authorization)مدیریت خطا و cache کردن پاسخ‌ها جهت افزایش سرعت پاسخگوییمدیریت و توسعه آسان‌تر API های مختلف و افزایش scale پذیری API هااستفاده راحت‌تر از هر یک از میکروسرویس‌ها در صورت استفاده از معماری میکروسرویسو ...معایب API Gatewayبله! همان‌طور که در مورد مزایا گفتیم، معایب و مشکلات API Gateway را نیز باید بدانیم. با یک مثال به بررسی معایب آن می‌پردازیم. ابتدا به تصویر ۲ نگاه کنید.تصویر ۲ - نمونه‌ای از یک API Gatewayهمان‌طور که دیدید، در backend سیستم نرم‌افزاری حداقل از لحاظ تعداد واحدهای برنامه به پیچیدگی‌های آن اضافه کرده‌ایم چرا که یک واحد به نام API Gateway اضافه شده است. این مشکل زمانی بیشتر مشخص می‌شود که سرویس‌های زیادی نداشته باشیم و از معماری میکروسرویس نیز استفاده نکرده باشیم. در این مواقع شاید استفاده از API Gateway بیشتر به پیچیدگی بیفزاید نه آن که کار را ساده‌تر کند و پیچیدگی را کمتر!فرض کنید روزی این API Gateway دچار خرابی شود. احتمالاً می‌توانید تصور کنید چه مصیبتی به بار خواهد آورد چون تقریباً تمام کلاینت‌ها و اپلیکیشن‌ها پاسخ درستی دریافت نخواهند کرد. در واقع با استفاده از یک API Gateway یک نقطه شکست (single point of failure) ایجاد کرده‌ایم که اگر به هر دلیلی دارای مشکل شود، روی کل سیستم تاثیر منفی خواهد گذاشت.هم‌چنین از معایب دیگر می‌توان به کاهش سرعت پاسخگویی از سمت API اشاره کرد. گفتیم که همه ریکوئست‌ها قرار است از API Gateway رد شوند پس به ازای هر ریکوئستی که می‌آید باید یکبار به API Gateway فرستاده شود و خود API Gateway به سرویس API مورد نظر ریکوئست را بفرستد. سپس جواب را از آن API بگیرد و در نهایت پاسخ را برای کلاینتی که ریکوئست را ارسال کرده بفرستد. همان‌طور که دیدید به جای کار مستقیم با API ها، با API Gateway کار کردن احتمالاً میزان سرعت پاسخگویی را کم می‌کند. البته این مشکل را با استفاده از cache در API Gateway می‌توان تا حدودی برطرف کرد.به طور کلی معایب API Gateway را می‌توان در چند مورد زیر خلاصه کرد:افزایش پیچیدگی به علت اضافه شده یک واحد به سیستم نرم‌افزاری و افزایش هزینه‌ها به علت توسعه و نگهداری این واحدافزایش زمان پاسخگویی به ریکوئست‌هاایجاد یک نقطه شکست (single point of failure) و گلوگاه (bottleneck) در معماری نرم‌افزارو ...معرفی ابزارهای و فناوری‌های متن باز در حوزه API Gatewayدر این بخش به معرفی دو نمونه از ابزارهای مرتبط با API Gateway می‌پردازیم.ابزار Kongابزار Kong Gateway یکی از محبوب‌ترین ابزارهای متن‌باز ابری API Gateway است. این ابزار مبتنی بر پروکسی کار می‌کند و با زبان Lua و با استفاده از Nginx این سرویس راه اندازی شده است. به گفته خود توسعه دهندگان این ابزار در سایت آن، این ابزار برای کار با میکروسرویس‌ها و معماری‌های توزیع شده بهینه شده است. هم‌چنین در این ابزار می‌توان با استفاده از راهنمای آن، پلاگین‌های مختلف جهت افزایش امکانات آن توسعه داد و به آن اضافه کرد. این ابزار رایگان و متن باز است که البته نسخه پولی آن نیز وجود دارد.ابزار Tykابزار Tyk یک API Gateway متن‌باز و سبک‌وزن است که با زبان go توسعه داده شده است. این ابزار به صورت ابری می‌تواند کار کند و performance بالایی دارد. Tyk به دیتابیس redis نیاز دارد. این ابزار امکانات متعددی مثل امکان محدود کردن تعداد ریکوئست‌ها (rate limiting)، لاگ، مانیتورینگ و آنالیز درخواست‌ها، بررسی event ها، امکان استفاده از mock api قبل از release اصلی و موارد دیگری را در بر دارد. این ابزار به طور کامل متن باز است.شرکت‌های ارائه دهنده API Gateway در ایراندر این بخش به معرفی دو شرکت ارائه دهنده API Gateway در ایران می‌پردازیم.شرکت مسیر هوشمنداین شرکت به کسب و کارهایی که قصد دارند به سمت معماری میکروسرویس حرکت کنند، زیرساخت‌هایی برای عرضه و مدیریت API به صورت یکپارچه می‌دهد. طبق گفته این شرکت، API Gateway های عرضه شده توسط آن به بیش از ۹ میلیارد درخواست از سازمان‌ها و کسب‌وکارهای مختلف پاسخ داده است. هم‌چنین این شرکت کمک می‌کند که معماری و زیرساخت کسب‌وکارهای مورد بازنگری و بازطراحی قرار بگیرد تا استفاده از سرویس‌های این شرکت با کمترین مشکل انجام شود. هم‌چنین این شرکت از سرویس‌هایی که ارائه می‌دهد به صورت کامل پشتیبانی می‌کند و به گفته خود در مقیاس ۳۷ میلیون کاربر سرویس‌دهی داشته است.شرکت وصلاین شرکت با ابزار مدیریت API Gateway ای که دارد، به توسعه دهندگان اجازه می‌دهد که برنامه‌هایی هماهنگ با سامانه‌های داخلی سازمان طراحی نمایند. این پلتفرم برای مدیریت API ها، مواردی مانند تجزیه و تحلیل داده‌ها، کنترل دسترسی‌ها و محافظت از اطلاعات حساس را ارائه می‌دهد. هم‌چنین یکی دیگر از مزایای این شرکت، ایجاد یک راه حل برای مدیریت اکوسیستم‌ها و API های مبتنی بر اینترنت اشیا (IoT) است و تمامی خدمات برای حوزه اینترنت اشیا در API Gateway را نیز دربردارد. یکی دیگر از مواردی که این شرکت تضمین می‌کند، امکان هماهنگی پنل‌های مدیریت API Gateway با استفاده از دستگاه‌های مختلف است که با استفاده از هشدارها، گزارش‌ها و آمارها و ایجاد یک پنل پیشرفته، مدیریت API ها را برای کسب و کارها آسان‌تر می‌کند.منابع و لینک‌های مفیدhttps://www.redhat.com/en/topics/api/what-does-an-api-gateway-dohttps://microservices.io/patterns/apigateway.htmlhttps://docs.microsoft.com/en-us/dotnet/architecture/microservices/architect-microservice-container-applications/direct-client-to-microservice-communication-versus-the-api-gateway-patternhttps://aws.amazon.com/api-gateway/https://geekflare.com/api-gateway/ http://smartpath.ir/ http://vasl.ir/platform/api-management/ https://konghq.com/kong/ https://tyk.io/ این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است. Hamid Montazeri Hamid Montazeri Fri, 24 Dec 2021 12:08:04 +0330 https://virgool.io/@hamidhandid/c4model-wzfku7vyppvg تا حالا شده که وقتی می‌خواین معماری نرم‌افزارتون رو برای افراد دیگه توضیح بدین، از نمودارها و دیاگرام‌ها استفاده کرده باشین؟ اگه جوابتون آره هست که احتمالاً همینطوره، از چه نمودارهایی استفاده کردین؟ UML؟ نمودارهای دیگه؟ شده که فرد غیرفنی تو تیمتون باشه و در فهم این نمودارا مشکل داشته باشه؟ اگه جوابتون آره هست، این نوشته برای شماست و داخل این نوشته در مورد روش C4 برای تجسم ساده‌تر از معماری نرم‌افزار صحبت می‌کنیم. اگه جوابتون نه هست هم خوندن مطلب ممکنه بهتون کمک کنه برای استفاده از نمودارهای قابل فهم‌تر برای ارائه در سندهای معماری نرم‌افزار.معمار ساختمان یا معمار نرم‌افزار؟ مسئله این است!اگر از یک معمار ساختمان یا حتی فردی که در صنعت ساختمان فعالیت داره، بخواین که براتون معماری ساختمانش رو براتون بکشه و توضیح بده، احتمالاً یه تصویر و نقشه از طبقات، قسمت‌های مختلف ساختمان و جزئیات اون ساختمان بهتون ارائه بده که احتمالاً با کمی نگاه کردن و دقت کردن بهش متوجه بشین چه معماری و نقشه‌ای در ذهن فرد مقابلی که اونو براتون کشیده هست.حالا اگه از یک مهندس یا توسعه دهنده نرم‌افزار بخواین در مورد معماری نرم‌افزارش با استفاده از نمودارها توضیح بده، احتمالاً تعدادی باکس، خط، شکل‌های مختلف، رنگ‌های متفاوت و یه عالمه چیزای دیگه می‌بینید که هیچی ازش سردر نمیارید یا حداقل نمی‌دونید چرا این‌طوری ازشون استفاده شده. خب باید چیکار کرد؟ چطوری میشه از این نمودارای سخت‌فهمی که مشخص نیست دقیقاً چه قاعده و اصولی دارن به نمودارهای آسون‌فهم‌تر رسید؟! چی کار کنیم که بتونیم این خط، باکس، روابط پیچیده، انتزاع بیش از حد، واژه‌های خیلی عمومی‌ و یه عالمه چیز دیگه که معمولاً تو این نمودارا استفاده میشه رو طوری برای بقیه ارائه و تجسم کنیم که قابل فهم تر باشه؟تصویر ۱ - نمونه نمودارهای کشیده‌شده توسط توسعه‌دهنده‌های نرم‌افزار!خب! مهندسای نرم‌افزار و توسعه‌دهنده‌ها معمولاً تو چنین جاهایی از UML اسم می‌برن و ازش استفاده می‌کنن تا زبان مشترکی بین خودشون و بین آدمای غیرفنی تیم و در واقع کل افراد مرتبط با معماری اون نرم‌افزار داشته باشن. اینجاس که یه مشکلی معمولاً پیش میاد. آدمای غیرفنی معمولاً کمتر با نشانه‌گذاری‌های استفاده شده تو UML آشنا هستن. شاید بهتر باشه با راه حلی ساده‌تر و واضح‌تر با افراد تیم صحبت کرد که لازم نباشه قواعد UML یا نمودارای مشابه UML رو همیشه یادشون باشه. اینجاست که آقای Simon Brown مدل C4 رو برای ساده‌سازی و کاهش پیچیدگی این نمودارا ارائه می‌کنه و به افراد مرتبط با معماری نرم‌افزار کمک می‌کنه که به جای اینکه لازم بشه خیلی به قواعد کشیدن نمودارا فکر کنن، به خود نرم‌افزار بیشتر توجه کنن و صرفاً یه سری نکات رو برای کشیدن نمودارا رعایت کنن که در ادامه بهشون می‌پردازیم.مدل C4 چیه؟اگه با نقشه‌های مختلف کار کرده باشین، با زوم کردن به جزئیات بیشتری از یه مکان می‌رسید و با کم کردن زوم یه نمای کلی‌تر از مکان موردنظرتون رو می‌بینید. این دقیقاً راهی هست که مدل C4 برای تجسم بهتر از جزئیات لایه‌های مختلف نرم‌افزار ازش استفاده می‌کنه. تو این مدل به ارتباط بین تیم‌های مختلف مرتبط با نرم‌افزار توجه شده به طوری که هر فرد مرتبط با نرم‌افزار تا سطحی از جزئیات که بهش احتیاج داره از معماری نرم‌افزار و کد خبر داشته باشه و اگه به جزئیات و پیچیدگی‌های بیشتری احتیاج نداره، اصلاً این جزئیات رو بهش کاری نداشته باشه و در عین حال، سیستم رو به خوبی بفهمه.مدل C4 همون‌طور که از اسمش پیداست از چهار سطح که با حرف C در انگلیسی شروع میشن، تشکیل شده که در مورد هر کدوم در ادامه توضیح می‌دیم. زمینه (Context)ظرف‌ها (Containers)اجزا (Components)کد (Code)تصویر ۲ - سطوح مختلف مدل C4سطح اول، زمینه (context)در سطح اول از مدل C4 که در واقع نمودار زمینه سیستم (system context diagram) هست، یک شمای کلی از سیستم‌ نرم‌افزاری در وسط داریم که کاربرها و سیستم‌های دیگه‌ای که با سیستم نرم‌افزاری مورد نظر ارتباط دارن در اطرافش قرار داره. تو این سطح، جزئیات نرم‌افزار نباید آورده بشه. به عنوان مثال نباید به تکنولوژی‌ها و جزئیات سطح پایین پرداخته بشه. چیزی که باید تو این سطح از مدل C4 بهش توجه بشه بیشتر خود سیستم‌ اصلی و سیستم‌های مرتبط باهاش و کاربرهای سیستم‌مون هست. در واقع این سطح از نمودار، راه خیلی مناسبی برای ارتباط با افراد فنی و غیرفنی مرتبط با پروژه هست.به عنوان مثال اگه یه سیستم بانک اینترنتی رو درنظر بگیریم، تو این سطح صرفاً خود سیستم رو به همراه یه توضیح از کارکرد سیستم در وسط داخل یک باکس میاریم و سیستم‌ها و کاربرایی که قراره باهاشون سیستم کار کنه رو در اطرافش میاریم که در این جا مشتری بانک اینترنتی به عنوان کاربر سیستم و سیستم‌های ایمیل و سیستم اطلاعات مرکزی بانک رو در اطرافِ باکس اصلی که در وسط قرار داره آوردیم. روابط بین کاربر و سیستم‌های مرتبط با سیستم اصلی رو هم روی فلش می‌نویسیم که چطوری هست. تصویر ۳ - نمودار سطح System Context برای یک سیستم بانکی اینترنتی سطح دوم، ظرف‌ها (Containers)برای اینکه بدونیم تو سطح دوم از مدل C4 باید چیا بیاد باید یکم زوم کنیم! اگه بخوایم جزئیات بیشتری از یه نقشه بدونیم چیکار می‌کنیم؟ زوم می‌کنیم دیگه! پس بیایم روی سیستم بانک اینترنتی خودمون یه مقدار زوم کنیم. وقتی که کمی زوم می‌کنیم می‌بینیم که این سیستم بانکی ممکنه شامل تعدادی ظرف باشه که هر ظرف در واقع یک واحد قابل اجرا یا استقراره که میتونه کد رو اجرا کنه یا داده تو اون ظرف ذخیره بشه. مثلاً به تصویر ۴ نگاه کنین. تو این تصویر، تعدادی باکس وجود داره. اپ موبایل، وب اپلیکیشن یا واحد API، ظرف‌هایی هستن که توشون کد میتونه اجرا بشه و Database بخشیه که داده داخلش میتونه ذخیره بشه. پس هر کدوم از این‌ها در واقع میتونن یه ظرف باشن.در واقع نمودار ظرف‌ها یا همون container ها (که البته منظور در این جا چیزایی مثل docker نیست لزوماً!) یک نمودار سطح بالا از معماری نرم‌افزار و اینکه وظایف و کارهای مختلف سیستم، در کدوم بخش‌ها و چطوری تقسیم شدن هست. هم‌چنین تو این سطح از مدل C4، تکنولوژی‌های اصلی و اینکه این ظرف‌ها چطوری با هم ارتباط برقرار می‌کنن هم میاد. سطح ظرف‌ها از مدل C4، برای توسعه‌دهنده‌های نرم‌افزار و افراد دیگه‌ای مثل واحدهای عملیاتی و پشتیبانی میتونه مفید باشه.تصویر ۴ - نمودار سطح Containers برای سیستم بانکی اینترنتیسطح سوم، اجزا (Components)حالا میخوایم ببینیم داخل هر ظرف، چه اجزایی وجود داره. اگه روی هر کدوم از ظرف‌هایی که تو سطح قبلی داشتیم زوم کنیم، بلاک‌ها و اجزای اصلی اون ظرف رو می‌بینیم. این اجزا در واقع، نماینده‌ بخش‌های مختلف کد ما هستن که هر بخش رو می‌تونیم مثلاً به یه بخش یا بخش‌هایی از کد، مپ کنیم. در هر جزء، وظیفه‌ اون جزء و جزئیات تکنولوژی و پیاده‌سازی جزء مورد نظر رو میاریم. این بخش بیشتر به درد افراد فنی پروژه مثل معمار نرم‌افزار و به خصوص توسعه‌دهنده‌ها میخوره.اگه به تصویر ۵ دقت کنید، ظرف API از سطح قبلی رو روش زوم کردیم و اجزای مختلف اون که در واقع نماینده‌ای برای اجزای مختلف کد هستن مثل جزء ایمیل، جزء ریست کردن رمزعبور و اجزای دیگه قابل مشاهده هستن و وظیفه هر جزء مشخص شده و نحوه ارتباط این اجزا و هم‌چنین ارتباط این اجزا با ظرف‌های دیگه هم قابل دیدن هست.تصویر ۵ - نمودار سطح Components برای بخش API سیستم بانکی اینترنتیسطح چهارم، کد (Code)داریم کم کم فول زوم می‌کنیم! اگه روی هر component زوم کنیم در واقع نحوه پیاده‌سازی اون جزء رو باید مشاهده کنیم. در سطح چهارم از مدل C4 پیاده‌سازی هر component رو می‌تونیم داشته باشیم و این‌جاست که می‌تونیم مثلاً از UML ها یا دیاگرام ارتباط بین موجودیت‌ها یا چیزای مشابه استفاده کنیم.معمولاً درستش اینه که این مقدار و این سطح از جزئیات در معماری نرم‌افزار نیاز نیست و معمولاً توصیه نمیشه تا این حد از جزئیات رو در نمودارهامون بیاریم و بهتره حتی اگه نیاز داشتیم که تا این سطح از نمودار رو داشته باشیم، از ابزارهای خود IDE ها برای این کار استفاده کنیم که مثلاً می‌تونن UML رو برامون جنریت کنن. البته باید دقت کنیم که حتی در همین نمودار، بخشی از ویژگی‌ها و متدها رو میاریم که مهم باشه و برای ارتباط با سایر اعضای تیم نرم‌افزار مفید باشه. بازم تکرار کنیم که این بخش از جزئیات توصیه نمیشه تو نمودارای معماری نرم‌افزار بیاد ولی اگه یه component خیلی پیچیده شد، خب شاید خوب باشه که سطح چهارم از مدل C4 هم آورده بشه. تصویر ۶ به عنوان مثال، کلاس‌های جزء mainframe رو نشون میدن.تصویر ۶ - نمودار سطح Code برای جزء mainframe سیستم بانکی اینترنتینشانه‌گذاریدر مورد نشانه‌گذاری در نمودارهای مختلفی که در معماری نرم‌افزار استفاده میشه، پیچیدگی‌های زیاد و مختلفی وجود داره که باعث میشه افراد غیرفنی یا افرادی که لازم نیست درگیر پیچیدگی باشن نیز مجبور بشن این نشانه‌گذاری‌ها رو یاد بگیرن. در مدل C4 هیچ نشانه‌گذاری‌ای از پیش تعریف نشده است. البته نشانه‌گذاری پیشنهادی وجود داره. مثلاً در مدل C4 نشانه‌گذاری پیشنهادی به سبک تصویر ۷ پیشنهاد میشه.تصویر ۷ - یک نشانه‌گذاری پیشنهادی برای مدل C4در واقع در استفاده از مدل C4، بیشتر به کارایی و معنای اجزا و توانایی این مدل برای سادگی تجسم معماری نرم‌افزار و ارتباط راحت‌تر بین اعضای فنی و غیرفنی برای توضیح آسان‌تر معماری توجه میشه. به اینکه مستند کردن معماری نرم‌افزار راحت‌تر و بدون توجه به پیچیدگی‌های غیرمفید باشه. در مدل C4 پافشاری خاصی روی نشانه‌گذاری وجود نداره.ابزارهای قابل استفاده برای مدل C4 ابزار Structurizr یک مجموعه ابزار برای ساختن و مستندکردن نمودارها و معماری نرم‌افزار به روش C4 هست که توسط سازنده‌ خود مدل C4 یعنی آقای Simon Brown ساخته شده. این ابزار متن بازه و می‌تونید ازش استفاده کنید.سخن پایانیبرای ارتباط بین افراد مختلف تیم‌های نرم‌افزاری لزوماً نیازی به افزودن پیچیدگی برای مستندسازی معماری و دانستن معلوماتی مثل نشانه‌گذاری‌های مختلف یا دانش فنی نیست. باید بیشتر به معنا و تجسم و ارتباط آسان‌تر و سریع‌تر و تمیزتر توجه کرد و نباید برای همه‌ افراد فنی یا غیرفنی یک سطح از جزئیات را ارائه داد بلکه هر کدام به قسمتی از جزئیات نیاز دارن. حتی شاید لازم باشه شما که این نوشته رو خوندین هم یه بازنگری‌ای در مستندسازی معماری نرم‌افزار خودتون داشته باشین!شعار مهم مدل C4منابع و لینک‌های مفیدhttps://c4model.com/https://en.wikipedia.org/wiki/C4_modelhttps://www.youtube.com/watch?v=x2-rSnhpw0ghttps://structurizr.org/این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است. Hamid Montazeri Hamid Montazeri Sat, 20 Nov 2021 18:48:41 +0330