Edge Computing به انجام بخشی از کار نزدیک‌تر به محل مصرف داده اشاره دارد، ولی یک جای ثابت در تمام معماری‌ها نیست. در وب، ممکن است کد در نقاط توزیع شبکه اجرا شود؛ در سیستم صنعتی، پردازش می‌تواند کنار دستگاه باشد. برای محصول وب، سؤال عملی این است که کدام کار از جابه‌جایی محل اجرا سود می‌برد و داده لازم آن کجا قرار دارد. «Edge-first» بدون پاسخ این سؤال‌ها، برنامه معماری محسوب نمی‌شود.
متن قبلی Edge را آینده اجتناب‌ناپذیر همه برنامه‌ها معرفی می‌کرد. چنین انتخاب عمومی‌ای نیازهای متفاوت محصولات را نادیده می‌گیرد. یک صفحه عمومی cache شده، یک عملیات پرداخت و یک پردازش سنگین فایل شرایط یکسان ندارند. تعریف Edge Computing در Cloudflare یک مرجع برای مفهوم است؛ تصمیم استقرار باید بر اساس مسیر واقعی درخواست و قرارداد داده گرفته شود.
CDN، Compute و Database سه مسئولیت‌اند
CDN محتوای قابل استفاده دوباره را توزیع می‌کند. Compute منطق برنامه را اجرا می‌کند. Database داده را با مدل ذخیره‌سازی و consistency مشخص نگه می‌دارد. قرار گرفتن این خدمات در یک پلتفرم به معنی یکی بودن رفتارشان نیست. ممکن است فایل عمومی نزدیک کاربر باشد و نوشتن داده همچنان به یک region مشخص برسد. نقشه معماری باید این تفاوت را نشان دهد.
برای یک مجله، فایل style و تصویر مقاله معمولاً ظرفیت توزیع دارند. شخصی‌سازی فهرست مطالعه به هویت و داده کاربر وابسته است. ثبت نظر به اعتبارسنجی، مجوز و نوشتن پایدار نیاز دارد. اگر همه این کارها را فقط «روی لبه» نام‌گذاری کنید، هنوز معلوم نیست کدام پاسخ مشترک است و کدام عمل باید به منبع معتبر داده برسد.
مفهوم Edge را از تعداد نقاط حضور جدا کنید. محل یک cache و محل اجرای کد الزاماً یکی نیست. سرویس ممکن است برخی درخواست‌ها را به منطقه خاصی بفرستد یا برای نزدیکی به backend محل دیگری انتخاب کند. به جای حدس از نقشه تبلیغاتی شبکه، رفتار همان محصول و تنظیم واقعی پروژه را بخوانید.
فاصله تا داده گاهی از فاصله تا کاربر مهم‌تر است
یک درخواست کوتاه که فقط header را بررسی می‌کند با درخواستی که چند query پشت سر هم دارد تفاوت دارد. اگر کد نزدیک کاربر است ولی queryها به پایگاه داده دور می‌روند، تأخیر آن ارتباط‌ها وارد مسیر می‌شود. نزدیکی یک بخش، تمام مسیر را نزدیک نمی‌کند. قبل از جابه‌جایی، تعداد رفت‌وبرگشت‌های ضروری و امکان انجام موازی آن‌ها را مشخص کنید.
در نمونه فرضی سفارش، ابتدا مجوز مشتری بررسی می‌شود، بعد موجودی خوانده می‌شود و سپس سفارش ثبت می‌شود. بعضی قدم‌ها به نتیجه قبلی وابسته‌اند و نمی‌توان همه را هم‌زمان آغاز کرد. اجرای این منطق کنار پایگاه داده ممکن است از اجرای کنار مرورگر مناسب‌تر باشد. برای صفحه عمومی معرفی کالا، وضعیت می‌تواند برعکس باشد. پاسخ از الگوی ارتباط می‌آید، نه یک رتبه‌بندی همیشگی محیط‌ها.
Cloudflare قابلیت Placement را برای برخی بارهای کاری ارائه می‌کند تا محل اجرا با نیاز backend هماهنگ شود. وجود چنین قابلیت‌هایی نشان می‌دهد موضوع صرفاً «هر چه نزدیک‌تر به کاربر بهتر» نیست. شرایط پشتیبانی و محدودیت سرویس را برای همان کاربرد بخوانید و جابه‌جایی خودکار را تضمین حل تمام ارتباط‌های بیرونی ندانید.
Runtime قرارداد قابلیت‌ها را تعیین می‌کند
کد Edge ممکن است در Runtime متفاوتی از سرور Node.js اجرا شود. Web APIهایی مانند Request و Response می‌توانند مشترک باشند، ولی فایل سیستم، افزونه بومی و بعضی کتابخانه‌ها شرایط دیگری دارند. شرح معماری Workers مدل isolate را توضیح می‌دهد. برنامه‌ای که به حافظه یک فرایند پایدار تکیه دارد باید این وابستگی را بازبینی کند.
فهرست نیازهای اجرای برنامه را بنویسید. آیا تبدیل تصویر به binary خارجی وابسته است؟ آیا کتابخانه PDF به امکانات سیستم‌عامل نیاز دارد؟ آیا اتصال دیتابیس با روش مورد پشتیبانی محیط برقرار می‌شود؟ اگر قابلیت لازم نیست، محدودیت آن اهمیتی برای این پروژه ندارد. اگر حیاتی است، انتقالش به سرویس جداگانه هزینه و نقطه شکست تازه ایجاد می‌کند و باید در مقایسه لحاظ شود.
در بازبینی فعلی، صفحه رسمی Edge Runtime در Vercel مهاجرت به Node.js را توصیه می‌کند و محدودیت تنظیم Edge در نسخه‌های جدید Next.js را توضیح می‌دهد. پس نام قدیمی سرویس را قرارداد امروز آن فرض نکنید. برای آشنایی با محیط‌های دیگر، مستندات Deno Deploy را با نیاز واقعی برنامه تطبیق دهید؛ نام Runtime به تنهایی شکل تمام امکانات استقرار را مشخص نمی‌کند.
Cache باید معنای پاسخ را حفظ کند
Cache نتیجه را برای استفاده دوباره نگه می‌دارد و از همین راه بخشی از کار را کم می‌کند. شرط لازم این است که پاسخ برای درخواست بعدی واقعاً معتبر باشد. زبان، پارامتر و داده کاربر ممکن است روی پاسخ اثر بگذارند. اگر کلید cache این عوامل را نبیند، پاسخ سریع ولی غلط تحویل می‌شود. حفاظت از درستی پاسخ، از کوچک‌تر کردن یک زمان اندازه‌گیری‌شده مهم‌تر است.
برای داده عمومی، عمر و روش ابطال را مشخص کنید. تغییر متن مقاله می‌تواند build یا purge لازم داشته باشد؛ تغییر قیمت ممکن است سیاست دقیق‌تری بخواهد. مسئول محتوا باید بداند تغییرش چه زمانی دیده می‌شود. اگر چند محل پاسخ دارند، ابطال باید با دامنه همان محل‌ها هماهنگ شود. نبودن یک قرارداد روشن، اختلاف نسخه محتوا در تجربه کاربر ایجاد می‌کند.
برای داده شخصی، فقط به وجود header یا Cookie اعتماد نکنید؛ دسترسی باید در سرور اعتبارسنجی شود. پاسخ مشترک نباید سفارش یا نام یک کاربر را به دیگری بدهد. اگر محصول ترکیبی از بخش عمومی و شخصی دارد، مرز آن‌ها را از ابتدا تعریف کنید. مقاله Partial Prerendering و Cache Components نمونه‌ای از همین تفکیک در سطح صفحه را توضیح می‌دهد.
Consistency روی تجربه کاربر اثر دارد
وجود چند Replica به معنی دیده شدن فوری آخرین نوشتن در همه محل‌ها نیست. مدل سرویس داده تعیین می‌کند چه تضمینی دارید. در صفحه‌ای که کاربر بلافاصله پس از ثبت، نتیجه را می‌بیند، خواندن داده قدیمی می‌تواند مثل شکست ثبت به نظر برسد. طراحی باید مسیر read-after-write و حالت انتظار را با قرارداد واقعی سرویس هماهنگ کند.
برای مثال، پس از تغییر نام حساب، می‌توانید پاسخ عمل موفق را برای نمایش موقت نتیجه استفاده کنید، ولی منبع پایدار همچنان باید درست نوشته شده باشد. این رفتار UI جای تضمین ذخیره‌سازی نیست. اگر عملیات ناموفق است، نمایش خوش‌بینانه بدون راه اصلاح، وضعیت غلط را به کاربر تحمیل می‌کند. مرز optimistic update و تأیید سرور را صریح تعریف کنید.
عملیات توزیع‌شده به گزارش قابل پیگیری نیاز دارد
وقتی درخواست در چند جزء حرکت می‌کند، یک خطای کلی کافی نیست. شناسه درخواست و ارتباط گزارش‌ها باید کمک کند مسیر را دنبال کنید. داده حساس را وارد log نکنید و سطح جزئیات را با وظیفه عیب‌یابی هماهنگ کنید. مسئول پشتیبانی باید بتواند مشکل Runtime، محدودیت سرویس و شکست backend را از هم جدا کند.
محدودیت زمان، CPU، اندازه ورودی و حافظه به نوع سرویس مربوط است. اجرای کد کوتاه روی Edge ممکن است مناسب باشد و پردازش طولانی به job جدا نیاز داشته باشد. Timeout را در هر مرز مشخص کنید تا انتظار نامحدود ظرفیت را مصرف نکند. تکرار درخواست هم باید با semantics عملیات هماهنگ شود؛ تکرار ثبت سفارش با تکرار خواندن یک فهرست تفاوت دارد.
Preview و Production را با داده و رازهای جدا نگه دارید. توزیع جهانی محیط آزمایشی نباید آن را به حساب‌های واقعی وصل کند. انتشار قابل تکرار، راه بازگشت و مشخص بودن نسخه artifact در معماری توزیع‌شده اهمیت بیشتری پیدا می‌کنند. مقاله CI/CD فرانت‌اند به ثبت همین مراحل مربوط است.
هزینه و دامنه استفاده را با هم ببینید
قیمت اجرای کد تنها بخش صورت‌حساب نیست. درخواست، انتقال داده، ذخیره‌سازی و سرویس‌های مکمل هر کدام می‌توانند هزینه داشته باشند. برآورد را با سناریوی روشن محصول و قیمت جاری انجام دهید. سناریوی فرضی را آمار واقعی معرفی نکنید. داده‌ای که میان چند سرویس جابه‌جا می‌شود ممکن است هزینه‌ای بسازد که در نمونه کوچک دیده نشده است.
برای مقایسه عملی محیط‌ها، مقاله Vercel و Cloudflare Workers بر اساس Runtime و مسیر داده ادامه مرتبطی است. انتخاب چند ارائه‌دهنده می‌تواند نیاز مشخصی را پوشش دهد، اما به مدیریت دسترسی و عیب‌یابی تازه نیاز دارد. معماری پیچیده‌تر باید فایده‌ای قابل توضیح برای همان محصول داشته باشد.
قدم بعدی، انتخاب یک درخواست نماینده و ثبت مسیر کامل آن است: کاربر، محل اجرا، داده، cache و پاسخ. مشخص کنید کدام فاصله یا کار تکراری مشکل فعلی را می‌سازد و جابه‌جایی چه چیزی را تغییر می‌دهد. پس از این کار، می‌توان یک بخش محدود را برای Edge انتخاب کرد و قرارداد بازگشت آن را نوشت. لازم نیست تمام محصول به یک شعار معماری تبدیل شود.
هنوز دیدگاهی ثبت نشده
اولین نفری باشید که نظر می‌دهد!