https://virgool.io/feed/@rostamkhanihamed1 fa 2026-06-16 18:36:14 https://static.virgool.io/images/default-avatar.jpg https://virgool.io/@rostamkhanihamed1 https://virgool.io/@rostamkhanihamed1/%D8%A8%D8%B1%D8%B1%D8%B3%DB%8C-%D9%88-%D9%BE%DB%8C%D8%A7%D8%AF%D9%87-%D8%B3%D8%A7%D8%B2%DB%8C-%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D9%85%D8%A7%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-peh6avx4aeon در این مقاله قصد دارم درباره پروژه‌ای که در درس معماری نرم‌افزار دانشگاه شهید بهشتی انجام دادم توضیحاتی رو خدمتتون ارائه بدم. هدف این مقاله آشنایی با یکی از معماری‌های مطرح در حوزه مهندسی نرم‌افزار هستش و می‌خواهیم این معماری را به همراه کانتینرها (Container) بررسی کرده و نهایتاً یک پیاده‌سازی از این معماری‌ داشته باشیم. در قدم اول یک معرفی کوتاهی درباره معماری مایکروسرویس‌ها خواهم داشت (درباره مفاهیم و معرفی کامل کانتینر‌ها در این مقاله صحبت کرده‌ام). سپس موضوعات مطرح و مرتبط با این دو معماری را بررسی و دسته‌بندی خواهم کرد (همچنین در هر دسته‌بندی، بهترین گزینه را معرفی می‌کنم). و در آخر به صورت مختصر درباره یک سیستم دمو که با معماری مایکروسرویسی به صورت داکرایز شده (dockerized) پیاده‌سازی کرده‌ام توضیحاتی را ارائه می‌دهم (لینک گیت‌هاب پروژه را در انتهای این مقاله در اختیار علاقه‌مندان قرار خواهم داد).تصویر۱: شمای کلی از معماری مایکروسرویس‌های داکرایز شدهمعرفی معماری مایکروسرویسما همیشه اسم معماری مایکروسرویس‌ها را کنار معماری یکپارچه (monolithic) شنیده‌ایم. این دو معماری به نوعی دو دیدگاه مختلف از معماری نرم‌افزار را نشان می‌دهند که تقریبا در تقابل و تضاد با یکدیگر می‌باشند. معماری یکپارچه، یک رویکرد سنتی برای تولید سیستم‌های نرم‌افزاری می‌باشد و اکثر بخش‌های نرم‌افزار در یکجا متمرکز هستند. در تصویر زیر می‌توانید یک نمونه ساده از این معماری را مشاهده کنید.تصویر۲: معماری یکپارچه فروشگاه اینترنتی همانطور که در تصویر بالا مشاهده می‌کنید بیشتر بخش‌های این سیستم مانند امنیت (احراز‌هویت، اعطای دسترسی و...)، لایه Presentation، لایه منطقی و کسب‌وکاری، بخش پیام‌رسانی (Notification module)، بخش ارتباط با repository (پایگاه‌داده‌ها و external storage ها) و... در یکجا و در یک codebase واحد متمرکز شده‌اند. علاوه بر مشکلات متعددی مانند SPOF (Single point of failure)، تاثیر به‌سزای یک تغییر کوچک در کل سیستم، قابلیت اطمینان (Reliability) و... که این معماری به همراه دارد، مشکل مقیاس‌پذیر نبودن این معماری برای پروژه‌های بزرگ (Enterprise Systems یا سیستم‌های نرم‌افزاری مقیاس وسیع) نیز یکی دیگر از دغدغه‌های اصلی سازمان‌ها و شرکت‌های IT می‌باشد.بنابراین به دلیل معایب بسیاری که معماری یکپارچه به همراه داشت، مهندسان و معماران نرم‌افزار بیش از پیش به سمت معماری‌های توزیع شده (مانند معماری سرویس‌گرا یا مایکروسرویسی که در اینجا فقط به معماری مایکروسرویس‌ها می‌پردازیم) متمایل شدند. در معماری مایکروسرویس، بخش‌های مختلف یک سیستم نرم‌افزاری به صورت مجزا طراحی، توسعه و در قالب سرویس‌های کوچک مستقر می‌شوند و نهایتاً با ارتباط با یکدیگر یک کل واحد را تشکیل می‌دهند.معماری مایکروسرویس ویژگی‌ها و خصوصیات زیادی از جمله مولفه‌ای بودن سرویس‌ها (ویژگی plug & play)، کسب‌وکار محور بودن هر مایکروسرویس، محصول‌گرا بودن (هر مایکروسرویس یک محصول محسوب می‌شود و نه یک پروژه)، حاکیمت غیرمتمرکز، خودشمول بودن (یعنی هر مایکروسرویس به صورت مجزا داده‌هایش را مدیریت می‌کند و حافظه، مخزن و یا دیتابیس مخصوص خود را دارد) و... دارد. البته قابل ذکر هست که برخی از این ویژگی‌ها الزاماً یک مزیت نمی‌باشد و گاهی ممکن است یک عیب نیز محسوب شود (مثلا ویژگی خودشمول بودن در سناریو‌هایی که تمامی مایکروسرویس‌ها در یک شبکه وجود دارند بی‌معنی است زیرا که وجود یک پایگاه‌داده یا یک schema به ازای هر مایکروسرویس، بسیار هزینه‌بر می‌باشد).تصویر۳: معماری مایکروسرویسی فروشگاه اینترنتیهمانطور که در تصویر ۳ مشاهده می‌کنید، پس از تجزیه صحیح بخش‌های یک سیستم monolithic می‌توان یک سیستم با معماری مایکروسرویس را تولید کرد. نکته قابل ذکر درباره معماری مایکروسرویس این است که با وجود مزیت‌های زیاد این معماری نسبت به معماری یکپارچه، همچنان نمی‌توان با قطعیت بیان کرد که این معماری در آینده نیز همچنان به عنوان یک معماری قالب و مطرح استفاده خواهد شد. به عنوان مثال یکی از چالش‌های مهمی که در معماری مایکروسرویس همچنان وجود دارد این است که نمی‌توان یک رویکرد (یا چندین رویکرد مشخص) برای خطایابی و ردگیری خطای سیستم مایکروسرویسی مطرح کرد (رویکرد‌ها و راه‌حل‌های مختلفی برای این مسئله وجود دارند ولی در هر use case نحوه حل این مسئله متفاوت می‌باشد.). در سیستم مایکروسرویسی که توسعه داده‌ام یک راه‌حل ساده برای حل این مسئله پیاده‌سازی کرده‌ام.بررسی و دسته‌بندی ابزار‌ها و فناوری‌های مرتبط با مایکروسرویس و کانتینردر این بخش به بررسی و دسته‌بندی موضوعات مختلف معماری مایکروسرویس و کانتینر‌ها (از جمله زبان‌ها، تکنولوژی‌ها، ابزارها، فریم‌ورک‌‌ها و...) پرداخته‌ام. اصولاً در شکل‌گیری هر معماری، مباحث و موضوعات مختلفی دخیل می‌باشند. به همین دلیل در این بخش سعی می‌کنیم بیشتر موضوعات و مباحثی که مربوط به معماری مایکروسرویس‌ها و کانتینر‌‌هاست را مطرح کنیم.زیرساخت و سیستم عاملمهم‌ترین و حیاتی‌ترین کار برای ساختن هر برنامه نرم‌افزاری، تنظیم و پیکربندی پایه و اساس صحیح آن است که این کار توسط سیستم عامل باید انجام شود. اصولاً سیستم عامل‌های مختلفی برای اجرای برنامه‌های سروری (میزبانی سرور) وجود دارند ولی پرکاربردترین آن‌ها سیستم عامل‌های لینوکسی می‌باشند. لینوکس یک سیستم عامل است که برای ساخت و توسعه برنامه نرم‌افزاری استفاده می‌شود و یک محیط مستقل برای اجرا ارائه می‌دهد. همچنین لینوکس امکان هماهنگی و پیکربندی Custom سرویس‌ها و فرآیند‌های کوچک و بزرگ مانند شبکه، امنیت، ذخیره‌سازی و... را فراهم می‌کند. نکته مثبت دیگری که سیستم عامل‌های لینوکسی دارند، پشتیبانی خوب آن‌ها از Container ها می باشد که همین مزیت بسیار خوبی برای مایکروسرویس‌ها محسوب می‌شود (در دسته‌بندی Containerization بیشتر درباره این موضوع صحبت می‌کنیم).اما سوالی که باقی می‌ماند این است که کدام توزیع از سیستم عامل لینوکس برای زیرساخت معماری مایکروسرویس مناسب می‌باشد. ممکن است در ابتدا به نظر برسد که Red Hat یا Ubuntu گزینه‌های منطقی باشند، اما نکته‌ای که باید در نظر گرفت این است که هر دو، سیستم‌ عامل‌هایی با فیچر‌های کامل هستند و دارای عملکردهای زیادی می‌باشند که نیازی به تمامی آن‌ها نداریم. زیرا علاوه بر ناکارآمد بودن (عملکرد غیرضروری دیسک و حافظه مصرفی بالا که ممکن است بر عملکرد سیستم نیز تأثیر بگذارد)، اجرای یک سیستم عامل با فیچرهای غیرضروری، امکان و فرصت حمله هکرها را بیشتر می‌کند (مثلا باز بودن پورت‌های زیاد دسترسی‌های بیشتر باعث ایجاد فرصت‌های بیشتری برای هک شدن ایجاد می‌کند).در سطوح مختلفی کسب‌وکاری انتخاب سیستم‌عامل مناسب بسیار حائز اهمیت می‌باشد به همین دلیل می‌توان انتخاب زیرساخت مناسب را مهم‌ترین گام توسعه هر سیستمی معرفی کرد. برای این پروژه از سیستم‌عامل CentOS استفاده کرده‌ام زیرا علاوه بر اینکه برای سرور‌‌ها optimize شده‌اند، می‌توان آن را با حداقل منابع سخت‌افزاری اجرا کرد.زبان‌های برنامه نویسی و تکنولوژی‌هامعماری مایکروسرویس‌ یک مزیت بسیار مهم را ارائه می‌دهد و آن این است که اجازه می‌دهد از تکنولوژی‌ها و زبان‌های مختلف برای ساخت سرویس‌های متنوع از یک سیستم نرم‌افزاری استفاده شود. بنابراین، توسعه دهندگان در انتخاب زبان و تکنولوژی که می خواهند با آن برای ساخت مایکروسرویس‌ها کار کنند، آزادند. نکته‌ای که باید در این دسته‌بندی در نظر گرفت، انتخاب زبان و تکنولوژی برحسب نوع کسب‌وکار می‌باشد؛ یعنی اینکه کدام زبان برنامه‌نویسی و کدام تکنولوژی باید برای توسعه انتخاب شود کاملاً به نیاز عملکرد تجاری بستگی دارد.زبان‌ها و تکنولوژی‌ها و فریم‌ورک‌های مختلفی برای پیاده‌سازی مایکروسرویس‌ها وجود دارند. به عنوان مثال چند مورد از محبوب‌ترین این تکنولوژی‌ها عبارتند از: Spring Boot (جاوا)، Flask (پایتون)، Express JS (جاوااسکریپت - Node JS) و Elixir (بر روی Erlang virtual machine اجرا می‌شود). در این پروژه از فریم‌ورک Spring boot، فریم‌ورک Angular، ابزار‌های Consul، Splunk و RabbitMQ استفاده شده است.ابزار‌های Containerizationکانتینرسازی (Containerization) شامل توسعه یک نرم‌افزار با تمام وابستگی‌ها و فایل‌های پیکربندی می‌باشد که برای اجرای آن در یک محیط پردازشی متفاوت از طریق ماشین توسعه‌دهنده به سرورهای مختلف (که ممکن است سیستم‌عامل متفاوتی داشته باشند) مورد نیاز است. از کانتینرسازی برای ساخت، انتقال و اجرای هر برنامه نرم‌افزاری در تمامی محیط‌های مختلف (عملیاتی، تست، توسعه و...) کار می‌کند. همچنین کانتینرها، جایگزینی سبک وزن برای ماشین‌های مجازی می‌باشند و انتخاب بهتری برای اجرای برنامه‌ها محسوب می‌شوند. به عبارتی دیگر، استفاده از کانتینرها به این معنی است که پردازش ارزش آفرین (برنامه‌های نرم‌افزاری توسعه داده شده) بیشتر ادامه پیدا کند و پردازش‌های غیرضروری (مصرف بیهوده منابع توسط برنامه‌های غیرضروری VM) حذف شوند.یکی از بهترین تطابقاتی که در حوزه معماری مایکروسرویس‌ها مشاهده کرد، تطبیق مایکروسرویس‌ها با تکنولوژی Docker می‌باشد. دو مورد از پرکاربردترین تکنولوژی‌های کانتینری‌سازی عبارتند از Docker، Containerd. از این دو تکنولوژی برای ایجاد کانتینر برنامه‌ها و سرویس‌های نرم‌افزاری استفاده می‌شود.ابزارهای مدیریت API (API Management Tools)مایکروسرویس‌ها و API ها ارتباط بسیار نزدیکی بهم دارند و هر مایکروسرویس از طریق API با دیگر مایکروسرویس‌ها و سرویس‌های خارجی ارتباط برقرار می‌کند. بنابراین یکی از چالش‌های مطرح در این حوزه مدیریت این API های مختلف و متنوع می‌باشد. به کمک API Management علاوه انتشار مدیریت شده API های مایکروسرویس‌ها می‌توان چندین API مربوط به مایکروسرویس ها را ترکیب کرد و سپس به عنوان یک API واحد منتشر کرد، روی API های مایکروسرویس‌ها محدودیت‌های امنیتی و دسترسی قرار داد (سیاست‌گذاری روی API ها) و سرویس‌های قدیمی را به عنوان API ها مدرن در معرض دید قرار داد.ابزار‌های متعددی برای مدیریت API منتشر شده‌اند که صرفاً برخی از آن‌ها را در این بخش معرفی می‌کنیم. Kong Gateway، Tyk و WSO2 API Microgateway برخی از ابزار‌های متن‌باز برای مدیریت API (از دید پیاده‌سازی API Gateway) می‌باشند. برای سیستم پیاده‌سازی شده به واسطه فریم‌ورک Spring یک Reverse Proxy توسعه دادم که به صورت محدود برخی از قابلیت‌های یک API Gateway در دنیای صنعت را دارد (Gateway توسعه داده شده فاقد قابلیت‌های امنیتی، Rate Limit، سیاست‌گذاری و... می‌باشد). ابزارهای پیام رسانی (Messaging Tool)برنامه‌های نرم‌افزاری که به واسطه معماری مایکروسرویس‌ها ساخته شده‌اند، سیستمی هستند که در آن هر مایکروسرویس‌ مستقل با یکدیگر به صورت همزمان (Synchronously) و ناهمزمان (Asynchronously) ارتباط برقرار می‌کنند. برای انجام ارتباط بین مایکروسرویس‌ها، از ابزار‌های پیام‌رسانی (یا انواع صف‌های پیام‌رسانی) استفاده می‌شود. دو مورد از پرکاربردترین این ابزارهای پیام‌رسانی عبارتند از:تکنولوژی Apache Kafka: این ابزار یک نوع سیستم پیام‌رسانی publish-subscribe توزیع شده است. که ماهیتی چابک، مقیاس‌پذیر و توزیع‌شده دارد که می‌تواند حجم عظیمی از داده‌ها را مدیریت کند یا آن را به صورت stream منتقل کند. از Kafka برای پردازش داده‌ها در میان مایکروسرویس‌ها و ارتباطات بین برنامه‌ای یا فراخوانی‌های API استفاده می‌شود.تکنولوژی RabbitMQ: این ابزار پیام‌رسان نیز برای برقراری ارتباط بین مایکروسرویس‌ها یا ارتباطات بین برنامه‌ای و مقیاس‌بندی برنامه‌ها استفاده می‌شود. با استفاده از این ابزار، مایکروسرویس‌ها می‌توانند به صورت ناهمزمان با یکدیگر ارتباط برقرار کنند و مشکل ناهمزمانی را در محیط‌های توزیع شده حل کنند. همچنین، این ابزار رویکرد محافظتی در برابر از دست رفتن داده‌ها در محیط‌های ارتباطی ناهمزمان دارد.ابزارهای همنواسازی (Orchestration Tools)همانطور که قبل‌تر صحبت کردیم بهترین تکنولوژی برای اجرای مایکروسرویس‌ها در محیط‌های مختلف، Container ها می‌باشند. روی هر سرور ممکن است یک یا ده‌ها مورد کانتینر اجرا شوند. کانتینرها به مجموعه‌ای از سرویس‌های پشتیبانی مانند API کنترلی و همچنین اقدامات امنیتی نیاز دارند. جابجایی همه این کانتینرها روی سرور و خاموش کردن آن‌ها، اطمینان از اتصال صحیح آن‌ها، ردیابی آن‌ها و...، اقداماتی پیچیده هستند که نیاز به ابزار‌های زمانبندی کانتینر‌ها (یا همان ابزار‌های همنواسازی) دارند.ابزار‌های همنواسازی مختلفی وجود دارند، اما برای بسیاری از سازمان‌های IT، انتخاب یکی از دو گزینه Docker Swarm یا Kubernetes مطرح می‌باشد. اولین تکنولوژی توسط شرکت Docker تولید شده و ممکن است فکر کنیم که بهترین انتخاب در همنواسازی است. با این حال Kubernetes بسیار محبوب‌تر می‌باشد و به نظر می‌رسد که اکوسیستم بزرگتری از فروشندگانی که با آن درگیر شده‌اند، ساخته است. به عنوان مثال، دو فریم‌ورک کاربردی محبوب، Red Hat’s OpenShift و Apprenda، هر دو از Kubernetes برای هماهنگ کردن استقرار چارچوب خود استفاده می‌کنند.ابزارهای مانیتورینگ (Monitoring Tools)یکی از بخش‌ها و حوزه‌های مهم در سیستم‌های مایکروسرویسی مربوط به نظارت و مانیتورینگ این سرویس‌های ریزدانه می‌شود. بسیار مهم است که ببینیم دقیقاً در هر زمان چه چیزی در یک سیستم در حال انجام است و این موضوع در یک توپولوژی‌های توزیع‌شده بسیار مهم‌تر می‌باشد. متأسفانه نظارت در مایکروسرویس‌ها و درکل سیستم‌های توزیع‌شده دشواری‌ها و چالش‌های خاص خود را دارد. اکثر سیستم‌های نظارتی سنتی برای محیط‌های استاتیک با تعداد گره‌های کم طراحی شده‌اند. هیچ کدام از این سیستم‌ها در یک محیط میکروسرویس مناسب نمی‌باشند. بسیاری از سیستم‌های مانیتورینگ سنتی برای رسیدگی بهتر به نیازمندی‌های نظارتی در مایکروسرویس‌ها اصلاح شده‌اند، اما همچنان در محیط‌های پیچیده دنیای واقعی شکست می‌خورند. خوشبختانه یک ابزار متن‌باز به نام Prometheus وجود دارد که توسط یکی از مهندسان گوگل ساخته شده است. ما با جزئیات بیشتر درباره Prometheus و Grafana صحبت خواهیم کرد و هریک را به تفصیل بررسی می‌کنیم.بحث مهم دیگر لاگ‌هایی می‌باشد که سیستم‌های توزیع‌شده تولید می‌کنند. اصولا به واسطه لاگ‌های سیستم می‌توان مشکلات و خطا‌های سیستم را ردگیری کرد و نظارت بهتری روی سیستم داشت. ولی خب در مایکروسرویس‌ها، سیستم مدیریت لاگ‌ها نیز با چالش‌های متعددی روبه‌رو می‌باشند (به عنوان مثال مختلف بودن تکنولوژی پیاده‌سازی و نحوه کاربرد هر سرویس، منجر به تولید لاگ‌های مختلف و متنوعی می‌شود که مدیریت آن‌ها و سپس tracing سیستم را با دشواری‌هایی روبه‌ور می‌کند). همچنین دو ابزار مطرح در این حوزه وجود دارند که یکی از آن‌ها متن‌باز می‌باشد. اولین ابزار Splunk می‌باشد و نسخه trial دارد. ابزار دیگر ELK (یا Elasticsearch) می‌باشد که متن‌باز است. Splunk نسبتاً سیستمی قدیمی‌تر و جا افتاده‌تر می‌باشد ولی برخی مزیت‌های ELK مانند فراگیر و رایگان بودن را ندارد.ابزارهای ساخت و سرهم‌‌بندی و استقرار (Building & Assembly & Deployment Tools)اصولاً به دلیل زیاد بودن گره‌ها و سرویس‌ها در معماری‌ مایکروسرویس، فاز‌های ساخت، سرهم‌بندی و استقرار هر یک از آن‌ها به صورت جداگانه کار زمان‌گیر و هزینه‌بری می‌باشد. به همین دلیل توسعه دهندگان نیاز به استفاده از ابزارهای ساخت مانند maven، Gradle و ابزار‌های سرهم‌بندی و یکپارچه‌سازی (version control هایی مانند git) و ابزار‌های استقرار مانند Jenkins دارند. به عبارت ساده‌تر در این معماری استفاده از CI/CD یک نیاز مبرم می‌باشد و پیکربندی و استقرار خودکار را تسهیل می‌کند.پیاده‌سازی سیستم مایکروسرویسی با داکرهمانطور که در بخش‌های قبلی مطرح شد، تکنولوژی داکر یکی از گزینه‌های پرکاربرد برای استقرار مایکروسرویس‌ها می‌باشد. به همین دلیل در توسعه این سیستم از این تکنولوژی استفاده کردم. همچنین برای این دموی ساده امکان بهره‌برداری از تمامی تکنولوژی‌ها و ابزار‌های مطرح در بخش قبل وجود نداشت.در تصویر زیر می‌توانید یک شمای کلی از سیستم طراحی شده مشاهده کنید. تمامی مولفه‌های این سیستم (یا به عبارتی تمامی مایکروسرویس‌ها و تکنولوژی‌ها) به صورت داکرایز شده مستقر شده‌اند و امکان اجرای تمامی این مولفه‌ها در هر سیستم‌عاملی که داکر روی آن نصب باشد وجود دارد.تصویر۴: معماری سیستم پیاده‌سازی شده (سیستم فروشنده و محصول)سیستم توسعه‌ داده شده یک سیستم نرم‌افزاری ساده‌ی مبتنی بر وب برای تخصیص مجموعه‌ای از محصولات به فروشندگان مختلف می‌باشد. این سیستم شامل ۱+۳ سرویس درشت دانه می‌باشد؛ یعنی هر سرویس خود شامل چندین مایکروسرویس است. این سرویس‌ها عبارتند از:سرویس فروشندگان: این سرویس شامل مایکروسرویس‌های MS1 و MS3 می‌باشد. مایکروسرویس اول (MS1) با فریم‌ورک Spring Boot پیاده‌سازی شده و برای ذخیره فروشندگانی که ثبت‌نام کرده‌اند استفاده شده است (اطلاعات این فروشندگان در دیتابیس Postgre ذخیره می‌شود). مایکروسرویس سوم (MS3) مسئول گرفتن اطلاعات فروشندگان و محصولات از یک API خارجی می‌باشد و این اطلاعات را به صورت In-Memory نگه می‌دارد. سرویس محصولات: این سرویس شامل مایکروسرویس‌های MS2 و MS3 می‌باشد. مایکروسرویس دوم (MS2) نیز با فریم‌ورک Spring Boot توسعه داده شده و برای ثبت نام محصولات در این سیستم، مدنظر گرفته شده است (اطلاعات این محصولات در دیتابیس MongoDB ذخیره می‌شود). همچنین از مایکروسرویس سوم (MS3) برای گرفتن لیست محصولات موجود استفاده شده است. سرویس اختصاص محصولات به فروشندگان: این سرویس برای اضافه کردن محصولات ثبت شده برای فروشندگانی که ثبت‌نام کرده‌اند در نظر گرفته شده. در این سرویس، MS1 از طریق یک Message Broker (که در این دمو RabbitMQ می‌باشد)، پیام ثبت محصول را برای MS2 ارسال می‌کند و آن محصول برای فروشنده ثبت می‌شود.سرویس مدیریت لاگ‌ها: این سرویس فقط شامل یک مایکروسرویس (MS4) است که وظیفه این مایکروسرویس بازیابی اطلاعات لاگ‌های ذخیره شده در پایگاه داده Splunk می‌باشد (این پایگاه داده‌ که موسوم به Time Series Database می‌باشد برای ذخیره‌سازی داده‌هایی استفاده می‌شود که زمان عنصر کلیدی در آن‌ها است). دقت شود اتفاقاتی که در تک‌تک مایکروسرویس‌ها رخ می‌دهد، به صورت لاگ در فایل‌های مربوطه ذخیره می‌شوند و سپس این فایل‌ها از طریق یک forwarder (که در این سیستم Splunk Universal Forwarder می‌باشد) به صورت Stream به Splunk ارسال می‌شوند.علاوه بر تکنولوژی‌ها و ابزار‌های مطرح شده، از تکنولوژی Consul برای معرفی مایکروسرویس‌ها به یکدیگر استفاده می‌‌شود (علاوه بر ویژگی Service Discovery از Consul برای ذخیره‌سازی پیکربندی‌های سیستم‌های توزیع شده نیز می‌توان استفاده کرد. اما فیچر اصلی این تکنولوژی، Service Discovery است که کاری شبیه به DNS را برای مایکروسرویس‌ها انجام می‌دهد). همچنین برای ایجاد یک abstraction حول مایکروسرویس‌ها از یک API Gateway استفاده شده (برای دریافت اطاعات بیشتر درباره این موضوع می‌توانید مقاله API Gateway را بخوانید).مطابق تصویر زیر اولین Tab بیانگر سرویس اول می‌باشد که در آن می‌توان از بین فروشندگانی که ثبت‌نام نکرده‌اند، فروشندگانی را در این سیستم ثبت کرد.تصویر ۵: سرویس اول از سیستم مایکروسرویسی پیاده‌سازی شدهدومین Tab در تصویر ۶ مربوط به سرویس دوم (یعنی ثبت محصول در سیستم می‌باشد). ستون سمت چپ مربوط به محصولاتی است که از MS3 گرفته شده است.تصویر ۶: سرویس دوم از سیستم مایکروسرویسی پیاده‌سازی شده سومین Tab نیز برای سرویس سوم می‌باشد که ۲ مایکروسرویس MS1 و MS2 را درگیر می‌کند و برای ثبت یک محصول ثبت‌شده برای یک فروشنده ثبت‌نام کرده در سیستم، پیاده‌سازی شده است (در تصویر ۷ می‌توانید این سرویس را مشاهده کنید).تصویر ۷: سرویس سوم از سیستم مایکروسرویسی پیاده‌سازی شده و نهایتاً آخرین Tab مربوط به سرویس چهارم می‌باشد که در آن صفحه می‌توانید جریان درخواست‌های ارسال شده به این سیستم مایکروسرویسی را به همراه جزئیات هرکدام مشاهده کنید (هر جریان شامل یک شناسه منحصر به فرد، زمان ورود درخواست، زمان پاسخ، نام درخواست و جزئیات مربوط به مایکروسرویس‌هایی که این درخواست از آن‌ها عبور کرده است، می‌باشد). تصویر ۸: سرویس چهارم از سیستم مایکروسرویسی پیاده‌سازی شده برای رسیدن از لاگ‌های خام به لاگ‌های Correlate شده از کوئری زیر (این کوئری با زبان SPL نوشته شده است)، استفاده کرده‌ام. این کوئری دربازه‌های یک دقیقه لاگ‌های خام دریافتی را براساس شناسه هر درخواست (UID) یکپارچه می‌کند و خروجی این یکپارچه‌سازی لاگ‌ها را می‌توانید در تصویر ۸ مشاهده کنید.index=&quotwild_index&quot _index_earliest=&quot-1m&quot _index_latest=now() | sort 0 -time | eval nodeInfo = json_object(&quottime&quot, time, &quotproject&quot, project, &quotmethodName&quot, methodName, &quotflowStart&quot, flowStart, &quotflowEnd&quot, flowEnd, &quotstart&quot, start, &quotend&quot, end, &quotstatus&quot, status, &quotdata&quot, data, &quoturl&quot, url)| transaction uid| eval flowInfo = json_object(&quotuid&quot, uid, &quotnodes&quot, nodeInfo)| eval flowInfo = replace(flowInfo, &quot\\\\(.)&quot, &quot\1&quot)| eval flowInfo = replace(flowInfo, &quot\&quot\{&quot, &quot{&quot)| eval flowInfo = replace(flowInfo, &quot\}\&quot&quot, &quot}&quot)| table flowInfo| collect index=&quotcorrelate_index&quotمی‌توانید به Source Code، فایل‌های Dockerfile، فایل docker-compose و... از طریق این آدرس github دسترسی داشته باشید. این مقاله، بخشی از تمرین‌های درس معماری نرم‌افزار در دانشگاه شهید بهشتی می‌باشدمنابعhttps://medium.com/koderlabs/introduction-to-monolithic-architecture-and-microservices-architecture-b211a5955c63https://martinfowler.com/articles/microservices.htmlhttps://medium.com/hashmapinc/the-what-why-and-how-of-a-microservices-architecture-4179579423a9https://www.n-ix.com/microservices-vs-monolith-which-architecture-best-choice-your-business/#:~:text=While%20a%20monolithic%20application%20is,as%20perform%20the%20specific%20functions.https://github.com/generalCode2019/microservice_architecture.githttps://www.aparat.com/v/M9jDthttps://docs.splunk.com/Documentationhttps://www.consul.io/docshttps://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/https://material.angular.io/componentshttps://www.rabbitmq.com/documentation.html حامد رستم‌خانی حامد رستم‌خانی Sat, 12 Feb 2022 22:58:24 +0330 https://virgool.io/@rostamkhanihamed1/%D9%85%D9%81%D8%A7%D9%87%DB%8C%D9%85-containerization-%D9%88-container-orchestration-kwd288jdnwcx مقدمهآیا تا به حال از خود پرسیده اید که Container ها چه تفاوتی با ماشین‌ های مجازی دارند؟ من در این مقاله قصد دارم به معرفی Container ها و معماری آن‌ ها و همچنین همنواسازی (Orchestration) آن ها بپردازم و به این سوالی که در ابتدا مطرح کردیم، پاسخ دهم. تکنولوژی Container پس از مدت کوتاهی به یک تکنولوژی فراگیر تبدیل شد، و علت این است که ما همگی در عصر تکنولوژی ابری (cloud) به سر می‌بریم و بهره برداری از Container ها به عنوان یکی از ابزار‌های کلیدی در ابر، ضروری می باشد. کانتینر ها به عنوان برنامه های نرم‌افزاری سبک‌ وزن، مزایای متعددی دارند. این مزایا عبارتند از کاهش زمان عرضه App ها، مقیاس‌ پذیری (scalability)، سهولت مدیریت App و پشتیبانی از آن (maintainability) و نهایتاً بهبود تجربه کاربری (improve user experience) است.مقابله با بحران کانتینر حمل و نقل با کمک هوش مصنوعیدر بخش بعدی به صورت مفصل درباره Container صحبت خواهم کرد و سپس برخی از ابزار‌های پرکاربرد آن را معرفی می‌ کنم و سپس سراغ همنواسازی Container ها و تکنولوژی‌ های مربوط به آن رفته و درباره آن ها نیز به تفصیل صحبت خواهم کرد. نهایتاً برخی از شرکت‌ های ایرانی که از این تکنولوژی ها استفاده می کنند تا سازوکار مدیریتی و نرم‌افزاری خود را بهبود بخشند را معرفی می کنم. تشریح Containerقبل از پرداختن به موضوع Container بهتر است کمی درباره سیستم عامل، Hypervisor و ماشین‌ های مجازی صحبت کنیم. سیستم عامل (Operating system یا به اختصار OS) مهم‌ترین نرم‌افزار هر سیستم کامپیوتری محسوب می‌ شود و این بخش نرم‌افزاری به مدیریت بخش سخت‌افزاری کامپیوتر می‌ پردازد. علاوه بر آن سیستم عامل مسئول مدیریت و نگهداری برنامه های نرم‌افزاری می باشد که کاربران و سایر برنامه ها با آن ها در ارتباط می باشند (به عبارتی سیستم عامل یک لایه انتزاعی برای نحوه تعامل برنامه های نرم‌افزاری با منابع سخت‌افزاری فراهم می‌کند). همانطور که می دانید مسئولیت های سیستم عامل شامل زمانبندی وظایف، اختصاص دادن حافظه و مدیریت و هماهنگی پردازش‌ها است و همه این مسئولیت ها به نحوی اجرا می‌ شوند که برنامه های نرم‌افزاری بتوانند به طور مجزا و جداگانه کنار هم کار کنند.تصویر ۱: ارتباط OS با بخش نرم‌افزاری و سخت‌ افزاری یک کامپیوترهر سیستم عامل از یک بخش اصلی به نام کرنل (kernel) تشکیل شده است (به عبارتی کرنل نقش قلب سیستم عامل را بازی می‌ کند). وظیفه کرنل همانند یک پلی می باشد که برنامه های نرم‌افزاری یک سیستم کامپیوتری را از طریق پردازش داده‌هایش روی سخت‌افزار، متصل می کند. همانطور که می دانید کرنل یک ناحیه از RAM را به صورت اختصاصی در اختیار خود قرار داده است و این قسمت از دسترسی دیگر برنامه ها جدا می باشد و کرنل به برنامه‌های نرم‌افزاری کاربر اجازه نمی‌ دهد که سیستم عامل را دستکاری کنند. پس نکته مهمی که در این بخش باید درباره کرنل مدنظر داشته باشید این است که کرنل مسئول مدیریت حافظه در برنامه‌های نرم‌افزاری است. این بخش برنامه ها را اجرا می کند و در حافظه قرار می دهد و سپس مسئولیت نگهداری و مدیریت پردازش داده‌ های آن‌ ها را بر عهده می گیرد.تصویر ۲: نمای کلی از ارتباط کرنل با برنامه‌های نرم‌افزاری و منابع سخت افزاریدسترسی کرنل‌ها به منابع سخت‌افزاری نامحدود می باشد این در حالی است که برنامه‌های نرم‌افزاری (App‌‌های) کاربر باید از طریق process های واسط به سخت‌افزار دسترسی داشته باشند. یکی از این process های اصلی Hypervisor می باشد. Hypervisor بین App ها و سخت‌افزار قرار می‌ گیرد. بنابراین اگر برنامه‌ی نرم‌افزاری بخواهد با RAM یا CPU یا Disk ارتباط داشته باشد، باید ابتدا از سیستم عامل و سپس از Hypervisor اجازه بگیرد.معماری مطرح شده می تواند باعث بروز مشکلاتی می شود. به عبارت ساده این معماری چند مرحله‌ای روی سرعت، عملکرد و تجربه کاربری تأثیر بدی می گذارد. به همین علت اجرا کردن همزمان دو نوع سیستم عامل میزبان بر روی یک سخت‌افزار هزینه زیادی را به همراه خواهد داشت (هم هزینه زمانی و هم هزینه مالی). بنابراین برای حل این مشکلات (کاهش زمان دسترسی، افزایش قابلیت های نگهداری، مقیاس‌پذیری، بهبود تجربه کاربری) مهندسان سراغ راه‌حل‌ های دیگر مانند ماشین‌های مجازی و Container ها رفتند. ماشین‌ مجازی (Virtual Machine یا به اختصار VM) برنامه‌ی نرم‌افزاری است که به عنوان یک رایانه مجازی عمل می‌ کند. این برنامه روی سیستم‌عامل میزبان یا Hypervisor اجرا می‌ شود و منابع سخت‌افزاری مجازی را برای یک سیستم‌عامل میهمان مهیا می‌ کند. به عبارتی ماشین مجازی یک لایه انتزاعی حول زیرساخت تشکیل‌ دهنده یک سیستم کامپیوتری و اجزای سخت‌افزاری آن می‌ سازد و پیچیدگی‌ های مربوط به چندین سیستم‌عامل مختلف را مخفی می کند و اصولا از ماشین‌های مجازی برای بهره‌ برداری مناسب از منابع سخت‌افزاری استفاده می شود. بنابراین مشکلی که پردازش Hypervisor برای اجرای دو سیستم عامل کنار یکدیگر داشت، به واسطه VM ها برطرف می‌ شوند.یکی از مشکلاتی که ماشین‌ های مجازی دارند این است که آن ها برنامه‌های نرم‌افزاری حجیمی هستند و نیازمند بخش زیادی از حافظه کامپیوتر می باشند. همچینین VM ها مشکلاتی اعم از زمان بالای بوت شدن، پروسه نصب و پیکربندی زمانگیر یا حتی پیچیده، عملکرد پایین، نگهداری و ایجاد نسخه‌ های تکراری را دارند. همین مشکلات باعث شد مهندسان به فکر راه‌حلی مناسب‌تر بیافتند (در ادامه درباره این راه‌حل که ها می باشند صحبت می کنیم).تصویر ۳: تفاوت سلسله مراتبی و ساختاری VM با Containerدر یک جمله ساده Container، نرم‌افزار مجازی‌ سازی در سطح سیستم عامل می باشد. بنابراین همه برنامه های داخل یک کانتینر، درون فضای عملکردی یک سیستم عامل، اجرا می‌شوند و معماری آن با معماری سیستم عامل میزبان یکسان یا همراستا می باشد. پس توجه کنید که در این حالت تنها کرنل، دارای فضای اختصاصی برای خود می باشد. همین موضوع و این وضعیت باعث می‌ شود که برنامه‌های نرم‌افزاری بتوانند بدون عبور از سد سیستم عامل میهمان و بعد هایپروایزر به منابع سخت‌افزاری دسترسی داشته باشند و در نتیجه کارایی و performance بهتری نسبت به روش‌های دیگر ارائه دهند.کانتینر ها به کاربران سیستم این امکان و قابلیت را می‌ دهند تا برنامه‌ های نرم‌افزاری و پیش نیازهای (dependency های) آن‌ ها را به صورت یک فرآیند ایزوله شده در سیستم اجرا کنند. تمام اجزای ضروری مورد نیاز یک برنامه نرم افزاری در قالب یک image بسته‌ بندی می‌ شوند و این image در یک محیط ایزوله اجرا می شود و منابع سخت افزاری مورد نیاز مانند CPU، فضای حافظه و فضای ذخیره سازی را با سیستم عامل به اشتراک نمی گذارد. اینکار باعث می‌ شود که فرآیند‌های اجرایی موجود در Container، نتوانندسایر فرآیندهای خارج از محدوده خود را مشاهده کنند.یکی از تفاوت‌های کلیدی و اصلی Container با VM این است که Container به جای مجازی‌سازی سخت‌افزار، سیستم عامل را مجازی‌سازی می‌ کند. هر Container توسط یک موتور Container (در تکنولوژی داکر آن را به نام daemon می شناسند) اجرا می شود و هر Container یک سیستم پیکربندی مبتنی بر فایل دارند. به همین دلیل می‌توان آن ها را نسخه‌بندی و پشتیبانی کرد و مورد نظارت قرار داد. پس در نتیجه می توان گفت که امکان انتقال و کلون کردن در Container ها نسبت به VM ها آسان‌تر می باشد، Container ها نیازمند حافظه کمتری می باشند و چند Container را می‌توان روی یک سیستم کامپیوتری فیزیکی اجرا کرد (البته چندین VM را نیز می‌ توان روی یک سیستم فیزیکی اجرا کرد ولی منظور این بود که Container های بیشتری را نسبت به VM ها می توان روی یک سیستم فیزیکی اجرا کرد).اگر بخواهیم مزایا و معایب Container ها را مطرح کنیم، می توانیم به شکل زیر آن ها را لیست کنیم.مزایای Container انتشار سریع تر و ساده تر برنامه‌های نرم‌افزاری (کاهش زمان عرضه برنامه‌ها)امکان انتقال (مهاجرت)، پشتیبان‌گیری آسان‌تر به دلیل اندازه کوچک‌ترایزوله سازی در سطح برنامه‌های نرم‌افزاریمصرف حافظه کمتر نسبت به ماشین مجازیاندازه گیری و پایش دقیق استفاده از منابع پردازشیارتباط سریع با سخت‌افزار که درنتیجه منجر به کارایی بالا می شودخودشمول بودن (همه پیش نیاز‌های یک Container درون خود قرار دارد)مطابقت بالا با معماری‌های مدرن نرم‌افزاری مانند مایکروسرویس‌ها و ساختار ابرمعایب Container معماری Container محدود به معماری محیطی است که در آن (میزبان) اجرا می شود (یعنی لینوکسی یا ویندوزی بودن میزبان در اجرای Container ها تاثیر می‌گذارد).بلوغ Container ها نسبت به VM ها کمتر بوده است و به همین دلیل تضمینی برای عملکرد آن‌ها در مقیاس‌های بزرگ وجود ندارد (البته هنوز تضمینی وجود ندارد).وقتی با کانتینر کار می کنید، شبکه سازی می تواند مشکل باشد. شما باید اتصال شبکه خوبی را حفظ کنید در حالی که فعالانه سعی می کنید کانتینرها را ایزوله نگه دارید.کانتینر ها به دلیل اینکه یک لایه اضافی روی زیرساخت ایجاد می کنند نیاز به نگهداری و مدیریت دارند که همین موضوع، نیاز به کار بیشتر را می طلبد. آموزش و یادگیری اضافی مفهوم جدید یکی دیگر از معایب پیش روی توسعه‌دهندگان و تیم‌های IT در استفاده و بهره برداری از Container می باشد.از آنجا که در Container ها برنامه های نرم‌افزاری به طور کامل مجزا نشده اند، به اندازه ماشین‌های مجازی امن نمی باشند.تشریح Container Orchestrationهنگامی که می خواهیم برنامه های نرم افزاری خود را روی چند سیستم میزبانی مختلف مقیاس دهیم، توانایی مدیریت هر سیستم میزبان و پیچیدگی های زیرساختی هرکدام از میزبان‌ها، کاری نسبتاً چالش برانگیز به نظر می رسد. همنواسازی (Orchestration) اصطلاحی است که به زمان‌بندی Container ها، مدیریت Cluster ها و به احتمال زیاد تدارک میزبان‌های بیشتر اشاره می کند. منظور از زمان‌بندی Container ها همان توانایی بارگذاری یک فایل سرویس روی یک سیستم میزبان و تعیین شیوه اجرای آن Container می باشد. عمل زمان‌بندی صرفاً به عمل خاص بارگذاری اشاره نمی کند بلکه در واقع ابزارهای زمانبندی مسئول مدیریت سرویس‌ها در تمامی سیستم های میزبان می باشند.همچنین منظور از مدیریت کلاستر اشاره به فرایند کنترل کردن گروهی از میزبان‌ها دارد که این مدیریت می‌تواند شامل اضافه کردن و یا حذف میزبان‌ها از یک کلاستر، دریافت اطلاعات در مورد وضعیت فعلی میزبان‌ها و Container ها، و شروع یا اتمام کار پردازش‌ها باشند. نکته قابل توجه این است که مدیریت کلاستر ارتباط نزدیکی با مدیریت زمانبندی باید داشته باشد، به دلیل اینکه ابزارهای زمان‌بندی باید به تمامی میزبان‌ها در یک یا چند کلاستر دسترسی داشته باشند تا بتوانند Container ها یا سرویس ها را زمان‌بندی کنند.یکی از اصلی ترین مسئولیت‌های ابزار زمان‌بندی، انتخاب میزبان می باشد. اگر کنترل کننده سیستم تصمیم بگیرد که یک Container را روی یک کلاستر اجرا کند، این ابزار زمان‌بندی است که در اغلب موارد مسئول انتخاب خودکار و پیشنهاد یک میزبان می‌ باشد. یعنی کنترل کننده سیستم می‌تواند به صورت خاص و بر اساس نیازها یا علاقه‌مندی‌ هایش، Container هایی را به ابزار زمان‌بندی معرفی کند ولی این ابزار زمان‌بندی می باشد که در نهایت مسئول اجرای این نیازمندی هاست.تصویر ۴: نمونه‌ای از عملکرد بخشscheduler در همنواساز کانتینراصولا ابزارهای زمان‌بندی از مکانیزم‌های override استفاده می‌ کنند که کنترل کنندگان سیستم می‌توانند از آن برای تنظیم و پیکربندی دقیق فرآیندهای انتخاب جهت رفع نیازمندی های خود بهره بگیرند. به عنوان مثال، اگر دو Container به دلیل این که به شکل واحد و یکسانی عمل می کنند، همواره روی میزبان یکسانی اجرا می‌شوند، این اتحاد بین Container ها را می‌توان در اغلب دستوراتی در طی زمان‌بندی به این ابزار ها اعلام کرد. به طور مشابه اگر دو Container نباید روی میزبان واحدی قرار بگیرند، این مورد را نیز می‌توان در طی پروسه زمان‌بندی تعیین و اعمال کرد.ابزار‌ ها و تکنولوژی های متن بازبرای پیشنهاد درباره ارائه‌دهندگان تکنولوژی Container می‌توان به ۳ تکنولوژی زیر اشاره کرد که هر ۳ به صورت متن باز و رایگان در اختیار استفاده‌کنندگان‌شان قرار می‌گیرد:تکنولوژی Dockerداکر یک نرم‌افزار کانتینری سازی (containerization) می باشد که مجازی سازی را در سطح سیستم عامل انجام می دهد. عرضه اولیه این نرم افزار در سال ۲۰۱۳ اتفاق افتاد و به زبان برنامه نویسی Go (زبان Golang) نوشته شده است. نحوه عملکرد داکر به این صورت است که Container ها را از یکدیگر جدا می کند و نرم‌افزار، کتابخانه ها و فایل های پیکربندی را در قالب image بسته بندی می کند و نهایتاً به واسطه docker daemon آن ها را اجرا می کند و آن ها می توانند از طریق کانال های کاملاً مشخص با یکدیگر ارتباط برقرار کنند.تصویر ۵: معماری سطح بالای Dockerتکنولوژی CoreOSتکنولوژی CoreOS یک سیستم عامل متن باز و سبک وزن است که بر اساس هسته لینوکس پایه گذاری شده است و برای کانتینر کردن برنامه های شما طراحی شده است (شبیه به ابزار LXC). این زیرساخت استقرار آسان کلاستری را ارائه می دهد و در عین حال بر خودکارسازی، امنیت، قابلیت اطمینان و مقیاس پذیری تمرکز می کند.تصویر ۶: معماری سطح بالای CoreOSتکنولوژی Containerd تکنولوژی Containerd به عنوان یک موتور اجرا کننده Container برای لینوکس و ویندوز عمل می کند و چرخه حیات کامل Container های سیستم میزبان خود را مدیریت می کند. بنابراین این تکنولوژی از انتقال و ذخیره سازی image ها و اجرای Container ها و نظارت بر آن ها گرفته تا ذخیره سازی سطح پایین و مدیریت شبکه و... را تحت کنترل خود دارد و این مراحل را مدیریت می کند.تصویر ۷: معماری سطح بالای Containerdهمچنین درباره تکنولوژی‌ های همنواسازی Container می توان به مورد زیر اشاره کرد (البته تکنولوژی های متنوعی نیز در این حوزه وجود دارند که می توانید آن‌ها را از طریق منابع در اختیار گذاشته شده، مطالعه کنید):ابزار Kubernetesابزار Kubernetes یک ابزار همنواساز کانتینرها می باشد که به صورت متن باز و رایگان در اختیار کاربران خود قرار گرفته است. این ابزار با بخش زمان‌بندی عالی و مدیر منابع برای استقرار کانتینرها به روشی کارآمد و با دسترسی پذیری بالایی ساخته شده است.تصویر ۸: معماری سطح بالای K8sشرکت‌ های ایرانیهمچنین بین شرکت‌های ایرانی می توان به شرکت معتبر زیر اشاره کرد که از Container ها و همنواسازی Container در فرایند‌های توسعه خود استفاده می‌کنند.شرکت ابرآروانشرکت ابر آروان (یا در اصل شرکت نویان ابر آروان) عرضه‌ کننده‌ی زیرساخت یکپارچه ابری در ایران می باشد که همگام با دانش روز دنیا، طراحی و پیاده‌سازی شده است. هم اکنون طیف گسترده‌ای از پر بازدیدترین و شناخته‌ شده‌ ترین وب‌ سایت‌ ها و کسب‌ و کارهای آنلاین در کنار سامانه‌ های حساس دولتی و بانک‌ ها از راهکار های ابری آروان بهره می‌ برند.این مقاله، بخشی از تمرین‌های درس معماری نرم‌افزار در دانشگاه شهید بهشتی می‌باشدمنابعhttps://medium.com/computethecloud/operating-system-concepts-4dff340775abhttps://afteracademy.com/blog/what-is-kernel-in-operating-system-and-what-are-the-various-types-of-kernelhttps://spin.atomicobject.com/2019/05/24/containerization-pros-conshttps://www.softwaretestinghelp.com/container-softwarehttps://containerd.io/https://www.docker.com/https://www.redhat.com/en/topics/containers/what-is-container-orchestrationhttps://devopscube.com/docker-container-clustering-tools حامد رستم‌خانی حامد رستم‌خانی Fri, 24 Dec 2021 23:55:11 +0330 https://virgool.io/@rostamkhanihamed1/%D8%AA%D8%AD%D9%88%DB%8C%D9%84-%D9%85%D8%B3%D8%AA%D9%85%D8%B1-continuous-delivery-as35mhgkl085 مقدمهمفهوم Continuous Delivery (CD) و در کل CI/CD، اصطلاحاتی هستند که به کرات در حوزه DevOps مورد استفاده قرار می‌ گیرند. CI/CD به سازمان‌ ها اجازه می‌ دهد تا نرم‌ افزار هایشان را به سرعت و به شکلی کار آمد به کابرانشان منتقل کنند. CI/CD فرآیند مؤثری را برای عرضه سریع‌ تر محصولات به بازار ارائه می‌ دهد.قبل از ظهور سیستم‌ های توزیع شده (مانند مایکروسرویس‌‌ ها)، اکثر بخش‌ های فرآیند تولید نرم‌ افزار به صورت دستی انجام می‌ شد ولی با ترند شدن این سیستم‌ ها، اعمال دستی تغییرات روی تک‌ تک مولفه‌ ها، امری دشوار و حتی غیرممکن شد. به همین دلیل مهندسان نرم‌ افزار به دنبال رویکردی بودند که در سریع‌ ترین زمان ممکن و با کمترین هزینه، نرم‌ افزار را انتشار و تحویل دهند. در ادامه با بوجود آمدن شیوه‌ های جدید Deployment مانند استقرار‌ های مبتنی بر Container و Container Orchestration، خودکار سازی بخش‌ های مختلف فرآیند تولید نرم‌ افزار، آسان‌ تر و سریع‌ تر شد.در این مقاله سعی ما بر این است که مفهوم CD را به صورت کامل شرح دهیم. اما اصولا در DevOps بیشتر CI همراه با CD استفاده می‌ شود و CI/CD کنار یکدیگر مورد بحث قرار می‌ گیرند. CI به فرآیندی اشاره دارد که از آن طریق فیچرهای جدید به صورت خودکار در مخزن (Repository) اصلی ادغام می‌ شوند اما CD به فرآیندی اشاره می‌ کند که از آن طریق نرم‌ افزار دائماً آماده استقرار روی سرور‌ها می‌ شود.خط لوله نفت (oil pipeline) در شمال چینبه طور کلی، مفاهیم CI/CD ارتباط تنگاتنگی با فرهنگ Agile دارند که در آن تمرکز اصلی فرآیند‌ های تولید نرم‌افزار روی بهبود مستمر و انتشار قابلیت‌ های جدید در بازه‌ های زمانی بسیار کوتاه است.تشریح تحویل مستمرتحویل مستمر (CD) توانایی دریافت انواع تغییرات، از جمله افزودن فیچرهای جدید، تغییرات در پیکربندی ها، رفع باگ‌ ها و آزمون ها می‌ باشد که در تولید ایمن، سریع و پایدار نرم افزار کمک زیادی می‌ کند. CD در ادامه‌ی فرآیند CI می‌ باشد که در آن تغییرات کد به صورت خودکار در قالب فرآورده‌های Build (مانند jar فایل یا فرمت‌های اجرایی دیگر) برای استقرار آماده می شوند. این فرآورده‌های (Artifacts) آماده را می توان در محیط های آزمایشی برای آزمایش های بیشتر مستقر کرد یا در محیط تولید برای بهره برداری مستقر کرد. تمامی این فرآیند تضمین می کند که کد تغییر داده شده به طور کامل تست می‌ شود و همیشه آماده استقرار می‌ باشد.در واقع CD این تضمین را ایجاد می‌ کند که تیم مهندسی در هر لحظه‌ای که اراده کند، نسخه جدید نرم‌ افزار باید قابل‌ انتشار باشد و بهره برداران بدون هیچ گونه مشکل و به صورت پایداری از سرویس‌ها توسعه داده شده استفاده کنند.چرا تحویل مستمر؟یکی از طرز فکر‌های اشتباهی که در بحث CD وجود دارد این است که اگر می خواهیم نرم‌افزار را به دفعات بیشتری مستقر کنیم، باید سطوح پایین‌تری از پایداری (stability) و قابلیت اطمینان (reliability) را در سیستم های خود بپذیریم. اما در واقعیت، تحقیقات نشان می دهند که این طرز فکر درست نیست و تیم های با عملکرد بالا به طور مداوم و مستمر سرویس‌ها را سریعتر و قابل اطمینان تر از رقبای کم عملکرد خود ارائه می دهند. دقت شود که این موضوع حتی در حوزه های بسیار پیچیده و پیشرفته مانند حوزه‌های مالی و دولتی نیز صادق می باشد. بنابراین وجود تحویل مستمر پایدار و مطمئن، مزیت رقابتی باورنکردنی را برای سازمان هایی که مایل به سرمایه گذاری در حوزه DevOps هستند، فراهم می کند.مزایای تحویل مستمردر واقع به نظر من یکی از مزیت های اصلی CD این است که فرآیند دریافت بازخورد (feedback) از کاربران را سریع‌تر می‌ کند. یعنی هنگامی که توسعه دهندگان با سرعت بالایی فیچر های جدید را در معرض استفاده کاربران نهایی نرم‌افزار یا اپلیکیشن قرار می‌دهند، به همان میزان هم سریع‌تر می‌توانند از آن ها بازخورد بگیرند و در صورت نیاز بلافاصله دست به اِعمال تغییرات بزنند. به طور کلی، دیگر مزیت‌ های CD عبارتند از:انتشار نرم‌افزار کم خطر: هدف اولیه از تحویل مستمر این است که استقرار نرم‌افزار بدون هیچ دردسری و با ریسک کمی، در هر زمان و بر اساس تقاضای مشتری انجام شود. با استفاده از الگوهایی مانند استقرارهای سبز - آبی (BlueGreenDeployment)، می‌ توان به انتشار‌های بدون وقفه دست یافت که کاربران متوجه این تغییرات نشوند.کمترین زمان برای تحویل به بازار: همانطور که می‌ دانید عادی می‌ باشد که مراحل یکپارچه‌سازی (integration)، آزمون و برطرف کردن خطا‌ها در انتشار و تحویل‌ های سنتی نرم افزار، هفته ها یا حتی ماه ها طول بکشد. اما در CD توسعه‌ دهندگان مراحل ساخت، استقرار، آماده سازی محیط ها و انجام فرآیندهای آزمون integration و regression را در کار‌های روزانه خود می‌ گنجانند و دیگر نیازی نیست که تیم عملیات (Operation) این مراحل را جداگانه انجام دهد (یعنی در روال سنتی تیم های توسعه و عملیات برای انجام مراحل ذکر شده هزینه زمانی بسیار زیادی صرف می کردند ولی انجام این مراحل توسط تک تک توسعه‌ دهندگان باعث می‌ شود که هزینه زمانی رفت و برگشت بین تیم ها کاهش چشم‌گیری یابد). همچنین به واسطه CD می توان از حجم زیادی از دوباره کاری ها اجتناب کرد.کیفیت بالاتر: با توجه به اینکه توسعه‌ دهندگان ابزارهای خودکاری دارند که در عرض چند دقیقه regression ها را کشف می‌ کنند، تیم‌ها زمان بیشتری می یابند تا تلاش خود را بر روی آزمون های سطح بالاتر مانند آزمون اکتشافی (Exploratory Testing)، آزمون قابلیت استفاده (Usability Testing)، آزمون کارایی (Performance Testing) و آزمون امنیتی (Security Testing) متمرکز کنند. بنابراین با ایجاد یک خط لوله استقرار، این فعالیت ها می توانند به طور مداوم در طول فرآیند تحویل انجام شوند و از همان ابتدا اطمینان حاصل شود که محصولات و سرویس های تولیدی از بالاترین کیفیت برخوردار هستند.هزینه های پایین تر: هر محصول یا سرویس نرم افزاری موفقی در طول عمر خود به طور قابل توجهی تکامل می یابد و چرخه های متعددی دارد. با خودکارسازی مراحل ساخت، آزمایش، استقرار و مهیاسازی محیط‌ها بسیاری از هزینه‌های ثابت مرتبط با فرآیند انتشار، هزینه ایجاد و ارائه تغییرات تدریجی در نرم‌افزار به‌طور قابل ملاحظه‌ای کاهش می یابند و این امکان بوجود می‌ آید که هزینه های صرف جویی شده در مراحل دیگر مورد استفاده قرار گیرند.تیم های شادتر: تحقیقات انجام شده نشان می دهد که تحویل مستمر باعث کاهش فشار و کاهش فرسودگی تیم ها می شود. علاوه بر این، هنگامی که نرم افزار به دفعات بیشتری منتشر می شود، تیم های تحویل نرم افزار می توانند فعالانه تر با کاربران درگیر شوند، یاد بگیرند که کدام ایده ها کارآمدتر هستند و کدام نه، و همچنین نتایج کاری را که انجام داده اند، از نزدیک ببینند. با حذف فعالیت‌های دردناک و کم‌ارزش مرتبط با تحویل نرم‌افزار، می‌توانیم بر روی چیزهایی که از اهمیت بیشتری برخوردار هستند، تمرکز کنیم و به طور مداوم تیم‌ ها و کاربران خود را خوشحال کنیم.تفاوت تحویل مستمر و استقرار مستمردر ادبیات DevOps اغلب دو اصطلاح تحویل مستمر (Continuous Delivery) و استقرار مستمر (Continuous Deployment) به جای یکدیگر استفاده می شوند ولی در واقعیت این دو اصطلاح به مفاهیم متفاوتی اشاره دارند. Continuous Deployment یعنی این که هر تغییری در نرم افزار به صورت خودکار (یا بر اساس یک زمان بندی از قبل تعیین شده) در محیط عملیات (Production Environment) منتشر شود. ولی Continuous Delivery به این معنی است که هر تغییر در نرم افزار، آماده انتشار در هر محیطی می‌ باشد. دقت شود در Continuous Delivery ممکن است تغییرات به دلایل مختلفی آماده انتشار باشند ولی منتشر نشوند (مثلا به خاطر تصمیم‌ گیری ها و سیاست‌ های کسب و کاری ممکن است از انتشار یک نسخه خاص جلوگیری شود).در تصویر ۱ می‌توانید تفاوت هر سه اصطلاح Continuous Integration و Continuous Deployment و Continuous Delivery را به صورت شماتیک مشاهده کنید:تصویر ۱: تفاوت یکپارچه‌سازی مداوم، تحویل مداوم و استقرار مداومدقت شود که در نبود CD، انتشار نرم افزار به عنوان یک گلوگاه برای تیم ها و نهایتاً برای محصول عمل می کند. مراحل دستی و غیر خودکار، باعث می شود که انتشارها نا مطمئن، با تاخیر و پر از خطا باشند.ابزار‌ ها و تکنولوژی های متن بازمجموعه ابزار و تکنولوژی هایی که ممکن است توسط یک تیم برای تحویل مستمر انتخاب شود به عوامل متعددی بستگی دارد. این عوامل می تواند شامل هزینه (به عنوان یک عامل اصلی)، محدودیت های سمت مشتری (عامل مهم دیگری است) یا ... باشد که باید آن ها را نیز در نظر گرفت. بنابراین، ابتدا باید نیاز های خاص و اکوسیستم را تحلیل کرد و سپس بر اساس آن ها نوع ابزار را انتخاب کرد.در این بخش چندین مورد از ابزارها و تکنولوژی های متن‌باز CD که در دنیا معروف و پر کاربرد هستند را بررسی می‌کنیم و درباره هر کدام به صورت مختصر توضیحاتی را ارائه می‌دهیم. البته باید دقت کرد که بعضی ابزار‌ ها و تکنولوژی ها مربوط به مراحل مختلف تحویل مستمر می‌ باشد و به خودی خود کاربرد مجزایی دارند:ابزار Argo CDابزار Argo CD یک ابزار تحویل مستمر GitOps برای Kubernetes است. Argo CD یک پروژه متن باز است که در حال حاضر در بنیاد CNCF در وضعیت توسعه و رفع باگ قرار دارد. این ابزار از مخازن Git برای ذخیره وضعیت برنامه های اجرا شده در Kubernetes استفاده می کند، همچنین برنامه ها را مانیتور می کند و می تواند خوشه های Kubernetes را به حالت دلخواه و Customize، مجدداً همگام سازی کند. رویکرد نوآورانه ای که این ابزار دارد به شما امکان می‌ دهد چندین حالت دلخواه یک برنامه Kubernetes را با استفاده از branch ها و tag ها و به کمک commit Git ذخیره کنید. Argo CD یک محیط انعطاف پذیر را برای مدیریت پیکربندی های Kubernetes در طول فرآیند تولید نرم افزار فراهم می کند.تصویر ۲: معماری سطح بالای ابزار Argo CDابزار CircleCIابزار CircleCI ابزاری متن باز برای CI/CD می باشد و شامل ویژگی هایی برای همنواسازی job ها (یعنی می توان چندین تسک مختلف را برای رسیدن به یک هدف خاص orchestracte کرد)، پیکربندی منابع، ذخیره سازی، اشکال زدایی، امنیت و گزارش های داشبورد می باشد. CircleCI با ابزارهای مختلفی از جمله GitHub، Heroku، Slack و Docker یکپارچه می شود. ابزار CircleCI در سه سطح موجود است که یکی از آن ها رایگان بوده و شما می‌ توانید آن را در فضای ابری یا سرور‌های لینوکسی، ویندوز و مک استفاده کنید.تصویر ۳: معماری سطح بالای CircleCIمحصول Jenkins Xمحصول Jenkins X نسخه به روز شده Jenkins معروف می باشد و در این محصول از نسخه‌ های جدیدتر جاوا و maven پشتیبانی می شود. همچنین این محصول بر پایه ی ویژگی های موجود در Jenkins و با قابلیت های متناسب با گردش کار Kubernetes و Docker تولید شده است. Jenkins X شامل ویژگی هایی برای pipelines از پیش ساخته شده، پشتیبانی یکپارچه با GitOps، محیط های پیش نمایش خودکار و یکپارچه سازی بازخورد ها می باشد (یعنی محیط هایی را فراهم کرده است که به صورت خودکار در مورد commit ها، خطا‌ها و درخواست‌ های pull پیش نمایشی به کاربر نشان داده و در مورد هر کدام کامنت مناسبی ارائه دهد). Jenkins X قابلیت یکپارچه سازی با Tekton، Prow، Helm، Knative و Skaffold را نیز دارد. می‌ توانید از آن در سیستم‌ عامل های لینوکس، مک یا ویندوز بهره ببرید.تصویر ۴: معماری محصول نرم‌افزاری Jenkins Xشرکت‌ های ایرانیدر بین شرکت‌ های ایرانی که در آن ها از ابزار‌های تحویل مستمر بهره برده می‌شود، می‌ توان به شرکت‌ های زیر اشاره کرد:شرکت ابرآروانشرکت ابر آروان (یا در اصل شرکت نویان ابر آروان) عرضه‌ کننده‌ی زیرساخت یکپارچه ابری در ایران می باشد که همگام با دانش روز دنیا، طراحی و پیاده‌سازی شده است. هم اکنون طیف گسترده‌ای از پر بازدیدترین و شناخته‌ شده‌ ترین وب‌ سایت‌ ها و کسب‌ و کارهای آنلاین در کنار سامانه‌ های حساس دولتی و بانک‌ ها از راهکار های ابری آروان بهره می‌ برند.ابرآروان محصولات و خدمات مختلفی اعم از شبکه‌ی توزیع محتوا (CDN)، DNS ابری (DNS Cloud)، امنیت ابری (Cloud Security)، زیرساخت ابری (IaaS)، فضای ابری (Cloud Storage)، پلتفرم ویدیو و پخش زنده (VoD & Live Streaming) و... را در اختیار مشتریان خود قرار می دهد. یکی از اصلی ترین ابزار‌ هایی که این شرکت از آن بهره می‌ برد، تحویل مستمر و در کل CI/CD می باشد. مطابق تصویر زیر می توانید معماری CI/CD را از دید پلتفرم ابری آروان مشاهده کنید.تصویر ۵: نقش pipeline یکپارچه‌سازی و تحویل مستمر در پلتفرم شرکت ابرآروانشرکت ابر زسیکی دیگر از شرکت‌های ایرانی که از ابزار CI/CD و به صورت خاص تحویل مستمر به خوبی توانسته بهره ببرد، شرکت ابر زس می باشد. یکی از موضوعاتی که شرکت ابر زس درباره آن صحبت کرده است، بهره بردن از سازوکار‌های هوش مصنوعی برای بهبود pipeline های CI/CD و افزایش سرعت زیرساخت‌ های استقرار نرم‌ افزار می‌ باشد.جمع‌ بندیبرای جمع بندی باید این نکته را اضافه کنم که فرایند Continuous Delivery و Infrastructure as Code و Monitoring به طور قابل ملاحظه ای مکمل یکدیگر هستند. از تحویل مستمر برای کنترل تغییرات در محیط عملیاتی استفاده می شود و اصولا در آن از استراتژی های استقرار مانند Blue-Green Deployment و همچنین تکنیک Feature Flags (یا Feature Toggles) نیز پشتیبانی می شود.با توجه به ارزش هایی که CD برای شرکت ها و سازمان ها ایجاد می کند، آن را به یک نیاز ضروری تبدیل کرده است. در نتیجه برای رساندن ارزش به مشتریان نهایی، باید محصول را به طور پیوسته و بدون خطا منتشر کرد. Pipeline های انتشار پیشرفته به توسعه دهندگان این اجازه را می دهد که فیچرهای جدید را سریع و مطمئن منتشر کنند. با کمک CD، رفع خطاها در محیط عملیات و اضافه کردن فیچرهای جدید بسیار سریع تر و با اطمینان بالاتر انجام خواهد شد و به دست مشتری خواهد رسید.این مقاله، بخشی از تمرین‌های درس معماری نرم‌ افزار در دانشگاه شهید بهشتی می‌باشدمنابعhttps://continuousdelivery.comhttps://medium.com/driven-by-code/the-journey-to-ci-cd-b1872927c36bhttps://towardsdatascience.com/continuous-integration-continuous-delivery-myths-pitfall-and-practical-approach-aaec22edacc5https://www.softwaretestinghelp.com/best-continuous-delivery-toolshttps://jenkins-x.iohttps://argo-cd.readthedocs.io/en/stablehttps://circleci.comhttps://devops.com/7-popular-open-source-ci-cd-toolshttps://xaas.irhttps://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%86https://pvlearn.com/%D8%AA%D9%81%D8%A7%D9%88%D8%AA-%D9%87%D8%A7%DB%8C-jenkins-%D9%88-circleci حامد رستم‌خانی حامد رستم‌خانی Mon, 20 Dec 2021 09:47:05 +0330 https://virgool.io/@rostamkhanihamed1/%D8%AF%D8%B1%DA%AF%D8%A7%D9%87-api-%DB%8C%D8%A7-api-gateway-yhykrqidte6n دروازه قرآن شیراز مقدمهقبل از پرداختن به موضوع API Gateway کمی درباره معماری مایکروسرویس‌ توضیحاتی را ارائه می‌دهم تا درباره کاربرد API Gateway و در کل مدیریت API ها، آشنایی پیدا کنید.همانطور که می‌دانید هدف مایکروسرویس‌ها تجزیه (decompose) و جداسازی (decouple) کافی برنامه‌های نرم‌افزاری به مولفه‌ها و ماژول‌های loosely coupled است، برخلاف برنامه‌های نرم‌افزاری یکپارچه (monolithic) که در آن ماژول‌ها به‌شدت coupled می‌باشند و به عنوان یک کل بزرگ و یکدست مستقر می‌شوند. در معماری مایکروسرویس، مایکروسرویس‌های مختلف براساس مسئولیت‌های اختصاص داده شده، مستقر می‌شوند و هرکدام دارای مدل API دقیق خود برای ارائه سرویس به مشتریان مختلف (وب، موبایل و APIهای شخص ثالث) هستند.تصویر۱: ارتباطات مختلف (Sync و Async) در مایکروسرویس‌هاهمانطور که در تصویر (۱) مشاهده می‌کنید، مشتریانان مختلف درحال ارتباط مستقیم با مایکروسرویس‌ها هستند. چالش‌های موجود در این نوع از ارتباط را می‌توان به شکل زیر لیست کرد:در حالتی که مایکروسرویس‌ها API هایشان را در معرض دید مشتری قرار می‌دهند، ممکن است مشتری برای دیدن یک صفحه خاص از چندین مایکروسرویس مختلف درخواست اطلاعات کند و در چندین مرحله‌ی رفت و برگشتی داده‌های مورد نیاز صفحه مدنظرش را بدست آورد. این کار ممکن است حتی برای دستگاه‌های دارای شبکه کم کار (قدرت عملیاتی شبکه پایین) مانند تلفن همراه، دشوار و در شرایطی غیرممکن نیز می‌باشد.پذیرش پروتکل‌های ارتباطی گوناگون (مانند gRpc، thrift، REST، AMQP و...) موجود در مایکروسرویس‌ها، برای مشتری چالش برانگیز و سخت می‌باشد.عملکردهای مشترک در تمامی مایکروسرویس‌ها (مانند احراز هویت، مجوز‌های دسترسی، ورود به سیستم و...) باید در هر مایکروسرویس پیاده‌سازی شوند.ایجاد تغییرات در مایکروسرویس‌ها بدون ایجاد اختلال در اتصال مشتری، دشوار خواهد بود. به عنوان مثال هنگام ادغام یا تقسیم مایکروسرویس‌ها، ممکن است نیاز به اعمال تغییر در کد‌های سمت client وجود داشته باشد.تشریح API Gatewayبرای برطرف کردن چالش‌های ذکر شده در قسمت بالا، یک لایه اضافی معرفی شده است که بین مشتری (Client) و سرور قرار می‌گیرد و به عنوان یک reverse proxy برای مسیریابی درخواست‌های ارسالی از مشتری به سرور عمل می‌کند (در شبکه‌های کامپیوتری، reverse proxy نوعی از سرور پروکسی است که منابع مورد نیاز مشتری از سمت یک یا چند سرور بازیابی می‌شود. سپس این منابع به مشتری ارسال می‌شوند و به نظر می‌رسد که از خود سرور پروکسی معکوس ارسال شده است. از این رویکرد عمدتاً برای load balancing استفاده می‌شود). API Gateway مشابه الگوی facade در پارادایم شی‌گرا، یک نقطه ورودی واحد (Single Entry Point) برای تمامی APIها فراهم می‌کند که معماری سیستم داخلی را محصور می‌کند.اگر بخواهیم به طور خلاصه API Gateway را تعریف کنیم باید بگوییم که API Gateway به عنوان یک مولفه یا یک ابزار در رویکرد مدیریت API عمل می‌کند (پس توجه به این نکته مهم است که بدانیم، مدیریت API با API Gateway یکسان و تبادل پذیر نیستند).تصویر۲: نمونه‌ای از ارتباطات مایکروسرویس‌ها با وجود API Gatwayقابلیت‌های API Gateway:در این قسمت برخی از قابلیت‌ها و عملکرد‌هایی که یک API Gateway می‌تواند داشته باشد را به صورت لیستی ذکر می‌کنیم (دقت شود API Gateway می‌تواند قابلیت‌های بیشتری هم داشته باشد ولی در این بخش ما مهم‌ترین آن‌ها را ذکر می‌کنیم):مسیریابی (Routing): با احاطه کردن سیستم داخلی و جدا کردن آن از مشتریان، یک نقطه ورودی واحد را برای مشتری فراهم می‌کند تا با سیستم مایکروسرویس‌ها به صورت غیرمستقیم ارتباط برقرار کند. پس عمل مسیریابی سرویس‌ها و مایکروسرویس‌های داخلی توسط خود API Gateway انجام می‌گیرد.احراز هویت و اعطای مجوز (Authentication & Authorization): در API Gateway می‌توان درخواست‌ های ورودی به سیستم را با استاندارد‌ها و پروتکل‌های امنیتی کنترل کرد و همچنین تدابیر امنیتی لازم را برای دسترسی به مایکروسرویس‌ها اعمال کرد.کشف سرویس (Service discovery): یکی از عملکرد‌هایی که API Gateway می‌تواند داشته باشد، کشف خودکار مایکروسرویس‌ها در سیستم داخلی است. یعنی با اضافه شدن یا کم شدن مایکروسرویس‌های جدید به سیستم، API Gateway می‌تواند به صورت خودکار تغییرات را تشخیص دهد و پیکربندی‌های لازم را برای برقراری ارتباط آن مایکروسرویس‌ها با مشتری فراهم کند.کَش کردن پاسخ‌ها (Response caching): یکی دیگر از قابلیت‌های خوب API Gateway ذخیره‌سازی موقت پاسخ‌ها و نتایج ایجاد شده توسط مایکروسرویس‌ها می‌باشد و این کار تاثیر چشم‌گیری روی performance سیستم دارد (البته کَش کردن پاسخ‌ها هنگامی می‌تواند موثر واقع شود که تعداد درخواست‌های زیادی در بازه کوتاهی به سمت سیستم روانه شوند).محدود کردن نرخ درخواست‌ها (Rate limiting): برای کنترل نرخ درخواست‌هایی که به سیستم وارد می‌شوند، می‌توان از استراتژی Rate Limit کمک گرفت و ترافیک ورودی را محدود کرد. می‌توان از این استراتژی برای جلوگیری از حملات DoS و Brute force استفاده کرد.متعادل‌سازی بار (Load balancing): قابلیت دیگری که API Gateway می‌تواند داشته باشد، توزیع ترافیک ورودی به سیستم می‌باشد. یعنی API Gateway می‌تواند با الگوریتم‌ها و استراتژی‌های مختلفی درخواست‌های دریافتی را بین منابع Back-end توزیع کند.الگوی BFFالگوی Backend for Frontend (BFF) مشتقی از الگوی API Gateway است و به جای یک نقطه ورودی واحد برای تمامی مشتریان، چندین Gateway را براساس نوع مشتری ارائه می‌دهد. هدف از این الگو ایجاد APIهای متناسب با نیازهای هر مشتری می‌باشد. به کمک این الگو می‌توان گلوگاه‌های یک API Gateway عمومی را از بین برد.تصویر۳: API Gateway مایکروسرویس‌ها با استفاده از الگوی BFFاگر نیازمندی‌های بین مشتری‌ها (IOS، اندروید، مرورگر وب و ...) به طور قابل توجهی متفاوت باشند آنگاه BFF ها راه حل خوبی می‌باشند. همچنین الگوی BFF ردگیری (tracking) درخواست‌ها را ساده‌تر می‌کند و در صورت خرابی یکی از Gateway ها بقیه دچار مشکلی نمی‌شوند (یعنی به عبارتی در این الگو Single Point of Failure نخواهیم داشت).ابزار‌ها و تکنولوژی‌های متن بازدر این بخش چندین مورد از API Gateway های متن‌باز و معروف در دنیا را بررسی می‌کنیم و درباره هر کدام به صورت مختصر توضیحاتی را ارائه می‌دهیم:محصول Kong Gatewayمحصول Kong Gateway یک API Gateway متن‌باز و سبک (lightweight) است که برای مایکروسرویس‌ها بهینه شده است و تأخیر انتها‌ به‌ انتها و مقیاس‌پذیری خوبی را ارائه می‌دهد. اگر فقط اصول اولیه و ساده مدنظر باشد، این محصول برای انتخاب API Gateway بهترین گزینه می‌باشد. Kong Gateway به صورت طراحی شده که به صورت افقی مقیاس‌پذیر است. یعنی با افزودن Node های بیشتری از Kong Gateway، به صورت موازی می‌توان درخواست‌های زیادی را به صورت همزمان پاسخ داد.تصویر۴: معماری سطح بالای Kong Gatewayمحصول Apache APISIXمحصول Apache APISIX یک API Gateway پویا (dynamic)، بلادرنگ (real-time) و با کارایی عالی (high-performance) است. APISIX ویژگی‌های خوبی را در مدیریت ترافیک مانند متوازن‌سازی بار (load balancing)، canary release (انتشار قناری تکنیکی است برای کاهش خطر معرفی نسخه جدید نرم‌افزار. در مرحله انتشار به صورت آهسته، نسخه جدید در اختیار زیرمجموعه کوچکی از کاربران قرار داده می‌شود تا بعد از دریافت فیدبک مثبت آن‌ها، این نسخه به صورت عمومی در دسترس قرار گیرد)، Circuit Breaker (این الگو‌ نیز باعث می‌شود در صورت خراب شدن یکی از مایکروسرویس‌ها، کل سیستم همچنان پایدار بماند و به عملکرد خود ادامه دهد)، احراز هویت و... را ارائه می‌کند.Apache APISIX تصویر ۵: معماری سطح بالای همچنین این محصول امکانات خوبی در حوزه مشاهده‌پذیری (observability) در اختیار کاربرانش قرار می‌دهد. یعنی کاربران می‌توانند به راحتی تمامی سرویس‌های احاطه شده توسط این محصول را نظاره کنند (Monitoring)، مشکلات را ردگیری کنند (Tracing) و لاگ‌های آن‌ها را مدیریت کنند (Logging). محصول Netflix API Gateway (Zuul)سرویس streaming نتفلیکس در بیش از ۱۰۰۰ نوع دستگاه مختلف (تلویزیون، ست تاپ باکس، گوشی‌های هوشمند، سیستم‌های بازی، تبلت‌ها و...) در دسترس می‌باشند و در مجموع ۵۰۰۰۰ درخواست در ثانیه را در ساعات اوج مصرف، به سمت سرور‌های نتفلیکس ارسال می‌کنند. نتفلیکس درخواست‌های ارسالی هر دستگاه را به واسطه API Gateway Zuul دریافت و handle می‌کند. در تصویر ۶ می‌توانید معماری کلی این API Gateway را مشاهده کنید.تصویر ۶: معماری سطح بالای Zuulشرکت‌های ایرانیشرکت‌های ایرانی که محصول API Gateway را به عنوان یک سرویس به مشتریانشان ارائه می‌دهند، عبارتند از:شرکت ابر درسا (Dorsacloud)سرویس API Gateway ابری شرکت ابر درسا شامل مجموعه وسیعی از توابع و ابزار‌های مدیریت چرخه زندگی API می‌باشد که برای ایجاد معماری سیستم‌های API محور، مورد استفاده قرار می‌گیرد. توابع مدیریت چرخه زندگی شامل طراحی API، توسعه، آزمایش، انتشار، فروش، O&M و نظارت، کنترل امنیت و عدم انتشار است. سرویس API Gateway ابری با استفاده از قابلیت‌های سازگاری و یکپارچگی قدرتمند خود، API های سیستم‌های تجاری مختلف را مدیریت می‌کند و API ها را به صورت متمرکز فراخوانی می‌کند.قابلیت‌هایی که این سرویس در اختیار کاربران خود قرار می‌دهد عبارتند از:پشتیبانی از محیط‌های ناهمگن: سرویس API Gateway ابری می‌تواند API های سیستم‌های تجاری مختلف را صرف نظر از اینکه آن سیستم‌ها در ابر درسا، مراکز داده محلی یا ابرهای شخص ثالث مستقر شده اند یا خیر، مدیریت کند. همچنین به واسطه این سرویس می‌توان انواع سیستم‌هایی که با تکنولوژی‌های پیاده‌سازی ناهمگون، ایجاد شده‌اند را کنار یکدیگر قرار داد و در قالب یک API واحد در اختیار کاربران قرار داد.ایجاد انواع معماری فنی: معماری بدون سرور ترکیبی از Function Compute و API Gateway به توسعه دهندگان امکان می‌دهد تا کد را کشف کرده و به سرعت خدمات کم هزینه، بسیار در دسترس و مقیاس‌پذیر در زمان واقعی را ایجاد کنند. این معماری توسعه مشاغل مرتبط با دستگاه‌های تلفن همراه، برنامه‌های وب، اینترنت اشیا (IoT) بازار ابر را تسهیل می‌کند. این معماری امکانات توسعه تجارت و مرزهای تجاری را گسترش می‌دهد. انعطاف‌پذیری ترکیبات محصول بهبود یافته است.یکپارچه‌سازی آسان با معماری مایکروسرویس: سرویس API Gateway ابری به عنوان یک سرویس ابری بالغ عمل می‌کند که اجازه دسترسی به خوشه‌های برنامه Kubernetes را می‌دهد. این به طور قابل توجهی قابلیت‌های سرویس خوشه‌های برنامه Kubernetes را بهبود می‌بخشد. این معماری به عنوان معماری استاندارد برای برنامه‌های کاربردی اینترنت در مقیاس بزرگ عمل می‌کند.شرکت وصل (Vasl)پلتفرم مدیریت API سورنا توسعه‌دهندگان را قادر می‌سازد تا برنامه‌هایی مرتبط با سامانه‌های داخلی سازمان طراحی و پیاده‌سازی نمایند. همچنین APIها در تکنولوژی‌های مختلف نظیر اینترنت اشیا، رایانش ابری و داده‌های حجیم نقشی کلیدی را ایفا می‌نماید. پلتفرم مدیریت API سورنا پایداری، امنیت و پشتیبانی ویژهای ارائه می‌کند تا شرکت‌های طرف ثالث، همکاران، شرکا و حتی توسعه‌دهندگان آزاد بتوانند با آسودگی خیال و اطمینان از آنها استفاده نمایند.تصویر ۷: نمای کلی از پلتفرم مدیریت APIقابلیت‌های این پلتفرم عبارتند از:طراحی سریع، سادگی پیاده سازی، تست دقیق: پلتفرم مدیریت API سورنا با نظارت، تجزیه و تحلیل داده‌ها، کنترل دسترسی‌ها و محافظت از اطلاعات حساس شما با سیاست‏‌های امنیتی خود موفقیت شما را تضمین می‌کند و به شما کمک می‌کند در نبرد با متجاوزان دنیای دیجیتال پیروز باشید.قدرتمند، جامع و بسیار انعطاف پذیر: بخش ایجاد کسب درآمد در پلتفرم سورنا یک راه حل قدرتمند، جامع و انعطاف پذیر است که به شرکت‌ها کمک می‌کند تا دارایی‌های دیجیتالی خود را به جریان درآمد جدید و مدل‌های کسب و کار بفروشند. تمامی صنایع توانایی کسب درآمد از سرویس‌هایی که در سازمان خود استفاده می‌کنند را دارند. بخش کسب درآمد در مدیریت سرویس سورنا ارزش افزوده در زنجیره ارزش دیجیتالی شما ایجاد خواهد کرد. شما می‌توانید مجموعه‌ای از سرویس‌های خود را با قیمت و زمان مشخص به فروشگاه سورنا اضافه کنید تا دیگر کاربران نیز بتوانند از آن‌ها استفاده کنند و شما نیز از دارایی‌های دیجیتال خود کسب درآمد کنید.راه‌حل‌های امنیتی کاملا هوشمند: با توجه به اینکه این مولفه در جلوی سرویس اصلی(سرویس ارائه دهنده API) قرار می‌گیرد، در صورتی که به خوبی پیکربندی شود می‌تواند به عنوان یک سد و لایه حفاظتی عمل نموده و در افزایش امنیت ارائه دهندگان API موثر باشد. سیستم خود را برای مقابله با هکرها، ربات‌ها و رفتارهای مشکوک آماده کنید. با آرامش و خیالی آسوده به ارائه خدمات خود بپردازید.ارتباط با سنسورها، نمایش گزارشات، ارائه خدمات به مشترکین: امروزه اینترنت اشیا و کاربردهای آن در حال فراگیر شدن است. اما انتخاب پلتفرم مناسب چالش بسیاری از سازمان‌ها و مدیران شهری است. شما با مدیریت سرویس سورنا می‌توانید تمامی خدمات در حوزه IOT را در پنل مدیریت اضافه کنید و با توجه به نیاز کاربرانتان آنها را ارائه نمایید.بینش‌های کاربردی، تحلیل‌های دقیق، هشدارهای متنی: بخش مانیتورینگ سورنا با ارائه تحلیل‌های دقیق و کاربردی به شما کمک میکند تا بتوانید هر روز عملکرد سیستم‌هایتان را افزایش و از وضعیت پاسخگویی آنها آمار و گزارشات دقیقی در اختیار داشته باشید. سیستم هشدارمتنی سورنا به کاربران این امکان رامی‌دهد تا در کوتاه ترین زمان ممکن مشکلات خود را شناسایی کنند و با صرف کمترین هزینه و کوتاهترین زمان آن مشکل را برطرف نمایند.هماهنگی لحظه‌ای پنل مدیریت با دستگاه‌ها: در زمان استفاده از وصل‌اپ پنل مدیریت سیستم در اختیار شما قرار خواهد گرفت که میتوانید از طریق آن از تمامی تغییرات در سیستم‌ها باخبر شوید و به راحتی در محتواها و کاربری سیستم تغییرات خود را ایجاد کنید. از همین پنل میتوانید برای بارگذاری محتوا، ارسال پوش، اطلاع از وضعیت پرداخت‌ها و…. استفاده کنید.جمع‌بندیبا توجه به جستجو‌های انجام شده متوجه شدیم که استفاده از API Gateway تنها زمانی افزایش می‌یابد که شرکت‌های بیشتری از معماری‌های مایکروسرویس و معماری بدون سرور (Serverless) پیچیده‌تری استفاده کنند. علاوه بر این، پس از مشاهده موفقیت اولیه شرکت‌هایی مانند آمازون و گوگل (Apige) و Salesforce، شرکت‌های بیشتری سیستم‌های نرم‌افزاری خود را به کمک این مفهوم راه‌اندازی می‌کنند. انتظار می‌رود با گسترش و تکامل API Gateway ها، این مفهوم نقش اصلی را در API Economy (اقتصاد API) بدست گیرد و در آینده تاثیر چشم‌گیری در معماری‌های سیستم‌های نرم‌افزاری داشته باشد.این مقاله، بخشی از تمرین‌های درس معماری نرم‌افزار در دانشگاه شهید بهشتی می‌باشدمنابعhttps://microservices.io/index.htmlhttps://docs.microsoft.com/en-us/azure/architecture/https://tsh.io/blog/design-patterns-in-microservices-api-gateway-bff-and-more/https://jstobigdata.com/architecture/the-api-gateway-pattern-in-microservices/https://rapidapi.com/blog/api-management-vs-api-gateway/https://www.getambassador.io/docs/edge-stack/latest/topics/concepts/microservices-api-gateways/https://martinfowler.com/bliki/CanaryRelease.htmlhttps://martinfowler.com/bliki/CircuitBreaker.html حامد رستم‌خانی حامد رستم‌خانی Thu, 09 Dec 2021 13:27:11 +0330 https://virgool.io/@rostamkhanihamed1/%D9%85%D8%B3%D8%AA%D9%86%D8%AF%D8%B3%D8%A7%D8%B2%DB%8C-%D8%A8%D8%A7-%D9%85%D8%AF%D9%84-c4-d0yesvzpcfoi همواره مستندسازی هر معماری، یکی از نیاز‌های اصلی در تمامی علوم مهندسی بوده ولی در علم مهندسی نرم‌افزار، این نیاز به یک دغدغه تبدیل شده چونکه با گذشت زمان و پیچیده‌تر شدن سیستم نرم‌افزاری نیاز به یک مستند جامع و گویا، بیشتر حس می‌شود. در مهندسی نرم‌افزار برخلاف علومی مانند مهندسی عمران، مستندسازی امری پیچیده و دشوار می‌باشد. زیرا در اکثر موارد استفاده از روش‌هایی مانند UML در مقابل ابزار‌های نقشه‌کشی ساختمان، عمل مستندسازی را به جزئیات بیهوده و بیراهه می‌کشد. مخصوصا بهره‌ بردن از UML و نمودار‌های آن، هنگام استفاده از روش‌‌های چابک (Agile) در فرآیند توسعه نرم‌افزار، تیم‌ها را با چالش جدی روبه‌رو می‌کند. یکی از چالش‌های اصلی استفاده از UML، وجود مفاهیم تخصصی در بطن نمودار‌ها می‌باشد و ممکن است در بیشتر مواقع ذی‌نفعانی که دید نرم‌افزاری و تخصصی ندارند، درک درستی نسبت به این نمودارها نداشته باشند و در نتیجه در فرآیند توسعه نرم‌افزار، به عنوان مانع عمل کنند.با کنار گذاشتن UML در فرآیند‌های توسعه Agile، نیاز به یک روش مستند‌سازی جدید بیش از پیش حس می‌شود زیرا تیم‌ها وقتی چابک عمل می‌کنند که خوب ارتباط برقرار کنند. همچنین برای برقراری ارتباط در دنیای Agile و lean، استفاده از مدل‌های مستندسازی مانند مدل C4 بسیار منطقی و مناسب می‌باشد. مدل C4 چیست؟مدل C4 یک رویکرد مستندسازی معماری نرم‌افزار می‌باشد که در آن اولویت انتزاع یا تجرید (Abstraction) از اهمیت بالایی برخوردار است (abstraction-first). این مدل توسط Simon Brown ابداع شد و هدف از آن، نمایش سیستم نرم‌افزاری در سطوح مختلفی از جزئیات می‌باشد. ۴ سطح مختلف این مدل که جلوتر با تفصیل به آن‌ها اشاره خواهیم کرد، برای مخاطبین و ذی‌‌نفعان مختلف با دیدگاه‌های متفاوت می‌باشد و تلاش می‌کنند درک مشترکی را بین تمامی ذی‌نفعان ایجاد کنند.نکته قابل توجه در این مدل، اولویت دادن به تجرید و کم‌ رنگ کردن نقش notation ها در مستندات می‌باشد (برخلاف UML که پر از notation بود). همچنین در این مدل محدودیتی برای استفاده از notation های مختلفی که در UML و ERD بود، وجود ندارد (انعطاف‌پذیری یکی از مزیت‌های خوب این مدل می‌باشد و تیم‌های چابک را بیشتر به استفاده از این مدل ترغیب می‌کند)همان‌طور که در تصویر (۱) مشاهده می‌کنید اساس نمودار‌های مدل C4، تجزیه ساختارمند و سلسله مراتبی یک سیستم به container ها و component ها و نهایتاً code می‌باشد (مطمئناً بعد خواندن این مطلب حدس زدید که C4 یک کلمه اختصاری هست که از ۴ تا C تشکیل شده. این ۴ تا C عبارتند از Context و Container و Component و Code). تصویر (۱): تجزیه سلسله مراتبی سیستممنظور از Code در مدل C4 مشخص می‌باشد ولی بهتر است قبل از ادامه سه مفهوم Context و Container و Component را کمی تشریح کنیم.مفهوم Context یا System Contex: این مفهوم به سیستم نرم‌افزاری اشاره دارد و بالاترین سطح تجرید در مدل C4 می‌باشد. به واسطه این مفهوم می‌توان ارتباطات سیستم‌نرم‌افزاری مدنظر را با Actor های خارجی مختلف اعم از انسان، سیستم‌نرم‌افزاری، دستگاه و... مشخص کرد.مفهوم Container: در مدل C4 منظور از Container همان یک برنامه‌کاربردی یا پایگاه‌داده می‌باشد. به عبارتی Container یک موجودیت runnable می‌باشد و اجرای آن باعث می‌شود سیستم نرم‌افزاری بالادستی کار کرده و عملکرد مطلوب از خود نشان دهد.مفهوم Component: مفهوم مولفه در موقعیت‌های مختلف و با معانی متفاوتی در حوزه نرم‌افزار استفاده شده است اما در مدل C4، مفهوم Component به گروهی از functionality های مرتبط، اشاره می‌کند که تحت یک interface خوش‌تعریف محصور شده‌اند. توجه به این نکته ضروری است که Component ها واحدهای مجزایی برای استقرار نیستند و در داخل Container ها، روی سرور‌ها و دستگاه‌ها مستقر می‌شوند.نمودار‌های اصلی مدل C4تجسم سلسله مراتب ذکر شده با ایجاد مجموعه‌ای از نمودارهای System Context و Container و Component و Code انجام می شود. در این بخش هر کدام از این نمودار‌ها را که بدنه اصلی مستندات C4 می‌باشند را تشریح می‌کنیم.سطح ۱: نمودار System Contexاین نمودار نقطه شروعی برای مستندسازی یک سیستم نرم‌افزاری می‌باشد که به ما این امکان را می‌دهد تا یک نمای کلی و تصویر بزرگی از سیستم را ببینیم. نموداری را ترسیم کنیم که سیستم مدنظرمان را به صورت جعبه‌ای در مرکز نشان می‌دهد و توسط کاربران و سایر سیستم‌هایی که با آن تعامل دارند، احاطه شده است.جزئیات در این نمودار مهم نیست زیرا قرار است به کمک این نمودار، تصویری جامع و کلی از چشم‌انداز سیستم نشان دهیم. در این نمودار تمرکز بر روی افراد (بازیگران، نقش‌ها، شخصیت‌ها و غیره) و سیستم‌های نرم‌افزاری خارجی می‌باشد تا تکنولوژی‌ها، پروتکل‌ها و سایر جزئیات سطح پایین. این همان نموداری است که می‌توان به افراد غیر فنی نشان داد.تصویر (۲): نمودار system context بانکداری اینترنتیمحدوده و scope نمودار: یک سیستم نرم‌افزاریاجزای اصلی: سیستم نرم‌افزاری مدنظراجزای پشتیبان: افراد (به عنوان مثال کاربران، بازیگران، نقش‌ها یا شخصیت‌ها) و سیستم‌های نرم‌افزاری (وابستگی‌های خارجی) که از نظر وسعت به طور مستقیم به سیستم نرم‌افزاری متصل هستند. معمولاً این سیستم‌های نرم‌افزاری دیگر، خارج از محدوده یا مرز سیستم نرم‌افزاری مدنظر قرار دارند و مسئولیت یا مالکیت آن‌ها را نداریممخاطبان و ذی‌نفعان: همه افراد، اعم از افراد فنی و غیر فنی، در داخل و خارج از تیم توسعه نرم‌افزارسطح ۲: نمودار Containerبعد از مشخص شدن مرز‌های سیستم نرم‌افزاری با محدوده خارج از سیستم، بهتر است کمی زوم کنیم و جزئیات بیشتری را مشاهده کنیم. همانطور که قبل‌تر اشاره کردیم یک Container موجودیتی است مجزا که قابلیت اجرا شدن و استقرار را دارد. به عنوان مثال یک برنامه‌کاربردی وب سمت سرور (مثل Spring MVC)، یک برنامه‌کاربردی Single-page (مثل Angular)، برنامه‌کاربردی دسکتاپ، برنامه‌کاربردی موبایل، پایگاه داده، File System، و غیره.اصولاً نمودار Container یک تصویر سطح بالایی از معماری نرم‌افزار و نحوه توزیع مسئولیت‌ها در آن را نشان می‌دهد. همچنین به کمک آن می‌توان گزینه‌های مناسب تکنولوژی را برای سیستم مدنظر انتخاب کرد. این نمودار ساده بوده و درک سیستم را برای توسعه‌دهندگان نرم‌افزار، تیم پشتیبانی و عملیات، آسان می‌کند.تصویر (۳): نمودار Container سیستم بانکداری اینترنتی محدوده و scope نمودار: یک سیستم نرم‌افزاریاجزای اصلی: Container های تعبیه شده در سیستم‌نرم‌افزاریاجزای پشتیبان: افراد و سیستم‌های نرم‌افزاری به طور مستقیم به Container ها متصل می‌شوندمخاطبان و ذی‌نفعان: افراد فنی در داخل و خارج از تیم توسعه نرم‌افزار؛ از جمله معماران نرم‌افزار، توسعه‌دهندگان و تیم‌های عملیاتی و پشتیبانیملاحظات: این نمودار درباره سناریوهای مربوط به استقرار، Clustering و Replica ها، شکست‌ها (failover) و... اطلاعاتی به ما نمی‌دهدسطح ۳: نمودار Componentدر مرحله بعد می‌توانی Container ها را تجزیه کرد تا به بلوک‌های ساختاری اصلی (یا همان مولفه‌ها) و تعاملات بین آن‌ها رسید. این نمودار نشان می‌دهد که چگونه یک Container از تعدادی مولفه تشکیل شده، مسئولیت و تکنولوژی ساخت هر یک از آن‌ها چیست. اصولا مولفه‌ها منطقاً (به صورت logical) به یکدیگر مرتبط می‌باشند. به عنوان مثال هر Controller یا هر DAO یا ... را می‌توان به عنوان یک مولفه در نظر گرفت.تصویر (۴): نمودار Container سیستم بانکداری اینترنتی محدوده و scope نمودار: یک Containerاجزای اصلی: مولفه‌های تعبیه شده در Containerاجزای پشتیبان: Container ها (در محدوده سیستم نرم‌افزاری) علاوه بر افراد و سیستم‌های نرم‌افزاری که مستقیماً به مولفه‌ها متصل هستندمخاطبان و ذی‌نفعان: معماران و توسعه‌دهندگان نرم‌افزارسطح ۴: نمودار Codeدر نهایت، آخرین سطح تجرید مربوط به نمودار‌های Code می‌باشد که به نحوه پیاده‌سازی سیستم نرم‌افزاری در سطح پایین، اشاره می‌کند. این نمودار را می‌توان با استفاده از نمودارهایی مانند Class Diagram در UML، نمودارهای ER یا مواردی مشابه به آن‌ها، رسم کرد. رسم نمودار‌های این سطح اختیاری می‌باشد و غالباً می‌توان آن‌ها را به واسطه ابزارهایی مانند IDE به صورت اتوماتیک و از روی کد تولید کرد. اصولا در سناریو‌های پیچیده یا سناریو‌هایی که تغییرات زیادی وجود دارند، رسم این نمودار‌ها زمان‌بر و بیهوده می‌باشد.تصویر (۵): نمودار Class سیستم بانکداری اینترنتی محدوده و scope نمودار: یک مولفهاجزای اصلی: اجزای کد (مانند کلاس‌ها، رابط‌ها، اشیاء، توابع، جداول پایگاه داده، و...) تعبیه شده در مولفه مدنظرمخاطبان و ذی‌نفعان: معماران و توسعه‌دهندگان نرم‌افزاردر تصویر (۶) می‌توان یک نمای کلی از ۴ نمودار اصلی مطرح در مدل C4 نشان داد و سطوح تجرید را به خوبی مشاهده کرد.تصویر (۶): سطوح مختلف مدل این امکان را می‌دهد که داستان‌های متفاوتی را برای مخاطبان مختلف تعریف کردنشانه‌گذاری‌ها و notation هاهمانطور که در ابتدای صحبتمان به این موضوع اشاره کردیم که رویکرد مدل C4 یک رویکرد abstraction-first می‌باشد و اولویت نشانه‌گذاری‌ها در این مدل پایین‌تر می‌باشند. اما این بدان معنی نیست که نشانه‌گذاری‌ها اصلاً مهم نیستند. فقط به دلیل چابک بودن این مدل، سخت‌گیری زیادی روی notation ها وجود ندارد.در ادامه نکات مهمی را مطرح می‌کنیم که به ما در رسم و درک نمودار‌های ذکر شده، کمک شایانی می‌کند:استفاده از عنوان روی هر نمودار: نوع ومحدوده هر نمودار در کنار عنوان آن نمودار باید معلوم باشددقت در سازگار بودن نمودار‌ها: تمامی نمودار‌های رسم شده باید ساختار سازگاری نسبت به یکدیگر داشته باشند (یعنی هر نمودار با یک سلیقه رسم نشده باشد)استفاده مناسب از کلمات اختصاری: در هر سطح باید با توجه به مخاطبان و ذی‌نفعان مربوطه، از کلمات اختصاری مناسب استفاده کرد (مثلا ذکر JDBC و MVC و... در نمودار Context بی‌معنا و غیرقابل فهم برای مخاطبان غیرفنی می‌باشد)استفاده از Element یا Box های مناسب: از اشکال مناسبی برای هر جز باید استفاده کرد (مثلا شکل پایگاه داده باید با شکل برنامه کاربردی موبایل فرق کند)استفاده مناسب از خطوط (از خطوط مناسب و جهت‌دهی مناسب استفاده شود)استفاده از key/legend: بهتر است برای هر نمودار پانویس نیز نوشته شودمی‌توانید برای رسم بهتر نمودار‌های C4 از چک لیست قرار داده شده در سایت استفاده کنید (https://c4model.com/review).منابع1. https://c4model.com2. https://en.wikipedia.org/wiki/C4_model3. https://medium.com/adeo-tech/how-do-we-document-architecture-across-multiple-teams-1e406883b4024. Visualising software architecture with the C4 model - Simon Brown, Agile on the Beach 2019 (Youtube Link : https://www.youtube.com/watch?v=x2-rSnhpw0g)5. Visualise, document and explore your software architecture - Simon Brown, NCD London 2017 (Youtube Link : https://www.youtube.com/watch?v=Ym9nhVZs89o) حامد رستم‌خانی حامد رستم‌خانی Wed, 17 Nov 2021 23:43:40 +0330