https://virgool.io/feed/@ali.kalate89 fa 2026-06-10 12:33:29 https://files.virgool.io/upload/users/1711328/avatar/qBa7Ux.jpeg?height=120&width=120 https://virgool.io/@ali.kalate89 https://virgool.io/@ali.kalate89/%D9%85%D8%A7%DA%A9%D8%B1%D9%88%D8%B3%D8%B1%D9%88%DB%8C%D8%B3-%D9%87%D8%A7-%DA%A9%D8%A7%D9%86%D8%AA%DB%8C%D9%86%D8%B1%D9%87%D8%A7-%D9%88-%D8%A7%D8%B1%D8%AA%D8%A8%D8%A7%D8%B7-%D8%A7%DB%8C%D9%86-%D8%AF%D9%88-%D8%A8%D8%A7%D9%87%D9%85-j4owvokmgblk کمی تاریخچهمنبع دقیق عبارت "میکروسرویس" نامشخص است، اما می توان گفت که آن را Martin Fowler، نویسنده و معمار نرم افزار معروف، در پست وبلاگی خود با عنوان "میکروسرویس" که در سال 2014 منتشر شد، معرفی کرد. در این پست وبلاگی، Fowler معماری میکروسرویس را بعنوان روشی برای ساخت و استقرار سامانه های نرم افزاری بعنوان یک مجموعه از خدمات جداگانه قابل استقرار، کوچک و ماژولار توصیف کرد.مفهوم میکروسرویس به نوعی بخاطر عدم رضایت کافی از معماری monolithic در توسعه پذیری و پردازش های سریع به بازار آمد. با پیشرفت روز افزون تکنولوژی و همچنین افزایش درخواست نرم افزارهایی برای تمام جنبه های زندگی، نیاز بود که نرم افزارها بزرگتر شده و مهم تر از آن به سرعت، پاسخگوی تعداد زیادی درخواست باشند. میکروسرویس بعنوان راهی برای حل این مشکلات توصیف شد، با تقسیم یک برنامه monolithic بزرگ به خدمات کوچکتر که می تواند بصورت مستقل توسعه و مستقر شود.اولین برنامه های مبتنی بر میکروسرویس توسط شرکت هایی مانند آمازون و نتفلیکس توسعه یافتند، که به عنوان پیشگامان در استفاده از این روش برای ساخت سیستم های نرم افزاری گسترش پذیر و flexible بودند. در این برنامه های اولیه، میکروسرویس برای بهبود گسترش پذیری و قابلیت اطمینان سیستم ها و تسریع روند توسعه و توزیع نرم افزار استفاده شد.مارتین فاولر، دانشمند نرم‌افزار، نویسنده و سخنران مشهور در جامعه توسعه نرم‌افزار است. او برای تخصص خود در الگوهای طراحی نرم‌افزار و معماری شناخته می‌شود و نوشته های بی‌نظیری در این زمینه دارد. از معروف ترین نوشته های او میتوان به "Refactoring: Improving the Design of Existing Code" و "Patterns of Enterprise Application Architecture" اشاره کرد که خواندن آنها برای هر توسعه دهنده و هر معمار نرم افزاری واجب است. همچنین او عضو پیشرو در توسعه روش های Agile است. مارتین فاولر به عنوان یکی از شخصیت‌های مهم در صنعت توسعه نرم‌افزار است و به پیشرفت توسعه نرم‌افزار در چارچوب کارآمد، کمک زیادی کرده است.حالا که به صورت خیلی خلاصه به مرور تاریخی ماکروسرویس ها پرداختیم، به سراغ توضیحات تکمیلی و فنی آن می رویممیکروسرویس چیست؟میکروسرویس یک سبک معماری برای ساخت نرم‌افزارهای کاملاً مقیاس پذیر و flexible، بر پایه ایده تقسیم یک برنامه بزرگ و مونولیتیک به سرویس‌های کوچک‌تر و مستقل، که با هم با استفاده از API ها در تعامل هستند، معرفی می شود.هر میکروسرویس برای یک مسئولیت خاص طراحی می شود، مانند مدیریت کاربران یا پردازش پرداخت، و می‌تواند بدون وابستگی به سایر میکرسرویس ها، توسعه داده، منتشر شده و مدیریت شود. این روش در سال‌های اخیر به دلیل مزایای زیادی که دارد، مانند راحت‌تر شدن نگهداری، دوره های سریع‌تر توسعه و منتشر شدن و بهتر شدن تحمل خطا، طرفداران زیادی پیدا کرده است. همچنین، میکروسرویس‌ها می‌توانند با زبان‌های برنامه نویسی مختلف و بر روی پلتفرم‌های مختلف اجرا شوند که این مسئله میتواند به توسعه چند تیم مختلف در کنار هم بر روی یک نرم افزار منجر شود که یکی از الزامات اصلی توسعه نرم افزاری در جهان فعلی ست.اگر بخواهیم اشاره ای کوتاه و لیست مانند به مزایای اصلی این معماری داشته باشیم باید بگوییم:مقیاس‌پذیری: میکروسرویس‌ها را می‌توان به‌طور مستقل مقیاس‌بندی کرد و به سازمان‌ها این امکان را می‌دهد تا بدون نیاز به استقرار مجدد کل برنامه، به سرعت به تغییرات تقاضا پاسخ دهند.انعطاف پذیری: از آنجا که هر میکروسرویس می تواند به طور مستقل توسعه یافته و مستقر شود، تیم ها می توانند از زبان های برنامه نویسی، ابزارها و فناوری هایی استفاده کنند که به بهترین وجه نیازهای هر سرویس را برآورده می کند.تاب آوری: اگر یک میکروسرویس از کار بیفتد، کل برنامه را از بین نمی برد. در عوض، سیستم به کار خود ادامه می دهد و امکان بازیابی سریعتر و کاهش زمان خرابی را فراهم می کند.قابلیت نگهداری بهبود یافته: نگهداری و اصلاح میکروسرویس ها آسان تر است زیرا هر سرویس دارای پایگاه کد کوچکتر و متمرکزتری است.زمان رسیدن به بازار سریعتر: تیم ها می توانند میکروسرویس ها را به صورت موازی توسعه داده و مستقر کنند، که می تواند زمان ورود به بازار را برای ویژگی ها و پیشرفت های جدید سرعت بخشد.تست پذیری: طراحی ماژولار امکان تست نویسی مستقل برای هر سرویس را فراهم می کند و همچنین میتوان به راحتی ارتباط میان سرویس ها، بار قابل تحمل هر سرویس و این قبیل مسائل را نیز تست کرد.برای ایجاد و راه اندازی موثر میکروسرویس ها، داشتن ارتباط و همکاری خوب بین تیم ها، API های تعریف شده و فرهنگ DevOps قوی که بر یکپارچه سازی مداوم، استقرار مستمر و نظارت تاکید دارد، مهم است. علاوه بر این، سازمان‌ها باید وابستگی‌های بین میکروسرویس ها و همچنین داده‌هایی را که تولید و مصرف می‌کنند را به دقت مدیریت کنند تا از ثبات و امنیت سیستم اطمینان حاصل شود.همان طور که می بینید پیاده سازی ماکروسرویس نیازمند مجموعه ای از مفاهیم و عملکردهایی ست که تا قبل از آن انقدر مهم نبودند و یا حتی مطرح نشده بودند. یکی از مفاهیمی که ارتباط تنگاتنگی با پیاده سازی این معماری دارد، CI/CD یا یکپارچه سازی و استقرار مداوم است. بدون درک این مفهوم، درک ماکروسرویس ناقص است. پس گذری به آن بزنیم.یکپارچه سازی و استقرار مداوم یا CI/CD یک روش توسعه نرم افزار است که هدف آن خودکارسازی ساخت، آزمایش و استقرار برنامه های کاربردی نرم افزار است. هدف CI/CD این است که سازمان‌ها را قادر سازد تا به‌روزرسانی‌ها و ویژگی‌های نرم‌افزار را به دفعات و با کیفیت بالاتر به مشتریان ارائه دهند.در معماری میکروسرویس، CI/CD اهمیت ویژه ای دارد، زیرا هر میکروسرویس جزء مجزا و مستقلی از برنامه کلی است. با CI/CD، تیم‌ها می‌توانند فرآیند ساخت، آزمایش و استقرار میکروسرویس‌ها را خودکار کرده، خطر خطاها را کاهش داده و سرعت تحویل را افزایش دهند.در CI/CD، هرگاه تغییری در یک پایگاه کد میکروسرویس ایجاد شود، pipeline به طور خودکار فرآیند build و آزمایش را آغاز می کند. در صورت موفقیت آمیز بودن آزمایشات، میکروسرویس سپس در محیط production مستقر می شود. این به تیم‌ها امکان می‌دهد تا به سرعت و به آسانی تغییرات در میکروسرویس‌ها را تأیید کرده، آن تغییرات را پیاده‌سازی کنند، بازخورد سریع ارائه دهند و کیفیت کلی برنامه را بهبود بخشند.به طور خلاصه، استفاده از CI/CD در معماری میکروسرویس، سازمان ها را قادر می سازد تا نرم افزار را سریعتر، با کیفیت بالاتر و با ریسک کمتر ارائه دهند. همچنین انعطاف پذیری بیشتری را برای تیم ها فراهم می کند، زیرا می توانند به طور مستقل تغییراتی در میکروسرویس ها ایجاد کنند و آن تغییرات را به طور لحظه ای اعمال کنند.حال برای درک بهتر کمی به سراغ مقایسه می رویم. مقایسه با دیگر معماری های معروفمیکروسرویس ها اغلب با سایر سبک های معماری از جمله معماری یکپارچه(monolithic) و معماری سرویس گرا (SOA) مقایسه می شوند.معماری یکپارچه یک رویکرد سنتی برای توسعه نرم‌افزار است که در آن یک برنامه کاربردی به عنوان یک واحد منفرد و کاملاً متصل ساخته می‌شود. تمام اجزای برنامه، از جمله رابط کاربری، منطق تجاری و لایه دسترسی به داده ها، در یک پایگاه کد واحد ترکیب شده و به عنوان یک برنامه واحد مستقر می شوند.در یک معماری یکپارچه، تغییرات در برنامه نیاز به بازسازی و استقرار مجدد کل پایگاه کد دارد که مدیریت آن زمان بر و چالش برانگیز است. علاوه بر این، با افزایش پیچیدگی برنامه، درک، آزمایش و نگهداری آن دشوارتر می شود که منجر به افزایش خطر خطا و کاهش کارایی می شود.در مقایسه با معماری یکپارچه، معماری میکروسرویس چندین مزیت از جمله قابلیت نگهداری بهبود یافته، چرخه‌های توسعه و استقرار سریع‌تر و تحمل خطای بهتر را ارائه می‌دهد. علاوه بر این، میکروسرویس‌ها را می‌توان به زبان‌های برنامه‌نویسی مختلف نوشت و بر روی پلتفرم‌های مختلف اجرا کرد، که آنها را با تغییرات سازگارتر و برای طیف وسیع‌تری از موارد استفاده مناسب‌تر می‌کند.همان طور که در متن بالا خواندید، معماری یکپارچه کار را برای توسعه مداوم و پیشرفت پروژه سخت می کند. همین مسئله که یک پایگاه کد داریم کار را به قدری سخت می کند که دیگر سراغ بررسی دیگر مسائل نرویم. اما این مطلب را هم در نظر داشته باشید که این حرف ها به این معنی نیست که این معماری منسوخ شده است و دیگر کسی سراغ آن نمی رود. هنوز نرم افزارهایی هستند که انتخاب این معماری برای آنها مناسب تر از دیگر معماری هاست و یک معمار نرم افزار باید تمام راه های ممکن را برای شروع کار خود در نظر داشته باشد.حال به سراغ دیگر معماری مهم می رویم.معماری سرویس گرا (SOA) یکی دیگر از سبک های معماری است که شامل تجزیه یک برنامه یکپارچه به سرویس های کوچکتر و مستقل است. با این حال، سرویس‌های SOA معمولاً بزرگ‌تر و تمرکز کمتری نسبت به میکروسرویس‌ها دارند، و اغلب به‌طور محکمی با هم مرتبط هستند، به این معنی که تغییرات در یک سرویس می‌تواند بر بسیاری دیگر تأثیر بگذارد. میکروسرویس و SOA شباهت‌هایی دارند، مانند استفاده از API برای برقراری ارتباط بین سرویس‌ها و تمرکز بر تجزیه یک برنامه یکپارچه به اجزای کوچک‌تر. با این حال، میکروسرویس‌ها معمولاً کوچک‌تر، متمرکزتر و کمتر از سرویس‌های SOA متصل هستند، که باعث انعطاف‌پذیری بیشتر و اصلاح پذیری آنها می‌شود.هر دوی اینها، رویکردهایی برای ساخت و استقرار سیستم های نرم افزاری هستند، اما تفاوت های کلیدی بین این دو وجود دارد.اندازه سرویس: در SOA، سرویس‌ها بزرگ‌تر و جامع‌تر هستند و چندین عملکرد تجاری را انجام می‌دهند. از سوی دیگر، میکروسرویس‌ها کوچک‌تر و متمرکزتر هستند و یک عملکرد تجاری خاص را انجام می‌دهند. اتصال: سرویس‌های SOA معمولاً به‌طور محکم با هم مرتبط هستند، به این معنی که تغییرات در یک سرویس می‌تواند بر بسیاری دیگر تأثیر بگذارد. این می‌تواند تغییر یا به‌روزرسانی سرویس‌ها را بدون تأثیر بر کل سیستم دشوار کند. از طرف دیگر، میکروسرویس‌ها به گونه‌ای طراحی شده‌اند که به‌طور آزادانه جفت شوند، به این معنی که تغییرات یک سرویس بر سایر خدمات تأثیری نمی‌گذارد و اصلاح یا به‌روزرسانی سرویس‌ها را آسان‌تر می‌کند.توسعه و استقرار: در SOA، توسعه و استقرار معمولاً متمرکزتر و هماهنگ تر است و یک تیم واحد، مسئول نظارت بر کل سیستم است. در میکروسرویس‌ها، توسعه و استقرار غیرمتمرکزتر است و تیم‌های جداگانه مسئول هر سرویس هستند.مقیاس‌پذیری: مقیاس‌پذیری سیستم‌های SOA ممکن است دشوار باشد، زیرا تغییرات در یک سرویس می‌تواند بر بسیاری دیگر تأثیر بگذارد. از سوی دیگر، میکروسرویس ها برای مقیاس پذیری طراحی شده اند و هر سرویس می تواند به طور مستقل مقیاس پذیر باشد.پشته فنی: سیستم‌های SOA معمولاً از یک پشته فنی مشترک استفاده می‌کنند که همه سرویس‌ها با استفاده از زبان‌ها، ابزارها و فناوری‌های برنامه‌نویسی یکسان توسعه یافته‌اند. از سوی دیگر، میکروسرویس‌ها را می‌توان به زبان‌های برنامه‌نویسی مختلف نوشت و بر روی پلتفرم‌های مختلف اجرا کرد. این مسئله میکروسرویس را برای طیف وسیعی از موارد استفاده مناسب می‌کند.برای جمع بندی میتوان گفتSOA و میکروسرویس ها نقاط قوت و ضعف خاص خود را دارند و انتخاب بین این دو به نیازهای خاص یک پروژه بستگی دارد. SOA برای پروژه هایی که نیاز به یک رویکرد متمرکز و هماهنگ برای توسعه و استقرار دارند، مناسب است، در حالی که میکروسرویس ها برای پروژه هایی که به انعطاف پذیری، مقیاس پذیری و کنترل غیرمتمرکز نیاز دارند، مناسب هستند. اگر بخواهیم مثال هایی برای کاربرد SOA بزنیم: سیستم های مدیریت فرآیند کسب و کار (BPM): سیستم های BPM به سازمان ها کمک می کند تا فرآیندهای تجاری را خودکار و مدیریت کنند. SOA می تواند برای ادغام سیستم های BPM با سایر برنامه های نرم افزاری مانند سیستم های ERP یا CRM استفاده شود تا راه حلی جامع برای مدیریت فرآیند ارائه دهد.میان‌افزار یا middleware: میان‌افزار برای ادغام نرم‌افزارها و سیستم‌های مختلف در یک سازمان استفاده می‌شود. SOA می‌تواند برای تعریف رابط‌های بین این سیستم‌ها مورد استفاده قرار گیرد که امکان تبادل یکپارچه داده‌ها و عملکرد را فراهم می‌کند.این دو نمونه فقط مثال هایی بودند برای این درک که همواره تنها راه حل میکروسرویس ها نیستند و معماری های دیگر نیز همچنان کاربردهای خاص خود را دارند اما به طور کلی میتوان گفت که در دنیای امروز و با توجه به گسترش نیازهای نرم افزاری و سرعت بالای تغییر در نیازمندی ها، میکروسرویس کاربرد بیشتری نسبت به دیگر معماری ها پیدا کرده است.فقط جدا کردن سرویس ها یا نحوه دیگری از تفکر معماری؟ اغلب وقتی در مورد میکروسرویس ها حرف زده می شود ذهن به سمت جدا کردن سرویس ها می رود. یعنی همه چیز حول محور سرویس ها و جدا کردن آنها و نحوه تعامل آنها با هم میچرخد و کمتر کسی به عوامل دیگر توجه می کند. حتی در توضیحات بالا که مقدمه ای بر میکروسرویس ها بود نیز بیشتر مسئله حول سرویس ها و جدا سازی آنها بود. اما میکروسرویس فقط همین است؟ یک معمار با درک همین مسئله میتواند یک نرم افزار به به صورت میکروسرویس پیاده سازی کند؟ منابع و بزرگان معماری نظرشان چیست؟به منظور توسعه برنامه‌های کاربردی به روش میکروسرویس، باید طراحی را بیشتر از سرویس های مجزا و مستقل تصور کنید. این به این معنی نیست که طراحی سرویس ها را می توان نادیده گرفت. درست همانطور که اتومبیل ها و عابران پیاده برای طراحی یک سیستم ترافیکی ضروری هستند، سرویس ها نیز جزء کلیدی یک سیستم میکروسرویس هستند. اما فکر کردن به شرایط سرویس ها و نحوه پیاده سازی شان به تنهایی کافی نیست. در عوض باید در نظر بگیرید که چگونه تمام جنبه های سیستم می توانند با هم کار کنند تا یک رفتار را شکل دهند. در این سبک معماری رفتارها را میتوان چیزی بیشتر از جمع تک تک سرویس ها دانست. میتوان به آن به چشم رفتار سیستم در زمان اجرا و هنگام بالا بودن نرم افزار نگاه کرد.یک سیستم میکروسرویس شامل همه چیزهایی در مورد سازمان است که به برنامه ای که تولید می کند مربوط می شود. این به این معنی ست که ساختار سازمان شما، افرادی که در آنجا کار می‌کنند، نحوه کار و خروجی‌هایی که تولید می‌کنند همگی از عوامل مهم سیستم هستند. دقیقا همان طور که عناصر معماری زمان اجرا مانند هماهنگی سرویس، رسیدگی به خطا و شیوه های عملیاتی مهم هستندعلاوه بر گستردگی موضوعی که باید در نظر بگیرید، چالش دیگری نیز وجود دارد که همه این عناصر به هم مرتبط هستند. تغییر در یک قسمت از سیستم می‌تواند تأثیر پیش‌بینی‌نشده‌ای بر قسمت دیگر داشته باشد. به عنوان مثال، تغییر اندازه یک تیم پیاده سازی می تواند تأثیر عمیقی بر کاری که تیم پیاده سازی تولید می کند داشته باشد.اگر تصمیمات درست را در زمان های مناسب اجرا کنید، می توانید بر رفتار سیستم تاثیر گذاشته و رفتارهای مورد نظر خود را تولید کنید. اما اغلب گفتن آن آسان تر از انجام آن است. دست و پنجه نرم کردن با همه این عناصر سیستم به طور همزمان دشوار است. در واقع، تصور مفهومی تمام بخش‌های پویای سیستم میکروسرویس در ذهن‌، ممکن است دشوار باشد و میتوان گفت برخلاف سادگی ای که میکروسرویس ها در توسعه و تولید یک نرم افزار ایجاد می کنند، سیستم های میکروسرویس و پیاده سازی آنها پیچیده هستند!دانشمندان نیز زمانی که با سیستم های پیچیده کار می کنند با چالش مشابهی روبرو می شوند. با وجود تمام قطعات به هم پیوسته، درک نحوه کار این قطعات با هم بسیار دشوار است. به طور دقیق تر، پیش‌بینی نتایجی که می‌تواند از تغییر در سیستم به وجود بیاید دشوار است. حتی اگر مانند میکروسرویس قطعات سیستم را ماژولار و جدا جدا طراحی کرده باشیم باز هم به دلیل ارتباط تنگاتنگ کارکردی این قطعات با هم کار بسیار دشوار است و در حقیقت این همان چالش اصلی معماری میکروسرویس است. پس چه میتوان کرد؟ همان کاری که دانشمندان در زمان مواجه با یک مشکل می کنند. مدل طراحی می کنیم.یک مدل طراحی میکروسرویس شامل پنج بخش است: سرویس ها، راه حل، فرآیند و ابزار، سازمان و فرهنگ.حال به اختصار در مورد هر یک توضیحاتی می دهیم.سرویس :‌ پیاده سازی میکروسرویس ها و API های خوب طراحی شده برای یک سیستم میکروسرویس ضروری است. در یک سیستم میکروسرویس، سرویس ها، بلوک‌های ساختمان را تشکیل می‌دهند که کل سیستم از آن ساخته می‌شود. اگر بتوانید طراحی، محدوده و جزئیات سرویس ها را به درستی انجام دهید، می‌توانید رفتارهای پیچیده‌ای را از مجموعه‌ ی ساده ای از سرویس ها دریافت کنیدراه حل: معماری راه حل از طراحی سرویس های مجزا متمایز است، زیرا به نوعی نمای کلان سیستم ما را نشان می دهد. هنگام طراحی یک میکروسرویس خاص، تصمیمات شما با نیاز به تولید یک خروجی، خروجی خود سرویس، محدود می شود. برعکس، هنگام طراحی یک معماری راه حل، تصمیمات شما با نیاز به هماهنگی همه ورودی ها و خروجی های چند سرویس هماهنگ می شود. این دیدگاه در سطح کلان از سیستم به طراح اجازه می دهد تا سیستم مطلوب تری را ایجاد کند. به عنوان مثال، یک معماری راه حل که ویژگی های توسعه، ایمنی و مسیریابی را فراهم می کند، می تواند پیچیدگی هر سرویس را کاهش دهد.فرایندها و ابزار:‌ سیستم میکروسرویس فقط یک محصول جانبی از اجزای سرویس نیست که درخواست ها را در زمان اجرا مدیریت می کنند. رفتار سیستم همچنین نتیجه فرآیندها و ابزارهایی است که در سیستم برای انجام کار استفاده می شود. در سیستم میکروسرویس، این معمولا شامل ابزار و فرآیندهای مربوط به توسعه نرم افزار، استقرار کد، نگهداری و مدیریت محصول می شود. انتخاب فرآیندها و ابزارهای مناسب عامل مهمی در ایجاد رفتار درست و مناسب سیستم میکروسرویس است. به عنوان مثال، اتخاذ فرآیندهای استاندارد مانند DevOps و Agile یا ابزارهایی مانند کانتینرهای Docker می تواند تغییرپذیری سیستم را افزایش دهد.سازمان: نحوه کار ما اغلب محصول این است که با چه کسی کار می کنیم و چگونه ارتباط برقرار می کنیم. از دیدگاه میکروسرویس، طراحی سازمانی شامل ساختار، جهت اختیارات، جزئیات و ترکیب تیم ها می شود. بسیاری از شرکت هایی که در معماری میکروسرویس موفق بوده اند به طراحی سازمانی خود به عنوان یک عنصر کلیدی اشاره می کنند.فرهنگ:‌ در میان همه حوزه‌های سیستم میکروسرویس، فرهنگ شاید ناملموس‌ترین حوزه باشد، اما میتوان گفت مهم‌ترین آنها نیز هست. ما می‌توانیم فرهنگ را به‌عنوان مجموعه‌ای از ارزش‌ها، باورها یا ایده‌آل‌ها تعریف کنیم که بین همه کارکنان یک سازمان مشترک است. فرهنگ سازمان مهم است زیرا تمام تصمیماتی که افراد درون سیستم می گیرند را شکل می دهد. این دامنه نفوذ زیاد همان چیزی است که آن را به ابزار قدرتمندی در طراحی سیستم شما تبدیل می کند. هر طور که آن را بسنجید، فرهنگ اغلب نشانه ای از تأثیر سایر بخش های سیستم بر همدیگر است. ایده‌آل‌های مشترک، نحوه انجام کار افراد را شکل می دهد. این ماهیت به هم پیوسته سیستم است.تمام مطالب گفته شده در مورد این مدل طبیعتا میتواند تغییر کند و به سبک نرم افزار مورد نظر در بیاید. اما دلایل ذکر آنها این بود که دیدگاه سطحی را از معماری میکرسرویس برداریم و به آن به چشم فقط یک سیستم متشکل از سرویس های جدا نگاه نکنیم. میکروسرویس در معنای کلی تر یک فرهنگ است که از نحوه ارتباط افراد با هم، تا نحوه کارکرد و توزیع منابع سخت افزاری را تحت تاثیر قرار می دهد و یک معمار نرم افزاری باید به تمام این مسائل اگاهی کامل داشته باشد.حال به سراغ ابزارها می رویم و سعی می کنیم آشنایی کلی و خلاصه واری از آنها بدست بیاوریم.ابزارهاابزارهای زیادی برای ساخت و استقرار میکروسرویس ها وجود دارد، از جمله:رجیستری خدمات: رجیستری خدمات یک مخزن مرکزی است که فهرستی از تمامی سرویس های موجود و وضعیت فعلی آنها را نگهداری می کند. نمونه‌هایی از ثبت سرویس ها عبارتند از Netflix Eureka، Consul و Zookeeperدروازه API یا API Gateway: یک API Gateway سروری است که به عنوان یک نقطه ورودی برای همه میکروسرویس ها عمل کرده و مسیریابی درخواست، ترکیب و ترجمه پروتکل ها و غیره را مدیریت می کند. معروف ترین نمونه آن که بیشترین کاربرد در صنعت را دارد kong استLoad Balancer: متعادل کننده بار ابزاری است که درخواست های دریافتی را در چندین نمونه از یک میکروسرویس توزیع می کند و به بهبود قابلیت اطمینان و مقیاس پذیری کمک می کند.نظارت و ثبت گزارش: ابزارهای پایش و ثبت گزارش به پیگیری سلامت و عملکرد میکروسرویس ها کمک می کنند. نمونه‌هایی از ابزارهای نظارتی عبارتند از New Relic، Datadog و Prometheus، در حالی که نمونه‌هایی از ابزارهای گزارش‌گیری شامل ELK Stack، Fluentd و Graylog هستند.سرور پیکربندی: سرور پیکربندی یک مخزن مرکزی برای داده های پیکربندی(configuration) است که توسط میکروسرویس ها استفاده می شود. نمونه‌هایی از سرورهای پیکربندی عبارتند از Spring Cloud Config، HashiCorp Vault و ZooKeeper.هماهنگ‌سازی کانتینر: ابزارهای هماهنگ‌سازی کانتینر به مدیریت استقرار، مقیاس‌بندی و مدیریت کانتینرها کمک می‌کنند، که جزء کلیدی میکروسرویس‌ها هستند. نمونه هایی از ابزارهای مدیریت کانتینر عبارتند از Kubernetes، Docker Swarm و Apache Mesos. در ادامه مقاله بحث کانتینرها و ارتباط آنها با میکروسرویس ها به تفصیل مورد بحث قرار می گیرد.Service Mesh: سرویس مش یک لایه زیرساخت قابل تنظیم برای میکروسرویس ها است که ویژگی هایی مانند مدیریت ترافیک، تعادل بار و امنیت را ارائه می دهد. نمونه هایی از ابزارهای مش خدمات عبارتند از Istio، Linkerd، و Consul Connect.اینها تنها چند نمونه از ابزارهای موجود برای ساخت و استقرار میکروسرویس ها هستند. ابزارها و فناوری های خاص مورد استفاده، به نیازهای خاص یک پروژه و ترجیحات تیم توسعه بستگی دارد. یکی از چالش های معماری میکروسرویس همین تعدد ابزارهای مختلف و نیاز به هماهنگی بین آنها و انتخاب ابزار درست برای نرم افزار می باشد که معمار نرم افزار باید در همان مراحل اولیه تولید نرم افزار بتواند انتخاب خوبی از این ابزارها داشته باشد. البته از نظر تجربه شخصی تولید و توسعه نرم افزار، انتخاب ابزار بیشتر به عهده تیم آن سرویس است و معمار بیشتر نیازسنجی می کند.کانتینر چیست؟کانتینرها روشی سبک و کارآمد برای اجرای برنامه‌ها ارائه می‌کنند، زیرا آنها فقط شامل حداقل اجزای ضروری مانند کتابخانه‌ها و فایل‌های پیکربندی هستند. این بدان معناست که کانتینرها نسبت به ماشین‌های مجازی سنتی (VM) بسیار کوچک‌تر و سریع‌تر راه‌اندازی می‌شوند، که به یک سیستم عامل کامل نیاز دارند و ممکن است چند دقیقه طول بکشد تا راه‌اندازی شوند.Containerization روشی برای بسته بندی برنامه های نرم افزاری در کانتینرها است که می توانند به طور مداوم در محیط های محاسباتی مختلف اجرا شوند. ایده کلیدی پشت کانتینری‌سازی، جداسازی یک برنامه کاربردی و وابستگی‌های آن در یک واحد واحد است که به راحتی قابل حمل و اجرا در هر سرویس و یا host ای باشد.کانتینرها همچنین بسیار قابل حمل هستند، زیرا می توانند با هر سیستمی که دارای محیط اجرا کانتینر است، سازگار باشند. به عنوان نمونه از این محیط های اجرا میتوان به داکر اشاره کرد که در ادامه توضیحاتی در مورد آن نیز داده می شود.همین مسئله قابل حمل بودن باعث می‌شود که انتقال کانتینرها بین محیط‌های مختلف، مانند لپ‌تاپ توسعه‌دهنده به محیط آزمایشی یا از محیط آزمایشی به محیط production، آسان شود.یکی دیگر از مزایای مهم کانتینری سازی این است که به بهبود سازگاری و قابلیت اطمینان استقرار نرم افزار کمک می کند. کانتینرها به توسعه دهندگان این امکان را می دهند که یک برنامه کاربردی و وابستگی های آن را در یک image قرار دهند که می تواند در یک محیط کنترل شده آزمایش و تایید شود. این کمک می کند تا اطمینان حاصل شود که یک برنامه زمانی که در مرحله production استقرار می یابد همانطور که انتظار می رود اجرا شود.علاوه بر این، کانتینرها نسبت به مجازی سازی سنتی سطح بالاتری از امنیت و ایزوله را ارائه می دهند. کانتینرها در محیط ایزوله خود اجرا می شوند، که به جلوگیری از نقض امنیت و کاهش خطر بدافزار یا سایر کدهای مخرب دیگری که بر سایر کانتینرها یا سیستم میزبان تأثیر می گذارد، کمک می کند.در نتیجه، کانتینری‌سازی جزء کلیدی توسعه نرم‌افزار مدرن است، زیرا راهی انعطاف‌پذیر، کارآمد و ایمن برای بسته‌بندی و استقرار برنامه‌های کاربردی نرم‌افزاری ارائه می‌دهد. Containerization به بهبود سازگاری و قابلیت اطمینان استقرار نرم‌افزار کمک می‌کند و انتقال برنامه‌ها را بین محیط‌های مختلف، از توسعه گرفته تا آزمایش و production، آسان‌تر می‌کند.حال که درک کلی از کانتینرها پیدا کردیم به سراغ ارتباط آن با میکروسرویس ها می رویم.ترکیب کانتینرسازی و ماکروسرویس ها به طور کلی دارای فایده هایی ست:قابلیت حمل: با بسته‌بندی هر میکروسرویس در کانتینر خود، توسعه‌دهندگان می‌توانند اطمینان حاصل کنند که هر سرویس می‌تواند روی هر سیستمی اجرا شود. این امر انتقال میکروسرویس ها را بین محیط های مختلف، از توسعه گرفته تا آزمایش و production، آسان می کند. تا قبل از کانتینرها، بسیار پیش می آمد که کدها بر روی لپ تاپ و یا سیستم توسعه دهنده کار کنند اما در زمان استقرار روی سرور به مشکل بخورند. این مشکلات عمدتا به دلیل عدم تطابق نسخه وابستگی های کد بود. اما با وجود کانتینرها، تمام وابستگی ها و پکیج های مورد نیاز هر سرویس، با خود آن در یک image قرار می گیردمقیاس پذیری: کانتینرها مقیاس پذیری میکروسرویس ها را آسان می کنند، زیرا هر سرویس می تواند بر روی host جداگانه خود اجرا شود، یا چندین نمونه از همان سرویس را می توان در host های مختلف اجرا کرد. این به توسعه دهندگان این امکان را می دهد که به راحتی تعداد نمونه های یک سرویس را برای برآورده کردن تقاضاهای در حال تغییر، افزایش یا کاهش دهند.تاب آوری: میکروسرویس ها با تقسیم یک برنامه بزرگ به اجزای کوچکتر و مستقل، ایجاد یک سیستم انعطاف پذیرتر را آسان تر می کنند. اگر یکی از سرویس ها خراب شود، روی بقیه سیستم که می توانند به طور عادی به کار خود ادامه دهند تأثیری نخواهد داشت. علاوه بر این، کانتینرها به ایزوله کردن هر سرویس کمک می کنند، که خطر انتشار خرابی بین سرویس ها را کاهش می دهد.انعطاف‌پذیری: معماری میکروسرویس‌ها به شما امکان می‌دهد برنامه‌هایی بسازید که می‌توانند در طول زمان با آسان‌کردن افزودن، حذف یا به‌روزرسانی سرویس‌ها تکامل یابند. این امکان پاسخگویی سریع و کارآمد به نیازها و فناوری های در حال تغییر کسب و کار را فراهم می کند. کانتینرها بسته بندی و استقرار این خدمات را آسان می کنند و امکان اجرای آنها را در هر زیرساختی ممکن می سازند.سهولت استقرار: کانتینرها، بدون توجه به محیط، استقرار خدمات را به طور مداوم و قابل اعتماد آسان می کنند. آنها یک قالب استاندارد برای packaging برنامه ها ارائه می دهند که انتقال آنها از توسعه به production را آسان می کند. علاوه بر این، کانتینرها را می توان به راحتی مدیریت و سازماندهی کرد و امکان استقرار و مدیریت ماکروسرویس ها را به صورت خودکار فراهم می کند.بهبود استفاده از منابع: کانتینرها به شما امکان می دهند چندین سرویس را روی یک host واحد اجرا کنید که می تواند استفاده از منابع را بهبود بخشد و هزینه ها را کاهش دهد. کانتینرها همچنین مدیریت منابع مورد نیاز هر سرویس را آسان می کنند که به بهینه سازی استفاده از منابع کمک می کند.حال اگر با دقت بیشتری به ارتباط کانتینرها و ماکروسرویس ها نگاه کنیم متوجه می شویم که پیاده سازی معماری ماکروسرویس بدون داشتن کانتینرها تقریبا غیر ممکن است. به همین دلیل کانتینرسازی از مهم ترین مسائلی ست که در این معماری مورد توجه قرار می گیرد و انتخاب ابزار مناسب برای آن از واجبات کار یک معمار است. اما این ابزارها چه هستند؟ در ادامه به معرفی آنها می پردازیم.ابزارهای کانتینری، فناوری های نرم افزاری هستند که برای ایجاد، مدیریت و اجرای کانتینرها استفاده می شوند. برخی از ابزارهای محبوب کانتینرسازی عبارتند از:داکر( Docker ): داکر پرکاربردترین ابزار کانتینری‌سازی است. بستری برای ساخت، انتقال و اجرای کانتینرها فراهم می کند. داکر به شما امکان می دهد یک برنامه کاربردی و وابستگی های آن را در یک Dockerfile تعریف کنید و سپس یک image داکر بسازید که می تواند به عنوان یک کانتینر اجرا شود. داکر همچنین یک مخزن متمرکز برای ذخیره و به اشتراک گذاری image داکر فراهم می کند که توزیع و همکاری در کانتینرها را آسان می کند.Kubernetes: Kubernetes یک سیستم مدیریت کانتینر منبع باز است که برای مدیریت و خودکارسازی استقرار، مقیاس‌بندی و مدیریت کانتینرها استفاده می‌شود. Kubernetes یک صفحه کنترل متمرکز برای مدیریت کانتینرها و خودکارسازی استقرار، مقیاس‌بندی و مدیریت کانتینرها ارائه می‌کند.Apache Mesos: Apache Mesos یک سیستم مدیریت cluster منبع باز است که برای مدیریت کانتینرها و سایر برنامه ها استفاده می شود. Mesos یک پلتفرم مقیاس پذیر و مقاوم در برابر خطا برای اجرای کانتینرها و سایر برنامه ها ارائه می دهد و با ابزارهای محبوب کانتینری مانند Docker و Kubernetes ادغام می شود.این ابزارها برای ساخت و مدیریت کانتینرها خوب هستند زیرا محیطی سازگار و قابل پیش بینی برای اجرای برنامه ها فراهم می کنند. آنها خودکارسازی استقرار، مقیاس بندی و مدیریت کانتینرها را آسان می کنند که می تواند به بهبود سرعت، قابلیت اطمینان و کارایی تحویل برنامه کمک کند. علاوه بر این، ابزارهای کانتینری اجرای برنامه‌ها در محیط‌های مختلف، از جمله مراکز داده داخلی، cluods و محیط‌های ترکیبی را ممکن می‌سازد، که می‌تواند به بهبود انعطاف‌پذیری و مقیاس‌پذیری برنامه‌ها کمک کند. دقت داشته باشید که اینها فقط نمونه هایی از ابزارها هستند که به طور عمومی شناخته شده تر می باشند و برای راه اندازی یک سیستم مدیریت و اجرا برای کانتینرها، نیاز به دانش بیشتر و شناختی مناسب از نیازمندی نرم افزار می باشد.هدف از این مقاله نسبتا مفصل، بررسی خلاصه واری از معماری میکروسرویس، کانتینرها و ارتباط این دو با هم است. هدف این بود که دیدگاه ساده ای که اغلب به میکروسرویس وجود دارد، عمیق تر شود و از حالت یک سیستم متشکل از سرویس های مختلف به ایده تفکری آمیخته با سازمان و فرهنگ تبدیل شود. در ادامه بررسی خلاصه وار ابزارها نیز برای آشنایی بیشتر خواننده و داشتن ایده اولیه برای هر کدام است. طبیعی ست که برای درک بهتر هر کدام نیاز به مطالعه مفصل و عمیق تری ست که نقطه شروع آن میتواند منابع همین مقاله باشد.منابعکتاب فوق العاده Microservice Architecture نوشته Irakli Nadareishvili چاپ شده توسط انتشارات O'Reily. اگر میخواهید با تمام وجود همه چیز معماری میکروسرویس را درک کنید حتما این کتاب را بخوانید. میتوانید در سایت هایی مانند libgen نیز آن را دانلود کرده و لذت ببرید. کتاب تقریبا تکمیل است و دیدگاه بسیار کاملی از تمام جنبه های میکروسرویس به شما می دهد.لینک گذاشته شده مقاله مارتین فاولر در مورد میکروسرویس هاست. متن روانی دارد که تا آخر شما را همراه خود می برد و خیلی دقیق بیشتر مسائل را بیان کرده. برای شروع حتما متن مناسبی ست.این مقاله در سایت مدیوم خیلی روان مسئله کانتینرها را بررسی کرده و توضیحات خوبی را ارائه داده. توصیه میکنم برای شروع سراغ این مقاله برویدمقاله ای کوچک در مورد داکر و کوبرنتیس و نحوه یادگیری آنها. اگر قرار به یادگیری این دو دارید حتما این مطلب را بخوانید و به لینک های دیگری که ارجاع داده مراجعه کنید. دید کاملی از مسیر یادگیری اینها می دهد.در ادامه باید بگویم بعضی مطالب استفاده شده در متن،‌ از دانش کم و تجربه اندک خودم بوده و طبیعتا میتواند دارای اشکال هم باشد. اگر این طور است و نیاز به اصلاح دارد حتما اطلاع بدهید. خوشحال میشم :) ali kalate ali kalate Fri, 10 Feb 2023 01:50:34 +0330 https://virgool.io/@ali.kalate89/%D8%AA%DA%A9%D9%84%DB%8C%D9%81-%D8%A7%D8%AE%D8%AA%DB%8C%D8%A7%D8%B1%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-jvtikevce6n5 مخفف Enterprise Service Bus هست یعنی گذرگاه سرویس سازمانی. به زبان ساده وقتی چندین برنامه مختلف داریم، و این برنامه ها میخوان با هم ارتباط برقرار کنن، این ارتباط میتونه 2 به 2 باشه اما مشکلی که وجود داره اینه که ممکنه همین پیچیدگی سیستم رو بالا ببره و مشکلاتی رو برامون بوجود بیاره و سیستم به شدت شلوغ بشه، پس بهتره از یک واسط یا گذرگاه استفاده کنیم که تمام برنامه هایی که میخوان با هم ارتباط برقرار کنن، درخواستشونو به این گذرگاه بفرستن و با این گذرگاه اصطلاحا صحبت کنند، حالا دیگه هر برنامه میتونه پروتکل خاص خودشو داشته باشه، پس الان سیستم ها در واقع از هم جدا هستند و بدون آگاهی از همدیگه میتونن از هم استفاده کنند و یکپارچه سازی این وسط شکل گرفته و ارتباطات اینها بسیار راحتتر شد. حالا به سازمان یا شرکتی فکر کنید که چندین وب سرویس مختلف رو ارائه میده یا میفروشه، با استفاده از ESB، سرویس گیرنده ها میتونن فارغ از اینکه چه پروتکلی تو این وب سرویس ها استفاده شده، از اونها استفاده کنن و خدمت بگیرن، پس ESB برای چنین سازمان هایی خیلی مناسبه و باعث امنیت بیشتر هم میشه. اما یکی از مهم ترین معایب ESB این هست که اگه خطایی داخل ESB رخ بده میتونه کل این سرویس ها رو مختل کنه و هیچ کاری انجام نشه. ali kalate ali kalate Fri, 30 Dec 2022 23:34:41 +0330 https://virgool.io/@ali.kalate89/%D8%A8%D8%B1%D8%B1%D8%B3%DB%8C-%DA%86%D9%86%D8%AF-%D9%85%D9%81%D9%87%D9%88%D9%85-%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-scbvyrytbg9u در این مقاله به صورت خیلی خلاصه و سطحی به سراغ ۲۰ مفهوم در معماری می رویم و هدف مان این است که اگر جایی درباره اینها صحبت شد، حداقل درکی سطحی از موضوع بحث داشته باشیم. سعی می شود در پایان منابعی نیز برای هر کدام معرفی شود تا اگر نیاز و علاقه به مطالعه بیشتر داشتید،‌ به سراغ آنها بروید.۱ ) رویکرد طراحی دامنه محور (Domain-Driven Design): با خواندن نام این رویکرد طبیعتا اطلاعات خاصی به ما داده نمی شود و حتی ممکن است گیج شویم. اصلا منظور از دامنه چیست؟ طراحی براساس دامنه دقیقا به چه صورت است؟ خب برای فهم این معماری باید اول به سراغ یک مفهوم برویم و آن هم دامنه است. دامنه به نوعی دلیل وجود نرم افزار است. کاربر برای چه دلیلی با آن نرم افزار کار می کند؟ آن دلیل می شود دامنه. به تعریف تخصصی میتوان گفت دامنه بیانگر حوزه کلی یک نرم افزار است. مثلا دیجی کالا یک دامنه فروش است. حالا تکلیف طراحی دامنه محور چیست؟ به طور کلی این طراحی می گوید که زبان و کد یک نرم افزار که به نوعی زیربنا و اجزای اصلی تشکیل دهنده آن هستند باید با دامنه آن مطابقت داشته باشد. به زبان دیگر، تعامل پیوسته و عمیق بیزینس و کسب و کار با توسعه نرم افزار است. در ادامه جمله ای از اریک اوانز، خالق این معماری بخوانیم : برای ایجاد نرم افزار خوب، باید بدانید که آن نرم افزار چیست. شما نمی توانید یک سیستم نرم افزاری بانکی ایجاد کنید مگر اینکه درک خوبی از چیستی بانکداری داشته باشید، باید حوزه بانکداری را درک کنید.برای مطالعه بیشتر :‌ مطلبی نسبتا مفصل با توضیحاتی در مورد مفاهیم خاص این معماری :‌ لینک برای بررسی تخصصی تر و نگاهی عمیق به این معماری :‌ لینک ۲ )‌ معماری شش ضلعی (Hexagonal Architecture) : معماری هگزاگونال یا معماری پورت و آداپتور، نوعی از معماری نرم افزار است که در آن ورودی کاربر و یا سرویس های خارجی در تعاملی دو طرفه با نرم افزار از طریق پورت و آداپتور هستند. این مسئله باعث ایجاد یک لایه ایزوله شده و جدا برای بدنه اصلی نرم افزار می شود که در تعاملات از تغییر مصون می ماند. حتی میتوان گفت که این لایه ایجاد شده برای بدنه نرم افزار باعث می شود که منطق نرم افزار پیاده شده ما از تغییر تکنولوژی ها نیز در امان باشد و تغییری نکند. چرا که ما یک سری پورت و اداپتور داریم که به عنوان درگاه ورودی و خروجی نرم افزار عمل کرده و نوعی کنترل را اعمال می کنند. اما سوالی که پیش مي آید این است که اصلا این پورت و آداپتور به چه معناست و کار آنها چیست؟ به طور خلاصه میتوان پورت را یک درگاه ورودی و خروجی دانست که امکان تعامل با نرم افزار را از طریق آداپتورها فراهم می کند. مانند تعامل با دیتابیس، سرویس اعتبارسنجی کاربران و غیره. اداپتور اما به نوعی تعامل با نرم افزار از طریق پورت را از طریق یک تکنولوژی خاص ارتباطی فراهم می کند. به عنوان مثال REST Controller نشان دهنده یک آداپتور است که بر پایه تعاملات REST ارتباط با نرم افزار را ممکن می کند. نکته مهم این است که یک پورت میتواند چندین آداپتور داشته باشد که به نسبت نیاز ورودی و یا خروجی آن پورت تعیین می شوند. برای درک بهتر به شکل زیر نگاه کنید.برای مطالعه بیشتر به این لینک مراجعه کنید. ۳) معماری CQRSبیاید دستورها را از کوئری ها جدا کنیم. این شعار اصلی این روش است. حتی اگر بخواهیم دقیق تر بگوییم شهود اصلی این معماری این است که محل ذخیره داده از محل برگرداندن داده جدا باشد. البته به این معنا نیست که باید و حتما دو دیتابیس داشته باشیم بلکه بیشتر تلاش برای جداسازی این دو سرویس است. در بیشتر سامانه های نرم افزاری خواندن اطلاعات از وارد کردن آن و یا به روزرسانی اطلاعات بیشتر اتفاق میفتد، پس با این روش به خوبی میتوان به روی هر سرویس تمرکز جداگانه ای گذاشت و یا حتی در صورت نیاز منابع هر کدام را متفاوت تعیین کرد. حتی در بعضی نرم افزارها، خواندن داده ها از یک دیتابیس no sql انجام می شود و یا نوشتن اطلاعات بر روی یک دیتابیس relational صورت می گیرد و یا برعکس. در کل این معماری یک نوع تفکیک میان مسئولیت بر روی دیتابیس انجام می دهد که شاید به تنهایی یک معماری مستقل نباشد اما میتواند تاثیر بزرگی بر روی معماری کلی سیستم بگذارد. به عنوان مثال شما در می يابید که خواندن اطلاعات شما بسیار بیشتر از نوشتن اطلاعات صورت می گیرد. خب این مسئله باعث می شود که شما دید بهتری نسبت به سامانه خود داشته باشید و با کمک آن بقیه مسائل را هم تغییر دهید.اما در این معماری با تمام مزایایی که ایجاد می کند مشکلات پیچیدگی زیاد و در صورت استفاده از دو دیتابیس مشکلات sync بودن آنها با هم ایجاد می شود. بعضا دیده می شود که یک دیتابیس برای سرچ ایجاد می کنند مانند elasticsearch که سرعت خوبی دارد در این زمینه و دیتابیس اصلی را به عنوان مثال Mongo می گذارند. این کار سرعت خوبی در عملکرد سیستم ایجاد می کند اما هماهنگی داده ها و به روزرسانی آنها مسئله مهمی ست که باید در نظر گرفت.برای اطلاعات بیشتر و صرفا داشتن یک دید کلی :‌ لینکاطلاعات تکمیلی تر و روش های مختلف پیاده سازی هم این لینک مناسب است.۴) مفهوم MVVMاین معماری نرم افزار را به ۳ بخش کلی Model,View,View Model تقسیم می کند و هدف اصلی آن جدایی توسعه رابط کاربری و UI نرم افزار از منطق آن و یا Backend است به طوری که رابط کاربری هیچ وابستگی ای به چیستی Backend و یا زبان آن نداشته باشد. در این مفهوم و یا در حالت بزرگتر معماری، منظور از Model همان لایه داده است و هر چیزی که به آن مربوط می شود. مانند API و یا Database. دقت داشته باشید که به این لایه میتوان repository‌ هم گفت چرا که محلی ست که تمام فعالیت های مرتبط به اطلاعات از قبیل ذخیره و خواندن در آن اتفاق میفتد. منظور از View همان رابط کاربری و یا ظاهر نرم افزار است و لایه سوم که ViewModel خوانده می شود نقشی ارتباطی میان آنها دارد. این لایه به نوعی یک تبدیل کننده است و کار آن تبدیل اطلاعات خروجی Model است به صورتی که به راحتی مدیریت شده و نمایش داده شوند. به این شکل نگاه کنید. منبع آب میتواند همان repository باشد و آب داخل آن همان داده یا اطلاعات. ما آب را از تانک میگیریم و به آشپرخانه می بریم که میتواند همان viewModel باشد. در آنجا یک تصفیه آب قرار دارد که آب را تصفیه کرده و قابل استفاده برای کاربر می کند. این همان View‌ است. در این معماری اضافه، حذف و یا تغییر یک عملکرد راحت تر است چرا که لایه ها جدایی خوبی دارند. مخصوصا که لایه Backend جدایی خوبی از لایه frontend دارد و همچنین با تغییرات منطق برنامه میدانیم که لایه ظاهری آن دچار آسیب نمی شود و همینطور میتوان تست های راحت تر و بهتری برای هر بخش نوشت.۵) مفهوم Micro-Frontendدر سال های اخیر و با گسترش استفاده از میکروسرویس ها که برای backend و توسعه سرویس ها به کار می رود ایده استفاده از چنین سبک توسعه ای به دیگر بخش ها نیز راه پیدا کرد. همچنین مشکلات کار به سبک مونولیتیک بر روی فرانت اند باعث شد بیشتر از قبل نیاز به چندگانگی این تکنولوژی و تقسیم آن به سبک بک اند احساس شود. اما میکروفرانت اند چیست؟‌طراحی و توسعه فرانت اند به سبکی که شامل تکه های کوچک قابل پیاده سازی، دیپلوی و تست مستقل باشد و جامعیت آنها بتواند یک رابط کاربری و یا یک UI را تشکیل دهد را میکرو فرانت اند می گویند. مزایای این روش را میتوان در چند مورد به صورت خلاصه بیان کردکدهای قابل تغییر و تعمیر کوچک ترتوسعه راحت تر مخصوصا در زمانی که پروژه به سمت بزرگتر یا scaling می روداما در کنار اینها میتواند به دانلود بیشتر بایت و یا duplication در کد نیز منجر شود.بیشتر مفاهیم میکروفرانت اند همانند میکروسرویس ها توسعه پیدا کرده و عرضه شده است اما نکته مهم در این زمینه این است که به آن صورت که باید و شاید فریمورک ها و یا منابعی برای توسعه جدی به این سبک به وجود نیامده و میتوان گفت جامعه توسعه دهندگان هنوز در حال توسعه این روش می باشد. بالاخره باید در نظر گرفت که این روش در سال ۲۰۱۶ تازه موجودیت پیدا کرد. بیشتر تمرکز و دلیل وجود ایده میکرفرانت اند، همانطور که در شکل نیز میتوان دید، دیپلوی جداگانه کامپوننت ها و یا قسمت های مختلف فرانت می باشد که میتواند به توسعه سریعتر و دقیقتر منجر شود. تصور کنید که دیگر نیاز نیست برای تغییرات یک بخش کوچک در سایت تمام پروژه را بیلد بگیرید و نسخه ای از آن تهیه کنید. برای مطالعه بیشتر ولی نه خیلی مفصل : لینکبرای در آوردن ته توی همه چیز :‌ لینک ۶)‌ مفهوم Api Gatewayبه طور خلاصه میتوان API GW یک ابزار مدیریت API ها معرفی کرد که میان کاربر و سرویس های بک اند می نشیند. اما کار آن چیست؟ خب API GW فراخوانی های انجام شده را دریافت می کند،‌ پاسخ سرویس های مورد نیاز برای پاسخ به فراخوانی را جمع می کند و در نهایت در قالبی مناسب کاربر، آن را برمیگرداند. اما اصلا استفاده از API GW به زحمتش می ارزد؟خب بیاید کمی از مشکلاتی که در نبود آن ایجاد می شود صحبت کنیم. در قدم اول باید توجه داشت که اگر فراخوانی های سرویس های شما به راحتی و توسط آدرس خودشان قابل استفاده باشند، شما تمام بک اند خود را در معرض عموم گذاشته اید و به راحتی میتوان آنها را از کار انداخت و یا در سامانه اخلال ایجاد کرد. از طرفی دیگر چطور میتوانید محدودیت فراخوانی روی آن بگذارید و یا به افراد مشخصی فقط اجازه فراخوانی بدهید؟ شاید بگویید به راحتی میتوان در بک اند یک سیستم لاگین پیاده سازی کرد. اما باید توجه داشته باشید که با این کار باز هم بار اضافی روی سرویس خواهید انداخت چرا که درخواست فرد باز هم به سرویس های شما خواهد رسید. مسئله بعدی تغییر آدرس و یا اضافه کردن API های جدید و از کار انداختن قدیمی هاست. شما طبیعتا دوست ندارید با هر تغییر آدرسی که به هر دلیلی اتفاق می افتد(مثلا تغییر سرور)، به مشتری آدرس جدید بدهید. این کار به کسب و کار شما آسیب میزند. شما همواره باید مشتری را از پیچیدگی سرویس های زیرساختی و بک اندی دور نگه دارید و API GW یکی از بهترین راه های این کار است. عملکرد آن در این مورد به خوبی شبیه به یک Revearse proxy است اما با قدرت بیشتر.یک مورد مهم دیگر که شاید اغلب به آن توجهی نمی شود. اگر کسب و کار شما و یا سرویس های شما زیاد فراخوانی شوند و یا بخواهید درکی از نحوه کارکرد سیستم های خود داشته باشید نیاز به مانیتورینگ دارید. این قدم اول درک و پایداری یک سیستم نرم افزاری ست. فرض کنید API GW وجود ندارد و شما بر روی هر سرویس خود یک سیستم مانیتورینگ بالا آوردید و اطلاعات لازم را میگیرید. خب آیا این مشکل شما را حل می کند؟ فرض کنید صد یا حتی پانصد API یا حتی سرویس دارید. چکار میکنید؟ برای هر کدام یک پنل جدا و یک مانیتورینگ جدا؟ چطور اینها را با هم جمع می کنید تا به یک درک کلی از عملکرد سیستم برسید؟ اینجاست که وجود یک لایه میانی بسیار به درد شما می خورد. تمام داده های مانیتورینگ را جمع می کند و به شما یک دید کلی می دهد. سیستم های تایید صلاحیت را روی آن بگذارید و مطمئن شوید که بار اضافی روی سرویس های شما قرار نمی گیرد. آدرس سرویس های بک اند خود را از طریق آن مخفی نگه دارید و حالا دیگر از نظر امنیت نیز خیال تان راحت باشد(البته این فقط یک قدم ساده در مسئله امنیت است) یکی از ابزارهای خیلی مهم در این زمینه Kong است. در این مقاله قرار نیست به سراغ پیاده سازی و جزئیات این ابزار بروم ولی توصیه می کنم بر روی سیستم خود به راحتی و با استفاده از Docker یک Kong بالا بیاورید و با آن کار کنید. کار کردن با آن ساده ست :) برای مطالب بیشتر و آشنایی بهتر :‌ لینکبرای راه اندازی و کار با Kong : لینک۷)‌ مفهوم BPMSمجموعه اقدامات و فعالیت‌هایی که هر سازمان و کسب و کاری به اجرا در می‌آورد تا به اهداف مشخص شده دست پیدا کند، تحت عنوان فرایند کسب و کار شناخته می‌شود. نرم‌افزار بی پی ام یا همان ‌BPMS یک ابزار اتوماسیون فرایند است. این ابزار کمک میکند تا فرایندهای هر روزه بررسی شود تا مشکلات و گلوگاه های موجود شناسایی شوند، هزینه های شرکت مدیریت شود و به طور کلی تا حد ممکن فرایندهای سازمان و افراد بهینه شوند. BMPSدر پیگیری، اجرا و خودکارسازی برخی عناصر فرایندهای کسب و کار نیز نقش دارد. این ابزار به عنوان یک سیستم شرکتی جهت ادغام اپلیکیشن‌ها، کارها و داده‌ها و ادغام جریان داده‌ها و تسک‌ها بین تیم‌ها و دپارتمان‌ها آغاز به کار کرد.این یک شمای ساده از فرایند اجرای این نرم افزارها را مشاهده می کنید. همانطور که از عکس پیداست به طور کلی میتوان این سبک نرم افزارها را ۵ قسمت تقسیم کرد. در قسمت طراحی تحلیلگران بیزنسی ابتدا اصول و قواعد کسب و کار موجود را بررسی می‌کنند، با ذینفعان مختلف مصاحبه می‌کنند و خروجی‌های موردنظر خود را با مدیریت به بحث می‌گذارند. هدف مرحله طراحی فرایند، دستیابی به فهمی از قواعد کار است. در قسمت مدلسازی، شناسایی، تعریف و بازنمایی فرایندهای جدید جهت پشتیبانی از قواعد کاری موجود برای ذینفعان مختلف اتفاق می افتددر قسمت اجرا فرایندهای کسب و کار ابتدا با گروه کوچکی از کاربران تست می‌شود، سپس به همه کاربران ارائه می‌شود.قسمت نظارت شامل تعیین شاخص‌های کلیدی عملکرد (KPI) و تصمیم گیری بر اساس آنها با استفاده از گزارش‌ها یا داشبوردهااما قسمت بهینه سازی. در این قسمت با وجود یک سیستم گزارش‌گیری کارآمد، سازمان می‌تواند عملیات را به طور موثری به سمت بهینه‌سازی یا بهبود فرایند، هدایت کند.اطلاعات بیشتر و کامل تر و حسابی مفصل تر :‌لینک۸) مفهوم صف یا message queueصف پیام این امکان را برای برنامه‌ها فراهم می‌کند که به صورت غیر همزمان با ارسال پیام‌ها از طریق یک صف با همدیگر ارتباط برقرار کنند. یک صف پیام، ذخیره‌سازی موقتی بین فرستنده و گیرنده فراهم می‌کند تا فرستنده بتواند بدون وقفه به کار خود در زمانی که برنامه مقصد مشغول است یا متصل نیست، ادامه دهد. متنی که بالا خواندید یک تعریف کلی از مفهوم صف بود. اما دقیقا صف چه کاری انجام می دهد؟ فرض کنید یک سرویس شما باید به تعدادی پیام جواب بدهد و هر پیام مدتی طول می کشد. وقتی یک درخواست برایش می آید یا میتواند آن را پردازش کند و یا نمیتواند. اگر بتواند که همه چیز خوب است اما اگر نشد و سرویس در حال پردازش پیام دیگری بود چه؟‌ درخواست از بین برود؟ یا پیامی به مشتری نمایش داده شود که بعدا امتحان کنید؟ هر دوی این روش ها کاربردی نیستند و باعث عملکرد ضعیف یک سیستم می شوند مخصوصا اگر سیستم ما دارای سرویس های پر کاربر باشد(یک اپراتور تلفن همراه را تصور کنید). در این شرایط پای صف به میان می آید. صف پیام هایی که باید منتظر بمانند را نگه می دارد و مانع از بهم ریختگی و یا گم شدن آنها می شود. در سیستم های service oriented و microservice صف از نان شب هم واجب تر است. مطالعه بیشتر : لینکآشنایی با یکی از بهترین ابزارهای صف یعنی rabbit mq :‌ لینک۹)‌ معماری ESB مجموعه ای از قوانین و اصول برای ادغام برنامه های کاربردی متعدد با هم بر روی یک زیرساخت اتوبوس مانند را ESB می گوییم. مفهوم اصلی معماری ESB این است که شما برنامه های مختلف را با قرار دادن یک گذرگاه ارتباطی بین آنها یکپارچه می کنید و سپس هر برنامه را قادر می سازید تا با این گذرگاه صحبت کند.حتی سرویس ها از طریق این گذرگاه با همدیگر صحبت کرده و اطلاعات مورد نیاز خود را بگیرند. گاهی حتی پیش می آید که دو سرویس که نیاز به یکدیگر دارند با پروتکل های متفاوتی ارتباط می گیرند. به عنوان مثال یکی با SOAP و دیگری با REST. وظیفه این درگاه ارتباطی در اینجا تبدیل زبان هر دو سرویس به یک زبان مشترک در داخل خود و پاسخگویی متناسب با پروتکل هر کدام می باشد. مفهوم ESB به دلیل نیاز به دور شدن از یکپارچگی نقطه به نقطه متولد شد که مدیریت آن در طول زمان شکننده و سخت می شود. ادغام نقطه به نقطه منجر به پخش کد در بین برنامه ها بدون هیچ راه مرکزی برای نظارت یا عیب یابی می شود. به زبان دیگر نمی شود به این راحتی درک کلی از سامانه و عملکرد آن پیدا کرد که طبیعتا این مسئله آسیب جدی به بزرگ شدن نرم افزار می زند.اگر کمی دقت کنید شباهت های زیادی میان ESB و API GW‌ می بینید. در حقیقت این دو تا حدی شبیه بهم عمل می کنند و حتی در بعضی سامانه ها از هر دو استفاده می شود. در حقیقت باید توجه داشت که API GW یک لایه پروکسی مانند است که وظیفه مدیریت و هندلینگ سیستم را دارد اما ESB شامل منطق نرم افزار شما نیز می شود. مسئله بعدی این است که در ESB مسیر تعامل سرویس ها با هم دو طرفه بوده و هر کدام میتواند به دیگری درخواست بدهد اما در API GW این مسیر یک طرفه بوده و سامانه ما شامل یک تامین کننده و یک مصرف کننده است. در حال حاضر روشی که کاربرد بسیار دارد استفاده از هر دوی این روش هاست. با وجود تکنولوژی های بهتر و دقیق تر سامانه برای دستیابی به پایداری بیشتر یک API GW در مسیر ورودی به ESB قرار می دهند و سرویس هایی همانند AUTH را بر روی آن می گذارند. و یک توصیه از طرف خودم که بیشتر از یک سال با ESB کار کردم. حتما تا جای ممکن آن را سبک کنید و تسک های اعتبارسنجی و این سبک کار ها را به API GW بسپارید.برای مطالعه بیشتر: لینک ali kalate ali kalate Sat, 26 Nov 2022 14:09:14 +0330 https://virgool.io/@ali.kalate89/%D8%A8%D8%B1%D8%B1%D8%B3%DB%8C-%D9%88-%D8%AA%D8%AD%D9%84%DB%8C%D9%84-%D8%A7%D9%86%D8%AA%D8%B4%D8%A7%D8%B1-%D9%88%DB%8C%D8%B1%D9%88%D8%B3-%DA%A9%D8%B1%D9%88%D9%86%D8%A7-%D8%A8%D8%B1-%D8%A7%D8%B3%D8%A7%D8%B3-%D8%B4%D8%A8%DA%A9%D9%87-%D9%87%D8%A7%DB%8C-%D9%BE%DB%8C%DA%86%DB%8C%D8%AF%D9%87-smmwhgbypdnx نویسندگان ‌: علی کلاته عربی - امیر مهدی عسلیاستاد درس : دکتر صادق علی اکبریمقدمههمه گیری کووید 19 باعث مریضی و مرگ و میر قابل توجهی در سراسر جهان شده است و تنها راه برای کاهش سرعت گسترش آن، اجرای روش های مداخله غیردارویی، به ویژه فاصله گذاری اجتماعی بوده است. مداخلات دارویی دارای اهمیت بالایی ست اما به دلیل قدرت شیوع شدید ویروس و همچنین ناشناخته بودن ابعاد زیادی از آن به منظور درمان کامل، همچنان و حتی بعد از دسترسی عمومی به واکسن نیز روش های مداخلات غیر دارویی اهمیت بالاتری دارد.[1]در تمام کشورهای جهان فاصله گذاری اجتماعی تا حد بالایی در دستور کار دولت ها قرار گرفته است. بعضی کشورها خیلی زود شروع کردند و بعضی دیگر با فاصله زمانی، اما در نهایت تقریبا تمام کشورها متوجه اهمیت ویژه آن شدند و تلاش برای فاصله گذاری و در عین حال پخش به صورت ویژه ماسک و لوازم ضد عفونی را شروع کردند. اما در نحوه اجرای این فاصله گذاری نیز اختلافاتی در میان کشورها و حتی ایالت های کشورها هست. در بعضی خیلی شدید اجرا می شود به صورتی که مردم در هیچ صورتی از خانه بیرون نمی آیند و حتی خریدهای خود را بصورت آنلاین انجام می دهند و در بعضی کشورها مواردی برای راحتی مردم در نظر گرفته می شود.در هر صورت و با تمام حالت های مختلف انجام فاصله گذاری، این روش و دیگر روش های مداخلات غیر دارویی به صورت گسترده برای کنترل شیوع ویروس انجام می شود. این روش ها اما مشکلاتی را نیز به همراه دارد. ملاحظات اقتصادی و همچنین خستگی روانی ناشی از فاصله گذاری اجتماعی در میان جمعیت انسانی، منجر به کاهش مداخلات غیردارویی می شود که دولت ها مجبور به انجام آن می شوند. به این معنا که شما نمی توانید مردم را به طور کامل در خانه ها نگه دارید و توقع داشته باشید که اقتصاد ضربه جدی ای نبیند و یا حتی مردم به راحتی این خانه نشینی را تحمل کنند. اما با کم کردن محدودیت های کرونایی شاهد ایجاد موج های جدید این ویروس نیز خواهیم بود که آثار مخرب آن نه فقط اقتصادی و روانی، بلکه آمار مرگ و میری ست که به طور مستقیم بر جمعیت تاثیرگذار خواهد بود.[2]در کنار تمام این مسائل، این سوال بزرگ نیز هست که این فاصله گذاری اجتماعی با تمام مشکلات اجرایش آیا به اندازه کافی تاثیرگذار است؟ الگوهای متفاوت و جالبی از اثر اعمال محدودیت های کرونایی مشاهده شده است. این الگوها شهر به شهر و کشور به کشور دارای تفاوت های بسیاری ست اما بعضی رفتارها نیز در آنها مشترک است. در برخی شهرها، به دنبال شروع فاصله گذاری اجتماعی شدید، کاهش قابل توجهی از موارد ابتلای روزانه و در برخی شهرها نیز، یک فاز ثابت نسبتا طولانی مدت مشاهده شد، که طی آن به نظر می رسید تعداد موارد روزانه حول یک سطح متوسط ثابت در نوسان است.[1]نکته قابل توجه این است که این امر در مکان‌هایی دیده شده است که اقدامات فاصله‌گذاری اجتماعی را نسبتاً زود اجرا کرده‌اند و موفق شدند شیوع را به طور مؤثر کنترل ‌کنند، مانند کالیفرنیا یا ایالت واشنگتن. اینها فقط دو نمونه از رفتارهای پویا و متغیر ویروس در مقابله با ایجاد محدودیت هاست. این قبیل رفتارها در مسائل مربوط به ویروس بود که باعث شد محققان به دنبال روش هایی بروند که بتوانند این رفتارها را توجیه کنند و با استفاده از آنها بتوانند به کنترل شیوع و انتشار ویروس دست بیابند. استفاده از مدل های ریاضی برای بررسی پویایی بیماری های عفونی سابقه طولانی دارد. مدل های کلاسیک جمعیت به طور گسترده برای مطالعه گسترش همه گیری ها برای نزدیک به یک قرن استفاده شده است. مدل‌ها معمولاً فرض می‌کنند که جمعیت‌ها در بخش‌های مختلف همگن هستند، به این معنا که همه افراد به طور مشابه رفتار می‌کنند و تراکم در یک محل نداریم. این مدل‌ها می‌توانند برای درک پویایی کلی یک بیماری همه‌گیر مفید باشند و پیش‌بینی‌های نسبتاً واقعی را برای یک جمعیت همگن ارائه دهند، اما زمانی که جمعیت از جوامعی با ویژگی‌های اجتماعی-شهری یا جمعیت‌شناختی متفاوت تشکیل شده باشد، دقت کافی ندارد.[3] ما نیاز به مدلی داریم که شیوه های مختلف تعاملات اجتماعی را در نظر بگیرد و همچنین بتواند الگویی برای پخش شدن و نحوه پخش شدن ویروس را ارائه دهد.حالت دیگری از بررسی کرونا بصورت شبکه های پیچیده نیز هست که در اینجا فقط به آن اشاره می شود و در ادامه تحقیقات به سراغ آن نمی رویم. در این حالت توجه و تمرکز شبکه ها بر روی خود ویروس و تشخیص آسیب پذیری راه های نفوذ به آن است.در قدم اول تحلیل موضوعات بیولوژیکی مربوط به کرونا ، واجب است که ساختار ویروس را به خوبی شناخت. ویروس کرونا از 4 پروتئین ساختاری تشکیل شده است.Spike glycoprotein, small envelope glycoprotein , membrane glycoprotein ,nucleocapsid proteinدر این مبحث تمرکز اصلی ما با توجه به تلاش برای تشکیل شبکه و گراف ، بر روی پروتئین spikeاست که از این به بعد با S شناخته می شود.در توضیحات تکمیلی باید گفت که برهمکنش S و گیرنده سلولی (ACE2) موجب اتصال غشا سلولی و غشا ویروس می شود.در حالت کلی تر میتوان گفت که S به نوعی دروازه ورود ویروس به داخل سلول را ایجاد می کند و با اینکار موجب شروع تکثیر ویروس توسط خود سلول می شود.در ادامه برای حفاظت S ها که ضامن بقای ویروس هستند نیاز به glycan دارد که از الان به g شناخته می شود.نقش g در ساختار ویروس به این شکل است که بر روی S تشکیل شده است و مانع از چسبیدن آنتی بادی ها به ویروس هستند.در شکل عملکرد و نحوه قرارگیری glycan ها آورده شده است. در یک تحلیل شبکه که بر روی گلیکان های محافظ بر روی پروتئین S اعمال می شود ؛ منجر به پیدا شدن نقاط قوت و ضعف شبکه محافظ می شود. در این گراف تشکیل شده هر گلیکان در نقش گره ظاهر می شود و ارتباط بین دو گره به این صورت ترسیم می شود که اگر فاصله بین دو گره در شبکه ، کمتر از 50 انگستروم باشد ، یک یال ارتباطی بین آنها کشیده می شود. همچنین باید در نظر داشت یال های ترسیم شده دارای وزنی هستند که مقدار آن برابر با انرژی برهمکنش بین دو گره یا گلیکان است. با اعمال فرضیات گفته شده ، گرافی رسم می شود که میتوان به آن گراف ارتباط شبکه محافظ گفت. به منظور تحلیل این گراف و دستیابی به اطلاعات مورد نیاز، از دو فاکتور مرکزیت استفاده می شود.Betweenness centrality(BC) و Eigenvector centrality(EC) معیار BC برای این منظور است که بفهمیم هر نود در ارتباط بین نودهای دیگر چندبار در کوتاه ترین مسیر ممکن قرار دارد و معیار EC بدین منظور است که قدرت همسایه های هر نود که به آنها وصل است چقدر است و یا به زبان دیگر نودهایی که هر نود به آنها وصل است خود به چند نود دیگر وصل هستند.آنتی بادی های موجود در بدن که کاربرد آنها به منظور خنثی سازی و جلوگیری از تکثیر ویروس می باشد، به دنبال روزنه نفوذی در ساختار محافظتی ویروس هستند. باید توجه داشت که در صورت بالا بودن میزان ارتباط گلیکان ها این امر سخت تر می شود و در نهایت میتوان گفت که بهینگی عملکرد آنتی بادی زیر سوال می رود.حتی مواردی در ساختار ویروس به وجود می آید که نفوذ آنتی بادی به آن در حد صفر است. به همین منظور و با تحلیل گراف موجود به نقاطی ­­دست پیدا میکنیم که چگالی خود گلیکان ها و چگالی ارتباطی آنها از بقیه مناطق کمتر است و این نقاطی ست که با تمرکز بر روی آنها میتوان به ساختار ویروس نفوذ کرد و احتمال خنثی سازی را بالا برد.با توجه به شکل میتوان به نحوه ارتباط گلیکان های با ساختار متفاوت(اسم های متفاوت نشان دهنده ساختار متفاوت می باشد) و وزن یال های آنها پی برد.[4]کارهای گذشتهدر [5]، نویسندگان از مدل‌های فراجمعیت شبکه برای توصیف گسترش سارس و شیوع آنفولانزای معروف به آنفولانزای مرغی، استفاده کردند. ویژگی مشترک این سه بیماری همه گیر، سرعت انتشار آن ها در محدوده جغرافیایی گسترده بود: در سال 2003، SARS-CoV از هنگ کنگ به بیش از 30 کشور در 4 قاره گسترش یافت و در سال 2009 A(H1N1) طی 3 تا 4 ماه به 214 کشور گسترش یافت. مفهوم فراجمعیت، که به عنوان گروهی از جمعیت‌های جدا شده که نوعی تعامل دارند، در ابتدا در مطالعه آفات حشرات معرفی شد و بعداً در ارتباط با شبکه‌ها برای معرفی یک بعد فضایی در مدل‌سازی انتقال بیماری استفاده شد. آنها از این مفهوم استفاده کردند تا به طور دقیق تری انتقال و شیوع بیماری را پیش بینی کنند.در – مقایسه میان رویکردهای مبتنی بر عامل(agent based) و مدل های مبتنی بر جمعیت انجام شده است.[6]تغییرات در الگوی رفت و آمد انسان و اعمال محدودیت هایی بر آن معمولا در زمان شیوع همه گیری انجام می شود تا به کمک آن بتوان ویروس را در محل پخش نگه داشت تا محل های دیگر را آلوده نکند.این ممنوعیت و محدودیت ها میتواند از ممنوعیت سفرهای هوایی باشد تا ممنوعیت های از درب منزل که در زمان کرونا به خوبی شاهد آن بودیم اما جالب است که در مقالاتی اثر این قبیل محدودیت ها نیز مورد سوال قرار گرفته است. به عنوان مثال در 4 اثر محدودیت های سفرهای هوایی اعمال شده توسط سازمان بهداشت جهانی به منظور کنترل آنفولانزا مورد بررسی قرار گرفته و تا حدی نشان از عدم تاثیر مطلوب دارد.در تحقیق دیگری که توسط [1] انجام گرفته است نمونه ای جالب مشاهده شده. آنها با بررسی اطلاعات بدست آمده از تعداد افراد مبتلا، بهبود یافته و فوت شده، متوجه شدند که در برخی ایالت های آمریکا الگویی پیش بینی نشده رخ می دهد. در این ایالت ها که اکثرا از مناطقی هستند که سریع ترین و بیشترین محدویت ها را نیز دارند؛ امار موارد روزانه گزارش شده به یک عدد ثابت می رسد که با توجه به اعمال محدودیت و کاهش اولیه آمار، کمی نگران کننده و شوکه کننده است. آنها علاوه بر نشان دادن power law بودن شیوع ویروس، همچنین نشان دادند که اگر بصورت خیلی سریع و زود هنگام محدودیت ها اعمال شود با احتمال بالا ممکن است یک فاز ثابت در موارد روزانه رخ دهد که بدون هیچ گونه اقدامات بیشتری خود به خود این فاز کنار رفته و کاهش آمار دوباره رخ خواهد داد. همچنین یک بعدی بودن انتقال در زمان اعمال محدودیت ها در مقایسه با دو بعدی بودن آن در قبل از محدودیت ها را عامل این فاز ثابت معرفی کردند. مسئله دیگری که در مطالعات آنها بسیار حائز اهمیت آن است؛ مسئله زمان ایجاد مداخلات غیر دارویی ست که در مطالعات دیگر کمتر به آنها اشاره شده است.در تحقیق دیگری [7] ، به سراغ این مسئله رفته اند که تاثیر سن در ابتلای افراد به چه صورت است و سعی کردند با توجه به داده های دست پیدا کرده از کرونا به مدل ریاضیاتی ای برسند که جواب این سوال را بدهد. آنها مدلی توسعه دادند که نشان داد امکان ابتلای افراد بالای 20 سال تقریبا 2 برابر افراد زیر این سن است و فقط 21 درصد افراد زیر 20 سال ممکن است که علائم داشته باشند. آنها از این مسئله در هوشمند سازی قرنطینه و اعمال سریعتر آن در کشورهایی با میانیگن سنی بالاتر استفاده کردند و نشان دادند که مناطق با سرانه سنی بالاتر اگر دیرتر این محدودیت ها را اعمال کنند میتواند منجر به یک فاجعه بشود.در تحقیق دیگری که به منظور روش های ایجاد قرنطینه هوشمند و رسیدن به نتیجه بهتر انجام شد؛ [8] نشان دادند که با اعمال سیاست های متفاوت از یک قرنطینه ساده و فاقد هوشمندی چقدر بهتر و سریع تر میتوان شیوع بیماری را کنترل کرد. در عکس 1 نتیجه تحقیقات آنها نمایش داده شده است.آنها در این شکل خلاصه از نحوه اعمال محدودیت ها را نشان می دهند و در آخر نشان می دهد که اعمال محدودیت و قطع ارتباط بر اساس مدل repetition بیشترین فایده و بهینه ترین حالت را داشته است. این تحقیق به دلیل مقایسه میان روش های موجود و همچنین ارائه مدلی برای قرنطینه هوشمندتر و بهتر بسیار جالب توجه بود. ما از این روش ها و مطالعات ایده گرفته و مدلی بر اساس تحلیل های خود ارائه دادیم. هدف ما از توسعه این مدل، تلاش برای رسیدن به ایده ای برای قرنطینه هوشمند و همچنین نیازسنجی قرنطینه و سنجش تاثیر اعمال واکسن است.روش مادر این تحقیق ما جامعه نمونه ۱۰۰۰۰ نفری در نظر گرفتیم که ۲۰درصد افراد در این جامعه را گروه های حساس (افراد دارای بیماری زمینه ای، افراد مسن و ...) تشکیل می دهند. شبکه ما یک شبکه رندوم هندسی است که هر نود در آن به نود هایی که در شعاع مشخصی از آن نود قرار دارند متصل میشود و برای رسیدن به یک شبکه شبه واقعی که بتواند شرایط جامعه انسانی را شبیه سازی کند، هر نود به تعدادی نود که خارج از شعاع گفته شده است نیز متصل است. شبیه سازی شرایط جوامع انسانی شاید یکی از بزرگترین چالش ها برای به نتیجه رسیدن تحقیقات در زمینه شبکه های پیچیده باشد. اینکه چه فاکتورهایی در نظر گرفته شود؟ به چه صورت و چه مقداری در نظر گرفته شود؟‌ و آیا نتیجه نهایی با واقعیت منطبق است یا نه؟ ما تلاش کردیم با توجه به درکی کلی از جوامع و با تقریبی از ارتباطات کلی افراد در آن، شبکه ای را بسازیم که وابستگی کمی به تعداد متغیرات داشته باشد و حالتی کلی برای تقریب را به ما بدهد. به همین منظور میانگین درجات هر نود ۱۱ تا ۱۳ است و این عدد را میتوانیم تعداد ارتباطات افراد در طول یک هفته در نظر بگیریم که با توجه به این که این عدد برای شرایط غیر قرنطینه است عدد معقولی به نظر میرسد. در این تحقیق هر مرحله زمانی ۱ هفته در نظر گرفته میشود و هر کس که بیمار میشود دو هفته بیماری را دارد و در این حالت بیماری را سرایت میدهد. پس از این دو هفته شخص یا خوب میشود و دیگر نمی گیرد یا می میرد در نتیجه کسی که بیمار می شود، پس از دو هفته دیگر نمی گیرد و انتقال نمی دهد.فرایند گرفتن بیماری به این شکل است که به هر شخص یک ضریب مقاومت به بیماری به شکل تصادفی تعلق میگیرد که میتواند میزان سلامت شخص و ... باشد. این ضریب در افراد حساس بین ۰ تا ۰.۴ است در بقیه افراد این ضریب ۰.۳ تا ۰.۸ است. وقتی فرد با کسی که بیمار است در تماس قرار میگیرد (۲ نود به هم متصل باشند.) یک ضریب انتقال به طور تصادفی تولید میشود (بین ۰ و ۱) که میتواند نشان دهنده میزان تماس دو شخص، نوع تماس و ... باشد. حال اگر ضریب انتقال بزرگتر از ضریب مقاومت شخص باشد، شخص مبتلا میشود.با بررسی و انجام تست های مختلف با شروع از ۵شخص مبتلا، دیده شد که در مراحل زمانی بین ۵۰ - ۶۰هفته حدود ۹۲ درصد جامعه دچار بیماری میشوند فرایند تمام میشود. در این فرایند، تعداد ابتلا های جدید در هر مرحله زمانی و در نهایت تعداد کل کسانی که بیماری را گرفنتد و بهبود یافتند و تعداد کسانی که در نهایت اصلا دچار بیماری نشدند را میتوان بررسی کرد. حال برای بررسی، پس از شروع بیماری در مرحله ای که تعداد بیماران از یک عدد مشخص عبور کرد واکسیناسیون و فاصله گذاری اجتماعی را اعمال می کنیم. فاصله گذاری اجتماعی در میانگین درجات نود ها و واکسیناسیون در ضریب مقاومت افراد موثر است.باید در نظر داشت که مفهوم قرنطینه را نیز در این تحقیق به کار بردیم که تعریف آن به این صورت است که فرد مبتلا در هفته دوم بیماری ۷۰ درصد ارتباطاتش را از دست می دهد که این حالت برای جلوگیری از انتشار در نظر گرفته شده است که به نوعی رفتار طبیعی افرادی ست که مبتلا شده اند و برای جلوگیری از آلوده شدن اطرافیان همچین عملی را انجام می دهند. این فرض به منظور نزدیک تر شدن شبکه به رفتار واقعی در نظر گرفته شده.با اجرای کدهای نوشته شده، به نتایج جالب توجهی در مورد نحوه انتشار و پاسخ شبکه ایجاد شده به مداخلات غیر دارویی رسیدیم. اگر هیچ گونه مداخلات دارویی و غیر دارویی اعمال نشود، در حدود ۱۵ هفته ۹۴ درصد جمعیت شبکه آلوده به ویروس می شوند که این آمار را میتوان آلودگی کل سیستم و تقریبا نابودی آن در نظر گرفت. با اعمال محدودیت های رفت و آمد، واکسن و همچنین فرض قرنطینه افراد مبتلا در هفته دوم ( فرض می شود که علائم در هفته دوم بروز پیدا می کند و فرد متوجه بیمار خود شده و خود را قرنطینه می کند) با توجه به نمودارهای بدست آمده از تعداد مبتلایان نشان داده می شود که زمان ایجاد اعمال محدودیت ها اهمیت بالایی دارد. به طوری که اگر زمانی که ۵ درصد جمعیت آلوده شده است محدودیت های اجتماعی را شروع کنیم، نزدیک به ۱۲۰۰ نفر در بالاترین مرحله انتشار به صورت هفتگی مبتلا می شوند که این آمار اگر در ۱۰ درصد جمعیت محدودیت ها آغاز شود به حدود ۱۹۰۰ نفر می رسد. شاید در نگاه این تفاوت آن چنان به چشم نیاید اما باید در نظر داشت جمعیت آماری فقط ۱۰ هزار نفر است و اگر ابعاد جمعیتی بزرگ تر شود این اختلاف بسیار هولناک خواهد بود اما نکته جالب توجه این است که شیب کاهش آمار موارد ابتلا در حالت دوم که ۱۰ درصد جمعیت آلوده شده و سپس محدودیت ها شروع می شود، تندتر از حالت اول است که این محدودیت ها در ۵ درصد آلودگی آغاز می شود. این پدیده در وهله اول با مطالعات و آمار استخراج شده از مقالات همخوانی دارد و همچنین تاکید بیشتری بر روی زمان اعمال محدودیت ها می کند. در حالت ۵ درصد آلودگی که اعمال محدودیت ها سریعتر از حالت ۱۰ درصد است حالتی از شیب خطی را در قله موارد ابتلا شاهد هستیم که همین مورد کاهش آمار را با تاخیر مواجه می کند.نتیجه جالب توجه دیگر تاثیر ارتباطات دور است. با توجه به تصاویر بدست آمده از نحوه انتشار و همچنین تعداد مراحل زمانی لازم تا به پایان رسیدن شیوع، میتوان نتیجه گرفت که ارتباطات دور تاثیر بسیار بیشتری از ارتباطات نزدیک دارند. آنها میتوانند در حالی که شبکه به حالت درمان و عدم ابتلا نزدیک شده ناگهان از نقطه ای دیگر شیوع را شروع کنند و تمام مداخلات را بی معنا جلوه دهند. اما چطور میتوان این نتیجه را بر اعمال محدودیت های هوشمند تطبیق داد؟‌ میتوان به حالت شهری و یا حتی محله ای به این مسئله نگاه کرد. در حالت محدودیت های سخت، اقتصاد ضربه جدی می خورد و تا خرد ترین کاسب ها و فعالیت های اقتصادی نیز دچار آسیب شدید می شوند و همچنین به دلیل در خانه ماندن افراد و دوری از فضاهای تعاملات انسانی، آسیب های روانی نیز به آن اضافه می شود. اما اگر محدودیت ها را نیز کمی آرام تر کرده و به مردم اجازه رفت و آمد بدهیم شاهد به وقوع پیوستن موج های جدید اپیدمی هستیم. پس آیا باید هرگز سراغ هیچ کم کردن محدودیتی نرویم؟ طبیعتا خیر. این حالت میتواند ضربات جبران ناپذیری دقیقا همانند شیوع بیماری بزند. نتایج تحقیقات ما نشان می دهد که اگر این کاهش محدودیت ها را در سطح انجمن ها انجام بدهیم نتایج قابل قبولی میگیریم. حال این انجمن را میتوان به عنوان مثال یک محله تعریف کرد. با کاهش منطقی محدودیت ها در سطح محله میتوان به نوعی اقتصاد خرد را تا حدی نجات داد و همچنین در مقابل آسیب های روانی اپیدمی نیز ایستادگی کرد. این نتیجه میتواند نوعی از قرنطینه هوشمند را ارائه کند که افراد میتوانند در بازه هایی در سطح های محلی کوچک ارتباط داشته باشند( طبیعتا با دریافت واکسن و رعایت موارد بهداشتی)‌ اما در سطح شهری و یا کشوری همچنان محدودیت ها برقرار بماند. این یعنی جلوگیری از شیوع موج های جدید و همچنین به کمترین حد رساندن آسیب های اقتصادی و روانی اپیدمی.شکل بالا مراحل آلودگی سیستم در حالت بدون اعمال محدودیت های رفت آمد، واکسن و قرنطینه فرد مبتلا را توسط مدل ساخته شده نشان می دهد.عکس بالا نحوه انتشار ویروس در حالتی ست که لینک های دور دست وجود ندارد و به نوعی ارتباط ها محلی می باشد. با دقت در عکس میتوان متوجه نحوه انتشار کند ویروس شد. درست است که اگر مداخلات غیردارویی و دارویی اعمال نشود باز هم سیستم با درصد بالایی آلوده می شود اما نکته حائز اهمیت کندی شیوع می باشد. این خود نمونه ای ست که میتوان برای تاثیر عمیق لینک های دوردست به منظور انتشار ویروس به آن اشاره کرد.نمودار بالا نشان دهنده کاهش موارد ابتلا با اعمال محدودیت کرونایی هوشمند در کنار واکسیناسیون و قرنطینه موارد مبتلا ست. نمودار بالا نشان دهنده حالت بدون اعمال محدودیت های کرونایی ست که نشان از تعداد بسیار بالای مبتلایان دارد. پایین آمدن نمودار فوق نشان از ابتلای بالای ۹۳ درصد جمعیت دارد و به معنای پایان اپیدمی نیست. https://www.dropbox.com/s/d6hkvveevhuyvtw/main_file.ipynb?dl=0 در لینک بالا تمام کدهای نوشته شده به زبان پایتون قابل مشاهده می باشد. تمام فرضیات گفته شده بر روی کد اعمال شده است و تا جای ممکن سعی شده با کامنت گذاری کد خوانایی بیشتری داشته باشدمنابع1) Komarova, Natalia L., Asma Azizi, and Dominik Wodarz. "Network models and the interpretation of prolonged infection plateaus in the COVID19 pandemic." Epidemics 35 (2021): 100463.2) Block, Per, et al. "Social network-based distancing strategies to flatten the COVID-19 curve in a post-lockdown world." Nature Human Behaviour 4.6 (2020): 588-596.3) Calvetti, Daniela, et al. "Metapopulation network models for understanding, predicting, and managing the coronavirus disease COVID-19." Frontiers in Physics 8 (2020): 261.4) Ghorbani, Mahdi, Bernard R. Brooks, and Jeffery B. Klauda. "Exploring dynamics and network analysis of spike glycoprotein of SARS-COV-2." Biophysical Journal 120.14 (2021): 2902-2913.5) Wang L, Li X. Spatial epidemiology of networked metapopulation: an overview. Chinese Sci Bull. (2014) 59:3511–22. doi: 10.1007/s11434-014-0499-86)Ajelli M, Gonçalves B, Balcan D, Colizza V, Hu H, Ramasco JJ, et al. Comparing large-scale computational approaches to epidemic modeling: agent-based versus structured metapopulation models. BMC Infect Dis. (2010) 10:190. doi: 10.1186/1471-2334-10-1907)Prem, K., Liu, Y., Russell, T.W., Kucharski, A.J., Eggo, R.M., Davies, N., Flasche, S., Clifford, S., Pearson, C.A., Munday, J.D., 2020. The effect of control strategies to reduce social mixing on outcomes of the COVID-19 epidemic in Wuhan, China: a modelling study. Lancet Public Health.8) Block, P., Hoffman, M., Raabe, I.J., Dowd, J.B., Rahal, C., Kashyap, R., Mills, M.C., 2020b. Social Network-based Distancing Strategies to Flatten the COVID 19 Curve in a Post-lockdown World. arXiv preprint arXiv:2004.07052. ali kalate ali kalate Mon, 11 Jul 2022 00:48:50 +0430