Get best of the week

كيفية ترتيب نظام محتوى صفحات Turbo: المخططات والحقائق وقليل من التاريخ



وفقًا لـ TelecomDaily ، يعاني ما يقرب من 30 ٪ من مستخدمي الإنترنت عبر الهاتف المحمول في روسيا يوميًا من مشاكل في تنزيل المواقع. ومع ذلك ، قد لا يكون السبب في التغطية غير المتساوية فحسب ، بل أيضًا في "وزن" الصفحة.

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

كيف يعمل هذا السحر؟ ما هو مسار البيانات قبل أن تصبح صفحة Turbo كاملة؟ اسمي Stas Makeev ، وأقود تطوير صفحات تكنولوجيا Turbo. الآن سأحاول شرح كل شيء.

لكن أولاً ، إنه جزء من ملخص حتى لا تضيع عندما أبدأ في الخوض في التفاصيل.

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

يمتلك مالكو المواقع عدة طرق للاتصال بالنظام:

  • . : YML — -, RSS – ;
  • API: ( );
  • : - .

يقوم نظام المحتوى بتخزين نتائج عمله في مخزن خاص من نوع "القيمة الرئيسية" (تخزين قيمة المفتاح أو تخزين KV) ، حيث يكون المفتاح هو عنوان URL للموقع الأصلي ، وتخزين القيمة محتوى صفحة Turbo. بمجرد أن تدخل البيانات هذا التخزين KV ، تصبح صفحة Turbo التالية متاحة على الفور للبحث عن المستخدمين ، وفي خدمات Yandex ، يحتوي المستند المقابل على رمز خاص مع صاروخ. أيضًا ، لتسريع العمل ، نقوم بالتخزين المؤقت للصور ومقاطع الفيديو في شبكات CDN الخاصة بنا.

يبدو مخطط العمل العام المبسط للغاية كما يلي:



كيف بدأ كل شيء


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

  • تم تنزيل قائمة موجزات RSS ، وتم إطلاق محلل المستندات ؛
  • تم استخراج قائمة الصور من نتائج المحلل ؛
  • لم يتم تحميل الصور غير المخزنة في CDN بعد ؛
  • تم سكب الوثائق المجهزة في مستودع KV.

عمل مثل هذا المخطط بشكل مثالي عندما تعامل النظام مع عدة آلاف من موجزات RSS الخفيفة إلى حد ما لوكالات الأنباء (في المجموع - معلومات حول أقل من 100000 مستند). ولكن مع زيادة عدد الخلاصات ، تم اكتشاف مشكلة بسرعة: استغرق كل خطوة المزيد والمزيد من الوقت ، وزاد التأخير بين ظهور مستند جديد في المصدر الأصلي وعرضه في وضع Turbo.

تمكنا من إبقاء الوضع تحت السيطرة بمساعدة الحيل المختلفة: أول شيء فعلناه هو تحديد الخطوة الأولى (تنزيل قنوات RSS + محلل المستندات) في عملية منفصلة. بمعنى ، بينما كان أحدهما يعالج الصور للتكرار السابق ، كانت العملية الأخرى تقوم بالفعل بتنزيل خلاصات للخطوة التالية. بعد مرور بعض الوقت ، أصبح من الواضح: في هذا الشكل ، من الصعب جدًا قياس النظام. نحن بحاجة إلى شيء جديد بشكل أساسي.

معالجة RSS و API و YML في نظام المحتوى الجديد


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



  • يقوم المكعب الأول بتنزيل تغذيات RSS ويمررها ؛
  • والثاني - يأخذ يغذي واحدا تلو الآخر ، ويوزع المحتويات. عند الخروج - وثائق منفصلة ؛
  • الثالث - يأخذ المستندات واحدًا تلو الآخر ، ويعالج الصور ومقاطع الفيديو ، ويسجل كل شيء في وحدة تخزين KV.

يمكن تسجيل نفس الخلاصات ليس فقط في Turbo ، ولكن أيضًا في خدماتنا الأخرى - في الأخبار أو في السوق ، على سبيل المثال. إذا قام كل منهم بتنزيل البيانات من تلقاء نفسه ، فسيكون التحميل على خادم مشرفي المواقع أعلى عدة مرات من التحميل المسموح به. كيف الحق؟ قم بتنزيل الموجز مرة واحدة ، ثم قم بتوزيع المحتوى على جميع خدمات المستهلك - تقوم Yandex.Robot بذلك. نستخدم خدماته لتنزيل المحتوى: نأخذ من Yandex.Webmaster قائمة بخلاصات RSS و YML المسجلة في Turbo ، وننقلها إلى Robot واشترك في نتائج التنزيل.

