مع فلسفة Discourses 1RTT، أعتقد أنه قد يكون الوقت قد حان لإعادة كتابة كود خدمة صور الأفاتار.
يجب التعامل مع صور الأفاتار مثل أي تحميل صورة آخر. يتم تغيير حجمها عند التحميل، وتخزينها، وتقديمها مباشرة من نظام الملفات/S3/CDN.
تستخدم طريقة Discourse الحالية طريقة وكيل لتقديم صور الأفاتار. يخلق هذا النهج رحلات ذهاب وإياب HTTP غير ضرورية وتحديات في عناوين IP.
إليك نظرة عامة على طلبات الأفاتار:
يتم رسم HTML الأولي لـ Discourse.
يكتشف المتصفح صورة أفاتار ويطلب صورة من خادم Discourse
يعمل خادم Discourse كوكيل ويطلب الصورة من مخزن الملفات المحلي/S3/CDN
يتلقى خادم Discourse الصورة
يرسل خادم Discourse الصورة إلى المتصفح.
كل أفاتار مخصص لديه رحلة ذهاب وإياب HTTP إضافية ووقت معالجة خادم متعلق بها. يمكن أن يحتوي الموضوع النموذجي أو قائمة المواضيع على أكثر من 30 صورة أفاتار مخصصة. في موقعي، ينتج عن ذلك 10 آلاف إلى 20 ألف رحلة ذهاب وإياب إضافية وحمل خادم متعلق بها يوميًا يمكن تجنبها.
بالإضافة إلى ذلك، يتم استدعاء صور الأفاتار مباشرة من الخادم. للقيام بأي حماية على مستوى CDN، يتطلب ذلك إضافة عنوان IP إلى القائمة البيضاء. يتطلب هذا إضافة البوابات إلى القائمة البيضاء بدلاً من عناوين IP للخوادم. تقوم شركات الاستضافة بإجراء تغييرات لموازنة حركة مرور الشبكة بانتظام. سيتغير/يتطور عنوان IP للبوابة الخاص بي. لا ينبغي أن يعتمد البرنامج على تحديث عنوان IP لكي تعمل صور الأفاتار الأساسية. يعتمد هذا على الحادث التالي في الدعم، Avatar Proxy and CDN Hot-Link Protection
من منظور الأداء والبساطة، هل يمكن تقديم صور الأفاتار مباشرة من مخزن الملفات المخصص لـ Discourse؟
لمعالجة بعض أوجه القصور فيه، قمنا مؤخرًا بتطوير طريقة لتقليل تلك الرحلات ذهابًا وإيابًا في الاستضافة لدينا، لكنني لا أعتقد أننا وثقناها هنا أبدًا. هل هناك أي وثائق عامة حول هذا الموضوع @david؟
نعم، لدينا هذا الإعداد العام GlobalSetting، والذي يمكنك تمكينه عن طريق تعيين متغير البيئة DISCOURSE_REDIRECT_AVATAR_REQUESTS=true
بعد ذلك، بدلاً من الوكالة (proxying)، سيتم تقديم طلبات الصور الرمزية (avatar) مع إعادة توجيه 302 إلى مخزن الملفات.
بحد ذاته… هذه ليست فكرة جيدة حقًا. هذا يعني أن المتصفحات يجب أن تقوم برحلتين ذهابًا وإيابًا كاملتين عبر HTTP لكل صورة رمزية. لذلك، في حين أنها قد تحل مشكلة “الحماية من الربط المباشر” لديك… لا أوصي بتمكينها. ستجعل التجربة أسوأ لمستخدميك.
نحن نستخدم الإعداد في استضافة discourse.org الخاصة بنا. لكننا ندعمها بدالة (lambda) تعمل على شبكة توصيل المحتوى (CDN) Cloudfront الخاصة بنا. تكتشف إعادة التوجيه 302 وتقوم بالوكالة بنفسها. في الأساس: ننقل الوكالة من خوادمنا التطبيقية إلى شبكة توصيل المحتوى.
أما بالنسبة للسؤال الأكثر عمومية “هل يمكننا تغيير الصور الرمزية للربط مباشرة بالأصل (asset)”؟ الأمر معقد لأن عناوين URL للصور الرمزية مضمنة في جميع المشاركات التاريخية (مثل الاقتباسات). تسمح لنا عناوين URL الديناميكية /user-avatar/ بالحفاظ على عمل هذه المشاركات عندما يغير المستخدم صورته الرمزية. أخشى أنه ليس لدينا أي خطط لتغيير هذا النظام.
إذا كانت هناك طريقة سهلة ومنخفضة المخاطر يمكننا من خلالها جعل الوكالة الحالية تعمل لحالة الاستخدام الخاصة بك (على سبيل المثال، إضافة إعداد عام GlobalSetting يدرج رأس HTTP محددًا في أي طلبات وكالة للصور الرمزية)، فيمكننا النظر في قبول طلب سحب (PR) لهذا التغيير.
لا تعتبر أي من الخيارات المذكورة أعلاه قابلة للتنفيذ أو مفضلة في بيئتي الحالية. أود أن أساعد في حل هذه المشكلة المعقدة في التطبيق، لكنني جديد جدًا في هذا النطاق التكنولوجي.
والمساعدة الوحيدة التي يمكنني تقديمها الآن هي باستخدام مهاراتي القديمة في إدارة الأعمال وإدارة التطوير. لذلك، وفي روح الشعور أنني أساعد، إليك أفكاري.
عندما أنظر إلى أي لغز تقني، أبدأ دائمًا بالنظر في الافتراضات المحتملة التي قد تجعل الحل أكثر صعوبة.
واحد من الافتراضات هو حفظ صورة الأفاتار المحدثة كاسم ملف جديد. الشخص لديه أفاتار واحد فقط. نحن لا نحتفظ بسجلات أسماء الأفاتارات. أقترح أنه عندما يقوم الشخص بتحديث صورة أفاتاره، يتم حفظها باستخدام نفس اسم الملف الخاص بالأفاتار الحالي. هذا هو ما تفعله بشكل أساسي رابط /user-avatar/. بدلاً من وجود حيلة، قم بتنفيذ هذه المنطق أثناء إنشاء أو تحديث الأفاتار. هذا سيحل مشاكل المشاركات التاريخية من أجل المنشورات المخبوزة مستقبلاً.
هل هذا تغيير شامل؟ لا، يمكن تنفيذ هذا التغيير على مدى شهور، مع تحسين أداء الموقع تدريجيًا. كانت فرق التطوير لدي دائماً قائمة بالكود الفرصة لكل قطعة كود. كنا نرغب في إجراء هذه التحسينات، لكنها لم تكن ضرورية بشكل فردي. عندما كان يُفتح الكود للتطوير لسبب آخر، كان المطور يجري أيضًا تغييرات فرصية. هذا قلل من اختباراتنا وأخطائنا من خلال تقليل مرات فتح وتحديث الكود.
سأقسم هذا المشروع إلى المراحل التالية:
تحديث منطق حفظ صورة الأفاتار لاستبدال أي تحديثات صورة باستخدام اسم الملف الحالي.
استبدال جميع استخدامات صور الأفاتار بوظيفة قياسية تستخدم نظام تخزين/توصيل الملفات المفضل لـ discourse. يمكن تنفيذ هذه على مدى شهور، تدريجيًا مع التحول إلى منطق عرض صورة الأفاتار الجديد.
بمجرد اكتمال المرحلتين الأوليين، تزويد المجتمع بالخطوات ولقطات الكود لتغيير وإعادة خبز صور الأفاتار التاريخية في HTML المخبوز حسب نظام الملفات المفضل لديهم. هذا سيكون خيارًا لمالكي مواقع discourse لتنفيذه. (سيكون من المفيد لوثائق الكود ولقطاته لتنفيذ تغييرات HTML الخام)
أنا متأكد أنك فكرت في كل هذا. وأعلم أيضًا أن تصحيح الكود الأقدم لا يحتل دائمًا قائمة الأولويات.
إذا كان هناك أي شيء يمكنني فعله للمساعدة في هذا الجهد، يرجى إعلامي.
ملاحظة: أقدر عرض إعداد رأس عالمي، دعني أبحث أكثر وأتابع بمزيد من المتطلبات المحددة. شكراً لمساعدتك.
للأسف، إذا كان الملف قابلاً للتغيير، فهذا يعني أنه لم يعد بإمكاننا تمكين التخزين المؤقت اللانهائي للمورد في شبكة توصيل المحتوى (CDN) ومتصفحات المستخدم النهائي.
هناك استراتيجيات لجعل شيء كهذا يعمل دون التأثير بشكل كبير على الأداء… على سبيل المثال، التوجيه stale-while-revalidate. ولكن هذا يأتي بتكاليفه الخاصة وتداعياته على تجربة المستخدم.