https://virgool.io/feed/@mojtabao121 fa 2026-07-16 04:46:48 https://files.virgool.io/upload/users/2925165/avatar/StnbQV.jpg?height=120&width=120 https://virgool.io/@mojtabao121 https://virgool.io/@mojtabao121/%D8%AA%D8%B3%D8%AA-wkosyroz7qly نویسندگانمجتبی شکوری فرارمین مظفریامیرحسین نوریچکیدهدر این پژوهش،از روش‌ انتروپی انتقالی برای تشخیص اختلال طیف اوتیسم از طریق تحلیل شبکه‌های مغزی استفاده شده است. استفاده از داده‌های تصویربرداری fMRI به‌ویژه در حالت استراحت، همراه با نظریه گراف، امکان مدل‌سازی شبکه‌های پیچیده مغزی را فراهم کرده است. داده‌های حاصل از پایگاه داده ABIDE برای گروه‌های سالم و مبتلا به اوتیسم به‌کار گرفته شدند و با استفاده از روش‌آنتروپی انتقالی، شبکه‌های عملکردی مغزی تجزیه و تحلیل شدند. نتایج نشان داد که تفاوت‌های معناداری در توپولوژی شبکه‌های مغزی این دو گروه وجود دارد. همچنین، استفاده از روش‌های یادگیری ماشین برای طبقه‌بندی ویژگی‌ها نشان‌دهنده دقت بالا در شناسایی افراد مبتلا به اوتیسم است. این نتایج می‌تواند به توسعه ابزارهای خودکار برای تشخیص اوتیسم و مداخلات درمانی هدفمند منجر شود.مقدمهاختلال طیف اوتیسم (ASD) یکی از اختلالات پیچیده و چندبُعدی عصبی-تکاملی است که به‌طور گسترده‌ای بر جنبه‌های مختلف رفتارهای اجتماعی، ارتباطات، تعاملات اجتماعی و فرآیندهای شناختی افراد تأثیر می‌گذارد. این اختلال با وجود پیچیدگی‌های خود، هنوز در تشخیص و شناسایی آن مشکلات زیادی وجود دارد. یکی از دلایل این مشکل، تفاوت‌های چشمگیر در علائم بالینی و شدت اختلال در افراد مختلف است که می‌تواند به تأخیر در تشخیص و مداخلات درمانی مناسب منجر شود. بنابراین، یافتن روش‌های جدید، سریع و دقیق برای تشخیص به‌موقع و بهبود روند درمان برای افراد مبتلا به اوتیسم، امری ضروری است.در سال‌های اخیر، روش‌های تصویربرداری مغزی به‌ویژه تصویربرداری تشدید مغناطیسی عملکردی (fMRI) به‌عنوان ابزارهایی کارآمد برای شناسایی الگوهای مغزی غیرعادی در افراد مبتلا به اختلالات عصبی، از جمله اوتیسم، مطرح شده‌اند. fMRI به ما این امکان را می‌دهد تا فرآیندهای مغزی را در سطح نواحی مختلف مغز مشاهده کرده و ارتباطات عملکردی بین این نواحی را بررسی کنیم. با استفاده از این داده‌ها، تحلیل‌های پیچیده شبکه‌های مغزی به‌ویژه با بهره‌گیری از نظریه گراف، می‌تواند به شبیه‌سازی ساختار و دینامیک مغز در افراد مبتلا به اوتیسم بپردازد و الگوهای مغزی مرتبط با این اختلال را شناسایی کند.نظریه گراف، با مدل‌سازی مناطق مختلف مغز به‌عنوان گره‌ها و ارتباطات میان آن‌ها به‌عنوان یال‌ها، شبکه‌ای پیچیده از فعالیت‌های مغزی را به نمایش می‌گذارد. این مدل‌ها می‌توانند به‌طور دقیق‌تری ساختار و عملکرد شبکه‌های مغزی افراد مبتلا به اوتیسم را نسبت به افراد سالم تجزیه و تحلیل کرده و ویژگی‌های منحصر به فرد مغز اوتیستیک را شبیه‌سازی کنند. استفاده از ابزارهای یادگیری ماشین برای پردازش و طبقه‌بندی داده‌های شبکه‌ای به‌دست آمده از fMRI می‌تواند دقت و کارایی مدل‌ها را افزایش دهد و ابزارهای خودکار و پیشرفته‌ای برای غربالگری و تشخیص اوتیسم فراهم آورد.یکی از مفاهیم کلیدی که در این تحقیق به آن پرداخته شده، استفاده از آنتروپی انتقالی به‌عنوان ابزاری برای تحلیل جریان اطلاعات در شبکه‌های مغزی است. آنتروپی انتقالی، که به‌عنوان یک معیار برای اندازه‌گیری پیچیدگی و جهت‌دار بودن انتقال اطلاعات در سیستم‌های پیچیده عمل می‌کند، می‌تواند به‌طور خاص در شبیه‌سازی نحوه انتقال اطلاعات بین نواحی مختلف مغز و تحلیل الگوهای ارتباطی در مغز افراد مبتلا به اوتیسم به کار رود. استفاده از این ابزار می‌تواند به درک عمیق‌تری از نحوه سازمان‌دهی و رفتار شبکه‌های مغزی در اوتیسم کمک کند.این مقاله با هدف بررسی و تحلیل روش‌های نوین در استفاده از داده‌های fMRI و نظریه گراف برای شناسایی اختلال طیف اوتیسم به‌عنوان یک رویکرد امیدوارکننده در عرصه پژوهش‌های تشخیصی و درمانی این اختلال پرداخته است. یافته‌های این تحقیق می‌توانند به توسعه مدل‌های دقیق‌تر و بهبود ابزارهای تشخیص خودکار در آینده کمک کنند و زمینه را برای مداخلات درمانی هدفمند و شخصی‌سازی‌شده فراهم سازند.کارهای گذشتهرویکرد نظریه گراف برای غربالگری اوتیسم در شبکه‌های پیچیده مغزی :این مقاله با عنوان "رویکرد نظریه گراف برای غربالگری اوتیسم در شبکه‌های پیچیده مغزی" به بررسی روش‌های نوینی برای تشخیص اختلال طیف اوتیسم (ASD) از طریق تحلیل شبکه‌های مغزی می‌پردازد. اوتیسم یک اختلال تکاملی مغزی است که باعث مشکلاتی در ارتباطات اجتماعی، الگوهای تکراری رفتاری و دشواری در گفتار و تعاملات اجتماعی می‌شود. به دلیل پیچیدگی علائم و دشواری تشخیص آن در سنین پایین، نیاز به روش‌های خودکار و دقیق برای غربالگری این اختلال به‌شدت احساس می‌شود. یکی از روش‌های نوین که در این مقاله مورد بررسی قرار گرفته، استفاده از نظریه گراف برای مدل‌سازی شبکه‌های عملکردی مغز بر اساس داده‌های تصویربرداری تشدید مغناطیسی عملکردی (fMRI) است.در این پژوهش، ابتدا داده‌های fMRIاز پایگاه داده‌ای عمومی USC Multimodal Connectivity Database استخراج شده است. این مجموعه داده شامل 42 فرد مبتلا به اوتیسم و 37 فرد سالم (Typically Developing) است که در شرایط استراحت مغزی، از آن‌ها اسکن fMRIگرفته شده است. در مرحله اول، پردازش داده‌ها به‌گونه‌ای انجام شده که مغز هر فرد به‌عنوان یک شبکه پیچیده مدل‌سازی شود. در این مدل، هر منطقه مغزی به‌عنوان یک گره در نظر گرفته شده و ارتباط عملکردی میان این مناطق به‌عنوان یال‌های شبکه تعریف شده است. برای این کار، از آتلانسی به نام Power-264 Atlasاستفاده شده که شامل 264 منطقه مغزی مشخص‌شده است. سپس، میانگین سیگنال BOLD (سطح اکسیژن خون مرتبط با فعالیت مغزی) برای هر منطقه محاسبه و میزان همبستگی میان این مناطق تعیین شده است. این همبستگی‌ها به‌عنوان یال‌های گراف در نظر گرفته شده و پس از اعمال روش‌های نرمال‌سازی، شبکه‌های عملکردی مغز تشکیل شده‌اند. در نهایت، برای تعیین میزان ارتباطات، یک حد آستانه (Thresholding) برای انتخاب یال‌های معتبر تعیین شده است. به‌جای استفاده از یک حد ثابت، پژوهشگران از رویکردی بر اساس چگالی شبکه استفاده کرده‌اند که مقدار آن بین 0.15 تا 0.32 تنظیم شده است تا تعادل مناسبی میان تعداد یال‌ها و دقت مدل‌سازی ایجاد شود.مرحله بعدی، استخراج ویژگی‌های شبکه مغزی برای تشخیص اوتیسم از طریق گرافلت‌ها است. گرافلت‌ها مجموعه‌ای از زیرگراف‌های کوچک و غیرایزومورفیک هستند که نشان‌دهنده الگوهای ارتباطی کوچک در یک شبکه بزرگ‌تر هستند. در این پژوهش، از 29 گرافلت اولیه معرفی‌شده توسط Przulj et al. استفاده شده و فراوانی آن‌ها در شبکه‌های مغزی محاسبه شده است. برای کاهش ابعاد ویژگی‌ها و افزایش دقت مدل، تنها 18 گرافلتی که بیشترین تفاوت را بین افراد سالم و مبتلا به اوتیسم نشان داده‌اند، به‌عنوان بردار ویژگی نهایی انتخاب شده‌اند.پس از استخراج ویژگی‌ها، داده‌ها برای طبقه‌بندی به مدل‌های یادگیری ماشین ارائه شده‌اند. از چندین الگوریتم شامل K-نزدیک‌ترین همسایه (KNN)، ماشین بردار پشتیبان (SVM)، درخت تصمیم و روش‌های ترکیبی استفاده شده است. برای ارزیابی عملکرد مدل‌ها، از روش اعتبارسنجی متقابل پنج‌برابر (Fivefold Cross-validation) استفاده شده و به‌دلیل کوچک بودن مجموعه داده‌ها، فرآیند طبقه‌بندی 100 بار تکرار شده تا نتیجه‌ای پایدار به‌دست آید. نتایج نشان داد که روش Ensemble Bagged Trees که ترکیبی از 30 درخت تصمیم است، بهترین عملکرد را دارد و توانسته با دقت 69.81 درصد افراد مبتلا به اوتیسم را از افراد سالم تشخیص دهد. این روش نسبت به رویکردهای پیشین مانند روش‌های مبتنی بر هندسه ریمانی (Riemannian Geometry) و هندسه گراسمن (Grassmann Geometry) که به‌ترتیب دقت 60.76 و 63.29 درصد داشتند، بهبود 6.5 درصدی نشان داده است.این پژوهش نشان می‌دهد که تحلیل شبکه‌های مغزی با استفاده از نظریه گراف و روش‌های یادگیری ماشین می‌تواند رویکردی امیدوارکننده برای غربالگری اوتیسم باشد. تفاوت‌های مشاهده‌شده در الگوهای گرافلت‌ها بین دو گروه سالم و مبتلا به اوتیسم نشان‌دهنده تغییرات ساختاری و عملکردی در مغز افراد دارای اوتیسم است. علاوه بر این، الگوی کلی نوسانات فراوانی گرافلت‌ها در هر دو گروه مشابه بود، اما برخی گرافلت‌های خاص مانند گرافلت‌های شماره 9 و 13 تفاوت چشمگیری داشتند که می‌تواند به‌عنوان یک شاخص کلیدی برای تشخیص اوتیسم در نظر گرفته شود.با وجود نتایج امیدوارکننده این مطالعه، محدودیت‌هایی نیز وجود دارد. یکی از مهم‌ترین چالش‌ها اندازه کوچک مجموعه داده است که ممکن است بر تعمیم‌پذیری نتایج تأثیر بگذارد. علاوه بر این، روش‌های بهینه‌سازی دیگری مانند استفاده از شبکه‌های عصبی عمیق یا مدل‌های مبتنی بر یادگیری عمیق می‌توانند برای بهبود دقت تشخیص مورد بررسی قرار گیرند. در آینده، استفاده از داده‌های fMRI بزرگ‌تر، ترکیب چندین نوع داده مغزی، و بررسی ویژگی‌های دیگر شبکه‌های پیچیده می‌تواند منجر به ایجاد مدل‌های دقیق‌تر و قابل‌اعتمادتر برای تشخیص اوتیسم شود[1].تشخیص خودکار اختلال طیف اوتیسم با استفاده از شبکه عصبی Convolutionalاین مقاله به بررسی استفاده از شبکه‌های عصبی پیچشی (CNN) برای تشخیص خودکار اختلال طیف اوتیسم (ASD) با استفاده از داده‌های fMRIمی‌پردازد. پژوهشگران برای این منظور از مجموعه داده ABIDE I، که شامل اسکن‌های مغزی از 17 مرکز تحقیقاتی مختلف است، استفاده کرده‌اند. در ابتدا، داده‌های fMRIپردازش شده‌اند که شامل اصلاح حرکت، نرمال‌سازی شدت سیگنال، حذف نویزهای ناشی از حرکات سر و تغییرات فیزیولوژیکی، و فیلترگذاری فرکانسی بوده است. پس از این مرحله، ماتریس اتصال عملکردی مغز بر اساس همبستگی BOLDبین 400 ناحیه مغزی استخراج شده و از اطلس CC400برای پارسلیشن مغز استفاده شده است. سپس این ماتریس‌ها به‌عنوان ورودی به شبکه عصبی پیچشی داده شده‌اند. شبکه طراحی‌شده شامل یک لایه پیچشی، یک لایه ماکزیمم پولینگ، و یک لایه کاملاً متصل (Fully Connected Layer) بوده که با تابع فعال‌سازی Tanhپردازش شده است. در این روش، 400 فیلتر مختلف با اندازه‌های بین 1×392 تا 7×392 اعمال شده‌اند که هرکدام به تحلیل ناحیه‌های مختلف مغزی کمک کرده‌اند. در نهایت، شبکه CNNموفق شد با دقت 70.22% افراد مبتلا به اوتیسم را از افراد سالم تفکیک کند که نسبت به روش‌های پیشین عملکرد بهتری نشان داده است. برای مقایسه عملکرد این مدل، از طبقه‌بندهای SVM، KNN و جنگل تصادفی (RF) نیز استفاده شد که CNNنسبت به آن‌ها دقت بالاتری داشت. پژوهشگران همچنین چهار ناحیه مغزی مهم را شناسایی کردند که بیشترین تأثیر را در تشخیص اوتیسم دارند، از جمله شیار فوقانی (Supramarginal Gyrus) که مسئول پردازش همدلی است. نتایج این مطالعه نشان می‌دهد که شبکه‌های عصبی پیچشی می‌توانند ابزار مؤثری برای غربالگری اوتیسم بر اساس داده‌های fMRIباشند و می‌توانند در آینده با داده‌های بیشتر بهبود یابند[2].غربالگری اوتیسم بر اساس fMRI بدون وظیفه با استفاده از رویکرد نظریه گرافاین مقاله با عنوان "غربالگری اوتیسم با استفاده از fMRI در حالت استراحت و نظریه گراف" به بررسی یک روش خودکار برای شناسایی اختلال طیف اوتیسم (ASD) بر اساس ویژگی‌های شبکه‌های عملکردی مغز پرداخته است. محققان از داده‌های fMRI در حالت استراحت 60 مرد جوان (29 فرد مبتلا به اوتیسم و 31 فرد سالم) استفاده کردند و شبکه‌های مغزی را با نظریه گراف تحلیل کردند.در این روش، ابتدا شبکه‌های عملکردی مغز از طریق ارتباطات بین نواحی مختلف مغزی مدل‌سازی شدند. سپس پارامترهای محلی و جهانی شبکه شامل کارایی شبکه، ضرایب خوشه‌بندی، و ویژگی‌های "small-worldness" محاسبه شد. نتایج نشان داد که افراد مبتلا به اوتیسم دارای کاهش در برخی ویژگی‌های شبکه‌ای در مقایسه با افراد سالم هستند، اما این تفاوت‌ها در سطح پارامترهای جهانی معنی‌دار نبودند. در مقابل، پارامترهای محلی مانند "betweenness centrality" و "degree centrality" در نیمکره راست مغز تفاوت‌های قابل‌توجهی را نشان دادند.برای غربالگری اوتیسم، از این ویژگی‌های شبکه‌ای به‌عنوان ورودی یک سیستم یادگیری ماشین استفاده شد. طبقه‌بندی با چندین الگوریتم از جمله ماشین بردار پشتیبان (SVM) انجام شد که بهترین عملکرد را با دقت 92٪ ارائه داد. این مدل سپس بر روی یک مجموعه داده مستقل شامل 20 فرد مبتلا به اوتیسم و 20 فرد سالم آزمایش شد که در این آزمایش، دقت مدل به 67.5٪ کاهش یافت. این نتیجه نشان داد که ویژگی‌های محلی مغز، اگرچه دقت بالایی در طبقه‌بندی دارند، اما به دلیل تفاوت‌های فردی در داده‌های مستقل، ممکن است برای غربالگری عمومی به‌تنهایی کافی نباشند.در نتیجه، این تحقیق نشان داد که الگوهای اتصال عملکردی مغز در افراد اوتیستیک به‌ویژه در نیمکره راست تغییراتی را نشان می‌دهد که می‌تواند برای تشخیص این اختلال مفید باشد. با این حال، استفاده از مدل‌های چندوجهی و ترکیب داده‌های مختلف مغزی می‌تواند دقت این روش را در آینده بهبود ببخشد[3].تأثیر توپولوژیکی لینک‌های منفی بر پایداری شبکه مغزی در حالت استراحتاین مقاله به بررسی تأثیر توپولوژی (چیدمان اتصالات) بر پایداری شبکه‌ی مغزی در حالت استراحت پرداخته و از نظریه‌ی تعادل ساختاری برای تحلیل این پدیده استفاده می‌کند. نظریه‌ی تعادل ساختاری، که ریشه در روان‌شناسی اجتماعی دارد، روابط سه‌گانه‌ی میان گره‌های یک شبکه‌ی دارای پیوندهای مثبت و منفی را بررسی می‌کند و تعیین می‌کند که آیا این شبکه در وضعیت پایدار قرار دارد یا نه. در این مطالعه، محققان نشان دادند که پیوندهای منفی در شبکه‌ی مغزی حالت استراحت، موجب شکل‌گیری هاب‌های منفی می‌شوند که از طریق کاهش انرژی تعادلی، شبکه را به وضعیت پایدارتر سوق می‌دهند. به این منظور، یک معیار جدید تحت عنوان "تمایل به ایجاد هاب" معرفی شد که میزان تجمع پیوندهای منفی در برخی نودهای شبکه را اندازه‌گیری می‌کند. نتایج نشان داد که شبکه‌های مغزی واقعی، برخلاف شبکه‌های تصادفی با توپولوژی ساده، از الگوی خاصی در توزیع لینک‌های منفی پیروی می‌کنند که این امر باعث افزایش تعداد مثلث‌های متعادل و کاهش انرژی تعادلی شبکه می‌شود.برای آزمایش این فرضیه، محققان از داده‌های تصویربرداری مغزی در پایگاه داده‌ی ABIDEاستفاده کردند و ۵۷ فرد راست‌دست، مرد و جوان را انتخاب کردند تا از تأثیر عوامل مخدوش‌کننده مانند جنسیت و سن جلوگیری شود. آن‌ها با استفاده از تحلیل همبستگی فعالیت‌های مغزی، شبکه‌ی عملکردی مغز را بازسازی کرده و اتصالات آن را به دو دسته‌ی مثبت و منفی تقسیم کردند. سپس برای بررسی تأثیر توپولوژی بر پایداری، شبکه‌های تصادفی (Null Networks) ایجاد شد که دارای همان تعداد نود و نسبت لینک‌های مثبت به منفی بودند، اما توزیع لینک‌هایشان تصادفی بود. نتایج نشان داد که شبکه‌های مغزی واقعی دارای انرژی تعادلی کمتری نسبت به شبکه‌های تصادفی هستند، به این معنی که توپولوژی خاص لینک‌های منفی در مغز باعث افزایش پایداری شبکه می‌شود. همچنین مشخص شد که هاب‌های منفی، که نودهایی با تعداد بالای لینک‌های منفی هستند، در این فرایند نقش کلیدی دارند، چرا که بین "تمایل به ایجاد هاب منفی" و میزان انرژی تعادلی یک رابطه‌ی منفی قوی مشاهده شد.یکی دیگر از یافته‌های مهم مقاله این بود که توزیع درجه‌ی نودهای منفی در شبکه‌ی مغزی از یک الگوی نمایی پیروی می‌کند، که نشان‌دهنده‌ی وجود چندین هاب منفی در مغز است. این ویژگی تأیید می‌کند که پیوندهای منفی برخلاف آنچه که در بسیاری از مطالعات گذشته نادیده گرفته شده‌اند، نقش مهمی در ساختار و پایداری مغز دارند. علاوه بر این، برخی از مناطق مغزی، مانند قسمت‌هایی از شبکه‌ی حالت پیش‌فرض (DMN) و شبکه‌ی کنترل فرونتوپاریتال، توزیع درجه‌ی متفاوتی از کل مغز نشان دادند که نشان‌دهنده‌ی خاصیت برهم‌نهی و ظهور (Emergence) در این مناطق است. در نهایت، پژوهشگران نتیجه گرفتند که مغز در حالت استراحت در یک وضعیت متاستابل (Metastable) قرار دارد که در آن انرژی تعادلی کمینه شده ولی همچنان امکان گذار به حالت‌های دیگر وجود دارد. این یافته‌ها می‌توانند در درک بهتر پایداری شبکه‌های مغزی در بیماری‌های عصبی، مانند اوتیسم، مؤثر باشند و در آینده مسیرهای جدیدی را برای مطالعه‌ی تغییرات شبکه‌ی مغزی در شرایط مختلف ارائه دهند[4].تغییرات در توپولوژی شبکه مغز و جفت اتصال ساختاری-عملکردی مرتبط با اختلال شناختیاین مقاله به بررسی تغییرات توپولوژیکی در شبکه‌های مغزی و ارتباطات ساختاری-عملکردی در افراد مبتلا به اختلال شناختی بدون زوال عقل (CIND) پرداخته و نقش این تغییرات را در نقص شناختی تحلیل می‌کند. نویسندگان با استفاده از تصویربرداری تشدید مغناطیسی (MRI) و تصویربرداری تانسور انتشار (DTI) ساختارهای مغزی و ارتباطات عملکردی را در 97 فرد سالم، 61 فرد با CIND خفیف و 56 فرد با CINDمتوسط مقایسه کردند. بر اساس فرضیه شبکه‌ای تخریب عصبی، بیماری‌های عصبی-تحلیل‌برنده نواحی خاصی از شبکه‌های مغزی را تحت تأثیر قرار می‌دهند و این تغییرات می‌توانند از طریق ارتباطات ساختاری و عملکردی گسترش یابند. مطالعه‌ی حاضر نشان داد که CIND متوسط نسبت به افراد سالم، کارایی جهانی کمتری در شبکه‌های ساختاری دارد، در حالی که تغییرات عملکردی کمتر محسوس بودند. علاوه بر این، ارتباط بین شبکه‌های ساختاری و عملکردی (SC-FC coupling) در بیماران CINDبیشتر از افراد سالم بود و این افزایش با کاهش عملکردهای شناختی مانند حافظه کلامی، عملکرد اجرایی و مهارت‌های بصری-ساختاری مرتبط بود.در سطح منطقه‌ای، در بیماران CINDمتوسط کاهش در مرکزیت نواحی خاصی مانند تالاموس، شبکه حرکتی، و شبکه‌های شناختی عالی مشاهده شد، در حالی که CINDخفیف تنها افزایش مرکزیت در نواحی جداری خلفی داشت. در سطح عملکردی، هر دو گروه CIND مرکزیت و کارایی کمتری در نواحی گیجگاهی و شبکه‌های حرکتی نشان دادند. این یافته‌ها نشان می‌دهند که تغییرات در ساختار و عملکرد مغز در مراحل اولیه بیماری‌های تحلیل‌برنده عصبی متفاوت بوده و به‌صورت پیشرونده افزایش می‌یابند.نتایج این مطالعه همچنین بی‌ثباتی در ارتباطات عملکردی را در CIND نشان می‌دهد، که می‌تواند نشان‌دهنده کاهش انعطاف‌پذیری عملکردی در شبکه‌های مغزی باشد. علاوه بر این، افزایش همبستگی بین شبکه‌های ساختاری و عملکردی (SC-FC coupling) نشان می‌دهد که کاهش پویایی شبکه مغزی با کاهش توانایی‌های شناختی همراه است. این نتایج اهمیت ارزیابی همزمان شبکه‌های ساختاری و عملکردی را در درک مکانیسم‌های عصبی زوال شناختی و همچنین تشخیص و پیش‌بینی بیماری‌های تحلیل‌برنده عصبی نشان می‌دهد. نویسندگان پیشنهاد می‌کنند که مطالعات آینده باید با طراحی طولی، تغییرات تدریجی در توپولوژی شبکه‌های مغزی را بررسی کنند تا نقش آن‌ها در تشدید بیماری‌های عصبی تحلیل‌برنده بهتر مشخص شود[5].تبادل داده های تصویربرداری مغز اوتیسماین مقاله به معرفی و تحلیل Autism Brain Imaging Data Exchange (ABIDE)می‌پردازد که یک کنسرسیوم داده‌های باز است و شامل 1112 مجموعه داده از اسکن‌های fMRI در حالت استراحت (R-fMRI) مربوط به 539 فرد مبتلا به اختلالات طیف اوتیسم (ASD) و 573 فرد سالم هم‌سن (TC) می‌باشد. هدف این پروژه تسریع پژوهش‌ها در زمینه‌ی زیست‌شناسی عصبی اوتیسم از طریق اشتراک‌گذاری داده‌ها و استفاده از آن‌ها برای تحلیل‌های مقیاس بزرگ است.مطالعات پیشین نشان داده‌اند که افراد مبتلا به اوتیسم دارای اختلال در اتصال عملکردی درون‌مغزی هستند، اما یافته‌ها در مورد هیپوکانکتیویتی (کاهش اتصال) و هایپرتانکتیویتی (افزایش اتصال) متناقض بوده است. تحلیل‌های انجام‌شده در این مقاله نشان داد که هر دو نوع تغییر در اتصال عملکردی در افراد اوتیستیک دیده می‌شود، اما هیپوکانکتیویتی غالب است، به‌ویژه در ارتباطات قشری-قشری و بین‌نیمکره‌ای. بررسی‌های منطقه‌ای نیز نشان داد که ناحیه‌های مهمی مانند اینسولا (insula)، قشر سینگولیت خلفی (PCC) و تالاموس دچار تغییرات عملکردی در اوتیسم هستند. این نتایج به درک بهتر نواحی مغزی درگیر در اوتیسم کمک کرده و مسیرهای جدیدی برای تحقیق در مورد مکانیزم‌های عصبی این اختلال ارائه می‌دهد.یکی از دستاوردهای کلیدی این پژوهش، امکان تکرار و بازتولید یافته‌های پیشین در مطالعات اوتیسم بود که نشان‌دهنده‌ی اعتبار و قابلیت استفاده‌ی گسترده‌ی مجموعه داده‌های ABIDEاست. تحلیل‌های گسترده‌ی اتصال عملکردی در کل مغز نشان داد که نواحی مرتبط با شبکه‌ی پیش‌فرض (default mode network) در اوتیسم دچار کاهش اتصال طولانی‌مدت و افزایش اتصال محلی هستند. همچنین، نتایج نشان داد که برخی از نواحی کمتر مورد مطالعه، مانند تالاموس، ممکن است نقش کلیدی در این اختلال داشته باشند.روش‌شناسی این مقاله شامل استفاده از روش‌های مختلف پردازش تصویر مانند تحلیل همبستگی عملکردی، شاخص‌های مبتنی بر وکسل (مانند ReHo، VMHC، DC و fALFF) و تحلیل مبتنی بر بذر (seed-based connectivity) بود. همچنین، برای کاهش اثرات مخدوش‌کننده‌ی حرکت سر در طول اسکن، از روش‌های تصحیح حرکتی استفاده شد که یافته‌ها را بهبود بخشید.این مقاله بر اهمیت داده‌های باز و همکاری بین‌المللی برای پیشرفت علوم اعصاب تأکید دارد و نشان می‌دهد که چگونه یک مجموعه‌ی بزرگ از داده‌های fMRI می‌تواند به کشف الگوهای جدید در اوتیسم و افزایش دقت مطالعات آینده کمک کند. نویسندگان پیشنهاد می‌کنند که تحقیقات بعدی باید بر روی مطالعات طولی برای بررسی تغییرات مغزی در طول زمان و بهبود استانداردهای تشخیصی برای افزایش همگنی داده‌ها تمرکز داشته باشند[6].عصب شناسی شبکه ایاین مقاله به‌طور مفصل رویکردی را معرفی می‌کند که در آن مغز به مثابه یک شبکه پویا و در هم‌تنیده در نظر گرفته می‌شود و با استفاده از نظریه گراف و ابزارهای محاسباتی، سعی دارد سازمان‌دهی ساختاری و عملکردی مغز را توضیح دهد. نویسندگان با تمرکز بر مفهوم «عصب‌پژوهی شبکه‌ای» استدلال می‌کنند که ویژگی‌های اساسی شبکه‌های پیچیده از جمله ماژولاریته، مرکزیت گره‌ها و توزیع مقیاس‌های همبستگی، همگی در مغز انسان مشاهده می‌شود و این ساختار شبکه‌ای پویا، پایه بسیاری از فرایندهای شناختی و رفتاری است. در این پژوهش، افزون بر مرور روش‌های متداول در تحلیل داده‌های تصویربرداری عصبی، مثال‌هایی از کاربرد این روش‌ها در شناخت سازوکارهای ادراکی و نیز درکِ الگوهای آسیب‌شناسی در اختلالات عصبی ارائه شده است. یکی از نکته‌های مهم مقاله این است که تغییرپذیری شبکه‌های مغزی در زمان و شرایط مختلف – نظیر یادگیری یا پردازش محرک‌های بیرونی – می‌تواند منعکس‌کننده توان انعطاف و سازگاری بالای سیستم عصبی باشد. همچنین، نویسندگان رابطه بین ساختار و عملکرد را فراتر از ارتباطات موضعی می‌بینند و توجه را به تعاملات گسترده میان نواحی مختلف مغز جلب می‌کنند که ممکن است در سطوح متعددی (از نورون تا مدارهای عصبی بزرگ‌مقیاس) دنبال شود. این مقاله زمینه‌ای نظری برای بسیاری از تحقیقات بعدی در حوزه شبکه‌های مغز فراهم کرده و به‌ویژه نشان داده است که ترکیب نظریه شبکه با روش‌های جدید اندازه‌گیری عملکرد عصبی، پنجره تازه‌ای به فهم عمیق‌تر فرایندهای شناختی و اختلالات مغزی می‌گشاید. در مجموع، دیدگاه نویسندگان تأکید دارد که برای درک بهتر رفتار و شناخت انسان، لازم است ارتباطات میان اجزای متعدد مغز را به صورت یک کل یکپارچه و شبکه‌ای مطالعه کنیم تا بتوانیم سازوکارهای بنیادین آن را کشف نماییم. [7]کنترل پذیری شبکه های ساختاری مغزدر این پژوهش، نویسندگان با ترکیب داده‌های تصویربرداری ساختاری (نظیر DTI) و ابزارهای نظریه کنترل، می‌کوشند دریابند که کدام نواحی مغز قادر به هدایت دینامیک کل شبکه عصبی هستند. آن‌ها نشان می‌دهند که شبکه‌های مغزی از دیدگاه کنترل‌پذیری دارای نظمی ویژه‌اند؛ بدین معنا که برخی گره‌های کلیدی – که اغلب همان هاب‌های ساختاری هستند – با صرف کمترین تغییر در ورودی می‌توانند وضعیت فعالیت بسیاری از بخش‌های دیگر را تحت تأثیر قرار دهند. این مقاله فراتر از صرف شناسایی این گره‌ها، بیان می‌کند که مغز انسان در شرایط سالم، چیدمانی دارد که حدی بهینه از کنترل‌پذیری را تضمین می‌کند و این امر در یادگیری، انعطاف رفتاری و همچنین واکنش به آسیب‌های عصبی نقش دارد. از نظر روش‌شناختی، تحلیل‌های ریاضی پیچیده‌ای بر ماتریس‌های اتصال ساختاری اجرا و سنجه‌هایی مانند «کنترل‌پذیری میانگین» و «کنترل‌پذیری مرزی» معرفی شده است تا پتانسیل هر ناحیه مغزی در هدایت کل شبکه بررسی شود. یافته‌های اصلی مقاله درک جدیدی از پویایی‌های مغزی ارائه می‌دهد و همچنین برای تفسیر اختلالات نورولوژیک یا روان‌پزشکی که در آن‌ها ساختار ارتباطات مختل شده، کاربرد بالقوه دارد. نکته حائز اهمیت این است که ترکیب تئوری کنترل با علوم اعصاب شبکه‌ای، راه را برای بررسی هدفمند روش‌های درمانی جدید، نظیر تحریک الکتریکی یا مغناطیسی نواحی خاصی از مغز، هموار می‌سازد و می‌تواند به شیوه‌های کارآمدتری در ترمیم اختلالات منجر شود. [8]کنترل پویایی در شبکه های مغزیاین مقاله بر پایه دیدگاه نظریه کنترل در مغز استوار است و تلاش می‌کند چهارچوبی ریاضی و محاسباتی برای درک نحوه کنترل دینامیک شبکه‌های عصبی ارائه دهد. نویسندگان با مرور مطالعات تجربی و شبیه‌سازی‌های متعدد، روشن می‌کنند که کنترل در مغز امری چندوجهی و در برخی موارد غیرخطی است و نمی‌توان آن را تنها با مدل‌های خطی ساده توضیح داد. آن‌ها ضرورت در نظر گرفتن ساختارهای هتروژن (ناهمگن) در مغز، وجود انواع مختلف سیناپس‌ها با وزن‌های متفاوت و نیز نقش تأخیرهای زمانی در ارتباطات را مورد تأکید قرار می‌دهند. این مقاله توضیح می‌دهد که کنترل‌پذیری نقاط کلیدی در شبکه، چگونه فرآیندهای یادگیری، حافظه، تصمیم‌گیری و حتی ترمیم پس از ضایعات عصبی را تحت تأثیر قرار می‌دهد و به‌گونه‌ای از آن دفاع می‌کند که هرچه ساختار شبکه منسجم‌تر و در عین حال دارای تنوع مناسب باشد، امکان کنترل مطلوب و سازگاری بهتر در برابر تنش‌های خارجی یا داخلی افزایش می‌یابد. از سوی دیگر، نویسندگان به چالش‌هایی مانند هزینه انرژی در فرآیند کنترل و پیچیدگی الگوریتم‌های شناسایی گره‌های کنترل‌کننده اشاره دارند و بیان می‌کنند که ترکیب داده‌های بالینی و مدل‌های نظری، می‌تواند درک ما را از بیماری‌هایی مانند صرع یا اختلالات حرکتی دگرگون سازد. این مطالعه در مجموع تصویری جامع از ظرفیت‌ها و محدودیت‌های نظریه کنترل در بررسی شبکه‌های مغزی ترسیم می‌کند و نشان می‌دهد چرا این رویکرد در سال‌های اخیر مورد توجه گسترده‌ای در علوم اعصاب قرار گرفته است. [9]مفاهیم و اصول در تجزیه و تحلیل شبکه های مغزیاین مقاله یک مرور نسبتاً گسترده بر مفاهیم اصلی در تحلیل شبکه‌های مغزی ارائه می‌دهد و می‌کوشد با ارائه تعریف‌ها و مثال‌های روشن، ابزارهای نظریه گراف را به علوم اعصاب پیوند زند. نویسندگان ابتدا بر تفاوت میان سه نوع اتصال مغزی – ساختاری، عملکردی و مؤثر – تأکید می‌کنند و نشان می‌دهند چگونه هر یک نمایانگر جنبه متفاوتی از ارتباطات عصبی است. سپس روش‌های متداول در ایجاد ماتریس‌های اتصال و پردازش داده‌های fMRI را معرفی می‌کنند و توضیح می‌دهند چگونه سنجه‌هایی نظیر مرکزیت، ضریب خوشه‌بندی، طول مسیر میانگین یا ماژولاریته می‌توانند برای شناسایی نواحی کلیدی در شبکه و نحوه خوشه‌بندی فعالیت‌ها به کار روند. این مقاله همچنین بحثی درباره جنبه‌های مختلف کاربرد مدل‌های شبکه‌ای در شناسایی الگوهای گروهی (مثلاً در کودکان با اختلال خواندن یا افراد مبتلا به اوتیسم) ارائه می‌دهد و به این نکته می‌پردازد که نشانه‌های بالینی را می‌توان از منظر عدم تعادل در پیکربندی شبکه تفسیر کرد. در مجموع، این پژوهش نقش مهمی در تبیین زبان مشترک بین عصب‌شناسان و پژوهشگران نظری ایفا کرده و برای کسانی که به تازگی وارد فضای «عصب‌پژوهی شبکه‌ای» می‌شوند، یک راهنمای نسبتاً جامع محسوب می‌شود. مقاله تأکید دارد که آینده علوم اعصاب در گرو درکی منسجم از مغز به عنوان یک سیستم پیچیده است و ابزارهای شبکه‌ای برای رسیدن به این درک، کلیدی به‌شمار می‌آیند. [10]مبانی تحلیل شبکه مغزاثر حاضر، هرچند شکل کتاب دارد، اما بخش‌های مختلف آن اغلب مانند مجموعه مقالات مرجع در حوزه تحلیل شبکه‌های مغزی به‌کار می‌رود و رویکردی نسبتاً نظام‌مند به مباحث شبکه‌ای در علوم اعصاب ارائه می‌دهد. نویسندگان با تکیه بر سال‌ها تحقیق و تدریس در زمینه تصویربرداری مغزی، از مفاهیم ابتدایی شروع می‌کنند و روش‌های ساخت ماتریس‌های اتصال از داده‌های fMRI، DTI و الکتروفیزیولوژی را شرح می‌دهند. سپس به معرفی شاخص‌های گرافی می‌پردازند؛ از معیارهای ساده نظیر درجه گره تا شاخص‌های پیچیده‌تر همچون ماژولاریته و کارآیی جهانی شبکه، و همچنین روش‌های نیرومند آماری برای بررسی معنادار بودن نتایج را تبیین می‌کنند. در ادامه، نمونه‌های متعددی از کاربرد این روش‌ها در اختلالات عصبی مانند اسکیزوفرنی، اختلالات طیف اوتیسم و بیماری آلزایمر آورده شده تا نشان دهند چگونه الگوهای اتصال مختل‌شده با علائم بالینی در ارتباط است. از نقاط قوت مهم این اثر، توجه ویژه به نکات عملی همچون مدیریت نویز، انتخاب آستانه‌های ارتباطی در ماتریس‌های اتصال و چگونگی درستی‌سنجی(Validation) نتایج حاصل از مطالعات شبکه‌ای است. افزون بر این، مولفان با پرداختن به روش‌های نوینی مانند تحلیل پویایی شبکه در طول زمان و ترکیب اطلاعات ساختاری و عملکردی، چشم‌انداز آینده این حوزه را ترسیم می‌کنند که در آن مدل‌های چندلایه (Multilayer) می‌توانند تصویر دقیق‌تری از فعل و انفعالات مغزی ارائه دهند. کتاب حاضر برای پژوهشگرانی که قصد ورود جدی به فضای تحلیل شبکه در علوم اعصاب دارند، مرجع استانداردی تلقی می‌شود و به‌خوبی پایه‌های لازم برای انجام پژوهش‌های تجربی و نظری را پوشش می‌دهد. [11]تئوری اتصال مختل شده قشر مغز به عنوان یک مدل توضیحی برای اختلالات طیف اوتیسمدر این مقاله، نویسندگان نظریه‌ای را پیش می‌کشند که بر مبنای آن، مغز افراد مبتلا به اوتیسم در برقراری ارتباطات درازمدت یا بلندمدت(Long-range) دچار مشکل است و از سوی دیگر، ارتباطات کوتاه‌مدت را تقویت می‌کند. این ایده در تضاد با آناتومی بهینه مغز معمولی قرار دارد که در آن نقاط دور از هم نیز همگرا می‌شوند تا برای کارکردهای عالی شناختی، تبادل اطلاعات صورت پذیرد. نگارندگان با استناد به داده‌هایfMRI، MEG و مطالعات الکتروفیزیولوژیک نشان می‌دهند که این اختلال در ارتباطات قشری می‌تواند ریشه بسیاری از مشکلات اجتماعی، زبانی و شناختی در افراد با اوتیسم باشد. همچنین توضیح می‌دهند که حتی اگر برخی نواحی مغزی در اوتیسم به‌تنهایی عملکرد مناسبی داشته باشند، ضعف در هماهنگی کلی میان این نواحی مانع از سازمان‌یابی درست فرایندهای پیچیده می‌شود. در این راستا، مدل‌های مختلفی از جمله فرضیه کاهش همگرا شدن سیگنال‌ها در پردازش اطلاعات اجتماعی و زبان مطرح می‌گردد که پیامد آن، محدود شدن تعاملات اجتماعی و رفتارهای تکراری است. نویسندگان مقاله از دستاوردهای بالینی نیز سخن می‌گویند و اشاره می‌کنند که مداخلات درمانی احتمالی می‌تواند بر بهبود انسجام شبکه‌ای مغز در سطحی گسترده متمرکز شود تا کارایی شبکه‌های دوربرد افزایش یابد. این نظریه «اتصال‌پذیری مختل‌شده» تاکنون الهام‌بخش بسیاری از پژوهش‌های مرتبط با تصویرسازی مغزی در اوتیسم بوده و زمینه‌ساز رویکردهای متفاوتی در ارزیابی و تشخیص زودهنگام شده است. [12]شبکه های ساختاری و عملکردی مغز: از ارتباطات تا شناختاین مقاله به رابطه تنگاتنگ میان ساختار آناتومیک شبکه‌های مغزی و نحوه بروز عملکرد شناختی می‌پردازد و تأکید دارد که درک ساختار اتصال‌ها، سنگ بنای فهم الگوهای فعالیت عملکردی است. نویسندگان معتقدند که ساختارهای متمایز قشری و زیرقشری که از طریق رشته‌های عصبی به هم وصل هستند، در کنار هم شبکه‌ای می‌سازند که ظرفیت بالایی برای تبادل اطلاعات دارد و این ظرفیت در سطح عملکردی، به شکل هم‌بستگی‌های زمانی در سیگنال‌های ثبت شده از fMRI یا سایر روش‌های تصویربرداری نمود می‌یابد. مقاله همچنین توضیح می‌دهد که تغییر در ساختار – مثلاً در نتیجه ضایعات یا مشکلات تکاملی – می‌تواند الگوهای عملکردی را به‌طور جدی تغییر دهد و این امر خود منجر به ناهنجاری‌های شناختی یا رفتاری می‌شود. با بررسی مجموعه‌ای از شواهد تجربی، نویسندگان به این نتیجه می‌رسند که شبکه‌های مغزی واجد خواصی چون کوچک‌جهانی (Small-Worldness) هستند که باعث می‌شود ارتباطات محلی و جهانی به شکل همزمان در دسترس باشد. از دید آنان، چنین ساختاری برای پردازش پیچیده اطلاعات لازم است و تضعیف یا قطع برخی ارتباطات دوربرد می‌تواند منجر به اختلالات متعددی شود. مقاله با پیشنهاد روش‌های آماری و مدل‌های دینامیکی ادامه می‌یابد و نشان می‌دهد که جمع‌آوری و ترکیب داده‌های ساختاری (مثل DTI) و داده‌های عملکردی (مثل fMRI) می‌تواند تصویری جامع‌تر از مغز ارائه دهد که در تفسیر فرایندهای شناختی عادی و بیمارگونه، بسیار راهگشا است. [13]نقش کلیدی جفت شدن، تاخیر و نویز در نوسانات مغزی در حال استراحتدر این مقاله، نقش عوامل حیاتی مانند کوپلینگ (Coupling)، تأخیر انتقال سیگنال و نویز تصادفی در شکل‌دهی الگوهای خودبه‌خودی مغزی در وضعیت استراحت مورد مطالعه قرار می‌گیرد. پژوهشگران با بهره‌گیری از مدل‌های دینامیک شبکه نشان می‌دهند که ترکیبی از تأخیرهای زمانی در ارسال سیگنال‌ها میان نواحی مغزی و حضور نویز با اندازه مناسب، می‌تواند الگوهای همبستگی مکانی و زمانی را توضیح دهد که در fMRI حالت استراحت مشاهده می‌کنیم. این یافته مهم است زیرا تا پیش از آن، مکانیزم ایجاد این همبستگی‌ها در غیاب محرک بیرونی چندان روشن نبود. مقاله تأکید می‌کند که هرچند ساختار شبکه (یعنی نقشه اتصالات فیزیکی) لازم است، اما کافی نیست و برای درک پویایی واقعی باید عوامل زمانی و تصادفی را نیز در محاسبات وارد کرد. نویسندگان در مسیر آزمایش مدل‌های مختلف، به این نتیجه می‌رسند که سطح نویز نباید خیلی بالا یا خیلی پایین باشد تا مغز بتواند در عین پایداری، رفتارهای پیچیده و متنوعی از خود نشان دهد. این موضوع با نظریه «حالت بحرانی» در مغز نیز همخوانی دارد که بر لبه آشوب تنظیم می‌شود تا مغز بتواند با کمترین انرژی، بیشترین تنوع پاسخ را داشته باشد. افزون بر این، مقاله به اهمیت این عوامل در تحلیل اختلالات مغزی اشاره می‌کند و بیان می‌دارد که هرگونه برهم خوردن ظریف در سطح کوپلینگ یا مدیریت نویز می‌تواند الگوهای حالت استراحت را تغییر دهد و نشانه‌های بالینی خاصی را به همراه آورد. [14]شکنندگی و نوسانات هاب های ساختاریاین مطالعه بر اهمیت هاب‌های ساختاری (نواحی پرتراکم در شبکه مغزی) متمرکز است و می‌کوشد نشان دهد که باوجود نقش کلیدی این گره‌ها در توزیع و یکپارچه‌سازی اطلاعات، شکنندگی (Fragility) و ناپایداری(Volatility) بالایی دارند و کوچک‌ترین اختلال در آن‌ها می‌تواند به اختلال در سراسر شبکه منجر شود. نویسندگان با استفاده از داده‌های MRI و DTI به ارزیابی کمی بافت اتصالات پرداخته‌اند و با مدل‌سازی ریاضی، رفتار پویای این هاب‌ها را تحت شرایط مختلف – نظیر حذف‌های موضعی یا تضعیف برخی ارتباطات – شبیه‌سازی کرده‌اند. یافته‌ها حاکی از آن است که سیستم عصبی انسان، با همه انعطافش، دارای گلوگاه‌هایی است که اگر در معرض آسیب قرار گیرد، عملکرد کلی مغز دچار اختلال قابل توجهی می‌شود. از سویی دیگر، این فرگشت تکاملی به نظر می‌رسد برای حداکثرسازی کارایی انتقال اطلاعات صورت گرفته باشد؛ چراکه تمرکز اتصالات در هاب‌ها باعث می‌شود سیگنال‌ها بتوانند سریع و کم‌هزینه میان بخش‌های مختلف مغز گردش کنند. مقاله علاوه بر تحلیل دینامیک شبکه‌ای، نتایج بالینی نیز ارائه می‌دهد و نشان می‌دهد که در برخی اختلالات روان‌پزشکی یا نورولوژیک، ممکن است هاب‌های کلیدی مغز دچار فرسایش ساختاری شده یا نحوه اتصال آن‌ها مخدوش گردد و همین امر علائم بیماری را تشدید می‌کند. در مجموع، پژوهش حاضر با ترکیب داده‌های تجربی و مدل‌های شبکه‌ای، بر آسیب‌پذیری ظریف و در عین حال نقش پراهمیت هاب‌های مغزی صحه می‌گذارد و برای درک و مدیریت بسیاری از اختلالات، راهنمای مفیدی محسوب می‌شود. [15]طبقه بندی اتصال عملکردی اوتیسمدر این پژوهش، گروهی از محققان با تکیه بر داده‌هایfMRI حالت استراحت (Resting-State) تلاش کردند تا با استفاده از روش‌های طبقه‌بندی ماشینی، گروهی از افراد مبتلا به اوتیسم را از افراد سالم متمایز کنند و بدین ترتیب، به یک شاخص زیستی (Biomarker) بالقوه برای تشخیص اوتیسم دست یابند. آنان داده‌ها را از دیتاست بزرگ ABIDE گردآوری کردند و گام اصلی پژوهش این بود که با محاسبه اتصال عملکردی در سراسر مغز، شاخص‌هایی پیدا کنند که قابلیت تفکیک دو گروه را با دقت بالا نشان دهد. نتایج اولیه نشان می‌داد که برخی الگوهای اتصال، به‌ویژه در شبکه‌های پیشانی-آهیانه‌ای و نیز ارتباطات میان نواحی دخیل در پردازش اجتماعی، قدرت پیش‌بینی قابل ملاحظه‌ای دارند. با این حال، نویسندگان اشاره می‌کنند که فاصله زیادی تا رسیدن به استانداردهای بالینی برای یک نشانگر زیستی قطعی وجود دارد و علت آن را هم در ناهمگونی بالینی اختلال اوتیسم و هم در محدودیت‌های رویکردهای اتصال عملکردی می‌دانند. آنان به‌ویژه خاطرنشان می‌سازند که به دلیل تنوع زیاد داده‌های fMRI در مراکز مختلف، نتایج طبقه‌بندی ممکن است دچار افت دقت شود و برای رسیدن به حساسیت و ویژگی مطلوب، باید روش‌های پیش‌پردازش و دسته‌بندی را بهینه کرد. همچنین در بخشی از مقاله، بر این نکته تأکید شده که چنین الگوهای اتصال عملکردی هرچند می‌توانند یک عامل کمکی در تشخیص باشند، اما نمی‌توانند به تنهایی معیار تشخیصی قطعی به شمار آیند. نویسندگان در نهایت نتیجه می‌گیرند که پژوهش آینده باید بر ترکیب داده‌های گوناگون (مانند داده‌های ساختاری، رفتاری و ژنتیکی) و روش‌های یادگیری عمیق یا مدل‌های پیشرفته تمرکز کند تا شاید بتوان به یک ابزار دقیق برای تشخیص زودهنگام اوتیسم نزدیک شد. درعین‌حال، این مطالعه اهمیت پرداختن به مبحث «الگوی اتصال» را تقویت کرد و نشان داد هرچند موانعی در راه استانداردسازی وجود دارد، اما طبقه‌بندی بر اساس اتصال مغزی می‌تواند سرنخ‌های ارزشمندی درباره پاتوفیزیولوژی اوتیسم ارائه دهد و درک ما را از تفاوت‌های بنیادین میان مغز سالم و مغز اوتیستیک عمیق‌تر سازد. [16]پیامدهای اتصال مغز در عصب روانشناسی اوتیسماین مقاله مروری به بررسی انواع شواهد تصویربرداری مغزی در اوتیسم می‌پردازد تا نشان دهد چگونه تغییرات خاص در الگوهای اتصال، اعم از ساختاری و عملکردی، می‌تواند تبیین‌کننده مشکلات روان‌شناختی و شناختی در افراد مبتلا به اوتیسم باشد. نویسندگان ابتدا مرور جامعی بر یافته‌های fMRI انجام می‌دهند که حکایت از کاهش هم‌بستگی میان نواحی دور از هم در قشر مغز و در عین حال، افزایش اتصال موضعی میان نواحی نزدیک به هم دارد. آن‌ها توضیح می‌دهند که این الگوی نامتقارن در سازمان‌دهی شبکه‌های مغز، اغلب با ضعف در همپارچگی (Integration) اطلاعات در سطح جهانی و تمایل به پردازش موضعی مرتبط است. با استناد به مطالعات DTI، بحث می‌شود که رشته‌های عصبی بلندمدت (Long-range fibers) ممکن است به‌خوبی در افراد اوتیستیک شکل نگرفته یا در طول رشد تکاملی دچار اختلال شده باشند و این امر باعث می‌شود نواحی مسئول عملکردهای اجتماعی، زبانی و اجرایی نتوانند هماهنگی مؤثری داشته باشند. مقاله به‌طور ضمنی از نظریه «اتصال‌پذیری مختل‌شده» پشتیبانی می‌کند و آن را به عنوان چارچوبی می‌شناساند که می‌تواند نقص‌های بالینی گوناگون، از مشکلات ارتباطی گرفته تا رفتارهای تکراری را توضیح دهد. همچنین استدلال می‌کند که برای درک بهتر این اختلال، باید به پویایی شبکه‌ای (Dynamic Connectivity) توجه شود و به جای مطالعه اتصال در یک بازه زمانی ثابت، تغییرات آن را حین انجام تکالیف شناختی مختلف رصد کرد. نویسندگان در نهایت به کاربرد بالینی نیز اشاره می‌کنند و یادآور می‌شوند که مداخلات توانبخشی، شاید با هدف تقویت ارتباطات طولانی‌مدت و افزایش هماهنگی میان‌مادولار در مغز، بتوانند تا حدی برخی نشانه‌های اختلال را کاهش دهند. در مجموع، مقاله تأکید دارد که نگاه شبکه‌ای نه تنها در بعد تشخیص، بلکه در تبیین مکانیسم‌های مرکزی اوتیسم نیز نقشی کلیدی ایفا می‌کند و راهگشای تحقیقات آتی در حوزه نوروسایکولوژی خواهد بود. [17]شناسایی اختلال طیف اوتیسم با استفاده از یادگیری عمیق و مجموعه داده ABIDEدر این پژوهش، محققان به سراغ یکی از رویکردهای نوین و قدرتمند در علوم داده، یعنی یادگیری عمیق (Deep Learning)، رفتند تا از طریق آن بتوانند داده‌های fMRI حالت استراحت را که از دیتاست ABIDE استخراج شده بود، به‌طور دقیق‌تری مورد تحلیل قرار دهند و الگوهای ویژه‌ای را در افراد مبتلا به اوتیسم شناسایی کنند. آنان ابتدا ماتریس‌های اتصال عملکردی هر فرد را تهیه کردند و سپس با طراحی یک معماری شبکه عصبی عمیق خاص، این ماتریس‌ها را به‌عنوان ورودی مدل در نظر گرفتند. نتیجه کار نشان داد که برخلاف روش‌های سنتی طبقه‌بندی (نظیر SVM یا رگرسیون لجستیک)، معماری عمیق قادر است الگوهای پیچیده‌تری از همبستگی‌ها و تعاملات میان مناطق مغزی را بیاموزد و تشخیص بهتری نسبت به مدل‌های قبلی ارائه دهد. هرچند مقاله گزارش می‌کند که هنوز دقت به حدی نرسیده که بتواند با قطعیت بالینی مورد استفاده قرار بگیرد، اما جهش قابل توجهی در کارایی طبقه‌بندی ایجاد شده است. نکته جالب آن است که برخی الگوهای مهم شناسایی‌شده توسط شبکه، به بخش‌هایی از مغز مرتبط با رفتارهای اجتماعی و تئوری ذهن مربوط می‌شود و این امر با شواهد بالینی درباره نقص در تعاملات اجتماعی در اوتیسم همخوانی دارد. نویسندگان همچنین چالش‌های موجود در راه عملی‌سازی این مدل‌ها را مورد بحث قرار می‌دهند؛ برای مثال، کمبود داده‌های پرحجم و همچنین نویز بالا در fMRI ممکن است دقت نهایی را محدود کند. با این حال، این مقاله از پیشگامان به‌کارگیری یادگیری عمیق در حوزه تحلیل شبکه‌های مغزی اوتیسم محسوب می‌شود و دریچه تازه‌ای را برای تلفیق علوم اعصاب، داده‌کاوی و رایانش پیشرفته گشوده است. از دید آن‌ها، تکمیل این مسیر نیازمند نمونه‌های بزرگ‌تر، روش‌های منسجم پیش‌پردازش و شاید تحلیل چندوجهی (Multimodal) است تا مدل بتواند به بیان دقیق‌تری از ریشه‌های عصبی اوتیسم دست پیدا کند. [18]تغییر اتصال مغز به سمت تصادفی بودن در اوتیسمنقطه تمرکز اصلی این پژوهش بر این پرسش استوار است که آیا شبکه‌های مغزی افراد مبتلا به اوتیسم، از حیث ساختار گرافی، به سمت الگوهای تصادفی‌تر و کم‌نظم‌تر متمایل می‌شوند یا خیر. نویسندگان معتقد بودند که تصادفی شدن نسبی شبکه می‌تواند شکل خاصی از سازگاری مغز را نشان دهد که برخی وظایف اطلاعاتی را در این اختلال دچار تغییر می‌کند. برای بررسی این ایده، آن‌ها داده‌های fMRI حالت استراحت را پردازش کرده و سنجه‌هایی مانند ضریب خوشه‌بندی (Clustering Coefficient) و طول مسیر میانگین(Characteristic Path Length) را در کنار سایر معیارهای گرافی محاسبه کردند. نتایج نشان داد که در برخی نواحی مغز (به‌ویژه نواحی درگیر در ادراک اجتماعی و ارتباطات زبانی)، ساختار شبکه‌ای در اوتیسم از الگویی منظم و ماژولار فاصله می‌گیرد و مقداری ویژگی‌های تصادفی‌تر به خود می‌گیرد. این امر الزاماً به معنای اختلال کامل نیست و حتی گاهی می‌تواند به همپارچگی اطلاعات در سطح بالاتری نیز کمک کند؛ چراکه شبکه‌های نزدیک به تصادفی، اتصالات میان بخش‌های مختلف را تسهیل می‌کنند و اگرچه نظم ماژولار کمتری دارند، سرعت تبادل اطلاعات را افزایش می‌دهند. مقاله همچنین بیان می‌کند که این سازوکار ممکن است بخشی از پاسخ تکاملی باشد که مغز اوتیستیک برای پردازش خاص داده‌ها ارائه می‌دهد. با این حال، نکته مهم در تفسیر چنین یافته‌هایی این است که جنبه تصادفی یا منظم بودن شبکه لزوماً به عوامل متعددی همچون مرحله رشد فرد، شدت اختلال و تنوع فنوتیپی در اوتیسم بستگی دارد و نباید نتیجه‌گیری کرد که این الگو برای همه افراد مبتلا یکسان است. در مجموع، این مطالعه رویکرد جدیدی را در تبیین چگونگی سازمان‌دهی شبکه مغزی در اوتیسم مطرح می‌کند و بر اهمیت فهم «موقعیت مغز بین نظم و آشوب» در اختلالات عصبی-رشدی تأکید دارد. [19]طبقه بندی اختلالات طیف اوتیسم با استفاده از ترکیبی از معیارهای ارتباط آناتومیکی و عملکردیدر این مقاله، محققان برای بهبود توان تفکیک میان افراد اوتیستیک و سالم، داده‌های اتصال ساختاری (DTI) و داده‌های اتصال عملکردی (fMRI) را با هم تلفیق کردند. ایده اصلی این بود که اتصال ساختاری زمینه زیربنایی شبکه‌های عصبی را مشخص می‌کند و اتصال عملکردی، نمود پویایی موقتی این ارتباطات است و بررسی همزمان هر دو نوع اتصال می‌تواند اطلاعات فراگیری درباره سازمان‌دهی شبکه مغزی ارائه دهد. در فرایند کار، ابتدا ماتریس‌های اتصال برای هر فرد و به شکل جداگانه (ساختاری و عملکردی) استخراج شد. سپس، ویژگی‌های گرافی نظیر مرکزیت، کارآیی شبکه، ضریب خوشه‌بندی و ماژولاریته از هر ماتریس به دست آمد. پس از آن، نویسندگان از روش‌های ماشین‌لرنینگ (مانند SVM و الگوریتم‌های مبتنی بر درخت تصمیم) استفاده کردند تا الگوهای بهینه برای تفکیک گروه‌ها را شناسایی کنند. نتایج نشان داد که ترکیب سنجه‌های ساختاری و عملکردی، به‌طور معناداری دقت تشخیص را بالا برد و در برخی آزمایش‌ها توانست به حساسیت و ویژگی بالاتری نسبت به استفاده از یک نوع داده دست یابد. نکته مهم مقاله این بود که برخی مناطق مغزی که در مدل‌های صرفاً ساختاری مهم به نظر می‌رسیدند، با افزودن داده‌های عملکردی اهمیت کمتری پیدا کردند و بالعکس؛ این امر نشان می‌دهد که ارزیابی چندوجهی ممکن است اولویت نواحی هدف را دستخوش تغییر کند. دستاورد کلیدی این پژوهش را می‌توان تأکید بر ضرورت بهره‌گیری از روش‌های جامع در تحلیل اوتیسم دانست؛ چرا که اوتیسم یک اختلال چندبعدی است و تمرکز بر یک شاخص مغزی، اغلب تصویری محدود از تغییرات شبکه‌ای ارائه می‌کند. [20]connectome در اوتیسم با استفاده از تبادل داده های تصویربرداری مغز اوتیسماین مقاله به معرفی نسخه دوم پروژه ABIDE می‌پردازد که با نامABIDE-II شناخته می‌شود و در واقع، تلاشی برای گسترش و استانداردسازی هرچه بیشتر داده‌های تصویربرداری مغزی اوتیسم محسوب می‌گردد. نویسندگان با گردآوری داده‌های fMRI، آناتومیک و اطلاعات بالینی گسترده از مراکز متعدد پژوهشی، کوشیده‌اند محدودیت‌های پیشین در زمینه حجم نمونه و تنوع جمعیت را کاهش دهند و مجموعه‌ای غنی‌تر از داده‌ها را در اختیار جامعه علمی قرار دهند. مقاله توضیح می‌دهد که چرا ناهمگونی شدید در روش‌های تصویربرداری و اختلاف در پروتکل‌های پیش‌پردازش ممکن است به نتایج ضدونقیض در مطالعات اوتیسم بینجامد و چگونه ABIDE-II با تعبیه دستورالعمل‌های دقیق‌تر و کنترل کیفی بهتر تلاش دارد این ناهمخوانی‌ها را کم کند. همچنین به این نکته می‌پردازد که پژوهش‌های مبتنی بر تحلیل شبکه‌ای، به‌ویژه در حوزه اوتیسم، نیازمند نمونه‌های بسیار بزرگ و متنوع هستند تا الگوهای مشترک و درعین‌حال زیرگروه‌های متمایز را آشکار سازند. از جنبه عملی، مقاله نشان می‌دهد که چگونه پژوهشگران می‌توانند با استفاده از ابزارهای پیش‌پردازشی استانداردشده و پلتفرم‌های تحلیل مشترک، داده‌های این دیتاست را تحلیل کنند و به روش‌های نوین (مانند یادگیری عمیق یا مدل‌های چندلایه شبکه‌ای) روی آورند. این تلاش جمعی می‌تواند نه‌تنها به شناخت بهتر اصول پایه‌ای اتصال مغزی در اوتیسم کمک کند، بلکه در نهایت مسیر را برای ارائه شاخص‌های زیستی معتبر هموارتر نماید. در مجموع، مقاله پیام روشنی دارد که ادامه مطالعات شبکه‌ای در اوتیسم، نیازمند همکاری علمی گسترده و پایگاه‌های داده با کیفیت بالا است تا از دل داده‌های حجیم و ناهمگن، الگوهای قابل اعتماد شناسایی شوند. [21]وضعیت های ارتباطی پویا در اسکیزوفرنی و ارتباط با علائم بالینیمحور اصلی در این مقاله، تحلیل پویایی اتصال عملکردی در طول زمان است؛ هرچند هدف مطالعه به‌طور مشخص به اختلال اسکیزوفرنی اشاره دارد، اما روش‌شناسی مورد استفاده برای مطالعات اوتیسم نیز کاربرد فراوان دارد. نویسندگان از روش‌های مبتنی بر Sliding Window و خوشه‌بندی استفاده می‌کنند تا وضعیت‌های مختلف اتصال عملکردی (Connectivity States) در مغز افراد اسکیزوفرن را شناسایی کنند و سپس این وضعیت‌ها را با علائم بالینی مقایسه نمایند. نتایج نشان داد که بیماران نسبت به افراد سالم، زمان بیشتری را در برخی حالت‌های ناسازگار (درگیر با فعالیت‌های پایه‌ای و هماهنگی ضعیف فرانتو-پاریتال) سپری می‌کنند. نکته مهم اینجاست که این شیوه دینامیک‌محور، با نگاه سنتی که میانگین اتصال را در کل مدت اسکن اندازه‌گیری می‌کند، تفاوت اساسی دارد و الگوهای گذرای مغز را نیز آشکار می‌سازد. از منظر پژوهش در اوتیسم، می‌توان استنتاج کرد که احتمالا مغز اوتیستیک نیز الگوهای گذرای متمایزی دارد که در تحلیل‌های استاتیک (میانگین اتصال) پنهان باقی می‌ماند. مقاله نشان می‌دهد که ارتباط قابل توجهی میان مدت‌زمان حضور در یک الگوی اتصال خاص و شدت علائم بالینی وجود دارد و این امر ممکن است برای اوتیسم نیز صادق باشد؛ یعنی ممکن است کودکان و بزرگسالان اوتیستیک در الگوهای معینی از اتصال فروروند و انعطاف اندکی در تغییر الگو داشته باشند. در مجموع، با اینکه پژوهش حاضر روی اسکیزوفرنی متمرکز است، اما الگویی ارائه می‌دهد که می‌تواند برای درک ماهیت پویا و پیچیده شبکه‌های مغزی در طیف اوتیسم نیز بسیار مفید باشد و راهگشای روش‌های تحلیلی جدید در این حیطه باشد. [22]تاثیر پویایی شبکه های مغزی تطبیقی ​​در نقش های عملکردی مناطق تحت بار شناختی در افراد مبتلا به اوتیسممحققان در این پژوهش، نه‌تنها به ثبت داده‌هایfMRI حالت استراحت بسنده نکردند، بلکه افراد را در موقعیت‌هایی با بار شناختی (Cognitive Load) متفاوت قرار دادند تا دریابند مغز هنگام درگیری با وظایف پیچیده چه الگوی پویایی از اتصال را نشان می‌دهد. آنان بر این باور بودند که افراد مبتلا به اوتیسم ممکن است در بازآرایی سریع شبکه (Reconfiguration) دچار مشکلاتی باشند و این امر می‌تواند توضیحی برای دشواری در مواجهه با تکالیف چندوجهی یا نیازمند انعطاف ذهنی باشد. نتایج تحلیل دینامیک نشان داد که در گروه کنترل (افراد سالم)، شبکه‌های کلیدی اجرایی و توجهی در مواجهه با افزایش بار شناختی فعال‌تر شده و ارتباطی منسجم‌تر برقرار می‌کردند؛ در حالی که در افراد اوتیستیک، چنین جهش منسجمی مشاهده نشد و برخی نواحی مهم از جمله قشر پیش‌پیشانی خلفی‌جانبی، به‌گونه‌ای متفاوت در شبکه ادغام می‌شدند. مقاله تأکید دارد که کاهش تطبیق‌پذیری شبکه‌ای در اوتیسم ممکن است منجر به صرف انرژی بیشتری شود و یا کارایی شناختی را کاهش دهد. همچنین از منظر «انتشار اطلاعات»، چنین تغییری نشان می‌دهد که مسیرهای حیاتی ارتباط بین نواحی مغز به‌درستی به‌کار گرفته نمی‌شوند و در نتیجه، اطلاعات پیچیده نمی‌تواند به‌راحتی به مناطق هدف برسد. این یافته‌ها از دید بالینی معنادار هستند و نویسندگان پیشنهاد می‌کنند که مداخلات آموزشی یا توانبخشی شناختی، اگر بر بهبود انعطاف شبکه‌ای تمرکز کنند، ممکن است منجر به ارتقای عملکرد در حیطه‌های تحصیلی و اجتماعی شود. مقاله همچنین بر آن است که شاخص‌های دینامیک شبکه‌ای، فراتر از سنجه‌های میانگین اتصال، می‌توانند بینش عمیق‌تری از سازوکارهای مغزی اوتیسم ارائه دهند و به‌عنوان ابزارهای پژوهشی و بالینی نوین به کار گرفته شوند. [23]اختلال در الگوهای فضایی و زمانی فعالیت مغز در اوتیسمدر این مطالعه، تحلیل به شکل ترکیبی از الگوهای مکانی و زمانی(Spatiotemporal Analysis) صورت گرفت تا دگرگونی‌های پیچیده در نحوه فعال‌شدن نواحی مغزی در افراد اوتیستیک شناسایی شود. پژوهشگران از داده‌های fMRI چندسایتی بهره بردند و با روش‌هایی نظیر ICA (Independent Component Analysis) و خوشه‌بندی زمانی، الگوهای فعالی را استخراج و مقایسه کردند. یافته کلیدی نشان داد که در اوتیسم، برخی شبکه‌های اجتماعی و شناخت اجتماعی، در زمان‌بندی فعالیت با سایر بخش‌های مغز همگام نیستند و این عدم هماهنگی (Desynchronization) موجب می‌شود توالی پردازش اطلاعات مختل شود. به بیان دیگر، ممکن است بخشی از مغز زودتر سیگنالی را پردازش کند، در حالی که بخش دیگر هنوز به آن سطح آماده‌باش نرسیده و این ناهماهنگی زمانی می‌تواند رفتارهای ارتباطی و شناختی را تحت تأثیر قرار دهد. مقاله همچنین به تفاوت‌های مکانی در شدت فعالیت اشاره دارد و بیان می‌کند که نواحی درگیر در بازنمایی هیجانات یا تفسیر نشانه‌های اجتماعی، در افراد اوتیستیک فعالیت کمتری نشان می‌دهند یا در شبکه گسترده‌تری پراکنده می‌شوند. در مجموع، این الگوهای مختل‌شده فضازمانی، دید جدیدی به مکانیسم‌های نهفته در پشت ناتوانی‌های اجتماعی و ارتباطی اوتیسم عرضه می‌کند. نویسندگان بر ضرورت توجه به عوامل زمانی و چرخه‌های فعال‌سازی موازی در مغز تأکید می‌کنند، چراکه مطالعات محدود به «میانگین اتصال» قادر به تشخیص این الگوهای پیچیده نخواهند بود. مقاله از منظر بالینی نیز پیشنهاد می‌کند که در آینده، فناوری‌هایی مانند تحریک الکتریکی یا مغناطیسی با هدف اصلاح یا همگام‌سازی الگوهای زمانی می‌توانند یکی از مسیرهای جدید مداخله‌ای باشند. [24]نشانگرهای زیستی مبتنی بر شبکه و ناهمگنی در اختلالات طیف اوتیسممقاله حاضر با تمرکز بر ناهمگونی شدید در طیف اوتیسم، سعی دارد نشان دهد که چرا یافتن یک نشانگر زیستی واحد برای همه افراد مبتلا دشوار است و چگونه تحلیل شبکه‌ای می‌تواند در شناخت زیرگروه‌های متمایز یا فنوتیپ‌های مختلف در این اختلال راهگشا باشد. نویسندگان، داده‌های fMRI چندین گروه از بیماران را بررسی کرده و سنجه‌هایی نظیر مرکزیت بردار ویژه (Eigenvector Centrality)، ماژولاریته و قابلیت کنترل (Controllability) در شبکه‌های ساختاری و عملکردی را محاسبه کردند. بر اساس این نتایج، به جای یک الگوی واحد، مجموعه‌ای از «سَبک‌های شبکه‌ای» شناسایی شد که هر کدام با ابعاد متفاوتی از کارکردهای شناختی، اجتماعی و رفتاری همبستگی داشتند. درواقع، برخی زیرگروه‌های اوتیسم دارای کاهش شدید اتصال طولانی‌مدت بودند و برخی دیگر الگوهای ترکیبی با حفظ بخشی از ساختار ماژولار نشان می‌دادند. این تمایز به پژوهشگران اجازه می‌دهد تا مداخلات درمانی را متناسب با الگوی شبکه‌ای هر زیرگروه طراحی کنند و بدین ترتیب شاید اثربخشی روش‌ها افزایش یابد. همچنین مقاله استدلال می‌کند که زیرگروه‌بندی براساس شاخص‌های شبکه‌ای می‌تواند به ما در پیش‌بینی بهتر مسیر رشد و پیامدهای بلندمدت کودکان اوتیستیک کمک کند. نکته مهم آن است که داده‌های بالینی و ژنتیکی نیز باید در کنار داده‌های شبکه‌ای تفسیر شوند، چراکه تنوع در ابعاد مختلف (از جهش‌های ژنتیکی تا ویژگی‌های شخصیتی) ممکن است بخشی از این ناهمگونی را شکل دهد. نتیجه‌گیری کلی پژوهش بر این محور قرار دارد که رویکردهای گرافی و شبکه‌ای، برخلاف روش‌های سنتی که به دنبال شاخص واحد تشخیصی هستند، می‌توانند به شکل‌گیری طبقه‌بندی‌های دقیق‌تر بینجامند و گامی مهم در راستای پزشکی شخصی‌سازی‌شده (Personalized Medicine) برای اوتیسم محسوب شوند. [25]اندازهگيری جریان‌های اطالعاتي در بازارهای مالي با استفاده از روش Transfer Entropyاین مقاله ، یک روشي جدید برای سنجش و تحليل جریانهای اطالعاتي در دورههای زماني مالي معرفي ميکند و برخالف روشهای قدیمي که بيشتر به Linear Dynamics فرایندهایي که رفتار سيستم به صورت خطي در آنها تغيير ميکند و تغييرات ورودی با تغييرات خروجي ، رابطه خطي و مستقيم دارد) محدود ميشدند ، بر مفاهيم غيرخطي تکيه دارد . در این مطالعه ، نویسندگان به دنبال تحليل جریانهای اطالعاتي در بازارهای مختلف از جمله بازارهای CDS و اوراق قرضه شرکتي بودند و همچنين ارتباط ميان شاخصهای ریسک بازار و ریسک اعتباری را بررسي کردند .در این مقاله ، دو موضوع مهم مورد بررسي قرار گرفته شده است. در اولين مورد ، به تحليل جریانهای اطالعاتي بين بازارهای CDSو اوراق قرضه شرکتي پرداخته شده است . دادههایي که از آنها استفاده شده است ، شامل اطلاعات مربوط به شرکتهای بزرگ اروپایي است که به صورت روزانه جمع آوری شده اند . تحليل‌های بدست آمده نشان ميدهند که جریان اطالعات بين این دو بازار ، دوطرفه است؛ اما در شرایط بحراني ، بازار CDSبه دليل خاصيت جذب اطالعات بالاتری که دارد، بيشتر در انتقال اطلاعات نقش دارد. این نتيجه حاکي از آن است که دردوران بحران ، اطالعات در بازار CDSسریعتر از بازار اوراق قرضه شرکتي منتشر ميشود و این بازار به نوعي ، درفرآیند قيمت گذاری ریسک اعتباری پيشرو است.در دومين مورد ، ارتباط ميان شاخص ریسک بازار VIXو شاخص ریسک اعتباری ( )iTraxx مورد بررسي قرارگرفته است. جریان اطلاعات بين این دو شاخص، قبل از بحران مالي، تا حدودی متقارن بود، اما با آغاز بحران، اطلاعات بيشتری از VIX به سمت iTraxxجریان پيدا کرد که بيانگر این است که در شرایط ناپایدار اقتصادی، ریسکهای بازار تأثير زیادی بر ریسک های اعتباری دارند و این رابطه در دوران بحران تقویت ميشود.این مقاله نمونهایی از روشهای تحليل جریانهای اطالعاتي در شبکه های پيچيده ارائه کرد که باعث ایجاد دید خوبي برای اجرای تحليلهای مشابه بر روی شبکه مغز میشود. در پروژه ما که به مطالعه فرآیندهای اطلاعاتي در مغز و مقایسه رفتار مغز سالم با مغز مبتلا به اوتيسم اختصاص دارد، ما ميتوانيم از این روش برای شناسایي الگوهای متفاوت انتقال اطلاعات استفاده کنيم. همانطور که در مقاله مورد بررسي دیدیم، وجود جریانهای اطلاعاتي غيرمتقارن در شرایط بحراني ميتواند بيانگر تفاوتهای مهم در رفتار شبکه باشد . در شبکه مغزی نيز، ميتوان فرض کرد که شرایطي مانند یادگيری یا تصميم گيری ممکن است باعث بروز جریانهای اطلاعاتي غيرمتقارن ميان نواحي مختلف مغز شود. به همين دليل، استفاده از Transfer Entropyبه ما این امکان را ميدهد که به درک بهتری از نحوه انتشار اطلاعات در شرایط مختلف برسيم[26].Shannon Entropy و Rényi Entropyبرای بررسي و تحليل جریان اطلاعات بين ارزهای دیجيتالاین مفاهيم ميتوانند به ما کمک کنند تا فرآیندهای اطلاعاتي مشابهي را در شبکه های بيولوژیکي، مانند مغز انسان ، مدلسازی کنيم و درک عميق تری از انتقال اطلاعات بين نواحي مختلف مغز به دست بياوریم .یکي از مهمترین بخشهای مقاله، روش استفاده از Transfer Entropyبرای بررسي وابستگي های پيچيده و غيرخطي بين اجزای یک سيستم است. در سيستم مغزی، ارتباطات بين نواحي مختلف مغز اغلب پيچيده و غيرخطي هستند و نميتوان آنها را به سادگي با مدل های خطي تحليل کرد. اینجا جایي است که آنتروپي رني وارد ميشود و به ما امکان ميدهد وابستگي های غيرخطي را که در انتقال اطلاعات بين نواحي مغزی وجود دارد، به طور مؤثرتری بررسي کنيم. از این روش میتوان برای تحليل نحوه انتشار اطلاعات در شرایط مختلف مانند تصميم گيری ، یادگيری یا حتي اختالالت عصبي مانند اوتيسم استفاده کرد.این مقاله همچنين به طور خاص نشان ميدهد که در شبکه های پيچيده، وقایع نادر ميتوانند اطلاعات بسيارمهمي درباره ساختار و عملکرد سيستم ارائه دهند. همچنين ، مقاله به بررسي تغييرات جریانهای اطلاعاتي قبل و بعد از یک بحران، مانند سقوط بازار ارزهای دیجيتال در سال۲۰۱۷ پرداخته است. یکي دیگر از موضوعات مهمي که مقاله به آن پرداخته است، استفاده از Shufflingبرای اطمينان از صحت و دقت نتایج است. در تحليلهای مربوط به مغز، احتمال بروز خطا وجود دارد و ممکن است نمونه انتخابي ما کوچک بوده و نتایج آن دقيق نباشد. در این مواقع، استفاده از تکنيک شافلينگ ميتواند به ما کمک کند تا این اثرات را کاهش دهيم و به نتایج دقيقتری برسيم. به عنوان مثال، در روش انتخابي با استفاده از دادههایFMRI ميتوانيم از این تکنيک برای بررسي صحت تحليلهای جریان اطالعات استفاده کنيم و مطمئن شویم که وابستگيهای مشاهده شده واقعي هستند و تصادفي نيستند.کارهایی که ما انجام دادیمدر این بخش، به‌منظور بررسی ساختار شبکه‌های مغزی و مقایسهٔ آن‌ها در افراد سالم و مبتلایان به اوتیسم، از رویکرد ترنسفر انتروپی (Transfer Entropy) استفاده کردیم. یکی از دلایلی که ما را به سمت استفاده از ترنسفر انتروپی هدایت کرد، این بود که با اعمال نظریهٔ هایدر (Heider’s Theory)، شبکه‌ها بیش از حد متراکم (Full Connected) می‌شدند و در نهایت اطلاعات ارزشمند کمتری در خصوص ارتباطات مؤثر بین نواحی مختلف مغزی به دست می‌آمد. در مقابل، ترنسفر انتروپی به ما این امکان را می‌دهد تا با حذف پیوندهای کم‌اهمیت‌تر، شبکه‌های اسپارس‌تر و معنادارتری بسازیم.برای این منظور، از داده‌های پایگاه ABIDE بهره گرفتیم که شامل دو گروه از آزمودنی‌ها بود: نزدیک به ۵۰۰ فرد سالم (Healthy Control) و حدود ۵۰۰ فرد مبتلا به اختلال طیف اوتیسم (ASD). با تشکیل ماتریس ترنسفر انتروپی برای هر مغز، دو نوع شبکه ایجاد شد:شبکهٔ عملکردی:‌ انتقال اطلاعات درون هر ناحیه ی عملکردی (مانند Default Mode, Ventral Attention, Somatomotor و غیره).شبکهٔ بین ناحیه ای: انتقال اطلاعات میان نواحی مختلف مغزی.سپس جهت بصری‌سازی و ساده‌سازی شبکه‌ها، ما آستانه‌ای بر اساس چارک سوم (Third Quartile) در نظر گرفتیم تا پیوندهایی را که قدرت یا وزن آن‌ها کمتر از این مقدار بود حذف کنیم. این کار اگرچه روش کاملاً ایدئال یا نهایی برای اسپارس کردن شبکه‌ها محسوب نمی‌شود، اما در مراحل مقدماتی، برای درک تفاوت‌های کلی بین ارتباطات مؤثر در مغز سالم و مغز مبتلا به اوتیسم، روشی مناسب به نظر می‌رسد. بدیهی است که در ادامه، آزمون‌های آماری دقیق جهت اعتبارسنجی این نتایج به کار گرفته خواهد شد.در شکل اول (تصویر چپ و راست)، توپولوژی شبکه‌های مغزی مبتنی بر ترنسفر انتروپی در دو گروه اوتیسم (ASD) و سالم (HC) نشان داده شده است. موقعیت گره‌ها (Nodes) ثابت است، اما اندازه و رنگ آن‌ها بسته به میزان میانگین ورودی یا خروجی متفاوت است:گره‌هایی که میانگین ورودی بالا (از سایر گره‌ها به آن‌ها) داشته باشند، بزرگ‌تر و با رنگ گرم‌تر (قرمزتر) به نمایش درآمده‌اند.گره‌هایی که خروجی آن‌ها به گره‌های دیگر بیشتر باشد، کوچکتر دیده می‌شوند (بر اساس مقیاسی که برای نمایش خروجی تعریف کردیم).با مشاهدهٔ این دو تصویر، تفاوت چشمگیری در نوع و شدت پیوندهای بین ناحیه های مختلف مغزی در گروه سالم و اوتیسم مشاهده می‌شود. برای نمونه، در مغز مبتلا به اوتیسم، گره مربوط به Default Mode (ناحیهٔ دیفالت‌مود) ورودی‌های نسبتاً زیادی دارد و با رنگ قرمز قابل توجهی ظاهر شده است؛ در حالی که در مغز سالم، دیفالت‌مود یک گرهٔ معمولی‌تر محسوب می‌شود و این بار Ventral Attention بیشترین ورودی را به خود اختصاص داده است. همچنین ناحیه Visual در مغز سالم پیوندهای متعددی به اطراف خود ارسال و دریافت می‌کند، اما در نمونهٔ اوتیسم، به‌نظر می‌رسد تراکم پیوندهای ورودی و خروجی در بخش دیداری کمتر و محدودتر است. این الگوهای گوناگون نشان می‌دهد که جریان اطلاعات در مغز سالم در مقایسه با مغز مبتلا به اوتیسم به شکل متمایزی سازمان یافته است و احتمالاً در کارکردهای شناختی و توجهی تأثیرگذار خواهد بود.در پایان باید یادآور شد که این مرحلهٔ اولیه از تحلیل توپولوژی شبکه‌های مغزی است و ما برای دستیابی به نتیجه‌گیری قطعی، برنامه داریم از روش‌های آماری پیشرفته (مانند Paired T Tests ) و همچنین متریک‌های پیچیدگی شبکه‌ای (مانند Clustering Coefficient، Modularity، و غیره) بهره بگیریم تا تفاوت‌های بین گروه‌ها با اعتبار بیشتری مشخص شود.در بخش بعدی، به تحلیل آمار لوپ‌ها (Loops) در همین شبکه‌های استخراج‌شده از طریق ترنسفر انتروپی می‌پردازیم. هدف اصلی، شناسایی الگوهای چرخشی یا حلقه‌های تکرارشونده در شبکه است که می‌توانند نشانه‌ای از سازوکارهای برگشتی (Recurrent Mechanisms) یا حلقه‌های بازخوردی در مغز باشند.برای محاسبهٔ این لوپ‌ها، از عملیات ضرب ماتریس ترنسفر انتروپی در خودش استفاده کردیم. به‌طور خلاصه، مراحل زیر را دنبال کردیم:در ابتدا، ماتریس ترنسفر انتروپی را (که نشان‌دهندهٔ وزن‌های اتصال بین گره‌ها است) یک بار در خودش ضرب کردیم تا حلقه‌هایی با طول ۲ لینک شناسایی شوند.سپس برای یافتن لوپ‌های سه‌تایی، ماتریس به‌دست‌آمده را نرمال‌سازی کردیم و هر بار قطر اصلی آن را صفر قرار دادیم (تا تأثیر حلقه‌های خود-بازگشت حذف شود). آنگاه محصول جدید را مجدداً در ماتریس اولیه ضرب کردیم. حاصل کار، مقداری را به ما می‌داد که می‌توانست وجود یا عدم وجود (و همچنین شدت) لوپ‌های سه‌تایی را نشان دهد.این روند بسته به اینکه چند بار ضرب در ماتریس اعمال شود، لوپ‌های طولانی‌تری نیز می‌تواند آشکار کند (مثلاً لوپ‌های طول ۴، ۵، و ...).در شکل دوم، نتایج مربوط به آمار لوپ‌ها در مغز سالم (HC) مشاهده می‌شود. در محور افقی، نرخ یا رتبهٔ لوپ‌ها (به‌صورت ۳تایی، ۴تایی و غیره) نشان داده شده و در محور عمودی، مقدار یا وزن متناظر آن لوپ‌ها آمده است. روندی که در شکل ملاحظه می‌کنید، نشان می‌دهد که برای لوپ‌های کوتاه‌تر (مانند ۳تایی یا ۴تایی) مقدار وزن بالاتری گزارش می‌شود و با افزایش طول حلقه (مثلاً از ۱۰تایی به بعد)، میزان این وزن کاهش می‌یابد. این امر می‌تواند به این تفسیر بینجامد که مغز بیشتر تمایل دارد در قالب حلقه‌های بازخوردی کوتاه‌تر سازماندهی شود و حلقه‌های طولانی‌تر به لحاظ آماری کمیاب‌ترند.البته باید در نظر داشت که این مشاهدات مقدماتی است و نرمال‌سازی پی‌درپی ماتریس‌ها می‌تواند اثرگذاری خاصی در بزرگ یا کوچک شدن مقدار لوپ‌ها داشته باشد. در پژوهش‌های آتی، علاوه بر اعمال روش‌های دقیق‌تری برای شناسایی این حلقه‌ها، قصد داریم مقایسهٔ دقیقی بین گروه سالم و گروه مبتلا به اوتیسم از منظر لوپ‌های بازخوردی انجام دهیم تا ببینیم آیا ممکن است مغز مبتلا به اوتیسم در حلقه‌های خاصی رفتار بیش‌فعالی یا کم‌فعالی داشته باشد یا خیر.به‌طور کلی، بررسی لوپ‌ها، دید عمیق‌تری نسبت به دینامیک سیستم‌های پیچیدهٔ مغز ارائه می‌دهد و می‌تواند در تبیین تفاوت‌های شناختی و رفتاری بین مغز سالم و مغز مبتلا به اوتیسم نقشی کلیدی ایفا کند. روش ارائه‌شده، در کنار سایر معیارهای شبکه‌ای، تصویری چندبعدی از ساختار و جریان اطلاعات در مغز در اختیار ما می‌گذارد و زمینه را برای مطالعات بالینی و عصب‌شناختی عمیق‌تر فراهم می‌نماید.در این مرحله از پژوهش، برای بررسی تفاوت‌های احتمالی میان حلقه‌های بازخوردی (Loops) با طول‌های زوج (Even Rate) و طول‌های فرد (Odd Rate)، شبکهٔ مغزی گروه سالم (HC) را به دو دستهٔ حلقه‌های زوج و حلقه‌های فرد تفکیک کردیم. سپس وزن (یا مقدار) این لوپ‌ها را در ریت‌های مختلف (۳تایی، ۴تایی، ۵تایی، …) اندازه‌گیری نمودیم. مشاهدات اولیه حاکی از آن بود که حلقه‌های فرد معمولاً وزن کمتری نسبت به حلقه‌های زوج دارند؛ به‌عبارت دیگر، در بیشتر طول‌ها، منحنی مربوط به حلقه‌های فرد زیر منحنی مربوط به حلقه‌های زوج قرار گرفت. بااین‌حال، هر دو نمودار در نرخ‌های بالاتر به‌تدریج افت می‌کنند و در نهایت به مقادیری نزدیک به صفر می‌رسند. این روند نزولی بیانگر آن است که تشکیل و حفظ حلقه‌های بلندمدت در شبکه‌های مغزی بسیار دشوارتر بوده و مغز بیشترین تمایل را به بهره‌گیری از حلقه‌های کوتاه‌تر دارد.همین روش تفکیک حلقه‌های زوج و فرد را برای مغز مبتلایان به اوتیسم (ASD) نیز پیاده‌سازی نمودیم. الگوی به‌دست‌آمده، شباهت قابل توجهی به گروه سالم نشان داد؛ یعنی در گروه اوتیسم هم حلقه‌های زوج در اکثر طول‌ها وزن بیشتری از حلقه‌های فرد داشتند و با بزرگ‌تر شدن طول حلقه، هر دو نمودار (زوج و فرد) شیبی نزولی به سمت مقادیر پایین از خود نشان می‌دهند. این هم‌گرایی در رفتار نزولی حلقه‌های بلندمدت بیان می‌کند که ساختار مغزی، چه در افراد سالم و چه در افراد مبتلا به اوتیسم، تمایل چندانی به شکل‌گیری و نگهداشت چرخه‌های طولانی‌تر ندارد. بنابراین، به‌صورت کلی می‌توان گفت تفاوت عمده در وزن لوپ‌ها بین این دو گروه، بیشتر در محدودهٔ حلقه‌های کوتاه‌تر و میان‌برد (مثلاً ۳تایی، ۴تایی، ۵تایی یا ۶تایی) نمایان می‌شود.در مقایسهٔ مستقیم نمودارهای حلقه‌های زوج و فرد میان دو گروه سالم (HC) و اوتیسم (ASD)، برخی از نرخ‌های خاص توجه ما را جلب کردند. به‌ویژه، حلقه‌هایی با ریت ۴ و ۶ در بعضی مواقع بین دو گروه اختلاف وزنی قابل‌توجهی از خود نشان می‌دهند؛ به این معنی که اگرچه در هر دو گروه حلقه‌های زوج در مقایسه با حلقه‌های فرد وزن بالاتری دارند، اما اوج و دامنهٔ آن در گروه اوتیسم با گروه سالم یکسان نیست. از سوی دیگر، در حلقه‌های فرد (مانند ۳تایی و ۵تایی)، گاه اختلاف کمتری بین دو گروه دیده می‌شود و نمودارها با فاصلهٔ کمتری به موازات هم سیر می‌کنند. در مجموع، یافته‌های ما نشان می‌دهد که اگرچه در هر دو گروه، تمایل به لوپ‌های کوتاه و میان‌برد بالا است و لوپ‌های طولانی عملاً کمیاب‌تر هستند، اما قدرت یا وزن حلقه‌های زوج در برخی طول‌های مشخص (مانند ۴ و ۶) می‌تواند نشانه‌ای از تفاوت‌های عصب‌شناختی میان افراد سالم و مبتلا به اوتیسم باشد. تمرکز بر این نرخ‌های ویژه در پژوهش‌های آینده، می‌تواند اطلاعات دقیق‌تری دربارهٔ سازوکارهای بازخوردی مغز و نحوهٔ سازمان‌دهی شبکه‌های مؤثر در اختلال اوتیسم ارائه دهد. همان‌طور که پیش‌تر اشاره شد، استفاده از چارک سوم به‌عنوان یک روش تحلیل معتبر نیست. بنابراین، تصمیم داریم برای انجام تحلیل‌های آماری بر روی این داده‌ها از سرویس دیتا تستینگ (یا در برخی موارد با نام سرویس سیگنال تستینگ شناخته می‌شود) استفاده کنیم. در این راستا، قصد داریم از تست‌های تی‌تست و پی‌تی‌تست برای محاسبه پی‌والیوزها بهره ببریم. سپس، با استفاده از این پی‌والیوزها شبکه را به روشی دقیق‌تر و با دقت بیشتر اسپارسیفای ‌خواهیم کرد. نهایتاً، با به‌کارگیری اصلاح و تصحیح‌های چند‌گانه (Multiple Comparisons Correction)، گراف نهایی شبکه را ایجاد خواهیم نمود. این فرآیند به‌منظور ارتقاء دقت تحلیل‌ها و به‌کارگیری آزمایش‌های آماری دقیق‌تر انجام خواهد شد که به‌ویژه برای بیولوژیست‌ها نیز معتبرتر و شفاف‌تر باشد. در ادامه، همان‌طور که پیشتر نیز مورد اشاره قرار گرفت، استفاده از کوارتر سوم به عنوان روشی برای اسپارس کردن شبکه، از نظر علمی روش معتبری محسوب نمی‌شود. به همین دلیل، ما تصمیم گرفته‌ایم تا از روش‌های دقیق‌تر آماری بهره ببریم. به عبارت دیگر، قصد داریم از سرویس‌های تست داده یا به عبارتی، سرویس‌های تست سیگنال جهت ارزیابی و اعتبارسنجی داده‌ها استفاده کنیم.در این راستا، برنامه ما شامل به‌کارگیری آزمون t و همچنین آزمون t جفت‌شده (paired t-test) برای استخراج مقادیر p-value می‌باشد. این مقادیر به عنوان شاخص‌هایی جهت سنجش معناداری تفاوت‌ها در داده‌های به‌دست‌آمده، مورد استفاده قرار خواهند گرفت. پس از تعیین p-value، گام بعدی ما، اسپارس‌ترسازی شبکه به کمک این شاخص‌ها خواهد بود؛ به عبارت دیگر، با استفاده از p-valueهای استخراج‌شده، شبکه به صورت دقیق‌تری پالایش (pruning) شده و از یال‌های کم‌اهمیت حذف می‌شود.در نهایت، با بهره‌گیری از روش‌های اصلاح چندگانه (Multiple Comparisons Correction) برای کنترل خطای نوع اول، ساختار نهایی گراف به صورت منظم و با دقت بالا ایجاد خواهد شد.این رویکرد، علاوه بر ارتقای دقت تحلیل‌های آماری، زمینه‌ای فراهم می‌کند تا نتایج به‌دست‌آمده از داده‌ها بتوانند از نظر علمی برای جامعه بیولوژیست‌ها معتبرتر ارائه شوند. بدین ترتیب، استفاده از تست‌های آماری دقیق‌تر، باعث افزایش اطمینان نسبت به نتایج و همچنین بهبود روش‌های غربالگری و تشخیص اختلالات عصبی از جمله اوتیسم خواهد شد.حلقه‌های علیتی در مغز: بینش‌هایی از آنتروپی انتقالی و مکانیسم‌های ما ایده‌ی مکانیزم بازخورد (فیدبک) را از پژوهش‌های انجام‌شده در حوزه اقتصاد وام گرفته‌ایم. در آنجا، فیدبک به این صورت تعریف می‌شود که اگر من محصولی را به کمپانی اول بفروشم و کمپانی اول مبلغی را به من پرداخت کند، سپس آن کمپانی محصولی را به کمپانی دوم بفروشد و در نهایت، کمپانی دوم محصولی را به من بفروشد، یک حلقه (لوپ) بسته شکل می‌گیرد. در اینجا، یک فیدبک اقتصادی سه مرحله‌ای ایجاد شده است که در نهایت، به خود من بازمی‌گردد.ما از همین ایده استفاده کرده‌ایم، با این تفاوت که به جای جریان پول، جریان اطلاعات (information) را در نظر می‌گیریم و این مفهوم را در مغز پیاده‌سازی می‌کنیم.علیت چرخه‌ای ایجادشده توسط بازخورد یکی از جنبه‌های مهم پیچیدگی است. در شکل 7.10، ما نمونه‌ای از یک زنجیره علّی خطی را مشاهده کردیم که از جنسیت به تخصص، از تخصص به بهره‌وری، سپس به دیده‌شدن و در نهایت از دیده‌شدن به حقوق منتهی می‌شود. این زنجیره هیچ بازخوردی ندارد و بنابراین شامل علیت چرخه‌ای نیست. جنسیت اولین علت این است که چرا برخی از دانشگاهیان کمتر از دیگران درآمد دارند. بهره‌وری در انتشار مقالات، میزان دیده‌شدن در جامعه علمی را افزایش می‌دهد، که این موضوع با معیارهایی مانند تعداد استنادات سنجیده می‌شود. دیده‌شدن، به نوبه خود، تنها علت مستقیم تعیین حقوق است. توجه داشته باشید که این روایت یک بُعد زمانی واضح دارد: پژوهشگران در اوایل دوران حرفه‌ای خود تصمیم می‌گیرند که تا چه حد تخصصی شوند و سپس همه چیز بر اساس این تصمیم پیش می‌رود.مانند همه دانشمندان، اقتصاددانان نیز به دنبال برقراری رابطه علّی بین موجودیت‌ها، مفاهیم و رویدادهای مختلف هستند. انواع روابط علّی که اقتصاددانان تحلیل می‌کنند، بسیار متنوع است و از مسائل نسبتاً محدود اقتصاد خرد تا موضوعات گسترده اقتصاد کلان را شامل می‌شود. یک پرسش متداول در اقتصاد خرد، بررسی اثرات علّی مهارت‌ها و آموزش بر درآمد و اشتغال است (به عنوان مثال، رجوع کنید به Hampf و همکاران، 2017). در مقابل، یک پرسش رایج در اقتصاد کلان مربوط به علل رشد اقتصادی است که در نهایت توضیح می‌دهد چرا برخی کشورها بسیار ثروتمندند، در حالی که بسیاری دیگر فقیر باقی مانده‌اند. میزان دشواری در تعیین و اثبات تجربی رابطه علّی بسیار متفاوت است.حلقه‌های علیتی اساس عملکرد مغز را تشکیل می‌دهند، جایی که مکانیسم‌های بازخورد، تطبیق‌های پویایی را هدایت می‌کنند که برای شناخت، ادراک و یادگیری ضروری هستند. برخلاف سیستم‌های اقتصادی که بر تبادل پول متمرکز هستند، مغز از اطلاعات به عنوان ارز اصلی خود استفاده می‌کند. حلقه‌های بازخورد در سیستم‌های عصبی را می‌توان به دو دسته تقسیم کرد: بازخورد مثبت که پاسخ‌های عصبی را تقویت می‌کند (مانند تصمیم‌گیری یا تشکیل حافظه) و بازخورد منفی که فعالیت را تثبیت می‌کند (مانند تنظیم هموستاتیک). این حلقه‌ها اغلب علیت چرخه‌ای دارند، جایی که خروجی یک فرایند ورودی آن را از طریق چرخه‌های بازگشتی تحت تأثیر قرار می‌دهد. یک مثال کلیدی، حلقه بازخورد حسی-حرکتی است: فرمان‌های قشر حرکتی حرکت را آغاز می‌کنند، بازخورد حسی اعمال بعدی را اصلاح می‌کند، و این تعامل دقت را تضمین می‌کند. برای بررسی این حلقه‌ها، آنتروپی انتقالی - معیاری برای جریان اطلاعات غیرخطی و جهت‌دار - به عنوان یک ابزار قدرتمند مطرح شده است. برخلاف روش‌های مبتنی بر همبستگی، آنتروپی انتقالی منبع و مقصد اطلاعات را متمایز می‌کند و به محققان اجازه می‌دهد روابط علی را در شبکه‌های مغزی نقشه‌برداری کنند. به‌عنوان مثال، در بازیابی حافظه، آنتروپی انتقالی می‌تواند جریان اطلاعات بین قشر پیش‌پیشانی و هیپوکامپ را کمی‌سازی کند و بازخورد پویایی را که برای حافظه اپیزودیک ضروری است، آشکار سازد. به همین ترتیب، در شبکه‌های توجه، آنتروپی انتقالی می‌تواند نشان دهد که چگونه بازخورد از نواحی عالی‌تر اولویت محرک‌های مرتبط را مشخص می‌کند. اختلال در این مکانیسم‌های بازخورد با اختلالات عصبی و روانی مرتبط است. به‌عنوان مثال، حلقه‌های نامنظم در مدار تالاموس-قشر ممکن است مشکلات پردازش حسی در اسکیزوفرنی را توضیح دهد، در حالی که بازخورد مختل در شبکه گانگلیون‌های قاعده‌ای-تالاموسی باعث نقص‌های حرکتی در بیماری پارکینسون می‌شود. علاوه بر این، جریان غیرطبیعی اطلاعات در شبکه پیش‌فرض با اختلال تفکر خودمرجعی در افسردگی مرتبط است. با استفاده از آنتروپی انتقالی در ثبت‌های عصبی، محققان می‌توانند چنین ناهنجاری‌هایی را شناسایی کرده و بینش‌هایی برای تشخیص و درمان ارائه دهند. حلقه‌های علیتی در مغز، سازگاری و پیچیدگی خارق‌العاده آن را برجسته می‌کنند. با ترکیب آنتروپی انتقالی با سایر تکنیک‌های تحلیلی، دانشمندان علوم اعصاب می‌توانند درک عمیق‌تری از پویایی بازخورد به‌دست آورند و آشکار کنند که چگونه تعامل اطلاعات، شناخت و رفتار را شکل می‌دهد. فراتر از علوم اعصاب، این یافته‌ها الهام‌بخش پیشرفت‌هایی در هوش مصنوعی هستند، جایی که مکانیسم‌های بازخورد زیست‌الهام گرفته می‌توانند یادگیری ماشین را بهبود بخشند. در نهایت، مطالعه حلقه‌های علیتی نه تنها کارکردهای درونی مغز را روشن می‌کند، بلکه راه را برای نوآوری در پزشکی و فناوری هموار می‌سازد. در ROIهای عملکردی، نحوه‌ی بازخوردها (فیدبک‌ها) را مورد بررسی قرار دادیم و آن‌ها را بر اساس رتبه (rank) دسته‌بندی و توضیح کردیم. رتبه در اینجا به این معناست که اگر یک اطلاعات (Information) پس از عبور از چهار لینک دوباره به همان گره (Node) بازگردد، رتبه‌ی آن ۴ در نظر گرفته می‌شود.ROIهای عملکردی شامل هفت مورد هستند که (X) را دربرمی‌گیرند. ما این موارد را بررسی کرده و تفاوت‌های قابل‌توجهی میان مغزهای سالم و اوتیسمی شناسایی کردیم که می‌توان از آن‌ها به عنوان بیومارکر استفاده کرد.برای بررسی نحوه‌ی رفتار این فیدبک‌ها در شبکه‌های تصادفی (Random Networks)، آن‌ها را در شکل ۵ ترسیم کردیم. نتایج نشان داد که این نمودارها برای سه نوع شبکه—شبکه‌ی تصادفی، شبکه‌ی مغز سالم، و شبکه‌ی مغز اوتیسمی—رفتارهای متفاوتی نشان می‌دهند.شدت جریان فیدبک در مغز سالم به‌مراتب بیشتر از مغز اوتیسمی است و همان‌طور که انتظار داشتیم، در شبکه‌های تصادفی کمترین مقدار را دارد. بااین‌حال، در نهایت، همه‌ی آن‌ها به صفر میل می‌کنند. همچنین، نمودار KDE آن‌ها را نیز ترسیم کردیم تا تابع توزیعشان را بهتر مشاهده کنیم. همان‌طور که در شکل ۶ مشخص است، حلقه‌های بازخورد (Loops) در مغزهای سالم بزرگ‌تر از مغزهای اوتیسمی و تصادفی هستند.ابزار های ارزیابیدر این تحقیق، برای ارزیابی نتایج و مقایسه تفاوت‌های میان گروه‌های مختلف (مغز سالم و مغز اوتیسمی) و تحلیل صحت و دقت مدل‌ها از ابزارهای آماری مختلفی استفاده شده است. در اینجا توضیح مختصری از این ابزارها و نحوه استفاده آن‌ها در پژوهش آورده شده است.1. Paired T-test برای مقایسهٔ تفاوت‌های میان گروه‌ها و ارزیابی معناداری این تفاوت‌ها، از Paired T-test استفاده شد. این ابزار آماری برای مقایسه میانگین‌های دو گروه وابسته به کار می‌رود. به عبارت دیگر، زمانی که داده‌ها از همان نمونه (یعنی همان افراد) در دو وضعیت مختلف جمع‌آوری شده باشد، از Paired T-test برای بررسی این تفاوت‌ها استفاده می‌شود.در این تحقیق، Paired T-test برای مقایسه نتایج مغز سالم و مغز اوتیسمی در اندازه‌گیری‌های مختلف مانند میزان آنتروپی انتقالی و اتصال‌های مغزی انجام شد. این ابزار به ما اجازه داد تا تعیین کنیم آیا تفاوت‌های مشاهده‌شده در داده‌ها معنادار هستند یا صرفاً به‌طور تصادفی رخ داده‌اند. با استفاده از این تست، ما توانستیم به‌طور علمی و دقیق ارزیابی کنیم که آیا تفاوت‌ها میان دو گروه واقعاً وجود دارند یا خیر.2. Multiple Comparisons Correction یکی از چالش‌های اصلی در مطالعات آماری که شامل مقایسه‌های متعدد است، افزایش احتمال وقوع خطای نوع اول (اشتباه در رد کردن فرضیه صفر) است. هنگامی که چندین مقایسه هم‌زمان انجام می‌شود، احتمال اینکه به‌طور تصادفی تفاوت‌هایی مشاهده کنیم که در واقع وجود ندارند، افزایش می‌یابد. برای جلوگیری از این مشکل، از Multiple Comparisons Correction استفاده شده است.در این تحقیق، پس از انجام Paired T-test و مقایسه‌های متعدد بین داده‌های مختلف، از روش‌های اصلاحی نظیر روش بونفرونی یا روش فالس دیسکوری (False Discovery Rate) برای کنترل نرخ خطای نوع اول استفاده شد. این اصلاحات آماری به این صورت عمل می‌کنند که آستانهٔ معناداری را برای مقایسه‌ها تنظیم می‌کنند و از بروز نتایج نادرست جلوگیری می‌کنند. به این ترتیب، اطمینان حاصل می‌شود که نتایج به‌دست‌آمده در نهایت از دقت و صحت علمی برخوردار هستند.3. Surrogate Data Testing برای ارزیابی پایداری و اعتماد به نتایج مدل‌های محاسباتی و به‌منظور اطمینان از اینکه روابط مشاهده‌شده بین متغیرها تنها به دلیل تصادف یا ناهنجاری‌های داده‌ها ایجاد نشده‌اند، از Surrogate Data Testing استفاده شد.در این روش، داده‌های اولیه با استفاده از یک فرآیند تصادفی شبیه‌سازی می‌شوند تا بررسی شود که آیا نتایج به‌دست‌آمده به‌طور تصادفی ممکن است در داده‌ها ظاهر شوند یا خیر. اگر نتایج مشاهده‌شده در داده‌های جانشینی قابل‌تکرار نباشد، نشان‌دهنده این است که روابط مشاهده‌شده در داده‌های اصلی معنادار هستند و نه تصادفی.در این تحقیق، داده‌های آنتروپی انتقالی و شبکه‌های مغزی به‌طور ویژه با استفاده از آزمون‌های داده‌های جانشینی ارزیابی شدند تا اطمینان حاصل شود که ارتباطات کشف‌شده در شبکه‌های مغزی اوتیسمی و سالم بر اساس شبیه‌سازی‌های تصادفی نیستند و به‌طور معناداری در داده‌ها وجود دارند.4. Null Hypothesis در تمامی آزمایش‌های آماری انجام‌شده، از Null Hypothesis برای ارزیابی صحت نتایج استفاده شد. فرضیه صفر به این صورت است که هیچ تفاوت واقعی میان گروه‌ها یا داده‌ها وجود ندارد و هر تفاوت مشاهده‌شده به‌طور تصادفی رخ داده است. هدف از آزمون‌های آماری، رد کردن فرضیه صفر است و در صورتی که نتایج نشان دهند که تفاوت‌ها معنادار هستند، فرضیه صفر رد می‌شود.در این تحقیق، فرضیه صفر برای تفاوت‌های اطلاعاتی میان مغز سالم و مغز اوتیسمی در نظر گرفته شد. برای رد فرضیه صفر و اثبات اینکه تفاوت‌های مشاهده‌شده واقعی و معنادار هستند، از آزمون‌های آماری مختلف مانند Paired T-test و Surrogate Data Testing استفاده شد. به عبارت دیگر، ما در این تحقیق سعی داشتیم تا Null Hypothesis را رد کنیم و نشان دهیم که واقعاً تفاوت‌هایی میان نحوه جریان اطلاعات در مغز سالم و مغز مبتلا به اوتیسم وجود دارد.استفاده از این ابزارهای آماری پیشرفته به ما کمک کرد تا اطمینان حاصل کنیم که نتایج این تحقیق معنادار و قابل‌اعتماد هستند. به‌ویژه، با استفاده از آزمون‌های داده‌های جانشینی و Multiple Comparisons Correction، توانستیم از بروز خطاهای احتمالی جلوگیری کرده و دقت بیشتری در تحلیل‌ها داشته باشیم. در نهایت، این ابزارها نه تنها صحت نتایج تحقیق را تأیید کردند، بلکه امکان انجام تحلیل‌های پیچیده‌تر و مقایسه‌های دقیق‌تری میان گروه‌ها را فراهم کردند که در نهایت به گسترش و بهبود درمان‌های مبتنی بر تحریک مغزی برای افراد مبتلا به اوتیسم منجر خواهد شد.جمعبندیدر این تحقیق، به بررسی تفاوت‌های ساختاری و عملکردی مغز افراد مبتلا به اوتیسم نسبت به افراد سالم پرداخته شد. نتایج به‌دست‌آمده نشان داد که مغز افراد مبتلا به اوتیسم الگوهای متفاوتی از اتصال عصبی و جریان اطلاعات نسبت به مغز سالم دارد. این یافته‌ها می‌توانند به‌عنوان مبنای توسعه نشانگرهای زیستی جدید برای تشخیص و بررسی دقیق‌تر این اختلال در آینده استفاده شوند. استفاده از مفاهیم پیشرفته‌ای همچون آنتروپی انتقالی برای مدل‌سازی جریان اطلاعات در مغز، به‌ویژه در اختلالات مغزی مانند اوتیسم، گامی مهم در تحلیل پیچیدگی‌های مغزی است.این تحقیق همچنین اهمیت مدل‌سازی دقیق‌تر جریان اطلاعات در مغز را به‌ویژه در ارتباط با اختلالات عصبی مانند اوتیسم به خوبی نشان داد. آنتروپی انتقالی به‌عنوان یک ابزار تحلیلی می‌تواند به شفاف‌سازی روابط علی و نحوه تعامل نواحی مختلف مغز کمک کند. این ابزار به‌طور خاص در تحلیل نحوه انتقال و پردازش اطلاعات در مغز افراد مبتلا به اوتیسم مورد استفاده قرار گرفت و تفاوت‌های معناداری در ساختارهای مغزی این گروه نسبت به افراد سالم مشاهده شد. جریان اطلاعات در مغز افراد مبتلا به اوتیسم به‌گونه‌ای است که نشان‌دهنده تغییرات و ناهنجاری‌هایی در الگوهای ارتباطی مغز است که می‌تواند به عنوان عامل اصلی در اختلالات رفتاری و شناختی این افراد در نظر گرفته شود.یکی از نکات قابل توجه در این تحقیق، استفاده از روش‌های نوین تحلیل مانند مدل‌سازی جریان اطلاعات و تحلیل آنتروپی بود که امکان بررسی و شبیه‌سازی دقیق‌تری از نحوه کارکرد شبکه‌های مغزی را فراهم آورد. این روش‌ها کمک می‌کنند تا بتوان به‌طور مؤثرتر و دقیق‌تر به شناسایی اختلالات مغزی و درمان‌های مناسب برای آن‌ها پرداخت. به‌ویژه، استفاده از این روش‌ها در بهبود درمان‌های مبتنی بر تحریک مغزی می‌تواند نتایج مثبتی در تنظیم مسیرهای اطلاعاتی مغز و اصلاح شبکه‌های عصبی مغز در افراد مبتلا به اوتیسم داشته باشد.تحقیقات پیشین نشان داده‌اند که تحریک مغزی می‌تواند تأثیرات مفیدی بر بهبود عملکرد مغز و کاهش علائم اختلالات عصبی داشته باشد، اما نتایج این تحقیق تأکید بیشتری بر استفاده از روش‌های دقیق‌تر و هدفمندتر دارد. این روش‌ها به ویژه می‌توانند در درمان‌های شخصی‌سازی‌شده برای بیماران اوتیسمی مفید واقع شوند و کمک کنند تا مسیرهای اطلاعاتی مغز به‌طور بهینه تنظیم شوند. با شناسایی دقیق‌تر این مسیرهای اطلاعاتی، می‌توانیم مداخلات درمانی را به گونه‌ای طراحی کنیم که تأثیر بیشتری بر تغییرات مغزی و بهبود وضعیت بیماران داشته باشد.همچنین، این نتایج می‌توانند به گسترش روش‌های درمانی نوآورانه در تحقیقات بالینی کمک کنند. با شبیه‌سازی دقیق‌تر شبکه‌های مغزی و پیگیری تغییرات در مسیرهای اطلاعاتی مغز، متخصصان می‌توانند رویکردهای جدیدی برای درمان اختلالات عصبی نظیر اوتیسم پیشنهاد دهند. در نهایت، این مطالعه می‌تواند به‌عنوان گامی مهم در فرآیند تشخیص و درمان اختلالات مغزی در آینده عمل کند و نقش مهمی در تسریع فرآیندهای بالینی برای بهبود وضعیت بیماران ایفا کند.از دیگر پیامدهای این تحقیق می‌توان به پتانسیل‌های موجود برای تحقیق در زمینه هوش مصنوعی اشاره کرد. با بهره‌گیری از مدل‌های پیچیده‌تر و روش‌های تحلیلی مبتنی بر داده‌های مغزی، امکان طراحی سیستم‌های هوش مصنوعی زیست‌الهام گرفته وجود دارد که می‌توانند در آینده به‌طور گسترده‌ای در پزشکی شخصی و درمان اختلالات عصبی به کار گرفته شوند. این سیستم‌ها قادر خواهند بود تا روندهای پیچیده مغز را شبیه‌سازی کرده و پیشنهادهای درمانی بهینه برای هر فرد ارائه دهند.همچنین، این تحقیق می‌تواند زمینه‌ساز تحقیقات بیشتری در زمینه شبکه‌های عصبی و ارتباطات مغزی در افراد سالم و مبتلا به اختلالات مختلف باشد. درک بهتر از نحوه عملکرد مغز و نحوه انتقال اطلاعات میان نواحی مختلف آن، در درک بهتر فرآیندهای شناختی، رفتاری و عاطفی کمک خواهد کرد. به‌ویژه در اختلالات پیچیده‌ای مانند اوتیسم، که اختلالات در فرآیندهای اطلاعاتی مغز می‌تواند به مشکلات رفتاری و اجتماعی منجر شود، مطالعات دقیق‌تر می‌تواند گام‌هایی مؤثر در بهبود درمان‌های شناختی و رفتاری به‌شمار رود.در پایان، با توجه به یافته‌های این تحقیق، می‌توان گفت که استفاده از روش‌های پیشرفته تحلیلی و مدل‌سازی در تحقیقات درمانی اوتیسم نه تنها می‌تواند در درک بهتر از مکانیسم‌های عصبی این اختلالات مؤثر باشد، بلکه به‌طور مستقیم بر توسعه درمان‌های مؤثر و شخصی‌سازی‌شده نیز تأثیرگذار است. بنابراین، این تحقیق به‌عنوان یک نقطه عطف در تحقیقات درمانی اوتیسم و اختلالات مشابه می‌تواند راه‌گشای روش‌های نوآورانه و تحقیقات بالینی جدید باشد که در نهایت به بهبود کیفیت زندگی بیماران و تسریع در فرآیندهای درمانی کمک خواهد کرد.مراجع[1] Ataei, S., Attar, N., Aliakbary, S. and Bakouie, F., 2019. Graph theoretical approach for screening autism on brain complex networks. SN Applied Sciences, 1(9), p.1122.[2] Sherkatghanad, Z., Akhondzadeh, M., Salari, S., Zomorodi-Moghadam, M., Abdar, M., Acharya, U.R., Khosrowabadi, R. and Salari, V., 2020. Automated detection of autism spectrum disorder using a convolutional neural network. Frontiers in neuroscience, 13, p.1325.[3] Sadeghi, M., Khosrowabadi, R., Bakouie, F., Mahdavi, H., Eslahchi, C. and Pouretemad, H., 2017. Screening of autism based on task-free fmri using graph theoretical approach. Psychiatry Research: Neuroimaging, 263, pp.48-56.Vancouver[4] Saberi, M., Khosrowabadi, R., Khatibi, A., Misic, B. and Jafari, G., 2021. Topological impact of negative links on the stability of resting-state brain network. Scientific reports, 11(1), p.2176.[5] Wang, J., Khosrowabadi, R., Ng, K.K., Hong, Z., Chong, J.S.X., Wang, Y., Chen, C.Y., Hilal, S., Venketasubramanian, N., Wong, T.Y. and Chen, C.L.H., 2018. Alterations in brain network topology and structural-functional connectome coupling relate to cognitive impairment. Frontiers in Aging Neuroscience, 10, p.404.[6] Di Martino, A., Yan, C.G., Li, Q., Denio, E., Castellanos, F.X., Alaerts, K., Anderson, J.S., Assaf, M., Bookheimer, S.Y., Dapretto, M. and Deen, B., 2014. The autism brain imaging data exchange: towards a large-scale evaluation of the intrinsic brain architecture in autism. Molecular psychiatry, 19(6), pp.659-667.Vancouver[7] Bassett, D. S., & Sporns, O. (2017). “Network neuroscience.” Nature Neuroscience, 20(3), 353–364.[8] Gu, Shi, et al. “Controllability of Structural Brain Networks.” Nature Communications, vol.6, no. 1, 1Oct. 2015[9] Tang, E., & Bassett, D. S. (2018). Colloquium : Control of dynamics in brain networks. Reviews of Modern Physics, 90(3)[10] 4. Wig, G. S., Schlaggar, B. L., & Petersen, S. E. (2011). “Concepts and principles in the analysis of brain networks.” Annals of the New York Academy of Sciences, 1224(1), 126–146.[11] Fornito, A., Zalesky, A., & Bullmore, E. (2016). “Fundamentals of Brain Network Analysis.” Academic Press.[12] Kana, R. K., Libero, L. E., & Moore, M. S. (2011). “Disrupted cortical connectivity theory as an explanatory model for autism spectrum disorders.” Physics of Life Reviews, 8(4), 410–437.[13] Park, H. J., & Friston, K. (2013). “Structural and functional brain networks: from connections to cognition.” Science, 342(6158), 1238411.[14] Deco, G., Jirsa, V. K., McIntosh, A. R., Sporns, O., & Kötter, R. (2009). “Key role of coupling, delay, and noise in resting brain fluctuations.” Proceedings of the National Academy of Sciences (PNAS), 106(25), 10302–10307.[15] Gollo, L. L., Roberts, J. A., Cropley, V. L., Di Biase, M. A., Pantelis, C., Zalesky, A., & Breakspear, M. (2018). “Fragility and volatility of structural hubs in the human connectome.” Nature Neuroscience, 21(8), 1107–1116.[16] Plitt, M., Barnes, K. A., & Martin, A. (2015). “Functional connectivity classification of autism identifies highly predictive brain features but falls short of biomarker standards.” NeuroImage: Clinical, 7, 359–366.[17] Maximo, J. O., Cadena, E. J., & Kana, R. K. (2014). “The implications of brain connectivity in the neuropsychology of autism.” Neuropsychology Review, 24(1), 16–31.[18] Heinsfeld, A. S., Franco, A. R., Craddock, R. C., Buchweitz, A., & Meneguzzi, F. (2018). “Identification of autism spectrum disorder using deep learning and the ABIDE dataset.” NeuroImage: Clinical, 17, 16–23.[19] Holiga, Š., Soriano-Mas, C., Fernández, D., Alcañiz, M., & Radua, J. (2019). “Shifting brain connectivity towards randomness in autism reveals an optimal network structure for information integration.” Human Brain Mapping, 40(4), 1147–1160.[20] Chen, B., Wang, C., Dong, Q., & Miao, D. (2016). “Classification of autism spectrum disorders using a combination of anatomical and functional connectivity measures.” Frontiers in Neuroscience, 10, 406.[21] Di Martino, A., et al. (2017). “Enhancing studies of the connectome in autism using the autism brain imaging data exchange II.” Scientific Data, 4, 170010.[22] Rashid, B., Damaraju, E., Pearlson, G. D., & Calhoun, V. D. (2016). “Dynamic connectivity states in schizophrenia and the relationship with clinical symptoms.” Translational Psychiatry, 6(9), e951.[23] Dajani, D. R., Largis, E. E., Burrows, C. A., Odriozola, P., Fetters, K. M., Kennedy, D. P., & Uddin, L. Q. (2021). “Adaptive brain network dynamics reflect functional roles of regions under cognitive load in individuals with autism.” NeuroImage, 231, 117848.[24] Khan, S., Michmizos, K. P., Tomasi, D., & Li, Q. (2020). “Disrupted spatiotemporal patterns of brain activity in autism.” Molecular Autism, 11, 67.[25] Rojas-Líbano, D., Sanguinetti, G., Flores, K., & Alarcon, M. (2022). “Network-based biomarkers and heterogeneity in autism spectrum disorders.” Frontiers in Psychiatry, 13, 889367.[26] Wibral, M., Vicente, R., & Lizier, J. T. (Eds.). (2014). Directed Information Measures in Neuroscience. Understanding Complex Systems. Springer.[27] Assaf, A., Bilgin, M. H., & Demir, E. (2022). Using transfer entropyto measure information flows between cryptocurrencies. Physica A: Statistical Mechanics and Its Applications, 586, 126484.[28] Dimpfl, T., & Peter, F. J. (2012). Using transfer entropy to measure information flows between financial markets. SFB 649 Discussion Paper, 2012-051. Humboldt University of Berlin.[29] Lizier, Joseph. (2014). JIDT: An Information-Theoretic Toolkit for Studying the Dynamics of Complex Systems. Frontiers in Robotics and AI. 1. 10.3389/frobt.2014.00011.[30] Lizier, Joseph. (2013). The Local Information Dynamics of Distributed Computation in Complex Systems. 10.1007/978-3-64232952-4.[31] Lizier, Joseph. (2021). Information transfer - Part 1 Concept. https://www.youtube.com/watch?v=_30xlQenNq8[32] Lizier, Joseph. (2021). Information transfer - Part 2 - Transfer entropy, and JIDT. https://www.youtube.com/watch?v=PXeI510ID5c[33] Lizier, Joseph. (2021). Information transfer - Part 3 - Heartbeat messages activity. https://www.youtube.com/watch?v=iGRtYOb4NKI[34] Friston, K. (2010). The free-energy principle: a unified brain theory. Nature Reviews Neuroscience, 11(2), 127-138[35] Schreiber, T. (2000). Measuring information transfer. Physical Review Letters, 85(2), 461-464.[36] Breakspear, M. (2017). Dynamic models of large-scale brain activity. Nature Neuroscience, 20(3), 340-352.[37] Deco, G., & Jirsa, V. K. (2012). Ongoing cortical activity at rest: criticality, multistability, and ghost attractors. Journal of Neuroscience, 32(10), 3366-3375[38] Hakimi Siboni, M. H., A. Kargaran, and G. R. Jafari. "Hybrid balance theory: Heider balance under higher-order interactions." Physical Review E 105.5 (2022): 054105.[39] Saberi, Majid, et al. "Pattern of frustration formation in the functional brain network." Network Neuroscience 6.4 (2022): 1334-1356.[40] Rabbani, F., Amir H. Shirazi, and G. R. Jafari. "Mean-field solution of structural balance dynamics in nonzero temperature." Physical Review E 99.6 (2019): 062302.[41] Pollonini, L., Patidar, U., Situ, N., Rezaie, R., Papanicolaou, A.C. and Zouridakis, G., 2010, August. Functional connectivity networks in the autistic and healthy brain are assessed using Granger causality. In 2010 Annual International Conference of the IEEE Engineering in Medicine and Biology (pp. 1730-1733). IEEE.[42] Barrett, A.B. and Barnett, L., 2013. Granger causality is designed to measure effect, not mechanism. Frontiers in neuroinformatics, 7, p.6.[43] Schreiber, T., 2000. Measuring information transfer. Physical review letters, 85(2), p.461.[44] Lizier, J.T., Prokopenko, M. and Zomaya, A.Y., 2008. Local information transfer as a spatiotemporal filter for complex systems. Physical Review E—Statistical, Nonlinear, and Soft Matter Physics, 77(2), p.026110. مجتبی شکوری فر مجتبی شکوری فر Fri, 07 Feb 2025 16:49:49 +0330 https://virgool.io/@mojtabao121/%D9%BE%D8%B1%D9%88%DA%98%D9%87-hohuk8fyaqup بررسی برخی از معماری ها در این قسمت ابتدا برخی از معماری های متدول را توضیح میدهیم و بعد وارد بررسی معماری های شرکت های مختلف می شویممعماری یونیکرنل (Unikernel)معماری یونیکرنل (Unikernel) یک معماری سیستم عامل است که بر اساس مفهوم کرنل مجازی (virtual kernel) ساخته شده است. کرنل مجازی یک نوع کرنل است که به جای اینکه یک برنامه کامل باشد، فقط یک مجموعه کوچک از توابع ضروری را برای اجرای یک برنامه کاربردی فراهم می کند.معماری یونیکرنل مزایای زیادی نسبت به معماری های سنتی سیستم عامل دارد، از جمله:سادگی و کارایی: معماری یونیکرنل بسیار ساده تر از معماری های سنتی است، زیرا فقط یک مجموعه کوچک از توابع را اجرا می کند. این امر منجر به بهبود کارایی و امنیت می شود.به عنوان مثال، یک سیستم عامل سنتی ممکن است شامل چندین میلیون خط کد باشد. این کد شامل توابع زیادی است که برای پشتیبانی از طیف گسترده ای از ویژگی ها و قابلیت ها ضروری است. با این حال، بسیاری از این توابع برای اجرای یک برنامه کاربردی خاص ضروری نیستند.یک سیستم عامل یونیکرنل فقط شامل توابعی است که برای اجرای یک برنامه کاربردی خاص ضروری هستند. این امر منجر به کاهش قابل توجهی در اندازه و پیچیدگی سیستم عامل می شود.کاهش اندازه و پیچیدگی سیستم عامل منجر به بهبود کارایی و امنیت می شود. سیستم عامل های کوچکتر و ساده تر سریعتر راه اندازی می شوند و کمتر مستعد حملات امنیتی هستند.ایمنی:معماری یونیکرنل از نظر امنیتی بسیار ایمن تر از معماری های سنتی است، زیرا فقط یک برنامه کاربردی را اجرا می کند. این امر خطر حملات امنیتی را کاهش می دهد.در یک سیستم عامل سنتی، تمام برنامه های کاربردی در یک فضای واحد اجرا می شوند. این امر به مهاجمان اجازه می دهد تا از یک برنامه کاربردی آسیب پذیر برای حمله به سایر برنامه های کاربردی استفاده کنند.در یک سیستم عامل یونیکرنل، هر برنامه کاربردی در یک فضای جداگانه اجرا می شود. این امر به مهاجمان اجازه نمی دهد تا از یک برنامه کاربردی آسیب پذیر برای حمله به سایر برنامه های کاربردی استفاده کنند.انعطاف پذیری:معماری یونیکرنل بسیار انعطاف پذیر است، زیرا می تواند برای اجرای طیف گسترده ای از برنامه های کاربردی استفاده شود.سیستم عامل های سنتی معمولاً برای اجرای برنامه های کاربردی خاص طراحی شده اند. به عنوان مثال، یک سیستم عامل لینوکس برای اجرای برنامه های کاربردی مبتنی بر هسته لینوکس طراحی شده است.معماری یونیکرنل می تواند برای اجرای طیف گسترده ای از برنامه های کاربردی استفاده شود، از جمله برنامه های کاربردی مبتنی بر لینوکس، برنامه های کاربردی مبتنی بر ویندوز، برنامه های کاربردی وب، و برنامه های کاربردی موبایل.برخی از معایب این معماری عبارتند از:پیچیدگی توسعه:توسعه یک سیستم عامل یونیکرنل می تواند پیچیده باشد، زیرا نیاز به دانش و مهارت خاصی دارد. به عنوان مثال، توسعه دهندگان باید با مفاهیم پیچیده ای مانند مجازی سازی، کامپایل به ماشین مجازی، و مدیریت حافظه آشنا باشند.علاوه بر این، توسعه دهندگان باید بتوانند برنامه کاربردی را به گونه ای طراحی کنند که با محدودیت های سیستم عامل یونیکرنل سازگار باشد. این امر می تواند چالش برانگیز باشد، زیرا برنامه کاربردی باید از منابع سیستم عامل به طور کارآمد استفاده کند و از آسیب پذیری های امنیتی جلوگیری کند.محدودیت های عملکردی: سیستم عامل های یونیکرنل ممکن است از نظر عملکردی محدود باشند، زیرا فقط برای اجرای یک برنامه کاربردی خاص طراحی شده اند. این امر به این دلیل است که سیستم عامل یونیکرنل باید توابعی را فراهم کند که برای اجرای برنامه کاربردی خاص ضروری هستند.به عنوان مثال، یک سیستم عامل یونیکرنل که برای اجرای یک برنامه کاربردی وب طراحی شده است، باید توابعی را برای مدیریت شبکه، مدیریت پایگاه داده، و پردازش درخواست های HTTP فراهم کند. این توابع می توانند بر عملکرد سیستم عامل تأثیر بگذارند.محدودیت های پشتیبانی: پشتیبانی از سیستم عامل های یونیکرنل ممکن است دشوار باشد، زیرا تعداد توسعه دهندگان و متخصصانی که در این زمینه مهارت دارند محدود است. این امر می تواند مشکل ساز باشد، زیرا ممکن است لازم باشد سیستم عامل یونیکرنل در صورت بروز اشکالات یا باگ ها به روز شود.علاوه بر این، توسعه دهندگان ممکن است برای دریافت پشتیبانی از سیستم عامل یونیکرنل مجبور به پرداخت هزینه باشند. این امر می تواند برای سازمان هایی که بودجه محدودی دارند مشکل ساز باشد.در مجموع، معماری یونیکرنل یک معماری سیستم عامل امیدوار کننده است که مزایای زیادی نسبت به معماری های سنتی دارد. با این حال، این معماری معایبی نیز دارد که باید در نظر گرفته شوند.معماری یونیکرنل در موارد استفاده مختلفی مورد استفاده قرار می گیرد، از جمله:· اجرای برنامه های کاربردی حساس از نظر امنیتی، مانند برنامه های کاربردی دولتی یا مالی.معماری یونیکرنل به دلیل امنیت بالا، برای اجرای برنامه های کاربردی حساس از نظر امنیتی بسیار مناسب است. در یک سیستم عامل یونیکرنل، هر برنامه کاربردی در یک فضای جداگانه اجرا می شود. این امر به مهاجمان اجازه نمی دهد تا از یک برنامه کاربردی آسیب پذیر برای حمله به سایر برنامه های کاربردی استفاده کنند.به عنوان مثال، سازمان های دولتی یا مالی ممکن است از سیستم عامل های یونیکرنل برای اجرای برنامه های کاربردی حساس خود مانند سامانه های مالی یا سامانه های دفاعی استفاده کنند.· اجرای برنامه های کاربردی در محیط های محدود، مانند دستگاه های IoT یا محیط های cloud.معماری یونیکرنل به دلیل اندازه کوچک و سادگی، برای اجرای برنامه های کاربردی در محیط های محدود بسیار مناسب است. در یک سیستم عامل یونیکرنل، فقط توابعی که برای اجرای برنامه کاربردی ضروری هستند، اجرا می شوند. این امر باعث می شود که سیستم عامل یونیکرنل کارآمدتر و مصرف کننده منابع کمتری باشد.به عنوان مثال، سازمان های دولتی یا نظامی ممکن است از سیستم عامل های یونیکرنل برای اجرای برنامه های کاربردی در دستگاه های IoT مانند پهپادها یا حسگرها استفاده کنند.· اجرای برنامه های کاربردی با کارایی بالا، مانند برنامه های کاربردی پردازش داده یا بازی های ویدیویی.معماری یونیکرنل به دلیل سادگی و کارایی بالا، برای اجرای برنامه های کاربردی با کارایی بالا بسیار مناسب است. در یک سیستم عامل یونیکرنل، فقط توابعی که برای اجرای برنامه کاربردی ضروری هستند، اجرا می شوند. این امر باعث می شود که سیستم عامل یونیکرنل سریعتر راه اندازی شود و عملکرد بهتری داشته باشد.به عنوان مثال، سازمان های فناوری اطلاعات ممکن است از سیستم عامل های یونیکرنل برای اجرای برنامه های کاربردی پردازش داده یا بازی های ویدیویی استفاده کنند.معماری مونولوتیک(monolithic architecture)معماری یکپارچه یک معماری نرم افزاری است که از یک واحد منطقی و یک فایل اجرایی واحد تشکیل شده است. تمام بخش‌های برنامه کاملاً به هم متصل و به هم وابسته هستند. این معماری معمولا برای کاربردهای کوچک و ساده مناسب است.تاریخچه و تکامل معماری‌های یکپارچه را می‌توان دردوران محاسبات بزرگ در اواسط قرن بیستم، زمانی که محدودیت‌های فنی گزینه‌های طراحی سیستم‌های نرم‌افزاری را محدود می‌کرد، ردیابی کرد. معماری های یکپارچه برای کاربردهای کوچک و ساده مناسب بودند، اما با پیشرفت تکنولوژی و نیازهای تجاری، به گلوگاهی برای رشد تبدیل شدند.روش های مختلفی برای طراحی معماری داخلی یک برنامه کاربردی یکپارچه وجود دارد، مانند استفاده از رویکرد لایه ای، مدولار یا مبتنی بر مؤلفه. هر یک از این روش ها از نظر کارایی، سادگی، انعطاف پذیری و قابلیت نگهداری مزایا و معایب خاص خود را دارند. برخی از ویژگی های مشترک یک معماری یکپارچه عبارتند از:تک اجرای یا Single executable: کل برنامه به صورت یک فایل اجرایی بسته بندی و مستقر می شود. همه اجزا و ماژول ها با هم ترکیب شده اند.اتصال محکم: اجزا و ماژول های داخل برنامه بسیار به هم مرتبط هستند و به یکدیگر وابسته هستند. تغییرات ایجاد شده در یک مؤلفه ممکن است نیاز به تغییرات در سایر بخش‌های برنامه داشته باشد.حافظه اشتراکی: همه اجزای برنامه دارای فضای حافظه یکسانی هستند. آنها می توانند مستقیماً به ساختارهای داده مشترک دسترسی داشته باشند و آنها را اصلاح کنند.استقرار یکپارچه: کل برنامه به صورت یک واحد مستقر می شود. به روز رسانی یا تغییرات در برنامه نیاز به استقرار مجدد کل یکپارچه دارد.جریان کنترل متمرکز: جریان کنترل در برنامه معمولاً توسط یک ماژول مرکزی یا یک تابع اصلی مدیریت می شود. جریان اجرا به صورت متوالی از یک جزء به جزء دیگر حرکت می کند.چالش های تجزیه یک برنامه یکپارچه به میکروسرویس ها بی اهمیت نیستند و نیاز به برنامه ریزی و اجرای دقیق دارند. برخی از چالش های رایج عبارتند از:· تجزیه سرویس: نحوه شناسایی و استخراج خدمات مستقلی که یک قابلیت تجاری را از برنامه یکپارچه محصور می کند.· توسعه موازی: نحوه اجرای موازی برنامه یکپارچه هنگام توسعه میکروسرویس ها و نحوه مدیریت وابستگی ها و ارتباطات بین آنها.· بازسازی پایگاه داده: نحوه تقسیم پایگاه داده یکپارچه به پایگاه های داده جداگانه برای هر میکروسرویس، و نحوه رسیدگی به مسائل مربوط به سازگاری و یکپارچگی داده ها.· مدیریت تراکنش: نحوه مدیریت تراکنش‌هایی که در چندین ریزسرویس انجام می‌شوند، و نحوه برخورد با اقدامات نهایی و سازگاری.برخی از نکات و بهترین روش ها برای طراحی و توسعه یک برنامه کاربردی یکپارچه عبارتند از:· از معماری لایه ای استفاده کنید: برنامه را به لایه های مختلفی مانند ارائه، کسب و کار، دسترسی به داده ها و پایگاه داده جدا کنید و برای هر لایه رابط ها و مسئولیت های واضحی تعریف کنید.· از طراحی ماژولار استفاده کنید: برنامه را به ماژول های کوچکتر تقسیم کنید که نشان دهنده یک ویژگی یا یک عملکرد است، و از کپسوله سازی و انتزاع برای پنهان کردن جزئیات پیاده سازی و افشای تنها رابط های ضروری استفاده کنید.· از رویکرد مبتنی بر مؤلفه استفاده کنید: برنامه را به اجزای قابل استفاده مجدد تقسیم کنید که از طریق یک رابط کاملاً تعریف شده سرویسی را ارائه می دهند و از تزریق وابستگی و وارونگی کنترل برای مدیریت وابستگی ها و تعاملات بین مؤلفه ها استفاده کنید.· از الگوهای طراحی استفاده کنید: برای حل مشکلات رایج طراحی و بهبود کیفیت و قابلیت نگهداری کد، از الگوهای طراحی مناسب مانند کارخانه، تک تن، استراتژی، ناظر و واسطه استفاده کنید.· از ابزارهای کیفیت کد استفاده کنید: از ابزارهایی مانند تحلیلگر کد، فرمت‌کننده کد، پوشش کد، و بازبینی کد استفاده کنید تا مطمئن شوید کد از بهترین شیوه‌ها، استانداردها و قراردادها پیروی می‌کند و هر گونه خطا، باگ یا آسیب‌پذیری را شناسایی و رفع می‌کند. .برخی از مزایا و معایب معماری یکپارچه عبارتند از:مزایا:سادگی: معماری یکپارچه ساده تر از معماری های دیگر است و نیازی به پیچیدگی های ارتباط بین سرویس ها، مدیریت شبکه، مقیاس پذیری و نظارت ندارد.کارایی: یک معماری یکپارچه می تواند سریعتر اجرا شود زیرا نیازی به فراخوانی سرویس های خارجی ندارد و از منابع سخت افزاری کمتری استفاده می کند.امنیت: یک معماری یکپارچه می تواند امن تر باشد زیرا دسترسی به داده ها و منطق محدود به یک واحد است و نیازی به احراز هویت و مجوز بین سرویس ها نیست.معایب:ناپایداری: یک معماری یکپارچه می تواند ناپایدار باشد زیرا یک خطای کوچک در یک قسمت می تواند باعث از کار افتادن کل برنامه شود و تأثیر منفی بر تجربه کاربر بگذارد.مقیاس پذیری: مقیاس یک معماری یکپارچه می تواند دشوار باشد زیرا برای افزایش ظرفیت برنامه، باید کل واحد را روی سرورهای بیشتری توزیع کنیم و این می تواند هزینه ها و پیچیدگی ها را افزایش دهد.ناکارآمدی: یک معماری یکپارچه می تواند ناکارآمد باشد زیرا برای ایجاد تغییرات در برنامه، باید کل یکپارچه را دوباره کامپایل کرده و مجدداً مستقر کنیم و این می تواند سرعت و انعطاف پذیری توسعه را کاهش دهد.معماری ابر (cloud architecture)معماری ابر به مجموعه اجزا، فناوری‌ها و روش‌هایی اطلاق می‌شود که برای ایجاد محیطی به منظور محاسبات ابری به کار گرفته می‌شوند.اجزای اصلی معماری ابر عبارتند از:1. زیرساخت جلویی (Frontend) شامل:رابط کاربری، برنامه‌های کاربردی سمت کلاینت و دستگاه یا شبکه‌ای که کاربران از طریق آن با ابر تعامل می‌کنند.2. زیرساخت انتهایی (Backend) شامل:برنامه‌های کاربردی سرورسرویس‌های اصلی ارائه‌دهنده خدمات ابریمحیط مجازی‌سازی (Runtime) برای اجرای سرویس‌هاذخیره‌ساز ابری برای داده‌هازیرساخت سخت‌افزاری و نرم‌افزارینرم‌افزارهای مدیریت و امنیت3. مدل تحویل خدمات ابری (Cloud Service Model) شامل SaaS، PaaS و IaaS4. شبکه و ارتباطاتبنابراین اجزای معماری ابر، مجموعه لایه‌ها و سرویس‌هایی هستند که برای ایجاد زیرساختی به منظور محاسبات و ذخیره‌سازی ابری ضروری می‌باشند. معماری ابر نقشه راهی برای ترکیب بهینه منابع و قابلیت‌ها به منظور پاسخگویی به نیازهای کسب و کار در محیط ابری است.معماری ابری (Cloud Architecture) به این صورت عمل می‌کند:معماری ابری شامل اجزا و لایه‌های مختلفی است که با هم یک پلتفرم محاسبات ابری را فراهم می‌کنند تا کاربران بتوانند به صورت درخواستی به منابع و سرویس‌ها دسترسی داشته باشند.سمت Back-End شامل تمامی منابع و سرویس‌های ابری از جمله سرورها، ذخیره‌سازی، شبکه و برنامه‌های کاربردی است که توسط ارائه‌دهنده خدمات ابری فراهم می‌شود.Front-End شامل رابط کاربری و برنامه‌هایی است که کاربران از طریق آن‌ها با ابر تعامل می‌کنند.یک شبکه، Back-End و Front-End را به هم متصل می‌کند تا داده‌ها بین آن‌ها رد و بدل شود.هنگامی که کاربران از طریق Front-End، درخواستی ارسال می‌کنند، این درخواست‌ها از طریق Middleware به Back-Endفرستاده می‌شود و سرویس‌ مورد نظر، وظیفه یا درخواست را انجام می‌دهد.انواع مدل‌های سرویس‌دهی ابری عبارتند از: IaaS، PaaS، SaaSکه هرکدام بسته به نوع نیازهای سازمانی مناسب هستند.امکاناتی مانند مجازی‌سازی، ابزارهای مدیریت و نظارت، و الگوهای خودکارسازی نیز بخشی از معماری ابری به شمار می‌روند.در معماری ابری، ابزارها و تکنولوژی‌های خاص نقش حیاتی در بهبود کارایی، انعطاف‌پذیری و مدیریت منابع ایفا می‌کنند:· کانتینرها: کانتینرها، مانند Docker، امکان بسته‌بندی برنامه‌ها و وابستگی‌های آن‌ها در یک محفظه قابل حمل را فراهم می‌آورند، که اجرای آن‌ها در محیط‌های مختلف را آسان‌تر می‌سازد.· سرویس‌های بدون سرور (Serverless): فناوری‌های بدون سرور به توسعه‌دهندگان اجازه می‌دهند تا برنامه‌هایی بسازند و اجرا کنند بدون نیاز به مدیریت سرورها، که به خودی خود مدیریت منابع و مقیاس‌بندی را بهینه می‌کند.· ابزارهای مدیریت و نظارت: ابزارهایی مانند Kubernetes برای مدیریت کلانشهرهای کانتینری، Prometheus برای نظارت و Grafana برای داشبورد و تجزیه و تحلیل داده‌ها، به شناسایی و رفع خطاها و بهبود عملکرد کمک می‌کنند.این تکنولوژی‌ها با هم کار می‌کنند تا محیطی انعطاف‌پذیر، قابل مدیریت و کارا در معماری ابری ایجاد کنند، که به سازمان‌ها اجازه می‌دهد به سرعت به نیازهای تغییریافته پاسخ دهند.در معماری‌های ابری، امنیت یکی از حیاتی‌ترین جنبه‌ها است که شامل مجموعه‌ای از رویکردها و بهترین شیوه‌ها برای حفاظت از داده‌ها، برنامه‌ها و زیرساخت‌ها در برابر تهدیدهای امنیتی می‌شود. این رویکردها شامل رمزنگاری داده‌ها برای اطمینان از امنیت اطلاعات در حین انتقال و ذخیره‌سازی و مدیریت هویت و دسترسی است تا تضمین شود که فقط کاربران مجاز قادر به دسترسی به منابع هستند. استفاده از سیاست‌های امنیتی محکم، نظارت مداوم بر ترافیک شبکه و تجزیه و تحلیل رفتاری برای شناسایی الگوهای مشکوک نیز بخشی از این رویکردها است.تأثیرات زیست‌محیطی معماری‌های ابری : این تأثیرات می‌توانند شامل مصرف انرژی، انتشار گازهای گلخانه‌ای، و استفاده از منابع طبیعی باشند. رویکردهای سبز در طراحی زیرساخت ابری، مانند بهینه‌سازی مصرف انرژی در مراکز داده، استفاده از انرژی‌های تجدیدپذیر، و بهبود کارایی سیستم‌های خنک‌کننده، به کاهش این تأثیرات کمک می‌کنند. هدف از این رویکردها کاهش اثرات منفی بر محیط زیست ضمن حفظ کارایی و قابلیت اطمینان سرویس‌های ابری است.انواع اصلی معماری ابری عبارتند از:1. معماری ابر عمومی (Public Cloud Architecture)در این معماری، منابع و زیرساخت محاسبات ابری توسط یک ارائه‌دهنده خدمات ابری عمومی تأمین و مدیریت می‌شود. معماری ابر عمومی به راحتی امکان مقیاس‌پذیری را فراهم می‌کند اما منابع به اشتراک گذاشته می‌شوند.2. معماری ابر خصوصی (Private Cloud Architecture)ابر خصوصی به ابری اطلاق می‌شود که توسط سازمانی به طور اختصاصی میزبانی و مدیریت می‌شود. این نوع معماری امکان کنترل بیشتر بر منابع و امنیت بالاتری را فراهم می‌کند اما هزینه‌برتر است.3. معماری ابر ترکیبی (Hybrid Cloud Architecture)در معماری ترکیبی از مزایای هر دو مدل ابر عمومی و خصوصی بهره گرفته می‌شود. این مدل انعطاف‌پذیری بالایی دارد.4. معماری چند ابری (Multi Cloud Architecture)در این معماری از چندین ارائه‌دهنده مختلف خدمات ابری عمومی استفاده می‌شود. مزیت اصلی آن انعطاف‌پذیری بالا و جلوگیری از وابستگی به یک ارائه‌دهنده خاص است.مهمترین مزایای معماری ابری (Cloud Architecture) به شرح زیر می‌باشند:1. کاهش هزینه‌های سرمایه‌ای اولیه2. افزایش سرعت به بازار و راه‌اندازی سریع‌تر خدمات3. انعطاف‌پذیری و مقیاس‌پذیری بالا4. تسریع تحول دیجیتال و مدرن‌سازی5. امکان بهره‌مندی از جدیدترین فناوری‌ها6. افزایش دسترس‌پذیری و قابلیت اطمینان7. بهبود امنیت اطلاعاتدر مجموع، معماری ابری باعث کاهش هزینه‌ها، تسریع ارائه محصولات و سرویس‌ها، و بهبود تجربه کاربری می‌شود و پاسخگویی سازمان‌ها به تغییرات را افزایش می‌دهد.چالش‌ها و محدودیت‌های معماری ابری شامل موارد زیر می‌شود:1. امنیت و حفظ حریم خصوصی: اطمینان از امنیت داده‌ها و برنامه‌ها در محیط ابری چالش‌برانگیز است.2. مدیریت هزینه: کنترل هزینه‌ها در محیط‌های ابری، به خصوص با مدل پرداخت بر اساس مصرف، دشوار است.3. پیچیدگی مدیریت: مدیریت و نظارت بر منابع ابری می‌تواند پیچیده باشد، به ویژه در محیط‌های چند ابری.4. قابلیت اطمینان و عملکرد: تضمین عملکرد و در دسترس بودن مداوم خدمات در سطح جهانی می‌تواند چالش‌برانگیز باشد.5. وابستگی به ارائه‌دهنده خدمات: وجود وابستگی شدید به ارائه‌دهنده‌های خدمات ابری می‌تواند ریسک‌هایی ایجاد کند.6. انتقال و مهاجرت داده‌ها: انتقال داده‌ها و برنامه‌ها به ابر و بین ابرهای مختلف می‌تواند پیچیده و هزینه‌بر باشد.7. مسائل قانونی و مقرراتی: رعایت قوانین و مقررات مربوط به داده‌ها در مناطق جغرافیایی مختلف می‌تواند محدودکننده باشد.معماری میکرو سرویس معماری میکروسرویس، یک رویکرد مدرن در توسعه نرم‌افزار است که در آن برنامه‌های کاربردی به مجموعه‌ای از خدمات مستقل و کوچک تقسیم می‌شوند. این سرویس‌ها می‌توانند به طور مستقل توسعه و استقرار یابند و از طریقAPIهای کاملاً تعریف‌شده با یکدیگر ارتباط برقرار کنند، که این امر بویژه در سازمان‌های بزرگ و پیچیده با چندین تیم توسعه مستقل مفید است. معماری میکروسرویس، که سبک خاصی از معماری نرم افزار و مشتق شده از معماری سرویس‌گرا (SOA) است، هدفش ارتقاء خودمختاری بالای سرویس‌ها از نظر منطق کارکردی-داده‌ای و نیز پلتفرم پیاده‌سازی و اجرا است. این سبک معماری علاوه بر استفاده از مفاهیم معماری سرویس‌گرا، از مفاهیم معماری رخدادمحور و سیستم‌های توزیع‌شده نیز بهره می‌برد.مشخصه‌های اصلی معماری میکروسرویس شامل خودگردانی و تخصصی بودن هر سرویس است. هر سرویس بر حل یک مشکل خاص تمرکز دارد و می‌تواند بدون تأثیر بر عملکرد سایر سرویس‌ها مستقلانه توسعه یابد. این امر به چابکی، مقیاس‌پذیری منعطف و استقرار آسان سیستم کمک می‌کند.معماری میکروسرویس در چند سال اخیر به شدت در حال گسترش و فراگیری در میان توسعه‌دهندگان و معماران است. اگرچه اولین اشاره مستقیم به واژه "میکروسرویس‌ها" به سال 2011 و در یک کارگاه معماری نرم‌افزار برمی‌گردد، اما این موضوع در طی سال‌های 2014 و 2015 داغ شد و هم اکنون میکروسرویس‌ها به عنوان یکی از موضوعات جذاب در دنیای نرم‌افزار و معماری محسوب می‌شوند. هر ماه مقالات، کتاب‌ها و ارائه‌های جدیدی از آن منتشر می‌شود و در کنفرانس‌ها یا سمینارهای تجاری-علمی نیز علاقه‌مندان زیادی را به خود جذب می‌کند. بر اساس گزارش‌های گوگل از میزان رشد جستجوی عبارات مرتبط با میکروسرویس، نقش محوری آن در معماری و توسعه سیستم‌ها مشخص است. تاریخچه معماری میکروسرویس‌ها به اوایل دهه 2000 بازمی‌گردد، زمانی که تعدادی از شرکت‌های پیشرو در صنعت نرم‌افزار شروع به اکتشاف و پیاده‌سازی این مدل کردند. این رویکرد به عنوان یک راه‌حل به چالش‌های موجود در معماری‌هایmonolithic (یکپارچه) ظهور یافت، که در آن‌ها تغییرات و مقیاس‌پذیری به سختی صورت می‌گرفت. با افزایش نیاز به انعطاف‌پذیری، توسعه سریع‌تر و استقلال بیشتر بین تیم‌های توسعه، معماری میکروسرویس‌ها به تدریج به عنوان یک رویکرد مطلوب در نظر گرفته شد.از نظر داخلی، معماری میکروسرویس‌ها به شکلی طراحی می‌شود که هر سرویس به صورت مستقل عمل کند و برای حل یک مشکل خاص یا ارائه یک قابلیت مشخص طراحی شده باشد. هر سرویس می‌تواند به طور جداگانه توسعه یابد، آزمایش شود و مقیاس‌پذیری داشته باشد، و از طریق API‌های تعریف‌شده با سایر سرویس‌ها ارتباط برقرار کند. این اجزاء مانند کانتینرها یا ماشین های مجازی، مستقل به طور معمول در محیط‌هایی که از نظر شبکه‌ای از هم جدا هستند اجرا می‌شوند.مشخصه‌های اصلی معماری میکروسرویس شامل خودگردانی و تخصصی بودن هر سرویس است. هر سرویس بر حل یک مشکل خاص تمرکز دارد و می‌تواند بدون تأثیر بر عملکرد سایر سرویس‌ها مستقلانه توسعه یابد. این امر به چابکی، مقیاس‌پذیری منعطف و استقرار آسان سیستم کمک می‌کند.در شکل زیر نمونه ای از عناصر یک سیستم ساده فروش اینترنتی مبتنی بر معماری میکروسرویس نشان داده شده استمزایای استفاده از معماری میکروسرویس عبارت‌اند از:- چابکی در توسعه و استقرار، به دلیل اینکه تیم‌ها می‌توانند مستقل و سریع‌تر کار کنند.- مقیاس‌پذیری منعطف که به هر سرویس اجازه می‌دهد به صورت مستقل مقیاس‌پذیر شود.- استقرار آسان و کاهش هزینه‌های مرتبط با اشتباهات توسعه.با این حال، معماری میکروسرویس هم محدودیت‌هایی دارد. برخی از محدودیت‌های آن شامل کندی عملکرد به دلیل ارتباطات شبکه‌ای بین سرویس‌ها، افزایش احتمال آسیب‌های امنیتی و پیچیدگی‌های بیشتر در توسعه سرویس‌هایی که با یکدیگر در بستر شبکه ارتباط برقرار می‌کنند است.در مقایسه، معماری Monolithic، که رویکرد سنتی‌تری در توسعه نرم‌افزار است، کل برنامه را به عنوان یک واحد واحد اجرا می‌کند و تمامی اجزای سیستم را بر اساس یک زبان برنامه‌نویسی و یک فریم‌ورک مشخص می‌نویسد. چک کوچکی. این معماری محدودیت‌های خاص خود را دارد، از جمله نیاز به Build و Deployمجدد کل برنامه برای هر تغییر کوچکی که انجام می‌شود. این امر می‌تواند باعث افزایش زمان و هزینه‌های توسعه شود و در مواردی که تغییرات سریع و مکرر مورد نیاز است، مشکل‌ساز باشد. علاوه بر این، در معماری Monolithic، اگر یک بخش از سیستم دچار خطا شود، این امر می‌تواند تأثیر منفی بر کل سیستم داشته باشد، چرا که تمامی اجزا به هم مرتبط و وابسته هستند. این موضوع، به ویژه در سیستم‌های بزرگ و پیچیده، مدیریت خطا و نگهداری را دشوار می‌کند.به طور مقابل، معماری میکروسرویس‌ها به طور طبیعی مشکلات مربوط به مقیاس‌پذیری و انعطاف‌پذیری را که در معماری‌های Monolithicمشاهده می‌شود، حل می‌کند. به دلیل اینکه هر سرویس به صورت مستقل عمل می‌کند و تنها از طریق APIها با دیگر سرویس‌ها ارتباط برقرار می‌کند، توسعه، آزمایش و استقرار سرویس‌ها به صورت مجزا و سریع‌تر انجام می‌گیرد. این امر به تیم‌های توسعه اجازه می‌دهد تا به صورت مستقل و چابک‌تر عمل کنند، و در نتیجه به سازمان‌ها کمک می‌کند تا به سرعت به تغییرات بازار و نیازهای کاربران پاسخ دهند.قانون دو پیتزا قانون Two-Pizza Teams ایجاد تیم های کوچک و مستقل تشکیل شده است که می توانند با دو پیتزا تغذیه سیر شوند. ایده کاهش پیچیدگی، سربار و هزینه های ارتباطی تیم های بزرگ و وابسته به یکدیگر و افزایش چابکی، کارایی و نوآوری توسعه نرم افزار است.تاریخچه Two-Pizza Teams از بنیانگذار و مدیر عامل آمازون جف بزوس می‌آید که این قانون را در روزهای اولیه این شرکت وضع کرد. او می‌خواست از مشکلات بوروکراسی، تفکر گروهی و تصمیم‌گیری کند که اغلب سازمان‌های بزرگ را گرفتار می‌کند اجتناب کند و فرهنگ مالکیت، مسئولیت‌پذیری و وسواس مشتری را در میان کارمندان خود تقویت کند. او همچنین می خواست از مفهوم قانون کانوی استفاده کند که بیان می کند ساختار یک سیستم نرم افزاری ساختار سازمانی را که آن را تولید می کند منعکس می کند. هدف او با ایجاد تیم های کوچک و مستقل، ایجاد سیستم های نرم افزاری ماژولار و مقیاس پذیر بود.یکی از نمونه‌هایی که چگونه Two-Pizza Teamsدر آمازون کار می‌کنند، توسعه AWS، پلتفرم رایانش ابری است که بسیاری از خدمات اینترنت را تامین می‌کند. AWS به عنوان یک پروژه داخلی برای استانداردسازی و ساده‌سازی راه ارتباط تیم‌های مختلف در آمازون و دسترسی به منابع مشترک شرکت آغاز شد. آمازون با ایجاد سرویس‌های کوچک و مستقلی که APIهای تعریف شده را در معرض دید قرار می‌داد، توانست وابستگی‌ها و تنگناهای بین تیم‌ها را کاهش دهد و امکان تحویل سریع‌تر و مکرر ویژگی‌ها و به‌روزرسانی‌ها را فراهم کند. بعداً آمازون متوجه شد که این خدمات می تواند به مشتریان خارجی نیز ارائه شود و به این ترتیب AWS متولد شد.تیم‌های دو پیتزا نه تنها توسط آمازون، بلکه توسط شرکت‌های دیگری که می‌خواهند رویکردی چابک‌تر و مشتری‌محورتر برای توسعه نرم‌افزار اتخاذ کنند، استفاده می‌شوند.برخی از مزایای تیم های دو پیتزا عبارتند از:· آنها تحویل سریع‌تر و مکرر ویژگی‌ها و به‌روزرسانی‌ها را امکان‌پذیر می‌کنند، زیرا هر تیم می‌تواند به طور مستقل توسعه، آزمایش و استقرار کند.· آنها مقیاس پذیری و عملکرد سیستم نرم افزار را افزایش می دهند، زیرا هر سرویس را می توان با توجه به تقاضا و در دسترس بودن منابع، کوچک یا بزرگ کرد.· آنها تحمل خطا و انعطاف‌پذیری سیستم نرم‌افزاری را بهبود می‌بخشند، زیرا هر سرویس را می‌توان جدا کرد و از خرابی‌ها بدون تأثیر بر کل سیستم بازیابی کرد.· آنها از تنوع و تکامل پشته فناوری پشتیبانی می کنند، زیرا هر تیم می تواند از زبان ها، چارچوب ها و ابزارهای مختلف استفاده کند.برخی از چالش های تیم های دو پیتزا عبارتند از:· آن‌ها پیچیدگی و سربار طراحی سیستم را افزایش می‌دهند، زیرا نیاز به برنامه‌ریزی دقیق و هماهنگی تجزیه، ارتباطات، یکپارچه‌سازی و استقرار سرویس دارند.· آن‌ها خطر تأخیر و شکست شبکه را معرفی می‌کنند، زیرا ارتباطات بین سرویس به قابلیت اطمینان و در دسترس بودن شبکه بستگی دارد.· آن‌ها نیاز به تست و استراتژی‌های نظارتی پیچیده‌تری دارند، زیرا شامل چندین سرویس توزیع شده و پویا هستند که با یکدیگر تعامل دارند.· آن‌ها خواستار قابلیت‌های عملیاتی و حاکمیتی بیشتری هستند، زیرا شامل مدیریت امنیت، پیکربندی، نسخه‌سازی و مستندسازی سرویس‌ها می‌شود.مقایسه معماری ها : در ادامه به مقایسه انواع معماری ها میپردازیم :مدیریت پیچیدگی: در معماری مونولیتیک، پیچیدگی برنامه با رشد آن افزایش می‌یابد و مدیریت آن سخت‌تر می‌شود. در معماری میکروسرویس، پیچیدگی برنامه به چندین سرویس کوچک و مستقل تقسیم می‌شود و مدیریت آن آسان‌تر می‌شود. در معماری یونیکرنل، پیچیدگی برنامه به اندازه‌ی متوسط است، زیرا هر برنامه به صورت یک کرنل مستقل اجرا می‌شود و نیازی به سیستم عامل ندارد. در معماری ابری، پیچیدگی برنامه به حداقل می‌رسد، زیرا برنامه‌ها به صورت سرویس‌های آماده‌ی ابری ارائه می‌شوند و نیازی به مدیریت زیرساخت ندارند.توانایی تغییر: در معماری مونولیتیک، تغییر در یک بخش از برنامه ممکن است تأثیر منفی بر سایر بخش‌ها داشته باشد و نیاز به کامپایل و استقرار مجدد کل برنامه داشته باشد. در معماری میکروسرویس، تغییر در یک سرویس مستقل از سایر سرویس‌ها است و نیاز به کامپایل و استقرار مجدد فقط آن سرویس دارد. در معماری یونیکرنل، تغییر در یک برنامه مستقل از سایر برنامه‌ها است و نیاز به کامپایل و استقرار مجدد فقط آن برنامه دارد. در معماری ابری، تغییر در یک سرویس ابری مستقل از سایر سرویس‌های ابری است و نیاز به کامپایل و استقرار مجدد فقط آن سرویس دارد.توانایی تست: در معماری مونولیتیک، تست کل برنامه به صورت یکپارچه انجام می‌شود و نیاز به تست هماهنگی بین اجزاء دارد. در معماری میکروسرویس، تست هر سرویس به صورت جداگانه انجام می‌شود و نیاز به تست هماهنگی بین سرویس‌ها دارد. در معماری یونیکرنل، تست هر برنامه به صورت جداگانه انجام می‌شود و نیاز به تست هماهنگی بین برنامه‌ها دارد. در معماری ابری، تست هر سرویس ابری به صورت جداگانه انجام می‌شود و نیاز به تست هماهنگی بین سرویس‌های ابری دارد .توانایی بازیابی: در معماری مونولیتیک، بازیابی از خطاها و اشکالات سخت‌تر است، زیرا هر خطا ممکن است کل برنامه را متوقف کند و نیاز به راه‌اندازی مجدد کل برنامه داشته باشد. در معماری میکروسرویس، بازیابی از خطاها و اشکالات آسان‌تر است، زیرا هر خطا فقط یک سرویس را متوقف می‌کند و نیاز به راه‌اندازی مجدد فقط آن سرویس دارد. در معماری یونیکرنل، بازیابی از خطاها و اشکالات متوسط است، زیرا هر خطا فقط یک برنامه را متوقف می‌کند و نیاز به راه‌اندازی مجدد فقط آن برنامه دارد. در معماری ابری، بازیابی از خطاها و اشکالات آسان‌تر است، زیرا هر خطا فقط یک سرویس ابری را متوقف می‌کند و نیاز به راه‌اندازی مجدد فقط آن سرویس دارد.نتفلیکسنتفلیکس در سال 1997 توسط رید هستینگز و مارک رندولف تأسیس شد. آنها ابتدا یک شرکت اجاره فیلم آنلاین به نام Pure Softwareداشتند که به مشتریان اجازه می‌داد فیلم‌ها را به صورت آنلاین اجاره کنند و DVDها را از طریق پست دریافت نمایند.در سال 1998، آنها مدل کسب و کار خود را به یک سرویس اشتراک ماهانه تغییر دادند که به مشتریان اجازه می‌داد به طور نامحدود فیلم‌ها را به صورت آنلاین مشاهده کنند. این مدل کسب و کار جدید بسیار موفق بود.در سال 1999، آنها نام شرکت را از Pure Software به نتفلیکس تغییر دادند. در ابتدا، محتوای نتفلیکس محدود به فیلم‌های دسته دوم بود اما به مرور زمان شروع به اضافه کردن محتوای اختصاصی و محبوب‌تر کردند.نتفلیکس در سال 2007 خدمات استریم ویدیو را راه‌اندازی کرد که به کاربران اجازه می‌داد محتوا را بدون نیاز به دانلود مستقیماً مشاهده کنند. همچنین، شروع به تولید محتوای اختصاصی خود مثل سریال ها و فیلم‌ها کردند.تا سال 2010، نتفلیکس به 20 میلیون مشترک در سراسر جهان دست یافت. در طی سال‌های بعدی نیز به رشد خود ادامه داد و در حال حاضر با بیش از 220 میلیون مشترک، بزرگترین سرویس استریم ویدیو در جهان محسوب می‌شود.نتفلیکس همچنان به سرمایه‌گذاری روی محتوای اختصاصی و بهبود تجربه کاربری ادامه می‌دهد و یکی از موفق‌ترین شرکت‌های فناوری در سراسر جهان به شمار می‌رود.معماری نتفلیکسدر دنیای خدمات پخش زنده، نتفلیکس همچون یک انحصار، میلیون‌ها بیننده را در سراسر جهان با کتابخانه‌ای عظیم از محتوا که به طور بی‌درنگ به صفحه‌هایی با اندازه‌های مختلف تحویل داده می‌شود، مجذوب خود کرده است. پشت این تجربه به ظاهر بی‌زحمت، یک طراحی سیستم دقیق و زیبا نهفته است. در این مقاله، ما طراحی سیستم نتفلیکس را مورد بررسی قرار خواهیم داد.الزامات طراحی سیستم نتفلیکسالزامات کارکردی (Functional Requirements)· کاربران باید بتوانند حساب‌های کاربری ایجاد کنند، وارد شوند و خارج شوند.· مدیریت اشتراک برای کاربران.· اجازه به کاربران برای پخش ویدئو و قابلیت‌های مکث، پخش، بازگردانی و پیش‌رفت سریع.· قابلیت دانلود محتوا برای تماشای آفلاین.· توصیه محتوای شخصی‌سازی شده بر اساس ترجیحات کاربر و تاریخچه تماشا.الزامات غیرکارکردی(Non-Functional Requirements)· کمترین تأخیر و بالاترین پاسخ‌دهی هنگام پخش محتوا.· قابلیت مقیاس‌پذیری برای پشتیبانی از تعداد زیادی کاربر همزمان.· در دسترس بودن بالا با حداقل زمان توقف.· احراز هویت و اجازه دسترسی امن برای کاربران.· رابط کاربری شهودی برای ناوبری آسان.طراحی سطح بالای سیستم نتفلیکساین شرکت دسته‌بندی‌های بزرگی از فیلم‌ها و محتوای تلویزیونی را مدیریت می‌کند و کاربران برای دسترسی به این محتواها، اجاره ماهانه پرداخت می‌کنند. نتفلیکس بیش از 180 میلیون مشترک در بیش از 200 کشور دارد.نتفلیکس بر روی دو ابر (Cloud) کار می‌کند: AWS و Open Connect. این دو ابر به عنوان ستون فقرات نتفلیکس عمل می‌کنند و هر دو در ارائه بهترین ویدئو به مشترکین بسیار مؤثر هستند.نتفلیکس به طور عمده از 3 جزء تشکیل شده است:1. مشتری:دستگاه (رابط کاربری) که برای جستجو و پخش ویدیوهای نتفلیکس استفاده می‌شود. تلویزیون، ایکس‌باکس، لپ‌تاپ یا تلفن همراه و غیره.2. OC (Open Connect) یا CDN نتفلیکس:CDN شبکه‌ای از سرورهای توزیع‌شده در مکان‌های جغرافیایی مختلف است، و Open Connect CDN جهانی سفارشی خود نتفلیکس است.هر چیزی که شامل پخش ویدئو می‌شود را مدیریت می‌کند.این شبکه در مکان‌های مختلف توزیع شده است و هنگامی که دکمه پخش را فشار می‌دهید، ویدئو از این جزء به دستگاه شما پخش می‌شود.بنابراین، اگر سعی کنید ویدئو را در آمریکای شمالی پخش کنید، ویدئو از نزدیک‌ترین Open Connect (یا سرور) به جای سرور اصلی ارائه می‌شود (پاسخ سریع‌تر از نزدیک‌ترین سرور).پشتیبانی (دیتابیس):این بخش همه چیزهایی را که شامل پخش ویدئو نمی‌شود (پیش از فشار دادن دکمه پخش) مانند پذیرش محتوای جدید، پردازش ویدئوها، توزیع آن‌ها به سرورهای واقع در نقاط مختلف جهان و مدیریت ترافیک شبکه را مدیریت می‌کند.بیشتر فرآیندها توسط سرویس‌های وب آمازون (AWS) مدیریت می‌شوند.معماری میکروسرویس‌های نتفلیکسقبل از معماری میکروسرویس، مثل اکثر سیستم‌ها از معماری‌های مونولیتیک یا Monolithic استفاده می‌کردند که در آنها تمام کامپوننت‌های مورد نیاز یک برنامه درون یک پروسه یا سرویس واحد قرار دارد. به معماری مونولوتیک قبلا به صورت مفصل پرداخته شده که از تکرار مکررات اجتناب میکنیم.سبک معماری نتفلیکس به صورت مجموعه‌ای از سرویس‌ها ساخته شده است. (که در بخش اول در مورد معماری میکروسرویس صحبت کردیم.) تمام API‌های مورد نیاز برای برنامه‌ها و وب‌اپ‌ها را تامین می‌کند. زمانی که درخواستی در نقطه پایانی (endpoint) دریافت می‌شود، این نقطه پایانی دیگر میکروسرویس‌ها را برای داده‌های مورد نیاز فرا می‌خواند و این میکروسرویس‌ها نیز ممکن است داده‌ها را از میکروسرویس‌های دیگری درخواست کنند. پس از آن، پاسخ کامل برای درخواست API به نقطه پایانی فرستاده می‌شود.در این معماری، سرویس‌ها باید از یکدیگر مستقل باشند. به عنوان مثال، سرویس ذخیره‌سازی ویدئو باید از سرویس مسئول تبدیل فرمت ویدئوها، جدا باشد.نتفلیکس چطور معماری میکروسرویس را قابل اعتماد کرد؟نتفلیکس برای قابل اعتماد کردن معماری میکروسرویس خود، چندین رویکرد و ابزار پیشرفته را به کار گرفته است. این اقدامات شامل موارد زیر است:1. استفاده از Hystrix برای مدیریت شکست‌هاHystrix یک کتابخانه مدارشکن ایجاد شده توسط نتفلیکس است که به میکروسرویس‌ها اجازه می‌دهد تا در مواجهه با خطاها، به صورت مقاوم عمل کنند. این ابزار به سرویس‌ها کمک می‌کند تا در زمان خرابی‌ها، ترافیک را به روش‌های پیش‌فرض یا فال‌بک هدایت کنند، کاهش زمان توقف و افزایش قابلیت اطمینان سیستم.2. جداسازی میکروسرویس‌های حیاتینتفلیکس برخی از سرویس‌های حیاتی را جدا می‌کند و آن‌ها را کمتر وابسته یا کاملاً مستقل از دیگر سرویس‌ها می‌سازد. این کار به کاهش تاثیر زنجیره‌ای خرابی‌ها کمک می‌کند و اطمینان حاصل می‌شود که حتی در صورت خرابی بخشی از سیستم، بخش‌های حیاتی همچنان قابل دسترسی باشند.3. اتخاذ رویکرد سرورهای بی‌حالتنتفلیکس سرورها را به گونه‌ای طراحی کرده است که هر یک از آن‌ها می‌توانند بدون نیاز به حفظ حالت خاصی، درخواست‌ها را پاسخ دهند. این رویکرد امکان می‌دهد که در صورت بروز خطا در یک سرور، به راحتی و بدون اختلال در تجربه کاربری، درخواست‌ها را به سرور دیگری منتقل کنند.4. مقیاس‌پذیری ابری و استفاده از AWSبا استفاده از زیرساخت ابری آمازون وب سرویس‌ها (AWS)، نتفلیکس از مزایای مقیاس‌پذیری، انعطاف‌پذیری و قابلیت اطمینان بالا بهره‌مند می‌شود. این زیرساخت ابری به نتفلیکس امکان می‌دهد تا منابع خود را بر اساس نیاز فوری افزایش یا کاهش دهد.5. مانیتورینگ و لاگ‌گیری پیشرفتهنتفلیکس از ابزارهای مانیتورینگ و لاگ‌گیری پیشرفته استفاده می‌کند تا بتواند عملکرد سیستم و میکروسرویس‌های خود را به طور مداوم زیر نظر داشته باشد. این امکان به تیم‌های مهندسی اجازه می‌دهد تا به سرعت مشکلات را شناسایی و رفع کنند.6. Chaos Engineeringنتفلیکس پیشرو در استفاده از Chaos Engineering است، یک رویکرد آزمایشی که به طور عمدی شرایط خرابی را در محیط تولید ایجاد می‌کند تا اطمینان حاصل شود که سیستم قادر به تحمل خرابی‌ها و بازیابی از آن‌ها است.با ترکیب این رویکردها و ابزارها، نتفلیکس توانسته است معماری میکروسرویس خود را به یکی از قابل اعتمادترین و مقیاس‌پذیرترین سیستم‌ها در صنعت پخش زنده تبدیل کند.نحوه نمایش ویدیو بر روی انواع دستگاه ها:نتفلیکس بیش از 2200 دستگاه را پشتیبانی می‌کند و هر یک از آن‌ها نیازمند رزولوشن‌ها و فرمت‌های مختلفی است. برای قابل مشاهده کردن ویدئوها بر روی دستگاه‌های مختلف، نتفلیکس عملیات ترنسکودینگ یا انکودینگ را انجام می‌دهد، که شامل یافتن خطاها و تبدیل ویدئوی اصلی به فرمت‌ها و رزولوشن‌های مختلف است.فرآیند ترنسکودینگ (transcoding):1. تجزیه و تحلیل ویدئوی اصلی: ابتدا، ویدئوی اصلی تجزیه و تحلیل می‌شود تا خطاهای احتمالی شناسایی و اصلاح شوند.2. انتخاب فرمت‌ها و رزولوشن‌ها: بر اساس دستگاه‌های پشتیبانی شده، نتفلیکس فرمت‌ها و رزولوشن‌های مختلفی را برای ویدئو تعیین می‌کند. این انتخاب شامل فرمت‌های استاندارد برای تلویزیون‌ها، رایانه‌های شخصی، تبلت‌ها و تلفن‌های همراه است.3. انکودینگ ویدئو: سپس، ویدئوی اصلی به فرمت‌ها و رزولوشن‌های مختلف انکود می‌شود. این فرآیند شامل فشرده‌سازی ویدئو برای اطمینان از کاهش حجم داده‌ها بدون از دست دادن کیفیت قابل توجه است.4. ذخیره‌سازی و توزیع: پس از انکودینگ، ورژن‌های مختلف ویدئو در سرورهای نتفلیکس ذخیره می‌شوند. این سرورها بخشی از شبکه تحویل محتوای (CDN) نتفلیکس هستند، که توزیع موثر ویدئوها به کاربران در سراسر جهان را تضمین می‌کند.5. پخش بهینه: هنگامی که کاربر درخواست پخش ویدئویی را می‌دهد، نتفلیکس به طور خودکار بهترین ورژن ویدئو را بر اساس پهنای باند و دستگاه کاربر انتخاب می‌کند. این اطمینان حاصل می‌کند که کاربران تجربه پخش بهینه‌ای داشته باشند، حتی در شرایط پهنای باند محدود.با این رویکرد، نتفلیکس تضمین می‌کند که کاربران در هر دستگاهی، با هر سرعت اینترنتی، تجربه تماشای ویدئویی بی‌نظیری داشته باشند، و همزمان، بهره‌وری شبکه و زیرساخت‌های خود را بهینه سازد.بهینه سازی فایل ها در نتفلیکسنتفلیکس همچنین بهینه‌سازی فایل‌ها را برای سرعت‌های مختلف شبکه انجام می‌دهد. کیفیت یک ویدئو زمانی خوب است که شما ویدئو را با سرعت بالای شبکه تماشا می‌کنید. نتفلیکس چندین نسخه مشابه (تقریباً 1100-1200) برای همان فیلم با رزولوشن‌های مختلف ایجاد می‌کند.این نسخه‌ها نیاز به مقدار زیادی ترنسکودینگ و پیش‌پردازش دارند. نتفلیکس ویدئوی اصلی را به چندین قطعه کوچکتر تقسیم می‌کند و با استفاده از کارگرهای موازی در AWS، این قطعات را به فرمت‌های مختلف (مانند mp4، 3gp و غیره) در رزولوشن‌های متفاوت (مانند 4k،1080P و بیشتر) تبدیل می‌کند. پس از ترنسکودینگ، زمانی که چندین نسخه از فایل‌ها برای همان فیلم وجود دارد، این فایل‌ها به تمام سرورهای Open Connectکه در مکان‌های مختلفی در سراسر جهان قرار دارند، منتقل می‌شوند.در زیر فرآیند گام به گام نحوه اطمینان نتفلیکس از کیفیت پخش بهینه آورده شده است:· زمانی که کاربر اپلیکیشن نتفلیکس را بر روی دستگاه خود بارگذاری می‌کند، ابتدا نمونه‌های AWS وارد عمل می‌شوند و برخی وظایف مانند ورود به سیستم، توصیه‌ها، جستجو، تاریخچه کاربر، صفحه اصلی، صورت‌حساب، پشتیبانی مشتری و غیره را انجام می‌دهند.· پس از آن، زمانی که کاربر دکمه پخش را بر روی یک ویدئو فشار می‌دهد، نتفلیکس سرعت شبکه یا ثبات اتصال را تجزیه و تحلیل می‌کند و سپس بهترین سرور Open Connect نزدیک به کاربر را پیدا می‌کند.· بسته به دستگاه و اندازه صفحه نمایش، فرمت ویدئوی مناسب به دستگاه کاربر پخش می‌شود. هنگام تماشای ویدئو، ممکن است متوجه شده باشید که ویدئو به صورت پیکسلی ظاهر می‌شود و پس از مدتی دوباره به HD بازمی‌گردد.· این اتفاق به این دلیل می‌افتد که برنامه به طور مداوم بهترین سرور Open Connect را برای پخش چک می‌کند و در صورت نیاز بین فرمت‌ها (برای بهترین تجربه تماشا) جابجا می‌شود.داده‌های کاربر مانند جستجوها، تماشاها، مکان، دستگاه، نظرات و پسندها در AWS ذخیره می‌شوند، نتفلیکس از این داده‌ها برای ساخت توصیه‌های فیلم برای کاربران با استفاده از مدل یادگیری ماشینی یا هادوپ استفاده می‌کند.مدیریت حجم ترافیک بالا در نتفلیکسمدیریت حجم ترافیک بالا در Netflixبه وسیله ابزارهای مختلفی انجام می‌شود. این ابزارها شامل موارد زیر هستند:1. Elastic Load Balancer (ELB): ELBوظیفه مسیریابی ترافیک به سرویس‌های جلویی را بر عهده دارد. ELBاز یک طرح دو مرحله‌ای برای توزین بار استفاده می‌کند. در مرحله اول، بار بین مناطق و سپس در مرحله دوم بین نمونه‌های سرویس توزیع می‌شود.2. ZUUL: ZUUL یک سرویس دروازه است که مسیریابی دینامیک، نظارت، انعطاف‌پذیری و امنیت را فراهم می‌کند. این سرویس امکان مسیریابی آسان بر اساس پارامترهای کوئری، URLو مسیر را به سرویس‌های مورد نیاز فراهم می‌کند.3. Hystrix: Hystrix برای کنترل تعاملات بین سرویس‌های توزیع شده استفاده می‌شود. این ابزار با افزودن منطق تحمل تأخیر و خطا، از تأخیر و خرابی سرویس‌ها جلوگیری می‌کند.4. EV Cache: برای بهبود عملکرد و سرعت دسترسی به داده‌ها، از لایه کش سفارشی با نام EV Cache استفاده می‌شود. این لایه کش بر اساس Memcachedعمل می‌کند و به جای سرور اصلی، از کش برای دسترسی به داده‌ها استفاده می‌شود.استفاده از این ابزارها در Netflixبهبود عملکرد سیستم، در دسترس بودن و قابلیت اطمینان را افزایش می‌دهد و به مدیریت بار ترافیک بالا کمک می‌کند.پردازش داده‌ها در نتفلیکس با استفاده از Kafka و Apache Chukwaنتفلیکس از Kafka و Apache Chukwa برای جمع‌آوری و پردازش داده‌ها استفاده می‌کند. این داده‌ها شامل گزارش خطا، فعالیت‌های رابط کاربری، رویدادهای عملکرد، فعالیت‌های تماشای ویدئو و رویدادهای عیب‌یابی و تشخیص هستند.Apache Chukwa یک سیستم جمع‌آوری داده‌های متن باز است که بر پایه HDFS و فریمورک MapReduce ساخته شده است. این سیستم قابلیت مقیاس‌پذیری و استحکام Hadoop را داراست و ابزارهای قدرتمندی برای نمایش، نظارت و تجزیه و تحلیل نتایج فراهم می‌کند.Chukwa رویدادها را از قسمت‌های مختلف سیستم جمع‌آوری می‌کند و می‌توان از آن برای نظارت و تجزیه و تحلیل استفاده کرد. این رویدادها در فرمت فایل توالی Hadoop (S3)نوشته می‌شوند و سپس تیم Big Data آن‌ها را در Hive در فرمت داده Parquet پردازش می‌کند.برای بارگذاری رویدادهای آنلاین به EMR/S3، Chukwa از Kafka استفاده می‌کند. Kafka نقش انتقال داده‌ها از Kafka جلویی به چاه‌های مختلف را داراست. مسیریابی پیام‌ها با استفاده از فریمورک Apache Samza انجام می‌شود.ترافیک ارسالی توسط Chukwa ممکن است جریان‌های کامل یا فیلترشده باشد، بنابراین ممکن است نیاز به اعمال فیلتر بیشتری بر روی جریان‌های Kafka باشد. به همین دلیل، استفاده از روتر می‌تواند به منظور انتقال از یک موضوع Kafka به موضوع Kafka دیگر مورد استفاده قرار گیرد.Elastic Searchدر سال‌های اخیر، استفاده از Elasticsearch در نتفلیکس رشد قابل توجهی داشته است. نتفلیکس حدود 150 خوشه Elasticsearch و 3500 میزبان با نمونه‌ها را به کار می‌برد. Elasticsearch در نتفلیکس برای مصورسازی داده‌ها، پشتیبانی مشتری و تشخیص خطاهای سیستم مورد استفاده قرار می‌گیرد.Apache Spark برای توصیه فیلمنتفلیکس از Apache Sparkو یادگیری ماشین برای توصیه فیلم استفاده می‌کند. وقتی شما صفحه اصلی را باز می‌کنید، مجموعه‌ای از ردیف‌های مختلف فیلم را مشاهده می‌کنید. نتفلیکس این ردیف‌ها را بر اساس داده‌های تاریخی و ترجیحات کاربران شخصی‌سازی می‌کند و تصمیم می‌گیرد کدام فیلم‌ها به کاربران نمایش داده شوند. همچنین، نتفلیکس برای کاربران خاص، مرتب‌سازی و رتبه‌بندی فیلم‌ها را بر اساس ارتباطات موجود در پلتفرم خود انجام می‌دهد. در اینجا نیز Apache Spark برای توصیه محتوا و شخصی‌سازی استفاده می‌شود.سیستم توصیه ویدئوسیستم توصیه نتفلیکس به کاربران کمک می‌کند تا محتوا یا ویدئوی مورد علاقه خود را کشف کنند. برای ساخت این سیستم، نتفلیکس باید علاقه کاربر را پیش‌بینی کند و اطلاعات مختلفی از کاربران جمع‌آوری کند، از جمله تاریخچه تماشا و امتیازدهی کاربر به عناوین دیگر، سلیقه‌ها و ترجیحات مشابه سایر اعضا، اطلاعات متادیتا از ویدئوهای قبلی که توسط کاربر تماشا شده اند، و دستگاه و زمان فعالیت کاربر. نتفلیکس از دو الگوریتم فیلترینگ همکارانه و فیلترینگ مبتنی بر محتوا برای ساخت سیستم توصیه استفاده می‌کند.طراحی پایگاه داده سیستم نتفلیکسنتفلیکس از دو پایگاه داده متفاوت یعنی MySQL (RDBMS) و Cassandra (NoSQL)برای اهداف مختلف استفاده می‌کند.EC2 Deployed MySQLنتفلیکس اطلاعات صورت‌حساب، اطلاعات کاربر و اطلاعات تراکنش را در پایگاه داده MySQL ذخیره می‌کند. برای رعایت استانداردهای ACID، نتفلیکس از تنظیمات master-master برای MySQL استفاده می‌کند و آن را بر روی نمونه‌های بزرگ EC2 آمازون با استفاده از InnoDB مستقر می‌کند.تنظیمات از "پروتکل همگام‌سازی تکرار" پیروی می‌کند. در این روش، اگر نویسنده نود اصلی مستر باشد، عملیات همچنین به نود مستر دیگر تکرار می‌شود و تأییدیه فقط در صورت تأیید نوشتار هر دو نود اصلی و دور ارسال می‌شود. این باعث می‌شود دسترسی به داده‌ها تضمین شود. همچنین نتفلیکس برای هر نود (محلی و منطقه‌ای) یک کپی خواندنی تنظیم کرده است که دسترسی بالا و قابلیت مقیاس‌پذیری را تضمین می‌کند.تمام پرس‌وجوهای خواندنی به کپی‌های خواندنی هدایت می‌شوند و تنها پرس‌وجوهای نوشتاری به نودهای مستر هدایت می‌شوند.در صورت خرابی نود مستر اصلی MySQL، نود مستر ثانویه نقش اصلی را به عهده می‌گیرد و ورودی route53 (پیکربندی DNS) برای پایگاه داده به این نود جدید اصلی تغییر می‌کند. این کار همچنین پرس‌وجوهای نوشتاری را به این نود مستر جدید اصلی هدایت می‌کند.CassandraCassandra یک پایگاه داده NoSQL است که می‌تواند مقادیر زیادی داده را مدیریت کند و همچنین می‌تواند نوشتن و خواندن سنگین را مدیریت کند. با افزایش تعداد کاربران در نتفلیکس، داده‌های تاریخچه تماشای هر عضو نیز افزایش یافت. این باعث افزایش تعداد کل داده‌های تاریخچه تماشا شد و مدیریت این حجم عظیم از داده‌ها برای نتفلیکس به چالش تبدیل شد.نتفلیکس برای ذخیره‌سازی داده‌های تاریخچه تماشا، دو هدف اصلی را در نظر گرفته است:· کاهش اثر پایین‌تر ذخیره‌سازی.· عملکرد یکنواخت خواندن/نوشتن با افزایش تماشای هر عضو (نسبت نوشتن به خواندن داده‌های تاریخچه تماشا در Cassandra حدود 9 به 1 است).نتفلیکس بیش از 50 خوشه Cassandra، بیش از 500 نود، بیش از 30 ترابایت پشتیبان‌گیری روزانه و بزرگ‌ترین خوشه با 72 نود دارد. هر خوشه بیش از 250K نوشتار در ثانیه را پشتیبانی می‌کند. ابتدا، تاریخچه تماشا در Cassandra در یک ردیف ذخیره می‌شد. با افزایش تعداد کاربران در نتفلیکس، اندازه ردیف‌ها و حجم داده‌ها افزایش یافت. این باعث افزایش حجم ذخیره‌سازی، هزینه عملیاتی بیشتر و کاهش عملکرد برنامه شد. راه‌حل این مشکل فشرده‌سازی ردیف‌های قدیمی بود.نتفلیکس داده‌ها را به دو بخش تقسیم کرد:· تاریخچه تماشای زنده (LiveVH): شامل تعداد کمی از داده‌های تاریخی تماشای اخیر کاربران با به‌روزرسانی‌های مکرر است. این داده‌ها به صورت فشرده‌نشده برای کارهای ETL استفاده می‌شوند.· تاریخچه تماشای فشرده (CompressedVH): شامل بخشی از سوابق تماشای قدیمی‌تر با به‌روزرسانی‌های نادر است. داده‌ها در یک ستون در هر کلید ردیف ذخیره می‌شوند و به صورت فشرده برای کاهش اثر پایین‌تر ذخیره‌سازی ذخیره می‌شوند.در پایان این بخش در مورد معماری نرم افزاری نتفلیکس، می توان نتیجه گرفت:نتفلیکس با شروع از یک معماری ساده مونولیتیک، به مرور زمان و با افزایش تعداد کاربران، نیاز به معماری پیچیده‌تر و مقیاس‌پذیرتری پیدا کرد. به همین دلیل، این شرکت به سمت استفاده از معماری میکروسرویس‌ها و معماری بدون سرور حرکت کرد تا بتواند نیازهای در حال رشد خود را برآورده سازد.ویژگی اصلی این معماری جدید، تفکیک سرویس‌های مختلف به میکروسرویس‌های کوچکتر، مستقل و به شدت گسترده پذیر است. همچنین استفاده از زیرساخت ابری و سرویس‌های آمازون، موجب افزایش انعطاف‌پذیری، در دسترس بودن و مقیاس‌پذیری شده است.علاوه بر معماری، نتفلیکس در زمینه پردازش داده‌ها و سیستم‌های توصیه‌گر هم سرمایه‌گذاری قابل توجهی انجام داده است که باعث شده یکی از بهترین سرویس‌های پخش ویدیوی تقاضا‌محور در جهان باشد.در مجموع می‌توان گفت که نتفلیکس با تکیه بر معماری‌های نوین، سیستم‌های توصیه‌گر و یادگیری ماشین، خدمات خود را به طور مداوم بهینه کرده و رضایت مشتریان خود را حفظ نموده است. آمازوندر این قسمت ابتدا داستان و تاریخچه شرکت امازون را تعریف میکنیم و در هر بازه ی زمانی معماری های مختلف آن را در ان زمان و قسمت هاهی جدیدی که به آن اضافه می شود را بررسی میکنیم .در دل گاراژی در سیاتل، واشنگتن، جرقه‌ای زده شد که به تولد یکی از غول‌های دنیای فناوری انجامید. جف بیزوس، در سال ۱۹۹۴، با فروش کتاب در وب نوپای آن زمان، بذر شرکتی را کاشت که امروزه به نام آمازون می‌شناسیم. اگرچه این کمپانی برای عموم مردم با پلتفرم خرده‌فروشی‌اش شناخته شده است، اما بخش اعظم سود عملیاتی آن (تا سال ۲۰۲۴) از زیرمجموعه رایانش ابری‌اش، Amazon Web Services (AWS)، حاصل می‌شود. آمازون همچنین با پلتفرمBedrock در حال تبدیل شدن به رهبر هوش مصنوعی تولید متن(GenAI) است. این شرکت غول‌پیکر در عرصه رسانه نیز با مدل اشتراک سرگرمی و ورزشی Prime Video که محتوای اختصاصی هم ارائه می‌دهد، درگیر «جنگ‌های استریمینگ» است و برای جذب مخاطب رقابت می‌کند.اما داستان آمازون فراتر از این خلاصه ابتدایی است. این شرکت آمریکایی چندملیتی، بر تجارت الکترونیک، رایانش ابری و پخش دیجیتال تمرکز دارد. آمازون را «یکی از تاثیرگذارترین نیروهای اقتصادی و فرهنگی جهان» لقب داده‌اند و از باارزش‌ترین برندهای دنیا به شمار می‌رود.بنیانگذار آمازون، جف بیزوس، در سال ۱۹۹۴ از گاراژ خانه‌اش در بل‌вью، واشنگتن، دست به کار شد. شرکتی که او بنا نهاد، ابتدا به عنوان یک بازار آنلاین کتاب فعالیت می‌کرد، اما به مرور دامنه محصولاتش را گسترش داد و به «فروشگاه همه‌چیز» ملقب شد. امروزه، آمازون زیرمجموعه‌های متعددی دارد، از جمله AWS، زوکس (خودروهای خودران)، Kuiper Systems (اینترنت ماهواره‌ای)، Amazon Lab126 (تحقیق و توسعه سخت‌افزار کامپیوتری)، رینگ، توئیچ، IMDb، MGM Holdings وWhole Foods Market.اما نفوذ آمازون به همین ختم نمی‌شود. این شرکت در صنایع مختلفی از جمله لجستیک، تولید محتوا، هوش مصنوعی و حتی هوافضا نیز فعالیت دارد. آن‌ها با خرید Whole Foods Market وارد عرصه خواربارفروشی شدند و با راه‌اندازی Prime Video به میدان سرگرمی‌های خانگی قدم گذاشتند. همچنین سرمایه‌گذاری‌های کلانی در حوزه‌هایی مانند تحویل با پهپاد و دستیارهای صوتی هوشمند انجام داده‌اند.با نگاهی به گذشته و حال آمازون، می‌توان گفت این شرکت تنها یک خرده‌فروشی آنلاین نیست، بلکه اکوسیستم وسیعی از خدمات و فناوری‌هاست که زندگی روزمره بسیاری از ما را تحت تاثیر قرار می‌دهد. نفوذ گسترده آمازون در ابعاد مختلف اقتصادی، اجتماعی و حتی سیاسی، بحث‌های فراوانی را به همراه داشته است. برخی آن را تهدیدی برای کسب‌وکارهای کوچک و محلی می‌دانند، در حالی که برخی دیگر معتقدند نوآوری و کارآفرینی این شرکت باعث پیشرفت و رفاه شده است.با وجود این چالش‌ها، آمازون به راه خود ادامه می‌دهد و همچنان در حال نوآوری و توسعه است. آینده این غول فناوری چه خواهد بود؟ آیا همچنان به رشد تصاعدی خود ادامه می‌دهد یا با موانعی جدی روبرو خواهد شد؟ تنها زمان پاسخ این سوالات را خواهد داد.تاسیس شرکت آمازونامازون، که ابتدا به عنوان یک فروشنده کتاب آنلاین شروع به کار کرد، تبدیل به یک عامل مهم تغییر در بخش‌ها و صنایع مختلف شده است. شرکت توسط جف بزوس، ویس پرزیدنت سابق شرکت دی. ای. شاو & کو، در سال 1994 در واشنگتن تأسیس شد. او شرکت را ابتدا با نام کادابرا ثبت کرد، اما پس از چند ماه به امازون تغییر نام داد، زیرا یک وکیل نام آن را اشتباه شنیده بود. انتخاب این نام به دلیل ویژگی‌هایی مانند بزرگترین رودخانه جهان بوده و بزوس قصد داشت فروشگاهی بسازد که بزرگترین کتابفروشی جهان باشد.امازون با سرویس‌های فروشنده‌های ثالث، سرویس‌های اشتراک و تبلیغات ریشه دوانده است. همواره هدف خود را گسترش فروش با "بهبود تمام جنبه‌های تجربه مشتری، از جمله کاهش قیمت‌ها، بهبود در دسترسی، ارائه زمان‌های تحویل سریعتر، افزایش انتخاب، گسترش اطلاعات محصول، بهبود سهولت استفاده و کسب اعتماد مشتری" اعلام کرده است.امازون به عنوان یک "مختل نما" کلاسیک در تاریخ، برای ایجاد تغییرات گسترده، نیازمند اختراع (و گاهی خرید) فناوری‌ها و روش‌های جدید بوده است. نوآوری‌های امازون، از جمله دستگاه خواندن الکترونیکی کیندل و خط تولید محصولات خانه هوشمند اکو، نه تنها تجربه مشتری را بهبود بخشیده، بلکه نحوه انجام معاملات توسط افراد و شرکت‌ها را نیز تغییر داده است.در ابتدای کار، امازون از گاراژ خانه بزوس در خیابان نورث‌ایست 28 در بلویو، واشنگتن اداره می‌شد. امازون با گذشت زمان، با توسعه در بخش‌های مختلف و ایجاد تغییرات چشمگیر در نحوه خرید و فروش آنلاین، به یکی از بزرگترین شرکت‌های جهان تبدیل شده است.سال 1995 پلتفرم فروش کتاب : سال 1995، آغازی مهم در تاریخ امازون بود. جف بزوس، سومین ثروتمند جهان (تا سال 2024)، امازون را تنها به عنوان یک فروشنده کتاب نمی‌دید. او از ابتدا امازون را یک شرکت فناوری می‌دانست، این نگرشی بود که توسط بسیاری از منتقدان مورد تمسخر قرار گرفت با توجه به تحقیقات خود، بزوس کتاب‌ها را به عنوان نقطه ورودی آسان به تجارت الکترونیک می‌دید. او یک وب‌سایت خرده‌فروشی جامع را پیش‌بینی می‌کرد که در نهایت به دنیای فروشگاه‌های بزرگ، فروشگاه‌های ورزشی، جواهرات، فروشگاه‌های موسیقی و ویدئو، فروشگاه‌های مستقل و هر چیز دیگری گسترش می‌یابد. شعار او "سریع بزرگ شو" بود، که این شعار را بر روی تی‌شرت‌های کارمندان چاپ کرده و به سرعت ثابت کرد که یک استراتژی برنده است. مانند بسیاری از شرکت‌های نوپای اوایل، اوایل امازون با زیان‌های فصلی مواجه بود. هرچند فروش و نقدینگی آن پرقدرت بودند، اما بسیاری از دلارهای آغازین به کارهایی چون توسعه سریع، بهینه‌سازی زمان تحویل، مدیریت و رصد موجودی و بهبود پلتفرم آنلاین چرخانده می‌شدند. امازون تا سال 2003، چهار سال پس از عرضه عمومی اولیه در سال 1997، سود خود را ثبت نکرد.استراتژی اولیه امازون به عنوان یک فروشنده بدون موجودی بود، اما به زودی دریافت که برای دستیابی به کنترل بیشتر در تحویلات نیاز به انبارها دارد. پس از عرضه عمومی در سال 1997، شرکت آغاز به ساخت یک مجموعه رشدی از انبارها کرد، از انبارهای بزرگ تا انبارهای کوچک در تقریباً هر گوشه‌ای از کشور.علاوه بر این، بزوس پس از خواندن یک گزارش درباره آینده اینترنت که رشد تجارت وب را در 2300 درصد پیش‌بینی کرده بود، لیستی از 20 محصول که می‌توانستند آنلاین بازاریابی شوند، ایجاد کرد. او این لیست را به پنج محصول واعظتان محدود کرد که شامل: دیسک‌های کوچک، سخت‌افزار کامپیوتر، نرم‌افزار کامپیوتر، ویدئوها و کتاب‌ها بودند. بزوس در نهایت تصمیم گرفت که کسب و کار جدید خود را به فروش کتاب‌ها آنلاین اختصاص دهد، به دلیل تقاضای جهانی بزرگ برای ادبیات، قیمت واحد کتاب‌ها و تعداد زیادی از عناوین موجود در چاپ. در 16 ژوئیه 1995، آمازون به عنوان یک فروشنده کتاب آنلاین آغاز به کار کرد و دنیایی از کتاب‌ها را به هر کسی با دسترسی به وب جهانی فروخت. اولین کتابی که در آمازون فروخته شد، کتاب "مفاهیم جاری و تشابه‌های خلاقانه" نوشته Douglas Hofstadter بود. در دو ماه اول فعالیت، آمازون به تمامی 50 ایالت آمریکا و بیش از 45 کشور فروخته بود و فروش آمازون به 20,000 دلار هفتگی رسید. سال ۱۹۹۵ یک نقطه عطف مهم در تاریخ تجارت الکترونیک بود. در آن سال، جف بزوس، کارآفرین باهوش و آینده‌نگر، با راه اندازی آمازون به عنوان یک پلتفرم آنلاین فروش کتاب، جرقه‌ای زد که بعدها به غول فناوری امروز تبدیل شد. اما داستان آمازون فراتر از یک فروشگاه کتاب اینترنتی ساده است. در این متن، تلاش می‌کنیم با تلفیق دو منبع به همراه اطلاعات اضافی، تصویری جامع از آن دوران اولیه و اهمیت سال ۱۹۹۵ برای این شرکت ترسیم کنیم.بزوس که در آن زمان ثروتش به اندازه امروز افسانه‌ای نبود، اما دیدگاهی بلندمدت داشت. او آمازون را صرفاً یک کتابفروش نمی‌دید، بلکه آن را یک شرکت فناوری می‌پنداشت. این طرز فکر در ابتدا توسط بسیاری تمسخر می‌شد، اما زمان به درستی بزوس گواهی داد. او معتقد بود که کتاب‌ها یک نقطه ورود آسان به تجارت الکترونیک هستند و از همان ابتدا چشم‌اندازی وسیع‌تر، با در بر گرفتن فروشگاه‌های بزرگ، ورزشی، جواهر فروشی و حتی خواربارفروشی‌ها، در ذهن داشت. شعار او «سریع بزرگ شو» بود که روی تی‌شرت کارمندان نقش می‌خورد و به سرعت به استراتژی برنده تبدیل شد.روزهای اولیه آمازون مانند بسیاری از استارت‌آپ‌ها با ضررهای فصلی همراه بود. با وجود فروش و جریان نقدینگی خوب، بخش زیادی از این درآمدها برای توسعه‌ی سریع به کسب‌و‌کار بازگردانده می‌شد. تمرکز اصلی بر پیشرفت‌های فناوری برای بهبود زمان تحویل، مدیریت و ردیابی موجودی و بهینه‌سازی پلتفرم آنلاین بود. جالب است بدانید که آمازون تا سال ۲۰۰۳، یعنی شش سال پس از عرضه اولیه سهام در سال ۱۹۹۷، اولین سود خود را ثبت نکرد.یکی از استراتژی‌های اولیه بزوس، راه‌اندازی آمازون بدون انبار بود. اما او زود متوجه شد که برای کنترل بیشتر بر تحویل‌ها به انبارها نیاز دارد. پس از عرضه اولیه سهام در سال ۱۹۹۷، این شرکت شبکه‌ای رو به رشد از انبارهای بزرگ و کوچک در سراسر کشور ایجاد کرد.اما چرا ۱۹۹۵ برای آمازون اهمیت ویژه‌ای داشت؟ در این سال، پس از مطالعه گزارشی درباره آینده اینترنت و پیش‌بینی رشد ۲۳۰۰ درصدی تجارت الکترونیک، بزوس فهرستی از ۲۰ محصول که می‌توانستند به صورت آنلاین به فروش برسند، تهیه کرد. او در نهایت با در نظر گرفتن تقاضای جهانی بالا، قیمت پایین کتاب و تعداد زیاد عناوین موجود، تصمیم گرفت روی فروش آنلاین کتاب تمرکز کند. در ۱۶ جولای ۱۹۹۵، آمازون رسماً به عنوان یک کتابفروش آنلاین افتتاح شد و بزرگترین مجموعه کتاب‌های جهان را برای هر کسی که به وب دسترسی داشت، عرضه کرد. اولین کتاب فروخته شده، «مفاهیم سیال و قیاس‌های خلاقانه» اثر داگلاس هافستادر بود. طی دو ماه اول فعالیت، آمازون به تمام ۵۰ ایالت آمریکا و بیش از ۴۵ کشور کتاب فروخت.سال ۱۹۹۵ تنها نقطه آغاز ماجرای آمازون نبود، بلکه تولد غول فناوری بود که امروز می‌شناسیم. این شرکت با تمرکز بر نوآوری، توجه به مشتری و گسترش مداوم فعالیت‌های خود، توانست از یک پلتفرم ساده‌ی فروش کتاب به ابرقدرتی در عرصه تکنولوژی و تجارت الکترونیک تبدیل شود. مسیر موفقیت آمازون همچنان ادامه دارد و این شرکت همچنان در حال تغییر شکل بخشیدن به نحوه تعامل ما با دنیای دیجیتال است.معماری مونولیتیک آمازون در سال ۱۹۹۵در سال ۱۹۹۵، زمانی که آمازون به عنوان یک پلتفرم آنلاین فروش کتاب راه اندازی شد، از معماری مونولیتیک استفاده می‌کرد. در این معماری، تمام کد و داده‌های برنامه در یک واحد واحد قرار دارند. این امر باعث می‌شود که توسعه و نگهداری برنامه ساده‌تر باشد، زیرا همه چیز در یک مکان قرار دارد. این معماری برای شرکت‌های نوپا و کسب‌وکارهای کوچکتر با تمرکز محدود محصولات، مانند آمازون در ابتدای کار، مزایایی داشت. معماری مونولیتیک به آمازون این امکان را می‌داد تا به سرعت رشد کند و در عین حال بر توسعه و نگهداری سیستم خود تمرکز کند، چرا که تمام کدها و سرویس‌ها در یک پایگاه کد یکپارچه قرار داشتنمزایا و معایب معماری مونولیتیک برای آمازونسرعت: زمان لازم برای توسعه و راه‌اندازی برنامه کوتاه‌تر بود.هزینه: هزینه‌های توسعه و نگهداری برنامه کاهش یافت.سادگی توسعه و نگهداری: تمامی اجزاء نرم‌افزاری در یک مکان قرار داشتند که باعث سهولت در توسعه و نگهداری می‌شد.همگرایی: از آنجا که همه بخش‌ها بخشی از یک سیستم یکپارچه بودند، هماهنگی و یکپارچگی بالاتری در عملکردها وجود داشت.تست آسان‌تر: تست کردن یک سیستم مونولیتیک نسبت به سیستم‌های پراکنده یا مبتنی بر میکروسرویس‌ها ساده‌تر بود.قابلیت نگهداری: در صورت تغییر در یک قسمت از برنامه، ممکن بود سایر قسمت‌ها نیز تحت تأثیر قرار بگیرند.ایمنی: برنامه آسیب‌پذیری بیشتری در برابر حملات امنیتی داشت.کمبود انعطاف‌پذیری: با افزایش اندازه و پیچیدگی برنامه، ایجاد تغییرات یا افزودن قابلیت‌های جدید دشوارتر می‌شد.مقیاس‌پذیری محدود: مقیاس‌بندی یک سیستم مونولیتیک بزرگ به مراتب دشوارتر است، چرا که تغییر در هر بخش نیازمند تغییرات در کل سیستم است.وابستگی به زبان برنامه‌نویسی و تکنولوژی: سیستم‌های مونولیتیک اغلب به یک زبان برنامه‌نویسی و مجموعه‌ای از تکنولوژی‌ها وابسته هستند، که انعطاف‌پذیری را در استفاده از تکنولوژی‌های جدید کاهش می‌دهد.چرا آمازون معماری مونولیتیک خود را تغییر داد؟با رشد آمازون و گسترش محصولات و خدمات آن، معماری مونولیتیک دیگر پاسخگو نبود. این معماری نمی‌توانست حجم ترافیک و تنوع محصولات جدید را مدیریت کند. علاوه بر این، معماری مونولیتیک قابل نگهداری نبود و امنیت آن نیز ضعیف بود.سال 2000 آغاز عصر خدمات شخص ثالثدر سال ۲۰۰۰، آمازون با هدف تبدیل شدن به بزرگترین فروشگاه آنلاین جهان، درهای خود را به روی فروشندگان شخص ثالث باز کرد و به خرده‌فروشان مستقل این امکان را داد تا طیف گسترده‌ای از کالاهای جدید، دست دوم، بازسازی شده و یا منحصر به فرد خود را در این پلتفرم ارائه دهند. آمازون در ازای دریافت هزینه‌های تراکنش، میزبان این پلتفرم و انجام بسیاری از کارهای لجستیکی را بر عهده می‌گرفت.راه‌اندازی خدمات شخص ثالث آمازون در سال ۲۰۰۰ منجر به ظهور سرویس Fulfillment by Amazon (FBA) شد. این سرویس به فروشندگان شخص ثالث اجازه می‌داد موجودی خود را به آمازون ارسال کنند و در ازای هزینه‌ای اضافی، آمازون محصولات را انبار، ارسال و بازگرداندن آنها را به عهده می‌گرفت. گزینه دیگر Fulfilled by Merchant (FBM) یا Merchant Fulfilled Network (MFN) است که فروشنده موظف است تمام امور لجستیکی (انبار، حمل و نقل و پردازش بازگرداندن) را خود انجام دهد.توسعه خدمات آمازون برای فروشندگانآمازون با ارائه محصولات و خدمات جدید، همکاری خود را با فروشندگان تقویت می‌کند. برخی از این خدمات عبارتند از: ادغام انبارداری و توزیع انبار، خدمات تحویل، مدیریت حمل و نقل و موجودی، و خدمات مدیریت ارتباط با مشتری (CRM) در مشارکت‌های خود. این شرکت همچنین یک بازوی مالی، Amazon Lending، را ارائه می‌دهد که به فروشندگان واجد شرایط امکان وام گرفتن تا ۵ میلیون دلار را می‌دهد.بخش خدمات فروشنده شخص ثالث همچنان در حال رشد است و در سال ۲۰۲۳، تقریباً ۶۰ درصد از فروش را به خود اختصاص داده است.عبور از بحران و تبدیل شدن به یک غول فناوریعلیرغم انتظارات آمازون مبنی بر عدم سودآوری تا چهار تا پنج سال، سرمایه‌گذاران از رشد نسبتاً کند این شرکت شکایت کردند و معتقد بودند که آمازون به اندازه کافی سریع سودآوری نمی‌کند تا سرمایه‌گذاری آنها را توجیه کند یا حتی در بلندمدت زنده بماند. در سال ۲۰۰۱، حباب دات کام ترکید و بسیاری از شرکت‌های الکترونیکی را نابود کرد، اما آمازون زنده ماند و پس از سقوط فناوری به پیش رفت تا تبدیل به یک بازیگر بزرگ در فروش آنلاین شود. این شرکت سرانجام در سه‌ماهه چهارم سال ۲۰۰۱ اولین سود خود را به دست آورد: ۰.۰۱ دلار (یعنی ۱ سنت) به ازای هر سهم، با درآمدی بیش از ۱ میلیارد دلار. این حاشیه سود، هرچند بسیار ناچیز بود، به منتقدان ثابت کرد که مدل تجاری غیرمعمول بزوس می‌تواند موفق باشد.سال 2000 تا 2002 و همچنان معماری مونولیتیکاز سال ۲۰۰۰ تا ۲۰۰۲، آمازون مثل قبل از معماری مونولیتیک استفاده می‌کرد. در مورد این معماری و مزایای ان صحبت کردیم در طول پروژه . اما یواش یواش زمان ان بود که دیگر امازون از این معماری عبور کند و به سمت معماری های جدید تر برود . امازون در سال ۲۰۰۰ با راه‌اندازی خدمات شخص ثالث خود، شروع به رشد سریع کرد. این رشد سریع، نیاز به مقیاس‌پذیری بیشتری را برای معماری مونولیتیک آمازون ایجاد کرد و مقدمات اولیه برای رفتن به سمت معماری میکروسرویس داشت ایجاد می شد. سال 2002 وب سرویس آمازونسال 2002، شاهد شروعی بزرگ در تاریخ آمازون بودیم: معرفی Amazon Web Services . آمازون وب سرویس ابتدا به عنوان راه حلی برای نیازهای خود آمازون طراحی شد، اما بزودی به پلتفرمی برای سایر کسب‌وکارها تبدیل شد تا بتوانند برنامه‌های خود را در فضای ابری بسازند، مستقر کنند و گسترش دهند.در سال 2002، آمازون با هدف تبدیل شدن به یک فناوری پیشرو، خدمات رایانش ابری خود را با نام Amazon Web Services (AWS) راه اندازی کرد. AWS در ابتدا برای پشتیبانی از نیازهای تجارت الکترونیک خود آمازون طراحی شده بود، اما به سرعت در دسترس سایر کسب‌وکارها قرار گرفت تا به آنها کمک کند تا برنامه‌های خود را در فضای ابری ایجاد، مستقر و مقیاس‌بندی کنند.آمازون وب سرویس یک پلتفرم رایانش ابری است که توسط آمازون ارائه می‌شود. به زبان ساده، AWS به کسب‌وکارها و توسعه‌دهندگان امکان می‌دهد تا بدون نیاز به خرید و نگهداری سخت‌افزارهای گران‌قیمت، منابع محاسباتی مانند سرورها، ذخیره‌سازی داده‌ها و پایگاه‌های داده را از طریق اینترنت استفاده کنند.برخی از خدمات پر استفاده که امازون ارائه می دهد عبارتند از : رایانش: AWS منابع محاسباتی مقیاس‌پذیر را در فضای ابری ارائه می‌دهد.ذخیره‌سازی: AWS راه‌حل‌های ذخیره‌سازی متنوعی را در فضای ابری ارائه می‌دهد.پایگاه داده: AWS پایگاه‌های داده متنوعی را در فضای ابری ارائه می‌دهد.شبکه: AWS خدمات شبکه‌ای متنوعی را در فضای ابری ارائه می‌دهد.تجزیه و تحلیل: AWS خدمات تجزیه و تحلیل داده‌های متنوعی را در فضای ابری ارائه می‌دهد.یادگیری ماشین: AWS خدمات یادگیری ماشین متنوعی را در فضای ابری ارائه می‌دهد.امنیت: AWS خدمات امنیتی متنوعی را در فضای ابری ارائه می‌دهد.آمازون وب سرویس اکنون بزرگترین پلتفرم رایانش ابری در جهان است AWS با ارائه بیش از 200 خدمت مختلف، از جمله در زمینه‌های محاسبات، ذخیره‌سازی، پایگاه داده، شبکه، تحلیل داده‌ها، یادگیری ماشین، امنیت و بیشتر، به پلتفرم پیشرو در زمینه رایانش ابری تبدیل شده است.امازون وب سرویس در اوایل فعالیت خود شاهد نوآوری و رشد سریع بود. در سال 2007، AWS سرویس Amazon S3 (Simple Storage Service) را راه‌اندازی کرد که راه‌حلی قابل اطمینان و مقیاس‌پذیر برای ذخیره‌سازی داده‌های کسب‌وکارها ارائه می‌کرد. این موضوع با راه‌اندازی Amazon EC2 (Elastic Compute Cloud) در سال 2008 دنبال شد که منابع محاسباتی قابل مقیاس‌پذیری در فضای ابری فراهم کرد.آمازون وب سرویس از زمان تأسیس خود توسط جف بزوس، با هدف ایجاد یک پلتفرم که کسب‌وکارها بتوانند فضای محاسباتی را اجاره کنند، رشد کرده است. این شرکت با عرضه خدماتی مانند EC2 و S3، که چگونگی ساخت برنامه‌های موبایلی توسط توسعه‌دهندگان را تغییر داد، به یک رهبر در زمینه رایانش ابری تبدیل شد.تا سال 2023، AWS حدود یک‌سوم بازار ابری را در اختیار دارد، پیشتاز از Microsoft’s Azure (23%) و Alphabet’s Google Cloud (11%). همچنین، AWS یک کسب‌وکار بسیار سودآور برای آمازون است، به طور تاریخی حدود 15 تا 18 درصد از کل فروش را تشکیل می‌دهد، اما تقریباً 50 درصد از درآمد عملیاتی شرکت را تولید می‌کند. امروزه توسط میلیون‌ها کسب‌وکار در سراسر جهان استفاده می‌شود و به عنوان پیشرو در پلتفرم رایانش ابری شناخته می‌شود. این شرکت همچنان به نوآوری و معرفی خدمات و ویژگی‌های جدید ادامه می‌دهد تا به نیازهای متغیر مشتریان خود پاسخ دهد.برخی از بزرگ ترین مشتریان این شرکت عبارتند از : Netflix، Airbnb ، Spotify ، Lyft ، Yelp ، The New York Times ، The Washington Post، The BBCبرخی از مهم ترین خدمات ارائه شده توسط awsیک) Amazon Route 53: سرویس DNS برای مدیریت نام دامنه و ارائه خدمات DNS. این سرویس به شما امکان می دهد تا نام دامنه های خود را مدیریت کنید و خدمات DNS را برای وب سایت ها، برنامه های کاربردی ، خدمات وب ، شبکه های خصوصی و سایر منابع آنلاین خود ارائه دهید.مدیریت نام دامنه: می توانید نام دامنه های خود را ثبت کنید، رکوردهای DNS را ایجاد و مدیریت کنید، و تنظیمات DNS خود را به طور کامل کنترل کنید.دسترسی بالا : Route 53 از زیرساخت جهانی AWS برای ارائه خدمات DNS با قابلیت اطمینان بالا استفاده می کند.سرعت: Route 53 از تکنیک های مختلفی برای سرعت بخشیدن به زمان پاسخگویی DNS استفاده می کند.امنیت: Route 53 از اقدامات امنیتی مختلفی برای محافظت از نام دامنه ها و داده های DNS شما استفاده می کند.قابلیت مقیاس پذیری: Route 53 می تواند به راحتی برای پشتیبانی از ترافیک DNS در هر اندازه ای مقیاس بندی شود.قیمت گذاری مقرون به صرفه: Route 53 بر اساس تعداد رکوردهای DNS و ترافیک پرس و جو که شما استفاده می کنید، قیمت گذاری می شود.دو ) Amazon CloudFront: شبکه تحویل محتوا (CDN) برای توزیع سریعتر و با تاخیر کمتر محتوا. CDN ها شبکه ای از سرورها هستند که در سراسر جهان توزیع شده اند و برای ارائه محتوای وب به کاربران با سرعت و تاخیر کمتر استفاده می شوند. CloudFront محتوای وب شما را از سرورهای نزدیک به کاربران شما ارائه می دهد، که منجر به سرعت بارگذاری سریعتر و تجربه کاربری بهتر می شود. همچنین می تواند به راحتی برای پشتیبانی از ترافیک وب در هر اندازه ای مقیاس بندی شود. CloudFront از اقدامات امنیتی مختلفی برای محافظت از محتوای وب شما استفاده می کند. یکی دیگر از مزایای استفاده از CloudFront این است که از زیرساخت جهانی AWS برای ارائه خدمات CDN با قابلیت اطمینان بالا استفاده می کند به همین خاطر قابلیت اطمینان بالایی دارد و به خاطر اینکه بر اساس ترافیک داده ای که شما استفاده می کنید، قیمت گذاری می شود بسیار مقرون به صرفه است. سه ) Elastic Load Balancing (ELB): توزیع خودکار و هدایت ترافیک برای برنامه های توزیع شده. ELB ترافیک ورودی را به طور خودکار بین چندین هدف، مانند Amazon EC2 instances یا containers، توزیع می کند. این کار به منظور افزایش قابلیت اطمینان، مقیاس پذیری و عملکرد برنامه های شما انجام می شود. ELB ترافیک ورودی را به طور خودکار بین اهداف سالم توزیع می کند و نیازی به تنظیمات دستی یا اضافی نیست و همچنین به راحتی برای پشتیبانی از ترافیک در هر اندازه ای مقیاس بندی شود و از این موضوع هم مشکلی ندارد . و مانند بقیه محصولات امنیت و اطمینان بالایی دارد و کاملا مقرون به صرفه است . از elb می شود در قسمت های مختلفی استفاده کرد مثلا می توان برای توزیع ترافیک ورودی به برنامه های وب خود بین چندین سرور برنامه استفاده کنید، می توانید برای توزیع ترافیک ورودی به API های خود بین چندین سرور API استفاده کنید، می توانید برای توزیع ترافیک ورودی به شبکه های خصوصی خود بین چندین سرور داخلی استفاده کنید و ...چهار ) AWS Shield: محافظت در برابر حملات DDoS .این سرویس برای محافظت از برنامه ها و منابع شما در برابر حملات Distributed Denial-of-Service (DDoS) طراحی شده است. AWS Shield می تواند از شما در برابر حملات DDoS لایه 3 و 4، مانند SYN floods، UDP floods و ICMP floods محافظت کند. این محافظت کاملا خودکار است و این سرویس به طور خودکار حملات DDoS را شناسایی و مسدود می کند. و مانند بقیه سرویس های امازون وب سرویس کاملا مقیاس پذیر و به صرفه است . البته این سرویس به دو صورت استاندارد و پیشرفته ارائه می شود. نسخه ی استاندارد به صورت رایگان برای همه مشتریان AWS ارائه می شود و محافظت در برابر حملات DDoS لایه 3 و 4 را ارائه می دهد. اما نسخه ی پیشرفته برای مشتریانی که به محافظت DDoS پیشرفته تری نیاز دارند، مانند محافظت در برابر حملات لایه 7، محافظت از برنامه های وب و پشتیبانی 24/7، در دسترس است و باید برای آن هزینه جداگانه ای پرداخت کنید . پنج ) Amazon ElastiCache: ذخیره سازی داده در حافظه برای افزایش سرعت و مقیاس پذیری برنامه ها.یک سرویس ذخیره سازی داده در حافظه است که توسط Amazon Web Services (AWS) ارائه می شود. این سرویس برای افزایش سرعت و مقیاس پذیری برنامه های شما با ذخیره داده های frequently accessed در حافظه (RAM) طراحی شده است. ElastiCache می تواند تاخیر را به طور قابل توجهی کاهش دهد و عملکرد برنامه شما را به طور قابل توجهی افزایش دهد. همچنین می تواند به راحتی برای ذخیره سازی حجم عظیمی از داده ها مقیاس بندی شود. همچنین بر اساس مقدار داده ای که ذخیره می کنید، قیمت گذاری می شود پس کاملا مقرون به صرفه است و هزینه ی اضافی پرداخت نمیکنید . ElastiCache از دو موتور ذخیره سازی داده در حافظه اصلی پشتیبانی می کند: اولی Redis است که یک پایگاه داده NoSQL منبع باز است که به دلیل سرعت و عملکرد بالا شناخته شده است و دومی Memcached است که یک سیستم ذخیره سازی داده-ارزش ساده است که به دلیل سرعت و مقیاس پذیری بالا شناخته شده است. از این سرویس استفاده های مختلفی می شود مانند : می تواند برای ذخیره سازی داده های پویا، مانند اشیاء جلسه، سبدهای خرید و داده های بازی، استفاده شود ، می تواند برای ذخیره سازی نتایج پرس و جو پایگاه داده، به منظور کاهش زمان پاسخگویی پرس و جو، استفاده شود ، می تواند برای ذخیره سازی داده های کش، به منظور افزایش سرعت دسترسی به داده ها، استفاده شود. به صورت کلی می توان گفت ElastiCache یک ابزار قدرتمند و انعطاف پذیر است که می تواند برای افزایش سرعت و مقیاس پذیری برنامه های شما استفاده شود. و تعداد زیادی سرویس دیگر که نمی توانیم همه ی ان هارا در این جا توضیح دهیم مانند Amazon Relational Database Service (Amazon RDS): سرویس مدیریت پایگاه داده رابطه ای ، Amazon Simple Storage Service (Amazon S3): سرویس ذخیره سازی برای ذخیره و مدیریت داده ها به صورت آنلاین و سرویس های دیگر ....شروع معماری ابری در آمازون سال 2002آمازون از معماری ابری اولین بار سال 2002 استفاده کرد البته اون موقع صرفا برای مصارف خود شرکت استفاده میکرد و تا سال 2006 به همین صورت ادامه داشت . معماری ابر رو در قسمت معماری ها به صورت کامل توضیح دادیم و اگر بخوایم به صورت خلاصه بگیم معماری ابر به چارچوبی کلی اشاره دارد که اجزای مختلف یک سیستم رایانش ابری را به هم مرتبط می‌کند. این معماری شامل زیرساخت‌ها: شامل لایه‌های فیزیکی مانند سرورها، شبکه‌ها، ذخیره‌سازی و مراکز داده می‌شود ، پلتفرم‌ها: شامل نرم‌افزارها و ابزارهایی است که برای توسعه و استقرار برنامه‌های کاربردی در ابر استفاده می‌شوند و برنامه‌های کاربردی: شامل برنامه‌هایی هستند که در فضای ابری اجرا می‌شوند ، است که در کنار هم یک محیط ابر را تشکیل می‌دهند. این سه بخش قسمت های اصلی معماری ابر هستند . امازون از سال 2006 با راه‌اندازی Amazon Web Services (AWS) به عنوان یک پلتفرم رایانش ابری، به طور فزاینده‌ای از این فناوری استفاده می‌کند و ان را در خدمت کاربران و مشتریان خود قرار می دهد.چارچوب‌های معماری ابر:مدل SaaS (Software as a Service): در این مدل، نرم‌افزار به عنوان یک سرویس از طریق اینترنت ارائه می‌شود. کاربران می‌توانند بدون نیاز به نصب یا نگهداری نرم‌افزار، از آن استفاده کنند.مدل PaaS (Platform as a Service): در این مدل، یک پلتفرم برای توسعه و استقرار برنامه‌های کاربردی ارائه می‌شود. کاربران می‌توانند بدون نیاز به مدیریت زیرساخت، برنامه‌های خود را در این پلتفرم اجرا کنند.مدل IaaS (Infrastructure as a Service): در این مدل، زیرساخت‌های فناوری اطلاعات به عنوان یک سرویس ارائه می‌شود. کاربران می‌توانند از منابع محاسباتی، ذخیره‌سازی و شبکه به صورت مجازی و در فضای ابری استفاده کنند.قسمت های مختلف امازون از این معماری استفاده می کنند که شاید یکی از دلایل مهم گسترش و پیشرفت سریع امازون هم همین بود. زیرا معماری ابری به آمازون این امکان را داده است تا سرعت و چابکی خود را افزایش دهد.تجارت الکترونیک: آمازون از AWS برای پشتیبانی از وب‌سایت تجارت الکترونیک خود، Amazon.com، و همچنین سایر پلتفرم‌های تجارت الکترونیک مانند Amazon Marketplace استفاده می‌کند.خدمات وب: آمازون از AWS برای ارائه خدمات وب مانند Amazon Prime Video، Amazon Music و Amazon Kindle استفاده می‌کند.رایانش ابری: آمازون از AWS برای ارائه خدمات رایانش ابری به سایر کسب‌وکارها استفاده می‌کند.هوش مصنوعی: آمازون از AWS برای توسعه و استقرار خدمات هوش مصنوعی مانند Amazon Rekognition و Amazon Lex استفاده می‌کند.یادگیری ماشین: آمازون از AWS برای توسعه و استقرار خدمات یادگیری ماشین مانند Amazon SageMaker و Amazon Polly استفاده می‌کند.اما سوال اصلی این است که چرا امازون از این معماری استفاده کرد و چه مزایایی برای ان ها داشته است .مقیاس‌پذیری: معماری ابری به آمازون این امکان را می‌دهد تا به سرعت و به آسانی زیرساخت‌های خود را مقیاس‌بندی کند تا با تقاضای رو به رشد خود پاسخ دهند.قابلیت اطمینان: معماری ابری به آمازون این امکان را می‌دهد تا از داده‌ها و برنامه‌های خود در برابر خطاها و خرابی‌ها محافظت کند.امنیت: معماری ابری به آمازون این امکان را می‌دهد تا از داده‌ها و برنامه‌های خود در برابر تهدیدات امنیتی محافظت کند.کاهش هزینه: معماری ابری می‌تواند به آمازون در کاهش هزینه‌های فناوری اطلاعات کمک کند.افزایش سرعت و چابکی: آمازون می‌تواند به سرعت برنامه‌ها و خدمات جدید را توسعه و استقرار دهد.مجموعه وسیع خدمات: ارائه خدمات متنوع در حوزه های مختلف.استقرار سریع: امکان توسعه و به روز رسانی سریع برنامه ها و خدمات.مدیریت آسان: کنسول مدیریت کاربرپسند برای کمک به کاربران در مدیریت و نظارت بر منابع.این مزایای فراوان معماری ابر باعث شد که امازون به این سمت پیش برود و یکی از پیشتازان در این عرصه شود.البته این معماری معایبی هم دارد که البته بسیار اندک است و همین باعث شده است که امازون و حتی بقیه شرکت های بزرگ همچنان از این معماری استفاده کنند. سال 2005 و بزرگ ترین اتفاق معماری آمازوندر این سال ها اتفاقات مهمی افتاد که بسیاری از ان ها ارتباطی با درس معماری معماری ندارند به همین خاطر به آن ها اشاره ای نمیکنیم و خیلی سریع و جزئی رد میشویم . از لحاظ معماری مهم ترین اتفاق شرکت امازون در این سال ها افتاد یعنی استفاده شرکت آمازون از معماری میکروسرویس!! معماری که تا الان هم از آن استفاده میکنند و بعید است حالا حالا ها قصد تغیر آن را داشته باشند. گسترش آمازون به حوزه کامپیوتر ابری با AWS (Amazon Web Services) و جمع‌سپاری با Amazon Mechanical Turk، حرکات استراتژیک مهمی بودند. AWS که در سال ۲۰۰۶ راه‌اندازی شد، به سرعت به یک بازیگر غالب در زمینه کامپیوتر ابری تبدیل شد. طیف وسیعی از خدمات ارائه شده توسط AWS شامل قدرت محاسباتی، گزینه‌های ذخیره‌سازی و سایر قابلیت‌ها است که برای کسب‌وکارها و افراد ضروری است. ورود زودهنگام و نوآوری‌های مداوم AWS به آن کمک کرد تا بخش قابل توجهی از زیرساخت اینترنت را تحت کنترل داشته باشد.آمازون در سال ۲۰۰۵ سرویس Amazon Prime را راه‌اندازی کرد. این یک سرویس عضویت بود که حمل‌ونقل رایگان دو روزه در ایالات متحده آمریکا (به جز مناطق دورافتاده) را برای تمام خریدهای واجد شرایط با هزینه سالانه ثابت ۷۹ دلار ارائه می‌داد. این سرویس تجربه مشتری را با ارائه حمل‌ونقل سریع و رایگان به طور قابل توجهی بهبود بخشید. معرفی Amazon Prime یک حرکت استراتژیک برای افزایش وفاداری مشتریان و تشویق به خریدهای مکرر بود.همچنین Amazon Mechanical Turk که در سال ۲۰۰۵ معرفی شد، یک بازار جمع‌سپاری است. این سرویس، کسب‌وکارها را با افرادی که قادر به انجام وظایفی هستند که کامپیوترها هنوز نمی‌توانند به طور مؤثر انجام دهند (مانند اعتبارسنجی داده‌ها و تحقیق) متصل می‌کند.آمازون حدود سال ۲۰۰۶ سرویس Fulfillment by Amazon (FBA) را راه‌اندازی کرد. این سرویس به کسب‌وکارهای کوچک و فروشندگان ثالث امکان می‌داد تا از شبکه لجستیک و توزیع آمازون استفاده کنند. فروشندگان می‌توانستند محصولات خود را در مراکز تکمیل سفارش آمازون نگهداری کنند و زمانی که محصولی فروخته می‌شد، آمازون بسته‌بندی، حمل‌ونقل، خدمات مشتری و برگشت کالا را انجام می‌داد. این برای کسب‌وکارهای کوچک یک تغییر بازی بود، زیرا به آن‌ها دسترسی به پایگاه مشتریان گسترده و توانایی‌های لجستیکی درجه یک آمازون را می‌داد. همچنین تجربه مشتریان در Amazon.com را بهبود می‌بخشید، زیرا محصولات فروخته شده توسط فروشندگان ثالث که از FBA استفاده می‌کردند، واجد شرایط برای پیشنهادات حمل‌ونقل آمازون، از جمله مزایای Prime بودند.در سال های بعد Amazon Kindle که در سال ۲۰۰۷ عرضه شد، روش مطالعه کتاب‌ها را متحول کرد. موفقیت آن منجر به افزایش فروش کتاب‌های الکترونیکی شد و تا سال ۲۰۱۰، فروش کتاب‌های الکترونیکی در آمازون از کتاب‌های فیزیکی پیشی گرفت. این تغییر نه تنها رفتار مصرف‌کنندگان را تغییر داد، بلکه بر صنعت نشر نیز تأثیر گذاشت.از سال ۲۰۱۱ تا ۲۰۱۵، آمازون با ارائه خدمات پخش جریانی مانند Amazon Music و Amazon Video، حضور خود را در بخش سرگرمی گسترش داد. این سرویس‌های پخش، حضور آمازون را در بخش سرگرمی گسترده‌تر کردند. تا سال ۲۰۱۵، ارزش بازاری آمازون از والمارت پیشی گرفت که نشان‌دهنده گذار آمازون از یک خرده‌فروش آنلاین به یک غول فناوری متنوع بود.مهاجرت به میکروسرویس چرا آمازون از معماری مونولیتیک به سمت معماری میکروسرویس رفت؟ آمازون، به عنوان یکی از پیشگامان تجارت الکترونیک، در طول سال‌ها با رشد فزاینده‌ای روبرو بوده است. این رشد، چالش‌های متعددی را برای زیرساخت‌های فناوری اطلاعات این شرکت به وجود آورده است. یکی از این چالش‌ها، مقیاس‌پذیری سیستم‌های مونولیتیک بود. مشکلاتی که معماری مونولیتیک برای آمازون ایجاد کرده بود : مقیاس‌پذیری دشوار: سیستم‌های مونولیتیک به سختی می‌توانند با افزایش ترافیک و تعداد کاربران همگام شوند و زمانی که روز به روز به ترافیک و کاربران وبسایت امازون افزوده میشد این اتفاق مانند عذاب بود.چابکی کم: تغییر و ارتقای این سیستم‌ها به دلیل وابستگی‌های متعدد، دشوار و زمان‌بر است و گاها لازم می شود از اول دوباره سیستم را طراحی کنند.پایداری ضعیف: بروز مشکل در یک بخش از سیستم می‌تواند کل سیستم را تحت تاثیر قرار دهد.سرعت توسعه پایین: وابستگی‌های متعدد در سیستم‌های مونولیتیک، سرعت توسعه و انتشار ویژگی‌های جدید را کاهش می‌دهد. و خودتان می توانید حدس بزنید برای امازون که دائم در حال نو آوری و توسعه بود این قضیه چه قدر دست و پا گیر بود.آمازون هم مانند سایر شرکت‌های بزرگ از معماری مونولیتیک به معماری میکروسرویس رفتند به دلیل مزایایی که این تغییر در معماری به آنها ارائه داد. در معماری مونولیتیک، تمامی عملکردها در یک قطعه کد تجمیع شده و همگی به هم وابسته هستند. این باعث می‌شد که تغییر یا افزودن یک ویژگی به یک سامانه مونولیتیک مشکل و هزینه‌بر شود و تغییر یک ویژگی حتی ساده، فرآیند زمان‌بر و گرانی شود. هرچه تعداد تغییرات بیشتر شود، برنامه نویسی پیچیده‌تر می‌شود تا جایی که ارتقاء و افزایش مقیاس تقریباً غیرممکن می شد. با گذشت زمان ، شرکت‌ها نمی‌توانستند بدون شروع دوباره از ابتدا تغییراتی در کد خود اعمال کنند. در این نقطه بود که توسعه‌دهندگان تصمیم گرفتند که عملکرد یک سامانه مونولیتیک را به میکروسرویس‌های کوچکتر و مستقل تقسیم کنند. میکروسرویس‌ها از طریق رابط‌های برنامه‌نویسی (API) به طور مستقل به یک معماری بر پایه میکروسرویس متصل می‌شوند. این معماری امکان توسعه، ارتقاء و مقیاس‌پذیری مستقل هر میکروسرویس را به شرکت‌ها ارائه می‌دهد. این امکان وجود دارد بدون نیاز به قطعی در خدمت‌رسانی، تاثیر منفی بر بخش‌های دیگر از برنامه یا نیاز به بازنگری دیگر میکروسرویس‌ها. این فرآیند ساده‌تر است و وقتی یک بخش از برنامه نیاز به تنظیم یا ارتقاء دارد این کار بدون تاثیر بر سایر بخش‌ها انجام می شودعلاوه بر این که این تغییر آن ها را از شر مشکلات منولیتیک راحت میکرد همچنین مزایای معماری میکروسرویس را هم به آن ها اضافه میکرد که دیگر شرایط خیلی بهتر از قبل می شد.ویژگی های مهمی که میکروسرویس به آمازون می داد: مقیاس‌پذیری آسان: هر میکروسرویس به طور مستقل قابل مقیاس‌بندی است، که انعطاف‌پذیری و کارایی بیشتری را فراهم می‌کند.چابکی بالا: استقلال و وابستگی‌های محدود میکروسرویس‌ها، چابکی و سرعت عمل را در توسعه و استقرار تغییرات افزایش می‌دهد.پایداری بیشتر: جداسازی میکروسرویس‌ها، خطاها را محدودتر می‌کند و پایداری و قابلیت اطمینان سیستم را افزایش می‌دهد.سرعت توسعه بالا: تیم‌های توسعه می‌توانند به طور مستقل و همزمان روی بخش‌های مختلف سیستم کار کنند.مهاجرت آمازون به میکروسرویس یک فرآیند پیچیده و زمان‌بر بود. این شرکت با استفاده از ابزارها و روش‌های مختلف، به تدریج سیستم‌های خود را به سمت این معماری جدید منتقل کرد. امروزه، آمازون به طور گسترده از میکروسرویس‌ها در سراسر سیستم‌های خود استفاده می‌کند. این امر به این شرکت کمک کرده است تا به یک رهبر در صنعت تجارت الکترونیک تبدیل شود و به طور مداوم خدمات نوآورانه و با کیفیتی را به مشتریان خود ارائه دهد. مهاجرت آمازون به میکروسرویس، یک نمونه موفق از چگونگی استفاده از این معماری برای غلبه بر چالش‌های مقیاس‌ پذیری است . مراحل تبدیل و انتقال از مونولیتیک به میکروسرویس توسط آمازون : خوب از انجایی که در این موارد اطلاعاتی در اینترنت نیست اکثر اطلاعات این بخش ها پیشبینی و تحلیل های شخصی خودمان است . بازسازی یک مونولیت یک کار پیچیده است. برنامه ریزی دقیق، اجرا و ارزیابی مداوم برای موفقیت ضروری است. با این حال، مزایای معماری میکروسرویس مانند مقیاس پذیری، انعطاف پذیری و قابلیت نگهداری، اغلب مزایای تلاش برای انتقال را توجیه می کند ابتدا باید برنامه مونولیتیک قبلی خود آمازون را مورد تجزیه و تحلیل دقیق قرار دادند، شناسایی عملکردها و ماژول‌های مختلف برنامه به عنوان پتانسیل میکروسرویس‌ها اهمیت بالایی دارد. مهم ترین قسمت در این مرحله این است که اجزای منطقی را شناسایی کنیم.اشیاء داده و فعالیت هایی که سیستم روی آنها انجام می دهد را شناسایی کردند.این فعالیت ها معمولا به صورت توابع و متدهای نرم افزاری کدگذاری شده اند.اجزا را بر اساس نوع داده ها و فعالیت های مرتبط با آنها گروه بندی کردند.مرحله ی بعدی ساده سازی و بازسازی اجزا بودتوابع تکراری را ادغام کردند تا اطمینان حاصل شود که هر عملکرد خاص فقط توسط یک میکروسرویس انجام می شود.بررسی کردند که آیا داده های مشابه از سیستم های مختلف قابل ادغام هستند یا خیر.اطمینان حاصل کردند که هر نوع داده تنها یک نمایش نهایی داشته باشد.مرحله ی سوم شناسایی وابستگی های اجزا استبا استفاده از تحلیل ایستا یا پویا، وابستگی های بین اجزا را شناسایی کردند.این کار به آن ها کمک کرد تا متوجه شوند که کدام اجزا را می توان با هم گروه بندی کرد.مرحله ی چهارم شناسایی گروه های اجزا گروه هایی از اجزا را که از نظر منطقی به هم مرتبط بودند و می توانستند به میکروسرویس تبدیل شوند، شناسایی کردند.مرحله پنجم ایجاد API برای رابط کاربری از راه دور : یک API یکپارچه طراحی کردند که رابط کاربری و برنامه های کاربردی بتوانند از آن برای دستکاری داده ها استفاده کنند.این API باید بدون شکستن سازگاری با نسخه های قبلی، قابل ارتقا و نسخه دار باشد.مرحله ی ششم انتقال گروه های اجزا به ماکروسرویس ها:به عنوان یک مرحله میانی، گروه های اجزا را به پروژه های جداگانه و استقرارهای جداگانه منتقل کردند.هر ماکروسرویس باید به طور مستقل از خط لوله CI/CD سیستم قابل استقرار باشد.مرحله هفتم انتقال ماکروسرویس ها به میکروسرویس هااجزا، اشیاء داده و توابع را به تدریج از سیستم مونولیتیک خارج کرده و به میکروسرویس ها منتقل کردند.به خاطر داشته باشید که هر میکروسرویس مخزن داده خاص خود را نگهداری می کند و فقط مجموعه کوچکی از فعالیت ها را روی اشیاء داده درون آن مخزن انجام می دهد.مرحله آخر استقرار و تستپس از آماده شدن یک ماکروسرویس یا میکروسرویس برای استقرار، تست یکپارچه و استقرار را انجام دهید.اطمینان حاصل کنید که سیستم مونولیتیک از سرویس جدید برای نیازهای داده ای خود به جای مخزن داده قدیمی استفاده می کند.تمام عملکردهایی که به داده های منتقل شده دسترسی دارند را در تمام رابط های کاربری آزمایش کنید تا مطمئن شوید که هیچ عملکردی هنوز سعی در استفاده از مخزن داده قدیمی ندارد.پس از اینکه آزمایش نشان داد که کد مونولیتیک باقی مانده از سرویس جدید برای اطلاعات خود استفاده می کند و به نظر نمی رسد هیچ ارتباط باقی مانده ای با مخزن داده قدیمی وجود داشته باشد، سرویس جدید را می توان در سیستم های تولید مستقر کرد.البته این طبق تحلیل های خودمان بود ، طبق اطلاعاتی که بعدا پیدا کردیم که در اینترنت بود داستانش به این صورت بود که این ساختار پیچیده باعث می‌شد هر بار که آمازون نیاز به به‌روزرسانی یا افزایش مقیاس سیستم‌های خود داشت، توسعه‌دهندگان مجبور به باز کردن گره‌های کور وابستگی‌های متعدد شوند. این فرایند طاقت‌فرسا، هزینه‌بر و زمان‌بر بود.در ابتدا، این ساختار تک محصولی به خوبی کار می‌کرد. اما با پیوستن توسعه‌دهندگان بیشتر به تیم، پایگاه کد به سرعت گسترش یافت. به‌روزرسانی‌ها و پروژه‌های متعدد، تاثیر منفی بر توسعه نرم‌افزار و عملکرد وبسایت داشتند. با کاهش آشکار بهره‌وری، نیاز به رویکردی جدید احساس می‌شد.در سال ۲۰۰۱، تأخیر در توسعه، چالش‌های کدگذاری و وابستگی‌های بین سرویس‌ها، توانایی آمازون را برای پاسخگویی به نیازهای مشتریان رو به افزایش محدود می‌کرد. شرکت و وبسایت آن در حال انفجار بودند، اما روشی برای همگام شدن با این رشد وجود نداشت.آمازون برای بازسازی سیستم خود از پایه، نرم‌افزار تک محصولی را به برنامه‌های کوچک، مستقل و اختصاصی به هر سرویس تفکیک کرد. استفاده از میکروسرویس‌ها بلافاصله نحوه کار شرکت را تغییر داد. امکان تغییر ویژگی‌ها و منابع به صورت جداگانه فراهم شد که بهبودهای فوری و گسترده‌ای در عملکرد وبسایت ایجاد کرد.آمازون چگونه این کار را انجام داد؟تجزیه کد: توسعه‌دهندگان کد منبع را تجزیه و تحلیل کردند و بخش‌هایی را که یک هدف عملکردی واحد را ارائه می‌دادند، استخراج کردند. همانطور که انتظار می‌رفت، این یک فرآیند زمان‌بر بود، زیرا تمام کدها در هم تنیده شده بودند و عملکردهای مختلف وبسایت به هم مرتبط بودند. با این حال، توسعه‌دهندگان تلاش کردند بخش‌هایی را که می‌توانستند به میکروسرویس تبدیل شوند، شناسایی و جدا کنند.ایجاد رابط وب سرویس: پس از جداسازی بخش‌های کد، توسعه‌دهندگان آن‌ها را در یک رابط وب سرویس قرار دادند. به عنوان مثال، آن‌ها یک سرویس برای دکمه خرید در صفحه محصول، یک سرویس برای تابع محاسبه مالیات و غیره ایجاد کردند. هر عملکرد بخش خاص خود را داشت.مالکیت تیمی: آمازون مالکیت هر سرویس مستقل را به یک تیم از توسعه‌دهندگان اختصاص داد تا گلوگاه‌های توسعه را با جزئیات بیشتری شناسایی کنند. با تمرکز تعداد کمی از توسعه‌دهندگان روی یک سرویس، حل چالش‌ها با کارایی بیشتری انجام می‌شد. همچنین، هر سرویس روی عملکرد کل سیستم تأثیر مستقیم نمی‌گذاشت، بنابراین کار روی آن آسان‌تر بود.معماری سرویس‌گرا (SOA) آمازون تا حد زیادی سرآغاز چیزی است که اکنون به عنوان میکروسرویس‌ها می‌شناسیم. این منجر به توسعه تعدادی راه‌حل برای پشتیبانی از معماری‌های میکروسرویس توسط آمازون شد، مانند آمازون AWS و آپولو، که در حال حاضر به شرکت‌های سراسر جهان فروخته می‌شود. بدون انتقال به میکروسرویس‌ها، آمازون نمی‌توانست به باارزش‌ترین شرکت جهان تبدیل شود که در تاریخ ۱ آگوست ۲۰۲۲ دارای ارزش بازار ۱.۶ تریلیون دلار است.قسمت های مختلف آمازون : به علت بزرگی شرکت آمازون قسمت های مختلف آن معماری های مختلفی را استفاده می کنند.آمازون وبسرویس رو کلی راجبش حرف زدیم پس کمتر تو این قسمت راجبش صحبت میکنیم صرفا در مورد معماری چند مستجره صحبت میکنیم : معماری چند مستاجره در آمازون وب سرویسمعماری چند مستاجره (Multi-tenant architecture) که به اصطلاح چند مستاجری هم نامیده می‌شود، امروزه به دلیل رشد رایانش ابری و مدل‌های کسب‌وکار نرم‌افزار به عنوان سرویس (SaaS)، اهمیت بیشتری پیدا کرده است. SaaS به ما امکان می‌دهد نرم‌افزارها را از طریق اینترنت به عنوان یک سرویس ارائه دهیم، در حالی که چند مستاجری به شرکت‌ها این امکان را می‌دهد تا با به اشتراک گذاشتن منابع بین کاربران مختلف، برنامه‌ها را سریع‌تر و کارآمدتر توسعه و مقیاس‌بندی کنند.اما چند مستاجری دقیقا چیست و چرا شرکت‌ها برنامه‌های خود را با استفاده از این معماری می‌سازند؟ در این بخش به این سوالات پاسخ می‌دهیم و مزایای اصلی معماری چند مستاجره را معرفی می‌کنیم.معماری چند مستاجره چیست؟معماری چند مستاجره رویکردی طراحی است که به چند گروه کاربر - که به عنوان مستاجر شناخته می‌شوند - امکان دسترسی به یک نمونه از یک برنامه یا سیستم را می‌دهد. این بسیار شبیه یک آپارتمان است که مستاجران مختلف آپارتمان های خود را دارند. همه آپارتمان ها خصوصی و امن هستند اما زیرساخت مشترکی دارند.این نوع معماری به شرکت‌ها این امکان را می‌دهد تا با استفاده از همان منابع سخت‌افزاری برای چندین نمونه از یک برنامه برای چندین مستاجر، در هزینه‌های زیرساخت صرفه‌جویی کنند. این امر به ویژه برای شرکت‌های SaaS مفید است زیرا به آن‌ها اجازه می‌دهد برنامه‌های خود را مقیاس‌بندی کنند و مقرون‌به‌صرفه باقی بمانند.معماری چند مستاجره چگونه کار می‌کند؟معماری چند مستاجره محیط‌های مجزا و جداگانه‌ای را در یک زیرساخت فیزیکی واحد، مانند ماشین مجازی، سرور یا پلتفرم ابری ایجاد می‌کند. این با پارتیشن‌بندی ذخیره‌سازی و پردازش داده انجام می‌شود و به هر مستاجر فضای اختصاصی خود در سیستم اختصاص داده می‌شود. یک مستاجر با برنامه تعامل می‌کند و می‌تواند به داده‌های خود دسترسی داشته باشد.مستاجران به موارد زیر اشاره دارند:کاربران و گروه‌های کاربری داخل شرکت شما (بخش‌ها، تیم‌ها، کارمندان فردی)کاربران و گروه‌های کاربری خارج از شرکت شما (فروشندگان، شرکای تجاری)مشتریانی (مشترکین یا مشتریانی) که محصول شما را خریداری می‌کننداز آنجایی که هر محیط چند مستاجره از یکدیگر جدا شده است، می‌توان آن‌ها را برای برآوردن نیازهای هر مستاجر به صورت جداگانه سفارشی کرد بدون اینکه بر سایر محیط‌ها تأثیر بگذارد. مستاجران می‌توانند ویژگی‌هایی مانند طراحی رابط کاربری و تنظیمات امنیت داده‌ها را برای محیط خود شخصی‌سازی کنند. علاوه بر این، مجموعه قوانین مختلفی را می توان بر اساس کنترل دسترسی، تخصیص منابع و در دسترس بودن ویژگی ها برای هر دامنه اعمال کرد.امنیت در معماری چند مستاجره AWS:AWS اقدامات امنیتی متعددی را برای محافظت از داده های مشتریان خود انجام می دهد. این اقدامات شامل موارد زیر است:جداسازی داده ها: داده های هر مستاجر از داده های سایر مستاجران جدا شده است.مجوزها: AWS از یک سیستم مجوز قوی برای کنترل دسترسی به داده ها و منابع استفاده می کند.رمزگذاری: AWS از رمزگذاری برای محافظت از داده های مشتریان در حال انتقال و در حال استراحت استفاده می کند.خدمات AWS که از معماری چند مستاجره استفاده می کنند:Amazon Elastic Compute Cloud (EC2): EC2 یک سرویس محاسبات ابری است که به شما امکان می دهد ماشین های مجازی (VM) را در ابر AWS راه اندازی و مدیریت کنید.Amazon Simple Storage Service (S3): S3 یک سرویس ذخیره سازی ابری است که به شما امکان می دهد هر مقدار داده ای را در ابر AWS ذخیره کنید.Amazon Relational Database Service (RDS): RDS یک سرویس پایگاه داده ابری است که به شما امکان می دهد پایگاه داده های رابطه ای را در ابر AWS راه اندازی و مدیریت کنید.آمازون پرایمدر این قسمت از دو معماری میکروسرویس و معماری چندلایه استفاده میشود . راجب میکروسرویس که کامل صحبت کردیم . حالا بریم سراغ معماری چند لایه صحبت کنیم .معماری چند لایه ای چیست؟معماری چند لایه ای (Multi-layered architecture) روشی برای سازماندهی نرم افزار به لایه های مستقل است که هر کدام مسئولیت های مشخص و متمایزی دارند. این لایه ها معمولا بسته هستند، یعنی فقط با لایه های مجاور خود تعامل دارند. در حالی که معماری هایی با یک یا دو لایه نیز وجود دارند، معماری چند لایه معمولاً دارای سه یا بیشتر لایه است که به آن معماری n لایه ای نیز گفته می شود.یک معماری چند لایه معمولاً دارای ساختار و لایه های زیر است:لایه نمایش (Presentation Layer): با رابط کاربری کاربر سروکار دارد و اطلاعات را به شکلی نمایش می دهد که برای کاربر قابل درک باشد.لایه کاربرد (Application Layer): منطق اصلی برنامه را در خود جای داده و درخواست های کاربر را پردازش می کند.لایه تجارت (Business Layer): قوانین و منطق کسب و کار را پیاده سازی می کند و با سیستم های داخلی دیگر تعامل دارد.لایه داده (Data Layer): از پایگاه داده و ذخیره سازی اطلاعات برنامه مراقبت می کند.مزایای استفاده از معماری چند لایه در آمازون پرایم:استفاده از معماری چند لایه در آمازون پرایم برای شرکت آمازون چندین مزیت داشته است:استقلال: تغییرات در یک لایه بر روی سایر لایه ها تأثیر نمی گذارد، بنابراین هر لایه را می توان بدون عوارض جانبی احتمالی در برنامه اصلاح کرد.قابلیت مقیاس پذیری: هر لایه را می توان روی یک سرور متفاوت اجرا کرد، که امکان مقیاس بندی آسان با افزایش تقاضا را فراهم می کند.سازماندهی: هر لایه وظیفه ای distinct و جداگانه را انجام می دهد، که منجر به جداسازی مناسب دغدغه ها (Separation of concerns) شده و کد را قابل فهم تر می کند.نگهداری: توسعه و نگهداری هر لایه ساده تر است، زیرا هر لایه مسئولیت محدودی دارد.قابلیت استفاده مجدد: اجزای هر لایه را می توان در برنامه های دیگر نیز استفاده کرد.در آمازون پرایم، هر لایه وظیفه خاصی را انجام می دهد:لایه نمایش: رابط کاربری برنامه را مدیریت می کند و به کاربران اجازه می دهد به فیلم ها، برنامه های تلویزیونی، موسیقی و غیره دسترسی داشته باشند.لایه کاربرد: درخواست های کاربر را دریافت و پردازش می کند و دستورات مناسب را به لایه تجارت ارسال می کند.لایه تجارت: قوانین و منطق کسب و کار را اجرا می کند، مانند بررسی صحت اشتراک کاربر و دسترسی به محتوا.لایه داده: داده های کاربر، فیلم ها، برنامه های تلویزیونی، موسیقی و سایر اطلاعات را در پایگاه داده ذخیره می کند.استفاده از معماری چند لایه به آمازون پرایم این امکان را می دهد تا برنامه ای مقیاس پذیر، قابل نگهداری و سازمان یافته برای کاربران خود ایجاد کند.در نظر داشته باشید که معماری چند لایه برای برنامه های کوچک ممکن است پیچیدگی غیرضروری به همراه داشته باشد و بر عملکرد تاثیر بگذارد. اما برای برنامه های بزرگ و پیچیده مانند آمازون پرایم، این مزایا باعث شده است که استفاده از این معماری انتخاب مناسبی باشد.آمازون ویدیومعماری محتوا محور (Content Driven Architecture) چیست؟معماری محتوا محور رویکردی برای توسعه و مدیریت وب سایت ها است که بر محتوا به عنوان عنصر اصلی تمرکز دارد. این رویکرد با در نظر گرفتن نیازهای تولیدکنندگان محتوا (Content creators) طراحی شده است و هدف آن ایجاد سیستمی است که هم انعطاف پذیر باشد و هم برای کاربران آسان استفاده باشد.مزایای استفاده از معماری محتوا محور در آمازون ویدیو:انعطاف پذیری: معماری محتوا محور به ediorها اجازه می دهد تا به راحتی ساختار و چیدمان صفحات را تغییر دهند بدون نیاز به کدگذاری دستی. این امر به ویژه برای وب سایت هایی با محتوای پویا که مرتباً در حال تغییر هستند مفید است.قابلیت استفاده: رابط کاربری ویرایشگر بصری است و به ediorها اجازه می دهد تا محتوا را به صورت مستقیم ویرایش کنند و ببینند که چگونه در صفحه نمایش داده می شود. این امر باعث صرفه جویی در وقت و کاهش خطاها می شود.کشف پذیری: معماری محتوا محور ابزارهایی را برای ediorها فراهم می کند تا الگوها و اجزای محتوا را کشف کنند و از آنها استفاده مجدد کنند. این امر باعث صرفه جویی در وقت و ایجاد ثبات در ظاهر و احساس وب سایت می شود.مقیاس پذیری: معماری محتوا محور به گونه ای طراحی شده است که با رشد وب سایت مقیاس پذیر باشد. این امر با استفاده از اجزای محتوا قابل استفاده مجدد و مدل داده های انعطاف پذیر حاصل می شود.نحوه استفاده آمازون ویدیو از معماری محتوا محور:آمازون ویدیو از یک CMS بدون سر (Headless CMS) به همراه ویرایشگر بصری Stackbit استفاده می کند تا معماری محتوا محور را پیاده سازی کند. این سیستم به ediorها اجازه می دهد تا:صفحات را با استفاده از اجزای محتوا قابل استفاده مجدد بسازند.ساختار و چیدمان صفحات را به صورت بصری تغییر دهند.از الگوها و نمونه های محتوا برای ایجاد صفحات جدید استفاده کنند.محتوا را به صورت مستقیم در صفحه ویرایش کنند.معماری محتوا محور رویکردی موثر برای توسعه و مدیریت وب سایت هایی است که بر محتوا تمرکز دارند. این رویکرد مزایای متعددی از جمله انعطاف پذیری، قابلیت استفاده، کشف پذیری و مقیاس پذیری را ارائه می دهد. آمازون ویدیو نمونه ای از چگونگی استفاده موفق از این معماری برای ایجاد یک وب سایت کاربرپسند و پویا است.آمازون موزیکدر امازون موزیک هم علاوه بر میکروسرویس از معماری مبتنی بر رویداد استفاده می شود.معماری رویداد محور (Event-Driven Architecture) چیست؟معماری رویداد محور (EDA) یک سبک معماری نرم افزار است که در آن سیستم به جای درخواست و پاسخ معمولی، بر رویدادهایی که رخ می دهند واکنش نشان می دهد. در این معماری، تولیدکنندگان رویدادهایی را منتشر می کنند و مصرف کنندگان رویداد به آنها گوش می دهند و بر اساس آنها عمل می کنند.آمازون موزیک از معماری رویداد محور به چند روش مختلف استفاده می کند:پیشنهادات موسیقی: هنگامی که کاربری به موسیقی خاصی گوش می دهد، رویدادی ایجاد می شود که به سرویس پیشنهادات موسیقی ارسال می شود. این سرویس از این رویداد برای پیشنهاد موسیقی های مشابه به کاربر استفاده می کند.لیست های پخش شخصی سازی شده: هنگامی که کاربری آهنگی را به لیست پخش اضافه می کند، رویدادی ایجاد می شود که به سرویس لیست پخش ارسال می شود. این سرویس از این رویداد برای به روز رسانی لیست پخش های شخصی سازی شده کاربر استفاده می کند.تحلیل رفتار کاربر: هر فعالیتی که کاربر انجام می دهد، مانند جستجو برای موسیقی، پخش موسیقی یا افزودن موسیقی به لیست پخش، به عنوان یک رویداد ثبت می شود. این رویدادها به سیستم تحلیل رفتار کاربر ارسال می شوند تا الگوهای استفاده را شناسایی کرده و تجربه کاربری را بهبود بخشد.مزایای استفاده از معماری رویداد محور در آمازون موزیک:مقیاس پذیری: معماری رویداد محور به راحتی مقیاس پذیر است، زیرا تولیدکنندگان و مصرف کنندگان رویداد به صورت مجزا عمل می کنند. این امر به آمازون موزیک اجازه می دهد تا با افزایش تعداد کاربران، به راحتی ظرفیت خود را افزایش دهد.قابلیت ارتقا: معماری رویداد محور به این معنی است که اجزای مختلف سیستم می توانند به طور مستقل ارتقا داده شوند. این امر باعث کاهش زمان و هزینه ارتقا می شود.انعطاف پذیری: معماری رویداد محور این امکان را به آمازون موزیک می دهد تا به راحتی ویژگی های جدیدی را به سیستم اضافه کند، زیرا مصرف کنندگان جدید رویداد می توانند به راحتی به سیستم اضافه شوند.زمان واقعی: رویدادها تقریباً به صورت بلادرنگ منتشر و دریافت می شوند، که به آمازون موزیک این امکان را می دهد تا تجربیات کاربری در زمان واقعی را ارائه دهد، مانند پیشنهادات موسیقی فوری پس از گوش دادن به یک آهنگ.معماری رویداد محور یک رویکرد قدرتمند برای توسعه سیستم های مقیاس پذیر، انعطاف پذیر و قابل ارتقا است. آمازون موزیک با موفقیت از این معماری برای ایجاد یک تجربه کاربری روان و شخصی سازی شده برای کاربران خود استفاده می کند.پیشنهاد ما برای آمازونمعماری Unikernel-based microservices می‌تواند برخی از معایب معماری میکروسرویس سنتی را برای شرکت‌هایی مانند آمازون برطرف کند. معماری میکروسرویس یونکرنل بیس (Microservices Unikernel-based) یک رویکرد جدید برای طراحی و توسعه سیستم‌های نرم افزاری است که از مزایای هر دو معماری میکروسرویس و یونکرنل استفاده می‌کند. این معماری می‌تواند برای بهبود عملکرد، مقیاس‌پذیری و امنیت سیستم‌های بزرگ و پیچیده مانند آمازون مفید باشد.توضیح در مورد Unikernel-based Microservices : یونیکرنل چیست؟یونیکرنل یک تصویر اجرایی سبک وزن است که شامل کد برنامه و کمینه‌ترین اجزای لازم سیستم عامل برای اجرای آن برنامه است. به جای اینکه یک سیستم عامل کامل را روی هر ماشین مجازی اجرا کنید، یونیکرنل تنها اجزای ضروری را برای اجرای یک میکروسرویس خاص بارگذاری می‌کند.معماری Unikernel-based Microservices در این معماری، هر میکروسرویس به صورت یک یونیکرنل جداگانه اجرا می‌شود. این امر موجب می‌شود که هر سرویس به طور مستقل و با حداقل وابستگی‌های سیستمی کار کند.مزایای Unikernel-based Microservices نسبت به میکروسرویس‌های سنتیکارایی و عملکرد: کاهش اورهد سیستم عامل به معنای بهبود کارایی و سرعت است. یونیکرنل‌ها بسیار سریع‌تر از ماشین‌های مجازی سنتی بوت می‌شوند و منابع کمتری مصرف می‌کنند.امنیت: با کاهش سطح تماس سیستم‌عامل (کاهش تعداد درایورها و سرویس‌های غیرضروری)، نقاط آسیب‌پذیر کمتری وجود دارد، که این امر امنیت را افزایش می‌دهد.بهره‌وری منابع: یونیکرنل‌ها با استفاده کارآمدتر از منابع سخت‌افزاری، امکان استقرار بیشتر میکروسرویس‌ها را در یک سرور فراهم می‌کنند.تفکیک و ایزولاسیون: هر یونیکرنل یک محیط مجزا فراهم می‌کند، که این امر به ایزولاسیون و تفکیک بهتر سرویس‌ها کمک می‌کند.کاهش پیچیدگی: با کم شدن وابستگی‌های سیستمی و کاهش اورهد سیستم عامل، پیچیدگی کلی سیستم کاهش می‌یابد.کارایی بهتر در محیط‌های توزیع شده: یونیکرنل‌ها برای محیط‌های ابری و توزیع شده، که نیازمند استقرار سریع و کارآمد هستند، ایده‌آل هستند.از آنجایی که آمازون یک سیستم بزرگ و پیچیده است و این معماری برای سیستم‌های بزرگ و پیچیده‌ای مانند آمازون که نیاز به عملکرد بالا، مقیاس‌پذیری و امنیت دارند بسیار مناسب است و همچنین این معماری برای سیستم‌های مبتنی بر ابر که نیاز به مقیاس‌پذیری و انعطاف‌پذیری دارند، مناسب است پس این معماری می تواند کاملا برای آمازون مناسب باشد.معماری میکروسرویس یونکرنل بیس یک رویکرد جدید و نویدبخش برای طراحی و توسعه سیستم‌های نرم افزاری است که می‌تواند مزایای زیادی برای سیستم‌های بزرگ و پیچیده مانند آمازون ارائه دهد. این معماری یک فناوری جدید و در حال ظهور است و هنوز در مراحل اولیه توسعه خود قرار دارد. با این حال، این معماری پتانسیل زیادی در اینده خواهد داشت .گوگلتاریخچه گوگل: از آغاز تا کنونآغازین گام‌ها:۱۹۹۶: لری پیج و سرگئی برین، دو دانشجوی دکترای دانشگاه استنفورد، پروژه‌ای تحقیقاتی به نام BackRub را آغاز می‌کنند. هدف این پروژه، تحلیل ساختار لینک‌های وب جهان‌گستر برای درک اهمیت آن‌ها بود.۱۹۹۷-۱۹۹۸:الگوریتم PageRank توسط پیج و برین توسعه می‌یابد. این الگوریتم، اهمیت یک صفحه وب را بر اساس کیفیت و تعداد لینک‌های ورودی به آن ارزیابی می‌کند.اولین نسخه موتور جستجوی گوگل در وب‌سایت دانشگاه استنفورد راه‌اندازی می‌شود.گوگل به عنوان یک شرکت خصوصی با سرمایه‌گذاری دوستان و خانواده ثبت می‌شود.رشد و چالش‌های اولیه:۱۹۹۹:گوگل به اولین دفتر خود در پالو آلتو، کالیفرنیا نقل مکان می‌کند.با وجود مخالفت‌های اولیه، گوگل مدل تبلیغات متنی را برای حفظ رابط کاربری ساده و سرعت بارگذاری بالا اتخاذ می‌کند.گوگل به دلیل طراحی ساده و نتایج جستجوی برتر، کاربران وفاداری جذب می‌کند.اولین پیشنهاد خرید گوگل توسط Excite.com ارائه می‌شود که توسط پیج و برین رد می‌شود.نوآوری و گسترش:دهه ۲۰۰۰:گوگل فروش تبلیغات مبتنی بر کلمات کلیدی را آغاز می‌کند و مدل جدیدی در صنعت تبلیغات آنلاین را پایه‌گذاری می‌کند.گوگل در سال ۲۰۰۴ با شعار "شرور نباشید" به بورس اوراق بهادار راه می‌یابد.گوگل با خرید Pyra Labs، مالک Blogger، دامنه فعالیت خود را در زمینه تولید محتوا و جمع‌آوری اطلاعات گسترش می‌دهد.گوگل برای رقابت با شرکت‌هایی مانند مایکروسافت و یاهو، محصولات متنوعی مانند Gmail، Google Chrome و Google Earth را ارائه می‌دهد.گوگل با چالش‌هایی مانند تقلب در کلیک و بحث‌هایی پیرامون حریم خصوصی و ردیابی داده‌ها روبرو می‌شود.تحولات و چالش‌های جدید:دهه ۲۰۱۰ و بعد از آن:گوگل Google+ را به عنوان چهارمین تلاش خود در زمینه شبکه‌های اجتماعی راه‌اندازی می‌کند که با استقبالی متوسط روبرو می‌شود.گوگل با بازسازی ساختاری خود به عنوان Alphabet Inc. و تبدیل شدن Google به زیرمجموعه اصلی آن، امکان تنوع‌بخشی به فعالیت‌های خود را فراتر از جستجو فراهم می‌کند.اعتراضات کارکنان گوگل به مسائلی مانند آزار جنسی، نگرانی‌های اخلاقی در مورد برخی پروژه‌ها و رویه‌های انحصاری ادعایی، این شرکت را تحت شعاع قرار می‌دهد.گوگل با ورود به حوزه‌هایی مانند بازی‌های ابری با Google Stadia، با نظارت‌های نظارتی و چالش‌های حقوقی روبرو می‌شود.وضعیت فعلی و آینده:۲۰۲۴:گوگل همچنان به عنوان یک بازیگر اصلی در صنعت فناوری به فعالیت خود ادامه می‌دهد و با چالش‌ها و فرصت‌های جدیدی روبرو است.این شرکت در حال عبور از چارچوب‌های نظارتی، رقابت و نگرانی‌های اجتماعی است و در عین حال به سمت پیشرفت‌های تکنولوژیکی مانند هوش مصنوعی و رایانش ابری گام برمی‌دارد.مسیر آینده گوگل به توانایی آن در سازگاری و نوآوری در عین توجه به ملاحظات اخلاقی و اجتماعی بستگی دارد.تاریخچه معماری گوگلمعماری گوگل در طول زمان برای پاسخگویی به نیازهای کاربران رو به رشد و پیچیدگی های خدماتش تکامل یافته است. در اینجا مروری بر تاریخچه معماری گوگل در سطح بالا آورده شده است:1. سال های اولیه: زمانی که گوگل برای اولین بار در سال 1998 تاسیس شد، بر اساس معماری نسبتا ساده ای کار می کرد. بنیانگذاران، لری پیج و سرگی برین، یک الگوریتم جستجوی نوآورانه ایجاد کردند و در ابتدا از سخت‌افزار ارزان قیمت برای پشتیبانی از موتور جستجوی خود استفاده کردند.2. سیستم فایل گوگل (GFS): در اوایل دهه 2000، گوگل سیستم فایل توزیع شده خود را به نام GFS ایجاد کرد. GFS به Google اجازه داد تا مقادیر زیادی از داده‌های ساختاریافته و بدون ساختار را در چندین ماشین ذخیره و بازیابی کند و تحمل خطا و مقیاس‌پذیری را فراهم کند.3. استفاده از Bigtable و MapReduce: گوگل با تکیه بر GFS، Bigtable، یک سیستم ذخیره سازی توزیع شده، و MapReduce، یک مدل برنامه نویسی برای پردازش مجموعه داده های بزرگ را توسعه داد. این فناوری‌ها به Google امکان داد تا حجم عظیمی از داده‌ها را در مجموعه‌ای از ماشین‌ها مدیریت کند و از خدمات اصلی و نیازهای پردازش داده پشتیبانی کند.4. زیرساخت به عنوان یک سرویس (IaaS): در سال 2008، گوگل زیرساخت خود را به عنوان یک پلت فرم خدمات به نام Google App Engine راه اندازی کرد. به توسعه دهندگان یک محیط مقیاس پذیر و مدیریت شده برای ساخت و استقرار برنامه های کاربردی وب ارائه می دهد و بسیاری از پیچیدگی های زیرساختی را از بین می برد.5. سرویس ابر Google Cloud Platform : گوگل با معرفی Google Cloud Platform در سال 2011، زیرساخت های خود را گسترش داد. GCP طیف وسیعی از خدمات رایانش ابری، از جمله ماشین های مجازی، ذخیره سازی، پایگاه های داده و یادگیری ماشینی را برای کمک به کسب و کارها و توسعه دهندگان برنامه های خود را می سازند، مستقر می کنند و مقیاس می دهند.6. Borg و Kubernetes: در داخل، گوگل چندین سیستم مدیریت خوشه، از جمله Borg و جانشین منبع باز آن، Kubernetes را توسعه داده است. این سیستم ها امکان تخصیص کارآمد منابع، کانتینرسازی و هماهنگ سازی برنامه های کاربردی توزیع شده در مقیاس بزرگ را فراهم می کنند.7. مراکز داده جهانی: گوگل شبکه گسترده ای از مراکز داده جهانی ایجاد کرده است تا از دسترسی مطمئن و کم تاخیر به خدمات خود در سراسر جهان اطمینان حاصل کند. این مراکز داده از فناوری‌های زیرساختی پیشرفته مانند سرورهای طراحی‌شده سفارشی، شبکه‌های پرسرعت و شیوه‌های کارآمد انرژی استفاده می‌کنند.معماری گوگل با مقابله با چالش‌های جدید و ترکیب فناوری‌های نوظهور به تکامل و نوآوری خود ادامه می‌دهد. مقیاس پذیری، قابلیت اطمینان و عملکرد را در اولویت قرار می دهد تا حجم عظیمی از داده های پردازش شده توسط خدمات خود را مدیریت کند و انتظارات کاربران خود را برآورده کند.گوگل از معماری میکروسرویس در طیف گسترده‌ای از محصولات و خدمات خود استفاده می‌کند، از جمله:جستجوی گوگل: سیستم جستجوی گوگل از مجموعه‌ای از میکروسرویس‌ها تشکیل شده است که هر کدام وظایف خاصی را انجام می‌دهند، مانند رتبه‌بندی نتایج جستجو، ذخیره‌سازی داده‌ها و ارائه نتایج.سرویس Gmail: Gmail از مجموعه‌ای از میکروسرویس‌ها تشکیل شده است که هر کدام وظایف خاصی را انجام می‌دهند، مانند ذخیره‌سازی ایمیل‌ها، ارسال ایمیل‌ها و فیلتر کردن اسپم.سرویس Google Maps: Google Maps از مجموعه‌ای از میکروسرویس‌ها تشکیل شده است که هر کدام وظایف خاصی را انجام می‌دهند، مانند ذخیره‌سازی داده‌های نقشه، ارائه تصاویر خیابان و مسیریابی.ابزارهای گوگل برای توسعه میکروسرویس:گوگل مجموعه‌ای از ابزارها را برای توسعه میکروسرویس ارائه می‌دهد، از جمله:ابزار Kubernetes: یک پلتفرم متن‌باز برای مدیریت و خودکارسازی استقرار و مقیاس‌بندی برنامه‌های مبتنی بر کانتینر.ابزار Cloud Run: یک پلتفرم بدون سرور برای اجرای برنامه‌های stateless.ابزار Istio: یک شبکه مش برای مدیریت ترافیک بین میکروسرویس‌ها.:معماری میکروسرویس مزایای متعددی را برای توسعه و استقرار نرم‌افزار ارائه می‌دهد. گوگل از معماری میکروسرویس در طیف گسترده‌ای از محصولات و خدمات خود استفاده می‌کند و مجموعه‌ای از ابزارها را برای توسعه میکروسرویس ارائه می‌دهد.جادوی سیستم های توزیع شده در گوگلتصور کنید اطلاعات کل دنیا جلوی شماست، چطور اون رو جستجو میکنید؟ گوگل این کار رو با یه سیستم جادویی به اسم "سیستم توزیع شده" انجام میده. بیا باهم ببینیم این سیستم چطور کار میکنه!سیستم توزیع شده چیه؟فکر کنید به جای یه کامپیوتر قدرتمند، از چند تا کامپیوتر معمولی استفاده کنید که با هم کار میکنن. هر کدوم از این کامپیوترها یه تیکه از کار جستجو رو انجام میدن، مثل بررسی یه سری صفحات وب خاص. بعد اطلاعاتشون رو با هم رد و بدل میکنن تا بهترین نتایج رو به شما نشون بدن. این همون سیستم توزیع شده هست!مزایای این سیستم چیه؟سرعت بیشتر: چون چند تا کامپیوتر با هم کار میکنن، سرعت جستجو خیلی بیشتر میشه.مقیاس پذیری: هر وقت بخوان، میتونن کامپیوترهای بیشتری به سیستم اضافه کنن و قدرت جستجو رو بالا ببرن.مقاومت بیشتر: اگه یه کامپیوتر خراب بشه، بقیه میتونن کارش رو انجام بدن و جستجو متوقف نمیشه.سیستم جستجوی گوگل چطور از این سیستم استفاده میکنه؟تصور کنید یه سوال میپرسید، سیستم توزیع شده گوگل کارهای زیر رو انجام میده:تقسیم کار: سوال شما به تیکه های کوچیکتر تقسیم میشه و به کامپیوترهای مختلف فرستاده میشه.جستجوی موازی: هر کامپیوتر یه سری صفحات وب رو بررسی میکنه و نتایج اولیه رو پیدا میکنه.جمع آوری نتایج: نتایج اولیه از همه کامپیوترها جمع آوری میشه.رتبه بندی نتایج: الگوریتم های پیچیده ای نتایج رو بر اساس کیفیت و ارتباط با سوال شما رتبه بندی میکنن.نمایش نتایج: بهترین نتایج به شما نشون داده میشن.این فقط یه بخش کوچیکی از دنیای سیستم های توزیع شده هست. گوگل از این سیستم ها برای خیلی از کارهای دیگه هم استفاده میکنه، مثل:ترجمه گوگل: ترجمه متن ها با استفاده از سیستم های توزیع شده سریع و دقیق تر میشه.تقسیم کار: متن مورد نظر به بخش‌های کوچک‌تر تقسیم می‌شود و به سرورهای مختلف فرستاده می‌شود.ترجمه موازی: هر سرور با استفاده از مدل‌های زبانی و هوش مصنوعی، بخش مربوطه را ترجمه می‌کند.جمع‌آوری نتایج: ترجمه‌های انجام شده از همه سرورها جمع‌آوری و به هم پیوسته می‌شوند.بهینه‌سازی: ترجمه با استفاده از الگوریتم‌های مختلف و فرهنگ لغت‌های تخصصی، بهینه‌سازی و ویرایش می‌شود.ارائه نتیجه: ترجمه نهایی به شما نمایش داده می‌شود.مزایای استفاده از سیستم‌های توزیع شده در ترجمه گوگل:سرعت بیشتر: ترجمه متن‌ها به طور همزمان در سرورهای مختلف انجام می‌شود و سرعت ترجمه را به طور قابل توجهی افزایش می‌دهد.دقت بیشتر: با استفاده از مدل‌های زبانی پیشرفته و هوش مصنوعی، ترجمه‌ها دقیق‌تر و روان‌تر می‌شوند.قابلیت مقیاس‌پذیری: سیستم می‌تواند به راحتی با افزایش حجم تقاضا برای ترجمه، مقیاس‌بندی شود.یوتیوب: پخش ویدیو برای میلیون ها نفر بدون مشکل با کمک این سیستم ها انجام میشه.ذخیره‌سازی ویدئو: ویدئوها به بخش‌های کوچک‌تر تقسیم می‌شوند و در سرورهای مختلف ذخیره می‌شوند.پخش ویدئو: هنگامی که شما یک ویدئو را تماشا می‌کنید، بخش‌های مختلف ویدئو از سرورهای مختلف به دستگاه شما ارسال می‌شوند.تنظیم کیفیت: سیستم به طور خودکار کیفیت ویدئو را با توجه به سرعت اینترنت شما تنظیم می‌کند.پخش زنده: سیستم‌های توزیع شده امکان پخش زنده ویدئو را برای میلیون‌ها نفر به طور همزمان فراهم می‌کنند.مزایای استفاده از سیستم‌های توزیع شده در یوتیوب:پخش روان: ویدئوها بدون مشکل و با کیفیت بالا پخش می‌شوند.قابلیت مقیاس‌پذیری: سیستم می‌تواند به راحتی با افزایش تعداد کاربران و حجم ترافیک، مقیاس‌بندی شود.هزینه کمتر: استفاده از سرورهای متعدد به جای یک سرور قدرتمند، هزینه‌ها را کاهش می‌دهد.جی میل: ایمیل های شما با خیال راحت روی سرورهای توزیع شده گوگل ذخیره میشن.ذخیره‌سازی ایمیل: ایمیل‌ها در سرورهای مختلف ذخیره می‌شوند تا از دست رفتن اطلاعات جلوگیری شود.ارسال و دریافت ایمیل: ایمیل‌ها به طور همزمان به سرورهای مختلف ارسال و دریافت می‌شوند.جستجوی ایمیل: سیستم به شما امکان می‌دهد تا به سرعت و به آسانی در میان ایمیل‌های خود جستجو کنید.ضد هرزنامه: سیستم‌های توزیع شده به فیلتر کردن هرزنامه‌ها و ایمیل‌های ناخواسته کمک می‌کنند.مزایای استفاده از سیستم‌های توزیع شده در جی میل:دسترسی سریع: شما می‌توانید به سرعت و به آسانی به ایمیل‌های خود دسترسی داشته باشید.قابلیت اطمینان بالا: احتمال از دست رفتن ایمیل‌ها بسیار کم است.امنیت بالا: ایمیل‌ها با استفاده از روش‌های مختلف رمزنگاری محافظت می‌شوند.سیستم های توزیع شده مثل یه تیم قدرتمند هستن که با هم کار میکنن تا بهترین نتیجه رو به شما بدن. به لطف این سیستم ها، گوگل میتونه به میلیاردها نفر در سراسر دنیا بهترین تجربه جستجو رو ارائه بده.کاربرد یادگیری ماشین در محصولات گوگلیادگیری ماشین به عنوان شاخه‌ای از هوش مصنوعی، نقشی حیاتی در ارتقای عملکرد و ارائه خدمات متناسب با نیاز کاربران در محصولات مختلف گوگل ایفا می‌کند. در ادامه به برخی از کاربردهای برجسته یادگیری ماشین در 5 محصول محبوب گوگل می‌پردازیم:1. جستجوی گوگل:الگوریتم رتبه‌بندی: با تحلیل محتوای صفحات وب، سیگنال‌های مرتبط با کیفیت و اعتبار محتوا را شناسایی و نتایج جستجو را بر اساس آن‌ها رتبه‌بندی می‌کند.پیشنهاد جستجو: با پیش‌بینی عبارت‌های جستجوی احتمالی، به کاربران در یافتن سریع‌تر اطلاعات مورد نظرشان کمک می‌کند.پاسخ‌های گوگل: به طور خودکار به سوالات متداول کاربران در صفحات نتایج جستجو پاسخ می‌دهد.شخصی‌سازی: نتایج جستجو را بر اساس علایق و رفتار گذشته کاربر، به صورت شخصی‌سازی شده ارائه می‌دهد.2. جیمیل:فیلتر هرزنامه: با تشخیص و فیلتر کردن ایمیل‌های ناخواسته، صندوق ورودی کاربر را مرتب و پاکیزه نگه می‌دارد.طبقه‌بندی خودکار: ایمیل‌ها را به طور خودکار در دسته‌های مختلف مانند "کار"، "شبکه‌های اجتماعی" و "تبلیغات" طبقه‌بندی می‌کند.پاسخ‌های هوشمند: با پیشنهاد پاسخ‌های مناسب به ایمیل‌ها، به کاربران در صرفه‌جویی در زمان و افزایش سرعت پاسخگویی کمک می‌کند.جستجوی پیشرفته: با استفاده از هوش مصنوعی، به کاربران در یافتن سریع‌تر ایمیل‌های مورد نظرشان در میان حجم انبوه ایمیل‌ها کمک می‌کند.3. گوگل مپ:مسیر یابی: با در نظر گرفتن ترافیک، شرایط آب و هوایی و سایر عوامل، بهترین مسیر را برای رسیدن به مقصد به کاربر پیشنهاد می‌دهد.زمان‌بندی سفر: با تخمین زمان تقریبی سفر، به کاربران در برنامه‌ریزی دقیق‌تر سفرشان کمک می‌کند.به روز رسانی زنده: اطلاعات مربوط به ترافیک، تصادفات و انسداد جاده‌ها را به طور زنده به کاربران ارائه می‌دهد.پیشنهاد مکان: با توجه به علایق و سابقه جستجوی کاربر، مکان‌های جدید و جذاب را به او پیشنهاد می‌دهد.4. یوتیوب:پیشنهاد ویدیو: با تحلیل رفتار و علایق کاربر، ویدیوهای مرتبط و جذاب را به او پیشنهاد می‌دهد.زیرنویس خودکار: به طور خودکار زیرنویس ویدیوها را به زبان‌های مختلف generate می‌کند.تشخیص محتوای نامناسب: با استفاده از هوش مصنوعی، محتوای نامناسب و خشونت‌آمیز را در ویدیوها شناسایی و حذف می‌کند.تجزیه و تحلیل ویدیو: اطلاعات مربوط به عملکرد ویدیوها، مانند تعداد بازدیدها و نظرات را به صاحبان کانال‌ها ارائه می‌دهد.5. گوگل کلود:تشخیص و پیش‌بینی خطا: با تحلیل داده‌ها، خطاهای احتمالی را پیش‌بینی و از بروز آن‌ها جلوگیری می‌کند.بهینه‌سازی منابع: با تخصیص بهینه منابع، عملکرد و کارایی سیستم‌ها را ارتقا می‌دهد.تجزیه و تحلیل داده‌ها: با ارائه ابزارهای مختلف، به کاربران در تحلیل داده‌ها و استخراج اطلاعات مفید از آن‌ها کمک می‌کند.شخصی‌سازی: خدمات و محصولات گوگل کلود را بر اساس نیازها و خواسته‌های کاربران، به صورت شخصی‌سازی شده ارائه می‌دهد.معماری چندلایه در گوگلمعماری چندلایه یکی از رایج‌ترین معماری‌های نرم‌افزاری است که در بسیاری از محصولات و خدمات گوگل از جمله موارد زیر استفاده می‌شود:1. جستجوی گوگل:لایه رابط کاربری: رابط کاربری جستجوی گوگل که کاربران با آن تعامل دارند.لایه منطق برنامه: شامل الگوریتم‌های رتبه‌بندی، پردازش زبان طبیعی و سایر منطق‌های مربوط به جستجو.لایه دسترسی به داده‌ها: شامل پایگاه داده‌های عظیم صفحات وب و سایر اطلاعات مرتبط.2. جیمیل:لایه رابط کاربری: رابط کاربری جیمیل که کاربران برای ارسال و دریافت ایمیل از آن استفاده می‌کنند.لایه منطق برنامه: شامل موتور پردازش ایمیل، فیلتر هرزنامه و سایر منطق‌های مربوط به ایمیل.لایه ذخیره‌سازی: شامل سرورهایی که ایمیل‌ها را ذخیره می‌کنند.3. یوتیوب:لایه رابط کاربری: رابط کاربری یوتیوب که کاربران برای تماشای و آپلود ویدیو از آن استفاده می‌کنند.لایه پردازش ویدئو: شامل پردازش ویدئو، رمزگذاری و سایر وظایف مربوط به ویدئو.لایه ذخیره‌سازی: شامل سرورهایی که ویدیوها را ذخیره می‌کنند.4. گوگل مپ:لایه رابط کاربری: رابط کاربری گوگل مپ که کاربران برای مسیریابی و جستجوی مکان‌ها از آن استفاده می‌کنند.لایه منطق برنامه: شامل موتور مسیریابی، رندر نقشه و سایر منطق‌های مربوط به نقشه.لایه داده‌ها: شامل پایگاه داده‌های اطلاعات مربوط به مکان‌ها، جاده‌ها و سایر اطلاعات مرتبط.مزایای استفاده از معماری چندلایه:مقیاس‌پذیری: این معماری به گونه‌ای طراحی شده است که به راحتی می‌توان آن را مقیاس‌بندی کرد تا بتواند نیازهای رو به رشد کاربران را برآورده کند.قابلیت نگهداری: این معماری به گونه‌ای طراحی شده است که به راحتی می‌توان آن را نگهداری و به روز رسانی کرد.قابلیت استفاده مجدد: اجزای این معماری می‌توانند در سیستم‌های دیگر نیز استفاده شوند.قابلیت تست: اجزای این معماری به طور جداگانه قابل تست هستند.معایب استفاده از معماری چندلایه:پیچیدگی: این معماری می‌تواند پیچیده باشد و نیاز به تخصص و دانش فنی بالا برای طراحی و پیاده‌سازی دارد.کارایی: این معماری می‌تواند به دلیل وجود لایه‌های متعدد، کارایی کمتری نسبت به معماری‌های ساده‌تر داشته باشد.معماری بدون سرور در گوگلمعماری بدون سرور برخلاف اسمش، به طور کامل سرورها را حذف نمی‌کند، بلکه وظایف مربوط به مدیریت سرور را از دوش ‍توسعه‌دهندگان برمی‌دارد. در این روش، شما فقط کدتان را نوشته و آن را ‍توسعه می‌دهید، و ارائه‌دهنده ابر وظایف مربوط به ‍تدارک، ‍مقیاس‌بندی و نگهداری سرور را به عهده می‌گیرد. این کار مزایای ‍متعددی به همراه دارد:‍توسعه سریع‌تر: تمرکز ‍توسعه‌دهنده فقط روی کد خواهد بود، نه زیرساخت.کاهش هزینه‌ها: ‍توسعه‌دهنده فقط به ازای منابعی که استفاده می‌کند هزینه ‍می‌پردازد، و ‍هزینه‌های مربوط به سرورهای ‍غیرفعال حذف ‍می‌شود.‍مقیاس‌‍پذیری ‍افزایش‌یافته: ‍مقیاس‌بندی ‍خودکار ‍می‌تواند به ‍طور ‍مناسب با ‍تغییرات ترافیک ‍انطباق ‍پیدا کند.قابلیت ‍اطمینان ‍افزایش‌یافته: خدمات ‍مدیریت‌شده ‍ارائه ‍شده توسط ‍ارائه‌دهندگان ابر، ‍قابلیت ‍دسترسی ‍بالا و ‍تحمل ‍خطا را ‍ارائه ‍می‌دهند.کاربردهای معماری بدون سرور در محصولات گوگل:منطق ‍پشتیبان ‍برای برنامه‌های ‍موبایل: ‍توابع ‍منحصر به فرد ‍وظایفی ‍مانند ‍احراز هویت ‍کاربر، ‍پردازش ‍داده‌ها و ‍ارسال ‍اعلان‌ها را ‍انجام ‍می‌دهند.پردازش لحظه‌ای: ‍توابع بدون سرور ‍می‌توانند به ‍رویدادهایی ‍مانند ‍پرس‌وجوهای ‍جستجو، ‍کلیک ‍بر روی ‍تبلیغات یا ‍اقدامات ‍کاربر ‍در ‍زمان ‍واقعی ‍واکنش ‍نشان ‍دهند.خطوط لوله داده: ‍پردازش و ‍تجزیه و تحلیل ‍مجموعه داده‌های ‍بزرگ با استفاده از ‍توابع ‍بدون سرور ‍قابل ‍مقیاس‌بندی.ریزخدمات: ‍ساخت ‍خدمات ‍مدولار ‍بدون ‍نیاز به ‍مدیریت ‍سرورهای ‍منحصر به فرد ‍برای ‍هر ‍یک.ابزارهای ‍داخلی و ‍اتوماسیون: ‍ساده‌سازی ‍فرآیندهای ‍داخلی با استفاده از ‍توابع ‍بدون سرور ‍که ‍با ‍رویدادها یا ‍برنامه‌ریزی ‍فعال ‍می‌شوند.مزایای ‍استفاده از ‍معماری بدون سرور برای گوگل:نوآوری ‍ سریع‌تر: ‍توسعه‌دهندگان ‍می‌توانند ‍بر ‍منطق ‍اصلی ‍تمرکز ‍کنند، ‍که ‍منجر به ‍تسریع ‍در ‍توسعه ‍محصول ‍می‌شود.بهینه‌سازی ‍ هزینه: ‍ مدل ‍ پرداخت ‍به ‍ازای ‍استفاده ‍منجر به ‍کاهش ‍هزینه‌های ‍زیرساخت ‍می‌شود.‍مقیاس‌‍پذیری ‍افزایش‌یافته: ‍می‌توان ‍به ‍طور ‍کارآمد با ‍پیک‌های ‍ترافیک ‍بسیار ‍بالا ‍مقابله ‍کرد.افزایش ‍بهره‌وری ‍توسعه‌دهندگان: ‍معماری بدون سرور ‍توسعه و ‍توسعه ‍را ‍ساده‌تر ‍می‌کند.چالش‌ها و ‍ ملاحظات:وابستگی به ‍ ارائه‌دهنده: ‍ توسعه‌دهنده به ‍ خدمات ‍ ارائه ‍ شده توسط ‍ یک ‍ارائه‌دهنده ‍ ابر ‍خاص ‍وابسته ‍می‌شود.اشکال‌‍ یابی و ‍ نظارت: ‍ اشکال‌‍ یابی ‍ مشکلات ‍ در ‍ توابع ‍ پراکنده ‍ می‌تواند ‍ پیچیده ‍ باشد.تأخیر ‍ شروع ‍ سرد: ‍ توابع ‍ ممکن است ‍ پس از ‍ غیرفعال ‍ بودن ‍ برای ‍ مدتی، ‍ در ‍هنگام ‍ فعال ‍ شدن ‍ دوباره ‍با ‍تأخیر ‍ شروع ‍ سرد ‍ مواجه ‍شوند.معماری بدون سرور ‍ مزایای ‍ قابل ‍ توجهی ‍ برای ‍ برنامه‌های ‍ مقیاس ‍ بزرگ ‍ مانند ‍ محصولات ‍ گوگل ‍ ارائه ‍ می‌دهد. ‍ این ‍ معماری ‍‍ توسعه ‍ سریع‌تر، ‍ کاهش ‍ هزینه‌ها، ‍و ‍ مقیاس‌‍ پذیری ‍ افزایش‌یافته ‍ را ‍ فراهم ‍ می‌کند، ‍ در ‍ حالی ‍ که ‍ نیاز به ‍ توجه دقیق به چالش‌های احتمالی ‍ دارد.پیشنهاد های ما : برای مشکلات معماری میکروسرویس در قسمت آمازون پیشنهاد مدنظر خودمون رو دادیم که در اینجا یکسان است و همان را می شود دوباره پیشنهاد داد.پیشنهاداتی برای رفع مشکلات معماری بدون سرور گوگل:کاهش وابستگی به ارائه دهنده:پشتیبانی از چندین ارائه دهنده: گوگل می تواند از چندین ارائه دهنده ابر مانند AWS، Azure و Oracle Cloud پشتیبانی کند. این به توسعه دهندگان اجازه می دهد تا از مزایای چندین ارائه دهنده ابر به طور همزمان استفاده کنند و از وابستگی به یک ارائه دهنده خاص جلوگیری کنند.ایجاد ابزارهای مهاجرت: گوگل می تواند ابزارهایی را برای مهاجرت آسان برنامه ها از یک ارائه دهنده ابر به ارائه دهنده دیگر ایجاد کند. این به توسعه دهندگان آزادی و انعطاف پذیری بیشتری می دهد تا در صورت نیاز به ارائه دهنده دیگری سوئیچ کنند.ایجاد استانداردهای باز: گوگل می تواند در ایجاد استانداردهای باز برای معماری بدون سرور مشارکت کند. این به ترویج قابلیت همکاری بین ارائه دهندگان مختلف ابر و کاهش وابستگی به یک ارائه دهنده خاص کمک می کند.بهبود اشکال یابی و نظارت:ارائه ابزارهای اشکال یابی: گوگل می تواند ابزارهای اشکال یابی قدرتمندی را برای کمک به توسعه دهندگان در شناسایی و رفع مشکلات در برنامه های بدون سرور خود ارائه دهد. این ابزارها باید بصری و آسان برای استفاده باشند و باید بتوانند مشکلات را در توابع مختلف پراکنده شناسایی کنند.ارائه داشبوردهای نظارتی: گوگل می تواند داشبوردهای نظارتی جامعی را ارائه دهد که به توسعه دهندگان دید کاملی از برنامه های بدون سرور خود را ارائه می دهد. این داشبوردها باید اطلاعات مربوط به عملکرد، استفاده از منابع و سلامت برنامه را نشان دهند.ایجاد جامعه پشتیبانی: گوگل می تواند یک جامعه پشتیبانی فعال برای توسعه دهندگان بدون سرور ایجاد کند. این جامعه می تواند به عنوان منبعی برای اشتراک گذاری دانش، بهترین روش ها و کمک به حل مشکلات عمل کند.کاهش تأخیر شروع سرد:استفاده از توابع گرم: گوگل می تواند از توابع گرم برای کاهش تأخیر شروع سرد استفاده کند. توابع گرم توابعی هستند که در حافظه پنهان نگه داشته می شوند و به طور مداوم اجرا می شوند، حتی زمانی که از آنها استفاده نمی شود. این تضمین می کند که توابع بلافاصله پس از فعال شدن آماده اجرا هستند.استفاده از پیش گرم کردن: گوگل می تواند از پیش گرم کردن برای کاهش تأخیر شروع سرد استفاده کند. پیش گرم کردن شامل فعال کردن توابع و بارگذاری آنها در حافظه قبل از نیاز به آنها است. این به کاهش زمان لازم برای شروع توابع در هنگام فعال شدن کمک می کند.استفاده از تکنیک های auto-scaling: گوگل می تواند از تکنیک های auto-scaling برای اطمینان از اینکه تعداد کافی از توابع برای پاسخگویی به تقاضا در دسترس هستند استفاده کند. این به کاهش تأخیر شروع سرد در هنگام افزایش ناگهانی ترافیک کمک می کند.پیشنهاداتی برای رفع مشکلات معماری چند لایه در گوگل:کاهش پیچیدگی:استفاده از ابزارهای مدیریت API: گوگل می تواند از ابزارهای مدیریت API مانند Google Cloud API Gateway استفاده کند تا مدیریت و نظارت API ها را ساده کند.ایجاد مستندات جامع: گوگل می تواند مستندات جامع و به روز شده ای را برای API های خود ارائه دهد تا توسعه دهندگان بتوانند به راحتی آنها را درک و استفاده کنند.ارائه آموزش و منابع: گوگل می تواند آموزش و منابع جامعی را برای کمک به توسعه دهندگان در یادگیری نحوه استفاده از API های خود ارائه دهد.بهبود کارایی:استفاده از حافظه پنهان: گوگل می تواند از حافظه پنهان برای ذخیره سازی داده های frequently accessed استفاده کند تا از بارگذاری مجدد داده ها از پایگاه داده جلوگیری شود.بهینه سازی پایگاه داده: گوگل می تواند پایگاه داده خود را برای بهبود عملکرد و کاهش زمان پاسخگویی بهینه کند.استفاده از CDN: گوگل می تواند از CDN برای توزیع محتوای خود به کاربران در سراسر جهان استفاده کند تا زمان بارگذاری را کاهش دهد.ایجاد یک معماری چند لایه انعطاف پذیر: گوگل می تواند یک معماری چند لایه انعطاف پذیر طراحی کند که بتواند به راحتی با نیازهای در حال تغییر سازگار شود.استفاده از میکروسرویس ها: گوگل می تواند از میکروسرویس ها برای تجزیه برنامه های خود به اجزای کوچکتر و قابل مدیریت تر استفاده کند.استفاده از تکنیک های DevOps: گوگل می تواند از تکنیک های DevOps برای بهبود همکاری و ارتباط بین تیم های توسعه و عملیات خود استفاده کند.سازمان فیلیموفیلیمو، به عنوان یک سرویس ویدئو به درخواست (VOD) محبوب، تجربه تماشای آنلاین فیلم و سریال‌های ایرانی و خارجی را برای کاربران فراهم می‌کند. با استفاده از معماری نرم افزار مبتنی بر وب، فیلیمو به طور موثری نیازهای مختلف کاربران خود را در پلتفرم‌های متنوع پوشش می‌دهد. در ادامه، جزئیات بیشتری در مورد لایه‌های معماری، نیازهای عملکردی و غیرعملکردی، و روش‌های بهینه‌سازی ارائه‌شده در فیلیمو بررسی خواهد شد.معماری نرم افزار فیلیمولایه ارائه: این لایه، که با تکنولوژی‌هایی نظیر HTML، CSS، و JavaScriptو فریمورک‌های React و React Native همراه با توسعه نرم افزار برای سیستم‌عامل‌های Android و iOSطراحی شده، واسط کاربری جذاب و قابل دسترسی را برای دستگاه‌های مختلف فراهم می‌آورد.لایه منطق: این لایه با استفاده از زبان‌های برنامه‌نویسی مانند PHP، Node.js، و Python و فریمورک‌های Laravelو Django، پردازش درخواست‌های کاربران و ارائه خدمات مورد نیاز را به عهده دارد.لایه داده: این لایه از پایگاه‌داده‌های MySQLو MongoDB برای ذخیره‌سازی و دسترسی به داده‌های کاربران و محتوا استفاده می‌کند، و با Redisو Elasticsearch، عملکرد و جستجوی سریع‌تری را تضمین می‌کند.نیازهای عملکردی و غیرعملکردیبرای توضیح دقیق‌تر نیازهای عملکردی و غیرعملکردی سیستمی مانند فیلیمو، می‌توان از مثال‌های زیر استفاده کرد:نیازهای عملکردی (Functional Requirements)نیازهای عملکردی به قابلیت‌ها و عملیات‌هایی اشاره دارند که سیستم باید بتواند انجام دهد. در مورد فیلیمو، این نیازها عبارتند از:1. ثبت‌نام و ورود کاربران: کاربران باید قادر به ایجاد حساب کاربری جدید، ورود و خروج از سیستم، و بازیابی رمز عبور خود باشند.2. مدیریت اشتراک: کاربران باید بتوانند برای اشتراک‌های مختلف ثبت‌نام کرده، آن‌ها را تمدید و مدیریت کنند.3. جستجو و مشاهده محتوا: کاربران باید قادر به جستجو، انتخاب و تماشای فیلم‌ها و سریال‌ها باشند. همچنین باید امکان دانلود محتوا برای تماشای آفلاین وجود داشته باشد.4. تعامل با محتوا: کاربران باید بتوانند به محتوا امتیاز دهند، نظرات خود را ارسال کنند، و محتوا را به لیست علاقه‌مندی‌های خود اضافه یا حذف کنند.5. کنترل والدین: امکان ایجاد محیطی امن برای کودکان با انتخاب محتوای مناسب سن.نیازهای غیرعملکردی (Non-Functional Requirements)نیازهای غیرعملکردی به کیفیت و معیارهایی اشاره دارند که سیستم باید بر اساس آن‌ها عمل کند. برای فیلیمو، این نیازها شامل موارد زیر است:1. امنیت: سیستم باید اطلاعات کاربران و تراکنش‌های مالی را ایمن نگه دارد، شامل رمزنگاری داده‌ها و محافظت در برابر نفوذهای غیرمجاز.2. قابلیت مقیاس‌پذیری: سیستم باید توانایی پاسخ‌گویی به افزایش تعداد کاربران و درخواست‌ها را داشته باشد بدون آنکه عملکرد آن به طور قابل توجهی کاهش یابد.3. کارایی: زمان پاسخ‌گویی سیستم باید کم باشد، حتی در زمان‌های اوج استفاده.4. قابلیت استفاده: رابط کاربری باید ساده، کاربرپسند و قابل دسترس برای افراد با توانایی‌های مختلف باشد.5. قابلیت اطمینان: سیستم باید پایدار بوده و بتواند خطاها را به گونه‌ای مدیریت کند که تأثیر کمتری بر تجربه کاربر داشته باشد.6. پشتیبانی از دستگاه‌های مختلف: سیستم باید قابلیت نمایش محتوا بر روی انواع دستگاه‌ها از جمله موبایل، تبلت، کامپیوتر و تلویزیون‌های هوشمند را داشته باشد.این نیازها زیربنای توسعه و بهبود مستمر فیلیمو را فراهم می‌آورند، به طوری که سرویسی امن، قابل اعتماد و کاربرپسند ارائه دهد.بهینه‌سازی‌هابرای نمایش ویدئو، فیلیمو از اپلیکیشن‌های اختصاصی برای تمام دستگاه‌ها و وب‌سایتی که از HTML5 و JavaScriptاستفاده می‌کند، بهره می‌برد. امکان اتصال دستگاه‌های موبایل به تلویزیون‌ها از طریق Chromecast یا Miracastو تبدیل تلویزیون‌های عادی به هوشمند با استفاده از دستگاه‌هایی مانند فیلیموباکس فراهم شده است.بهینه‌سازی فایل‌ها شامل استفاده از الگوریتم‌های فشرده‌سازی پیشرفته، اداپتیو بیت‌ریت استریمینگ برای تطبیق با پهنای باند کاربر، و کشینگ محتوا در سرورهای مختلف با استفاده از CDN می‌باشد. همچنین، کاربران می‌توانند کیفیت ویدئو را بر اساس نیاز خود انتخاب کنند و امکان دانلود ویدئوها برای تماشای آفلاین نیز وجود دارد.پیشنهاد هایی برای بهبود معماری نرم افزار فیلیمو1. میکروسرویس‌ها: به جای یک معماری تک‌لایه‌ای، می‌توان از معماری میکروسرویس استفاده کرد. به این صورت که هر بخش از منطق کسب‌وکار به صورت یک سرویس مجزا و مستقل پیاده‌سازی شود. مزایای این کار عبارتند از: توسعه‌پذیری و نگهداری آسان‌تر، امکان مقیاس‌پذیری مستقل هر سرویس، انتشار مداوم و انعطاف‌پذیری بیشتر.2. CQRS: در این الگو، ماژول‌های مجزایی برای عملیات خواندن (Query) و نوشتن (Command) از پایگاه‌داده در نظر گرفته می‌شود تا کارایی و بهره‌وری بهبود یابد. همچنین با استفاده از ذخیره‌سازی کشی می‌توان زمان دسترسی به داده‌ها را کاهش داد. البته این الگو هم ممکن است باعث افزایش پیچیدگی و هزینه‌های توسعه و نگهداری شود. اما با تعیین معیارهای مناسب برای انتخاب بخش‌هایی که از این الگو استفاده می‌کنند و استفاده از ابزارهای مدرن می‌توان این مشکلات را کنترل کرد.3. معماری بدون‌سرور: با ذخیره‌سازی توزیع‌شده محتوا در شبکه‌ای همتا به همتا (P2P) بر پایه IPFSمی‌توان نیاز به سرورهای متمرکز را کاهش داده و مقیاس‌پذیری، تحمل‌پذیری خطا و امنیت را بهبود بخشید. البته که در شرایط ایران قابل اجرا نیست. چون برای این کار نیاز به دسترسی به اینترنت پایدار و سریع و شبکه‌های همتا به همتا مطمئن و امن است. اما در ایران، اینترنت دارای محدودیت‌های زیادی است و شبکه‌های همتا به همتا نیز ممکن است تحت سانسور و فیلترینگ قرار گیرند. بنابراین، این روش برای فیلیمو مناسب نیست. ولی با فرض اینکه اگر فیلیمو در کشوری غیر از ایران بارگزاری شود میتواند از این پیشنهاد استفاده4. تحلیل الگوها: با به کارگیری الگوریتم‌های یادگیری ماشینی و داده‌کاوی می‌توان الگوهای رفتاری کاربران را شناسایی کرده و بر اساس آن‌ها خدمات شخصی‌سازی‌شده و توصیه محتوا ارائه نمود. این کار نیاز به داده‌های کافی و کیفی از رفتار کاربران و الگوریتم‌های مناسب برای تحلیل آن‌ها دارد. اما با استفاده از روش‌های جمع‌آوری داده‌ها و یادگیری ماشینی می‌توان این کار را انجام داد.5. معماری رویداد-محور: استفاده از یک لایه ارتباطی مبتنی بر رویداد بین سرویس‌ها که امکان همگام‌سازی آنی داده‌ها و وضعیت کاربران را فراهم می‌کند. این معماری هم نیاز به ابزارهای مناسب برای انتقال و مدیریت رویدادها دارد. اما با استفاده از تکنولوژی‌های مدرن مانند Kafkaو RabbitMQ می‌توان این کار را انجام داد.برخی از منابع مورد استفاده : https://www.britannica.com/topic/Amazoncomhttps://en.wikipedia.org/wiki/History_of_Amazonhttps://www.techaheadcorp.com/knowledge-center/history-of-aws/https://www.simplilearn.com/tutorials/cloud-computing-tutorial/cloud-computing-architecturehttps://aws.amazon.com/architecturehttps://medium.com/@eyupcebe/aws-cloud-architecture-8ea9a99fe8fahttps://dl.acm.org/doi/fullHtml/10.1145/3624486.3624492http://unikernel.orghttps://www.morethanseven.net/2015/08/21/operating-unikernel-challengeshttps://dl.acm.org/doi/fullHtml/10.1145/3624486.3624492http://unikernel.org/https://www.morethanseven.net/2015/08/21/operating-unikernel-challenges/https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/two-pizza-teams.htmlhttps://blog.nuclino.com/two-pizza-teams-the-science-behind-jeff-bezos-rulehttps://www.geeksforgeeks.org/monolithic-architecture/https://dzone.com/articles/evolution-of-software-architecture-from-monolithshttps://www.mdpi.com/2076-3417/10/17/5797https://blog.dreamfactory.com/microservices-exampleshttps://www.youtube.com/watch?v=_azoxefUs_Yhttps://insights.sei.cmu.edu/blog/8-steps-for-migrating-existing-applications-to-microservices/https://cloud.google.com/architecture/microservices-architecture-refactoring-monolithshttps://www.gooddata.com/blog/multi-tenant-architecture/https://medium.com/@e0324913/multilayered-software-architecture-1eaa97b8f49ehttps://www.stackbit.com/blog/content-driven-architecturehttps://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/event-drivenhttps://www.britannica.com/topic/Netflix-Inchttps://www.geeksforgeeks.org/system-design-netflix-a-complete-architecture/https://www.codingninjas.com/studio/library/system-design-netflix-a-complete-architecturehttps://en.wikipedia.org/wiki/History_of_Googlehttps://www.spiceworks.com/tech/cloud/articles/what-is-distributed-computing/https://www.serverless.com/blog/serverless-architecturehttps://www.vmware.com/topics/glossary/content/cloud-architecture.html.htmlhttps://cloud.google.com/learn/what-is-cloud-architectureاین مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است مجتبی شکوری فر مجتبی شکوری فر Thu, 01 Feb 2024 13:22:39 +0330 https://virgool.io/@mojtabao121/%D8%AE%D9%84%D8%A7%D8%B5%D9%87-%D9%BE%D9%86%D8%AC-%D8%AA%D8%A7-%D8%A7%D8%B2-%D8%A8%D9%87%D8%AA%D8%B1%DB%8C%D9%86-%D9%88-%D8%AC%D8%AF%DB%8C%D8%AF-%D8%AA%D8%B1%DB%8C%D9%86-%D8%B3%D8%AE%D9%86%D8%B1%D8%A7%D9%86%DB%8C%D8%A7%DB%8C-%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-sk1aucfhnqkp ویدیو اول : https://www.youtube.com/watch?v=tBWhUgDwZUw&list=PLndbWGuLoHeYTBaqFu31Nac-19qsdUl_V&index=39 در این ویدیو، تجس چوپرا در مورد Netflix Drive توضیح می‌دهد که چگونه این سیستم، به عنوان یک راه‌حل زیرساختی، با حجم عظیمی از داده‌ها و دارایی‌ها در مقیاس اگزابایت کار می‌کند که توسط استودیوها و پلتفرم‌های Netflix تولید و مدیریت می‌شوند. او ابتدا با معرفی کلی Netflix Drive شروع می‌کند و اینکه این سیستم چگونه به هنرمندان استودیو امکان می‌دهد تا از گوشه و کنار جهان بر روی ایجاد داستان‌ها و دارایی‌هایی کار کنند که جهان را سرگرم کنند.چوپرا انگیزه‌هایی که منجر به ایجاد Netflix Drive شدند را توضیح می‌دهد که از جمله آن‌ها می‌توان به نیاز به زیرساختی توزیع شده، قابل مقیاس و کارآمد اشاره کرد. او بیان می‌کند که دارایی‌ها در Netflix عمدتاً مجموعه‌ای از فایل‌ها و پوشه‌ها هستند که دارای داده و متاداده‌ای هستند که توسط سیستم‌ها و خدمات مختلف مدیریت می‌شوند. از لحظه تولید داده‌ها مستقیماً از دوربین تا زمانی که این داده‌ها در نهایت به فیلم‌ها و نمایش‌ها تبدیل می‌شوند، این دارایی‌ها با انواع مختلف متاداده توسط سیستم‌های مختلف برچسب‌گذاری می‌شوند.چوپرا بیان می‌کند که Netflix Drive در واقع یک نرم‌افزار لبه‌ای است که بر روی ایستگاه‌های کاری هنرمندان استودیو اجرا می‌شود. این سیستم، که به عنوان یک سیستم فایل ابری چند رابطه‌ای و چند سیستم‌عاملی طراحی شده است، قصد دارد تا حس و عملکرد یک سیستم فایل معمولی POSIX را ارائه دهد. علاوه بر این، این سیستم مانند یک میکروسرویس عمل می‌کند که دارای نقاط پایانی REST است و عملیات پس‌زمینه‌ای دارد که توسط بسیاری از جریان‌های کاری و موارد استفاده خودکار استفاده می‌شود، جایی که کاربران و برنامه‌ها به طور مستقیم با فایل‌ها و پوشه‌ها سر و کار ندارند.او همچنین به طراحی و معماری Netflix Drive می‌پردازد، به زندگی‌نامه یک نمونه معمولی از Netflix Drive اشاره می‌کند و برخی از درس‌هایی که از این فرایند آموخته شده‌اند را با مخاطبان به اشتراک می‌گذارد. بخش مهمی از سخنرانی به بررسی چگونگی پشتیبانی Netflix Drive از نیازهای متنوع استودیوها و پلتفرم‌های Netflix و نقش آن به عنوان یک قطعه اساسی زیرساخت ذخیره‌سازی اختصاص دارد. او تاکید می‌کند که Netflix Drive به گونه‌ای طراحی شده است که می‌تواند انواع مختلفی از ذخیره‌سازی‌های داده و متاداده را در بر بگیرد و به یک چارچوب عمومی تبدیل شود که انواع مختلفی از مخازن داده را پشتیبانی کند.در نهایت، چوپرا در مورد چالش‌هایی که در طراحی و پیاده‌سازی این سیستم با آن‌ها مواجه شده‌اند صحبت می‌کند و به پرسش‌هایی پاسخ می‌دهد که مربوط به تصمیم‌گیری‌های فنی، مدیریت داده‌ها و متاداده‌ها و امنیت است. او بیان می‌کند که Netflix Drive توانسته است عملکردی نزدیک به یک سیستم فایل محلی ارائه دهد و به طور چشمگیری از سایر سیستم‌های ذخیره‌سازی ابری مانند Google Drive عملکرد بهتری داشته باشد.ویدیو دوم : https://www.youtube.com/watch?v=nEO4eAr2AGE&list=PLndbWGuLoHeYTBaqFu31Nac-19qsdUl_V&index=41 هالی کامینز در سخنرانی خود به تجربیاتش از کار به عنوان مشاور در IBM Garage اشاره می‌کند و مشکلات متداول در پیاده‌سازی معماری میکروسرویس‌ها را مورد بررسی قرار می‌دهد. او تاکید می‌کند که یکی از اصلی‌ترین مشکلات در پیاده‌سازی میکروسرویس‌ها، عدم درک کافی از مشکلاتی است که سازمان‌ها قصد دارند با استفاده از این تکنولوژی حل کنند. بسیاری از سازمان‌ها به سمت میکروسرویس‌ها می‌روند چون این روش جدید و جذاب به نظر می‌رسد، بدون آنکه وقت کافی صرف تعریف مشکلات واقعی و اهداف خود کرده باشند.کامینز همچنین به مشکلاتی اشاره می‌کند که در نتیجه‌ی عدم تفکیک و وابستگی‌های نامناسب در میکروسرویس‌ها به وجود می‌آید. او توضیح می‌دهد که گاهی اوقات، سیستم‌ها به جای آنکه به صورت مجموعه‌ای از خدمات مستقل عمل کنند، به یک "مونولیت پراکنده" تبدیل می‌شوند که هماهنگی و نگهداری آن‌ها دشوار است. این مشکل می‌تواند منجر به "اسپاگتی ابری" شود، که در آن تغییر در یک بخش می‌تواند اثرات ناخواسته در سایر بخش‌ها ایجاد کند.بحث دیگری که کامینز مطرح می‌کند مربوط به تست‌های قراردادی است. او توضیح می‌دهد که چگونه تست‌های قراردادی می‌توانند به عنوان یک راهکار برای اطمینان از اینکه ارتباط بین میکروسرویس‌ها به درستی کار می‌کند، عمل کنند. با این حال، اجرای موثر این تست‌ها نیازمند همکاری و تفاهم بین تیم‌های مختلف است و ممکن است با چالش‌هایی مواجه شود.در نهایت، کامینز تاکید می‌کند که میکروسرویس‌ها نباید به عنوان هدف نهایی دیده شوند، بلکه باید به عنوان ابزاری برای رسیدن به اهداف بزرگتر تجاری مانند افزایش چابکی و کارایی مورد استفاده قرار گیرند. او همچنین توصیه می‌کند که قبل از تصمیم‌گیری برای پیاده‌سازی میکروسرویس‌ها، سازمان‌ها باید به دقت نیازهای خود، اندازه تیم‌ها، و پیچیدگی دامنه‌های کاری خود را در نظر بگیرند. این سخنرانی با تاکید بر اهمیت درک عمیق از معماری و تکنولوژی‌های مورد استفاده و تاثیر آن‌ها بر اهداف کسب و کار به پایان می‌رسد.ویدیو سوم : https://www.youtube.com/watch?v=HQUIZC3_OmI&list=PLndbWGuLoHeYTBaqFu31Nac-19qsdUl_V&index=45 لوکاس کاواکانچی، مهندس ارشد نرم‌افزار در نیو بانک، با ارائه داستان رشد و توسعه‌ی نیو بانک، به بررسی نحوه ساختاردهی نرم‌افزار برای بیشینه‌سازی اهرم مالی می‌پردازد. او اهرم را به عنوان میزان ارزش حاصل نسبت به سرمایه‌گذاری تعریف می‌کند و تاکید دارد که در محیط نرم‌افزاری، این به معنای تصمیمات، انتخاب‌های فنی و بدهی‌های فنی در مقابل ارزش ایجاد شده است.در دوران استارتاپی نیو بانک، تمرکز بر سرعت وارد شدن به بازار و جمع‌آوری بازخورد بود. انتخاب‌های فنی شامل استفاده از پایگاه داده‌های خاص مانند Datomic، زبان برنامه‌نویسی کلوژر و معماری هگزاگونال بود که هرکدام به نوعی به تسریع توسعه و افزایش انعطاف‌پذیری کمک کردند. کاواکانچی به اهمیت انتخاب‌های هوشمندانه در این مرحله تاکید می‌کند، جایی که هر تصمیم می‌تواند پیامدهای عمده‌ای بر روی آینده‌ی شرکت داشته باشد.با رشد شرکت، نیو بانک وارد فاز رشد شد. در این مرحله، مسائلی مانند تحمل پذیری خطا، قابلیت اطمینان و توانایی در مقیاس‌بندی به اهمیت بیشتری رسیدند. کاواکانچی از مفهوم شاردینگ زیرساخت و مهاجرت به کوبرنتیز و توسعه ابزارهای نظارتی پیشرفته صحبت می‌کند. او می‌گوید که چگونه این تغییرات به مدیریت بهتر ترافیک و داده‌های در حال رشد کمک کردند، همچنین به تدریج شرکت را برای مقیاس‌های بزرگتر آماده‌کردند.در مرحله توسعه و گسترش، نیو بانک شروع به ساخت پلتفرم‌های افقی و عمودی کرد تا توانایی توسعه محصولات متنوع و متعدد را در تیم‌های مختلف افزایش دهد. این شامل توسعه ابزارهایی برای موبایل و وب، زیرساخت‌ها و پلتفرم‌های تجربه کاربری می‌شود. لوکاس همچنین بر اهمیت داده‌ها و استفاده از ابزارهای پیشرفته برای تحلیل و پردازش داده‌های بزرگ تاکید دارد.لوکاس در پایان تاکید می‌کند که چگونه تصمیمات معماری در هر مرحله از رشد شرکت برای موفقیت آن حیاتی است. او با ارائه داستان نیو بانک به عنوان یک مورد مطالعه، نشان می‌دهد که چگونه تصمیمات استراتژیک می‌توانند به تحقق اهداف کسب و کار و تحولات عمده منجر شوند. سخنرانی با تاکید بر اهمیت تفکر استراتژیک و هوشمندانه در تصمیم‌گیری‌های معماری به پایان می‌رسد.ویدیو چهارم : https://www.youtube.com/watch?v=sZd4xTQlrIE&list=PLndbWGuLoHeYTBaqFu31Nac-19qsdUl_V&index=96 در این ویدیو، پنلی در مورد معماری میکروسرویس‌ها صحبت می‌کنند و تجربیات خود را در این زمینه به اشتراک می‌گذارند. ابتدا، از پنلیست‌ها خواسته می‌شود که خود را معرفی کرده و بگویند چه چیزی را کاش قبل از شروع کار با میکروسرویس‌ها می‌دانستند. یکی از آن‌ها می‌گوید که آرزو می‌کرده می‌دانسته که چطور پیچیدگی‌ها می‌توانند با توسعه کسب‌وکار افزایش پیدا کنند. دیگری می‌گوید که باید می‌دانست بعضی از مشکلات می‌توانند بدون تغییر به میکروسرویس‌ها حل شوند.آن‌ها در مورد اینکه چطور میکروسرویس‌ها می‌توانند به افزایش سرعت تحویل کمک کنند صحبت می‌کنند و در عین حال به این نکته اشاره می‌کنند که می‌توانند باعث پیچیدگی شوند. یکی از پنلیست‌ها تاکید می‌کند که مهم است پیش از رفتن به سمت میکروسرویس‌ها، مشکلات اصلی را شناسایی کرده و راه حل مناسب را پیدا کنیم، چه این راه حل میکروسرویس باشد یا نه.یکی دیگر از موضوعات مورد بحث، اهمیت ابزارها و تیم‌ها در مدیریت میکروسرویس‌ها بود. بحث شد که چطور ساختار تیم‌ها و فرایند توسعه نرم‌افزار باید با یکدیگر هماهنگ باشند و اینکه تغییرات سازمانی چگونه باید با معماری میکروسرویس‌ها همراه شوند.پنل به پایان رسید با بحث در مورد تصمیم‌گیری برای تقسیم کد به میکروسرویس‌ها به جای ساختاردهی ماژولار آن در یک کدبیس واحد و چالش‌های عملیاتی که با میکروسرویس‌ها و معماری‌های بزرگتر مواجه می‌شوند. در نهایت، پنلیست‌ها توصیه‌هایی برای پذیرش یا تکامل میکروسرویس‌ها ارائه دادند، از جمله اهمیت نگهداری و مستندسازی از ابتدا و هماهنگی میکروسرویس‌ها با جریان‌های ارزشی کسب‌وکار.ویدیو پنجم : https://www.youtube.com/watch?v=QrEOvHdH2Cg&list=PLndbWGuLoHeYTBaqFu31Nac-19qsdUl_V&index=68 در این ویدیو، جنیفر و استیون، مهندسین در تیم API سیستم‌های نتفلیکس، به بررسی تاریخچه، چالش‌ها و فلسفه پشت معماری میکروسرویس‌ها و API های فدرالیزه شده می‌پردازند. آنها داستان شروع نتفلیکس را با یک مونولیت ساده که به مرور به میکروسرویس‌های متعدد تقسیم شد، تعریف می‌کنند و اشاره می‌کنند که چگونه مواجهه با چالش‌های مقیاس‌بندی و انعطاف‌پذیری آن‌ها را به سمت معماری فدرالیزه GraphQL سوق داده است.تکامل معماری:آن‌ها شرح می‌دهند که چگونه در ابتدا نتفلیکس یک سرور ساده داشت که با یک پایگاه داده صحبت می‌کرد و صفحات وب را ارائه می‌داد. با رشد کسب و کار و افزایش تیم‌های مهندسی، ساختار ساده به یک مونولیت بزرگ تبدیل شد که بعداً به میکروسرویس‌ها تقسیم شد تا استقلال و سرعت تیم‌ها افزایش یابد.معماری فدرالیزه و چالش‌های آن:آن‌ها به مشکلات رشد یک API Gateway تکی اشاره می‌کنند که به تدریج به مونولیت جدیدی تبدیل شد. برای مقابله با این چالش، معماری فدرالیزه GraphQL را به کار گرفتند که به تیم‌های مختلف اجازه می‌دهد قسمت‌های مختلفی از گراف کلی API را مدیریت کنند. این رویکرد، تقسیم وظایف و مالکیت را بهبود می‌بخشد و به هر تیم اجازه می‌دهد با سرعت خودش پیش برود.کاربرد و مزایا:آنها نمونه‌هایی از چگونگی کاربرد و مزایای این معماری را ارائه می‌دهند، از جمله افزایش بهره‌وری، توانایی مدیریت بهتر ترافیک و داده‌ها، و انعطاف‌پذیری بیشتر در توسعه و نگهداری سرویس‌ها.فلسفه و اجرای فدرالیزه:آنها همچنین به جزئیات فنی و چالش‌های اجرای معماری فدرالیزه پرداخته و بحث می‌کنند که چگونه این معماری نه تنها یک فناوری خاص، بلکه بیشتر یک فلسفه و رویکرد به ساختار API است. این شامل تشریح اجزای مختلف فدرالیزه، از جمله سرویس‌های گراف، رجیستری اسکیما و گیت‌وی گراف است.چالش‌ها و درس‌های آموخته:در پایان، آنها به چالش‌ها، درس‌های آموخته، و نکاتی برای سازمان‌هایی که علاقه‌مند به اتخاذ این معماری هستند، پرداختند. آنها تاکید می‌کنند که موفقیت در اجرای چنین تغییری نیازمند تعهد به رویکرد میکروسرویس‌ها، سرمایه‌گذاری در ابزارها و تیم‌های مرتبط، و برقراری فرهنگی است که از مشارکت و مالکیت بخشی حمایت کند. این ویدیو نمونه‌ای از چالش‌ها و راهکارهای موجود در مسیر رشد و تکامل معماری نرم‌افزاری در شرکت‌های بزرگ و پیشرفته‌ای مانند نتفلیکس است و درس‌های مهمی برای سازمان‌های دیگر در هر مقیاسی دارد.این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است مجتبی شکوری فر مجتبی شکوری فر Fri, 29 Dec 2023 23:11:33 +0330 https://virgool.io/@mojtabao121/%D8%A8%D8%B1%D8%B1%D8%B3%DB%8C-%D8%A8%D8%B1%D8%AE%DB%8C-%D8%A7%D8%B2-%D9%85%D9%88%D8%B6%D9%88%D8%B9%D8%A7%D8%AA-%D9%BE%D8%B1-%DA%A9%D8%A7%D8%B1%D8%A8%D8%B1%D8%AF-%D8%AF%D8%B1-%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-bl7eurdi4z9d توی این مقاله قصد دارم چندتا از موضوعات و کانسپت های پر کاربرد معماری نرم افزار رو بررسی کنم و یه توضیح کوتاهی به زبان ساده در مورد هر کدوم بدم صرفا برای اشنایی اولیه تا اگه علاقه به این موضوعات داشتین در موردش بیشتر تحقیق کنین . قبل از اینکه مقاله رو شروع کنم بزارین یک توضیح کوتاه راجب معماری نرم افزار بدم. معماری نرم‌افزار مجموعه قواعد و ساختارهایی است که مشخص می‌کنند چگونه نرم‌افزار ساخته شده و سازماندهی می‌شود. این ساختار نشان می‌دهد چگونه مؤلفه‌ها و اجزا در نرم‌افزار با یکدیگر تعامل می‌کنند و چگونه داده‌ها و عملیات‌ها مدیریت می‌شوند. در واقع، معماری نرم‌افزار به ما کمک می‌کند تا بفهمیم که چگونه قسمت‌های مختلف نرم‌افزار با هم ترتیب داده شده و کار می‌کنند تا یک نرم‌افزار کامل ایجاد شود. خوب دیگه مقدمه رو تموم کنیم و بریم سراغ مقاله.معماری ماژولار مونولوتیک (Modular Monolithic)یکی از الگو های رایج معماری مونولوتیک است که در ان یک برنامه یکپارچه (مونولوتیک) به قسمت های کوچک تر و مستقل (ماژولار) تقسیم می شود و هر بخش به صورت مستقل و جداگانه توسعه ، تست و نگهداری می شوند اما در پایان همه ی این بخش ها در یک برنامه یکپارچه ادغام می شوند . برای اشنایی با این معماری باید با معماری مونولوتیک و معماری ماژولار اشنا باشید زیرا ترکیب این دو است و تقریبا مزایای این دو معماری را دارد و بخشی از معایب ان ها را از بین برده است. وردپرس ، معروف ترین و پر استفاده ترین سیستم مدیریت محتوای جهان از این معماری استفاده می کند به این صورت که قسمت های مختلف مثل هسته ی اصلی وردپرس ، قالب ، افزونه و... به صورت ماژول های مختلف نگهداری و توسعه داده می شوند اما همه در یک نرم افزار وردپرس قرار دارند. مثلا وقتی می خواهید امکانات جدید به وبسایتون اضافه کنید کافی است که یک افزونه نصب کنید.سرویس‌های وب آمازون (Amazon Web Services)سرویس های وب امازون که به صورت مخفف به آن aws گفته می شود یک پلتفرم رایانش ابری است که همانطور که از نامش پیداست شرکت امازون به کاربران خدمات زیرساختی مختلفی مانند ذخیره‌سازی داده‌ها، قدرت پردازشی، پایگاه‌های داده ، یادگیری ماشین و ... را اراعه می دهد. این سرویس ها به صورت پرداخت به ازای استفاده به مشتریان فروخته می شود به این صورت که شما فقط به ازای منابع و ماشین های مجازی که استفاده میکنید هزینه پرداخت می کنید و هر زمان نیاز بیشتری داشتید به سرعت برای شما فراهم می شود.رویکرد API-firstرویکرد api first به این صورت است که ما api ها را به عنوان محصول در نظر بگیریم و در سطح معماری مهم ترین و بالاترین ارزش را برای api ها قرار دهیم. به این صورت که در فرایند تولید نرم افزار ابتدا api ها را بسازیم و سپس با توجه به ان بقیه مراحل را پیش ببریم. api اهای ساخته شده باید قابل استفاده ی مجدد و سازگار باشند. مراقب باشید که این رویکرد را با موبایل فرست اشتباه نگرید ، در رویکرد موبایل فرست api فقط بخشی از نرم افزار موبایل هستند اما در این رویکرد مهم ترین قسمت نرم افزار ما حساب می شوند.دیتابیس NoSQLپایگاه‌های داده NoSQL، که مخفف Not Only SQL است ، یک پایگاه داده متفاوت با پایگاه داده های سنتی مانند mysql و اوراکل است. در پایگاه های داده سنتی از مدل های رابطه ای استفاده می کنند که در ان ها داده ها در جدول ها توسط سطون و ردیف مدیریت می شوند و جداول با همدیگه ارتباطات خاص خود را دارند و تمامی این اطلاعات در فایل های اسکیما ذخیره می شود اما پایگاه داده NoSQL داده ها را در XML یا JSON ذخیره می کند و از اسکیما پویا استفاده می کند که این کار باعث می شود دسترسی ، کارایی ، مقیاس پذیری بالا برود. پایگاه‌های داده NoSQL انواع مختلفی دارد مانند : پایگاه‌های داده گرافی ، پایگاه‌های داده چند مدله ، ایگاه‌های داده سندی و... که هر کدوم داستان خودشون دارند که در صورت علاقه میتونین دنبال کنید.معماری بدون سرور (Serverless Architecture)همانطور که از اسم این معماری پیداست ،در معماری بدون سرور اجرای برنامه‌ها و سرویس‌ها بدون نیاز به مدیریت سرورها انجام می شود . در این معماری توسعه دهندگان تمرکزشان را فقط روی برنامه نویسی و توسعه نرم افزار ها می گذارند و دیگر کوچک ترین دغدغه ای راجب زیرساخت مانند : نگهداری سرور ها ، کم یا زیاد کردن سرور ها با افزایش یا کاهش حجم درخواست ، تعادل بار، پیاده‌سازی سرورها، مراقبت و مانیتورینگ و دیباگینگ و ... ندارند و این کار ها را شرکت های سرویس دهنده ی ابری مثل گوگل کلود و aws که بالاتر تو همین مقاله توضیح دادیم برایشان انجام می دهد. مهم ترین ویژگی این معماری این است که سرویسی که به شما داده می شود کاملا پویا است و شرکت شما باید فقط به ازای مصرفش هزینه پرداخت می کند و از هدر رفت سرمایه برای خرید سرور اضافی یا از کم اومدن سرور در صورت رشد نرم افزار و مصرف جلوگیری می کند. نتفلیکس یکی از معروف ترین شرکت هایی است که از این معماری استفاده می کند.معماری طراحی دامنه محور Domain Driven Designبهترین تعریف برای این معماری را می توانیم جمله خود مبدع این معماری اقای Eric Evans بدانیم که اکثر اطلاعات مفیدی که از این معماری است از داخل کتاب همین شخص گرفته شده است.برای ایجاد نرم افزار خوب، باید بدانید که آن نرم افزار چیست. شما نمی توانید یک سیستم نرم افزاری بانکی ایجاد کنید مگر اینکه درک خوبی از چیستی بانکداری داشته باشید، باید حوزه بانکداری را درک کنید.مفهموم دامنه در این مثال را اگه بخوام با یه مثال بگم اینکه فرض کنید شما می خواهید یک فروشگاه اینترنتی ایجاد کنید. این فروشگاه آنلاین دارای محصولات، مشتریان، سفارشات، و سایر مفاهیم مرتبط با فروش است. این مفاهیم را می‌توان به عنوان دامنه نرم‌افزار فروشگاه آنلاین شما در نظر گرفت.معماری شش ضلعی (Hexagonal Architecture)معماری شش ضلعی یک الگوی معماری نرم‌افزاری است که تمرکز اصلی آن، جداسازی منطق نرم‌افزار از زیرساخت است. در این رویکرد طراحی، نرم‌افزار به عنوان یک شش ضلعی در نظر گرفته می‌شود که در مرکز آن، منطق نرم‌افزار قرار دارد و در اطراف آن، زیرساخت قرار دارد. در این معماری، نرم‌افزار به دو بخش تقسیم می‌شود: مرکز نرم‌افزار که منطق کاربردی را شامل می‌شود و پورت‌ها و آداپتورها که ارتباط با ورودی و خروجی‌های خارجی را مدیریت می‌کنند و کاملا مستقل از زیرساخت هستند. این تفکیک این کمک را به ما می کند که فرایند تست و توسعه و تغیرات بسیار راحت تر و سریع تر انجام شود و از اتصال مستقیم به جزئیات خارجی جلوگیری می‌کند.منبع یابی رویداد (Event Sourcing)یک روش ذخیره داده در نرم‌افزار است که همه وقایع و تغییرات در سیستم را به صورت رویدادها ثبت می‌کند. به جای ذخیره وضعیت فعلی، همه تغییرات از طریق وقایع ثبت می‌شوند. این معماری امکان دسترسی به تاریخچه کامل تغییرات را فراهم می‌کند و به تحلیل و بازسازی وضعیت‌ها در زمان‌های مختلف کمک می‌کند. Event Sourcing در بسیاری از بخش‌ها و قسمت های یک سیستم، از جمله امور مالی، مراقبت‌های بهداشتی، خرده‌فروشی، حمل‌ونقل، توسعه بازی‌های ویدیویی و بسیاری موارد دیگر، کاربردهای گسترده‌ای دارد.توسعه کم کد (Low code platforms)نرم‌افزارهایی هستند که به افراد بدون تجربه گسترده در برنامه‌نویسی اجازه می‌دهند تا نرم‌افزارها و برنامه‌های کاربردی پیچیده را به سادگی ایجاد کنند همچنین این کمک را به برنامه نویسان حرفه ای می کند که با سرعت و کیفیت بالاتری نرم افزار های پیچیده ایجاد کنند. این پلتفرم‌ها از طریق ارائه ابزارها و ماژول‌های آماده، کار توسعه نرم‌افزار را ساده‌تر می‌کنند. استفاده از این پلتفرم در شرکت ها و سازمان ها باعث افزایش چابکی و چالاکی ، کاهش هزینه‌ها ، افزایش دقت در تصمیم‌گیری ، دسترسی به فناوری‌های نوین و ... می شود .سیستم‌های مدیریت فرایند کسب‌وکار(BPMS)به مجموعه‌ای از ابزارها و روش‌هایی که برای بهبود، بهینه‌سازی، و اتوماسیون فرایندهای کسب‌وکار استفاده می‌شوند Business Process Management Systems می گویند. این سیستم‌ها به سازمان‌ها کمک می‌کنند تا فرایندهای خود را به شکلی مؤثرتر مدیریت کنند و به این ترتیب بهره‌وری و کیفیت خدمات خود را افزایش دهند.این سیستم شامل اجزایی مانند نرم‌افزار مدل‌سازی فرایند، ابزارهای اتوماسیون، و داشبوردهای تحلیلی است. BPMS به کاربران اجازه می‌دهد تا فرایندهای کاری خود را شناسایی، طراحی، اجرا، نظارت و بهبود بخشند. اگه بخوایم یک مثلا عملی بزنیم مثلا یک شرکت ممکنه برای اتوماتیک کردن فرایندهایی مثل سفارشات مشتریان، مدیریت موجودی، یا پردازش حقوق و دستمزد و... از این سیستم استفاده کند.صف‌ پیام (Message Queue)صف پیام‌رسانی (Message Queue) یک سیستم نرم‌افزاری است که برای مبادله پیام‌ها بین برنامه‌ها و سیستم‌های کامپیوتری استفاده می‌شود. در واقع، این سیستم به برنامه‌ها اجازه می‌دهد تا پیام‌ها را بدون نیاز به اتصال مستقیم یا همزمان با یکدیگر ارسال و دریافت کنند. پیام‌ها می‌توانند از هر نوع داده‌ای از جمله متن، JSON، یا XML باشند.هنگامی که برنامه مقصد مشغول است یا متصل نیست، صف پیام ، پیام ارسال شده را به صورت موقت نگهداری می کند و تا زمانی که پیام توسط گیرنده دریافت نشود در ان جا ذخیره می ماند. استفاده از صف‌های پیام به سیستم‌ها امکان می‌دهد که به طور مؤثرتری با یکدیگر ارتباط برقرار کنند، کارایی سیستم را افزایش دهند و از ازدحام و بار اضافی بر سرورها جلوگیری کند. این فناوری در معماری‌های مبتنی بر میکروسرویس‌ها و سیستم‌های توزیع‌شده کاربرد فراوانی دارد.ارکستراسیون کانتینر (Container orchestration)به معنای خودکار سازی فرایند ها برای اجرا در کانتینر ها و مدیریت و کنترل گروهی از کانتینرها است که درون آنها برنامه‌ها و خدمات اجرا می‌شوند. این فناوری به ایجاد، مقیاس‌پذیری، مدیریت، و پیگیری کانتینرها کمک می‌کند . پر استفاده ترین و معروف ترین پلتفرم ارکستراسیون در کلاد ، کوبرنتیز است .معروف ترین مسئله در این مورد صحبت در مورد اپلیکیشن هاست. در گذشته فرایند های مختلف تولید و منتشر کردن نرم افزار مانند کامپایل کردن کدها، پیکر بندی اجزا ، فعالیت های سمت سرور به صورت دستی انجام می شد که این اتفاق باعث بالا رفتن خطاها و اشتباهات می شود اما امروز با استفاده از این تکنولوژی این فرایند ها به صورت خودکار انجام می شود و از بسیاری از خطا ها جلوگیری می کند.ابزار های مدیریت لاگ ( Log Management Tools )ابزارهای مدیریت لاگ (Log Management Tools) داده‌های لاگ را به طور مداوم جمع‌آوری، تجزیه و تحلیل کرده و به مدت زمان طولانی نگهداری می‌کنند. این داده‌ها برای مانیتورینگ عملکرد پویا و هشداردهی به زمان واقعی استفاده می‌شوند تا سازمان‌ها نسبت به امنیت، کارایی و سلامت سیستم‌های خود بیشترین دید و درک را داشته باشند. لاگ‌ها به تعداد زیادی در مراحل مختلف برنامه‌ها و زیرساخت‌های سیستمی تولید می‌شوند. وقتی که جمع‌آوری و به کار گرفته می‌شوند، می‌توانند به تجزیه و تحلیل اطلاعات حیاتی کمک کنند.نرم‌افزارهای مدیریت لاگ با فیلتر کردن حجم عظیم داده و تبدیل آن به اطلاعات قابل مدیریت، چارت‌ها، نقشه‌ها و خلاصه‌های ساده‌تری از فعالیت‌های شرکت ارائه می‌دهند. ابزار های نظارت فناوری اطلاعات ( Monitoring tools )نظارت بر IT یا فناوری اطلاعات، به مجموعه ابزارها و فرآیندهایی گفته می‌شود که برای تعیین کارکرد صحیح تجهیزات و خدمات IT یک سازمان و شناسایی و حل مشکلات استفاده می‌شوند. این ابزارها می‌توانند از ابزارهای ساده تا راه‌حل‌های پیشرفته‌ای که از هوش مصنوعی برای پیش‌بینی و جلوگیری از قطعی قبل از وقوع آن استفاده می‌کنند، متغیر باشند. با افزایش پیچیدگی محیط‌های IT و رشد محبوبیت رایانش ابری، نظارت بر IT به‌طور قابل توجهی تکامل یافته است. این نظارت شامل نظارت بر زیرساخت‌های مبتنی بر ابر و محلی (on-premises) می‌شود. انواع مختلفی از نظارت بر IT وجود دارد، از جمله نظارت بر دسترسی، نظارت بر عملکرد وب، مدیریت برنامه‌های کاربردی، نظارت بر API، نظارت بر کاربران واقعی، نظارت بر امنیت، و نظارت بر فعالیت‌های تجاری. نظارت بر IT می‌تواند به سه دسته کلی ابزارهای نظارتی - تحلیلی، مشاهداتی، و تعاملی - تقسیم‌بندی شود. این ابزارها به تیم‌های IT کمک می‌کنند تا درک بهتری از عملکرد سیستم‌های خود در لحظه و برای مدت زمان طولانی‌تر داشته باشند و بتوانند تصمیمات کوتاه‌مدت و بلندمدت مؤثری بگیرند.تحلیل استاتیک کد (Static Code Analysis) یک روش اشکال‌زدایی است که بدون اجرای برنامه، به‌طور خودکار کدهای منبع را بررسی می‌کند. این روش به توسعه‌دهندگان کمک می‌کند تا از انطباق، امنیت و ایمنی کد خود مطمئن شوند. تحلیل استاتیک کد به تجزیه و تحلیل کدها در برابر مجموعه‌ای از قوانین برنامه‌نویسی اطلاق می‌شود و به شناسایی نقاط ضعفی که ممکن است به آسیب‌پذیری‌ها منجر شوند، می‌پردازد. این فرآیند معمولاً در ابتدای توسعه، قبل از شروع تست‌های نرم‌افزاری انجام می‌شود و با ایجاد یک حلقه بازخورد خودکار، به توسعه‌دهندگان کمک می‌کند تا از مشکلات احتمالی کدهای خود زودتر آگاه شوند و به راحتی آنها را برطرف کنند. تحلیل استاتیک در مقایسه با تحلیل دینامیک که پس از اجرای برنامه صورت می‌گیرد، نقایص را قبل از اجرای برنامه شناسایی می‌کند. این روش دارای محدودیت‌هایی است، از جمله عدم درک از قصد توسعه‌دهنده، قوانینی که به‌طور استاتیک اجرا نمی‌شوند و احتمال گزارش اشتباهات کاذب. تحلیل استاتیک کد مزایایی از جمله سرعت، عمق و دقت در شناسایی مشکلات دارد و به بهبود کیفیت کد، افزایش امنیت، اطمینان از انطباق و افزایش کارایی کمک می‌کند. منابع :https://swagger.io/resources/articles/adopting-an-api-first-approach/ رویکرد api-firsthttps://7learn.com/blog/what-is-nosql : دیتابیس NoSQLhttps://www.eventstore.com/event-sourcing : منبع یابی رویداد https://rns.ir/blog/what-is-low-code-platforms : توسعه کم کدhttps://www.ibm.com/topics/business-process-management : مدیریت فرایند کسب‌وکارhttps://www.cloudamqp.com/blog/what-is-message-queuing.html : صف پیامhttps://www.sumologic.com/blog/log-management-tool: ابزار های مدیریت لاگhttps://xaas.ir/blog/orchestration : ارکستراسیون کانتینرhttps://www.splunk.com/en_us/data-insider/what-is-it-monitoring.html : ابزار های نظارت فناوری https://www.perforce.com/blog/sca/what-static-analysis : تحلیل استاتیک کد مجتبی شکوری فر مجتبی شکوری فر Sat, 18 Nov 2023 20:16:58 +0330 https://virgool.io/@mojtabao121/%D8%AC%D8%B2%D8%A6%DB%8C%D8%A7%D8%AA-%D8%AE%D9%84%D8%A7%D8%B5%D9%87-%D9%81%D8%B5%D9%84-15-%D8%AA%D8%A7-30-%DA%A9%D8%AA%D8%A7%D8%A8-%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D8%AA%D9%85%DB%8C%D8%B2-azp7tqm4wlwu فصل 30 بانک اطلاعات به عنوان جزئی از یک کلدر این فصل در مورد نقش و اهمیت پایگاه داده در معماری سیستم های نرم افزاری بحث شده است. پایگاه داده، از دیدگاه معماری، به عنوان یک جزئیات تلقی می‌شود که در سطح عنصرهای معماری بلند مدت نیست و نباید به معماری سیستم نفوذ کند. پایگاه داده مثل یک جزئیات کوچک در مقایسه با ساختار کلی سیستم نرم‌افزاری است. ارتباط پایگاه داده با معماری سیستم نرم‌افزاری شبیه به ارتباط یک دستگیره درب با معماری خانه‌ی شماست. راحت تر بخوام بگم پایگاده داده خیلی برای معماری مهم نیست و اهمیت انچنانی ندارد. برای همین در فصل جزئیات به ان اشاره کرده است . اما مراقب باشید که پایگاه داده را با مدل داده قاطی نکنین ، استراکچری که به داده ها تو نرم افزار می دهیم بسیار مهم است و برای معماری مهم است . در کل باید حواسمان باشد که یک جزئیات سطح پایین مانند پایگاه داده وارد معماری شود و سیستم نرم افزاری مارا الوده کند. پایگاه داده یک مکانیزم سطح پایین است که برای ذخیره کردن و دستری به داده ها استفاده می شود اما داده ها مدل داده را درست می کنند که برای معماری نرم افزار اهمیت بالایی دارند ولی پایگاه داده فقط یک وسیله یا تولز برای دسترسی به این داده هاست به همین خاطر جزو مکانیزم های سطح پایین حساب می شود. موضوع دیگری که در این فصل صحبت شد پایگاه داده رابطه ای است . دلیل اهمیت این مدل این است که به خوبی می توانند با دیسک ها ارتباط برقرار کنند. دیسک ها برای دسترسی به داده ها بسیار کنند هستند که سیستم های مدیریت پایگاه داده از روش های مختلفی استفاده می کند تا سرعت کار را بالا ببرد . اگر از دیسک ها استفاده نکنیم و همه داده در حافظی رم ذخیره بشوند داده ها به شکل لیست های پیوندی ، درخت ها ، جداول هش و... ذخیره می شوند و با استفاده از پوینتر به ان ها دسترسی پیدا میکنیم . با گذشت زمان و پیشرفت های زیاد تکنولوژی دیسک ها منسوخ شدند و جای خود را به حافظ های موقت دادند . درسته که پایگاه داده اهمیت بالایی دارد و به عنوان یک مکانیزم برای انتقال داده ها بین دیسک و حافظ موقت استفاده می شود ، اما نباید ان را در معماری دخیل کنیم . میشه پایگاه داده رو به صورت چداگانه از قوانین تجاوری و موارد کاربردی سیستم مدیریت کرد و وارد معماری نرم افزار نکردش.فصل 31 وب یک جز از کل استاین فصل در مورد تغییرات و نوسانات در طراحی و پیاده سازی سیستم های کامپیوتری صحبت می شود و به چگونگی توزیع قدرت پردازش می پردازد . همچنین می خواهد این را بیان کند که وب ، درست است که رابط کاربری است اما فقط یک جز از یک سیستم بزرگ تر است و نباید به عنوان تنها قسمت مهم سیستم در نظر گرفته شود. قدیم در بیشتر وقتا تمامی قدرت پردازش در یک مکان مرکزی مانند یک سرور جمع می کردند و بقیه دستگاها صرفا یک واسطه ی کاربری بودند. اما با گذشت زمان قدرت پردازش به دستگاه های محلی منتقل شد. البته چندین بار بین اینکه همه پردازش ها در یک مکان باشد یا تقسیم بشود بحث بود و مدادم جایگزین یکدیگر میشدند این دو روش. اصلی ترین نکته که در این فصل مطرح می شود این است که وب به عنوان یک رابط کاربری فقط یکی از جزئیات سیستم است و نباید معماران در طراحی معماری نرم افزار خود قوانین کسب و کار و دیگر اجزای سطح بالا را با جزئیات فنی مانند رابط کاربری قاطی کنن و باید مستقل باشند. اگر این نکته را رعایت کنند هر وقت تغییراتی در رابطه کاربری یا تکنولوژی های مورد استفاده قرار بگیرد که بسیار هم اتفاق می افتد ، نیاز به تغیر کلی سیستم نداریم. مثلا شما بارها می بینین که شرکت های بزرگ نرم افزاری داخل و خارجی ظاهر وبسایت خود را عوض میکنند. تصور کنین که امازون یا دیجی کالا هر بار که ظاهر خود را می خواهند عوض کنند مجبور شوند کل سیستم نرم افزار خود را کامل عوض کنند چه هزینه زیادی باید پرداخت کنند .درست است که این جدا سازی ها و محافظ از لوجیک اصلی سیستم در برابر تغییرات فنی و تکنولوژی بسیار سخت است ، اما با توجه سرعت بالای پیشرفت تکنولوژی بسیار واجب و ضروری است .فصل 32 فریم ورک ها اجزای معماری هستنددر این فصل در مورد تاثیر فریم ورک ها در معماری در نرم افزار صحبت می کند. فریم ورک ها ابزار هایی هستند که به برنامه نویسان کمک می کند تا برنامه ها را سریع تر و استاندارد تر درست کنند. فریم ورک ها بسیار قدرتمند هستند و بسیاری از ان ها رایگان در دسترس برنامه نویسان قرار گرفته اند و کمک بسیاری در تولید نرم افزار ها می کنند اما باید توجه داشته باشید که این ها به هیچ عنوان جزو معماری نرم افزار نیسند و تنها یک ابزار مناسب برای توسعه سیستم های نرم افزاری هستند. اکثر این فریم ورک ها را برنامه نویسان برای رفع مشکلات خودشان یا تیم و شرکت خودشان نوشته اند اما با توجه به کیفیت بالای ان ها و استقبال دیگران از ان در اختیار عموم قرار گرفته اند. اما استفاده از فریم ورک ها خطرات خود را دارند . باید مراقب باشید که برنامه شما به هیچ عنوان وابسته به فریم ورک ها نشوند زیر ممکن است بعضی از قسمت های ان خوب توسعه داده نشده باشد و در روند توسعه نرم افزار شما دچار مشکل شوید. در ابتدای کار فریم ورک ها بسیار کمک کننده هستند مخصوصا زمانی که نرم افزار شما کوچک است و ویژگی های خاصی ندارد . اما زمانی که نرم افزار شما بزرگ تر و پیشرفته تر شوند فریم ورک ها پاسخگوی نیاز های شما نیستند و دست و پای شمارا میگیرند و نیاز های شما از توانایی های فریم ورک خارج می شود. همچنین امکان دارد فریم ورک ها اپدیت بشوند و ویژگی های قدیمی که شما سیستم نرم افزاری خودتونو با اون ساختین از فریم ورک حذف بشود و شما دیگر نتوانید فریم ورک خودتون را اپدیت کنین و باید از همون نسخه های قدیمی استفاده کنید که ممکن است باگ های امنیتی و.. داشته باشد و از امکانات بروز فریم ورک محروم شوید. پس اگر بخواهیم به زبان ساده بگوییم بهترین کار این است که فریم ورک ها وابسته نشوید !!. به جای اینکه فریم ورک هارا جزوی از برنامه ی اصلی خودتون بکنین ، اون هارو تو یه قسمت جداگانه و مستقل قرار دهید و اجازه ندهید وارد کد های اصلی برنامه شما بشوند. فصل 33 مطالعه ی موردی : فروش ویدئودر این فصل در مورد یک نرم افزاری برای وبسایتی که ویدیو می فروشد صحبت می کند. یک دسته ویدیو داریم که میتوانیم به فرد یا شرکت ها بفروشیم . برای طراحی معماری نرم افزار سیستم ابتدا باید اکتر ها و یوز کیس هارا تعریف کنیم . در این مثال چهار اکتر داریم ، مدیر وبسایت ، نویسنده ویدیو ، کسی که ویدیو را میخرد و کسی که ویدیو را می بیند. پس تعریف بازیگران و یوز کیس ها معماری کامپوننت ها ایجاد میشود. معماری کامپوننت یک نقشه یا معماری از چگونگی تقسیم بندی و تعامل بخش های مختلف یک سیستم است.مطالعه موردی روشی است برای نشان دادن چگونگی پیاده سازی قوانین و مفاهیم و در مثال های دنیای واقعی. انطعاف پذیری در تحویل به ای ن معناست که با استفاده از معماری نرم افزار خوب می شود اجزای سیستم را به هر شکل که دوست دارید تحویل دهید و با توجه نیاز ها حتی این تحویل را تغییر دهید. فصل 34 فصل گم شده در این فصل در مورد چگونگی سازماندهی کد ها در یک پروژه صحبت می کند. ساختار لایه ای : در این روش کد ها بر اساس عملکردی فنی که دارند در لای های افقی تقسیم می شوند و کد ها مشابه از نظر وظایف در یک گروه قرار میگیرند که در عمده نرم افزار ها به سه قسمت تقسیم می شوند . لایه وب ، لایه قوانین کسب و کار و لایه دسترسی به داده ها .ساختار بر اساس ویژگی : در این روش همانطور که از نامش پیداست کد ها بر اساس ویژگی هایشان یا عناصر اصلی تقسیم می شوند. تمامی کلاس ها یا اینتر فیس های مرتبط با یک ویژگی خاص در یک دسته قرار می گیرند. پورت ها و اداپتر ها : در این روش به جداسای کد های معتمد بر دامنه از جزئیات فنی می پردازد. به زبان ساده تر کد های مرتبط با دامنه در داخل قرار دارند و کد های مرتبط با دنیای خارجی در خارج قرار میگیرند. در این روش کد های خارجی به داخلی وابسته باشند .ساختار مرتبط با کامپوننت : این روش در حقیت ترکیبی از روش های قبلیست که تازه گفته شد . در این روش به ایجاد بسته های کدی مرتبط با کامپوننت های چندگانه می پردازد. این روش به سمت معماری های مبتنی بر سرویس مانند معماری میکرو سرویس میرود . این روش را نویسنده ی کتاب که اسمش یادم نیست توصیه میکند. کد ها بر اساس کامپوننت های خود پروژه تقسیم می شوند و هر کامپوننت بسته ای از کلاس ها و اینترفیس های مرتبط ب یکی ویژگی یا بخشی از سیستم را در خود دارد . این روش می تواند کد را از لایه بندی افقی و عمودی بهبود دهد. مجتبی شکوری فر مجتبی شکوری فر Fri, 20 Oct 2023 20:10:35 +0330 https://virgool.io/@mojtabao121/%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D8%AE%D9%84%D8%A7%D8%B5%D9%87-%D9%81%D8%B5%D9%84-15-%D8%AA%D8%A7-30-%DA%A9%D8%AA%D8%A7%D8%A8-%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D8%AA%D9%85%DB%8C%D8%B2-ysxebjdyukvr فصل 15 معماری چیست؟در این فصل راجب اینکه معماری نرم افزار چیست صحبت میکنیم و نکات پیرامون ان صحبت میکنیم.معمار نرم افزار کاملا با تصور شما تفاوت دارد و اینگونه نیست که دیگر نیاز به کدنویسی نداشته باشد. درست است که معمار نرم افزار باید در سطح انتزاع بالا کار کند و از جزییات بپرهیزد اما همچنان یک برنامه نویس است و باید برنامه نویسی انجام دهد. معمار نرم افزار باید با توجه به تجربه ی بالای خود بقیه افراد تیم را به سمت درست هدایت کنند . ان ها باید برنامه نویسی را انجام دهند تا بتوانند بهتر برنامه نویسان را درک کنند و مشکلات احتمالی که برای برنامه نویسان اعضای تیم ایجاد شود را پیشبینی کند.معماری نرم افزار به نحوه ی ساختار دهی سیستم به منظور تحقق الزامات و نیاز های اصلی همزمان با تامین قابلیت تکامل و اپدیت و نگهداری ان است. اگر بخواهیم ساده تر بگوییم معماری نرم افزار ، تصمیمات اصلی در مورد ساختار یک سیستم نرم افزاری است. اگر معماری خوب باشد سیستم نرم افزاری ما نگهداری ساده تری خواهد داشت و هزینه ی کمتر مالی و انسانی برای ان خواهیم پرداخت ، اپدیت کردن و تکامل رساندن ان ساده تر باشد و می توان از ان به سادگی بارها استفاده ی مجدد کرد. اما اگر معماری ما ضعیف باشد پروسه توسعه ی نرم افزار ما بسیار دشوار می شود و تغییرات و اپدیت های اینده بسیار هزینه بر و سخت و گاها غیر ممکن می شود.تصمیماتی که در معماری نرم افزار میگیریم بسیار مهم است . در معماری تصمیماتی گرفته می شود که تغییر ان در اینده بسیار سخت است . سخت بودن به این معناست که این تغییرات یا هزینه ی بسیار زیاد مالی یا زمانی دارند یا تقریبا غیر ممکن است . انتخاب زبان های برنامه نویسی که برای پروژه ی نرم افزار انتخاب می کنیم ، انتخاب فریم ورک ها ، انتخاب پایگاه داده مورد استفاده در پروژه و... از جمله تصمیمات مهمی است که در معماری نرم افزار میگیریم. بنظر من معماری نرم افزار مثل کاشتن درخت گردو است ، نتیجه و حاصل ان را در دراز مدت خواهیم دید. در بخش توسعه در مورد این صحبت شد که معماری خوب ، فرایند توسعه را ساده تر میکند وقتی ساختار نرم افزار ما مشخص و ساده و واضح باشد برنامه نویسان راحت تر می توانند برنامه را توسعه بدهند یا تغییرات لازم را اعمال کنند. درست است که معماری به تنهایی نمی تواند عملکرد درست سیستم را گارانتی کند اما اگر معماری خوب باشد به برنامه نویسان کمک میکند که باگ ها و مشکلات را شناسایی کنند و عملکرد سیستم را بسیار بالا ببرند. معماری به شما این فرصت را می دهد تا که تصمیمات را جلو بندازید و زمانی تصمیمات را بگیریم که دانش و اگاهی کافی راجب به مسئله را داشته باشیم. در معماری نرم افزار جدید و مدرن از ادرس دهی های منطقی استفاده میکنیم ، این کار باعث می شود تا اجزای مختلف سیستم را خارج از موقعیت فیزیکی ان ها مدیریت کنیم که کار ویزایش و تغییرات را بسیار ساده تر برای ما می کند.فصل 16 استقلالهمانطور که از نام این فصل مشخص است این فصل در مورد این است که معماری نرم افزار باید به گونه ای طراحی شود که از جزییات خاص مثل تکنولوژی ها یا فریم ورک ها و .. مستقل باشد. همچنین قسمت های مختلف به هم دیگه وابسته نباشند و استقلال داشته باشند تا تیم های توسعه بتونن به صورت موازی و بدون اینکه با همدیگه تداخل داشته باشند کار هاشونو بکنن.در معماری نرم افزار بسیار مهم است که ساختار ما به گونه ای باشد که تغییر در یک قسمت یا واحد تاثیری در بخش ها و قسمت های دیگه نداشته باشه. به این مفهوم جدا سازی میگویند.قابلیت دیپلوی مستقل در این فصل گفته شد به این معناست که به توسعه دهندگان این امکان را بدهد تا قسمت های مختلف یک نرم افزار رابه صورت مستقل از یکدیگر دیپلوی کنند.اگر یوز کیس ها به درستی از یکدیگر جاداسازی شوند تیم های توسعه می توانند به سادگی بدون تداخل با یکدیگر کار کنند. هر یوز کیس به نوعی مجموعه ای از عملیات هاست این عملیات ها نشان دهنده ی تعاملات کاربر با سیستم هستند.یک معماری خوب به ما این اجازه را می دهد تا بتوانیم با تغییراتی که پیش می اید همچنان بتوانیم جدا سازی را به خوبی انجام دهیم. در نرم افزار ها از لایه بندی برای تقسیم وظایف مختلف استفاده می شود. جدا کردن این لایه ها و وظایف از یکدیگر کار ما را راحت میکنید تا به صورت مستقل هر لایه را نگهداری کنیم. باید از ادغام بی مورد یوزر کیس ها بشدت بپرهیزید حتی اگر که ساختار ظاهری ان ها یکسان باشد باز هم با گذشت زمان این یوزکیس ها احتمال دارد تغییر کنند و با یکدیگر فرق کنند. تا جای ممکن سعی کنید که یوز کیس هارا از هم مستقل کنید.جدا سازی هایی که در این فصل راجب ان صحبت کردیم میتواند در سطوح مختلفی باشد ، سطح کد منبع ، سطح دیپلوی ، سطح سرویس و ... انتخاب بین این سطج ها بستگی به نیاز ها و ویژگی های پروژه نرم افزاری ما دارد. در طول توسعه برنامه باید همیشه مراقب باشیم که کد ها را بی مورد تکرار نکنیم ، بعضی وقتا این تکرار از قصد است و برنامه نویس هدفی پشت این کار دارد در این موارد مشکلی ندارد اما باید مراقب بود تا جای ممکن از کپی های بی مورد بپرهیزیم زیرا باعث انومالی در سیستم نرم افزاری ما می شوند.در گذر زمان شاید نیاز ها یا نحوه ی دیکاپلینگ تغییر کند ، یک معمار خوب و یک معماری نرم افزار خوب باید بتواند این تغییرات را پیشبینی کند و سیستم نرم افزاری را برای این تغییرات از قبل اماده کند. همچنین یک معمار خوب باید این اجازه را بدهد که حالت های جدا سازی با توجه به نیاز های پروژه تغییر کند.فصل 17 خط مرزی : خطوط طراحیموضوع اصلی که در این فصل مطرح می شود چگونگی کشیدن مرز ها در معماری سیستم های نرم افزاری است . این مرز ها به ما کمک می کنند تغییراتی که در یک بخش از نرم افزار انجام می دهیم بقیه قسمت ها و بخش های نرم افزار مارا تحت تاثیر قرار ندهند.مرز ها بین قسمت هایی کشیده می شوند که تغییرات ان ها همدیگه رو تحت تاثیر نذارند . مثل بین رابط کاربری و قوانین کسب و کار باید مرز کشیده شود و از همه دیگه جدا باشند.معماری پلاگین به این صورت است که قسمت های نرم افزار که قابل تعویض هستند جدا باشند از بقیه بخش ها . با استفاده از معماری پلاگین مثلا پایگاه داده سیستم نرم افزاری را عوض میکنیم و بقیه قسمت های سیستم نرم افزاری ما تغییری نمیکند. به جای اینبکه یک برنامه ثابت و واحد بسازیم ، می توانیم برنامه امان را به قسمت های کوچک تر تقسیم کنیم که به ان ها پلاگین می گویند و به ساده قابل تعویض و تغییر و ارتقا هستند. در دنیای امروز که تکنولوژی به سرعت پیشرفت میکند استفاده از این معماری بسیار کار امد است . زیرا می توانیم قسمت های مختلف سیستم نرم افزاری خودمان را پلاگین های بروز تر و اپ تو دیت جایگذاری کنیم.اصل وابستگی معکوس به این معناست که به قسمت های بالاتر و اصلی تر نرم افزار نباید به قسمت های جزئی تر و پایین تر وابسته باشند. مثلا قوانین کسب و کار که جزو قسمت های اصلی سیستم نرم افزاری هستند نباید به پایگاه داده که یک قسمت سطح پایین تر نرم افزار است وابسته باشند و باید بر عکس ان باشد.اصل مسئولیت یکتا این را میگوید که هر قسمت از نرم افزار باید فقط یک دلیل برای تغییر داشته باشد. که ما با استفاده از مرزها ، قسمت های مختلف را جدا میکنیم که تغییرات بر بقیه قسمت ها تاثیری نداشته باشه.فصل 18 تشریح خط مرزیدر این فصل به بررسی چگونگی تعریف و تشخیص مرزها و اهمیت ان ها در طراحی یک سیستم می پردازد. معماری سیستم ها توسط مجوعه از اجزای نرم افزار و مرزهایی که انها را از یکدیگر جدا میکند تعریف میشوند. این اجزا در سیستم نرم افزاری باید با یکدیگر ارتباط بر قرار کنند. این ارتباطات باید جوری مدیریت شوند تا از قاطی شدن و وابستگی های بی مورد جلوگیری شود . این دقیقا اصلی ترین دلیل ایجاد مرز ها هستند. در زمان اجرا زمانی که یک تابع از یک سمت مرز یک تابع دیگه رو از سمت دیگه ی مرز فراخوانی کند می گویند از مرز عبور کرده است. زمانی که مشتری هایی با سطح بالاتر بخواهند از خدمات سطح پایین تر استفاده کنند ، بحران معماری ایجاد می شود. برای رفع این بحران ما از روش هایی نانند پلی مورفیسم دینامیکی استفاده میکنیم. نخ ها مکانیزم هایی هستند که بکد ما این اجازه را می دهند که به صورت همزمان اجرا شوند. مولفه های مستقر به صورا واحد های قابل اجرا می باشند که بدون نیاز به کامپایل مجدد قابل استفاده هستند. فرایند های محلی در یک سیستم اجرا می شوند اما در فضاهای مموری مجزا قرار دارند. فرایند هایی که می توانند در سیستم های مختلف و حتی مکان های فیزیکی مختلف اجرا شوند را خدمات یا سرویس می گویند. امروزه در بیشتر سیستم های نرم افزاری از ترکیبی از چند نوع مرز مختلف استفاده می شود. هر کدام از این مرز ها خصوصیات و ویژگیهای خاص خود را دارند و با توجه به نیاز ها و ویژگی هایی که پروژه داره ، استفاده می شوند .فصل 19 خط مشی و سطحدر این فصل راجب شرح خطی مشی صحبت میکنیم . خط مشی نرم افزار را تقریبا می توان قوانین و سیاست های سیستم ترجمه کرد که می تواند به چگونگی محاسبه قوانین کسب و کار ، چگونگی قالب بندی گزارش ها و.... توضیحات دیگر شکسته شود.هنر معماری نرم افزار این است که بتواند این قوانین را از یکدیگر جداسازی کند و چیدمان ان هارا بر اساس تغییراتشان انجام دهد. اگر دو تغییر در برای دو قانون با یک دلیل مشترک و در زمان یکسان اتفاق بیفتد باید در یک قسمت قرار بگیرند ولی اگر دلایل یا حتی زمان ان ها متفاوت باشد باید در قسمت های جداگانه ای قرار بگیرند. معماران نرم افزار این قوانین را در نمودار های بدون حلقه قرار می دهند که این نمودار ها وابستگی میان اجزای مختلف را نشان می دهند. در یک معماری خوب وابستگی ها بر اساس سطج اجزا مشخص می شوند و باید اجزای سطح پایین وابسته به اجزای سطح بالای سیستم ما باشند.معیار بالا پایین بودن سطح ، فاصله ی ان قانون از ورودی ها و خروجی هاست و هر چه قدر یک قانون از ورودی ها و خروجی ها دور تر باشد سطح ان بالاتری دارد و هر چه نزدیک تر باشد سطح پایین تری دارد. بیاید یک مثال بزنیم مثبلا در برنامه ی رمز نگاری قسمت ترجمه رمز ها از قسمت ورودی ها و خروجی ها دورتر است پس بالاترین سطح را در سیستم نرم افزاری دارد.در یک معماری نرم افزار خوب وابستگی های کد با جریان داده همیشه همسو نیست و هدف از جداسازی این دو کاهش اثر تغییرات است . مثلا همان مثال قبلی که گفتم ، در نرم افزار رمز نگار اگه یک دستگاه ورودی / خروجی تغییر کند ، الگریتم رمزنگاری و ترجمه تغییر نمیکند یا تغییر بسیار کمی دارد. فصل 20 قوانین کسب و کاردر این فصل در مورد قوانین کسب و کار صحبت شده است . قوانین کسب و کار به زبان ساده به قوانین ، دستور العمل ها و سازوکار هایی که در یک کسب و کار یا بیزنس باعث کسب درامد و تولید پول یا کاهش هزینه ها و صرفه جویی شود قوانین کسب و کار می گویند. اگر قوانین به صورت دستی هم استفاده شوند همین تاثیر را دارند. مثلا اگر ما یک فروشگاه داریم و محصولات رو به صورت قصطی میفروشیم فرقی ندارد که سودی که به ازای فروش قسطی میگیریم توسط نرم افزار محاصبه شود یا به صورت دستی ، در هر صورت به شرکت سود میرسد زیرا این یکی از قوانین کسب و کار فروشگاه ماست.در این فصل موجودیت هارا هم توضیح داده. طبق تعریف کتاب موجودیت ، یک شیء در سیستم های کامپیوتری است که مجموعه قوانین اساسی کسب و کار و همچنین داده های مرتبط با ان را اجرا می کند.اما همه ی قوانین کسب و کار مثل موجودیت ها نیستند ، بعضی از این قوانین با تعریف کردن چگونگی عملکرد یک سیستم خودکار ، کسب درامد و تولید پول میکنند ، یا در هزینه های شرکت صرفه جویی میکنند. توجه کنید که این قوانین فقط در محیط اتوماتیک معنی دارد.در مورد مدل های درخواست و پاسخ هم صبحت شد که متاسفانه خیلی متوجه نشدم چی میگه :)اگر بخواهیم این فصل را جمع بندی کنیم میتوانیم بگوییم در حقیقت قوانین کسب و کار دلیل ساخت سیستم های نرم افزاری هستند . اگر قوانین کسب و کار نباشند دلیلی برای تولید سیستم های نرم افزاری نداریم . قوانین کسب و کار هسته و مرکزی ترین قسمت سیستم نرم افزاری ما هستند. باید دقت کنیم که ان ها به دیگر اجزای سیستم وابستگی نداشته باشند و کاملا مسقل باشند تا در سیستم های مختلف بتوانیم از ان استفاده کنیم. فصل 21 معماری شگفت انگیزمعماری نرم افزار نباید فقط ابزار های استفاده شده در نرم افزار ، فریم ورک ها ، زبان های برنامه نویسی و... را نشان بدهد بلکه باید ویژگی ها و کاربرد های اصلی برنامه را نشان بدهد. مثلا وقتی نقشه ی یک مدرسه را میبینیم از ویژگی هایی که توی نقشه است متوجه میشویم که این نقشه ، نقشه ی مدرسه است و تمامی ویژگی های مهم ان را نشان میدهد نه اینکه فقط بگویید با چه موادی ساخته شده این ساختمان. در معماری نرم افزار هم باید به گونه ای عمل کنیم که تمامی ویژگی ها و کاربرد های اصلی سیستم نرم افزاری مارا نشان بدهد. یک معماری شگفت انگیز ، تصمیات مربوط به فریم ورک ها ، زبان های برنامه نویسی ، دیتابیس و.... را به تاخیز می اندازد و بر ویژگی ها و کاربرد های اصلی برنامه تاکیید دارد و ان هارا از دیگر ویژگی های جانبی جدا می کند. معماری نرم افزار شما باید سیستم نرم افزاری شمارا توضیح بدهد مثلا اگر یک سیستم نرم افزاری بانکی می سازید ، برنامه نویسان دیگری که به معماری نرم افزار شما نگاه می کنند در نگاه اول متوجه شوند که این یک سیستم بانکی است.فریم ورک ها ابزاری ها قدرتمندی هستند اما نباید معماری کلی نرم افزار مارا تعیین کند. باید به گونه ای از فریم ورک ها استفاده کرد که معماری کلی نرم افزار را تحت تاثیر قرار ندهند. برای وب هم به همین صورت است . وب هم صرفا یک مکانیسم تحویل یا رابط کاربری است و نباید معماری اصلی نرم افزار مارا تعیین کند و معماری کلی نرم افزار را تغییر دهد. یک معماری شگفت انگیز باید امکان تست کردن قسمت های مختلف سیستم نرم افزاری را بدون نیاز به وابستگی ها مانند فریم ورک و... فراهم کند. یعنی بتوانیم ویژگی های اصلی و کاربرد های نرم افزار را تست کنیم بدون اینکه به موارد خارجی وابستگی داشته باشیم.هدف اصلی از طراحی معماری نرم افزار در این فصل ( در هر فصل یک هدف اصلی دارد ) اطمینان از پشتیبانی از کاربر های و ویژگی های اصلی سیستم است و معماری باید امکان اتخاذ تصمیم ها را در مورد ابزرا ها و تکنولوژی های جدید که در اینده می اید را فراهم کند نه اینکه محدود کننده باشد.فصل 22 معماری تمیزاین فصل هم نام کتاب است پس میتوان گفت یکی از فصل های مهم است . از گذشته تا الان دیدگاه ها و روش های متفاوتی برای معماری وجود داشته است . درست است که هر کدام از معماری های نرم افزار جزئیات و ویژگی های خودشان را دارند اما هدف اصلی همه این معماری ها یک چیز است ، جدا سازی مسئولیت ها . هر چه به داخل تر می رویم و وارد جزئیات می شویم سطح انتزاع نرم افزار بالاتر می رود . بیرونی ترین دایره ها مکانسیم ها هستند و داخلی ترین دایره ها سیساست ها یا خط مشی ها هستند. وابستگی ها باید فقط به داخل اشاره کنند و دایره های داخلی نباید چیزی راجب به یک دایره ی خارجی بدانند. برای انتقال داده از یک دایره به دایره دیگر باید به جای اینکه یک لایه داخلی به یک لایه خارجی مستقیما وابسته باشد و از یک واسطه یا اینترفیس استفاده شود که لایه خارجی اجرایی کرده باشد. بعضی از داده ها که عبور می کنند معمولا ساختار داده ساده ای دارند. داده ها نباید هیچ وابستگی داشته باشند که قانون وابستگی را نقض کنند یا به زبان ساده تر نباید مستقیما از یک پایگاه داده یا فریم ورک خارجی وارد شوند. معماری هایی که گفتیم ویژگی های اصلی دارند که در این فصل اشاره شدند. سیستم بر اساس یک کتابخانه خاص ساخته نمی شود و از فریم ورک ها استقلال دارند. قوانین تجاری بدون واسط کاربری یا پایگاه های داده قابل تست هستند همچنین می توان واسطه کاربری را تغییر داد بدون اینکه قوانین تجاری و کسب و کار را تغییر کند. پایگاه داده را نیز میتوان تغییر داد و کاملا مستقل است . چند بخش دیگر هم در این فصل تعریف شده است . مانند موجودیت ها که شامل قوانین تجاری کلی سیستم هستند ، یوز کیس ها که شامل قوانین خاص نرم افزاری هستند و... . رعایت این قوانین که در این فصل گفته شد باعث می شود تا سیستم نرم افزاری تولیدی ما قابل آزمون باشد و وقتی قسمت های خارجی مانند پایگاه داده ، رابط کاربری و ... منسوخ شود می توان با حداقل هزینه ان هارا تعویض کرد و ان هارا با تکنولوژی روز دنیا بروزرسانی کرد. همچنین باعث می شود سیستم ها مقایسه پذیر شوند و نگهداری ان ها بسیار ساده تر و کم هزینه تر شوند. فصل 23 presenter و شی humbleدر این فصل در مورد humble و presenter صحبت میکنیم . الگو شی humble برای جدا کردن رفتاری های خست از اسان در تست به وجود امده اند . رفتار ها به دو کلاس تقسیم می شوند یک سخت تست می شوند و اون دیگری اسان . با استفاده از این الگو مثلا رابط های کاربری سخت تست می شوند . ما می توانیم رفتار هایی مرتبط با رابط کاربری و رفتار های قابل تست رو از همیدگه جدا کنیم و این دو رفتار را به صورت دو کلاس ارائه دهنده و نمایش دسته بندی کنیم . view شیء سخت تست است و کد در ان به حداقل ممکل محدود شده است و presenter وظیفه دارد داده ها را قالب بندی کرده و view منتقل کند. الگوی شی humble جدا سازی رفتار های یک مرز معماری را تعریف میکنند که کمک میکند معماری ها قابل تست شوند. در هر مرز معماری الگوی شیء فروتن را میتوانیم مشاهده کنیم . استفاده از این الگو در مرز های معماری تست پذیری کل سیستم را افزایش خواهد داد. فصل 24 مرز های جزئیدر این فصل به ادامه صحبتمون در مورد مرز ها میپردازیم . در بعضی وقتا نیازی به تعریف یک مرز معماری کامل نیست، بعضی وقتا ایجاد یک مرز کامل زمان بر و پر هزینه است ، برخی مواقع معماران نرم افزار امکان دارد تصمیم بگیرند تا به جای ایجاد یک مرز کامل از یک مرز جزئی استفاده کنند. این فصل در مورد همین مرز های جزئی است.ایجاد کردن یک مرز معماری کامل هزینه های بسیاری را برای ما دارد مانند واسطه های چندشکلی ، ساختار های وردوی و خروجی و.... . در بعضی مواقع معماران نرم افزار پیشبینی کنند که در اینده شاید نیاز به مرز داشته باشند و باید ان را تعریف کنند اما در حال حاظر نیازی به ان مرز نیست ، در چنین شرایطی معمولا معماران تصمیم به تعریف یک مرز جزئی میکنند. راهکار های مختلفی برای ایجاد مرز جزئی وجود دارد . یکی از این راه ها این است که تمامی کار های مورد نیاز برای ساختن مولفه های مستقل را بکنیم ولی تمامی این هارا در یک مولفه یکپارچه کنیم. روش ش مرز های یک بعدی به این صورت است که فقط یک سمت وابستگی را در نظر میگیریم . این کار ساده تر و کم هزینه تر از روش مرز های کامل است ولی در عین حال می تواند اماده سازی برای یک مرز معماری کامل باشد. اخرین سبکی که در این فصل معرفی می شود نمایه هست که یکی از ساده ترین هاست . این الگو از یک مرز ساده تر است که تنها یک کلاس نمایه تعریف می شود و حتی وابستگی های معکوسم چشم پوشی میکنیم. در پایان معمار باید تصمیم بگیرد که در کجا ممکن است یک مرز معماری وجود داشته باشد و این مرز به صورت کامل باید پیاده سازی شود یا جزئی شود.فصل 25 لایه ها و مرز هادر این فصل در مورد ساختار و معماری نرم افزار صبحت میکنیم . اکثر سیستم های ساده از سه بخش اصلی تشکیل شده اند. این سه بخش عبارتند از قوانین تجاری ، پایگاه داده و رابطه ی کاربری . این فکر که همه ی سیستم ها از همین سه بخش تشکیل شده اند اشتباه است و سیستم های بزرگ تر و پیچیده تر معمولا اجزای دیگری نیز دارند ولی میتوان این را با اطمینان گفت که اغلب سیستم ها این سه بخش را دارند و دیگر از این قدر ساده تر نیستند.در این فصل یک بازی کامپیوتری را مثال زده است و این بخش ها را در ان مشخص کرده است. نکاتی که در مورد بازی است این است که می توانیم رابط کاربری متنی بازی را جدا کنیم تا بتوانیم ان را در سیستم عامل های مختلف تولید کنیم و بتوانیم در همه سیستم عامل ها اجرا شود. همچنین باید ذخیره سازه داده ها مستقل باشند ، مهم نیست که داده ها در کجا ذخیره می شوند ، اصل مهم این است که قوانین بازی نباید از جزئیات ذخیره سازی اگاه باشند.در این فصل معماری تمیز را برای بار دیگر تعریف کرده است که به این معناست که باید به صورت مناسب و با دقت ساختاردهی و تقسیم و وظایف سیستم را مدیریت کرد . در سیستم های پیچیده تر ممکن است داده ها از چند مسیر مختلف عبور کنند ، به عنوان مثال ممکن است داده ها از طریق یک کامپیوتر لوکال به یک سرور منتقل شوند. الته حتی بازی های ساده ممکن است دارای قوانین و مکانیزم های پیچیده ای باشند . همه این ها نشان دهنده این است که در هر سیستمی می توانیم به مرزها و جدایی های معماری برخورد کنیم ، به عنوان معمار باید به طور مداوم به دنبال این مرز ها باشیم و وقتی لازم است ان ها را پیاده سازی کنیم .فصل 26 کامپوننت اصلی در این فصل در مورد مولفه یا کامپوننت اصلی صحبت میکند. در هر سیستمی حداقل یک قسمت وجود دارد که باقی قسمت ها را ایجاد میکند و هماهنگی و نظارت بر باقی قسمت ها نیز به عهده ی ان بخش است . به این قسمت کامپوننت اصلی میگوند.این قسمت وظایف مهمی دارد ، نقطه ورودی اولیه به سیستم است ، هیچ چیز جز سیستم عامل به ان وابسته نیست ، وظیفه ی ان ایجاد تمامی کارخانه ها استراتژی ها و دیگر امکانات جهانی است ، پس از ایجاد، کنترل را به قسمت‌های سطح بالای سیستم واگذار می‌کند و.... از مهم ترین وظایف کامپوننت اصلی هستند.کامپوننت اصلی یک مؤلفه سطح پایین در معماری نرم‌افزار است.، مانند یک افزونه به نرم‌افزار است که شرایط اولیه را راه‌اندازی می‌کند و منابع خارجی را جمع‌آوری می‌کند. با تصور Main به عنوان یک افزونه، می‌توان برای هر تنظیمات مختلف نرم‌افزار یک Main مختلف داشت (مانند توسعه، تست، تولید و .... ) فصل 27 سرویس ها : بزرگ و کوچک در این فصل در مورد معماری های مبتنی بر سرویس های بزرگ و سرویس های کوچک یا میکرو صبحت میکنیم که اخیرا بسیار محبوب شده اند. دلیل محبوبیت بالای این معماری ها این است که به نظر می رسد که بخش های مختلف یک سیستم ( یعنی سرویس ها ) می توانند به صورت متسقل از یکدیگر کار کنند ، اما باید توجه کرد که این موضوع به طور کامل درست نیست .فقط استفاده از سرویس ها به معنای داشتن یک معماری سرویس خوب برای سیستم نرم افزاری ما نیست ، معماری خوب در مورد چگونگی سازماندهی قسمت های مختلف یک سیستم و وابستگی سرویس ها و قسمت ها و.. به یکدیگر می گوید. سرویس هایی که فقط رفتار های برنامه را شکسته اند مانند دستورات تابع در کد هستند و همیشه برای معماری سیستم مهم نیستند. اما بعضی از این سرویس ها بسیار سودمند هستند مثلا زمانی که تسک ها را در فرایند ها یا سیستم های مختلف جدا کنند.فصل 28 مرز تستموضوع این فصل کتاب در مورد این است که ازمون ها بخشی از سیستم هستند مانند بقیه بخش های سیستم . یکی از سوال های رایج این است که ایا ازمون واقعا بخشی از ازمون هستند یا اینکه چه نوع ازمون هایی بخشی از سیستم هستند. پاسخ این است که دید معماری نرم افزار همه ازمون ها یکسان هستند و تفاوت مهمی بین ان ها نیست ، ازمون ها وابسته به قسمت های خاصی از هستند و هیچ بخشی از سیستم بع ازمون ها وابسته نیست.در هنگام طراحی ازمون باید به نکات مهمی توجه کرد ، ازمون ها باید با سیستم هماهنگ باشد وگرنه می توانند کارایی لازم را ندارند و نگهداری از ان ها نیز سخت می شود. ازمون هایی که بیش از حد وابسته به سیستم باشند هنگام تغییرات سیستم دچار تغییرات زیادی می شوند که این موضوع خودش مشکلات خاص خودش را دارد. برای رفع این مشکلات باید طراحی سیستم و ازمون به نحوی باشه که بشه بدون استفاده از ui اونارو تست کرد. برای اینکار می توان از api ها استفاده کرد تا بدون ایجاد مشکلات امنیتی یا استفاده از منابع پر ازشمون سیستم نرم افزاری رو تست کنیم .فصل 29 معماری تو کار تمیزدر این فصل در مورد اهمیت نگهداری نرم افزار در مقابل تغییرات سخت افزاری در محیط های توکار صحبت میکنیم . به صورت کلی نرم افزار ها منسوخ یا از رده خارج نمی شوند اما سخت افزار ها با گذر زمان منسوخ می شوند و باید تعویض شوند . مثلا ما دیگر از کامپیوتر های 20 سال پیش استفاده نمیکنیم . باید مراقب باشیم که نرم افزار های ما وابسته به سخت افزار نباشند تا این تغییر راحت باشد. اگر نرم افزار ما وابسته به سخت افزار ها یا فریم ورک ها باشد با گذر زمان و منسوخ شدن سخت افزار و فریمورک ، نرم افزار هم نابود می شود .یکی از وظایف معمار نرم افزار این است که مرز بین نرم افزار و سخت افزار تعبیه کند تا از مشکلاتی که بالا مطرح کردم جلو گیری شود. همچنین در این فصل در مورد اهمیت معماری تمیز توکار در توسعه نرم افزار اشاره کرده است . طراحی معماری توکار تمیز امکان تست نرم افزار خارج از سخت افزار مقصد را برای ما ایجاد میکند و این امکان را به نرم افزار ما می دهد که بدون وابستگی به سخت افزار مقصد کار کند.(تمرین تشویقی )فصل 30 بانک اطلاعات به عنوان جزئی از یک کلدر این فصل در مورد نقش و اهمیت پایگاه داده در معماری سیستم های نرم افزاری بحث شده است. پایگاه داده، از دیدگاه معماری، به عنوان یک جزئیات تلقی می‌شود که در سطح عنصرهای معماری بلند مدت نیست و نباید به معماری سیستم نفوذ کند. پایگاه داده مثل یک جزئیات کوچک در مقایسه با ساختار کلی سیستم نرم‌افزاری است. ارتباط پایگاه داده با معماری سیستم نرم‌افزاری شبیه به ارتباط یک دستگیره درب با معماری خانه‌ی شماست. راحت تر بخوام بگم پایگاده داده خیلی برای معماری مهم نیست و اهمیت انچنانی ندارد. برای همین در فصل جزئیات به ان اشاره کرده است . اما مراقب باشید که پایگاه داده را با مدل داده قاطی نکنین ، استراکچری که به داده ها تو نرم افزار می دهیم بسیار مهم است و برای معماری مهم است . در کل باید حواسمان باشد که یک جزئیات سطح پایین مانند پایگاه داده وارد معماری شود و سیستم نرم افزاری مارا الوده کند.پایگاه داده یک مکانیزم سطح پایین است که برای ذخیره کردن و دستری به داده ها استفاده می شود اما داده ها مدل داده را درست می کنند که برای معماری نرم افزار اهمیت بالایی دارند ولی پایگاه داده فقط یک وسیله یا تولز برای دسترسی به این داده هاست به همین خاطر جزو مکانیزم های سطح پایین حساب می شود.موضوع دیگری که در این فصل صحبت شد پایگاه داده رابطه ای است . دلیل اهمیت این مدل این است که به خوبی می توانند با دیسک ها ارتباط برقرار کنند. دیسک ها برای دسترسی به داده ها بسیار کنند هستند که سیستم های مدیریت پایگاه داده از روش های مختلفی استفاده می کند تا سرعت کار را بالا ببرد . اگر از دیسک ها استفاده نکنیم و همه داده در حافظی رم ذخیره بشوند داده ها به شکل لیست های پیوندی ، درخت ها ، جداول هش و... ذخیره می شوند و با استفاده از پوینتر به ان ها دسترسی پیدا میکنیم . با گذشت زمان و پیشرفت های زیاد تکنولوژی دیسک ها منسوخ شدند و جای خود را به حافظ های موقت دادند .درسته که پایگاه داده اهمیت بالایی دارد و به عنوان یک مکانیزم برای انتقال داده ها بین دیسک و حافظ موقت استفاده می شود ، اما نباید ان را در معماری دخیل کنیم . میشه پایگاه داده رو به صورت چداگانه از قوانین تجاوری و موارد کاربردی سیستم مدیریت کرد و وارد معماری نرم افزار نکردش.فصل 31 وب یک جز از کل استاین فصل در مورد تغییرات و نوسانات در طراحی و پیاده سازی سیستم های کامپیوتری صحبت می شود و به چگونگی توزیع قدرت پردازش می پردازد . همچنین می خواهد این را بیان کند که وب ، درست است که رابط کاربری است اما فقط یک جز از یک سیستم بزرگ تر است و نباید به عنوان تنها قسمت مهم سیستم در نظر گرفته شود. قدیم در بیشتر وقتا تمامی قدرت پردازش در یک مکان مرکزی مانند یک سرور جمع می کردند و بقیه دستگاها صرفا یک واسطه ی کاربری بودند. اما با گذشت زمان قدرت پردازش به دستگاه های محلی منتقل شد. البته چندین بار بین اینکه همه پردازش ها در یک مکان باشد یا تقسیم بشود بحث بود و مدادم جایگزین یکدیگر میشدند این دو روش.اصلی ترین نکته که در این فصل مطرح می شود این است که وب به عنوان یک رابط کاربری فقط یکی از جزئیات سیستم است و نباید معماران در طراحی معماری نرم افزار خود قوانین کسب و کار و دیگر اجزای سطح بالا را با جزئیات فنی مانند رابط کاربری قاطی کنن و باید مستقل باشند. اگر این نکته را رعایت کنند هر وقت تغییراتی در رابطه کاربری یا تکنولوژی های مورد استفاده قرار بگیرد که بسیار هم اتفاق می افتد ، نیاز به تغیر کلی سیستم نداریم. مثلا شما بارها می بینین که شرکت های بزرگ نرم افزاری داخل و خارجی ظاهر وبسایت خود را عوض میکنند. تصور کنین که امازون یا دیجی کالا هر بار که ظاهر خود را می خواهند عوض کنند مجبور شوند کل سیستم نرم افزار خود را کامل عوض کنند چه هزینه زیادی باید پرداخت کنند .درست است که این جدا سازی ها و محافظ از لوجیک اصلی سیستم در برابر تغییرات فنی و تکنولوژی بسیار سخت است ، اما با توجه سرعت بالای پیشرفت تکنولوژی بسیار واجب و ضروری است .فصل 32 فریم ورک ها اجزای معماری هستنددر این فصل در مورد تاثیر فریم ورک ها در معماری در نرم افزار صحبت می کند. فریم ورک ها ابزار هایی هستند که به برنامه نویسان کمک می کند تا برنامه ها را سریع تر و استاندارد تر درست کنند. فریم ورک ها بسیار قدرتمند هستند و بسیاری از ان ها رایگان در دسترس برنامه نویسان قرار گرفته اند و کمک بسیاری در تولید نرم افزار ها می کنند اما باید توجه داشته باشید که این ها به هیچ عنوان جزو معماری نرم افزار نیسند و تنها یک ابزار مناسب برای توسعه سیستم های نرم افزاری هستند. اکثر این فریم ورک ها را برنامه نویسان برای رفع مشکلات خودشان یا تیم و شرکت خودشان نوشته اند اما با توجه به کیفیت بالای ان ها و استقبال دیگران از ان در اختیار عموم قرار گرفته اند.اما استفاده از فریم ورک ها خطرات خود را دارند . باید مراقب باشید که برنامه شما به هیچ عنوان وابسته به فریم ورک ها نشوند زیر ممکن است بعضی از قسمت های ان خوب توسعه داده نشده باشد و در روند توسعه نرم افزار شما دچار مشکل شوید. در ابتدای کار فریم ورک ها بسیار کمک کننده هستند مخصوصا زمانی که نرم افزار شما کوچک است و ویژگی های خاصی ندارد . اما زمانی که نرم افزار شما بزرگ تر و پیشرفته تر شوند فریم ورک ها پاسخگوی نیاز های شما نیستند و دست و پای شمارا میگیرند و نیاز های شما از توانایی های فریم ورک خارج می شود. همچنین امکان دارد فریم ورک ها اپدیت بشوند و ویژگی های قدیمی که شما سیستم نرم افزاری خودتونو با اون ساختین از فریم ورک حذف بشود و شما دیگر نتوانید فریم ورک خودتون را اپدیت کنین و باید از همون نسخه های قدیمی استفاده کنید که ممکن است باگ های امنیتی و.. داشته باشد و از امکانات بروز فریم ورک محروم شوید.پس اگر بخواهیم به زبان ساده بگوییم بهترین کار این است که فریم ورک ها وابسته نشوید !!. به جای اینکه فریم ورک هارا جزوی از برنامه ی اصلی خودتون بکنین ، اون هارو تو یه قسمت جداگانه و مستقل قرار دهید و اجازه ندهید وارد کد های اصلی برنامه شما بشوند.فصل 33 مطالعه ی موردی : فروش ویدئودر این فصل در مورد یک نرم افزاری برای وبسایتی که ویدیو می فروشد صحبت می کند. یک دسته ویدیو داریم که میتوانیم به فرد یا شرکت ها بفروشیم . برای طراحی معماری نرم افزار سیستم ابتدا باید اکتر ها و یوز کیس هارا تعریف کنیم . در این مثال چهار اکتر داریم ، مدیر وبسایت ، نویسنده ویدیو ، کسی که ویدیو را میخرد و کسی که ویدیو را می بیند. پس تعریف بازیگران و یوز کیس ها معماری کامپوننت ها ایجاد میشود. معماری کامپوننت یک نقشه یا معماری از چگونگی تقسیم بندی و تعامل بخش های مختلف یک سیستم است.مطالعه موردی روشی است برای نشان دادن چگونگی پیاده سازی قوانین و مفاهیم و در مثال های دنیای واقعی. انطعاف پذیری در تحویل به ای ن معناست که با استفاده از معماری نرم افزار خوب می شود اجزای سیستم را به هر شکل که دوست دارید تحویل دهید و با توجه نیاز ها حتی این تحویل را تغییر دهید.فصل 34 فصل گم شدهدر این فصل در مورد چگونگی سازماندهی کد ها در یک پروژه صحبت می کند.ساختار لایه ای : در این روش کد ها بر اساس عملکردی فنی که دارند در لای های افقی تقسیم می شوند و کد ها مشابه از نظر وظایف در یک گروه قرار میگیرند که در عمده نرم افزار ها به سه قسمت تقسیم می شوند . لایه وب ، لایه قوانین کسب و کار و لایه دسترسی به داده ها .ساختار بر اساس ویژگی : در این روش همانطور که از نامش پیداست کد ها بر اساس ویژگی هایشان یا عناصر اصلی تقسیم می شوند. تمامی کلاس ها یا اینتر فیس های مرتبط با یک ویژگی خاص در یک دسته قرار می گیرند.پورت ها و اداپتر ها : در این روش به جداسای کد های معتمد بر دامنه از جزئیات فنی می پردازد. به زبان ساده تر کد های مرتبط با دامنه در داخل قرار دارند و کد های مرتبط با دنیای خارجی در خارج قرار میگیرند. در این روش کد های خارجی به داخلی وابسته باشند .ساختار مرتبط با کامپوننت : این روش در حقیت ترکیبی از روش های قبلیست که تازه گفته شد . در این روش به ایجاد بسته های کدی مرتبط با کامپوننت های چندگانه می پردازد. این روش به سمت معماری های مبتنی بر سرویس مانند معماری میکرو سرویس میرود . این روش را نویسنده ی کتاب که اسمش یادم نیست توصیه میکند. کد ها بر اساس کامپوننت های خود پروژه تقسیم می شوند و هر کامپوننت بسته ای از کلاس ها و اینترفیس های مرتبط ب یکی ویژگی یا بخشی از سیستم را در خود دارد . این روش می تواند کد را از لایه بندی افقی و عمودی بهبود دهد. مجتبی شکوری فر مجتبی شکوری فر Thu, 19 Oct 2023 19:04:06 +0330