على البيانات المستلمة ، ابدأ المحلل اللغوي. في هذه الحالة فقط ، دعني أذكرك: موجز RSS هو مجرد ملف بتنسيق ".XML" ، يمكن الوصول إليه عن طريق عنوان URL ثابت على مضيف الشريك. يحتوي هذا الملف على معلومات حول جميع التحديثات على الموقع - أي المستندات جديدة ، والتي تم تغييرها. ستكون أحدث المعلومات فقط في الساعات القليلة الماضية في خلاصات مثالية: لا يزيد عن 100 مستند لكل مئات الكيلوبايت.

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

لا تختلف معالجة خلاصات YML وواجهات برمجة التطبيقات من وجهة نظر نظام المحتوى عمليًا عن التفاعل مع RSS: بالنسبة إلى YML ، نبدأ محللًا آخر ، ويتم الحصول على البيانات المرسلة من خلال واجهة برمجة التطبيقات مباشرة من Yandex.Webmaster.



معالجة الصور والفيديو


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

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

  • نرسل قائمة عناوين URL المفقودة إلى الروبوت للتخطيط والتنزيل ؛
  • المستند نفسه في التخزين المؤقت ، لذا حاول بعد فترة التحقق منه مرة أخرى.

يتلقى مكعب آخر في هذا الوقت نتائج التنزيل ، ويحمل البيانات إلى شبكة CDN ويقوم بتحديث قاعدة البيانات.

في مثل هذا المخطط ، يمكن حل مشكلة مهمة أخرى تتعلق بالتخطيط: يفهم الروبوت مدى السرعة التي يمكن بها تنزيل البيانات من مضيفين مختلفين ، ولا يسمح بزيادة التحميل.



المسار النموذجي الذي يتبعه مستند جديد:

  • يظهر المستند في موجز ويب.
  • يقوم الروبوت بتنزيل الخلاصة ؛
  • يكتشف المحلل المستند الجديد ويرسله أكثر ؛
  • نتحقق من أن الصور من المستند غير مذكورة في قاعدة البيانات ، نطلب التنزيل ، يتم إرسال المستند إلى التخزين المؤقت (تأخير). أثناء وجود المستند ، يقوم الروبوت بتنزيل الصور ، ويتم تخزينها مؤقتًا في شبكة CDN ، وتظهر الروابط في قاعدة البيانات ؛
  • , CDN, KV-.
  • : , Delay.


هناك طريقة أخرى للاتصال بصفحات Turbo ، والتي لا يحتاج مسؤول الموقع للقيام بأي شيء - Autoparser. يقوم ببناء صفحات Turbo بناءً على البيانات المصدر لموقع المحتوى. يمكنك الاتصال والاطلاع على أمثلة للصفحات النهائية وتكوين الإعلانات والتحليلات في Yandex.Webmaster.

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

  • الأول RSS- HTML- . — , RSS- ( ), . , . CatBoost , , . , , , . , . , , , HTML . ? : . – , .
  • : .. , , , , — . — .

بالمناسبة ، هناك عقبة واحدة أكثر تكرارًا - تمنع العديد من المواقع إمكانية تنزيل الصور بواسطة برامج الروبوت في ملف robots.txt. لسوء الحظ ، من المستحيل تجاوز هذه المشكلة ، ولا يتوفر Autoparser لمثل هذه الصفحات.

نتيجة لذلك ، يبدو المخطط الكامل لنظام المحتوى كما يلي:



تبين أن النظام قابل للتطوير بشكل جيد: الآن يتم استخدام كمية كبيرة من الموارد لخدمة قاعدة البيانات والمحرر التلقائي والمكونات الأخرى للنظام (فقط المكعب المسؤول عن تحليل RSS و YML و API يستخدم أكثر من 300 معالج النوى) ، وفي حالة زيادة الحمل ، لن يكون من الصعب جدًا توصيل السعات الإضافية.

شكرا لقراءتك حتى النهاية! آمل ، بعد هذه المادة ، في عمل صفحات Turbo ، ستحصل على منطق أكثر وسحر أقل (بالمناسبة ، هنا- مزيد من التفاصيل حول صفحات Turbo). إذا كان هناك شيء لا يزال غير مفهوم ، فاكتب في التعليقات - نحن على اتصال.

More articles:


All Articles