معماری رویدادمحور

معماری رویداد محور (انگلیسی: Event-driven architecture) یک الگوی معماری نرم‌افزار است در آن به تولید، شناسایی و واکنش به رویداد اهمیت داده می‌شود. این معماری سازمان را قادر می‌سازد تا "رویدادها" یا لحظات مهم تجاری (مانند تراکنش، بازدید از سایت، رها کردن سبد خرید و …) را شناسایی کند و بر اساس آن‌ها در زمان واقعی یا نزدیک به زمان واقعی عمل کند. این الگو جایگزین معماری سنتی "درخواست/پاسخ" می‌شود که در آن سرویس‌ها باید قبل از اینکه بتوانند به کار بعدی بروند منتظر پاسخ باشند. جریان معماری رویداد محور توسط رویدادها اجرا می شود و برای پاسخ به آنها یا انجام برخی اقدامات در پاسخ به یک رویداد طراحی شده است.

ساختاری معماری رویداد‌محور

اجزای یک معماری رویداد محور می تواند شامل سه بخش باشد: تولید کننده، مصرف کننده، broker. Broker می تواند اختیاری باشد، به خصوص زمانی که شما یک تولید کننده و یک مصرف کننده دارید که مستقیماً با یکدیگر در ارتباط هستند و تولید کننده فقط رویدادها را برای مصرف کننده ارسال می کند. یک مثال می تواند تولید کننده ای باشد که فقط به یک پایگاه داده یا انبار، داده ارسال می کند تا رویدادها برای تجزیه و تحلیل جمع آوری و ذخیره شوند. معمولاً در شرکت‌ها، شما منابع متعددی دارید که انواع رویدادها را با یک یا چند مشتری علاقه‌مند به برخی یا همه آن رویدادها ارسال می‌کنند.

موارد استفاده از معماری رویداد محور

سازمان ها هنگام طراحی سیستم های خود برای دستیابی به اهداف مختلف از معماری رویداد محور استفاده می کنند. موارد زیر رایج ترین هستند:

تکرار داده ها: یک رویداد را می توان بین چندین سرویس به اشتراک گذاشت که باید داده های آن را در پایگاه داده خود کپی کنند.

پردازش موازی: فرآیندهای متعددی می توانند توسط یک رویداد راه اندازی شوند تا به صورت غیر‌همزمان با یکدیگر اجرا شوند.

نظارت در زمان واقعی: سیستم ها می توانند رویدادهایی را برای تغییرات در وضعیت خود ایجاد کنند تا سازمان بتواند ناهنجاری ها و فعالیت های مشکوک را اسکن کند.

قابلیت همکاری: رویدادها را می توان بدون در نظر گرفتن سرویس های کدی که در آن نوشته شده است ادامه و منتشر کرد.

افزونگی: اگر سرویسی از کار بیفتد، رویدادها می‌توانند در روتر ادامه داشته باشند تا زمانی که سرویس برای مصرف رویداد در دسترس باشد.

میکروسرویس ها: معماری رویداد محور معمولاً با میکروسرویس ها جفت می شود تا به طور مؤثر اطلاعات را بین سیستم های جدا شده در مقیاس به اشتراک بگذارد.

الگو‌های معماری رویداد محور

بنا به دلایلی همچون scalability، flexibility و coupling کم، ممکن است یک تیم توسعه‌ی نرم‌افزار تصمیم بگیرد سیستم خود را به نحوی طراحی و پیاده‌سازی کند که بین اجزای خود از ارتباط و پردازش رویداد محور استفاده کند. به همین منظور تیم توسعه‌ی مذکور باید به استفاده از الگو‌های معماری رویداد محور روی بیاورد. در این قسمت برخی از این الگو‌ها را نام برده و به اختصار توضیح می‌دهیم.

