https://virgool.ir/feed/@maryam_76shfa2026-11-11 09:29:17https://virgool.ir/images/default-avatar.jpghttps://virgool.ir/@maryam_76shhttps://virgool.ir/@maryam_76sh/ارائه-معماری-مناسب-برای-سامانه-تشخیص-شی-و-افزودن-اطلاعات-در-بستر-واقعیت-افزوده-موبایل-hwwx9jk7xt7hچکیده:معماری نرم‌افزار، کدگذاری انتخاب توسعه‌دهندگان نرم‌افزار در طراحی است و یک هسته اصلی برای طراحی نرم‌افزار تعریف می‌کند. با افزایش پیچیدگی نرم افزار، استفاده از معماری نرم افزار اهمیت بیشتری پیدا می‌کند. معماری‌های متفاوتی می‌توان برای یک سامانه نرم افزاری ارائه شود که باید متناسب با نیازمندی‌های آن باشد. برای مثال یک نرم افزار تعاملی بلادرنگ، نیازمندی‌های بسیار متفاوتی با نیازمندی‌های یک سیستم مبتنی بر تراکنش دارد.واقعیت افزوده دنیای واقعی مشاهده شده از طریق رابط کامپیوتری را با شی مجازی تولید شده توسط کامپیوتر ترکیب می‌کند. با ظهور دستگاه های تلفن همراه قدرتمند، برنامه‌های کاربردی واقعیت افزوده موبایل (MAR) مورد توجه قرار گرفتند. محدودیت منابع در موبایل، چالش اصلی واقعیت افزوده موبایل است. اکثر تحقیقات حوزه MAR در حوزه‌ی فناوری مربوط به آن است و به طراحی و معماری آن توجه چندانی نشده است. این امر منجر به کمبود ادبیات معماری و طراحی برای MAR شده است. نیاز اصلی که یک معماری MAR باید برآورده کند، پردازش کارآمد بلادرنگ جریان های داده مانند فریم های ویدئویی و داده های حسگر است.در این تحقیق با مقایسه انواع معماری در این حوزه، معماری متناسب با نیازمندی‌های سامانه تشخیص شی و افزودن اطلاعات در بستر واقعیت افزوده موبایل ارائه می‌شود.تعریف:واقعیت افزوده (AR) دنیای واقعی را که از طریق رابط کامپیوتری مشاهده می‌شود، با شی مجازی تولید شده توسط کامپیوتر ترکیب می‌کند. در دهه گذشته گوشی‌های موبایل بسیار پیشرفت کرده اند. واحدهای پردازش مرکزی چند هسته‌ای (CPU)، واحدهای پردازش گرافیکی (GPU) و نمایشگرهای با وضوح بالا همراه با دوربین‌ها و حسگرهای پیشرفته با قابلیت تشخیص موقعیت، جهت‌گیری و حرکت به آن افزوده شده است. از این رو اجرای برنامه‌های پیچیده واقعیت افزوده در موبایل امکان پذیر شده است. همچنین با توجه به فراگیر بودن دستگاه‌های تلفن همراه در دنیای مدرن، این سامانه‌ها بسیار محبوب شده اند.اولین قدم در مسیر طراحی یک نرم‌افزار منسجم، معماری آن نرم‌افزار است که پایه‌ای برای طراحی باقی اجزا است. معماری نرم افزار در واقع ترسیم زیرساخت بنیادی برای ساخت نرم افزار بر آن است.بهترین معماری برای یک سامانه، متناسب ترین معماری با توجه به نیازمندی‌های سامانه است و باید گویای آن سامانه نیز باشد. مهم‌ترین نیاز سامانه‌های واقعیت افزوده موبایل، پردازش و اجرای کارآمد و بلادرنگ است که باید معماری متناسب با آن باشد. سامانه مدنظر در این پژوهش، سامانه تشخیص شی و افزودن اطلاعات در بستر واقعیت افزوده موبایل است. در این سامانه ابتدا یک فریم تصویر گرفته شده توسط دوربین وارد سیستم می‌شود، در زیر سیستم تشخیص اشیا، شی موجود در تصویر، تشخیص داده شده و مکان دوربین نسبت به شی تخمین زده می‌شود سپس اطلاعات مربوط به شی از پایگاه داده محلی بازیابی می‌شود و در صورت عدم وجود اطلاعات کافی، اطلاعات مربوطه از وب بازیابی و کاوش می‌شود. این اطلاعات به زیر سیستم ثبت و اجرای شی مجازی، فرستاده می‌شود و اطلاعات در مکان تخمین زده شده افزوده می‌شود.در بخش‌های بعد، ابتدا معماری‎های مطرح در این حوزه بررسی می‌شود. سپس در بخش بعد، معماری متناسب برای سیستم مذکور معرفی می‌شود و بخش آخر شامل جمع‌بندی و نتیجه‌گیری است.معماری‌های پیشین:پژوهش‌های بسیاری در حوزه پیاده سازی واقعیت افزوده و واقعیت افزوده در موبایل انجام شده است. اکثر این پژوهش‌ها بر پیاده سازی یک برنامه کاربردی خاص همانند برنامه راهنمای گردشگری تمرکز دارند و بسیار اندک به معماری یا طراحی آن سامانه پرداخته شده است. طبق گفته‌ی آقای بوچ و همکارانش، ویژگی‎های معماری شامل موارد زیر است:ماژول‌بندی: سیستم به صورت چند ماژول جداگانه نمایش داده شود.انسجام: اجزای یک ماژول یک وظیفه یا هدف مشترک داشته باشند.وابستگی کم: وابستگی غیر ضروری به ماژول‌های دیگر نباشد.کپسوله‌سازی عملکرد: از رابط ها برای دسترسی به ماژول ها یا اجزا استفاده شود.انتزاع عملکرد سیستم : کپسوله سازی برای نمایش تمام عملکردهای ارائه شده توسط سیستم استفاده شود.در سال 1988 آقای رایچر معماری مبتنی بر MVC3را توصیف کرد که شامل ماژول‌های برنامه، زمینه، تعامل، ردیابی، نمایش و دنیای واقعی است. پیاده سازی این معماری آسان و سریع است. سیستم امنیت دارد. امکان توسعه وجود دارد و رفع خطا آسان‌ اما پر هزینه است. این معماری انعطاف پذیری کمی دارد. درک معماری آن برای توسعه دهنده دشوار است. در صورت بزرگ بودن سیستم کنترل آن دشوار است.معماری سطح بالا مبتنی بر MVCیک معماری عمومی برای برنامه های چند رسانه ای توسط فرانسوا 2003 پیشنهاد شد که می‌تواند برای استفاده در واقعیت افزوده موبایل مناسب باشد. این معماری با نام SAI شناخته می‌شود و بر سه جزء سلول، منابع و پالس استوار است. سلول‌ها در خطوط لوله مرتب شده‌ اند و داده‌های دریافتی را پردازش می‌کنند و نتیجه را به سلول بعدی ارسال می‌کنند. داده‌ها می‌توانند پایدار باشند، به عنوان مثال، داده های ثابت مانند تنظیمات یا غیرثابت مانند فریم‌های ویدئویی یا صوتی است. داده پایدار در منابع متصل به سلول های خاص حاوی داده های پایدار نگهداری می‌شوند. در حالی که منابع، داده های ثابتی را نگه می‌دارند، پالس ها داده های غیرثابتی را به صورت دوره ای ارسال می‌کند. پالس همراه با مهر زمان، از طریق خط لوله سلول‌ها منتشر می‌شود و هر سلول می‌تواند داده‌های موجود در پالس را استخراج کرده و روی آن کار کند. پیاده سازی این معماری سریع است. امکان توسعه وجود دارد. این معماری انعطاف پذیری کمی دارد. در صورت بزرگ بودن سیستم کنترل آن دشوار است و برای سیستم بلادرنگ مناسب نیست.معماری قسمت بندی ویدئو با SAIجریان های داده به طور سنتی با استفاده از الگوی معماری PIPES و FILTERS در سال 1996 پردازش می‌شوند. فیلترها مراحل پردازش را کپسوله می‌کنند و می‌توانند همزمان با فیلترهای دیگر، زمانی که داده‌ها در دسترس هستند، اجرا شوند. داده ها از طریق لوله ها میان فیلترها منتقل می‌شوند و پردازش صورت می‌گیرد. این الگو پردازش جریان‌های بی‌درنگ یا تعاملی دارای معایبی از جمله عدم وجود بازخورد، سربار سرعت و تاخیر غیر ضروری است. یک جایگزین برای این الگوی معماری، الگوی خط لوله موازی در سال 2012 است که از فیلترهای موازی نیز پشتیبانی می‌کند و می‌تواند همزمان بیش از یک داده جریان را پردازش کند. پیاده‌سازی این الگو پیچیده‌تر است و باید امکان داده‌های خارج از ترتیب را فراهم کند.الگوی معماری Task Graph در سال 2010، برای سامانه واقعیت افزوده موبایل که قادر به پردازش چندین جریان داده بلادرنگ باشد، مناسب است.ساختار این معماری به صورت یک گراف جهتدار بدون دور است که گره ها وظایف هستند و یال‌ها وابستگی‌های جریان داده هستند و جریان داده می تواند در امتداد آن‌ها جریان یابد. از آنجایی که بسته های داده جریان می‌توانند بزرگ باشند، برای مثال فریم های ویدئویی، پس کپی مکرر داده ها میان گره‌ها نامطلوب و ناکارآمد است. یک راه حل بهتر ترکیب این الگو با الگوی منبع اشتراکی است و توکن نشان دهنده داده‌های میان گره‌ها ارسال شود و به داده‌های واقعی در منبع مشترک دسترسی پیدا کرد.فناوری در حال پیاده‌سازی باید از موازی سازی پشتیبانی کند و اجزا باید به گونه‌ای طراحی شوند که بتوانند از پردازش مورد بعدی در جریان پشتیبانی کنند و توان عملیاتی بیشینه شود. همچنین می توان سایر اشکال موازی سازی را در نمودار ترکیب کرد. به عنوان مثال، یک گره وظیفه ممکن است از الگوی map reduce pattern استفاده کند. این معماری به همراه ترکیب با الگوهای ذکر شده برای پردازش بلادرنگ در سیستم‌ مناسب است.شکل زیر یک نمونه معماری برای دوربین های تکی عقب و جلو است. گره های دایره ای سمت چپ کد مدیریت دوربین اندروید را مشخص می کنند که در Kotlin7 همراه با تبدیل مبتنی بر RenderScript8 (یا CPU) فرمت ویدیوی YUV به RGB برای پردازش مبتنی بر CV مورد نیاز است.معماری نمونهمدل چند لایه به طور معمول در طراحی واقعیت افزوده موبایل استفاده می‌شود. آقای اشمالستیگ و همکاران از مدل 3 لایه در سیستم خود استفاده کردند. اولین لایه یک پایگاه داده است. لایه دوم جهت پیوند و تعامل پایگاه داده و برنامه ها است و داده های خام را به لایه سوم که برنامه ها در آن قرار دارند تبدیل می‌کند. سپس در یک معماری دیگر، تونیس یک مدل 4 لایه با لایه پایین ارائه خدمات ارتباطی و تعامل، لایه دوم شامل اجزای اصلی واقعیت افزوده، ردیف سوم با ماژول های سطح بالا متشکل از اجزای اساسی و لایه بالایی مسئول تعامل کاربر طراحی کرد. یک معماری لایه‌ای پیشنهادی در cloudiAR پلتفرمی برای توسعه برنامه های واقعیت افزوده موبایل ارائه می‌دهد که استفاده آسان برای توسعه دهندگان فراهم می‌آورد. عملکرد بلادرنگ با برون سپاری محاسبات فشرده به فضای ابری است. همچنین وجود لایه انتزاعی برای محصور کردن سخت افزارهای متنوع در دستگاه های تلفن همراه قابلیت مقیاس‌پذیری در دستگاه‌های مختلف را فراهم می‌کند. از آنجایی که منطق برنامه از اجرا و نمایش جدا می شود، توسعه سریع برنامه ها را با این چارچوب امکان پذیر است.معماری پلتفرم cloudiarبه طور کلی توسعه و تست در معماری چند لایه آسان است. معمولا کارایی بالایی دارند. اما با افزایش نیازمندی‌ها جداسازی بخش‌های مختلف دشوار می‌شود و تغییرات در این معماری چابک نیست.یک معماری دیگر، معماری سرویس‌گرا به نام SOMARA است که از چارچوب سرویس وب به عنوان یک سیستم پشتیبان استفاده می‌کند و میان مشتری واقعیت افزوده موبایل و ارائه‌دهندگان خدمات باز مشارکت‌کننده ارتباط ایجاد می‌کند. پلتفرم واقعیت افزوده موبایل محتوای دیجیتال را درخواست می کند و آنها را در محیط های واقعیت افزوده شخصی اعمال می‌کند. در این معماری سه جزء اصلی شامل کلاینت، چارچوب خدمات وب و ارائه دهندگان محتوای وب سرویس وجود دارد.معماری سرویس گرا SOMARAمعماری مبتنی بر سرویس انعطاف پذیر است و تغییرات در آن آسان است و امکان توسعه سریع وجود دارد. اما بار سیستم بالا می‌رود و سرعت پاسخ نیز کم است و در سیستم‌های بلادرنگ مناسب نیست.یک معماری دیگر بر پایه کلاینت-سرور که به طور خاص برای یک برنامه کاربردی توریستی طراحی شده است. سرور یک پایگاه داده توسعه یافته مانند MySQL است که اطلاعات خاص را نگهداری می‌کند. اطلاعات بر اساس درخواست مکان به واحد مربوطه فرستاده می‌شود. پایگاه داده از طریق یک سرویس وب REST-full با مشتری در ارتباط است.معماری کلاینت-سرورفن‌آوری‌های ارتباطی نوظهور 5G در برنامه‌های واقعیت افزوده موبایل از جهت تأخیر بسیار کم و نرخ داده بسیار بالا نقش مهمی دارد. در معماری مبتنی بر ابر، سیستم واقعیت افزوده موبایل در مدل مشتری-سرور عمل می کند. دستگاه های واقعیت افزوده موبایل که برنامه های ترمینال را اجرا می کنند کلاینت نامیده می شوند. سرور واقعیت افزوده در فضای ابری قرار دارد و از هر نقطه‌ای از طریق اینترنت قابل دسترسی است. دستگاه ها تصاویر را می‌گیرند، پردازش هایی انجام می دهند، تصاویر را به سرور منتقل می کنند و تقویت های دریافت شده از سرور را نمایش می دهند. سرور ابر واقعیت افزوده وظایف محاسباتی فشرده تری را در پردازش تصویر انجام می دهد. سرور مشتری معمولاً پردازش را به سرور که منابع محاسباتی بالایی دارد می‌سپارد و فقط پردازش های اولیه، فشرده‌سازی و کدگذاری تصویر را انجام می‌دهد. این روش در عمر باتری، ارتقای آسان نرم افزار، عیب یابی نرم افزار تاثیر مثبت دارد. اما نقطه ضعف اصلی افزایش تاخیر ارتباط است. سیستم واقعیت افزوده موبایل مبتنی بر ابر دارای یک نقطه خرابی است.شمای کلی استفاده از فضای ابریدر برخی موارد استفاده از واقعیت افزوده موبایل باید تأخیر بسیار کمی داشته باشد که معماری مبتنی بر ابر آن را تضمین نمی‌کند. محاسبات لبه ای مناسب‌ترین الگوی محاسباتی برای خدمت به آن موارد است. معماری مبتنی بر لبه همچنین به عنوان یک مدل سرور مشتری عمل می‌کند که در آن سرور واقعیت افزوده در لبه شبکه میزبانی می‌شود. دستگاه های ترمینال واقعیت افزوده موبایل همان حداقل عملکرد را در معماری مبتنی بر ابر انجام می دهند. سرور واقعیت افزوده وظایف محاسباتی فشرده مانند پیش پردازش، ردیابی و رندر تقویت ها را اجرا می‌کند. معماری مبتنی بر لبه برای ارائه برنامه‌های کاربردی با تأخیر کم، مناسب‌تر است. عملکرد واقعیت افزوده کمتر از معماری مبتنی بر ابر به پیوندهای زیرساخت بستگی دارد زیرا سرور در لبه مستقر است. سرورهای لبه ارتباطات قابل اعتمادتری را نسبت به معماری مبتنی بر ابر تضمین می‌کنند. اما خرابی سرور واقعیت افزوده لبه کل سیستم را تحت تأثیر قرار می دهد. همچنین سربار عملیاتی بالاتر در مقایسه با معماری مبتنی بر ابر نیز یک اشکال است.شمای کلی استفاده از لبهمعماری ترکیبی برای یک شبکه واقعیت افزوده موبایل دارای یک گره ابری و یک گره لبه همراه با شبکه واقعیت افزوده مشتری است. توابع واقعیت افزوده تعاملی مهم تأخیر باید در گره لبه اجرا شوند زیرا تأخیر کلی شبکه مستقیماً به طول مسیر سیگنال و تعداد عناصر مسیریابی واسطه مربوط می شود. برنامه‌هایی که به تأخیر بسیار کم نیاز ندارند در گره ابر میزبانی می‌شوند. از مزایای معماری ترکیبی، کاهش تاخیر است. پردازش لبه وابستگی برنامه را به پیوندهای زیرساخت کاهش می دهد و ارتباطات قابل اطمینان تر را تضمین می کند. اما به طور کلی پیچیده تر از معماری های دیگر است و سربار عملیاتی دارد.معماری ترکیبیمعماری پیشنهادی:معماری یک سیستم باید نیازمندی‌ها و محدودیت‌های اولیه مربوط به طراحی سیستم را در نظر بگیرد. درک کاربر از یک سیستم واقعیت افزوده موبایل به میزان پاسخگویی آن بستگی دارد، بنابراین نیاز اولیه برای سیستم واقعیت افزوده، پردازش جریان های ویدئویی و داده های حسگر به صورت بلادرنگ است. بنابراین انتخاب یک معماری بهینه برای پردازش جریان‌های داده بلادرنگ ضروری است. با توجه به محدودیت باتری گوشی موبایل، برنامه‌های کاربردی که بر آن اجرا می‌شوند باید از نظر مصرف انرژی و شارژ باتری، بهینه باشند. بنابراین کارایی سیستم واقعیت افزوده در موبایل اهمیت دارد. حافظه و قدرت پردازشی گوشی موبایل محدود است و برنامه‌های کاربردی ویژه گوشی موبایل باید از نظر میزان حافظه و پردازش مورد نیاز، متناسب با منابع باشند. همچنین سیستم مدنظر نیاز دارد تا در تمام مکان‌ها قابل اجرا باشد و محدود به یک مکان بسته نباشد.با توجه به معماری‌های پیشین که در بخش قبل بررسی شد و نیازمندی‌های سیستم بهترین معماری برای سامانه تشخیص شی و افزودن اطلاعات در بستر واقعیت افزوده موبایل ارائه شده است.طبق الگوی TASK GRAPH اگر هر نود را یک وظیفه و یال‌ها وابستگی درنظر گرفته شود، به این ترتیب گراف زیر تولید می‎شود.گراف وظایفبا توجه به نیازمندی‌ها و محدودیت‌های سخت افزاری، معماری این سامانه به الگوی معماری کلاینت-سرور و استفاده از فضای ابری است. کامپوننت تشخیص اشیا، بازیابی اطلاعات و پایگاه داده در فضای ابری خواهد بود. در فضای محلی، پایگاه داده محلی و کامپوننت اجرا و نمایش واقعیت افزوده قرار داده می‌شود. معماری ارائه شده به این شکل است.نمودار زمینه سیستمنمودار نگهدارنده و کامپوننت سیستمنتیجه گیری:اولین قدم در مسیر طراحی یک نرم‌افزار منسجم، معماری آن نرم‌افزار است که پایه‌ای برای طراحی باقی اجزا است. معماری نرم افزار در واقع ترسیم زیرساخت بنیادی برای ساخت نرم افزار بر آن است. واقعیت افزوده دنیای واقعی مشاهده شده از طریق رابط کامپیوتری را با شی مجازی تولید شده توسط کامپیوتر ترکیب می‌کند. با ظهور دستگاه های تلفن همراه قدرتمند، برنامه‌های کاربردی واقعیت افزوده موبایل مورد توجه قرار گرفتند.نیاز اصلی که یک معماری واقعیت افزوده موبایل باید برآورده کند، پردازش کارآمد بلادرنگ جریان های داده مانند فریم های ویدئویی و داده های حسگر است. در این تحقیق با مقایسه انواع معماری در این حوزه، یک معماری متناسب با نیازمندی‌های سامانه تشخیص شی و افزودن اطلاعات در بستر واقعیت افزوده موبایل ارائه شد.منابع:Munro, Donald, A. P. Calitz, and Dieter Vogts. "Architecture and Architectural Patterns for Mobile Augmented Reality." South African Computer Journal 33, no. 1 (2021): 59-78.Alvarado, Luis Antonio Rivera, Eduardo López Domínguez, Yesenia Hernández Velázquez, Saúl Domínguez Isidro, and Cora Beatriz Excelente Toledo. "Layered software architecture for the development of mobile learning objects with augmented reality." IEEE Access 6 (2018): 57897-57909.Huang, Zhanpeng, Weikai Li, Pan Hui, and Christoph Peylo. "CloudRidAR: A cloud-based architecture for mobile augmented reality." In Proceedings of the 2014 workshop on Mobile augmented reality and robotic technology-based systems, pp. 29-34. 2014.Benbelkacem, Samir, Nadia Zenati-Henda, Djamel Aouam, Yousra Izountar, and Samir Otmane. "MVC-3DC: Software architecture model for designing collaborative augmented reality and virtual reality systems." Journal of King Saud University-Computer and Information Sciences 32, no. 4 (2020): 433-446.Siriwardhana, Yushan, Pawani Porambage, Madhusanka Liyanage, and Mika Ylianttila. "A Survey on Mobile Augmented Reality With 5G Mobile Edge Computing: Architectures, Applications, and Technical Aspects." IEEE Communications Surveys & Tutorials 23, no. 2 (2021): 1160-1192.Rattanarungrot, Sasithorn, and Martin White. "A service-oriented mobile augmented reality architecture for personalized museum environments." In 2014 International Conference on Virtual Systems & Multimedia (VSMM), pp. 277-284. IEEE, 2014.Panou, Chris, Lemonia Ragia, Despoina Dimelli, and Katerina Mania. "An architecture for mobile outdoors augmented reality for cultural heritage." ISPRS International Journal of Geo-Information 7, no. 12 (2018): 463.مریم مرادیمریم مرادیMon, 31 Jan 2022 14:52:27 +0330https://virgool.ir/@maryam_76sh/معماری-esp-k5bsrdm4nef6واژه ESB کوتاه شده‌ی واژه‌هایEnterprise Service Bus است و ابزاری برای یکپارچه کردن انواع برنامه‌های کاربردی که توسط چندین شرکت تهیه شده است.ESB یک سیستم ارتباطی بین برنامه‌های نرم‌افزاری در تعامل در معماری سرویس‌گرا (SOA) پیاده‌سازی می‌کند و یک معماری نرم‌افزاری برای محاسبات توزیع‌شده ارئه می‌دهد. در واقع یک نوع خاص از مدل کلاینت-سرور است که در آن هر برنامه کاربردی به عنوان سرور و یا مشتری رفتار می‌کند. ESBبا توجه به ارتباطات پروتکل سطح بالا بین برنامه‌ها سبب افزایش چابکی و انعطاف پذیری سیستم می‌شود. این تکنیک برای یکپارچه‌سازی برنامه‌های کاربردی سازمانی (EAI) شامل سرویس‌های پیچیده مورد استفاده قرار می‌گیرد. امروزه در سطح دنیا، بسیاری از شرکتهای قدرتمند و مشهور در زمینه ESB فعالیت دارند.بهترین راه توصیف این ابزار این است که آن را به عنوان مجموعه ای از سوئیچ ها تجسم کرد که می‌توانند یک پیام را در امتداد یک مسیر خاص میان اجزای برنامه بر اساس محتوای پیام و اجرای سیاست های کسب و کاری هدایت کنند.مفهوم ESB مشابه مفهوم bus در معماری سخت‌افزار کامپیوتر است که با طراحی ماژولار و همزمان سیستم‌عامل‌های کامپیوتری با کارایی بالا ترکیب شده است. هدف از توسعه معماری، یافتن مفهومی استاندارد، ساختاریافته برای توصیف پیاده‌سازی اجزای نرم‌افزاری به نام سرویس‌ها است. همچنین ESB یک الگوی پیاده سازی متداول برای معماری سرویس گرا است.استاندارد بین المللی برای مفاهیم و پیاده سازی گذرگاه خدمات سازمانی وجود ندارد. ارائه دهندگان میان افزار پیام محور مفهوم گذرگاه خدمات سازمانی را به عنوان استاندارد برای معماری سرویس گرا پذیرفته اند. پیاده‌سازی‌های ESB از میان‌افزار پیام‌محور مبتنی بر رویداد و استاندارد در ترکیب با صف‌های پیام به عنوان چارچوب‌های فناوری استفاده می‌کنند.هر پیام ورودی به قالب استاندارد تبدیل شده و به مشتری مربوطه ارسال می شود.کارکردیک ESB طراحی سیستم عامل‌های مدرن را برای سرویس‌های مستقل که در شبکه‌های کامپیوتری متفاوت و مستقل اجرا می شوند، اعمال می‌کند. مانند سیستم‌های همروند، یک ESB علاوه بر خدمات پذیرش، تطبیق و مسیریابی درخواست‌های مشتری، خدمات پاسخگویی مناسب را ارائه می‌کند. وظایف اصلی ESB را میتوان به طور خلاصه به شکل زیر توصیف کرد:پیام‌ها میان سرویس‌ها را مسیریابی می‌کند.بر مسیریابی و تبادل پیام میان سرویس‌ها نظارت و کنترل دارد.عدم تطابق بین اجزای سرویس ارتباطی را مدیریت می‌کند.استقرار و نسخه سازی خدمات کنترل می‌کند.استفاده از سرویس‌های جایگزین را پیشنهاد می‌دهد.خدمات کالایی از جمله مدیریت رویداد، تبدیل داده‌ها و نقشه برداری، صف بندی پیام ها و رویدادها و توالی یابی، مدیریت امنیتی، تبدیل پروتکل و اعمال کیفیت مناسب خدمات ارتباطی را ارئه می‌کند.پیشینهاولین استفاده منتشر شده از روش ESB به آقای Roy از گروه گارتنر در سال 2002 و کتاب The Enterprise Service Bus نوشته شده توسط دیوید چاپل نسبت داده شده است. اگرچه تعدادی از شرکت‌ها این روش را منتسب به خود می‌دانند، اما آقای Roy در مصاحبه‌ای گفت: ابتدا این عبارت را از شرکتی به نام Candle شنیده است و افزود: اصلی‌ترین استفاده از ESB محصولی به نام روما در سال 1998 در شرکت کندل است. روما اولین بار در سال 1998 به عنوان محصول ESB فروخته شد و آن را تجاری کرد. محصول سونیک در سال 2002 نیز یکی از ESB های اولیه در بازار بود.ابتدا تعریفی از هر یک از قسمت‎ها ارائه می‌شود.service:برنامه های غیر تکراری و مستقلی که از طریق تبادل پیام با سرویس های دیگر ارتباط برقرار می‌کنند را شامل می‌شود.Bus :متناظر با گذرگاه سخت افزار کامپیوتر است.Enterprise :این مفهوم در ابتدا برای کاهش پیچیدگی یکپارچه سازی برنامه‌های کاربردی سازمانی در یک شرکت تعریف شده است و هم اکنون مورد استفاده قرار می‌گیرد.معماری ESBدر نرم‌افزاری که میان برنامه‌های کاربردی کار می‌کند و ارتباط بین آن‌ها را امکان‌پذیر می‌سازد، پیاده سازی می‌شود. در حالت ایده آل، ESB باید بتواند تمام ارتباطات مستقیم را با برنامه‌های موجود در گذرگاه جایگزین کند، به طوری که تمام ارتباطات از طریق ESB انجام شود. جهت رسیدن به این هدف، ESB باید عملکرد برنامه‌های کاربردی اجزای خود را به روشی معنادار کپسوله‌سازی کند. به طور معمول به کمک استفاده از یک مدل پیام سازمانی امکان‌ پذیر است. در این مدل، مجموعه‌ای استاندارد از پیام های ارسلی و دریافتی در ESB تعریف می‌شود. هنگامی که ESBپیامی دریافت می‌کند، با توجه به سیاست‌های تعریف شده، پیام را به برنامه مربوطه هدایت می‌کند. اغلب، بدلیل آنکه برنامه بدون مدل پیام یکسانی توسعه یافته است، ESB باید پیام را در قالبی مشخص که برنامه بتواند آن را تفسیر کند، ارسال کند.این معماری بر ساخت دقیق مدل پیام سازمانی و طراحی مناسب عملکرد ارائه شده توسط برنامه‌ها پایه گذاری شده اند. اگر مدل پیام به طور کامل عملکرد برنامه را کپسوله سازی نکند، برنامه‌های کاربردی دیگری که مایل به انجام آن عملکرد هستند ممکن است مجبور شوند گذرگاه را دور بزنند و برنامه‌های ناهماهنگ را مستقیماً فراخوانی کنند که با اهداف این معماری مغایرت دارد.برتری این معماری در ماهیت غیر وابسته به زیرساخت و توانایی ادغام در هر شرایط پنهان است.مقایسه ESB و معماری میکروسرویسروش ESB اغلب مواردی از جمله روش پیاده‌سازی و مدیریت مؤثر معماری‌های مبتنی بر SOAP، مانند معماری سنتی سرویس‌گرا را بررسی می‌کند. با این حال، ESB ها استراتژی جریان کار بسیار متفاوتی را نسبت به رویکرد مرتبط با میکروسرویس ها ارئه می‌دهند.برخلاف میکروسرویس ها یا استراتژی های مشابه که واسط اتصالات API بین اجزا هستند، ESB مرکز جریان کار در برنامه است و در واقع یک صف پیام است و تبادل اطلاعات در سراسر برنامه را مدیریت می‌کند.یک ESB تعیین نمی کند که آیا اجزایی که از گذرگاه استفاده می‌کنند محلی یا غیرمحلی هستند یا هیچ الزامات خاصی را برای زبان‌های برنامه نویسی ندارد. ESB روش‌های مختلفی را که اجزا می‌توانند اطلاعات را دریافت یا به دیگر عناصر برنامه ارسال کنند، یکپارچه می‌کند.در قسمت بعد به مزیت، معایب و چالش‌های رو به رو در این معماری پرداخته می‌شود. مزیت‌های ESBدر ESB نحوه جریان کار کنترل می‌شود و تغییرات در اجزا یا افزودن اجزای اضافی به یک برنامه به آسانی انجام می‌شود. همچنین ابزاری مناسب برای اجرای موارد امنیتی و برآورد نیازمندی‌ها، ثبت شرایط عادی یا خطاها و حتی نظارت بر عملکرد تراکنش است. همچنین ESB تعادل بار در سیستم را نیز فراهم می‌کند. به این ترتیب می‌توان چندین نسخه از یک مؤلفه را برای بهبود عملکرد و همچنین پشتیبانی از خطا و شکست در صورت خرابی یک مؤلفه یا منبع، نگهداری کرد.همچنین این ابزار دارای ویژگی مقیاس پذیری است و از سطح خرد تا استقرار در سطح سازمان را پشتیبانی می‌کند. اتصال و قطع کردن سیستم آسان است و به اصطلاح coupling در سیستم کم می‌شود.چالش‌هایک چالش رایج در ESB عدم وجود یک استاندارد پذیرفته شده واحد برای ویژگی‌ها و رفتارها است. اگرچه وظیفه اصلی ESB این است که به عنوان یک گذرگاه پیام عمل کند و پیام ها را بین برنامه‌ها یا مؤلفه‌ها مطابق با یک سیاست تعریف شده، هدایت می‌کند. گاهی این کلید واژه برای توصیف هر چیزی که به نوعی از جریان و فرآیند کار پشتیبانی می‌کند، استفاده می شود. به عنوان مثال، اوراکل شرکت ارائه‌دهنده تکنولوژی، از گذشته چندین نوع میان‌افزار را در دسته‌بندی ESB قرار داده است.هدایت پیام‌ها بر اساس سیاست تعریف شده، یک عملکرد تمایز دهنده ESB از سایر میان افزارها است. برای کاربران بسیار مهم است که به وضوح نیازهای کسب و کار خود را تعریف کنند و سپس ویژگی‌های ESB کاندید خود را در برابر نیازهای از پیش تعریف شده، تأیید کنند.این ابزار معایبی نیز دارد. از جمله معایب آن میتوان به این موارد اشاره کرد. در ESB سرعت ارتباط سرویس‌ها به ویژه سرویس‌های سازگار، کندتر است. همچنین وجود یک نقطه شکست، ممکن است سبب از بین رفتن تمام ارتباطات در سازمان شود. دیگر عیب این ابزار، پیچیدگی بالا در نگهداری و پیکربندی آن است.از جمله محصولات ESB می‌توان موارد زیر را نام برد.محصولات تجاری و اختصاصی:Candle's Roma ESB - bought by IBM and became WebSphere ESBIBM App Connect, formerly IBM Integration Bus and IBM WebSphere ESBInterSystems EnsembleInformation Builders iWay Service ManagerMicrosoft Azure Service BusMicrosoft BizTalk ServerMule ESBOracle Enterprise Service BusProgress Software Sonic ESB (acquired by Trilogy)SAP Process IntegrationTIBCO Software ActiveMatrix BusinessWorkswebMethods enterprise service bus (acquired by Software AG)Sonic ESB from Aureaو محصولات متن باز:Apache CamelApache ServiceMixApache SynapseFuse ESB from Red HatJBoss ESBNetKernelOpen ESBPetals ESBSpring IntegrationUltraESBWSO2 ESBدر ادامه دو نمونه از ابزارهای ESB نام برده، بررسی می‌شود.ابزار Apache Camelاین ابزار یک فریمورک یکپارچه منبع باز است و امکان ادغام با سرعت و به راحتی در سیستم‌های مختلف مصرف کننده یا تولید داده را فراهم می‌کند. Camel از بسیاری از الگوهای یکپارچه سازی سازمانی در کتاب آقای گرگور هوپ و بابی وولف و الگوهای ادغام جدیدتر در معماری‌های میکروسرویس نیز پشتیبانی می‌کند.ابزار Apache Camel مستقل است و می تواند به عنوان یک کتابخانه در Spring Boot، Quarkus، Application Servers و در ابرها تعبیه شود. همچنین این ابزار دارای چندین مؤلفه است که برای دسترسی به پایگاه‌های داده، صف‌های پیام و API استفاده می‌شود و به یکپارچگی تمام اجزا کمک می‌کند. این ابزار بیش از 50 فرمت داده را پشتیبانی می‌کند و امکان ترجمه پیام ها در قالب‌های مختلف را فراهم می‌آورد.ابزار Open ESB"خدمات خود را به روشی هوشمندانه مدیریت کنید." این شعار شرکت open ESB است. بیش از یک دهه است که OpenESB در حال تولید بوده است و یک شالوده اصلی به عنوان پلتفرم یکپارچه سازی فراهم می‌کند. کاربران OpenESB آن را به عنوان یک محصول سبک وزن، با قابلیت اطمینان، مقیاس پذیر، مقاوم در برابر خطا و آسان در کارکرد و پیاده سازی معرفی می‌کنند. OpenESB میلیاردها پروژه‌های و فرآیند پیچیده را در سرتاسر جهان برای بانک‌ها، مؤسسات مالی، شرکت‌های لجستیک یا دولت اجرا می‌کنند. در ادامه ویژگی‌های این ابزار بررسی می‌شود.· زیرساخت هوشمندمفهوم رابط و پیاده‌سازی را به میکرو سرویس‌هایی مانند جاوا یا C++ می‌آورد، طراحی با رابط‌ها و فراخوانی پیاده‌سازی آن‌ها در زمان اجرا، کپسوله‌سازی و جداسازی سرویس را بهبود می‌بخشد و انعطاف‌پذیری به برنامه‌ها می‌دهد.· طراحی معمارانهشامل فرآیند توسعه‌ی تعریف شده بر اساس سه وظیفه اصلی تعریف سرویس، هماهنگ‌ سازی سرویس و ترکیب سرویس است و امکان اتصال و پیکربندی گرافیکی اجزای مختلف و فرآیند را فراهم می‌کند.· ترکیب خدماتمیتوان به صورت دقیق جزئیات استقرار میکروسرویس را تعریف کرد و با کار تیم توسعه مطابقت داد.· ارکستراسیون خدماتبرای یک فرآیند تجاری، ترکیب سرویس برای مدیریت آن کافی نیست و نیاز به جبران خدمات مورد نیاز یا همبستگی دارد. این ابزار کمک می‌کند تا فرآیندهای پیچیده از سرویس‌های میکرو ساخته شود.· تنوع فناوری اطلاعات· پشتیبانی فنیخلاصه و نتیجه گیریهمانطور که بررسی شد، ESB ابزاری برای یکپارچه کردن انواع برنامه‌های کاربردی که توسط چندین شرکت تهیه شده است و یک سیستم ارتباطی بین برنامه‌های نرم‌افزاری در تعامل در معماری سرویس‌گرا (SOA) پیاده‌سازی می‌کند و یک معماری نرم‌افزاری برای محاسبات توزیع‌شده ارئه می‌دهد. در واقع یک نوع خاص از مدل کلاینت-سرور است که در آن هر برنامه کاربردی به عنوان سرور و یا مشتری رفتار می‌کند. برتری این معماری در ماهیت غیر وابسته به زیرساخت و توانایی ادغام در هر شرایط پنهان است.این تکنیک می‌تواند برای شرکت‌های در تعامل با یکدیگر که هر یک سرویسی را ارائه می‌دهند و نیازمند یکپارچه سازی این سرویس‌ها و برنامه‌ها برای یک برنامه کاربردی اصلی اند، مفید باشد. برای مثال شرکت های ارائه دهنده خدمات زیرساخت ابری همانند ابر آروان و شرکت‌های ارائه دهنده خدمات تحت یک برنامه وب همانند شرکت کوئرا می‌توانند برای یکپارچگی برنامه خود از این تکنیک استفاده کنند. همچنین در یک شرکت مانند ترب برای یکپارچگی ارتباطات بخش‌ها و سرویس‌های مختلف میتواند مورد استفاده قرار گیرد.«این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است» https://en.wikipedia.org/wiki/Enterprise_service_bus https://searchapparchitecture.techtarget.com/definition/Enterprise-Service-Bus-ESB https://camel.apache.org/ https://www.open-esb.net/ مریم مرادیمریم مرادیSun, 12 Dec 2021 11:35:03 +0330https://virgool.ir/@maryam_76sh/single-sign-on-and-identity-management-djdydkhzazdoاین مطلب در رابطه با یک یک روش احراز هویت است. در این روش به کاربران امکان داده می‌شود تا با استفاده از مجموعه‌ای از اعتبارنامه‌ها به طور ایمن با چندین برنامه و وب سایت احراز هویت کنند. این روش، بر اساس یک رابطه اعتماد ایجاد شده بین یک برنامه کاربردی (به عنوان ارائه دهنده خدمات) و یک ارائه دهنده هویت (مانند OneLogin ) است. این رابطه اعتماد، اغلب بر اساس گواهی رد و بدل شده میان ارائه دهنده هویت و ارائه دهنده خدمات است. این گواهی می‌تواند برای امضای اطلاعات هویتی که از ارائه دهنده هویت به ارائه دهنده خدمات ارسال می شود استفاده کرد تا ارائه دهنده خدمات از وجود یک منبع مطمئن، اطمینان حاصل کند. در SSO، این داده‌های هویتی token هایی هستند که حاوی اطلاعات مربوط به کاربر همانند آدرس ایمیل یا نام کاربری هستند.جریان ورود معمولاً به این صورت است:1. کاربر به برنامه یا وب‌سایتی که می‌خواهد به آن دسترسی داشته باشد (درواقع همان ارائه‌دهنده خدمات) را مرور می‌کند.2. ارائه‌دهنده خدمات رمزی (token) حاوی اطلاعاتی از کاربر مانند آدرس ایمیل، به سیستم SSO به عنوان بخشی از درخواست احراز هویت کاربر ارسال می‌کند.3. ابتدا ارائه دهنده خدمت شناسایی بررسی می‌کند آیا کاربر قبلاً احراز هویت شده است یا خیر در صورت وارد شدن به کاربر اجازه دسترسی به برنامه ارائه دهنده خدمات را می‌دهد و در ادامه به مرحله 5 می‌رود.4. اگر کاربر وارد سیستم نشده باشد، با ارائه مدارک مورد نیاز توسط ارائه دهنده خدمت شناسایی از کاربر درخواست می‌شود تا وارد شود. این مرحله می تواند با ورود یک نام کاربری و رمز عبور باشد یا شامل نوعی دیگر از احراز هویت مانند استفاده از رمز عبور یک بار مصرف (OTP) باشد.5. هنگامی که ارائه دهنده خدمت شناسایی اعتبار ارائه شده را تأیید کرد، رمزی (token) را به ارائه دهنده خدمات ارسال می‌کند تا تاییدی بر شناسایی موفقیت آمیز باشد.6. این رمز یا token از طریق مرورگر کاربر به ارائه دهنده خدمات ارسال می‌شود.7. رمزی که توسط ارائه‌دهنده خدمات دریافت می‌شود، بر اساس رابطه اعتمادی که بین ارائه‌دهنده خدمات و ارائه‌دهنده هویت در طول پیکربندی اولیه تنظیم شده بود، تأیید می‌شود.8. در گام نهایی به کاربر اجازه دسترسی به ارائه دهنده خدمات داده می‌شود.این گام‌ها در شکل مرور شده‌اند.رمز یا token در SSOتوکن SSO مجموعه ای از داده یا اطلاعات منتقل شده میان سیستم‌ها در طی فرآیند SSO است. داده‌ها می‌توانند به طور ساده شامل آدرس ایمیل کاربر و اطلاعاتی از سیستم ارسال کننده توکن باشد. توکن‌ها باید به‌صورت دیجیتالی امضا شوند تا گیرنده توکن تأیید کند که رمز از یک منبع قابل اعتماد می‌آید و گواهی که برای این امضای دیجیتال استفاده می‌شود در طی فرآیند پیکربندی اولیه مبادله می‌شود.پیاده سازیجزئیات نحوه اجرای یک SSO با توجه به راه حل های مختلف درSSO ، متفاوت است. اما پاسخ به سوالات زیر برای اطمینان از تعیین اهداف مهم است:· به چه نوع کاربرانی خدمات می‌دهید و نیازمندی‌های هریک از آن‌ها چیست؟· آیا به دنبال یک راه حل On Prem هستید یا یک راه حل مبتنی بر ابر نیاز است؟· آیا این راه حل می‌تواند با شرکت و نیازهای شما رشد کند؟· به دنبال چه ویژگی‌هایی هستید تا مطمئن شوید که فقط کاربران قابل اعتماد وارد سیستم می‌شوند؟ MFA، احراز هویت تطبیقی، اعتماد دستگاه، لیست سفید آدرس IP و...؟· نیاز است تا با چه سیستم‌هایی باید یکپارچه شوید؟· آیا به دسترسی API نیاز دارید؟درک تفاوت میان ورود به سیستم و مدیریت رمز عبور مهم است. گاهی اوقات به آن SSO می گویند که می تواند به معنای همان Sign-on و نه Single Sign-on باشد. ممکن است یک فرد نام کاربری و رمز عبور یکسانی داشته باشد، اما هر بار که به برنامه یا وب سایت دیگری منتقل شود، باید آنها را وارد کند. سیستم ذخیره رمز عبور به سادگی اعتبار شما را برای همه برنامه های مختلف ذخیره می‌کند و در صورت لزوم آن‌ها را درج می‌کند. هیچ رابطه اعتمادی بین برنامه‌ها و سیستم ذخیره رمز عبور تنظیم نشده است.با SSO به معنی (Single Sign-On)، پس از ورود به کمک روش SSO می‌توان بدون نیاز به ورود مجدد به همه برنامه‌ها و وب سایت‌های مورد تایید شرکت دسترسی یافت. این شامل برنامه‌های کاربردی ابری و همچنین برنامه‌های کاربردی اولیه است که اغلب از طریق یک پورتال SSO (که پورتال ورود نیز نامیده می شود) در دسترس هستند.ممکن است مشاهده شود گاهی اوقات SSO، به عنوان نرم افزار SSO ، در مقابل روش SSO و در مقابل ارائه دهنده SSO اشاره شده باشد. در بسیاری از موارد، تفاوت ممکن است صرفاً در نحوه طبقه‌بندی شرکت‌ها باشد. یک نرم افزار چیزی را پیشنهاد می‌کند که در محل نصب شده است. معمولاً نرم افزار برای انجام یک مجموعه خاص از وظایف طراحی شده است. یک روش، توانایی گسترش یا سفارشی کردن قابلیت‌های محصول اصلی را نشان می‌دهد و ارائه دهنده راهی برای ارجاع به شرکتی است که راه حل را تولید یا میزبانی می‌کند. به عنوان مثال، OneLogin به عنوان یک ارائه دهنده راه حل SSOشناخته می شود.اصطلاحات زیادی در مورد Single Sign-On (SSO) به کار می‌رود: مدیریت هویت متحد (FIM)اصطلاح OAuth اتصال OpenID (OIDC) زبان نشانه گذاری دسترسی امنیتی (SAML) ورود مشابه (SSO)اصطلاح SSO در واقع بخشی از یک مفهوم بزرگتر به نام مدیریت هویت متحد است. بنابراین گاهی اوقات SSO به عنوان SSO متحد و یکپارچه شناخته می‌شود.اصطلاح FIM فقط به رابطه اعتمادی اشاره دارد که بین دو یا چند دامنه یا سیستم مدیریت هویت ایجاد می‌شود و Single Sign-on یک ویژگی است که در معماری FIM در دسترس است.اصطلاحOAuth یک چارچوب خاص است که می‌تواند بخشی از معماری FIM نیز در نظر گرفته شود. OAuth بر رابطه قابل اعتماد تمرکز می‌کند که اجازه می دهد اطلاعات هویت کاربر در بین دامنه‌ها به اشتراک گذاشته شود.مورد دیگر، OpenID Connect (OIDC) یک لایه احراز هویت است که در بالای OAuth 2.0 برای ارائه عملکرد Single Sign-on ساخته شده است.زبان نشانه گذاری دسترسی امنیتی (SAML) یک استاندارد باز است که برای ارائه عملکرد Single Sign-on طراحی شده است.اصطلاح Same Sign On که اغلب به آن SSO نیز می گویند، در واقع با Single Sign-on یکسان نیست. زیرا هیچ رابطه اعتمادی بین نهادهایی که احراز هویت را انجام می دهند، وجود ندارد. اغلب وابسته به تکرار اعتبارنامه‌ها بین سیستم‌ها است و به اندازه هیچ یک از راه حل های Single Sign-on ایمن نیست.برخی از سیستم‌های خاص وجود دارند که معمولاً هنگام بحث در مورد Single Sign-on ظاهر می‌شوند:Active Directory، Active Directory Federation Services (ADFS) و Lightweight Directory Access Protocol (LDAP).بحث Active Directory که امروزه به طور خاص به عنوان Active Directory Directory Services (ADDS) شناخته می‌شود، سرویس دایرکتوری متمرکز مایکروسافت است. کاربران و منابع برای مدیریت مرکزی به سرویس دایرکتوری اضافه می‌شوند و ADDS با پروتکل های احراز هویت مانند NTLM و Kerberos کار می‌کند. بنابراین، کاربرانی که به ADDS تعلق دارند می‌توانند در دستگاه های خود احراز هویت کنند و به سیستم های دیگری که با ADDSادغام می شوند دسترسی داشته باشند. این یک شکل از Single Sign-on است.بحث دیگر، Active Directory Federation Services (ADFS) نوعی از سیستم مدیریت هویت متحد است که قابلیت‌های Single Sign-on را نیز ارائه می‌کند و از SAML و OIDC پشتیبانی می‌کند. ADFS در درجه اول برای ایجاد اعتماد بین ADDS و سیستم های دیگر مانند Azure AD یا سایر موارد در ADDSاستفاده می‌شود.پروتکل دسترسی به دایرکتوری سبک وزن (LDAP) به سادگی یک استاندارد صنعتی است که راهی برای سازماندهی و جستجوی اطلاعات دایرکتوری تعریف می‌کند. LDAP این امکان را می‌دهد که منابعی مانند کاربران و سیستم‌ها به صورت متمرکز مدیریت شود. با این حال، LDAP نحوه ورود به سیستم ها را تعریف نمی‌کند، به این معنی که پروتکل‌های واقعی مورد استفاده در احراز هویت را تعریف نمی‌کند. با این حال، اغلب به عنوان بخشی از فرآیند احراز هویت و فرآیندهای کنترل دسترسی استفاده می‌شود. به عنوان مثال، قبل از اینکه کاربر بتواند به یک منبع خاص دسترسی پیدا کند، ممکن است از LDAP برای پرس و جو برای آن کاربر و هر گروهی که به آن تعلق دارند استفاده شود تا ببیند آیا کاربر به آن منبع دسترسی دارد یا خیر. راه حل های LDAPمانند OpenLDAP احراز هویت را از طریق پشتیبانی از پروتکل های احراز هویت مانند احراز هویت ساده و لایه امنیتی (SASL) ارائه می‌کنند.انواع تنظیمات SSOبرخی از سرویس های SSO از پروتکل هایی مانند Kerberos و Security Assertion Markup Language (SAML) استفاده می‌کنند.پروتکل SAML یک استاندارد زبان نشانه گذاری توسعه پذیر (XML) است که تبادل اطلاعات احراز هویت و مجوز کاربر را در دامنه های امن آسان می‌کند. سرویس‌های SSO مبتنی بر SAML شامل ارتباطات بین کاربر، به عنوان ارائه‌دهنده هویت که فهرست کاربر و ارائه‌دهنده خدمات را حفظ می‌کند. در یک راه‌اندازی مبتنی بر Kerberos، پس از ارائه اطلاعات کاربری، یک تیکت اعطای تیکت (TGT) صادر می‌شود. TGT تیکت‌های سرویس را برای سایر برنامه‌هایی که کاربر می‌خواهد به آن‌ها دسترسی داشته باشد، بدون اینکه از کاربر بخواهد دوباره اعتبارنامه را وارد کند، واکشی می کند.مبتنی بر کارت هوشمند از کاربر نهایی می خواهد که برای اولین ورود به سیستم از کارتی استفاده کند که دارای اعتبارنامه ورود است. پس از استفاده از کارت، کاربر نیاز نیست نام کاربری یا رمز عبور را دوباره وارد کند. کارت‌های هوشمند SSO یا گواهی‌ها یا رمزهای عبور را ذخیره می‌کنند.امنیت SSOامنیت sso وابسته به شرایط مختلف است. دلایل زیادی مبنی بر بهبود امنیت در SSO وجود دارد. یک روش ورود به سیستم می‌تواند مدیریت نام کاربری و رمز عبور را هم برای کاربران و هم برای مدیران ساده کند. کاربران دیگر نیازی به پیگیری مجموعه‌ مختلف اعتبارنامه ندارند و به سادگی می توانند یک رمز عبور پیچیده‌تر را به خاطر بسپارند. SSO اغلب کاربران را قادر می سازد تا به برنامه های خود بسیار سریع تر دسترسی پیدا کنند. SSO همچنین می‌تواند مدت زمانی خدمت برای کمک به کاربران با رمزهای فراموش شده را کاهش دهد. مدیران می‌توانند الزاماتی مانند پیچیدگی رمز عبور و احراز هویت چند عاملی (MFA) را به صورت متمرکز کنترل کنند.اگرچه ورود به سیستم با این روش برای کاربران راحت است، اما خطراتی را برای امنیت شرکت ایجاد می‌کند. اگر مهاجم کنترل اعتبارنامه SSOکاربر را به دست آورد، به هر برنامه‌ای که کاربر مجوز دسترسی دارد، دسترسی پیدا می‌کند و میزان آسیب احتمالی را افزایش می‌دهد. به منظور جلوگیری از دسترسی مخرب، ضروری است که هر جنبه ای از اجرای SSO با احراز هویت همراه باشد. سازمان‌ها همچنین می‌توانند از احراز هویت دو مرحله ای (2FA) یا احراز هویت چند عاملی (MFA) با SSO برای بهبود امنیت استفاده کنند.مزایا و معایب SSOاز مزایای SSO می‌توان به موارد زیر اشاره کرد:کاربران قادرند رمزهای عبور و نام کاربری کمتری را برای هر برنامه به خاطر بسپارند و مدیریت کنند.فرآیند ثبت نام و استفاده از برنامه‌ ها را آسان می کند.(بدون نیاز به وارد کردن مجدد رمزهای عبور)احتمال فیشینگ را کاهش می دهد.معایب SSO نیز شامل موارد زیر است:سطوح خاصی از امنیت که ممکن است ورود هر برنامه به آن نیاز داشته باشد را پاسخگو نیست.اگر دسترسی از بین برود، کاربران از چندین سیستم متصل به SSO قفل می‌شوند.اگر کاربران غیرمجاز دسترسی پیدا کنند، می توانند به بیش از یک برنامه دسترسی پیدا کنند.ابزارهای حوزه SSOچندین ابزار در حوزه SSO وجود دارد که به خوبی شناخته شده اند. ابزارهای حوزه SSO شامل موارد زیر است:پلتفرم Rippling به کاربران امکان می دهد از چندین دستگاه وارد برنامه های ابری شوند.ابزار Avatier Identity Anywhere یک SSO برای پلتفرم های مبتنی بر کانتینر Docker است.ابزار OneLogin یک پلت فرم مبتنی بر هویت و مدیریت دسترسی (IAM) است که از SSO پشتیبانی می‌کند.ابزار Okta ابزاری با قابلیت SSO است. Okta همچنین از 2FA پشتیبانی می‌کند و در درجه اول توسط کاربران سازمانی استفاده می شود.جمع بندی و نتیجه گیریهمانطور که در مطلب بررسی شد، SSO یک روش احراز هویت است. در این روش به کاربران این امکان داده می‌شود تا با استفاده از مجموعه‌ای از اعتبارنامه‌ها به طور ایمن با چندین برنامه و وب سایت احراز هویت کنند. این روش، بر اساس یک رابطه اعتماد ایجاد شده بین یک برنامه کاربردی و یک ارائه دهنده هویت است. این رابطه اعتماد، اغلب بر اساس گواهی رد و بدل شده میان ارائه دهنده هویت و ارائه دهنده خدمات است. این گواهی می‌تواند برای امضای اطلاعات هویتی که از ارائه دهنده هویت به ارائه دهنده خدمات ارسال می شود استفاده کرد تا ارائه دهنده خدمات از وجود یک منبع مطمئن، اطمینان حاصل کند.این تکنیک می تواند در شرکت هایی مثل اسنپ و کافه بازار برای احراز هویت استفاده شود و در تمام برنامه های کاربردی آن ها با کمک همین روش ارحاز هویت انجام شود و به راحتی کاربر وارد برنامه های کاربردی و وبسایت شود و استفاده نماید.«این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است» https://www.onelogin.com/learn/how-single-sign-on-works https://www.techtarget.com/searchsecurity/definition/single-sign-on مریم مرادیمریم مرادیSun, 12 Dec 2021 11:34:17 +0330https://virgool.ir/@maryam_76sh/containerization-and-container-orchestration-llqzjnrkhaxfمفهوم Containerizationنوعی مجازی سازی در سطح برنامه است که اجازه می دهد چندین نمونه فضای کاربر ایزوله روی یک هسته واحد وجود داشته باشد. به این نمونه ها کانتینر می گویند. کانتینرها یک روش استاندارد برای پکیج کردن کد برنامه، زمان اجرا، ابزارهای سیستم، کتابخانه های سیستم و تنظیمات در یک نمونه ارائه می کنند. کانتینرها یک هسته (سیستم عامل) مشترک دارند که روی سخت افزار نصب شده است. ابزارهای ارکستراسیون کانتینر به طور گسترده بر اساس نسخه‌های منبع باز مانند Kubernetes, LXC ، Docker Swarm یا نسخه تجاری Red Hat OpenShiftهستند.کانتینری‌سازی تقریباً در تمام صنایع و اندازه‌های شرکت در سراسر جهان رو به افزایش است. در واقع، نسخه 2019 گزارش سالانه بررسی پذیرش کانتینرهای Portworxنشان داد که بیش از 87 درصد از سازمان‌های مورد بررسی از فناوری‌های کانتینر استفاده می‌کنند. بیش از 90 درصد آنها از کانتینرسازی در تولید استفاده می کنند. در سال 2021، گزارش پذیرش Kubernetes نشان داد که 68٪ از متخصصان فناوری اطلاعات مورد بررسی، استفاده از کانتینرها را در طول همه‌گیری افزایش داده‌اند. از جمله اهداف آنها سرعت بخشیدن به چرخه های استقرار، افزایش اتوماسیون، کاهش هزینه های فناوری اطلاعات، و توسعه و آزمایش برنامه‌ها و مدل های هوش مصنوعی بود.مزیت کانتینرها· سبکیکانتینرها نسبت به ماشین های مجازی فضای کمتری را در سرور اشغال می‌کنند و معمولاً در چند ثانیه راه اندازی می شود.· انعطاف پذیریکانتینرها بسیار منعطف هستند و نیازی به تخصیص مقدار مشخصی از منابع ندارند. این بدان معناست که کانتینرها می توانند از منابع سرور استفاده موثرتر و پویایی داشته باشند. هنگامی که تقاضا برای یک کانتینر کاهش می‌یابد، منابع اضافی برای استفاده توسط سایر کانتینرها آزاد می شود.· تراکمتراکم به تعداد اشیایی که یک سرور فیزیکی می تواند در یک زمان اجرا کند اشاره دارد. Containerizationاجازه ایجاد محیط های متراکم را می دهد که در آن منابع سرور میزبان به طور کامل استفاده می شود اما بیش از حد مورد استفاده قرار نمی گیرد. در مقایسه با مجازی‌سازی سنتی، کانتینری‌سازی محیط‌های متراکم‌تری را امکان‌پذیر می‌کند زیرا کانتینرها نیازی به میزبانی سیستم عامل خود ندارند.· کاراییهنگامی که فشار منابع بالا وجود دارد، عملکرد برنامه ها با کانتینرها به مراتب بهتر از هایپروایزرها است. زیرا با مجازی سازی سنتی، سیستم عامل مهمان نیز باید نیازهای حافظه خود را برآورده کند و RAM مناسب را از میزبان دور کند.· کارایی تعمیر و نگهداریبا تنها یک هسته سیستم عامل، به روز رسانی ها یا وصله ها در سطح سیستم عامل فقط باید یک بار انجام شوند تا تغییرات در همه کانتینرها اعمال شود. این امر عملکرد و نگهداری سرورها را کارآمدتر می کند.ارکستراسیون کانتینربه استقرار و سازماندهی کانتینرها برای پشتیبانی از برنامه ها، کانتینر ارکستراسیون گفته می شود که از طریق ابزار هماهنگ سازی کانتینر انجام می شود. تقریباً هر برنامه‌ای که نیاز به تغییر و استقرار مجدد سریع و مکرر داشته باشد، برای کانتینری‌سازی مناسب است. همانند برنامه های کاربردی که از معماری Microservices استفاده می‌کنند.چرا به ارکستراسیون کانتینر نیاز داریم؟ارکستراسیون کانتینر برای خودکارسازی وظایف زیر در مقیاس مختلف استفاده می‌شود:• پیکربندی و برنامه ریزی کانتینرها.• تهیه و استقرار کانتینرها.• دسترس پذیری کانتینرها.• پیکربندی برنامه‌ها بر حسب کانتینرهایی که در آن اجرا می شوند.• مقیاس بندی کانتینرها برای متعادل کردن بارهای کاری برنامه در سراسر زیرساخت سیستم.• تخصیص منابع بین کانتینرها.• تعادل بار، مسیریابی ترافیک و کشف سرویس کانتینرها.• نظارت بر سلامت کانتینرها.• ایمن سازی ارتباطات میان کانتینرها.ارکستراسیون کانتینر چگونه کار می کند؟ارکستراسیون کانتینر با ابزارهایی مانند Kubernetes و Docker Swarmکار می‌کند. فایل های پیکربندی، ابزار هماهنگ سازی کانتینر است که چگونگی شبکه بندی میان کانتینرها و مکان ذخیره لاگ های سیستم را مشخص می‌کند. ابزار ارکستراسیون همچنین استقرار کانتینرها در خوشه‌ها را زمان بندی می‌کند و بهترین میزبان را برای کانتینر تعیین می‌کند. پس از تصمیم گیری میزبان، ابزار ارکستراسیون چرخه حیات کانتینر را بر اساس مشخصات از پیش تعیین شده مدیریت می‌کند. ابزار ارکستراسیون کانتینر در محیط هایی که کانتینرها را اجرا می کنند، کار می‌کند.ابزارهای ارکستراسیون برای Docker شامل موارد زیر است:•ابزار Docker Machine: میزبانی را فراهم می‌کند و موتور داکر را نصب می‌کند.• ابزار Docker Swarm: چندین میزبان داکر را در یک میزبان واحد جمع می‌کند. همچنین می تواند با هر ابزاری که با یک میزبان داکر کار می‌کند، ادغام شود.• ابزار Docker Compose: برنامه های کاربردی چند کانتینری را با ایجاد کانتینرهای مورد نیاز مستقر می‌کند.ابزارهای ارکستراسیون برای Kubernetes شامل ویژگی‌های زیر اند:• استقرار و تکثیر خودکار کانتینرها.• مقیاس پذیری برای بزرگ کردن یا کوچک کردن خوشه‌های کانتینری به صورت آنلاین.• گروه های متعادل کننده بار کانتینرها.• برنامه ریزی مجدد خودکار کانتینرهای ناموفق.• قرار گرفتن کنترل شده پورت‌های شبکه با سیستم های خارج از خوشه.ابزارهاابزار Kubernetesیک پلتفرم ارکستراسیون کانتینر منبع باز است که هم از اتوماسیون اعلامی و هم از پیکربندی پشتیبانی می کند. امروزه رایج ترین ارکستراتور کانتینری است. گوگل ابتدا آن را قبل از اینکه به بنیاد محاسبات Cloud Native تحویل دهد، توسعه داد. Kubernetes کانتینرها را با استفاده از فایل های YAML و JSON هماهنگ می‌کند. همچنین مفهوم پادها، گره ها و خوشه ها را معرفی می کند.تفاوت بین پادها، گره ها، خوشه ها و کانتینرها چیست؟· برخی از پلتفرم‌های ارکستراسیون کانتینر، کانتینرها را مستقیماً اجرا نمی‌کنند. در عوض، آن‌ها یک یا چند کانتینر را در ساختاری به نام پاد می پیچند. در یک پاد، کانتینرها می توانند شبکه محلی (و آدرس IP) و منابع را به اشتراک بگذارند در حالی که همچنان از کانتینرهای موجود در سایر پادها جدا هستند. از آنجایی که پادها یک واحد تکرار در پلتفرم ارکستراسیون هستند، آنها به عنوان یک واحد بالا و پایین می شوند، به این معنی که همه کانتینرهای درون آنها بدون توجه به نیازهای فردی آنها، بر اساس آن مقیاس می شوند. یک گره نشان دهنده یک ماشین واحد است، کوچکترین واحد سخت افزار محاسباتی که نمونه های پاد روی آن اجرا می شوند. وقتی چندین گره منابع را به هم می‌کشند، یک خوشه، ماشین اصلی را تشکیل می‌دهند.چندین ارائه دهنده Kubernetes-as-a-Service بر روی پلت فرم Kubernetesساخته شده اند:· سرویس کانتینر الاستیک آمازون (ECS)· خدمات Azure Kubernetes (AKS)· Google Kubernetes Engine (GKE)· RedHat OpenShift Container Platform· VMware Tanzu· Knative· Istio· Cloudify· Rancherدر حالی که ماهیت گسترده Kubernetes می‌تواند مدیریت و تخصیص فضای ذخیره‌سازی را چالش‌برانگیز کند، همچنین می‌تواند برنامه‌های کانتینری‌شده شما را در صورت به خطر انداختن یک کانتینر در معرض مشکلات امنیتی قرار دهد.ابزار MESOSیک پلت فرم ارکستراسیون با مقیاس پذیری آسان (تا 10000 نود)، سبک وزن، در دسترس بودن بالا و پلتفرم های مختلف ارائه می دهد. این برنامه روی لینوکس، ویندوز و OSXاجرا می‌شود و APIهای آن از چندین زبان محبوب مانند جاوا، پایتون و سی پلاس پلاس پشتیبانی می‌کنند. Mesos برخلاف Kubernetes و Docker Swarm فقط مدیریت در سطح خوشه را ارائه می دهد. با این حال، Marathonارکستراسیون کانتینری را به عنوان یک ویژگی ارائه می دهد. همچنین برای شرکت‌های بزرگ ایده‌آل است، زیرا ممکن است برای سازمان‌های کوچک‌تر با بودجه‌های ITکم‌، بسیار زیاد باشد.شرکت های Uber، PayPal، Twitterو Airbnbبرخی از برندهایی هستند که از پلت فرم هماهنگ سازی کانتینر Mesos استفاده می کنند.مقایسه کانتینر و معماری میکروسرویسکانتینرها به بسته‌های نرم‌افزاری اطلاق می‌شوند که شامل همه چیزهایی است که یک واحد برنامه برای عملکرد نیاز دارد. میکروسرویس ها به فناوری اطلاق می شود که تقسیم یک برنامه بزرگ (یکپارچه) را به سرویس های کوچکتر و چندگانه که هر یک عملکرد خاصی را انجام می دهند، ممکن می سازد.اگر میکروسرویس ها را به عنوان کالاهای موجود در یک کانتینر حمل و نقل و کانتینرها و همچنین کانتینرهای بار را در نظر گرفته شود. میکروسرویس ها داخل کانتینر قرار می‌گیرند. معماری میکروسرویس‌ها به مهندسان نرم‌افزار اجازه می‌دهد تا برنامه‌های یکپارچه را به چندین واحد تبدیل کنند که مقیاس‌بندی خودکار، بازسازی به‌صورت جداگانه و سریع‌تر برای استقرار، اصلاح مشکلات و انجام بازیابی اشکال آسان‌تر است.مقایسه کانتینر و ماشین مجازیکانتینرها در بالای سخت افزار یک سرور فیزیکی نصب می‎شوند و یک سیستم عامل واحد را به اشتراک می گذارند. ماشین‌های مجازی (VM) از نرم‌افزار و سخت‌افزار برای ایجاد چندین ماشین مجازی که سیستم‌عامل‌های مختلف را روی یک میزبان اجرا می‌کنند، استفاده می‌کنند. بسیاری ماشین‌های مجازی را با کانتینر اشتباه می‌گیرند زیرا هر دو شکل مجازی‌سازی هستند.امروزه مهندسان می‌توانند یک Hypervisor (سخت‌افزار، سفت‌افزار یا نرم‌افزاری که ماشین‌های مجازی را ایجاد، اجرا و نظارت می‌کند) را در بالای سخت‌افزار یک سرور فیزیکی قرار دهند تا چندین رایانه مجازی تولید کنند. این فرآیند به عنوان مجازی سازی شناخته می شود.مجازی سازی این امکان را فراهم می‌کند که چندین سیستم عامل روی یک سخت افزار اجرا شود. هر ماشین مجازی می‌تواند سیستم عامل خود (سیستم عامل مهمان) را اجرا کند. به این ترتیب، هر ماشین مجازی می‌تواند اپلیکیشن‌ها، کتابخانه‌ها و باینری‌های متفاوتی را از برنامه‌های کنار خود سرویس دهد. ماشین‌های مجازی مهندسین را قادر می‌سازد تا برنامه‌های متعددی را با سیستم‌عامل‌های ایده‌آل بر روی یک سرور فیزیکی اجرا کنند تا قدرت پردازش را افزایش دهند و هزینه‌های سخت‌افزاری را کاهش دهند و دیگر نیازی به اجرای یک برنامه در کل سرور ندارند. اما ماشین های مجازی کامل نیستند. از آنجایی که هر ماشین مجازی یک تصویر سیستم عامل، باینری ها و کتابخانه ها را در داخل خود اجرا می‌کند، می تواند به سرعت حجم خود را افزایش دهد و به سرعت به چندین کاهش یابد که یک گلوگاه عملکردی است.ماشین‌های مجازی همچنین هنگام انتقال نرم‌افزار از یک محیط محاسباتی به محیط دیگر، در اجرای نرم‌افزار مشکل دارند. این می تواند در عصری که کاربران از طریق دستگاه ها برای دسترسی به خدمات از هر کجا و در هر زمان تغییر می‌کنند، محدود کننده باشد.همانطور که قبلاً گفته شد، کانتینرها سبک وزن هستند، منابع سرور میزبان را به اشتراک می گذارند، و به طور منحصر به فردتر، برای کار در هر محیطی طراحی شده اند.مقایسه Docker Container Orchestration و Kubernetes Container Orchestrationابزار هماهنگ‌سازی کانتینر Docker که به نام Docker Swarm نیز شناخته می‌شود، می‌تواند برنامه‌ها را به‌عنوان کانتینر بسته‌بندی و اجرا کنند، تصاویر کانتینر موجود را از دیگران پیدا کند و یک کانتینر را روی لپ‌تاپ، سرور یا ابر (ابر عمومی یا خصوصی) مستقر کنند. ارکستراسیون کانتینر داکر به تنظیمات ساده ای نیاز دارد.ارکستراسیون در خدمات کانتینر برای Kubernetes امکان خوشه بندی کانتینر را از طریق موتور هماهنگ سازی کانتینر فراهم می کند. Kubernetes دارای مدیریت اعلامی است که پیچیدگی را پنهان می کند و منبع باز است بنابراین می توانید آن را در هر جایی اجرا کنید.خلاصه و نتیجه گیریهمانطور که بررسی شد، به استقرار و سازماندهی کانتینرها برای پشتیبانی از برنامه ها، کانتینر ارکستراسیون گفته می شود که از طریق ابزار هماهنگ سازی کانتینر انجام می شود. تقریباً هر برنامه‌ای که نیاز به تغییر و استقرار مجدد سریع و مکرر داشته باشد، برای کانتینری‌سازی مناسب است.این پلتفرم‌ها با توجه به کارایی که دارند میتواند در شرکت‌هایی مانند سروش و بله مورد استفاده قرار گیرند."این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است." https://www.alibabacloud.com/knowledge/what-is-containerization https://avinetworks.com/glossary/container-orchestration/ https://www.cloudzero.com/blog/container-orchestration مریم مرادیمریم مرادیSun, 12 Dec 2021 11:33:51 +0330https://virgool.ir/@maryam_76sh/api-gateway-cqdvvfpom0iaامروزه نیازی روزافزون به برنامه‌های کاربردی بزرگ سازمانی وجود دارد که نیازمند یک معماری مناسب براساس نیازمندی‌های سیستم نرم افزاری است. معماری میکروسرویس در صنعت توسعه نرم‌ افزار محبوب شده است و توسعه دهندگان بسیاری در توسعه‌ ی برنامه‌های کاربردی پیچیده از این معماری استفاده می‌کنند. شاید در ابتدا معماری میکروسرویس پیچیده به نظر آید اما در واقعیت این گونه نیست. در معماری میکروسرویس، هر سرویس مجموعه‌ای از وظایف مرتبط و مستقل از بخش‌های دیگر را انجام می‌دهد. برای مثال در سیستم تولید و مدیریت اخبار سرویس‌هایی از جمله مدیریت ثبت خبر و محتوا، مدیریت فایل‌ها و مدیریت انتشار می‌توان اشاره کرد. در این صورت هر زیر سرویس میتواند خدمات و داده‌های خودش را برای سایر قسمت ها در قالبAPI در اختیار بگذارد. به جای تولید یک وب اپلیکیشن بزرگ مجموعه‌ای از اپلیکیشن‌های کوچک برای انجام یک کار مشخص و در تعامل برای رسیدن به هدف اصلی توسعه می‌یابد. اما اگر تعداد زیرسرویس‌ها زیاد شود و هر برنامه API مربوط به خود را ارائه دهد، برای تعاملات تعداد زیادی آدرس بوجود خواهد آمد که باید مدیریت شود.اگر قصد توسعه یک فروشگاه آنلاین باشد که شامل چند صفحه است. اگر صفحه جزئیات محصولات در نظر گرفته شود، هدف اصلی آن نمایش جزئیات هر محصول است. علاوه بر این شامل اطلاعاتی مانند فروشندگان، بخش نظردهی، بخش ثبت امتیاز، پرسش و پاسخ و پیشنهادات است. اگر از معماری میکروسرویس استفاده نشود و به کمک روش Monolith اپلیکیشن موبایل طراحی شود، به کمک یک درخواست ساده از api مربوطه اطلاعات گرفته می‌شود. اما در معماری میکروسرویس نیاز است تا اطلاعات هر بخش از سرویس مربوطه گرفته شود. برای مثال اطلاعات سرویس سبد خرید، سرویس پرسش و پاسخ، سرویس محصول پیشنهادی و سرویس محصولات از سرویس حاوی اطلاعات مورد نیاز درخواست می‌شود. می‌توان فرض کرد در صورت نیاز اطلاعات یک سرویس، مشتری به طور مستقیم با آن تعامل داشته باشد و درخواست دهد. اما برای یک صفحه ساده همانند صفحه مذکور برای نمایش جزئیات محصول، نیاز است تا به چندین مقصد متفاوت درخواست فرستاده شود و با بالارفتن تعداد درخواست‌ها،ساخت و مدیریت صفحه نیز به شدت سخت و پیچیده خواهد شد. همچنین هر سرویس برای تعامل api مربوطه پروتکل‌های متفاوت مانند Thrift و AMQP دارد که ممکن است برخی از پروتکل به راحتی با وب سازگار نباشند. دیگر چالش زمانی است که نیاز به تغییر میکروسرویس‌ها و یا ادغام یا ترکیب چند میکروسرویس باشد و به احتمال زیاد Refactoring با مشکل مواجه خواهد شد.برای رفع این چالش‌ها، API Gateway مورد استفاده قرار می‌گیرد و روشی بهتر برای تعامل مشتری‌ها با هر سرویس است. در این روش برای ارتباط مشتری با هر یک از سرویس‌های سیستم، تنها از یک گذرگاه api مشترک استفاده می‌شود. به این صورت پیچیدگی‌های معماری داخلی از دید کاربر خارجی پنهان است و فقط با یک api تعامل و ارتباط دارد. Api gateway وظیفه ارتباط با سرویس‌های مختلف و دریافت نتیجه نهایی برای درخواست کاربر دارد. به این ترتیب ارتباط کاربر خارجی به سادگی صورت می‌گیرد. در شکل شمای کلی از این معماری قابل مشاهده است.تمامی درخواست‌های کاربران به api gateway وارد می‌شود. با مسیریابی هر سرویس مربوطه و تعامل با پروتکل‌های تنظیم شده، اطلاعات مورد نیاز برای کاربر آماده می‌شود. در ادامه نکاتی راجع به طراحی ذکر می‌شود. عملکرد و مقیاس پذیریتنها تعداد محدودی از شرکت‌ها مانند نتفلیکس نیاز به پاسخگویی روزانه میلیاردها درخواست دارند. با این حال، در بیشتر برنامه‌ها عملکرد و مقیاس پذیری API Gateway بسیار مهم است و API Gateway باید بر پلتفرمی ساخته شود که از ورودی/خروجی آسنکرون و غیر مسدود کننده پشتیبانی کند. انواع مختلفی از این فناوری‌ها وجود دارد که می‌توان برای پیاده سازی یک API Gateway مقیاس پذیر استفاده کرد. برای مثال در JVM می‌توان از پلتفرم‌های مبتنی بر NIO مانند Netty، Vertx، Spring Reactor یا JBoss Undertow استفاده کرد. یکی از پلتفرم‌های محبوب دیگر Node.js است که بر روی موتور جاوا اسکریپت کروم ساخته شده است. گزینه دیگر استفاده از NGINX Plus است. NGINX Plus یک وب سرور مقیاس پذیر، با کارایی بالا است که پروکسی ارائه می دهد و به آسانی مستقر، پیکربندی و برنامه‌ریزی می‌شود. NGINX Plus می‌تواند احراز هویت، کنترل دسترسی، درخواست‌های تعادل بار، پاسخ‌های ذخیره‌سازی را مدیریت و نظارت کند. استفاده از مدل برنامه نویسی واکنشیاین تکنیک برخی از درخواست‌ها را به سادگی با مسیریابی به سرویس مربوطه پاسخ‌ میدهد. باقی درخواست‌ها با فراخوانی چندین سرویس پشتیبان و جمع‌آوری نتایج، صورت می‌گیرد. برخی از درخواست‌ها، مانند درخواست جزئیات محصول، درخواست‌های مربوط به خدمات پشتیبان مستقل از یکدیگر هستند. به منظور کمینه سازی زمان پاسخ، API Gateway باید درخواست های مستقل را همزمان انجام دهد. در رویکرد مناسب، کد API Gateway با استفاده از رویکرد واکنشی به سبک اعلانی نوشته می‌شود. به عنوان مثال، Future در Scala، CompletableFutureدر جاوا 8 و Promise در جاوا اسکریپت را می‌توان نام برد. استفاده از یک رویکرد واکنشی این امکان را فراهم می‌کند تا کد API Gateway ساده و در عین حال کارآمد نوشته شود. فراخوان خدماتیک برنامه کاربردی مبتنی بر میکروسرویس یک سیستم توزیع شده است و باید از مکانیزم ارتباط بین فرآیندی استفاده کند. یکی از سبک‌های ارتباطی، استفاده از مکانیزم ناهمزمان و مبتنی بر پیام است. برخی از پیاده سازی‌ها از یک واسط پیام مانند JMS یا AMQP استفاده می‌کنند و یا مانند Zeromq، بدون واسط هستند و به طور مستقیم ارتباط برقرار می‌کنند. سبک دیگر ارتباط بین فرآیندی یک مکانیسم همزمان مانند HTTP یا Thrift است. یک سیستم ممکن است از هر دو سبک ناهمزمان و همزمان استفاده کند. API Gateway باید از مکانیسم‌های ارتباطی مختلفی پشتیبانی کند.کشف خدماتدر این تکنیک API Gateway باید آدرس IP و پورت هر میکروسرویسی که با آن در ارتباط است را بداند. در یک برنامه میکروسرویس مبتنی بر ابر، سرویس‌های زیرساخت، مانند کارگزار پیام، معمولاً دارای آدرس استاتیک هستند و می‌توان از طریق متغیرهای محیط سیستم عامل مشخص شوند. با این حال، تعیین مکان یک سرویس برنامه چندان آسان نیست. سرویس‌های برنامه دارای مکان‌هایی به صورت پویا هستند. Api gateway، مانند هر سرویس گیرنده دیگری در سیستم، باید از مکانیسم کشف سرویس سیستم (کشف سمت سرور یا کشف سمت مشتری) استفاده کند.رسیدگی به خرابی‌های جزئییکی دیگر از مسائلی که باید هنگام پیاده سازی یک API Gateway به آن پرداخته شود، مشکل شکست جزئی است. این موضوع در سیستم های توزیع شده زمانی که یک سرویس با سرویس دیگری ارتباط می‌گیرد و کند پاسخ می‌دهد یا در دسترس نیست، ایجاد می‌شود. Gateway API نباید به طور نامحدود منتظر یک سرویس پایین‌تر باشد. API Gateway همچنین می‌تواند داده‌های کش شده را در صورت موجود بودن بازگرداند. به عنوان مثال، از آنجایی که قیمت محصول به ندرت تغییر می کند، در صورتی که سرویس قیمت گذاری در دسترس نباشد، می‌تواند داده‌های قیمت گذاری ذخیره شده را برگرداند. داده‌ها را می توان توسط خود API Gateway ذخیره کرد یا در یک کش خارجی مانند Redis یا Memcached ذخیره کرد.برای نمونه Netflix Hystrix یک کتابخانه فوق العاده مفید برای نوشتن کدی است که خدمات از راه دور را فراخوانی می کند. Hystrix تماس هایی را که از آستانه تعیین شده فراتر می روند، بررسی می‌کند و مشتری را از انتظار بیهوده برای سرویس بی پاسخ باز می‌دارد.نمونه‌هایی از ابزارهایی متن باز برای api gateway شامل موارد زیر است:Kong Gatewayابزاری محبوب مبتنی بر ابر بر پایه پروکسی سبک وزن است. این برنامه به زبان Lua نوشته شده است. این موتور قالب، به زمان رویدادها سرعت میدهد و عملکرد تأخیر و مقیاس‌پذی برای برنامه‌های میکروسرویس تضمین می‌کند. شرکت‌هایی از جمله Nasdaq، Honeywell، Cisco، FAB، Expedia، Samsung، Siemens و Yahoo Japan به طور گسترده از این ابزار استفاده می‌کنند. از مزایا و ویژگی‌های این ابزار میتوان به احراز هویت، کنترل ترافیک، تجزیه و تحلیل، ورود به سیستم، بدون سرور بودن، قابلیت توسعه با استفاده از معماری پلاگین و وجود اسناد مناسب اشاره کرد.Apache APISIXاین ابزار بتدا در فناوری ZhiLiu چین متولد شد. آقای مینگ ون، معاون پروژه، بیان می‌کند که این ابزار چالش‌های مختلفی را در سرویس‌های بومی ابری و میکروسرویس‌ها حل می‌کند. APISIX توسط شرکت‌هایی مانند 360، HelloTalk، NetEase، TravelSky و بسیاری دیگر استفاده می‌شود. Apache APISIX مبتنی بر Nginx و etcd است و دارای مسیریابی پویا و بارگذاری پلاگین است و برای مدیریت API تحت سیستم میکروسرویس مناسب است. نمایی از این ابزار در شکل آورده شده است.Tykیک ابزار api gateway متن باز سازمانی است. از ویژگی‌های آن می‌توان به احراز هویت، محدود کردن نرخ، مدیریت نسخه، اطلاعیه‌ها و رویدادها، نظارت و تجزیه و تحلیل دقیق اشاره کرد.Ocelotهدف این پروژه استفاده از دات نت، میکروسرویس های در حال اجرا یا معماری سرویس گرا است که نیاز به یک نقطه ورود واحد به سیستم خود دارد. روی هر پلتفرمی که ASP.NET Core پشتیبانی می کند اجرا می‌شود.این ابزار به عنوان یک میان افزار به ترتیب عمل می‌کند. HttpRequest در وضعیت پیکربندی نگهداری می‌شود تا زمانی که به میان افزار سازنده درخواست برسد. یک شی HttpRequestMessage ایجاد می‌شود و برای درخواست یک سرویس پایین دست استفاده می‌شود. میان افزاری که درخواست را می‌سازد آخرین قسمت در فرآیند Ocelot است. سپس HttpResponseMessage بر شی HttpResponse نگاشت می‌شود و به کاربر بازگردانده می‌شود.این ابزار ویژگی‌های استانداردی مانند مسیریابی، احراز هویت، محدود کردن نرخ، حافظه پنهان و تعادل بار را ارائه می‌دهد. این برنامه از رمزگذاری خرد، ارسال header میزبان و Swagger پشتیبانی نمی‌کند.Gokuیک دروازه میکروسرویس مبتنی بر Golang است که مسیریابی پویا با کارایی بالا، هماهنگی خدمات، مدیریت چند اجاره‌ای و کنترل دسترسی API را ارائه می‌دهد. Goku یک رابط گرافیکی و یک سیستم پلاگین برای آسان‌تر کردن پیکربندی و گسترش راحت‌تر فراهم می‌کند. به غیر از ویژگی‌های استاندارد، Goku خوشه‌بندی، به‌روزرسانی‌های داغ، هشدار و گزارش‌گیری را نیز ارائه می‌دهد.Express Gatewayاین ابزار بر روی Express.jsساخته شده است. Express Gateway مجموعه‌ای از مؤلفه‌ها است که به‌طور اعلانی پیرامون Expressساخته می‌شوند تا نیازمندی‌هایAPI Gateway را برآورده کنند. قدرت Express Gateway از اکوسیستم غنی پیرامون میان‌افزار Expressاستفاده می‌کند.شرکت هایی از جمله Joyent، The Linux Foundation، VIRICITI، Switch Media، Coozy و Musement به طور گسترده از Express Gateway استفاده می‌کنند.این ابزار ساده و سریع است و تمام ویژگی های اصلی را داراست.Glooیک API Gatewy و کنترل کننده ورودی ویژه برای محیط‎های ابری است. این برنامه بر روی Envoy Proxyساخته شده است تا ترافیک را در سراسر سرویس‌های برنامه متصل، ایمن و کنترل کند.از ویژگی‌های این ابزار می‌توان به پورتال توسعه دهندگان، WAF، پیشگیری از دست دادن داده، احراز هویت، محدود کردن نرخ پیشرفته و مدیریت چند خوشه ای اشاره کرد.KrakenDابزاری منبع باز با عملکرد فوق العاده بالا است. عملکرد اصلی آن ایجاد یک API به عنوان جمع کننده بسیاری از میکروسرویس‌ها در نقاط پایانی است و کارهای سنگین از جمله تجمیع، تبدیل، فیلتر، رمزگشایی و احراز هویت را به طور خودکار انجام می دهد و به خوبی ساختار یافته و لایه بندی شده است. KrakenD ادعا می‌کند سریعتر از Kong و Tyk است.FusioWSO2یک راه حل مدیریت API در چرخه حیات کامل است که می‌تواند در هر مکانی اجرا شود. می‌توان آن را در حالت اولیه، ابری یا به صورت ترکیبی مستقر کرد و اجزای آن در چندین زیرساخت ابری و اولیه توزیع و مستقر شود.ApigeeCloud EndpointsAmazon API GatewayAzureهنگامی که API نوشته و آماده شد، نظارت و ایمن کردن آن نباید فراموش شود. برای افراد در حال توسعه برنامه نرم افزاری جهت تسریع در آزمایش و توسعه API، این ابزارهای متن باز می‌توانند مفید باشند.خلاصه و نتیجه‌ گیری معماری میکروسرویس در صنعت توسعه نرم‌ افزار محبوب شده است و توسعه دهندگان بسیاری در توسعه‌ ی برنامه‌های کاربردی پیچیده از این معماری استفاده می‌کنند. در معماری میکروسرویس، هر سرویس مجموعه‌ای از وظایف مرتبط و مستقل از بخش‌های دیگر را انجام می‌دهد. برای اکثر برنامه‌های کاربردی مبتنی بر میکروسرویس، پیاده‌سازی یک API Gatewayبه عنوان یک نقطه ورودی واحد در یک سیستم، نیاز است. Gateway API مسئول مسیریابی درخواست، ترکیب و تفسیر پروتکل است و به هر یک از مشتریان برنامه یک API ارائه می‌کند. API Gateway همچنین می‌تواند با برگرداندن داده‌های ذخیره‌شده یا پیش‌فرض، خرابی‌های سرویس‌های پشتیبان را پنهان کند.شرکت سورنا از نمونه شرکت‌هایی در ایران است که در این زمینه خدمات ارائه می‌دهد. همان طور که در این گزارش اهمیت معماری میکروسرویس مرور شد این معماری امروزه در بسیاری از سامانه مورد استفاده قرار میگیرد. api gateway یک تکنیک مهم در این نوع معماری است. از جمله شرکت‌هایی که می‌توانند از این تکنولوژی بهره ببرند سامانه‌های فروشگاهی و خدمت رسان با درخواست های بالا و پیچیده هستند. برای نمونه این خدمات می‌تواند برای شرکت‌هایی همانند دیجیکالا و ترب قابل استفاده باشد و عملکرد سیستم را بهبود بخشیده و از پیچیدگی آن کاسته شود.«این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است» https://www.nginx.com/blog/building-microservices-using-an-api-gateway/ https://geekflare.com/api-gateway https://nikamooz.com/what-micro-service مریم مرادیمریم مرادیSun, 12 Dec 2021 11:33:24 +0330https://virgool.ir/@maryam_76sh/معماری-message-queue-jgop26abrmiwدر علوم کامپیوتر، صف‌های پیام و صندوق‌های پستی اجزای مهندسی نرم‌افزار هستند که معمولاً برای ارتباطات بین پردازه‌ها یا برای ارتباطات بین تردهای یک پردازه استفاده می‌شوند. صف‌ها برای پیام رسانی استفاده می‌شوند. سیستم های ارتباطی گروهی نیز مشابه این عملکرد را ارائه می دهند.پارادایم صف مشابه الگوی صادرکننده - امضا کننده است و معمولاً بخشی از یک سیستم میان افزار پیام محور بزرگتر است. اکثر سیستم‌های پیام‌رسان از دو مدل‌ الگوی صادرکننده - امضا کننده و مدل‌های الگوی صف پیام در رابط خود پشتیبانی می‌کنند. به عنوان مثال سرویس پیام جاوا (JMS) یک نمونه از آن است.صف های پیام یک الگوی ارتباطی ناهمزمان را بین دو یا چند پردازه یا ترد پیاده سازی می‌کنند که به موجب آن طرف فرستنده و گیرنده نیازی به تعامل با صف پیام دقیقا در همان زمان ندارند. پیام هایی که در صف قرار می گیرند تا زمانی که گیرنده آن‌ها را بازیابی کند، ذخیره می شوند. صف‌های پیام در اندازه داده‌هایی که ممکن است در یک پیام منتقل شوند و تعداد پیام‌هایی که ممکن است در صف باقی بمانند، محدودیت‌هایی ضمنی یا صریح دارند.بسیاری از پیاده سازی های صف پیام به صورت داخلی در یک سیستم عامل یا در یک برنامه کاربردی عمل می‌کنند که به طور خاص برای اهداف آن سیستم هستند. در پیاده سازی‌های دیگر امکان پیام رسانی میان سیستم های مختلف کامپیوتری، اتصال بالقوه برنامه های کاربردی و سیستم عامل های مختلف فراهم می‌شود. سیستم‌های صف پیام معمولاً قابلیت انعطاف‌پذیری به سیستم می‌دهند تا اطمینان حاصل شود پیام‌ها در صورت خرابی سیستم از دست نروند. نمونه‌هایی از پیاده‌سازی تجاری این نوع نرم‌افزار صف‌بندی پیام شامل IBM MQ (سری MQ سابق) و Oracle Advanced Queuing (AQ) است. یک استاندارد در زبان جاوا به نام Java Message Service وجود دارد که چندین نوع پیاده سازی اختصاصی و رایگان دارد.سیستم‌ عامل‌های بلادرنگ (RTOS) مانند VxWorks و QNX استفاده از صف پیام به‌عنوان مکانیسم ارتباطی اولیه بین فرآیندی یا میان تردها ترغیب می‌کند و می تواند یکپارچگی ارسال پیام و زمان بندی CPU را ارائه دهد. نمونه‌های اولیه سیستم‌ عامل‌های بلادرنگ ​​تجاری که مبنای صف پیام را برای ارتباطات بین تردها ترغیب می‌کردند نیز شامل VRTX و pSOS+ هستند که هر دو در اوایل دهه 1980 ظهور کرده اند. زبان برنامه نویسی Erlang از فرآیندها برای ایجاد همزمانی و موازی سازی استفاده می‌کند. این فرآیندها به صورت ناهمزمان با استفاده از صف پیام ارتباط برقرار می‌کنند.نرم افزار صف پیام می تواند اختصاصی، متن باز یا ترکیبی از هر دو باشد که در سرورهای خصوصی یا در سرورهای ابری خارجی (سرویس صف پیام) اجرا می‌شوند.میان افزارهای اختصاصی سابقه زیادی دارند و شامل محصولاتی از ابتدای ظهور صف پیام‌ها، مانند IBM MQ، محصولات مرتبط با سیستم‌عامل‌های خاص، مانند مایکروسافت Message Queuing (MSMQ) می‌شوند. ارائه دهندگان خدمات ابری همچنین راه حل‌های اختصاصی خود مانند Amazon Simple Queue Service (SQS)، StormMQ، Solace و IBM MQ را ارائه می‌دهند.میان افزارهای منبع باز پیام رسانی شامل Apache ActiveMQ، Apache Kafka، Apache Qpid، Apache RocketMQ، Enduro/X، JBoss Messaging، JORAM، RabbitMQ، Sun Open Message Queue و Tarantool است.محصولات Solace، Apigee و IBM MQ نیز نمونه هایی از میان افزارهای پیام رسانی مبتنی بر سخت افزار هستند.نحوه استفادهدر یک پیاده سازی معمول در صف پیام، یک مدیر سیستم، نرم افزار صف پیام را نصب و پیکربندی می‌کند و یک صف پیام با نامی مشخص تعریف می‌کند و یا یک سرویس صف پیام ثبت می‌کنند. سپس یک برنامه یک روال نرم افزاری را ثبت می‌کند که پیام‌های قرار داده شده در صف را گوش می دهد. برنامه های بعدی ممکن است به صف متصل شوند و پیامی را به آن منتقل کنند. نرم افزار مدیریت صف تا زمانی که یک برنامه دریافت کننده متصل شود، پیام‌ها را ذخیره می‌کند و سپس روال نرم افزار ثبت شده را فراخوانی می کند و برنامه دریافت کننده، پیام را با روشی مناسب پردازش می‌کند.اصططلاحات و مفاهیمی برای مفهوم دقیق ارسال پیام وجود دارد که در ادامه اشاره می‌شود:دوام: پیام ها ممکن است در حافظه نگهداری شوند، روی دیسک نوشته شوند یا در یک DBMS ثبت شوند.سیاست های امنیتی: کدام برنامه‌ها میتوانند به این پیام ها دسترسی داشته باشند و کدامیک نباید دسترسی داشته باشند؟سیاست پاکسازی پیام: صف‌ها یا پیام‌ها ممکن است یک زمان مشخص به نام زمان حیات داشته باشند.فیلتر کردن پیام: برخی سیستم‌ها از فیلتر کردن داده‌ها پشتیبانی می‌کنند تا کاربر مربوطه فقط پیام‌هایی را ببیند که با معیارهای از پیش تعیین‌شده و مورد نیازش مطابقت دارند.سیاست ارسال: تضمین کردن تحویل پیام حداقل یک بار یا بیش از یک بار نیاز است؟سیاست های مسیریابی: در سیستمی با تعداد زیادی سرور صف، چه سرورهایی باید پیام یا پیام های صف را دریافت کنند؟سیاست‌های دسته‌بندی: آیا پیام‌ها باید در لحظه تحویل داده شوند؟ یا اینکه سیستم باید کمی صبر کند و سعی بر ارسال همزمان چندین پیام باشد؟معیارهای صف: چه زمانی یک پیام باید در صف قرار گیرد؟ چه زمانی یک صف آن را داراست؟ یا چه زمانی حداقل به یک صف از راه دور ارسال شده است؟ یا چه زمانی به همه صف‌ها ارسال شده است؟اعلان رسید: ممکن است ارائه دهنده نیاز داشته باشد بداند که برخی یا همه مشترکین پیامی را دریافت کرده اند یا خیر؟این موارد ملاحظاتی هستند که می توانند تأثیرات قابل توجهی بر معناشناسی معاملات، قابلیت اطمینان سیستم و کارایی سیستم داشته باشند.استانداردها و پروتکل‌هاگذشته، صف پیام‌ها از پروتکل‌های بسته و اختصاصی استفاده می‌کردند که توانایی سیستم‌ عامل‌ها یا زبان‌های برنامه‌نویسی مختلف را برای تعامل در مجموعه‌ای از محیط‌های ناهمگون محدود می‌کردند.اولین تلاش برای فراگیرتر کردن صف پیام ها، مشخصات JMS Sun Microsystems بود که یک انتزاع جاوا برای API مشتری ارائه می کرد و به توسعه دهندگان جاوا اجازه داد تا بین ارائه دهندگان صف پیام (به روشی مشابه توسعه دهندگان پایگاه داده های SQL) جابجا شوند. در عمل، با توجه به تنوع تکنیک ها و سناریوهای صف بندی پیام، این روش آنقدر کارایی در عمل نداشت. به این ترتیب پروتکل‌ها و استانداردهایی ایجاد شد. سه استاندارد در اجرای صف پیام منبع باز شامل موارد زیر است:· پروتکل صف پیام پیشرفته (AMQP): پروتکل صف پیام غنی از ویژگی، از آوریل 2014 به عنوان ISO/IEC 19464 تایید شده است.· پروتکل پیام رسانی متن محور (STOMP): پروتکل پیام ساده و متن محور· در MQTT (قبلاً MQ Telemetry Transport نامیده می شد): پروتکل صف پیام سبک به ویژه برای دستگاه‌های کم توان.دو پروتکل اول در سطح HTTP وMQTT در سطح TCP/IP عمل می‌کنند. برخی از پیاده سازی های اختصاصی نیز از HTTP برای ارائه صف پیام از پیاده سازی هایی مانند SQS آمازون استفاده می‌کنند زیرا همیشه امکان لایه‌بندی رفتار ناهمزمان (که برای صف‌بندی پیام لازم است) روی یک پروتکل همزمان وجود دارد. با این حال، چنین پیاده‌سازی‌هایی توسط پروتکل زیربنایی در این مورد محدود شده‌اند.تفاوت همزمانی و نا همزمانیبسیاری از پروتکل‌های ارتباطی شناخته شده‌تر در حال استفاده، به‌صورت همزمان عمل می‌کنند. پروتکل HTTP که در شبکه جهانی وب و در خدمات وب استفاده می شود یک مثال واضح ارائه می دهد که در آن کاربر درخواستی برای یک صفحه وب ارسال می کند و سپس منتظر پاسخ می ماند.با این حال، سناریوهایی وجود دارد که در آنها رفتار همزمان مناسب نیست. به عنوان مثال، AJAX (جاوا اسکریپت ناهمزمان و XML) می تواند برای ارسال ناهمزمان متن، پیام های JSON یا XML برای به روز رسانی بخشی از یک صفحه وب با اطلاعات مرتبط تر استفاده شود. Google از این رویکرد برای Google Suggest خود استفاده می‌کند، یک ویژگی جستجو که درخواست‌های نیمه تایپ‌شده کاربر را به سرورهای Google ارسال می‌کند و فهرستی از درخواست‌های کامل احتمالی را برمی‌گرداند. این لیست به صورت ناهمزمان با تایپ کاربر به روز می شود. نمونه های ناهمزمان دیگر در سیستم های اطلاع رسانی رویداد و سیستم های انتشار/اشتراک وجود دارد. یک برنامه ممکن است نیاز داشته باشد که به دیگری اطلاع دهد که رویدادی رخ داده است، اما نیازی نیست منتظر پاسخ باشد. در سیستم‌های انتشار/اشتراک، یک برنامه کاربردی اطلاعات را برای هر تعداد مشتری برای خواندن منتشر می‌کند. در هر دو مثال فوق منطقی نیست که فرستنده اطلاعات مجبور باشد برای مثال اگر یکی از گیرندگان از کار افتاده بود منتظر بماند.برنامه ها نباید منحصراً همزمان یا ناهمزمان باشند. یک برنامه تعاملی ممکن است نیاز داشته باشد که فوراً به بخش‌های خاصی از یک درخواست پاسخ دهد، اما ممکن است قسمت‌های دیگر را در صف قرار دهد تا مدتی بعد انجام شود.در تمام این شرایط، داشتن یک سیستم فرعی که صف بندی پیام را انجام می دهد (یا به طور متناوب، یک سیستم پیام رسانی پخش) می تواند به بهبود رفتار سیستم کلی کمک کند.مزیت هاراه‌حل‌های صف پیام به طور گسترده در صنایع مورد استفاده قرار می‌گیرند و می‌توانند مجموعه‌ای از مزایا را به توسعه‌دهندگان و مدیران سیستم ارائه دهند، از جمله موارد زیر:ارسال قابل اعتماد پیام: استفاده از صف پیام می تواند اطمینان حاصل کند که پیام های مهم تجاری بین برنامه ها از بین نخواهند رفت و فقط یک بار به گیرنده تحویل داده می شوند. با وجود این ویژگی، منطق حذف مجدد یا جلوگیری از ضرر اضافی ضروری نیست.اتصال بین برنامه‌ای: برخی از راه حل های صف پیام می توانند رمزگذاری پیام، تراکنش و سایر جنبه های ارتباطی بین برنامه ها و خدمات را مدیریت کنند. این امر توسعه اپلیکیشن را ساده می کند و معماری های متفاوت را قادر می سازد با یکدیگر کار کنند.تطبیق پذیری: راه حل های صف پیام می توانند چندین زبان مانند Java، Node.js، COBOL، C/C++، Go، .NET، Python، Ruby و C# را پشتیبانی کنند. آنها همچنین می توانند از چندین رابط برنامه نویسی برنامه (API) و پروتکل ها، از جمله MQTT، AMQP، و REST و همچنین موارد دیگر پشتیبانی کنند.انعطاف‌پذیری: پیام‌رسانی ناهمزمان تضمین می‌کند که خطاهای خاص برنامه تأثیری روی سیستم نخواهد داشت. اگر یکی از اجزای سیستم متوقف شود، بقیه می توانند به تعامل با صف و پردازش پیام ها ادامه دهند وکاهش احتمال اینکه پایداری کل سیستم تحت تأثیر خرابی یک قسمت قرار گیرد.بهبود امنیت: یک صف پیام ممکن است بتواند همه پیام‌ها را شناسایی و احراز هویت کند و در برخی از راه‌حل‌های صف پیام، می‌توان آن‌ها را طوری تنظیم کرد که پیام‌ها را در حالت استراحت، در حال انتقال یا سرتاسر رمزگذاری کنند. این می‎تواند به امنیت کلی برنامه ها و زیرساخت کمک کند.انتقال فایل یکپارچه: برخی از راه حل‌های صف پیام دارای ویژگی های اضافی مانند توانایی انتقال فایل‌ها هستند و می‌تواند جایگزینی برای FTP باشد.مقایسه با دیگر نرم افزارهادر مقایسه با پایگاه داده، صف های پیام را نمی توان برای اهداف ذخیره سازی استفاده کرد. در مقایسه با سرویس وب، سرویس های وب نمی توانند تحویل پیام را تضمین کنند در حالیکه صف‌ها این ویژگی را دارند. در مقایسه با گذرگاه پیام، اگر قرار باشد برنامه‌های جداشده از طریق یک گذرگاه پیام ارتباط برقرار کنند، پیام‌ها باید به گونه‌ای تبدیل شوند که همه از یک نوع باشند. اما در صف‌های پیام، فرقی نمی‌کند از نوع مشابه یا متفاوت باشند.ابزارهاMuleSoft Anypoint Platform.IBM MQ.Azure Scheduler.Apache Kafka.TIBCO Rendezvous.RabbitMQ.IBM Cloud Pak for Integration.Google Cloud Pub/Sub.ابزار RabbitMQ· تهیه کننده پیامی را برای تبادل منتشر می‌کند و باید نوع آن باید مشخص شود.· پیام برای تبادل دریافت می‌شود و مسئول مسیریابی پیام می‌شود. بسته به نوع مبادله، ویژگی‌های پیام مختلفی مانند کلید مسیریابی در نظر گرفته می‌شود.· اتصالات باید از تبادل به صف ایجاد شود. تبادل پیام بسته به ویژگی‌های پیام به صف‌ها هدایت می‌شود.· پیام ها در صف می مانند تا زمانی که توسط یک مصرف کننده مدیریت شوند.· مصرف کننده پیام را مدیریت می کند.انواع تبادل:direct: پیام به صف هایی هدایت می شود که کلید اتصال آن‌ها دقیقاً با کلید مسیریابی پیام مطابقت دارد.Fanout: یک مبادله fanout پیام ها را به تمام صف‌های متصل به آن هدایت می‌کند.topic: تطبیق بین کلید مسیریابی و الگوی مسیریابی مشخص شده در binding انجام می دهد.header: از ویژگی های هدر پیام برای مسیریابی استفاده می کنند.ابزار kafkaآپاچی کافکا یک سیستم انتشار/اشتراک بسیار محبوب است که می تواند برای پردازش قابل اعتماد جریانی از داده ها استفاده شود.می‌توان با استفاده از کدهای موجود در مخزن kmq که در GitHub در دسترس است، نحوه عملکرد این کار را در عمل امتحان کرد. بخش اصلی پیاده سازی در ماژول اصلی قرار دارد که شامل کلاس های زیر است:KmqClient - یک رابط به سبک تکرار کننده برای خواندن پیام ها از یک موضوع صف و ارسال نشان‌گرهای شروع ارائه می دهد. پس از پردازش پیام ها، هر کدام باید با استفاده از متد processed تایید شوند. به عبارت دیگر، جریان پردازش پیام 5 مرحله ای را مدیریت می‌کند.RedeliveryTracker - یک برنامه Kafka+Akka و یک سرویس راه اندازی می کند که پیام هایی را که باید دوباره تحویل داده شوند را ردیابی می کند و در صورت نیاز تحویل مجدد را انجام می دهد.MarkerKey، MarkerValue - کلاس‌هایی که نشانگرهای شروع و پایان را نشان می‌دهد.KmqConfig - کلاس پیکربندی حاوی نام موضوعات صف و نشانگر.ماژول example-java شامل دو نوع تنظیم پردازش پیام است، یکی با استفاده از نمونه تعبیه شده کافکا، و دیگری با استفاده از یک نمونه مستقل کافکا که در پس‌زمینه اجرا می‌شود. می‌توان کلاس EmbeddedExample یا سه کلاس مستقل جداگانه را برای آزمایش اجرا کرد. همچنین یک نمونه Scala مستقل در example-scala وجود دارد که شامل پیاده‌سازی مجدد KmqClient با استفاده از جریان‌های reactive-kafka و Akka است.نتیجه گیری صف پیام به سرورهای وب این امکان را می دهد که به درخواست ها به سرعت پاسخ دهند به جای اینکه مجبور باشند پردازه‌های سنگینی انجام دهند که ممکن است زمان پاسخ را به تاخیر بیندازد. صف پیام زمانی که لازم است پیامی را بین چندین مصرف کننده توزیع کرد یا بارها را متعادل کرد مناسب است.مصرف کننده پیامی را از صف خارج می کند و شروع به پردازش می‌کند. در همان زمان، تولید کننده در صف پیام های جدید است. مصرف کننده می تواند در سروری کاملاً متفاوت از سازنده باشد یا می تواند در همان سرور قرار گیرد. درخواست را می توان در یک زبان برنامه نویسی ایجاد کرد و به زبان برنامه نویسی دیگری رسیدگی کرد. نکته این است که این دو برنامه فقط از طریق پیام هایی که برای یکدیگر ارسال می کنند ارتباط برقرار می کنند، که به این معنی است که فرستنده و گیرنده اتصال کمی دارند.این ابزار همانطور که توضیح داده شد میتواند در شرکت هایی مانند آپ و بام که نیاز به پاسخ سریع دارد و ارسال پیام باید تضمین شود میتواند مناسب باشد.«این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است»منابعhttps://softwaremill.com/using-kafka-as-a-message-queue/ https://en.wikipedia.org/wiki/Message_queue https://aws.amazon.com/message-queue/ https://www.cloudamqp.com/blog/part1-rabbitmq-for-beginners-what-is-rabbitmq.html https://www.ibm.com/cloud/learn/message-queues مریم مرادیمریم مرادیSun, 12 Dec 2021 11:32:43 +0330https://virgool.ir/@maryam_76sh/domain-driven-design-ddd-bbhmedkrb0ptطراحی دامنه محور (DDD) حدود 15 سال است که وجود دارد. این نام توسط اریک ایوانز در کتاب وی به نام "طراحی دامنه محور: مقابله با پیچیدگی در قلب نرم افزار" ابداع شد.طراحی دامنه محور (DDD) رویکردی برای توسعه نرم افزار برای نیازهای پیچیده با اتصال عمیق پیاده سازی به یک مدل در حال تکامل از مفاهیم اصلی کسب و کار است. در این مفهوم ساختار و زبان کد نرم افزار (نام کلاس ها، روش های کلاس، متغیرهای کلاس) باید با دامنه تجاری مطابقت داشته باشد. به عنوان مثال، اگر نرم افزاری برنامه های وام را پردازش کند، ممکن است کلاس هایی مانند LoanApplication و Customerو روش هایی مانند AcceptOffer و Withdraw داشته باشد.فرض های اولیه این معماری موارد زیر است:تمرکز اولیه پروژه روی دامنه اصلی و منطق دامنه قرار دارد.طرح های پیچیده بر روی یک مدل قرار داده می‌شوند.همکاری خلاقانه بین متخصصان فنی و متخصصان حوزه به منظور کاهش مشکلات در قلب مفاهیم است.معماری DDD یک فناوری نیست، بلکه اصطلاحات، شیوه ها و اصول را برای حمایت از تصمیم گیری در حوزه های تجاری پیچیده معرفی می‌کند. اگر پیچیدگی دامنه زودتر و به درستی در طراحی برنامه مورد توجه قرار نگیرد، بهترین فناوری به ایجاد سیستمی که قابل نگهداری، قابل گسترش و غیره باشد کمکی نخواهد کرد.علاوه بر این، DDD یک زبان مشترک و فراگیر را معرفی می‌کند که می تواند همکاری تیم‌ها را بهبود بخشد تا ارتباط میان افراد با پیشینه ها و دیدگاه های مختلف سهل گردد. به عنوان مثال، کارشناسان حوزه عمل را درک می کنند و طراح سیستم فناوری را درک می کند.در زمینه Microservice Architectures، توسعه دهندگان و معماران به دنبال روش یا ابزاری برای تعریف محدوده و اندازه هر Microserviceبودند. تعیین این مرز آسان نیست و اگر تصمیمات اساسی در مورد چگونگی "برش" اشتباه باشد، سیستم به سرعت به اصطلاح معروف "big ball of mud" تبدیل خواهد شد. DDD مفهوم زمینه های محدود را معرفی کرد تا به پاسخگویی به سوالات کمک کند. اما DDD حاوی مفاهیم و اصول بیشتری است که به ایجاد سیستم های قوی و قابل نگهداری کمک می‌کند. مایکل پلود در مورد اینکه چگونه اصول DDDمی تواند به ایجاد میکروسرویس های خوب کمک کند، مطالبی را ارائه داده است.مروزه سیستم های مدرن اغلب توزیع شده و واکندار اند و از پیام رسانی ناهمزمان استفاده می‌کنند. چنین معماری هایی مستقیماً به چالش هایی مانند مدیریت پیام های متعدد یا تحویل خارج از دستور منجر می‌شود. در مقاله‌ای وان ورنون نشان می‌دهد که چگونه DDDمی‌تواند به مدیریت این عدم قطعیت از طریق استفاده از مدل‌سازی خوب کمک کند.منبع یابی رویداد (event sourcing) رویکردی برای ذخیره داده‌ها است و فقط از دستورات SQL INSERTو SELECT استفاده می کند. اگرچه منبع یابی رویداد بخشی از DDDنیست اما هر دو مفهوم به خوبی یکدیگر را تکمیل می کنند.الگوی طراحی CQRSجداسازی سمت نوشتن از سمت خوانده شده یک برنامه کاربردی را توصیف می کند. CQRSو DDD لزوماً به یکدیگر تعلق ندارند، بلکه به خوبی یکدیگر را تکمیل می کنند، به همین دلیل است که ترکیب آنها اغلب در عمل مورد استفاده قرار می گیرد.اگرچه این مفاهیم به خودی خود ایستاده اند و می توان آنها را به طور جداگانه به کار برد، اما می توان مشاهده کرد که هر سه با هم اغلب با هم ترکیب می شوند.مفاهیم DDDحتی از روش چابک به خوبی پشتیبانی می کنند. بسیاری از رهبران فکری چابک وجود دارند که از DDD حمایت می کنند به عنوان مثال، مارتین فاولر در صفحه وب خود یا کنت بک در پشت جلد کتاب ایوانز در مورد DDD صحبت می‌کند. "اگر می خواهید کارها را درست انجام دهید، گاهی باید کمی بیشتر در مورد آن فکر کنید. فقط در آن عجله نکنید، به خصوص اگر از مفاهیم پیچیده ای مانند CQRS و Event Sourcing استفاده کنید."از جمله ابزارهای این مفهوم میتوان موارد زیر را نام برد.ابزار Actifsource، یک پلاگین برای Eclipse که توسعه نرم افزار را با ترکیب DDDبا مهندسی مدل محور و تولید کد امکان پذیر می‌کند.ابزار CubicWeb، یک چارچوب وب معنایی منبع باز که به طور کامل توسط یک مدل داده هدایت می شود.ابزار OpenMDX، یک چارچوب MDA منبع باز، مبتنی بر جاوا با پشتیبانی از Java SE، Java EE و .NETابزار Restful Objects، استانداردی برای نگاشت یک API Restful بر روی یک مدل شی دامنه است.«این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است» https://en.wikipedia.org/wiki/Domain-driven_design https://medium.com/modern-software-architecture/modern-software-architecture-1-domain-driven-design-f06fad8695f9 مریم مرادیمریم مرادیFri, 10 Dec 2021 21:02:18 +0330https://virgool.ir/@maryam_76sh/event-sourcing-yvfzqcx969ebمواقعی وجود دارد که فقط نمی خواهیم ببینیم کجا هستیم، بلکه می خواهیم بدانیم چگونه به آنجا رسیده ایم! Event Sourcing تضمین می‌کند که همه تغییرات در وضعیت برنامه به‌ صورت دنباله‌ای از رویدادها ذخیره می‌شوند. نه تنها می‌توان این رویدادها را جستوجو کرد، بلکه می‌توان از گزارش رویداد برای بازسازی حالت‌های گذشته و به‌عنوان پایه‌ای برای تنظیم خودکار وضعیت برای مقابله با تغییرات آینده استفاده کرد.ایده اساسی Event Sourcing این است که اطمینان حاصل شود که هر تغییری در وضعیت یک برنامه کاربردی در یک شی رویداد ثبت می شود، و این اشیاء رویداد خودشان به ترتیبی که برای مدت عمر مشابه خود حالت برنامه اعمال شده اند ذخیره می شوند.به عنوان یک مثال ساده، اعلان های حمل و نقل در نظر گرفته می‌شود. در این مثال کشتی های زیادی در دریاهای آزاد وجود دارد م و باید مکان آن ها مشخص شود. یک راه ساده برای انجام این کار، داشتن یک برنامه کاربردی ردیابی با کمک روش‌هایی است که این امکان را می دهد تا زمان حرکت و یا رسیدن کشتی به بندر مشخص شود.در این حالت وقتی سرویس فراخوانی می شود، کشتی مربوطه را پیدا کرده و مکان آن را به روز می کند. شی از نوع کشتی وضعیت شناخته شده فعلی کشتی ها را ثبت می کنند.معرفی Event Sourcing یک مرحله به این فرآیند اضافه می کند. اکنون این سرویس یک شی رویداد ایجاد می‌کند تا تغییر را ثبت کند و آن را برای به روز رسانی کشتی پردازش می‌کند.تفاوت جالب زمانی است که به آنچه در برنامه پس از چند تغییر باقی می ماند نگاه کرد. چند تغییر ساده را فرض می‌شود:کشتی "کینگ روی" سانفرانسیسکو را ترک می کند.کشتی «پرنس ترور» وارد لس آنجلس می شود.کشتی "کینگ روی" وارد هنگ کنگ شد.با سرویس اولیه، فقط وضعیت نهایی مشخص می‌شود که توسط اشیاء کشتی گرفته شده است.به کمک Event Sourcing هر رویداد نیز ذخیره می‌شود. درواقع دو چیز متفاوت نگهداری می‌شود، یک وضعیت برنامه و یک گزارش رویداد است.مشخص ترین چیزی که با استفاده از Event Sourcing به دست می‌آید این است که اکنون گزارشی از تمام تغییرات موجود است. نه تنها می توان مکان هر کشتی را مشخص کرد، بلکه می توان فهمید کشتی کجا بوده است. با این حال این یک مزیت کوچک است. همچنین می‌توان این کار را با نگه‌داشتن تاریخچه پورت‌های گذشته در شی کشتی، یا با نوشتن در یک فایل گزارش هر زمان که کشتی حرکت می‌کند، انجام داد. هر دوی این ها می تواند تاریخچه کافی به ما بدهد.کلید Event Sourcing این است که تضمین می‌شود تمام تغییرات در اشیاء دامنه توسط اشیاء رویداد آغاز می شود. این منجر به تعدادی امکانات می شود که می توان در بالای گزارش رویداد ایجاد کرد:بازسازی کامل: می‌توان وضعیت برنامه را به طور کامل کنار گذاشت و با اجرای مجدد رویدادها از گزارش رویداد در یک برنامه خالی، آن را دوباره ساخت.پرس و جو زمانی: می‌توان وضعیت برنامه را در هر نقطه از زمان تعیین کرد. در واقع، این کار با شروع از یک حالت خالی و اجرای مجدد رویدادها تا یک زمان یا رویداد خاص انجام می شود. می‌توان با در نظر گرفتن خطوط زمانی متعدد (مشابه با انشعاب در یک سیستم کنترل نسخه) این کار را بیشتر انجام داد.پخش مجدد رویداد: اگر متوجه شود یک رویداد گذشته نادرست بوده است، می‌توان پیامدهای آن را با معکوس کردن آن و رویدادهای بعدی و سپس پخش مجدد رویداد جدید و رویدادهای بعدی محاسبه کرد. (یا در واقع با دور انداختن حالت برنامه و پخش مجدد همه رویدادها با رویداد صحیح به ترتیب.) همین تکنیک می‌تواند رویدادهایی را که به ترتیب اشتباه دریافت می‌شوند مدیریت کند - یک مشکل رایج در سیستم‌هایی که با پیام‌رسانی ناهمزمان ارتباط برقرار می‌کنند.نمونه رایج برنامه‌ای که از Event Sourcing استفاده می‌کند، سیستم کنترل نسخه است. چنین سیستمی اغلب از پرس و جوهای زمانی استفاده می کند. هر زمان که از Dump و Restore برای جابجایی میان فایل‌های مخزن استفاده می‌شود، Subversion از بازسازی های کامل استفاده می‌کند. برنامه های سازمانی که از Event Sourcing استفاده می کنند نادرتر هستند.ساده‌ترین راه برای استفاده از Event Sourcing این است که یک حالت برنامه درخواستی را با شروع از یک وضعیت برنامه خالی و سپس اعمال رویدادها برای رسیدن به حالت مطلوب محاسبه کرد. به همان اندازه ساده است که بفهمیم چرا این روند کند است، به خصوص اگر رویدادهای زیادی وجود داشته باشد. در بسیاری از برنامه‌ها، درخواست وضعیت‌های برنامه اخیر رایج‌تر است، اگر چنین است، یک جایگزین سریع‌تر، ذخیره وضعیت فعلی برنامه است و اگر شخصی ویژگی‌های ویژه‌ای را که Event Sourcing ارائه می‌دهد می‌خواهد، آن قابلیت اضافی در بالا ساخته می‌شود.حالت های برنامه را می توان در حافظه یا روی دیسک ذخیره کرد. از آنجایی که یک وضعیت برنامه صرفاً از گزارش رویداد قابل استخراج است، می‌توان آن را در هر جای دلخواهی ذخیره کرد. سیستمی که در طول یک روز کاری مورد استفاده قرار می‌گیرد، می تواند در ابتدای روز از یک حالت فوری شروع شود و وضعیت فعلی برنامه را در حافظه نگه دارد. اگر خراب شود، رویدادهای فروشگاه را دوباره پخش می کند. در پایان روز کاری می توان یک حالت فوری جدید تهیه کرد. حالت‌های فوری جدید را می توان در هر زمان به صورت موازی بدون پایین آوردن برنامه در حال اجرا ایجاد کرد.سیستم رسمی ثبت می تواند گزارش رویداد یا وضعیت فعلی برنامه باشد. اگر وضعیت فعلی برنامه در یک پایگاه داده نگهداری شود، گزارش رویدادها ممکن است فقط برای ممیزی و پردازش ویژه وجود داشته باشد. به صورت دوره‌ای، گزارش‌های رویداد می‌توانند رکورد رسمی باشند و هر زمان که نیاز باشد، می‌توان پایگاه‌های اطلاعاتی را از آنها ساخت.چندین گزینه در مورد اینکه محل قرار دادن منطق مدیریت رویدادها وجود دارد. انتخاب اولیه این است که منطق را در اسکریپت های تراکنش یا مدل دامنه قرار داد. طبق معمول، اسکریپت های تراکنش برای منطق ساده بهتر هستند و مدل دامنه زمانی بهتر است که همه چیز پیچیده تر شود.منطق دامنه پردازش، منطق تجاری است که برنامه را تغییر می‌دهد. منطق انتخاب پردازش، منطقی است که انتخاب می‌کند کدام بخش از منطق دامنه پردازشی باید بسته به رویداد ورودی اجرا شود. می‌توان این ها را با هم ترکیب کرد، اساساً این رویکرد اسکریپت تراکنش است، اما همچنین می‌توان با قرار دادن منطق انتخاب پردازش در سیستم پردازش رویداد، آن ها را از هم جدا کرد و متدی را در مدل دامنه فراخوانی می‌کند که شامل منطق دامنه پردازش است. وقتی این تصمیم گرفته شد، مرحله بعدی این است که آیا منطق انتخاب پردازش را در خود شی رویداد قرار داد یا یک شی پردازشگر رویداد جداگانه باشد.یکی از مواردی که داشتن یک پردازنده مجزا می‌تواند منطقی باشد، زمانی است که شی رویداد یک DTO است که با برخی ابزارهای خودکار که مانع از قرار دادن کد در رویداد می‌شود، سریال‌سازی و سریال‌زدایی می‌شود. در این مورد باید منطق انتخاب رویداد را پیدا کنید.اگر نیازی به معکوس کردن رویدادها وجود نداشته باشد، می‌توان یک مدل دامنه را از گزارش رویداد نادیده گرفت. معکوس کردن منطق این کار را دشوارتر می کند، زیرا مدل دامنه نیاز به ذخیره و بازیابی حالت قبلی دارد، که باعث می شود مدل دامنه از گزارش رویداد آگاه باشد.معکوس کردن رویدادهاهنگامی که رویداد به شکل یک تفاوت نمایش داده می شود، معکوس کردن ساده ترین راه است. یک مثال از این می‌تواند «افزودن 10 دلار به حساب مارتین» در مقابل «حساب مارتین روی 110 دلار» باشد. در حالت اول می توان فقط با کم کردن 10 دلار معکوس کرد، اما در مورد دوم اطلاعات کافی برای ایجاد مجدد ارزش گذشته حساب نیست.اگر رویدادهای ورودی از رویکرد ایجاد تفاوت پیروی نکنند، رویداد باید اطمینان حاصل کند که هر چیزی را که برای معکوس کردن در طول پردازش لازم است ذخیره می‌کند. می توان این کار را با ذخیره مقادیر قبلی روی هر مقداری که تغییر می کند یا با محاسبه و ذخیره تفاوت ها در رویداد انجام داد.شایان ذکر است که تمام قابلیت‌های معکوس کردن رویدادها را می‌توان با بازگشت به یک حالت فوری گذشته و پخش مجدد جریان رویداد انجام داد، ممکن است تفاوت زیادی در کارایی ایجاد نشود، زیرا ممکن است اغلب در موقعیتی باشید که معکوس کردن چند رویداد بسیار کارآمدتر از استفاده از حرکت رو به جلو در بسیاری از رویدادها باشد.به روز رسانی های خارجییکی از عناصر پیچیده در Event Sourcing، نحوه برخورد با سیستم های خارجی است که از این رویکرد پیروی نمی کنند (و اکثر آنها از این رویکرد پیروی نمی کنند). هنگام ارسال پیام‌های اصلاح‌کننده به سیستم‌های خارجی و زمانی که درخواست‌هایی از سیستم‌های دیگر دریافت می‌شود، مشکل ایجاد می‌شود.بسیاری از مزایای Event Sourcing از توانایی پخش مجدد رویدادها به دلخواه نشات می‌گیرد، اما اگر این رویدادها باعث شود پیام‌های به‌روزرسانی به سیستم‌های خارجی ارسال شود، همه چیز اشتباه می‌شود زیرا آن سیستم‌های خارجی تفاوت بین پردازش واقعی و پردازش واقعی را نمی‌دانند. تکرار می شود.برای انجام این کار، باید هر سیستم خارجی را با یک Gateway متصل کرد. این به خودی خود خیلی سخت نیست زیرا در هر صورت ایده کاملاً خوبی است. دروازه باید کمی پیچیده‌تر باشد تا بتواند با پردازش‌های تکراری که سیستم Event Sourcing انجام می‌دهد مقابله کند. برای بازسازی‌ها و درخواست‌های زمانی، معمولاً کافی است که دروازه‌ها در طول پردازش پخش مجدد غیرفعال شوند. اگر از رویداد Retroactive استفاده شود، به‌روزرسانی‌های خارجی پیچیده‌تر می‌شوند. تاکتیک دیگری که ممکن است در سیستم های خارجی مشاهده شود، بافر کردن اعلان های خارجی بر اساس زمان است.پرس و جوهای خارجیمشکل اصلی پرس‌و‌جوهای خارجی این است که داده‌هایی که آنها برمی‌گردانند روی نتایج مدیریت یک رویداد تأثیر می‌گذارند. برای مثال "اگر من برای 5 دسامبر نرخ ارز بخواهم و آن رویداد را در 20 دسامبر دوباره پخش کنم، به نرخ ارز در 5 دسامبر نیاز خواهم داشت نه نرخ بعدی."یکی از رویکردها، طراحی دروازه به سیستم خارجی است به طوری که پاسخ‌های پرسش‌های خود را به خاطر بسپارد و در حین پخش مجدد از آنها استفاده کند. برای کامل شدن این به این معنی است که پاسخ به هر پرس و جو خارجی باید به خاطر سپرده شود. اگر داده های خارجی به کندی تغییر کنند، ممکن است معقول باشد که تغییرات را فقط زمانی که مقادیر تغییر می‌کنند به خاطر سپرد.تعامل خارجیهم پرس و جوها و هم به روز رسانی سیستم های خارجی باعث پیچیدگی های زیادی با Event Sourcing می شود. چنین تعاملی ممکن است یک تماس خارجی باشد که هم نتیجه ای را برمی گرداند (یک پرس و جو) اما همچنین باعث تغییر حالت در سیستم خارجی می شود، مانند ارسال یک سفارش برای تحویل که اطلاعات تحویل آن سفارش را برمی‌گرداند.تغییرات کدمی‌توان سه نوع تغییر کد در نظر گرفت: ویژگی‌های جدید، رفع نقص و منطق زمانی.ویژگی‌های جدید اساساً قابلیت‌های جدیدی را به سیستم اضافه می‌کنند، اما چیزهایی را که قبلاً اتفاق افتاده است باطل نمی‌کنند. اینها را می توان در هر زمان کاملاً آزادانه اضافه کرد.رفع اشکال زمانی رخ می دهد که به پردازش گذشته نگاه می‌شود و متوجه اشتباه شد. تنها کاری که باید انجام شود این است که اصلاح شود و رویدادها دوباره پردازش شود.مورد سوم جایی است که خود منطق در طول زمان تغییر می‌کند، برای مثال «هزینه 10 دلاری قبل از 18 نوامبر و 15 دلاری پس از آن». این نوع چیزها باید در واقع وارد مدل دامنه شوند. مدل دامنه باید بتواند رویدادها را در هر زمان با قوانین صحیح برای پردازش رویداد اجرا کند. می‌توان این کار را با منطق شرطی انجام داد، اما اگر منطق زمانی زیادی باشد، این کار مناسب نیست. مسیر بهتر این است که اشیاء استراتژی را به یک ویژگی زمانی متصل کنند. برای مثال "این رویداد را طبق قوانین 1 آگوست که در 1 اکتبر داشتیم معکوس کنید و آن را طبق قوانین 1 آگوست که اکنون داریم جایگزین کنید".از جمله ابزارها می‌توان Axon, Kafkaرا نام برد.این تکنیک مناسب برای زمان خرابی است اگر منبع پایین دستی خراب شود، داده های آن را می توان از منابع رویداد ذخیره شده، بازسازی کرد. این تکنیک همچنین بسیار انعطاف پذیر است و هر نوع پیامی را می توان ذخیره کرد. همچنین بسیار مناسب برای گزارش دهی بلادرنگ است.اما این تکنیک نیاز به یک زیرساخت شبکه بسیار کارآمد دارد. همچنین به روشی قابل اعتماد برای کنترل قالب های پیام نیاز است. رویدادهای مختلف، حاوی بارهای متفاوتی خواهند بود. برای تعریف و تعیین قالب های پیام برای یک رویداد خاص، باید یک منبع واحد وجود داشته باشد.این تکنیک برای شرکت هایی مانند دیجیکالا و ترب مناسب است. https://martinfowler.com/eaaDev/EventSourcing.html مریم مرادیمریم مرادیFri, 10 Dec 2021 18:09:59 +0330https://virgool.ir/@maryam_76sh/روش-مستندسازی-c4-در-معماری-نرم-افزار-qxmeibxbxjmiیک نکته مهم در توسعه‌ی سیستم‌های نرم افزاری، مستندسازی معماری نرم افزار است. در ادامه یکی از مدل‌های مستندسازی معماری نرم‌افزار به نام c4 بررسی می‌شود. این مدل براساس نمودار UML و نمای معماری 4+1 در سال 2006–2011 توسط آقای سایمون براون ساخته شده است. او مشاور متخصص در معماری نرم‌افزار و نویسنده کتاب معماری نرم‌افزار برای توسعه‌دهندگان، راهنمای توسعه‌دهنده برای معماری نرم‌افزار، رهبری فنی و تعادل چابکی، است. همچنین مجموعه ای از ابزارهای منبع باز و تجاری برای کمک به تیم‌های نرم افزاری در تجسم، مستندسازی و کاوش معماری نرم افزار را ایجاد کرده است. مدل C4 یک رویکرد انتزاعی برای بصری‌سازی معماری نرم افزار است که نحوه تفکر معماران و توسعه دهندگان در مورد نرم افزار و چگونگی ساخت آن را نشان می‌دهد. این روش با کمک تقسیم نرم‌افزار به قسمت‌های کوچک‌تر مدلسازی می‌کند. نماها در سطوح سلسه مراتبی زمینه، نگهدارنده، مولفه و کد متمایز می‌شوند. این مدل زمانی توصیه می‌شود که اشتراک سریع و کارا و بروزرسانی پیوسته معماری نرم‌افزار نیاز است و مناسب نمای استاتیک معماری نرم‌افزار است. مدل C4 معماری بصری اشتراکی و معماری تکاملی در چارچوب تیم‌های چابک را تسهیل می‌بخشد. در ادامه مطلب ابتدا مدل C4 با جزئیات بررسی می‌شود و سپس یک ابزار جهت رسم این نمودارها معرفی می‌شود.مدل c4مدل C4:در صنعت نمودارسازی نسبت به مدل‌سازی ترجیح دارد. زیرا موانع ورودی نسبتاً کم است و ساده‌تر به نظر می‌آید. در زمان ترسیم نمودار، معمولاً به کمک ابزارهایی (مثلاً Microsoft Visio یا تخته سفید) یک یا چند نمودار جداگانه ایجاد می‌شود. زبان ابزارهای نمودارسازی در واقع فقط اشکال و خطوط هستند، بنابراین نمی توانند پاسخگوی سوالاتی مانند "مولفه X چه وابستگی هایی دارد؟" باشند. در این جاست که مدل C4 صرف نظر از نمودارسازی یا مدل‌سازی قابل استفاده است.در این قسمت به معرفی مدل C4 پرداخته می‌شود. یک سیستم نرم افزاری از یک یا چند نگهدارنده (به عنوان مثال برنامه‌های کاربردی وب، برنامه‌های موبایل، برنامه‌های کاربردی دسکتاپ، پایگاه‌های داده و سیستم فایل) تشکیل شده است. هریک شامل یک یا چند مولفه است که توسط یک یا چند عنصر کد (به عنوان مثال کلاس‌ها، رابط‌ها، اشیاء و توابع) پیاده‌سازی می‌شود و مردم از سیستم نرم‌افزاری ساخته شده استفاده می‌کنند. سطوح نما به صورت زیر سازماندهی می‌شود:سطح اول، زمینه (Context): حیطه و روابط میان کاربران و دیگر سیستم‌ها را نشان می‌دهد. جزئیات در این نمودار مهم نیست و تمرکز بر روی افراد و سیستم‌های نرم افزاری است و به فناوری‌ها و جزئیات سطح پایین توجه نمی‌شود. این نمودار قابل نشان دادن به افراد غیرفنی است و به اکثر تیم‌ها توصیه می‌شود. در شکل زیر نمونه‌ای از نمودار زمینه آورده شده است.نمودار زمینه سیستمسطح دوم، نگهدارنده (Container): در این سطح سیستم به نگهدارنده‌های مرتبط تجزیه می‌شود و نمای سطح بالای معماری نرم افزار و نحوه توزیع مسئولیت‌ها نشان داده می‌شود. درواقع یک واحد قابل اجرا یا قابل استقرار جداگانه است که کد را اجرا می‌کند و یا داده ها را ذخیره می‌کند. این نمودار برای توسعه دهندگان نرم افزار و پشتیبانان عملیاتی مفید است. رسم این نمودار برای اکثر تیم‌ها توصیه می‌شود اما برای سیستم‌های بسیار بزرگ خیلی ارشمند نیست. در شکل زیر نمونه‌ای از نمودار نگهدارنده آورده شده است.نمودار نگهدارنده سیستمسطح سوم، نمودار مولفه (Component): در این سطح، نگهدارنده‌ها به نگهدارندها‌ی مرتبط تجزیه می‌شود و مولفه‌ها به سیستم های دیگر یا نگهدارنده‌های دیگر مرتبط می‌شود. اجزای هر مولفه، مسئولیت آن و جزئیات فناوری نشان داده می‌شود. رسم این نمودار برای تمام تیم‌ها توصیه نمی‌شود و فقط در مواردی خاص نیاز به رسم دارد. در شکل زیر نمونه‌ای از نمودار مولفه آورده شده است.نمودار مولفه سیستمسطح چهارم، نمودار کد (Code): در این سطح جزئیات طراحی معماری که به کد نگاشت می‌شود، نمایش داده می‌شود. این سطح از جزئیات فقط برای مهم‌ترین یا پیچیده‌ترین اجزا توصیه می‌شود و نیازی به رسم آن در تمام تیم‌ها وجود ندارد. در شکل زیر نمونه‌ای از نمودار کد آورده شده است.نمودار کد سیستماز نمودارهای مدل c4 می‌توان برای نمایش برخی دیگر از جنبه‌های نرم‌افزار استفاده کرد. به عنوان مثال، نمودار چشم‌انداز سیستم در حیطه سازمانی، یک نمودار زمینه بدون تمرکز بر یک سیستم نرم‌افزاری خاص است. نمونه دیگر، نمودار پویا برای نشان دادن چگونگی همکاری عناصر در یک مدل استاتیک در زمان اجرا، برای پیاده‌سازی توصیف ویژگی سیستم برای کاربر، نمونه و ویژگی است. همچنین به عنوان مثالی دیگر، نمودار استقرار جهت نمایش نحوه نگاشت سیستم نرم افزاری و یا نگهدارنده به زیرساخت مناسب مورد استفاده قرار می‌گیرد.نکاتی رسم نمودارها:هر نمودار باید عنوانی داشته باشد که نوع و محدوده نمودار را توصیف کند و دارای یک کلید باشد که نماد مورد استفاده را توضیح دهد.کلمات اختصاری و اختصارات آورده شده باید برای همه مخاطبان قابل درک باشد.نوع هر عنصر مشخص باشد(به عنوان مثال شخص، سیستم). هر عنصر شامل توصیف کوتاهی باشد که مسئولیت های کلیدی آن را نمایان می‌کند. در هر نگهدارنده و مولفه تکنولوژی مربوطه مشخص باشد.هر پیکان ارتباطی نشان دهنده یک رابطه یک طرفه است و باید برچسب گذاری شود. در روابط بین نگهدارنده‌ها که معمولاً ارتباطات بین فرآیندهاست، تکنولوژی یا پروتکل مربوطه به کمک برچسب گذاری مشخص شود.ابزار:ابزارهایی جهت رسم این نمودار موجود است. در این قسمت یک نمونه از ابزارهای رسم نمودارهای مدل c4 معرفی می‌شود. به کمک Gliffy می‌توان نمودارهای مربوطه را رسم کرد. مراحل رسم به شرح زیر است:1. اشکال گوناگون برای نمودار زمینه شامل نام، توضیحی مختصر از نقش آن، تکنولوژی و فلش‌هایی جهت نشان دادن تعاملات رسم می‌شود.2. کلید برای واضح شدن نمودار ایجاد می‌شود. برای مثال استفاده از رنگ‌های یکسان برای سیستم‌های در تعامل می‌تواند به درک بهتر نمودارها کمک کند.3. ارتباطات میان مولفه‌ها به کمک پیکان‌ها رسم مشخص می‌شود.4. لایه جدید برای نمودار بعدی در مدل ایجاد می‌شود.5. مراحل 1-4 برای رسم نمودار نگهدارنده تکرار می‌شود.6. مراحل 1-4 برای رسم نمودار مولفه تکرار می‌شود.7. مراحل 1-4 برای رسم نمودار کد تکرار می‌شود.8. پیوند لایه‌ها برای دسترسی به هر یک لایه‌ها ایجاد شود.10. نمودار آماده است و ذخیره می‌شود.مثال نمودار رسم شده در ابزاراین مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است.منابع: https://en.wikipedia.org/wiki/C4_model https://www.gliffy.com/blog/c4-model https://c4model.com/ https://engineering.linecorp.com/en/blog/diagramming-software-architecture-using-c4-model-and-c4-plantuml/#DiagrammingsoftwarearchitectureusingC4modelandC4PlantUML_ko-C4%EB%AA%A8%EB%8D%B8 مریم مرادیمریم مرادیSun, 14 Nov 2021 12:57:29 +0330