هنگام ساخت برنامه های بدون سرور مبتنی بر رویداد در AWS، EventBridge یکی از ضروریات است. استفاده از آن ساده، مقیاس پذیر و ارزان است.
با این حال، چالشی که اغلب در پروژه‌های رویداد محور با آن مواجه بودم، آزمایش بود. من نتوانستم راه آسانی برای تأیید اینکه رویدادهای ارسال شده توسط برنامه من مطابق انتظارات من هستند پیدا کنم. چالش حیاتی فهرست کردن رویدادهایی بود که از طریق یک گذرگاه رویداد ارسال می‌شدند، که به صورت بومی با EventBridge امکان‌پذیر نیست.
TL; DR
من یک کتابخانه آزمایشی ادغام EventBridge برای Typescript درست کردم، آن را بررسی کنید!
چه چیزی ممکن است در معماری رویداد محور من اشتباه کند؟
از زمان انتشار اولیه در سال 2019، EventBridge به طور گسترده ای برای ساخت معماری رویداد محور در AWS مورد استفاده قرار گرفته است و به تدریج جایگزین ابزارهای قدیمی مانند SQS و SNS شده است (اگرچه این موارد هنوز دارای موارد استفاده خاص معتبر هستند).
من همیشه از طرفداران EventBridge بوده ام. استفاده از آن ساده، قدرتمند و ارزان است. با این حال، در طول اولین پروژه‌هایم با EventBridge، آزمایش برنامه‌های ناهمزمانم بسیار دشوار بود.
به عنوان مثال، بیایید یک برنامه بسیار ساده را با EventBridge تصور کنیم:
در این معماری دو لامبدا داریم. اولین مورد به طور همزمان توسط ApiGateway راه اندازی می شود. سپس یک را قرار می دهد ORDER_CREATED رویداد در EventBridge. آن رویداد باعث اجرای دومین لامبدا می شود. خیلی ساده، درست است؟
با این حال، بسیاری از چیزها ممکن است در سیستم ما اشتباه باشد:
- ما کاربرد کد ممکن است به طور غیرمنتظره ای رفتار کند و رویداد را ارسال نکند
- می تواند باشد پیکربندی مسائل:
- مجوزهای IAM نامعتبر
- متغیرهای محیطی از دست رفته
-
onOrderCreatedمی تواند به رویداد اشتباه گوش دهد
برای کاهش این خطرات، می توانیم سیستم خود را در 3 سطح مختلف آزمایش کنیم:
- تست های واحد: آنها می توانند به کاربرد علت شکست آنها تأیید می کنند که کد مطابق انتظار عمل می کند و تعاملات خارجی آن را مسخره می کنند. تست واحد کارآمد برای لامبدا به خودی خود یک موضوع پیچیده است که در مقاله دیگری در مورد معماری شش ضلعی برای سرور بدون سرور به آن خواهم پرداخت.
- تست های ادغام: آنها ادعا می کنند که چندین مؤلفه در سیستم ما با هم مطابق انتظار رفتار می کنند. انواع مختلفی از تست‌های یکپارچه‌سازی، و به‌ویژه تست‌های یکپارچه‌سازی بومی ابری وجود دارد. خوشبختانه برای ما، این آزمایشات می تواند از ما جلوگیری کند پیکربندی علت شکست
- تست های انتها به انتها: آنها کل سیستم ما را یک جعبه سیاه می دانند و فقط با رابط های آن تعامل دارند. آنها از حوصله این مقاله خارج هستند
در ادامه این مقاله بر روی آن تمرکز خواهیم کرد تست های ادغام و رویداد پل. در سیستم ما، دو تست یکپارچه سازی مرتبط به نظر می رسد.
ساده ترین آنها تعاملات بین EventBridge و onOrderCreated.
به منظور اعتبارسنجی آن EventBridge و onOrderCreated به درستی پیکربندی شده‌اند، می‌توانیم به سادگی یک رویداد معتبر را در EventBridge در ابتدای آزمایش خود قرار دهیم، سپس منتظر بمانیم و بررسی کنیم که Lambda ما فراخوانی شده است، مثلاً با بررسی گزارش‌های CloudWatch.
دومین آزمون یکپارچه سازی پیچیده تر است و هدف آن بررسی تعاملات بین منابع در شروع فرآیند ما است.
در اینجا، هدف آزمایش ما این است که نقطه پایانی ارائه شده توسط API Gateway را فراخوانی کنیم و ادعا کنیم که createOrder Lambda رویدادی مطابق با انتظارات ما در EventBridge ارسال کرده است. و اینجاست که واقعاً پیچیده می شود.
مناسبت ها؟ چه اتفاقاتی؟
آزمایش معماری های رویداد محور به خودی خود یک موضوع کامل است، اما به طور خاص، EventBridge آن را آسان نمی کند.
اما چه چیزی باعث می‌شود تا برنامه‌های مبتنی بر EventBridge آزمایش شوند؟ EventBridge هیچ راهی برای فهرست کردن رویدادهایی که دریافت کرده است، یا بررسی اینکه آیا رویدادی در آن قرار داده شده است ارائه نمی دهد. در حالی که این ویژگی‌ها در یک محیط تولید معنی کمی دارند، اما برای بررسی اینکه کد ما برخی رویدادها را ایجاد کرده است، بسیار مفید خواهد بود.
برای اینکه ادعا کنیم رویدادها از طریق اتوبوس عبور کرده اند، باید آنها را به نحوی در مکانی قابل مشاهده نمایش دهیم.
جستجو برای ابزار تست EventBridge
به منظور دور زدن محدودیت های EventBridge در موضوع تست، من به دنبال یک ابزار موجود گشتم.
اما من از این ابزار چه می خواهم؟
- من می خواهم که باشد ساده برای راه اندازی. توسعه دهندگان برای نوشتن تست های یکپارچه سازی خوب باید با کمترین اصطکاک ممکن مواجه شوند
- من می خواهم که باشد مقیاس پذیر: من به تست های یکپارچه سازی خود نیاز دارم تا بتوانم به صورت موازی بدون تداخل اجرا شوند
- من می خواهم که آن باقی بماند ارزان: کل معماری من از مدل قیمت‌گذاری بدون سرور استفاده می‌کند و تست‌های من باید به اندازه کافی ارزان باشند.
- بدیهی است که باید باشد امن است (آیا باید دلیلش را توضیح دهم؟)
در چندین راه حل آنلاین یافت شد:
- تنظیم یک تابع مرحله برای هر آزمون
- ایجاد یک هدف EventBridge برای ریختن رویدادها به SQS. این رویکرد در چندین مقاله (اینجا و اینجا) پیشنهاد و در کتابخانه sls-test-tools پیاده سازی شد.
- استفاده از CloudWatch برای حذف و اشکال زدایی رویدادها، معرفی شده توسط David Boyne. اگرچه هدف مستقیم آن آزمایش نبود، شاید بتوان از این راه حل برای تست های یکپارچه سازی استفاده کرد
من می‌خواستم مزایا و معایب هر راه‌حل را ارزیابی کنم، بنابراین آنها را با توجه به محدودیت‌هایم نمره دادم و آنها را در جدول مقایسه‌ای قرار دادم:
| راه اندازی ساده | مقیاس پذیر | ارزان | امن است | |
|---|---|---|---|---|
| توابع مرحله | ❌ تنظیم دستی مورد نیاز است | ⚠️ احتمالاً یک زیرساخت در هر آزمون | ✅ پرداخت به موقع | ✅ IAM |
| SQS | ✅ بسته NPM ✅ ایجاد خودکار منابع |
❌ بدون موازی: SQS فقط می تواند یک مصرف کننده داشته باشد ⚠️ محدودیت های ایجاد SQS |
✅ پرداخت به موقع ⚠️ بدون غیرفعال کردن خودکار منابع |
✅ IAM |
| CloudWatch | ❌ تنظیم دستی مورد نیاز است | ✅ خواندن موازی نامحدود | ❌ گزارش های CloudWatch گران هستند! ❌ بدون غیرفعال کردن قانون خودکار |
✅ IAM ⚠️ داده‌های رویداد معقول ممکن است در گزارش‌ها باقی بماند |
اگرچه همه این راه‌حل‌ها به من الهام بخشیدند و به من فهماندند که آزمایش EventBridge امکان پذیر است، اما هیچ یک از آنها به طور کامل نیازهای من را برآورده نکرد.
ساخت زیرساخت تست EventBridge مقیاس پذیر
بنابراین تصمیم گرفتم یک کتابخانه تست های ادغام EventBridge بسازم و منبع باز بسازم. به همین دلیل با افتخار معرفی می کنم EventScout!
مطابق با الزاماتی طراحی شده است که من برای راه حل های آنلاین موجود اعمال کرده بودم.
ساده برای استفاده
EventScout از دو بخش بسیار قابل استفاده مجدد تشکیل شده است:
- یک ساختار CDK برای استقرار منابع لازم
- یک کلاینت سبک وزن برای استفاده در تست ها، به عنوان مثال با Jest of Vitest
اگر می خواهید یاد بگیرید که چگونه از EventScout در پروژه خود استفاده کنید، به مستندات بروید.
مقیاس پذیر
مقیاس پذیر ساختن زیرساخت تست ما مستلزم آن است که آزمایش های ما به صورت موازی اجرا شوند. برای این:
- ما نباید توسط سهمیه های AWS محدود شویم (به عنوان مثال پس از حذف یک صف SQS، نمی توان به مدت 60 ثانیه صف دیگری با همان نام ایجاد کرد). بنابراین EventScout تضمین می کند که فقط حداقل منابع ایجاد شده است در حین یک مجموعه آزمایشی و استفاده مجدد از منابع بین تست ها
- ما باید بتوانیم رویدادها را به طور مستقل برای هر مجموعه آزمایشی دریافت کنیم:
- هر مجموعه آزمایشی الگویی از رویدادها را برای تماشا اعلام می کند (الف دنباله از رویدادها)
- سپس هر مسیر کاملاً مستقل از سایر مسیرها است تا امکان پرس و جوی موازی را فراهم کند. هر مسیر را می توان به تعداد دفعاتی که لازم است پرس و جو کرد
بنابراین، نمودار توالی مجموعه آزمایشی به صورت زیر است:
از نقطه نظر معماری، بیایید در این دنباله شیرجه بزنیم:
- در طول مرحله راه اندازی، تست یک عدد ایجاد می کند رویداد پل قانون با الگوی مورد نظر، پیوند دادن به لامبدا هضم EventScout (
storeEvents) - این آزمون رویدادهایی را ایجاد می کند که با الگو مطابقت دارند
- قانون جدید ایجاد شده نامیده می شود
- این قانون باعث ایجاد لامبدا در بلع می شود
- با استفاده از اطلاعات فراداده از قانون،
storeEventsرویداد را در مسیر صحیح ذخیره می کند. - آزمون می‌تواند دنباله‌روی را پرس و جو کند و اظهارات را انجام دهد
- در پایان آزمایش، تنها چیزی که باقی می ماند حذف قانون EventBridge است
دو ویژگی در اینجا برای مقیاس پذیر کردن EventScout کلیدی هستند:
- استفاده از یک قانون EventBridge در هر مجموعه آزمایشی:
- این باعث می شود که هر آزمون کاملاً مستقل از بقیه باشد
- از زیرساخت استفاده مجدد می کند و فقط نیاز به ایجاد و حذف قانون دارد که بسیار سریع است
- استفاده از فراداده قانون برای ذخیره رویدادها در یک دنباله:
- برای دانستن اینکه کدام مجموعه آزمایشی به رویداد دریافتی علاقه مند هستند، نیازی به درخواست یا محاسبات اضافی نیست
- اگر رویدادی منطبق با دو قانون ارسال شود، در دو مسیر ذخیره می‌شود که آزمایش‌های موازی را فعال می‌کند.
ارزان
EventScout فقط از منابع بدون سرور (Lambda، DynamoDB، API Gateway) استفاده می‌کند تا از مزایای مدل پرداخت به‌موقع استفاده کند. علاوه بر این، EventScout تضمین می کند که از هیچ منبع غیر ضروری استفاده نمی شود پاکسازی خودکار مسیر. با بهره‌گیری از قابلیت‌های Time-to-live DynamoDB، به طور خودکار:
- رویدادهای دنباله‌دار ثبت‌شده را بعد از 15 دقیقه پاک می‌کند
- قوانین رویداد را پس از 15 دقیقه متوقف می کند تا زمانی که به صورت دستی متوقف نشده اند، پرونده را رسیدگی کند
این باعث می شود EventScout امن ترین راه برای اجرای تست های یکپارچه سازی بدون نگرانی در مورد هزینه آنها باشد.
امن است
- تمام تعاملات بین مشتری EventScout و ساختار توسط IAM ایمن می شود
- رویدادها پس از 15 دقیقه به طور خودکار پاک می شوند و هر گونه مشکل حریم خصوصی از بین می رود
از EventScout در زیرساخت خود استفاده کنید
استفاده از قابلیت های EventScout در زیرساخت شما بسیار ساده است.
منابع را با ساختار EventScout مستقر کنید
با نصب سازه EventScout شروع کنید:
npm install @event-scout/construct
سپس، ساختار CDK را در برنامه CDK خود نمونه سازی کنید:
import { EventScout } from '@event-scout/construct';
import { CfnOutput } from 'aws-cdk-lib';
import { EventBus } from 'aws-cdk-lib/aws-events';
// create the necessary resources
const { restEndpoint } = new EventScout(this, 'EventScout', {
eventBus: EventBus.fromEventBusName(this, 'EventBus', eventBusName),
});
// export the endpoint value for easier use in tests
new CfnOutput(this, 'EventScoutEndpoint', {
value: restEndpoint,
description: 'EventScout endpoint',
exportName: '<your export name>',
});
صادرات در اینجا لازم نیست، اما برای بازیابی نقطه پایانی EventScout برای آزمایشات شما مفید خواهد بود.
از سرویس گیرنده EventScout در تست های خود استفاده کنید
npm install --save-dev @event-scout/client
سپس می توانید برای جزئیات در مورد نحوه نمونه سازی و استفاده از مشتری در آزمایشات خود به مستندات مراجعه کنید.
تبریک می‌گوییم، شما قدرت EventScout را باز کرده‌اید! عاقلانه استفاده کن…