• Event Sourcing: با استفاده از این الگو، حالت و state کنونی اپلیکیشن را می‌توان از ثبت و بازپخش رویداد‌ها به دست‌ آورد. در واقع state کنونی اپلیکیشن از record کردن رویداد‌ها نشات می‌گیرد. به جای اینکه در هر نقطه از زمان state کنونی اپلیکیشن را ذخیره کنیم، هر تغییر در state را یک رویداد می‌انگاریم و آن را در گزارشی از رویداد‌ها ذخیره می‌کنیم. این رویکرد طراحی معماری باعث می‌شود تا قابلیت حسابرسی ردپای تغییرات سیستم را به راحتی داشته باشیم و در هر زمانی که بخواهیم state کنونی اپلیکیشن را بازسازی کنیم.
• Command Query Responsibility Segregation: با استفاده از این الگوی معماری، وظایف read و write در سیستم را به مدل‌های جدایی می‌سپاریم به گونه‌ای که با مدل command، عملیات و دستورات write را اجرا می‌کنیم که هریک state کنونی سیستم را تغییر می‌دهند. در حالی که با پیاده سازی مدل query و استفاده از آن، دستورات read را در سیستم اجرا می‌کنیم و داده‌ها را بازیابی می‌کنیم. از آن‌جایی که با این کار می‌توانیم دستورات read و write را به صورت مجزا بهینه سازی و optimize کنیم، در نهایت scalability سیستم را بالا می‌بریم.
• Publish-Subscribe Pattern: نام دیگر این الگو ، observer pattern است. در این الگو دو نوع component سیستم به نام‌های publisher و subscriber داریم. Subscriber ها نیازمند انواع خاصی از رویداد‌ها از طرف publisher ها هستند و publisher ها بدون اینکه به صورت مستقیم در رابطه با کلیت subscriber ها چیزی بدانند، برای آن‌ها رویداد ارسال می‌کنند. با استفاده از این الگو flexibility سیستم را افزایش داده و در نهایت coupling را کاهش می‌دهیم.
• Message Queue: با استفاده از این الگوی معماری برای فراهم سازی زیرساخت ارتباط بین component ها و اجزای مختلف سیستم، یک broker و واسط پیام‌ها تعبیه و پیاده سازی می‌کنیم. با پیاده سازی یک broker پیام، قابلیت ارسال پیام به صورت asynchronous را برای component ها فراهم می‌کنیم و در نهایت می‌توانیم از صحت پیام ارسالی اطمینان خوبی حاصل کرده و fault tolerance خوبی خواهیم داشت. این واسط پیام یک صف از پیام‌ها دارند و component هایی که وظیفه‌ی publish کردن را دارند، پیام خود را در این صف ارسال می‌کنند و در عین حال بقیه‌ی component ها می‌توانند از روی این صف، پیام‌ها را به هنگام آماده شدن دریافت کنند.
• Choreography and Orchestration: این الگو‌های معماری، علاوه بر اینکه چگونگی همکاری اجزای مختلف یک سیستم رویداد محور را  تعیین می‌کنند، همچنین وظیفه‌ی هماهنگی عملکرد اجزا و component های مذکور را نیز بر عهده دارند. در Choreography، هرکدام از component ها به صورت مستقلی به رویدادها واکنش نشان می‌دهند و رفتار و state کلی سیستم از ترکیب این فعل و انفعالات component ها شکل می‌گیرد. در Orchestration یک component مرکزی پیاده سازی شده که وظیفه هماهنگی اقدامات و action های سایر component ها را برعهده دارد و به آن‌ها جهت می‌دهد.
• Event-Driven Messaging: با استفاده از این نوع الگو‌ها، یک سری پیام‌ها به صورت رویداد‌هایی بین component های سیستم، به منظور شروع یک سری اقدامات و action ها و القای یک سری اطلاعات، رد و بدل می‌شوند. مثال‌هایی از این نوع الگو‌ها : request-reply , event notification , message routing , …

همانگونه که بیان شد، می‌توانیم پس از بررسی‌های لازم با استفاده از این الگو‌های معماری رویداد محور برای طراحی سیستم‌های بزرگ و پیچیده، flexibility و scalability را افزایش دهیم. این الگو‌های رویداد محور باعث می‌شوند سیستم توانایی پردازش حجم عظیمی از رویداد‌ها را داشته باشد و به تغییرات component های خود واکنش درستی نشان دهد. همچنین فرایند یکپارچه‌سازی سیستم مورد نظر را با سایر سیستم‌ها آسانتر میکنند. در کل با استفاده از این الگو‌ها می‌توان سیستم‌هایی بهینه طبق استاندارد‌های روز توسعه‌ی نرم‌افزار طراحی و پیاده سازی کرد.

معماری رویداد محور و میکروسرویس‌ها

امروزه شرکت‌های زیادی به سمت آن رفته‌اند که از معماری‌های براساس میکروسرویس را برای افزایش سرعت و بهره‌وری استفاده کنند. از جمله‌ معماری‌هایی که برای ارتباط سرویس‌های مختلف در میکروسرویس‌ها استفاده می‌شود معماری رویداد محور است.

میکروسرویس‌های بر پایه معماری رویداد محور حاوی سه جزء اصلی هستند:

• تولید کنندگان رویداد (event producers)، که هنگام رخداد رویداد آن را شناسایی و به روتر‌ها ارسال می‌کنند.
• روتر‌های رویداد (event routers)، که رویداد را بررسی و مقصد آنها تعیین می‌کنند.
• مصرف کنندگان رویداد (event consumers)، که رویدادها را پردازش و عملیات مرتبط با آنها را انجام می‌دهند.

