https://virgool.io/feed/@borjianamin98 fa 2026-06-16 11:54:13 https://static.virgool.io/images/default-avatar.jpg https://virgool.io/@borjianamin98 https://virgool.io/@borjianamin98/%D8%B4%D8%A8%DA%A9%D9%87-%D9%88%D8%A7%DA%98%D9%87-%D9%87%D8%A7%DB%8C-%D9%85%D8%B1%D8%AA%D8%A8%D8%B7-ooo2winbziec چکیدهواژه‌های زیادی امروزه در اطراف ما و در محیط‌های مختلف مثل اینترنت، شبکه‌های اجتماعی، گروه‌ها و کتاب‌ها در حال تولید هستند. این در حالی است که نرخ تولید این واژگان در گذشته بسیار کم و محدود بوده است. یکی از مباحثی که در حوزه‌ی پردازش زبان‌ها مورد بررسی قرار می‌گیرد، مبحث تعبیه‌سازی واژه‌ها (word embedding) می‌باشد. تعبیه واژه معمولا به صورت تبدیل واژه به یک بردار صورت می‌گیرد به طوری که انتظار می‌رود کلماتی که در فضای برداری نزدیکتر هستند از نظر معنی یا کاربرد مشابه باشند. برای این منظور الگوریتم‌های هوش مصنوعی یا آماری مختلفی در طول زمان ایجاد یا پیشنهاد شده است. این در حالی است که در شبکه‌های پیچیده با ویژگی‌های خاص، همین اطلاعات به شکل دیگری نهفته است! احتمالا شما در توییت‌ها حول موضوعات مشخصی صحبت می‌کنید یا افرادی را دنبال می‌کنید که درباره‌ی موضوعات مرتبط با شما صحبت می‌کنند. احتمال لینک بین صفحات اینترنت نشان‌دهنده‌ی نوعی ارتباط موضوعی بین سایت‌ها می‌باشد. احتمالا در شبکه‌‌ی مقالات، ارتباط موضوعی بین مقاله‌ها مشاهده می‌شود و بسیاری موارد دیگر. آیا می‌توانیم به جای استفاده از الگوریتم‌های مشخص و از پیش آموزش‌دیده، از طریق شبکه‌های موجود واژه‌های مرتبط به یکدیگر را پیدا کنیم؟ بدون این که لازم باشد ابتدا واژگان را به بردارهایی تبدیل کنیم؟ هدف ایجاد پیوندی بین دنیای پردازش زبان و شبکه‌های پیچیده می‌باشد. با ایجاد روشی برای پاسخ‌دهی به این مسئله، می‌توانیم اطلاعاتی را استخراج کنیم که همچون خروجی‌های پردازش زبان طبیعی، برای نیازها یا توسعه‌های بعدی مورد استفاده قرارگیرند. همچنین این اطلاعات بر اساس رفتارهای شبکه ایجاد می‌شوند و تغییرات زمانی یا مکانی را در بر می‌گیرند. (مثلا ارتباط بین بایدن و انتخابات در برهه‌ی زمانی انتخابات) به عبارتی با اجرای مدوام این کار، می‌توانیم از تغییرات لحظه‌ای و پویای شبکه‌های پیچیده، برای کشف ارتباطات واژه‌ای که ایجاد شده یا از بین می‌روند استفاده کنیم. مقدمهشبکه‌ی اینترنت، شبکه‌ی بزرگی از صفحات اینترنت می‌باشد که هر کدام از این صفحات دارای یکسری مطالب و همچنین یکسری لینک (اصطلاحاً anchor) به صفحات دیگر هستند. اگر صفحات مختلف شبکه اینترنت را به صورت نودهای شبکه در نظر بگیریم، وجود این لینک‌ها به نوعی باعث ایجاد یکسری یال بین نودها می‌شود. اکنون هدف ما این است که از این شبکه‌ی بزرگ برای استخراج کلمات هم‌معنا یا مرتبط (related) استفاده کنیم. مبنای ارتباط کلمات، میزان تکرارشدن یک ارتباط در شبکه می‌باشد. وقتی یک سایت در مورد ورزش صحبت می‌کند، احتمالا کلمات مربوط به حوزه‌ی ورزش در این صفحه به خوبی مشاهده می‌شود. به همین دلیل خود کلمات یک صفحه ارتباطاتی را تشکیل می‌دهند (مثلا ارتباط بین کلمه فوتبال و توپ) در عین حال خود صفحات مختلف وب دارای لینک هستند و احتمالا یک صفحه‌ی ورزشی، به دیگر صفحات ورزشی لینک می‌دهد. پس اگر در صفحه‌ی اول کلمه «فوتبال» و صفحه‌ی دوم «بازیکن» را ببینیم، این کلمات نیز به یکدیگر مرتبط هستند. اکنون به نوعی شبکه‌ی اینترنت ما خود یک شبکه‌ای از شبکه‌ها (network of networks) می‌باشد چون خود کلمات یک صفحه نیز یک شبکه را تشکیل می‌دهند. اگر رخداد ارتباط کلمه‌ی «فوتبال» و «توپ» بعد از خزش (crawl) تعداد زیادی صفحات وب، زیاد باشد نشان می‌دهد که احتمالا بین این کلمات ارتباط خوبی برقرار است و از نظر معنایی مرتبط یا نزدیک هستند. اگر 1 میلیون بار بین کلمه‌ی «فوتبال» و «توپ» لینک برقرار شود در حالی که بین «درس» و «قالی» یک یال ایجاد شود، این نشان‌دهنده‌ی ارتباط معنایی بین «توپ» و «فوتبال» می‌باشد.هدف اصلی خزش صفحات وب می‌باشد برای این که گراف بزرگی از کلمات مرتبط استخراج شود. با این حال این شبکه خیلی بزرگ می‌باشد و ارتباط کلمات داخل یک صفحه دلیل محکمی بر ارتباط میان کلمات نیست و از طرفی تعداد کلمات یک صفحه متغیر (حداقل 200 کلمه) است که حجم زیادی از آن‌ها کلمات غیرکاربردی مثل فعل‌ها یا حروف اضافه هستند. به همین دلیل خوب است در حین تشکیل این گراف، یکسری عملیات برای کاهش حجم گراف و در عین حال بالابردن دقت گراف شبکه انجام دهیم. (چون در نظر گرفتن تمامی کلمات یک صفحه و ارتباطات آن‌ها بیهوده و تنها باعث افزایش حجم گراف نهایی می‌شود) در ادامه پایه‌های اصلی انجام این کار را مورد بررسی قرار می‌دهیم و بعد از آن، معماری و شیوه‌ی پیاده‌سازی صورت‌گرفته را بیان می‌کنیم. در نهایت خروجی کار و ارزیابی آن بر اساس پیاده‌سازی صورت‌گرفته ارائه می‌شود.ادبیات موضوعخزش اینترنتخزش وب یا اینترنت، برنامه ماشینی خودکاری است که محتوای موجود در اینترنت را جستجو و ذخیره‌سازی می‌کند تا در ادامه برای نیازهای مختلف مورد استفاده قرار بگیرد. اساسا، خزنده‌های وب وظیفه درک مطالب موجود در یک صفحه وب را دارند تا بتوانند از طریق آن به صورت خودکار و بدون مداخلت انسان، لینک و صفحات جدید را پیدا کنند. برای این کار، این ربات‌ها با واکشی چند صفحه وب آغازین (اصطلاحاً seed) شروع به کار می‌کند و سپس لینک‌های موجود در آن صفحات وب را برای یافتن صفحات بعدی و تکرار فرآیند دنبال می‌کند.اگر چه در ظاهر انجام خزش ساده می‌باشد اما لازم است نکاتی در نظر گرفته‌شود و پیاده‌سازی آن به سادگی بیان‌شده نیست. از جمله نکاتی که باید در این مورد در نظر گرفته شود، می‌توان موارد زیر را نام برد:عدم گیرافتادن در تور بسته عنکبوت: گاهی یکسری از صفحات به صورت مدوام به یکدیگر لینک داشته به صورتی که حلقه‌ای از اتصالات برگشتی به یکدیگر را شکل می‌دهند. به عنوان مثال در ساده‌ترین حالت، صفحه‌ی A به صفحه‌ی B لینک دارد و صفحه B نیز به صفحه‌ی A لینک دارد. در این حالت خزش‌کننده بعد از خزش صفحه‌ی A به صفحه‌ی B می‌رود و دوباره بر می‌گردد، در نتیجه در حلقه‌ی نامتناهی گیر می‌کند و نمی‌تواند کار خود را ادامه دهد. برای خودداری از این مشکل، خزش‌کننده‌ها از حافظه‌ی جداگانه‌ای استفاده می‌کنند تا از خزش دوباره یک صفحه خودداری کنند و در نتیجه چنین مشکلی به وجود نخواهد آمد. رعایت ادب: وقتی یک دامنه‌ی خاص مثل صفحه‌ی ویکی‌پدیا را نظر می‌گیریم، اگر خزش‌کننده بخواهد هر ثاینه صفحه‌ی جدیدی را از این دامنه درخواست دهد، بلافاصله توسط دامنه ویکی‌پدیا دسترسی به صفحه‌ی موردنظر برای درخواست‌دهنده بسته می‌شود. علت این است که ویکی‌پدیا فکر می‌کند که شما قصد حمله به سایت آن را دارید و به همین دلیل تلاش بر واردکردن فشار دائمی به سایت او دارید. حتی برخی سایت‌ها به شما اجازه‌ی دسترسی به تمامی صفحات خود را نمی‌دهند. در این موارد ربات‌های خزشگر باید اصلاحا ادب را در ارسال درخواست‌ها رعایت کنند و بلافاصله و پشت سر هم از یک دامنه مشخص درخواست یک صفحه را ندهند. نرخ درخواست گاهی توسط خود سایت‌ها ارائه می‌شود و گاهی نیز به صورت حداقلی یک دقیقه در نظر گرفته می‌شود.استخراج کلماتبه منظور استخراج کلمات مهم یک صفحه‌ی وب، به دنبال الگوریتم‌هایی برای استخراج کلمات مهم هستیم. هدف از استخراج کلمات مهم کاهش حجم اطلاعاتی است که ذخیره می‌کنیم زیرا ذخیره‌سازی تمام کلمات از جمله حروف و حرف‌های اضافه صرفاً حجم نگهداری داده را افزایش می‌دهد. این در حالی است که نگهداری تمامی این کلمات فایده‌ای ندارد. این الگوریتم‌ها تحت عنوان word extraction شناخته می‌شوند. معمولا مهم‌ترین و معروف‌ترین الگوریتم که افراد مختلف در این حوزه پیشنهاد می‌دهند، الگوریتم TF-IDF می‌باشد. با این حال این الگوریتم و موارد مشابه آن به دلایل مختلف برای هدف این پیاده‌سازی مناسب نیستند:این الگوریتم نیاز به کلیه‌ی اسناد (صفحات) برای استخراج کلمات مهم یک صفحه دارد و به همین دلیل، کار پیدا کردن کلمات مهم یک صفحه نمی‌تواند در حین خزش اتفاق بیافتد و باید در انتهای کار و بعد از این که مطمئن شدیم دیگر قصد خزش بیش‌تر نداریم انجام شود. این باعث می‌شود هزینه‌ی آن در طول زمان نیز پخش نشود، اما بدی این روش این است که در صورت ادامه‌دادن خزش لازم است دوباره از کل شبکه استفاده و این الگوریتم اجرا شده و کلمات استخراج شود.به دلیل این که نیاز به کل صفحات می‌باشد، باید کلیه‌ی صفحات و محتوای آن‌ها نگه داشته شود (حجم زیادی داده) تا در انتها کلمات مهم و اساسی استخراج شوند. در صورتی که اگر در طول زمان کلمات را استخراج می‌کردیم، هم هزینه‌ی کمتری از نظر اجرا در ادامه و همچنین فضای دیسک می‌پرداختیم.این الگوریتم‌ها معمولا نسبت به اسناد جمع‌شده حساس هستند و بر اساس آن خروجی می‌دهند، در صورتی که شاید دید مستقل به هر سند نسبت به دیگر اسناد و استخراج کلمات، دقت بیش‌تری را خروجی دهد. به عبارتی این الگوریتم کلیه صفحات استخراج‌شده را نگاه می‌کند و بر اساس کلمات آن‌ها، کلمات مهم را استخراج می‌کند و تا حد خوبی وابسته به محتوای کلیه صفحات استخراج‌شده می‌باشد. در حالی که اگر هر صفحه را مستقلا نگاه می‌کردیم و کلمات مهم را استخراج می‌کردیم، وابستگی کمتری به نوع صفحات خزش‌شده می‌داشتیم.همچنین روش‌های مبتنی بر یادگیری نیز برای هدف پروژه مفید نیستند. این روش‌ها وابسته به داده‌ی یادگیری هستند و قابلیت تعمیم کمی را در فضای اینترنت با صفحات مختلف و متن‌های مختلف دارند. همچنین هزینه‌ی یادگیری در این روش‌ها نیز افزوده می‌شود و مشابه با روش TF-IDF، نیاز به حجم خوبی از کل داده دارند (برای یادگیری و سپس استخراج) و به همین دلیل معایب روش TF-IDF را نیز شامل می‌شوند. این روش‌ها همچنین از مشکلات جدیدتری مثل وابسته‌شدن زیاد به ورودی تمرین یا دقت کم رنج می‌برند و اگر متن کاملا جدیدی متفاوت از داده‌های تمرین دریافت کنند، احتمالا به خوبی عمل نخواهند کرد.به همین دلیل با توجه به محدودیت‌های روش‌های بیان‌شده و حجم داده‌ی ما، استفاده از روش‌های با ویژگی‌های زیر برای ما مفید نیستند:نیازمند کل مجموعه صفحات برای استخراج کلماتنیازمند دریافت اطلاعات وابسته به زبان (مثل کلمات stop word و ...)روش‌های مبتنی بر یادگیریدر نتیجه ما در این پیاده‌سازی به دنبال روش‌هایی هستیم که بدون مشاوره و مستقلاً برای هر صفحه، کلمات مهم را استخراج کنند. در این میان روش‌های مختلفی بررسی شدند که با توجه به محدودیت مقاله، زمان توضیح بررسی هر کدام از موارد نیست. در ادامه نام برخی از الگوریتم‌های مهم بررسی‌شده، سال انتشار و خلاصه‌ای از رویکرد آن را مشاهده می‌کنیم.روش TextRank (سال 2014): پایه و اساس روش‌های دیگر که با تشکیل گرافی از کلمات صفحه (بر اساس روش صفحه‌ی متحرک) و اعمال الگوریتم‌های PageRank، کلمات مهم را استخراج می‌کند.روش PositionRank (سال 2017): مشابه روش TextRank با این تفاوت که موقعیت کلمات در صفحه را در نظر می‌گیرد. (کلمات ابتدایی صفحه احتمالا مهم‌تر از کلمات انتهایی صفحه هستند)روش RAKE یا Rapid Automatic Keyword Extraction (سال 2010): روشی مبتنی بر گراف که بر اساس کلمات stop word، جملات را جدا کرده و سپس بر حسب هم‌نشینی کلمات داخل یک جمله و بین جمله‌ها، گراف را تشکیل می‌دهد. سپس بر اساس معیارهای درجه و ... گراف، کلمات مهم را استخراج می‌کند.روش Multi-word Keyword Scoring Strategy (سال 2017): این روش بر اساس روش‌های دیگر موجود استخراج کلمه عمل می‌کند و در نهایت خروجی آن‌ها را ویرایش و کلمات مهم‌تر را استخراج و تشخیص می‌دهد به نحوی که دقت الگوریتم استفاده‌شده را افزایش می‌دهد.روش Word Attraction Rank (سال 2015): در این روش گرافی روی کلمات صفحه ایجاد می‌شود و در ادامه بر اساس مفاهیمی مثل کشش و دافعه (مفاهیم فیزیکی) و اعمال آن‌ها به صورت ریاضی روی گراف، کلمات مهم را استخراج می‌کند.روش YAKE یا Yet Another Keyword Extractor (سال 2020): در این روش ابتدا صفحه بررسی شده، کلمات مهم و کاندید استخراج می‌شوند، سپس کلمات بر اساس ویژگی‌های مختلف آماری یک بردار ویژگی دریافت می‌کنند (مثل موقعیت کلمه، تکرار کلمه، ارتباط به حوزه و ...)، سپس بر اساس بردار ویژگی امتیازی دریافت می‌کنند، در ادامه از روش‌هایی معروف برای حذف کلمات تکراری استفاده می‌شود و در نهایت خروجی ارائه می‌شود.روش‌های دیگری هم نیز بررسی شدند اما مهم‌ترین آن‌ها در این قسمت ذکر شدند. هر کدام از روش‌ها و منطق پیاده‌سازی آن‌ها بررسی شد. تلاش شد تا حد امکان پیاده‌سازی‌های آن‌ها یافت شده یا ایجاد شود و بر روی متون مختلف عملکرد آن‌ها بررسی شود. در نهایت بر اساس بررسی‌ها و مطالعات مختلفی که رخ داد، الگوریتم YAKE با بهترین نتایج به عنوان پایه و اساس برای ادامه‌ی کار انتخاب شد.پیاده‌سازیدر ادامه با توجه به حجم عظیمی از داده که ایجاد می‌شود لازم داریم که تا ابزارهایی مناسب در جهت موارد زیر را استفاده کنیم:ذخیره‌سازی داده با فرمت مناسب برای پردازش‌های بعدیابزاری برای پردازش صفحات خزش‌شده و ساخت گراف و استخراج کلماتالبته شاید با توجه به مدت زمان محدودی که برای پیاده‌سازی و سپس اجرای برنامه وجود دارد، حجم زیادی داده جمع‌آوری نشود اما پیاده‌سازی بر اساس فرض حجم زیاد داده انجام می‌شود تا برنامه‌ی پیاده‌سازی برای استفاده دیگران در مقیاس حجم زیاد کاربردی باشد. بررسی‌های مختلفی روی ابزارهای مختلف صورت گرفت تا از میان ابزارهای موجود و پیشرفت‌های اخیر، بهترین تکنولوژی برای این موضوع انتخاب شود. معروف‌ترین ابزارهای یافت‌شده در حوزه پردازش شبکه‌های بزرگ و پیچیده موارد زیر بودند:ابزار Apache Mahoutابزار Apache Giraphابزار Apache Sparkاین ابزارها، معروف‌ترین موارد بودند. با این حال رویکرد هر کدام و محبوبیت هر کدام بررسی شد و تلاش شد بر اساس میزان بروزبودن، محبوبیت، قابلیت‌ها و مقایسه‌های موجود در اینترنت (benchmarkها) ابزاری را برای پیشبرد پروژه انتخاب کنم. بر این اساس تصمیم گرفتم تا بر اساس ابزار Apache Spark ادامه‌ی کار را پیش ببرم. این ابزار هم نسبت به دیگر ابزارهای جدید بروز بود و همچنین از محبوبیت بسیاری برخوردار بود.در کنار انتخاب ابزارها، پیاده‌سازی صورت‌گرفته تا حد امکان به صورت ماژولار انجام می‌گیرد. هدف از پیاده‌سازی ماژولار این است که تا حد امکان به معماری میکروسرویس نزدیک باشیم و امکان اجرای هر کدام از بخش‌ها به صورت مستقل قابل انجام باشد. معماری برنامه بر اساس این توضیحات در نهایت به صورت زیر می‌باشد:کلیه برنامه‌هایی که در تصویر مشاهده می‌کنید، در کنار یکدیگر هدف نهایی این پیاده‌سازی یعنی ساخت گراف کلمات مرتبط را انجام می‌دهند. در این راستا از یکسری سرویس‌های زیرساختی آماده نیز استفاده شده است که فهرست آن‌ها را در پایین تصویر مشاهده می‌کنید و محل استفاده هر کدام را نیز در بخش ماژول‌های پیاده‌سازی‌شده مشاهده می‌کنید. همچنین در پیاده‌سازی برنامه‌های موردنیاز، ارتباطات میان تمام برنامه‌ها از طریق زیرساخت‌های مستقل فراهم شده است. برای این منظور از ساختار صف توزیع‌شده (Kafka) و فایل‌سیستم توزیع‌شده (HDFS) استفاده شده است. این نحوه‌ی معماری این امکان را می‌دهد تا هر کدام از از برنامه‌ها به صورت مستقل اجرا شوند چون ورودی آن‌ها و خروجی آن‌ها مستقیماً به دیگر برنامه‌ها فرستاده نمی‌شود و در محل‌های میانی ذخیره می‌شود. در ادامه به صورت خلاصه کارکرد هر کدام از برنامه‌ها را مورد بررسی قرار می‌دهیم.خزشگر (crawler): اولین و شروع‌کننده برنامه، بخش خزشگر می‌باشد. این بخش در روز صفر، فهرستی از صفحات اولیه را دریافت می‌کند و شروع می‌کند به خزش محتوای صفحات آن‌ها و استخراج لینک‌های موجود در آن‌ها تا این فرایند را دوباره تکرار و ادامه دهد. فهرست لینک‌های اولیه در یک صف کافکا قرار داد و لینک‌های جدیدی که یافت می‌شوند، به این صف دوباره اضافه می‌شوند. همچنین صفحاتی که با موفقیت خزش می‌شوند، محتوای آن‌ها و لینک‌های صفحه در صفی به نام pages قرار می‌گیرند تا در ادامه توسط مولفه‌های بعدی مورد استفاده قرار بگیرند. دقت شود که محتوای صفحه سرشار از تگ‌های HTML می‌باشد ولی تنها محتوای صفحات بدون تگ ذخیره می‌شوند. (البته در آینده می‌توان این را بهبود داد تا بین تگ‌های header و لیست و ... تفاوت بگذارد اما در پیاده‌سازی کنونی صرف از نظر نوع تگ، صرفا محتوای درون تمامی تگ‌ها در نظر گرفته شده است) همچنین این مولفه باید از خزش دوباره صفحات خودداری کند. برای این منظور از پایگاه داده mongodb برای نگهداری لینک صفحات خزش‌شده استفاده می‌کند. همچنین در نگهداری لینک‌ها تا حد امکان آن‌ها را فشرده ذخیره‌سازی می‌کند.استخراج‌کننده کلمات کلیدی (keyword-extractor): این بخش صفحاتی که در صف pages قرار گرفته‌اند را می‌خواند و سپس به ازای هر صفحه، به صورت مستقل و مبتنی بر روش YAKE، کلمات کلیدی را استخراج کند. سپس کلمات کلیدی استخرج‌شده را در صف دیگری به نام keywords قرار می‌دهد تا توسط مولفه‌ی بعدی استفاده شود.استخراج‌کننده لینک‌ها (anchor-extractor): این بخش صفحاتی که در صف pages قرار گرفته‌اند را می‌خواند و سپس به ازای هر لینک موجود در صفحه، بین صفحه‌ی مبدا و مقصد یک لینک (X -> Y) ایجاد می‌کند و آن را در صف دیگری به نام links قرار می‌دهد تا توسط مولفه‌ی بعدی استفاده شود. علت تصمیم‌گیری این نوع ساختار استفاده‌شده، پیاده‌سازی راحت‌تر بخش ساخت گراف در مراحل بعدی می‌باشد. ذخیره‌کننده کلمات کلیدی (keyword-persister): این بخش کلمات کلیدی استخراج‌شده برای هر صفحه را از صف keywords می‌خواند و به صورت دسته‌هایی با اندازه و حجم مشخص، در قالب یکسری فایل بر روی فایل‌سیستم توزیع‌شده HDFS می‌نویسد. علت این مولفه میانی این است که اولا منطق آن از منطق استخراج کلمات جدا شود و همچنین فایل سیستم HDFS برای فایل‌های بزرگ مناسب است (نه فایل‌های کوچک) به همین دلیل از طریق این روش می‌توان نحوه‌ی نوشتن لینک‌ها بر روی HDFS را کنترل کرد. خروجی نوشته‌شده در این قسمت در ادامه توسط مولفه‌ی بعدی مورد استفاده قرار می‌گیرد.ذخیره‌کننده لینک‌ها (keyword-persister): این بخش مشابه بخش ذخیره‌کننده کلمات کلیدی، لینک‌های استخراج‌شده را از صف links می‌خواند و به صورت دسته‌هایی با اندازه و حجم مشخص، در قالب یکسری فایل بر روی فایل‌سیستم توزیع‌شده HDFS می‌نویسد. علت این مولفه میانی این است که اولا منطق آن از منطق استخراج لینک جدا شود و همچنین خروجی‌های مناسب برای فایل سیستم HDFS تولید شود. خروجی نوشته‌شده در این قسمت در ادامه توسط مولفه‌ی بعدی مورد استفاده قرار می‌گیرد.بخش تولید گراف (graph-producer): این بخش هر دو خروجی ذخیره‌شده در مولفه‌های قبلی شامل کلمات کلیدی و لینک‌ها را دریافت می‌کند و با کنار هم قراردادن این دو مورد، گرافی میان کلمات یک صفحه و صفحات دیگر ایجاد می‌کند. در این گراف هر گره یک صفحه با فهرستی از کلمات است و لینک‌ها نشان‌دهنده‌ی وجود ارتباط بین دوصفحه است. سپس این گراف را به گراف دیگری تبدیل می‌شود که در آن هر کلمه از یک گره به کلمه دیگری از یک گره لینک پیدا می‌کند اگر بین دو گره، یالی باشد. همچنین بین کلمات یک صفحه نیز لینک ایجاد می‌شود. در ادامه این گراف جدید مبتنی بر فرمت جدید در سیستم‌فایل HDFS ذخیره می‌شود که همان گراف کلمات مرتبط شامل کلیه جزییات (از کوچکترین ارتباطات تا بزرگترین آن‌ها) می‌باشد.این خروجی در ادامه توسط مولفه بعدی استفاده می‌شود.رسم‌کننده گراف (graph-drawer): این بخش خروجی گراف قبلی را از فایل‌سیستم می‌خواند و در صفحه‌ی HTML ارائه می‌دهد. در هنگام رسم یکسری فیلترها توسط این مولفه می‌تواند بر روی خروجی انجام شود تا کیفیت خروجی بهبود پیدا کند. در حال حاضر ساده‌ترین فیلتر که انتخاب صرفا 100 کلمه دارای لینک با وزن زیاد می‌باشد، پیاده‌سازی شده است. برای پیاده‌سازی هر کدام از این مولفه‌ها نیز از یکسری سرویس‌های زیرساختی استفاده شده است که در ادامه توضیح خلاصه‌ای را در مورد هر کدام از آن‌ها بیان می‌کنیم:ابزار Apache HDFS: کارکرد اصلی ابزار نگهداری داده است. این ابزار مجموعه‌ای از نرم‌افزارهای منبع باز است که استفاده از شبکه‌ای از رایانه‌های زیادی را برای حل مشکلات مربوط به حجم عظیم داده و محاسبات تسهیل می‌کند. بخش HDFS این ابزار یک چارچوب نرم‌افزاری برای ذخیره‌سازی توزیع شده فراهم می‌کند. HDFS می‌تواند انواع داده‌ها را شامل ساختاریافته، نیمه ساختاریافته یا بدون ساختار ذخیره کند. این ابزار برای ذخیره‌سازی لینک‌ها و کلمات کلیدی استخراج‌شده مورد استفاده قرار گرفته است.ابزار Spark: کارکرد اصلی ابزار پردازش داده می‌باشد. Apache Spark یک چارچوب محاسباتی خوشه‌ای منبع‌باز و توزیع‌شده برای پردازش بلادرنگ (real-time) محسوب می‌شود. اسپارک سازگاری روان با Hadoop را فراهم می‌کند. اسپارک به منظور تعامل با خوشه، APIهای سطح بالایی را در جاوا، اسکالا، پایتون و R ارائه می‌دهد. کد اسپارک را می‌توان به هر یک از این چهار زبان نوشت. از این ابزار برای تحلیل داده‌های خروجی و ایجاد گراف نهایی استفاده شده است.ابزار Zookeeper: یک سرویس متمرکز برای حفظ اطلاعات پیکربندی، نامگذاری، ارائه همگام‌سازی توزیع شده و ارائه خدمات گروهی است. همه این نوع خدمات به شکلی توسط برنامه‌های کاربردی توزیع شده استفاده می‌شوند. به عنوان مثال هادوپ و کافکا از این سرویس استفاده می‌کنند. علت آن این است که به دلیل دشواری پیاده‌سازی این نوع خدمات، برنامه‌های کاربردی معمولاً به ابزارهای خارجی وابسته می‌شوند. حتی زمانی که به درستی انجام شود، پیاده‌سازی های مختلف این خدمات منجر به پیچیدگی مدیریت در هنگام استقرار برنامه‌ها می‌شود.ابزار Kafka: کافکا یک سرویس رویداد توزیع شده و بستر پردازش جریان است که متشکل از سرورها و کلاینت‌هایی است که از طریق یک پروتکل شبکه TCP با کارایی بالا ارتباط برقرار می‌کنند. این به کاربران امکان می‌دهد داده‌ها را به هر تعداد سیستم یا برنامه های بلادرنگ منتشر (publish) کنند و سرویس‌های دیگر برای دریافت داده خود را ثبت (subscribe) کنند. این ابزار معمولا به عنوان یک صف توزیع‌شده نیز شناخته می‌شود و از ویژگی‌های آن برای جداسازی برنامه‌های کاربردی مختلف در پیاده‌سازی جاری استفاده شده است.ابزار MongoDb: یک پایگاه داده سند گرا است و به عنوان پایگاه داده NoSQL طبقه‌بندی می‌شود زیرا اسناد JSON مانند با طرح‌های اختیاری را ذخیره می‌کند. این پایگاه داده قابلیت‌های متنوعی از جمله پرس‌وجوهای در لحظه، ایندکس‌کردن داده، تکرار داده (برای خودداری از بین رفتن داده)، تقسیم بار، جمع‌آوری و تحلیل را فراهم می‌کند. به علت ساده‌بودن این ابزار و سرعت خوب در تست‌های صورت‌گرفته، به عنوان یک persisntent cache در پیاده‌سازی کنونی استفاده شد.خروجی و ارزیابیبر اساس پیاده‌سازی صورت‌گرفته، سایت‌های اولیه برای اجرا و تولید گراف نهایی مشخص شدند. فهرست سایت‌های اولیه که برای خزش انتخاب شدند، موارد زیر بودند که همگی جزو سایت‌های معروف هستند:http://google.comhttp://wikipedia.orghttp://instagram.comhttp://yahoo.comhttp://whatsapp.comhttp://amazon.comhttp://live.comhttp://netflix.comhttp://reddit.comhttp://office.comhttp://linkedin.comhttp://zoom.ushttp://discord.comhttp://twitch.tvhttp://bing.comhttp://roblox.comhttp://microsoftonline.comhttp://duckduckgo.comhttp://pinterest.comhttp://msn.comhttp://microsoft.comhttp://ebay.comhttp://accuweather.comhttp://fandom.comhttp://weather.comhttp://paypal.comhttp://walmart.comهمچنین برای رعایت ادب در هنگام خزش، مدت زمان یک دقیقه فاصله بین درخواست‌ها به یک دامنه یکسان فاصله انداخته شد. مدت زمان محدودی به دلیل پیاده‌سازی خود مولفه‌ها، بخش خزش‌کننده در حال اجرا بود و همچنین به دلیل مصرف اینترنت بالای مولفه، صرفا در ساعت خاصی از روز که اینترنت رایگان داشتم، اجرا شد. (که البته در این ساعت نیز سرعت اینترنت حداقل مقدار بود) در نهایت تعداد 150 هزار صفحه یافت شد که از میان آن‌ها 10 هزار صفحه، محتوا و لینک‌هایشان به صورت کامل استخراج شد. به ازای هر صفحه تنها صد کلمه‌ی کلیدی استخراج گردید و مبتنی بر همین مشخصات، گراف خروجی ساخته شد. در ادامه پیش از نتیجه‌گیری، چند نمونه از شکار صحنه‌های زیبا را برای گراف خروجی را مشاهده می‌کنیم.همان‌طور که در تصویر بالا مشاهده می‌کنید، ما توانستیم تمامی ماه‌های میلادی را با ارتباطات زیاد در یک گروه و دسته‌بندی تقریبا متصل داشته باشیم و این در حالی هست که ما هیچ‌گونه دانشی در این سامانه در مورد ماه‌های سال قرار نداده بودیم و خود سامانه توانسته بود این رابطه را بر اساس لینک‌ها و محتوای موجود در اینترنت، استخراج کند. همان‌طور که در این تصویر مشاهده می‌کنید، بین «حریم شخصی» با سه مفهوم «سیاست»، «داده» و «اطلاعات» ارتباطاتی تشخیص داده شده است که تا حدود زیادی مفاهیم مرتبط به یکدیگر می‌باشند. در تصویر بالا کلیه‌ی خدماتی که توسط شرکت مایکروسافت ارائه می‌شوند را می‌توانیم مشاهده کنیم. به عنوان مثال «سیستم‌عامل ویندوز»، تبلت پیشرفته‌ی «surface» آن، دستگاه «Xbox»، زیرساخت ابری «Azure» و حوزه‌های کاری مثل «آموزش»، «بازی»، «توسعه‌دهنده‌» و «کسب و کار» را مشاهده می‌کنیم. در تصویر بالا دو گروه تشخیص داده شده دیگر را مشاهده می‌کنید. در سمت چپ مشاهده می‌کنید که بین مفاهیم «سلامتی» و «دولت» و «سرمایه‌گذاری» ارتباطی تشخیص داده شده است که می‌تواند حاکی از این باشد که به دلیل بیماری کرونا در شرایط کنونی، دولت قصد دارد در حوزه‌ی سلامت سرمایه‌گذاری کند. در سمت راست تصویر، ارتباط خودکار تشخیص داده شده بین تمامی مرورگرهای معروف را مشاهده می‌کنیم که دوباره بدون دانش قبلی و توسط سامانه کشف شده است. در تصویر بالا نیز مشاهده می‌کنیم که مفاهیم موجود در حوزه‌ی توسعه‌ی وب مشاهده می‌شوند از جمله تکنولوژی‌های پایه که برای پیاده‌سازی آن استفاده می‌شوند. همان‌طور که در تمامی مثال‌های بالا مشاهده کردیم، روابط مختلفی از دیدگاه‌های مختلف به صورت خودکار تشخیص داده شده بودند و این در حالی که بود که هنوز کل گراف نشان داده نشده بود و همچنین هر مقدار تعداد لینک‌های بیش‌تری خزش شوند، کیفیت خروجی بهبود پیدا می‌کند. همچنین بسته به این که لینک‌های اولیه بهتر و بیش‌تری استفاده می‌شود، می‌توان به خروجی خیلی بهتر و کامل‌تری رسید. با این حال با همین مقدار خروجی می‌توان مشاهده کرد که خودکار بودن این ابزار و امکان استخراج یکسری مجموعه از کلمات مرتبط (مثلا از طریق communityها) می‌تواند برای ساخت پایگاه داده‌ای از کلمات مرتبط مفید باشد. این پایگاه داده می‌تواند در مراحل بعدی توسط ابزارهای پیشنهاددهنده‌ و جستجوگرها، تحلیل‌گرهای مبتنی بر پردازش زبان طبیعی و ... مورداستفاده قرار بگیرد. پیاده‌سازی این پروژه را در این لینک می‌توانید مشاهده کنید.این مطلب، پروژه درس شبکه‌های پیچیده در دانشگاه شهیدبهشتی است. امین برجیان امین برجیان Sun, 10 Jul 2022 09:28:08 +0430 https://virgool.io/CTO-insight/%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-%D8%AF%D8%B1-%D8%A7%D8%A8%D8%B2%D8%A7%D8%B1%D9%87%D8%A7%DB%8C-%D9%BE%D8%B1%D8%AF%D8%A7%D8%B2%D8%B4-%D8%AF%D8%A7%D8%AF%D9%87-%D9%87%D8%A7%DB%8C-%D8%AD%D8%AC%DB%8C%D9%85-m6ivjcxj68rv شبکه‌های اجتماعی و افزایش تولید حجم متن، تصویر یا ویدیو در بستر اینترنت و ... حجم عظیمی از داده را امروزه تولید می‌کنند. تمامی این شرکت‌ها بزرگ همچون لینکدن، توییتر، گوگل، مایکروسافت و ... نیاز به ذخیره‌سازی حجم عظیمی از اطلاعات و در عین پردازش آن برای استخراج اطلاعات آماری، پاسخ‌گویی نیاز کاربران، تحلیل داده و ... دارند. همچنین اکثر این شرکت‌ها اگر چه روش‌هایی را در طول زمان برای مدیریت داده‌های خود در نظر گرفته‌اند، اما هر کدام معمولا مقالات یا ابزارهایی را از روش‌های نگهداری و پردازش داده‌ی خود در طول زمان منتشر و عمومی کرده‌اند. هر کدام از این ابزارها به شکل مختلفی بخش یا کلیه‌ی نیازمندی حوزه‌ی داده‌های حجیم را پوشش داده‌اند. به طور کلی، می‌توانیم ابزارهای موجود در حوزه‌ی داده‌های حجیم را در یک طیف قرار دهیم که دو سر این طیف به شکل زیر است:فراهم‌کردن بستری برای ذخیره‌سازی دادهفراهم‌سازی امکانات پردازش و پرس‌وجواکثر ابزارها معمولا به دو سر این طیف نزدیک هستند و بخشی از ابزارها نیز در میانه قرار دارند. هدف در این پروژه این هست که تا حد خوبی معماری ابزارهای مختلفی از این طیف را مورد بررسی قرار دهیم.اکثریت تمرکز در این مقاله بر روی رویکرد صنعتی (مرور ابزارها، فناوری‌ها و ..) می‌باشد. البته تعداد این ابزارها بسیار زیاد می‌باشد و همگی آن‌ها نیز به صورت مبنع‌باز نبوده و تنها تعدادی مقاله در مورد آن‌ها منتشر شده است. با این حال تلاش بر این بوده است که اکثر ابزارهای معروف پوشش داده شوند. بررسی‌های این مقاله در مورد اکثر ابزارهای موجود در بخشی زیر می‌باشد:Apache HDFSApache Hadoop YARNApache HBaseApache SparkApache StormApache FlinkApache DrillApache HiveApache PigApache ImpalaApache FlumeApache OozieApache ZooKeeperApache AccumuloPrestoDbApache SamzaApache TezApache BeamApache Kuduدر ادامه رویکرد یکسانی برای بررسی هر کدام از ابزارهای بالا مشخص شده است. برای این منظور یکسری معیارهای مشخص تعیین شده و هدف بر این است تا هر کدام از این معیارها برای ابزارهای ارائه‌شده در فهرست بالا بررسی شود.نام ابزارکارکرد اصلی: نگهداری داده، مدیریت، پردازش داده، پایگاه‌داده، زمان‌بند، استخراج یا وارد‌سازی داده، ...توضیح کارکرد اصلیویژگی‌های کارکردیمعماری: خلاصه ساختار و مدل‌های معماری ابزاردسترس‌پذیری: تصمیمات معماری در زمینه‌ی Availabilityکارایی: تصمیمات معماری در زمینه‌ی Performanceمقیاس‌پذیری: تصمیمات معماری در زمینه‌ی Scalabilityتعامل‌پذیری: شامل رابط کاربری، پروتکل‌های پشتیبانی‌کننده، زبان‌های برنامه‌نویسی پشتیبانی‌شونده، ...محدودیت‌ها: خلاصه محدودیت‌های ابزاردر ادامه به ترتیب برای بخشی از فهرست ابزارها که بررسی شده‌اند، توضیحات هر کدام از معیارهای بالا را مشاهده می‌کنیم.ابزار Apache Hadoop Distributed File System (HDFS)کارکرد اصلی ابزار نگهداری داده است. این ابزار مجموعه‌ای از نرم‌افزارهای منبع باز است که استفاده از شبکه‌ای از رایانه‌های زیادی را برای حل مشکلات مربوط به حجم عظیم داده و محاسبات تسهیل می‌کند. بخش HDFS این ابزار یک چارچوب نرم‌افزاری برای ذخیره‌سازی توزیع شده فراهم می‌کند.ویژگی‌های کارکردیفضای ذخیره‌سازی یکپارچه توزیع‌شده: این ابزار یک انتزاع برای ذخیره‌سازی داده در چندین گره از کلاستر به صورت توزیع‌شده ایجاد می‌کند. مقاوم‌بودن نسبت به خرابی دیسک‌های نگهداری دادهپشتیبانی از فرمت‌های متنوع فایل برای ذخیره‌سازی دادهدسترسی و پردازش سریع‌ترمعماریابزار یک سیستم فایل با ساختار بلوکی است که در آن هر فایل به بلوک‌هایی با اندازه از پیش تعیین شده تقسیم می‌شود. این بلوک‌ها در یک خوشه (cluster) از یک یا چند ماشین ذخیره می‌شوند. این ابزار از معماری Master/Slave پیروی می‌کند، که در آن یک خوشه از یک گره اصلی (NameNode) تشکیل شده است و همه گره‌های دیگر، گره‌های برده (DataNodes) هستند. HDFS را می‌توان بر روی طیف وسیعی از سرورها که صرفا جاوا را پشتیبانی می‌کنند مستقر کرد. با توجه به کارکرد Namenode، این مولفه به محیطی با فضای ذخیره‌سازی کم و منابع محاسباتی بالا نیاز دارد.ساختار ساده معماری ابزار HDFS (منبع عکس)وظایف Namenode به شرح زیر می‌باشد:این مولفه‌ی اصلی است که گره‌های برده (DataNodes) را نگهداری و مدیریت می‌کند.فراداده‌های (metadata) تمام فایل‌های ذخیره‌شده را ثبت می‌کند مانند مکان بلوک‌های ذخیره شده، اندازه فایل‌ها، مجوزها، سلسله مراتب و غیره.هر تغییری که در فراداده سیستم فایل رخ می‌دهد را ثبت می‌کند. به عنوان مثال، اگر فایلی حذف شود، بلافاصله آن را در Edit Log ثبت می‌کند.به طور منظم یک Heartbeat و یک گزارش بلوک از تمام گره‌های برده خوشه دریافت می‌کند تا اطمینان حاصل شود که DataNodes فعال هستند.مسئول مراقبت از ضریب تکرار (replication) همه بلوک‌ها است. (برای افزایش مقاوم‌پذیری)در صورت خرابی DataNode، هدف‌های جدید را برای کپی‌های جدید انتخاب می‌کند، استفاده از دیسک را متعادل می‌کند و ترافیک ارتباطی به گره‌های برده را مدیریت می‌کند.تمام داده‌ها در گره‌های برده ذخیره می‌شود و از این رو به منابع ذخیره‌سازی بیشتری نیاز دارد. این گره‌های برده می‌توانند سروهای معمولی در محیط توزیع شده باشند. گره‌های برده درخواست‌های سطح پایین خواندن و نوشتن را از کاربرهای سیستم فایل انجام می‌دهد. به منظور ذخیره‌سازی داده در هنگام نوشتن یا خواندن داده به منظور پردازش، ارتباط کاربر با گره اصلی برقرار می‌شود و خود گره اصلی این درخواست را در صورت نیاز به گره‌های برده‌ی مرتبط انتقال می‌دهد.دسترس‌پذیریدر معماری ارائه‌شده برای این ابزار، گره اصلی به صورت پیشفرض نقطه‌ی شکست سیستم (Single Point of Failure) محسوب می‌شود. ابزار در دسترس‌بودن گره اصلی را با اجازه‌دادن به ما برای داشتن دو گره اصلی در پیکربندی فعال/غیرفعال (active/passive) فراهم می‌کند. برای این منظور می‌توان از یکی از رویکردهای زیر استفاده کنیم:استفاده از Quorum Journal Nodes: گره اصلی آماده به کار و غیرفعال از طریق یک گروه جداگانه از گره‌ها به نام گره‌های Journal با یکدیگر همگام می‌شوند. گره‌های Journal از ساختار حلقه پیروی می‌کنند که در آن گره‌ها به یکدیگر متصل می‌شوند تا یک حلقه را تشکیل دهند. یک گره درخواستی را که به آن ارسال می‌شود، سرویس می‌دهد و اطلاعات را در سایر گره‌های حلقه کپی می‌کند. این قابلیت تحمل خطا را در صورت رخداد خطا در گره‌های Journal فراهم می‌کند.فضای ذخیره‌سازی مشترک با استفاده از NFS: گره غیرفعال و فعال با استفاده از یک مخزن ذخیره‌سازی مشترک با یکدیگر همگام می‌شوند. گره فعال هرگونه تغییر انجام شده در فضای نام خود را در یک EditLog موجود در این مخرن مشترک ثبت می‌کند. گره غیرفعال تغییرات ایجاد شده را از طریق مخزن مشترک می‌خواند و آن را در فضای حافظه خود اعمال می‌کند. (در این حالت لازم است که فضای مشترک خود دارای دسترسی بالا باشد تا خوشه هم دسترسی بالا باشد)برای افزایش دسترس‌پذیری گره‌های برده، مکانیزم‌های مختلفی شامل تکرارکردن داده در گره‌ها (replication)، مکانیزم آگاهی از وضعیت و ساختار Rack ها و ... ارائه شده است تا در صورت از دسترس خارج‌شدن چندین گره برده از خوشه (بسته به نحوه‌ی تنظیمات) مشکلی برای خوشه ایجاد نشود. از آنجایی که ما از سخت‌افزار برای نگهداری داده استفاده می‌کنیم و می‌دانیم که میزان خرابی این سخت‌افزارها بسیار بالا است، بنابراین اگر یکی از گره‌ها خراب شود، HDFS همچنان کپی آن بلوک‌های داده از دست رفته را خواهد داشت. به همین دلیل تا حد خوبی به خطاهای سخت‌افزاری در سطح نگهداری داده مصون هستیم.کاراییبه منظور کاهش سربار ابزار در هنگام راه‌اندازی (بعد از رخداد فاجعه یا خاموش‌شدن موقتی به دلیل تعمیرات)، یک فرایند دیگر به نام Secondary Namenode ایجاد شده است. (این ابزار برای HA کردن مولفه نیست و صرفا به منظور ایجاد یکسری تصویر لحظه‌ای از وضعیت گره‌های اصلی هست)عملکرد مولفه‌ی Secondary Namenode (منبع عکس)کارکردهای Secondary Namenode شامل موارد زیر می‌شود:به طور مداوم تمام سیستم‌های فایل و ابرداده‌ها را از فضای حافظه گره اصلی می‌خواند و آن را در دیسک یا سیستم فایل می‌نویسد.تاخیرات اخیر روی شوخه (EditLogs) را با تصویر قبلی وضعیت خوشه (FsImage) ترکیب می‌کند تا تصویر جدیدی از وضعیت خوشه ایجاد نماید.در نهایت وضعیت جدید خوشه را به گره اصلی کپی می‌کند، که هر زمان که گره اصلی به هر دلیلی شروع به اجرای دوباره کرد، سریع‌تر بالا آمده و به وضعیت جاری برسد.گره اصلی تضمین می‌کند که همه کپی‌های یک بلاک در یک Rack ذخیره نشوند. برای کاهش تأخیر و همچنین ارائه تحمل خطا از یک الگوریتم هوشیاری Rack داخلی استفاده می‌شود. به عنوان مثال با در نظر گرفتن ضریب تکرار 3، الگوریتم Rack Awareness می‌گوید که اولین نسخه از یک بلوک در یک Rack محلی و دو کپی بعدی در یک Rack متفاوت (از راه دور) ذخیره شوند. مزایای الگوریتم Rack Awareness شامل موارد زیر است:بهبود عملکرد شبکه: ارتباط بین گره‌های مستقر در Rack‌های مختلف از طریق سوئیچ هدایت می‌شود. به طور کلی، پهنای باند شبکه بیشتری را بین ماشین‌های موجود در یک Rack نسبت به ماشین‌هایی که در Rack‌های مختلف قرار دارند، مشاهده می‌کنیم. بنابراین از طریق این الگوریتم، ترافیک نوشتن در بین Rack‌های مختلف کاهش یافته و در نتیجه عملکرد نوشتن بهتری ارائه می‌شود. همچنین، به دلیل استفاده از پهنای باند چندین Rack، سرعت خواندن افزایش می‌یابد.جلوگیری از از دست رفتن داده‌ها: حتی اگر کل Rackبه دلیل خرابی سوئیچ یا قطعی برق از کار بیفتد، داده هدف در Rackهای دیگری نیز وجود خواهد داشت.یکی از چالش‌های مهم در حوزه‌ی داده‌های حجیم بحث نگهداری و مقاوم‌بودن نبست به از دست رفتن داده است. معمولا وقتی یک سرور را به تنهایی نگاه می‌کنیم تکنیک‌های مختلفی مثل RAID و ... استفاده می‌شود تا نسبت به از دست‌رفتن داده مقاوم شویم و در عین حال کارایی خواندن و نوشتن افزایش داده شود. اما این رویکردها و همچنین اتصال حجم زیادی دیسک به یک سرور یا استفاده از دیسک‌های حجیم برای سرور مناسب نیست. استفاده از دیسک‌های حجیم با توجه به سرعت محدود IO یک دیسک می‌تواند کارایی را کاهش دهد و همچنین در تعداد دیسک‌ها نیز محدودیت وجود دارد. رویکردی که در HDFS استفاده می‌شود این است که داده در گره‌های کلاستر توزیع می‌شود و مدیریت این توزیع‌ها و استفاده از دیسک تمامی سرورها به صورت یکپارچه توسط این ابزار فراهم می‌شود. با توجه به موازی‌سازی کارایی خواندن داده‌ها و همچنین نوشتن داده‌ها (با توجه به تکرار داده‌ها برای مقاوم‌سازی) افزایش می‌یابد.به منظور دستیابی به پردازش با کارایی بالا، پردازش را به داده و نه داده را به پردازش منتقل می‌کند. در واقع به جای انتقال داده‌ها به یک گره و سپس پردازش آن، منطق پردازش به گره‌های مختلف ارسال می‌شود و سپس داده‌ها به موازات گره‌های مختلف پردازش می‌شوند. سپس نتایج پردازش شده به گره‌ای ارسال می‌شود که در آن نتایج ادغام می‌شوند و پاسخ به کاربر برگردانده می‌شود.مقیاس‌پذیریبا توجه به معماری ارائه‌شده توسط این ابزار، به راحتی از طریق افزودن گره‌های اصلی می‌توانیم فضای ذخیره‌سازی و قدرت پردازشی خوشه را افزایش دهیم. البته این مورد به راحتی در مورد گره‌های اصلی صادق نیست و نیاز به افزایش منابع به صورت عمودی شامل فضای اصلی و ... (Vertical Scaling) دارد. با این حال به راحتی می‌توانیم گره‌های برده را به صورت افقی افزایش دهیم و تعدادشان برای تقسیم بار و پردازش سریع‌تر اضافه کنیم. (Horizontal Scaling)تعامل‌پذیریاز آن‌جایی که یک فرمت یکسان برای تمام نیازمندی‌ها و سازمان‌های دنیا کافی نیست، وجود پشتیبانی از فرمت‌های متنوع و عدم ایجاد محدودیت در این زمینه بسیار مهم است. HDFS می‌تواند انواع داده‌ها را شامل ساختاریافته، نیمه ساختاریافته یا بدون ساختار ذخیره کند.ابزار نوشته‌شده امکان ارتباط با کلاستر HDFS را از طریق رابط کنسولی و همچنین محیط وب فراهم می‌کند. البته قابلیت‌های ارائه‌شده در محیط وب شامل موارد محدودی مثل مشاهده‌ی فایل‌ها، وضعیت کنونی کلاستر، تنظیمات و ... می‌باشد و برای بهره‌گیری از تمامی قابلیت‌های مدیریت و نگهداری ابزار استفاده از رابط کنسولی الزامی است. این ابزار مبتنی بر زبان Javaپیاده‌سازی شده است و به همین دلیل کلاینت‌های آن معمولا برای زبان‌های مبتنی برا JVM مثل جاوا و اسکالا بیش‌تر می‌باشد. از کلاینت‌ها به منظور پردازش داده‌های کلاستر استفاده می‌شود.محدودیت‌هادسترسی به داده‌ها با تاخیر کم (دسترسی سریع به بخش‌های کوچک داده) در این ابزار امکان‌پذیر نیست.ساختار HDFS تنها زمانی مناسب‌ است که هدف اصلی خواندن داده‌ها باشد و داده‌های نوشته‌شده را ویرایش نکنیم.ساختار HDFS برای سناریوهایی مناسب است که فایل‌های کمی داشته باشیم اما حجم این فایل‌ها زیاد باشد. در مواردی که معمولا حجم زیادی فایل کوچک داریم به دلیل سربار نگهداری فراداده‌های مربوط به داده‌ها، ابزار خوب عمل نخواهد کرد.ابزار Apache Hadoop Yet Another Resource Negotiator (YARN)کارکرد اصلی ابزار مدیریت پردازش داده و زمان‌بندی است. این ابزار به روش‌های مختلف پردازش داده مانند پردازش گراف، پردازش تعاملی، پردازش جریانی و همچنین پردازش دسته‌ای اجازه می‌دهد تا داده‌های ذخیره شده در سیستم توزیع‌شده هادوپ را پردازش کنند. به عبارتی این ابزار امکان اجرای انواع رویکردهای پردازش داده‌‌ی حجیم فراتر از MapReduce را فراهم می‌کند.ویژگی‌های کارکردیاین ابزار همان‌طور که گفته شد در کنار ابزار HDFS مورد استفاده قرار می‌گیرد. این ابزار به عنوان بخش پردازشی اصلی هادوپ شناخته می‌شود و وظیفه‌ی مدیریت پردازش‌هایی را که روی کلاستر انجام می‌شوند، بر عهده دارد. همچنین این ابزار وظایف زمان‌بندی کارها را (Job Scheduling) نیز انجام می‌دهد. برای این منظور تمام فعالیت‌های پردازشی را با تخصیص منابع (بر اساس سیاست‌های مختلف) و زمان‌بندی وظایف انجام می‌دهد.معماریاین ابزار از دو مولفه‌ی اصلی به نام Resource Manager و Node Manager تشکیل شده است و دو بخش فرعی‌تر آن Application Master و Container است.نحوه‌ی ارتباط بخش‌های مختلف ابزار (منبع عکس)بخش Resource Manager وظایف زیر را بر عهده دارد:تخصیص منابع توسط این بخش ابزار انجام می‌شود.درخواست‌های پردازش را از سمت کاربران دریافت می‌کند و سپس بخش‌هایی از درخواست‌ها را به Node Manager های مربوطه می‌فرستد، جایی که پردازش واقعی انجام می‌شود.بهینه‌سازی استفاده از خوشه مانند استفاده از همه‌ی منابع در تمام مدت با در نظر گرفتن محدودیت‌های مختلف مانند تضمین ظرفیت منابع سرورها، انصاف (fairness)، تعهد سطح سرویس و ...این بخش از مولفه خود از دو بخش داخلی و مهم تشکیل شده است:زمان‌بند (Scheduler): زمانبند، مسئول تخصیص منابع به برنامه‌های مختلف در حال اجرا با توجه به محدودیت سرورها، صف‌ها و ... می‌باشد. این بخش به صورت خالص تنها زمان‌بندی را انجام می‌دهد و بعد از زمان‌بندی اجرای موفق آن یا وضعیت آن توسط این بخش بررسی نمی‌شود. برنامه‌ریزی را بر اساس منابع موردنیاز برنامه‌ها انجام می‌دهد. دو نوع زمان‌بندی پیش‌فرض به نام زمانبندی بر اساس ظرفیت منابع و زمانبندی منصفانه در حال حاضر پشتیبانی می‌شوند.مدیریت برنامه (Application Manager): مسئولیت پذیرش برنامه‌های ارسالی از سمت کاربران را بر عهده دارد. اولین ظرف اجرا (Container) را از مدیر منابع برای اجرای مدیر برنامه (Application Master) خاص برنامه ارسالی مورد استفاده قرار می‌دهد. اجرای کلیه‌ی مدیر برنامه‌های مختلف را در یک خوشه مدیریت می‌کند و خدماتی از جمله راه‌اندازی مجدد ظرف اجرا را در صورت خرابی ارائه می‌دهد.بخش گره اجرایی (Node manager) روی هر گره برده حاوی مولفه‌ی DataNode نصب می‌شود و وظیفه اجرای درخواست‌های آمده به سمتش را بر روی گره‌های برده به عهده دارد. استفاده از منابع (حافظه، CPU و ...) ظروف اجرایی جداگانه را نظارت می‌کند و مدیریت لاگ را نیز انجام می‌دهد. همچنین طبق دستور مدیر منابع، ظرف اجرایی (Container) را در صورت لزوم متوقف می‌کند.به ازای هر برنامه (Job) که از طریق این ابزار و به درخواست کاربر برنامه‌ریزی می‌شود، یک مدیر برنامه (Application Master) منحصر به فرد ایجاد می‌شود. این مولفه اجرای برنامه را در خوشه هماهنگ می‌کند و همچنین خطاها را مدیریت می‌کند. وظیفه آن تعامل با منابع از طریق مدیر منابع (Resource Manager) و همکاری با گره‌های اجرایی (Node Manager) برای اجرا و نظارت بر وظایف اجزا می‌باشد.بخش ظرف (Container) مجموعه‌ای از منابع فیزیکی مانند RAM، هسته‌های CPU و دیسک‌های موجود در یک گره خوشه است که برای یک برنامه ارسالی از سمت کاربر استفاده می‌شود تا مقدار خاصی از منابع موجود در یک گره خاص را برای آن فراهم کند.دسترس‌پذیریامکان بالا آوردن چندین نسخه از مدیر منابع (Resource Manager) برای افزایش دسترس‌پذیری سرویس ممکن می‌باشد. نحوه‌ی بالا بردن دسترس‌پذیری ابزار کردن به صورت حالت فعال/غیرفعال می‌باشد و بعد از اتصال به Zookeeper می‌تواند به صورت خودکار در صورت متوقف‌شدن مولفه فعال، مولفه‌ی غیرفعال جایگزین آن شود. (بدیهی است که دسترس‌پذیری ابزار وابسته به تنظیم درست ابزار وابسته می‌باشد)همچنین Resource Manager کارهای ارسالی از سمت کاربر را بر روی گره‌های اجرایی (Node Manager) اجرا می‌کند که در صورت از دست‌رفتن هر کدام از آن‌ها (به دلیل خرابی ماشین یا ...)، امکان اجرای آن قسمت از کار بر روی گره اجرایی دیگری فراهم هست. به همین دلیل نسبت به از دست‌رفتن تعدادی گرده در خوشه بسته به تنظیمات صورت‌ گرفته مقاوم می‌باشد.کاراییاین ابزار از طریق مکانیزم‌های داخلی خود (مانند Node Manager و Scheduler) می‌تواند به صورت مناسب و همچنین پویا (dynamic) منابع موردنیاز برای اجرای درخواست‌های کاربر را تخصیص دهد. فراهم‌نمودن رویکردهای مختلف توسط این ابزار از جمله معیارهای مختلف مثل انصاف، بهره‌وری و ... برای نحوه‌ی تخصیص منابع، بررسی پویای منابع در هنگام اجرا، اولویت‌بندی و ... از ویژگی‌های زمان‌بند این ابزار می‌باشد. البته بدیهی است که برای دستیبای به کارایی خوب، لازم است که که ابزار هادوپ به خوبی تنظیم شود.مقیاس‌پذیریبا توجه به سوارشدن این ابزار بر روی کلاستر هادوپ و مقیاس‌پذیری خود هادوپ، این ابزار نه تنها مقیاس‌پذیری هادوپ را کاهش نداده بلکه با رویکری مشابه امکان پردازش عظیم بر روی کلاستر هادوپ را با رویکردی مقیاس‌پذیر مشابه هادوپ فراهم کرده است. البته بدیهی است که برای دستیبای به مقیاس‌پذیری خوب، لازم است که که ابزار هادوپ به خوبی تنظیم شود.تعامل‌پذیریاین ابزار نه تنها بستری را برای پردازش‌های توزیع‌شده روی کلاستر هادوپ فراهم می‌کند، بلکه این ویژگی را با انعطاف زیاد فراهم می‌کند. به این صورت که نه تنها امکان زمان‌بندی و مدیریت منابع برای برنامه‌های MapReduce که فریم‌ورک محبوب هادوپ در زمینه‌ی اجرای پردازش‌های توزیع‌شده می‌باشد را فراهم می‌کند، بلکه برای ابزارهای توسعه‌داده‌شده توسط دیگر شرکت‌های مثل اسپارک، Hive و ... نیز بستری را فراهم می‌کند. به همین دلیل تقریبا در اکثر دیگر ابزارها به جای استفاده از زمان‌بند و مدیریت منابع داخلی، به صورت مستقیم از خود YARN استفاده می‌شود.این ابزار این امکان را نیز فراهم می‌کند تا از طریق docker containerization چندین نسخه از یک برنامه در کنار هم اجرا کنیم که برای برخی نیازها مفید می‌باشد.فراهم‌نمودن قابلیت‌ها از جمله مشاهده کارهای در حال اجرا، منابع تخصیص‌داده‌شده، میزان پیشرفت کارها و مدیریت لاگ از دیگر مزایای خوب این ابزار می‌باشد. این موارد هم از طریق API و هم از طریق محیط وب ساده‌ای فراهم شده است. از طریق رابط تعاملی (CLI) نیز می‌توان با این ابزار تعامل کرد.محدودیت‌هابا توجه به قرارگرفتن این ابزار بر روی ابزار هادوپ، محدودیت‌های مشاهده‌شده برای آن ابزار نیز در این قسمت صادق می‌باشد.ابزار Apache HBaseکارکرد اصلی ابزار، فراهم‌سازی پایگاه داده درحوزه‌ی کلان‌داده می‌باشد. HBase یک پایگاه داده متن‌باز، چندبعدی (multidimensional)، توزیع شده، مقیاس‌پذیر و NoSQL است. HBase بر روی زیرساخت HDFS اجرا می‌شود و قابلیت‌هایی یک پایگاه‌داده را در اختیار Hadoop قرار می‌دهد. این ابزار به گونه‌ای طراحی شده است که با تحمل خطای بالا، امکان ذخیره مجموعه بزرگی از داده‌های توزیع‌شده را ارائه می‌دهد.ویژگی‌های کارکردیقابلیت خواندن و نوشتن سریع را در مجموعه داده‌های عظیم با توان بالا و تاخیر کمدسترسی سریع و تصادفی (random) به حجم زیادی از داده‌هاپشتیبانی از داده‌های نیمه ساختار یافته یا بدون ساختار یا ترکیبی از هر دوذخیره‌سازی داده‌ها به صورت ستونی (column oriented)قابلیت نگهداری چندین نسخه‌ برای یک داده با کلید مشخصمعماریاز نظر شیوه‌ی نگهداری داده، این ابزار از روش column oriented برای نگهداری داده استفاده می‌کند که به منظور ذخیره‌سازی حجم زیادی داده و همچنین انجام پردازش‌های OLAP مناسب‌تر است. برای این منظور همانند پایگاه‌داده‌های معمولی شامل جدول (table) می‌باشد اما هر جدول به صورت ستونی شامل تعدادی Column Family می‌باشد. یک Column Family می‌تواند از چندین Column Qualifier تشکیل شده باشد اما تمامی محتوای هر Column Family به صورت پیوسته روی دیسک ذخیره می‌شود. ذخیره‌سازی داده‌ها به همراه زمان (Timestamp) مربوط به ویرایش/اضافه‌شدن می‌باشد که امکان جستجو روی نسخه‌های مختلف یک داده را فراهم می‌کند. در نگاه قضیه‌ی CAP، تمرکز HBase بر روی فراهم‌سازی دسترس‌پذیری (Availability) و سازگاری (Consistency) بوده است. در این راستا، در یک ردیف، ابزار خواندن و نوشتن واحد (atomic) را فراهم می‌کند.این ابزار از سه مولفه‌ی اصلی شامل سرور HBase Region، سرور HMaster و منطقه‌ها (Regions) تشکیل‌شده است که برای هماهنگی با یکدیگر از ابزار خارجی Zookeeper استفاده می‌کنند.معماری ابزار HBase (منبع عکس)یک جدول به چند منطقه (Region) تقسیم می‌شود. منطقه یک محدوده مرتب‌شده از ردیف‌هایی است که داده‌ها را بین یک کلید شروع و یک کلید پایان ذخیره می‌کند. یک منطقه دارای اندازه پیش‌فرض 256 مگابایت است که می‌تواند بر اساس نیاز تغییر کند. یک گروه از مناطق توسط یکسرور منطقه (Region Server) به کاربران (clients) ارائه می‌شود. (مسئول مدیریت، اجرای عملیات خواندن و نوشتن در آن مجموعه از مناطق است) یک سرور منطقه می‌تواند تقریباً شامل 1000 منطقه باشد که نشان‌دهنده‌ی قدرت پردازشی خوب این ابزار است.سرور HMaster عملیات ایجاد و حذف جداول (DDL) را انجام می‌دهد و تخصیص مناطق به سرورهای مناطق توسط آن انجام می‌شود. هماهنگی و مدیریت مناطق به خصوص در هنگام راه‌اندازی بر عهده‌ی آن می‌باشد. در حین بازیابی و متعادل‌سازی بار، منطقه‌ها را دوباره به سرورهای منطقه اختصاص می‌دهد. تمام سرورهای مناطق را با کمک Zookeeper در خوشه نظارت می‌کند و فعالیت‌های بازیابی را هر زمان که سرور منطقه‌ای از کار بیفتد، انجام می‌دهد. Zookeeper مانند یک هماهنگ‌کننده در محیط توزیع‌شده ابزار عمل می‌کند و با برقراری ارتباط از طریق نشست‌ها، به حفظ وضعیت سرور در داخل خوشه کمک می‌کند. هر سرور منطقه به همراه سرور HMaster ضربان قلب مداوم را در فواصل منظم به Zookeeper می‌فرستد و بررسی می‌کند که کدام سرور زنده و موجود است. (وضعیت سرورهای منطقه توسط جدول META در Zookeeper نگهداری می‌شود)دسترس‌پذیریهمان‌طور که در بخش معماری توضیح داده شد، تعداد زیادی سرور منطقه وجود دارد و قابلیت بازیابی خطا برای هر کدام از آن‌ها به صورت خودکار توسط زوکیپر وجود دارد. در نتیجه به راحتی قابلیت مقیاس‌پذیری و در عین حال فراهم‌سازی دسترس‌پذیری دارند. همچنین بخش HMaster می‌تواند با کمک Zookeeper به صورت دسترس‌پذیر بالا با معماری Active/Passive اجرا شود و دسترس‌پذیری خوشه را افزایش دهد.ابزار از طریق ماکنیزم WAL (Write Ahead Log) که بر روی سراسر خوشه‌ی HDFS ارائه می‌دهد، قابلیت این را دارد که در زمان رخداد خطا و مشکل، به صورت خودکار خود را ترمیم و راه‌اندازی مجدد کند.کاراییفشرده‌سازی و عملیات درون حافظه (In-memory) برای برآورده‌کردن نیازهای خواندن و نوشتن سریع فراهم می‌کند.از Block Cache در سرورهای منطقه استفاده می‌شود که به صورت نگهداری داده‌های اخیر (LRU) عمل کرده و داده‌هایی را که اخیرا مورد دسترسی قرار گرفته‌اند، برای دسترسی‌های بعدی در مموری نگه می‌دارد.از تکنیک‌های Bloom Filters (ساختار داده‌ای که می‌گوید آیا یک مقدار در یک مجموعه وجود دارد یا نه) برای بهینه‌سازی پرس و جو با حجم بالا پشتیبانی می‌کند و می‌تواند از طریق آن هنگام خواندن داده، حجم خوبی از داده را چشم‌پوشی کرد و میزان IO و شبکه مصرفی را کاهش داد.از آنجایی که جستجو در محدوده ردیف‌ها انجام می‌شود، ابزار کلیدهای سطر‌ها را به ترتیب واژگانی (sorted) ذخیره می‌کند. با استفاده از این کلیدهای مرتب‌شده می‌توان یک درخواست بهینه ایجاد کرد و با کمترین تاخیر پاسخ آن را دریافت کرد.از روش‌های فشرده‌سازی (compaction) مختلف به منظور فشرده‌سازی داده و حذف داده‌های اضافی استفاده می‌کند که سرعت خواندن را برای درخواست‌های آینده افزایش می‌دهد.مقیاس‌پذیریمقیاس‌پذیری افقی از نظر ذخیره‌سازی: از آن‌جایی که مجموعه داده‌ها بر روی خوشه HDFS توزیع می‌شوند، بنابراین به صورت افقی در گره‌های مختلف خوشه می‌تواند مقیاس‌پذیر باشد.مقیاس‌پذیری افقی از نظر استقرار: نحوه‌ی پیاده‌سازی و استقرار آن به صورت ماژولار (modular) بوده و این امکان وجود دارد که حداکثر بار قابل تحمل آن را با افزایش تعداد مولفه‌های در حال اجرای آن به صورت خطی روی گره‌های خوشه افزایش داد، به همین دلیل از نظر استقرار نیز مقیاس‌پذیر است.تقسیم سرورهای منطقه به صورت خودکار: به صورت خودکار با افزایش حجم داده‌ی گروهی از مناطق، سرور منطقه مربوطه به دو سرور کوچکتر شکسته می‌شود که هم مقیاس‌پذیری و امکان پردازش موازی را افزایش می‌دهد.تعامل‌پذیریبرای اتصال به کلاستر HBase در زمینه‌ی جاوا کلاینت خیلی خوبی فراهم شده است که به راحتی امکان اتصال و بهره‌وری از امکانات HBase را به صورت برنامه‌نویسی فراهم می‌کند. همچنین در زمینه‌ی روش‌های مبتنی بر Restful API و Thrift نیز امکاناتی برای اتصال کاربران فراهم شده است.محدودیت‌هابرخلاف جداول معمول که امکان عملیات Join را فراهم می‌کنند، معماری ابزار برای این منظور طراحی نشده است. به جای پایگاه داده، Joinها در لایه MapReduce مدیریت می‌شوند.هیچ پشتیبانی برای تراکنش وجود ندارد.طراحی کنونی ابزار تنها وجود یک فیلد برای ایندکس‌کردن (همان row key) را پشتیبانی می‌کند و برای مواردی که نیاز به چندین ایندکس برای جستجوی سریع‌تر نیاز باشد، به صورت پیشفرض مکانیزمی فراهم نشده است.برای نگهداری فایل‌های باینری با حجم خیلی زیاد مناسب نیست.ابزار نمی‌تواند عملکردهایی مانند SQL را انجام دهد. از ساختار SQL پشتیبانی نمی‌کند، بنابراین حاوی هیچ بهینه‌سازی برای پرس و جو نیست.هیچ مجوز یا احراز هویت داخلی وجود ندارد.ترکیب ابزار با مواردی مثل Map-Reduce، منجر به تاخیرهای غیرقابل پیش‌بینی می‌شود.ابزار Apache Sparkکارکرد اصلی ابزار پردازش داده می‌باشد. Apache Spark یک چارچوب محاسباتی خوشه‌ای منبع باز و توزیع‌شده برای پردازش بلادرنگ (real-time) محسوب می‌شود.ویژگی‌های کارکردیپردازش به صورت لحظه‌ای (به جای پردازش دسته‌ای) صورت می‌گیرد. سرعت آن چندین برابر MapReduce برای پردازش داده در مقیاس بزرگ می‌باشد.محاسبات اسپارک بلادرنگ است و به دلیل محاسبات درون حافظه آن، تأخیر کمی دارد. اسپارک برای مقیاس‌پذیری عظیم طراحی شده است و خوشه‌هایی با هزاران گره اجرا و چندین مدل محاسباتی را پشتیبانی می‌کند.اسپارک سازگاری روان با Hadoop را فراهم می‌کند. Spark یک جایگزین بالقوه برای توابع MapReduce است، در حالی که این توانایی را دارد که در بالای یک خوشه Hadoop موجود با استفاده از YARN برای زمان‌بندی منابع اجرا شود.بخش Spark Streaming برای پردازش داده‌های جریانی در زمان واقعی استفاده می‌شود. پردازش جریان‌داده‌ها با توان و تحمل خطای بالا را امکان پذیر می‌کند.بخش Spark SQL پردازش رابطه‌ای را با API برنامه‌نویسی تابعی اسپارک یکپارچه می‌کند.بخش GraphX برای پردازش داده‌های دارای ساختار درختی به صورت موازی مناسب است.بخش MLlib برای یادگیری ماشین و نیازمندی‌های مشابه مناسب است.قابلیت‌های ذخیره‌سازی و کش‌کردن اطلاعات را بر روی دیسک فراهم می‌کند.معماریدر معماری اسپارک، ما یک گره master داریم که به عبارتی برنامه ما در آن اجرا می‌شود و مدیریت کل اجرای برنامه را به عهده می‌گیرد. (به عبارتی می‌تواند هر گره‌ای باشد که قابلیت اتصال به خوشه اسپارک را دارد) همچنین در کنار این گره master، کلی گره در خوشه داریم که از آن‌ها در اسپارک با عنوان worker یاد می‌شود. در گره اصلی، برنامه درایور (driver program) را داریم که همان برنامه‌ی نوشته‌ شده‌ی ما می‌باشد. در واقعیت کدی که نوشته می‌شد به عنوان یک برنامه درایور عمل می‌کند یا اگر از shell استفاده کنیم، shell به عنوان برنامه درایور عمل می‌کند. در داخل برنامه درایور، اولین کاری که انجام می‌شود این است که یک Spark Context ایجاد می‌شود. این Context به صورت یک دروازه برای همه عملکردهای اسپارک عمل می‌کند.معماری ساده ابزار (منبع عکس)بخش Context با مدیر خوشه برای مدیریت کارهای مختلف هماهنگ می‌شود. برنامه درایور و Context از اجرای کار در خوشه مراقبت می‌کنند. یک کار یا برنامه به وظایف (task) متعددی تقسیم می‌شود که بر روی گره‌های کارگر توزیع می‌شوند (توسط Executorsها اجرا می‌شوند) و سپس نتیجه به Context برگردانده می‌شود. گره‌های کارگر، گره‌های برده‌ای هستند که کار آن‌ها اساسا اجرای وظایف است. هنگامی که کاربر کد برنامه کاربردی را برای اجرا ارسال می‌کند، درایور به طور ضمنی کد کاربر را که شامل تبدیل‌ها و اقدامات است به یک گراف غیر حلقه‌ای منطقی (logical DAG) تبدیل می‌کند. در این مرحله بهینه‌سازی‌هایی مانند جابه‌جایی اجرای دستورات و ... نیز انجام می‌شوند. پس از آن، نمودار منطقی با چندین مرحله به طرح اجرای فیزیکی نهایی (Physical Plan) که همان اجرای واقعی روی خوشه اسپارک می‌باشد، تبدیل می‌شود. پس از تبدیل به یک طرح اجرای فیزیکی، وظایف (tasks) مختلف مبتنی بر آن ایجاد می‌شوند و به خوشه ارسال می‌شوند. قبل از ارسال، ابتدا از طریق Cluster Manager منابع لازم درخواست می‌شود و مدیر خوشه اجراکننده‌ها را (Executors) در گره‌های کارگر راه‌اندازی می کند. سپس وظایف برای مجریان ارسال می‌شوند و مجری‌ها شروع به کار می‌کنند، خودشان را نزد Context ثبت می‌کنند. در طول اجرای وظایف، برنامه درایور مجموعه‌ای از مجریانی که اجرا می‌شوند را نظارت می‌کند. درایور گره همچنین وظایف آینده را بر اساس قراردادن داده‌ها زمان‌بندی می‌کند.وظایفی که توسط اسپارک ایجاد می‌شوند، مبتنی بر ساختارهای داده‌ی RDD هستند. کلمه‌ی RDD مخفف سه عبارت زیر می‌باشد:ارتجاعی (Resilient): تحمل خطا دارد و قادر به بازسازی داده‌ها در صورت خرابی است.توزیع شده (Distributed): داده‌‌ها توزیع‌شده بین گره‌های متعدد در یک خوشه هستند.مجموعه‌داده (Dataset): مجموعه‌ای از داده‌های پارتیشن‌بندی‌شدهدسترس‌پذیریاسپارک به منظور فراهم‌سازی دسترس‌پذیری بالا از معماری active/passive برای گره‌های اصلی استفاده می‌کند. همچنین در زمینه‌ی کارگرها نیز به صورت تحمل‌خطا عمل کرده و در صورت پیش‌آمدن هر مشکلی برای یکی از گره‌ها، از طریق دیگر گره‌ها به اجرای دوباره‌ی آن بخش خاص از برنامه می‌پردازد. (البته لازمه‌ی آن این است که داده فقط بر روی آن گره خاص نباشد. مثلا از طریق HDFS داده تکرار شده باشد و در چندین گره موجود باشد وگرنه خود داده باعث عدم دسترس‌پذیری بالا خواهد شد.)اسپارک با استفاه از تعریف RDD و تبدیل داده‌های ورودی به این انتزاع تلاش می‌کند تا در عین مستقل‌شده نسبت به داده‌ی ورودی، دسترس‌پذیری و تحمل خطای بالا را ایجاد کند.کاراییاگر تعداد کارگران افزایش داده شود، کارها می‌توانند به وظایف بیش‌تری تقسیم شوند و آن‌ها به طور موازی در چندین گره کارگر اجرا شوند که بسیار سریع‌تر خواهد بود. با افزایش تعداد کارگران، اندازه حافظه نیز افزایش می‌یابد و می‌توانید کارها را در حافظه اصلی نگه داشت (cache) تا سریع‌تر اجرا شوند.همچنین ابزار قادر است از طریق پارتیشن‌بندی کنترل‌شده داده‌ها، به سرعت بسیار زیاد دست یابد. استفاده از این روش به موازی‌سازی پردازش داده‌های توزیع‌شده با حداقل ترافیک شبکه کمک می‌کند.اسپارک ارزیابی خود را تا زمانی که کاملا ضروری باشد به تاخیر می‌اندازد. این یکی از عوامل کلیدی در سرعت آن است. برای این منظور، اسپارک تبدیلات و دستورهای کاربر را به یک گراف غیر حلقه‌دار جهت‌دار (DAG) محاسبات اضافه می‌کند و تنها زمانی که کاربر مقداری داده را درخواست کند، این DAG واقعاً اجرا می‌شود. (همچنین قبل اجرا محتوای گراف تا حد امکان ساده و بهینه می‌شود)مقیاس‌پذیریبا توجه به معماری برای اسپارک که شامل گره‌های اصلی و کارگر می‌شود و اجرای وظایف تنها توسط کارگرها می‌باشد، می‌توان با افزایش تعداد کارگرها به صورت خطی قدرت پردازشی و همچنین حجم پردازش موازی یا تحمل خطا را افزایش داد.تعامل‌پذیریاسپارک به منظور تعامل با خوشه، APIهای سطح بالایی را در جاوا، اسکالا، پایتون و R ارائه می‌دهد. کد اسپارک را می‌توان به هر یک از این چهار زبان نوشت. همچنین اسپارک نصب‌شده به صورت پیش‌فرض برای یکسری زبان‌ها از جمله اسکالا و پایتون رابط کنسولی فراهم نموده است.اسپارک از چندین منبع‌داده مانند Parquet، JSON، Hive و Cassandra جدا از فرمت‌های معمول مانند فایل‌های متنی، CSV و RDBMS پشتیبانی می‌کند. اسپارک مکانیزمی قابل اتصال برای دسترسی به داده‌های ساختاریافته از طریق Spark SQL نیز فراهم می‌کند.محدودیت‌هاهیچ سیستم مدیریت فایلی در اسپارک وجود ندارد و به همین دلیل باید با ابزارهای دیگر مانند Hadoop یا هر پلتفرم مبتنی بر ابر (cloud) استفاده شود. اسپارک به طور کامل از پردازش جریان‌داده به صورت بلادرنگ (real-time) پشتیبانی نمی‌کند. اسپارک، جریان داده زنده را به دسته‌هایی تقسیم می‌کند و عملیاتی مانند اتصال، نگاشت یا کاهش و ... بر روی این دسته‌ها اعمال می‌کند. پس از پردازش، نتیجه دوباره به دسته‌ها تبدیل می‌شود. به این ترتیب، جریان اسپارک فقط پردازش میکرو دسته‌ای است و از پردازش کاملاً بلادرنگ پشتیبانی نمی‌کند.در پردازش کلان‌داده، نگهداری داده‌ها در حافظه آسان نیست و در حین کار با اسپارک مصرف حافظه بسیار بالا دارد.تأخیر اسپارک زیاد است که باعث کاهش توان عملیاتی آن می‌شود.ابزار Apache Stormکارکرد اصلی ابزار پردازش داده بلادرنگ است. چارچوب محاسباتی پردازش جریانی منبع باز و توزیع‌شده است. پردازش جریان‌های نامحدود داده به صورت قابل اعتماد (تحمل خطای بالا) فراهم می‌کند و برای پردازش بلادرنگ استفاده می‌شود.ویژگی‌های کارکردیبه پردازش کلان داده‌ها کمک می‌کند. یک سیستم پردازش سریع و قابل اعتماد است.این ابزار می‌تواند داده‌های با حجم بالا و سرعت بالا را جذب کند.مکانیزم‌های توسط این ابزار ارائه می‌شود که می‌تواند برای تجزیه و تحلیل بلادرنگ، یادگیری ماشینی و پردازش جریان نامحدود استفاده شود. همچنین این ابزار می‌تواند پیام‌های تولید شده را به طور مداوم دریافت کند و به چندین سیستم خروجی دهد.معماریابزار هیچ‌گونه قابلیت مدیریت داخلی ندارد و برای مدیریت وضعیت خوشه‌ای خود، مواردی مانند تایید پیام، وضعیت‌های پردازش و سایر پیام‌ها، به ZooKeeper متکی است. همچنین دو مدل داده‌ی زیر در این ابزار استفاده می‌شوند:مدل tuple: یک لیست مرتب‌شده از مقادیر نامگذاری شده مشابه یک ردیف پایگاه‌داده است. هر فیلد در آن دارای یک نوع داده است که می تواند پویا باشد. فیلد می‌تواند از هر نوع داده‌ای مانند انواع متداول یا آرایه بایتی باشد. انواع داده‌های تعریف شده توسط کاربر نیز مجاز هستند.مدل stream: جریان یک توالی نامحدود از tupleها است.معماری این ابزار مبتنی بر master/slave می‌باشد. یک سرور اصلی به نام Nimbus وجود دارد که روی یک گره به نام Master Node اجرا می‌شود. سرویس‌های به نام سرپرست (Supervisor) وجود دارند که روی هر گره کارگر اجرا می‌شوند. سرپرستان یک یا چند فرآیند کارگری (worker process) شروع می‌کنند که به صورت موازی برای پردازش ورودی اجرا می‌شوند.معماری ابزار (منبع عکس)فرآیند Nimbus وظایف را به گره‌های کارگر اختصاص داده و توزیع می‌کند. همچنین در عین حال وظایف را نظارت می‌کند تا از اجرای درست آن‌ها مطمئن شود و وظایف مربوط به خرابی گره را مجدداً اختصاص می‌دهد. فرآیند سرپرست (Supervisor) روی هر گره کارگر از خوشه اجرا می‌شود. هر وظیفه را که از سمت گره اصلی به آن محول می‌شود، به عنوان یک فرآیند جداگانه به نام فرآیند کارگر (worker process) اجرا می‌کند. فرآیند کارگر همان کار و پردازش واقعی را انجام می‌دهد. اجراهای آن‌ها توسط بخش سرپرست شروع و نظارت می‌شود. تعداد فرآیندهای کارگر برای هر وظیفه یا کار ایجادشده توسط کاربر بر روی خوشه، قابل پیکربندی است.ابزار از دو مولفه‌ی اصلی به نام‌های Spout و Bolt تشکیل شده است. این دو نوع مولفه، جریان ورودی یا داخلی را پردازش می‌کنند. بخش دهانه‌ها (spout) داده‌های خارجی سیستم را برای تولید جریان‌های tuple پردازش می‌کنند و آن‌ها را به boltها می‌فرستند. این مولفه، داده‌ها را از سایر سیستم‌های صف مانند کافکا، توییتر و ... می‌تواند دریافت کند. پیاده‌سازی Spout برای تولیدکنندگان داده محبوب در دسترس است. یک Spout واحد می‌تواند چندین جریان خروجی تولید کند که در صورت نیاز هر خروجی توسط یک یا چندین بخش دیگر مصرف شوند. Boltها جریان tuple ارسال‌شده به خودشان را دریافت می‌کنند و پردازش می‌کنند. خروجی آن‌ها دوباره جریانی از tupleها خواهد بود که متناسب با کارکرد برنامه به مقصد مناسب ارسال می‌شود.منطق هر برنامه در قالب یک توپولوژی بسته‌بندی شده است که اساساً شبکه‌ای از Boltها و Spoutها است. توپولوژی برای همیشه اجرا می شود مگر اینکه کاربر سامانه به صراحت آن را متوقف کند. شبکه شامل گره‌هایی است که منطق پردازش را تشکیل می‌دهند و پیوندهایی که انتقال داده‌ها و اجرای فرآیندها را نشان می‌دهند. انواع توپولوژی‌های کاربردی به صورت پیشفرض توسط ابزار فراهم شده است.دسترس‌پذیریدسترس‌پذیری این ابزار با توجه به معماری آن به دسترس‌پذیری Zookeeper نیز وابسته می‌باشد. با این حال پیاده‌سازی آن به گونه‌ای است که بر روی گره‌های فراوانی (workers) استقرار می‌یابد و نحوه‌ی پیاده‌سازی آن تحمل از دست‌رفتن تعدادی گره را فراهم می‌کند. همچنین پیاده‌سازی گره‌ اصلی به صورت active/passive می‌باشد که دسترس‌پذیری بالایی را فراهم می‌کند.قابلیت اعتماد یا تحمل خطای این نرم‌افزار متناسب با نیاز کاربر می‌تواند تضمین کند که هر واحد داده حداقل یک بار یا دقیقا یک بار پردازش شود. پیام‌ها فقط زمانی دوباره پردازش می‌شوند که خرابی وجود داشته باشد. برای این منظور لازم است که پیاده‌سازی مربوط به spoutها و boltها در صورت رخداد خطا، در صورت نیاز کاربر فرایند پردازش را تکرار کنند. البته پیاده‌سازی این قابلیت به تنهایی از طریق Storm ممکن نیست. در مورد بخش‌های ورودی داده (spout) لازم است که منبع ورودی داده قابلیت دریافت بازخورد داشته باشد و بتواند در صورت نیاز داده را دوباره ارسال کند. (مثلا اگر UDP باشد Storm در آن صورت کاری نمی‌تواند انجام دهد) همچنین برای بخش‌های داخلی (Bolt) لازم است که پردازش‌های رخ‌داده در لایه‌ی ذخیره‌کننده‌ی میانی (مثل یک حافظه‌ی in-memory یا دیتابیس یا ...) ذخیره شوند تا در صورت خطا امکان ادامه‌ی فرآیند و از دست‌نرفتن داده‌ها وجود داشته باشد. اگر این امکان فراهم نشود، Storm دوباره کاری نخواهد کرد. به عبارتی این ابزار در صورت فراهم‌سازی شرایط امکان تحمل‌خطا و پردازش تمامی‌داده‌ها را دارد اما به تنهایی این امکان را به صورت داخلی فراهم نکرده است. (غیر از پیاده‌سازی یکسری امکانات برای اتصال به ابزارهای معروف مثل Kafka یا Hadoop)کاراییمتناسب با تنظیماتی که برای اجرای jobها مشخص می‌شود و منابعی که در اختیار آن گذاشته می‌شود می‌تواند کارایی خوبی در پردازش داده‌های درون خوشه داشته باشد.همچنین بسته به این که پیاده‌سازی مربوط به ورودی‌دهنده‌های داده (spout) به چه صورتی باشد، می‌تواند توانایی پردازش حجم زیادی داده با نرخ بالای ورودی را داشته باشد. به عبارتی کارایی آن در بخش ورودی متناسب با نوع ورودی داده است. (به عنوان مثال اگر از کافکا برای ورودی داده استفاده شود، کارایی برنامه وابسته به کافکا خواهد بود یا اگر از Hadoop به عنوان مبدا ورودی داده استفاده شود، کارایی وابسته به تنظیمات و توانایی خوشه Hadoop خواهد بود)زمان تاخیر مربوط به این ابزار با توجه به مسئله‌ی مدل‌شده می‌تواند متفاوت باشد و وابسته به نرخ ورودی یا محاسبات انجام‌شده باشد. به همین دلیل در مورد تاخیر با قطعیت نمی‌توان نظری داد.مقیاس‌پذیریمقیاس‌پذیری این ابزار در درجه‌ی اول وابسته به نحوه‌ی دریافت ورودی داده و خروجی داده و محل‌های میانی ذخیره‌ی داده می‌باشد. با فرض مقیاس‌پذیر بودن وابستگی‌های خارجی ابزار که در بالا ذکر شد، در آن صورت خود ابزار به راحتی با افزوده‌شدن گره‌های به کلاستر (به عنوان مثال برای افزایش توان پردازشی) به صورت افقی گسترش پیدا کند.تعامل‌پذیریتنظیمات استاندارد برای اجرای این ابزار در روز صفر مناسب هستند و تقریبا با کمترین هزینه می‌توان ابزار را اجرا نموده و به کار کردن و کسب تجربه پرداخت.استفاده از این ابزار و ارتباط با آن توسط زبان‌های برنامه‌نویسی متنوعی پشتیبانی می‌شود. همچنین این ابزار می‌تواند بر روی YARN هم سوار شود و کاملا با اکوسیستم Hadoop ادغام شود.محدودیت‌هایک جریان کامل از داده‌ها را به‌عنوان یک «رویداد» به‌جای رویکرد دسته‌ای دریافت می‌کند. به همین دلیل، برای داده‌هایی که قرار است به‌عنوان یک موجودیت واحد مصرف شوند، مناسب‌تر است.برای به روزرسانی توپولوژی در حال اجرا، تنها گزینه در حال حاضر حذف توپولوژی فعلی و ارسال مجدد توپولوژی جدید است. (این از نظر به دلیل پایین‌بودن موقتی برنامه خوب نیست)برای داشتن دسترسی بالا و کارایی خوب به ابزارهای خارجی وابسته است.در صورتی که نیاز به پردازش‌های کلان‌داده به صورت دسته‌ای دارید، این ابزار راه‌حلی ارائه نداده است. (تنها برای جریان داده‌های بلادرنگ مناسب می‌باشد)ابزار Apache Flinkکارکرد اصلی ابزار پردازش داده است. ابزار یک چارچوب متن‌باز و موتور پردازش توزیع‌شده برای محاسبات دارای حالت (stateful) بر روی جریان‌های داده نامحدود و محدود است.ویژگی‌های کارکردیپشتیبانی از پردازش جریانی (stream) و دسته‌ای (batch) به صورت همزمانپشتیبانی از ورودی‌های بلادرنگ و ذخیره‌شدهپشتیبانی از عملکرد درون حافظهدارای پردازش تکراری برای یادگیری ماشین و پشتیبانی از تجزیه و تحلیل گرافپشتیبانی از پردازش زمان رویداد (event-time processing)پشتیبانی از مکانیزم‌هایی برای مدیریت داده‌های دارای تاخیر مانند watermarking و ...پشتیبانی از ویژگی‌های جریانی پیشرفته مانند trigger، Sessions و ...معماریابزار برای اجرای برنامه‌های جریانی در هر مقیاسی طراحی شده است. برنامه‌ها به هزاران وظیفه موازی تقسیم می‌شوند که به طور همزمان در یک خوشه از گره‌ها توزیع و اجرا می‌شوند. مکانیزم تقسیم کار توسط ابزار مدیریت می‌شود اما مکانیزم اجرای آن توسط گره‌های خوشه می‌تواند توسط خود ابزار به صورت standalone یا توسط پیکربندی ابزارهای دیگر (مثل YARN و ...) مدیریت شود. علاوه بر این، ابزار به راحتی حالت (state) برنامه بسیار بزرگ را حفظ می‌کند. الگوریتم checkpoint که به صورت ناهمزمان (آسنکرون) و افزایشی اجرا می‌شود، حداقل تأثیر را بر تأخیرهای پردازش تضمین می‌کند و در عین حال ثبات حالت را دقیقاً یک بار (exactly-one consistency) تضمین می‌کند.معماری ابزار (منبع عکس)دسترس‌پذیریابزار می‌تواند به صورت HA استقرار پیدا کند و شامل نقطه‌ی شکست (Single Point of Failure) نمی‌باشد. البته در صورتی که برای مواردی مثل ذخیره‌سازی checkpointها یا زمان‌بندی اجرای کارها (Scheduling) از ابزار خارجی استفاده شود (پیکبرندی به گونه‌ای باشد که از قابلیت‌های این ابزارها استفاده شود) در آن صورت دسترس‌پذیری ابزار وابسته به دسترس‌پذیری آن ابزارها نیز خواهد بود.تحمل خطا ابزار برای مقاوم‌شدن نسبت به خرابی‌ها به صورت داخلی پیاده‌سازی شده است. برای این منظور ابزار هر از چند گاهی از طریق checkpoint وضعیت سامانه را ذخیره‌سازی و حفظ می‌کند. نقاط checkpoint به ابزار امکان بازیابی وضعیت و موقعیت‌های موجود در جریان‌ها را برای بازیابی (recovery) از وضعیت ناموفق می‌دهد.کاراییبرنامه‌های Stateful Flink برای دسترسی به حالت محلی بهینه شده‌اند. وضعیت کارها همیشه در حافظه حفظ می‌شود یا اگر اندازه حالت از حافظه موجود بیشتر باشد، در ساختارهای داده روی دیسک با دسترسی کارآمد حفظ می‌شود. به همین دلیل، کارها همه محاسبات را با دسترسی به حالت محلی، اغلب در حافظه، انجام می‌دهند که تأخیر پردازش بسیار پایینی را ایجاد می‌کند. ابزار با کنترل دوره‌ای و ناهمزمان تلاش می‌کند تا تاثیر کمی بر روی تاخیر و توان پردازشی ایجاد کند.به منظور رسیدن به کارایی‌های بیش‌تر می‌توان آن را با ابزارهای دیگر در موضوعات check-pointing و ورودی داده و زمان‌بندی کارها متصل کنید تا از کارایی بیش‌تری برخوردار شوید. (متناسب با امکانات فراهم‌شده توسط ابزارهای خارجی)مقیاس‌پذیریاین ابزار پشتیبانی خوبی برای پارتیشن‌بندی و مقیاس‌بندی دارد. در صورتی که از ابزارهای دیگر مانند Yarn یا Mesos و ... برای پیکربندی زیرساخت اجرای عملگرها استفاده شود، مقیاس‌پذیری و دسترس‌پذیری وابسته به آن ابزارهای خارجی خواهد بود اما اگر از روش خوشه مستقل (standalone) استفاده شود، امکان فراهم‌سازی مقیاس‌بندی خوبی را فراهم می‌کند.تعامل‌پذیریابزار را می‌توان بر روی ارائه‌دهندگان منابع مختلف مانند YARN، Apache Mesos و Kubernetes و همچنین به عنوان خوشه مستقل روی گره‌ها مستقر کرد. تعامل با آن برای پیاده‌سازی منطق‌های برنامه می‌تواند مبتنی بر زبان‌های برنامه‌نویسی Java/Scala صورت بگیرد.ابزار برای ذخیره‌سازی checkpointها با ابزارهای خارجی مختلفی می‌تواند تعامل داشته باشد. از نمونه این ابزارها می‌توان به ابزارهای مدیریت صف مانند کافکا، Google Pub/Sub، RabbitMQ یا فضای فایلی مانند هادوپ، GFS، S3، NFS، Ceph اشاره کرد که امکان پیکربندی‌شدن به عنوان محل ذخیره‌سازی را دارند.به منظور تعامل با این ابزار امکانات رابط کنسولی فراهم شده است. ابزار به منظور پایش وضعیت کارها قابلیت‌های زیر را فراهم نموده است:رابط کاربری وب: رابط کاربری وب برای بازرسی، نظارت و اشکال‌زدایی برنامه‌های در حال اجرالاگ: استفاده از ابزار محبوب slf4j و قابلیت ادغام با چارچوب‌های log4j یا logbackمتریک‌ها: دارای سیستم متریک کامل برای جمع‌آوری و پایش سیستممحدودیت‌هادر صورتی که نیاز دارید تا از روش‌های متنوع‌تری (به غیر از جاوا یا اسکالا) برای تعامل استفاده کنید، نیاز به ابزار متفاوتی دارید.اگر چه ابزار امکانات پردازش داده‌های غیر جریانی (مثل جریان‌داده‌های ذخیره‌شده) را فراهم می‌کند اما امکانات فراوانی برای این ابزار در زمینه‌ی داده‌های جریانی ارائه شده است و احتمالا ابزارهای اختصاصی در زمینه‌ی پردازش داده‌ی دسته‌ای (batch processing) بهتر عمل خواهند کرد.ابزار Apache Drillکارکرد اصلی ابزار، پردازش داده با زبان SQL می‌باشد. یک موتور جستجوی SQL منبع باز برای جستجو داده‌های بزرگ است. اجرای پرس‌وجو بر روی داده‌های نیمه ساختاریافته و برنامه‌های کاربردی کلان‌داده را پشتیبانی می‌کند، در حالی که هنوز اکوسیستم ANSI SQL، زبان پرس و جو استاندارد صنعت را فراهم می‌کند.ویژگی‌های کارکردی پشتیبانی از استاندرادهای SQLجستجو به صورت پویا بر روی داده‌های خودتوصیف کننده (مانند JSON، Parquet، ...) بدون نیاز به تعریف اطلاعات افزوده (metadata) برای توصیف ساختار داده پیش از انجام جستجوپشتیبانی از مدل داده‌های متنوع و انعطاف‌پذیرپشتیبانی از داده‌های تو در توامکان انجام پرس‌وجو بر روی چندین پایگاه‌داده‌ی مختلف به صورت همزمان و اتصال خروجی آن‌ها در قالب مکانیزم‌های Join زبان SQLمعماریابزار شامل یک محیط اجرای توزیع شده است که برای پردازش داده در مقیاس بزرگ ساخته شده است. در هسته این ابزار سرویس Drillbit قرار دارد که مسئولیت پذیرش درخواست‌های کاربر، پردازش پرس‌وجوها و برگرداندن نتایج به کاربر را بر عهده دارد. ابزار از ZooKeeper برای نگهداری وضعیت عضویت گره‌ها در کلاستر و اطلاعات سلامت سرویس‌ها استفاده می‌کند. البته ابزار توانایی اجرا در هر محیط خوشه‌ای توزیع‌شده را دارد و تنها پیش‌نیاز آن Zookeeper است.کاربر (client) یک پرس و جو را ارسال می‌کند. هر سرویس (Drillbit) در خوشه می‌تواند درخواست‌های کاربران را بپذیرد و مفهوم ارباب یا برده در معماری ابزار وجود ندارد. سپس سرویس پرس و جو را تجزیه می‌کند، آن را بهینه می‌کند و یک طرح پرس و جو توزیع شده ایجاد می‌کند که برای اجرای سریع و کارآمد بهینه شده است. سرویسی که پرس‌وجو را می‌پذیرد به گره محرک (driver) برای درخواست تبدیل می‌شود. این سرویس فهرست گره‌های دیگر را از زوکیپر دریافت می‌کند و گره‌های مناسب را برای اجرای قطعات طرح پرس‌وجوی مختلف برای به حداکثر رساندن محلی‌بودن داده‌ها تعیین می‌کند. سرویس‌ محرک اجرای قطعات پرس‌وجو را بر روی گره‌های جداگانه طبق برنامه اجرا زمان‌بندی می‌کند. گره‌های مجزا اجرای خود را به پایان می‌رسانند و داده‌ها را به سرویس محرک برمی‌گردانند. سرویس محرک جواب‌های بازگردانده‌شده را در قالب جریان داده به کاربر باز می‌گرداند.تصویر زیر نشان‌دهنده اجزای سرویس Drillbit است:معماری سرویس Drillbit (منبع عکس)اجزای مهم این سرویس موارد زیر هستند:بخش نقطه اتصال RPC: فراهم‌کننده‌ی نیازمندی‌های ارتباطی از سمت کاربران (پشتیبانی از پروتکل‌های متنوع ارتباطی)بخش تحلیل‌کننده‌ی SQL: تبدیل پرس‌وجوهای ورودی به خروجی مستقل از زبان (برای تحلیل‌های موردنزار در ادامه) از طریق ابزار منبع‌باز Calciteبخش بهینه‌ساز: استفاده از بهینه‌سازی‌های مختلف مانند قوانین مبتنی بر قواعد یا مبتنی بر هزینه، موقعیت مکانی داده‌ها، سایر قوانین بهینه‌سازی مربوط به ابزار فراهم‌کننده داده، ... برای بازنویسی و تقسیم پرس‌و‌جوماشین اجرایی: یک موتور اجرای توزیع‌شده برای انجام پردازش پرس و جو در گره‌های مختلف خوشهرابط‌های افزونه داده: یک لایه انتزاعی برای ارتباط با منبع‌داده‌های مختلف به منظور فراهم‌سازی فراداده موجود در منبع، رابط‌هایی برای خواندن و نوشتن در منابع داده، مکان داده‌ها و مجموعه‌ای از قوانین بهینه‌سازی برای کمک به اجرای کارآمد و سریعتر پرس و جوهادسترس‌پذیریبا توجه به نبود مکانیزم master/slave و امکان افزایش تعداد سرویس‌ها در خوشه، به راحتی امکان افزایش دسترس‌پذیری ابزار وجود دارد. همچنین در هنگام اجرای پرس و جوها، در صورت رخداد خطا در هر گره، اجرای آن را به گره‌های دیگر منتقل می‌کند که سبب نمی‌شود نسبت به رخداد خطا تحمل‌پذیر بوده و دسترس‌پذیری آن افزایش یابد. البته متناسب با نوع داده‌ای که برای کوئری انتخاب می‌شود (مثلا مخزن HDFS و ...)، تحمل خطای ابزار در برابر مشکلات وابسته به ابزار جانبی نیز خواهد بود.کارایی بهینه‌ساز درونی ابزار، اطلاعات ارائه‌شده توسط ابزار (مثلا metadataهای فایل پارکت یا جدول Hive و ...) به‌طور خودکار استفاده می‌کند تا طرح پرس‌وجو را بازسازی کرده و از قابلیت‌های پردازش داخلی پایگاه‌داده‌ی هدف استفاده کند.پشتیبانی از مکانیزم تشخیص داده‌های محلی به منظور کاهش پنهای باند شبکه و افزایش سرعتمدیریت تخصصی حافظه به منظور کاهش میزان مصرف حافظه و حذف جمع‌آوری زبالهبهینه‌ساز پیشرفته مبتنی بر هزینه که در صورت امکان، پردازش را تا حد امکان به لایه‌ی خواندن داده‌ی ذخیره‌شده نزدیک می‌کند.بردارسازی (Vectorization): به جای کار بر روی مقادیر یک رکورد جدول در زمان، بردارسازی به CPU اجازه می‌دهد تا بر روی بردارهایی که مجموعه‌ای از رکوردها هستند، کار کند. (با استفاده از تکنولوژی‌های جدید این نوع محسابات خیلی سریع‌تر هستند)کامپایل در زمان اجرا: کامپایل در زمان اجرا در مقایسه با اجرای تفسیرشده سریع‌تر بوده و کد سفارشی بسیار کارآمد را برای هر پرس و جو و هر اپراتور تولید می‌کند.مقیاس‌پذیریاین ابزار به راحتی با بالا آوردن یکسری سرویس (Drillbet) اجرا می‌شود و به راحتی توسط ابزار ZooKeeper مقیاس پیدا کرده و روی چندین گره بالا بیاید. ابزار برای شروع فرآیند اجرای پرس و جو نیازی به مشخصات طرح یا نوع برای داده‌ها ندارد. این ابزار ساختارداده‌ها را را در حین پردازش کشف می‌کند. برخلاف سایر فناوری‌های مانند پایگاه‌داده سنتی رابطه‌ای، ابزار نیازی به ابرداده (metadata) متمرکز ندارد. به منظور پرس و جو از داده‌ها، کاربران نیازی به ایجاد و مدیریت جداول/نماها در یک مخزن ندارند و به همین دلیل به راحتی می‌تواند بر روی هر نوع داده‌ای سوار شده و مقیاس آن به راحتی کاهش یا افزایش پیدا کند.تعامل‌پذیریکاربر (client) یک پرس و جو را از طریق روش‌های JDBC، ODBC، رابط خط فرمان یا REST API ارسال می‌کند. ابزار در کنار فایل محلی سیستم عامل از انواع داده‌های NoSQL از جمله موارد زیر پشتیبانی می‌کند:HBase، MongoDB، MapR-DB، HDFS، MapR-FS، Amazon S3، Azure Blob Storage، Google Cloud Storage، Swift، NAS, ...کاربران تجاری، تحلیلگران داده می‌توانند از ابزارهای استاندارد BI زیر برای تعامل با داده‌های غیرمرتبط استفاده کنند. توسعه‌دهندگان می‌توانند از REST API ساده ابزار در برنامه‌های سفارشی خود برای ایجاد داشبوردهای مفید استفاده کنند:Tableau، Qlik، MicroStrategy، Spotfire، SAS, Excel, ...ابزار یک معماری قابل توسعه را در همه لایه‌ها، از جمله لایه افزونه ذخیره‌سازی، لایه پرس و جو، بهینه‌سازی، اجرای پرس و جو و API های کاربر ارائه می‌دهد. هر لایه را برای نیازهای خاص می‌توان سفارشی کرد یا لایه را به مجموعه وسیع‌تری از ابزار گسترش داد.محدودیت‌هاعدم پشتیبانی از عملکرد تجميعي فراوانمحدودیت در توابع تعریف شده توسط کاربر (UDF)عدم پشتیبانی از پرس و جو سلسله مراتبیعدم پشتیبانی از پرس و جو فرعی (subquery) تک ردیفیمحدودیت‌هایی در عملیات join و group byابزار Apache Hiveکارکرد اصلی ابزار پردازش داده‌های روی سیستم منبع‌باز Hadoop می‌باشد. یک ابزار ذخیره‌سازی داده در اکوسیستم Hadoop است که زبانی شبیه SQL را برای پرس و جو و تجزیه و تحلیل کلان داده ارائه می‌کند. انگیزه اصلی ایجاد ابزار، مسیر یادگیری ساده‌تر برای توسعه دهندگان و تحلیلگران کلان‌داده می‌باشد.ویژگی‌های کارکردیتجزیه و تحلیل داده‌های ساخت‌یافته و نیمه‌ساختار یافته بر روی سیستم Hadoopکاهش پیچیدگی MapReduce با فراهم‌سازی امکانات پرس‌وجوهای به زبان Hive Query Language شبیه به دستورات SQLمعماریبا توجه به اجرای Hive بر روی خوشه Hadoop، معماری این ابزار پیچیدگی‌های کمی داشته و می‌توان آن را به صورت خلاصه در تصویر زیر مشاهده نمود:معماری ابزار Hive (منبع عکس)بخش کلایت: این ابزار از برنامه‌های نوشته شده در بسیاری از زبان‌ها با استفاده از پروتکل‌های مختلف به منظور ارتباط با سرور پشتیبانی می‌کند.خدمات Hive: خدمات مختلفی مانند رابط کاربری وب، کنسول و ... برای انجام پرس و جو ارائه شده است.چارچوب پردازش و مدیریت منابع و ذخیره‌سازی توزیع شده: در داخل ابزار از چارچوب Hadoop MapReduce به عنوان موتور واقعی برای اجرای پرس و جوها استفاده می‌شود. از آن‌جایی که ابزار بر روی هادوپ نصب می‌شود، از HDFS زیرساخت هادوپ برای ذخیره‌سازی توزیع شده استفاده می‌کند.درایور (driver) پرس و جو را به کامپایلر ارسال می‌کند که در آن تجزیه، بررسی نوع و تحلیل معنایی با کمک طرح‌های تعریف‌شده در metastore انجام می‌شود. در مرحله بعد، یک طرح منطقی بهینه شده در قالب DAG از MapReduceها تولید می‌شود. در نهایت موتور اجرایی این وظایف را به ترتیب وابستگی‌ها با استفاده از زیرساخت هادوپ اجرا می‌کند.بخش metastore به عنوان یک مخزن مرکزی برای ذخیره تمام اطلاعات فراداده موردنیاز ابزار استفاده می‌شود. این اطلاعات شامل ساختار جداول و پارتیشن‌ها به همراه ستون، نوع ستون، نوع تبدیل فرمت‌ها یعنی serializer و deserializer و ... می‌باشد. این بخش از دو واحد اساسی تشکیل شده است: سرویسی که دسترسی بخش را برای سایر سرویس‌های ابزار فراهم می‌کند و پایگاه‌داده‌ای مستقل از HDFS که برای نگهداری اطلاعات فراداده استفاده می‌شود.مدل داده‌ی استفاده شده در این ابزار اطلاعات داده‌ها را مبتنی بر 3 مفهوم زیر نگهداری می‌کند:جداول: این جداول مشابه جداول در پایگاه‌های داده رابطه‌ای هستند. جداول را می‌توان فیلتر، متصل و متحد (union) کرد. علاوه بر این، تمام داده‌های یک جدول در یک پوشه در HDFS ذخیره می‌شود.پارتیشن: هر جدول می‌تواند یک یا چند کلید پارتیشن داشته باشد که نحوه ذخیره داده‌ها را تعیین می‌کند. داده‌های مربوط به جدول برای هر ترکیب‌های مختلف پارتیشن‌ها، در پوشه‌های جداگانه HDFS ذخیره می‌شوند. (به همین دلیل برای رسیدن به پرارتیشن P1=V1و P2=V2 از جدول T کافی است پوشه‌ی T/P1=V1/P2=V2 خوانده شود)تقسیم‌بندی: داده‌های هر پارتیشن ممکن است بر اساس hash یک ستون جدول به قسمت‌هایی (buckets) تقسیم شوند. این روش به ابزار اجازه می‌دهد تا به طور موثرتر پرس و جوهایی را که به نمونه‌ای از داده‌ها بستگی دارد، ارزیابی کند.دسترس‌پذیریبا توجه به امکانات ابزار امکان بالاآوردن چندین نسخه از سرور (server) ابزار وجود داشته که امکانات دسترس‌پذیری را فراهم می‌کند. با توجه به وابستگی کامل ابزار به زیرساخت هادوپ، مواردی مثل تحمل‌پذیری، دسترس‌پذیری و ... ابزار کاملا مستقل نبوده و وابسته به نحوه‌ی استقرار HDFS هستند. از طریق استفاده از امکانات remote/local metastore قابلیت بالاآوردن چندین metastore را به صورت همزمان دارید که در نتیجه دسترس‌پذیری را افزایش می‌دهد. البته این metastore ها طبق توضیحات بالا از یک پایگاه‌داده جدا مستقل از HDFS استفاده می‌کنند. بدیهی است که دسترس‌پذیری ابزار به دسترس‌پذیری پایگاه‌داده‌ی استفاده‌شده نیز وابسته می‌باشد.کاراییذخیره اطلاعات فراداده ابزار در یک RDBMS به منظور کاهش زمان بررسی‌های معنایی (semantic) در طول اجرای پرس و جو از مهم‌ترین ویژگی‌های این ابزار می‌باشد. همچنین کامپایلر درونی این ابزار به گونه‌ای عمل می‌کند که پرس و جوهای ورودی را با توجه به اطلاعات فراداده به بهترین شکل (بهینه‌ترین حالت) به برنامه‌ی منطقی که درختی از MapReduce ها می‌باشد تبدیل کند. با این حال با توجه به وابستگی کامل ابزار به زیرساخت هادوپ، مواردی مثل کارایی اجرای پرس و جوها به قابلیت‌های فراهم‌شده توسط زیرساخت HDFS وابسته می‌باشد که در بخش‌های قبلی توضیح داده شده است.مقیاس‌پذیریاین ابزار با توجه به معماری ارائه‌داده قابلیت استقرار چندین سرور (Hive server) و همچنین چندین metastore را فراهم نموده است. با این حال افزایش تعداد این استقرارها سبب افزایش مقیاس‌پذیری اجرای پرس و جو نمی‌شوند و تنها دسترس‌پذیری را افزایش می‌دهند. این ابزار از زمان‌بندهای هادوپ و زیرساخت هدوپ استفاده می‌کند و به همین دلیل مقیاس‌پذیری آن منطبق بر مقیاس‌پذیری زیرساخت HDFS می‌باشد.تعامل‌پذیریابزار از هر برنامه کاربری نوشته شده در جاوا، PHP، Python، C یا Ruby پشتیبانی می‌کند و می‌تواند این برنامه‌ها را از طریق Thrift خود اجرا کند. همچنین ابزار رابط‌های کنسول (CLI) و رابط کاربری وب را نیز برای ارتباط فراهم نموده است.محدودیت‌هابا توجه به محدودیت زیرساخت Hadoop، ابزار از عملیات update و delete پشتیبانی نمی‌کند.این ابزار برای پردازش‌های لحظه‌ای (real-time) یا تراکنشی (OLTP) مناسب نمی‌باشد.پرس و جوهای فرعی (sub-query) پشتیبانی نمی‌شوند.زبان HQL از ویژگی پردازش تراکنشی (Transactional) پشتیبانی نمی‌کند.ابزار Apache Pigکارکرد اصلی ابزار پردازش داده می‌باشد. این ابزار یک پلتفرم برای تجزیه و تحلیل مجموعه داده‌های بزرگ است که از یک زبان سطح بالا برای بیان برنامه‌های تجزیه و تحلیل داده‌ها تشکیل شده است.ویژگی‌های کارکردیزبان Pig یک زبان سطح بالا (بر خلاف MapReduce به زبان جاوا) است.پشتیبانی از رویکرد چند پرس و جو به منظور کاهش حجم کد (یک پرس و جو می‌تواند به چندین MapReduce تبدیل شود)دارای مجموعه‌ای غنی از عملگرها مانند پیوستن، مرتب‌سازی، فیلتر کردن و ... برای خواندن، نوشتن و پردازش مجموعه داده‌های بزرگگسترش زبان با نوشتن توابع سفارشی در Pig (به هر زبانی مانند جاوا، پایتون، روبی، جیتون، جی روبی و ...)مدیریت انواع داده‌ها شامل داده‌های ساختاریافته، نیمه ساختاریافته یا بدون ساختارپشتیبانی از عملیات استخراج، تبدیل و بارگزاری (ETL)پشتیبانی از تعریف طرحواره (schema) برای داده‌هامعماریمعماری این ابزار با توجه به قرارگیری بر روی زیرساخت HDFS، ساده و به صورت زیر می‌باشد:معماری ابزار (منبع عکس)در ابتدا اسکریپت نوشته‌شده به زبان Pig به محیط اجرای Pig توسط محیط تعاملی (shell) یا سرور ارسال می‌شوند. Pig Script ها در ادامه به بخش پارسر منتقل می‌شوند. پارسر پس از بررسی نوع و نگارش اسکریپت، یک DAG (گراف غیر چرخه‌ای جهت دار) را خروجی می‌دهد. عملگرهای منطقی به صورت گره‌ها و جریان‌های داده به صورت یال‌ها نمایش داده می‌شوند. سپس DAG به بهینه‌ساز ارسال می‌شود. بهینه‌ساز فعالیت‌های بهینه‌سازی مانند عملگرهای تقسیم، ادغام، تبدیل و ترتیب مجدد و ... را انجام می‌دهد. پس از فرآیند بهینه‌سازی، کامپایلر کد بهینه شده را در قالب یکسری MapReduce کامپایل می‌کند. کامپایلر وظیفه تبدیل کارهای Pig را به طور خودکار به MapReduce بر عهده دارد. MapReduce برای اجرا به موتور اجرا ارسال می‌شوند و بعد از اجرا نتیجه لازم متناسب با نیاز کاربر ذخیره یا نمایش داده می‌شوند.دسترس‌پذیریتوضیحات مبنی بر امکان بالاآوردن برنامه به صورت HA در مستندات نرم‌افزار یافت نشد. متاسفانه امکان اجرای چندین نسخه (instance) از مولفه وجود دارد اما هر نسخه به صورت مستقل عمل می‌کند و اطلاعات داخلی یک نسخه در صورت رخداد مشکل در اختیار نسخه دیگر نیست. اگر چه با توجه به وابستگی کامل ابزار به زیرساخت هادوپ، مواردی مثل تحمل‌پذیری، دسترس‌پذیری و ... ابزار کاملا مستقل نبوده و وابسته به نحوه‌ی استقرار HDFS می‌باشد، اما اگر خود برنامه قابلیت HA نداشته باشد، امکان دارد در هنگام ارسال MapReduce ها به زیرساخت هادوپ دچار مشکل شود. (حتی اگر زیرساخت هادوپ کاملا در دسترس باشد) کاراییابزار به طور خودکار وظایف و پرس و جوهای تعریف‌شده را قبل از اجرا بهینه می‌کند. برای این منظور از تکنیک‌های مختلفی به صورت پیشفرض بهره می‌گیرد شامل موارد زیر (لیست کامل آن‌ها و توضیحاتشان را می‌توانید از این لینک مشاهده کنید)PushUpFilter, PushDownForEachFlatten, ColumnPruner, MapKeyPruner, LimitOptimizer, ...با توجه به وابستگی کامل ابزار به زیرساخت هادوپ، مواردی مثل کارایی اجرای پرس و جوها به قابلیت‌های فراهم‌شده توسط زیرساخت HDFS وابسته می‌باشد که در بخش‌های قبلی توضیح داده شده است.مقیاس‌پذیریاین ابزار از زمان‌بندهای هادوپ و زیرساخت هدوپ استفاده می‌کند و به همین دلیل مقیاس‌پذیری آن منطبق بر مقیاس‌پذیری زیرساخت HDFS می‌باشد. البته خود برنامه بار محساباتی کمی دارد با این حال امکان بالاآوردن چند نسخه از ابزار به صورت مستقل وجود دارد که می‌توان از این طریق برای کاهش بار روی یک نسخه اقدام کرد.تعامل‌پذیریابزار از زبان اسکریپت خاصی و مشخصی استفاده می‌کند. با این حال در صورتی که نیاز به این باشد که یکسری توابع شخصی برای توسعه قابلیت‌های ابزار نوشته شود، امکان نوشتن این کدهای توسعه‌دهنده در قالب زبان‌های مبتنی بر JVM مثل جاوا و اسکالا وجود دارد. همچنین ابزار تنها رابط‌های کنسول (CLI) را فراهم نموده است.محدودیت‌هابا توجه به محدودیت زیرساخت Hadoop، ابزار از عملیات update و delete پشتیبانی نمی‌کند.خطاهای ایجادشده در ابزار مخصوصا در موارد UDF بسیار ناقص هستند.پشتیبانی این ابزار در سایت‌های مثل stackoverflow و ... کم می‌باشد.برای زبان اسکریپت آن IDE مناسب وجود نداشته و باید به مستندات تکیه کرد.ابزار Apache Impalaکارکرد اصلی پردازش داده‌ می‌باشد. Impala یک موتور پرس و جوی SQL با پردازش موازی انبوه، منبع باز، کاملاً یکپارچه است که به طور خاص برای استفاده از انعطاف‌پذیری و مقیاس‌پذیری Hadoop طراحی شده است.ویژگی‌های کارکردیتاخیر کم و همزمانی بالا برای پرس و جوهای تحلیلی بر روی Hadoopرابط SQL آشنا که تحلیلگران داده با آن آشنا هستند.علاوه بر ویژگی‌های اولیه SQL (انتخاب، پیوستن، گروه‌بندی، ترتیب، محدود کردن)، از نماهای درون خطی، پرسش‌های فرعی (subquery) ناهمبسته و همبسته، همه انواع اتصالات بیرونی (outer-join) شامل چپ/راست نیمه یا ضد اتصال (anti-join) و توابع پنجره تحلیلی (window function) پشتیبانی می‌کند.معماریمعماری این ابزار به صورت خلاصه از سه سرویس اصلی تشکیل شده است. معماری سطح بالای ابزار را در عکس زیر مشاهده می‌کنید:معماری ابزار Impala (منبع عکس)سرویس Impala daemon (impalad) به صورت همزمان دو وظیفه پذیرش پرس‌و‌جوها از سمت کاربر (client) و هماهنگی اجرای آن‌ها در سراسر خوشه را بر عهده دارد. البته این سرویس در اجرای قطعات پرس و جو از طرف دیگر سرویس‌های impalad موجود در خوشه نیز مشارکت می‌کند. هنگامی که این سرویس با مدیریت اجرای پرس و جو کاربر در نقش اول عمل می‌کند، به عنوان هماهنگ‌کننده پرس و جو (Coordinator) عمل می‌کند. همه این سرویس‌ها متقارن هستند و هر کدام ممکن است در همه نقش‌ها (اجراکننده یا هماهنگ‌کننده) عمل کنند. این ویژگی به تحمل خطا و تعادل بار کمک می‌کند.یک سرویس impalad بر روی هر ماشینی در خوشه که datanode اجرا می‌کند، مستقر می‌شود. این به Impala اجازه می‌دهد تا از موقعیت داده‌ها استفاده کند و بلوک‌ها را از سیستم فایل بدون نیاز به استفاده از شبکه بخواند. دومین سرویس، سرویس نگهدارنده‌ی وضعیت (Statestore) می‌باشد که یک سرویس برای اشتراک فراداده (metadata) از طریق مکانیزم انتشار/اشتراک (publish-subscribe) می‌باشد. فراداده‌های خوشه در تمام سرویس‌های Impala توسط این قسمت منتشر می‌شود. درواقع همه گره‌ها باید مثلاً نسخه‌های به‌روز کاتالوگ سیستم و نمای اخیر عضویت خوشه (گره‌هایی که سالم بوده و توانایی مشارکت دارند) و ... داشته باشند تا درخواست‌ها به درستی زمان‌بندی شوند. طراحی ابزار برای جلوگیری از RPC های همزمان و چالش‌های آن، به گونه‌ای انجام شده است تا به‌روزرسانی‌ها برای همه طرف‌های علاقه‌مند ارسال شود. پیاده‌سازی این سرویس شبیه ترکیبی از Zookeeper و Kafka می‌باشد اما به صورت مستقل توسط ابزار توسعه و استقرار می‌یابد. سومین سرویس، سرویس کاتالوگ (Catalog) می‌باشد که به عنوان مخزن کاتالوگ عمل می‌کند. تغییرات اعمال‌شده در کاتالوگ از طریق سرویس نگهدارنده‌ی وضعیت پخش می‌شود. سرویس کاتالوگ اطلاعات را از ابزارهای دیگر (به عنوان مثال Hive Metastore یا HDFS Namenode) دریافت و آن اطلاعات را در یک ساختار کاتالوگ سازگار با Impala نگهداری می‌کند. این معماری به ابزار اجازه می‌دهد تا نسبت به ساختار ابزارهای دیگر بی‌اعتنا باشد و امکان اضافه‌کردن فراداده‌های ابزارهای دیگر (مثلاً HBase) وجود داشته باشد. از آن‌جایی که کاتالوگ‌ها اغلب بسیار بزرگ هستند، فراداده‌ها در پس‌زمینه به صورت lazy بارگزاری می‌شوند.در کنار موارد بالا ابزار از دو بخش اصلی frontend و backend تشکیل شده است. بخش frontend مبتنی بر زبان جاوا توسعه یافته است و بخش backend مبتنی بر زبان C++ توسعه یافته است. بخش forntend مسئول کامپایل متن SQL در طرح‌های پرس و جو برای اجرا توسط سرویس‌های ابزار است. کامپایل شامل تجزیه کننده SQL، بهینه‌ساز پرس و جو مبتنی بر هزینه و ... است که همگی از ابتدا پیاده‌سازی شده‌اند. (از ابزارهای دیگر استفاده نشده است) بخش backend قطعات پرس و جو را از frontend دریافت می‌کند و مسئول اجرای سریع آن‌ها است. (طراحی این بخش متناسب با امکانات سخت‌افزار مدرن می‌باشد) دسترس‌پذیریتمامی سرویس‌های impalad موجود در خوشه به دلیل قابلیت دریافت پرس و جو از سمت کاربر، شبیه هم بوده و به همین دلیل دسترس‌پذیری در زمینه ارسال پرس و جو به خوشه و اجرای آن کاملا بالا می‌باشد. بخش نگه‌دارنده‌ی وضعیت (statestore) هیچ ابرداده‌ای را روی دیسک نگه نمی‌دارد و همه ابرداده‌های فعلی توسط مشترکین زنده به آن منتقل می‌شوند. بنابراین، در صورت راه‌اندازی مجدد این سرویس (به علت مشکل یا بعد از اعمال یک تغییر)، وضعیت آن در مرحله اولیه ثبت‌نام توسط مشترکان (سرویس‌های impalad) بازیابی می‌شود. اگر دستگاهی که سرویس روی آن کار می‌کند از کار بیفتد، سرویس جایگزین می‌تواند در جای دیگری راه‌اندازی شود و مشترکان از این به بعد از آن استفاده کنند. ابزار به صورت خودکار مکانیزمی برای انتقال درخواست‌ها به سمت سرویس جدید ندارد و معمولا از ابزارها و روش‌های دیگر مثل تنظیمات DNS استفاده می‌کنند تا مشترکان را به طور خودکار به سرویس جدید متصل شوند.بدیهی است که به دلیل قرارگیری این سرویس بر روی سرویس‌های HDFS یا HBase و ...، دسترس‌پذیری این سرویس وابسته به سرویس‌های نامبرده نیز می‌باشد.کاراییابزار به جای استفاده از RPCهای همزمان که دارای کندی‌ها و چالش‌ها هستند، از رویکرد انتشار/ اشتراک استفاده نموده است. این رویکرد البته شاید چالش‌های دیگری داشته باشد اما تا حد خوبی توسط ابزار رفع شده‌اند.در زمینه‌ی سرویس کاتالوگ، از آنجایی که اطلاعات فراداده دیگر ابزارها اغلب بسیار بزرگ هستند و دسترسی به جداول به ندرت یکنواخت است، سرویس کاتالوگ فقط برای هر جدولی که در راه‌اندازی پیدا می‌کند یک اسکلت کلی ایجاد می‌کند. فراداده‌های جدول به صورت دقیق‌تر در پس‌زمینه بارگیری می‌شود. اگر جدول قبل از بارگیری کامل موردنیاز باشد، ابزار به صورت خودکار این را تشخیص داده و یک درخواست با اولویت را به سرویس کاتالوگ صادر می‌کند. این درخواست تا زمانی که جدول به طور کامل بارگیری شود سرویس را مسدود می‌کند.در زمینه‌ی اجرای کوئری، مکانیزم‌هایی برای تحلیل و بهینه‌سازی پرس و جو بیش از اجرا استفاده می‌کند. ابزار از زبان C++ برای بخش اجرای پرس و جو استفاده می‌کند و از تولید کد در زمان اجرا برای تولید مسیرهای کد کارآمد (با توجه به تعداد دستورالعمل‌ها) و سربار حافظه کوچک، به ویژه در مقایسه با سایر موتورهای پیاده‌سازی شده در جاوا استفاده می‌کند. مقیاس‌پذیریتمامی سرویس‌های impalad موجود در خوشه، مشابه با یکدیگر بوده و هر کدام می‌توانند به عنوان مدیریت‌کننده‌ی پرس و جو یا اجراکننده عمل کنند. به همین دلیل به راحتی می‌توان با بالابردن تعداد سرویس‌ها، مقیاس ابزار را برای پردازش و اجرای کوئری‌ها افزایش داد. در پیاده‌سازی ارائه‌شده توسط ابزار، تنها یک سرویس statestore در نظر گرفته‌شده است و طبق ادعای ابزار برای کلاسترهایی با اندازه‌های کوچک تا میانه نیز کافی است. با این حال امکان بالا آوردن چند عدد از این سرویس برای تقسیم بار و مقیاس‌پذیری ممکن است.تعامل‌پذیرییک موتور کاملاً جدید است که از ابتدا به زبان C++ و جاوا نوشته شده است و با استفاده از مولفه‌های استاندارد از جمله HDFS، HBase، YARN و ... انعطاف‌پذیری Hadoop را حفظ می‌کند و می‌تواند اکثر فرمت‌های فایل پرکاربرد مانند Sequence File، Parquet، Avro، RCFile و ... را بخواند.از بیش‌ترین استاندارها و دستورات موجود در حوزه‌ی SQL پشتیبانی می‌کند. منطق‌های سفارشی موردنیاز برنامه را می‌توان از طریق توابع ساده یا تجمعی تعریف‌شده توسط کاربر (UDF) به زبان‌های جاوا و C++ اضافه نمود. تعامل با این ابزار برای اجرای پرس و جو از طریق رابط تعاملی (shell)، ارتباطات ODBC یا JDBC یا Hue قابل انجام است.محدودیت‌هابا توجه به محدودیت زیرساخت Hadoop، ابزار از عملیات update و delete پشتیبانی نمی‌کند.اگر چه می‌تواند برای عملیات پردازش دسته‌ای استفاده شود اما برای پردازش ad-hoc مناسب‌تر است.هیچ پشتیبانی از Serialization و Deserialization در Impala وجود ندارد.وقتی رکوردها/فایل‌های جدیدی به فهرست داده‌ها در HDFS اضافه می‌شود (به صورت مستقیم و از نه طریق ابزار)، باید دستور بروزرسانی جدول بر روی ابزار اجرا شود.امکان خواندن فایل‌های باینری سفارشی (نه فرمت‌های معروف مثل پارکت و ...) در ابزار وجود ندارد.ابزار Apache Flumeکارکرد اصلی واردنمودن یا خارج‌سازی داده می‌باشد. یک ابزار استاندارد، ساده، قوی، انعطاف‌پذیر و قابل توسعه برای دریافت داده‌ها از تولیدکنندگان مختلف داده (مانند فایل‌های گزارش، رویدادها، ...) و واردسازی آن‌ها به یک مخزن داده متمرکز (معمولا Hadoop یا HBase) یا بلعلکس است.ویژگی‌های کارکردیپشتیبانی از مجموعه بزرگی از انواع منابع و مقصد (شامل Hadoop و HBase)فراهم‌سازی یک جریان داده ثابت بین داده‌های ورودی و خروجی در صورت وجود تفاوت در نرخ ورودی و نوشته‌شدن در مخزن‌های متمرکزپشتیبانی از جریان‌های multi-hop، جریان‌های fan-in fan-out، مسیریابی زمینه‌ای و ...تضمین تحویل مطمئن پیام بین فرستنده و دریافت‌کنندهمعماریمعماری ابزار در عین سادگی مزیت‌های فراوانی را به همراه آورده است. معماری این ابزار از یکسری عامل (Agent) تشکیل شده است. هر عامل از تعدادی ورودی داده (Source) دریافت می‌کند، داده‌ها را به یک یا چند کانال (Channel) ارسال می‌کند و تعدادی ارسال‌کننده (Sink) دارد که هر کدام بسته به نیاز به یک یا چند کانال وصل هستند و داده‌های کانال را دریافت کرده و به مقصد بعدی (مخزن داده یا یک عامل دیگر به عنوان گره بعدی) ارسال می‌کنند. رخدادها که در ورودی‌ها دریافت می‌شوند، به عنوان واحدی از جریان داده تعریف می‌شود که دارای بدنه بایتی (payload) و مجموعه‌ای اختیاری از ویژگی‌ها (headers) هستند. یک عامل یک فرآیند سیستمی مبتنی بر جاوا است که در ورودی خود رویدادها را دریافت و آن‌ها را به مقصد بعدی (hop) ارسال می‌کند.ساختار یک عامل در معماری ابزار (منبع عکس)با توجه به این معماری و امکان سواردکردن عامل‌ها به صوت زنجیره‌ای پشت سر هم، امکان ایجاد جریان داده‌های متنوع از جمله موارد زیر وجود دارد:جریان چند عامله (multi-hop): یک رویداد قبل از رسیدن به مقصد نهایی، ممکن است از طریق بیش از یک عامل سفر کند.جریان Fan-out: جریان داده از یک منبع به چندین کانال به عنوان جریان خروجی ارسال می‌شود. در این حالت ممکن است رویداد ورودی به همه‌ی خروجی‌ها برود یا صرفا به برخی از ورودی‌ها برود.جریان Fain-in: رویدادها از چندین منبع به یک کانال منتقل می‌شود.انتقال بین فرستنده و دریافت‌کننده در تمامی قسمت‌های جریان داده به صورت تراکنشی و ثبتی رخ می‌دهد و تا زمان عدم اطمینان از ارسال یک رویداد، فرآیند تکرار می‌شود. معماری به منظور افزایش کارایی و فراهم‌سازی کابردهای مختلف، مفاهیم دیگری را از جمله موارد زیر فراهم نموده است:گروه‌بندی بخشی از خروجی‌ها (Sink): فراهم‌سازی امکانات تقسیم بار و Failoverتعریف رهگیرها (interceptors): تغییر/بازرسی رویدادهادسترس‌پذیریابزار به منظور مقاوم‌بودن نسبت به مشکلات احتمالی در عامل‌ها، مکانیزمی به نام پردازنده‌های خروجی (Sink Processors) فراهم نموده است. از طریق این مفهوم می‌توان خروجی‌ها را گروه‌بندی نمود. گروه‌های خروجی به کاربران این امکان را می‌دهند که چندین خروجی را در یک موجودیت گروه‌بندی کنند. گروهبندی خروجی‌ها را می‌توان به منظور ارائه قابلیت‌های متعادل‌کننده بار (load balancing) در تمام خروجی‌های داخل گروه یا برای دستیابی به مقاوم‌کردن یک خروجی نسبت به خرابی موقت استفاده کرد. همچنین در قسمت ورودی مربوط به عامل‌ها، می‌تواند با اجرا کردن چندین عامل به منظور دریافت ورودی (جریان داده Fan-in) ورودی داده را نیز نسبت به خطاها مقاوم نمود. البته دسترس‌پذیری کامل ابزار وابسته به نحوه‌ی دریافت ورودی، نوع کانال‌های استفاده شده و نحوه‌ی ارسال خروجی می‌باشد. به عنوان مثال در صورتی که فرستنده از روش UDP برای ارسال ورودی استفاده کند، در صورت رخداد هر مشکل و عدم دریافت بسته و همچنین عدم ارسال دوباره از سمت فرستنده، بسته گم خواهد شد. یا در حالت استفاده از کانال in-memory در صورت رخداد خطا در عامل، اطلاعات درون حافظه از بین خواهد رفت. به همین دلیل دستیابی به دسترس‌پذیری کامل امکان‌پذیر است به شرطی که تنظیمات کانال و نحوه‌ی دریافت و ارسال به مخزن خروجی با نوع‌های مناسبی تنظیم شوند.کاراییبرخلاف استفاده از روش‌های ساده مانند put کردن در مخزن داده‌ی HDFS، ساخت فایل‌های Avro و ... که هر کدام تنظیمات فراوانی و موازی‌سازی برای رسیدن به کارایی خوب لازم دارند، با استفاده از معماری ابزار و اجرا کردن چند عامل یا استفاده از قابلیت‌های دسته‌بندی (batch) ابزار می‌توان به کارایی خوبی در نوشتن داده‌ها در خروجی دست یافت. همچنین بسته به نوع کانال‌های میانی می‌توان از مزیت‌های کارایی ابزارهای میانی نیز استفاده نمود. (به عنوان مثال کانال از نوع کافکا مزایا و کارایی‌های کافکا را نیز فراهم می‌کند)مقیاس‌پذیریمعماری ابزار به گونه‌ای است که به راحتی می‌توان به صورت افقی (horizontal) مقیاس برنامه را افزایش داد. افزایش یا کاهش مقیاس‌پذیری به راحتی و از طریق افزودن یا حذف یکسری عامل‌ها انجام می‌شود.تعامل‌پذیریتنظیم و مدیریت وضعیت و ساختار جمع‌کننده‌ها و فرستنده‌ها به راحتی و از طریق یکسری فایل کانفیگ صورت می‌گیرد که استفاده از ابزار را ساده و لذت بخش می‌کند. ابزار به صورت پیشفرض از لیست فراوانی از ورودی‌ها و خروجی‌ها پشتیبانی می‌کند که لیست کامل آن‌ها را از این لینک می‌توانید مشاهده کنید. به عنوان نمونه:Sources: Avro, Thrift, JMS, Kafka, NetCat, Sequence Generator, Syslog, HTTP Source, ...Channels: Memory, JDBC, Kafka, File, ...Sinks: HDFS, Hive, Avro, Thrift, File Roll, HBase, Elastic Search, Kafka, ...محدودیت‌هاضمانت‌های ضعیف‌تری نسبت به سیستم‌های دیگر در ترتیب ارسال داده‌ها (رویدادها حداقل یک بار تحویل داده می‌شوند، اما ترتیب دریافت داده‌ها در سمت دریافت‌کننده می‌تواند کاملا متفاوت از ترتیب ارسال باشد)امکان ارسال داده تکراری در سامانهابزار Apache Oozieکارکرد اصلی زمان‌بندی اجرای جریان کارها می‌باشد. در موارد بلادرنگ، یک کار به کارهای دیگر وابسته است، مانند خروجی یک کار MapReduce ممکن است برای پردازش بیشتر به Hive job منتقل شود. همچنین برنامه‌ریزی مجموعه‌ای از کارها می‌تواند بر اساس زمان مانند روزانه، هفتگی، ماهانه یا بر اساس در دسترس بودن داده باشد. ابزار این امکان را در اختیار شما قرار می‌دهد تا به راحتی این نوع سناریوها را مدیریت کنید.ویژگی‌های کارکردیمدیریت و اجرای کارهای Hadoop در یک محیط توزیع شدهاجرای ترکیب انواع مختلف وظایف مانند Spark، Hive، Pig، Sqoop یا MapReduce و ...امکان استفاده از قابلیت‌های Fork/Join برای اجرای موازی کارهایقابلیت زمان‌بندی اجرای کارهای بر اساس زمان، داده و شرایط رخدادپشتیبانی از انتظام‌های مختلف اجرا مانند FIFO، LIFO و ...معماریمدل‌های موجود در ابزار در قالب سه مفهوم قرار می‌گیرند:کارهای گردش کار (Workflow Jobs): نمودارهای غیر چرخشی جهت‌دار (DAG) که دنباله‌ای از کارها را برای اجرا توسط ابزار مشخص می‌کنند.کارهای هماهنگ‌کننده (Coordinator Jobs): شامل کارهای گردش کار (Workflow) است که متناسب با تنظیم صورت‌گرفته، بر اساس زمان، در دسترس بودن داده و دیگر شرایط راه‌اندازی (trigger) می‌شوند.دسته (Bundle): مجموعه‌ای از چندین هماهنگ‌کننده (Coordinator) و کارهای گردش کار (Workflow)مدل‌هایموجود در ابزار (منبع عکس)معماری ابزار به سادگی تصویر زیر می‌باشد (در تصویر نحوه‌ی در دسترس بودن بالا نیز نمایش داده شده است):نمای در دسترس بالای ابزار در هنگام استقرار (منبع عکس)یک سرور Oozie به عنوان برنامه وب جاوا که در سرور Tomcat میزبانی می‌شود مستقر می‌شود و تمام اطلاعات مرحله‌ای مانند تعاریف گردش کار، کارها و ... در یک پایگاه داده ذخیره می‌شوند. بخش کاربر (کلاینت) Oozie در واقعی کاربری است که به منظور تعریف گردش کار، اجرای یک کار، تنظیم و ... به سرور متصل می‌شود.دسترس‌پذیریدسترس‌پذیری بالا در ابزار از طریق بالاآوردن چندین نسخه از برنامه به صورت همزمان انجام می‌شود. تمامی این نسخه‌ها برای مشاهده‌ی یک وضعیت یکسان و ارتباط با یکدیگر، به یک پایگاه‌داده‌ی یکسان متصل می‌شوند. (بدیهی است که برای رسیدن به حداکثر دسترسی و حذف نقطه‌ی شکست، لازم است پایگاه داده نیز به صورت دسترس‌پذیر تنظیم و اجرا شود)همچنین خود ابزار هیچ وضعیتی را در زمان اجرا در مموری نگه نمی‌دارد و اجرای تمای کارهای تعریف‌شده توسط کلاسترها‌ی دیگر (مانند Hadoop، Hive، Spark و ...) انجام می‌شود. به همین دلیل در عمل دسترس‌پذیری کامل این ابزار وابسته به تنظیم درست وابسته‌های زیرساختی ابزار می‌باشد. کاراییبا توجه به شیوه‌ی طراحی ابزار، میزان منابع مصرفی سرور بسیار کم می‌باشد و به همین دلیل به راحتی با حداقل منابع، بهترین عملکرد را خواهد داشت. البته بدیهی است که کارایی این ابزار وابسته به پایگاه‌داده‌ی استفاده‌شده، نوع کارها و تنظیمات مربوط به خوشه‌های اجراکننده‌ی کارها می‌باشد که در بخش‌های قبلی توضیح داده شده‌اند. مقیاس‌پذیریابزار به راحتی در مقیاس افقی (horizontal) قابل توسعه است. اجرای کار خاص در فرآیند سرور ابزار نیست. سرور تنها مسئول اجرای گردش کار است، در حالی که اقدامات در گردش کار، مانند MapReduce یا جاوا، توسط خوشه‌ای دیگر اجرا می‌شوند. سرور تنها مسئول استعلام وضعیت اجرا و نتایج این اقدامات است، بنابراین بار سرور کم می‌باشد. با این حال اگر تعداد گردش کار ارسالی توسط کاربران افزایش یافت، به سادگی می‌توان تعداد سرورهای Oozie را اضافه کرد. وضعیت کار در پایگاه داده رابطه‌ای حفظ می‌شود. از آن‌جایی که وضعیت کار به جای حافظه یک ماشین، در پایگاه داده ذخیره می‌شود، بسیار مقیاس‌پذیر است.تعامل‌پذیریپایگاه داده مربوط به ذخیره‌سازی وضعیت ابزار می‌تواند انوع مختلفی از پایگاه‌داده‌ها از جمله موارد زیر باشد:Apache Derby، HSQL، Oracle، MySQL, PostgreSQL, ...همچنین بخش کلاینت به منظور اتصال به سرور می‌تواند از مکانیزم‌های مختلفی مانند HTTP و رابط کاربری وب، REST API، رابط تعاملی (CLI) و ... استفاده کند.محدودیت‌هاابزارهای دیگری نیز امکانات تعریف گردش کار و زمان‌بندی را ارائه می‌دهند در حالی که امکان استقرار آن‌ها به شکل بهتری در محیط‌های جدید همچون کوبرنتیز و ... موجود است. امکانات پیشرفته برای استفاده‌ی منصفانه از منابع در هنگام زمان‌بندی ارائه نشده است.وابستگی فراوان به پایگاه‌داده در شرایط بار زیاد می‌تواند بسته به تنظیمات پایگاه داده منجر به کندی شود.جمع‌بندیابزارهای فراونی در این زمینه موجود هستند و تنها بخشی از آن‌ها بررسی و تحلیل شدند. اطلاعات دقیق فنی این ابزارها، تعاملات آن‌ها، ویژگی‌های آن‌ها و ... همه در بخش‌های قبلی قابل مشاهده است. برای هر ابزار می‌توانید با مطالعه همان ابزار به اطلاعات خلاصه‌ای در مورد جنبه‌های مختلف معماری آن برسید. با این حال اگر نیاز داشته باشید که یک یا چند ابزار را از نظر «تعامل‌پذیری» مقایسه کنید، می‌توانید توضیحات مربوط به این بخش را برای هر کدوم از دو ابزار مطالعه کنید و مقایسه کنید. به همین دلیل با توجه به این که امکان مشاهده‌ی کامل تمامی اطلاعات ابزار یا مقایسه یکسری ویژگی‌های ابزارهای مختلف با یکدیگر وجود دارد، در ادامه تلاش است که بر اساس چند رویکرد خاص و توضیحات قبلی، دسته‌بندی‌هایی را ایجاد کنیم.مهم‌ترین و شاید متمایزترین ویژگی بین ابزارهای بررسی‌شده، کارکرد ابزار می‌باشد. ابزارها هر کدام یک کارکرد اصلی داشته و در عین حال از چندین کارکرد دیگر نیز پشتیبانی می‌کردند. به همین دلیل در جدول زیر دسته‌بندی مربوط صورت‌گرفته برای کارکردهای مختلف را مشاهده می‌کنید. در این جدول نام یک ابزار می‌تواند در چندین سطر مشاهده شود که نشان‌دهنده‌ی پشتیبانی ابزار از کارکردهای مختلف می‌باشد. همچنین بخشی از ابزارها به دلیل حجم بالای مقاله مورد بررسی دقیق قرار نگرفتند اما بر اساس یه جستجوی ساده، دسته‌بندی آن‌ها مشخص شده و با رنگ قرمز مشخص شده‌اند. (البته دقت این روش کم بوده و ممکن است ابزار کارکردهای دیگری هم داشته باشد که در نظر گرفته نشده باشد)مقایسه کارکرهای مختلف ابزارهای بررسی‌شدهاین ابزارها در زمان‌های مختلفی ایجاد شده و ممکن است این پنداشت وجود داشته باشد که ابزارهای جدید نسبت به ابزارهای قدیمی رویکرد بهتری داشته باشند. با این حال خوب است که بدانیم محبوبیت این ابزارها طبق بررسی صورت‌گرفته به صورت زیر می‌باشد (معیار بررسی میزان محبوبیت مخزن توسعه می‌باشد):محبوبیت ابزارهای مختلفهمان‌طور که مشاهده می‌شود ابزارهای Apache HDFS & YARN، Apache Spark و Apache Flink جزو مواردی هستند که محبوبیت بسیار زیادی دارند. این در حالی است که این موارد معمولا بهترین عملکرد خود را در کنار ابزارهای دیگر دارند و همراه با آن استفاده می‌شوند. تقریبا این ابزارها با توجه به community فعالی که دارند در حال توسعه و پیشرفت بوده و روز به روز بر محبوبیت آن‌ها افزوده می‌شود.نکته‌ی جالب دیگر در این مورد ابزارها بررسی زمان انتشار اولین نسخه‌ی رسمی آن‌ها می‌باشد. نمودار زمانی می‌تواند نکات جالب دیگری را در مورد این ابزارها نسبت به نمودارهای قبلی نشان دهد.نمودار زمانی انتشار ابزارها مختلف بررسی‌شده در مقالههمان‌طور که در این نمودار مشاهده می‌شود، ابزار Apache HDFS & YARN که جزو محبوب‌ترین ابزارها نیز بود، خوب جزو پیشگامان و اولین‌ها در حوزه‌ی پردازش داده می‌باشد. این در حالی است که ابزار Apache Spark که محبوبیت فراوانی داشت در سال 2014 (تقریبا 8 سال بعد) منتشر شده است. همچنین ابزار معروف دیگر یعنی Apache Flink نیز در سال 2011 (تقریبا 5 سال بعد) منتشر شده است. در کنار هم قرار دادن نمودار زمانی انتشار ابزارها و نمودار محبوبیت آن‌ها نشان می‌دهد که هر ابزاری مورد قبول جامعه قرار نمی‌گیرد و اگر چه امروزه تکنولوژی پیشرفت‌های فراوانی کرده است، اما ابزارهای قدیمی خود را به خوبی با تکنولوژی‌های جدید همگام کرده‌اند و به همین دلیل حس نیاز به ابزاری جدید برای سازگاری با معماری‌های جدید خیلی کم دیده شده است. (با توجه به نبود ابزارهای خیلی قوی جدید که در چند سال اخیر منتشر شده باشد)در کنار موارد بالا خوب است که با توجه بررسی‌هایی که در بخش‌های قبلی انجام شده است، گراف وابستگی/تعامل این ابزارها با یکدیگر را نیز بررسی کنیم.گراف وابستگی یا تعاملات ابزارهای مختلف بررسی‌شدهدر این گراف که در تصویر بالا مشاهده می‌کنید، هر کدام از ابزارهای بررسی‌شده به صورت یک گره هستند و ارتباط میان گره‌ها، وابستگی/تعامل ابزارهای را نشان می‌دهد. گراف به صورت جهت‌دار بوده و به همین دلیل وجود یال جهتداری از A به B نشان‌دهنده‌ی وابسته‌بودن/تعامل‌داشتن یک طرفه از سمت A به B می‌باشد. گره‌ها دارای دو حالت می‌باشند.گره‌های دارای پیکان توپور نشان‌دهنده‌ی وابستگی بین دو ابزار می‌باشند. به عبارتی ابزار برای عملکرد خود نیازمند ابزار دیگر بوده و بدون آن قابل استفاده نیست.پیکان‌های توخالی نشان‌دهنده‌ی تعامل بین دو ابزار هستند. به عبارتی ابزارها قابلیت اتصال و استفاده‌شدن در کنار هم را دارند. یک ابزار می‌تواند از قابلیت‌های ابزار دیگر استفاده کند اما این به معنای این نیست که حتما باید ابزار مربوطه استفاده شود.این گراف نیز به ما نشان می‌دهد میزان استفاده‌شده/تعامل‌پذیری ابزار Apache HDFS & YARN بسیار زیاد می‌باشد که حاکی از قدرت این ابزار می‌باشد. همچنین برخی ابزارهای مثل Hive اگر چه امروزه محبوبیت کمی دارند اما تعامل‌پذیری بالایی دارند که امکان مهاجرت را برای سازمان‌ها ساده می‌کنند. (مثلا سازمان از ابزار محبوب‌تری استفاده کند اما در عین حال مشابه قبل از آن استفاده کند) البته شما می‌توانید با قراردادن این نمودار در کنار دیگر نمودارها و تحلیل‌های آن‌ها به نکات جالبی دیگری نیز برسید!با این حال همان‌طور که مشاهده می‌کنید با توجه به معیارهای مختلف بیان‌شده در بخش‌های قبلی و اطلاعات ارائه‌شده در این بخش، ابزاری همه‌کاره به منظور رفع همه‌ی نیازمندی‌ها وجود دارد. هر کدام از ابزارها برای کارکردهایی خاص با ویژگی‌های خاص ارائه شده و بدون محدودیت نیستند. همچنین روز به روز تکنولوژی در حال پیشرفت می‌باشد و شرکت‌های بیش‌تری در این حوزه ابزارهای خود را متن‌باز کرده تا توسعه آن‌ها سرعت بیابد. به همین دلیل با توجه به این که نیاز شما در چه زمینه می‌باشد و به دنبال چه نوع کارهایی هستید، انتخاب شما متفاوت خواهد بود. در این مقاله تلاش شده است تا به صورت خلاصه و از نگاه‌های مختلف ابزارها بررسی شوند تا در زمان کوتاهی دید خوبی به شما بدهند. امیدوارم که توانسته باشید تصمیم خود را گرفته باشید!این مطلب، بخشی از تمرین‌های درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است.منابعHadoop EcosystemApache Hadoop HDFS architectureHow to set up Hadoop cluster with HDFS high availabilityHadoop YARN tutorialDifferent types of failures in HadoopHBase tutorialHBase tutorialHBase architectureHBase pros and consSpark tutorialSpark architectureSpark architecture in depthApache Spark limitationsWatermarking in Spark structured streamingApache Storm the Hadoop of real timeApache Storm architectureEverything you need to know about Apache StormBig data tutorial Apache StormIntroduction to Apache FlinkExactly once is not exactly the sameApache Flink use casesApache Flink architectureApache Flink applicationsApache Flink operationsApache Flink blogApache DrillApache Drill architectureApache Drill introductionApache Drill in 10 minutesApache Hive tutorialApache Hive designApache Hive features and limitationsApache Pig tutorialApache PigApache Pig architecture in HadoopApache Pig advantages and disadvantagesApache Impala overviewApache Impala articleApache Impala introductionPros and cons of Apache ImpalaApache Flume ConfigurationApache Flume ChannelsApache Flume data flowApache Flume architectureTutorials point Apache Flume architectureApache Flume features limitationsIntroduction to Oozie architecture and operation modelApache Oozie tutorialOozie architecture and job scheduling امین برجیان امین برجیان Thu, 10 Feb 2022 10:34:07 +0330 https://virgool.io/@borjianamin98/%D8%A7%D8%AD%D8%B1%D8%A7%D8%B2-%D9%87%D9%88%DB%8C%D8%AA-%DB%8C%DA%A9%D9%BE%D8%A7%D8%B1%DA%86%D9%87-cll5rmqz0uoh احراز هویت یکپارچه (Single Sign On)راهکارهای احراز هویت یکپارچه (Single Sign-on یا SSO) در سال‌های اخیر از اهمیت زیادی برخوردار گشته‌اند. در سال‌های اخیر استفاده از نرم‌افزارهای مبتنی بر وب بسیار افزایش یافته است و به همین دلیل در بین کاربران روشی کارا برای احراز هویت بین سامانه‌های مختلف اهمیت فراوانی پیدا کرده است. امروزه با ایجاد محیط‌های کاری دورکاری و ترکیبی، پذیرش و استفاده حتی سریع‌تر برنامه‌های مبتنی بر وب را ایجاد کرده است و پذیرش احراز هویت یکپارچه را حتی بیشتر از این پیش برده است. از مزایای اصلی که احراز هویت یکپارچه ارائه می‌کند بهبود امنیت، انطباق و بهره‌وری است که برای کاربران داخلی و از راه دور به طور یکسان است.احراز هویت یکپارچهاحراز هویت یکپارچه یک روش احراز هویت می‌باشد که این قابلیت را به کاربران ارائه می‌دهد تا به صورت امن با چندین برنامه مختلف (برنامه‌های مبتنی بر وب، برنامه‌های ویندوزی، لینوکسی و ...) تنها با استفاده از یک مجموعه از اعتبار ارتباط برقرار کنند. روش احراز هویت چگونه عمل می‌کند؟ روش احراز هویت یکپارچه بر اساس یک رابطه اعتماد ایجاد شده بین یک برنامه کاربردی که به عنوان ارائه دهنده‌ی خدمات (service provider) شناخته می‌شود و یک ارائه دهنده‌ی هویت (identity provider) کار می‌کند. این رابطه اعتماد اغلب بر اساس گواهی است که بین ارائه دهنده‌ی هویت و ارائه دهنده‌ی خدمات رد و بدل می شود. این گواهی معمولا برای این استفاده می‌شود تا اطلاعاتی که قرار هست بین ارائه‌دهنده‌ی خدمات و همچنین ارائه‌ دهنده‌ی هویت جابه‌جا می‌شود، امضای الکتریکی (signed) شوند تا ارائه دهنده‌ی خدمات هنگام دریافت اطلاعات هویتی مطمئن باشد که این اطلاعات را از ارائه‌ دهنده‌ی هویتی معتبر و درست دریافت کرده است.در روش احراز هویت یکپارچه، اطلاعات هویتی که بین ارائه‌دهنده‌ها جابه‌جا می‌شوند، معمولا به صورت توکن‌هایی هستند که اطلاعاتی در مورد کاربر مثل ایمیل، نام کاربری و ... را شامل می‌شوند. معمولا جریان ورود با وجود فرایند احراز هویت یکپارچه برای ورودی به سامانه‌های مختلف به صورت زیر می‌باشد: کاربر ابتدا برنامه یا وبسایتی که می‌خواهد به آن دسترسی پیدا کند را باز می‌کند. (service provider) سرویس ارائه‌دهنده در هنگام احراز هویت کاربر، یک توکن شامل اطلاعات کاربر مثلا ایمیل را به سامانه ارائه‌دهنده‌ی هویت یکپارچه (SSO) ارسال می‌کند.سرویس ارائه دهنده‌ی هویت در ابتدا بررسی می‌کند که آیا کاربر تاکنون احراز هویت انجام داده است یا خیر. در صورتی که کاربر احراز هویت کرده باشد، سرویس ارائه‌دهنده‌ی هویت به کاربر اجازه‌ی ورود می‌دهند و در ادامه به مرحله‌ی 5 می‌رویم. در صورتی که کاربر تاکنون احراز هویت نکرده باشد و به سامانه وارد نشده باشد، از کاربر درخواست می‌شود که اطلاعات هویتی لازم را برای بررسی هویت وارد نماید. این اطلاعات می‌تواند در ساده‌ترین حالت به صورت نام کاربری و رمز کاربر باشد و حتی در موارد پیچیده‌تر می‌تواند به صورت رمزهای یکبار مصرف (OTP) باشد. هنگامی که ارائه دهنده‌ی هویت اطلاعات امنیتی کاربر را تایید کرد، یک توکن که نشان‌دهنده‌ی احراز هویت موقت کاربر بوده به سمت ارائه هنده‌ی سرویس ارسال می‌شود. توکن پس از دریافت‌شدن توسط ارائه دهنده‌ی سرویس، بر اساس اطمینانی که از قبل بین ارائه دهنده‌ی خدمات و ارائه دهنده‌ی هویتی که در ابتدای تنظیمات اولیه برقرار شده بود، بررسی و تایید می‌شود.برای کاربر اجازه‌ی دسترسی به ارائه دهنده‌ی سرویس فراهم می‌شود. هنگامی که کاربر سعی می‌کند به وب سایت دیگری دسترسی پیدا کند، وب سایت جدید باید یک رابطه اعتماد مشابه با راه‌حل SSO پیکربندی شده داشته باشد و جریان احراز هویت مراحل مشابهی را دنبال می‌کند. چرا باید از احراز هویت یکپارچه استفاده کنیم؟اما سوال اصلی این که چرا یک سازمان باید از احراز هویت یکپارچه استفاده کند؟ مهم‌ترین مزیت که استفاده از این روش برای یک سازمان خواهد داشت این است که سازمان می‌تواند برای تمامی کاربران خود یک مجموعه یکسان از اطلاعات هویتی را برای دسترسی به تمامی سرویس‌های فناوری اطلاعات (IT) فراهم کند. همچنین استفاده از احراز هویت یکپارچه میزان بهره‌وری، امنیت و تجربه کاربری کاربران و تیم‌ها را افزایش می‌دهد. زمانی که کاربران از روش احراز هویت یکپارچه استفاده می‌کنند، حجم زیادی از ارتباط میان کاربران با تیم‌های فناوری اطلاعات (IT) کاهش پیدا می‌کند که این هم در وقت کاربران و هم تیم توسعه زیرساخت صرفه‌جویی می‌کند. همچنین زمانی که امنیت را در یک راه‌حل کامل که شامل احراز هویت یکپارچه می‌شود بررسی می‌کنیم، مدیران فناوری اطلاعات می‌توانند به طور متمرکز الزامات رمز عبور، احراز هویت چند عاملی و دسترسی مشروط را در تمام منابع فناوری اطلاعات مورد استفاده در سازمان خود اعمال کنند و آن‌ها می‌توانند با اطمینان بدانند که فقط افراد مناسب به منابع حیاتی شرکت دسترسی دارند. مزایا و معایب روش احراز هویت یکپارچهراه‌حل‌های پیاده‌سازی احراز هویت یکپارچه متنوع بوده و تنها به یک روش خاص منتهی نمی‌شوند. هر کدام از این روش‌ها، مزایا و معایب خود را به دنبال خواهند داشت. اگر چه مزایا بسیار بیشتر از هرگونه معایب احتمالی است، مهم است که هنگام تصمیم‌گیری، تمام اطلاعات را در ذهن داشته بایم.مزیت‌هاساده‌سازی مدیریت اطلاعات امنیتی ساده‌سازی فرایند‌های ورود یا خروج از شرکت (در زمان‌های قدیم که چندین سرویس با روش‌های احراز هویت مختلف وجود داشت، لازم بود که هنگام ورود یک فرد به شرکت، برای تک تک سرویس‌ها درخواست‌ها و دسترسی‌های جداگانه‌ای ایجاد شود. همچنین لازم بود که در زمان خروج فرد، تمام دسترسی‌های فرد در سرویس‌های مختلف جداگانه بررسی شود و هر کدام جداگانه سلب شوند که امکان خطا نیز وجود داشت)افزایش کنترل مدیرانساده‌سازی و روان‌سازی تجربه‌ی کاربریبهبود امنیت و قابل اتکا سامانهکاهش تعداد دفعات ورود اطلاعات هویتیکاهش درخواست‌های مربوط به دسترسی و کارهای پشتیبانی در سمت فناوری اطلاعات (IT)افزایش بهره‌وری تیم فناوری اطلاعات (IT)افزایش تمایل به استفاده از سامانهکاهش هزینه‌هامعایبدر مقیاس‌های بزرگ، می‌تواند هزینه‌هایی را به همراه داشته باشد. نیازمند آشنایی با سرویس‌های یکپارچه و استفاده مناسب از قابلیت‌های آن‌ها برای رسیدن به حداکثر کارایی نیاز به وجود اطلاعات امنیتی پیچیده‌تر (رمز کاربری باید قوی‌تر باشد چون بین سرویس‌ها مشترک می‌باشد)دسترسی به تمام سرویس‌ها در صورت هک‌شدن سرویس احراز هویت یکپارچهوجود مشکل در دستگاه‌های مشترکخوشبختانه، بسیاری از معایب احراز هویت یکپارچه را می‌توان با استفاده از یک راه‌حل بزرگتر مثل سرویس مدیریت دسترسی (IAM) که شامل احراز هویت یکپارچه نیز می‌باشد، به همراه اجرای سیاست‌های خاص برای کارمندان، حل‌ نمود.نمونه سرویس‌های متن‌باز برای احراز هویت یکپارچهنرم‌افزار Aerobase Serverاین سرویس، یک سرویس منبع‌باز (open source) می‌باشد که برای مدیریت دسترسی و هویت (IAM) استفاده می‌شود. این نرم‌افزار به راحتی سرویسی امن و احراز هویت قوی را ارائه می‌دهد. این ابزار امکاناتی از جمله موارد زیر ا فراهم می‌کند:احراز هویت یکپارچه (SSO) که مدیریت و به یادسپاری رمزها را ساده می‌نماید. پشتیبانی از ساختارهای پوشه‌ای (directory based) متنوع از جمله active directory، LDAP، ADFS و ...قابلیت ورود از شبکه‌های اجتماعی مختلف شامل گوگل، فیس‌بوک و ...فراهم‌سازی یک جریان ورود یکسان و امن و بهبود تجربه‌ی کاربریامن‌سازی دسترسی به برنامه توسط مکانیزم‌های MFA برای اجبار امنیت قویفراهم‌نمودن ساختار منسجم برای دریافت لاگ‌ها و رفع عیبفراهم سازی احراز هویت دو مرحله (Two-Factor Authentication)فراهم کردن رابط کاربری ساده و قوی برای مدیریت مرکزینرم‌افزار Keycloakاین نرم‌افزار، یک نرم‌افزار منبع باز (open source) می‌باشد که به راحتی قابلیت‌های مدیریت دسترسی و هویت را برای شما فراهم می‌کند. امنیت برنامه‌ها و سرویس‌ها را با کد کم یا بدون کد آسان می‌کند. کاربران با Keycloak به جای تک تک برنامه‌های مختلف احراز هویت می‌کنند. این بدان معنی است که برنامه‌های شما نیازی به تعبیه‌ی فرآیندی برای ورود به سیستم، احراز هویت کاربران و ذخیره کاربران ندارند. پس از ورود به Keycloak، کاربران برای دسترسی به یک برنامه دیگر نیازی به ورود مجدد به سیستم ندارند. این در مورد خروج نیز اعمال می‌شود. Keycloak یک خروجی یکتا را نیز فراهم می‌کند، به این معنی که کاربران فقط باید یک بار از سیستم خارج شوند تا از همه برنامه‌هایی که از Keycloak استفاده می‌کنند خارج شوند.فعال کردن ورود به سیستم با شبکه های اجتماعی به راحتی از طریق کنسول مدیریت اضافه می‌شود. فقط مسئله‌ی انتخاب شبکه اجتماعی است که می خواهید اضافه کنید و هیچ کد یا تغییری در برنامه لازم نیست!نرم‌افزار Keycloak دارای پشتیبانی داخلی برای اتصال به سرورهای LDAP یا Active Directory موجود است. همچنین از طریق کنسول مدیریت، مدیران می‌توانند تمام جنبه‌های سرور Keycloak را به صورت مرکزی مدیریت و شخصی‌سازی کنند. آن‌ها می توانند ویژگی‌های مختلف را به سادگی فعال و غیرفعال کنند. آن‌ها می‌توانند کارگزاری هویت و فدراسیون کاربر را پیکربندی کنند. آن‌ها می‌توانند برنامه‌ها و خدمات را ایجاد و مدیریت کنند و خط مشی‌های مجوز دقیق را تعریف کنند. آن‌ها همچنین می‌توانند کاربران از جمله مجوزها و جلسات را با مطابق با نیاز خود مدیریت کنند.از طریق صفحه‌ی مدیریت حساب، کاربران می‌توانند حساب‌های خود را مدیریت کنند. آن‌ها می‌توانند تنظیمات خود را به روز کنند، رمزهای عبور را تغییر دهند و احراز هویت دو مرحله‌ای را در صورت نیاز برای خود فعال و تنظیم کنند. کاربران همچنین می‌توانند جلسات را مدیریت کنند و همچنین تاریخچه حساب خود را مشاهده کنند. اگر ورود به سیستم اجتماعی یا واسطه‌گری هویت را فعال کرده باشند، کاربران می‌توانند حساب‌های خود را با ارائه‌دهندگان دیگری پیوند دهند تا به آن‌ها اجازه دهند تا در همان حساب با ارائه‌دهندگان هویت مختلف احراز هویت شوند.نمونه سرویس‌های ایرانیشرکت آتینشرکت آتین، یک شرکت دانش‌بنیان و مستقر در پارک علم و فناوری دانشگاه تهران می‌باشد که در سال 1396 فعالیت خود را در حوزه ارائه‌ی خدمات احراز هویت آغاز کرده است.این شرکت با بررسی نمونه‌های مشابه خارجی و بر اساس نیازهای داخلی کشور، درحوزه احراز هویت، اقدام به توسعه سامانه مدیریت هویت و دسترسی نموده است. تیم فنی آتین از فارغ التحصیلان دانشگاه‌های برتر کشور در حوزه نرم‌افزار و امنیت اطلاعات و با پشتوانه سابقه چندین ساله در حوزه احراز هویت و کنترل دسترسی تشکیل شده است.آتین یک سرویس مدیریت هویت و دسترسی است که با تمرکز ویژه بر رضایت مشتری بر بستر زیرساخت ابری توسعه یافته است. با استفاده از سامانه آتین مراکز و سرویس دهنده‌های فناوری اطلاعات به راحتی می‌توانند دسترسی دستگاه‌های مختلف داخل سازمان یا اشخاصی از جمله کارمندان، شرکای تجاری و مشتریان را به تمامی سامانه‌ها به صورت متمرکز مدیریت نمایند. آتین تضمین می‌کند که دسترسی همه کاربران بر اساس سیاست واحد صورت گیرد و تمامی افراد و سرویس‌ها، احراز هویت، مجوزدهی و نظارت شوند.این شرکت در حوزه‌های مختلفی از جمله احراز هویت یکپارچه و ورود متمرکز یا احراز هویت چندعاملی برای سازمان‌های و نهادهای دولتی مختلف، دانشگاه‌ها و موسسات عالی، بانک‌ها، شرکت‌های تولیدی و صنعتی راه‌حل ارائه می‌دهد. با معرفی شرکت و نیازمندی خود به این شرکت، می‌توانید از سرویس‌های این شرکت در حوزه‌ی احراز هویت یکپارچه بهره‌مند شوید. برای اطلاعات بیش‌تر نسبت به مزایای این شرکت و نحوه‌ی استفاده از آن می‌توانید به آدرس «سامانه‌ی احراز هویت متمرکز آتین» مراجعه نمایید. https://authin.ir/single-sign-on/ شرکت هویتاشرکت دانش بنیان فناوران هویت الکترونیکی امن (هویتا)، فعالیت خود را از سال 1381 در کشور آغاز نموده‌ و هدف آن، توسعه محصولات و خدمات حوزه زیرساخت مانند احراز هویت و هویت‌سنجی دیجیتال و ... به منظور تأمین امنیت اطلاعات و ارتباطات می‌باشد.سامانه احراز هویت ParsSSO شرکت هویتا، سرویس‌های احراز هویت و امضای دیجیتال مبتنی بر PKI را ارائه می‌‌دهد. احراز هویت در این سامانه به صورت Single Sign-On است یعنی تنها با یکبار احراز هویت، کاربر می‌‌تواند از تمامی سامانه ‌های سازمان بدون نیاز به احراز هویت مجدد استفاده نماید. همچنین مدیریت یکپارچه کاربران، مشکلات مربوط به سرپرستی سامانه ‌ها را به صورت چشمگیری کاهش می‌دهد. با تعریف یک کاربر، دسترسی کاربر در تمامی سامانه‌‌ها به صورت خودکار ایجاد می‌‌گردد و با حذف دسترسی، در تمامی سامانه‌ها از ورود کاربر جلوگیری خواهد شد. علاوه بر این، محصول ParsSSO با ارائه درگاه امضای دیجیتال، باعث حذف فرآیند PK-Enabling در سامانه‌‌های نرم ‌افزاری می‌گردد که منجر به کاهش چشمگیر زمان و هزینه‌‌های سازمان در تجهیز سامانه‌ها به زیرساخت کلید عمومی می‌‌شود. این سامانه از دو زیرسامانه Identity Provider و Digital Signature Gateway تشکیل شده است.برای اطلاعات بیش‌تر نسبت به مزایای این سرویس و نحوه‌ی استفاده از آن می‌توانید به آدرس «سامانه‌ی احراز هویت متمرکز هویتا» مراجعه نمایید. https://www.hovita.ir/portal/newsview/24/single-sign-on-sso-%DA%86%DB%8C%D8%B3%D8%AA%D8%9F/ این مطلب، بخشی از تمرین‌های درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است.منابعWhat Is Single Sign OnHow does single sign-on work?Aerobase IAMKeyCloak امین برجیان امین برجیان Fri, 24 Dec 2021 08:51:27 +0330 https://virgool.io/@borjianamin98/%D8%A7%D8%B1%DA%A9%D8%B3%D8%AA%D8%B1%D8%A7%D8%B3%DB%8C%D9%88%D9%86-%DA%A9%D8%A7%D9%86%D8%AA%DB%8C%D9%86%D8%B1-container-orchestration-yjijl7xiurwk امروزه تقریبا استفاده از روش‌های کانتینری‌سازی (containerization) در تمام صنایع و شرکت‌های سراسر جهان رو به افزایش است. در واقع، گزارش‌های سالانه اخیر نشان می‌دهد که روش‌های مبتنی بر کانتینر تقریبا در بیش‌تر از 87 درصد از سازمان‌های مورد بررسی در حال استفاده می‌باشد. از جمله اهداف شرکت‌ها در رفتن به سمت استفاده از روش‌های مبتنی بر کانتینر، سرعت بخشیدن به چرخه‌های استقرار، افزایش اتوماسیون، کاهش هزینه‌های فناوری اطلاعات و ... می‌باشد. فناوری‌های کانتینری در این میان چه فوایدی را برای شرکت‌ها فراهم می‌کنند؟ در این بخش، در ابتدا به صورت خلاصه با کانتینرها آشنا می‌شویم، سپس مفهوم ارکستراسیون کانتینر (container orchestration) را مورد بررسی قرار خواهیم داد و به چند نمونه از ابزارهای یا سرویس‌های موجود در این زمینه اشاره می‌کنیم. کانتینر چیست؟کانتینر یک واحد اجرایی از نرم‌افزار است که به بسته‌بندی و اجرای کد نرم افزار، کتابخانه‌ها، وابستگی‌ها و سایر بخش‌های یک برنامه کمک می‌کند تا بتواند به طور مستقل از محیطی که در آن استقرار پیدا می‌کند، قابل اجرا باشد. البته الزامی وجود ندارد که یک کانتینر حتما بخشی از یک برنامه‌ی اجرایی باشد بلکه می‌تواند قابلیت‌هایی مثل داشتن یک ابونتوی تمیز، یک سرور HTTP ساده و ... را فراهم کند بدون این که شما لازم باشد درگیر فرآیندهای لازم برای آماده‌سازی، کامپایل یا پکیج‌بندی موارد مختلف شوید.برنامه‌های کانتینری می‌توانند به راحتی روی دسک‌تاپ محلی، سرورهای مجازی با سیستم‌عامل‌های مختلف و ... اجرا شوند. مفهوم کانتینرسازی (Containerization) به فرآیندی گفته می‌شود که در آن توسعه، بسته‌بندی و استقرار یک برنامه بر اساس آماده‌سازی آن بر اساس روش کانتینر باشد به گونه‌ای که خروجی کار را بتوانیم به راحتی و مستقل از محیط نصب، اجرا کنیم. البته این که قسمت‌های مختلف و جداگانه یک برنامه را در یک کانتینر توسعه داده و قرار دهیم یا این که یک برنامه را به صورت کامل در آن قرار دهیم، کاملا به تصمیمات توسعه‌دهندگان مربوط می‌شود اما مستقل از این که تصمیم چه باشد، به این فرآیند کانتینرسازی می‌گویند.کانتینر چگونه عمل می‌کند؟کانتینرها از نوعی فناوری مجازی‌سازی (در واقعیت این فناوری در سیستم‌عامل‌ها فراهم شده است) برای رسیدن به این سطح از قابلیت حمل، عملکرد و سازگاری با محیط‌های مختلف استفاده می‌کنند. مجازی‌سازی به معنای استفاده از سخت‌افزار یک سیستم‌عامل برای ایجاد چندین سیستم‌عامل مجازی است. بعد از انجام این کار می‌توانیم از سیستم‌عامل‌های جداگانه برای انجام وظایف محاسباتی مختلف در بالای یک سرور فیزیکی واقعی استفاده کنیم. معمولا از این روش به روش مجازی‌سازی (virtual machine) گفته می‌شود. روش کانتینرها مشابه این روش می‌باشد با این تفاوت که اگر چه در بالای سخت‌افزار یک سرور میزبان قرار می‌گیرند اما تمامی کانتینرها از منابع مشترک سیستم‌عامل سرور مانند کتابخانه ها، باینری‌ها و ... بهره می‌برند. نمایش گرافی رابطه میان کانتینر و سیستم‌عامل (منبع عکس)طبق توضیحات، کانتینرها دارای چندین مزیت هستند که به صورت خلاصه در زیر به آن‌ها اشاره می‌کنیم:با کانتینرها، می‌توانید چندین کار را روی یک سیستم عامل اجرا کنید، که می‌تواند سبب کاهش پیچیدگی در مراحل مهندسی نرم افزار حذف شود.یک برنامه کانتینری را می‌توانیم به راحتی به یک محیط جدید با منابع مناسب منتقل کنیم و مانند قبل بدون توجه به تغییرات سرور یا نوع دیسک یا ...، آن را اجرا کنیم. کانتینرها معمولا خیلی سبک هستند (از نظر موارد مختلفی مثل حجم، منابع مودنیاز، ...) و سریع‌تر از ماشین‌های مجازی (VM) که سیستم عامل‌های مختلف را اجرا می‌کنند، مستقر می‌شوند. اگر به هر دلیلی یکی از کانتینرها دچار مشکل شود، این مشکل تا حد خیلی خوبی ایزوله عمل خواهد کرد و در رفتار و اجرای دیگر کانتینرها مشکل ایجاد نخواهد کرد.کانتینرها را در استفاده بهینه از منابع و صرفه‌جویی در هزینه‌های سخت‌افزاری خیلی بهتر عمل می‌کند.تفاوت کانتینر با ماشین مجازیکانتینرها در بالای سخت‌افزار یک سرور فیزیکی نصب می‌شوند و یک سیستم‌عامل واحد را به اشتراک می‌گذارند. در عین حال، ماشین‌های مجازی (VM) از نرم‌افزار، سفت‌افزار یا سخت‌افزار برای ایجاد چندین ماشین مجازی که سیستم‌عامل‌های مختلف را روی یک هاست اجرا می‌کنند، استفاده می‌کنند. بسیاری از مردم ماشین‌های مجازی را با کانتینر اشتباه می‌گیرند زیرا هر دو شکل مجازی‌سازی هستند. برای این که بتوانیم تفاوت این دو را درک کنیم، بهتر است تاریخچه این دو را نگاه کنیم.سال‌ها پیش ماشین‌های مجازی (VM) برای پاسخ‌گویی به نیازمندی فناوری اطلاعات و توسعه‌دهندگان متولد شدند. مهندسان می‌توانستند یک Hypervisor (سخت‌افزار، سفت‌افزار یا نرم‌افزاری که ماشین‌های مجازی را ایجاد، اجرا و نظارت می‌کند) را در بالای سخت‌افزار یک سرور فیزیکی قرار دهند تا چندین ماشین مجازی تولید کنند. این فرآیند در حال حاضر به عنوان مجازی‌سازی شناخته می‌شود.ساختار ماشین‌های مجازی بر سرور فیزیکی (منبع عکس)مجازی‌سازی این امکان را فراهم می‌کند که چندین سیستم عامل را روی یک سخت‌افزار اجرا کنیم. هر ماشین مجازی می‌تواند سیستم عامل خود (سیستم عامل مهمان) را اجرا کند. به این ترتیب، هر ماشین مجازی می‌تواند اپلیکیشن‌ها، کتابخانه‌ها و باینری‌های متفاوتی را از برنامه‌های کنار خود سرویس دهد. ماشین‌های مجازی به توسعه دهندگان این امکان را می‌دهد تا برنامه‌های متعددی را با سیستم‌عامل‌های موردنظر خود بر روی یک سرور فیزیکی اجرا کنند تا قدرت پردازش را افزایش دهند، هزینه‌های سخت‌افزاری را (خرید چندین سرور جدا) کاهش دهند و فرآیندهای مربوط به DevOps را کاهش دهند. توسعه‌دهندگان دیگر نیازی به اجرای یک برنامه در کل سرور ندارند و برنامه‌ها به خوبی از یکدیگر تفکیک می‌شوند.با این حال، ماشین‌های مجازی بهترین راه‌حل نبودند. از آن جایی که هر ماشین مجازی یک سیستم‌عامل مستقل شامل باینری‌ها و کتابخانه‌ها را در داخل خود اجرا می‌کند، باعث می‌شود که اجرای ماشین‌های مجازی حجم استفاده را افزایش دهد و به سرعت به چندین گیگابایت تبدیل شود. همچنین ماشین‌های مجازی به دلیل داشتن یک سیستم‌عامل کامل در خود، به جای چند ثانیه، نیاز به چندین دقیقه برای شروع به کار کردن دارند. این یک مشکل جدید است زیرا هنگام اجرای برنامه‌های پیچیده و تلاش‌کردن برای بازیابی فاجعه رخ‌داده، چند دقیقه می‌تواند مشکلات جدی ایجاد کند.همچنین ماشین‌های مجازی همچنین هنگام انتقال نرم‌افزار از یک محیط محاسباتی به محیط دیگر، در اجرای نرم‌افزار مشکل دارند. (وابستگی به محیط نصب شده روی ماشین مجازی هستند) این می‌تواند به دلیل نیازهای کنونی و روش‌های توسعه جدید،، مشکل‌برانگیز باشد.در این زمان بود که کانتینرها وارد عمل شدند. همانطور که قبلا بحث شد، کانتینرها سبک وزن هستند، منابع سرور میزبان را به اشتراک می‌گذارند و به طور منحصر به فردتر، برای کار در هر محیطی طراحی شده‌اند. در تصویر زیر تفاوت طراحی بین کانتینرها و ماشین‌های مجازی را یکبار دیگر مشاهده می‌کنید.تغییرات رخ‌داده در طول زمان بر نحوه‌ی استقرار برنامه‌ها (منبع عکس)ارکستراسیون کانتینر (container orchestration)ارکستراسیون کانتینر فرآیند خودکار برای هماهنگی و سازماندهی تمام جنبه‌های کانتینرهای مختلف، عملکرد آن‌ها و محیط‌های آن‌ها است. استقرار و مقیاس‌بندی کانتینر، تنظیمات مربوط به شبکه و نگهداری همه جنبه‌های ارکستراسیون کانتینرها هستند. یک برنامه در ابعاد بزرگ مخصوصا در روش‌های میکروسرویس، می‌تواند شامل صدها یا هزاران کانتینر باشد. مدیریت همه این کانیترها شامل استقرار آن‌ها، ارتباطات شبکه‌ای آن‌ها و ... به صورت دستی چالش برانگیز است! بنابراین مهندسان توسعه عملیات از ابزارهای اتوماسیون برای سهولت و بهینه‌سازی این فرآیندها استفاده می‌کنند.ارکستراسیون کانتینر چگونه کار می کند؟با استفاده از ارکستراسیون کانتینر، مهندسان می‌توانند زمان و نحوه شروع و توقف کانتینرها را مدیریت کنند، فعالیت‌های بخش‌های مختلف را برنامه‌ریزی و هماهنگ کنند، سلامتی و اجرای درست و به موقع را نظارت کنند، به‌روزرسانی‌ها را به راحتی توزیع کنند و فرآیندهای شکست و بازیابی از خطا را مدیریت و برنامه‌ریزی کنند. مهندسانی که در فرهنگ‌های توسعه‌ی عملیات (DevOps) کار می‌کنند از پلتفرم‌ها و ابزارهای هماهنگ‌سازی کانتینر برای خودکار کردن این فرآیند در طول چرخه حیات کانتینرها استفاده می‌کنند. ابزارهای ارکستراسیون فراوانی امروزه توسعه داده شده‌اند. معمولا نسخه‌های مدرن‌تر این نوع ابزارها به برنامه‌نویسان اجازه می‌دهند که از زبان توصیفی (declarative programming) برای توصیف بخش‌های مختلف استفاده کنند. این با روش استفاده از زبان امری متفاوت است و به توسعه‌دهندگان این امکان را می‌دهد که بدون مشخص‌کردن جزئیات انجام فرآیند، نتیجه مورد‌نظر را تعریف کنند.ارکستراسیون کانتینرها کارکردهای مختلفی دارد که در بالا نیز به بخشی از آن‌ها اشاره شد. اما مهم‌ترین مواردی که از آن‌ها انتظار داریم شامل موارد زیر می‌باشدپیکربندی و زمان‌بندی تعادل بار (Load balancing) بین کانتینرهاتخصیص منابع بین کانتینرهانظارت بر سلامت کانتینرهاارکستراسیون مدیریت کانتینر‌ها را ساده می‌کند. علاوه بر این، ابزارهای ارکستراسیون به تعیین اینکه کدام میزبان‌ها برای اجرای کاینترنهای خاص منطبق‌تر هستند کمک می‌کند. (الگوریتم‌هایی برای تخصیص بهینه منابع کلاستر بین کانتینرهای مختلف ارائه می‌دهند) این کار توسعه‌دهندگان را بسیار آسان‌تر می کند و در عین حال خطای انسانی و زمان استفاده را کاهش می‌دهد. ارکستراسیون همچنین اگر در جایی، خرابی رخ دهد و یک یا چندین مورد از کانتینرها دچار مشکل شوند، معمولا کانتینرها را مجددا بر روی همان سرور یا در صورت نیاز روی سرور دیگری راه‌اندازی می‌کنند تا انعطاف‌پذیری سیستم در برابر خطا افزایش یابد.کوبرنتیز (Kubernetes)کوبرنتیز یک پلتفرم ارکستراسیون کانتینر منبع باز است که هم از اتوماسیون توصیفی و هم از پیکربندی پشتیبانی می‌کند. امروزه جزو رایج‌ترین ابزارها در این زمینه می‌باشد. گوگل ابتدا آن را قبل از اینکه به بنیاد محاسبات Cloud Native تحویل دهد، توسعه داد. کوبرنتیز کانتینرها را با استفاده از فایل‌های YAML یا JSON توصیف و مدیریت می‌کند. در کوبرنتیز سه مفهوم pod و node و cluster را داریم. برخی از ارکستراسیون کانتینرها از جمله کوبرنتیز، کانتینرها را مستقیما اجرا نمی‌کنند. در عوض، آن‌ها یک یا چند کانتینتر را که معمولا به صورت واحد شناخته و استفاده می‌شوند، در ساختاری به نام pod (نامگذاری کوبرنتیز) قرار می‌دهند. کانتینرهای داخل یک مجموعه می‌توانند شبکه محلی و منابع را به اشتراک بگذارند در حالی که همچنان از کانتینرهای موجود در سایر بخش‌ها جدا و مستقل هستند. از آنجایی که این بسته‌ها یک واحد کاملا مستقل در پلتفرم ارکستراسیون هستند، آن‌ها به عنوان یک واحد بالا و پایین می‌شوند، به این معنی که همه کانتینرهای درون آن‌ها بدون توجه به نیازهای فردی آن‌ها، بر اساس آن مقیاس می‌شوند.یک گره (node) نشان دهنده یک ماشین واحد (سرور فیزیکی، ماشین مجازی، ...) است که که نمونه‌های بسته‌های مختلف از کانتینرها روی آن‌ها اجرا می‌شوند. وقتی مجموعه‌ای از چندین گره (node) را در کنار هم‌دیگر قرار می‌دهیم و از آن برای مدیتری برنامه‌های مختلف استفاده می‌کنیم، در عمل یک خوشه یا کلاستر تشکیل داده‌ایم.امروزه چندین ارائه دهنده Kubernetes-as-a-Service بر روی پلتفرم کوبرنتیز ساخته شده‌اند که نام برخی از آن‌ها در زیر مشاهده می‌کنید:Amazon Elastic Container Service (ECS)Azure Kubernetes Services (AKS)Google Kubernetes Engine (GKE)RedHat OpenShift Container PlatformRancherازدحام داکرها (Docker Swarm)اگرچه داکر به طور کامل Kubernetes را به عنوان موتور منتخب ارکستراسیون کانتینر پذیرفته است، این شرکت همچنان Swarm را ارائه می‌کند. این ابزار مشابه کوبرنتیز بوده و نسبت به آن کم‌تر توسعه‌پذیر و پیچیده‌ است، اما برای علاقه‌مندان به داکر که می‌خواهند مسیر آسان‌تر و سریع‌تری برای استقرار کانتینر داشته باشند، انتخاب مناسبی است. اجزای اصلی معماری داکر در Swarm به صورت خلاصه به صورت زیر است:ازدحام (Swarm): معادل یک خوشه در کوبرنتیز می‌باشد و مجموعه‌ای از گره‌ها با حداقل یک گره اصلی و چندین گره کارگر است که می توانند ماشین‌های مجازی یا فیزیکی باشند.سرویس (service): یک سرویس مجموعه‌ای از وظایف است که یک مدیر یا گره‌های عامل باید روی کلاستر انجام دهند. یک سرویس تعریف می‌کند که کلاستر باید از کدام کانتینرها به منظور رسیدن به اهدافی مشخص، چه دستوراتی را اجرا کند. یک سرویس در این زمینه مشابه یک میکروسرویس است. همچنین امکان مشخص‌کردن پارامترهایی مثل تعداد نمونه‌های یک سرویس وجود دارد.گره مدیر (manager node): هنگامی که یک برنامه کاربردی را در یک ازدحام مستقر می‌کنید، گره مدیر چندین عملکرد را ارائه می دهد: کار (به شکل وظایف) به گره‌های کارگر تحویل می‌دهد و وضعیت گروهی را که به آن تعلق دارد مدیریت می‌کند. گره مدیر می‌تواند خود در کنار مدیریت کارها، به صورت گره کارگر (worker) هم عمل کند. (در صورتی که تنظیم آن را فعال نمایید)گره‌ کارگر (worker node): این گره‌ها وظایف توزیع شده توسط گره مدیر در ازدحام را اجرا می‌کنند.وظیفه (tasks): کانتینرهای داکر هستند که دستوراتی را که در سرویس تعریف شده‌اند را اجرا می‌کنند. گره‌های مدیر وظایفی را به گره‌های کارگر اختصاص می‌دهند و پس از این تخصیص، کار را نمی‌توان به کارگر دیگری منتقل کرد. اگر کار به هر دلیل ناموفق باشد، مدیر نسخه جدیدی از آن وظیفه را به گره در دسترس دیگری در ازدحام اختصاص می‌دهد.در ایران معمولا به دلیل این که خود داکر و دیگر ابزارهای موجود منبع باز و قدرتمند برای ارائه قابلیت‌های کانتینر (Containerization) وجود دارند، ابزارهای جایگزینی برای آن‌ها تولید نمی‌شوند. اما در عوض سرویس‌هایی که معمولا ابزارهای موجود مثل کوبرنتیز را به عنوان سرویس ارائه می‌دهند (Platform as a service) (Pass) در ایران در دسترس نیستند. (مثل سرویس‌های گوگل و ...) به همین دلیل در ایران شرکت‌های مشابهی به وجود آمده‌اند که این سرویس‌ها را ارائه می‌دهند. در ادامه دو مورد از آن‌ها را معرفی می‌کنیم. کانتینر ابری ابرآوانابر آروان شرکتی است که در حوزه‌ی فناوری ابری محصولات و ابزارهای مختلفی را برای راحتی توسعه‌دهندگان در سرار جهان ارائه می‌دهد. از جمله سرویس‌هایی که با مراجعه به سایت این شرکت می‌تواند مشاهده نمود مواردی همچون شبکه توزیع محتوا (CDN)، سرور ابری، پلتفرم ویدیویی، کانتینر ابری، آبجکت استوریج و زیرساخت کسب‌وکارهای آنلاین می‌باشد. سرویس‌دهی به بسیاری از پربازدیدترین وب‌سایت‌های ایرانی، پخش‌زنده‌ی مهم‌ترین رویدادهای ملی، ارایه‌ی خدمات امنیتی به سامانه‌های حساس دولتی و هم‌چنین جلوگیری از حملات سایبری به بسیاری از بانک‌ها و سامانه‌های کشور از جمله خدماتی است که این شرکت در اختیار کاربران قرار می‌دهد.با استفاده از سکوی ابری آروان تنها با چند کلیک، محصول‌تان را به بازار عرضه کنید و از دغدغه‌های آماده‌سازی زیرساخت، نیروی فنی متخصص و صرف زمان برای تامین، آماده‌سازی و پیکربندی سرور، نصب اپلیکیشن‌های پایه مانند Run Time و نصب سرویس‌هایی مانند Load Balancing و Monitoring بی‌نیاز شوید. با ویژگی Scalability سکوی ابری آروان می‌توانید با توجه به نیازهای زیرساختی کسب‌وکارتان، تنها با یک کلیک منابع خود را افزایش دهید. این سرویس مبتنی بر APIهای ارائه‌شده توسط کوبرنتیز پیاده‌سازی شده است و محصول کوبرنتیز را به عنوان یک سرویس (PaaS) ارائه می‌دهد. کانتینر ابری آروان تمامی نیازمندی‌های زیرساختی شما از جمله Monitoring و Load Balancing را تامین می‌کند و با کنترل مداوم وضعیت زیرساخت، نرم‌افزارتان را مطابق با پیکربندی مورد نظرتان، همیشه در دسترس قرار می‌دهد.برای شناخت بیش‌تر سرویس ارائه‌شده توسط ابرآوان می‌توانید از صفحه‌ی زیر استفاده نمایید: https://www.arvancloud.com/blog/%d8%aa%d8%ba%db%8c%db%8c%d8%b1%d8%a7%d8%aa-%d8%b3%da%a9%d9%88%db%8c-%d8%a7%d8%a8%d8%b1%db%8c/ سرویس کوبرنتیز ستونمجموعه ستون با در اختیار داشتن سه دیتاسنتر قدرتمند در ایران و با گستردگی جغرافیایی و شبکه‌ای و حضور در نقاط متعددی در اروپا، آمریکای شمالی و شرق آسیا و با بهره‌گیری از به‌روزترین تکنولوژی‌های دنیا، همان زیرساختی را ارائه می‌کند که تاکنون به بزرگترین شرکت‌های ایران مانند بازار، دیوار و بلد نیز ارائه کرده است.راه‌اندازی و نگهداری کوبرنتیز کار بسیار سخت، تخصصی و هزینه‌بری است. ستون با بهره‌گیری از بهترین متخصصان، امکان استفاده از کوبرنتیز به‌عنوان سرویس را برای شما فراهم می‌کند. با استفاده از سرویس کوبرنتیز ستون دیگر نیازی به صرف هزینه‌های زیاد برای استفاده از آن نخواهید داشت و کلیه‌ی کارهای مرتبط با نگهداری، پایداری، توسعه‌پذیری و تامین منابع مورد نیاز را ستون برای شما انجام خواهد داد.از آن‌جایی که توضیحات خود سایت ستون در مورد خدمات آن در زمینه‌ی ارائه‌ی سرویس زیرساخت ابری بر مبنای کانتینر کامل بوده و ارتباط با پشتیبانی نیز فراهم است، پیشنهاد می‌شود برای اطلاعات بیش‌تر در این زمینه، به سایت ستون مراجعه نمایید: https://sotoon.ir/products/kubernetes نتیجه‌گیریمانند بسیاری از فناوری‌های که تازه به وجود می‌آیند، ابزارهای ارکستراسیون کانتینر دارای مزایا و معایب خود هستند. پلتفرم‌هایی که کوبرنتیز را برای شما مدیریت می‌کنند یا روش‌های مدیریت خود را برای داکرها به شما ارائه می‌دهند و از سوی دیگر ابزارهای منبع باز کنونی مثل کوبرنتیز، Swarm و Mesos/Marathon و ... باید بسته به معیارهایی مانند معماری، نیازهای دسترسی (High available)، انعطاف‌پذیری و از همه مهم‌تر منحنی یادگیری و پذیرش آن‌ها، ارزیابی شوند.این مطلب، بخشی از تمرین‌های درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است.منابعWhat is Container OrchestrationContainer Orchestration امین برجیان امین برجیان Fri, 24 Dec 2021 08:51:01 +0330 https://virgool.io/@borjianamin98/%D8%A7%D8%A8%D8%B2%D8%A7%D8%B1-%D9%BE%D8%A7%DB%8C%D8%B4-l3g1on4z3ou6 مقدمهفعالیت مانیتورینگ مخصوصا در فضاهای محاسبات و سرویس‌های ابری، شامل ردیابی پویا پارامترهای کیفیت سرویس (QoS) مربوط به منابع مجازی (مانند ماشین‌های مجازی، فضای ذخیره‌سازی، شبکه، دستگاه‌ها و ...)، منابع فیزیکی که به اشتراک می‌گذارند، برنامه‌هایی که روی آن‌ها اجرا می‌شوند و داده‌های میزبانی شده روی آن‌ها است. پیکربندی برنامه‌ها و منابع در محیط‌های رایانش ابری با توجه به تعداد زیادی از منابع ناهمگن، بسیار چالش برانگیز است. علاوه بر این، با توجه به این واقعیت که در یک زمان معین، ممکن است نیاز به تغییر پیکربندی منابع ابری (تعداد ماشین‌های مجازی، انواع ماشین‌های مجازی، تعداد نمونه‌های دستگاه و ...) به دلایلی همچون برآورده‌کردن الزامات کیفیت، رفع موقت مشکل قطعی شبکه، خرابی دیسک و ... وجود دارد؛ وجود ابزارهایی برای تشخیص خودکار این موارد و رفع مشکل آن‌ها به صورت خودکار یا در کمترین حالت اطلاع‌رسانی تیم پشتیبانی برای آگاه‌شدن از موضوع الزامی است. در عمل در مقیاس‌های بزرگ این قدر منابع و پارامترهای مختلف زیاد خواهند بود که بررسی دستی آن‌ها، می‌تواند بسیار زمان‌گیر و همچنین دارای خطای انسانی باشد. از این رو، ابزارهای نظارت و پایش بر سامانه‌های بزرگ می‌توانند به ارائه‌دهندگان سرویس‌ها یا توسعه‌دهندگان برنامه در موارد زیر کمک کنند:حفظ منابع و برنامه‌های کاربردی خود در زمان‌های اوج فشار (peak time)تشخیص تغییرات در عملکرد منابع و برنامه‌ها (رفتار نادرست، خروجی اشتباه و ...)بررسی نقض توافقات سطح خدمات (SLA) یا مواد پارامترهای کیفیت سرویس (QoS)ردیابی عملیات ترک و پیوستن منابع ابری به دلیل خرابی‌ها و سایر تغییرات پیکربندیدر این قسمت ما قصد نداریم که تمامی مزایای و معایب استفاده و عدم استفاده از سرویس‌های پایش سامانه را بیان کنیم. نیاز به وجود سامانه مانیتورینگ بر حسب تعاریف و نیاز‌های یک کسب و کار ممکن است الزامی یا در برخی موارد پیچیدگی و هزینه‌ی بیش از حد باشد. به همین دلیل بحث این موضوع خارج از این مقاله است. هدف این مقاله این هست که با فرض وجود نیاز به سرویس‌هایی برای پایش سامانه، از چه ابزارهایی می‌توان در این زمینه استفاده نمود، ویژگی‌ها و مزایای خاص این نرم‌افزارها چیست و ... ابزارهای پایشدر سامانه‌های ابری و بزرگ، نظارت برای حفظ در دسترس بودن سیستم و عملکرد درست سامانه ضروری است. این ضرورت هم برای ارائه‌دهندگان سرویس به مشتری و هم برای مصرف کنندگان سرویس مهم و حیاتی است. پایش یک سامانه یک ابزار کلیدی و مهم برای «مدیریت منابع نرم‌افزاری و سخت‌افزاری» و «ارایه‌ی اطلاعات مستمر» برای آن منابع و همچنین برای برنامه‌های کاربردی در سامانه است. در سامانه‌های بزرگ، نظارت می‌تواند به دو شکل متفاوت انجام شود: پایش سطح بالا و پایش سطح پایین.نظارت سطح بالا به وضعیت پلتفرم مجازی مرتبط است (اجرای درست برنامه، تولید خروجی مناسب، کارایی سرویس، در دسترس‌بودن سرویس، ...)نظارت سطح پایین به اطلاعات جمع‌آوری شده در مورد وضعیت زیرساخت فیزیکی مربوط می‌شود. (عدم وجود خرابی در دیسک، در دسترس‌بودن سرویس زیرساختی، عدم مصرف CPU بالا، تعادل در مصرف پنهای باند شبکه)سیستم مانیتورینگ معمولا یک سیستم قابل تنظیم (برای تطابق با محیط‌های مختلف) و معمولا چند بخشی است که قادر به پشتیبانی از عملکردهای نظارتی است. معمولا ابزارهای مانیتورینگ خاص‌منظوره مثل ابزار پایش روترهای شبکه و پایش سیستم‌عامل‌ها و برنامه‌ها جدا هستند و در کنار هم برای پوشش کامل نیاز‌ها استفاده می‌شوند. گاهی نیز یک ابزار اکثر این نیازمندی‌ها را (احتمالا نه به اندازه‌ی ابزار تخصصی در آن حوزه) به صورت یکجا ارائه می‌دهد.ابزارهای پایش، به طور جامع موارد و منابع شناسایی شده در سامانه را برای ناهنجاری‌ها رصد می‌کند. در تشخیص یک رفتار غیرعادی، سیستم پایش تلاش می‌کند تا این نمونه یا منبع را به‌طور خودکار تعمیر کند، در صورتی که مانیتور مربوطه دارای یک عمل بهبود خودکار باشد. (فرآیندی توسط توسعه‌دهنده یا ابزار ارائه شده باشد) در صورت که ترمیم خودکار توسط ابزار پایش ممکن نباشد، ابزار پایش به تیم پشتیبانی اطلاع می‌دهد. از نظر فنی، اعلان‌ها را می‌توان با روش‌های مختلفی مانند ایمیل یا پیامک ارسال کرد.در ادامه با دو نمونه از ابزارهای منبع‌باز در این زمینه آشنا می‌شویم و به صورت خلاصه عملکرد و نحوه‌ی کارکرد آن‌ها را بررسی می‌کنیم. پرامتئوس (Prometheus)ابزار پرامتئوس (لینک ابزار)پرامتئوس یک راه حل نظارتی برای ضبط و پردازش هر سری زمانی صرفا عددی است. این ابزار معیارهای منطبق بر این اصل را به همراه شناسه‌ها و ویژگی‌های زمانی منحصر به فرد آن‌ها، جمع آوری، سازماندهی و ذخیره می‌کند.پرامتئوس نرم افزار منبع‌باز است که متریک‌ها را از اهداف مشخص‌شده (scrape targets) جمع‌آوری می‌کند. ابزارهای زیادی امروزه از نحوه‌ی تعامل پرامتئوس پشتیبانی می‌کنند (و در صورت عدم پشتیبانی پرامتئوس روش‌هایی برای پشتیبانی ابزارهای خاص‌منظوره ارائه می‌دهد) شامل پلتفرم‌های زیرساختی (مانند کوبرنتیز)، برنامه‌های کاربردی و خدمات (مانند سیستم‌های مدیریت پایگاه داده، برنامه‌های توسعه داده‌شده توسط برنامه‌نویسان) می‌شود. پرامتئوس همراه با سرویس مدیریت هشدار (Alertmanager)، یک ابزار جمع‌آوری معیارها و ارائه‌ی هشدارهای انعطاف‌پذیر را ایجاد می‌کند.معماری و مولفه‌های مختلف پرامتئوسمعماری و مولفه‌های مختلف پرامتئوس (منبع عکس)پرامتئوس دارای اجزای مختلفی است که با هم کار می‌کنند تا سلامت، رفتار و عملکرد سیستم را ردیابی و گزارش دهند. روش جمع‌آوری داده‌ها که پرامتئوس پیشنهاد می‌دهد روش بسیار ساده‌ای است. هر سامانه‌ای کافی است که متریک‌های خود را در قالب متن ساده از طریق نقاط پایانی HTTP (endpoint) نشان بدهد، در آن صورت پرامتئوس داده‌های موردنیاز را جمع‌آوری می‌کنند و آن‌ها را ذخیره می‌کند. در ادامه پرامتئوس این امکان را فراهم کند تا با زبان پرس و جوی خاص پرامتئوس (PromQL) آن‌ها را تجزیه و تحلیل کنید.در ادامه به صورت خلاصه چند بخش مهم پرامتئوس را مورد بررسی قرار می‌دهیم.سرور پرامتئوسسرور پرامتئوس بخش مربوط به جمع‌آوری داده از هدف‌های مشخص‌شده و ذخیره‌سازی آن برای استفاده‌های بعدی را به عهده دارد. همچنین این سرور بحث مدیریت هشدارهای تعریف‌شده و زمان‌بندی و اجرای آن‌ها به منظور بررسی وضعیت سرویس‌های مختلف را نیز بر عهده دارد. روش کار پرامتئوس مبتنی بر روش کشیدن (pull based) می‌باشد به این معنا که داده‌ها و متریک‌ها به صورت خودکار به سرور فرستاده نمی‌شوند بلکه سرور آن‌ها را جمع‌آوری و ذخیره می‌کند. اطلاعات مربوط به نقاط هدف برای جمع‌آوری متریک‌ها معمولا به شکل‌های مختلفی (service discovery) می‌تواند مشخص شود. خود پرامتئوس تعداد روش مشخص و استاندارد شامل روش فایل (فایل json یا yaml)، روش‌های مبتنی بر کوبرنتیز و ... را ارائه می‌دهد. صادرکنندگان پرامتئوسبر خلاف دیگر نرم‌افزارهای مانیتورینگ که خود برنامه، پشتیبانی از نرم‌افزارهای مختلف مثل SNMP، رست‌سرور، متریک‌های سیستم‌عامل و ... را پشتیبانی می‌کنند، پرامتئوس بسیار سبک بوده و این موارد را در داخل خود ندارد. در عوض تعداد بسیار زیادی صادرکننده (exporters) به صورت رسمی و غیر رسمی توسط پرامتئوس نوشته شده است که می‌توانند متریک‌های سامانه‌های مختلف مثل پایگاه‌داده، سیستم‌عامل و ... را جمع‌آوری و در قالب یکسری صفحات متن ساده HTTP ارائه دهند تا توسط سرور اصلی پرامتئوس جمع‌آوری شوند. این طراحی این امکان را فراهم می‌کند تا هر کسی بتواند در صورتی که نرم‌افزار استانداری برای سامانه‌ی خاص و مورد استفاده‌اش وجود نداشت، پیاده‌سازی خود را فراهم کند. پرامتئوس push gatewayاگر چه پرامتئوس بر مبنای جمع‌آوری داده به جای ارسال داده از سمت برنامه‌ها عمل می‌کند، اما در مواقعی نیاز هست که متریک‌ها به جای جمع‌آوری ارسال شوند. این نیاز معمولا در برنامه‌های کوتاه مدت (برنامه‌ای که در زمان خاص به مدت کوتاهی اجرا می‌شود و سپس متوقف می‌شود) الزامی است. در این نوع برنامه‌ها، چون برنامه همواره بالا نیست، احتمال زیاد پرامتئوس در زمان‌هایی که مراجعه می‌کند داده‌ای را مشاهده نمی‌کند و در زمان‌هایی هم که برنامه بالا هست، ممکن است دقیقا در زمان درست که متریک حاضر هست، مراجعه نکند. در چنین مواردی معمولا یک سرور میانی بالا آورده می‌شود که متریک‌ها به صورت دائمی در قالب یک صفحه HTTP خروجی داده می‌شوند. سپس برنامه‌های کوتاه‌مدت اطلاعات خود را در زمان‌های موردنیاز به این سرور میانی ارسال می‌کنند و سرور میانی این اطلاعات را برای سرور پرامتئوس خروجی می‌دهد. پرامتئوس برای این نیازمندی مشابه که احتمالا در کاربردهای زیادی نیاز می‌شوند، یک سرور Push gateway طراحی کرده است که عملکرد مشابه عمکلرد توصیف‌شده در قسمت بالا را ارائه می‌دهد. به عبارتی از این طریق به نوعی پرامتئوس پشتیبانی از متریک‌های مبتنی بر ارسال (push based) را نیز فراهم می‌کند. با این حال توصیف کلیه‌ی ویژگی‌های پرامتئوس خارج از بحث این مقاله بوده و به همین مقدار توضیح برای آشنایی با آن اکتفا می‌کنیم. زبیکس (Zabbix)زبیکس یک راه‌حل پایش توزیع شده منبع باز برای نظارت بر سرورها است. این نرم‌افزار برای نظارت بر پارامترهای متعدد یک شبکه و سلامت و یکپارچگی سرورها، ماشین‌های مجازی، برنامه‌ها، سرویس‌ها، پایگاه‌های داده، وب سایت‌ها، ابر و غیره استفاده می‌شود. زبیکس از یک مکانیسم اعلان انعطاف‌پذیر استفاده می‌کند که از طریق تعدادی از پلتفرم‌ها مانند ایمیل، جیرا، slack و ... به کاربران هشدار می‌دهد.یکی از مزیت های اصلی این نرم‌افزار مشابه پرامتئوس این است که یک نرم افزار متن باز است، به این معنی که کاملا بدون هزینه و رایگان است. سرور زبیکس داده‌ها را از تمام عوامل خود جمع‌آوری می‌کند، آن‌ها را تجزیه و تحلیل می‌کند و نمایش داده‌ای مناسب از آن‌ها ارائه می‌دهد. همچنین روشی قابل تنظیم و آسان برای تفسیر رابط کاربری/داشبورد وب با ویجت‌ها، نمودارها، نقشه‌های شبکه، نمایش اسلاید و گزارش‌های مختلف ارائه می‌کند.المان‌های اصلی زبیکسمهم‌ترین المان‌های زبیکس شامل آیتم‌ها (Items)، محرک‌ها (triggers) و اعمال (actions) می‌شود. آیتم‌ها شامل هر چیزی می‌شوند که می‌توانیم روی سیستم مورد پایش تست و خروجی آن را به دست بیاوریم. خروجی تست‌ها در واقعیت داده‌ای خواهد بود که بعدا می‌توانیم از آن برای اطلاع‌رسانی‌های موردنیاز یا تحلیل داده مثل رسم گراف و ... استفاده کنیم. محرک‌ها در واقعیت شروطی هستند که محدوده‌ی یک آیتم را مشخص می‌کنند. (محدوده‌ای که ما انتظار داریم) محرک‌ها دارای وضعیت یا حالت می‌باشند مثلا می‌توانند در حالت عادی (OK) باشند و در صورت خارج‌شدن آیتم مورد بررسی از محدوده‌ی مشخص‌شده، به وضعیت مشکل‌دار (Problem) تغییر حالت دهند. همچنین در صورتی که دوباره وضعیت آیتم موردبررسی در بازه‌ی مورد انتظار قرار بگیرد، دوباره متریک از حالت مشکل‌دار به حالت عادی منتقل می‌شود. بین جابه‌جایی یک محرک از حالت عادی به مشکل‌دار و مشکل‌دار به عادی تفاوت می‌باشد و هر کدام یک انتقال (transition) مستقل محسوب می‌شوند. اعمال در واقعیت فرآیندهایی هستند که هر گاه وضعیت یک محرک تغییر می‌کند، اجرا می‌شوند. برای هر کدام از انتقال‌های محرک می‌توان اعمال متفاوتی را تعریف نمود. همچنین مجموعه فرایند‌های فراوانی از پیش طراحی‌شده (مثل ارسال ایمیل، sms و ...) و امکان تعریف فرآیندهای شخصی وجود دارد. قواعد دقیق چگونگی تعریف هر کدام از موارد بالا در سامانه زبیکس بسته به نوع نیاز می‌تواند ساده تا پیچیده باشد اما بحث این مقاله آموزش استفاده از زبیکس نبوده و به همین دلیل در صورت علاقه، می‌توانید مطالب مرتبط را مطالعه کنید.سامانه‌های قابل پایش با زبیکساگر می توانید یک دستگاه، پردازش یا سرویس را در شبکه از طریق یک برنامه، پروتکل یا حتی یک کد اسکریپت (bash script) مشاهده کنید، می‌توانید آن را با استفاده از Zabbix پایش کنید. معمولا در زمان‌های قدیم از روش SNMP (پروتکل مدیریت شبکه ساده) برای پایش بر دستگاه‌های شبکه استفاده می‌شد اما زبیکس فقط به استفاده از SNMP محدود نمی‌شود.زبیکس از دو مولفه‌ی اصلی تشکیل شده است - سرورهای زبیکس و عامل‌های زبیکس (Zabbix Agents) (البته به صورت دقیق‌تر مواردی مثل پراکسی‌ها و ... نیز وجود دارد که فعلا در این قسمت بحث نمی‌شود)سرورهای زبیکس برنامه‌های مرکزی هستند که نظارت می‌کنند، با پراکسی‌ها و عوامل زبیکس تعامل دارند، محرک‌ها را محاسبه می‌کنند، اعلان‌ها و فرآیندها را متناسب با اعمال تعریف‌شده انجام می‌دهند و به عنوان یک مخزن مرکزی داده‌های پایش‌شده عمل می‌کنند. سرورهای زبکیس می‌توانند بر روی اکثر سیستم عامل‌ها اجرا شوند.عامل زبیکس یک برنامه دیگر است که بر روی اهداف مشخص‌شده برای پایش مثل منابع و برنامه‌های محلی (هارد دیسک، حافظه، آمار پردازنده و غیره) مستقر می‌شود و اطلاعات آن‌ها را جمع‌آوری می‌کند. عامل اطلاعات عملیاتی را به صورت محلی جمع آوری می‌کند و داده‌ها را برای پردازش بیشتر به سرور زبیکس مرکزی ارسال می‌کند. عامل‌های زبیکس از طیف وسیعی از توابع داخلی برای جمع‌آوری داده‌های مختلف پشتیبانی می‌کند.در ایران معمولا در زمینه‌ی پایش بخش‌های مختلف مثل پایش سرورهای یک کلاستر، شبکه‌ی یک کلاستر و ... توسط شرکت‌های مختلف سرویس‌هایی ارائه می‌شود. در ادامه با دو مورد از این شرکت‌ها آشنا می‌شویم. نت‌نگارشرکت نت نگار تلاش کرده تا هر آنچه مجموعه‌ای از افراد صاحب کسب و کار از یک سرویس پایش شبکه و وب‌سایت برای آنلاین نگه داشتن سرویس خود نیاز دارند را فراهم کند. از جمله سرویس‌های ارائه شده توسط این شرکت برای این موضوع می‌توان به پوشش دیتاسنترهای ایران، عیب‌یابی آسان، پوشش بین المللی، اطلاع‌رسانی (Notification)، گزارش پایش، وضعیت صفحه عمومی، تعریف محرک و ... اشاره نمود.در زیر توضیح این شرکت در مورد برخی از ویژگی‌های مهم آن در زمینه‌ی پایش را مشاهده می‌کنیم:یکی از قابلیت‌های سرویس مانیتورینگ نت نگار، امکان تعریف گروه‌های کاری و انتخاب آن‌ها برای دریافت پیام‌های تیمی در زمان بروز خطا است. همچنین امکان اطلاع‌رسانی از طریق تماس تلفنی و اتصال حساب کاربری سرویس کاوه نگار، در شرایط حساس نیاز است با آن ها تماس تلفنی گرفته شود، وجود خواهد داشت که این امر پایش تیمی سرویس آنلاین شما را میسر می‌کند. اگر محصول شما دارای وب اپلیکیشن های موبایل است و از API استفاده می‌کنید، می‌توانید با قرار دادن یک Endpoint در API خود وضعیت آن را مانیتور کنید و از بروز خطا یا افزایش زمان پاسخگویی (Response time) قبل از مشتریان مطلع شوید. با تعریف مانیتور از نوع Ping می‌توانید وضعیت Uptime سرور خود را از نقاط مختلف بررسی و مانیتور کنید. ...برای آشنایی بیش‌تر با سرویس نت‌نگار می‌توانید به سایت آن مراجعه نمایید. https://netnegar.io/ بینانرم افزار مانیتورینگ شبکه بينا نرم افزاری برای پایش شبکه و کلاستر می‌باشد. پایش سرویسهای موجود بر روی شبکه را،رديابی هرگونه اختلال و اشکال، ارسال انواع اخطار به مسئولان شبکه و ... بخشی از ویژگی‌های این نرم‌افزار می‌باشد.نرم‌افزار بینا امکان پایش مواردی از جمله پایگاه‌های داده (شامل استفاده از منابع، وضعیت سخت‌افزاری، سرویس‌ها)، تجهیزات شبکه، سرورها، ایمیل سرورها، وب‌سایت‌ها، سرورهای مجازی، دما و رطوب اتاق‌های سرور و دیتاسنتر، پهنای باند بخش‌های مختلف کلاستر، صحبت لینک‌های شبکه، لاگ تجیزات شبکه و ... را فراهم می‌نماید. این نرم‌افزار توسط شرکت داناپرداز ارائه شده است که تاریخچه‌ی کوچکی از آن را در زیر می‌توانید مطالعه کنید.در دانا پرداز ما اعتقاد داریم کسب و کار شما استحقاق این رو داره که از بهترین نرم‌افزارها استفاده کند. نرم‌افزارهایی که نیاز سازمان شما رو مطابق با استانداردهای روز دنیا پوشش بدهند، به راحتی نصب و راه‌اندازی بشوند و از همه مهم‌تر کاربر پسند باشند. ما با این نگرش، محصولات فوق العاده‌ای طراحی و تولید کردیم که در بیش از 3000 شرکت و سازمان بزرگ در کشور نصب و راه‌اندازی شده‌اند و البته این هنوز برای ما اول راه است. محصولات مدیریت خدمات فناوری اطلاعات که مخاطب اصلی این گروه از محصولات، واحد فناوری اطلاعات شرکت‌ها و سازمان‌ها است شامل مانیتورینگ شبکه و زیرساخت و همچنین مدیریت خدمات فناوری اطلاعات بر اساس چارچوب ITIL کمک می‌کند.برای آشنایی بیش‌تر با خدمات نرم‌افزار ارائه‌شده توسط این شرکت در زمینه پایش سامانه‌ها می‌توانید از اطلاعات سایت آن استفاده نمایید.نتیجه‌گیریفعالیت پایش مخصوصا در فضاهای محاسبات و سرویس‌های ابری، شامل ردیابی وضعیت منابع مختلف استفاده‌شده توسط بخش‌های مختلف کلاستر به مدیریت بهتر و دقیق‌تر کلاستر کمک فراوانی می‌کند. امروزه ابزارهای مختلفی چه خاص‌منظوره و چه عمومی برای پایش بخش‌های مختلف ارائه شده است. همچنین شرکت‌های مختلفی در این زمینه برای ارائه‌ی مشاوره و راه‌اندازی این سرویس‌ها به کمک شرکت‌ها آمده‌اند. با توجه به نیازهای امروزه توجه به این مورد امروزه از اهمیت زیادی برخوردار می‌باشد. این مطلب، بخشی از تمرین‌های درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است.منابعAn overview of the commercial cloud monitoring toolsIntroduction to Prometheus monitoringZabbix: An Introduction To The Server Monitoring ToolIntroduction to Zabbix امین برجیان امین برجیان Fri, 24 Dec 2021 08:50:11 +0330 https://virgool.io/@borjianamin98/%D8%A7%D8%A8%D8%B2%D8%A7%D8%B1-%D9%85%D8%AF%DB%8C%D8%B1%DB%8C%D8%AA-%D9%84%D8%A7%DA%AF-n03igqbkiqie مقدمهلاگ فایلی است که هر بار که رویدادی خاص (اجرای یا توقف برنامه، رخداد‌های برنامه، رخدادهای سیستمی و ...) در سامانه رخ می‌دهد به طور خودکار تولید می‌شود. بسته به نیاز ممکن است تنها بخشی از این رویداد ذخیره شوند در حالی که تقریبا می‌توان تمامی رویدادها را به صورت خودکار ذخیره نمود. فایل‌های لاگ معمولاً مجموعه‌ای از رخدادها هستند که مهم‌ترین ویژگی این رخدادها، رمان رخداد می‌باشد. به عبارتی هر گزارش و رویدادی که لاگ می‌شود، می‌تواند ویژگی‌های زیادی را متناسب با نوع رویداد داشته باشند اما مهم‌ترین ویژگی آن‌ها ویژگی زمان می‌باشد که بتوانیم بر اساس آن رخدادها را بر اساس زمان مرتب نماییم.این رخدادها هر چیزی را که در پشت صحنه در سیستم‌عامل‌ها یا برنامه‌های نرم‌افزاری اتفاق می‌افتد ضبط می‌کنند. به طور خلاصه، آن‌ها هر چیزی را که سرور، شبکه، سیستم‌عامل یا برنامه فکر می‌کند برای پیگیری مهم است، ضبط می‌کنند. گزارش‌ها می‌توانند انواع رویدادها را از جمله پیام‌ها و تراکنش‌هایی که بین کاربران مختلف رخ می‌دهد، آنچه در حین پشتیبان‌گیری اتفاق افتاده، خطاهایی که اجرای برنامه را متوقف کرده است یا فایل‌هایی که توسط کاربران از یک وب‌سایت درخواست شده است، مستند کنند.انواع مختلفی از لاگ‌ها وجود دارند. گزارش‌های حسابرسی، گزارش‌های تراکنش، گزارش‌های رویداد، گزارش‌های خطا، گزارش‌های پیام تنها نمونه‌هایی از فایل‌های گزارش مختلف هستند و هر کدام هدف متفاوتی را دنبال می‌کنند. آنها در طیف گسترده‌ای از پسوندها، مانند log، txt یا پسوندهای اختصاصی مختلف وجود دارند. بسته به پسوند و خوانایی، می توان آن‌ها را با یک ویرایشگر متن استاندارد یا برنامه پردازش کلمه (مثلا Microsoft Word) باز کرد یا ممکن است نیاز به برنامه‌های خاصی داشته باشد. برخی از ابزارهای مدیریت لاگ این قابلیت را دارند که گزارش‌ برنامه‌ها یا سامانه‌های مختلف را بخوانند و داده‌های مفید از آن‌ها را استخراج کنند.مدیریت لاگ (گزارش) چیست؟مدیریت لاگ (گزارش) یک اصطلاح جامع است که شامل تمامی فعالیت‌ها و فرآیندهایی می‌شود که به منظور تولید داده‌ی گزارش، جمع‌آوری آن، متمرکز کردن، تجزیه و تحلیل آن، انتقال، ذخیره‌سازی، بایگانی و مدیریت حجم عظیمی از داده‌های گزارش تولید شده (اگر مدیریت نشوند، به زودی با محدودیت فضای ذخیره‌سازی مواجه می‌شویم) انجام می‌شود. ابزارهای مدیریت لاگ برای رسیدگی به تمام گزارش‌های تولید شده توسط برنامه‌ها، سیستم‌ها، شبکه‌ها، نرم‌افزارها یا کاربران و استفاده از آن‌ها به منظور رفع نیازهای سازمان می‌باشد. مدیریت گزارش نه تنها برای توسعه‌دهندگان بلکه حتی برای بخش‌های مختلف یک سازمان مثل بخش فناوری اطلاعات نیز مهم می‌باشد. این به این دلیل است که استفاده از لاگ‌ها برای اهداف امنیتی، بهبود عملکرد یا عیب‌یابی در بسیاری از بخش‌های فناوری اطلاعات و نقش‌های شغلی گسترده قابل استفاده است.طبق ویکی‌پدیا، می‌توانیم این فیلد را به شش زیر بخش تقسیم کنیم: ● تولید لاگ (گزارش) ● تجمیع لاگ‌ها و متمرکزسازی (aggregation) ● ذخیره و نگهداری طولانی مدت لاگ ● چرخش لاگ‌ها (log rotation) ● تجزیه و تحلیل لاگ‌ها ● جستجو و تولید گزارش از لاگ‌هادر ادامه با جزئیات بیشتر موارد بالا آشنا می‌شویم.تولید لاگاولین قدم در مدیریت لاگ‌ها، تعیین نحوه تولید داده‌های گزارش و محل ذخیره آن‌ها می‌باشد. لاگ‌های شما داده‌هایی را از بخش‌های مختلف محیط شامل می‌شوند: سیستم‌عامل، فایروال‌ها، سرورها، سوئیچ‌ها، روترها، برنامه‌ها، پایگاه‌داده‌ها و ...وقتی صحبت از ذخیره‌سازی به میان می‌آید، سامانه‌های امنیتی مانند فایروال، سامانه‌های تشخیص نفوذ یا سامانه‌های دارای نرخ درخواست بالا دارای حجم زیادی داده برای لاگ‌شدن هستند و این سامانه‌ها معمولاً ده‌ها یا صدها رویداد در ثانیه تولید می‌کنند. تولید این حجم از داده جدای از بحث چالش‌های جمع‌آوری، نیازمند فضای ذخیره‌سازی فراوانی می‌باشد. معمولا در این زمان‌ها بین هزینه و فایده باید مصالحه نمود و تصمیم گرفت چه مقدار هزینه برای ذخیره‌سازی داده می‌پردازیم، چه مقدار جمع‌آوری لاگ‌ها می‌تواند شبکه را شلوغ کند، چه مقدار نمونه‌گیری از داده‌ی لاگ برای ما کافی است و ...تجمیع لاگ‌ها و متمرکزسازیتجمیع لاگ‌ها و متمرکز‌ کردن آن‌ها فرآیندی است که در آن همه لاگ‌ها بدون توجه به منبع تولید آن‌ها در یک مکان جمع‌آوری می‌شوند. همانطور که در بخش قبلی گفته شد، حجم داده‌ها یکی از بزرگترین چالش‌ها در این فرآیند است، اما نکات مهم دیگری نیز وجود دارد که باید در نظر گرفته شود. حتی اگر سیستم مدیریت گزارش شما بتواند حجم زیادی از داده‌ها را مدیریت کند، آنچه اهمیت دارد سرعت تولید این داده‌ها است. ابزارهای مدیریت لاگ باید بتوانند با این سرعت همگام شوند، به همین دلیل است که «سرعت پردازش» یک ابزار چیزی است که باید هنگام انتخاب آن در نظر گرفته شود. نکته‌ی مهم دیگری که در این زمینه وجود دارد این است تمامی گزارش‌ها (به دلیل منبع‌های مختلف) با فرمت یکپارچه نیستند و در هنگام جمع‌آوری گزارش‌ها از منابع مختلف، چالش ایجاد می‌کنند. فرآیند نرمال‌سازی تمام لاگ‌های دریافتی را می‌گیرد و آن‌ها را به یک خروجی مشترک تبدیل می‌کند تا اطلاعات درون لاگ‌ها راحت‌تر تجزیه و تحلیل شوند. ما در ادامه نیاز به تحلیل داریم و جمع‌آوری خام این داده به صورت یک متن چندان مفید نخواهد بود بلکه نیاز داریم قسمت‌های مختلف این لاگ‌ها مثل زمان رخداد، منبع، سطح لاگ و ... قابل تفکیک و جداسازی باشند تا بتوانیم به راحتی روی لاگ‌های متمرکزشده جستجو کنیم و گزارشات مفید تولید کنیم. ذخیره و نگهداری طولانی مدت لاگبعد از تولید و تجمیع‌سازی لاگ‌ها، ذخیره و نگهداری لاگ برای طولانی مدت مسئله‌ی بعدی است. سوال اصلی در این مرحله این است که چه مدت باید لاگ ها را ذخیره کرد. در حالی که آسان‌ترین راه برای ذخیره‌سازی لاگ‌ها، در نظر گرفتن زمان نامحدود است تا در صورت نیاز بتوانیم داده‌های قدیمی را بازیابی کنیم، اما ذخیره این حجم داده بسیار پرهزینه خواهد بود. معمولا به همین دلیل داده‌ها برای مدت مشخصی مثلا حداکثر برای یک سال ذخیره می‌شوند به گونه‌ای که نیازهای مختلف سازمان را پاسخ داده و در عین حال حجم داده محدود شود. (البته بازه‌ی زمانی به حجم هر رکورد لاگ نیز وابسته است و به همین دلیل بازه‌ی زمانی ممکن است کمتر یا زیاد‌تر شود)هنگام ذخیره لاگ‌ها، می‌توانیم آن‌ها را بر روی دیسک یا در فضای ابری متناسب با نیاز ذخیره کنیم. هر کدام از این روش‌ها مزیتی دارند که بحث این مقاله نیست.چرخش لاگ‌هاچرخش گزارش با تغییر نام خودکار، تغییر اندازه، جابجایی یا حذف فایل‌های گزارش که خیلی بزرگ یا خیلی قدیمی هستند، به رفع مشکلات در مرحله قبل کمک می‌کند. با انتخاب فاصله زمانی می‌توان مشخص کنیم که پس از آن گزارش حذف شود یا برای صرفه‌جویی در فضا فشرده شود یا به مکان دیگری فرستاده شود. به این ترتیب، فضای ذخیره‌سازی جدیدی برای فایل های گزارش جدیدتر باز می‌شود.تجزیه و تحلیل لاگ‌هاتجزیه و تحلیل گزارش یکی از مهمترین بخش‌های مدیریت گزارش است زیرا جمع‌آوری و ذخیره داده‌های لاگ هیچ فایده‌ای ندارد اگر قرار نباشد از آن استفاده شود. ابزارهای مدیریت لاگ فرآیند تجزیه و تحلیل داده‌های لاگ را خودکار و ساده می‌کنند و راه‌های پیشرفته‌ای برای مصورسازی داده‌ها ارائه می‌دهند. گزارش تجزیه و تحلیل از نمودارها و سایر تصاویر برای نشان‌دادن همبستگی‌ها و شباهت‌های بین رویدادها و داده‌ها استفاده می‌کند و تشخیص مسائل و ردیابی علت آن‌ها را ساده‌تر می‌کند.موارد مورد استفاده تجزیه و تحلیل گزارش شامل انطباق‌دادن رویدادهای یکسان، امنیت، عیب‌یابی ساده‌تر و بهبود عملکرد است.جستجو و تولید گزارش از لاگ‌هاابزارهای مدیریت لاگ با داشتن رویکرد جمع‌آوری متمرکز و گزینه‌های جستجوی پیشرفته، جستجو و گزارش‌گیری از داده‌های لاگ را ساده می‌کنند. با در نظر گرفتن حجم فایل‌های گزارش، وجود ویژگی‌های جستجو پیشرفته تأثیر زیادی بر کاربردی‌بودن ابزار مدیریت لاگ خواهد داشت. جستجوی پیشرفته این امکان را فراهم می‌کند که به گزارش‌های ساختاریافته و بدون ساختار نگاه کنید و اطلاعاتی در مورد رویدادهای خاصی اطلاعاتی مهم را جمع‌آوری کنید. گاهی راه‌حل‌های مدیریت لاگ مجهز به ابزارهایی برای داده‌کاوی می‌شوند که در میان حجم‌ عطیم داده‌های لاگ برای کشف الگوهایی متفاوت می‌گردند و مواردی پنهان را کشف می‌کنند. این ابزارها قابلیت‌های ایجاد گزارش را نیز فراهم می‌کنند که خلاصه‌ی نهایی جستجو و تجزیه و تحلیل انجام شده می‌باشد.مزایای مدیریت لاگمزایای استفاده از فرآیند و روال‌های مدیریت لاگ را به صورت خلاصه (مهم‌ترین آن‌ها) می‌توانیم به صورت زیر بیان کنیم:ذخیره‌سازی یکپارچهنظارت و هشدارهای سیستمامنیت بهبود یافتهعیب‌یابی بهترتجزیه و استخراج اطلاعات از فایل‌های لاگ تحلیل داده‌هابا توجه به وجود فرآیندهای متنوعی که در زمینه‌ی مدیریت لاگ انجام می‌شود، معمولا یک ابزار مشخص تمامی این قابلیت‌ها را فراهم نمی‌کند (اگر چه ابزارهایی هم به صورت مجمتع‌شده وجود دارند) به همین دلیل در ادامه ابزار یا مجموعه‌ای از ابزارها را که به منظور مدیریت لاگ هستند، معرفی می‌کنیم. مجموعه ابزار ELKمجموعه ابزارهای ELK به همراه Beatهاتا یک یا دو سال پیش، مجموعه ابزار ELK مجموعه‌ای از سه محصول منبع باز شامل Elasticsearch و Logstash و Kibana بود که همگی توسط شرکتی واحد توسعه، مدیریت و نگهداری می‌شدند. در ادامه با اضافه‌شدن Beatهای متنوع، این مجموعه به یک پروژه چهار بخشی تبدیل شد اگر چه هنوز اسم آن بر حسب تاریخچه به صورت ELK می‌باشد.مولفه Elasticsearchمولفه Elasticsearch به عنوان محور اساسی و اصلی در مجموعه‌ی ELK محسوب می‌شود. Elasticsearch که معمولا برای جستجو و تجزیه و تحلیل گزارش استفاده می‌شود، امروزه یکی از محبوب ترین سیستم‌های پایگاه‌داده موجود است. این نرم‌افزار ابتدا در سال 2010 منتشر شد، یک موتور جستجو و تجزیه و تحلیل مدرن است که مبتنی بر Apache Lucene است. این نرم‌افزار کاملاً منبع باز و ساخته شده بر پایه‌ی جاوا می‌باشد. در دسته‌بندی پایگاه‌های داده از آن به عنوان یک پایگاه داده NoSQL نام‌ برده می‌شود. این ابزار داده‌ها را به روشی بدون ساختار (البته به صورت دقیق‌تر semi-structure) ذخیره می‌کند و تا همین اواخر حتی امکان استفاده از SQL برای پرس‌وجو روی داده‌ها وجود نداشت. (پروژه جدید Elasticsearch SQL به استفاده از دستورات SQL برای تعامل با داده‌ها می‌پردازد) اما با این حال بر خلاف بسیاری از پایگاه‌ داده‌های NOSQL دیگر، این ابزار تمرکز زیادی بر قابلیت‌ها و ویژگی‌های جستجو دارد و برای این منظور، یک واسط کاربری خیلی ساده و در عین حال قدرتمندی دارد که می‌توان با آن ساده‌ترین و پیچیده‌ترین جستجوهای متنی ممکن را انجام داد. در زمینه تجزیه و تحلیل داده‌ها، Elasticsearch همراه با سایر مولفه های ELK استفاده می‌شود و نقش ذخیره‌سازی داده‌ها را ایفا می‌کند.مولفه Logstashتجزیه و تحلیل لاگ بر اساس لاگ‌های دارای ساختار (structured) ممکن است. ساختار این امکان را فراهم می‌کند تا داده‌ها را در هر ابزاری بتوانیم ساده‌تر و راحت‌تر جستجو، تجزیه و تحلیل و تجسم کنیم. در صورت امکان، این ساختار باید متناسب با لاگ‌های تولید‌شده در سطح برنامه باشد. (تا حد امکان بخش زیادی از این ساختار توسط نرم‌افزار و برنامه‌های نوشته‌شده فراهم شود) در موارد دیگر، به عنوان مثال لاگ های زیرساخت و سیستم، ممکن است این ساختار وجود نداشته باشد و لازم است که ساختار لاگ‌ها توسط برنامه‌هایی استخراج شود تا تجزیه و تحلیل‌های آن‌ها در ادامه ساده‌تر شود. در پشته ELK وظیفه مهم تجزیه داده‌ها به Logstash به عنوان یک ابزار منبع باز توسعه‌یافته برای مدیریت جریان حجم زیادی از داده‌های لاگ از چندین منبع داده شده است. این نرم‌افزار وظیفه پردازش لاگ‌ها، بهبود آن‌ها و تغییر آن‌ها و سپس ارسال آن‌ها به یک مقصد مشخص برای ذخیره‌سازی را بر عهده دارد. به لطف حجم زیادی از افزونه‌ها (plugins) که امروزه برای آن فراهم شده است، این ابزار می‌تواند برای جمع‌آوری، غنی‌سازی و تبدیل طیف وسیعی از انواع مختلف داده استفاده شود. (بیش از 200 پلاگین مختلف برای این ابزار وجود دارد)مولفه Kibanaهیچ راه حل متمرکزی (log aggregation) بدون ابزار تحلیل و مصورسازی کامل نیست. بدون امکان پرس و جو و نظارت موثر بر داده‌ها، صرفا جمع‌آوری و ذخیره آن‌ها فایده چندانی ندارد. Kibana این نقش را در ELK به عنوان یک لایه تحلیل و مصورسازی قدرتمند ایفا می‌کند.این ابزار کاملاا منبع‌باز بوده و دارای یک رابط کاربری مبتنی بر مرورگر است که می‌تواند برای جستجو، تجزیه و تحلیل و مصورسازی داده‌های ذخیره‌شده در Elasticsearch استفاده شود (در زمان حال، Kibana را نمی‌توان در ارتباط با پایگاه‌های داده دیگر استفاده کرد). این ابزار به با قابلیت‌های گرافیکی و بصری غنی خود به کاربران این امکان را می‌دهد تا حجم زیادی از داده‌ها را کاوش کنند.مولفه‌های Beatsابزارهای Beats مجموعه‌ای از ارسال‌کنندگان گزارش منبع‌باز هستند که به‌عنوان عوامل (agents) روی سرورهای مختلف در محیط نصب می‌شوند و برای جمع‌آوری گزارش‌ها یا معیارهای مختلف عمل می‌کنند. این ابزارها معمولا با زبان برنامه‌نویسی Go نوشته می‌شوند (به همین دلیل سریع و سبک هستند) و در کنار آن این فرستنده‌ها به گونه‌ای طراحی شده‌اند که از نظر ماهیت سبک وزن باشند یعنی از منابع به صورت کارآمد استفاده می‌کنند و معمولا بدون نیاز به وابستگی خاصی کار می‌کنند. داده‌های جمع‌آوری‌شده توسط beatهای مختلف متفاوت است: ابزار Filebeat: جمع‌کننده‌ی فایل‌های گزارش (لاگ‌) نوشته‌شده بر روی دیسکابزار Packetbeat: جمع‌کننده‌ی داده‌های شبکهابزار Metricbeat: جمع‌کننده‌ی معیارهای سیستم و متریک‌های سامانه‌های مختلفابزار Winlogbeat: جمع‌کننده‌ی گزارش‌های رویداد ویندوز...علاوه بر Beatهای توسعه‌یافته و پشتیبانی‌شده توسط Elastic، فهرست رو به رشدی از آن‌ها ارائه‌شده توسط جامعه (community) نیز وجود دارد. پس از جمع‌آوری این اطلاعات، معمولا می‌توانید Beatهای خود را طوری پیکربندی کنید که داده‌ها را مستقیما به Elasticsearch یا Logstash برای پردازش اضافی ارسال کند. برخی از Beatها همچنین از پردازش پشتیبانی می‌کنند که باعث می‌شود نیاز به ابزارهایی مثل Logstash که قبلا مسئول آن‌ها بودند کم شود.در صورتی که علاقه‌مند به آشناشدن بیش‌تر با بخش‌های مختلف ELK و نحوه‌ی پیکربندی آن‌ها هستید، می‌توانید به سایت‌های مشابه در این زمینه مانند این سایت مراجعه کنید.مجموعه ابزار EFKمجموعه ابزار EFKاین مجموعه ابزار بسیار شبیه مجموعه ابزار قبلی می‌باشد! تفاوت آن در این است که به جای Logstash از مولفه‌ی دیگری به نام Fluentd استفاده شده است. این مولفه که امروز گسترش و اهمیت زیادی پیدا کرده است، به دلیل وجود کوبرنتیز و ... مورد استفاده قرار می‌گیرد (به راحتی قابل اجرا و تنظیم‌کردن می‌باشد) البته این مولفه Fluentd خود چندین نوع روش استقرار را پشتیبانی می‌کند که تا حد خوبی آن را شبیه مجموعه ابزار ELK می‌کند. این ابزار می‌تواند به عنوان یک فرستنده یا جمع‌کننده عمل کند. به عنوان فرستنده، داده‌های گزارش را به Elasticsearch و به عنوان جمع‌آورنده، لاگ‌ها را جمع‌آوری و به فرستنده ارسال می‌کند. روش‌های زیادی برای استقرار و استفاده از Fluentd وجود دارد که در ادامه به دو مورد از آن‌ها اشاره می‌شود.روش فرستنده و جمع‌کننده توامنحوه‌ی پیکربندی نوع یک (منبع عکس)یک رویکرد ساده و غیر کارا این است که فرض کنیم سرورهای بزرگ را در اختیار داریم. در اینجا ما می توانیم FluentD را در داخل این سرورها راه‌اندازی کنیم که به عنوان «گردآورنده» و همچنین «فرستنده» عمل می‌کند، لاگ‌ها را جمع‌آوری می‌کند و آن را به Elasticsearch می‌فرستد که ممکن است به یک گلوگاه تبدیل شود.روش فرستنده و جمع‌کننده مستقلنحوه پیکربندی نوع دو (منبع عکس)یک رویکرد بهتر استفاده FluentBit به عنوان یک «گردآورنده» لاگ‌های داخل سرورها می‌باشد. FluentBit حجم کمی دارد و جمع‌آوری داده‌های گزارش و ارسال آن به سرورهای Fluentd را به عهده می‌گیرد. در اینجا، Fluentd مزایای بسیاری را ارائه می‌دهد:تنها به عنوان یک «فرستنده» برای Elasticsearch عمل می‌کند که بسیار سبک‌تر می‌شود و کاری مستقل و مشخص را انجام می‌دهد. (درگیر انواع مختلف برنامه‌ها و نحوه‌ی جمع‌آوری داده‌های آن نمی‌شود)در حالت‌هایی که ممکن است به یک گلوگاه تبدیل می‌شود، می‌تواند تنظیم شود تا به عنوان یک بافر عمل کند (یا از ابزارهای موجود استفاده کند) تا به صورت موقت لاگ‌ها را ذخیره کرده و در زمان مناسب ارسال کند. می‌توان قوانین مسیریابی را بر اساس برچسب‌های فرستنده یا اطلاعات داخل لاگ برای آن مشخص کنیم. به عنوان مثلا بر اساس برخی از ویژگی‌های داخل لاگ یا برچسب فرستنده‌، مجموعه‌ای از لاگ‌ها را به ایندکس دیگری در Elasticsearch بفرستد. معمولا در ایران در این حوزه شرکت‌هایی به وجود آمده‌اند که سرویس‌هایی را در زمینه مدیریت لاگ ارائه می‌دهند، فرایند استفاده از ابزارهای منبع‌باز موجود را تسهیل می‌کنند یا خود ابزارهایی را ارئه می‌دهند. در ادامه با چند مورد از آن‌ها آشنا می‌شویم.مدیریت لاگ کوالاتکشرکت داده کاوان تصمیم یار در زمینه‌ی ارائه، مشاوره و آموزش خدمات نرم‌افزاری به سازمان‌های دولتی و خصوصی فعالیت می‌نماید. شرکت داده کاوان تصمیم یار خدمات نرم‌افزاری مختلفی ارائه می‌دهد که یکی از آن‌ها «کوالاتک» نام دارد که «تست اتوماتیک نرم افزار و تضمین کیفیت» می‌باشد. تیم کوالاتک متشکل از کارشناسان ارشد دانشگاه صنعتی شریف است که کیفیت دغدغه آن‌هاست. مجموعه به سازمان‌ها و تیم‌های توسعه نرم‌افزار کمک می‌کند از مزایای تست و تضمین کیفیت بهره‌مند شوند.سیستم مدیریت لاگ کوالاتک (Log Management) ابزاری است که به سازمان کمک می‌کند تا لاگ‌های مختلف نرم‌افزارها، اپلیکیشن‌ها و … را در این ابزار جمع‌آوری کند و آن‌ها را متناسب با نیاز خود ساماندهی نماید. ابزار مدیریت لاگ نتایج کاربردی و مهمی برای سازمان دارد که این نتایج به شرح ذیل می‌باشد: جمع آوری لاگ‌ها، تبدیل لاگ به داده، قابلیت جستجو، مانیتورینگ و هشدار و گزارشگیریبرای آشنایی بیش‌تر با این ابزار و خدمات ارائه‌شده توسط این شرکت می‌توانید از این لینک استفاده نمایید.مدیریت لاگ آتینشرکت دانش بنیان آتین، مستقر در پارک علم و فناوری دانشگاه تهران، در سال 1396 فعالیت خود را به طور تخصصی درحوزه ارائه خدمات احراز هویت آغاز کرد. این شرکت با بررسی نمونه های مشابه خارجی و بر اساس نیازهای داخلی کشور درحوزه احراز هویت، اقدام به توسعه سامانه مدیریت هویت و دسترسی نموده است. با این حال این شرکت امروزه در زمینه‌ی مدیریت لاگ و مانیتورینگ آن‌ها نیز خدماتی را ارائه می‌دهد. البته سرویس ارائه‌شده توسط این شرکت معمولا در کنار دیگر سرویس‌های حوزه‌ی امنیت این شرکت استفاده می‌شود. لاگ فعالیت های کاربران را در سامانه آتین رقابل ردیابی می‌باشد. همچنین اقداماتی نظیر ورود به سامانه، افزودن کاربر، به‌روز رسانی داشبورد و … از موارد موجود در سامانه آتین است. ثبت خودکار رفتارهای کاربران و رخدادهای مرتبط، ثبت وقایع امنيتی تعریف شده در برنامه های کاربردی، امکان پیگیری وقایع و گزارش‌گیری، امکان نظارت بر عملکرد کلیه کاربران، محفوظ‌ماندن فعاليت كاربران از سايرين به جز مدیران سامانه، ثبت وقایع در سطوح مختلف به منظور کاهش ریسک‌های دسترسی به اطلاعات و خدمات و ... شامل ویژگی‌های این سامانه است.برای آشنایی بیش‌تر با این ابزار و خدمات ارائه‌شده توسط این شرکت می‌توانید از لینک زیر استفاده نمایید. https://authin.ir/log-management-and-auditing/ نتیجه‌گیریدر حالی که انجام تمام مراحل ذکر شده مدیریت لاگ به تنهایی امکان پذیر است، این یک فرآیند زمان‌بر است که نیاز به سفارشی‌سازی و برنامه‌ریزی زیادی دارد. مدیریت لاگ بدون ابزارهای لاگ شبیه به برنامه نویسی از ابتدا به جای استفاده از کتابخانه‌ها و اسکریپت‌های موجود است که اگر چه قابل انجام است، اما از نظر زمان و منابع بیهوده است. ابزارهای مدیریت لاگ شامل تمام بخش‌های فرآیند مدیریت لاگ می‌شود و به شما امکان می‌دهد نحوه اجرای آن را کنترل کنید. از آنجایی که هیچ دو سیستمی دقیقا شبیه هم نیستند، هر راه‌حل مدیریت لاگ به شما امکان می‌دهد روشی را که می‌خواهید برای ذخیره داده‌های لاگ خود انتخاب کنید. یکی از بزرگترین مزیت‌ها، تجزیه و تحلیل و مصورسازی است که به کاربران بینش بهتری نسبت به داده های خود می‌دهد.این مطلب، بخشی از تمرین‌های درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است.منابعWhat Is Log Management? A Complete Logging GuideThe Complete Guide to the ELK StackLogging Architecture, EFK Stack امین برجیان امین برجیان Fri, 24 Dec 2021 08:49:17 +0330 https://virgool.io/@borjianamin98/%D8%B3%D8%A7%D9%85%D8%A7%D9%86%D9%87-%D9%87%D8%A7%DB%8C-%D9%85%D8%AF%DB%8C%D8%B1%DB%8C%D8%AA-%D9%81%D8%B1%D8%A2%DB%8C%D9%86%D8%AF-%DA%A9%D8%B3%D8%A8-%D9%88-%DA%A9%D8%A7%D8%B1-bpms-cehhsoacaa4v مقدمهمدیریت فرآیندهای کسب و کار، یک چالش بزرگ در اکثر سازمان‌ها است. بسیاری از صاحبان مشاغل تصور می‌کنند که این هزینه بزرگی است یا فقط برای فرآیندهای عظیم ارزش آن را دارد که به سراغ خودکارسازی این فرآیند‌ها پیش برویم. با این حال، ابزارهای موجود در این زمینه، بدون توجه به اندازه کسب و کار مهم هستند.مدیریت فرآیند کسب و کار چیست؟مدیریت فرآیند کسب و کار (BPM) یک مفهوم سازمانی است که در آن یک شرکت یک بار به همه فرآیندهای خود به طور کلی و جداگانه نگاه می‌کند. وضعیت فعلی را تجزیه و تحلیل می‌کند و زمینه‌های بهبود را برای ایجاد یک سازمان کارآمدتر و مؤثرتر شناسایی می‌کند. مدیریت فرآیند کسب و کار (BPM) شامل نحوه ایجاد، ویرایش و تجزیه و تحلیل فرآیندهای قابل پیش‌بینی که هسته اصلی کسب و کار آن شرکت را تشکیل می‌دهند، می‌باشد. هر بخش در یک شرکت یکسری ورودی‌ها مثل داده را دریافت می‌کند و وظیفه‌ی انجام یکسری فرآیند‌ها و تبدیل ورودی‌ها به چیز دیگری را بر عهده دارد. یک سازمان ممکن است شامل تعداد زیادی فرآیند اصلی یا فرعی باشد که توسط بخش‌های مختلف مدیریت می‌شوند و شناسایی و تحلیل آن‌ها به منظور بهبود آن‌ها برای سازمان از اهمیت زیادی برخوردار می‌باشد.چرا مدیریت فرآیند کسب و کار اهمیت دارد؟هنگامی که فرآیندهای تجاری سازماندهی نشده باشند و به صورت خودکار و سیستمی مدیریت نشوند، می‌توانند منجر به آشفتگی شوند. در سطح فردی، افراد فقط یک بخش از یک فرآیند را می‌بینند و تعداد کمی از آن‌ها می‌توانند اثرات کامل یک فرآیند، شروع و پایان آن، داده های کلیدی موردنیاز و جایی که تنگناها و ناکارآمدی‌های بالقوه وجود دارند را تشخیص دهند و ببینند.فرآیندهای مدیریت نشده و آشفته به کسب و کار آسیب می‌زند و منجر به یک یا چند مورد از موارد زیر می‌شود:زمان‌های تلف‌شده به دلیل سازماندهی‌نشدن فرآیندهاخطاهای بیشتر در فرآیند‌های مختلفافزایش سرزنش و ناراحتی افراد مختلفکمبود داده به دلیل تحلیل‌نشدن درست فرآیندهابا بکارگیری مدیریت فرآیندهای کسب و کار، سازمان‌ها می‌توانند فرآیندهای خود را بهبود بخشند و تمامی جنبه‌های عملیات را به صورت بهینه حفظ کنند. ابزار مدیریت فرآیند کسب و کار (BPMS) یک ابزار اتوماسیون است که به تجزیه و تحلیل، مدل‌سازی، پیاده‌سازی و نظارت بر فرآیندهای تجاری کمک می‌کند. این ابزارها کمک می‌کنند که آسیب‌پذیری‌ها را در سازمان‌های کسب و کاری و فرآیند‌های روزمره شناسایی کنیم که معمولا این موارد برای شرکت هزینه و زمان دارند و به کنترل آ‌ن‌ها کمک می‌کنند. از این طریق کارایی کارکنان شرکت افزایش می‌یابد. فرآیندهایی مانند مدیریت حساب، استخدام کارمند، صورتحساب، مدیریت موجودی و مستندات (که شامل مدیریت داده‌های پیچیده زیادی است) را می‌توان با استفاده از BPMS خودکار کرد.ابزار BPMS برای فرآیندهای یک سازمان که تکرار شوند یا به طور منظم و با الگوی خاصی انجام شوند، مفید هستند مانند استخدام یک کارمند، ارسال بسته، پرداخت حقوق، مدیریت گواهی‌ها، مجوزها، حساب‌ها، صورتحساب، خدمات مشتری، فناوری اطلاعات و امور مالی و ... هدف کاهش خطا و تاخیرهای ناشی از خطاهای انسانی است.برای فهم بهتر به عنوان مثال نمونه‌ای از فرایند‌ها در مدیریت بهداشت و درمان یک بیمارستان بررسی می‌کنم. بستری‌شدن در بیمارستان می‌تواند برای بیماران بسیار آسیب‌زا باشد. (جدای از بحث‌های روحی و روانی، در تماس با بیماران دیگر خواهند بود) هر گونه اختلال در روند پذیرش و ترخیص فقط به این ناراحتی می‌افزاید. فرآیند پذیرش به تنهایی دارای چندین مرحله است که از جمع‌آوری اطلاعات، اخذ مدارک پزشکی، جزئیات بیمه و اولویت اتاق را شامل می‌شود. ایجاد صورت‌حساب در ارتباط با چندین بخش انجام می‌شود از جمله پرستاری، جراحی، نیازهای پزشکی جانبی و موارد دیگر. فرآیندهای BPMS این اطمینان را ایجاد می‌کنند که جزئیات در طول مراحل مختلف فراموش یا نادیده گرفته نشوند، کارایی افزایش می‌یابد، از بیمار مراقبت می‌شود و استرس کمتری را تجربه می‌کند و هیچ فرآیندی از دست نمی‌رود.انواع مدیریت فرآیندهای کسب و کاریسامانه‌های BPMS را می‌توان به طور کلی به سه نوع طبقه بندی کرد:یکپارچه‌محورانسان‌محورسند‌محوردر ادامه به صورت خلاصه هر کدام را توصیف می‌کنیم. یکپارچه‌محوراین سیستم فرآیندهای را مدیریت می‌کند که بدون تعامل انسان انجام می‌شوند یا به حداقل تعامل انسانی نیاز دارند. این نوع مدیریت فرآیند به ادغام یکپارچه برنامه‌های رایانه‌ای و مبتنی بر اینترنت وابسته است. به عنوان مثال، داده‌های مورد استفاده توسط یک تیم فروش ممکن است از طریق یکپارچه‌سازی داده‌های دریافتی از ابزار بازاریابی شرکت‌های مختلف که آن را در ابزار مدیریت ارتباط با مشتری ذخیره می‌کنند، به دست آید. اگر چه اطلاعات توسط یک تیم استفاده می‌شود، اما از ادغام چندین نقطه به دست آمده است.انسان محوراین یک رویکرد مستقیم‌تر است که در آن انسان‌ها در هر مرحله تصمیم گیرنده هستند. با این حال، آن‌ها توسط یک رابط بصری هدایت می‌شوند تا فرآیند تصمیم‌گیری را بهتر درک کنند و چیزی از قلم نیافتد. یک نمونه آن استخدام کارمند است. در هر مرحله، از ارسال درخواست استخدام تا بررسی درخواست و پردازش توسط بخش منابع انسانی، این فرآیند به طور کامل توسط انسان انجام می‌شود. (با این حال موارد هر مرحله و خروجی هر مرحله و ... قابل مدیریت توسط نرم‌افزار مدیریت فرآیند‌ها می‌باشد.)سندمحوراین فرآیند کاملا توسط یک سند فرآیند هدایت می‌شود. در هر نقطه از گردش کار به چندین تاییدیه نیاز دارد. نمونه‌ای از این نوع می‌تواند تصویب بودجه‌ای باشد که نیاز به تایید در سطوح مختلف دارد اما کلیه‌ی مراحل و بخش‌های فرآیند، مبتنی بر اسناد از پیش تعریف‌شده می‌باشد.چرخه مدیریت فرآیند‌های کسب و کاریچرخه مدیریت فرآیند‌های کسب و کاری (منبع عکس)یک BPMS کارآمد نه تنها به بهبود فرآیندها کمک می‌کند بلکه به خودکارسازی فرآیند‌ها نیز کمک می‌کند که تمامی این‌ها از طریق نرم‌افزار انجام می‌شود. این نرم افزار کل گردش کار فرآیند را مشخص می‌کند و آن را در یک محیط مجازی آزمایش می‌کند، در حالی که متغیرها و نتایج را فرض می‌کند و گلوگاه‌ها را شناسایی می‌کند و آن‌ها را حذف می‌کند. سپس فرآیند آزمایش شده جدید به کار گرفته می‌شود. BPMS به همین جا ختم نمی‌شود و از اینجا به بعد، به طور مداوم گردش کار را برای اثربخشی و کارایی نظارت می‌کند. به همین دلیل معمولا چرخه‌ی BPMS بر اساس مراحل روبرو خواهد بود: تجزیه و طراحی، مدل‌سازی، اجرا، نظارت و بهینه‌سازی.تحلیل و طراحیاین فرآیند مطالعه رویه‌های موجود و تجزیه و تحلیل آن‌ها برای کشف تأخیرهای موجود است. هر جنبه‌ای از گردش کار تجزیه و تحلیل می‌شود و معیارهایی برای مقایسه در محل قرار می‌گیرند. این فرآیند شامل اصلاح عیوب و تأخیرهای فرآیندهای با طراحی یک گردش کار کارآمدتر است. هدف این طراحی اصلاح گردش کار و فرآیندهای درون آن است که منجر به تنگناها و ناکارآمدی می‌شود. تمام هشدارها و تشدیدها را در فرآیندهای عملیات استاندارد هدف قرار می‌دهد و آن‌ها را با یک فرآیند کارآمدتر تصحیح می‌کند.مدل‌سازیاین طرح اکنون در یک فلوچارت در هر فرآیند نشان داده می شود در حالی که دسترسی‌ها مشخص می‌شوند و بخش‌های تکراری حذف می‌شوند. در ادامه حلقه‌های شرطی (مانند if و when) را با متغیرهایی در هر نقطه معرفی می‌کند تا نتایج متفاوتی از فرآیندهای قدیمی را تعیین کند، مانند مراحلی که باید در زمانی که خروجی هدف برآورده نشد یا اگر نتیجه مرحله قبل رضایت‌بخش است، انجام داد.ابزارهای مدل‌سازی کسب‌وکار ایده‌آل باید خوانا، ساده برای برقراری ارتباط، ارزان و به‌روز با استانداردهای صنعت باشند. مدل باید دارای یک رابط گرافیکی و یک ویرایشگر و شبیه‌ساز گردش کار باشد.اجراپس از مدل سازی و شبیه‌سازی موفقیت آمیز طراحی گردش کار، مرحله بعدی اجرای فرآیند است. قبل از استقرار در گروه‌های بزرگتر روی گروه کوچکتری آزمایش می‌شود. محدودیت‌های دسترسی برای محافظت از اطلاعات حساس معمولا اعمال می‌شود. این فرآیندهای مربوط به این قسمت می‌توانند خودکار یا دستی باشند.نظارتدر این قسمت، فرآیندهای فردی ردیابی شده و آمار استخراج می‌شود. عملکرد در هر مرحله برای تعیین اثربخشی آن تجزیه و تحلیل می‌شود. همچنین به شناسایی گلوگاه‌ها و آسیب‌پذیری‌های امنیتی کمک می‌کند. بسته به اطلاعاتی که کسب و کار می‌خواهد، سطوح مختلفی از نظارت می‌تواند مورد استفاده قرار گیرد. نظارت (مانیتورینگ) شامل فرآیند کاوی است که در آن گزارش‌های رویداد تجزیه و تحلیل و بین فرآیند فعلی و فرآیند قبلی مقایسه می‌شوند. این اختلافات و تنگناهای بین دو فرآیند را آشکار می‌کند.هدف BPMS این است که تا حد امکان کسب و کار را خودکار کند و آن را به طور کارآمد برای منافع بلندمدت اجرا کند. با این حال، یک نرم‌افزار بد طراحی شده و غیرمعمول می‌تواند بیشتر از اینکه مفید باشد آسیب وارد کند. یک BPMS خوب باید دارای ویژگی‌های زیر باشد:رابط کاربر پسند برای طراحی فرآیندیک نمودار فرآیند بصری و سادهذخیره سازی مبتنی بر ابر برای ثبات و قابلیت اطمینان بهترداشبوردها و گزارش هایی که قابل تنظیم و یکپارچه هستندهشدارهای زمان واقعی خودکاردر ادامه دو نمونه از ابزارهای مربوطه در این حوزه را معرفی می‌کنیم. در این قسمت سعی می‌کنیم بیش‌تر ابزارهایی را معرفی کنیم که امکان مدل‌کردن فرآیندهای کسب و کاری را توسط نرم‌افزار فراهم می‌کنند. به این صورت هم توسعه‌دهندگان و هم افراد حوزه‌ی کسب و کار می‌توانند از زبان مشترکی استفاده کنند و هر دو سود کنند. ابزار jBPMابزار jBPM یک نرم افزار رایگان و منبع باز BPM و موتور گردش کار است که شکاف بین تحلیلگران تجاری و توسعه‌دهندگان را پر می‌کند. jBPM دارای تمرکز دوگانه است: ارائه ویژگی‌های مدیریت فرآیند هم برای کاربران تجاری و هم توسعه‌دهندگان به طور یکسان. این ابزار مبتنی بر زبان جاوا نوشته شده است و به تسهیل اجرای فرآیند با استفاده از مشخصات BPMN 2.0 کمک می‌کند. این ابزار می‌تواند به راحتی برای استقرار در برنامه‌های مختلف جاسازی شود. همچنین قابلیت‌های مختلفی را ارائه می‌کند که منطق کسب‌وکار را به دارایی‌های قابل استفاده مجدد مانند موارد (cases)، فرآیندها، جداول تصمیم‌گیری و ... ساده‌سازی و بیرونی می‌کند و استفاده از هیچ یک از چارچوب‌ها را الزامی نمی‌کند. jBPM می تواند به عنوان یک سرویس مستقل یا تعبیه شده در خدمات مشتری استفاده شود. برای اطلاعات بیش‌تر می‌توانید به سایت مربوط به آن مراجعه کنید. https://www.jbpm.org/ ابزار activitiموتور Activiti مبتنی بر BPMN منبع باز سبک وزن و جاوا محور پیشرو است که از نیازهای اتوماسیون فرآیند در دنیای واقعی پشتیبانی می‌کند. کمک به کسب و کارها برای حل چالش‌های اتوماسیون در زیرساخت‌های توزیع شده، بسیار مقیاس پذیر و مقرون به صرفه از ویژگی‌های این ابزار است.از ویژگی‌های جالب این ابزار این است که استفاده از آن برای سازمان‌های مختلف ساده است:اگر از تکنولوژی‌های Spring Boot / Spring Cloud استفاده می‌کنید، افزودن این ابزار به این ترکیب خیلی ساده می‌باشد.اگر به دنبال فناوری‌هایی مانند Kubernetes و Docker هستید، همه اجزای آن آماده استفاده هستند و ابزار با الزامات این محیط‌ها هماهنگ هستند.اگر می‌خواهید پشته فناوری زیربنایی را تغییر دهید، برای مثال RabbitMQ را به ActiveMQ یا Kafka تغییر دهید، می‌توانید زیرا ابزار به لایه‌های انتزاعی Spring Cloud متکی می‌باشد.اگر از قبل یک خط CI/CD دارید، می‌توانید بلوک های خاص BPM را با آن ابزارها ادغام کنید....برای اطلاع بیش‌تر از ویژگی‌ها و مزایای این ابزار می‌توانید به لینک زیر مراجعه نمایید. https://www.activiti.org/ در ادامه با دو نمونه از شرکت‌های ایرانی که در این حوزه ابزارهایی را ارائه دادند، آشنا می‌شویم.سامانه مدیریت فرآیندهای کسب و کار آی‌کن (ICAN BPMS)آی‌کن (آینده کاوان کهکشان نرم‌افزار) بر اساس نیاز هر یک از مشتریان راهکارهایی را در جهت برنامه‌ریزی و بهینه‌سازی سازمان ارائه می‌دهد. گروه مهندسی آی کن در واحد تولید و ارائه‌ی خدمات پشتیبانی خود به صورت حضوری، تلفنی و از راه‌ دور، همه مشتریان خود را پشتیبانی می‌کند. سیستم مدیریت فرآیندهای کسب و کار آی‌کن (ICAN BPMS)، با رعایت کلیه استانداردهای BPM، چرخه تولید را به نحوی پیاده‌سازی می‌نماید که هر فرآیند در طول عمر خود بتواند از طریق این چرخه، بهینه‌سازی شده و در نهایت، منجر به بهینه‌سازی فرآیندهای کسب و کار گردد. این نرم‌افزار، اولین نمونه کاملا بومی در نوع خود می‌باشد که پس از ارائه به بازارهای داخلی و بین المللی، تحولی چشمگیر در صنعت نرم‌افزار ایران ایجاد نمود.با استفاده از ICAN BPMS می‌توانید با سایر سیستم‌های اطلاعاتی موجود در سازمانتان ارتباط برقرار کنید و فرم‌ها و فرآیندهای خاص خودتان را به صورت خودکار تعریف کنید. بهینه‌سازی مستمر فرآیندهای کسب و کار، تمرکز بر فرآیندها، امکان شبیه‌سازی و تست فرآیندهای سازمانی قبل از مرحله بهره‌برداری و قابلیت پیگیری و مانیتورینگ و بهینه‌سازی فرآیندها، کار را برای شما آسان‌تر و قابل فهم‌تر خواهد ساخت. این نرم‌افزار برای شما امکان دریافت گزارش‌ها و تحلیل‌های مدیریتی کاملی را ایجاد می‌کند که با استفاده از آن می‌توان تصمیم گیری‌های دقیقی را انجام داد.برای اطلاعات بیش‌تر در مورد سیستم مدیریت فرآیندهای کسب و کار آی‌کن، می‌توانید از لینک زیر استفاده نمایید. https://ican.ir/products/%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-bpms/ مدیریت فرآیند پارسامروزه یکی از مهم ترین مشکلات موجود در سازمان ها در سطح کشور، وجود ساختارهای وظیفه محور و یا سیستم‌های جزیره‌ای است. گروه مدیریت فرآیند پارس با ارایه خدمات مشاوره، تحلیل و توسعه سامانه‌هایی مبتنی بر وب و موبایل، در تلاش است تا راهکارهایی برای سازمان‌ها و کسب و کارها در راستای مدیریت فرآیندهای خود و افزایش کارایی در فرآیندها و روال‌ها ارائه کند. سازمان‌ها با بهره‌گیری از خدمات مشاوره‌ای و سیستمی که در اختیار آنان قرار داده می‌شود، قادر خواهند بود تا کسب و کار و فرآیندهای خود را به شکلی مکانیزه و یکپارچه به اجرا درآورده و گزارش‌های لحظه‌ای از وضعیت سازمان خود را در سیستم کامپیوتری، تبلت و یا تلفن همراه خود مشاهده نمایند تا شاهد افزایش روزانه بهینگی و یکپارچگی در سازمان خود باشند.از خدمات این شرکت در زمینه‌ی مدیریت فرآیند می‌توانیم به سیستم مدیریت فرآیند پارس، خدمات مشاوره، آموزش، شناسایی، تحلیل، بازمهندسی، پیاده‌سازی و استقرار فرآیندهای کسب و کار بر روی سیستم مدیریت فرآیند پارس، یکپارچه‌سازی فرآیندها با سایر سرویس‌ها و سیستم‌های اطلاعاتی در سازمان، برگزاری انواع کارگاه‌ها و دوره‌های آموزشی تحلیل، طراحی و پیاده‌سازی فرآیند، ارایه خدمات و انواع بسته‌های پشتیبانی به سازمان‌ها اشاره کنیم.برای آشنایی بیش‌تر با خدمات این شرکت می‌توانید به لینک زیر مراجعه نمایید. https://parsbpms.com/ نتیجه‌گیریخودکارسازی هدف کلیدی هنگام اجرای BPMS است. اگرچه BPMS یک سامانه است و نه یک نرم‌افزار یا سخت‌افزار خاص، فناوری نقش مهمی در کارآمدتر و مؤثرتر کردن BPMS دارد. این نرم‌افزار اکثر بخش‌های BPMS مانند مدل‌سازی و نظارت را خودکار می‌کند و هزینه بکارگیری و نگهداری مجموعه مهارت‌های تخصصی برای این منظور را حذف می کند. به همین دلیل استفاده از چنین ابزارهایی در مقابل عدم استفاده از این ابزارها، مزایا و فواید بسیاری را به همراه خواهد داشت.این مطلب، بخشی از تمرین‌های درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است.منابعA Full Overview of Business Process Management (BPM)What is BPMS?The Top 15 Free and Open-Source BPM Solutions امین برجیان امین برجیان Fri, 24 Dec 2021 08:48:15 +0330 https://virgool.io/@borjianamin98/%DA%A9%D8%AA%D8%A7%D8%A8-%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D8%AA%D9%85%DB%8C%D8%B2-knjpn9zmminn معرفی کتاب و عنوان آنکتاب Clean Architecture: A Craftsman’s Guide to Software Structure and Design اثر Robert C. Martin می‌باشد. معمولا اکثر افراد نویسنده‌ی این کتاب را با نام Uncle Bob می‌شناسند. نام این کتاب معماری تمیز گذاشته شده است اما سوالی که ایجاد می‌شود این است که چرا نام کتاب این‌گونه تعیین شده است؟ نویسنده‌ی کتاب در بخش مقدمه‌ی کتاب این چنین شروع می‌کند:من اولین خط برنامه‌نویسی خود را در سن 12 سالگی در سال 1964 نوشتم. امروز سال‌ها گذشته است و من هنوز در حال نوشتن کد هستم. در آن زمان من در مورد ساختار سامانه‌های نرم‌افزاری مطالبی را یاد گرفتم، مطالبی که به نظرم از نظر دیگران نیز ارزشمند بودند.من این موارد را با ساختن سامانه‌های بسیاری چه کوچک و چه بزرگ یاد گرفتم. من هم سامانه‌های کوچک در حد سامانه‌های نهفته (Embedded) را طراحی کردم و هم سامانه‌های بزرگ مثل سامانه‌های پردازش دسته‌ای را طراحی کردم. من هم سامانه‌های پردازش لحظه‌ای (real-time) و هم سامانه‌های مبتنی بر وب را طراحی کردم. من سامانه‌های مبتنی بر ترمینال، دارای رابط کاربری، بازی‌های متنوع، سامانه‌های حساب‌داری، ارتباط راه دور و خیلی موارد دیگر را تولید کردم. من همچنین برنامه‌های تک پروسس، چند پروسسه، دارای پروسس‌های سبک و سنگین، پایگاه‌داده‌ای، دارای محاسبات هندسی و ... نیز تولید کردم. من نرم‌افزارهای زیادی در این سال‌ها تولید کردم و در تمام این سال‌ها این را مشاهده کردم:تمام قواعد معماری یکسان هستند!چگونه ممکن است تمامی این سامانه‌ها با ویژگی‌های مختلف دارای قواعد معماری یکسانی باشند؟ نتیجه‌ی جمله‌ی بالا به این معناست که که قواعد طراحی معماری کاملا مستقل از هر نوع متغیری است. این خود عجیب‌تر است وقتی تمام تغییرات طول زمان مثل تغییرات سمت سخت‌افزار، پیشرفت سیستم‌عامل‌ها و ... را در نظر می‌گیریم. یک تحقیق ساده نشان می‌دهد که یک سیستم مثل مک‌بوک امروزه حداقل به اندازه‌ی ده به توان 22 برابر قوی‌تر از کامپیوترهایی است که آنکل باب با آن شروع به برنامه‌نویسی کرده است. این اصلا عدد کوچکی نیست! این تغییرات همچنین در سمت نرم‌افزارها و زبان‌های برنامه‌نویسی دیده می‌شود. امروزه ابزارها و زبان‌های پیشرفته‌ای ایجاد شده‌اند که به راحتی قابلیت توسعه را به برنامه‌نویسان با انعطاف فراوان ارائه می‌دهند. اما اگر کمی دقیق‌تر نگاه کنیم مشاهده می‌کنیم برنامه‌هایی که ما می‌نویسیم در پایین‌تر سطح خود همان شروط و حلقه‌ها هستند. همان چیزهایی که در زبان‌های برنامه‌نویسی ابتدایی وجود داشته و تنها نحوه‌ی نوشتار یا استفاده از آن‌ها ساده‌تر شده است. شاید گفته شود امروزه زبان‌های قوی مانند Java و C# و ... به وجود آمده‌اند و برنامه‌نویسی شی‌گرا استفاده می‌شود اما در نهایت هر برنامه‌ای توالی از دستورها، انتخاب بین مسیرها و حلقه‌ها هست که همان برنامه‌نویسی دهه‌های قدیم می‌باشد. در واقعیت اگر چه زبان‌ها و ابزارها تغییر کرده‌اند اما پایه و اساس زبان‌های برنامه‌نویسی همان موارد قدیمی است.این همان جواب راز جمله‌ی اول است. اگر چه ابزارها تغییر کرده‌اند اما عدم تغییر مفاهیم کدنویسی دلیلی است که معماری بین سامانه‌های مختلف هنوز یکپارچه هستند. قواعد معماری در واقعیت قواعد کنار هم گذاشتن این بلاک‌های کد و نحوه‌ی اجرای آن برای رسیدن به هدف هستند. از آن‌جایی که این بلاک‌های کد خود هنوز تغییر نکرده‌اند، قواعد مربوط به نحوه‌ی در کنار هم قرار دادن و ترتیب اجرای آن‌ها نیز تغییر نکرده است.(مطلبی که درک آن برای برنامه‌نویسان امروزه سخت است اگر چه که یک واقعیت است!)به همین دلیل آنکل باب مطالب این کتاب را این‌گونه توصیف می‌کند:در طول زمان یک چیز تغییر کرده است: در زمان‌های قدیم، ما نمی‌دانستیم قوانین معماری چیست. در نتیجه، ما آن‌ها را بارها و بارها شکستیم. اکنون، با نیم قرن تجربه پشت سرمان، ما به آن قوانین پی برده‌ایم. این قواعد (قوانین بی‌زمان و تغییرناپذیر) است که این کتاب درباره‌ی آن‌ها توضیح می‌دهد.در ادامه تعداد از بخش‌های کتاب را به صورت خلاصه شرح می‌دهیم تا شما را با حال و هوای مطالب کتاب و کلیت مطالب آن آشنا کنیم. قطعا گنجایش کلیه مطالب کتاب در این مقاله امکان‌پذیر نیست و هدف از این مقاله پوشش خلاصه و روان از مطالبی است که در چند فصل اول این کتاب مشاهده می‌کنید به امید این که به مطالب کتاب علاقه‌مند شوید و برای خواندن ادامه‌ی کتاب و خرید آن، اقدام کنید!تمامی عکس‌های استفاده‌شده، همان عکس‌های کتاب است تا با حال و هوای عکس کتاب نیز آشنا شوید.بخش یک (آشنایی)تفاوت طراحی و معماریدر طول سال ها سردرگمی‌های زیادی در مورد طراحی و معماری وجود داشته است. طراحی چیست؟ معماری چیست؟ چه تفاوت‌هایی بین این دو وجود دارد؟کلمه «معماری» اغلب در زمینه چیزی سطح بالا استفاده می‌شود که از جزئیات سطح پایین جدا شده است، در حالی که به نظر می‌رسد «طراحی» اغلب به ساختارها و تصمیمات در سطح پایین‌تر دلالت دارد. با این حال جزئیات سطح پایین و ساختار سطح بالا همه بخشی از یک کل هستند. آن‌ها یک کل پیوسته را تشکیل می‌دهند که شکل سیستم را مشخص می‌کند. شما نمی‌توانید یکی را بدون دیگری داشته باشید؛ هیچ خط جداکننده واضحی آن‌ها را از هم جدا نمی‌کند. صرفا دنباله‌ای از تصمیمات از بالاترین تا پایین‌ترین سطوح وجود دارد.هدف معماری نرم‌افزار به حداقل رساندن نیروی انسانی موردنیاز برای ساخت و نگهداری سیستم موردنیاز است.بررسی میزان کیفیت یک طراحی در واقعیت همان میزان تلاش موردنیازی است که برای برآورده‌کردن نیازهای مشتری باید بپردازیم. اگر این تلاش کم باشد و در طول عمر سیستم کم بماند، طراحی خوب است. اگر این تلاش با هر نسخه جدید افزایش یابد، طراحی بد است!معمولا توسعه‌دهندگان یک دروغ آشنا را می‌گویند: «ما می‌توانیم بعدا آن را اصلاح کنیم. فقط باید اول به بازار برسیم!» البته، همه چیز بعداً تمیز نمی‌شود، زیرا فشارهای مشتری هرگز کاهش نمی‌یابد. ورود به بازار ابتدا به این معنی است که شما اکنون انبوهی از رقبا را در پشت سر خود دارید و باید با سرعت هر چه بیشتر از آن‌ها جلوتر بمانید. دروغ بزرگ‌تری که توسعه‌دهندگان به آن می‌پردازند این است که نوشتن کدهای نامرتب باعث می‌شود در کوتاه‌مدت سریع پیش بروند اما در بلندمدت سرعت آن‌ها را کاهش می‌دهد. توسعه‌دهندگانی که این دروغ را می‌پذیرند، اعتماد بیش از حد را به توانایی خود در تغییر حالت‌ها از ایجاد آشفتگی به پاک‌کردن آشفتگی‌ها در آینده نشان می‌دهند، اما در عین حال یک اشتباه ساده را نیز مرتکب می‌شوند. واقعیت این است که ایجاد آشفتگی همیشه کندتر از تمیز کردن آن است.تنها راه سریع پیش رفتن، خوب پیش رفتن است.در هر صورت، بهترین گزینه این است که سازمان، اعتماد بیش از حد خود را کنار بگذارد و کیفیت معماری نرم‌افزار خود را جدی بگیرد. برای جدی گرفتن معماری نرم‌افزار، باید بدانیم که معماری نرم افزار خوب چیست. برای ساختن سامانه‌ای با طراحی و معماری که تلاش را در ادامه‌ی مسیر به حداقل می‌رساند و بهره‌وری را به حداکثر می‌رساند، باید بدانیم که کدام ویژگی‌های معماری سیستم به این هدف منجر می‌شود. در ادامه خواهیم دید که معماری‌ها و طرح‌های تمیز خوب چگونه به نظر می‌رسند، به طوری که توسعه‌دهندگان نرم‌افزار می‌توانند سیستم‌هایی بسازند که عمر مفید طولانی داشته باشند.ازرش دو مقدار (رفتار و ساختار)هر سامانه نرم‌افزاری دو ارزش متفاوت را برای ذینفعان فراهم می‌کند: رفتار و ساختار. توسعه‌دهندگان نرم‌افزار مسئول اطمینان از بالا ماندن هر دو ارزش هستند. متأسفانه، آن‌ها اغلب بر یکی تمرکز می‌کنند تا دیگری را کنار بگذارند. متاسفانه‌تر، آن‌ها اغلب بر روی دو مقدار کمتر تمرکز می‌کنند و سیستم نرم‌افزاری را در نهایت بی‌ارزش می‌کنند.رفتار سامانهاولین ارزش نرم‌افزار رفتار آن است. برنامه‌نویس‌ها استخدام می‌شوند تا ماشین‌ها را به گونه‌ای با برنامه‌نویسی هدایت کنند که باعث رفع یک نیازمندی یا صرفه‌جویی در پول برای ذینفعان شود. ما این کار را با کمک به ذینفعان برای توسعه مشخصات عملکردی یا سند ویژگی‌های سامانه انجام می‌دهیم.معماری (ساختار)دومین ارزش نرم‌افزار مربوط به کلمه "نرم‌افزار" است، کلمه‌ای مرکب که از «soft» و «ware» تشکیل شده است. کلمه «ware» به معنای «محصول» است. کلمه «نرم» همان جایی است که ارزش دوم نهفته است. نرم‌افزار برای «نرم» بودن اختراع شد و در نظر گرفته شده بود که راهی برای تغییر آسان رفتار ماشین‌ها باشد. اگر می‌خواستیم رفتار ماشین‌ها به سختی تغییر کند، آن را سخت افزار می‌نامیدیم.برای تحقق هدف خود، نرم‌افزار باید نرم باشد، یعنی تغییر آن آسان باشد. هنگامی که نظر مشتریان در مورد یک ویژگی تغییر می‌کند، آن تغییر باید ساده و آسان باشد. دشواری ایجاد چنین تغییری فقط باید متناسب با دامنه تغییر باشد و نه با شکل تغییر.ارزش بیش‌تر؟ عملکرد یا معماری؟اگر از مدیران کسب و کار بپرسید، اغلب می‌گویند که کارکرد سیستم نرم افزاری مهم‌تر است. توسعه‌دهندگان، به نوبه خود، اغلب با این نگرش همراه هستند. اما این نگرش اشتباه است. ما می‌توانیم با یک مثال ساده نشان دهیم که اشتباه است.اگر برنامه‌ای را داشته باشیم که کاملا کار می‌کند اما تغییر آن غیرممکن باشد، در صورت تغییر نیازها کار نمی‌کند و ما نمی‌توانم به سادگی کاری که کنیم که دوباره کار کند. بنابراین برنامه بی فایده خواهد شد. اگر برنامه‌ای داشته باشیم که کار نمی‌کند اما به راحتی قابل تغییر باشد، می‌توانیم آن را تغییر دهیم و با وجود تغییر نیازمندی‌ها آن را به کار بیاندازیم. بنابراین برنامه به طور مداوم مفید خواهد بود.ممکن است این استدلال را قانع کننده ندانید. در واقع، چیزی به نام برنامه‌ای وجود ندارد که تغییر آن غیرممکن باشد. با این حال، سیستم‌هایی وجود دارند که تغییر آنها عملا غیرممکن است، زیرا هزینه تغییر بیشتر از مزایای تغییر است. بسیاری از سیستم‌ها در برخی از ویژگی‌ها یا تنظیمات خود به آن نقطه می‌رسند.ماتریس Eisenhowerما دو نوع مشکل داریم، مشکل فوری (urgent) و مهم (important). موارد فوری مهم نیستند و موارد مهم هرگز فوری نیستند.اولین ارزش نرم افزار، «رفتار» ضروری است اما همیشه مهم نیست. دومین ارزش نرم افزار «معماری» مهم است اما هرگز همیشه ضروری نیست. البته بعضی چیزها هم فوری هستند و هم مهم. چیزهای هم هستند که فوری و مهم نیستند. در نهایت، می‌توانیم این چهار مورد را به صورت زیر از اولویت‌ها بالا به کم مرتب کنیم: فوری و مهمغیر فوری و مهم فوری و غیر مهمغیر فوری و غیر مهمتوجه داشته باشید که معماری کد (موارد مهم) در دو موقعیت بالای این لیست هستند، در حالی که رفتار کد (موارد فوری) در جایگاه‌های اول و سوم هستند. اشتباهی که مدیران و توسعه‌دهندگان کسب و کار اغلب مرتکب می‌شوند این است که موارد را در جایگاه 3 به جایگاه 1 ارتقا می‌دهند. به عبارت دیگر، آن‌ها نمی‌توانند آن ویژگی‌هایی را که فوری هستند اما مهم نیستند از ویژگی‌هایی که واقعا فوری و مهم هستند جدا کنند.معضل توسعه‌دهندگان نرم افزار این است که مدیران تجاری برای ارزیابی اهمیت معماری توانایی کامل ندارند. این همان کاری است که توسعه‌دهندگان نرم افزار برای انجام آن استخدام شدند. بنابراین این مسئولیت تیم توسعه نرم‌افزار است که اهمیت معماری را بر فوریت ویژگی‌ها تایید کند.تیم توسعه باید برای آنچه که معتقد است برای شرکت بهترین است مبارزه کند، تیم مدیریت، تیم بازاریابی و تیم فروش و تیم عملیات نیز همینطور. به عنوان یک توسعه دهنده نرم افزار، شما یک ذینفع هستید. شما سهمی در نرم افزار دارید که باید از آن محافظت کنید. این بخشی از نقش شما و بخشی از وظیفه شماست و این بخش بزرگی از دلیل استخدام شما است.بخش دوم (پارادایم‌های برنامه نویسی)معماری نرم‌افزار با کد شروع می‌شود و بنابراین، ما بحث خود را در مورد معماری با نگاه به نوشتن کد شروع می‌کنیم. پارادایم‌ها روش‌هایی برای برنامه‌نویسی هستند که نسبتا به زبان‌ها بی‌ارتباط هستند. یک پارادایم به شما می‌گوید که از کدام ساختارهای برنامه‌نویسی استفاده کنید و چه زمانی از آن‌ها استفاده کنید. تا به امروز، سه پارادایم از این دست وجود داشته است. در ادامه به صورت خلاصه با هر کدام از این پارادیام‌ها آشنا می‌شویم.برنامه‌نویسی ساختاریافتهاولین پارادایم پذیرفته شده (اما نه اولین موردی که اختراع شد) برنامه‌نویسی ساختاریافته بود. Dijkstra نشان‌داد که استفاده از پرش‌های مهار نشده (گزاره های goto) برای ساختار برنامه مضر است. او این پرش‌ها را با ساختارهای آشناتر if/then/else و do/while/until جایگزین کرد. می‌توانیم پارادایم برنامه‌نویسی ساخت‌یافته را به صورت زیر خلاصه کنیم:برنامه‌نویسی ساختاریافته بر روی انتقال مستقیم کنترل قواعد مشخصی را تحمیل می‌کند.برنامه‌نویسی ساختاریافته به ماژول‌ها اجازه می‌دهد تا به صورت بازگشتی به واحدهای قابل اثبات تجزیه شوند، که به نوبه خود به این معنی است که ماژول‌ها می‌توانند به طور عملکردی تجزیه شوند. یعنی می‌توانیم یک مسئله در مقیاس بزرگ را به توابع سطح بالا تجزیه کنیم. سپس هر یک از آن توابع را می‌توان به توابع سطح پایین‌تر، تا بی‌نهایت، تجزیه کرد. علاوه بر این، هر یک از آن توابع تجزیه شده را می‌توان با استفاده از ساختارهای کنترل محدود (حلقه و شروط) برنامه‌نویسی ساخت‌یافته پیاده‌سازی نمود.این توانایی ایجاد واحدهای برنامه‌نویسی است که امروزه برنامه‌نویسی ساخت‌یافته را ارزشمند می‌کند. به همین دلیل است که زبان‌های مدرن معمولاً از دستورات goto بدون محدودیت پشتیبانی نمی‌کنند. علاوه بر این، در سطح معماری، به همین دلیل است که ما هنوز تجزیه عملکردی را یکی از بهترین روش‌ها می‌دانیم.برنامه‌نویسی شی‌گراپارادایم دومی دو سال قبل کشف شد. تابع تبدیل به سازنده یک کلاس، متغیرهای محلی به متغیرهای نمونه (instance) و توابع تو در تو به متد (method) تبدیل شدند. این امر همچنین منجر به کشف چندشکلی (polymorphism) شد که از طریق استفاده از نشانگرهای تابع انجام می‌شد. الگوی برنامه‌نویسی شی‌گرا را به صورت زیر می‌توان خلاصه کرد:برنامه‌نویسی شی‌گرا بر روی انتقال غیر مستقیم کنترل قواعد مشخصی را تحمیل می‌کند.اما شی‌گرا دقیقا چیست؟ ترکیبی از داده‌ها و عملکرد جواب برخی از افراد به این سوال است اما این یک پاسخ صرفا رضایت بخش است و دقیق نیست چون فرق زیادی بین obj.f با f(obj) نیست. یکی دیگر از پاسخ‌های رایج به این سوال، راهی برای مدل‌سازی دنیای واقعی است. این یک پاسخ گریزان است زیرا مدل‌سازی از دنیای واقعی واقعا به چه معناست و چرا این چیزی است که ما می‌خواهیم انجام دهیم؟ شاید این عبارت به این معنی باشد که شی‌گرایی درک نرم افزار را آسان‌تر می‌کند زیرا رابطه نزدیک‌تری با دنیای واقعی دارد اما حتی این عبارت نیز ضعیف است و اصلا مشخص نمی‌کند که بالاخره شی‌گرایی چیست. برخی از افراد برای توضیح ماهیت شی‌گرایی از سه کلمه جادویی استفاده می‌کنند: کپسوله‌سازی (encapsulation)، وراثت، و چندشکلی. به عبارتی زبانی را شی‌گرا می‌دانند که ترکیب مناسبی از این سه چیز است یا حداقل از این سه چیز پشتیبانی کند. اما اگر به صورت دقیق‌تر زبان‌های گذشته مثل C را مشاهده کنیم و بررسی کنیم، می‌بینیم که هر کدام از نیازهای بالا را می‌توانستیم به شکل دیگری برآورده کنیم (با فرمت دیگری) و در نتیجه در زبان‌های قدیمی نیز این ویژگی‌ها وجود داشته است. صرفا در زبان‌های شی‌گرا این مفاهیم ساده‌تر شده و نامگذاری شده‌اند!نکته این است که بخش زیادی از این ویژگی‌ها در زبان‌های قدیمی توسط اشاره‌گرها (pointers) فراهم می‌شود. مشکل استفاده صریح از اشاره‌گر به توابع برای ایجاد رفتار چندشکلی یا وراثت این است که نشانگرهای توابع خطرناک هستند. چنین استفاده‌ای توسط مجموعه‌ای از قراردادهای دستی هدایت می‌شود. شما باید به یاد داشته باشید که برای مقداردهی اولیه آن اشاره‌گرها از قرارداد پیروی کنید. شما باید به یاد داشته باشید که برای فراخوانی تمام توابع خود از طریق آن اشاره‌گرها، از قرارداد پیروی کنید. اگر هر برنامه‌نویسی نتواند این قراردادها را به خاطر بسپارد، ردیابی و حذف باگ ایجاد شده به طرز عجیبی دشوار است. زبان‌های شی‌گرا این قراردادها و در نتیجه این خطرات را حذف می‌کنند. این واقعیت قدرت عظیمی را ارائه می‌دهد که برنامه‌نویسان قدیمی C فقط می‌توانستند رویای آن را داشته باشند. بر این اساس می‌توان نتیجه گرفت که شی‌گرایی نظم و انضباط را بر انتقال غیرمستقیم کنترل (Pointers) تحمیل می‌کند.این واقعیت که زبان‌های شی‌گرا چند شکلی را به صورت امن و راحت ارائه می‌کنند به این معنی است که هر نوع وابستگی کد منبع، مهم نیست که کجا باشد، می‌تواند معکوس شود. (برای این مورد می‌توانید در مورد Dependency Inversion مطالعه کنید) این به معمار اجازه می‌دهد تا یک معماری پلاگین‌مانند ایجاد کند، که در آن ماژول‌هایی که شامل سیاست‌های سطح بالا هستند مستقل از ماژول‌هایی هستند که حاوی جزئیات سطح پایین هستند. جزئیات سطح پایین به ماژول‌های افزونه منتقل می‌شوند که می‌توانند مستقل از ماژول‌هایی که حاوی سیاست‌های سطح بالا هستند، مستقر و توسعه یابند. این همان قدرت واقعی پارادیام شی‌گرایی می‌باشد.برنامه‌نویسی تابعی (Functional)پارادایم سوم، که اخیرا مورد استفاده قرار می‌گیرد، اولین موردی بود که ابداع شد. در واقع، اختراع آن به قبل از برنامه‌نویسی کامپیوتری باز می‌گردد. این پارادیام بر این پایه بنا شده است که یک زبان تابعی هیچ دستور انتسابی ندارد. اکثر زبان‌های تابعی در واقع ابزارهایی برای تغییر مقدار یک متغیر دارند، اما فقط تحت شرایط خاصی اجازه‌ی آن را می‌دهند. می‌توانیم پارادایم برنامه‌نویسی تابعی را به صورت زیر خلاصه کنیم:برنامه‌نویسی تابعی، بر روی انتساب مقادیر (assignments) قواعد مشخصی را تحمیل می‌کند.چرا این نکته به عنوان یکی از ملاحظات معماری مهم است؟ چرا یک معمار باید نگران تغییرپذیری متغیرها باشد؟ همه شرایط مسابقه (race condition)، شرایط بن بست و مشکلات به روزرسانی همزمان به دلیل متغیرهای قابل تغییر هستند. اگر هیچ متغیری به‌روزرسانی نشود، نمی‌توانید شرایط مسابقه یا مشکل به‌روزرسانی همزمان داشته باشید. شما نمی‌توانید بدون قفل‌های قابل تغییر (locks) بن بست داشته باشید. به عبارت دیگر، تمام مشکلاتی که در برنامه‌های همزمان با آن‌ها مواجه می‌شویم، اگر متغیرهای قابل تغییر وجود نداشته باشند، نمی‌توانند اتفاق بیفتند. اما آیا تغییرناپذیری عملی است؟ اگر فضای ذخیره‌سازی بی‌نهایت و سرعت پردازنده بی‌نهایت باشد، پاسخ این سوال مثبت است. با نداشتن آن منابع بی‌نهایت، تغییر‌ناپذیری می‌تواند عملی باشد، اگر مصالحه‌های خاصی صورت گیرد. مواردی مثل جداسازی بخش‌های تغییرناپذیر و تغییرپذیر تا حد ممکن از یکدیگر، استفاده از روش‌های منبع‌کردن رویداد (event sourcing) و ... می‌تواند راه‌حل‌های میانه برای این موضوع باشد.هر یک از پارادایم‌ها قابلیت‌هایی را از برنامه‌نویس حذف می‌کند. هیچ یک از آن‌ها قابلیت‌های جدیدی را اضافه نمی‌کند. هر کدام نوعی قوانین اضافی را تحمیل می‌کنند که در ذات خود منفی است. پارادایم‌ها به ما می‌گویند چه کاری را نباید انجام دهیم، تا اینکه به ما بگویند چه کار کنیم. این پارادایم ها چه ربطی به معماری دارد؟ ما از چندشکلی به عنوان مکانیزمی برای عبور از مرزهای معماری استفاده می‌کنیم. ما از برنامه نویسی کاربردی برای تحمیل نظم و انضباط در مکان و دسترسی به داده‌ها استفاده می‌کنیم. از برنامه‌نویسی ساخت‌یافته به عنوان پایه الگوریتمی ماژول‌های خود استفاده می‌کنیم. این سه تا حد خوبی با دغدغه بزرگ معماری همسو می‌شوند: عملکرد، جداسازی اجزا (separation of components) و مدیریت داده. در واقعیت در نگاه ساده پارادیام‌ها ما را محدود می‌کنند اما در عمل تمامی این قوانین برای این هستند که نظم برنامه بهتر شود و در بلندمدت به ما کمک خواهند کرد.بخش سوم (اصول طراحی)در این بخش uncle bob به بحث اصول SOLID و ارتباط آن‌ها با معماری می‌پردازد. اصول SOLID مشخص می‌کنند که چگونه توابع و ساختارهای داده را در کلاس‌ها مرتب کنیم و چگونه آن کلاس‌ها باید به هم متصل شوند. استفاده از کلمه «کلاس» به این معنی نیست که این اصول فقط برای زبان‌ها شی‌گرا قابل اجرا هستند. یک کلاس به سادگی یک گروه‌بندی توابع و داده است. هر سیستم نرم‌افزاری چنین گروه‌بندی‌هایی دارد، مستقل از این که کلاس نامیده شوند یا نه. اصول SOLID برای آن گروه‌بندی‌ها اعمال می‌شود.هدف از استفاده از این اصول ایجاد ساختارهای نرم‌افزاری سطح متوسط است که تغییرات را تحمل می‌کند، درک آن آسان می‌باشد و اساس اجزایی می‌باشند که در بسیاری از سیستم‌های نرم‌افزاری مورد استفاده قرار می‌گیرند. اصطلاح «سطح متوسط» به این واقعیت اشاره دارد که این اصول توسط برنامه‌نویسانی که در سطح ماژول کار می‌کنند اعمال می‌شود. آن‌ها درست بالاتر از سطح کد اعمال می‌شوند و به تعریف انواع ساختارهای نرم‌افزاری مورد استفاده در ماژول‌ها و مؤلفه‌ها کمک می‌کنند. در ادامه به صورت خلاصه با هر کدام از این اصول از نگاه کتاب آشنا می‌شویم:اصل مسئولیت واحد (Single Responsibility Principle)سیستم‌های نرم‌افزاری برای جلب رضایت کاربران و ذینفعان تغییر می‌کنند. آن کاربران و ذینفعان «دلیل تغییر» هستند. متأسفانه، کلمات «کاربر» و «ذینفع» واقعا کلمات مناسبی برای استفاده در اینجا نیستند. احتمالا بیش از یک کاربر یا ذینفع وجود خواهد داشت که خواهان تغییر سیستم به همان روش هستند. در عوض، ما واقعا به یک گروه (یک یا چند نفر) اشاره می‌کنیم که به این تغییر نیاز دارند. ما از آن گروه به عنوان یک بازیگر (actor) یاد خواهیم کرد. بنابراین SRP به این صورت است:یک ماژول باید در برابر یک و تنها یک بازیگر مسئول باشد.بهترین ساختار برای یک سیستم نرم‌افزاری به شدت تحت تأثیر ساختار اجتماعی سازمانی است که از آن استفاده می‌کند، به طوری که هر ماژول نرم‌افزاری یک و تنها یک دلیل برای تغییر دارد. اصل مسئولیت واحد درباره توابع و کلاس‌ها است، اما در سطوح دیگر طراحی نرم‌افزار به شکل متفاوتی ظاهر می‌شود. در سطح کامپوننت‌های یک نرم‌افزار همین اصل را با نام دیگری به نام اصل بسته‌بندی مشترکات مشاهده می‌کنیم و در سطح معماری سامانه، به محور تغییر تبدیل می‌شود که مسئول ایجاد مرزهای معماری را دارد.اصل باز و بسته (Open-Closed Principle)برای اینکه سیستم‌های نرم‌افزاری به راحتی قابل تغییر باشند، باید طوری طراحی شوند که رفتار آن سیستم‌ها را با افزودن کد جدید به جای تغییر کد موجود تغییر دهند. به عبارتی اصل OCP بیان می‌کند که:یک نرم‌افزار تولیدشده باید برای گسترش باز باشد اما برای تغییرات بسته شود.به عبارت دیگر، رفتار یک نرم‌افزار باید بدون نیاز به تغییر آن محصول قابل گسترش باشد. این اساسی‌ترین دلیلی است که ما معماری نرم‌افزار را مطالعه می‌کنیم. بدیهی است که اگر نیازمندی‌های ساده که از جنس اضافه‌شدن یک ویژگی جدید هستند نیاز به تغییرات گسترده‌ای در نرم افزار و بخش‌های از قبل نوشته‌شده هستند، معماران آن سیستم نرم‌افزاری دچار شکستی چشمگیر شده‌اند. اکثر افراد طراحی نرم‌افزار OCP را به عنوان اصلی می‌شناسند که آن‌ها را در طراحی کلاس‌ها و ماژول‌ها راهنمایی می‌کند، اما وقتی سطح اجزای معماری را در نظر می‌گیریم، این اصل اهمیت بیشتری پیدا می کند.اصل OCP یکی از نیروهای محرک پشت معماری سیستم‌ها است. هدف این است که سیستم را به راحتی گسترش دهیم بدون اینکه تأثیر زیادی از تغییر ایجاد شود. این هدف با پارتیشن‌بندی سیستم به اجزا و مرتب‌کردن آن اجزا در یک سلسله مراتب وابستگی انجام می‌شود که از اجزای سطح بالاتر در برابر تغییرات در اجزای سطح پایین محافظت می‌کند.اصل جایگزینی لیسکوف (Liskov Substitution Principle)برای ساختن سیستم‌های نرم‌افزاری از قطعات قابل تعویض، آن قطعات باید به قراردادی پایبند باشند که اجازه بدهد آن قطعات با دیگری جایگزین شوند. باربارا لیسکوف موارد زیر را به عنوان راهی برای تعریف زیرگروه‌ها نوشت.آنچه در این‌جا می‌خواهیم چیزی شبیه ویژگی جایگزینی زیر است: اگر برای هر شی o1 از نوع S یک شی o2 از نوع T وجود داشته باشد به طوری که برای همه برنامه‌های P که بر حسب T تعریف شده‌اند، رفتار P هنگامی که o1 جایگزین می‌شود بدون تغییر است. برای o2 پس S یک زیرنوع از T است. برای درک این ایده، که به عنوان اصل جایگزینی لیسکوف (LSP) شناخته می‌شود، یک مثال را بررسی می‌کنیم.تصور کنید که کلاسی به نام License داریم، همانطور که در شکل نشان داده شده است. این کلاس متدی به نام calcFee دارد که توسط اپلیکیشن Billing فراخوانی می‌شود. دو نوع زیر مجوز وجود دارد: مجوز شخصی و مجوز تجاری. آن‌ها از الگوریتم‌های مختلفی برای محاسبه هزینه مجوز استفاده می‌کنند.این طراحی با LSP مطابقت دارد زیرا رفتار برنامه صورتحساب (Billing) به هیچ وجه به هیچ کدام از دو نوع مجوز بستگی ندارد. هر دو نوع مجوز (تجاری و شخصی) قابل جایگزینی برای نوع مجوز (License) هستند.اگر بخواهیم مثالی را بیان کنیم که در آن قاعده‌ی لیسکوف رعایت نشده است، می‌توانیم مثال معروف مربع و مستطیل را بیان می‌کنیم. در این مثال، مربع یک زیرگروه مناسب از مستطیل نیست زیرا ارتفاع و عرض مستطیل به طور مستقل قابل تغییر هستند. در مقابل، ارتفاع و عرض مربع باید با هم تغییر کنند. از آن‌جایی که کاربر معتقد است با یک مستطیل ارتباط برقرار می‌کند، به راحتی ممکن است گیج شود. کد زیر دلیل را نشان می‌دهد:Rectangle r = ... r.setW(5); r.setH(2); assert(r.area() == 10);اگر کد بخشی که مشخص نشده است یک مربع تولید می‌کرد، آن‌گاه ادعا (assert) شکست می‌خورد. تنها راه دفاع در برابر این نوع نقض LSP افزودن مکانیسم‌هایی به کاربر (مانند عبارت if) است که تشخیص می‌دهد که آیا مستطیل در واقع مربع است یا خیر. از آن‌جایی که رفتار کاربر به انواعی که استفاده می‌کند بستگی دارد، آن انواع قابل جایگزینی نیستند. (یعنی در عمل ارث‌بری این دو کلاس از همدیگر اشتباه بوده و باید دو کلاس جدا می‌شدند)همانطور که در بخش‌های قبلی نشان داده شد، LSP را معمولا راهی برای هدایت استفاده از وراثت می‌دانند. با این حال، LSP یک اصل گسترده‌تر در سطح معماری نرم‌افزار می‌باشد که به رابط‌ها و پیاده‌سازی‌ها مربوط می‌شود. رابط های مورد بحث می‌توانند اشکال مختلفی داشته باشند:رابطی (interface) به سبک جاوا که توسط چندین کلاس پیاده‌سازی شده است.چندین کلاس Ruby یا Go که امضاهای متد (method signature) یکسانی دارند.مجموعه‌ای از خدمات که همه از طریق یک رابط REST یکسان پاسخ می‌دهند.در تمام موقعیت‌های بالا و موارد دیگر، LSP قابل استفاده است. یک نقض ساده قابلیت جایگزینی، می‌تواند باعث شود که معماری سیستم با مقدار قابل توجهی از مکانیسم‌های اضافی آلوده شود.اصل جداسازی رابط‌ها (Interface Segregation Principle)این اصل به طراحان نرم‌افزار توصیه می‌کند که از وابستگی به چیزهایی که استفاده نمی‌کنند اجتناب کنند. وابستگی به ماژول‌هایی که حاوی بیش از نیاز شما هستند مضر است. این بدیهی است که برای وابستگی‌های کد (source code) می‌توانند کامپایل‌های غیرضروری و جابجایی مجدد را ایجاد کند. اما در سطح معماری نیز این اصل ضروری و مهم است و عدم رعایت آن منجر به همین مشکلات می‌شود.به عنوان مثال، یک معمار را در نظر بگیرید که روی یک سیستم (S) کار می‌کند، او می‌خواهد یک چارچوب خاص (F) را ا در سیستم بگنجاند. حال فرض کنید که نویسندگان F آن را به یک پایگاه داده خاص (D)، متصل کرده‌اند. بنابراین S به F بستگی دارد که به D بستگی دارد. حال فرض کنید که D دارای ویژگی‌هایی است که F از آن‌ها استفاده نمی‌کند و بنابراین S به آن‌ها اهمیت نمی‌دهد. تغییرات در آن ویژگی‌ها (یعنی تغییر در D) ممکن است به‌خوبی باعث جابجایی مجدد F و بنابراین، استقرار مجدد S شود. حتی بدتر از آن، خرابی یکی از ویژگی‌های درون D ممکن است باعث خرابی در F و S شود. مشکل از آن‌جایی ایجاد شد که سامانه S به کلیه‌ی ویژگی‌های F نیاز نداشت اما تصمیم گرفت به آن وابسته شود. درسی که در اینجا وجود دارد این است که اگر چمدانی را حمل می‌کنید که در آن اشیایی است که به آن نیاز ندارید، می تواند مشکلاتی را برای شما ایجاد کند که انتظارش را نداشتید. اصل وارونگی وابستگی‌ها (Dependency Inversion Principle)کدی که سیاست‌های سطح بالا را پیاده‌سازی می‌کند نباید به کدی که جزئیات سطح پایین را پیاده‌سازی می‌کند بستگی داشته باشد. در عوض، جزئیات باید به سیاست‌ها بستگی داشته باشد.اصل وارونگی وابستگی (DIP) بیان می‌کند که انعطاف‌پذیرترین سیستم‌ها، آن‌هایی هستند که در آن وابستگی‌های کد فقط به انتزاع‌ها (abstractions) اشاره می‌کنند، نه به موارد پیاده‌سازی (concretions).واضح است که در نظر گرفتن این ایده در حالت کلی و به صورت صد درصد غیر ممکن است، زیرا سیستم‌های نرم‌افزاری باید به بسیاری از امکانات ملموس وابسته باشند. به عنوان مثال، کلاس String در جاوا عینی است و این بی معنی است که سعی کنیم آن را انتزاعی کنیم. نمی‌توان و نباید از وابستگی کد به String اجتناب کرد. کلاس String بسیار پایدار است و تغییرات آن بسیار نادر است و به شدت کنترل می‌شود. برنامه‌نویسان و معماران لازم نیست نگران تغییرات مکرر و هولناک String باشند.به این دلایل، وقتی صحبت از DIP به میان می‌آید، ما تمایل داریم که پس زمینه پایدار سیستم عامل و امکانات platform را نادیده بگیریم. ما آن وابستگی‌های ملموس را تحمل می‌کنیم زیرا می‌دانیم که می‌توانیم برای تغییر نکردن به آن‌ها تکیه کنیم.در عوض عناصری که ما تعریف می‌کنیم و سامانه را با آن توسعه می‌دهیم دارای یکسری عناصر فرار (volatile) هستند. ما دنبال این هستیم که از وابستگی به این موارد تا حد امکان اجتناب کنیم. این‌ها ماژول‌هایی هستند که ما به طور فعال در حال توسعه آن‌ها هستیم و در حال تغییر مکرر هستند.هر تغییر در یک رابط انتزاعی (interface) با تغییری در پیاده‌سازی‌های عینی آن (implementation) همراه است. برعکس، تغییرات در پیاده‌سازی‌های همیشه و یا حتی معمولا به تغییراتی در رابط‌هایی که پیاده‌سازی می‌کنند نیاز ندارند. بنابراین واسط‌ها نسبت به پیاده‌سازی‌ها کمتر تغییر می‌کنند. در واقع، طراحان و معماران نرم‌افزار خوب سخت تلاش می‌کنند تا نوسان تغییرات رابط‌ها را کاهش دهند. آن‌ها سعی می‌کنند راه‌هایی را برای اضافه‌کردن عملکرد به پیاده‌سازی‌ها استفاده کنند به گونه‌ای که تغییراتی در رابط‌ها ایجاد نشود.بنابراین، مفهوم این است که معماری‌های نرم‌افزاری پایدار آن‌هایی هستند که از وابستگی به ترکیبات تغییر‌کننده زیاد اجتناب می‌کنند و از رابط‌های انتزاعی پایدار استفاده می‌کنند. این مفهوم به مجموعه‌ای از شیوه‌های زیر خلاصه می‌شود:به کلاس‌های پیاده‌سازی فرار (volatile concrete) ارجاع ندهید. به جای آن به رابط‌های انتزاعی مراجعه کنید. این قانون در همه زبان‌ها، اعمال می‌شود. معمولا عمل به این قاعده محدودیت‌های شدیدی را برای ایجاد اشیا ایجاد می‌کند و به همین دلیل معمولا همراه Abstract Factories اعمال می‌شود.عملکرد کلاس‌های پیاده‌سازی (concrete) را با ارث‌بری جایگزین (override) نکنید. توابع این کلاس‌ها اغلب به وابستگی کد منبع نیاز دارند. وقتی آن توابع را جایگزین می‌کنید، آن وابستگی‌ها را حذف نمی‌شوند (dependencies)، در واقع آن‌ها را به ارث می‌برید. برای مدیریت آن وابستگی‌ها، باید تابع موردنظر را انتزاعی کنید و چندین پیاده‌سازی ایجاد کنید که هر کدام آن تابع را مطابق با نیاز شما پیاده‌سازی کنند.بخش چهارم (اصول کامپوننت‌ها)اگر اصول SOLID به ما می‌گوید که چگونه آجرها را در دیوارها و اتاق‌ها چیدمان کنیم، اصول کامپوننت به ما می‌گوید که چگونه اتاق‌ها را در ساختمان‌ها چیدمان کنیم. سیستم‌های نرم‌افزاری بزرگ، مانند ساختمان‌های بزرگ، از اجزای کوچک‌تر ساخته شده‌اند. در این بخش عمو باب در مورد اینکه چه اجزای نرم‌افزاری هستند، چه عناصری باید آن‌ها را تشکیل دهند و چگونه باید با هم در سیستم‌ها ترکیب شوند، بحث می‌کند.تعریف کامپوننتبیش از شروع به صحبت‌کردن در مورد کامپوننت‌ها لازم است ابتدا تعریف کامپوننت‌ها را بفهمیم. کامپوننت یا اجزاء واحدهای استقرار هستند. آن‌ها کوچکترین موجوداتی هستند که می‌توانند به عنوان بخشی از یک سیستم مستقر شوند. در جاوا، آن‌ها فایل‌های jar هستند. در Ruby، آن‌ها فایل‌های gem هستند. در Net، آن‌ها DLL هستند. در زبان‌های کامپایل شده، آن‌ها انبوهی از فایل‌های باینری هستند. در زبان‌های تفسیر شده، آن‌ها مجموعه‌ای از فایل‌های کد هستند. در همه زبان‌ها، کامپوننت‌ها اجزایی هستند که استقرار می‌یابند.کامپوننت‌ها را می‌توان به یک فایل اجرایی متصل کرد یا می‌توان آن‌ها را با هم در یک آرشیو واحد، مانند یک فایل war جمع کرد یا می‌توان آن‌ها را به‌صورت مستقل به‌عنوان افزونه‌هایی مانند فایل‌های jar یا dll یا exe مستقر کرد. صرف نظر از نحوه استقرار آن‌ها در نهایت، اجزای خوب طراحی شده همیشه این توانایی را حفظ می‌کنند که به طور مستقل قابل استقرار و بنابراین به طور مستقل قابل توسعه باشند.انسجام کامپوننت‌ها (component cohesion)کدام کلاس ها در کدام کامپوننت قرار می‌گیرند؟ معیار انتساب یک کلاس به یک کامپوننت چیست؟ این یک تصمیم مهم است و نیاز به راهنمایی از اصول مهندسی نرم افزار خوب دارد. متأسفانه، در طول سال‌ها، این تصمیم به‌صورت موقتی و تقریبا کاملا بر اساس زمینه و موضوع اتخاذ شده است. در این بخش سه اصل انسجام اجزا را مورد بحث قرار خواهیم داد:اصل هم‌ارزی استفاده مجدد/انتشار (Reuse/Release Equivalence Principle) (REP)اصل بسته‌بندی مفاهیم مرتبط (Common Closure Principle) (CCP)اصل استفاده مجدد از مشترک‌ها (Common Reuse Principle) (CRP)در ادامه به صورت خلاصه با هر کدام از این مفاهیم آشنا می‌شویم و نکاتی را در مورد هر یک از آن‌ها و ارتباط آن‌ها با موضوع انسجام کامپوننت‌ها بیان می‌کنیم.اصل هم‌ارزی استفاده مجدد/انتشار (Reuse/Release Equivalence Principle)در دهه‌های گذشته شاهد ظهور مجموعه‌ای از ابزارهای مدیریت ماژول مانند Maven یا Leiningen و RVM بوده‌ایم. اهمیت این ابزارها در طول زمان افزایش یافته است و تعداد زیادی از اجزای قابل استفاده مجدد و کتابخانه‌ها ایجاد شده است. ما اکنون در عصر استفاده مجدد از نرم‌افزار زندگی می کنیم. اصل هم ارزی استفاده مجدد/انتشار (REP) یک اصل است که حداقل در ظاهر بدیهی به نظر می‌رسد: افرادی که می‌خواهند از یک کتابخانه نرم‌افزاری استفاده مجدد کنند، نمی‌توانند و نمی‌خواهند این کار را انجام دهند، مگر اینکه این مؤلفه‌ها از طریق فرآیند انتشار (release) ردیابی شوند و شماره انتشار به آن‌ها داده شود.وجود اعداد انتشار (release version) به این دلیل است که بدون وجود آن‌ها هیچ راهی برای اطمینان از سازگاری همه کتابخانه‌های استفاده‌شده با یکدیگر وجود نخواهد داشت. به عبارتی این نشان‌دهنده این واقعیت است که توسعه‌دهندگان نرم‌افزار باید بدانند چه زمانی نسخه‌های جدید عرضه می‌شوند و این نسخه‌های جدید چه تغییراتی را به همراه خواهند داشت.غیرمعمول نیست که توسعه‌دهندگان در مورد یک نسخه جدید بر اساس اطلاعیه‌های سازنده خبردار شوند و بر اساس تغییرات ایجاد شده در آن نسخه، تصمیم بگیرند که به جای آن از نسخه قدیمی استفاده کنند. بنابراین فرآیند انتشار باید اعلان‌ها و اسناد انتشار مناسب را ارائه کند تا کاربران بتوانند درباره زمان و اینکه آیا نسخه جدید را استفاده کنند یا نه، تصمیم‌گیری آگاهانه بگیرند.از دیدگاه طراحی و معماری نرم‌افزار، این اصل به این معنی است که کلاس‌ها و ماژول‌هایی که به صورت یک جزء تشکیل می‌شوند باید به یک گروه منسجم تعلق داشته باشند. کامپوننت نمی‌تواند به سادگی از مجموعه‌ای تصادفی از کلاس‌ها و ماژول‌ها تشکیل شود. در عوض، باید یک موضوع یا هدف کلی وجود داشته باشد که همه آن ماژول ها به اشتراک بگذارند.کلاس ها و ماژول‌هایی که با هم در یک کامپوننت گروه‌بندی می‌شوند باید با هم قابل انتشار باشند. این واقعیت که آن‌ها شماره نسخه یکسان و انتشار یکسانی را به اشتراک می‌گذارند و در اسناد انتشار یکسان گنجانده شده‌اند، هم برای نویسنده و هم برای کاربران باید منطقی باشد.اصل بسته‌بندی مفاهیم مرتبط (Common Closure Principle)آن دسته از کلاس‌هایی را که به دلایل مشابه و در زمان‌های مشابه تغییر می‌کنند، در کامپوننت جمع‌آوری کنید. کلاس‌هایی که در زمان‌های مختلف و به دلایل مختلف تغییر می‌کنند را به عنوان کامپوننت‌های مختلف جدا کنید.اگر تعریف بالا را نگاه کنیم، این تعریف تا حد خوبی آشنا به نظر می‌آید. این همان اصل مسئولیت واحد است که قبلا آن را در سطح کد و کلاس‌ها مشاهده کرده بودیم اما اکنون مجددا آن را برای کامپوننت‌هاها بیان کرده‌ایم. همانطور که SRP بیان می‌کند که یک کلاس نباید چندین دلیل برای تغییر داشته باشد، اصل بسته‌بندی مفاهیم مرتبط (CCP) نیز بیان می‌کند که یک کامپوننت نباید چندین دلیل برای تغییر داشته باشد.برای اکثر سامانه‌های نرم‌افزاری، قابلیت نگهداری مستمر سامانه مهمتر از قابلیت استفاده مجدد از یکسری توابع و مفاهیم می‌باشد. اگر کد در یک بخش از سامانه باید تغییر کند، ترجیح می‌دهیم که همه تغییراتی که باید انجام شوند در یک کامپوننت رخ دهند، نه اینکه در بسیاری از بخش‌های مختلف سامانه که مربوط به کامپوننت‌های مختلف هستند توزیع شود. سایر کامپوننت‌هایی که به کامپوننت تغییریافته وابسته نیستند، نیازی به تست‌شدن دوباره یا استقرار مجدد در محیط عملیاتی ندارند.این قاعده در واقعیت بیان می‌کند که تمام کلاس‌هایی را که احتمالا به دلایل مشابه تغییر می‌کنند در یک مکان جمع‌آوری کنید. اگر دو کلاس، چه از نظر فیزیکی و چه از نظر مفهومی، آن قدر محکم به هم متصل شده باشند که همیشه با هم تغییر کنند، آن‌گاه به یک کامپوننت تعلق دارند. در صورت پایبند بودن به این اصل و قاعده، حجم کارهایی از جمله انتشار، اعتبارسنجی مجدد و استقرار مجدد نرم‌افزار کاهش پیدا خواهد کرد.اصل استفاده مجدد از مشترک‌ها (Common Reuse Principle) این اصلا به ما کمک می‌کند مشخص کنیم کدام کلاس‌ها و ماژول‌ها باید در یک کامپوننت قرار گیرند. به عبارتی کلاس‌ها و ماژول‌هایی که در هنگام استفاده‌ی مجدد با هم دیگر استفاده می‌شوند، متعلق به یک کامپوننت هستند.کاربران یک کامپوننت را مجبور نکنید به چیزهایی که نیاز ندارند وابسته شوند.کلاس‌ها به ندرت به صورت جداگانه مورد استفاده مجدد قرار می‌گیرند. به طور معمول، کلاس‌های قابل استفاده مجدد با کلاس‌های دیگری که بخشی از یک انتزاع یا مفهوم هستند، همکاری می‌کنند. این اصل بیان می‌کند که این کلاس‌ها به هم تعلق دارند و یک کامپوننت را تشکیل می‌دهند. در چنین کامپوننتی انتظار داریم کلاس‌هایی را ببینیم که وابستگی‌های زیادی به یکدیگر دارند.اما این اصل نکته‌ی مهم دیگری را نیز بیان می‌کند. این اصل بیشتر از این‌که کدام کلاس‌ها را در یک کامپوننت کنار هم قرار دهیم، بیان می‌کند کدام کلاس‌ها را در یک کامپوننت با هم نگه‌داریم. هنگامی که یک بخش از برنامه از بخش دیگری استفاده می‌کند، یک وابستگی بین بخش‌ها ایجاد می‌شود. شاید کامپوننت استفاده کننده فقط از یک کلاس در کامپوننت استفاده شده استفاده کند اما این هنوز وابستگی را ضعیف نمی‌کند. کامپوننت استفاده کننده همچنان به بخش استفاده شده بستگی دارد. به دلیل این وابستگی، هر بار که مولفه مورد استفاده تغییر می‌کند، مولفه استفاده‌کننده احتمالا به تغییرات مربوطه نیاز خواهد داشت. حتی اگر هیچ تغییری در کامپوننت استفاده‌کننده لازم نباشد، احتمالا همچنان نیاز به کامپایل مجدد، تست مجدد و استقرار مجدد خواهد داشت. این قاعده کاملا بدیهی است حتی اگر کامپوننت استفاده کننده به تغییر ایجاد شده در کامپوننت استفاده شده اهمیتی ندهد. بنابراین وقتی به یک بخش وابسته می‌شویم، می‌خواهیم مطمئن شویم که به هر کلاس در آن بخش وابسته هستیم. به عبارت دیگر، ما می‌خواهیم مطمئن شویم که کلاس‌هایی که در یک کامپوننت قرار می‌دهیم، جدایی‌ناپذیر هستند به صورتی که غیرممکن است به برخی وابسته باشیم و به برخی وابسته نشویم. در غیر این صورت، ما بیش از آنچه لازم است اجزای سازنده را دوباره مستقر خواهیم کرد و زمان قابل توجهی را هدر خواهیم داد. بنابراین CRP بیشتر بیان می‌کند که کدام کلاس‌ها نباید با هم باشند تا اینکه کدام کلاس‌ها باید با هم باشند. کلاس‌هایی که محکم به یکدیگر متصل نیستند نباید در یک کامپوننت باشند.طبق توضیحات بالا، CRP نسخه عمومی‌تر قاعده ISP است که در بخش‌های قبلی مشاهده کردیم. ISP بیان می‌کند که به کلاس‌هایی وابسته نباشیم که بخش‌هایی دارند که ما استفاده نمی‌کنیم. CRP به ما توصیه می‌کند به کامپوننت‌هایی که کلاس‌هایی دارند که ما استفاده نمی‌کنیم وابسته نباشیم. به چیزهایی که نیاز ندارید وابسته نباشید.نمودار تنش برای انسجام کامپوننت‌هااگر مطالب مربوط به سه اصل انسجام را بار دیگری مطالعه کنید، می‌بینید که سه اصل انسجام به مبارزه با یکدیگر تمایل دارند. REP و CCP اصولی فراگیر هستند و هر دو تمایل دارند کامپوننت‌ها را بزرگتر کنند. CRP یک اصل انحصاری است که باعث کوچکتر شدن کامپوننت‌ها می‌شود. این یک تنش بین این اصول است که معماران خوب به دنبال حل آن هستند. شکل زیر نمودار کششی است که نحوه تعامل سه اصل انسجام با یکدیگر را نشان می‌دهد. لبه‌های نمودار هزینه کنار گذاشتن اصل در راس مخالف را توضیح می‌دهد.به عنوان مثال طبق نمودار بالا معماری كه فقط بر روی REP و CRP تمركز می‌كند، متوجه می‌شود كه هنگام ايجاد تغييرات ساده، اجزای زيادی تحت تاثير قرار می‌گیرند. در مقابل، معماری كه به شدت بر CCP و REP تمركز می‌كند، باعث می‌شود كه تعداد زيادی نسخه‌های غیرضروری تولید شود.یک معمار خوب تلاش می‌کند که دغدغه‌های فعلی تیم توسعه را برآورده بکند، اما همچنین آگاه است که این نگرانی‌ها در طول زمان تغییر خواهند کرد. به عنوان مثال، در اوایل توسعه یک پروژه، CCP بسیار مهمتر از REP است، زیرا توسعه‌پذیری مهمتر از استفاده مجدد است.به طور کلی، پروژه‌ها تمایل دارند از سمت راست مثلث شروع شوند، جایی که تنها قربانی استفاده مجدد است. همان‌طور که پروژه توسعه داده می‌شود و پروژه‌های دیگر شروع به استخراج از آن می‌کنند، پروژه به سمت چپ می‌لغزد و بحث قرار گرفتن مفاهیم مشترک در کنار هم اهمیت پیدا می‌کند. این بدان معنی است که ساختار اجزای یک پروژه می‌تواند با زمان و بلوغ متفاوت باشد. این بیشتر به نحوه توسعه و استفاده از آن پروژه مربوط می‌شود تا به آنچه که پروژه در واقع انجام می‌دهد.جفت‌شدن کامپوننت‌ها (component coupling)در این بخش از کتاب عمو باب شروع به صحبت‌کردن در مورد ارتباط بین کامپوننت‌ها و نحوه‌ی تعامل آن‌ها می‌پردازد. در این بخش نیز 3 اصل مهم در رابطه با ارتباط میان کامپوننت‌ها اشاره می‌شود:اصل وابستگی‌های غیر چرخشی (Acyclic Dependencies Principle)اصل وابستگی‌های پایدار (Stable Dependencies Principle)اصل انتزاعات پایدار (Stable Abstractions Principle)اصل وابستگی‌های غیر چرخشی (Acyclic Dependencies Principle)آیا تا به حال شده است که تمام روز کار کنید، چیزهایی را به کار بگیرید و سپس تا صبح روز بعد به خانه بروید. صبح روز بعد وقتی می‌رسید متوجه شوید که تغییرات شما دیگر کار نمی‌کند و خطاهای عجیبی را مشاهده کنید؟ بعد بررسی‌های فراوان مشخص می‌شود که کسی دیرتر از شما به خانه رفته است و تغییراتی را بر روی چیزهایی که شما به آن‌ها وابسته بودید اعمال کرده است که باعث شده مولفه‌ی شما دچار مشکل شود! این اتفاقات در محیط‌های توسعه رخ می‌دهد که در آن بسیاری از توسعه‌دهندگان در حال تغییر فایل‌های مشابه یا وابسته به هم هستند. در پروژه‌های نسبتا کوچک با چند توسعه‌دهنده، مشکل خیلی بزرگی نیست اما با افزایش اندازه پروژه و تیم توسعه، صبح‌های بعد می‌تواند بسیار ترسناک باشند. این غیر معمول نیست که هفته‌ها بدون اینکه تیم قادر به ساخت یک نسخه پایدار از پروژه باشد، بگذرد و همه در تلاش باشند که تغییرات خود را با آخرین تغییراتی که شخص دیگری انجام داده، سازگار کنند. در طول چند دهه گذشته، دو راه حل برای این مشکل تکامل یافته است. پیشنهاد اولا معمولا «تولید هفتگی» است و دومی اصل وابستگی‌های غیر چرخشی (ADP) است.تولید هفتگی (Weekly Build)ساخت هفتگی قبلاً در پروژه‌های متوسط رایج بود. این کار به این صورت بود که همه‌ی توسعه‌دهندگان در چهار روز اول هفته یکدیگر را نادیده می‌گیرند و همه آن‌ها روی کپی‌های خصوصی کد خود کار می کنند و نگران ادغام کارشان به صورت جمعی نیستند. سپس، در روز جمعه، آن‌ها همه تغییرات خود را یکپارچه می‌کنند و سامانه را مطابق با تغییرات یکدیگر تجمیع و آماده می‌سازند.این رویکرد دارای مزیت شگفت‌انگیزی است که به توسعه‌دهندگان اجازه می‌دهد تا چهار روز از پنج روز هفته را در یک دنیای منزوی زندگی کنند. بدیهی است که ضرر آن هزینه‌ای خواهد بود که در روز ادغام این تغییرات باید پرداخت. متأسفانه، با رشد پروژه، تکمیل پروژه در انتهای هفته کمتر امکان‌پذیر می‌شود. بار ادغام تغییرات معمولا تا ابتدای هفته‌ی بعد کشیده می‌شود. به همین دلیل کم کم توسعه دهندگان قانوع می‌شوند که ادغام باید از روز پنجشنبه آغاز شود تا زودتر و همان انتهای هفته به پایان برسد.بنابراین شروع ادغام به آرامی به سمت وسط هفته پیش می‌رود.با کاهش تعداد روزهای باقی‌مانده برای توسعه‌دهندگان در مقابل زمان عظیم ادغام تغییرات، کارایی تیم کاهش می‌یابد. در نهایت این وضعیت به قدری ناامیدکننده می‌شود که توسعه‌دهندگان یا مدیران پروژه اعلام می‌کنند که برنامه باید به یک تولید هر دو هفته‌ای تغییر دهند. این برای مدتی کافی است، اما زمان ادغام با اندازه پروژه به رشد خود ادامه می‌دهد و به احتمال زیاد این کافی نخواهد بود!در نهایت، این سناریو به یک بحران منجر می‌شود. برای حفظ بهر‌ه‌وری، برنامه زمان‌بندی تولید باید به طور مداوم طولانی شود اما طولانی‌شدن زمان‌بندی تولید، خطرات پروژه را افزایش می‌دهد. انجام یکپارچه‌سازی و آزمایش به‌طور فزاینده‌ای سخت تر می‌شود و تیم مزیت بازخورد سریع را از دست می‌دهد. به همین دلیل معمولا امروزه این روش کاربرد ندارد و به جای آن با توجه به پیشنهاد ابتدای مطلب، از روش دیگری استفاده می‌شود.راه حل این مشکل این است که محیط توسعه را به کامپوننت‌های قابل انتشار تقسیم کنیم. کامپوننت‌ها تبدیل به واحدهای کاری می‌شوند که می‌توانند تحت مدیریت یک توسعه‌دهنده یا تیمی از توسعه‌دهندگان باشد. هنگامی که توسعه‌دهندگان یک کامپوننت‌ها را تغییر می‌دهند، آن را برای استفاده توسط توسعه‌دهندگان دیگر منتشر می‌کنند و برای آن نسخه‌ی انتشاری را مشخص می‌کنند و آن را به فهرستی منتقل می‌کنند تا سایر تیم‌ها از آن استفاده کنند. آن‌ها سپس به اصلاح کامپوننت‌ خود در مناطق خصوصی خود ادامه می‌دهند و بقیه در صورت نیاز از نسخه منتشر شده استفاده می‌کنند.از آن‌جایی که نسخه‌های جدید یک کامپوننت‌ در دسترس قرار می‌گیرد، تیم‌های دیگر می‌توانند تصمیم بگیرند که آیا نسخه جدید را فورا استفاده کنند یا خیر. اگر آن‌ها تصمیم بگیرند که فعلا زمان مناسبی برای استفاده از نسخه‌ی جدید نیست، به سادگی به استفاده از نسخه قدیمی ادامه می‌دهند. هنگامی که آن‌ها تصمیم گرفتند که آماده هستند، شروع به استفاده از نسخه جدید می‌کنند.بنابراین هیچ تیمی در اختیار دیگران نیست. تغییرات ایجادشده در یک کامپوننت نیازی به تأثیر فوری بر سایر تیم‌ها ندارد. هر تیمی می‌تواند خودش تصمیم بگیرد که چه زمانی کامپوننت‌های خودش را با نسخه‌های جدید دیگران تطبیق دهد. علاوه بر این، ادغام در گام‌های کوچک و به صورت دقیق و تست‌شده می‌تواند اتفاق بیافتد. هیچ نقطه‌ای از زمان وجود ندارد که همه توسعه‌دهندگان باید دور هم جمع شوند و هر کاری را که انجام می‌دهند یکپارچه کنند. (اگر چه در می‌توانند به تصمیم خود در برخی مواقع این کار را انجام دهند ولی اجباری نیست)این یک فرآیند بسیار ساده و منطقی است و به طور گسترده‌ای مورد استفاده قرار می‌گیرد. اما برای اینکه آن را با موفقیت انجام دهیم و امکان آن از نظر عملیاتی ممکن باشد، باید ساختار وابستگی اجزا را مدیریت کرد. هیچ چرخه‌ای نمی‌تواند در گراف وابستگی‌ها وجود داشته باشد وگرنه این کار ممکن نیست.حذف وابستگی‌های چرخه‌ایمعمولا گراف وابستگی‌هایبین کامپوننت‌ها به صورت یک گراف بدون حلقه جهت‌دار (DAG) می‌باشد. صرف‌نظر از اینکه از کدام کامپوننت‌ شروع کنیم، غیرممکن است که روابط وابستگی را دنبال کنیم و به آن کامپوننت بازگردیم. این ساختار هیچ چرخه‌ای ندارد.وجود حلقه در این گراف مشکلاتی را به همراه خواهد داشت. ساده‌ترین مورد که می‌توان به آن اشاره نمود، پیچدگی و حتی عدم امکان نسخه‌دهی می‌باشد. اگر فرض کنیم حلقه‌ای از وابستگی‌ها در گراف وجود داشته باشد، در آن صورت در صورتی که یکی از اجزای این حلقه تغییر کند، به دلیل تغییر آن باید وابسته‌های آن و وابسته‌های وابسته‌ی آن و ... همه بروزرسانی شوند. اما انتهای این فرآیند همان مولفه‌ی اول است و این به نوعی در عمل ممکن است. انگار برای این که یک مولفه را بسازیم باید خودش را از قبل ساخته باشیم! در عمل این حلقه باعث می‌شود که تمامی موارد درون حلقه همگی یک کامپوننت بزرگ محسوب شوند به صورتی که همه با هم نسخه‌ی جدیدشان منتشر می‌شود. این مشکل جدای از بحث چگونگی تست‌کردن و استقرار مولفه‌ها می‌باشد.در ادامه با دو اصل دیگر در زمینه‌ی ارتباط بین مولفه‌ها آشنا می‌شویم. هر دوی این اصول فرض می‌کنند که اصل وابستگی‌های غیرچرخه‌ای رعایت شده است در غیر این صورت بیان این اصولدر عمل ممکن نخواهد بود. اصل وابستگی‌های پایدار (Stable Dependencies Principle)طرح‌ها و معماری‌ها نمی‌توانند کاملا ثابت باشند. اگر قرار است طرح و معماری حفظ شود، مقداری نوسان لازم است. (چون نیازمندی‌ها از سمت مشتری تغییر می‌کند) با انطباق با اصل CCP که در بخش‌های قبلی دیدیم، باید تلاش کنیم که اجزایی ایجاد کنیم که نسبت به انواع خاصی از تغییرات حساس هستند، اما نسبت به سایر تغییرات مصون هستند. برخی از این کامپوننت‌ها به گونه‌ای طراحی می‌شوند که فرار (volatile) باشند. ما انتظار داریم آن‌ها تغییر کنند و هر مؤلفه‌ای که انتظار داریم بی‌ثبات باشد، نباید به مؤلفه‌ای وابسته باشد که تغییر آن دشوار است. در غیر این صورت، تغییر آن بخش غیرثابت نیز دشوار خواهد بود.ماژولی را که شما طراحی کرده‌اید تا به راحتی قابل تغییر باشد، می‌تواند توسط شخص دیگری مورد استفاده قرار بگیرد و تغییر آن را دشوار کند. هیچ خطی از کد منبع در ماژول شما نیاز به تغییر ندارد، اما تغییر ماژولی که به آن وابسته شدید، ناگهان چالش برانگیزتر می‌شود. با انطباق با اصل وابستگی‌های پایدار (SDP)، اطمینان حاصل می‌کنیم که ماژول‌هایی که برای تغییر آسان در نظر گرفته شده‌اند توسط ماژول‌هایی که تغییر آن‌ها سخت‌تر است استفاده نشوند.پیش از توضیح بیش‌تر در مورد این اصل، ابتدا لازم است تعریف پایداری را بدانیم. فرهنگ لغت وبستر می‌گوید که اگر چیزی «به راحتی جابه جا نشود» پایدار است. ثبات به میزان کار موردنیاز برای ایجاد تغییر مربوط می‌شود. یک پنی ایستاده پایدار نیست زیرا برای سرنگونی آن به کار بسیار کمی نیاز است. از طرف دیگر، یک میز بسیار پایدار است، زیرا برای برگرداندن آن به تلاش قابل توجهی نیاز است. با این حال وابستگی صفر و یک مطلق نیست بلکه مفهومی است که بین صفر تا یک قرار می‌گیرد.این موضوع چه ارتباطی با نرم‌افزار دارد؟ بسیاری از عوامل ممکن است تغییر یک کامپوننت نرم‌افزار را سخت کند به عنوان مثال، اندازه، پیچیدگی آن و ... عمو باب همه آن عوامل را نادیده می‌گیرید و در عوض روی مورد خاصی متمرکز می‌شود. اگر کامپوننت‌های فراوانی به یک کامپوننت وابسته شوند، در عمل تغییر آن کامپوننت بسیار سخت خواهد شد. یک کامپوننت‌ با وابستگی‌های ورودی زیاد بسیار پایدار است، زیرا برای هرگونه تغییری باید تمامی کامپوننت‌‌های وابسته به آن را در نظر بگیریم که به کار زیادی نیاز دارد.نمودار در شکل زیر را نشان می‌دهد که X یک کامپوننت‌‌ پایدار است. سه کامپوننت‌‌ به X بستگی دارند، بنابراین سه دلیل خوب برای تغییر نکردن آن وجود دارد. ما می‌گوییم که X مسئول آن سه کامپوننت‌‌ است. برعکس، X به هیچ چیز دیگری وابسته نیست بنابراین هیچ چیز تأثیر خارجی برای تغییر آن وجود ندارد و به همین دلیل ما می‌گوییم مستقل است.شکل زیر نشان می‌دهد که Y کامپوننت‌‌ بسیار ناپایدار است. هیچ کامپوننت‌‌ دیگری به Y وابسته نیست، بنابراین می‌گوییم که Y غیرمسئول در برابر دیگران است. Y همچنین دارای سه کامپوننت‌‌ است که به آن‌ها بستگی دارد، بنابراین تغییرات ممکن است از سه منبع خارجی باشد و به همین دلیل می‌گوییم Y وابسته است.متریک‌های پایداریچگونه می‌توانیم پایداری یک کامپوننت را اندازه‌گیری کنیم؟ یکی از راه‌ها این است که تعداد وابستگی‌هایی را که وارد و خارج می‌شوند، بشماریم. این شمارش‌ها به ما امکان می‌دهد تا ثبات موقعیتی کامپوننت را محاسبه کنیم. برای این منظور مفاهیم زیر را تعریف می‌کنیم:مفهوم Fan-in (وابستگی‌های ورودی): این متریک تعداد کلاس‌های خارج از این کامپوننت را که به کلاس‌های داخل کامپوننت بستگی دارد، مشخص می‌کند.مفهوم Fan-out (وابستگی‌های خروجی): این متریک تعداد کلاس‌های داخل این کامپوننت را که به کلاس‌های خارج از کامپوننت بستگی دارد، مشخص می‌کند.مفهوم I (ناپایداری): این مفهوم را بر اساس دو مفهوم بالا تعریف می‌کنیم. این مفهوم را می‌توان با فرمول زیر مدل نمود. این معیار دارای محدوده صفر تا یک است. I = 0 یک کامپوننت حداکثر پایداری را نشان می‌دهد. I = 1 یک کامپوننت حداکثر ناپایدار را نشان می‌دهد.I = Fan-out / (Fan-in + Fan-out)اکنون می‌توانیم اصل پایداری را یکبار دیگر دقیق‌تر بیان کنیم. SDP می‌گوید که متریک ناپایداری یک کامپوننت باید بزرگتر از متریک ناپایداری اجزایی باشد که به آن بستگی دارد. یعنی معیارهای ناپایداری باید در جهت وابستگی کاهش یابد.با این حال تمامی این کامپوننت‌ها نمی‌توانند همگی پایدار باشند. اگر تمام اجزای یک سیستم حداکثر پایدار باشند، سیستم غیرقابل تغییر خواهد بود. این وضعیت مطلوبی نیست. در واقع، ما می‌خواهیم ساختار اجزای خود را طوری طراحی کنیم که برخی از اجزا ناپایدار و برخی پایدار باشند. کامپوننت‌های قابل تغییر در بالای گراف وابستگی قرار دارند و به کامپوننت‌های پایدار در پایین بستگی دارند. قرار دادن اجزای ناپایدار در بالای نمودار یک قرارداد مفید است، زیرا در این صورت قاعده‌ی SDP نقض می‌شود. به صورت خلاصه این اصل را ربه صورت زیر خلاصه می‌کنیم:در جهت پایداری وابسته شوید.اصل انتزاعات پایدار (Stable Abstractions Principle)برخی از بخش‌های موجود در یک سامانه‌ی نرم‌افزاری نباید اغلب تغییر کنند. این موارد در واقعیت همان معماری سطح بالا و تصمیمات مربوط به سیاست‌ها هستند. ما نمی‌خواهیم این تصمیمات تجاری و معماری بی‌ثبات باشد. بنابراین نرم‌افزاری که سیاست‌های سطح بالای سیستم را در بر می‌گیرد باید در اجزای پایدار قرار گیرد (0 = I). مؤلفه‌های ناپایدار (I = 1) باید فقط شامل بخش‌هایی باشند که بی‌ثبات هستند، بخشی که می‌خواهیم بتوانیم سریع و آسان آن‌ها را تغییر دهیم. با این حال، اگر سیاست‌های سطح بالا در کامپوننت‌های پایدار قرار داده شوند، تغییر کد منبعی که آن سیاست‌ها را نشان می‌دهد دشوار خواهد بود. این می‌تواند معماری کلی را غیرقابل انعطاف کند.چگونه یک کامپوننت که حداکثر پایدار است (I = 0) می‌تواند به اندازه کافی انعطاف‌پذیر باشد تا در برابر تغییراتی که از سمت مشتری ایجاد می‌شود مقاومت کند؟ پاسخ در اصل OCP یافت می‌شود در بخش‌های قبلی توضیح دادیم. این اصل به ما می‌گوید که مطلوب است که کلاس‌هایی ایجاد کنیم که به اندازه کافی انعطاف‌پذیر باشند تا بدون نیاز به اصلاح، گسترش یابند. کلاس‌های انتزاعی با این اصل مطابقت دارند.اصل انتزاع پایدار (SAP) رابطه‌ای بین ثبات و انتزاع ایجاد می‌کند. از یک طرف می‌گوید یک کامپوننت پایدار نیز باید انتزاعی باشد تا پایداری آن مانع از گسترش آن نشود. از سوی دیگر، می‌گوید که یک بخش ناپایدار باید عینی باشد، زیرا ناپایداری آن اجازه می‌دهد تا کد درون آن به راحتی تغییر یابد.قاعده SDP می گوید که وابستگی‌ها باید در جهت ثبات حرکت کنند و SAP می‌گوید که ثبات به معنای انتزاع است. بنابراین وابستگی‌ها در جهت انتزاع حرکت می‌کنند.اندازه‌گیری انتزاعمتریک A معیاری برای انتزاع‌بودن یک کامپوننت است. مقدار آن صرفا نسبت رابط‌ها و کلاس‌های انتزاعی در یک کامپوننت به تعداد کل کلاس‌های کامپوننت است.متریک Nc: تعداد کلاس‌های کامپوننت.متریک Na: تعداد کلاس‌ها و رابط‌های انتزاعی در کامپوننت.متریک انتزاع: نسبت بین Na به Nc می‌باشد. متریک A از 0 تا 1 متغیر است. مقدار 0 به این معنی است که کامپوننت هیچ کلاس انتزاعی ندارد. مقدار 1 به این معنی است که کامپوننت چیزی جز کلاس‌های انتزاعی ندارد.دنباله‌ی اصلی (Main Sequence)در ادامه خوب است که رابطه بین ناپایداری (I) و انتزاع (A) را تعریف کنیم و مورد بررسی قرار دهیم. برای انجام این کار، یک نمودار با A در محور عمودی و I در محور افقی ایجاد می‌کنیم. اگر دو نوع کامپوننت «خوب» را در این نمودار رسم کنیم، کامپوننت‌هایی را خواهیم یافت که حداکثر پایداری و انتزاعی را در بالا سمت چپ در (0، 1) دارند. اجزایی که حداکثر ناپایدار و عینی هستند در پایین سمت راست در (1، 0) قرار دارند.همه کامپوننت‌ها در یکی از این دو موقعیت قرار نمی‌گیرند، زیرا کامپوننت‌‌ها اغلب دارای درجاتی از انتزاع و ثبات هستند. برای مثال، بسیار رایج است که یک کلاس انتزاعی از کلاس انتزاعی دیگر مشتق شود. مشتق انتزاعی است که وابستگی دارد. بنابراین، اگرچه حداکثر انتزاعی است، اما حداکثر پایدار نخواهد بود. وابستگی آن باعث کاهش ثبات آن می‌شود.از آن‌جایی که نمی‌توانیم قاعده‌ای را اعمال کنیم که همه مؤلفه‌ها در (0، 1) یا (1، 0) قرار گیرند، باید فرض کنیم که یک مکان از نقاط در نمودار A/I وجود دارد که موقعیت‌های معقولی را برای کامپوننت‌‌ها تعریف می‌کند. این بخش معمولا همین خط میانه‌ی نمودار هست که از آن به عنوان دنباله‌ی اصلی یاد می‌شود. با این حال وقتی این ناحیه‌ی میانی را در نظر می‌گیریم یکسری ناحیه‌ی دیگر هم در نمودار ظاهر می‌شوند. این ناحیه‌ها، نواحی هستند که تا حد امکان باید از قرارگیری مولفه‌ها در آن جلوگیری شود. در ادامه این نواحی را موردبررسی قرار می‌دهیم.ناحیه‌ی درد (Zone Of Pain)مولفه‌ای را در ناحیه‌ی اطراف (0، 0) در نظر بگیرید. این یک کامپوننت بسیار پایدار و در عین حال عینی (غیرانتزاعی) است. چنین کامپوننتی مطلوب نیست زیرا تغییر آن سخت است. نمی‌توان آن را گسترش داد زیرا انتزاعی نیست و تغییر آن به دلیل وابستگی‌های بسیار دیگران به آن دشوار است. بنابراین ما معمولاً انتظار نداریم که کامپوننت‌های خوب طراحی شده را در نزدیکی (0، 0) نبینیم. ناحیه اطراف (0، 0) ناحیه طرد شده به نام ناحیه‌ی درد است.با این حال برخی از موجودیت‌های نرم‌افزاری در واقع در منطقه درد قرار می‌گیرند. یک مثال می‌تواند یک ساختار داده‌ها در پایگاه داده باشد. ساختارهای داده‌ی پایگاه داده بسیار بی‌ثبات، ملموس و به شدت وابسته هستند. این خود از دلایلی است که چرا مدیریت رابط بین برنامه‌های کاربردی شی‌گرا و پایگاه‌های داده بسیار دشوار است و به‌روزرسانی‌های ساختارهای داده عموما دردناک هستند. نمونه دیگری از نرم‌افزارهایی که در این ناحیه قرار دارند، کتابخانه خود ابزارها مثل String است. اجزای ثبات‌دار در ناحیه (0، 0) بی ضرر هستند زیرا احتمال تغییر آن‌ها وجود ندارد. هرچه یک کامپوننت در ناحیه درد احتمال تغییرش بیش‌تر باشد، «دردناک‌تر» است.ناحیه‌ی بی‌فایدگی (Zone of Uselessness)یک کامپوننت نزدیک (1، 1) را در نظر بگیرید. این مکان نامطلوب است زیرا حداکثر انتزاعی است، اما هیچ وابسته‌ای ندارد. چنین اجزایی بی‌فایده هستند. بنابراین این منطقه را منطقه بی‌فایده می‌نامند. موجودات نرم‌افزاری که در این منطقه زندگی می‌کنند اغلب کلاس‌های انتزاعی باقی‌مانده‌ای هستند که هیچ‌کس آن‌ها را پیاده‌سازی و استفاده نکرده است. بدیهی است که وجود چنین موجودات بی‌فایده‌ای نامطلوب است.اجتناب از مناطق محرومبه نظر واضح است که فرارترین اجزای ما باید تا حد امکان از هر دو منطقه محرومیت دور نگه داشته شوند. مکان نقاطی که از هر ناحیه حداکثر فاصله دارند، خطی است که (1،0) و (0،1) را به هم متصل می‌کند. عمو باب این خط را دنباله‌ای اصلی (Main Sequence) می‌نامد. هر کامپوننتی که روی دنباله‌ی اصلی قرار می‌گیرد برای پایداری آن بیش از حد انتزاعی نیست و برای انتزاعی بودن، بیش از حد ناپایدار نیست. به عبارتی این کامپوننت نه بی‌فایده است و نه به خصوص دردناک. تا حدی که انتزاعی است به آن وابستگی‌هایی وجود دارد و به اندازه‌ای که عینی است به دیگران بستگی دارد. مطلوب‌ترین موقعیت برای یک کامپوننت در یکی از دو نقطه انتهایی دنباله‌ی اصلی است. معماران خوب تلاش می‌کنند تا اکثر کامپوننت‌های خود را در آن نقاط پایانی قرار دهند.فاصله از دنباله‌ی اصلی (Main Sequence)اگر مطلوب است که کامپوننت‌ها روی دنباله‌ی اصلی یا نزدیک به آن باشند، می‌توانیم معیاری ایجاد کنیم که میزان فاصله یک کامپوننت از این ایده‌آل را اندازه‌گیری می‌کند.متریک فاصله (D) با رابطه‌ی |A+I-1| محاسبه می‌شود میزان نزدیکی به این خط را می‌سنجد. محدوده این متریک مقدار صفر تا یک است. مقدار صفر‌ نشان می‌دهد که کامپوننت مستقیما روی دنباله‌ی اصلی قرار دارد. مقدار یک نشان می دهد که کامپوننت تا حد امکان از دنباله‌ی اصلی دور است.با توجه به این معیار، یک معمار می‌تواند میزان انطباق کلی طرح خود با دنباله‌ی اصلی را تحلیل کرد. متریک D برای هر کامپوننت قابل محاسبه است. هر کامپوننتی که دارای مقدار D باشد که نزدیک به صفر نباشد، می‌تواند بررسی و در صورت نیاز به گونه‌ای دیگر بازسازی و طراحی شود.تجزیه و تحلیل آماری یک طرح نیز امکان‌پذیر است. میانگین و واریانس تمام معیارهای D مربوط به تمام کامپوننت‌های یک طرح قابل محاسبه می‌باشد. ما انتظار داریم که طراحی خوب دارای میانگین نزدیک به یک و واریانس نزدیک به صفر باشد. واریانس را می‌توان برای ایجاد «محدودیت های کنترلی» به منظور شناسایی اجزایی که در مقایسه با بقیه «استثنایی» هستند استفاده کرد.در این بخش از کتاب عمو باب سعی می‌کند مقداری از حالت توصیفی خارج شود و در عوض از متریک‌ها و محاسبات عددی برای سنجش موضوعات استفاده کند. معیارهای مدیریت وابستگی شرح داده شده در این بخش از کتاب، انطباق یک طرح را با الگوی وابستگی و انتزاعی را اندازه‌گیری می‌کند. تجربه نشان داده است که برخی وابستگی‌ها خوب و برخی دیگر بد هستند. الگوهای بیان شده در این بخش از کتاب به گفته‌ی عمو باب منعکس‌کننده آن تجربه‌ی چندساله‌ی ایشان هستند. با این حال، به گفته‌ی ایشان معیار یک اصل بدون شرط و کامل نیست. این متریک‌ها صرفا راهی برای اندازه‌گیری در برابر یک استاندارد دلخواه و تشریحی هستند. این معیارها در بهترین حالت ناقص هستند و احتمالا نیاز به متریک‌های دیگری وجود دارد، اما عمو باب امیدوار است که این متریک‌ها در اکثر موارد مفید هستند.معماریتا این بخش از کتاب عمو باب سعی کرده است که ابتدا مفاهیم مهم در سطح کد را بیان کند، سپس به مفاهیم مهم در سطح کامپوننت‌ها و اجزای مختلف برنامه بپردازد. از این بخش کتاب به بعد عمو باب دوباره تمرکز خود را بر روی معماری قرار می‌دهد و تلاش می‌کند از مفاهیم قبلی در این زمینه استفاده کند. کتاب بعد از این بخش نیز کلی فصل دیگر دارد اما بیان همه‌ی آن‌ها خارج از زمان این مقاله است. در این بخش تنها یکی از زیربخش‌های فصل معماری کتاب توضیح داده می‌شود به امید این که برای مطالعه دیگر مطالب کتاب علاقه‌مند شده و جداگانه برای خرید کتاب و مطالعه‌ی آن اقدام نمایید.اول از همه، خوب است که با تعریف دقیق‌تر از معمار نرم‌افزار آشنا شویم. معمار نرم‌افزار یک برنامه‌نویس است و همچنان برنامه‌نویس باقی می‌ماند. هرگز این دروغ را که می‌گویند معماران نرم‌افزار از کد عقب‌نشینی می‌کنند تا روی مسائل سطح بالاتر تمرکز کنند باور نکنید. معماران نرم‌افزار بهترین برنامه‌نویسان هستند و به انجام وظایف برنامه‌نویسی ادامه می‌دهند، در حالی که بقیه اعضای تیم را به سمت طراحی سامانه هدایت می‌کنند به گونه‌ای که بهره‌وری را به حداکثر برساند. معماران نرم افزار ممکن است به اندازه برنامه‌نویسان دیگر کد ننویسند، اما همچنان درگیر کارهای برنامه‌نویسی هستند. آن‌ها این کار را انجام می‌دهند زیرا اگر مشکلاتی را که برای بقیه برنامه‌نویسان ایجاد می‌کنند را تجربه نکنند، نمی‌توانند وظایف خود را به درستی انجام دهند.معماری یک سیستم نرم‌افزاری شکلی است که توسط کسانی که آن را می‌سازند به آن سیستم داده می‌شود. شکل معماری در تقسیم آن سیستم به اجزا، چیدمان آن اجزا و راه‌های ارتباط آن اجزا با یکدیگر است. هدف این شکل تسهیل توسعه، استقرار، بهره‌برداری و نگهداری سیستم نرم‌افزاری موجود در آن است.این تسهیلات برای این است که تا آن‌جا که ممکن است گزینه‌های زیادی را باز بگذاریم تا زمانی که ممکن است.هدف معماری نرم افزار این است که سیستم به درستی کار کند. مطمئناً ما می‌خواهیم که سیستم به درستی کار کند و قطعاً معماری سیستم باید از آن به عنوان یکی از بالاترین اولویت‌های آن پشتیبانی کند. با این حال، معماری یک سیستم تأثیر بسیار کمی بر کارکرد آن سیستم دارد. سیستم‌های زیادی وجود دارد، با معماری‌های وحشتناک، که به خوبی کار می‌کنند. مشکلات آن‌ها در عملکردشان نیست. بلکه در استقرار، نگهداری و توسعه مستمر آن‌ها رخ می‌دهد.این بدان معنا نیست که معماری نقشی در حمایت از رفتار مناسب سیستم ندارد. قطعا این کار را می‌کند و این نقش حیاتی است. اما گزینه‌های رفتاری کمی وجود دارد که معماری یک سیستم بتواند آن‌ها را باز بگذارد. هدف اصلی معماری پشتیبانی از چرخه‌ی حیات سیستم است. معماری خوب باعث می‌شود سیستم به راحتی قابل درک باشد، توسعه‌ی آن آسان باشد، نگهداری آن آسان باشد و به راحتی قابل استقرار باشد. هدف نهایی به حداقل رساندن هزینه طول عمر سیستم و به حداکثر رساندن بهره‌وری برنامه‌نویس است.به صورت خلاصه هر کدام از ابعاد معماری را در زیر بیان می‌کنیم.توسعهسیستم نرم‌افزاری که توسعه آن سخت است، عمر طولانی و سالمی نخواهد داشت. بنابراین معماری یک سیستم باید توسعه آن سیستم را برای تیم‌هایی که آن را توسعه می‌دهند آسان کند.استقراربرای مؤثر بودن، یک سیستم نرم‌افزاری باید قابل استقرار باشد. هر چه هزینه استقرار بیشتر باشد، سیستم کمتر مفید است. بنابراین، هدف یک معماری نرم‌افزاری باید ساختن سیستمی باشد که بتوان به راحتی با یک اقدام واحد آن را مستقر کرد. متأسفانه، استراتژی استقرار به ندرت در طول توسعه اولیه در نظر گرفته می‌شود. این منجر به معماری‌هایی می‌شود که ممکن است توسعه سیستم را آسان کند، اما استقرار آن را بسیار دشوار کند.به عنوان مثال، در توسعه اولیه یک سیستم، توسعه دهندگان ممکن است تصمیم بگیرند که از یک معماری میکروسرویس استفاده کنند. آن‌ها ممکن است متوجه شوند که این رویکرد توسعه سیستم را بسیار آسان می‌کند زیرا مرزهای مؤلفه بسیار محکم و رابط‌ها پایدار هستند. با این حال، زمانی که زمان استقرار سیستم فرا می‌رسد، ممکن است متوجه شوند که تعداد سرویس‌های بسیار زیاد است. پیکربندی اتصالات بین آن‌ها و زمان شروع آن‌ها نیز ممکن است منبع بزرگی از خطاها باشد. اگر معماران در اوایل مسائل مربوط به استقرار را در نظر می‌گرفتند، ممکن بود تصمیمات بهتری را بگیرند.عملکردتأثیر معماری بر عملکرد سیستم نسبت به تأثیر معماری بر توسعه، استقرار و نگهداری کمتر چشمگیر است. تقریبا هر مشکل عملیاتی را می‌توان با استفاده از سخت افزار بیشتر به سیستم بدون تأثیر شدید بر معماری نرم‌افزار حل کرد. در واقع، ما بارها و بارها شاهد این اتفاق بوده‌ایم. سیستم‌های نرم‌افزاری که دارای معماری ناکارآمد هستند، اغلب می‌توانند به سادگی با افزودن فضای ذخیره‌سازی بیشتر و سرورهای بیشتر، حل شوند. این واقعیت که سخت افزار ارزان است و افراد گران هستند به این معنی است که معماری‌هایی که مانع عملکرد می‌شوند به اندازه معماری‌هایی که مانع توسعه، استقرار و نگهداری می‌شوند پرهزینه نیستند.با این حال خوب است که معماری یک سیستم عملکرد سیستم را به راحتی برای توسعه‌دهندگان آشکار کند. این امر درک سیستم را ساده می‌کند و بنابراین به توسعه و نگهداری کمک زیادی می‌کند.نگهداریاز بین تمام جنبه‌های یک سیستم نرم‌افزاری، تعمیر و نگهداری پرهزینه‌ترین است. وجود بی‌پایان ویژگی‌های جدید و دنباله اجتناب‌ناپذیر نقص‌ها و اصلاحات، حجم عظیمی از منابع انسانی را مصرف می‌کند. یک معماری با دقت فکرشده این هزینه‌ها را بسیار کاهش می‌دهد. با جداسازی سیستم به اجزا و جداسازی آن اجزا از طریق رابط‌های پایدار، می‌توان مسیرها را برای ویژگی‌های آینده روشن کرد و خطر شکستگی ناخواسته را تا حد زیادی کاهش داد.روشی که نرم‌افزار را نرم نگه می‌دارید این است که تا جایی که ممکن است گزینه‌های زیادی را باز بگذارید. گزینه‌هایی که باید باز بگذاریم چیست؟ آن‌ها جزئیاتی هستند که اهمیتی ندارند. تمام سیستم‌های نرم‌افزاری را می‌توان به دو عنصر اصلی تقسیم کرد: سیاست‌ها و جزئیات.عنصر سیاست شامل تمام قوانین و رویه‌های تجاری است. سیاست جایی است که ارزش واقعی سامانه قرار دارد. جزئیات مواردی هستند که برای توانمندسازی انسان‌ها، سایر سیستم‌ها و برنامه‌نویسان برای برقراری ارتباط با سیاست‌ها ضروری هستند، اما به هیچ وجه بر سیاست‌ها تأثیر نمی‌گذارند. آن‌ها شامل دستگاه‌های IO، پایگاه‌های داده، سیستم‌های وب، سرورها، چارچوب‌ها، پروتکل‌های ارتباطی و ... هستند.معماران خوب به دقت جزئیات را از سیاست جدا می‌کنند به گونه‌ای که سیاست هیچ اطلاعی از جزئیات نداشته باشد و به هیچ وجه به جزئیات وابسته نباشد. معماران خوب سیاست را طوری طراحی می‌کنند که تصمیم‌گیری در مورد جزئیات را می‌توان تا زمانی که ممکن است به تعویق انداخت.ان شا الله که مطالب بیان‌شده برای شما مفید باشد به گونه‌ای که شما را برای خواندن دیگر مطالب کتاب ترغیب نموده باشد. متن این کتاب روان بوده و تا حد خوبی مستقل از پیش‌زمینه‌ی فراوان در برنامه‌نویسی قابل فهمیدن و یادگیری می‌باشد. به امید این که مطالعه‌ی کتاب‌های مفید افزایش پیدا کند!این مطلب، بخشی از تمرین‌های درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است. امین برجیان امین برجیان Sat, 18 Dec 2021 23:22:11 +0330 https://virgool.io/@borjianamin98/%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D8%B4%D8%B4-%D8%B6%D9%84%D8%B9%DB%8C-km2q13l5bdzk ساختار شش‌ضلعیساختار شش‌ضلغی، یک ساختار طراحی معماری می‌باشد که اگر چه مزیت‌های زیادی می‌تواند داشته باشد، اما تقریبا از سال 2015 به بعد مورد توجه قرار گرفت. هدف اصلی که برای آن معماری شش‌ضلعی ارائه شده بود، این بود که این نوع معماری این اجازه را به ما می‌دهد تا یک برنامه به صورت مساوی توسط کاربران، برنامه، تست‌های خودکار یا اسکریپ‌های نوشته‌شده مورد استفاده قرار بگیرد و همچنین در عین حال به صورت کاملا مجزا نسبت محیط نهایی و دستگاه‌هایی که در آن اجرا می‌شود، قابلیت تست‌شدن و توسعه‌یافتن داشته باشد. توضیحات بالا بسار جذاب و زیبا به نظر می‌آیند! همچنین در صورت عملی‌بودن توضیحات بالا، ما می‌توانیم به راحتی هسته‌ی اصله‌ی کسب و کار را از برنامه جدا کنیم و همچنین به راحتی رفتار برنامه را مستقل از هر چیز دیگری تست نماییم. امکاناتی که توسط این نوع طراحی معماری ارائه می‌شود به نیازمندی‌هایی که برای پیاده‌سازی معماری دامنه‌محور (Domain Driven Desgin) داریم بسیار نزدیک هست و به همین دلیل معمولا این موارد در کنار یکدیگر و با هم استفاده می‌شوند. اما با این حال این دو معماری، کاملا متفاوت هستند و هر کدام به تنهایی قابل پیاده‌سازی و استفاده هستند. این معماری پیچیدگی خاصی برای پیاده‌سازی ندارد و می‌تواند به راحتی استفاده و مورد بهره‌برداری قرار بگیرد. در واقعیت این معماری بر مبنای تعدادی قواعد ساده و مشخص هستند که به راحتی قابل پیاده‌سازی و استفاده هستند. در ادامه به این موارد خواهیم پرداخت. توضیحات ارائه‌شده در این مطالب، اکثرا ترجمه‌ی مطالب موجود در مراجع ارائه‌شده در انتهای این مقاله هستند. اصول معماری شش‌ضلعیمعماری شش‌گانه بر پایه‌ی یکسری اصول و تکنیک‌ها ایجاد شده است که به صورت خلاصه در ابتدا بیان می‌کنیم:در این طراحی به صورت مشخص (نه ضمنی) بخش‌های سمت سرور (server-side)، سمت کاربر (user-side) و منطق‌های کسب و کاری (Business Logic) از همدیگر تفکیک می‌شوند. تمامی وابستگی‌ها بین سه بخش بیان شده به این صورت است که تنها بخش‌های سمت سرور و کاربر، به بخش مفاهیم کسب و کاری وابسته هستند. (وابستگی از سمت بخش مفاهیم کسب و کاری به بخش‌های سمت سرور یا کاربر وجود ندارد)تمامی مرزهای بین بخش‌های مختلف بیان‌شده در بالا، از طریق پورت‌ها (Port) و آداپتورها (Adapters) فراهم می‌شود. در ادامه از مفاهیم کسب و کاری، سمت سرور و سمت کاربر استفاده‌های فراوانی می‌شود. این مفاهیم بر اساس اسم‌های استفاده‌شده در مقاله‌ی اصلی معماری شش‌ضلغی می‌باشند.جداسازی منطق‌های کسب و کاری از سمت سرور و کاربراولین و مهم‌ترین اصل در معماری شش‌ضلعی، جداسازی سه بخش اساسی به صورت مشخص از یکدیگر می‌باشد. این موارد را می‌توان در تصویر زیر نیز مشاهده نمود:معماری شش‌ضلعی به صورت سطح بالا و نحوه‌ی ارتباط بخش‌های مختلفبخش سمت کاربر در سمت چپاین بخش، در واقعیت همان بخشی می‌باشد که یا کاربر یا سامانه‌های خارجی که از سامانه‌ی ما استفاده می‌کنند، با برنامه‌ی ما تعامل و ارتباط برقرار می‌کنند. در واقعیت پیاده‌سازی‌هایی که این نوع ارتباطات را فراهم می‌کنند، در این قسمت قرار می‌گیرند. معمولا بخش رابط کاربری که توسط کاربر استفاده می‌شود (مثلا ارتباطات API با برنامه یا ورودی با فرمت کنسول) در این قسمت قرار می‌گیرند. به عبارتی در این قسمت ما استفاده‌کنندگان (actor) را می‌بینیم که از منطق‌های کسب و کاری استفاده می‌کنند. علت استفاده از نام سمت چپ نیز، به دلیل استفاده از همین مفهوم مشابه در مقاله‌ی اصلی این معماری می‌باشد. بخش منطق‌های کسب و کاری در میانهاین بخش، در واقعیت همان بخش اصلی است که از سمت چپ و راست که استفاده‌کننده‌های آن هستند، به صورت مشخص جدا می‌شود. در واقعیت این بخش تمامی پیاده‌سازی‌های مربوط به منطق‌های کسب و کاری و نکات مرتبط به آن‌ها را در نظر می‌گیرد. در واقعیت همان واژگان کسب و کاری که قرار بوده در ابتدا توسط این سامانه مدل‌سازی و حل شود، در این قسمت از برنامه مشاهده می‌شود. معمولا یه متخصص در حوزه‌ی کسب و کار برنامه‌ی طراحی‌شده که معمولا فردی بدون بیشینه‌ی برنامه‌نویسی بوده یا شاید هم دانش حرفه‌ای در زمینه‌ی برنامه‌نویسی نداشته باشد، باید بتواند این بخش از برنامه را مشاهده کند و به راحتی به تناقض‌های میان آن و آن چه که باید برای حل مسئله مربوط کسب و کار خاص در نظر گرفته می‌شده است، اشاره کند. (در واقعیت ممکن است گاهی در مدل‌سازی مسئله بین مختصصان حوزه و تیم توسعه‌دهندگان، به دلایل مختلف تناقص‌هایی ایجاد شود)بخش سمت سرور در سمت راستدر سمت سرور، در واقعیت تمام نیازمندی‌های برنامه برای این که برنامه قابلیت اجرایی‌شدن را داشته باشد، مشاهده می‌کنیم. اگر چه تعاملات با برنامه در سمت راست نشان داده شده است و تمامی منطق‌های کسب و کاری نیز در میانه آورده شده است، اما این که وضعیت سیستم به چه صورت نگهداری شود، ارتباطات با سرویس‌های خارجی لازم می‌باشد یا خیر، این که این وضعیت به چه صورت توسط تغییرات کاربر، تغییر می‌کند و ... همگی در این بخش پیاده‌سازی می‌شوند. به عنوان مثال یکی از نیازمندی‌های اصلی هر سامانه‌ای وجود پیاده‌سازی (منطق کد) برای ارتباط به لایه‌ی داده (مثل دیتابیس) می‌باشد که نحوه‌ و نوع فراخوانی‌های سمت لایه‌ی داده، ویژگی‌های فراهم‌شده توسط آن و ... در این بخش پیاده‌سازی می‌شود. به عنوان مثالی دیگر گاهی ممکن است که نیاز به ارتباطات در سطح شبکه (مثلا پروتکل HTTP) با دیگر سامانه‌ها باشد تا بتوانیم پاسخ کاربر را ارائه دهیم. این موارد نیز در سمت سرور پیاده‌سازی می‌شوند. در واقعیت این بخش شامل استفاده‌کنندگانی (actor) می‌شود که توسط منطق‌های کسب و کاری مشخص‌شده، مدیریت می‌شوند. در مقاله‌ی اصلی از این بخش نیز به عنوان بخش سمت راست یاد شده است. اهمیت این جداسازی بخش‌ها در چیست؟اولین اهمیت جداسازی بخش‌های مختلف برنامه این هست که در واقعیت هر کدام از این بخش‌ها، مسئله‌های مختلفی را پاسخگو هستند. به عبارتی ما در هر زمانی می‌توانیم بر روی منطقی که باید متمرکز شویم، تمرکز کنیم و مستقل از بخش‌های دیگر تغییرات را اعلام کنیم. با جدابودن این بخش‌ها، فهم هر کدام از آن‌ها راحت‌تر خواهد شد و محدودیت‌های هر بخش تاثیر کمتری بر روی بخش‌های دیگر خواهد داشت. نکته‌ی مهم دیگری که وجود دارد این است که ما منطق‌های کسب و کاری اصل و مبنای قرار داده‌ایم و بقیه بخش‌ها به آن وابسته هستند. به عبارتی این بخش به راحتی می‌تواند در یک پوشه یا ماژول جدا قرار گرفته و در اختیار تمام برنامه‌نویسان باشد. همچنین این بخش به راحتی می‌تواند تست شود بدون این که لازم باشد پردازش‌های سنگین دیگر بخش‌های سامانه اجرا شود. این بسیار مهم است چون در واقعیت آن چه که ما قرار بوده مدل کنیم و بر اساس آن مسئله را حل کنیم، همین مدل‌ها و منطق‌های کسب و کاری بوده است. با توجه به توضیحات بالا، در عمل ما می‌توانیم بخش‌های مختلف سامانه را با تلاش حداقلی تست نماییم:تست کل بخش کسب و کاریتست ارتباط بین بخش کاربری و بخش منطق کسب و کاری مستقل از سمت سرورتست ارتباط بین بخش سرور و بخش منطق کسب و کاری مستقل از سمت کاربروارونگی وابستگی در زمینه معماری شش‌ضلعیقاعده‌ی وارونگی یکی از قواعد بسیار مهم می‌باشد که به اهمیت آن در زمینه برنامه‌نویسی شی‌گرا، آنکل باب (uncle bob) در کتاب خود نیز اشاره کرده بود. در بخش اصول توسعه سامانه‌های نرم‌افزاری چابک، او اشاره می‌کند که:ماژول‌های سطح بالا نباید به ماژول‌های سطح پایین وابسته باشند، بلکه هر دو باید تنها به مفاهیم انتزاعی وابسته باشند. مفاهیم انتزاعی نباید به جزییات وابسته باشند، بلکه جزییات باید به مفایهم انتزاعی وابسته باشند.اگر کمی به این دو نکته‌ی اشاره‌شده دقت کنیم و طرح معماری شش‌ضلعی را دوباره نگاه کنیم، مشاهده می‌کنیم که همان سمت چپ و راست که در معماری شش‌ضلعی وجود دارد، در واقعیت نماینده‌ی دو استفاده‌ کننده‌ی مختلف هستند و به نوعی مفاهیم بالا در آن‌ها مشاهده می‌شود.همان‌طور که در بالاتر، ارتباط بین بخش‌های چپ یا راست با قسمت مرکزی، از طریق پورت‌ها و آداپتورها ارائه می‌شود. به عبارتی بخش مرکزی تعدادی پورت (Port) را ارائه می‌دهد و بخش‌های دیگر برای اتصال به بخش مرکزی، از آداپتور (Adapter) مناسب استفاده می‌کنند. برای این که بتوانیم این مفاهیم و استفاده‌ی نکات بیان‌شده در بالا را در معماری شش‌ضلعی مشاهده و درک کنیم، در ادامه مثالی را بیان می‌کنیم تا مفاهیم روشن‌تر شوند. فرض‌کنیم سامانه‌ای داریم که در آن قرار است هر شخصی بتواند یاد‌داشت‌های را با یک‌سری ویژگی‌های خاص بنویسید و در صورت نیاز لیست مواردی که تا الان نوشته است، دریافت کند. در هسته‌ی مرکزی ما مفهوم یادداشت و ویژگی‌های آن را به عنوان منطق کسب و کاری خواهیم داشت. در سمت چپ (سمت کاربر) به دنبال آن هستیم که کاربر بتواند یک یادداشت جدید اضافه کند یا لیست یادداشت‌ها را دریافت کند. در سمت راست (قسمت سرور) نیاز داریم تا یادداشت‌ها در یک پایگاه داده ذخیره شوند تا اطلاعات آن در هنگام خروجی‌گرفتن، وجود داشته باشند. با فرض بر وجود مسئله‌ی بالا، ما نیاز داریم که از ورودی‌های استاندارد (مثل ورودی متنی) اطلاعات مربوط به یادداشت را دریافت کنیم تا در ادامه آن را ذخیره کنیم. منطق خواندن از ورودی استاندارد ممکن است به هر دلیل در آینده تغییر کند و همچنین نیاز سمت کاربر می‌باشد اما سمت کاربر مستقیما به سمت سرور دسترسی ندارد. در واقعیت سمت کاربر باید به نوعی به بخش منطق کسب و کاری وابسته می‌شود و از آن درخواست اضافه‌شدن یک یادداشت را می‌کند. اما در واقعیت این درخواست نیاز دارد به روشی اطلاعات یاداداشت را فراهم کند. به همین دلیل در سمت بخش میانی، یک واسط با نام NoteProvider ایجاد می‌شود که تامین‌کننده‌ی یک یادداشت می‌باشد. همچنین در سمت مرکزی تابعی برای اضافه‌کردن یک یادداشت (addNote) قرار می‌گیرد که از NoteProvider درخواست یک یادداشت می‌کند. سپس از واسط NotePersistent استفاده می‌شود تا این یادداشت را ذخیره کند. اما تمامی این واسط‌های هیچ پیاده‌سازی ندارند! در عمل این بخش‌های سمت کاربر و سمت سرور هستند که این پیاده‌سازی را فراهم می‌کنند. بخش سمت کاربر مثلا واسط NoteProvider را فراهم می‌کنند که امکان خواندن این اطلاعات را از فایل متنی فراهم می‌کند. (حتی می‌تواند در آینده تغییر کند تا از روش دیگری اطلاعات یادداشت دریافت شود) همچنین بخش سمت سرور پیاده‌سازی NotePersistent را فراهم می‌کند که به عنوان مثال داده را در دیتابیس mysql ذخیره کند. (در حالی که هر نوع پیاده‌سازی دیگری را در آینده می‌توان پیاده‌سازی نمود) اگر مثال بالا را نگاه کنیم، مشاهده می‌کنیم که بخش مرکزی تنها یکسری واسط فراهم کرده است (مثل NoteProvider و NotePersistent) که در عمل مثل یکسری پورت در معماری شش‌ضلعی هستند. پیاده‌سازی این موارد در هر بخش به صورت مناسب فراهم می‌شود که این پیاده‌سازی در واقع همان آداپتور در معماری شش‌ضلعی می‌باشد.وجود پورت‌ها و آداپتورها برای بخش‌های مختلف معماری شش‌ضلعی (منبع عکس)اما همان‌طور که در مثال بالا مشاهده می‌کند، ما می‌توانستیم مثلا منطق ارتباط با پایگاه داده را در بخش مرکزی قرار دهیم و به راحتی از آن برای ذخیره‌سازی داده استفاده کنیم. اما به جای این نوع رفتار، ما یک واسط را در بخش میانه قرار دادیم و سپس بخش سمت سرور آن را پیاده‌سازی می‌کند. اما در عمل موقع ایجاد یک نمونه از بخش مرکزی، ما باید این واسط را با پیاده‌سازی مناسب ایجاد کنیم. این همان مفهوم وارونگی وابستگی‌ها هست که اگر چه هنوز وابستگی وجود دارد و باید فراهم شود، اما این وابستگی به صورت مستقیم در درون بخش میانه قرار نمی‌گیرد بلکه بعدا به صورت یک وابستگی تزریق می‌شود. این سبب می‌شود که به راحتی بتوانیم این بخش‌ها و پیاده‌سازی‌ها را از هم جدا کنیم. همچنین این امکان برای ما وجود دارد که در هر زمانی، پیاده‌سازی ساده‌تری از واسط را به جای پیاده‌سازی واقعی فراهم کنیم. این کاربرد در تست‌ها بسیار مهم می‌باشد.نتیجه‌گیریطراحی شش‌ضلعی یا نام دیگر آن، طراحی پورت و آداپتور یک طراحی شاهکارانه نیست که پاسخ‌گوی نیاز همه‌ی مسائل باشد اما با توجه به قواعد و اصولی که توسط این معماری مشخص شده است، پیاده‌سازی این سامانه در بدو کار و همچنین توسعه‌ی سامانه در ادامه‌ی کار، بسیار راحت‌تر خواهد بود. همچنین مزیت‌های چون سادگی استفاده از بخش‌های مختلف، وجود امکان تست هر بخش از سامانه به صورت مستقل، تمرکز بر مدل‌های کسب و کاری و ... همه از ویژگی‌های مفیدی هستند که این نوع معماری ارائه می‌دهد. در واقعیت این معماری اگر چه در ظاهر شاید کمی پیچیدگی را اضافه کند، اما اگر این پیچیدگی به درستی و با مراقبت، مدیریت شود، می‌تواند مزیت‌های بسیاری را برای سامانه و توسعه‌ی آن فراهم کند. این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است.منابع Hexagonal Architecture: three principles and an implementation exampleHexagonal Architecture, there are always two sides to every story امین برجیان امین برجیان Mon, 06 Dec 2021 22:35:57 +0330 https://virgool.io/@borjianamin98/%D8%B7%D8%B1%D8%A7%D8%AD%DB%8C-%D8%AF%D8%A7%D9%85%D9%86%D9%87-%D9%85%D8%AD%D9%88%D8%B1-%DB%8C%D8%A7-%D8%AD%D9%88%D8%B2%D9%87-%D9%85%D8%AD%D9%88%D8%B1-%DA%86%DB%8C%D8%B3%D8%AA-q09i9gomreae طراحی دامنه‌محور یا حوزه‌محور (Domain Driven Design) برای حل هر مسئله‌ای به صورت مهندسی، شناخت حوزه‌‌ای که برای آن راه‌حل ارائه می‌شود الزامی است. بدیهی است که بدون شناخت فرایندهای بانکی، مسائل مربوط به آموزش، بیمه و ...، طراحی سامانه‌ای در این حوزه‌ها در عمل غیرممکن خواهد بود. تعامل میان مهندسان نرم‌افزار و افراد متخصص در این حوزه‌ها برای دستیابی به این هدف الزامی می‌باشد. طراحی دامنه‌محور یا حوزه‌محور (Domain Driven Design) برای پاسخ به نیازمندی بالا، تکنیک‌ها و روش‌هایی را ارائه می‌دهد و ارتباطات میان افراد متخصص در یک حوزه و توسعه‌دهندگان سامانه را تسهیل می‌کند. دامنه یا حوزه چیست؟حوزه (Domain) در معنای عام یک مجموعه‌ی دانشی محسوب می‌شود. وقتی ما در مورد یک حوزه صحبت می‌کنیم، در واقعیت درباره مجموعه‌ی علوم و اصطلاحات مربوط به یک دامنه‌ی خاص صحبت می‌کنیم مثلا حوزه کارهای بانکی، حوزه بیمه و موارد دیگر. در زمینه‌ی نرم‌افزار، حوزه در واقعیت همان کسب و کار یا ایده‌ای هست که قصد مدل‌سازی آن را در قالب یک سامانه داریم. متخصصان در یک حوزه کسانی هستند که تمامی اصطاحات و دانش مورد نیاز در مورد آن حوزه را دارند در حالی که شاید برنامه‌نویس نباشند. یکی از اهداف طراحی دامنه‌محور ساخت یک مدلی است که افراد مختصص حوزه آن را درک کنند. دقت شود این مدل به این معنا نیست که من یک تکه کد را ارائه دهم و از آن به عنوان مدل یاد کنم. بلکه مدل مفهومی انتزاعی و بستری مشترک برای صحبت با متخصصان در آن حوزه است. پیاده‌سازی نرم‌افزاری یا نموداری از رفتار مدل، همگی پیاده‌سازی‌های از مدل هستند که باید تا حد امکان نماینده مدل اصلی باشند اما معیار صحبت با متخصصان حوزه نیستند.زبان فراگیرارتباط میان مختصصان یک حوزه و توسعه دهندگان، نیاز به زبان مشترک و فراگیر (Ubiquitous) دارد. دقت شود که با صحبت به متخصصان حوزه به یک زبان مشترک می‌رسیم و از اصطلاحات آن‌ها در حوزه‌ی تیم توسعه نیز استفاده می‌کنیم. نباید این مسیر را به صورت برعکس انجام دهیم مثلا بیان مفهوم جدول، سطر و شی و توصیف آن‌ها برای متخصصان و صحبت کردن روی این موارد کار کاملا اشتباهی است. یک مشتری رستوران تنها سفارش، رزرو و غذا را درک می‌کند!تجزیه یک دامنهبررسی هر حوزه دانشی اگر چه در نگاه اول ساده به نظر می‌آید، اما زمانی که دقیق مورد بررسی قرار می‌گیرد، حجم زیادی از روابط و موضوعات مشاهده می‌شود. اگر قرار باشد تمامی این موارد را تحت یک مدل بیان کنیم قطعا خروجی بسیار پیچیده می‌شود. به همین دلیل ما معمولا دامنه مورد بررسی را به زیردامنه‌های کوچک‌تری تقسیم می‌کنیم. این زیردامنه‌ها از کنار هم قرارگرفتن ایده‌ها و قواعد مرتبط ایجاد می‌شوند. هر کدام از این زیر بخش‌ها می‌توانند زبان فراگیر خود را داشته باشند. مثالی از تجزیه دامنه رستورانممکن است در این تقسیم به زیردامنه، مفاهیم مشترکی را مشاهده کنیم که در چندین زیردامنه وجود داشته باشند، مثل مشتری یا سفارش در رستوران. حتی گاهی این موارد مشترک در نگاه اول کاملا یکسان هستند اگر چه ممکن است در زمان تغییر کنند. در این تجزیه این نکته مهم را باید در نظر گرفت که هرگز تلاش نکنیم این موارد را به صورت مشترک استفاده کنیم. استفاده مشترک تنها توسعه‌های آینده را محدود می‌سازد. نکات زیر در مورد این موجودیت‌های مهم باید در نظر گرفته شود:این موارد ممکن است در ابتدای کار یکسان نباشند یا در طول زمان در ویژگی‌هایی تفاوت پیدا کنند. (جمع‌آوری کلیه‌ی ویژگی‌های مختلف زیر یک مفهوم خوب نیست)ممکن است یکسری ویژگی‌ها تنها برای زیردامنه‌های خاصی مهم باشند مثلا رمز مشتری یا آدرس مشتری در سامانه برای بخش سفارش مهم نیست. (برای بخش ورود به سامانه یا بخش تحویل تنها مهم هستند)معمولا به این زیردامنه‌ها که می‌توانند زبان مشترک خود را داشته باشند، محدوده مفاهیم (bounded context) می‌گویند. مثلا معنای سفارش در انبار برای دریافت مواد غذایی و سفارش یک مشتری برای خرید غذا کاملا متفاوت هستند. (زیردامنه‌ی سفارش غذا و مدیریت انبار) معمولا این زیردامنه‌های محدود نقطه‌ی شروع خوبی برای معماری میکروسرویس‌ها هستند. متاسفانه رویکرد کلی برای تشخیص این محدوده مفاهیم وجود ندارد. اما می‌توان با در نظر گرفتن نکات زیر تا حد خوبی زیردامنه‌ها را تشخیص دهیم:در نظر گرفتن بخش‌های مختلف سامانه که توسط افراد مختلفی مدیریت می‌شوند.در نظر گرفتن تغییرات در زبان مشترکحفظ استقلال محدوده مفاهیمبعد از این که لایه‌های مختف برنامه تشخیص داده شدند و در قالب محدوده مفاهیم جدا شدند، ما نیاز داریم که ارتباط بین این بخش‌ها را به گونه‌ای فراهیم کنیم که این استقلال برای هر محدوده حفظ شود. به عبارتی گاهی مفاهیم مختلفی در هر محدوده وجود دارند که خاص آن محدوده هستند یا در صورت یک مفهوم‌بودن، یکسری ویژگی‌ها را نداشته یا نیاز به ترجمه‌شدن برای یک محدوده‌ی دیگر داشته باشند. ایجاد یک ساختار داده جامع (شامل ویژگی‌های هر دو محدوده) یا به اشتراک‌گذاری مفاهیم بین هر دو محدوده، تنها وابستگی محدوده‌ها را افزایش می‌دهد که خوب نیست. لایه‌های جلوگیری از انحراف (Anti-Corruption Layer)، مسئولیت این تبدیلات را بین محدوده‌ی مفاهیم دارند به صورتی که استقلال بین محدوده‌ها حفظ شوند. این لایه به خصوص در سامانه‌هایی دارای بخش‌های قدیمی (legacy) بسیار مفید می‌باشد زیرا جداسازی بخش legacy از دیگر محدوده‌های سیستم و تنها ارتباط‌دادن با دیگر بخش‌ها از طریق لایه جلوگیری از انحراف سبب می‌شود که خلوص و تمیزی دیگر محدوده‌ها حفظ گردد.فعالیت‌های سامانهدر هر حوزه‌ی دانشی، انواع مختلفی از فعالیت‌ها (activities) رخ می‌دهد که بررسی آن‌ها برای تولید سامانه الزامی می‌باشد. دستوردستور (Command) درخواستی به منظور انجام یک هدف می‌باشد. یک دستور در زمان تعریف هنوز انجام نشده است و به همین دلیل ممکن است پیش از انجام، لغو شود. معمولا دستورات به یک محدوده مشخص ارسال می‌شوند و سبب تغییر در وضعیت دامنه می‌شوند مانند اضافه‌کردن یک مورد به سفارش، پرداخت قبض، آماده‌سازی غذا و ...رخدادرخداد (Event) نشان‌دهنده‌ی عملی هستند که در گذشته انجام شده است. از آن‌جایی که عمل در گذشته انجام شده است، دیگر قابل انکار یا لغو‌کردن نیستند. معمولا رخدادها به تعداد زیادی محدوده ارسال می‌شوند و تغییرات رخ‌داده در درون دامنه را ثبت می‌کنند مانند موردی که به سفارش اضافه شده است، قبضی که پرداخت شده است و ...پرس و جوپرس و جو (Query) نشان‌دهنده‌ی درخواست برای یک اطلاعاتی در دامنه هستند. جواب یک پرس و جو همواره وجود خواهد داشت و پس از اجرای آن، تغییری در وضعیت دامنه رخ نمی‌دهد. پرس و جو نیز معمولا برای یک محدوده خاص ارسال می‌شود مثلا گرفتن لیست موارد یک سفارش، بررسی پرداخت یا عدم پرداخت یک قبض.انواع فعالیت‌های ذکرشدن در بالا، همگی در طراحی‌های مختلف نشان‌دهنده‌ی مفهوم‌های مختلف هستند. مثلا تمامی موارد بالا همان پیام‌های سیستم‌های واکنش‌پذیر (reactive) هستند. یا در طراحی محدوده مفاهیم (bounded context) یا میکروسرویس (micro-service) بخش رابط برنامه (API) هستند. تبدیل زبان فراگیر به کدبعد از تشخیص محدوده‌های مفاهیم و تشخیص فعالیت‌های مختلفی که در دامنه وجود دارند، ما نیاز داریم که همین مفاهیم را در سمت کد نیز داشته باشیم. زمانی که ما به این سمت می‌رویم، دوست داریم به گونه‌ای مفاهیم را در کد مشاهده کنیم که بتوانیم تناظر یک به یک را به سادگی در هنگام استفاده از زبان فراگیر در صحبت با افراد متخصص داشته باشیم. به همین دلیل معمولا تلاش می‌شود که اگر مثلا دستوری به نام «باز کردن در» داریم، آن را به صورت OpenDoor یا OpenDoorCommand در کد قرار دهیم. به این وسیله، به راحتی بتوانیم بین توسعه‌دهندگان و افراد متخصص زبان مشترک را حفظ کنیم. اشیای دامنهدر درون هر کدام از این محدوده مفاهیم، یکسری اشیا (objects) وجود دارند که خاص آن محدوده هستند. این اشیا انواع مختلفی دارند که در ادامه با هر کدام آشنا می‌شویم. شی از نوع مقدارمثالی برای شی از نوع مقدارشی از نوع مقدار (Value Object) بر اساس مقدار ویژگی‌هایش تعریف می‌شود. به عنوان مثال در بالا «آدرس» یک شی مقدار هست. از آن‌جایی که هر دو جدول اول و دوم دارای ویژگی‌های کاملا یکسانی هستند، هر دو با هم برابر بوده و یک شی مقدار را نشان می‌دهند. یکی از خاصیت‌های مهم شی مقدارها، تغییرناپذیری (immutable) می‌باشد به صورتی که اگر هر کدام از ویژگی‌ها تغییر کنند، این شی دیگر با شی قبلی برابر نخواهد بود و به شی جدیدی تبدیل می‌شود. این شی‌ها می‌توانند دارای منطق‌های کسب و کاری باشند مثلا آدرس دارای یک منطق (یا تابعی) باشد که بر اساس آدرس، مقدار تقریبی طول و عرض جغرافیایی را روی نقشه برگرداند. موجودیتمثالی برای موجودیتهر موجودیت (Entity)، توسط یک ویژگی یکتا (شناسه یا کلید) مشخص می‌شود. به عنوان مثال در بالا «امین» به عنوان یک موجودیت واحد می‌باشد. اگر چه ممکن است که «قد» یا «وزن» امین تغییر کند (به دلیل مثلا ورزش‌کردن!)، ولی موجودیت «امین» ثابت خواهند ماند و این همان فرد است. با این حال موجودیت «امین» با «علیرضا» متفاوت است حتی اگر دارای ویژگی‌های کاملا یکسانی باشند. به صورت مشابه هر موجودیت نیز می‌تواند دارای یکسری منطق‌های کسب و کاری برای استخراج یا تغییر ویژگی‌ها باشد. شی تجمیعیمثالی برای شی تجمیعیشی تجمیعی (Aggregate)، نوعی خاص از موجودیت می‌باشد که در آن مجموعه‌ای از اشیای دامنه تحت یک موجودیت ریشه (root) قرار می‌گیرند. تمامی اشیا در یک شی تجمیعی تحت یک موجودیت مورد بررسی قرار می‌گیرند و هر دسترسی به زیربخش‌ها باید از طریق موجودیت ریشه صورت بگیرد. تشخیص موجودیت‌های تجمیعی کار ساده‌ای نیست. گاهی یک موجودیت در یک محدوده، نیاز به چندین موجودیت ریشه دارد. موجودیت‌های ریشه الزاما بین محدوده‌ها یکسان نیستند. تعدادی سوال که در تشخیص موجودیت‌های تجمیعی به ما کمک می‌کنند:آیا این موجودیت در اکثر فعالیت‌های یک محدوده مفاهیم مشارکت دارد؟آیا اگر این موجودیت حذف شود، موجودیت‌های دیگری نیز بی‌معنی شده و حذف می‌گردند؟آیا یک تراکنش در سامانه بر روی چندین موجودیت مختلف و مرتبط تاثیر می‌گذارد؟ (البته گاهی نیز تراکنش به درستی تعریف نشده است)انتزاع‌های دامنهدر طراحی دامنه‌محور، در کنار اشیا و فعالیت‌هایی که استخراج و طراحی می‌شوند، معمولا یکسری انتزاع‌ها (abstractions) نیز مشاهده می‌شود که در بیش‌تر فعالیت‌ها به ما کمک می‌کنند. در ادامه با انواع مختلفی از این انتزاع‌ها آشنا می‌شویم.سرویسمثالی از سرویس ارسال ایمیلاگر چه موجودیت‌ها و اشیا می‌توانند دارای منطق‌های کسب و کار (business logic) باشند اما گاهی یک منطق خاصی وجود دارد که این منطق به یک موجودیت یا شی خاص مربوط نمی‌شود. (به عبارتی به هر دلیلی نمی‌تواند موجودیتی را انتخاب کنید که برای این فرآیند منطقی به نظر بیاید) در چنین مواردی این منطق می‌تواند در قالب یک سرویس پنهان (encapsulate) شود. سرویس‌ها باید بدون وضعیت (stateless) باشند. اگر نیاز به یک وضعیت دارید، احتمالا منطق مربوطه یک موجودیت یا مقدار می‌باشد. معمولا سرویس‌ها خود در قالب یک انتزاع (مشخص‌نمودن رفتار) بیان می‌شوند و سپس به شکل‌های مختلفی پیاده‌سازی (concrete implementation) می‌شوند. این سبب می‌شود که تغییر پیاده‌سازی راحت باشد و از طرفی استفاده‌کننده تنها رفتارهای موردنیاز را استفاده می‌کند در حالی که نگران نحوه‌ی پیاده‌سازی نیست. معمولا تعداد سرویس‌های درون یک سامانه نباید بسیار باشند. اگر به چنین وضعیتی برسیم، احتمالا در تعریف برخی موارد زیاده‌روی کرده‌ایم. همچنین یک سرویس باید یک لایه‌ی سبک روی یک فرایند یا منطق باشد و نباید به گونه‌ای باشد که انگار یک آچار فرانسه همه کاره است!کارخانهمثالی از کارخانه در سامانه‌ی رستورانگاهی وقتی در هنگام ایجاد موجودیت‌ها (مخصوصا موجودیت‌های تجمیعی) منطق لازم برای ساخت این موجودیت‌ها بدیهی نیست و باید نکات مختلفی را در نظر گرفت. مثلا ممکن است برای ایجاد موجودیتی لازم باشد اطلاعات آن ابتدا توسط سرویسی خارجی بررسی شود و سپس شناسه‌ی یکتا برای آن تولید شود و در انتها در یک مخزن داده خارجی ذخیره شود. به همین دلیل ایجاد یک شی می‌تواند چالش‌های زیادی داشته باشد و یک کارخانه (Factory) می‌تواند این پیچیدگی‌های فراوان را پنهان نموده و استفاده از موجودیت را برای ما ساده کند. معمولا در پیاده‌سازی کارخانه مشابه سرویس از روش انتزاع استفاده می‌شود و پیاده‌سازی مختلف برای آن ارائه می‌شوند. در مثال بالا مثلا ایجاد یک رزرو و پیچیدگی‌های آن در قالب یک انتزاع ساده‌سازی شده است و مفاهیمی مثل پایگاه‌داده Cassandra یا نحوه‌ی ایجاد شناسه‌ی یکتا پنهان شده است. اگر با مفهوم CRUD آشنا باشید، یک کارخانه معادل بخش C یا Create می‌باشد. مخزنمثالی از مخزن در سامانه‌ی رستورانمخزن‌ها (Repository) خیلی مشابه کارخانه‌ها هستند با این تفاوت که بخش دریافت اطلاعات یا ویرایش موجودیت‌های پیچیده را برای ما به صورت انتزاعی فراهم می‌کنند. به عبارتی اگر با مفهوم CRUD آشنا باشید، در این صورت مخزن‌ها کارهای RUD (یعنی Read و Update و Delete) را انجام می‌دهند. معمولا به صورت مشابه مخزن‌ها به صورت انتزاعی نوشته می‌شوند و پیاده‌سازی‌های مختلف برای آن‌ها فراهم می‌شود. همان‌طور که مشخص است مفاهیم مخزن و کارخانه بسیار به هم نزدیک هستند، به همین دلیل در مواردی این دو مفهوم با یکدیگر ترکیب می‌شوند و تحت عنوان مخزن کلیه‌ی ویژگی‌های CRUD را فراهم می‌کنند. نتیجه‌گیریمفاهیم طراحی دامنه‌محور که در این قسمت آن‌ها را بیان کردیم، صرفا برای آشنایی اولیه با این نوع رویکرد طراحی و معماری بود. به عبارتی همان‌طور که مشاهده کردید، تلاش این نوع طراحی و معماری این بود که تا جای ممکن زبان مشترکی را بین توسعه‌دهندگان و افراد متخصص ایجاد کند و از طرفی تلاش می‌کرد که نحوه‌ی پیاده‌سازی برنامه را به گونه‌ای انجام دهد که مفاهیم و محدوده‌ها به خوبی از همدیگر تفکیک‌شده و برای توسعه سامانه مشکلی نداشته باشیم. یکی از مزیت‌های این روش طراحی این است که مفاهیم آن و نحوه‌ی قسمت‌بندی بخش‌های مختلف آن، در رویکرهایی مثل معماری واکنش‌گرا (Reactive Architecture) و میکروسرویس (Micro-services) مفید خواهد بود. این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است.منابعReactive Architecture Course: Domain Driven Design امین برجیان امین برجیان Mon, 06 Dec 2021 22:34:44 +0330 https://virgool.io/@borjianamin98/%D9%85%D9%86%D8%A8%D8%B9-%DA%A9%D8%B1%D8%AF%D9%86-%D8%B1%D9%88%DB%8C%D8%AF%D8%A7%D8%AF-whavwe3lzxps ما می‌توانیم وضعیت فعلی یک برنامه کاربردی را در هر زمانی بر اساس منابع نگهداری وضعیت سامانه (پایگا‌‌های داده)، مقادیر موجود در مموری برنامه‌ها و ... جویا شویم و در اکثر موارد، این به بسیاری از سوالات ما پاسخ می‌دهد. با این حال، مواقعی وجود دارد که ما فقط نمی‌خواهیم ببینیم کجا هستیم، بلکه می‌خواهیم بدانیم چگونه به آن‌جا رسیده‌ایم. دلایلی فراوانی وجود دارد که به خاطر آن‌ها بخواهیم بدانیم که چگونه به این وضعیت رسیده‌ایم که در ادامه بیش‌تر در مورد آن آشنا می‌شویم. یکی از راه‌های پاسخ به این نیازمندی، منبع‌کردن رویدارد (event sourcing) می‌باشد که در این متن و بحث‌های ادامه با آن آشنا می‌شویم. نگهداری وضعیتاکثر سامانه‌های متدوال امروزی، معمولا به این صورت طراحی می‌شوند که وضعیت سامانه را به صورت‌های مختلف مثل فایل، اطلاعات پایگاه‌داده، اطلاعات موجود در مموری و ... نگهداری می‌کنند. به این سامانه‌ها، سامانه‌های نگهداری داده مبتنی بر وضعیت (state based persistence) نیز گفته می‌شود. در سامانه‌های مبتنی بر نگهداری وضعیت، ما همواره وضعیت جاری سیستم را داریم و می‌توانیم در هر زمان برای نیازهای مختلف مثل گرفتن گزارش، دریافت اطلاعات یک موجودیت و ... به راحتی با یکسری کوئری‌های ساده، به هدف خود برسیم. همچنین هر زمانی نیز دستوری مبتنی بر بروزرسانی وضعیت یک مولفه ایجاد شود (مثل افزایش میزان سفارش یک مشتری در رستوران، تغییر نام کاربری، تغییر آدرس و ...) ما به راحتی درخواست را اعمال و وضعیت سامانه در پایگاه‌داده یا ... را بروزرسانی می‌کنیم. در نتیجه این که وضعیت قبل از بروزرسانی اطلاعات موجودیت چگونه بوده است، محو و غیرقابل دسترس می‌شود و ما تنها وضعیت کنونی موجودیت را دسترسی داریم. این نوع عملکرد می‌تواند سبب عواقبی شود که مهم‌بودن یا نبودن آن‌ها، کاملا به حوزه‌ی کسب و کاری و نیازمندی سامانه بر می‌گردد. در ادامه می‌خواهیم در مورد این عواقب صحبت کرده و آن‌ها را بهتر بشناسیم تا در ادامه بتوانیم بهتر تصمیم بگیریم که آیا نیازمندی سامانه شامل این موارد می‌شود یا نه. تغییرات جدید بر روی داده‌های قدیمییکی از مواردی که باید در نظر داشت این است که نیازمندی‌های یک دامنه همیشه ثابت و مشخص نیست. مخصوصا امروزه با رفتن به سمت متدولوژی‌های چابک، تغییر نیازمندی‌های کسب و کاری در هر مرحله از طراحی سامانه‌ی نرم‌افزاری امکان‌پذیر می‌باشد. هر کدام از این تغییرات در نیازمندی‌ها می‌توانند به دلایل مختلفی در سامانه رخ دهند. ممکن است بنا به دلایل حقوقی یا امنیتی، نیازمندی‌های جدیدی برای سامانه در نظر گرفته شوند. حتی تغییرات ممکن است به دلایل درخواست افراد قانونی یا سطح بالاتر ایجاد شوند. همچنین ممکن است که فرصت‌های کسب و کاری جدیدی ایجاد شده باشند و لازم باشد برای عقب‌نماندن از رقبا، نیازهای جدید به سامانه افزوده شوند. برای مثال فرض کنیم رستورانی داشته باشیم که اطلاعات سفارش مشتریان را نگهداری می‌کند. این اطلاعات شامل شناسه سفارش، مشتری، وضعیت سفارش و مواردی که سفارش داده شده‌اند، می‌باشد. بدیهی است که همین مدل ساده برای نگهداری داده‌های سامانه در اکثر موارد توسط اکثر افراد پذیرفته می‌باشد و همچنین در بیش‌تر نیازمندی‌ها کافی و قابل توسعه می‌باشد. اما فرض کنیم که روزی مسئول کسب و کار تصمیم می‌گیرد که تا حد امکان هدر رفت‌های کسب و کاری‌اش را کاهش دهد. او به این نکته توجه می‌کند که یک سفارش می‌تواند در چهار وضعیت مختلف باشد: یک سفارش اخیرا ایجاد شده است (created)، این سفارش تحویل آشپزخانه برای آماده‌سازی شده است (prepare)، سفارش تحویل داده شده و مشتری رستوران را ترک کرده است (closed) یا این سفارش در هر کدام از مراحل قبلی پیش از تحویل به مشتری، به دلایل مختلفی لغو شده است و حتی جریمه در صورت نیاز دریافت شده است (canceled). مسئول کسب و کار می‌داند که اگر یک سفارش در مرحله‌ای که به آشپزخانه تحویل داده شده است، لغو شود باعث هدر رفت مواد غذایی می‌شود. (با این که شاید جریمه نیز دریافت شود اما به هر حال وقت آشپزخانه، مواد مصرفی و ... مورد استفاده قرار گرفته‌اند اما الان مشتری برای آن وجود ندارد) مسئول کسب و کار تصمیم می‌گیرد که پیش از شروع به کار و تصمیم‌گیری روی این موضوع، مقداری وضعیت جاری سامانه را بهتر بشناسد. او نیاز دارد تا نرخ رخداد این اتفاق، میزان هدر رفت، خسارت وارد‌شده و ... را در اختیار داشته باشد تا بتواند تصمیم دقیق‌تری بگیرد. به همین دلیل از طراحان سامانه‌ی نرم‌افزاری می‌خواهد که اطلاعات مربوط به مشتریان یک سال اخیر رستورانش را در اختیار او قرار دهند. اما در این وضعیت و با توجه به مدل ساده‌ای که ما در ابتدا در نظر گرفتیم، چگونه می‌توانیم نیازمندی کارفرما را پاسخ دهیم؟! ما باید بدانیم چه تعداد از سفارشات بعد از قرار گرفتن در وضعیت آماده‌شدن (prepare)، توسط مشتری لغو شده‌اند (cancel) و این در حالی است که ما همواره وضعیت نهایی سامانه یعنی لغو‌شدن یا بسته‌شدن درخواست را نگهداشت داشته‌ایم. در عمل راهی برای پاسخ‌گویی به این نیازمندی کارفرما در وضعیت فعلی با توجه به طراحی صورت‌گرفته وجود نخواهد داشت!با توجه به مثال بالا، شاید ما بدانیم که چگونه کسب و کار خود را در یک جهت خاص شروع کرده‌ایم، اما شما در طول زمان متوجه می‌شوید که داده‌ای که در حال جمع‌آوری است می‌تواند برای موارد دیگری نیز ارزشمند باشد. (مثلا گزارشات جدیدبرای تحلیل کسب و کار) به همین دلیل احتمالا کسب و کار به دنبال آن خواهد رفت که از این داده‌ها استفاده کند تا بتواند تصمیم‌های دقیق و بهتری بگیرد و درآمد یا سود بیش‌تری را به دست بیاورد.همچنین در طول زمان درک و فهم طراحان از سامانه و منطق‌های کسب و کاری دقیق‌تر خواهد شد. معمولا ما زمانی که شروع به ساخت یک سامانه‌ی کسب و کاری می‌کنیم، فهم و دانش ما در مورد آن سامانه خیلی دقیق و با جزییات تمام نیست. به عبارتی احتمالا ما تمامی نیازمندی‌های آینده مشتری بر روی سامانه و داده‌های جمع‌آوری شده را نمی‌شناسیم. اما زمانی که ما دامنه کسب و کاری را بهتر می‌شناسیم، زمانی که متوجه می‌شویم مشتریان چگونه می‌توانند از سامانه ما بهتر استفاده کنند، ما به دنبال آن خواهیم بود که با نیازهای جدید سازگار شویم. ما به دنبال آن خواهیم رفت که نیازمندی‌های جدید را در سامانه قرار دهیم، مدل‌های سامانه را گسترش بدهیم و ویژگی‌های جدید را به سامانه اضافه کنیم. اما یک مشکل اساسی در سامانه‌های مبتنی بر نگهداری وضعیت این است که ما تنها وضعیت کنونی را داریم. چگونه می‌توانیم نیازمندی‌ها و تغییرات مدل‌های کسب و کاری را روی داده‌های قدیمی اعمال کنیم؟!وجود مشکلات نرم‌افزاریمعمولا از دیگر مواردی که ما باید در نوشتن سامانه‌های نرم‌افزاری در نظر بگیریم این است که اماکن نوشتن برنامه‌ای بدون باگ، تقریبا کم هست. یعنی امکان وجود خطا در سامانه همواره وجود دارد اگر چه ما همواره تلاش می‌کنیم که با نوشتن تست، انجام تست در سطوح مختلف و ... از این مشکلات جلوگیری کنیم. زمانی که این خطاها رخ می‌دهند، برخی از این خطاها به این گونه هستند که شاید صرفا کابر خروجی اشتباهی را مشاهده کند اما خیلی راحت بعد رفع مشکل، کاربر خروجی درست را مشاهده کند. اما برخی از مشکلات می‌توانند منجر به ایجاد وضعیت اشتباه شوند. ممکن است به دلیل یک مشکل، کاربران ادمین سامانه بتوانند میزان درآمد ذخیره‌شده در بانک شخصی فرد را بدون دلیل تغییر دهند. قطعا این تغییر بعد از انجام‌شدن و کشف مشکل، حتی اگر در سامانه رفع شود (امکان این قابلیت از ادمین سامانه سلب شود) اما تشخیص این که چه کسانی از این مشکل اثر دیده‌اند، در عمل ممکن نباشد. حتی گاهی ممکن است کد اشتباهی نوشته شود که به اشتباه بعد از قرار گرفتن در محیط و اجرا شدن، وضعیت داده‌ها را خراب کند. (مثلا فیلد درآمد هر کارمند را صفر کند) شاید بتوان این کد را اصلاح کرد، اما اکنون بازگرداندن وضعیت داده‌ها بدون وجود پشتیبان (backup) از سامانه ممکن نیست. همچنین در صورت وجود پشتیبان، احتمالا داده‌ی پشتبانی مربوط به چند هفته یا ماه اخیر خواهد بود و وضعیت کنونی کاربران مشخص نیست. تمامی توضیحاتی که در بالاتر توضیح داده شده‌اند، نشان می‌دهد که نگهداری وضعیت کنونی سامانه چه مشکلاتی را می‌تواند به دنبال داشته باشد. در واقعیت وضعیت کنونی تنها مشخص‌کننده‌ی مقدار پارامترها و ویژگی‌ها در زمان حال هست و هیچ‌گونه نمی‌توان از طریق آن، تاریخچه‌ای که سبب شده است به خاطر آن در این وضعیت قرار گرفته‌ایم را مشخص کنیم. در هر دو مثال‌های بیان شده اگر ما می‌دانستیم که چگونه به وضعیت جاری رسیده‌ایم، رفع مشکل سامانه کار سختی نبود. همچنین نیازمندی‌های جدید همواره می‌توانند تاثیرات خود را بر روی وضعیت جاری و آینده بگذارند و در اکثر موارد ما نمی‌توانیم وضعیت جدید را برای داده‌های قدیمی اعمال کنیم. (مگر این که بتوانیم مقادیر پیشفرضی را برای ویژگی‌های اضافه‌شده برای داده‌های قدیمی قرار دهیم)به همین دلیل ما به دنبال این هستیم که روشی جایگزین را برای روش‌های مبتنی برای نگهداری وضعیت معرفی کنیم که در آن‌ها برای مشکلات بالا راه‌حل‌هایی ارائه می‌شود. البته هر چیزی به رایگانی به دست نمی‌آید. (در غیر این صورت همه امروز از روش‌های جدید‌تر استفاده می‌کردند) هر روشی معمولا مزایا و معایبی که دارد که تصمیم به استفاده از آن به موقعیت و نیازمندی‌های کسب و کاری بر می‌گردد و باید به صورت جداگانه توسط هر کسب و کاری مشخص شود. منبع‌کردن رویدادنگهدار منتبی برای وضعیت، اگر چه یک رویکرد عمومی مناسبی هست اما دارای محدودیت‌هایی می‌باشد. به همین دلیل ما به دنبال آن هستیم که به روش‌هایی این محدودیت‌ها را رفع یا کاهش دهیم. یکی از روش‌های معروف در این زمینه، منبع‌کردن رویدادها (event sourcing) می‌باشد. یک روش ساده که معمولا برای رفع این مشکل می‌توان در نظر داشت این است که ما در کنار وضعیت برنامه که نگهداری می‌کنیم، وضعیت وقایع رخ‌داده در برنامه را نیز به صورت جداگانه ثبت نماییم. این حسابرسی وضعیت یا وقایع رخ‌داده (audit log) می‌توانند به شکل‌های مختلفی مثل یک فایل متنی ساده، جداولی در پایگاه‌داده و ... ذخیره شوند. در واقعیت با این کار وضعیت و تاریخچه‌ی تمامی رخدادهای سامانه را که منجر به رسیدن به وضعیت کنونی سامانه می‌شوند، نگهداری می‌شود. با وجود این لاگ‌ها، ما به راحتی می‌توانیم در هر زمان وضعیت کنونی را بر اساس رخدادهای صورت‌گرفته دوباره ایجاد کنیم و همچنین در صورت نیاز، وضعیت کنونی را اصلاح کنیم. کافی است در صورتی که مشکلی را در وضعیت کنونی پیدا کردیم، از طریق لاگ‌های ذخیره‌شده در زمان عقب برویم تا بفهمیم که علت رخداد مشکل چه بوده است، مشکل را رفع کنیم و دوباره وضعیت جدید و درست را ایجاد کنیم. همچنین مزیت دیگر این روش این است که ما می‌توانیم در هر زمان منطق‌های کسب و کاری را توسعه دهیم و در عین حال به دلیل داشتن تمامی وقایعی که در گذشته رخ داده‌اند، وقایع را متناسب با تغییرات جدید به درستی مدیریت کرده و وضعیت کنونی درست را ایجاد کنیم. همان‌طور که مشاهده می‌کنیم روش جدید به شکل خیلی خوبی محدودیت‌های ما در سامانه‌های مبتنی بر نگهداری وضعیت را حل می‌کنند. همچنین این نوع سامانه‌ها معمولا با روش‌های برنامه‌نویسی functional بسیار همخوان هستند که البته فعلا بحث مطالب این قسمت نبوده و صرفا به آن اشاره شد. با این که این روش محدودیت‌های ما را در نیازمندی‌های قبلی بر طرف نمود، اما در عین حال مشکلات و چالش‌های جدیدی را نیز برای ما ایجاد کرد. چالش منبع حقیقیبه عنوان ساده‌ترین مثال، نکته‌ی اول این است که اگر لاگ و اطلاعات وضعیت سیستم به دلایلی با یکدیگر هماهنگ نباشند، کدام یک را باید به عنوان منبع حقیق (true source) در نظر بگیریم؟ ممکن است به عنوان مثال باگی در سامانه وجود داشته باشد که گاهی مواقع وضعیت برنامه را خراب می‌کند اما در لاگ‌های سامانه مشکلی ایجاد نمی‌کند یا برعکس. پاسخ به این سوال معمولا این‌گونه بیان می‌شود که چون وضعیت، اطلاعات کافی برای ساخت دوباره‌ی لاگ را ندارد، نمی‌تواند به عنوان منبع حقیقی انتخاب شود. انتخاب لاگ به عنوان انتخاب منبع همواره مثل برنامه‌های قدیمی که مبتنی بر نگهداری وضعیت بودند، این ریسک را دارد که اگر لاگ‌ها به اشتباهی ذخیره شوند، هم لاگ‌ها و هم وضعیت ساخته‌شده بر اساس آن‌ها مشکل خواهد داشت. اما نکته این هست که احتمال خطا در ذخیره‌سازی یک لاگ کمتر از حتمال خطا در نگهداری وضعیت است.چالش تغییر واحدیکی دیگر از مشکلاتی که در این نوع روش دیده می‌شود، بستگی به این دارد که ما به چه روش و فرمتی، داده‌های مربوط به لاگ را ذخیره نماییم. این تصمیم می‌تواند سبب مشکلات تراکنش (transaction) شود. اگر به عنوان مثال اطلاعات مربوط به لاگ در درون یک فایل یا یک پایگاه داده متفاوت از پایگاه داده وضعیت قرار بگیرد، ما در هنگامی که بخواهیم از مفاهیم تراکنش در سطح پایگاه داده استفاده کنیم، دچار مشکل می‌شویم. (علت مشکل این است که ما در یک تراکنش نمی‌توانیم اطلاعات دو پایگاه داده‌ی مختلف یا یک فایل و پایگاه‌داده‌ی معمولی را همزمان بروزرسانی کنیم). اگر هم فرض کنیم که هر دو را در درون یک پایگاه داده یکسان قرار می‌دهیم، مشکلاتی مثل این که تمامی وضعیت‌های سامانه باید همگی در یک پایگاه داده باشند (وابستگی بین مولفه‌ها)، باگ‌های نرم‌افزاری ممکن است موجب تاثرگذاشتن بر روی داده‌های وضعیت یا لاگ شوند و خیلی اتفاقات متنوع دیگر را باید مورد بررسی قرار دهیم. معمولا در روش منبع‌کردن داده، دیگر وضعیت سامانه نگهداری نمی‌شود و فقط لاگ‌ها نگهداری می‌شوند. به عبارتی ما همواره می‌توانیم وضعیت را از روی لاگ در صورت اجرای دوباره‌ی برنامه بسازیم و وضعیت کنونی را هم در مموری نگه داریم.یک نکته که باید در نظر گرفت این است که اگر به هر دلیلی برنامه متوقف شود و لازم باشد از نو اجرا شود، ما نیاز داریم که تمامی لاگ‌ها را بررسی کنیم تا به وضعیت کنونی برسیم. به عبارتی باید وضعیت ابتدایی را در نظر بگیریم و تمامی لاگ‌ها را روی آن اعمال کنیم تا به وضعیت کنونی برسیم. البته دقت شود که در اجرای لاگ‌ها، تاثیرات جانبی را در نظر نگیریم. (مثلا ارسال اطلاعیه به همه بازیکنان با اضافه‌شدن یک بازیکن به بازی) این کار ممکن است در برخی مواقع صرفا تعداد کمی لاگ باشد اما در مواقعی نیز حجم لاگ‌ها بسیار زیاد است. در چنین مواقعی زمان اجرای برنامه بسیار افزایش پیدا می‌کند. معمولا رویکردی که در این مواقع استفاده می‌شود، استفاده از تصویر لحظه‌ای (snapshot) است.تصویر لحظه‌ای به معنای نگهداری وضعیت کنونی نیست بلکه در بازه‌‌های زمانی مشخصی، وضعیت خوانده‌شدن لاگ‌ها تحت عنوان یک وضعیت در زمانی خاص ذخیره می‌شود. در این صورت در صورت نیاز به اجرای دوباره‌ی برنامه، تنها تصویر لحظه‌ای را می‌خوانیم و سپس تمامی رویدادهای بعد از آن را اجرا می‌کنیم تا به وضعیت جاری برسیم. به همین دلیل در ازای مقداری فضا، سرعت بارگزاری برنامه افزایش پیدا می‌کند. دقت شود که این تصویرهای لحظه‌ای تنها برای بهبود کارایی در مواقع خاص هستند در حالی که در اکثر موارد نیاز به آن‌ها جدی نمی‌باشد. البته این روش، چالش‌های دیگری مثل میزان فضای لازم برای نگهداری را نیز به دنبال خواهد داشت. به همین دلیل شاید در اکثر موارد لازم باشد در طول زمان لاگ‌ها را فشرده کرد و تنها لاگ‌ها را تا بازه‌ی زمانی خاص (مثلا یک یا دو سال) نگهداری کرد. نتیجه‌گیریاستفاده از روش منبع‌کردن رویداد‌ها مزیت‌های فراوانی را برای ما فراهم نمود. یکی از مهم‌ترین مزیت‌های این روش وجود کلیه‌ی وقایع سامانه به صورت ثبت‌شده می‌باشد. حتی گاهی به دلایل امنیتی و ...، از نیازمندی‌های سامانه ثبت وقایع می‌باشد که این روش به صورت خودکار آن را ارائه می‌دهد. همچنین این روش این امکان عجیب را فراهم می‌کند که ما بتوانیم در زمان به عقب بازگردیم! معمولا پایگاه‌داده‌های خاصی وجود دارند که برای عملیات تنها اضافه‌شدن رکورد ساخته شده‌اند که برای این روش نیز بسیار کاربردی هستند. با این حال همان‌طور که گفته‌شد پیاده‌سازی این روش بدون پرداختن یکسری هزینه‌ها نخواهد بود و به همین دلیل تصمیم به انجام این کار باید بر اساس نیاز‌های کسب و کاری مشخص شود. این مطلب، بخشی از تمرین‌های درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است.منابعReactive Architecture(6): CQRS & Event Sourcing امین برجیان امین برجیان Mon, 06 Dec 2021 22:32:56 +0330 https://virgool.io/@borjianamin98/%D9%85%D8%AF%D9%84-c4-%D8%A8%D8%B1%D8%A7%DB%8C-%D8%AA%D8%AC%D8%B3%D9%85-%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-oyvqsrurjigz سایمون براون (Simon Brown) سازنده طرح C4 (منبع عکس)مقدمهوقتی یک خانه ساخته می‌شود، نقشه‌های مختلفی از ساختمان تهیه می‌شوند که هر کدام از این نقشه‌ها برای مخاطبان خاصی هستند و از زاویه‌های مختلفی به ساختمان نگاه می‌کنند. اطلاعات مختلفی در هر کدام از این نقشه‌ها نهفته شده است و هیچ‌کدام از آن‌ها به تنهایی ساختمان را توصیف نمی‌کنند. از جمله این نقشه‌ها مثلا نقشه‌ی لوله‌کشی ساختمان، برق‌کشی ساختمان، طراحی فضاهای ساختمان و ... می‌باشد. هر کدام از این موارد در جای خود مفید خواهند بود و بدون وجود آن‌ها، قطعا در زمان نیاز دچار مشکل خواهیم شد. اگر چه که یک ساختمان دارای نقشه‌های مختلفی می‌باشد که از زاویه‌های مختلف به آن نگاه می‌کنند، اما هر نقشه خود دارای جزییاتی است که سطح این جزییات نیز خود مسئله‌ی مهمی است. به عنوان مثال وقتی ما به بنگاه املاک مراجعه می‌کنیم، به صورت کلی مشخصات ساختمان را می‌گوییم مثل آپارتمانی یا هم‌کف، تعداد طبقه، تعداد اتاق‌ها و .... در صورتی که نقشه‌ی طراحی یک ساختمان وقتی مشاهده می‌شود جزییات فراوانی از جمله وضعیت شیشه‌ها، اندازه‌ی دیوارها، جهت بازشدن درها و ... را مشاهده می‌کنیم. قطعا وجود این جزییات برای مخاطبان خاص آن مهم است مثل مهندس ساختمان. اما برای افرادی نیز این حد جزییات لازم نیست و بیش‌تر به دنبال طرح کلی ساختمان هستند. مثالی که سایمون برای میزان جزییات یک طرح بیان می‌کند، نقشه است! احتمالا زمان‌هایی بوده که ما نیاز به نقشه داشته‌ایم. گاهی در این نقشه‌ها به دنبال آن بوده‌ایم که دقیقا موقعیت خیابان‌ها، کوچه‌ها و مکان‌های مهم را مشاهده کنیم. گاهی نیز به دنبال آن بوده‌ایم که کلیه‌ی مکان‌های مهم یک شهر یا استان را مشاهده کنیم. گاهی نیز به دنبال تعیین مسیری برای سفر از یک شهر به شهر دیگر بوده‌ایم و در مقیاس کشور به نقشه نگاه کرده‌ایم. گاهی نیز به دنبال کشورها و موقعیت‌های آن در جهان بوده و به نقشه‌ی کره‌ی زمین نگاه کرده‌ایم. تمامی این کارها را به سادگی با کوچک‌نمایی یا بزرگ‌نمایی نقشه انجام می‌شوند و در هر زمان متناسب با نیاز، از میزان بزرگ‌نمایی مناسب استفاده می‌شود. آیا ما نمی‌توانیم از نقشه ایده بگیریم و طرح‌های معماری را نیز به همین شکل طراحی کنیم؟!آیا روش‌های استاندارد برای طراحی معماری کافی نیست؟نمونه‌ای از طرح معماری (منبع عکس)احتمالا افراد زیادی هستند که حتی اگر از UML (Unifed Modeling Language) استفاده نکردند، نام آن را شنیده باشند. این روش، زمانی به عنوان یک روش استاندارد برای طراحی و مستند‌سازی معماری در نظر گرفته می‌شد اما در طول زمان با روی کار آمدن روش‌های چابک و محدودیت‌های این روش، کم کم سازمان‌ها به این نتیجه رسیدند که تعدادی «خطوط و جعبه» برای توصیف معماری کافی است! اگر چه واقعا شاید مقداری شکل و شمایل برای توصیف معماری کافی باشد و کنار گذاشتن یکسری استاندارهای دست و پا گیر (مثل UML) برای به دست آوردن چابکی خوب باشد، اما بسیاری از تیم‌ها با استفاده از روش‌های جدید از نظر ارتباطی دچار مشکل شده‌اند. کافی است که طرح معماری دو تیم مختلف یا سازمان مختلف را جابه‌جا کنیم و از هر سازمان بخواهیم که معماری سازمان دیگر را توصیف کنند. در این وضعیت به احتمال زیاد مشکل اصلی را مشاهده خواهیم کرد.اگر اکثر طرح‌های کنونی را که برای توصیف معماری استفاده می‌شوند مشاهده کنیم، معمولا نشانه‌گذاری‌هایی را مشاهده می‌کنیم که بین طرح‌های مختلف متفاوت هستند مثل رنگ‌ها، شکل‌ها و خطوط مختلف، نام‌گذاری‌های مبهم، روابط بدون نام یا مبهم بین موجودیت‌ها، واژگان عمومی. اگر همین الان به گوگل مراجعه کنید و در مورد نمونه طرح معماری در تصاویر جستجو کنید، حجم زیادی از تصاویر را در رنگ‌ها و شکل‌ها مختلف مشاهده می‌کند که حتی بعد از بررسی آن‌ها، از طریق خود عکس نمی‌توانید در یک نگاه معماری را متوجه شوید و احتمالا مجبور می‌شوید حجم زیادی از توضیحات را بخوانید تا معماری را درک کنید. در کنار این موارد، گاهی ما به دنبال معماری کلی و گاهی معماری با جزییات فراوان هستیم و معمولا این نیز مشکل دیگری در طرح‌های کنونی معماری سازمان‌ها می‌باشد. مدل C4مدل C4 در نگاه سطح بالا (منبع عکس)مدل C4 به‌عنوان روشی برای کمک به تیم‌های توسعه برای توصیف‌کردن و تعامل و صحبت در مورد معماری نرم‌افزار، هم در جلسات طراحی اولیه و هم هنگام مستندسازی ایجاد شده است. به عبارتی این روش به ما کمک می‌کند تا برای کد خود نقشه‌هایی را در سطوح مختلف با جزئیات مختلف طراحی کنیم به همان روشی که از چیزی مانند نقشه‌های گوگل برای بزرگ‌نمایی و کوچک‌نمایی منطقه‌ای که به آن علاقه داشتیم استفاده می‌کردیم. اگرچه هدف اصلی طراحی این مدل، استفاده‌شدن توسط معماران و توسعه‌دهندگان نرم‌افزار است، مدل C4 راهی را برای تیم‌های توسعه نرم‌افزار فراهم می‌کند تا به طور کارآمد معماری نرم‌افزار خود را در سطوح مختلف از جزئیات بیان کنند. سطوحی که هر کدام از آن‌ها توضیحات مختلف برای انواع مختلف مخاطب (تیم تست، تیم توسعه، کارفرما و ...) فراهم می‌کنند. در کنار جزییات مختلفی که هر کدام از این سطوح فراهم می‌کنند، افراد تیم‌ها می‌توانند با زبانی مشترک با یکدیگر تعامل کنند بدون این که درگیر جزییات اضافه شوند. مدل C4 برخلاف توضیحات و معایبی که برای روش‌های قدیمی مثل UML گفتیم، یک روش مبتنی بر «نشانه‌گذاری» نیست. به عبارتی قرار نیست در این روش برای توصیف هر موجودیت روش خاصی را مشخص کنیم و علایم و نگارش‌های مختلفی را به صورت یکسان در همه‌جا اعمال کنیم. این روش از رویکرد «انتزاع» برای نمودارسازی معماری نرم‌افزار استفاده می‌کند. انتزاع‌هایی که نشان می‌دهد معماران و توسعه‌دهندگان نرم‌افزار چگونه در مورد نرم‌افزاری که طراحی می‌کنند، فکر می‌کنند و یا چگونه آن را می‌سازند. در واقعیت در این روش، ما مجموعه کوچکی از انتزاع‌ها و انواع نمودارها را داریم که یادگیری و استفاده از مدل C4 را بسیار آسان می‌کند. دیگر قرار نیست که ما قواعد و نشانه‌گذاری‌های فراوانی را مشخص و تعریف کنیم. البته نکات و کلیت‌هایی در انتها به عنوان پیشنهاد چگونگی طراحی نمودارها بیان می‌شود که در حد توصیه هستند برای این که طراح‌ها مفید‌تر باشند اما هیچ‌گونه شیوه‌ی رسم‌کردن خاصی (مثل چگونگی علامت‌ها، خطوط، جعبه‌ها و ...) اجبار نمی‌شود. در ادامه خواهیم دید که در مدل C4 ما از چهار نمودار برای مجسم‌سازی سطوح مختلف معماری استفاده خواهیم کرد. توجه به این نکته نیز مهم است که نیازی به استفاده از هر چهار سطح نمودار نیست. این نمودار تعریف می‌شوند اما فقط آن‌هایی که ارزش اضافه می‌کنند، برای بسیاری از تیم‌های توسعه نرم‌افزار کافی هستند. به عنوان مثال احتمالا نمودارهای System Context و Container (در ادامه آشنا می‌شویم) برای بسیاری از تیم‌ها کافی هستند. همچنین به احتمال زیاد نمودار Code برای اکثر تیم‌های توسعه غیرالزامی هستند و می‌توانند از طریق ابزارهای خودکار در این زمینه تولید شوند. انتزاع‌های مدل C4انتزاع‌های مدل C4 (منبع عکس)برای ایجاد سطوح مختلفی از کد که در بخش قبلی توضیح داده شدند، ابتدا به مجموعه‌ای از انتزاع‌های مشترک نیاز داریم تا همه افراد از این زبانی مشترک برای توصیف ساختار ایستای سامانه نرم‌افزاری استفاده کنند. مدل C4 ساختارهای ایستا یک سامانه نرم‌افزاری را از چهار نظر زیر مورد بررسی قرار می‌دهد:سامانه نرم‌افزاری (software system)ظرف (container)مولفه (component) کد (code)فرد (person)هر کدام از موارد بالا نماینده‌ی موارد خاصی هستند که در ادامه هر کدام را توصیف می‌کنیم اما همان‌طور که از طریق تصویر مشخص است، به صورت ساختاری هر سامانه نرم‌افزاری (software system) دارای یک زمینه (context) می‌باشد و افرادی حقیقی یا غیر حقیقی (person) از آن استفاده می‌کنند. این سامانه از مجموعه‌ای از ظروف (containers) تشکیل شده است. هر کدام از این ظروف حاوی یک یا چندین مولفه (component) هستند که هر کدام از آن‌ها نیز از مجموعه‌ای از کدها (code) تشکیل شده‌اند. ممکن است مفاهیم بالا را در زمینه و نرم‌افزارهای دیگر مشاهده کرده باشید اما تعاریف هر کدام از موارد بالا به صورت خاص توسط مدل C4 مشخص شده است. مثلا اکثر افراد با شنیدن «ظرف» احتمالا مفاهیم داکر و ابزارهای مشابه در این زمینه را به یاد می‌آورند اما مفهوم آن در مدل C4 کاملا متفاوت و خاص آن می‌باشد. حتی عده‌ای نیز با شنیدن «مولفه» معادل‌هایی را برای آن در زبان‌های برنامه‌نویسی مختلف مثل جاوا یا C# به یاد می‌آورند در حالی که زبان‌هایی هم هستند که برای این مفاهیم، اسم‌های دیگری دارند یا معادلی ندارند. با این حال تعریف «مولفه» کاملا خاص مدل C4 هست و نباید با این موارد اشتباه گرفته شود. به همین دلیل بیش از این که با نمودارهای مربوط به C4 آشنا شویم، ابتدا هر کدام از انتزاع‌های بالا را بررسی می‌کنیم.فردیک فرد نماینده‌ی استفاده‌کنندگان سامانه می‌باشد. این فرد می‌تواند یک فرد حقیقی یا مجموعه‌ای از افراد باشند یا حتی گاهی یک ماشین خودکار باشد که از سامانه‌ی نرم‌افزاری استفاده می‌کند. سامانه نرم‌افزارییک سامانه نرم‌افزاری یک انتزاع سطح بالا می‌باشد و توصیف‌کننده چیزی می‌باشد که ارزشی را به کاربران خود (خواه انسان باشند یا نباشند)، ارائه می‌کند. یک سامانه نرم‌افزاری همیشه به صورت منفرد نیست و احتمال بسیار زیاد در تعامل با سامانه‌های نرم‌افزاری دیگری به اهداف خود می‌رسد. این سامانه‌های نرم‌افزاری ممکن است همگی توسط یک تیم توسعه داده شده باشند یا این که توسط تیم‌های مختلفی توسعه داده شده باشند. ظرفدر مدل C4، یک ظرف نماینده‌ی یک برنامه یا مخزن ذخیره داده می‌باشد. در واقعیت ظرف چیزی است که لازم است اجرا شود تا کل سامانه بتواند به درستی عمل کند. اما اگر به خواهیم به صورت جزئی‌تر آن را بیان کنیم هر چیزی مانند برنامه‌های سمت سرور یا سمت کلاینت، برنامه‌های موبایل، برنامه‌های کنسولی، پایگاه‌های داده یا یک پوشه یا فایل در فایل سیستم، یک اسکریپ و ... نماینده ظرف می‌باشد. یک ظرف در اصل یک جعبه‌ای است که در داخل آن برخی از کدها (به صورت تک برنامه یا مجموعه‌ای از نخ‌های موازی) اجرا شده یا برخی از داده‌ها ذخیره می‌شود. هر ظرف را نیز می‌توان به عنوان موجودیت زمان اجرا که به طور جداگانه قابل استقرار یا اجرا است، در نظر گرفت. مولفهمولفه مجموعه‌ای از عملکردهای مرتبط است که در پشت یک رابط تعریف‌شده قرار می‌گیرند. به عبارتی مجموعه‌ای از کلاس‌های پیاده‌سازی که به منظور پیاده‌سازی یک هدف نوشته شده‌اند و این هدف را از طریق یک رابطی مثل ارتباط شبکه‌ای یا فایلی یا ... فراهم می‌کنند، مولفه گفته می‌شود. جنبه‌هایی مانند نحوه بسته‌بندی آن مولفه‌ها (مثلا به فرمت JAR یا DLL یا ...) یک بحث جدا است. نکته مهمی که در اینجا باید به آن توجه کرد این است که همه اجزای داخل یک ظرف معمولا در یک فضای پردازش یکسان اجرا می‌شوند. در مدل C4، «مولفه‌»ها به طور جداگانه واحدهای قابل استقرار نیستند. (مثلا مجموعه‌ای از کلاس‌ها که در درون back-end یک سرور قرار گرفته و بحث مدیریت سفارش‌ها را (از میان کلیه‌ی دیگر فرایند‌های یک رستوران) انجام می‌دهد، یک مولفه است چون این بخش به صورت جدا قابل استقرار و اجرا نیست و در هنگام استقرار ظرف back-end اجرا می‌شود. نمودارهای اصلیاکنون که با انتزاع‌های مختلف در مدل C4 آشنا شدیم، در ادامه با ایجاد مجموعه‌ای از نمودارهای مختلف در بحث زمینه (context)، ظرف (container)، مولفه (component) و به صورت اختیاری کد (code) (به عنوان مثال کلاس UML) انجام می‌شود. نام مدل C4 نیز از همین نمودارها نشات گرفته است. برای بیان مثال و فهم بهتر مطالب، سامانه‌ای را نیز برای بررسی مشخص می‌کنیم. سامانه‌ی بانکداری به عنوان نمونه توسط سایمون در هنگام معرفی مدل C4 بیان شده است که توضیحات و نمودارهای آن به صورت کامل می‌باشند. در ادامه ما نیز از همین سامانه به عنوان نمونه استفاده می‌کنیم. نمودار زمینه سیستمنمودار زمینه سامانه بانکداری (منبع عکس)نمودار زمینه (context) به عنوان شروع برای مجسم‌سازی و مستندسازی سامانه نرم‌افزاری محسوب می‌شود. این نمودار در واقعیت یک دید کلی از سامانه هدف و تمامی تعاملات آن با سامانه‌های دیگر (خواه همان تیم توسعه داده باشد یا تیم‌های دیگر) ارائه می‌دهد. بهتر است در رسم این نمودار، سامانه‌ی نرم‌افزاری هدف به صورت یک جعبه در میان صفحه قرار گرفته و بقیه سامانه‌ها و تعاملاتشان با سامانه‌ی ما در اطراف آن قرار بگیرند. همچنین پیشنهاد می‌شود که همین ساختار را در هنگام بزرگنمایی و رسم دیگر سطوح مدل C4، حفظ نمایید تا استفاده از نمودارها تسهیل شود. دقت شود در این نمودار بیان جزییات سامانه، تکنولوژی‌های استفاده شده، پروتکل ارتباطی بین سامانه‌ها و ... اهمیت ندارند و در صورت نیاز، باید از دیگر نمودارها استفاده شود. در این نمودار تمرکز تنها باید بر روی افرادهایی باشند که از سامانه استفاده می‌کنند، سامانه‌هایی که از سامانه‌ی ما داده‌ای را دریافت یا ارسال می‌کنند. این نمودار بهترین نمودار برای نشان‌دادن به افراد غیرفنی می‌باشد. نمودار ظرف‌هانمودار ظرف سامانه بانکداری (منبع عکس)بعد از رسم‌شدن نمودار زمینه و مشخص‌شدن سامانه و تعاملات آن با دیگر سامانه‌ها، باید سامانه را بزرگنمایی کنیم و تمامی ظروف (containers) آن را رسم کنیم. تعریف مربوط به ظروف را در بخش‌های قبلی مشاهده کردیم و در این قسمت از بیان دوباره آن خودداری می‌کنیم. با نگاه به عکس بالا می‌توانید می‌توانید مثال‌های عملی آن را مشاهده کنید.نمودار ظرف شکل و ساختار سطح بالای معماری نرم‌افزار و نحوه توزیع بخش‌های مختلف سامانه را به منظور رسیدن به هدف نهایی سامانه نشان می‌دهد. همچنین تلاش می‌شود در این نمودار، تکنولوژی‌های اصلی انتخاب‌شده برای پیاده‌سازی بخش‌های مختلف و نحوه ارتباط ظروف (استفاده از API، پایگاه‌داده، صف و ...) با یکدیگر نشان داده شود. این نمودار در عین ساده‌بودن، با تمرکز بر معماری به صورت سطح بالا است که برای توسعه‌دهندگان نرم‌افزار و کارکنان بخش پشتیبانی سامانه مفید است.نمودار زمینه و ظروف، جزو پرکاربردترین نمودارها هستند که در اکثر سازمان‌ها و تیم‌ها می‌تواند مفید واقع شود. اکثرا نمودارهای دیگر بسیار کم استفاده می‌شوند اما این دو نمودار توضیح داده‌شده جزو مهم‌ترین نمودارها هستند.نمودار مولفه‌هانمودار مولفه‌های سامانه بانکداری (منبع عکس)در نمودار مولفه‌ها (components)، هر ظرف را بزرگ‌نمایی می‌کنیم و بیشتر تجزیه می‌کنیم تا بخش‌های اصلی و تعاملات آن‌ها را شناسایی کنیم. (دقت شود این بخش‌ها همگی در داخل ظرف هستند و به صورت جداگانه قابل اجرا نیستند) معمولا همه چیز به صورت یک جسم متمرکز (monolithic) نیست و بخش‌های مختلف در یک سامانه دیده می‌شود. نمودار کامپوننت نشان می‌دهد که چگونه یک ظرف از تعدادی «بخش‌های معنی‌دار» تشکیل شده است، هر یک از آن اجزا چیست و فعالیت‌های آن‌ها و تکنولوژی آن‌ها چیست.نمودار کدنمودار کد برای یکی از بخش‌های سامانه بانکداری (منبع عکس)در نهايت، در نمودار کد برای یک مولفه، ما پیاده‌سازی آن را تصویر می‌کنیم. معمولا برای این قسمت از نمودار معروف UML استفاده می‌شود که این نمودار هم توسط محیط‌های توسعه‌دهنده‌ی فراوانی پشتیبانی می‌شود و به راحتی از طریق کد، قابل خروجی گرفتن است. به همین دلیل در اکثر موارد نیاز به این نمودار نیست و نمودارهای دیگر کافی هستند. البته اگر چه ابزارهای مختلف توانایی رسم این نمودار را به صورت خلاصه دارند، اما باید در این نمودار تا حد امکان تنها کلاس‌ها و کدهایی را قرار دهیم که داستان اصلی آن مولفه را بیان می‌کنند. مثلا رسم کلاس‌های کاربردی (utility) یا پیاده‌سازی‌های مختلف یک واسط (interface) در اکثر موارد لازم نیست.نشانه‌گذاری‌هاهمان‌طور که در ابتدای توضیحات بیان شد، در نمودارهای بالا ما از روش یا قواعد نمایشی خاصی برای رسم نمودارها استفاده نکردیم. این از مزیت‌های مدل C4 می‌باشد. با این حال سازنده‌ی این طرح، تعدادی پیشنهاد برای رسم بهتر نمودارها ارائه می‌دهد. در پایان، تعدادی از این پیشنهادات را به صورت خلاصه بیان می‌کنیم:حتما برای تمامی نمودارها عنوانی تعیین شود که در آن ابتدا نوع نمودار و سپس توضیحی خلاصه‌ای فراهم شود. بهتر است اگر ترتیب نمودارها مهم است، نام نمودارها شماره‌گذاری شود. تلاش شود که نمودارهای مختلف از نظر علائم و اشکال و رنگ‌بندی استفاده‌شده یکسان باشند.در بیان هر کدام از جعبه‌های در نمودارهای مختلف بهتر است حداقل نام آن عنصر، تکنولوژی آن (اگر مفید است) و توضیح خلاصه‌ای فراهم شود. تلاش شود از خطوط یک‌طرفه برای رسم نمودارها استفاده شود و بر روی هر خط، حتما توضیح خلاصه‌ای از معنای ارتباط رسم‌شده بیان شود.تمامی شکل‌ها (دایره، مستطیل، ...)، شیوه‌ی رسم خطوط، رنگ‌ها، حاشیه‌ها و ... حتی اگر در ظاهر بدیهی هستند، در پایین نمودارها توصیف شوند. این مطلب، بخشی از تمرین‌های درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است.منابعWikipedia C4 ModeThe C4 model for visualizing software architectureInfoQ C4 Model ArchitectureVisualizing software architecture with the C4 model - Agile on the Beach 2019Visualize, document and explore your software architecture - Simon Brown امین برجیان امین برجیان Sat, 13 Nov 2021 21:53:00 +0330