https://virgool.ir/feed/@m_97260858fa2026-11-12 02:33:56https://virgool.ir/images/default-avatar.jpghttps://virgool.ir/@m_97260858https://virgool.ir/@m_97260858/بررسی-مطالعات-انجام-شده-در-حوزه-شبکه-زمانی-papmpfidhxuuچکیدهشبکه پیچیده یکی از انواع شبکه‌هاست که به کمک ساختار گرافی می‌توان موجودیت‌ها و تعاملات بین آنها را نمایش داد. یکی از انواع شبکه‌های پیچیده، شبکه زمانی است که پویایی دارد و به کمک آن می‌توان زمان را هم در شبکه‌های پیچیده در نظر گرفت. در واقع شبکه زمانی نوعی شبکه پیچیده است که در طول زمان تغییر کرده و یا تکامل می‌یابد. از انواع شبکه‌های زمانی می‌توان به شبکه مغز، شبکه ترافیک و ... اشاره کرد. به دلیل ویژگی زمانی و تکامل آن، نحوه تولید و بررسی شبکه‌های زمانی با سایر انواع شبکه متفاوت است. بنابراین نیاز به ارائه روش‌های خاصی در این زمینه است که بتوان با استفاده از ویژگی‌های زمانی تحلیل و بررسی این شبکه‌ها را انجام داد. در این نوشتار به مرور برخی از کارهای انجام شده در حوزه شبکه زمانی پرداخته شده است و هدف از انجام این مطالعه، بررسی مطالعات شبکه‌های زمانی به ویژه با رویکرد مدل‌های یادگیری عمیق است.کلمات کلیدی: شبکه پیچیده، شبکه زمانی، مدل تولید گراف1- مقدمهشبکه‌های زمانی یکی از انواع شبکه‌های پیچیده‌اند که پویایی دارند. به عبارت دیگر هر یال در این شبکه در زمان خاصی وجود داشته و فعال است. مثال‌های زیادی از این نوع شبکه در دنیای واقعی وجود دارد که شامل شبکه انتشار (بیماری، اطلاعات، ویروس کامپیوتری و ...)، شبکه مغز، شبکه حمل و نقل (به خصوص شبکه ترافیکی) و ... هستند. در واقع می‌توان گفت که این شبکه‌ها در طول زمان تکامل یافته یا تغییر می‌کنند. برای مثال می‌توان از این شبکه برای پیش‌بینی وضعیت آینده ترافیک یا احتمال ابتلای فرد به آلزایمر و ... استفاده کرد. پس مطالعه شبکه‌های زمانی از اهمیت بالایی برخوردار است.به صورت کلی کارهای انجام شده در حوزه شبکه پیچیده را می‌توان در دو گروه یادگیری توزیع شبکه و تولید آن یا تحلیل و پیش‌بینی الگوها در شبکه تقسیم‌بندی کرد. تحلیل و پیش‌بینی الگوهای شبکه بسیاری از حوزه‌های تحقیقاتی از جمله رده‌بندی گره، رده‌بندی یال، رده‌بندی گراف و پیش‌بینی یال، تشخیص انجمن‌ها و ... را پوشش می‌دهد.یکی دیگر از مسائل موجود در رابطه با شبکه‌های پیچیده، مدلی برای تولید آنهاست. به علت اینکه اطلاعات بسیاری از شبکه‌های موجود در دسترس نیستند، نیاز به سنتز و تولید شبکه‌های مصنوعی است تا بتوان از آنها در شبیه‌سازی، ارزیابی و حل مسائل موجود استفاده کرد. از آنجایی که هدف اصلی این پروژه مطالعه شبکه‌های زمانی است، به بررسی روش‌هایی برای تحلیل و پیش‌بینی و مدل‌هایی برای تولید شبکه‌های پیچیده زمانی پرداخته خواهد شد.2- ادبیات پژوهشی2- 1- شبکه زمانیشبکه‌های پویا که با نام شبکه زمانی هم شناخته می‌شوند، شبکه‌هایی هستند که در طول زمان تغییر می‌کنند. پویایی شبکه‌ها را می‌توان از نظر تغییر ساختار شبکه (اضافه یا حذف شدن یال‌ها یا گره‌ها) یا تغییر ویژگی‌های گره‌ها و یال‌ها در طول زمان بررسی کرد. در واقع می‌توان شبکه زمانی را معادل با یک سری زمانی در نظر گرفت که سیر تغییرات ساختاری شبکه را نشان می‌دهد [1].از نظر زمانی، دو نوع شبکه پویا وجود دارد. اگر شبکه زمان گسسته باشد، می‌توان آن را به صورت دنباله‌ای از شبکه‌های ایستا با برچسب زمانی t و به صورت زیر نمایش داد که Vt و Et به ترتیب گره‌ها، یال‌ها در زمان t مشخص می‌کنند. در صورتی که شبکه زمان پیوسته باشد، مبتنی بر رویداد است و بر اساس تغییراتی از قبیل حذف یا اضافه شدن یال‌ها و گره‌ها توصیف می‌شود [1].2- 2- انجمنبسیاری از شبکه‌های پیچیده قابل تقسیم به گروه‌ها و انجمن‌هایی هستند که بیشترین ارتباطات بین موجودیت‌های داخل انجمن نسبت به ارتباطات با خارج انجمن است. در برخی موارد ممکن است یک گره عضو بیش از یک انجمن باشد که در این صورت انجمن‌ها با یکدیگر همپوشانی خواهند داشت. در الگوریتم‌های مربوط به شناسایی انجمن‌ها، برای ارزیابی عملکرد روش از معیاری به نام پیمانگی استفاده می‌شود. این معیار در واقع تعداد یال‌های بین گره‌ها در یک انجمن را با تعداد یال‌هایی که انتظار می‌رود در یک شبکه تصادفی بین این گره‌ها وجود داشته باشد، مقایسه می‌کند. معیار پیمانگی کیفیت تقسیم‌بندی را نشان می‌دهد و عددی بین 1- تا 1 است. طبق محاساباتی که انجام شده است، معیار پیمانگی بیش از 0.3 در شبکه‌های واقعی مناسب است.2- 3- مدل‌های تولید شبکهدر بسیاری از کاربردها و برای آزمایش فرضیات، نیاز به وجود شبکه‌هایی است که از آنها برای شبیه‌سازی و آزمون استفاده شود. اما از آنجایی که اغلب دسترسی به اطلاعات شبکه‌های واقعی ناممکن است، روش‌هایی برای تولید شبکه‌های مصنوعی ارائه شده تا بتوان با استفاده از ویژگی‌های شبکه مد نظر، نمونه مصنوعی آن را ساخت. مدل‌های تولید گراف الگوریتم‌هایی هستند که گراف‌هایی با ویژگی‌های مشخص را از روی شبکه‌های واقعی تولید می‌کنند. این مدل‌ها فرایندی مشابه شبکه واقعی برای مدلسازی را طی می‌کنند و از این رو تحلیل شبکه‌های پیچیده به کمک آنها امکان پذیر می‌شود [2].به دلیل کاربردهای فراوان حوزه تولید گراف، مدل‌های مولد مختلفی برای شبکه‌ها ارائه شدند که از جمله این موارد می‌توان به مدل‌های معروفی مانند گراف‌های تصادفی، مدل‌های دنیای کوچک و ... اشاره کرد. این مدل‌های تولید گراف بر اساس یک نوع خاص از شبکه‌های واقعی ارائه شدند و تنها قادر به مدلسازی گراف با چند ویژگی آماری هستند. در واقع از آنجایی که شبکه‌های واقعی بسیار متنوع هستند، در بسیاری از موارد ویژگی‌های شبکه و قوانین ساخت آن ناشناخته است. برای رفع این مشکل مدل‌های ترکیبی و مدل‌های مبتنی بر یادگیری ماشین ارائه شد که قادر بودند به صورت خاص‌تر شبکه‌های مد نظر را تولید کنند. با کاربرد گسترده حوزه یادگیری عمیق و مدل‌های مولد عمیق، روش‌های دیگری هم برای ساخت شبکه‌های مصنوعی ارائه شد [3]. در ادامه به توضیح مختصری از هر یک از این روش‌ها پرداخته شده است.در مدل‌های سنتی تولید گراف، با بررسی ساختار نوع خاصی از شبکه‌های دنیای واقعی قوانینی برای ساخت شبکه‌های مصنوعی ارائه می‌شود. از آنجایی که در بسیاری از حوزه‌ها، ویژگی‌های شبکه و قوانین تولید آن ناشناخته هستند (مانند تفسیر مکانیسم‌های بیماری‌های روانی در شبکه‌های مغزی، انتشار بدافزارها و ...)، نمی‌توان از این مدل‌ها به صورت گسترده استفاده کرد [3].به دلیل عدم وجود مدل کاملی برای تولید همه انواع شبکه‌ها، روش‌های قبلی در تولید اغلب ساختارهای شبکه موفق نبودند. به همین دلیل به سراغ روش‌های ترکیبی و استفاده از یادگیری ماشین برای برازش مدل ارائه شد. در این روش‌ها مدل یادگیری ماشین بر اساس انواع مختلف روش‌های سنتی آموزش داده شده و سپس بهترین روش ساخت شبکه بر اساس برخی از ویژگی‌های مد نظر شبکه هدف انتخاب می‌شود. گام‌های برازش مدل شامل انتخاب مدل مناسب و تنظیم پارامترهای آن است.نسل فعلی روش‌های تولید شبکه از یادگیری عمیق و شبکه عصبی برای ساخت مدل استفاده می‌کنند. تفاوت این روش‌ها با مدل‌های یادگیری ماشین در مرحله استخراج ویژگی است. در مدل یادگیری عمیق، این توانایی در مدل وجود دارد تا ویژگی‌ها را استخراج کرده و بر حسب اهمیت هر ویژگی ضریب متناسب با آن را بدهد.3- مطالعات انجام شدهدر این بخش به توضیح مختصر برخی از منابع مرتبط با شبکه‌های زمانی پرداخته شده است. علاوه بر این موارد، یکی از کارهای مطرح در حوزه شبکه و گراف، یادگیری بازنمایی است. در ادامه این بخش به مطالعات انجام شده در حوزه یادگیری بازنمایی هم پرداخته خواهد شد.3- 1- یادگیری بازنمایییادگیری بازنمایی گراف به فرایند یادگیری بازنمایی‌های برداری و با ابعاد کم از گره‌ها و یال‌ها در یک گراف اشاره دارد. این بازنمایی‌ها اطلاعات ساختاری و ارتباطی موجود در گراف را به خوبی نمایش داده و امکان انجام کارهای حوزه یادگیری ماشین را فراهیم می‌کنند. در واقع با استفاده از بازنمایی، شبکه‌ها به نمایش قابل استفاده برای مدل‌های یادگیری ماشین تبدیل می‌شوند.ژو و همکارن در مطالعه‌ای به مرور روش‌های بازنمایی عمیق پرداختند. علت انجام این پژوهش این بود که روش‌های سنتی بازنمایی، مانند «قدم زدن تصادفی» ظرفیت محدودی داشته و متکی بر یادگیری بدون نظارت هستند. روش‌های سنتی بازنمایی شامل ماتریس مجاورت و کاهش ابعاد آن، «قدم زدن تصادفی» و روش‌هایی غیر از GNNهستند. روش «قدم زدن تصادفی» به این صورت است که یک گره تصادفی در شبکه انتخاب شده و سپس با استفاده از پیمایش تصادفی از این گره به یکی از گره‌های همسایه رفته تا به محدودیت مشخصی برسد. برای مثال طول مسیر به اندازه مشخصی برسد. در این تجربه تصادفی برخی از اطلاعات ثبت شده تا با کمک آن بازنمایی انجام شود. در واقع به جای خود گراف از تعدادی مسیر آن به عنوان نماینده استفاده می‌شود. در مطالعات مربوط به مدل‌های تولید شبکه مانند TagGen و TIGGER، از مفهوم «قدم زدن تصادفی» با در نظر گرفتن ویژگی زمانی استفاده شده است. در این مدل‌ها، علاوه بر در نظر گرفتن هر مسیر که حاصل از «قدم زدن تصادفی» است، برچسب زمانی هم لحاظ می‌شود. زیرا در شبکه زمانی در هر لحظه تعدادی از یال‌ها وجود دارند.در ادامه به توضیح روش‌های مبتنی بر یادگیری عمیق پرداخته شده است. برای مثال یکی از روش‌های یادگیری بازنمایی می‌تواند با استفاده از شبکه‌های کانولوشن گرافی باشد. به صورت کلی شبکه‌های عصبی کانولوشنی برای داده‌هایی مانند تصاویر مناسب هستند. به همین در حوزه شبکه کارایی آنها بسیار نامطلوب بوده است. روش دیگر استفاده از جمع‌آوری گراف است. در حالت سراسری با این روش بازنمایی، از تعبیه گره‌ها استفاده شده و با تجمیع آنها بازنمایی کل گراف به دست می‌آید. طبق نتایج این مطالعه، روش جمع‌آوری برای گراف‌ها با ویژگی‌های ساده مناسب بوده اما اگر شبکه زمانی و پویا باشد، عملکرد مطلوبی نخواهد داشت. در این مطالعه بررسی‌هایی در زمینه کارهای انجام شده برای یادگیری ساختار گراف و کاربردهای بازنمایی اشاره شده است و مروری بر مزایا و معایب هر یک انجام شده است [4].روش‌های بازنمایی موجود اغلب برای حوزه شبکه‌های ایستا ارائه شدند و به خاطر پیچیدگی و داشتن عامل زمان در شبکه‌های پویا و زمانی مدل مناسبی برای یادگیری بازنمایی عمیق ارائه نشده است. به همین دلیل ضرورت دارد، روش‌هایی ارائه شود که عامل زمان را هم در نظر می‌گیرد. شبکه‌های پویا را می‌توان با سه روش توصیف کرد. در روش اول، شبکه زمان گسسته است. یعنی برچسب زمانی آن، مضربی از یک زمان خاص است. در این حالت، شبکه زمانی با استفاده از تعدادی شبکه ایستا بازنمایی می‌شود. به این روش توصیف، روش مبتنی بر تصویر لحظه‌ای گفته می‌شود. در روش دوم، شبکه زمان پیوسته است. یعنی برچسب زمانی هر عددی می‌تواند داشته باشد. در این حالت برای توصیف شبکه از رویدادها استفاده می‌شود. در واقع هر تغییری یک رویداد است که در جایی به نام «صندوق پستی» قرار گرفته و به ترتیب پردازش می‌شود. در روش سوم، شبکه معادل ایستا از روی شبکه زمانی ساخته شده و از الگوریتم‌ها و روش‌های بازنمایی در حالت ایستا استفاده خواهد شد [5].یکی از معایب مدل‌های موجود در حوزه بازنمایی همچنین روش‌های موجود مقایس‌پذیر نبوده و اغلب برای شبکه‌ها کوچک مناسب هستند. در حالی که شبکه‌های واقعی تعداد بسیار زیادی گره دارند. همچنین سربار محاسباتی روش‌های موجود بسیار زیاد بوده و کارایی مناسبی ندارند [5].3- 2- بررسی شبکه‌های حمل و نقلیکی از انواع شبکه‌های زمانی، شبکه حمل و نقل است. شبکه حمل و نقل نشان دهنده مکان‌ها و مسیر‌های ارتباطی مانند خیابان‌ها، بزرگره‌ها و ... بین آنهاست. برای مثال شبکه جاده‌ای یا در محیط‌های شهری را می‌توان از این نوع شبکه‌ها در نظر گرفت. در این شبکه، اغلب محل گره‌ها و یال‌ها ثابت است و ساختار شبکه در بازه‌های زمانی نسبتا طولانی، تقریبا ثابت است. آنچه با زمان تغییر می‌کند، ویژگی گره‌ها و یال‌هاست. برای مثال نرخ عبور و مرور از یک گذرگاه، سرعت عبور، تعداد وسایل حمل و نقلی که از آن مکان عبور کردند و ... را می‌توان جز ویژگی‌های این شبکه در نظر گرفت. شبکه حمل و نقل علاوه بر ویژگی زمانی، دارای ویژگی‌های مکانی هم بوده و به همین دلیل از انواع شبکه‌های زمانی-مکانی در نظر گرفته می‌شود.ترافیک در شبکه‌های حمل و نقل یکی از مواردی است که در سال‌های اخیر بسیار مورد توجه قرار گرفته و پژوهش‌های زیادی در این حوزه انجام شده است. پژوهش‌های این حوزه شامل پیش‌بینی‌هایی درباره سرعت ترافیک، جریان ترافیک یا تقاضای ترافیک است. روش‌های مختلفی برای این کار وجود دارد که شامل روش‌های ساده‌ای مانند رگرسیون خطی تا روش‌های پیچیده‌تری مانند شبکه‌های عصبی، مدل‌های بازنمایی گراف و یادگیری عمیق هستند. این روش‌ها با تحلیل و پردازش داده‌های ترافیک، الگوهای زمانی را شناسایی کرده و بر اساس آنها پیش‌بینی‌های دقیقی درباره آینده ترافیک ارائه می‌دهند. همچنین مطالعاتی درباره نحوه بازنمایی این نوع از شبکه‌ها انجام شده است. اهمیت این موضوع از این جهت است که در شبکه‌های حمل و نقل علاوه بر عامل زمان، مکان هم وجود دارد. بنابراین نیاز است روش‌هایی برای بازنمایی و استخراج نمایش برداری از عناصر مرتبط با ترافیک، مانند تقاطع‌ها، خیابان‌ها، خودروها و ... ارائه شود.جیانگ و لو به بررسی مقالات و تحقیقات انجام شده در زمینه پیش‌بینی ترافیک با استفاده از شبکه عصبی گرافی و مدلسازی زمانی و مکانی پرداختند. داده‌های ترافیک در دسته داده‌های زمانی قرار می‌گیرند. از آنجایی که گراف ترافیک اغلب از نظر ساختار ثابت است یعنی گره‌ها و یال‌های آن مشخص هستند هدف آن حل حالت خاصی از مسائل شبکه‌های پیچیده زمانی یعنی پیش‌بینی ویژگی یال‌ها یا گره‌ها در طول زمان است. از طرفی در اگر در یک گره از شبکه ترافیک وجود داشته باشد، این ترافیک می‌تواند به گره‌های اطراف نیز منتقل شود. بنابراین ترافیک علاوه بر زمان به مکان نیز وابسته است [6].طبق تعریف ارائه شده، جریان ترافیک تعداد عبور وسایل نقلیه از مکان مشخص در بازه زمانی مشخص را تعیین می‌کند. پیش‌بینی جریان ترافیک برای کنترل تراکم ترافیک و کنترل چراغ‌های راهنمایی و ... کمک کننده است. در این مقاله مروری بر مشکلات مختلف حوزه پیش‌بینی ترافیکی انجام شده است. این مشکلات مربوط به سه جریان ترافیکی جاده‌ای، منطقه‌ای و ایستگاه‌هاست که پیش‌بینی‌ها در رابطه با جریان‌های ترافیکی، سرعت و تقاضای ترافیک است. در مشکلات جریان ترافیکی جاده‌ای، هدف پیش بینی حجم ترافیکی است که از یک حسگر در جاده یا از یک مکان خاص در طول جاده در یک بازه زمانی مشخص عبور می‌کند. همچنین می‌توان با در نظر گرفتن حجم ترافیک در زمان مشخص و بین دو مکان خاص، مشکلات جریان ترافیکی مبدا-مقصد را بررسی کرد. در مشکلات جریان ترافیکی منطقه‌ای، جریان ترافیک در یک منطقه مورد بررسی قرار می‌گیرد. در این نوع از مشکلات، تقسیم‌بندی بر اساس نوع حمل و نقل (دوچرخه یا تاکسی) انجام شده است. در مشکلات جریان ترافیکی در سطح ایستگاه، حجم ترافیک در ایستگاه‌هایی مانند ایستگاه اتوبوس یا مترو اندازه‌گیری و پیش‌بینی می‌شود. در این نوع از مشکلات، تقسیم‌بندی بر اساس نوع ایستگاه (مترو، اتوبوس، راه آهن و ...) انجام شده است [6].یکی دیگر از شاخص‌های ترافیکی مهم دیگر، سرعت ترافیک است. سرعت ترافیک برابر با میانگین سرعت وسایل نقلیه عبوری از یک مکان مشخص در یک بازه زمانی مشخص است و نشان‌دهنده میزان شلوغی است. پیش‌بینی تقاضای ترافیک در زمینه ارائه خدمات تاکسی موثر است. این پیش‌بینی به ارائه‌دهنگان خدمات تاکسیرانی کمک می‌کند تا منابع حمل و نقل محدود خود را به مناطق شهری با تقاضای بیشتر تخصیص دهند. سرعت ترافیک در دو سطح مسائل جاده‌ای و منطقه‌ای بررسی شده است. علاوه بر پیش‌بینی سرعت ترافیک، کارهای دیگری در زمینه پیش‌بینی زمان سفر هم انجام شده است [6].علاوه بر این مقاله، جیانگ در پژوهشی دیگر روش‌های یادگیری عمیق مبتنی بر گراف برای شبکه‌های ارتباطی را مورد مطالعه و بررسی قرار داده و روش‌های ارائه شده در مقالات این حوزه را دسته‌بندی و مرور کرده است [7].در حوزه پیش‌بینی‌های ترافیکی، جین و همکارن چارچوبی برای تخمین زمان سفر مبتنی بر شبکه‌های عصبی گراف به نام STGNN-TTE ارائه دادند. تخمین زمان سفر در مسیرهای شهری اساس برنامه‌ریزی برای راه‌ها و کنترل ترافیک است. یکی از چالش‌های تخمین زمان سفر، تاثیر پویایی‌های زمانی و مکانی بر وضعیت ترافیک است. STGVV-TTE این چالش را با استفاده از یک چارچوب شبکه عصبی گرافی زمانی- مکانی (STGNN) رفع کرده است. در این STGNN از یک ماژول زمانی-مکانی برای ثبت شرایط واقعی ترافیک در زمان واقعی استفاده شده است. اما STGNN-TTE محدودیت‌هایی دارد. اول اینکه به خاطر محدودیت در منابع محاسباتی، فقط فضای کوچکی برای ارزیابی مدل استفاده شده است که منجر به کوتاه شدن مسیرها شده و دوم اینکه به دلیل عدم دسترسی به برخی از داده‌ها، این مدل تاثیر برخی عوامل مانند رویدادهای زمانی مکانی و ... را در تخمین زمان سفر در نظر نمی‌گیرد [8].3- 3- مجموعه داده شبکه زمانیدر بررسی کارهای انجام شده در زمینه شبکه‌های پیچیده زمانی، هوانگ و همکاران TGB(benchmark برای گراف‌های زمانی) را ارائه کردند. TGB شامل مجموعه‌ای متنوع از شبکه‌های زمانی در حوزه‌های شبکه اجتماعی، حمل و نقل، تجارت و ... است که برای ارزیابی مدل‌های یادگیری ماشین قابل استفاده است. این مجموعه داده به صورت آنلاین در اختیار پژوهشگران قرار گرفته است [9].3- 4- تحلیل و پیش‌بینی الگوهای شبکههمانطور که اشاره شد، در شبکه‌های زمانی به دلیل وجود فاکتور زمان و تکامل زمانی ضرورت دارد روش‌هایی متناسب با ساختار آنها ارائه شود تا امکان تحلیل و پیش‌بینی دباره شبکه زمانی فراهم شود. در این بخش به مرور چند روش در حوزه تشخیص انجمن‌ها و پیش‌بینی یال‌ها پرداخته شده است.3- 4- 1- تشخیص انجمن‌هادر تعریف بسیار ساده، انجمن مجموعه‌ای از گره‌هاست که با یکدیگر ارتباط منسجم و با خارج از این گروه ارتباط کمی دارند. یکی از انواع مطالعات انجام شده روی شبکه‌ها، تشخیص این انجمن‌ها به صورت خودکار است. این مسئله در حوزه شبکه زمانی، پیچیدگی‌های بیشتری دارد. از آنجایی که در شبکه زمانی، تغییراتی در ساختار شبکه ممکن است رخ بدهد، پس نیاز است مجددا انجمن‌ها شناسایی شوند. اما در بسیاری از مواقع این گونه نیست و می‌توان با استفاده از الگوهای زمانی و بدون نیاز به تعیین انجمن‌ها از ابتدا، این کار را انجام داد. در ادامه به مرور یکی از مطالعات این حوزه برای شبکه‌های زمانی متناوب پرداخته شده است.شین و همکاران روشی ارائه دادند که با کمک در نظ رگرفتن الگوهای زمانی متناوب در شبکه، بتوان انجمن‌ها را شناسایی کرد. تناوب پدیده‌ای رایج در تعاملات اجتماعی در شبکه‌های زمانی است. شناسایی و کشف این ارتباطات متناوب، به درک رفتارهای گروهی تکرار شونده در شبکه‌های زمانی کمک می‌کند. از مثال‌های تناوب در شبکه تعاملات اجتماعی می‌توان به ملاقات‌های هفتگی، دیدارهای خانوادگی، جشن تولد و ... اشاره کرد. این موارد الگوهای منظم و مهمی در شبکه‌های تعامل زمانی هستند که در بازه‌های زمانی مشخصی تکرار می‌شوند. شناسایی الگوهای گروه‌های متناوب در دو حوزه پیش‌بینی آینده و تشخیص رفتار کمک می‌کند. با داشتن الگوهای متنواب، آینده قابل پیش‌بینی خواهد بود، زیرا این الگوها به طور متناوب و در زمان‌های مشخص تکرار خواهند شد. همچنین با داشتن الگوها می‌توان حالت عادی رفتار افراد که همان گره‌های شبکه هستند را به دست آورد و تغییرات غیر عادی را شناسایی کرد [10].مدل ارائه شده از k-کلیک متناوب که انجمن‌های دوره‌ای را در شبکه‌های زمانی نمایش می‌دهند، استفاده کرده است. طبق تعریف مقاله، k-کلیک متناوب در واقع کلیکی با اندازه بزرگتر از k است که حداقل tبار به صورت متناوب در شبکه زمانی دیده شده باشد. در مطالعات قبلی شین و همکاران، نشان داده شده بود که مسئله شمارش تمام کلیک‌های متناوب جزو مسائلی است NP-hardاست. برای اینکه بتوان این مشکل را حل کرد، آنها راه حلی ارائه کردند که شامل دو مرحله است. در مرحله اول، شبکه را کاهش داده و برخی از بخش‌های آن را هرس می‌کنند. سپس در مرحله دوم، شبکه زمانی را به شبکه ایستا تبدیل می‌کنند. آنها اثبات کردند که شناسایی انجمن‌ها در شبکه ایستا، معادل شناسایی انجمن‌های متناوب در شبکه زمانی است. برای بررسی نتایج، از پنج مجموعه داده واقعی استفاده شده است. دو مجموعه داده برای تعاملات افراد در شبکه‌های زمانی هستند که یکی از آنها ارتباطات رو در روی بین دانش‌آموزان در یک دبیرستان را مشخص کرده شبکه دیگر، ارتباطات بین دانش‌آموزان و معلمان در یک دبیرستان است. دو شبکه دیگر از نوع شبکه‌های ارتباطی زمانی هستند که در آنها هر یال زمانی مانند uvt، ارتباط ایمیلی از کاربر uبه vدر زمان tرا نمایش می‌دهد. آخرین شبکه نیز DBLP است که شبکه همکاری نویسندگان مقالات را نشان داده است. نتایج نشان داده است که مدل ارائه شده قابلیت مقایس‌پذیری، اثربخشی و کارایی دارد [10].3- 4- 2- پیش‌بینی یالدر مسائل پیش‌بینی یال بر اساس ساختار فعلی شبکه، احتمال وجود یک یال در آینده بررسی می‌شود. برای این کار به صورت سنتی از روش‌های تحلیل ساختار گراف مانند تراگذری یال‌ها، در نظر گرفتن ویژگی‌های مشترک بین گره‌ها و پیدا کردن زیرگراف‌های پرتکرار استفاده می‌شود. یکی از کاربردهای پیش‌بینی یال پیشنهاد در سیستم‌های توصیه‌گر است.در شبکه‌های استاتیک، پیش‌بینی یال همان پیش‌بینی یال‌های مخفی در یک شبکه زمانی در یک دوره خاص است. علاوه بر این، هدف پیش‌بینی یال در شبکه‌های زمانی که با نام پیش‌بینی یال زمانی شناخته می‌شود، پیش‌بینی یال‌هایی از یک شبکه است که در زمان بعدی یا آینده آن شبکه ظاهر می‌شوند. همانطور که اشاره شد، شبکه‌های زمانی، رفتار تکاملی دارند. داشتن متغیر زمانی در این شبکه‌ها سبب می‌شود پیش‌بینی یال زمانی مسئله‌ای چالش برانگیز باشد. همچنین یادگیری این رفتار تکاملی در شبکه‌ها ارتباط مستقیمی با مسئله پیش‌بینی یال دارد، زیرا افزودن یال‌های جدید یا حذف آنها در طول زمان منجر به تکامل شبکه می‌شود. این مسئله با ایجاد شبکه‌های زمانی بزرگ مانند شبکه‌های اجتماعی مورد توجه قرار گرفت و مطالعات زیادی در این زمینه انجام شد. دیواکاران و موهان در مطالعه مروری، به بررسی و دسته‌بندی روش‌های موجود پرداختند. در ادامه به توضیح کارهای انجام شده در زمینه پیش‌بینی یال پرداخته شده است. در اکثر مطالعات انجام شده در حوزه پیش‌بینی یال، روش‌هایی ارائه شده است که ورودی آنها شبکه زمانی در قالب یک شبکه ایستا در یک لحظه خاص است. این رویکرد به عنوان یک روش کارامد برای پیش‌بینی یال زمانی شناخته نمی‌شود، زیرا پویایی این شبکه‌ها را در نظر نمی‌گیرد [11].یکی از مشکلات اصلی کارهای انجام شده در این حوزه این است که اغلب فرض می‌کنند نودها در همه مراحل زمانی ثابت می‌مانند، در حالی که یال‌ها در طول زمان اضافه شده یا حذف می‌شوند. این روش منجر به از دست دادن اطلاعاتی می‌شود که مربوط به ایجاد یک یال جدید همزمان با اضافه شدن یکی از گره‌های آن است. شکل 1 طبقه‌بندی از روش‌های مختلف پیش‌بینی یال زمانی را بر اساس تکنیک‌های مختلف نشان می‌دهد [11].شکل 1 دسته‌بندی روش‌های پیش‌بینی یال زمانی [11] طبق بررسی‌های انجام شده توسط دیواکاران و موهان، هر یک از این روش‌ها ویژگی‌ها و مشکلاتی دارند که در ادامه به توضیح مختصری از آنها پرداخته شده است. روش‌های مبتنی بر فاکتورگیری ماتریس، ویژگی‌های محلی و سراسری و الگوهای شبکه‌های زمانی را برای پیش‌بینی یال زمانی استخراج کرده و ذخیره می‌کنند. در این روش ماتریس به عوامل کوچک‌تری تقسیم می‌شود. روش مبتنی بر فاکتورگیری ماتریس، برای شبکه‌های واقعی کوچک مناسب هستند و برای شبکه‌های بزرگ، مقیاس‌پذیر نیستند. در مدل‌های احتمالاتی به جای استفاده از عدد ثابت، توزیع‌های احتمال ثابت استفاده می‌شود. در نتیجه قابلیت اندازه‌گیری امکان تغییر و عدم قطعیت نیز ممکن می‌شود. مدل‌های احتمالاتی توانایی بالاتری برای بررسی الگوهای تکاملی در شبکه‌های پویا دارند. این مدل‌ها با وجود عملکرد خوب برای شبکه‌های کوچک، برای شبکه‌های بزرگ هزینه محاسباتی بالایی دارند و مقیاس‌پذیر نیستند. در برخی از روش‌ها از رویکردهای مبتنی بر خوشه‌بندی طیفی استفاده شده است که مطالعه ویژگی‌های یک گراف با مقادیر ویژه و بردارهای ویژه ماتریس مجاورت یا ماتریس لاپلاسین مرتبط با گراف است. الگوریتم‌های مبتنی بر خوشه‌بندی طیفی به طور مؤثر از تکامل شبکه استفاده می‌کنند اما مشابه روش‌های قبلی برای شبکه‌های بزرگ و پیچیده مقیاس‌پذیر نیستند و پیچیدگی محاسباتی بالایی دارند [11].رویکرد دیگر استفاده از سری زمانی است. در این روش‌ها، امتیاز سری زمانی با محاسبه شباهت بین هر زوج گره در شبکه ساخته می‌شود. بنابراین این روش از پیش‌بینی امتیازهای سری زمانی آینده بر اساس امتیازهای قبلی مشاهده شده، استفاده می‌کند. روش سری زمانی برای مجموعه‌داده‌هایی که در طول دوره‌ها یا فواصل زمانی خاص دچار تغییرات قابل توجهی در ویژگی‌های خود می‌شوند، عملکرد خوبی دارند. اما اکثر روش‌های مبتنی بر سری زمانی، فقط به ویژگی‌های محلی می‌پردازند و ویژگی‌های ساختاری و سراسری شبکه را نادیده می‌گیرند. در ادامه روش‌های پیش‌بینی یال، از روش‌های مبتنی بر تکنیک‌های یادگیری عمیق استفاده شده است. روش‌های مبتنی بر یادگیری عمیق برای پیش‌بینی یال زمانی عملکرد خوبی را برای مجموعه‌داده‌های با خصوصیات غیرخطی و پیچیده ارائه می‌دهند و تقریبا چالش‌های روش‌های قبلی را رفع کردند [11].3- 5- مدل‌های تولید شبکهدر چند سال گذشته در حوزه‌های مختلف، یکی از مسائل اصلی ارائه روش‌های تشخیص یا پیش‌بینی با استفاده از داده‌های موجود بوده است. اما با پیشرفت‌های زیاد در سخت‌افزارها و افزایش توان محاسباتی، مسائلی با موضوع تولید و مدل‌های مولد ارائه شد. برای مثال در حوزه پردازش تصویر، یکی از مسائل پرتکرار یادگیری و تشخیص برچسب درست تصاویر بود. اما امروزه مسئله اصلی ارائه روش‌هایی برای تصاویر با توجه به توصیف‌های انجام شده است. مشابه این مسئله در حوزه شبکه هم وجود دارد. همانطور که در بخش دوم توضیح داده شد، ضروری است که بتوان روش‌هایی برای تولید شبکه‌ها با ویژگی‌های مد نظر ارائه کرد.3- 5- 1- مدل‌های عمیق تولید شبکهنسل فعلی از مدل‌های تولید شبکه‌ها مربوط به روش‌هایی است که از یادگیری عمیق در آنها استفاده می‌شود. در روش‌های عمیق تولید شبکه از شبکه‌های عصبی عمیق استفاده می‌شود. این روش‌ها در بسیاری از حوزه‌ها مانند پردازش تصویر، متن و ... موفق بوده‌اند. در این روش چندین لایه از معماری مدل‌ها به استخراج ویژگی‌ها مربوط است. در حالی که در روش‌های سنتی یادگیری ماشین استخراج ویژگی نیاز به متخصصین دارد. در ادامه به مرور برخی از مطالعات انجام شده در این زمینه پرداخته شده است.فائز و همکاران در سال 2021، در مرور روش‌های عمیق تولید گراف، کارهای انجام شده را در پنج دسته تقسیم‌بندی کردند. این موارد شامل مدل‌های خود-رگرسیون، مبتنی بر خود-رمزگذار، مبتنی بر یادگیری تقویتی، خصمانه و مبتنی بر جریان هستند. هدف و ضرورت انجام این مطالعه به خاطر گسترش روش‌های تولید گراف مبتنی بر یادگیری عمیق در چند سال اخیر است که در حوزه‌های زیادی مانند کشف ساختارهای مولکولی جدید تا مدل‌سازی شبکه‌های اجتماعی به کار می‌روند. بنابراین، به دلیل توسعه گسترده روش‌های نوین تولید گراف، که به آنها تحت عنوان مولد‌های گراف عمیق اشاره می‌شود، و همچنین در نظر گرفتن کاربردهای آنها در حوزه‌های مختلف تحقیقات، نیاز به انجام مطالعاتی است که این روش‌ها را به طور خاص بررسی کنند [12].برای مثال یکی از دسته‌بندی‌ها، مربوط به مدل‌های خود رگرسیون است. در مطالعه فائز و همکاران، این روش مربوط به مدل‌هایی است که به صورت مرحله‌ای گراف‌ها را تولید می‌کنند، به طوری که این فرایند در هر مرحله تحت تاثیر خروجی‌های گذشته است که آن‌ها را به روش‌های بازگشتی و غیر بازگشتی تقسیم‌بندی کرده‌اند. روش‌های بازگشتی تاریخچه تولید را با استفاده از واحدهای بازگشتی مانند حافظه کوتاه‌مدت طولانی یا واحدهای بازگشتی گیت ثبت می‌کنند، در حالی که روش‌های غیربازگشتی تصمیمات خود را مستقیما بر اساس آخرین گراف جزئی تولید شده می‌گیرند [12].مدل‌های خود رگرسیون بازگشتی همانطور که اشاره شد، از LSTMیا GRUاستفاده می‌کنند و شامل سه حالت گره به گره، مجموعه‌ای از گره‌ها و یال به یال هستند. در مولد گره به گره، اغلب روش‌های خود رگرسیونی یک گره جدید را به ترتیبی و یک به یک در گراف تولید شده اضافه می‌کنند. آغاز فرایند با افزودن یک گره به گراف خالی است و در ادامه به تصمیم‌گیری تکراری می‌پردازد؛ یعنی برای افزودن یک گره جدید به گراف، اتصال گره اضافه شده به گراف‌های پیشین را انجام می‌دهد یا فرایند را خاتمه می‌دهد. مشابه همین کار برای یال‌ها هم قابل انجام است. به این صورت که یال‌ها یک به یک به گراف اضافه شوند. مدل‌های خود رگرسیون غیربازگشتی، تاریخچه را در نظر نمی‌گیرند و در اغلب مقالات این نوع، از روش‌های مبتنی بر توجه استفاده شده است [12].برخی از مدل‌های مبتنی بر خود-رمزگذار هستند. این روش به بررسی مدل‌هایی می‌پردازد که از خود-رمزگذار برای تولید ساختارهای گرافی استفاده می‌کنند. به طور خاص، یک شیوه متداول در این روش‌ها این است که ابتدا یک گراف ورودی را با استفاده از GNN، شبکه کانولوشنی گرافی یا نسخه‌های دیگری از آن‌ها به فضای برداری رمز می‌کنند و سپس شروع به تولید گراف از این فضای بازنمایی می‌کنند. فائز و همکاران روش‌های موجود را بر اساس سطح دقت تولید آن‌ها (انتخاب یک استراتژی تولید همه با یک‌بار، استفاده از زیرساختارهای معتبر به عنوان بلوک سازنده یا تولید گراف به صورت گره به گره) به سه دسته تقسیم کردند [12].در بخش چهارم، به مولدهای مبتنی بر شبکه خصمانه پرداخته شده است. این روش‌ها اغلب از رویکرد «قدم زدن تصادفی» به جای در نظر گرفتن کل گراف استفاده می‌کند. در این زمینه، NetGAN اولین مدل تولیدی برای گراف‌ها را معرفی می‌کند که از «قدم زدن تصادفی» بر روی یک گراف، برای تولید شبکه و یادگیری با استفاده از چارچوب WGAN استفاده می‌کند [12].برای درک بهتر رده‌بندی‌های روش‌های تولید شبکه‌های عمیق، در ادامه مقایسه‌ای بین روش‌های بررسی شده انجام شده است. ویژگی اصلی مدل‌های خود رگرسیون این است که از یک استراتژی مرحله به مرحله برای تولید گراف استفاده کرده به طوری که در هر مرحله، تصمیمات بر اساس نتایج به دست آمده از مراحل قبلی گرفته می‌شود. مزیت این روش‌ها نسبت به دسته‌های دیگر، ویژگی مرحله به مرحله بودن فرآیند تولید است که منجر به مقیاس‌پذیری بیشتر می‌شود. در مقابل، روش‌های مبتنی بر خود-رمزگذارهایی که تا کنون پیشنهاد شده‌اند، قابلیت مقیاس‌پذیری کافی برای استفاده در مجموعه داده‌هایی شامل گراف‌های بزرگ را ندارند و اغلب قادر به تولید گراف‌هایی با کمتر از 100 گره هستند و بیشتر در حوزه شبکه‌های مولکولی استفاده می‌شوند. بخش کمی از روش‌ها نیز مبتنی بر یادگیری تقویتی هستند و مجددا این روش‌ها نیز در شبکه‌های مولکولی کوچک (با حداکثر 100 گره) قابل استفاده هستند. در سال‌های اخیر نیز تعداد کمی از مولد‌های گراف مبتنی بر جریان ارائه شده‌اند و اغلب بر روی گراف‌های نسبتا کوچک با کمتر از 100 گره مورد استفاده قرار گرفته‌اند [12].به دلیل کاربردهای فراوان حوزه تولید گراف، مدل‌های مولد مختلفی برای شبکه‌ها ارائه شدند که از جمله این موارد می‌توان به مدل‌های معروفی مانند گراف‌های تصادفی، مدل‌های دنیای کوچک و ... اشاره کرد. این مدل‌های تولید گراف بر اساس یک نوع خاص از شبکه‌های واقعی ارائه شدند و تنها قادر به مدلسازی گراف با چند ویژگی آماری هستند. در واقع از آنجایی که شبکه‌های واقعی بسیار متنوع هستند، در بسیاری از موارد ویژگی‌های شبکه و قوانین ساخت آن ناشناخته است. برای رفع این مشکل، مدل‌های ترکیبی و مدل‌های مبتنی بر یادگیری ماشین ارائه شدند که قادر هستند به صورت خاص‌تر شبکه‌های مد نظر را تولید کنند. با کاربرد گسترده حوزه یادگیری عمیق و مدل‌های مولد عمیق، روش‌های دیگری هم برای ساخت شبکه‌های مصنوعی ارائه شد [3].گوپتا و بداتور در سال 2022 مروری بر مدل‌های تولید و بازنمایی شبکه زمانی انجام دادند. در این مقاله ابتدا به تعریف شبکه زمانی پرداخته شده است. شبکه زمانی نوعی شبکه است که با گذر زمان تغییر کرده و تکامل پیدا می‌کنند. این شبکه‌ها دارای دو نوع زمان گسسته و زمان پیوسته هستند. گوپتا و بداتور ابتدا روش‌های بازنمایی و تولید شبکه‌های ایستا را بررسی کردند. به طور کلی روش‌های بازنمایی شبکه ایستا شامل دو نوع «قدم زدن تصادفی» و روش‌های مبتنی بر GNNهاست. کلیت روش تولید این شبکه‌ها با در نظر گرفتن مجموعه‌ای از گراف‌ها شامل نمونه‌برداری از توزیع احتمالاتی گراف‌ها و یادگیری ساختار آنهاست تا در نهایت بتوانند گراف‌هایی با ویژگی‌های ساختاری بسیار مشابه به گراف‌های ورودی تولید کنند. برای مثال یکی از مدل‌هایی که در این مقاله بررشی شده است NetGan بوده که از روش «قدم زدن تصادفی» با طول T استفاده کرده و یک WGAN را روی نمونه‌های انتخابی آموزش می‌دهد. معماری کلی این روش نیز شامل یک مولد و یک تشخیص دهنده است [13].در ادامه مقاله گوپتا و بداتور، به بررسی مدل‌های تولید شبکه زمانی پرداخته شده است. با توجه به بررسی‌ها ایشان، تحقیقات فعلی در زمینه مدل‌های تولیدی عمیق برای گراف‌های زمانی هنوز در مراحل اولیه قرار دارد و به شکل محدودی انجام شده است. در شبکه‌های ایستا ، مدل‌هایی مانند دنیای کوچک وجود دارند که به عنوان مدل معیار برای شبکه‌های ایستا شناخته می‌شوند. اما در حوزه شبکه زمانی، چنین مدل‌هایی وجود ندارند. در برخی از مطالعات، رویکردی ارائه شده که با تولید شبکه ایستا آغاز می‌شود. سپس برای هر یال در شبکه، بازه زمانی فعال و زمان آغاز آن تولید می‌شود. در نتیجه دنباله زمانی ایجاد شده و با ترکیب این دنباله با بازه زمانی فعال بودن هر یال، شبکه تعاملی تولید می‌شود. در روشی دیگر، رویکردی مبتنی بر تولید شبکه‌های زمانی مبتنی بر فعالیت معرفی شده است. در این حالت، هر گره با احتمال مشخصی فعال خواهد شد و با توجه به ظرفیت فعالیت هر گره، آن گره به چندین گره دیگر متصل خواهد شد. در زمان بعدی، همین فرآیند مجددا تکرار می‌شود [13].3- 5- 2- مدل TagGenگوپتا و بداتور، به بررسی مدل‌های تولید شبکه زمانی پرداخته‌اند. با توجه به بررسی‌های ایشان، تحقیقات فعلی در زمینه مدل‌های تولیدی عمیق برای گراف‌های زمانی هنوز در مراحل اولیه قرار دارد و به شکل محدودی انجام شده است. اما یکی از مدل‌های معروف در این زمینه TagGen است. TagGen گراف‌های زمانی را با تبدیل آن‌ها به گراف‌های ایستای معادل و با ادغام شناسه گره‌ها با تعاملات زمانی آن‌ها (یال زمانی) تعریف می‌کند و فقط آن گره‌هایی را که شرایط همسایگی زمانی مشخص را ارضا می‌کنند، به یکدیگر متصل می‌کند. در TagGen روی گراف تبدیل شده قدم زدن‌های تصادفی انجام می‌شود و با استفاده از روش مبتنی بر الگوریتم‌های ابتکاری این قدم زدن‌ها تغییر داده می‌شوند تا شبکه مطلوب تولید شود. مدل TagGen اولین تلاش برای تولید شبکه‌های زمانی با یادگیری مستقیم از مجموعه‌ای از یال‌های برچسب‌دار است که در ادامه به اختصار ساختار این مدل توضیح داده شده است [13] و [14].ایده اصلی TagGen این است که یک مکانیزم خود-توجه به همراه یک خانواده از عملیات‌های محلی را آموزش دهد تا بتواند دنباله‌های تصادفی زمانی را برای تجمیع شبکه‌های تعاملی زمانی مدل کند و تولید کند. چارچوب کلی مدل TagGen در شکل 2 ارائه شده است که شامل چهار مرحله اصلی است. ورودی مدل شبکه تعاملی زمانی است که توسط مجموعه‌ای از یال‌های زمانی با برچسب تعریف شده است. در مرحله اول باید اطلاعات شبکه‌های تعاملی زمانی با استفاده از نمونه‌برداری به روش قدم زدن زمانی استخراج شود. در مرحله دوم، از فرایندی برای تولید عمیق استفاده شده که مجموعه‌ای از عملیات ساده مانند اضافه و حذف کردن یال‌های زمانی را برای تولید «قدم زدن زمانی» مصنوعی تعریف می‌کند. در مرحله سوم، یک متمایزگر بر روی «قدم زدن‌های زمانی» نمونه‌برداری شده آموزش داده می‌شود تا تعیین کند که آیا این موارد تولید شده مطابق با توزیع‌های همان نمونه‌های واقعی هستند یا خیر. در نهایت، با جمع‌آوری «قدم زدن زمانی» مصنوعی از طریق متمایزگر، شبکه تعاملی زمانی تولید می‌شود. نتایج حاصل از این مدل با برخی از روش‌های سنتی مانند مدلباراباشی-آلبرت و اردوش-رنی و مدل NetGAN مقایسه شده است. معیارهای اریابی، ویژگی‌های ساختاری شامل میانگین درجه، تعداد مولفه‌های همبند، اندازه مولفه‌های همبند و ... بودند. این معیارهای برای شبکه‌های ایستا ارائه شده بودند اما در اینجا ژو و همکاران این معیارها را برای شبکه‌های زمانی تعمیم دادند. نتایج نشان داد که این روش عملکرد بسیار بهتری نسبت به سایر روش‌های مقایسه شده از نظر معیارها بوده است [14].شکل 2 ساختار مدل TagGen از [14] 3- 5- 3- مدل EvovleGCNمدل دیگری به نام EvolveGCN توسط پارجا و همکاران ارائه شده که برای حوزه شبکه‌های پویا به کار می‌رود. اغلب مطالعات انجام شده در حوزه شبکه‌های ایستا است اما در عمل شبکه‌هایی وجود دارند که به طور مداوم در حال تکامل هستند. در محیط ایستا، روش‌های موجود معمولا به تعبیه گره‌ها می‌پردازند و از یک شبکه عصبی بازگشتی برای تنظیم تعبیه‌ها و یادگیری پویایی‌های زمانی استفاده می‌کنند. این روش‌ها نیازمند دانشی از گره در کل طول دوره زمانی هستند و قابلیت استفاده در مواجهه با تغییر مکرر مجموعه گره‌ها را ندارند. EvolveGCN برای حل این چالش‌ها ارائه شده است که مدل شبکه کانولوشن گرافی را در بعد زمانی بدون توجه به تعبیه‌های گره بهینه می‌کند. در بخش ارزیابی نیز عملکرد این مدل برای حوزه‌های مختلف از جمله پیش‌بینی یال و ... انجام شده است و نتایج نشان‌دهنده عملکرد بهتر EvolveGCN نسبت به سایر روش‌های ارائه شده هستند [15].3- 5- 4- مدل TIGGERیکی دیگر از روش‌هایی که برای تولید شبکه زمانی در سال‌های اخیر ارائه شده، TIGGER است. این مدل مبتنی بر روش‌های خود رگرسیون بوده و دارای دو ویژگی کلیدی است. اول آنکه دارای مقیاس‌پذیری به گراف‌های زمانی بزرگ بوده دوم آنکه توانایی یادگیری توزیع قوانین گرافی ورودی‌های جدید که بر خلاف گراف آموزشی تکرار نمی‌شوند را دارد. در واقع این مدل با هدف رفع چالش‌های مطرح شده توسط گوپتا و بداتور در [13] ارائه شده است. معماری و ساختار این مدل در شکل 3 آمده است.شکل 3 ساختار خط لوله TIGGER از [16] عملکرد این مدل با توجه به سرعت اجرا و تولید گراف‌هایی با ویژگی‌های مشابه به ورودی اما نه خود این گراف‌ها ارزیابی می‌شود. در آزمایشات، این مدل عملکرد بسیار خوبی نسبت به روش‌های قبلی مانند TagGen داشته است. نتایج نشان داده که سرعت TIGGER تا ۲۰۰۰ برابر سریع‌تر بوده، مقیاس‌پذیری بالا با تعداد بیشتر برچسب‌های زمانی دارد و شبکه‌هایی با دقت بالا تولید می‌کند [16].3- 6- چالش‌ها و محدودیت‌هابا وجود کارهای بسیاری که در حوزه تولید شبکه‌های مصنوعی انجام شده، اما هنوز چالش‌هایی وجود دارد. یکی از این موارد مشکل تفسیر پذیری است. مدل‌های موجود چه در زمینه شبکه‌های زمانی و چه در حوزه شبکه‌های ایستا توانایی توصیف تحوه تصمیم‌گیری در تعیین خروجی را ندارند. در واقع مشخص نیست که کدام ویژگی‌های شبکه ورودی در تولید خروجی تاثیر گذار هستند. مشکل دیگر مقیاس‌پذیری است. برخی از روش‌های موجود قابلیت استفاده در شبکه‌های بزرگ را ندارند [17]و [18].گوپتا و بداتور در مروری که بر روی روش‌های تولید شبکه زمانی انجام دادند، محدودیت‌ها و چالش‌های این مدل‌ها را شناسایی کردند. به صورت کلی روش‌های تولید شبکه زمانی دارای محدودیت‌هایی است که شامل ضعف در مدلسازی زمانی، مشکل مقیاس‌پذیری برای شبکه‌های بزرگ و کمبود مدلسازی تجربی هستند. برای مثال مدل TagGen‌ نرخ تکامل گراف را به طور صریح مدل نمی‌کند. این مدل محدود به شبکه‌هایی است که که تعداد گره‌های کمتر از حدود 10000 دارند. همچنین انتخاب طراحی اساسی TagGen‌ برای تبدیل گراف زمانی به گراف ایستا، در طولانی مدت مقیاس‌پذیر نمی‌باشد زیرا تعداد گره‌ها در گراف ایستای نتیجه مضاعف می‌شود [13]4- جمع‌بندیشبکه زمانی یکی از انواع شبکه‌های پیچیده است که در طول زمان تغییر می‌کند. این تغییر در دو حالت ممکن است. اگر تغییر در ساختار شبکه باشد، و یال‌ها و گره‌های جدیدی به آن اضافه شده یا از حذف می‌شود. در حالت دوم ویژگی گره‌ها و یال‌های آن تغییر می‌کند. در سال‌های اخیر و با ظهور شبکه‌های بزرگی مانند شبکه‌های اجماعی، شبکه حمل و نقل و ...، اهمیت شبکه‌های زمانی افزایش یافته و تولید و تحلیل این نوع شبکه‌ها از اهمیت بالایی برخوردار شده است. به همین دلیل مطالعات زیادی در این زمینه انجام شده است.چالش اصلی روش‌هایی که برای تحلیل و بررسی شبکه‌ها یا تولید آنها نیاز است، تکامل زمانی و عامل زمان است. به خاطر وجود تکامل زمانی این نوع شبکه‌ها، استفاده از روش‌های قبلی مناسب نبوده و به همین دلیل نیاز به ایجاد مدل‌هایی برای تحلیل و تولید این نوع از شبکه‌هاست تا تاثیر زمان و تکامل زمانی نیز در نظر گرفته شود. در این نوشتار به مرور برخی از این روش‌ها مانند مدل‌های پیشبینی یال یا تشخیص انجمن و مدل‌های تولید شبکه پرداخته شده است.به صورت کلی سیر تکامل روش‌ها چه در تحلیل و پیش‌بینی الگوها و چه در تولید شبکه، از روش‌های سنتی بوده است. در این روش‌ها از مشاهدات یا رویکردهای حوزه گراف استفاده می‌کردند. اما با پیشرفت علم شبکه و ظهور شبکه‌های متنوع و پیچده، این روش‌ها کارایی مناسبی نداشتند و به همین دلیل به سراغ رویکردهای یادگیری ماشین رفتند. در نهایت به دلیل عدم امکان انتخاب ویژگی مناسب جهت آموزش مدل‌های یادگیری ماشین و پیشرفت‌هایی که منجر به روی کار آمدن مدل‌های یادگیری عمیق شد، در حوزه‌های مختلف از یادگیری عمیق استفاده شد. یادگیری عمیق در حوزه شبکه منجر به پیشرفت‌های زیادی شد تا آنجا که از مدل‌های خاص گرافی مانند شبکه عصبی گرافی (GNN) و شبکه کانولوشنی گرافی (GCN) ارائه شد که کاربرد گسترده‌ای در حوزه‌های مختلف دارند. در برخی از مقالات حتی اشاره شده بود که این مدل‌های یادگیری ماشین برای حوزه شبکه زمانی هم ارائه شدند تا ویژگی‌های زمانی را هم در نظر بگیرند.باوجود انجام مطالعات متعدد در حوزه تحلیل و پیش‌بینی شبکه، حوزه تولید شبکه زمانی نسبتا جدید است و امکان ارائه مدل‌های مناسب در این زمینه وجود دارد. این درحالی است که برای روش‌های یادگیری بازنمایی برای این حوزه مطالعات زیادی انجام شده و روش‌های مناسبی ارائه شده است.مراجع[1] N. Masuda and R. Lambiotte, A Guide to Temporal Networks, London: World Scientific Publishing Europe Ltd, 2020.[2] M. Newman, Networks, New York: Oxford University Press, 2018.[3] X. Guo and L. Zhao, "A Systematic Survey on Deep Generative Models for Graph Generation," IEEE Transactions on Pattern Analysis and Machine Intelligence, vol. 45, pp. 5370-5390, 2023.[4] W. Ju, Z. Fang, Y. Gu, Z. Liu, Q. Long, Z. Qiao, Y. Qin, J. Shen, F. Sun, Z. Xiao, J. Yang, J. Yuan, Y. Zhao, Y. Wang, X. Luo and M. Zhang, "A Comprehensive Survey on Deep Graph Representation Learning," Neural Networks, vol. 173, 2024.[5] L. Yang, C. Chatelain and S. Adam, "Dynamic Graph Representation Learning With Neural Networks: A Survey," IEEE Access, vol. 12, pp. 43460-43484, 2024.[6] W. Jiang and J. Luo, "Graph neural network for traffic forecasting: A survey," Expert Systems with Applications, vol. 207, pp. 163-205, 2022.[7] W. Jiang, "Graph-based deep learning for communication networks: A survey," Computer Communications, vol. 185, pp. 40-54, 2022.[8] G. Jin, M. Wang, J. Zhang, H. Sha and J. Huang, "STGNN-TTE: Travel time estimation via spatial–temporal graph neural network," Future Generation Computer Systems, vol. 126, pp. 70-81, 2022.[9]S. Huang, F. Poursafaei, J. Danovitch, M. Fey, W. Hu, E. Rossi, J. Leskovec, M. Bronstein, G. Rabusseau and R. Rabbany, "Temporal Graph Benchmark for Machine Learning on Temporal Graphs," in 37th Conference on Neural Information Processing Systems Datasets and Benchmarks Track, 2023.[10] H. Qin, R.-H. Li, Y. Yuan, G. Wang, W. Yang and L. Qin, "Periodic Communities Mining in Temporal Networks: Concepts and Algorithms," IEEE Transactions on Knowledge and Data Engineering, vol. 34, pp. 3927-3945, 2022.[11] A. Divakaran and A. Mohan, "Temporal Link Prediction: A Survey," New Generation Computing, vol. 38, pp. 213-258, 2020.[12] F. Faez, Y. Ommi, M. S. Baghshah and H. R. Rabiee, "Deep graph generators: A survey," IEEE Access, vol. 0, pp. 106675-106702, 2021.[13] S. Gupta and S. Bedathur, "A survey on temporal graph representation learning and generative modeling," arXiv preprint arXiv:2208.12126, 2022.[14] D. Zhou, L. Zheng, J. Han and J. He, "A data-driven graph generative model for temporal interaction networks," in Proceedings of the 26th ACM SIGKDD International Conference on Knowledge Discovery & Data Mining, 2020, pp. 401-411.[15] A. Pareja, G. Domeniconi, J. M. T. Chen, T. Suzumura, H. Kanezashi, T. Kaler, T. Schardl and C. Leiserson, "Evolvegcn: Evolving graph convolutional networks for dynamic graphs," in Proceedings of the AAAI conference on artificial intelligence, 2020, pp. 5363-5370.[16] S. a. M. S. a. B. S. a. R. S. Gupta, "Tigger: Scalable generative modelling for temporal interaction graphs," Proceedings of the AAAI Conference on Artificial Intelligence, vol. 36, no. 6, pp. 6819-6828, 2022.[17] A. Longa, V. Lachi, G. Santin, M. Bianchini, B. Lepri, P. Lio, F. Scarselli and A. Passerini, "Graph neural networks for temporal graphs: State of the art, open challenges, and opportunities," arXiv preprint arXiv:2302.01018, 2023.[18] X. Guo and L. Zhao, "A Systematic Survey on Deep Generative Models for Graph Generation," IEEE Transactions on Pattern Analysis and Machine Intelligence, vol. 45, pp. 5370-5390, 2023.m_97260858m_97260858Sat, 13 Jul 2024 20:48:07 +0330https://virgool.ir/@m_97260858/بررسی-معماری-چند-نرم-افزار-موفق-dsbviqgfudngمقدمهیکی از موارد موثر در موفقیت نرم‌افزار تولید شده، معماری آن است. اگر معماری یک نرم‌افزار مناسب و خوب باشد می‌تواند منجر به موفقیت‌های چشمگیری شده و در غیر این صورت ممکن است منجر به شکست و ضررهای بزرگی شود. هدف از انجام پروژه درس معماری نرم‌افزار، بررسی و مرور معماری چند نرم‌افزار موفق و معروف است. بررسی معماری‌های موفق کمک می‌کند تا الگوهای مرسوم شناسایی شوند و در توسعه نرم‌افزارهای جدید مورد استفاده قرار گیرند. در این نوشته به بررسی معماری LinkedIn، Amazon، TikTok، Uber و Telegram پرداخته شده است.معماری LinkedInبرنامه LinkedIn در سال 2003 با هدف برای پیدا کردن فرصت‌های شغلی بهتر و با 2700 نفر از کاربران کار خود را آغاز کرد و تا سال 2023 دارای 930 میلیون کاربر بود. یعنی در هر ثانیه به ده‌ها هزار صفحه در وب خدمات می‌دهد. همچنین به خاطر داشتن نسخه تلفن همراه، چیزی حدود 50 درصد از کل ترافیک در دنیا را شامل می‌شود. در همه این موارد، اطلاعاتی از سرورهای لینکدین دریافت می‌شود که به معنی پاسخ به میلیون‌ها کوئری در هر ثانیه است. با توجه به این موارد می‌توان گفت که معماری نرم‌افزار آن دچار تحولات زیادی شده تا بتواند این حجم از کاربران و درخواست‌ها را مدیریت کند.1. معماری یکنواختمعماری LinkedIn در چندین مرحله تکامل یافته است. در ابتدا معماری آن به صورت یکنواخت (monolithic) بود. به این برنامه، Leo گفته می‌شد و تعداد کمی پایگاه داده داشت. این ساختار بسیار ساده بود و در این برنامه نیاز به مدیریت ارتباطات بین افراد بود. به همین دلیل، به سراغ Service Graph رفتند.2. استفاده از Service Graphیکی از کارهایی که باید در این برنامه به عنوان شبکه اجتماعی انجام می‌شد، مدیریت ارتباط افراد بود. در واقع به سیستمی در حافظه نیاز بود که داده‌های مرتبط با ارتباطات را با استفاده از پیمایش گراف (با efficiency و کارایی بالا) بازیابی کند. این ساختار باید مستقل از Leo ایجاد می‌شد تا بتواند این کارکرد متفاوت را عملی کند. بنابراین یک سیستم جداگانه برای Member Graph به نام Cloud ایجاد شد که اولین سرویس لینکدین بود. برای جداسازی این بخش از Leo نیز از ارتباطات Java RPC استفاده کردند. سپس برای پاسخگویی به درخواست‌های جستجو از Lucene (نرم‌افزار متن‌باز جستجوی آپاچی) استفاده کردند که داده‌های آن از Member Graph می‌آمد.استفاده از Service Graph در لینکدین3. مقیاس‌بندی پایگاه دادهدر ادامه، با افزایش تعداد کاربران، پیچیدگی Leo نیز افزایش یافت و برای کمک به load balancing، چندین کپی از Leo ایجاد شد. اما این کار منجر شد که DB (مربوط به اطلاعات کاربران) تبدیل به گلوگاه سیستم شود. در ابتدا CPU و مموری را به صورت vertical مقیاس کردند (scale out) یعنی این منابع را به سیستم اضافه کردند. اما این روش هم نتوانست مشکل را حل کند. به همین دلیل پایگاه‌های داده را scale کردند. علت این کار، این بود که پایگاه داده هم کار خواندن و هم نوشتن را مدیریت می‌کرد، برای همین از تکنیک Replica استفاده کردند. یعنی کپی دقیق از پایگاه داده کاربران ایجاد کردند که از طریق نسخه اولیه data bus با منبع اصلی sync می‌ماند. این کپی‌ها صرفا برای درخواست‌های خواندن بودند و به صورت master-slave مدیریت می‌شد. این راه‌حل برای میان‌مدت در نظر گرفته شده بود زیرا برای کوئری‌های نوشتن راهکاری ارائه نداده بود. راه حل اصلی، partition کردن پایگاه داده بود.با افزایش تعداد کاربران، ترافیک سایت افزایش یافت. با اینکه از مهم‌ترین ویژگی‌های کیفی لینکدین دسترس‌پذیری بود، Leo اغلب از دسترس خارج می‌شد و بازیابی آن بسیار سخت بود. به همین دلیل به معماری به SOA تغییر پیدا کرد.4. معماری سرویس‌گرابرای داشتن دسترس‌پذیری به خصوص در ترافیک بالا، معماری مونولیتیک به چندین سرویس کوچک stateless تبدیل شد. این سرویس‌ها در سه دسته frontend (نمایش منطق و ارتباط مدل‌های داده حوزه‌های مختلف)، mid-tier (APIهایی برای دسترسی به مدل‌های داده‌ها فراهم می‌کردند) و backend (دسترسی به پایگاه داده) قرار می‌گرفتند. با این تغییر در معماری در سال 2010، حدود 150 سرویس مجزا ایجاد شد که در 2015 به 750 سرویس افزایش پیدا کرده است. سرویس‌ها نیز stateless بودند تا امکان scale-out را ایجاد کپی‌ها ممکن باشد.معماری سرویس گرا5. استفاده از cachingبا افزایش بیشتر تعداد کاربران، نیاز به مقیاس‌پذیری بیشتری بود. در همین راستا از تکنیک caching استفاده کردند و لایه‌های cache را افزایش دادند. علاوه بر استفاده از کش، لینکدین از Voldemort به عنوان یک data store توزیع شده (به شکل key-value) استفاده کرد که بسیار مقایس‌پذیر بود.6. ایجاد Kafkaلینکدین برای اینکه بتواند حجم زیادی از داده‌ها را جمع‌آوری کند، خط لوله‌های زیادی برای صف‌بندی داده‌ها ایجاد کرد. برای مثال نیاز به جریان داده‌ها به Hadoop و data warehouse برای کاربردهای تحلیل بود. در نتیجه Kafka به عنوان بستری برای پیام‌رسانی pub-sub، ایجاد شد. اما این پلتفرم مختص لینکدین نبود و به تبدیل به خط لوله‌ای جهانی شد که با مفهوم commit log ساخته شده بود. (commit log شامل مجموعه‌ای از رکوردها با شناسه منحصر به فرد است که تغییر ناپذیر و ترتیبی است. کافکا این مفهوم را با انعطاف‌پذیری در یکپارچه‌سازی با منابع داده، تغییر داده‌ها و نوشتن در سیستم‌های دیگر ترکیب کرد) این امکان دسترسی تقریبا بلادرنگ به هر منبع داده‌ای را فراهم کرد. در سال 2015، Kafka قادر بود بیش از 500 میلیارد رویداد در روز را مدیریت کند.7. پدیده وارونگی (Inversion)در سال 2011 برای تمرکز روی بهبود ابزارها، زیرساخت‌ها و فرایند استقرار، لینکدین توسعه امکانات جدید را متوقف کرد. این کار منجر به ایجاد چابکی در فرایند توسعه شده و همچنین منجر به مقیاس‌پذیری تیم‌ها شد.8. ایجاد چارچوب Rest.liزمانی هنگامی که معماری به SOA تغییر پیدا کرد، APIها به صورت RPC در نظر گرفته شده بودند. این نوع API منجر به بروز ناسازگاری بین تیم‌ها شد زیرا کاملا وابسته به لایه presentation بود. برای رفع این مشکل APIجدید به نام Rest.li ایجاد کردند. Rest.li سبب شد که به سمت معماری data model centric بروند و یک مدل API Restful که stateless بود را تضمین کرد. در واقع این کار باعث decoupling سرویس‌ها شد.در این روش جدید، از JSON در HTTP برای ارسال درخواست و دریافت پاسخ استفاده می‌شد که کار را برای کاربران غیر Java آسان کرده بود. حذف APIهای RPC مشکلات backward compatibility را حل کرد. همچنین با استفاده از Dynamic Discovery (D2) در کنار Rest.li، به صورت خودکار load balancing، کشف و مقیاس‌پذیری هر سرویس API نیز ممکن شد. D2 از نظر عملکردی به نوعی کار DNS را انجام می‌دهد و یک URI را به آدرس دیگری ترجمه می‌کند و همچنین کار load balancing را سمت کاربر انجام می‌دهد.9. مفهوم Super blocksاستفاده از معماری SOA منجر به جداسازی نسبتا خوب دامنه‌ها و امکان مقیاس‌پذیری سرویس‌ها به صورت مستقل شد. اما مشکلاتی وجود داشت. برای مثال، هر درخواست نمایش صفحه پروفایل نیازمند اطلاعات زیادی مانند عکس‌ها، لینک‌ها، پست‌ها، توصیه‌ها و ... بود. این مشکل به نام fanout یا call graph شناخته می‌شد. مدیریت این call graph بسیار مشکل بود. برای حل این مشکل، مفهوم super block توسط لینکدین معرفی شد که به معنی دسته‌بندی سرویس‌های backend با یک API برای دسترسی به آنها بود.10. چندین data centerبرای اینکه لینکدین بتواند دسترس‌پذیری بالایی داشته باشد و از single point of failure جلوگیری کند، چندین مرکز داده در مکان‌های مختلف دنیا ایجاد کرد. بسیاری از پایگاه‌های داده روی Espresso اجرا می‌شدند. Espresso یک پایگاه داده NoSQL آنلاین و توزیع شده لینکدین است که در حال حاضر از تقریبا 30 برنامه کاربردی لینکدین (پروفایل کاربران، پیامرسانی بین افراد یا InMail و...) پشتیبانی می‌کند. این مراکز داده، باعث site-up شده و دسترس‌پذیری بالایی را تضمین می‌کنند. در سال 2015 لینکدین دارای سه مرکز داده اصلی به همراه PoPدر سراسر جهان بود. استفاده از PoP (Points of Presents) سبب می‌شود که زمان دانلود محتوای داینامیک بهتر شود. PoP در واقع مراکز داده در مقیاس کوچک و دارای تجهیزات شبکه و سرورهای proxy هستند. همچنین در هنگام دریافت اطلاعات درخواستی، ارتباط را برقرار نگه می‌دارد.11. کنار گذاشتن JSONداده‌های JSON و سریال کردن آنها، تبدیل به یک گلوگاه از نظر کارایی شد. به همین دلیل و برای کاهش تاخیر ایجاد شده به جای JSON از Protobuf استفاده کردند.با توجه به توضیحات هر یک از تغییرات معماری لینکدین، می‌توان گفت که همه این تغییرات در جهت بهبود مقیاس‌پذیری و فراهم کردن دسترس‌پذیری بالا بوده است.یکی دیگر از تغییراتی که در معماری LinkedIn رخ داد، تغییر معماری Lambda بود. WVYP (به معنی Who Viewed Your Profile) یکی از ویژگی‌های خاص لینکدین است که با معماری Lambda پیاده‌سازی شده بود. معماری Lambda یکی از الگوهای معماری در زمینه Big Data است که از آن برای پردازش داده‌ها به صورت batch و محاسبات مرتبط با آنها استفاده می‌شود. در عمل پیاده‌سازی Lambda منجر به بروز پیچیدگی و سربار عملیاتی شد و توسعه در هر تکرار را کُند کرد. به این دلایل بود که مهندسان لینکدین تصمیم گرفتند به معماری بدون Lambda مهاجرت کنند و در نتیجه سرعت توسعه به صورت قابل توجهی بهبود یافت.برای این کار، بخش مرتبط با مجموعه کارهای آفلاین به صورت batch از معماری حذف شد و از پردازشگر پیام‌های جدیدی به نام Samza استفاده شد. Samza توسط خود لینکدین و با استفاده از Kafka توسعه یافت و مسئول پردازش جریان توزیع شده است. همچنین Samza از مدل برنامه نویسی Beam پشتیبانی کرده و APIهایی برای آن نیز پیاده سازی کرده است. APIهای Beam امکان ایجاد خط لوله پردازش داده مانند فیلتر، تبدل‌ها و ... را فراهم می‌کند.همچنین لینکدین از GraphQL استفاده کرد که منجر به افزایش سرعت توسعه APIها شد. یکی از اهدافی که لینکدین داشت، ارتباط با سازمان‌ها از طریق ارائه PaaS (platform as a service) بود. GraphQL یک زبان کوئری برای APIهای داده است و به هیچ پایگاه داده خاصی وابسته نیست و توسط اطلاعات سمت سرور پشتیبانی می‌شود.پیش از استفاده از این رویکرد، باید برای هر خواسته کاربران در ارائه سرویس یک APIجداگانه ایجاد می‌شد چون این افراد خواسته‌های متفاوتی (جستجو از طریق ایمیل و ...) داشتند. این کار هزینه بسیار بالایی داشت. راه حل استفاده از GraphQL بود. با سرویس GraphQL کلاینت مشخص می‌کند دقیقا چه داده‌هایی از یک API می‌خواهد و نیاز به مهندسی اضافه‌تری نخواهد بود. به این ترتیب در هزینه‌ها هم صرفه‌جویی خواهد شد.منابعhttps://newsletter.systemdesign.one/p/scalable-software-architecturehttps://engineering.linkedin.com/architecture/brief-history-scaling-linkedinhttps://www.linkedin.com/blog/engineering/architecture/how-linkedin-adopted-a-graphql-architecture-for-product-developm#:~:text=The%20GraphQL%20architecture%20we%20use,at%20LinkedIn%20is%20completely%20autogenerated.https://www.linkedin.com/blog/engineering/data-science/lambda-to-lambda-less-architecturehttps://www.linkedin.com/blog/engineering/infrastructure/linkedin-s-graphql-journey-for-integrations-and-partnershipsمعماری آمازونآمازون یک برنامه در حوزه تجارت الکترونیک است. برنامه‌هایی که در این حوزه هستند برخی از الزامات غیرکارکردی مانند تاخیر کم، دسترسی بالا و پایداری بالا داشته باشد. همچنین باید قابلیت‌هایی نظیر امکان جستجوی کالاها، ایجاد سبد خرید، پرداخت، مشاهده تاریخچه سفارشات و ... ارائه دهد.در طی یک مصاحبه با مدیر ارشد آمازون، اطلاعاتی از معماری نرم‌افزار آن به دست آمده است. آمازون از یک کتابفروشی آنلاین کوچک به یکی از بزرگترین فروشگاه های دنیا تبدیل شد. در حال حاضر، بیش از 55 میلیون حساب کاربری فعال و بیش از 1 میلیون فروشنده در سراسر جهان دارد.در ابتدا معماری آمازون به صورت دو لایه‌ای و مونولیتیک بود. تغییری که در معماری آن رخ داد، باعث شد که به صورت توزیع شده و غیر متمرکز خدمات خود را ارائه دهد. معماری دو لایه آن شامل یک برنامه کاربردی به همراه backend (به زبان C++) بود. سال‌ها تلاش آمازون برای ایجاد مقیاس بندی پایگاه داده جهت نگهداری اطلاعات پشتیبان بود. تغییرات معماری سبب شد که معماری آنها به صورت loosely coupled و با استفاده از سرویس‌ها طراحی شود. این معماری SOA این امکان را فراهم می‌کرد که بتوانند مولفه‌های نرم‌افزاری را به صورت مستقل توسعه دهند.در برخی از مطالب، درباره ساختار معماری وب سرویس آمازون (AWS) صحبت شده است. AWS یکی از برجسته‌ترین و پیشروترین‌های رایانش ابری است. آمازون در بیش از 190 کشور و با بیش از یک میلیون مشتری، از جمله نزدیک به 2000 سازمان دولتی، 5000 موسسه آموزشی و بیش از 17500 سازمان غیرانتفاعی مشتری دارد. همچنین بیش از یک سوم کاربران اینترنت از سایت یا برنامه‌ای بازدید می‌کنند که توسط AWS پشتیبانی می‌شود. AWS خدمات ابری را برای مدیریت ترافیک‌های بالا و داده‌های حجیم تولید شده ارائه می‌دهد. معماری آن نیز تضمین می‌کند که بهترین شیوه‌ها را برای توسعه و نگه‌داری در فضای ابری دنبال می‌کند.معماری AWS شامل چهار مولفه استقرار ابر عمومی، ابر خصوصی، ابر community و ابر هیبرید است. هر یک از این 4 مولفه برای برخی از کارها مناسب هستند. مثلا سازمان‌هایی که تقاضای در حال رشد دارند از ابر عمومی استفاده می‌کنند. یا برای داشتن مقیاس پذیری، امنیت و انعطاف پذیری ابر هیبرید مناسب است. در شکل زیر معماری ساده‌ای برای AWSآمده است. همانطور مه در شکل زیر مشخص شده است، ابر خصوصی سفارشی برای ایمن‌سازی برنامه وب ایجاد می‌شود. در این ساختار ترافیک خارجی به سرورها توسط Elastic Load Balancer ارجاع داده می‌شود.ساختار کلی معماری وب سرویس آمازون شکل فوق یک نمودار معماری ساده برای AWSاست که ساختار اصلی آن را مشخص کرده است. در ادامه به برخی از عناصر مهم معماری آمازون پرداخته خواهد شد. یکی از این عناصر load balancer است که منجر به بهبود کارایی سرورها می‌شود و اغلب به شکل سخت افزاری و به عنوان بخشی از شبکه در حالت سنتی استفاده می‌شود. اما با AWS Elastic Load Balancer، کنترل ظرفیت در شرایط مختلف ترافیک انجام می‌شود و حتی ترافیک خارجی را مدیریت می‌شود.یکی دیگر از عناصر مهم، Cloud Front است. این مولفه اغلب برای تحویل محتوا به کار می‌رود. از طریق این مولفه، کاربران می‌توانند محتوا را به صورت خودکار و از نزدیک‌ترین محل درخواست کنند. این سبب می‌شود زمان تحویل محتوا کاهش پیدا کند و در نتیجه کارایی افزایش می‌یابد. مولفه‌های دیگری برای مدیریت امنیت (استفاده از EC2 که مشابه فایروال شبکه است)، Elastic Cache (برای افزایش مقیاس پذیری، قابلیت اطمینان و دسترسی سریع‌تر به اطلاعاتی که زیاد مورد استفاده قرار می‌گیرند) و Amazon RDS (پایگاه داده رابطه‌ای) هستند.چارچوبی که توسط AWS ارائه شده، ویژگی‌های مهم و منحصر به فردی دارد که در ادامه به برخی از آنها پرداخته شده است. ویژگی اول، امنیت است. معماری AWS اطمینان می‌دهد که از داده‌ها و سیستم‌ها در برابر حملات و تهدیدات امنیتی با استفاده ار رمزنگاری، کنترل دسترسی، حفط محرمانگی و ... محافظت می‌کند.ویژگی دوم، قابلیت اطمینان است. AWS عملکرد مداوم برنامه را با استفاده ار افزونگی، backup و ... تضمین می‌کند تا بتواند خدمات مورد نیاز سرویس گیرندگان را به طور مداوم در دسترس نگه دارد. همچنین AWS باید با سرعت بهینه امکان پاسخگویی را فراهم کند. برای این کار از قابلیت‌هایی مانند انتخاب منابع مناسب، مدیریت ذخیره‌سازی موثر داده‌ها و استفاده از CDN(برای دسترسی سریع) استفاده می‌کند.منابعhttps://medium.com/@kethan.pothula/amazon-system-design-and-architecture-d787a6572f35http://highscalability.com/amazon-architecturehttps://intellipaat.com/blog/what-is-aws-architecture/https://www.tutorialspoint.com/amazon_web_services/amazon_web_services_basic_architecture.htm#:~:text=This%20is%20the%20basic%20structure,%2C%20various%20pricing%20options%2C%20etcمعماری TikTokمعماری نرم‌افزار TikTok برای پشتیبانی از پلتفرم رسانه‌های اجتماعی در مقیاس بزرگ با ویژگی‌هایی مانند اشتراک‌گذاری ویدیو، کشف محتوا، تعاملات کاربر، سیستم‌های توصیه و تجزیه و تحلیل داده‌ها طراحی شده است. این معماری بر اساس ترکیبی از میکروسرویس ها، زیرساخت های ابری، فناوری های پردازش داده ها و الگوریتم های یادگیری ماشین ساخته شده است. از ویژگی‌های مهم این نرم‌افزار تاخیر کم، مقیاس پذیری، در دسترس بودن بالا (حدود 99.999٪ یعنی متوسط زمان قطعی در سال 5.25 دقیقه) و ... است. در ادامه اجزای کلیدی معماری نرم افزار TikTok آمده است:1. معماری میکروسرویس‌ها:تیک تاک از معماری میکروسرویس برای تجزیه سیستم به سرویس‌های کوچک و مستقل استفاده می‌کند که عملکردهای خاصی مانند تایید هویت کاربر، آپلود ویدیو، توصیه محتوا (recommendation)، تعاملات اجتماعی و تجزیه و تحلیل را انجام می‌دهند.این رویکرد با انعطاف‌پذیری، مقیاس‌پذیری و استقرار مستقل سرویس‌ها اجازه می‌دهد که توسعه سریع و توانایی به‌روزرسانی و مقیاس‌بندی اجزای جداگانه بدون تاثیر بر کل سیستم ممکن باشد.2. زیرساخت رایانش ابری:تیک تاک از زیرساخت رایانش ابری، در درجه اول از طریق پلت فرم خود و ارائه دهندگان ابری مانند خدمات وب آمازون (AWS) و پلتفرم ابری گوگل (GCP) استفاده می‌کند. زیرساخت ابری، تیک تاک را قادر می‌سازد تا به صورت پویا منابع را بر اساس تقاضا تخصیص دهد و دسترس پذیری بالا، و مقیاس‌پذیری داشته باشد. همچنین خدمات محاسباتی، ذخیره سازی، شبکه و پایگاه داده لازم را برای پشتیبانی از عملیات تیک تاک فراهم می‌کند.3. پردازش و تجزیه و تحلیل داده‌ها:تیک تاک حجم زیادی از داده‌ها را برای تعاملات کاربر، توصیه‌های محتوا و ... پردازش می‌کند. این شامل پردازش real-time داده، پردازش دسته‌ای و الگوریتم‌های یادگیری ماشینی برای استخراج بینش و ارائه تجربیات شخصی برای کاربران است.فناوری هایی مانند Apache Kafka، Apache Flink، Apache HBase و Elasticsearch برای indexing بلادرنگ، پردازش جریان داده ها و تجزیه و تحلیل استفاده می شوند. تیک تاک همچنین از چارچوب های پردازش داده خود برای تجزیه و تحلیل سفارشی و سیستم های توصیه استفاده می‌کند.4. شبکه تحویل محتوا (CDN):با توجه به حجم زیاد محتوای ویدیویی در تیک تاک، یک CDN برای ارائه محتوای ویدیویی به کاربران در سراسر جهان استفاده می شود. این امر زمان بارگذاری سریع و پخش بدون قطعی را برای کاربران بدون توجه به موقعیت مکانی آنها تضمین می کند.5. بخش load balancerاستفاده از load balancer کمجر به بهبود کارایی می‌شود زیرا ترافیک را بر اساس برخی الگوریتم‌های کارآمد هدایت می‌کند.6. استفاده از shardingاین یک پارتیشن افقی در پایگاه داده ایجاد می‌کند. این پارتیشن کردن منجر تقسیم پایگاه داده‌های بزرگ به قطعات کوچک‌تر و سریع‌تر می‌شود و مدیریت آن را آسان‌تر می‌کند.سه بخش CDN، load balancer و Sharding امکان مقیاس‌پذیری را برای این سیستم فراهم می‌کند.یکی از بخش‌های مهم در این برنامه، سیستم توصیه‌گر آن است. در ادامه به توضیحات آن پرداخته شده است.معماری سیستم توصیه گر تیک تاکمعماری سیستم توصیه تیک تاک شامل سه بخش است: فریم‌ورک Big Data، یادگیری ماشین و معماری میکروسرویس‌ها. فریم‌ورک Big Data نقطه شروع سیستم است که پردازش جریان داده به صورت بلادرنگ، محاسبات داده و ذخیره سازی داده را فراهم می‌کند. بخش یادگیری ماشین نیز مهمترین بخش سیستم است که تعدادی الگوریتم‌ها و تکنیک‌های یادگیری ماشین و یادگیری عمیق دارد. این بخش با توجه به اولویت‌های افراد باید بتواند توصیه کند. بخش معماری میکروسرویس هم به عنوان زیرساخت کل سیستم است.1. بخش فریم‌ورک Big Dataدر تیک تاک، بیشتر داده‌ها از سمت تلفن همراه کاربران به سرورها ارسال می‌شود. همچنین اطلاعات دیگری مانند زمان مشاهده ویدئو، میزان فعالیت کاربران، تعداد لایک‌ها، اشتراک گذاری، نظرات و ... نیز وجود دارد. در شکل زیر معماری این بخش مشخص شده است:جمع‌آوری داده‌ها از طریق Flume و Scribe است. سپس این داده‌ها به سمت Kafka هدایت شده و سپس توسط Hadoop پردازش می‌شوند. Apache Hadoop یک سیستم توزیع شده برای پردازش و ذخیره سازی داده‌ها است که کار Map Reduce را برای پردازش توزیع شده انجام می‌دهد. در ادامه YARN وجود دارد که چارچوبی برای زمانبندی کار و مدیریت منابع است.در بخش Storage، اجزایی مانند HDFS (فایل سیستم توزیع شده)، HBase (پایگاه داده مقیاس‌پذیر و توزیع شده برای ذخیره سازی داده‌های ساختارمند در جداول بزرگ)، Hive (زیرساخت data warehouse)، Zookeeper (سرویس coordination با کارایی بالا) دارد. همچنین سیستم‌های پایگاه داده شامل MySQL، MongoDB و ... هستند.از آنجایی که حجم داده‌ها به سرعت افزایش می‌یابد و فریم‌ورک پردازش داده باید به صورت بلادرنگ اینها را پردازش کند، از Apache Spark استفاده شده است. Spark با انجام پردازش در حافظه، کارایی MapReduce را افزایش می‌دهد. در چند سال گذشته، تیک تاک از چارچوب دیگری به نام Flink استفاده کرده است.2. یادگیری ماشینفریم‌ورک یادگیری عمیق و شبکه عصبی مانند TensorFlowبرای انجام بینایی کامپیوتر و پردازش زبان طبیعی (NLP) استفاده می‌شود. برخی از الگوریتم‌های یادگیری ماشین کلاسیک نیز مانند رگرسیون لجستیک استفاده می‌شوند. سایر الگوریتم‌ها شامل شبکه عصبی CNN و شبکه عصبی بازگشتی (RNN) نیز به کار رفتند. هکچنین برای سیستم توصیه گر مواردی مانند content based filtering و collaborative filtering نیز اعمال می‌شوند.برای اینکه تیک تاک بتواند توصیه‌گر خوبی ارائه دهد، کارهای دیگری هم می‌کند:الف) برای پیدا کردن توصیه‌گر خوب، مهندسان چندین الگوریتم یادگیری ماشین را با هم ترکیب می‌کنند و سپس با تست A/B بهترین روش را انتخاب می‌کنند.ب) مدل‌های مورد استفاده گزارشات رایج کاربران مانند زمان دیدن ویدئو، لایک‌ها یا اشتراک‌گذاری و ... را برای پیدا کردن بهترین توصیه‌ها به کار می‌برند. علاوه بر این موارد نیز، ویژگی‌های دیگری هم به مرور به بردار ویژگی تصمیم‌گیری مدل‌ها اضافه می‌شود.ج) مدل‌ها از کاربران بازخورد نیز دریافت می‌کنند. ایت تجربیات کاربران نیز بر روی تصمیمات تاثیر گذاشته و در نهایت خطاها را کاهش داده و توصیه‌ها را بهبود می‌دهد.د) برای اولین بار در توصیه به کاربر جدید که اطلاعاتی از او وجود ندارد، چندین ویدئو بر اساس میزان محبوبیت و کیفیت به کاربر توصیه می‌شود.3. میکروسرویس‌هاتیک تاک از زیرساخت‌های ابری استفاده می‌کند. مؤلفه‌های توصیه‌ای مانند پروفایل کاربر، پیش‌بینی‌ها، فراخوانی و موتور بازخورد کاربر به عنوان API عمل می‌کنند. سرویس‌های آن (ایجاد پروفایل، پیش‌بینی، بازخورد کاربران و ...) با استفاده از API و در فضای ابری مانند Amazon AWS و Microsoft Azure میزبانی می‌شوند.تیک تاک از کانتینری‌سازی با استفاده Kubernetes به عنوان یک orchestrator برای هماهنگی بین سرویس‌ها استفاده می‌کند. Service Mesh نیز ابزار دیگری برای مدیریت ارتباط سرویس‌هاست که وظیفه کنترل چگونگی تبادل و اشتراک داده بین بخش‌های مختلف را بر عهده دارد.به خاطر ضرورت همزمانی بالا، سرویس‌ها با زبان Go (زبان اصلی توسعه در تیک تاک به دلیل پشتیبانی و شبکه داخلی قوی) و gRPC (چارچوب Remote Procedure Control برای ایجاد اتصال مناسب بین سرویس‌ها) توسعه داده می‌شوند.یکی از دلایل موفقیت تیک تاک این است که آنها سعی بر ارائه بهترین تجربه کاربری دارند. به همین دلیل اغلب ابزارها را به صورت داخلی می‌سازند. برای مثال ByteMesh یک نسخه بهبود یافته از Service Mesh است یا KiteX یک فریم‌ورک Golang gRPC با کارایی بالا است.منابعhttps://www.youtube.com/watch?v=yaIYb8n8HnEhttps://www.lavivienpost.com/how-tiktok-works-architecture-illustrated/https://levelup.gitconnected.com/how-tik-toks-engineering-works-f746bb82645dhttps://www.youtube.com/watch?v=oYY10fWtSr0https://kindsonthegenius.com/system-design/system-design-design-tiktok-interview-question/معماری Uberمعماری نرم افزار اوبر برای پشتیبانی از شبکه حمل و نقل در مقیاس بزرگ طراحی شده است که مسافران را به رانندگان متصل کرده و میلیون‌ها تراکنش و داده‌ها را به صورت بلادرنگ پردازش می‌کنند. شروع این معماری مانند بسیاری از نرم‌افزارهای دیگر با مونولیتیک، تعدادی از سرورها و یک پایگاه داده بود. بعدها در حدود سال 2014 معماری آن به سرویس‌گرا با 100 سرویس تبدیل شد.1. معماری میکروسرویس:اوبر از معماری میکروسرویس استفاده می‌کند تا سیستم خود را به سرویس‌های کوچک و مستقلی تقسیم کند که عملکردهای خاصی مانند matching سواری، پرداخت، ردیابی راننده، احراز هویت کاربر و ... را انجام می‌دهد.2. پردازش بلادرنگ داده:پردازش بلادرنگ داده‌ها جنبه‌ای حیاتی از معماری اوبر است، زیرا نیاز به مدیریت حجم زیادی از داده‌ها از منابع مختلف مانند درخواست‌های مسافر، مکان‌های راننده، شرایط ترافیک و تراکنش‌های پرداخت دارد.اولویت سرویس‌دهی در اوبر، تلفن همراه است. به این صورت که ابتدا تقاضاها و داده‌های تلفن همراه را پردازش می‌کند. اما مسئله چالش بر انگیز در پاسخگویی به تقاضا، تعداد متغیر رانندگان است. سیستم Dispatch در اوبر مانند یک پلتفرم بی‌درنگ برای مرتبط کردن مسافر با راننده عمل می‌کند.بنابراین می‌توان گفت که به طور کلی دو سرویس دارد: 1) supply (تامین توسط راننده) و 2) demand (تقاضای مسافر)سرویس supply خودروها را با استفاده از موقعیت جغرافیایی آنها ردیابی می‌کند. این ردیابی با توجه به برخی از ویژگی‌های خودرو مانند تعداد صندلی، نوع وسیله نقیله و ... است.سرویس demand مسئول درخواست‌های مسافران است. وقتی درخواستی ثبت شود، این سرویس موقعیت GPS کاربر را ردیابی می‌کند. همچنین نوع درخواست را پردازش می‌کند و مسئولیت تطبیق نیازمندی‌های مشخص شده در درخواست با آنچه عرضه شده است را دارد.مسئولیت تامین demand با supply بر عهده بخشی به نام DISCO است.سرویس DISCO (Dispatch Optimization)بخش اصلی نحوه کار این بخش با استفاده از GPS (موقعیت مکانی) است. پس باید نقشه‌ها و داده‌های مکانی مدل‌سازی شوند. زمین به شکل کرده است و تقریب مکان فقط با استفاده از طول و عرض جغرافیایی کار دشواری است. بنابراین اوبر با استفاده از کتابخانه Google S2، زمین را به سلول‌های کوچک تقسیم می‌کند و به هر سلول ID منحصر به فردی می‌دهد. اوبر از S2 استفاده می‌کند تا بتواند موقعیت‌های مکانی اطراف تا شعاع مشخصی را پیدا کند. برای مثال برای پوشش دایره‌ای با شعاع 1 کیلومتر از شهر لندن، S2 می‌تواند سلول‌های مورد نیاز را مشخص کند.ویژگی منحصر به فرد کتابخانه S2 این است که برخلاف سیستم‌های جغرافیایی سنتی (نمایش مکان در دو بعد)، همه داده‌ها را در یک کره سه بعدی نشان می‌دهد. یکی از ویژگی‌های همه این کتابخانه، استفاده از کوئری کارآمد برای یافتن اشیا نزدیک، اندازه گیری فواصل و ... است. همچنین از آنجایی که روی مجموعه عظیم داده‌های جغرافیایی گوگل آزمایش شده، می‌توان گفت از دقت خوبی برخوردار است.سرویس supply برای ارسال و ذخیره‌سازی پیام‌ها از Kafka استفاده می‌کند. راننده از APIهای Kafka برای ارسال مکان‌های دقیق به مرکز داده استفاده می‌کند. هنگامی که مکان‌های GPS در Kafka قرار می‌گیرند، به مرور زمان در حافظه اصلی هم ذخیره می‌شوند و هنگامی که سفر انجام می‌شود، در پایگاه داده ذخیره می‌شوند.در ادامه به نحوه پیدا کردن رانندگان برای مسافران پرداخته می‌شود. نکته مهم در انجام این کار، این است که اوبر علاوه بر در نظر گرفتن رانندگانی که آماده هستند، باید رانندگانی که سفر فعلی آنها رو به اتمام است را هم مشخص کند. مثلا حتی ممکن است مسیر یکی از سفرهای در حال انجام را تغییر دهد تا سفر زودتر به پایان برسد و بتواند به علت موقعیت بهتر یا سایر موارد، به این راننده درخواست را تخصیص بدهد.برای انجام عمل dispatch لازم است ابتدا از روی نقشه تمام موقعیت‌های رانندگان در یک شعاع خاص را پیدا کند و سپس ETA (زمان تخمینی برای رسیدن به مسافر) را محاسبه کند. سپس رانندگان را بر این اساس فیلتر کرده و به همه آنهایی که فیلتر شدند درخواست را ارسال می‌کنیم. اگر راننده درخواست را بپذیرد، این فرایند به پایان می‌رسد.معماری سیستمدر ادامه به بررسی اجزای این معماری پرداخته شده است:فایروال برنامه کاربردی وب (WAF): از این بخش برای بررسی‌های امنیتی استفاده می‌شود. برای مثال برخی از IPها را مسدود می‌کند یا بر اساس مکان‌هایی که اوبر از آنها پشتیبانی نمی‌کند، برخی از درخواست‌ها را فقط به load balancer ارسال می‌کند.استفاده از Load Balancer: برای این بخش می‌توان از Load Balancer با تعداد لایه‌های مختلف مانند Layer 3 (مبتنی بر IP) ، Layer4 (مبتنی بر DNS) و Layer 7 (load balancing در سطح برنامه کاربردی) استفاده کرد.استفاده از KAFKA REST API: از این API برای ارسال مکان هر 4 ثانیه یکبار توسط رانندگان ارسال می‌شود تا DISCO بتواند موقعیت را به صورت live رصد کند.پایگاه‌های دادهاوبر قبلا از RDBMS برای ذخیره داده‌های مربوط به profile و اطلاعات مکانی و ... استفاده می‌کرد. اما این روش مقیاس پذیر نبود. به همین دلیل از پایگاه‌های داده NoSQL استفاده کردند. این پایگاه داده به صورت افقی مقیاس‌پذیر است. با توجه به حجم زیاد اطلاعات موقعیت مکان، خواندن و نوشتن در آن با کارایی بالاتری انجام می‌شود و همچنین دسترس‌پذیری مورد انتظار را برآورده می‌کند.تجزیه و تحلیلتجزیه و تحلیل داده‌ها امکان درک آنها را فراهم می‌کند. به همین دلیل لازم است که Uber بتواند داده‌های مرتبط با مشتریان و رانندگان تحلیل کند. تمام اطلاعات راننده و مسافر در پایگاه داده NoSQL یا RDBMS یا HDFS ذخیره می‌شوند. برای پردازش، داده‌ها از صف Kafka برداشته شده و سپس توسط Hadoop تجزیه و تحلیل می‌شوند.نحوه مواجهه با failureمشکل در دیتاسنترها به ندرت پیش می‌آید اما برای جلوگیری از ایجاد مشکل، اوبر دیتاسنتر پشتیبان دارد. اوبر در این دیتاسنتر داده‌های موجود در دیتاسنترهای دیگر را کپی نمی‌کند. در واقع اوبر از تلفن همراه رانندگان به عنوان منبعی برای داده‌های سفرها استفاده می‌کند تا با خرابی دیتاسنترها مقابله کند. وقتی که تلفن همراه راننده با سرویس Dispatch ارتباط برقرار می‌کند، این سیستم وضعیت رمزگذاری شده (برای پیگیری آخرین داده‌ها) را به تلفن همراه راننده ارسال ارسال می‌کند و در هر بار ارتباط این اطلاعات در برنامه راننده دریافت و ذخیره می‌شود. اگر برای دیتاسنتر مشکلی پیش بیاید، دیتاسنتر پشتیبانی اطلاعاتی درباره سفر ندارد، بنابراین خلاصه وضعیت را از برنامه راننده درخواست کرده و اطلاعات خود را بر اساس همین داده‌ها به روز می‌کند.منابعhttps://medium.com/@narengowda/uber-system-design-8b2bc95e2cfehttps://medium.com/nerd-for-tech/uber-architecture-and-system-design-e8ac26690dfchttps://interviewnoodle.com/uber-system-architecture-40201134aaeahttps://www.geeksforgeeks.org/system-design-of-uber-app-uber-system-architecture/معماری تلگرامتلگرام سرویس پیام‌رسانی فوری و VoIP (Voice over IP فناوری مرتبط با امکان تماس صوتی از طریق اتصال به اینترنت) مبتنی بر فضای ابری است که در سال 2013 راه‌اندازی شد. تلگرام قابلیت‌هایی مانند ارسال پیام‌های متنی و چند رسانه‌ای، برقراری تماس صوتی و تصویری و ایجاد گروه و کانال‌ها را فراهم کرده است. همچنین یک بستر امن است که با رعایت حریم خصوصی افراد و داشتن سرعت بالا و قابلیت اطمینان، این تضمین را می‌دهد که فقط گیرنده پیام به آن دسترسی دارد.تلگرام با بیش از 700 میلیون کاربر فعال ماهانه تا سال 2023 به یک بستر ارتباطی محبوب در جهان تبدیل شده که علت اصلی محبوبیت آن، رعایت حریم خصوصی و ایجاد فضای امن برای تعاملات است. همچنین قابلیت سفارشی‌سازی را نیز دارد.کلیت معماریهمانطور که اشاره شد، اصلی‌ترین ویژگی کیفی تلگرام امنیت و قابلیت اطمینان است. برای دستیابی به این هدف از ترکیبی از مدل‌های کلاینت-سرور، شبکه‌های P2P (peer to peer) و فضای ذخیره‌سازی مبتنی بر فضای ابری استفاده می‌کند.هسته اصلی معماری، کلاینت-سرور است. این بخش معماری جایی است که که کاربران با سرورهای تلگرام برای ارسال و دریافت پیام تعامل می‌کنند. سرورها نقش واسطه را دارند که پیام‌ها را به کلاینت‌ها ارسال می‌کنند. همچنین تا زمانی که پیام تحویل نشده باشد در فضای ابری ذخیره می‌شود.استفاده از شبکه P2P برای بهینه کردن سرعت پیام‌رسانی و کاهش لود سرور است. در این صورت و با استفاده از شبکه P2P، وقتی دو کلاینت به یک شبکه متصل می‌شوند می‌توانند بدون واسطه قرار دادن سرورها با هم به صورت مستقیم در ارتباط باشند. در نتیجه سرعت ارسال پیام‌ها و تاخیر کاهش می‌یابد.علاوه بر این دو مولفه، تلگرام از فضای ابری برای ذخیره‌سازی پیام‌ها و همگام‌سازی استفاده می‌کند. در هنگام ارسال پیام توسط کاربر، ابتدا رمزگذاری می‌شود و سپس در فضای ابری ذخیره می‌شود تا تضمین شود که پیام‌ها همیشه در دسترس هستند و کاربر با هر دستگاهی که به حساب کاربری او متصل است، بتواند همه پیام‌ها را ببیند. در نتیجه همه دستگاه‌ها با هم همگام خواهند بود.ویژگی‌های امنیتی تلگرامیکی از نقاط قوت تلگرام، امنیت و رعایت حریم خصوصی است. در ادامه به برخی از کارهایی که در این راستا انجام شده اشاره خواهد شد. تلگرام پیام‌ها را رمزگذاری می‌کند و تضمین می‌کند که فقط گیرنده پیام می‌تواند آنها را بخواند و دسترسی داشته باشد. در این صورت پیام‌ها در دستگاه فرستنده رمزگذاری می‌شوند و فقط در گیرنده پیام، رمز گشایی می‌شوند. حتی این تضمین را می‌دهد که نه تنها هیچ شخص سومی، بله خودش هم نمی‌تواند به پیام‌ها دسترسی داشته باشد.علاوه بر رمز کردن پیام‌ها، تلگرام این امکان را می‌دهد که پیام‌هایی که ارسال شدند پس از یک زمان مشخص حذف شوند. این ویژگی تضمین می‌کند که پیام‌های حساس یا محرمانه برای مدت زمان طولانی در سمت گیرنده وجود نداشته باشند. یکی دیگر از قابلیت‌هایی که منجر به حفط حریم شخصی می‌شود، secrete chatها هستند. در چت‌های secret، از ارسال پیام‌ها به شخص دیگری جلوگیری می‌کنند و همچنین قابلیت حذف پیام‌ها بعد اززمان مشخصی را می‌دهند. این چت‌ها فقط در همان دستگاهی که مکالمه در آنها آغاز شده وجود دارند و در سرورهای تلگرام ذخیره نمی‌شوند. همچنین برای ایجاد امنیت بیشتر، از احراز هویت دو مرحله‌ای (Two-Factor Authentication) هم استفاده می‌کند که از دسترسی غیر مجاز به حساب کاربری جلوگیری می‌کند.بخش APIهای تلگرامتلگرام دو API مختلف برای توسعه‌دهندگان ارائه داده تا با آن در ارتباط باشند. یکی از این APIها، مربوط به ربات تلگرام است. این API امکان ایجاد chat bot را فراهم کرده است که می‌توانند با کاربران تلگرام در تعامل باشند و کارهایی مانند ارسال و دریافت پیام، مدیریت چت و پاسخ به برخی از سوالات کاربر و ... را انجام دهند. همچنین این API امکان ارتباط با سرویس‌های دیگر و حتی پلتفرم‌های دیگر را فراهم می‌کند. دومین API مربوط به TDLib است. پایگاه داده تلگرام (TDLib) یک کتابخانه برای ایجاد کاربران خاص تلگرام با ویژگی‌های پیشرفته است.ارائه APIها توسط تلگرام به توسعه دهندگان اجازه می‌دهد تا برنامه‌های خود را با این پلتفرم یکپارچه کنند. در نتیجه می‌تواند قابلیت‌هایی فراتر از پیام‌رسانی را به کاربران بدهد. از نظر فنی و پیاده سازی API تلگرام مبتنی بر پروتکل MTProto است که برای برقراری ارتباط سریع و ایمن بین کاربر و سرور طراحی شده است. همچنین این API از زبان‌های برنامه نویسی مختلف مانند پایتون، جاوا و Node.js پشتیبانی می‌کند. علاوه بر این، API دسترسی به چندین ویژگی از جمله پیام‌رسانی، چت‌های گروهی، اشتراک‌گذاری فایل و موارد دیگر را فراهم می‌کند.هوش مصنوعیتلگرام از هوش مصنوعی و یادگیری ماشین برای بهبود تجربه کاربری استفاده می‌کند. یکی از نمونه های استفاده تلگرام از هوش مصنوعی، چت‌بات‌ها هستند که امکان پرسش و پاسخ را با استفاده از پردازش زبان طبیعی (NLP) ایجاد می‌کند و کاربران می‌توانند پاسخ سوالات مختلف خود را از آنها بپرسند. مثال دیگر تشخیص اسپم است.ذخیره سازی در فضای ابریذخیره‌سازی در فضای ابری به کاربران این امکان را می‌دهد تا به اطلاعات و پیام‌های خود از هر جا و با هر دستگاهی دسترسی داشته باشند. همچنین این سیستم ذخیره‌سازی بسیار امن و کارآمد است و گزینه مناسبی برای کسانی است که به حریم خصوصی و راحتی اهمیت می‌دهند زیرا تمام اطلاعات در سرورهای تلگرام به صورت رمز شده ذخیره می‌شوند. این رویکرد مزایای زیادی دارد که در ادامه به برخی از آنها اشاره خواهد شد:- ذخیره‌سازی در فضای ابری منجر به قابلیت دسترسی بالا شده و امکان دسترسی به پیام‌ها را از هر جایی می‌دهند.- فضای ابری، رمزگذاری و اقدامات امنیتی پیشرفته را برای محافظت از داده‌های کاربر در برابر دسترسی غیرمجاز فراهم می‌کند.- فضای ابری به نوعی به عنوان گزینه پشتیبان عمل کرده و امکان بازیابی را فراهم می‌کند. همچنین تضمین می‌کند که در صورت آسیب دیدن، گم شدن و ... دستگاه کاربر، اطلاعات از دست نمی‌رود.- فضای ابری امکان مقیاس پذیری دارد و می‌تواند مقدار فضای ذخیره‌سازی مورد نیاز را با توجه به میزان استفاده افزایش یا کاهش دهد.- از نظر هزینه نسبت به روش‌های ذخیره‌سازی سنتی، مقرون به صرفه است.این فضای ذخیره‌سازی از مراکز داده متعدد در مناطق جغرافیایی مختلف استفاده می‌کند تا اطمینان حاصل کند که داده‌های کاربر همیشه در دسترس هستند. همچنین از یک سیستم فایل‌های توزیع‌شده ویژه تلگرام به نام TFS (Telegram File System) استفاده می‌کند که امکان ذخیره‌سازی و بازیابی داده‌ها را فراهم می‌کند.طراحی رابط کاربریطراحی رابط کاربری در برنامه‌های پیام‌رسان بسیار مهم است، زیرا کاربران باید بتوانند به راحتی از برنامه استفاده کنند، مخاطبان خود را پیدا کنند و به راحتی پیام را ارسال کنند. رابط کاربری تلگرام نیز به همین صورت طراحی شده تا تجربه کاربر را بهبود بدهد و استفاده از آن را برای کاربران راحت کند. همچنین UI تلگرام قابلیت تنظیم را در اختیار کاربران قرار می‌دهد.در مقایسه با سایر برنامه‌های پیام‌رسان، طراحی رابط کاربری این پلتفرم استفاده را بسیار ساده کرده و به همین دلیل تلگرام را از سایر پلتفرم‌ها متمایز می‌کند. در واقع می‌توان گفت طراحی UI این پلتفرم باعث محبوبیت آن است. چیدمان المان‌های این برنامه تمیز و مرتب است و به راحتی می‌توان دکمه‌های مورد نظر را پیدا کرد.نسخه وب تلگرامنسخه وب تلگرام (با نام دیگر Webogram) قابل دسترس از مرورگرهای کروم و فایرفاکس است. این برنامه اپلیکیشنی است که بر اساس API تلگرام ساخته شده تا به کاربران موبایل و دسکتاپ اجازه دهد بدون نصب تلگرام از آن استفاده کنند. همچنین این برنامه به عنوان یک اپلیکیشن تک صفحه‌ای طراحی شده و از فریم‌ورک AngularJS استفاده می‌کند.منابعhttps://interviewnoodle.com/telegram-system-architecture-ddf9f7d358dehttps://intuji.com/how-does-telegram-work-telegram-tech-stack/https://delftswa.gitbooks.io/desosa-2017/content/telegram-web/chapter.htmlاین مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است.m_97260858m_97260858Tue, 30 Jan 2024 00:56:20 +0330https://virgool.ir/@m_97260858/خلاصه-پنج-سخنرانی-qdceoblvgeheویدئو اول: Energy-Efficient Software Architecture for Developersلینک ویدئو: https://www.youtube.com/watch?v=xVKJvUHCanQسخنران: Henrik Bærbak Christensenخلاصه:این ویدئو درباره energy efficiency است که در آن تاکتیک‌هایی برای مصرف بهینه انرژی پیشنهاد شد. اگر بخواهیم برای پرسش و پاسخ در فضای کنفرانس به جای حالت شفاهی یک برنامه بنویسیم، عملا انرژی بسیار زیادی را هدر دادیم.برای اینکه معماری ما energy efficiencyداشته باشد، باید فیزیک بدانیم. انرژی میزان کار انجام شده است. سخت‌افزار انژی مصرف می‌کند تا نرم‌افزار بتواند کار خود را انجام بدهد. برای مثال در کامپیوترهای gaming، CPUبه علت مصرف انرژی زیاد داغ می‌کند. برای اینکه بتوانیم خنکش کنیم، باید از فن استفاده کنیم که خودش انرژی مصرف می‌کند!برای اینکه بتوانیم طراحی خوبی داشته باشیم که مصرف انژی کمتری داشته باشد، باید از فریم‌ورک‌های متناسب با green architectureاستفاده کنیم. این فریم‌ورک‌ها شامل فرایندها و تاکتیک‌ها هستند. فرایندها نحوه طراحی را مشخص می‌کنند که در ادامه به معرفی آنها پرداخته شده است.فرایندهای طراحی معماری سبز:1) You need to measureبرای اینکه بتوانیم معماری‌ها را مقایسه کنیم، لازم است آزمایش کنیم. در واقع نیاز به اندازه‌گیری میزان مصرف انژی داریم. برای اینکه بتوانیم اندازه‌گیری کنیم، یک راه استفاده از برنامه‌های دیگر است.2) اولویت‌بندیباید بتوانیم منابع فکری کمتری استفاده کینم و همچنین زمان برنامه نویسی را هم مدیریت کنیم.3) سومین مورد افزایش آگاهی است که از طریق تعامل با افراد حاصل می‌شود.تاکتیک‌های معماری سبز: هفت دسته اصلی از تاکتیک‌های وجود دارد تا بتوانیم به معماری برسیم که مصرف انرژی آن بهینه باشد.1) اگر چیزی را استفاده نمی‌کنیم باید خاموش کنیم. (Shut down when idle)در معماری میکروسرویس بحث scale downو scale up وجود دارد. اگر این scaling انجام نشود، میکروسرویس‌ها خیلی انرژی مصرف می‌کنند. این تاکتیک بیشتر زمانی استفاده می‌شود که می‌خواهیم scalingانجام دهیم.2) Avoid unnecessary resourcesبرای درک بهتر این موضوع، می‌توانیم مثال سفر رفتن را در نظر بگیریم. برای مسافرت دو روزه نباید چمدان را به اندازه یک هفته پر کنیم. در نرم‌افزار هم همین اصل برقرار است. باید سعی کنیم payloadرا کمینه کنیم. مثلا برای ارسال در شبکه، اطلاعات بیهوده نفرستیم.3) Bulk fetch dataمثلا اگر به فروشگاه برویم و چیزی را فراموش کنیم، مجددا باید برگردیم و خرید کنیم. این درباره ترافیک شبکه هم صادق است. اسم این روش batch method است. به جای اینکه هر بار یک بخش از دیتا را بگیریم، در یک bulkبزرگ دیتاها را دریافت کنیم. (27 درصد صرفه جویی در انرژی در سمت سرور)4) Fetch data from proximity(مشابه caching)5) Utilize an efficient technologyدر سال 2017 مقایسه بین مصرف انرژی زبان‌ها برنامه نویسی انجام شد که زبان C از همه بهتر بود و زبان Python امتیاز خوبی نداشت.همچنین باید از پایگاه‌های داده بهینه استفاده کنیم. مثلا استفاده از Redis مصرف انرژی را 31 درصد کاهش می‌دهد.6) Utilize your resource efficiency7) Accept lower fidelityاگر برای ارسال یک عکس، کیفیت آن پایین بیاید راحت‌تر منتقل می‌شود. پس می‌توانیم به جای استفاده از یک تجربه خاص، حالت عادی را استفاده کنیم تا مصرف انرژی کاهش یابد. یکی از راه‌ها در این زمینه کاهش loggingاست.یک راه‌های دیگر هم feature creepاست. شاید در برخی از موارد استفاده از همه جزئیات لازم نباشد.ویدئو دوم: Scaling Your Architecture with Services and Eventsلینک ویدئو: https://youtu.be/Idkz_rOS-ug?si=5Q_TlUxdv2g_RzVSسخنران: Randy Shoupخلاصه:در این ویئدو به چهار حوزه پرداخته شده که شامل Architecture Evolution، Service Architecture، ارتباطات event-driven و ترکیب رویداد و سرویس هستند.1) موضوع اول: Architecture Evolutionسه مرحله برای رشد هر شرکت وجود دارد. مرحله اول starting است که در آن تیم کوچک است و معماری مونولیتیک دارد. (در هیچ نرم‌افزار موفقی از ایتدا معماری میکروسرویس استفاده نشده است)مرحله دوم scaling است که در آن چند تیم وجود دارد و سرعت و مقیاس پذیری در اضافه کردن نیازمندی‌ها دارد. همچنین معماری آن به جای مونولیتیک، میکروسرویس است. مرحله سوم نیز optimizing است که در آن تعداد تیم‌ها کاهش یافته و به جای دستیابی به سرعت و مقیاس‌پذیری هدف کارایی بیشتر است.اگر برنامه‌های موفق مانند eBay، Twitter و آمازون را در نظر بگیریم در ابتدا معماری آنها به صورت مونولیتیک بوده و سپس به میکرورسرویس تغییر کرده است. با توجه به این مثال‌ها، می‌توان گفت که الگویی در تغییر معماری وجود دارد. هیچ نرم‌افزاری از همان ابتدا با میکروسرویس کار خود را شروع نکرده است.2) موضوع دوم: Service Architectureدر هر سامانه در حال رشد، چند تیم وجود دارد که باید بتوانند به صورت مداوم تغییرات را مستقل از بقیه اعمال کنند. معماری این سیستم به ازای هر دامنه دارای یک تیم است که مسئول توسعه و نگهداری سرویس‌های آن است. ارتباط با سرویس‌ها نیز فقط از طریق واسطی است که ارائه دادند.برای مثال اگر سامانه فروش لباس را در نظر بگیریم که فقط یک پایگاه داده دارد، در صورت کندی DB، کل سامانه از کار می‌افتد. راه‌حل این است که DB به صورت مونولیتیک نباشد و decoupled شود.مراحل ایجاد این DB با ایجاد سرویس برای هر جدول در این پایگاه داده است. برای مثال اگر جدول کلاینت را در نظر بگیریم، سرویس استفاده از آن را می‌سازیم و در اختیار سایر سرویس‌ها که به این اطلاعات نیاز دارند، قرار می‌دهیم. در ادامه باید این جدول را از DBمشترک خارج کرده و به شکل خصوصی برای همان سرویس قرار بدهیم. این کار باعث ایجاد service boundary می‌شود.3) ارتباطات event-drivenوقتی استیت برای کاربر، آیتم یا ... تغییر کند، یک رویداد منتشر خواهد شد که بخشی از سیستم به آن واکنش نشان می‌دهد.4) ترکیب سرویس و رویدادهر داده‌ای که در سیستم است، فقط یک سرویس مالک آن است. اما علاوه بر مالک داده، سرویس‌های زیادی هستند که به آن اطلاعات نیاز دارند. در این صورت لازم است که سرویس مالک به آنها یک کپی read-onlyبدهد.در ادامه ویدئو، به بررسی برخی از چالش‌ها و ارائه را‌ه‌حل برای آنها در رابطه با رویدادها و داشتن DBهای خصوصی برای هر سرویس پرداخته شد.- در صورت تغییر استیت، رویداد تولید می‌شود. دو راه حل برای این کار وجود دارد. راه اول change data capture است. در این حالت تغییر در DBنوشته شده و سپس تبدیل به رویداد می‌شود. راه دوم transactional outboxاست که در همان ابتدا تغییر و رویداد متناظر با آن در یک DB ذخیره می‌شوند.- چالش دوم در رابطه با داده‌های اشتراکی است. دو رویکرد برای مدیریت این داده‌ها وجود دارد. راه اول synchronous lookup است. در این رویکرد از سرویس مسئول آن DBسوال کرده و به صورت بلادرنگ پاسخ دریافت کند. راه دوم asynchronous events and local cache است. در این رویکرد، سرویسی که اطلاعات را می‌خواهد آنها را به صورت کش شده ذخیره می‌کند.- چالش بعدی در رابطه با join جداول از DBهای مختلف است. راه اول join in client application است که خیلی ساده بوده ولی در عمل فشار و تاخیر زیادی دارد. راه دوم سرویسی است که materializing the view انجام می‌دهد.- چالش دیگر، transactionها هستند. در DBهای مونولیتیک ایجاد یک تراکنش روی چند موجودیت بسیار راحت است برای برای حالت توزیع شده باید راه‌حل دیگری استفاده کرد. برای این کار باید تراکنش را به صورت جریانی از کارها (workflow) که به آن saga گفته می‌شود، در نظر بگیریم. در واقع یک زنجیره از ‌آپدیت‌ها داریم که هر کدام رویداد ورودی بعدی را تولید می‌کنند. برای roll back نیز باید در جهت عکس رویدادها را تولید کنیم. این رویکرد در بسیاری از سیستم‌ها وجود دارد. برای مثال یک تراکنش بانکی، فرایند توسعه و ... را می‌توان به صورت یک workflowدر نظر گرفت. در این workflow علاوه بر استیت نهایی، استیت‌های میانی هم وجود دارد.ویدئو سوم: Team Topology, Software Architecture and Complexity Scienceلینک ویدئو: https://youtu.be/izLg4NkJQO4?si=OQzPaxNWo1NNVH8bسخنران: James Lewisخلاصه:بحث team topology درباره سازماندهی تیم‌ها و ساختار آنهاست. در اوایل ویدئو نقل قولی از یکی از افراد در آمازون گفته شد:“The bigger we get, the easier it becomes to get bigger”هر قدر تیم‌ها بیشتر شده و مقیاس شوند، ساخت محصولات بیشتر راحت‌تر خواهد بود. هدف team topology و این سازماندهی بهینه کردن جریان رسیدن به ارزش است.چهار نوع تیم از دیدگاه team topologyوجود دارد. اولی stream-aligned است که محصول را مستقیما به مشتری تحویل می‌دهد. سایر انواع تیم نیز شامل enabling team، complicated subsystem و platform team هستند.پیچیدگی معماریفرد بروکس در کتاب خود (The Mythical Man Month) گفته که اضافه کردن نیروی انسانی به پروژه‌ها می‌تواند تحویل آن را به خاطر سربار ارتباط افراد به تاخیر بیندازد. اما در آمازون این طور نبوده و با دو برابر شدن اندازه سازمان درآمد دو برابر می‌شود و تاخیری در پروژه‌ها ایجاد نمی‌شود. علت این اتفاق این است که در آمازون، ارتباطات از طریق واسط مشخصی است و تعداد افراد تیم‌ها کم است به طوریکه همه آنها با داشتن دو پیتزا سیر می‌شوند. آمازون برای بهبود جریان ارزش و تحویل سریع محصول به مشتری سه اصل team isolation، limiting interaction to nearby team و scale Dunbar’s numberاست.سیستم‌های complex adaptiveدر ابتدای این بخش مثالی از پستانداران زده شد. از نظر بیولوژی با اینکه اندازه موش و فیل متفاوت است اما هر دوی آنها دارای فشار خون و ضربان قلب یکسان هستند. آنچه این دو موجود (و سایر پستانداران) را از هم متمایز می‌کند تفاوت در متابولیسم (سوخت‌و‌ساز) آنهاست. هر قدر پستاندار بزرگتر باشد، میزان سوخت‌وساز آن کمتر است. در اینجا قانونی تحت عنوان scaling rule وجود دارد که به همین مسئله اشاره می‌کند. با افزایش دو برابری اندازه پستاندار، سوخت‌وساز آن حدود 0.75 برابر می‌شود. همین اصل برای سازمان‌ها هم برقرار است. یعنی با دو برابر کردن اندازه سازمان (تعداد افراد آن) درآمد دو برابر نمی‌شود بلکه بین 75 تا 85 درصد افزایش می‌یابد. این نوع از scaling را sub-linear scaling می‌نامند.علت این اتفاق چیست؟سیستم‌های complex adaptive دارای چهار مشخصه خودمشابهتی، خودسازماندهی، پیچیدگی و emergence هستند. این سیستم‌ها با در نظر گرفتن سه اصل قابل ساده‌سازی هستند. اصل اول در نظر داشتن سلسله مراتب است. اصل دوم invariant terminating unit و اصل سوم نیز optimizationاست.علت دو برابر نشدن درآمد با دو برابر شدن اندازه سازمان، ساختار سلسله مراتبی است. هر قدر این ساختار عمق بیشتری داشته باشد، جریان‌های اطلاعاتی کندتر بوده و در نتیجه درآمد افزایش خطی با اندازه سازمان نخواهد داشت. پس می‌توان نتیجه گرفت که سازمان‌های سلسله مراتبی رشد sub-linear در درآمد دارند و در نتیحه نرخ سوخت‌وساز آنها کمتر است.اما مدلی دیگری برای مقیاس‌بندی وجود دارد که super-linearنام دارد. در این مدل با دو برابر شدن x، مقدار yبیش از دو برابر می‌شود. این نوع از scaling در ساختار social networkها وجود دارد. مثالی از این ساختار در Spotify و thoughtWorks است.پس به صورت خلاصه:- ساختار سلسله مراتبی که economic of scaling (less than you think) است- ساختار social network که returns to scale (more than you think) استپس می‌توان نتیجه گرفت که آمازون از ساختار social networkاستفاده می‌کند که توانسته درآمد خود را بیشتر کند.ویدئو چهارم: What are reactive system?لینک ویدئو: https://youtu.be/Ysn6eInApYM?si=U1boPLoY1IWeXPOzسخنران: Dave Farleyخلاصه:مانیتفست سیستم‌های reactive یک رویکرد جالب برای معماری نرم‌افزار است. سیستم reactive یک سیستم توزیع شده است که تعدادی مشخصه کابردی دارد. از نظر مانیفست reactive این سیستم‌ها به صورت زیر تعریف می‌شوند:“These systems are more robust, more resilient, more flexible and better positioned to meet modern demands.”سیستم reactive باید دارای ویژگی باشد:1) باید responsive باشد. یعنی در زمان مشخص پاسخ بدهد.2) باید resilient باشد. یعنی در شرایطی که failureرخ داده است باید responsive بماند.3) این سیستم elastic است. در بار کاری مختلف باز هم responsiveمی‌ماند.4) همچنین message driven است. یعنی سیستم reactiveمبتنی بر async message passing است. همچنین بیانگر loosely coupled بودن سیستم‌های reactiveاست.برای درک بهتر این ساختار در ویدئو مثالی آورده شده است. اگر سیستم سفارش کتاب را در نظر بگیریم که از دو بخش store و warehouseتشکیل شده باشد، تمام تعاملات از طریق پیام‌های async است. این ساختار نسبت به حالت sync سریع‌تر است (برای دریافت پاسخ صبر نمی‌کند) و همچنین responsive است.به طور کلی در این ساختار هنگامی که پیام دریافت می‌شود، پردازش انجام شده، استیت برنامه تغییر می‌کند و سپس پیام دیگری به عنوان خروجی داده می‌شود. تنها فرضی هم که برای این سیستم‌ها وجود دارد ارسال پیام است و اینکه بالاخره به دست گیرنده می‌رسد.ویدئو پنجم: When to Use Microservices (And When Not To!)لینک ویدئو: https://www.youtube.com/watch?v=GBTdnfD6s5Qسخنران: Sam Newman and Martin Fowlerخلاصه:در این ویدئو کتاب «Monolith to Microservices» که توسط Sam Newman نوشته شده، معرفی شد و پاسخ به تعدادی از چالش‌ها در همین زمینه داده شد. در ادامه مرور کوتاهی از مباحث مطرح شده آمده است.- چه زمانی باید از میکروسرویس استفاده کنیم؟طبق دیدگاه نیومن، استفاده از میکروسرویس یک تصمیم آگاهانه است که منجر به پیاده‌سازی در یک سبک خاص شده و خروجی مورد انتظاری را به ما می‌دهد. در واقع معیاری که برای انتخاب این سبک وجود دارد با توجه به چیزهایی است که برای ما به همراه خواهد داد. معماری میکروسرویس به ما گزینه‌های زیادی در راستای scale-up می‌دهد، منجر به امکان استقرار مستقل از هم می‌شود و با محدود کردن حوزه اثرگذاری و آسیب ناشی از failureمنجر به تولید نرم‌افزار پایدارتری می‌شود. طبق گفته جیمز لوئیس استفاده از میکروسرویس هزینه‌هایی دارد.“Microservices architecture buy you options”- میکروسرویس نباید گزینه پیش‌فرض در تولید یک نرم‌افزار باشد مگر اینکه دلیل خوبی برای انتخاب آن داشته باشیم.- سه تا از اصلی‌ترین دلایلی که می‌تواند منجر به انتخاب معماری میکروسرویس شوند شامل نیاز به استقرار مستقل، ایزوله کردن داده‌ها و پردازش آنها و نیاز به خودمختاری سازمانی هستند. با استفاده از استقرار مستقل به zero downtimeهم دست پیدا می‌کنیم. در واقع این نیاز برای برخی از برنامه‌ها مانند SaaSضروری است.- برای جلوگیری از distributed monolithic چا کار باید کرد؟این مشکل زمانی پیش می‌آید که با هدف ایجاد معماری میکروسرویس کار را شروع کردیم ولی در عمل برای استقرار یک میکروسرویس به دیگری نیاز است که آن هم به میکروسرویس دیگر برای استقرار خود نیاز دارد و ... در واقع independent deployability برقرار نیست.دو راه حل اصلی نیومن معرفی کرده است:ساخت مکانیزمی برای استقرارپیدا کردن الگوها: برای مثال ممکن است چند میکروسرویس با هم تغییر کنند. این را با ابزارهایی مانند Jira می‌توان از روی کامیت‌ها و داستان‌هایی که تکمیل شدند تشخیص داد. بعد می‌توان این میکروسرویس‌ها را با هم ادغام کرد.نکته مهم در طراحی نیز توجه به information hiding یا پنهان‌سازی اطلاعات است. در میکروسرویس هر قدر اطلاعات بیشتر مخفی شده باشند، امکان تغییرات داخلی بیشتر است.- چرا independent deployability به عنوان اولین دلیل مطرح شد؟ در حالی که بسیار از نرم‌افزارها هستند که به صورت مونولیتیک بوده و حتی فرایند استقرار دارند که خودکار است.مثال‌های زیادی در این زمینه وجود دارد و داشتن فرایند استقرار مداوم برای معماری مونولیتیک هم ممکن است. اما معماری ‌ میکروسرویس تاثیر تغییرات در هر انتشار را محدود‌تر می‌کند. در واقع محیطی ایمن برای اعمال تغییرات ایجاد می‌کند. در واقع استقرار در مونولیتیک هم قابل انجام است اما بسیار زمان‌بر است در حالی که معماری میکروسرویس این کار را سریع‌تر و کارامدتر انجام می‌دهد.چالش دوم درباره افزایش اندازه تیم‌هاست. هر قدر تعداد افراد تیم بیشتر باشد، مدیری و هماهنگی استقرار پیچیده‌تر خواهد بود.- مورد دیگر، مدیریت داده‌هاست. در جداسازی بخش‌ها باید بتوانیم داده‌ها را مدیریت کنیم. جداسازی DBهای رابطه‌ای به خاطر ماهیت آنها ناممکن است زیرا امکان جداسازی روباط را نداریم. پس شاید بهتر باشد از همان ابتدا طراحی را به صورت جداگانه انجام بدهیم و schemaها را جداگانه طراحی کنیم. (حتی اگر DB یکپارچه باشد)این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است.m_97260858m_97260858Fri, 29 Dec 2023 13:35:18 +0330https://virgool.ir/@m_97260858/برخی-مفاهیم-معماری-ujyc1vzbzxgpModular Monolithicمعماری Modular Monolithicمعماری Modular Monolithic معماری نرم‌افزاری است که مزایای طراحی modular را با سادگی یک معماری مونولیتیک ترکیب می‌کند. علت شهرت این معماری، سادگی و قابلیت نگه‌داری (maintainability) بالای آن است. در این رویکرد از یک codebase بزرگ استفاده می‌شود که می‌توان آن را به بخش‌های مجزا تقسیم کرد و هر بخش می‌تواند در صورت لزوم منطق کسب‌وکاری خود را داشته باشد. در این صورت هر یک از این بخش‌ها به صورت مستقل قابلیت توسعه، تست و نگهداری دارند. این جداسازی به گونه‌ای است که ارتباطات بین ماژول‌ها بسیار کم یا به عبارتی loosely coupled باشند.در معماری Modular Monolithic، ما هنوز برنامه و نرم‌افزار یک کل واحد است که توسعه داده شده و مستقر می‌شود. اما این کد به ماژول‌های مستقل برای هر یک از ویژگی‌های مورد نیاز در برنامه شکسته می‌شود. در هر ماژول ویژگی‌های مرتبط با هم از دامنه مسئله دسته‌بندی می‌شوند و به این طریق، وابستگی‌های ماژول‌ها کاهش می‌یابد و یک ماژول را بدون نیاز به تغییر در سایر ماژول‌ها توسعه داده یا اصلاح کرد.این معماری مشابه با معماری میکروسرویس است. اما تفاوت‌هایی دارد. در معماری میکروسرویس، هر میکروسرویس کاملا از بقیه مجزاست، این استقلال تا حدی است که هر ماژول می‌تواند پایگاه داده مجزا، و زبان برنامه نویسی و تکنولوژی متفاوتی از بقیه داشته باشد. همچنین این معماری مقیاس پذیرتر از Modular Monolithic است و با بروز تغییر در یکی از میکروسرویس‌ها می‌توان آن را بدون تاثیر گذاری روی سایر سرویس‌ها کامپایل کرده و مستقر کرد. اما در معماری Modular Monolithic، هر ماژول وابستگی حداقلی به برخی از ماژول‌های دیگر دارد که نسبت به معماری مونولیتیک این وابستگی‌ها بهتر مدیریت می‌شود. همچنین در این حالت نرم‌افزار را می‌توان به عنوان یک کل واحد نگهداری کرد و همین سبب می‌شود پیچیدگی کمتری از معماری میکروسرویس داشته باشد.از مزایای این معماری می‌توان به قابلیت استفاده مجدد، کپسوله سازی قوانین کسب‌وکار، refactor کردن آسان‌تر‌، مدیریت بهتر وابستگی‌ها، پیچیدگی کمتر (به خصوص نسبت به معماری میکروسرویس) و به‌کارگیری آسان‌تر برای توسعه دهندگان اشاره کرد.AWSوب سرویس آمازون (AWS) یک پلتفرم جامع برای رایانش ابری است که توسط آمازون ارائه شده و شامل ترکیبی از سرویس‌های مختلف IaaS، PaaS و SaaSرا ارائه می‌دهد. آمازون اولین وب سرویس خود را در سال 2002 برای کسب‌وکار فروش آنلاین خود ارائه داد. در سال 2006 نیز زیرساخت را به عنوان یکی سرویس (IaaS) ارائه داد. همچنین یکی از اولین شرکت‌ها ارائه دهنده خدمات ابری با پرداخت هزینه بود.وب سرویس آمازون ارائه دهنده خدمات مختلفی است که بر اساس نیازمندی‌های کاربران قابل پیکربندی است. این خدمات شامل بیش از 200 سرویس از جمله محاسبات، پایگاه داده، زیرساخت‌ها، شبکه، هوش مصنوعی، ابزارهای توسعه و ... است. در ادامه به شرح کوتاهی از برخی خدمات AWSپرداخته شده است.سرویس EC2 (Elastic Compute Cloud): این سرویس سرورهای مجازی را برای افزایش ظرفیت محاسبات به کاربران ارائه می‌دهد.سرویس S3 (Simple Storage Service): این سرویس امکان ذخیره سازی داده را فراهم می‌کند. در واقع این سرویس کمک می‌کند تا توسعه‌دهنگان به جای تمرکز روی نحوه ذخیره سازی داده به خود داده‌ها توجه کنند.API-first Approachبرای استفاده از رویکرد API-first باید APIها را اولویت بندی کنیم. را اتخاذ کند، باید API ها را اولویت بندی کند، نقش API های عمومی، خصوصی و شریک در سازمان ها را بشناسد و چرخه عمر API و ابزار مورد نیاز برای تبدیل شدن به API اول را درک کند.Hexagonal architectureمعماری شش ضلعی به معماری پورت و آداپتور نیز معروف است زیرا در آن اپلیکیشنی داریم که از طریق پورت ها یا آداپتورها با اجزای دیگر ارتباط برقرار می‌کند.همچنین از نظر پیاده‌سازی بسیار شبیه به معماری لایه‌ای است اما از نظر مفهومی معماری شش ضلعی برای portability و قابلیت تعویض ساخته شده است تا بتوان قطعات مختلف زیادی داشت که هر یک قابلیت جایگزینی در معماری را داشته باشند.Event Sourcingاگر بخواهیم تمامی تغییراتی که در استیت برنامه رخ داده را ذخیره کنیم، دنباله‌ای از رویداد‌ها خواهیم داشت. اینکار منجر به ایجاد event sourcing می‌شود. در واقع در این رویکرد، تمامی اطلاعات نرم‌افزار را در رویدادهایی که برای آن رخ می‌دهد نگه داری کنیم. این کار در سیستم‌هایی ارزشمند است که می‌خواهیم بدانیم در چه مرحله یا استیتی نرم‌افزار رفتار و عملکرد نادرستی داشته است. یکی از این مثال‌ها سیستم حسابداری است که باید تمامی رویداد‌ها ذخیره شوند تا اگر مشکلی در مقادیر مالی رخ داد (مانند بدهی و بستانکاری) متوجه شویم. در نرم‌افزار این لیست از رویداد‌ها در جایی به نام event store ذخیره می‌شود که به نوعی پایگاه داده‌ای از رویداد‌هاست.Business Process Management Systems (BPMS)به راه حل های نرم افزاری یکپارچه ای که به سازمان ها اجازه می دهند تا فرآیندها را در تمام مراحل به صورت خودکار نظارت و مدیریت کنند، BPMS گفته می شود. سیستم مدیریت فرایند کسب و کار به تعریف گردش کار و ایجاد فرایندها برای وظایف با هر پیچیدگی برای خودکارسازی عملیات در چندین بخش کمک می‌کند. پلتفرم‌های BPM فناوری اصلی برای سازمان‌هایی که در حال تغییر دیجیتال هستند فراهم می‌کند و چرخه تحول، نوآوری و انطباق را تسریع می‌کند. قبل از خودکارسازی جریان کار فرایندها باید مستند شوند و نیاز به برنامه‌ریزی و همکاری و همچنین ابزاری برای نمایش نحوه ظهور فرایندها دارد.مدل‌های فرایند کسب و کار می‌توانند در BPMS با روش‌های مختلف ایجاد شوند. تغییرات مکرر در فرایندهای کسب و کار برای بازارهایی با محیط رقابتی بالا رایج هستند. انواع مختلف روش‌ها و راه حل‌های نرم‌افزاری وجود دارند که سبب تنظیم فرایندها برای مطابقت با شرایط تجاری در حال تغییر پویا می‌گردد. امروزه فرایندها اغلب از کلاس جدیدی از سیستم‌ها و راه حل BPMS استفاده می‌کنند. BPMSها یک رویکرد فرایند محور برای مدیریت شرکت اعمال می‌کنند و سبب خودکارسازی فرایند کسب و کار end-to-end و تغییر سریع در صورت نیاز می‌شوند. مدل‌های فرایند را می‌توان با روش‌های مختلف یا به فرمت‌های مختلف منتشر کرد.Message Queue (such as Kafka and RabbitMQ)اغلب با بزرگتر شدن سیستم و برای جلوگیری از شکست، به جای معماری یکپارچه قدیمی از معماری میکروسرویس استفاده می‌شود. با تقسیم برنامه به واحدهای مستقل کوچکتر نیز، تعداد تعامل بین هر واحد به طور قابل توجهی افزایش می یابد. صف پیام(Messaging queue) یکی از روش های برقراری ارتباط و هماهنگی آسنکرون در واحد های جدا شده ارائه داده و در عین حال عملکرد، قابلیت اطمینان و مقیاس پذیری را بهبود می دهد.در این ساختار ارائه شده، مؤلفه ای که پیام را به صف اضافه می کند تولید کننده و مؤلفه ای که پیام را بازیابی و پردازش می کند مصرف کننده نامیده می شود. مصرف کننده و تولیدکننده مستقیماً با هم تعامل ندارند و از واسطی به نام broker که معمولا صف را مدیریت می کند، با هم در ارتباط هستند.صف های پیام دارای دو ویژگی دوام و ماندگاری هستند. هنگامی که هیچ مصرف کننده فعالی وجود ندارد، broker پیام ها را قبل از حذف آنها از صف نگه می دارد. به این ترتیب پیام ها بادوام هستند. اما اگر کارگزار از کار بیفتد و در این مدت دوباره راه اندازی شود، ممکن است پیام های بافر را از حافظه حذف کند. برای جلوگیری از حذف، باید پیام ها را با افزودن آنها به یک فایل لاگ ماندگار حفظ کنیم.کافکا آپاچی(Apache Kafka) و RabbitMQ نمونه‌هایی از صف پیام هستند.Container orchestration (such as Kubernetes)هم‌نواسازی کانتینر فرآیند خودکار مدیریت یا زمان‌بندی کار کانتینرهای جداگانه برای برنامه‌های کاربردی بر اساس میکروسرویس‌ها در چندین خوشه است.هم‌نواسازی کانتینر، خودکارسازی تمام جنبه های هماهنگی و مدیریت کانتینرها است. هم‌نواسازی کانتینر بر مدیریت چرخه زندگی کانتینرها و محیط های پویای آنها متمرکز است.هم‌نواسازی کانتینر برای خودکارسازی وظایف زیر در مقیاس بالا استفاده می‌شود:پیکربندی و زمان‌بندی کانتینرهاتهیه و استقرار کانتینرهادر دسترس بودن کانتینرهاپیکربندی برنامه‌ها از نظر کانتینرهایی که در آنها اجرا می‌شوندمقیاس‌بندی کانتینرها برای متعادل کردن بار کاری برنامه‌ها در سراسر زیرساختتخصیص منابع بین کانتینرهاتعادل بار، مسیریابی ترافیک و کشف سرویس کانتینرهانظارت بر سلامت کانتینرهاایمن سازی تعاملات بین کانتینرهاابزارهای هم‌نواسازی برای Kubernetes شامل ویژگی های زیر است:استقرار و تکرار خودکار کانتینرهامقیاس آنلاین یا کوچک کردن خوشه های کانتینرمتعادل کننده بار گروه های کانتینربرنامه ریزی مجدد خودکار کانتینرهای ناموفقدر معرض قرار گرفتن کنترل شده پورت های شبکه به سیستم های خارج از خوشهLog Management Tools (such as ELK)ابزارهای مدیریت لاگ عمدتاً لاگها را از سرورهای مختلف از جمله برنامه‌های کاربردی، پایگاه داده، سرورهای پیام‌رسان و ... جمع‌آوری می‌کنند و انها را به یک سرور متمرکز ارسال می‌کنند تا بعدا لاگها را در پایگاه داده تجزیه و تحلیل و فهرست‌بندی کند. سپس کاربر نهایی می تواند وارد کنسول این ابزارها شود و گزارش های ایجاد شده از لاگ ها را تجزیه و تحلیل کند.در ادامه به برخی از عناصر مختلف چنین ابزارهایی اشاره شده است:عوامل(agent) لاگ به سیستم که لاگ ها را جمع می کنندموتور نمایه سازی که لاگ ها را نمایه می کندسرور مدیریت لاگ که درخواست کاربران را برای گزارش ها پردازش می کندموتور استقرار که برای نصب عوامل لاگ استفاده می شودMonitoring tools (such as Prometheus)نظارت بر نرم افزار منتشر شده بخش اساسی از چرخه حیات آن است. ابزارهای مختلفی برای نظارت بر نرم افزار وجود دارد، اما Prometheus قطعا یک ابزار کاربردی برای نظارت بر معیارهای مختلف برنامه است.ابزار Prometheus این امکان را می دهد که معیارها را جمع آوری، پردازش، فیلتر، و تجمیع کنیم و در نهایت آنها را در قالبی قابل خواندن برای انسان نمایش دهیم.در Prometheus، کل پروژه متمرکز است و می توانید برنامه را از یک سرور واحد کنترل کنید و معیارها را در یک نقطه پایانی HTTP در مرورگر وب خود مشاهده کنید.اگرچه می توان از Prometheus برای هر برنامه ای استفاده کرد، اما عمدتاً از آن برای Kubernetes استفاده می شود زیرا بسیاری از ویژگی های Prometheus کاملاً با Kubernetes مطابقت دارد. به عنوان مثال، داده های چند بعدی، فرمت سنجه ها و کشف خدمات.از این رو برنامه Kubernetes بیشتر با استفاده از Prometheus نظارت می شود.افراد جامعه توسعه دهندگان، Prometheus را به عنوان یک ابزار نظارتی عالی برای نظارت بر عملکرد، نظارت ابری، نظارت بر اینترنت اشیا و ... می شناسند.سهولت استفاده و تطبیق پذیری آن، آن را برای بسیاری از انواع برنامه ها مناسب کرده است و تقریباً می تواند هر نوع سنجه ای را کنترل کند.پرومتئوس برای ثبت داده های زمان عددی بسیار مناسب است. با نظارت ماشین محور و همچنین بسیار پویا و سرویس گرا به خوبی کار می کند. پشتیبانی از پرس و جوی داده های چند بعدی نیز از تخصص های آن است.Static Code Analysis (such as SonarQube)تجزیه و تحلیل ایستا روشی برای اشکال زدایی است که با بررسی خودکار کد منبع بدون نیاز به اجرای برنامه انجام می شود. این به توسعه دهندگان درک درستی از پایه کدشان را می دهد و به اطمینان از سازگاری، ایمن بودن و امنیت آن کمک می کند.تجزیه و تحلیل کد ایستا به عملیات انجام شده توسط یک ابزار تجزیه و تحلیل ایستا اشاره دارد که تجزیه و تحلیل مجموعه ای از کدها در برابر یک مجموعه (یا مجموعه های متعدد) از قوانین کدگذاری است.تجزیه و تحلیل کد ایستا و تجزیه و تحلیل ایستا اغلب به جای هم به همراه تجزیه و تحلیل کد منبع استفاده می شود.این نوع تجزیه و تحلیل به نقاط ضعف در کد منبع می پردازد که ممکن است منجر به آسیب پذیری شود. البته، ممکن است از طریق بررسی دستی کد نیز به این امر برسید. اما استفاده از ابزارهای خودکار بسیار موثرتر است.تجزیه و تحلیل کد ایستا در اوایل توسعه، و قبل از شروع تست نرم افزار انجام می شود. برای سازمان هایی که DevOps را تمرین می کنند، تجزیه و تحلیل کد ایستا در مرحله ایجاد انجام می شود. تجزیه و تحلیل کد ایستا با ایجاد یک حلقه بازخورد خودکار، از DevOps پشتیبانی می کند. به این ترتیب توسعه دهندگان زودتر متوجه مشکلات کدشان می شوند و رفع این مشکلات آسان تر خواهد بود.m_97260858m_97260858Tue, 21 Nov 2023 00:51:26 +0330https://virgool.ir/@m_97260858/خلاصه-فصل-پانزده-تا-سی-و-چهار-کتاب-معماری-تمیز-euq2805xoirsبخش پنجم: معماریاز دید نویسنده کتاب معماری تمیز، معماری شامل تفکر درباره تصمیمات مهم و مهارت‌های فنی است. همچنین معمار نرم‌افزار باید اول برنامه نویس خوبی باشد تا بتواند مشکلات اعضای تیم فنی را بهتر درک کند و تیم را به سمت بهره‌وری بالاتر هدایت کند.معماری نرم‌افزار شکلی است که سازنده یا معمار به آن می‌دهد و نرم‌افزار را به مولفه‌ها و نحوه ارتباط آنها تبدیل می‌کند. هدف این شکل ساده‌سازی مراحل توسعه، استقرار، عملیات و نگه‌داری نرم‌افزار است. این کار را با باز گذاشتن تصمیمات تا جای ممکن (leave as many options open as possible for as long as possible) انجام می‌دهد. معماری خوب علاوه بر این مورد، هزینه را کاهش داده و نرخ بهره‌وری برنامه‌نویس را بیشینه می‌کند.در ادامه این نوشته به بررسی چهار مرحله ذکر شده از دید معماری می‌پردازیم. یکی از مراحل، توسعه است. ساختار تیمی متفاوت منجر به تصمیمات متفاوت می‌شود. در این صورت از معماری component-per-team می‌توان استفاده کرد که از نظر استقرار، عملیات و نگه‌داری اصلا مناسب نیست. این معماری در تیم‌های کوچک منجر به داشتن معماری بد می‌شود و در تیم‌های بزرگ برای هر تیم در ساختار شرکت مثلا یک مولفه در نظر گرفته می‌شود.مرحله دیگر استقرار است. هدف معماری در این راستا آسان سازی استقرار سیستم با یک حرکت است. مثلا در معماری میکروسرویس توسعه راحت ولی استقرار پیچیده و مشکل است. مرحله دیگر عملیاتی شدن سیستم است. در این مرحله وظیفه معماری آشکار کردن عملیات است. یعنی باید ویژگی‌ها، رفتار و ... به موجودیت‌های first-classقابل فهم برای توسعه‌دهنده تبدیل شوند.آخرین مرحله نگه‌داری است. این مرحله از سایر مراحل پر هزینه‌تر است. این هزینه شامل spelunking (بررسی نرم‌افزارهای موجود برای پیدا کردن بهترین مکان و استراتژی اضافه کردن یک ویژگی جدید یا رفع نقص) و ریسک (ایجاد defectهای ناخواسته ناشی از تغییرات) است. در اینجا معماری خوب باید باعث کاهش هزینه‌ها شود. راه‌حل شامل تبدیل نرم‌افزار به مولفه‌های مجزا و ایزوله کردن آنها با اینترفیس‌های پایدار است.در فصل‌های قبلی کتاب به این مسئله اشاره شد که نرم‌افزار دارای دو ارزش رفتار و ساختار است و از دید نویسنده کتاب ساختار از اهمیت بیشتری برخوردار است و منجر به نرم و انعطاف پذیر بودن نرم‌افزار می‌شود. راهکاری که برای نرم‌تر بودن نرم‌افزار ارائه شده، باز گذاشتن گزینه‌ها تا جای ممکن است.اکنون باید بررسی کنیم چه گزینه‌هایی را باید باز بگذاریم؟ نرم‌افزار شامل policy و جزئیات است. طبق تعریف کتاب، policy همان قوانین کسب‌وکار و procedureهاست که همان هسته اصلی سیستم است. در مقابل جزئیات قرار دارند که تاثیری روی policy ندارند. طبق این تعریف، هدف معماری ایجاد ساختاری برای نرم‌افزار است که در آن تمرکز روی policyهاست و تصمیم درباره جزئیات تا جای ممکن به تعویق می‌افتد. هر قدر این تصمیمات دیرتر گرفته بشوند، اطلاعات بیشتری کسب کردیم و مناسب‌تر خواهند بود.همانطور که قبلا اشاره شد معماری خوب باید از عملیات و موارد کاربرد، نگه‌داری، توسعه و استقرار نرم‌افزار پشتیبانی کند. اولین دغدغه معمار و اولین اولویت معماری پشتیبانی از موارد کاربری است. در واقع باید رفتار تبدیل به المان‌ها first-class در بالاترین سطح سیستم تبدیل شود تا هدف سیستم در سطح معماری مشخص شود. برای توسعه نیز طبق اصل Conway ساختار طراحی نرم‌افزار یک کپی از ساختار ارتباطات آن است. برای انجام این کار در بهترین حالت، سیستم را باید به تعدادی مولفه کاملا مستقل و مجزا تقسیم کرد. در مرحله استقرار نیز هدف این است که در لحظه بتوان نرم‌افزار را مستقر کرد و معماری خوب به ده‌ها فایل تنظیمات برای این کار متکی نیست. راه‌حل در اینجا ایزوله کردن و تقسیم‌بندی است.معماری خوب باید بتواند تمام این دغدغه‌ها را متوازن کند. اما این کار به دلیل تغییر دغدغه‌ها و ناپایدار بودن اهداف بسیار سخت است. برای همین باید از «باز گذاشتن تصمیمات» استفاده کرد تا بتوان به راحتی سیستم را تغییر داد.طبق اصل SRP در SOLID و اصل CCP، معمار باید لایه‌ها را از هم جدا کند. بنابراین سیستم به تعدادی لایه افقی تقسیم می‌شود که مثلا شامل UI، قوانین کسب‌وکار و پایگاه داده است. هر مورد کاربری نیز سیستم را به تعدادی لایه عمودی تقسیم می‌کند. بنابراین هر مورد کاربری شامل تمام لایه‌های افقی سیستم نیز خواهد بود.حالت‌های جداسازی مختلفی برای این کار وجود دارد که خود آن یک گزینه است. برای مثال می‌توان این جداسازی را در سطح سرویس یا واحدهای اجرایی انجام داد که به مولفه‌های آن سرویس یا میکروسرویس می‌گویند. معماری متناظر با آن نیز معماری سرویس‌گرا است. حالت دیگر جداسازی در سطح استقرار است و سیستم به واحدهایی تقسیم می‌شود که قابلیت استقرار مجزا از هم را دارند. حالت سوم، جداسازی در سطح کد منبع است که منجر به ساختار یکپارچه (monolithic) می‌شود. در مراحل اولیه توسعه مشخص نیست که کدام حالت بهتر است. ممکن است در ابتدا یکی از این سه حالت را انتخاب کنیم ولی در ادامه که سیستم تکامل یابد حالت بهینه تغییر کند. معماری خوب در ابتدا مونولیتیک است وقتی که رشد کند واحدهایی که مستقل از هم استقرار یابند ایجاد می‌شوند و با تکامل بیشتر سرویس‌ها از هم مجزا می‌شوند و به سمت سرویس‌گرایی پیش می‌رود. پس بنابراین باید این تصمیم را تا جای ممکن باز گذاشت.در ادامه کتاب درباره مرزهای معماری صحبت شده است. هدف معماری کاهش نیروی انسانی برای ساخت و نگه‌داری سیستم است. آنچه باعث کاهش قدرت افراد تیم می‌شود، تصمیمات نابه‌هنگامی است که می‌توانست به تعویق بیفتد. این تصمیمات شامل مواردی هستند که تاثیری روی موارد کاربری یا نیازمندی‌های کسب‌وکار ندارند. در کتاب دو مثال از این نوع تصمیمات آورده شده است. در این دو مثال تاثیر مخرب تصمیمی که باید به تعویق می‌افتاد ولی زود گرفته شده بود نشان داده شده است. در ادامه نیز نویسنده یک مثال از پروژه موفق Fitness زده است. در این مثال‌ها انگار خط مرزی بین قوانین کسب‌وکار و جزئیات (مثل پایگاه داده) رسم شده است. کشیدن این مرز منجر به تاخیر انداختن برخی تصمیمات شده و از بروز برخی مشکلات جلوگیری می‌کند. خط مرزی بین موارد با اهمیت و آنهایی است که مهم نیستند.در مثالی از کتاب نشان می‌دهد چگونه می‌توان گفت که پایگاه داده جزو تصمیماتی است که باید به تعویق بیفتد. در واقع پایگاه داده چیزی است که قوانین کسب‌وکار می‌توانند غیر مستقیم از آن استفاده کنند و برای کار با آن به یک واسط نیاز دارند. طبق شکل زیر و جهت وابستگی بین دو مولفه، پایگاه داده می‌تواند هز چیزی باشد و برای قوانین کسب‌وکار مهم نیست.شکل 1 - خط مرزی معماریدرباره ورودی و خروجی‌ها نیز همین مسئله برقرار است. مثلا GUI باید به قوانین کسب‌وکار وابستگی داشته باشد و در نتیجه مرز جداسازی مشابه حالت فوق خواهد بود.بخش بعدی از کتاب معماری تمیز، تحت عنوان معماری افزونه‌ای (Plug-in Architecture) است. در تاریخچه توسعه نرم‌افزار ایجاد پلاگین برای معماری مقیاس‌پذیر و قابل نگه‌داری مطرح شده است. این معماری متشکل از یک هسته (core) و تعدادی پلاگین است. هسته این معماری، قوانین کسب‌وکار است و پلاگین گزینه‌های اختیاری یا مواردی هستند که چند انتخاب برای آنها وجود دارد. با فرض داشتن این نوع معماری اعمال تغییرات نیز عملی می‌شود.استدلال وجود پلاگین نیز مشابه با پایگاه داده است. در اینجا قصد داریم برخی ازماژول‌ها و مولفه‌ها مثل قوانین کسب‌وکار از اغییرات بقیه در امان باشند. معماری افزونه‌ای این امکان را فراهم می‌کند تا با ایجاد فایروال ار انتشار تغییرات به سایر بخش‌ها جلوگیری کنیم. در واقع همان مرزی که در تصویر گرافیکی رسم کردیم، محوری برای تغییر است. مولفه‌هایی که در یک طرف مرز قرار دارند به دلایل مختلفی می‌توانند تغییر کنند. بنابراین می‌توان گفت که همان اصل SRPدر اصول طراحی SOLID استفاده شده است و این اصل مشخص می‌کند مرز را در کجا رسم کنیم. به طور کلی در کشیدن مرز پس از شناسایی مولفه‌ها باید حواسمان باشد که تمام پیکان‌هایی که در مرز قرار دارند در یک جهت و به سمت هسته باشند. این بخش نیز ناشی از اصل DIP در اصول طراحی SOLID است که جهت پیکان‌ها از مولفه‌های‌ سطح پایین به سمت سطح بالا باید باشد.همانطور که اشاره شد، معماری مولفه‌ها و خطوط جداکننده آنها را مشخص می‌کند. تعریف تقاطع خط مرزی (boundary crossing) در کتاب به صورت زیر است:«یک تابع در طرفی از مرز که تابع دیگری را در آن ظرف مرز با پاس دادن داده‌ها فراخوانی می‌کند.»برای اینکه بتوانیم تقاطع خط مرزی را به صورت مناسب ایجاد کنیم لازم است وابستگی‌ها در سطح کد را مدیریت کنیم. از آنجایی که تغییر کوچکی در کد منجر به تغییر کد وابسته به آن شده و در نتیجه نیاز به کامپایل و استقرار مجدد هر دو مولفه دارد، باید مرزها را طوری تغیین کنیم که از تغییرات این چنینی محافظت کنند. در ادامه به بررسی ساختار برخی از مرزهای معماری پرداخته شده است.ساده‌ترین مرزها نمایش فیزیکی ندارند و معمولا به صورت یک قانون و نظم در جداسازی هستند. در واقع این مرزها ناشی از حالت جداسازی در سطح sourceهستند و منجر به ساختار مونولیتیک می‌شوند. این معماری به نوعی چندریختی (polymorphism) پویا جهت مدیریت وابستگی‌های داخلی متکی است. ساده‌ترین تقاطع مرزی نیز فراخوانی یک تابع از کاربر به سرویس‌های نرم‌افزاراست. پس بنابراین ارتباطات از نوع فراخوانی تابع است که بسیار سریع و ارزان هستند. استقرار نیز شامل کامپایل و لینک کردن استاتیک است.نوع دیگر مرزها با توجه به مولفه‌های استقرار است. ساده‌ترین راه نمایش مرزها استفاده از کتابخانه‌های لینک پویا است. در واقع این مرز ناشی از حالت جداسازی در سطح استقرار است. در اینجا نیز مشابه با حالت مونولیتیک ارتباطات از طریق فراخوانی توابع است.نوع دیگر مرزها که قوی‌تر از بقیه است، فرایندهای محلی است. فرایند محلی شامل کدها یا مجوعه‌ای از مولفه‌هاست. ایجاد این فرایندها از طریق خط فرمان (command line) یا فراخوانی‌های سیستمی است. ارتباط اینها از طریق سوکت یا هر راه ارتباطی دیگری در سیستم عامل است و در نتیجه اتباطات نسبت به مرزهای دیگر هزینه‌بر هستند.قوی‌ترین مرز معماری، سرویس است که هر سرویس مجموعه‌ای از فرایندهای محلی است. این نوع مرز به مکان فیزیکی وابستگی ندارد و فرض این است که در همه سرویس‌های در شبکه قرار دارند. این فرض منجر می‌شود که در مقایسه با فراخوانی توابع بسیار کندتر باشد و تاخیر خیلی زیادی داشته باشد.نرم‌افزار توضیحی از policyهاست. بخشی از توسعه معماری مربوط به جداسازی این policyها از یکدیگر و قرار دادن آنها در گروه‌ها بر مبنای علت تغییراتشان است. نتیجه این جداسازی نیز یک گراف بدون حلقه و جهت‌دار (DAG) است. معماری خوب است که جهت وابستگی‌ها در آن براساس سطح مولفه‌ها و از پایین به بالا باشد.سطح هر مولفه «فاصله میان ورودی و خروجی» آن است. هر قدر یک policy از ورودی و خروجی دورتر باشد سطح آن بالاتر است. این policyها با نرخ کمتری تغییر می‌کنند و دلایل تغییرشان مهم‌تر است. از طرفی دیگر policyکه مسئول مدیریت ورودی و خروجی است پایین‌ترین سطح را دارد که با نرخ بیشتری تغییر می‌کنند و دلایل تغییرشان فوریت بیشتر و اهمیت کمتری دارد. این policyهای سطح پایین به صورت پلاگین با policyهای سطح بالا در ارتباط هستند.همانطور که قبل‌تر اشاره شد معماری افزونه‌ای شامل دو بخش هسته (قوانین کسب‌وکار) و پلاگین‌هاست. در ادامه توضیحاتی درباره قوانین کسب‌وکار داده شده است. این قوانین چه به صورت سیستمی و یا به صورت دستی اجرا شوند، منجر به تولید سرمایه یا ذخیره آن می‌شوند. به همین دلیل به آنها قوانین حیاتی کسب‌وکار (Critical Business Rules) گفته می‌شود. این قوانین در اجرا نیاز به داده‌هایی دارند که به آنها داده‌های حیاتی کسب‌وکار گفته می‌شود. این داده‌ها و قوانین به هم متصل‌اند و بهترین کاندیدایی هستند که شی موجودیت (Entity) را ایجاد می‌کنند. این موجودیت کاملا مربوط به کسب‌وکار است و جزئیات دیگری ندارند. واسط این موجودیت نیز شامل توابعی است که قوانین کسب‌وکار اجرایی روی داده‌ها را پیاده‌سازی کردند.مورد کاربری روشی است که یک سیستم خودکار استفاده می‌شود. در واقع مورد کاربری قوانین کسب‌وکار application-specific را مشخص می‌کنند. پس می‌توان گفت که کورد کاربری به نوعی موجودیت‌ها را کنترل می‌کند. مثلا مورد کاربری تعیین زمان و چگونگی فراخوانی قوانین، روش انتقال داده و در کل تعامل بین کاربر و موجودیت را بیان می‌کند. با توجه به این توضیحات، مورد کاربری یک شی است که موجودیت از آن اطلاعاتی ندارد. بنابراین طبق اصل DIPاز اصول طراحی SOLID، موجودیت سطح بالا و مورد کاربری سطح پایین است.از آنجایی که قوانین کسب‌وکار سبب ایجاد نرم‌افزار می‌شوند، بنابراین باید از دغدغه‌های سطح پایین مانند UI در امان باشند. پس می‌توان گفت قوانین کسب‌وکار باید دارای بیشترین قابلیت استفاده مجدد و مستقل‌ترین بخش کد باشند.فردی به نام Jacobson معماری را به صورت زیر تعریف می‌کند:«معماری ساختارهایی است که از موارد کاربری نرم‌افزار پشتیبانی می‌کند»بنابراین معماری درباره چارچوب‌ها و ابزارها نیست و معماری خوب تصمیمات مربوط به اینها را به عویق می‌اندازد. پس تاکید روی جداسازی موارد کاربری از دغدغه‌های جانبی است. به عنوان مثال وب یک مکانیزم ارسال است و معماری نیز همین دید را نسبت به وب دارد. پس جزو جزئیات سیستم است و تاثیری روی ساختار ندارد بنابراین می‌تواند به تعویق بیفتد. چارچوب‌ها نیز همینطور هستند زیرا معماری باید درباره سیستم باشد و نه ابزارها و چارچوب‌هایی است که استفاده می‌شود. علاوه بر این موارد معماری باید قابلیت تست نیز داشته باشد و باید بتوانیم موارد کاربری را تست کنیم.یکی از ایده‌های مطرح شده برای معماری، جداسازی است که نرم‌افزار را به تعدادی لایه تقسیم‌بندی می‌کند. سیستم‌هایی که با این معماری ساخته شوند، مشخصه‌های زیر را دارند:1- فریم‌ورک‌ها به عنوان یک ابزار هستند و نه محدودیت.2- تمامی بخش‌ها باید قابلیت تست داشته باشند3- واسط کاربری (UI) به صورت مستقل و بدون تغییر در قوانین کسب‌وکار باید بتواند تغییر کند.4- مشابه مورد قبل برای پایگاه داده نیز برقرار است و قوانین کسب‌وکار ارتباطی با پایگاه داده ندارند.5- همچنین قوانین کسب‌وکار چیزی از دنیای بیرون نمی‌دانندشکل 2 - معماری تمیزدر این شکل ساختار معماری تمیز نشان داده شده است که در مرکز policyها و در اطراف مکانیزم‌ها قرار دارند. طبق این ساختار و قانون وابستگی، دایره‌ها داخلی از بیرونی‌ها اطلاعی ندارند. در ادامه به توضیح مختصری از اجزا این ساختار پرداخته شده است:- موجودیت‌ها: موجودیت یک مجموعه از داده و متدهاست. در واقع در این لایه باید قوانین سطح بالای کسب‌وکار را قرار بدهیم که با تغییرات خارجی کمتر احتمال عوض شدن آنها وجود داشته باشد.- موارد کاربری: این موارد شامل قوانین مختص به آن برنامه (app-specific) و پیاده سازی آنها است. در صورت تغییر کارکرد سیستم، باید موارد کاربری و در نتیجه این لایه تغییر کند و کدهای مرتبط با آن نیز به‌روز شوند.- واسط adapter: این لایه تبدیل داده‌ها را از فرمت مناسب برای موارد کاربری به فرمت مناسب برای فعالیت‌ها خارجی مثل پایگاه داده یا وب تبدیل می‌کند.- فریم‌ورک و درایور: این لایه، خارجی ترین لایه و شامل ابزارهایی مانند پایگاه داده است. تمام جزئیات در اینجا قرار دارد، به خصوص مواردی که ممکن است خطرناک باشند.آیا همین چهار لایه برای معماری کافی است؟ خیر، می‌توانیم در صورت لزوم با توجه به دو نکته لایه اضافه کنیم: 1- وابستگی‌ها از خارج به داخل هستند؛ و 2- هر قدر به مرکز نزدیک شویم، جزئیات کمتر می‌شود و سطح تجرید افزایش می‌یابد.در ادامه همین فصل به توضیح مرزهای متقاطع (crossing boundary) پرداخته شده است. در شکل 2، در مرکز موارد کاربری قرار گرفته است و تمام وابستگی‌ها به سمت داخل است. اما جریان کنترل متفاوت است. برای حل این مسئله از اصل DIPاستفاده می‌شود. برای مثال اگر موارد کاربری به فراخوانی presenter نیاز داشته باشند، یک اینترفیس در لایه موارد کاربری ایجاد می‌کنیم تا از طریق آن با لایه بیرونی ارتباط برقرار شود.داده‌هایی که از این نوع مرز عبور می‌کنند داده‌های ساده و ایزوله هستند و حتما فرمت آنها به حالتی که برای مقصد قابل فهم باشد خواهد بود.در فصل بعدی دربارهpresenter و شی humble صحبت شده است. الگوی شی humble یک الگوی طراحی و راهی برای unit testerهاست تا رفتاری را که به سختی از سایر بخش‌ها جدا می‌شود تست کنند. در این الگو رفتار را به دو ماژ<ل یا کلاس تقسیم می‌کنند:1- بخش humble که بخشی است که به سختی تست می‌شود. برای مثال view (تست واحد برای GUIسخت است)2- رفتار قابل تست یا presenterاز آنجایی که تست پذیری به عنوان یک ویژگی کیفی برای معماری در نظر گرفته می‌شود، استفاده از الگوی شی humble می‌تواند یک مرز منایب برای معماری باشد. یکی از این مرزها Presenter/View است.برای مثال بین پایگاه داده و interactorهای موارد کاربری مرزی به نام gateway پیاگاه داده قرار گرفته است که شامل اینترفیس‌های مختلف برای CRUDاست. این gateway که توسط لایه پایگاه داده پیاده‌سازی شده است در واقع یک شی humbleاست. مثال‌های دیگر در کتاب نیز درباره Data mapper و service listenerاست.پس به طور کلی می‌توان گفت که در اغلب مرزهای معماری از الگوی شی humble استفاده شده است که منجر به افزایش testability می‌شود.در ادامه به مرزهای جزئی پرداخته شده است. اگر بخواهیم از مرزهای کامل معماری استفاده کنیم، بسیار هزینه‌بر است و تلاش زیادی به خصوص در نگهداری نیاز دارد. اما معمار خوب باید به گونه‌ای طراحی کند که در آینده اگر نیاز به چنین مرزهایی بود، بتوان به راحتی آنها را اضافه کرد. در جامعه Agile این تفکر نقضی برای YAGNI است که “You aren’t going to need it”. از آنجایی که ممکن است معماران به این مرزها نیاز نداشته باسند، مفهوم مرزهای جزئی مطرح شد. در ادامه به توضیح سه نوع مرز جزئی پرداخته شده است:مرز جرئی اول: skip the last step - راه ایجاد این نوع مرزها، انجام تمام کارهای لازم برای ساخت مولفه‌های مستقل از هم از نظر استقرار و کامپایل است که در نهایت به سادگی در یک مولفه قرار می‌گیرند. انگار که یک فایل کامپایل و مستقر شده است.مرز جزئی دوم: مرزهای یک بعدی - مرزهای تکامل یافته، برای جداسازی در دو جهت از اینترفیس‌های مرزی استفاده می‌کنند که بسیار پر هزینه است. راه ساده‌تر برای این کار استفاده از الگوی Strategy است.مرز جزئی سوم: استفاده از الگوی Facade - در این نوع مرز، به جای وابستگی مستقیم کلاینت به متدها و سرویس‌ها، از یک واسط استفاده می‌شود و کلاینت به شکل غیر مستقیم به سرویس وابستگی دارد. در نتیجه در صورت بروز هر تغییری در یک سرویس، مجددا باید توسط کلاینت کامپایل شود.شکل 3 - الگوی Facadeاغلب سیستم‌های ساده از سه مولفه UI، قوانین کسب‌وکار و پایگاه داده تشکیل شدند. اما سیستم‌های پیچیده‌تر مولفه‌های بیشتری نیاز دارند. برای مثال اگر یک بازی ساده را نظر بگیریم، UI پیام‌ها را از بازکنان به بخش قوانین کسب‌وکار منتقل می‌کند و قوانین هم اطلاعات را در پایگاه داده ذخیره می‌کنند. اما مولفه‌های دیگری هم ممکن است وجود داشته باشد.در کتاب مثالی از یک بازی به نام Hunt the Wumpus آورده شده است. در این مثال اگر بخواهند که بازی مستقل از زبان باشد، باید بخش متنی UI از قوانین کسب‌وکار جدا شود. اگر وابستگی کد به درستی مدیریت شود، می‌توان هر تعداد کامپوننت UI را مجزا از قوانین ایجاد کرد. مشابه با جداسازی این مولفه، می‌توان انواع ذخیره سازی داده‌ها را هم از قوانین جدا کرد.در این صورت برنامه دارای دو جریان داده می‌شود. یکی از این جریان‌ها داده را از کاربر گرفته و سپس در بخش زبان، با استفاده از یک APIمستقل از زمان از قوانین کسب‌وکار استفاده می‌کند و جریان دیگر هم اطلاعات را ذخیره می‌کند. باز هم ممکن است جریان‌های داده دیگری وجود داشته باشد. به صورت کلی هر قدر که سیستم پیچیده‌تر باشد، ساختار ممکن است به تعداد بیشتری از این جریان‌های تقسیم شود.حتی گاهی ممکن است خود قوانین کسب‌وکار را به مولفه‌های دیگری تقسیم کنیم. مثلا اگر قوانین شامل سیاست‌های سطح بالا و پایین باشند که بهتر است از هم جدا شوند. تمام این تقسیمات به نوعی مرزهای معماری هستند. به عنوان معمار اگر بخواهیم این مرزها را کامل پیاده سازی کنیم، خیلی هزینه دارد و از طرفی اگر آنها را نادیده بگیریم، هزینه اضافه کردن آنها در آینده هم خیلی زیاد است.راه حل این است که به عنوان معمار آینده را هم در نظر بگیریم، محل مرزها، هزینه و ریک هر کدام را تخمین بزنیم و در نهایت درباره پیاده سازی کامل، جزئی یا نادیده گرفتن تصمیم بگیریم. این کار را در همان ابتدای پروژه نمی‌توان انجام داد و باید به صورت مداوم بررسی‌ها انجام شود.در ادامه به مولفه اصلی پرداخته شده است. در هر سیستم، حداقل یک مولفه وجود دارد که مولفه‌های دیگر را ایجاد، هماهنگ و نظارت می‌کند و به آن Main یا اصلی می‌گویند. این مولفه سطح پایین و بسیار کثیف است و در خارجی‌ترین حلقه از معماری تمیز قرار می‌گیرد. پس مولفه Main نقطه ورودی اولیه به سیستم است و فقط سیستم‌عامل به آن وابسته است. وظیفه مولفه Main، ایجاد امکانات مورد نیاز (مانند جریان ورودی) و سپس واگذاری کنترل به بخش‌های سطح بالای سیستم است. همچنین باید وابستگی‌ها از طریق یک فریم‌ورک (Dependency Injection Framework) در آن تزریق شوند.به صورت کلی می‌توانیم Main را به عنوان یک plugin برای برنامه در نظر بگیریم که تنظیمات اولیه را انجام می‌دهد و سپس کنترل را به مولفه‌های سطح بالاتر منتقل می‌کند. همچنین به خاطر افزونه‌ای بودن این مولفه، می‌توان انواع مختلفی از آن را برای هر پیکربندی در نظر گرفت.در فصل بعدی به سرویس‌ها و میکروسرویس‌ها پرداخته شده است که امروزه محبوبیت بالایی دارند. علت این محبوبیت در ادامه آمده است. اما باید توجه داشت که این دلایل کاملا درست نیستند:- سرویس‌ها کاملا مجزا از هم هستند (decoupled)- سرویس‌ها از توسعه و استقرار مستقل پشتیبانی می‌کنند.استفاده از سرویس‌ها یک معماری نیست. زیرا آنچه معماری را مشخص می‌کند، مرزهایی است که policy سطح بالا را از جزئیات سطح پایین جدا می‌کند و همه سرویس‌ها لزوما از نظر معماری مهم نیستند.مزیت اول منجر می‌شود که سرویس‌ها در فضاهای مجاز از هم اجرا شده و به اطلاعات هم دسترسی نداشته باشند. اما این تا حدی درست است. سرویس‌ها از طریق منابع مشترک با هم در ارتباط هستند و در واقع به خاطر همین داده‌ها از هم مجزا نیستند.مزیت دوم به این معنی است که هر تیم مسئول یک سرویس است. همچنین فرض شده که داشتن مولفه‌های مستقل از نظر استقرار و توسعه، مقیاس‌پذیر بوده و در سازمان‌ها بزرگ هم امکان‌پذیر است. اما بخشی از این درست است. در سازمان‌ها بزرگ سرویس‌ها تنها راه ساخت سیستم‌های مقیاس‌پذیر نیستند. همچنین این میزان استقلال بستگی به داده‌ها، کارکرد و سایر موارد مشترک دارد.برای درک بهتر نادرستی دلایل محبوبیت سرویس‌ها، مثالی از یک شرکت تاکسی اینترنتی آمده است که می‌خواهد کارکرد جدیدی اضافه کند تا گربه‌ها را هم بتوانند از مبدا به مقصد ببرند. اما باید این را هم در نظر بگیرند که ممکن است رانندگان یا مسافران به گربه آلرژی داشته باشند. برای اضافه کردن این امکان باید همه سرویس‌ها تغییر کنند. در واقع این نشان دهنده اتصال بین سرویس‌هاست و اینکه نمی‌توانند به صورت مستقل از هم توسعه یابند. این ناشی از دغدغه‌ها متداخل است و فقط مشکل سیستم‌های سرویس‌گرا نیست.چگونه این مشکل در معماری مبتنی بر مولفه حل می‌شود؟ استفاده از رویکرد شی گرایی به حل این مسئله کمک می‌کند. همچنین برای حل مشکل دغدغه‌های متداخل، باید سرویس‌ها با با مولفه‌های داخلی طراحی شوند و از قانون وابستگی هم تبعیت کنند.در ادامه به مرزهای تست پرداخته شده است. تست‌ها هم بخشی از سیستم هستند و در معماری تاثیر دارند. تست‌ها به طور طبیعی از قانون وابستگی تبعیت می‌کنند. تست‌ها بسیار جزئی و concrete هستند و همیشه به کدها وابسته‌اند. به نوعی می‌توان تست‌ها را خارجی‌ترین لایه معماری دانست که هیچ چیز به آنها وابسته نیست.تست‌ها به صورت مستقل قابل استقرار هستند. همچنین ایزوله‌ترین بخش سیستم هستند و برای عملیاتی شدن سیستم ضروری نیستند و هدفشان پشتیبانی از توسعه سیستم است. اما این ایزوله کردن تست‌ها اگر بیش از خد باشد توسعه دهنگان دچار گمراهی شده و تست‌ها را خارج سیستم در نظر می‌گیرند و تست‌ها به خوبی طراحی نمی‌شوند. در نتیجه در صورت تغییر سیستم، تست‌ها تغییر نمی‌کنند، که این منجر به ایجاد مشکل «تست‌های آسیب پذیر یا Fragile Tests Problem» می‌شود. تست‌های آسیب پذیر اغلب تاثیرات نامطلوبی در انعطاف پذیری سیستم داشته باشد.راه حل این مشکل طراحی به شکل testable است. اولین قانون طراحی نرم‌افزار این است که وابسته به چیزهای فرّار و volatile نباشیم. در واقع باید سیستم به گونه‌ای ساخته شود که قوانین کسب‌وکار بدون نیاز به بخش‌های volatile تست شوند.راه حل رسیدن به این قابلیت، استفده از یک APIبرای تست است که بتوانیم تمام قوانین کسب‌وکار را تست کنیم. این APIباید شامل interactorها و adapterهای اینترفیس باشد که توسط رابط کاربری به کار بروند. هدف از APIجدا کردن تست‌ها از برنامه کاربردی است.Structural couplingیکی از قوی‌ترین شکلهای اتصال تست است. با استفاده از API ساختار برنامه از تست‌ها مخفی می‌شود. از طرفی این API برای تست ممکن است منجر به نگرانی‌های امنیتی شود. به همین دلیل توصیه می‌شود که این بخش در مولفه جداگانه نگهداری شود.پس به صورت کلی تست‌ها بخشی از سیستم هستند و باید به خوبی طراحی شوند. اگر با این دیدگاه تست‌ها طراحی نشوند با دشواری در نگه داری رو به رو می‌شویم.در ادامه به بحث معماری تو کار نهفته اشاره شده است. نرم‌افزار چیزی است که می‌تواند عمر مفید طولانی داشته باشد، در حالی که سخت افزار این طور نیست و به طور مداوم در حال بهبود و تکامل است. پس با اینکه نرم‌افزار فرسوده نمی‌شود اما به خاطر عدم میریت وابستگی ممکن است از بین برود.فریمور به معنی نرم‌افزاری که در ROMقرار گرفته نیست و در واقع به جای ذخیره شدن ربطی ندارد. بلکه به دلیل آنچه که به آن وابسته است و میزان سختی تغییر آن، firmware گفته می‌شود. پس آنچه نیاز است firmware کمتر و نرم‌افزار بیشتر است. ما هم زمانی که کدهایمان به پلتفرم وابسته است، firmware می‌نویسیم. برای طولانی کردن عمر نرم‌افزار باید نوشتن firmware را متوقف کنیم و از معماری تو کار استفاده کنیم.سه فعالیت ساخت نرم‌افزار از دید Beck در ادامه آمده است:1- نرم‌افزار باید کار بکند وگرنه از بیزینس خارج می‌شود.2- نرم‌افزار باید درست کار کند. یعنی متناسب با نیازها تغییر کند و بتوان آن را اصلاح کرد.3- نرم‌افزار باید سریع کار کند. یعنی refactor برای بهبود پرفورمنسپس اول باید چیزی که می‌سازیم کار کند و سپس آن را بهتر کنیم. مجبور کردن برنامه برای کارکردن تست app-titude است. برنامه نویسی فراتر از آن است که فقط یک برنامه کار کند.بخش امتیازیبخش ششم از کتاب درباره جزئیات است. در ادامه به خلاصه کوتاهی از هر یک از جزئیات مطرح شده (پایگاه داده، وب، فریم‌ورک) و مطالعه موردی در رابطه با فروش ویدئو پرداخته خواهد شد.در فصل بعدی درباره نقش و اهمیت پایگاه داده در معماری سیستم‌های نرم‌افزاری بحث شده است. از نظر معماری بانک اطلاعاتی بخش جزئی و کوچکی از معماری به شمار می‌رود و رابطه آن با معماری شبیه به رابطه دستگیره در و معماری خانه است. (همین قدر جزئی و کوچک) پس می‌توان گفت که یک جزئیات کوچک در مقایسه با ساختار کلی سیستم نرم‌افزاری است.در ادامه به بحث پایگاه داده رابطه‌ای پرداخته شده است. مدل رابطه‌ای یک فناوری برای ذخیره‌سازی داده‌هاست و بنابراین می‌توان گفت که یک برنامه کاربردی نباید در این زمینه دغدغه‌ای داشته باشد. زیرا طبق توضیحاتنحوه کارکرد آنها، بانک‌های اطلاعاتی یا پایگاه‌های داده مکانیزمی هستند که برای انتقال داده‌ها به عقب و جلو بین سطح دیسک و RAM می‌شوند.در فصل بعدی به وب به عنوان یکی از جزئیات پرداخته شده است. در دهه 90 میلادی وب همه چیز را تغییر داد. در ادامه مثالی از شرکتی به نام Q آورده شده که یک سیستم مالی شخصی بسیار محبوب ایجاد کرد. این شرکت در نسخه‌های بعدی خود GUIرا تغییر داد تا مانند مرورگر شود و بعدها دوباهر این GUI شبیه مرورگر را از بین برده و از نسخه دسکتاپ استفاده کردند. GUIیکی از جزئیات است و وب نیز یک GUI است. پس وب یکی از جزئیات طراحی است و باید آنها را از منطق کسب‌وکار جدا کنیم.در فصل بعدی به فریم‌ورک‌ها پرداخته شده است که جزئی از معماری هستند و خود معماری به شمار نمی‌روند. اغلب فریم‌ورک‌ها به صورت رایگان در اختیار افراد قرار می‌گیرند تا کمکی به جامعه شده باشد. رابطه بین ارائه دهندگان استفاده کنندگان از فریم‌ورک‌ها نامتقارن است. یعنی استفاده کننده باید نسبت به آن تعهد زیادی داشته باشند در حالی که ارائه دهنده هیچ تعهدی به آنها ندارند. همچنین استفاده از فریم‌ورک‌ها توسط استفاده کنندگان برای ارائه دهندگان که کنترل کاملی روی آن دارند، خطری ندارد. ارائه دهنده فریم‌ورک می‌خواهد استفاده کننده را به آن وابسته کند زیرا چیزی که باعث اعتبار آنها می‌شود، داشتن گروه بزرگی از جامعه کاربران است.استفاده از فریم‌ورک‌ها ریسک‌هایی مانند تمیز نبودن معماری دارد و حتی ممکن است در وسط راه فریم‌ورک‌های دیگری پیدا کنیم که بهتر باشند و بخواهیم از آنها استفاده کنیم. راه‌حل این است که فقط از فریم‌ورک‌ها استفاده کنیم و نباید به آنها وابسته باشیم. همچنین نباید بلافاصله با دیدن یک فریم‌ورک از آن استفاده کنیم و به جامعه کاربران آن بپیوندیم. بلکه باید تا حد امکان تصمیم‌گیری در این زمینه را به تاخیر بیندازیم تا حتی شاید بدون نیاز به استفاده از برخی فریم‌ورک‌ها بتوانیم با هزینه کمتر به هدف خود برسیم.در فصل بعدی به مطالعه موردی درباره یک وبسایت که فروش ویدئو پرداخته شده است. اولین گام درتعیین معماری اولیه این سیستم، شناسایی اکتورها و موارد کاربری هستند. در این مثال چهار اکتور (خریدار، ادمین، نویسنده و بازدید کننده) وجود دارد داریم و برای هر یک از آنها موارد کاربری را مشخص کردیم. در مرحلهبعدی معماری مولفه‌ها مشخص می‌شود.در شکل فوق جداسازی مولفه‌ها در دو بعد انجام شده است. اولین بعد جداسازی اکتورها بر اساس مسئولیت‌ها و دومین بعد وابستگی است.یکی از روش‌ها پکیج کردن به وسیله ساختار لایه‌ای است. این روش اولین و ساده‌ترین رویکرد طراحی است که در آن کدها بر اساس دیدگاه فنی به لایه‌های افقی تقسیم می‌شوند. وابستگی در این ساختار فقط به لایه پایین است. به اغلب این تقسیم‌بندی نرم‌افزارها را به سه قسمت تقسیم می‌کند که شامل وب، قوانین کسب‌وکار و ماندگاری (persistence) است.روش دیگر پکیج بر اساس ویژگی است. در این رویکرد برش‌های عمودی بر اساس ویژگی‌های مرتبط و مفاهیم آن دامنه ایجاد می‌شود. پورت‌ها و اداپتورها، معماری شش ضلعی و ... نیز در این روش به جداسازی کمک می‌کنند. به این معنی که کد‌های مرتبط با دامنه در داخل و تعاملات با دنیای بیرونی در ناحیه خارجی قرار می‌گیرند. همچنین باید اصل وابستگی (از سمت خارجی به داخلی) نیز رعایت شود.روش دیگر پکیج بر اساس کامپوننت‌هاست. این رویکرد ترکبیبی از کلیه روش‌هایی است که تا کنون در این کتاب بررسی شده است. در رویکرد پکیج بر اساس کامپوننت، منطق کسب‌وکار را با کدها با هم در یک بسته قرار می‌دهیم که از دید نویسنده همان مفهوم کامپوننت است.در نهایت نیز به این موضوع اشاره شده که باید اندازه تیم، سطح مهارت آنها و پیچیدگی راه‌حل در رابطه با زمان و محدودیت‌های پروژه در نظر گرفت.این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است.m_97260858m_97260858Sat, 21 Oct 2023 00:09:00 +0330