Yandex Lego Oleg Obolensky

LEGO в Как собрать из кубиков большой web-проект Оболенский Олег руководитель отдела разработки [email_address]

О чем все это

Как программные системы в Яндексе (и вообще крупные web-проекты) могут быть устроены в целом, и как их части могут взаимодействовать между собой?

Что это дает?

Это красивая идея или есть работающие реализации?

внедрено и работает с 2001 года

Почта (~ 12 млн хитов в сутки), Каталог (3,5 млн), Маркет (2,2 млн), Словари (1,3 млн), Карты (1,1 млн), Погода (800 тыс), Телепрограмма (400 -600 тыс), Открытки (350 тыс.), Игрушки (350 тыс.), Адреса (250 тыс.), Афиша (200 тыс), ППБ (200 тыс.) и еще примерно 20 мелких проектов (stat.yandex.ru, music.yandex.ru, и т.д.)

Статистика

Условия жизни

Распределенность – следует из нефункциональных требований к проекту (масштабируемость, отказоустойчивость)

Компонентный подход – научились пользоваться достоинствами, в связи с чем активно применяется

Компоненты развернуты на бекендах и взаимодействуют с фронтендами и друг с другом при помощи открытых протоколов (HTTP, CORBA)

Проблема

Как интегрировать проекты, не затрачивая усилий каждый раз при появлении нового?

`

Application server

называется XScript

многопоточный

выполняется, как правило, в адресном пространстве веб-сервера, (что накладывает ограничения на архитектуру последнего), однако может взаимодействовать с ним и по протоколу FastCGI.

использует основанное на XML декларативное описание вызовов для формирования страницы.

необходимая функциональность выполняется преимущественно на бекендах.

Как это выглядит <?xml version="1.0"?> <page> <block timeout="1500"> <name>Yandex/PPB/Rating.id</name> <method>getRatingFor</method> <param type="QueryArg" default="abc">feed</param> <param type="Auth"/> </block> <http xslt="xsl/sample.xsl"> <method>getHttp</method> <param type="String">http://www.ya.ru?q=</param> <param type="QueryArg">num</param> </http> </page>

Детали

Разобранные XML и XSL хранятся в памяти XScript.

Yandex/PPB/Rating.id – имя распределенного объекта в стандартном CORBA NameService

NameService поднят на каждой машине на локальном интерфейсе.

в IOR объекта «зашит» IP-адрес балансирующего маршрутизатора

Почему IPVS, а не балансирующий NameService?

Ээээ..... Отлично, но что при этом показать пользователю?

Как это выглядит

По соглашению, CORBA- и HTTP-сервера возвращают xml

его можно трансформировать при помощи xsl

полученный от бекендов xml (возможно, после xsl-преобразования) подставляется в документ вместо узлов, описывающих соответствующие вызовы

На сформированный xml-документ накладывается xsl – получается html (m3u, rss, e.t.c)

Адаптация к нагрузке Ура! Проект сделали. Чего бы теперь такого предпринять, чтобы он еще и заработал нормально?

Параллельность

Декларации XScript, как и шаблонные правила в XSLT, описывают конечный результат, но не порядок выполнения – это хороший повод вызывать бекенды параллельно.

Последовательно тоже можно

Параллельность выполнения прозрачна для бекенда

в XScript есть набор механизмов для передачи данных между вызовами

Кеширование

Кешируются ответы бекендов, а не сформированные страницы.

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

HTTP-ответы кешируются стандартно.

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

Кеширование в CORBA ... module Yandex { typedef long TimeT; struct Tag { TimeT expire_time; TimeT lasl_modified; boolean not_modified; }; }; // module Yandex ...

Кеширование в CORBA

Механизм действия очень похож на кеширование в HTTP

Явное кеширование – если бекенд вернул expire_time, то кеш-копия валидна до наступления expire_time.

Неявное кеширование – если бекенд вернул на первом вызове last_modified, то на каждый вызов ходим в бекенд и not_modified в ответе означает, что кеш-копия валидна.

Если авария

Деградация сервисов