يحتاج التسليم الأمامي في عصر النشر عالي التردد إلى إعادة تصميم التخزين المؤقت والتعاون في الضغط

بمجرد دخول موارد الواجهة الأمامية إلى إيقاع إصدار عالي التردد، لن تكون مشكلات الأداء قريبًا بسيطة مثل “تشغيل Brotli”. تتباطأ الشاشة الأولى، وتزداد حركة العودة إلى الأصل، وتؤدي إلى اهتزاز وحدة المعالجة المركزية لعقدة الحافة. على السطح، يبدو أن الضغط ليس قويا بما فيه الكفاية. إذا نظرنا بشكل أعمق، غالبًا ما يتم تحسين التخزين المؤقت والضغط بشكل منفصل، وفي النهاية يقوض كل منهما الآخر على رابط النشر.

بشكل عام، لم يتم الكشف عن هذا النوع من المشاكل في الإصدار الأول. في البداية، لم يرى الفريق سوى بعض الإشارات المتناثرة: تغيير بسيط تسبب في انهيار معدل ضرب الموارد الثابتة، وزيادة غير طبيعية في وحدة المعالجة المركزية لضغط الحافة عشية عرض ترويجي كبير، وحجم حزمة الإرجاع في مرحلة التدرج الرمادي لم يتطابق مع حركة المرور الرسمية. إذا واصلت التحقق، فعادة ما تتقارب القرائن في نفس الشيء: على الرغم من أن محتوى المورد قد تغير قليلاً فقط، أصبح مفتاح ذاكرة التخزين المؤقت وتقسيم القطعة والإدخال المضغوط مجموعة مختلفة من الأشياء، وتضطر طبقة النقل إلى ابتلاع التكلفة بأكملها مرة أخرى.

حتى تصبح تجزئة المورد مستقرة، فإن فوائد الضغط لا يمكن الدفاع عنها ببساطة.

بعد إصدار مشاريع الواجهة الأمامية بالتوازي مع صفحات متعددة ومسارات متعددة وفرق متعددة، فإن الجانب الأكثر سهولة الذي يتم تجاهله هو استقرار اسم الملف. طالما أن تجزئة القطعة تنحرف قليلاً، حتى لو كان رمز العمل يغير فقط نسخة الزر، فقد يقوم المنتج النهائي أيضًا بإعادة كتابة تجزئة سلسلة من الحزم العامة. ما يراه نظام التخزين المؤقت هو مجموعة من الكائنات الجديدة تمامًا، وما يراه نظام الضغط هو مجموعة من المدخلات التي تظهر لأول مرة.

في هذا الوقت، بغض النظر عن مدى ارتفاع معدل الضغط، لا يمكن حفظ معدل الضرب من الانهيار. لا تزال الملفات القديمة موجودة في عقد الحافة، وتمت إعادة إدخال الملفات الجديدة؛ ذاكرة التخزين المؤقت المحلية للمتصفح غير صالحة تمامًا، ويجب على شبكة CDN إعادة سحب المصدر وإعادة ضغطه وإعادة توزيعه. يتم تضخيم تغيير الأعمال الصغيرة إلى عمل متكرر لرابط النقل بأكمله.

الإجراء المفيد حقًا ليس عادةً الاستمرار في ضبط مستوى الضغط، بل التحكم أولاً في استقرار المنتج الذي تم إصداره:

• يتم تقسيم التبعيات العامة إلى طبقات منفصلة لتقليل تغييرات الأعمال وتجميع الحزم الأساسية معًا لتغيير التجزئة.
• تجنب خلط التغييرات عالية التردد مثل الطوابع الزمنية وأرقام الإنشاء مباشرة في محتوى المنتج
• دع الكود القريب من نفس المسار ينقسم إلى أجزاء مستقرة قدر الإمكان بدلاً من تعديله في كل مرة يتم تجميعه فيها.

فقط عندما يتم تثبيت هوية المورد، يمكن إعادة استخدام ذاكرة التخزين المؤقت بشكل مستمر وتكون لنتائج الضغط قيمة تراكمية.

مؤتمر صحفي عالي التردد يعيد كتابة مشكلة الضغط إلى مشكلة إصدار القاموس

مع تزايد تجزئة الموارد، لا يزال الملف الفردي Brotli أو gzip مهمًا، لكنه لم يعد كل شيء. تبدأ التكلفة الحقيقية في التحول نحو الأجزاء المكررة: كود وقت تشغيل الإطار، وقوالب الأنماط، وإعلانات نوع الواجهة، وطبقات التغليف التي تم إنشاؤها بواسطة المحزمين، غالبًا ما تكون متشابهة إلى حد كبير بين مجموعات الإصدارات. مع إيقاع الإصدار السريع، سيتم نقل هذه المقطوعات الموسيقية مرارًا وتكرارًا.

المشكلة هي أن قاموس الضغط يمكن أن يتحول بسهولة من التحسين إلى التعطيل إذا لم تتم إدارته مع إيقاع الإصدار. إذا تم تبديل القاموس مسبقًا، فسيكون القاموس الجديد المشار إليه في الصفحة القديمة غير متطابق؛ يتم تقطيع القاموس إلى أجزاء كثيرة جدًا، ويزداد بشكل حاد عدد الإصدارات التي يجب الحفاظ عليها بواسطة العقد الطرفية؛ لا تتم مزامنة تحديث القاموس مع المورد عبر الإنترنت، ويتم إرجاع الكائنات التي كان من المفترض أن يتم ضربها إلى الإرسال الكامل.

