موضوع مقاله: معماری رویدادمحور | مخاطب: عمومی | لحن: دانشنامه‌ای | ساختار: عنوان، مقدمه، 3 بخش، جمع‌بندی | مقاله: | # معماری رویدادمحور | مقدمه: معماری رویداد محور یک الگوی معماری نرم‌افزار است در آن به تولید، شناسایی و واکنش به رویداد اهمیت داده می‌شود. | ## بخش 1: معماری رویدادمحور | این معماری سازمان را قادر می‌سازد تا "رویدادها" یا لحظات مهم تجاری (مانند تراکنش، بازدید از سایت، رها کردن سبد خرید و …) را شناسایی کند و بر اساس آن‌ها در زمان واقعی یا نزدیک به زمان واقعی عمل کند. این الگو جایگزین معماری سنتی "درخواست/پاسخ" می‌شود که در آن سرویس‌ها باید قبل از اینکه بتوانند به کار بعدی بروند منتظر پاسخ باشند. جریان معماری رویداد محور توسط رویدادها اجرا می شود و برای پاسخ به آنها یا انجام برخی اقدامات در پاسخ به یک رویداد طراحی شده است. ساختاری معماری رویداد‌محور اجزای یک معماری رویداد محور می تواند شامل سه بخش باشد: تولید کننده، مصرف کننده، broker. Broker می تواند اختیاری باشد، به خصوص زمانی که شما یک تولید کننده و یک مصرف کننده دارید که مستقیماً با یکدیگر در ارتباط هستند و تولید کننده فقط رویدادها را برای مصرف کننده ارسال می کند. یک مثال می تواند تولید کننده ای باشد که فقط به یک پایگاه داده یا انبار، داده ارسال می کند تا رویدادها برای تجزیه و تحلیل جمع آوری و ذخیره شوند. موارد استفاده از معماری رویداد محور سازمان ها هنگام طراحی سیستم های خود برای دستیابی به اهداف مختلف از معماری رویداد محور استفاده می کنند. موارد زیر رایج ترین هستند: تکرار داده ها: یک رویداد را می توان بین چندین سرویس به اشتراک گذاشت که باید داده های آن را در پایگاه داده خود کپی کنند. پردازش موازی: فرآیندهای متعددی می توانند توسط یک رویداد راه اندازی شوند تا به صورت غیر‌همزمان با یکدیگر اجرا شوند. نظارت در زمان واقعی: سیستم ها می توانند رویدادهایی را برای تغییرات در وضعیت خود ایجاد کنند تا سازمان بتواند ناهنجاری ها و فعالیت های مشکوک را اسکن کند. قابلیت همکاری: رویدادها را می توان بدون در نظر گرفتن سرویس های کدی که در آن نوشته شده است ادامه و منتشر کرد. افزونگی: اگر سرویسی از کار بیفتد، رویدادها می‌توانند در روتر ادامه داشته باشند تا زمانی که سرویس برای مصرف رویداد در دسترس باشد. | ## بخش 2: معماری رویدادمحور | میکروسرویس ها: معماری رویداد محور معمولاً با میکروسرویس ها جفت می شود تا به طور مؤثر اطلاعات را بین سیستم های جدا شده در مقیاس به اشتراک بگذارد. به همین منظور تیم توسعه‌ی مذکور باید به استفاده از الگو‌های معماری رویداد محور روی بیاورد. به جای اینکه در هر نقطه از زمان state کنونی اپلیکیشن را ذخیره کنیم، هر تغییر در state را یک رویداد می‌انگاریم و آن را در گزارشی از رویداد‌ها ذخیره می‌کنیم. این رویکرد طراحی معماری باعث می‌شود تا قابلیت حسابرسی ردپای تغییرات سیستم را به راحتی داشته باشیم و در هر زمانی که بخواهیم state کنونی اپلیکیشن را بازسازی کنیم. در حالی که با پیاده سازی مدل query و استفاده از آن، دستورات read را در سیستم اجرا می‌کنیم و داده‌ها را بازیابی می‌کنیم. این الگو‌های رویداد محور باعث می‌شوند سیستم توانایی پردازش حجم عظیمی از رویداد‌ها را داشته باشد و به تغییرات component های خود واکنش درستی نشان دهد. در کل با استفاده از این الگو‌ها می‌توان سیستم‌هایی بهینه طبق استاندارد‌های روز توسعه‌ی نرم‌افزار طراحی و پیاده سازی کرد. معماری رویداد محور و میکروسرویس‌ها امروزه شرکت‌های زیادی به سمت آن رفته‌اند که از معماری‌های براساس میکروسرویس را برای افزایش سرعت و بهره‌وری استفاده کنند. از جمله‌ معماری‌هایی که برای ارتباط سرویس‌های مختلف در میکروسرویس‌ها استفاده می‌شود معماری رویداد محور است. هنگامی که یک در تراکنش چندین سرویس گسترده باشد، به مکانیزمی نیاز داریم که ثبات داده را در این سرویس‌ها تضمین کند. مزایای معماری رویداد محور معماری رویداد محور مزایای بسیاری را برای سازمان هایی ارائه می دهد که به دنبال بهبود پاسخگویی و انعطاف پذیری پشته فناوری خود هستند. جداسازی: سرویس‌ها دیگر نیازی به دانستن وجود سرویس‌های دیگر، برای همکاری با یکدیگر ندارند. | ## بخش 3: معماری رویدادمحور | آنها فقط باید درباره رویدادها بدانند و کارگزار، رویدادهای مناسب را به سیستم های مناسب واگذار می کند. جداسازی، معماری رویداد محور را به یک راه مناسب برای اتصال میکروسرویس ها تبدیل می کند. تغییرناپذیری: رویدادها را نمی‌توان پس از ایجاد تغییر داد، بنابراین می‌توان آن‌ها را با چندین سرویس به اشتراک گذاشت، بدون اینکه خطر تغییر یا حذف اطلاعاتی که سایر سرویس‌ها سپس مصرف می‌کنند، توسط یک سرویس به اشتراک گذاشته شود. مقیاس پذیری: می توان از یک رویداد برای راه اندازی چندین عمل در مصرف کنندگان مختلف استفاده کرد که اجرای موازی کار را ممکن می کند و عملکرد را بهبود می بخشد. جداسازی همچنین فرآیندی، به‌روزرسانی یا حذف تولیدکنندگان و مصرف‌کنندگان رویداد را ساده می‌کند، زیرا نیازی به به‌روزرسانی منطق در هر سرویس یا سیستم ندارید و به شما امکان می‌دهد تا به سرعت مجموعه ابزار خود را برای برآورده کردن نیازها یا تقاضاهای جدید تنظیم کنید. گردش کار در زمان واقعی: معماری رویداد محور با رخ دادن رویدادها اجرا می‌شود و از پاسخ‌های بی‌درنگ یا تقریباً هم‌زمان به تعاملات حیاتی مانند خرید و پیام‌های چت زنده پشتیبانی می‌کند. این چابکی تضمین می کند که مشتریان همیشه به محض نیاز، پشتیبانی و اطلاعات را دریافت می کنند. چالش های معماری رویداد محور اگرچه معماری رویداد محور مزایای بسیاری را ارائه می دهد، برخی از این دستاوردها با معاوضه هایی همراه هستند، از جمله موارد زیر: کارایی: گاهی ممکن است که مصرف‌کنندگان زمان بیشتری را برای اجرای کنش‌ها صرف کند زیرا رویداد را به سرعت دریافت نمی‌کنند. همچنین بین حرکت رویدادها با تمام داده‌های موجود یا ارسال اعلان‌های باریک‌تر معاوضه‌هایی وجود دارد که از مصرف‌کنندگان می‌خواهد برای داده‌های اضافی پرس و جو کنند. از یک طرف، انتقال رویداد بیشتر طول می کشد و ممکن است هر مصرف کننده ای به مجموعه داده کامل نیاز نداشته باشد. از سوی دیگر، باید منطق اضافی تعریف کنید تا اطمینان حاصل شود که مصرف کننده هرگونه داده از دست رفته را تهیه می کند. سازگاری نهایی: دو سرویس ممکن است بر اساس مدت زمانی که برای اجرای وظایفشان و سایر عوامل طول می کشد، در زمان های مختلف یک رویداد را پردازش کرده و به آن واکنش نشان دهند. | ## جمع‌بندی | این بدان معنی است که همه واکنش‌ها به یک رویداد به طور همزمان رخ نمی‌دهند، اما در نهایت همه سرویس‌ها پردازش رویداد را به پایان خواهند رساند.