یکی از نمونه کاربردهای اصلی معماری رویداد محور در میکروسرویس‌ها زمانی است که از الگوی "پایگاه داده به ازای سرویس" (database per service) استفاده شده‌ است، بدین معنا که هر سرویس داده مربوط به خود را نگاه می‌دارد. هنگامی که یک در تراکنش چندین سرویس گسترده باشد، به مکانیزمی نیاز داریم که ثبات داده را در این سرویس‌ها تضمین کند.

مزایای معماری رویداد محور

معماری رویداد محور مزایای بسیاری را برای سازمان هایی ارائه می دهد که به دنبال بهبود پاسخگویی و انعطاف پذیری پشته فناوری خود هستند.

جداسازی: سرویس‌ها دیگر نیازی به دانستن وجود سرویس‌های دیگر، برای همکاری با یکدیگر ندارند. آنها فقط باید درباره رویدادها بدانند و کارگزار، رویدادهای مناسب را به سیستم های مناسب واگذار می کند. جداسازی، معماری رویداد محور را به یک راه مناسب برای اتصال میکروسرویس ها تبدیل می کند.

تغییرناپذیری: رویدادها را نمی‌توان پس از ایجاد تغییر داد، بنابراین می‌توان آن‌ها را با چندین سرویس به اشتراک گذاشت، بدون اینکه خطر تغییر یا حذف اطلاعاتی که سایر سرویس‌ها سپس مصرف می‌کنند، توسط یک سرویس به اشتراک گذاشته شود.

مقیاس پذیری: می توان از یک رویداد برای راه اندازی چندین عمل در مصرف کنندگان مختلف استفاده کرد که اجرای موازی کار را ممکن می کند و عملکرد را بهبود می بخشد. جداسازی همچنین فرآیندی، به‌روزرسانی یا حذف تولیدکنندگان و مصرف‌کنندگان رویداد را ساده می‌کند، زیرا نیازی به به‌روزرسانی منطق در هر سرویس یا سیستم ندارید و به شما امکان می‌دهد تا به سرعت مجموعه ابزار خود را برای برآورده کردن نیازها یا تقاضاهای جدید تنظیم کنید.

گردش کار در زمان واقعی: معماری رویداد محور با رخ دادن رویدادها اجرا می‌شود و از پاسخ‌های بی‌درنگ یا تقریباً هم‌زمان به تعاملات حیاتی مانند خرید و پیام‌های چت زنده پشتیبانی می‌کند. این چابکی تضمین می کند که مشتریان همیشه به محض نیاز، پشتیبانی و اطلاعات را دریافت می کنند.

چالش های معماری رویداد محور

اگرچه معماری رویداد محور مزایای بسیاری را ارائه می دهد، برخی از این دستاوردها با معاوضه هایی همراه هستند، از جمله موارد زیر:

کارایی: گاهی ممکن است که مصرف‌کنندگان زمان بیشتری را برای اجرای کنش‌ها صرف کند زیرا رویداد را به سرعت دریافت نمی‌کنند.

همچنین بین حرکت رویدادها با تمام داده‌های موجود یا ارسال اعلان‌های باریک‌تر معاوضه‌هایی وجود دارد که از مصرف‌کنندگان می‌خواهد برای داده‌های اضافی پرس و جو کنند. از یک طرف، انتقال رویداد بیشتر طول می کشد و ممکن است هر مصرف کننده ای به مجموعه داده کامل نیاز نداشته باشد. از سوی دیگر، باید منطق اضافی تعریف کنید تا اطمینان حاصل شود که مصرف کننده هرگونه داده از دست رفته را تهیه می کند.

سازگاری نهایی: دو سرویس ممکن است بر اساس مدت زمانی که برای اجرای وظایفشان و سایر عوامل طول می کشد، در زمان های مختلف یک رویداد را پردازش کرده و به آن واکنش نشان دهند. این بدان معنی است که همه واکنش‌ها به یک رویداد به طور همزمان رخ نمی‌دهند، اما در نهایت همه سرویس‌ها پردازش رویداد را به پایان خواهند رساند.

جستارهای وابسته

• برنامه‌نویسی رویدادمحور
• معماری سرویس‌گرا

منابع

• مشارکت‌کنندگان ویکی‌پدیا. «Event-driven architecture». در دانشنامهٔ ویکی‌پدیای انگلیسی، بازبینی‌شده در ۴ دسامبر ۲۰۱۷.