Durable Objects در Cloudflare برای موقعیت‌هایی طراحی شده که چند درخواست یا چند کاربر باید روی یک State مشترک هماهنگ شوند. هر Object هویت مشخص و ذخیره‌سازی مرتبط با خود دارد. این مدل با «یک نسخهٔ مستقل از همان State در همهٔ Edgeها» فرق دارد. اگر کاربران یک اتاق گفتگو باید پیام‌ها را با ترتیب مشترک ببینند، وجود یک محل هماهنگی برای همان اتاق مفید است. فاصلهٔ شبکه و قواعد برنامه همچنان در تجربه اثر دارند.
عبارت قبلی این مقاله دربارهٔ کار بدون سرور مرکزی می‌توانست این تصور را ایجاد کند که هماهنگی کاملاً حذف شده است. در عمل، مسئولیت مدیریت زیرساخت از توسعه‌دهنده کم می‌شود، اما هر Object می‌تواند نقش هماهنگ‌کنندهٔ یک واحد منطقی را داشته باشد. معرفی رسمی Durable Objects ترکیب compute و storage را توضیح می‌دهد. برای انتخاب این مدل باید ابتدا واحد هماهنگی محصول را مشخص کنیم، نه اینکه فقط محل اجرای کد را Edge بنامیم.
واحد هماهنگی را از محصول استخراج کنید
برای یک ابزار همکاری فرضی، واحد هماهنگی می‌تواند یک سند باشد. کاربران همان سند به Object مرتبط هدایت می‌شوند و تغییرها در یک زمینهٔ مشترک بررسی می‌شوند. برای بازی، شاید واحد یک اتاق مسابقه باشد. این دو مثال داده یا نتیجهٔ واقعی یک مشتری نیستند؛ فقط شکل تقسیم مسئله را نشان می‌دهند. انتخاب یک Object برای تمام کاربران یک سازمان، ممکن است دامنهٔ هماهنگی را بی‌دلیل بزرگ کند و هزینهٔ تغییر و اختلال را افزایش دهد.
تقسیم بیش‌ازحد ریز نیز مشکل خود را دارد. اگر هر بخش کوچک سند Object جدا داشته باشد، عملیات مشترک میان آن‌ها به هماهنگی تازه‌ای نیاز پیدا می‌کند. قبل از انتخاب کلید، بنویسید چه تغییرهایی باید با هم سازگار باشند و کدام تغییرها مستقل‌اند. مرز Object باید به همین رابطه مربوط باشد. نام فنی کلید، جای این تصمیم را نمی‌گیرد. یک مدل مناسب با عملیات واقعی محصول قابل توضیح است، نه فقط با تعداد کاربران یا تعداد رکوردها.
هویت Object با مجوز دسترسی متفاوت است
Namespace و شناسه به برنامه کمک می‌کنند درخواست را به Object مناسب بفرستد. اما دانستن شناسهٔ اتاق یا سند نباید مجوز ورود به آن باشد. بررسی مالکیت و نقش کاربر باید در جریان درخواست قرار داشته باشد. اگر شناسه از URL گرفته می‌شود، سرویس باید تأیید کند کاربر حق دسترسی به همان منبع را دارد. یک مسیر معتبر از نظر فنی ممکن است به دادهٔ سازمان دیگری اشاره کند و باید طبق قرارداد محصول محدود شود.
راهنمای مفهوم Durable Objects نقش هویت یکتا و State را توضیح می‌دهد. در طراحی برنامه، کلیدهای داخلی را از نام‌های قابل ویرایش کاربر جدا نگه دارید. عنوان سند ممکن است تغییر کند یا تکراری باشد؛ هویت عملیاتی باید با قرارداد برنامه پایدار بماند. این جداسازی به جابه‌جایی و تغییر نام نیز کمک می‌کند، چون یک ویرایش محتوایی ناخواسته به ساخت منبع منطقی تازه تبدیل نمی‌شود.
حافظهٔ زنده، ذخیرهٔ پایدار نیست
متغیری که در حافظهٔ اجرای Object قرار دارد، برای State موقت مفید است، اما نباید تنها محل نگهداری دادهٔ لازم برای بازیابی باشد. اجرا ممکن است متوقف شود و دوباره شروع شود. شمار کاربران متصل یا cache موقت با تاریخچهٔ پیام و دادهٔ سند نقش یکسانی ندارند. هر داده را به یکی از این نیازها متصل کنید: فقط هنگام اجرای فعلی لازم است یا باید بعد از شروع مجدد نیز قابل بازیابی باشد.
وقتی دادهٔ پایدار دوباره خوانده می‌شود، برنامه باید بداند چگونه State زنده را بازسازی کند. اگر نسخهٔ ساختار داده تغییر کرده، مسیر تبدیل نیز لازم است. حذف و ساخت مجدد یک متغیر محلی، مسئلهٔ سازگاری دادهٔ ذخیره‌شده را حل نمی‌کند. مستند کوتاهی از شکل داده و نسخهٔ آن، به تیم کمک می‌کند تغییرهای بعدی را با عمر واقعی داده هماهنگ کند. State محصول ممکن است بسیار بیشتر از عمر یک اجرای کد باقی بماند.
Storage را با نیاز عملیات انتخاب کنید
Cloudflare برای Durable Objects مسیرهای storage با قراردادهای مشخص ارائه می‌کند و مستندات جاری، SQLite-backed storage را برای کلاس‌های تازه مطرح می‌کنند. راهنمای دسترسی به Storage مرجع بررسی رفتار عملیات است. انتخاب باید با نوع داده و روش خواندن هماهنگ باشد. تاریخچهٔ قابل جست‌وجو، یک مقدار کوچک تنظیم و فهرست وضعیت کاربران، نیازهای یکسانی ندارند. وجود API ذخیره‌سازی به معنی مناسب بودن یک شکل داده برای همهٔ این‌ها نیست.
تراکنش را برای مجموعهٔ تغییرهایی در نظر بگیرید که باید با هم پذیرفته شوند. مثلاً ثبت نتیجهٔ یک عملیات و تغییر وضعیت مرتبط ممکن است به قرارداد مشترک نیاز داشته باشند. اما عملیات روی سرویس خارجی، صرفاً با وجود تراکنش محلی به بخشی از همان تضمین تبدیل نمی‌شود. اگر پرداخت یا ارسال پیام بیرونی شکست بخورد، رفتار بازیابی باید مشخص باشد. مرز storage و مرز سیستم خارجی را در مستند طراحی جدا نشان دهید تا تضمین محلی بیش از دامنهٔ خود تفسیر نشود.
هم‌زمانی به قواعد برنامه نیاز دارد
هماهنگی درخواست‌ها ابزار مفیدی است، ولی عملیات دارای await و تماس بیرونی همچنان باید با قرارداد اجرا نوشته شوند. تصور اینکه هر تابع بلند، بدون توجه به بخش‌های asynchronous همیشه مانند یک بخش اتمی عمل می‌کند، خطرناک است. اگر تصمیم به State فعلی وابسته است، محل خواندن و نوشتن آن را مرور کنید. بررسی کنید در صورت تغییر میان مراحل چه اتفاقی می‌افتد. مثال واقعی عملیات از یک شعار کلی دربارهٔ مدل Actor دقیق‌تر است.
درخواست تکراری نیز باید دیده شود. اگر کاربر بعد از تأخیر شبکه دوباره کلیک کند، ممکن است همان اقدام به سرویس برسد. برای عملیاتی که باید فقط یک بار اثر بگذارد، یک قرارداد idempotency یا شناسایی تکرار لازم است. Object از نام یک متد نمی‌فهمد که دو درخواست معنای تجاری واحد دارند. شناسهٔ اقدام، نتیجهٔ ثبت‌شده و رفتار پاسخ دوباره باید با هم طراحی شوند. این موضوع مخصوص Edge نیست و در هر سرویس دارای شبکه اهمیت دارد.
WebSocket با مدیریت اتصال همراه است
برای اتاق گفتگو، WebSocket می‌تواند مسیر ارتباط زنده باشد. اما اتصال پایدار فرض همیشگی نیست؛ دستگاه جابه‌جا می‌شود، شبکه قطع می‌شود و کاربر دوباره وارد می‌شود. برنامه باید بداند پس از اتصال مجدد چه پیام‌هایی لازم است و آیا ترتیب قابل بازیابی وجود دارد. راهنمای WebSocketهای Durable Objects و قابلیت Hibernation مرجع این بخش‌اند. استفاده از API مدیریت‌شده، قرارداد تاریخچه و اتصال مجدد محصول را حذف نمی‌کند.
پیام «آنلاین» نیز به مشاهدهٔ یک اتصال در زمان مشخص مربوط است، نه تضمین حضور شخص پشت دستگاه. برای رابط، معنای این وضعیت را روشن نگه دارید. اگر پیام مهمی باید تحویل شود، صرف ارسال روی اتصال کافی نیست؛ بسته به نیاز ممکن است تأیید و ذخیرهٔ نتیجه لازم باشد. این تصمیم را از هدف محصول استخراج کنید. یک چت دوستانه و یک ابزار هماهنگی حساس، سطح انتظار متفاوتی دارند و نباید قرارداد یکسانی بگیرند.
مقیاس، هزینه و محل داده
تقسیم کار میان Objectهای مستقل، با افزایش ظرفیت یک Object واحد فرق دارد. یک اتاق بسیار پرکاربر ممکن است گلوگاه خود را داشته باشد، حتی اگر تعداد زیادی اتاق دیگر مستقل اجرا شوند. حدود پلتفرم و هزینه‌ها نیز می‌توانند تغییر کنند؛ پیش از استقرار، محدودیت‌های رسمی را برای طرح انتخاب‌شده بخوانید. عددی که برای یک نمونهٔ کوچک مناسب است نباید بدون بررسی به محصول بزرگ منتقل شود.
برای ارزیابی، یک جریان محدود با واحد هماهنگی روشن انتخاب کنید. شکل دادهٔ پایدار، مجوز، اتصال مجدد و درخواست تکراری را بنویسید. برای سمت رابط، راهنمای Chat UI به نمایش وضعیت‌ها کمک می‌کند. Durable Objects زمانی ارزش خود را نشان می‌دهد که مرز State با عملیات محصول هماهنگ باشد. افزودن نام Edge به معماری، جای تصمیم دربارهٔ این مرز و رفتار شکست را نمی‌گیرد.
هنوز دیدگاهی ثبت نشده
اولین نفری باشید که نظر می‌دهد!