Cloudflare K2: جریان های رویداد بدون سرور

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

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

امروز ما در حال راه اندازی Cloudflare K2 در نسخه بتا عمومی برای حل این مشکل هستیم. K2 یک رویداد بادوام است که در پلتفرم توسعه دهندگان جریان دارد. شما رویدادها را به یک جریان K2 ارسال می کنید، که آنها را به عنوان یک گزارش سفارشی ذخیره می کند. مصرف‌کنندگان می‌توانند آنها را به روش‌های مختلفی بخوانند، برای مثال با تقسیم خواندن در مجموعه‌ای از مصرف‌کنندگان، یا ارائه همه پیام‌ها به همه مصرف‌کنندگان. این کاملا بدون سرور است، به مقادیر زیادی داده مقیاس می‌شود و از نگهداری طولانی مدت پشتیبانی می‌کند، بنابراین حتی دوره‌های طولانی از کار افتادگی مصرف‌کننده، داده‌ها را از دست نمی‌دهد.

در زیر هود، K2 یک سیاهه پارتیشن بندی شده و بادوام را در بالای فضای ذخیره سازی اشیاء R2 پیاده سازی می کند که به آن اجازه می دهد تا حجم زیادی از فضای ذخیره سازی را افزایش دهد.

اگر برای شروع آماده هستید، می توانید با دنبال کردن راهنمای اینجا، اولین جریان خود را در چند ثانیه ایجاد کنید.

ما ابتدا K2 را ساختیم زیرا به یک بافر بادوام در لبه نیاز داشتیم که در ابتدا به عنوان لایه جذب برای خطوط لوله حوضه عمل می کرد. خطوط لوله توسط یک موتور پردازش جریانی کار می کند که بر اساس یک مدل مبتنی بر کشش کار می کند، به این معنی که برخی از سیستم های دیگر باید رویدادها را قبل از خواندن، تبدیل و نوشتن در R2 ذخیره کنند. و از آنجایی که ما متعهد می شویم که هرگز رویدادها را پس از پذیرفته شدن در Pipelines Stream حذف نکنیم، این ذخیره سازی باید بادوام باشد - به این معنی که نمی تواند داده ها را از دست بدهد - در دوره های بالقوه طولانی مدت.

اینجا جایی است که اکثر شرکت ها آپاچی کافکا را مستقر می کنند. با این حال، Pipelines بر روی لبه Cloudflare اجرا می‌شود، که تعداد زیادی سرور در بیش از 335 شهر را پوشش می‌دهد. معماری منحصربه‌فرد ما به این معناست که ما اغلب نمی‌توانیم نرم‌افزار سیستم‌های توزیع‌شده سنتی مانند کافکا را اجرا کنیم و باید درباره نحوه ساخت و عملکرد این سیستم‌ها تجدیدنظر کنیم.

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

در طراحی سیستم بافر بادوام که K2 شد، تصمیم گرفتیم به حالت اولیه قدرتمندی که در حال حاضر داریم تکیه کنیم: R2. سیستم‌های ذخیره‌سازی اشیا مانند R2 فضای ذخیره‌سازی بسیار بادوام (11 9s!) را با APIهای کاملا سازگار ترکیب می‌کنند. بارگذاری تکرار و اجماع در لایه ذخیره‌سازی به ما اجازه می‌دهد تا لایه کاربردی (در این مورد K2) را بسیار ساده‌تر، ارزان‌تر و کارایی بالاتر کنیم. یک مزیت ثانویه این است که محاسبات و ذخیره سازی را از هم جدا می کند، به این معنی که هر کدام می توانند به طور مستقل مقیاس شوند. این به ما امکان می دهد تا مقادیر زیادی از داده های تاریخی را با هزینه کم ذخیره کنیم.

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

در حالی که ساخت بر روی R2 دارای مزایای بسیاری است، یک نقطه ضعف وجود دارد: تاخیر تولید بالاتر. نوشتن در ذخیره سازی شی کندتر از یک دیسک محلی است و قبل از شروع نوشتن باید منتظر بمانیم تا دسته محلی جمع شود. در نسخه اولیه K2 ما، حدود 1 ثانیه تأخیر تولید در صدک 99 زمان پاسخ را افزایش می دهد.

ما جزئیات بیشتری در مورد طراحی K2 در یک غواصی عمیق فنی آینده به اشتراک خواهیم گذاشت.

Cloudflare چندین نسخه اولیه تحویل ناهمزمان موجود، از جمله Queues و Basin Pipelines دارد. چه زمانی باید به جای این محصولات موجود به K2 برسید؟

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

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

Basin Pipelines یک سرویس انتقال بدون سرور است. می‌توانید رویدادهای Pipeline JSON خود را ارسال کنید، که می‌توانند تبدیل شوند و به R2 یا یک کاتالوگ حوضه نوشته شوند. هنگامی که نتیجه نهایی نوشتن رویدادهای شما در ذخیره‌سازی اشیا یا جداول Iceberg است، Pipelines و هنگام انجام پردازش سفارشی یا نوشتن به مقصد دیگر، K2 را توصیه می‌کنیم.

استفاده از K2 ابتدا مستلزم ایجاد یک جریان است. می‌توانید جریان‌های زیادی در حساب خود برای موارد استفاده یا انواع رویدادها داشته باشید. جریان ها را می توان از طریق cf، Wrangler، داشبورد یا API ایجاد کرد.

بیایید جمع آوری و پردازش تجزیه و تحلیل محصول را مثال بزنیم. ابتدا یک جریان با cf ایجاد می کنیم:

هنگامی که یک جریان داشته باشیم، می توانیم از طریق یک API HTTP یا Worker binding شروع به تولید آن کنیم. به عنوان مثال، از یک کارگر:

K2 داده ها را به صورت بایت نشان می دهد، بنابراین می توانید از هر فرمت یا رمزگذاری که برای برنامه شما منطقی است استفاده کنید.

اکنون که رویدادهایی در یک جریان داریم، می‌توانیم یک اشتراک ایجاد کنیم. اشتراک‌ها کار را بین مصرف‌کنندگان تقسیم می‌کنند و موازی خواندن را امکان‌پذیر می‌سازند - به تعداد خواننده‌های متعددی کاهش می‌یابد تا بار بیشتری را نسبت به یک سرور مدیریت کند.

ما می توانیم از طریق HTTP API یک اشتراک ایجاد کنیم.

با اشتراک ایجاد شده، می‌توانیم آن را از هر یک از مشتریان خود نظرسنجی کنیم:

وقتی مشتری با مصرف تماس می گیرد، برای آن دسته خاص از رویدادها به مدت 5 دقیقه اجاره نامه دریافت می کند. مشتری می تواند یکی از سه کار زیر را انجام دهد:

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

برای جزئیات کامل در مورد APIها به اسناد K2 مراجعه کنید.

K2 امروز در نسخه بتا عمومی برای حساب‌های دارای اشتراک Workers Paid در این محدودیت‌ها در دسترس است:

اگر به محدودیت‌های بالاتر نیاز دارید، لطفا با تیم در Discord تماس بگیرید یا فرم افزایش محدودیت را پر کنید.

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

ما یک نقشه راه هیجان انگیز برای K2 در ماه های آینده داریم، از جمله:

ما از دیدن آنچه که بر روی K2 می سازید هیجان زده ایم! بازخورد خود را در مورد Cloudflare Discord به اشتراک بگذارید.