يعد هذا أيضًا تغييرًا عمليًا جدًا في التسليم الأمامي الحديث: لم يعد من الممكن الحفاظ على استراتيجيات التخزين المؤقت وبروتوكولات الضغط بواسطة فرق مختلفة. تعد إصدارات الموارد وإصدارات القاموس ومساحات مفاتيح ذاكرة التخزين المؤقت هي نفس مشكلة النشر بشكل أساسي.

عادةً ما يكون النهج الهرمي مثل ما يلي أكثر استقرارًا من “الضغط القوي الموحد للموقع بأكمله”:

const policy = {
  immutableAssets: 'public, max-age=31536000, immutable',
  releaseManifest: 'public, max-age=60, stale-while-revalidate=30',
  sharedDictionary: 'versioned-by-release-train'
}

المفتاح ليس تكوين هذه الأسطر الثلاثة نفسها، ولكن القيود التي تعبر عنها: موارد دورة الحياة الطويلة، وقائمة دورة الحياة القصيرة، ونسخة القاموس المضغوطة يجب أن تتطور معًا وفقًا لنفس إيقاع الإصدار.

غالبًا ما لا يكون ضغط العودة إلى المصدر هو أن الملف كبير جدًا، ولكن طريقة الفشل قاسية جدًا.

هناك خطأ آخر شائع جدًا وهو إرجاع الزيادة في عرض النطاق الترددي مباشرة إلى وزن الصفحة. من المؤكد أن الصفحات تزداد ثقلًا، ولكن المضخمات الأكثر خطورة عبر الإنترنت هي عادةً ما تكون هي الحل الأمثل.

إذا قمت بالتطهير حسب الدليل أو البادئة أو حتى الموقع بأكمله في كل مرة تقوم فيها بالنشر، فستفقد طبقة ذاكرة التخزين المؤقت ذاكرتها على الفور. في هذا الوقت، حتى لو لم يستمر حجم الملف في النمو، فسيتم رفع قيمة ذروة العودة إلى الأصل من تلقاء نفسها. بمجرد إرجاع المصدر، تتم إعادة ضغط الحواف، ويتم إعادة تدفئة الكائنات، ويتم إعادة تنزيل المتصفح. ستتغير نافذة النشر من تغيير بسيط إلى نقل كامل للموقع.

في هذا النوع من السيناريوهات، الشيء الأكثر قيمة هو نصف قطر الفشل الذي يمكن التحكم فيه:

• فقط إبطال البيان وHTML والموارد القابلة للتغيير التي تغيرت بالفعل
• حاول عدم إزالة الملفات الثابتة بالتجزئة، وقم بتسليمها إلى مراجع جديدة للتبديل الطبيعي.
• قم بتقسيم الإصدار إلى ترتيب “قم أولاً بتحميل موارد جديدة، ثم قطع المراجع، ثم قم بإعادة تدوير الموارد القديمة” بدلاً من مسحها كلها مرة واحدة

الأمر الحساس حقًا بشأن تكلفة النقل ليس فقط حجم الملف، ولكن أيضًا كيفية تحديد النظام للمحتوى الذي يجب إعادة جلبه.

يتم تحديد الحدود المطبقة مع حجم الموارد وتكرار الإصدار.

هذه المجموعة من التصميم المشترك ليست مطلوبة لجميع المواقع. بالنسبة للمشاريع التي تحتوي على عدد صغير من الصفحات الثابتة، وحزمة موارد صغيرة، وتكرار الإصدار أسبوعيًا أو حتى شهريًا، فإن استخدام أسماء ملفات التجزئة التقليدية بالإضافة إلى الضغط المسبق لـ Brotli عادةً ما يكون مستقرًا بدرجة كافية.

وسرعان ما يصبح التخزين المؤقت والضغط معًا بنية أساسية للتسليم بمجرد توفر هذه الخصائص:

• يتم إصداره عدة مرات يوميًا، مع تدرج رمادي أو تراجع أو إطلاق إقليمي
• منتج الواجهة الأمامية كبير الحجم، وله العديد من التبعيات العامة، وله علاقات قطعية معقدة.
• تشارك CDN وتخزين الكائنات وضغط الحافة والتخزين المؤقت للمتصفح في وقت واحد في رابط النقل
• حركة المرور عالية جدًا بحيث يعكس معدل وصول ذاكرة التخزين المؤقت وقيمة الذروة للعودة إلى الأصل التكلفة والاستقرار بشكل مباشر.

بعد دخول التسليم الأمامي إلى هذه المرحلة، لم يعد الضغط مجرد “تصغير حجم الملفات”، ولم يعد التخزين المؤقت مجرد “تخزين المزيد من نسخ المحتوى”. ما يقرره الاثنان معًا هو: بالنسبة لتغيير الأعمال الصغيرة، سواء كان ذلك مجرد إرسال قطعة أخرى، أو ما إذا كان رابط النقل بأكمله يحتاج إلى التشغيل مرة أخرى. كلما قمت بالنشر بشكل متكرر، أصبح هذا الاختلاف أكثر تكلفة.