معماری رویداد محور (EDA) چیست؟
معماری رویداد محور (EDA) یک الگوی معماری مدرن است که از سرویس‌های کوچک و جدا از هم ساخته شده که رویدادها را منتشر، مصرف یا مسیریابی می‌کنند.
یک رویداد نشان‌دهنده تغییر در وضعیت یا یک به‌روزرسانی است. به عنوان مثال: کالایی که در سبد خرید قرار می‌گیرد، فایلی که در یک سیستم ذخیره‌سازی آپلود می‌شود، یا سفارشی که آماده ارسال می‌شود. رویدادها می‌توانند هم وضعیت را (مانند نام کالا، قیمت یا مقدار در یک سفارش) حمل کنند و هم صرفاً شامل شناسهها (به عنوان مثال، “سفارش شماره ۸۹۴۲ ارسال شد”) مورد نیاز برای جستجوی اطلاعات مرتبط باشند.
برخلاف مدل‌های سنتی مبتنی بر درخواست، EDA، اتصال سست بین سرویس‌های تولیدکننده و مصرف‌کننده را ترویج می‌کند. این امر باعث می‌شود که مقیاس‌پذیری، به‌روزرسانی و استقرار مستقل اجزای جداگانه یک سیستم آسان‌تر باشد.
چرا معماری جدا از هم مهم است؟
بسیاری از سازمان‌ها دریافته‌اند که برنامه‌های کاربردی، پایگاه‌های داده و فناوری‌های یکپارچه، تأثیر منفی بر نوآوری و بهبود تجربه کاربر دارند. برنامه‌های کاربردی و پایگاه‌های داده قدیمی، گزینه‌های شما را برای پذیرش چارچوب‌های فناوری مدرن کاهش می‌دهند و رقابت‌پذیری و نوآوری شما را محدود می‌کنند. با این حال، هنگامی که برنامه‌های کاربردی و فروشگاه‌های داده آنها را مدرن می‌کنید، مقیاس‌پذیری آنها آسان‌تر و توسعه آنها سریع‌تر می‌شود.
یک استراتژی داده جدا از هم، تحمل خطا و انعطاف‌پذیری را بهبود می‌بخشد، که به تسریع زمان ورود به بازار (TTM) برای ویژگی‌های جدید برنامه شما کمک می‌کند.
برای اطلاعات بیشتر در مورد مزایای مدرن‌سازی برنامه‌های کاربردی یکپارچه، به «فعال کردن ماندگاری داده‌ها در میکروسرویس‌ها» در راهنمای تجویزی AWS مراجعه کنید.
مزایای معماری رویداد محور (EDA) چیست؟
معماری رویداد محور (EDA)، اتصال سست بین اجزای یک سیستم را ترویج می‌کند که منجر به چابکی بیشتر می‌شود. میکروسرویس‌ها می‌توانند به طور مستقل مقیاس شوند، بدون تأثیر بر سایر سرویس‌ها از کار بیفتند و پیچیدگی گردش‌های کاری را کاهش دهند. رویدادها را می‌توان به صورت انعطاف‌پذیر مسیریابی، ذخیره و برای اهداف حسابرسی ثبت کرد. جریان‌های رویداد مبتنی بر فشار می‌توانند در زمان واقعی عمل کنند و هزینه‌های مرتبط با ایجاد و اجرای کدی که به طور مداوم سیستم‌ها را برای تغییرات بررسی می‌کند، کاهش دهند.
مقیاس و خرابی مستقل
با جدا کردن سرویس‌ها، اجزای یک معماری رویداد محور می‌توانند به طور مستقل مقیاس شوند و از کار بیفتند و انعطاف‌پذیری یک برنامه را افزایش دهند. این امر با افزایش تعداد ادغام بین سرویس‌ها اهمیت بیشتری پیدا می‌کند. اگر یک سرویس دچار مشکل شود، بقیه می‌توانند به کار خود ادامه دهند.
معماری رویداد محور همچنین می‌تواند طراحی سیستم‌های تقریباً بی‌درنگ را آسان‌تر کند و به سازمان‌ها کمک کند از پردازش دسته‌ای فاصله بگیرند. رویدادها هنگام تغییر وضعیت یک برنامه ایجاد می‌شوند. با افزایش مقیاس رویدادها، لایه‌ای که رویدادها را پردازش می‌کند نیز می‌تواند افزایش یابد.
رویدادها معمولاً در سرویس‌های پیام‌رسانی منتشر می‌شوند که مانند یک بافر الاستیک بین میکروسرویس‌ها عمل می‌کنند و به مدیریت مقیاس‌پذیری کمک می‌کنند. رویدادها همچنین ممکن است به یک سرویس مسیریاب ارسال شوند که می‌تواند پیام‌ها را بر اساس محتوای رویداد فیلتر و مسیریابی کند. در نتیجه، برنامه‌های مبتنی بر رویداد می‌توانند مقیاس‌پذیرتر باشند و نسبت به برنامه‌های کاربردی یکپارچه، افزونگی بیشتری ارائه دهند.
توسعه با چابکی
با معماری رویداد محور و مسیریاب‌های رویداد، توسعه‌دهندگان دیگر نیازی به نوشتن کد سفارشی برای بررسی، فیلتر و مسیریابی رویدادها ندارند. یک مسیریاب رویداد به طور خودکار رویدادها را فیلتر و به مصرف‌کنندگان ارسال می‌کند. مسیریاب همچنین نیاز به هماهنگی سنگین بین سرویس‌های تولیدکننده و مصرف‌کننده را از بین می‌برد که چابکی توسعه‌دهنده را افزایش می‌دهد.
معماری رویداد محور مبتنی بر فشار است، به این معنی که همه چیز در صورت تقاضا با ارسال رویدادها به مسیریاب و سیستم‌های پایین‌دستی اتفاق می‌افتد، بدون نیاز به اطلاع سرویس‌های وابسته. به همین دلیل، زیرساخت و منابع می‌توانند با حجم رویداد، مقیاس بالا و پایین شوند که هزینه‌های پردازش حجم‌های کاری و اجرای برنامه‌های مستقر را کاهش می‌دهد.
ساخت سیستم‌های توسعه‌پذیر
معماری رویداد محور نیز بسیار توسعه‌پذیر است. تیم‌های دیگر می‌توانند ویژگی‌ها را گسترش دهند و قابلیت‌ها را بدون تأثیر بر میکروسرویس‌های موجود اضافه کنند. با انتشار رویدادها، یک برنامه می‌تواند با سیستم‌های موجود ادغام شود – و برنامه‌های آینده می‌توانند به راحتی به عنوان مصرف‌کنندگان رویداد ادغام شوند – بدون تغییر راه‌حل موجود.
تولیدکنندگان رویداد هیچ اطلاعی از مصرف‌کنندگان رویداد ندارند، بنابراین گسترش سیستم اصطکاک کمتری دارد و ویژگی‌ها یا ادغام‌های جدید وابستگی‌هایی را که سرعت توسعه آینده را کاهش می‌دهند، اضافه نمی‌کنند.
کاهش پیچیدگی
میکروسرویس‌ها، توسعه‌دهندگان و معماران را قادر می‌سازند تا گردش‌های کاری پیچیده را تجزیه کنند. به عنوان مثال، آنها می‌توانند یکپارچه تجارت الکترونیک را به «پذیرش سفارش» و «فرآیندهای پرداخت» با خدمات موجودی، انجام و حسابداری جداگانه تقسیم کنند.
حجم کاری که مدیریت و هماهنگی آن در یکپارچه پیچیده است، به مجموعه‌ای از سرویس‌های ساده و جدا از هم تبدیل می‌شود که به طور مستقل مدیریت می‌شوند و به صورت ناهمزمان از طریق پیام‌های رویداد ارتباط برقرار می‌کنند.
یک رویکرد رویداد محور، امکان مونتاژ و هماهنگ کردن سرویس‌هایی را که داده‌ها را با نرخ‌های مختلف پردازش می‌کنند، فراهم می‌کند. در مثال زیر، یک میکروسرویس پذیرش سفارش از طریق یک صف با یک سیستم پردازش پرداخت تعامل دارد.
در این مثال، سرویس پذیرش سفارش می‌تواند حجم زیادی از سفارش‌های ورودی را با ذخیره پیام‌ها در یک صف ذخیره کند.
سرویس پردازش پرداخت، که معمولاً به دلیل پیچیدگی مدیریت پرداخت‌ها کندتر است، می‌تواند جریان ثابتی از پیام‌ها را از صف بگیرد. سرویس پرداخت به دلیل منطق تلاش مجدد و مدیریت خطا، بین حالات مختلف سیستم جابجا می‌شود. سرویس گردش کار، مراحل پرداخت را بر اساس وضعیت سیستم هماهنگ و مدیریت می‌کند و در نهایت رویدادهای بیشتری را مورد علاقه سرویس‌های موجودی، انجام و حسابداری تولید می‌کند.
حسابرسی آسان
یک مسیریاب رویداد در یک معماری رویداد محور به عنوان یک مکان متمرکز برای حسابرسی برنامه شما و تعریف سیاست‌ها عمل می‌کند. این سیاست‌ها می‌توانند محدود کنند که چه کسی می‌تواند در یک مسیریاب منتشر و مشترک شود و کنترل کنند که کدام کاربران و منابع مجوز دسترسی به داده‌های شما را دارند. همچنین می‌توانید رویدادهای خود را هم در حال انتقال و هم در حالت ذخیره رمزگذاری کنید.
کاهش هزینه‌ها
EDAها مبتنی بر فشار هستند، بنابراین همه چیز در صورت تقاضا با ظاهر شدن رویداد در مسیریاب اتفاق می‌افتد. به این ترتیب، شما برای بررسی مداوم یک رویداد هزینه نمی‌پردازید. این بدان معناست که مصرف پهنای باند شبکه کمتر، استفاده CPU کمتر، ظرفیت ناوگان بیکار کمتر و تعداد کمتری از دست‌دهی‌های SSL/TLS است.
معماری رویداد محور (EDA) چگونه کار می‌کند؟
در زیر نمونه‌ای از یک معماری رویداد محور (EDA) برای یک سایت تجارت الکترونیک آورده شده است:
%20for%20an%20ecommerce%20site.88b2240905b1b6addd672871b98bcb17bd44d701.jpg "ٍEDA, برنامه های توزیع شده, سرویس های ابری, معماری رویداد محور, میکروسرویس ها")
این سایت نمونه سه جزء اصلی تولیدکننده رویداد و رویدادهایی را که تولید می‌کنند نشان می‌دهد. در این سناریو، یک مسیریاب رویداد، رویدادها را دریافت و فیلتر می‌کند، سپس یک یا چند رویداد را به مصرف‌کنندگان رویداد ارسال می‌کند.
معماری رویداد محور، سایت را قادر می‌سازد تا در مواقع اوج تقاضا، بدون از کار افتادن برنامه یا تأمین بیش از حد منابع، به تغییرات از منابع مختلف واکنش نشان دهد.
چه نوع حجم‌های کاری برای معماری رویداد محور (EDA) مناسب هستند؟
معماری‌های رویداد محور (EDA) می‌توانند راهی مؤثر برای پاسخگویی به خواسته‌های حجم‌های کاری بسیار مقیاس‌پذیر و بسیار در دسترس ارائه دهند. EDA همچنین به خوبی برای حجم‌های کاری با الگوهای ترافیکی غیرقابل پیش‌بینی یا “spike” (نوک‌دار) اعمال می‌شود.
معماری رویداد محور (EDA) چگونه برنامه‌ها را بهبود می‌بخشد؟
معماری رویداد محور (EDA)، اتصال سست بین اجزا را ترویج می‌کند، که آن را به رویکردی خوب برای ساخت برنامه‌های مدرن و توزیع‌شده تبدیل می‌کند.
تولیدکنندگان رویداد از هیچ فعالیتی از مصرف‌کنندگان پایین‌دستی رویدادهایی که تولید می‌کنند، بی‌اطلاع، بی‌توجه و بی‌بار هستند. خود رویدادها نشان‌دهنده تغییر در وضعیت هستند و ممکن است حاوی داده باشند یا نباشند. رویدادها از عواقب وجود خود بی‌اطلاع هستند. مصرف‌کنندگان گوش می‌دهند و رویدادهای مورد علاقه را پردازش می‌کنند. شما می‌توانید مصرف‌کنندگان جدید را به صورت آنلاین بیاورید تا قابلیت‌های جدیدی را بدون اختلال در گردش‌های کاری موجود ارائه دهند.
EDAها تجزیه سیستم‌های یکپارچه به مدل‌های دامنه کوچکتر را ترویج می‌کنند. توسعه‌دهندگان می‌توانند با بار شناختی کمتر، سرعت بیشتری بگیرند و سریع‌تر بهره‌ور شوند. هنگامی که توابع حیاتی از هم جدا می‌شوند، خطر کمتری برای استقرار به‌روزرسانی‌ها و ویژگی‌های جدید وجود دارد.
موارد استفاده رایج معماری رویداد محور (EDA) چیست؟
- ارتباط میکروسرویس‌ها برای بک‌اند‌های وب و موبایل: وب‌سایت‌های خرده‌فروشی یا رسانه‌ای و سرگرمی اغلب باید برای مدیریت ترافیک غیرقابل پیش‌بینی، مقیاس‌پذیر شوند. مشتریان از یک وب‌سایت تجارت الکترونیک بازدید می‌کنند و سفارش می‌دهند. رویداد سفارش به یک مسیریاب رویداد ارسال می‌شود. همه میکروسرویس‌های پایین‌دستی می‌توانند رویداد سفارش را برای پردازش دریافت کنند. اقدامات مثال می‌تواند شامل موارد زیر باشد: ارسال سفارش، مجوز پرداخت و ارسال جزئیات سفارش به یک ارائه‌دهنده حمل‌ونقل.
از آنجا که هر یک از میکروسرویس‌ها می‌توانند به طور مستقل مقیاس شوند و از کار بیفتند، این فرآیند می‌تواند در دوره‌های اوج سفارش بدون نقاط منفرد خرابی، مقیاس‌پذیر شود.
- خودکارسازی گردش کار تجاری: بسیاری از گردش‌های کاری تجاری، مانند تراکنش‌های خدمات مالی، نیاز به تکرار مراحل یکسان دارند. شما می‌توانید این مراحل را با معماری رویداد محور (EDA) آغاز و خودکار کنید.
به عنوان مثال، هنگامی که یک مشتری برای یک حساب جدید در یک بانک درخواست می‌دهد، بانک باید چند بررسی داده (اسناد هویتی، آدرس و غیره) را انجام دهد. برخی از حساب‌ها نیز به یک مرحله تأیید انسانی نیاز دارند. شما می‌توانید همه این مراحل را از طریق یک سرویس گردش کار که مراحل را به طور خودکار هنگام دریافت درخواست‌های حساب جدید اجرا می‌کند، هماهنگ کنید.
همچنین می‌توانید یک گردش کار برای پردازش ناهمزمان داده‌های درخواست مشتری با یادگیری ماشین اضافه کنید تا داده‌های مرتبط را استخراج کند و به طور بالقوه ساعت‌ها جمع‌آوری و اعتبارسنجی دستی داده‌ها را ذخیره کند.
-
ادغام برنامه SaaS: یک چالش اصلی برای محیط‌های نرم‌افزار به عنوان سرویس (SaaS)، عدم دید در فعالیت کاربر و داده‌ها است. برای باز کردن داده‌های silo شده، معماری‌های رویداد محور می‌توانند رویدادهای برنامه SaaS را دریافت کنند یا رویدادها را به برنامه‌های SaaS خود ارسال کنند. به عنوان مثال، می‌توانید میان‌افزاری برای دریافت داده‌های سفارش شریک ورودی و ارسال مستقیم سفارش‌ها به یک برنامه پردازش سفارش داخلی بسازید.
-
خودکارسازی زیرساخت: هنگام اجرای حجم‌های کاری محاسباتی فشرده (مانند تحلیل‌های مالی، تحقیقات ژنومی یا تبدیل رسانه)، می‌توانید منابع محاسباتی را در پاسخ به مقیاس‌پذیری برای پردازش بسیار موازی و سپس کاهش مقیاس پس از اتمام کار، پاسخگو کنید.
به عنوان مثال، در صنایع بسیارregulated، شرکت‌های دارای EDA می‌توانند در پاسخ به یک حادثه، منابع وضعیت امنیتی را فعال کنند، یا هر زمان که یک سیاست امنیتی یک رویداد هشدار ارسال می‌کند، اقدام اصلاحی انجام دهند.
چه زمانی باید از معماری‌های رویداد محور (EDA) استفاده کنید؟
معماری‌های رویداد محور (EDA) برای بهبود چابکی و حرکت سریع ایده‌آل هستند. آنها معمولاً در برنامه‌های مدرنی که از میکروسرویس‌ها استفاده می‌کنند، یا هر برنامه‌ای که اجزای جدا از هم دارد، یافت می‌شوند.
-
ادغام سیستم‌های ناهمگن: اگر سیستم‌هایی دارید که روی پشته‌های مختلف اجرا می‌شوند، می‌توانید از یک EDA برای به اشتراک گذاشتن اطلاعات بین آنها بدون اتصال استفاده کنید. مسیریاب رویداد، indirection و قابلیت همکاری بین سیستم‌ها را ایجاد می‌کند، بنابراین آنها می‌توانند پیام‌ها و داده‌ها را در حالی که آگنوستیک باقی می‌مانند، مبادله کنند.
-
تکثیر داده بین مناطق و حساب‌ها: می‌توانید از یک EDA برای هماهنگ کردن سیستم‌ها بین تیم‌هایی که در مناطق و حساب‌های مختلف AWS فعالیت می‌کنند و مستقر می‌شوند، استفاده کنید. با استفاده از یک مسیریاب رویداد برای انتقال داده بین سیستم‌ها، می‌توانید سرویس‌ها را به طور مستقل از تیم‌های دیگر توسعه، مقیاس و مستقر کنید.
-
نظارت بر وضعیت منابع و هشدار: به جای بررسی مداوم منابع خود، می‌توانید از یک EDA برای نظارت و دریافت هشدار در مورد هرگونه ناهنجاری، تغییر و به‌روزرسانی استفاده کنید. این منابع می‌توانند شامل سطل‌های ذخیره‌سازی، جداول پایگاه داده، توابع بدون سرور، گره‌های محاسباتی و موارد دیگر باشند.
-
Fanout و پردازش موازی: اگر سیستم‌های زیادی دارید که باید در پاسخ به یک رویداد عمل کنند، می‌توانید از یک EDA برای fan out رویداد بدون نیاز به نوشتن کد سفارشی برای ارسال به هر مصرف‌کننده استفاده کنید. مسیریاب، رویداد را به سیستم‌ها ارسال می‌کند که هر یک می‌توانند رویداد را به موازات با هدفی متفاوت پردازش کنند.
الگوهای رایج معماری رویداد محور (EDA) چیست؟
-
توابع کوتاه زیاد: توابع کوتاه زیادی را نسبت به تعداد کمتر از توابع بزرگتر ایجاد کنید. تخصصی کردن توابع برای حجم کاری شما به این معنی است که آنها مختصر هستند و به طور کلی زمان پردازش را کاهش می‌دهند. هر تابع باید رویداد ارسال شده به تابع را بدون اطلاع یا انتظارات از گردش کار کلی یا حجم تراکنش‌ها مدیریت کند. این امر باعث می‌شود که تابع نسبت به منبع رویداد با حداقل اتصال به سایر سرویس‌ها آگنوستیک باشد.
-
پردازش در صورت تقاضا به جای دسته‌ها: بسیاری از سیستم‌های سنتی به گونه‌ای طراحی شده‌اند که به صورت دوره‌ای اجرا شوند و دسته‌هایی از تراکنش‌ها را که با گذشت زمان جمع می‌شوند، پردازش کنند. به عنوان مثال، یک برنامه بانکی ممکن است ساعتی اجرا شود تا تراکنش‌های دستگاه خودپرداز را به دفاتر کل مرکزی پردازش کند.
در معماری رویداد محور (EDA)، پردازش سفارشی می‌تواند به هر رویدادی پاسخ دهد. این امر به سرویس اجازه می‌دهد تا همزمان با نیاز برای پردازش تراکنش‌ها تقریباً در زمان واقعی، مقیاس‌پذیر شود.
- بازیابی اختلال: در صورت بروز اختلال، ممکن است یک سرویس به طور خودکار برای تلاش مجدد پردازش یک رویداد فراخوانی شود. از آنجا که سرویس ممکن است یک رویداد را بیش از یک بار دریافت کند، توابع را به گونه‌ای طراحی کنید که idempotent باشند. این امر تضمین می‌کند که نتیجه پس از اولین باری که سرویس رویداد را دریافت می‌کند، تغییر نمی‌کند.
به عنوان مثال، اگر یک خرده‌فروش به دلیل تلاش مجدد سعی کند یک کارت اعتباری را دو بار پردازش کند، سرویس فقط در اولین تلاش، پرداخت را پردازش می‌کند. در تلاش مجدد، سرویس وضعیت پرداخت را بررسی می‌کند و رویداد را حذف می‌کند.
چالش‌های معماری رویداد محور (EDA) چیست؟
هنگام پذیرش معماری رویداد محور (EDA)، ممکن است لازم باشد در نحوه مشاهده طراحی برنامه خود تجدید نظر کنید.
- تأخیر متغیر: برخلاف برنامه‌های کاربردی یکپارچه، که ممکن است همه چیز را در همان فضای حافظه روی یک دستگاه واحد پردازش کنند، برنامه‌های رویداد محور در سراسر شبکه‌ها ارتباط برقرار می‌کنند. این طراحی تأخیر متغیر را معرفی می‌کند. اگرچه برنامه‌های کاربردی یکپارچه ممکن است تأخیر کمتر یا کمتر متغیری داشته باشند، اما این امر به طور کلی به قیمت مقیاس‌پذیری و در تمام می‌شود.
حجم‌های کاری که به عملکرد ثابت با تأخیر کم نیاز دارند، کاندیداهای خوبی برای EDA نیستند. دو نمونه، برنامه‌های معاملاتی با فرکانس بالا در بانک‌ها یا خودکارسازی رباتیک زیر میلی‌ثانیه در انبارها هستند.
- سازگاری نهایی: یک رویداد نشان‌دهنده تغییر در وضعیت است. با بسیاری از رویدادها که در هر نقطه از زمان از طریق سرویس‌های مختلف در یک معماری جریان دارند، چنین حجم‌های کاری اغلب در نهایت سازگار هستند. این امر باعث می‌شود که پردازش تراکنش‌ها، مدیریت موارد تکراری یا تعیین وضعیت کلی دقیق یک سیستم پیچیده‌تر باشد.
برخی از حجم‌های کاری به دلیل نیاز به ویژگی‌های ACID برای EDA مناسب نیستند. با این حال، بسیاری از حجم‌های کاری شامل ترکیبی از الزامات هستند که در نهایت سازگار (به عنوان مثال، کل سفارش‌ها در ساعت جاری) یا کاملاً سازگار (به عنوان مثال، موجودی فعلی) هستند. برای آن دسته از ویژگی‌هایی که نیاز به سازگاری قوی داده دارند، الگوهای معماری برای پشتیبانی از این امر وجود دارد. به عنوان مثال:
* DynamoDB می‌تواند خواندن کاملاً سازگار را، گاهی اوقات با تأخیر بیشتر، ارائه دهد، و همچنین می‌تواند از تراکنش‌ها برای کمک به حفظ سازگاری داده‌ها پشتیبانی کند. * می‌توانید از پایگاه‌های داده رابطه‌ای برای ویژگی‌هایی که نیاز به ویژگی‌های ACID دارند استفاده کنید، اگرچه هر پایگاه داده رابطه‌ای کمتر از یک فروشگاه داده NoSQL مقیاس‌پذیر است.
برگرداندن مقادیر به تماس‌گیرندگان: در بسیاری از موارد، برنامه‌های مبتنی بر رویداد ناهمزمان هستند. این بدان معناست که سرویس‌های تماس‌گیرنده قبل از ادامه کار دیگر، منتظر درخواست‌ها از سرویس‌های دیگر نمی‌مانند. این ویژگی اساسی EDAها، مقیاس‌پذیری و انعطاف‌پذیری را امکان‌پذیر می‌کند. با این حال، انتقال مقادیر برگشتی یا نتایج گردش کار را پیچیده‌تر از جریان‌های همگام می‌کند. در بسیاری از موارد، برگرداندن یک مقدار کمتر از تضمین موفقیت یا شکست پردازش رویداد مهم است. ویژگی‌هایی که پردازش رویدادها را تضمین می‌کنند، ممکن است مهم‌تر از برگرداندن مقادیر به یک تماس‌گیرنده باشند.
برای حجم‌های کاری تعاملی، مانند برنامه‌های وب و موبایل، کاربر نهایی معمولاً انتظار دارد که یک مقدار برگشتی یا وضعیت فعلی یک تراکنش را دریافت کند. برای این حجم‌های کاری، الگوهای طراحی متعددی وجود دارد که می‌تواند رویدادهای غنی را به تماس‌گیرنده ارائه دهد. با این حال، این پیاده‌سازی‌ها در یک معماری رویداد محور پیچیده‌تر از استفاده از یک مقدار برگشتی ناهمزمان سنتی هستند. پلتفرم اغلب می‌تواند این پیچیدگی را کاهش دهد.
-
عیب‌یابی در سرویس‌ها و توابع: عیب‌یابی سیستم‌های رویداد محور با عیب‌یابی یک برنامه کاربردی یکپارچه متفاوت است. مانند همه برنامه‌های مبتنی بر میکروسرویس و سیستم‌ها و سرویس‌های مختلف که رویدادها را ارسال می‌کنند، ثبت و بازتولید وضعیت دقیق چندین سرویس هنگام بروز خطا می‌تواند چالش‌برانگیز باشد. از آنجا که هر فراخوانی سرویس و تابع فایل‌های گزارش جداگانه دارد، تعیین آنچه برای یک رویداد خاص که باعث خطا شده است، پیچیده‌تر است.
-
هماهنگ‌سازی: معمول است که گردش‌های کاری ساده با گذشت زمان پیچیده‌تر شوند. در یک یکپارچه معمولی، این می‌تواند منجر به گروه‌های محکم‌تر از توابع و سرویس‌ها و کد پیچیده برای مدیریت مسیریابی و استثناها شود.
برای پیگیری وضعیت سیستم، گردش‌های کاری که شامل منطق انشعاب، انواع مختلف مدل‌های شکست و منطق تلاش مجدد هستند، معمولاً از یک هماهنگ‌کننده استفاده می‌کنند. هنگام ایجاد یک برنامه بدون سرور رویداد محور، مهم است که مشخص کنید چه زمانی این اتفاق می‌افتد تا بتوانید این منطق را برای هماهنگ‌سازی مناسب به یک ماشین حالت منتقل کنید.
