پشته مدرن برای ساخت یک برنامه رویداد محور در زمان واقعی

ظهور برنامه های کاربردی رویداد محور منجر به توسعه پشته های فناوری مدرن شده است که می توانند حجم زیادی از رویدادها را در زمان واقعی مدیریت کنند. برنامه های کاربردی رویداد محور در زمان واقعی با توانایی آنها در پاسخ فوری به رویدادها در زمان وقوع مشخص می شوند و اطلاعات به روز و بازخورد سریعتر را در اختیار کاربران قرار می دهند.
برای ساختن یک پشته مدرن برای یک برنامه کاربردی رویداد محور، باید چندین مؤلفه و فناوری را در نظر بگیرید که می توانند مراحل مختلف پردازش رویداد، از مجموعه رویداد تا رابط کاربری را مدیریت کنند. در این مقاله، ما اجزای مختلف یک پشته مدرن را در یک نمونه معماری برنامه آنلاین مبتنی بر رویداد در زمان واقعی که اطلاعات تخفیف را ارائه می دهد از بازارهای مختلف در یک شهر به مشتریان.
اهداف یادگیری
در پایان این مقاله یاد خواهید گرفت:
- محدودیت های داده های نظرسنجی مداوم از یک سرور را درک کنید.
- ساخت معماری رویداد محور برای یک برنامه وب تخفیف.
- نحوه نمایش داده ها به کاربران در زمان واقعی
درک موارد و الزامات استفاده از برنامه
وب سایت یا اپلیکیشن موبایلی که اطلاعات تخفیف از بازارهای مختلف یک شهر را در اختیار مشتریان قرار می دهد، می تواند ابزار مفیدی برای خریدارانی باشد که به دنبال در خرید خود صرفه جویی کنید. این برنامه میتواند اطلاعات بیدرنگ درباره تخفیفها و معاملات در بازارهای مختلف ارائه دهد و به کاربران این امکان را میدهد تا به سرعت و به راحتی بهترین معاملات را پیدا کنند.
تصویر زیر زمانی را نشان می دهد که ما وب سایت را در یک برنامه تلفن همراه باز می کنیم:
مشتریان می توانند از این وب سایت استفاده کنند قیمت ها را در بازارهای مختلف مقایسه کنید و دریافت اعلان ها در مورد تخفیف ها و معاملات در بازارهایی که به مکان فعلی خود نزدیک هستند به محض ایجاد آن بازارها ورودی های زمان واقعی به سیستم آنها میتوانند از این اپلیکیشن برای برنامهریزی سفرهای خرید خود استفاده کنند و بر اساس تخفیفها و معاملات موجود، بودجه خرید خود را تعیین کنند.
برخی از الزامات فنی اصلی برای این برنامه ممکن است شامل موارد زیر باشد: باید ارائه شود اطلاعات بلادرنگ در مورد تخفیف ها و معاملات در بازارهای مختلف، اطمینان حاصل کنید که مشتریان به به روزترین اطلاعات دسترسی دارند و این داده ها را بر اساس موقعیت مکانی کاربر فیلتر کنید. شاید همچنین باید به کاربران اجازه دهد جستجو برای تخفیف و معاملات بر اساس محصولات یا دسته بندی های خاص. پیاده سازی احراز هویت کاربر برای ارائه اطلاعات معاملات شخصی بر اساس ترجیحات کاربر.
در اینجا یک سوال مهم مطرح می شود: چگونه می توانیم اطلاعات تخفیف در زمان واقعی را به کاربران نشان دهیم (در حالی که آنها از وب سایت استفاده می کنند) همانطور که این داده ها در بازارهای شهر ظاهر می شوند؟ بدون پرداختن به جزئیات زیادی در معماری این وب سایت، بیایید فقط بر روی یافتن راه حلی برای نیازهای فنی تمرکز کنیم. بازیابی اطلاعات تخفیف از سرور در زمان واقعی.
اولین راه حل معمولی را ارزیابی کنید
اولین معماری ساده ممکن، اطلاعات تخفیف را با واکشی تغییرات از سرور بر اساس گزارش می دهد یک تایمر و آنها را در یک برنامه فرانت اند تک صفحه ای نشان می دهد. این صفحه از یک تایمر برای ارسال درخواست به سرور هر سه ثانیه برای درخواست تخفیف استفاده می کند. پاسخ مجموعه ای از تخفیف ها را برمی گرداند که سپس به کاربر نمایش داده می شود.
این طرح به عنوان یک رویکرد نظرسنجی مبتنی بر تایمر شناخته می شود. کلاینت نمونه ممکن است از کتابخانههای جاوا اسکریپت مانند ReactJS برای ایجاد رابط کاربری وبسایت و کلاینت HTTP Axios برای رسیدگی به درخواستها به یک نقطه پایانی API باطن استفاده کند (باطن را میتوان با استفاده از REST و هر چارچوب پشتیبان مانند NodeJS یا هر کد کمکد ایجاد کرد. چارچوب).
اطلاعات تخفیف به طور مرتب توسط یک API یکپارچه دیگر که با تماسهای خارجی از بازارهای مختلف مواجه میشود، بهروزرسانی میشود (این میتواند از یک نقطه پایانی webhook استفاده کند تا با ارائه یک نقطه پایانی بازگشت به تماس، هنگام دریافت تخفیفهای جدید بازار مطلع شود) و سپس در سرور ذخیره میشود. پایگاه داده رابطه ای (MySQL، PostgreSQL). هنگامی که API تخفیف باطن ما توسط یک درخواست HTTP از وب سایت مشتری فعال می شود، محتوا را از پایگاه داده برمی گرداند.
محدودیت های راه حل فعلی
مسئله واقعی در سرعت دریافت دادههای تخفیف بازار از ارائهدهندگان داده نیست، بلکه در سرعت تحویل آن به UI نهفته است (با فرض اینکه دادهها قبلاً در پایگاه داده ما ذخیره شده است، این دادهها را تجزیه و تحلیل و پردازش میکنیم). بیایید در مورد برخی از آنها فکر کنیم نقاط ضعف این رویکرد.
بین اپلیکیشن تخفیف تخفیف و سرویس باطن، درخواستهای نظرسنجی دائمی برای تغییرات وجود دارد. از آنجایی که این برنامه مبتنی بر تایمر است، برنامه مشتری با سرور تماس می گیرد، خواه تغییراتی در داده های اساسی وجود داشته باشد یا خیر. هنگامی که داده ها از سرور برگردانده می شوند، لیست کامل تخفیف ها در صفحه وب به روز می شود – بدون توجه به هر گونه تغییر در داده ها. این بسیار ناکارآمد است، و تماس می گیرد ممکن است منجر به بارهای خالی شود زمانی که هیچ به روز رسانی در پایگاه داده وجود ندارد. همچنین، اگر HTTP API فراخوانی شده درخواست HTTP ما را بپذیرد اما چه میشود رسیدگی به آن زمان زیادی می برد، این می تواند بر روی تجربه کاربر تأثیر بگذارد، به خصوص زمانی که این رفتار در رابط کاربری منعکس می شود (به این معنی که کاربر باید یک صفحه را به روز کند تا آخرین تغییرات تخفیف را دریافت کند).
هنگامی که با اولین معماری اپلیکیشن وب و محدودیت های آن بیشتر آشنا شدید، نوبت به معرفی یک طرح جدید برای حل مشکلات فوق می رسد.
تبادل داده مبتنی بر رویداد در زمان واقعی
به نظر می رسد معماری رویداد محور (EDA) برای دستیابی به الزامات فنی فوق مناسب باشد. در معماری رویداد محور، اجزا طراحی می شوند تا هنگام وقوع به رویدادها واکنش نشان می دهند، به جای اینکه توسط مؤلفه ها یا سرویس های دیگر فراخوانی شود. دقیقاً همان چیزی که ما می خواهیم، به جای اینکه دائماً تغییرات را از باطن نظرسنجی کنیم، از a استفاده می کند رویکرد مبتنی بر فشار و به سرور باطن اجازه می دهد تا به طور خودکار یک پیام یا اعلان برای همه مشتریان متصل ارسال کند.
اینجا، به موقع به توانایی سیستم ما برای پاسخگویی فوری به رویدادها یا ورودی ها یا در مدت زمان بسیار کوتاه اشاره دارد. در زمینه اپلیکیشن وب تخفیف، به معنای پردازش رویدادهای تخفیف به محض وقوع، بدون تاخیر قابل توجه است.
نمودار زیر معماری جدیدی از اجزای برنامه تخفیف را نشان می دهد. معماری 4 را نشان می دهد مراحل اصلی شروع از نحوه ما تشخیص تغییر داده های تخفیف، بلعیدن و رواج دادن آنها را به مصرف کنندگان رویداد و نشان می دهد آنها را در UI اساساً، این یک جریان معکوس نسبت به طراحی راه حل اول است.
بیایید هر جزء را تجزیه کنیم و نقش آنها را در بخش بعدی درک کنیم.
خرابی معماری جدید
این طراحی جدید ویژگیهای بلادرنگ را به دادههای تخفیف ما اضافه میکند، ترافیک را کاهش میدهد و تنها با بهروزرسانی با تغییر داده، رابط کاربری کارآمدتری ایجاد میکند. اما از چند فناوری و ابزار منبع باز برای پخش رویداد استفاده می کند.
اولین جزء الف است پایگاه داده که به عنوان منبع داده عمل می کند که می تواند PostgreSQL باشد (گزینه های محبوب دیگر شامل MongoDB یا MySQL). با تغییر داده ها در پایگاه داده، یک تغییر با استفاده از CDC مبتنی بر گزارش شناسایی می شود (تغییر ضبط داده ها) قابلیت های پایگاه داده این تغییر را می گیرد و آن را در یک گزارش تراکنش ثبت می کند. سپس تغییرات ثبت شده به یک رویداد تغییر تبدیل می شود که می تواند در زمان واقعی توسط سیستم های پایین دستی (یک کارگزار پیام) مانند کافکا مصرف شود.
ما از رابط Debezium برای Postgres برای استخراج این گزارشهای CDC در قالب جریان رویداد از پایگاه داده به کافکا استفاده خواهیم کرد. هنگامی که رویدادهای تخفیف ما وارد کافکا شد، الف پایگاه داده جریان مانند RisingWave می توانید در این فید تغییر از موضوعات کافکا مشترک شوید. سپس، RisingWave آنها را میخواند و در ذخیرهسازی دائمی محلی خود در قالب نماهای مادیشده برای دستیابی به تحمل خطا ذخیره میکند. به عبارت دیگر، می تواند به عنوان یک پردازشگر جریانی حالتی عمل کند که می تواند رویدادهای CDC را تحقق بخشد به جداول پایگاه داده رابطهای که وضعیت فعلی را نشان میدهند جریان یابد. پایگاه داده پخش جریانی به ما کمک می کند تا به سرعت یک نمای واقعی در زمان واقعی ایجاد کنیم که تمام اطلاعات تخفیف را بر اساس معیارهای تطبیق مشخص شده توسط کاربر نشان می دهد، یا آماری مانند 5 معاملات برتر در یک محصول انتخابی را آماده می کند یا نزدیک ترین معاملات را از نتایج بازارهای مختلف پیدا می کند. علاوه بر این، این توانایی را به ما می دهد تا داده ها را با تحویل آنها به آن تجزیه و تحلیل کنیم پلتفرم های BI و تجزیه و تحلیل داده ها برای اتخاذ تصمیمات تجاری بهتر بر اساس استفاده از برنامه وب ما.
RisingWave یک پایگاه داده استریم تخصصی در تجزیه و تحلیل بلادرنگ است که می تواند مستقیماً رویدادهای تغییر پایگاه داده را از باینلوگ های Postgres یا موضوعات کافکا بخواند و با پیوستن چندین رویداد به یکدیگر، یک نمای مادی ایجاد کند. RisingWave نمایش را با آمدن رویدادهای جدید به روز نگه می دارد و به شما امکان می دهد با استفاده از SQL پرس و جو کنید تا به آخرین تغییرات ایجاد شده در داده ها دسترسی داشته باشید.
پایگاه داده استریم نتایج را با استفاده از عملیات سینک در زمان واقعی به موضوعات کافکا می نویسد. اکنون، باید کد جاوا اسکریپت را اضافه کنیم تا پیامهای تخفیف دریافتی از کافکا را مصرف و پردازش کنیم و برای نمایش آنها، رابط کاربری را در زمان واقعی بهروزرسانی کنیم. ما میتوانیم از کتابخانه KafkaJS استفاده کنیم، که یک کلاینت محبوب کافکا برای Node.js برای گوش دادن و مصرف پیامهای کافکا است.
اکنون، میتوانید از این تابع مصرفکننده کافکا در کامپوننت React Native برای بهروزرسانی رابط کاربری با دریافت دادههای تخفیف جدید استفاده کنید.
نتیجه
در این پست، نحوه طراحی معماری برای یک اپلیکیشن وب که اطلاعات تخفیف در زمان واقعی را از بازارهای مختلف ارائه می دهد، یاد گرفتیم. برنامه وب می تواند به کاربران کمک کند بهترین معاملات را پیدا کنند و تصمیمات آگاهانه ای برای خرید بگیرند. ما دو راهحل مختلف را ارزیابی کردیم که نظرسنجیهای زماندار را اجرا میکنند و از الگوهای یکنواخت استفاده میکنند.
ما متوجه شدیم که ساختن یک پشته مدرن برای یک برنامه کاربردی رویداد محور نیاز به طیف وسیعی از فناوریها دارد. می توان از ترکیبی از پردازنده های جریان، پایگاه داده جریان، چارچوب های جاوا اسکریپت مدرن و کتابخانه ها استفاده کرد. پایگاه داده جریانی با پرس و جوهای پیچیده سروکار دارد که اغلب با محاسبه از قبل نتیجه در حافظه پنهان آن تغییر می کنند. در معماری دوم، ما هیچ سرویس/سرویس اضافی دیگری که منطق پردازش جریان سفارشی را پیادهسازی کند که منجر به افزایش سربار عملیاتی و پیچیدگی استقرارها شود، معرفی نکردیم.
منابع مرتبط
محتوای پیشنهادی
انجمن
🙋 به انجمن Risingwave بپیوندید
درباره نویسنده
از وبلاگ شخصی من دیدن کنید: www.iambobur.com