31 августа 2013 года в Минске прошел Я.Субботник, в ходе которого сотрудники минского, московского, питерского и симферопольского офисов Яндекса делились своим опытом. Для тех, кто не присутствовал на конференции, была организована онлайн-трансляция и трансляция в Твиттере по хэштегу #yasubbotnik.

Открыл мероприятие Алексей Сикорский, руководитель офиса разработки в Минске, который рассказал, что интересного произошло за последний год.

По словам докладчика, в этом году Яндекс усиленно развивал направления «Поиск» и «Карты», были запущены новые направления — мобильная разработка, разработка браузера, функциональное тестирование, автоматизация тестирования.Также, в этом году был первый выпуск Школы анализа данных (ШАД, совместный образовательный проект с БГУ), первые 12 человек выпустились, закончив двухлетний проект. Набрали следующий курс — еще 29 студентов.

Александр рассказал о контент-системе, или поисковом роботе — части поиска, отвечающей за подготовку данных, то есть, за скачивание контента из интернета и обновления на его основании поисковой базы.

Контент представляется не только классическими «синими» или «фиолетовыми» ссылками, но и «по-богатому», в виде rich preview.

Предоставляется API для создание таких превью.

Превью состоит из заголовка, характерной картинки документа и краткой текстовой аннотации.

Проект начинался с разработки прототипа, на котором обкатывались алгоритмы построения превью. В определенный момент было принято решение перевести его на поисковые сервисы, чтобы задействовать всю мощь инфраструктуры.

Rich Content API можно использовать на форумах, в соцсетях, на блог-платформах, в мессенджерах, браузерах, сервисах укорачивания урлов и других местах, где фигурируют ссылки.

Про реализацию Rich Content API на базе робота.

Сервисы, которые есть в контент-системе:

1. Фетчер (качалка). Сервис занимается тем, что скачивает документы из интернета с соблюдением политик обхода, кэширует их и выполняет некоторую предварительную обработку.

2. База данных. Предоставляет возможность по хранению документов и многочисленных дополнительных данных о документах и не только, является платформой для вычислений — в ней можно реализовывать обработчики документов. Также база данных выступает в качестве «большого» кэша фетчера, предоставлятеся доступ по ключу (realtime) и, в случае, когда нужно обойти всю или почти всю базу, это можно сделать при помощи batch-режима.

3. Sita. В этом сервисе реализуются частые пользовательские сценарии поверх других сервисов, возможно комбинирование сценариев. Сервис допускает различные интерфейсы доступа к данным и сценариям и кэширование. Общим для всех сервисов является отказоустойчивость, масштабируемость и возможность передачи данных в формате Google Protocol Buffers.

