- PVSM.RU - https://www.pvsm.ru -
По данным TelecomDaily [1], почти 30% пользователей мобильного интернета в России ежедневно сталкиваются с проблемами при загрузке сайтов. Однако причина может быть не только в неравномерном покрытии, но и в слишком большом «весе» страницы.
Повлиять на качество соединения мы не можем, а вот помочь вебмастерам упростить наполнение сайта, сделать его легче — почему бы и нет? Так в Яндексе появилась технология Турбо-страниц: нашей контент-системе передают всё необходимое к размещению, а она преобразует эти данные в лёгкие и быстрые материалы.
Как работает эта магия? Какой путь проходят данные, прежде чем стать полноценной Турбо-страницей? Меня зовут Стас Макеев, я руковожу разработкой технологии Турбо-страниц. Сейчас попробую всё объяснить.
Но сначала — что-то вроде краткого содержания, чтобы вы не потерялись, когда начну углубляться в детали.
Ключевое преимущество системы Турбо-страниц — быстрое преобразование данных из исходной формы в окончательную: материалы новостных сайтов наиболее востребованы в первые минуты после публикации, а карточки товаров интернет-магазинов должны оперативно обновляться и всегда соответствовать актуальному статусу наличия. Второй важный параметр — надёжность: контент-система должна быть максимально стабильна, уметь переживать поломку отдельных серверов или даже целых дата-центров. И, конечно же, было важно не допустить чрезмерной нагрузки на хосты наших партнёров, подключившихся к Турбо-страницам. То есть при проектировании сервиса нужно было каким-то образом нащупать баланс между скоростью обработки данных и увеличением количества запросов.
У владельцев сайтов есть несколько способов подключиться к системе:
Контент-система складывает результаты своей работы в специальное хранилище типа «ключ-значение» (key-value-хранилище или KV-хранилище), где ключом является URL оригинального сайта, а в значении хранится контент Турбо-страницы. Как только данные попадают в это KV-хранилище, очередная Турбо-страница сразу же становится доступна пользователям поиска, а в сервисах Яндекса у соответствующего документа появляется специальный значок с ракетой. Также для ускорения работы мы кешируем картинки и видео в наших CDN.
Очень упрощенно общая схема работы выглядит так:
Самая первая версия контент-системы была устроена совсем просто: каждые несколько минут, по расписанию, на сервере внутреннего облака Яндекса запускалась одна и та же программа. Она состояла из нескольких шагов, каждый следующий запускался после того, как были готовы данные предыдущего для всех известных нам фидов:
Такая схема отлично работала, когда система имело дело с несколькими тысячами довольно лёгких RSS-фидов новостных агентств (суммарно — информация о чуть менее 100 000 документов). Но с увеличением количества фидов быстро обнаружилась проблема: каждый шаг занимал всё больше времени, росла задержка между появлением нового документа в исходном источнике и его отображением в Турбо-режиме.
Ситуацию удавалось держать под контролем с помощью различных ухищрений: первым делом мы выделили первый шаг (скачивание RSS-фидов + парсер документов) в отдельный процесс. То есть, пока один обрабатывал картинки для предыдущей итерации, другой процесс уже скачивал фиды для следующей. Через некоторое время стало понятно: в таком виде систему очень сложно масштабировать. Нам нужно что-то принципиально новое.
Главная проблема старой контент-системы — все данные обрабатывались одним куском: перехода к следующему шагу не происходило, пока каждый документ не прошёл предыдущий. Чтобы избавиться от этого, было решено построить некий конвейер: пусть фиды и отдельные документы обрабатываются максимально независимо друг от друга. Все шаги выделили в отдельные кубики-сервисы — на верхнем уровне схема получилась такая:
Одни и те же фиды могут быть зарегистрированы не только в Турбо, но и на других наших сервисах — в Новостях или в Маркете, например. Если каждый из них будет скачивать данные самостоятельно, нагрузка на сервера вебмастеров в несколько раз превысит допустимую. Как правильно? Скачать фид один раз, а затем содержимое раздать всем сервисам-потребителям — этим занимается Яндекс.Робот. Его же услугами мы пользуемся для выгрузки контента: забираем из Яндекс.Вебмастера список зарегистрированных в Турбо RSS- и YML-фидов, передаем его в Робота и подписываемся на результаты скачивания.
На полученных данных запускаем парсер. На всякий случай напомню: RSS-фид — просто файл в формате «.XML», доступный по статическому URL на хосте партнера. В этом файле расположена информация обо всех обновлениях на сайте — какие документы новые, какие измененные. В идеальных фидах находилась бы только самая актуальная информация за последние несколько часов: не более 100 документов на несколько сотен килобайт.
Реальность кусается: иногда файлы находятся внутри фида очень долго и никогда не меняются. Как избежать повторной обработки в таких случаях? Вычисляем хеш каждого документа, запоминаем его в базу данных, и ничего не предпринимаем, пока хеш не изменится.
Обработка YML-фидов и API с точки зрения контент-системы практически ничем не отличается от взаимодействия с RSS: для YML запускаем другой парсер, а данные, переданные через API, получаем напрямую из Яндекс.Вебмастера.
Документ, который получается на выходе из парсера, практически готов для записи в KV-хранилище. Единственное, что осталось сделать перед отправкой — обработать изображения и видео: закешировать в CDN и заменить ссылки в документе. Тут снова обращаемся за помощью к Роботу.
Первым делом проверяем каждую картинку и видео: есть ли они в CDN? Если все уже закешировано, заменяем ссылки и обновленный документ отправляем в KV-хранилище. В противном случае:
Другой кубик в это время получает результаты скачивания, заливает данные в CDN и обновляет базу данных.
В такой схеме удается решить ещё одну важную проблему, связанную с планированием: Робот понимает, с какой скоростью можно качать данные с разных хостов, и не допускает перегрузок.
Типичный путь, который проходит новый документ:
Есть ещё один способ подключения к Турбо-страницам, для которого вебмастеру практически ничего не нужно делать — Автопарсер. Он строит Турбо-страницы на основании исходных данных контентного сайта. Подключиться, посмотреть примеры готовых страниц, настроить рекламу и аналитику можно в Яндекс.Вебмастере.
Основная сложность, с которой сталкивается Автопарсер — распознать по HTML-разметке, какая информация основная и должна быть использована при построении Турбо-страницы. Для этого у нас есть несколько оффлайн-процессов, которые пытаются понять, как именно нужно парсить конкретный хост. Остановлюсь на двух основных:
Кстати, ещё одно частое препятствие — многие сайты закрывают в robots.txt возможность скачивания картинок роботами. Обойти эту проблему, к сожалению, невозможно, и для таких страниц Автопарсер недоступен.
В итоге полная схема контент-системы выглядит вот так:
Система получилась хорошо масштабируемой: уже сейчас для обслуживания базы данных, автопарсера и других компонентов системы используется значительное количество ресурсов (только в кубике, отвечающем за парсинг RSS, YML и API, задействовано более 300 процессорных ядер), а в случае роста нагрузки подключить дополнительные мощности будет не слишком сложно.
Спасибо, что дочитали до конца! Надеюсь, после этого материала, в работе Турбо-страниц для вас станет больше логики и меньше магии (кстати, вот тут [2] — ещё больше подробностей о Турбо-страницах). Если что-то всё же осталось непонятным, пишите в комментариях — мы на связи.
Автор: Станислав Макеев
Источник [3]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/yandeks/351301
Ссылки в тексте:
[1] TelecomDaily: https://www.kommersant.ru/doc/4148482
[2] вот тут: https://habr.com/ru/company/yandex/blog/460373/
[3] Источник: https://habr.com/ru/post/494824/?utm_source=habrahabr&utm_medium=rss&utm_campaign=494824
Нажмите здесь для печати.