ممکن است یک گذرگاه EventBridge دارای قاعده ای باشد که پیام ها را به گذرگاه EventBridge دیگر ارسال می کند. اما، چه اتفاقی می‌افتد اگر گذرگاه EB دوم قانونی داشته باشد که هر پیامی را که دریافت می‌کند به گذرگاه اول EB برمی‌گرداند؟ همانطور که انتظار می رود، یک انتقال داده بازگشتی بین دو اتوبوس EB وجود خواهد داشت.
در این مقاله، بیایید در مورد نحوه رسیدگی به چنین پیام‌های بازگشتی که بین دو اتوبوس EB عبور می‌کنند، بحث کنیم.
ابتدا به معماری نگاه می کنیم.
می‌توانید پروژه CDK را که شامل کد منبع برای راه‌اندازی این سیستم در محیط AWS با استفاده از AWS CDK و Python است در اینجا بیابید: https://github.com/pubudusj/eb-to-eb
چگونه کار می کند
هنگامی که پروژه راه اندازی شد، 2 اتوبوس EB ایجاد می کند. هر اتوبوس دو قانون خواهد داشت.
یک قانون گذرگاه EB دیگر را به عنوان هدف دارد. قانون دیگر یک گروه CloudWatch را به عنوان هدف خواهد داشت که هر پیام دریافتی را در گذرگاه ثبت می کند. همچنین هر گذرگاه دارای یک تنظیم صف نامه مرده برای حفظ هرگونه پیامی است که قابل پردازش نیست.
برای آزمایش، می توانید هر پیامی را به گذرگاه EB A ارسال کنید.
رفتار مورد انتظار این است که پیام بین گذرگاه های EB به عنوان یک حلقه ارسال می شود، به طوری که یک رکورد در گروه CloudWatch Log برای هر رسید وجود دارد.
رفتار واقعی این است که، پیام از گذرگاه A به گذرگاه B ارسال می‌شود. گروه‌های CloudWatch A پیام را ثبت می‌کنند. همچنین، گروه CloudWatch B این پیام را ثبت کرده است که به معنای دریافت پیام به اتوبوس B است.
با این حال، اینها تنها رکوردهای گزارش CloudWatch در دسترس هستند، به این معنی که پیام به اتوبوس A ارسال نشده است.
در عوض، اگر صف حرف مرده اتوبوس B را بررسی کنید، می‌توانید ببینید که پیام در آنجا موجود است. همچنین، اگر ویژگی های پیام را بررسی کنید، می توانید کد خطا را به صورت “THIRD_ACCOUNT_HOP_DETECTED“. و پیغام خطا می گوید – “انتقال رویداد برای رویداد رد شد [event id] زیرا یک رویداد می تواند تنها یک بار به یک هدف اتوبوس رویداد ارسال شود. این رویداد قبلاً به هدف اتوبوس رویداد تحویل داده شده بود.”
این بدان معناست که در گذرگاه B، هنگامی که می‌خواهید پیام را به اتوبوس A برگردانید، آن را پردازش نمی‌کند.
توضیح
خب، این رفتار پیش‌فرض اتوبوس‌های رویداد EventBridge Amazon است. EventBridge Bus مکانیزمی دارد که یک پیام مشابه را بیش از یک بار به هدف اتوبوس رویداد دیگری ارسال نمی کند. در چنین سناریویی، به سادگی پیام را رد می کند و در این حالت، از آنجایی که ما DLQ را راه اندازی کرده ایم، پیام به آنجا ارسال شده است.
به دلیل این ویژگی Amazon EventBridge، از حلقه بازگشتی جلوگیری می شود. بنابراین، برای جلوگیری از بازگشت در اینجا نیازی به انجام اقدامات اضافی ندارید.