Один из частых и востребованных сценариев, которые реализуются в Sita — удлинение урлов (http://clck.ru/LiHj — Sita — http://yandex.by — http://www.yandex.by).

Удлинение урлов в Sita происходит так: сначала ищется урл в базе данных («большой» кэш). Если урла нет в базе — то он скачивается. При этом, происходит квотирование пользователей, чтобы ограничить максимально возможную нагрузку, ограничить максимальное возможное количество вызовов этого сценария. Другой аспект сервиса Sita — он предоставляет различные интерфейсы доступа к сценариям и данным. Интероперабельность — это способность систем общаться друг с другом, поскольку роботные сервисы предоставляют один и тот же протокол предоставления данных, а именно — Protocol Buffers. Это важно в случае использования HTTP API на базе JSON. Ключ согласованности — в автоматической генерации одного интерфейса из другого. 


Rich Content API с помощью роботных сервисов реализован следующим образом. Для начала алгоритмы построения превью переведены на базу данных, на вычислительную платформу. После этого был реализова сценарий построения превью в Sita с вызовом нужных обработчиков, с запрашиванием необходимых данных. Этот сценарий был скомбинирован со сценарием удлинения урлов, и получился профит в виде отказоустойчивости, масштабируемости, скорости работы. Скорость построения превью увеличилась раза в два.

Rich Content API сейчас находится в состоянии бэты, но его уже можно видеть по ссылке http://api.yandex.com/rca.

Ангелина рассказала, как делался фронтенд. Была большая цельная библиотека блоков, которая называлась LEGO. Эта библиотека является внутренним сервисом, то есть, предназначена для внутреннего пользования. Используется практически на всем портале и на всех сервисах. Была сделана по методологии и в терминах БЭМ, и сделана для того, чтобы сократить время на разработку фронтендов.

Есть общепортально одна библиотека, в которой реализованы общие блоки для того, чтобы каждому сервису не нужно было эти блоки делать заново. За счет этого было обеспечено единообразие всего портала. Не всем сервисам это было удобно. Если у сервиса использовалось несколько блоков, и он хотел получить обновление только одного из этих блоков, то получал он все обновления, и на своем уровне ему приходилось все это переопределять.

Было решено сделать из одной цельной много маленьких библиотек. Было выделено несколько блоков, которые по смысловым своим назначениям относятся к какому-то направлению.

Есть блоки, которые могут относиться к странице в целом, не важно, какой это сервис — блоки в виде шапки, логотипа.

Выделены блоки, которые относятся к идентификации сервиса, например, иконка, его название, урл, на который он ведет.

В итоге, библиотека выглядит так: на каждой «полочке» отдельные смысловые блоки.

Получилось разбить все, что есть, на новом островном дизайне, по смысловым библиотекам.

Целями этого дробления были — автономное обновление, независимая разработка и отсутствие лишнего кода.

Следующим шагом было вынесение в opensource и деление по платформам.

Негласно выделено три платформы, для которых ведется разработка: десктопные браузеры, планшеты и телефоны.

Для десктопной платформы:

Для планшетной платформы:

Для телефонной платформы:

Каждой платформе отдается только то, что нужно именно ей.

Дальше была сделана мета-библиотека, которая является стабильным состоянием всех библиотек. Был сделан срез версий библиотек, тестирование связки библиотек, и установлено стабильное состояние с определенными версиями.

Антон рассказал о об облачной платформе Cocaine и об ее отличиях от других облачных платформ. Ее главное отличие состоит в том, что она опенсорсная. Система спроектирована как модульная.

Платформа большая, состоит из многих частей с разными задачами. Бывают утилитарные задачи, такие, как хранение кода приложения. Есть плагин, который по умолчанию отвечает за хранение кода. Предоставляется «из коробки» хранение на файловой системе, куда можно залить ноду. Для серьезных облаков, когда речь идет о сотнях и более машин, предоставляется плагин для elliptics.

При попытке интегрировать рабочую среду в другую часто возникает проблема — надо ли все переписывать. Большинство облачных платформ в интернете поддерживают стандартный набор: Node.js, Python, Ruby, Java.

Cocaine с точки зрения платформы запускает любой исполняемый файл и ожидает взаимодействия. Такое техническое решение позволило добиться следующего. Написаны фреймворки для Node.js, C++, Python, Go, Java, два последних — в стадии бета. Сама облачная платформа распределенная, поэтому должно быть как-то организовано взаимодействие. Для этих целей придуман бинарный протокол на основе мессендж-пака, и все составные части, такие, как сервисы, приложения, ядро — все общаются по этому протоколу. Протокол состоит из семи команд, поддерживает стриминг и имеет много общего с НТТР 2.0.

Платформа разрабатывалась для высоконагруженных решений, и предполагается, что приложения будут асинхронными. Такой подход позволяет достичь большего потенциала по масштабируемости и производительности.

Event-driven подразумевает некие ивенты. В качестве источников этих событий могут выступать, например, клиентский код за пределами облака, приложение внутри облака, различные драйверы (ZeroMQ, таймеры), HTTP-интерфейс.

Всем приложениям в облаке нужны достаточно типичные задачи вроде хранения данных, геолокации, логирования, определения модели телефона. И включать этот элемент в каждый раздел кода плохо по нескольким параметрам. Во-первых, это нерациональное использование предоставляемых ресурсов. Во-вторых, если изменится API какого-то элемента, придется менять все приложения. В третьих, не надо писать биндинг в каждый язык.

Предлагается такой подход. Берется, например, библиотека для геолокации, для нее пишется обертка на С++, которая позволяет запустить библиотеку как сервис в облаке.

Логи по умолчанию пишутся в syslog, для больших облаков — logstash, для отправки логов в распределенное индексирующее хранилище.

Балансировка в облаке является очень важной по двум причинам. Во-первых, она позволяет обеспечить отказоустойчивость облака. Во-вторых, она позволяет более рационально использовать ресурсы этого облака. Типичная схема инсталляции Cocaine в Яндексе выглядит так:

То есть, есть некоторые пользователи, которые приходят во фронт, где стоит кокаиновый балансировщик. И он перенаправляет эти запросы в зависимости от текущей конфигурации облака на нужную ноду. Нода реализуется мультикастом.

Рекомендуется использовать балансировщик на основе IPVS.

IPVS — ядерная технология, очень распространенная, предоставляет интерфейс для модифицирования текущих весов. Технология «из коробки» умеет 11 алгоритмов, умеет балансировать TCP/UDP, и по одному IP-адресу доступны несколько сервисов. Проблему изоляции и ограничения ресурсов решает CGroups. Docker запускается внутри контейнера, позволяет свое окружение иметь всегда с собой, файловая система организована слоями и можно менять окружение, комбинируя слои.

Владимир наглядно показал, как создать и запустить приложение в облаке.

Проект доступен по ссылке.

Есть методология БЭМ, по этой методологии написано какое-то количество инструментов, библиотек, блоков, и есть заготовка, которая позволяет быстро начать новый проект.

Владимир создал приложение, которое из Яндекс.Фоток получило альбом с прошлого мероприятия Я.Субботник в Минске и показало в галерее.

Обзор докладов подготовила Александра Кирьянова