Insight IT

Что стоит знать о памяти в Linux?

Иван Блинков — Sun, 07 Jun 2015 22:45:00 +0300

Подсистема работы с оперативной памятью в Linux - достаточно многогранная конструкция. Чтобы разобраться в её деталях нужно целенаправленно погрузиться в тему, с обязательным чтением исходников ядра, но это нужно не каждому. Для разработки и эксплуатации серверного программного обеспечения важно иметь хотябы базовое предстваление о том, как она работает, но меня не перестает удивлять насколько небольшая доля людей им обладает. В этом посте я постараюсь кратко пробежаться по основным вещам, без понимания которых на мой взгляд очень легко натворить глупостей.

Какая бывает память?

Физическая и виртуальная

Начнем издалека. В спецификации любого компьютера и в частности сервера непременно числится надпись "N гигабайт оперативной памяти" - именно столько в его распоряжении находится физической памяти.

Задача распределения доступных ресурсов между исполняемым программным обеспечением, в том числе и физической памяти, лежит на плечах операционной системы, в нашем случае Linux. Для обеспечения иллюзии полной независимости, она предоставляет каждой из программ свое независимое виртуальное адресное пространство и низкоуровневый интерфейс работы с ним. Это избавляет их от необходимости знать друг о друге, размере доступной физической памяти и текущей её занятости. Адреса в виртуальном пространстве процессов называют логическими.

Для отслеживания соответствия между физической и виртуальной памятью ядро Linux использует иерархический набор структур данных в своей служебной области физической памяти (только оно работает с ней напрямую), а также специализированные аппаратные контуры, которые в совокупности называют MMU.

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

Также стоит упомянуть, что на аппаратном уровне как правило есть поддержка дополнительного уровня абстракции в виде "сегментов" оперативной памяти, с помощью которых можно разделять программы на части. В отличии от других операционных систем, в Linux она практически не используется - логический адрес всегда совпадает с линейным (адресом внутри сегмента, которые сконфигурированы фиксированным образом).

Файловая и анонимная

У приложений существует много способов выделить себе память для тех или иных нужд. Высокоуровневые языки программирования и библиотеки часто прячут от разработчиков какой из них в реальности использовался и другие детали (хотя их всегда можно "раскусить" с помощью strace). Если углубляться в особенности каждого доступного варианта, эта статья быстро бы превратилась в книгу. Вместо этого предлагаю разделить их на две, на мой взгляд, крайне важные группы по тому, какую память они выделяют:

Файловой памяти однозначно соответствует какой-либо файл или его часть в файловой системе. Первым делом в ней как правило находится исполняемый код самой программы. Для прикладных задач можно запросить отображение файла в виртуальное адресное пространство процесса с помощью системного вызова mmap - после чего с ним можно работать как с любой другой областью памяти без явного чтения/записи, что будет при этом происходить с данными в файловой системе и что будут видеть другие процессы "отобразившие" этот же файл зависит от настроек.
Любую другую выделенную память называют анонимной, так как ей не соответствует никакой файл, которые как известно именованы. Сюда попадают как переменные на стеке, так и области, выделенные с помощью функций вроде malloc (к слову, за сценой для выделения больших блоков памяти они обычно тоже используют mmap с особым набором настроек, а для всего остального - brk/sbrk или выдают ранее освобожденную память).

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

Вытесняемая и нет

Суммарный объем используемой виртуальной памяти всех программ запросто может превышать объем доступной физической памяти. При этом в каждый конкретный момент времени приложениями может использоваться лишь небольшое подмножество хранимых по виртуальным адресам данных. Это означает, что операционная система может откладывать не используемые в данный момент данные из оперативной памяти на жесткий диск ("вытесняя"" их из памяти), а затем при попытке к этим данным обратиться - скопировать обратно в физическую оперативную память. Этот механизм официально называется major page fault, но под просто page fault как правило подразумевают тоже её, так как minor page fault мало кого заботит (отличие в том, что в случае minor ядру удается найти запрашиваемые данные уже загруженными в память с какой-то другой целью и обращения к диску в итоге не происходит).

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

Прочитать 4Кб данных с обычного серверного жесткого диска 7200rpm занимает порядка 10 мс, при хорошем стечении обстоятельств чуть меньше.
- Если вытесненных страниц оказывается много, запросто могут набегать заметные доли секунды (как условным пользователям, так и на внутренних приборах, в зависимости от задачи).
- Особенно опасны циклические pagefaults, когда есть две или более регулярно используемые области памяти, которые вместе не помещаются в физическую память, по-этому бесконечно вытесняют друг друга туда-обратно.
- При этом диск вынужден делать честный seek, что само по себе тоже может быть не кстати. Например, если с этим же диском работает какая-либо база данных.
Если используется SSD, то ситуация несколько более радужная - из-за отсутствия механического движения аналогичная операция занимает примерно на порядок меньше, около 1 мс или её доли, в зависимости от типа и конкретной модели диска. Но годы идут, а SSD так и остаются нишевым компромиссным продуктом по цене-объему.
А теперь для сравнения: если бы страница уже была в памяти, то при обращении к ней счет шел бы на сотни наносекунд. Это почти на 4 порядка быстрее, чем pagefault, даже на SSD.

Стоит отметить, что с точки зрения приложения всё это прозрачно и является внешним воздействием, то есть может происходить в самый не подходящий, с точки зрения решаемой им задачи, момент.

Думаю понятно, что приложения, которым важна высокая производительность и стабильное время отклика, должны избегать pagefault'ов всеми доступными методами, к ним и перейдем.

Методы управления подсистемой памяти

swap

С файловой памятью всё просто: если данные в ней не менялись, то для её вытеснения делать особо ничего не нужно - просто перетираешь, а затем всегда можно восстановить из файловой системы.

С анонимной памятью такой трюк не работает: ей не соответствует никакой файл, по-этому чтобы данные не пропали безвозвратно, их нужно положить куда-то ещё. Для этого можно использовать так называемый "swap" раздел или файл. Можно, но на практике не нужно. Если swap выключен, то анонимная память становится невытесняемой, что делает время обращения к ней предсказуемым.

Может показаться минусом выключенного swap, что, например, если у приложения утекает память, то оно будет гарантированно зря держать физическую память (утекшая не сможет быть вытеснена). Но на подобные вещи скорее стоит смотреть с той точки зрения, что это наоборот поможет раньше обнаружить и устранить ошибку.

mlock

По-умолчанию вся файловая память является вытесняемой, но ядро Linux предоставляет возможность запрещать её вытеснение с точностью не только до файлов, но и до страниц внутри файла.

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

Несколько примеров, когда это может быть целесообразно:

У приложения большой исполняемый файл с большим количеством ветвлений, некоторые из которых срабатывают редко, но регулярно. Такого стоит избегать и по другим причинам, но если иначе никак, то чтобы не ждать лишнего на этих редких ветках кода - можно запретить им вытесняться.
Индексы в базах данных часто физически представляют собой именно файл, с которым работают через mmap, а mlock нужен чтобы минимизировать задержки и число операций ввода-вывода на и без того нагруженном диске(-ах).
Приложение использует какой-то статический словарь, например с соответствием подсетей IP-адресов и стран, к которым они относятся. Вдвойне актуально, если на одном сервере запущено несколько процессов, работающих с этим словарем.

OOM killer

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

Происходит это достаточно радикальными методами: послуживший названием данного раздела механизм выбирает по определенному алгоритму процесс, которым наиболее целесообразно в текущий момент пожертвовать - с остановкой процесса освобождается использовавшаяся им память, которую можно перераспределить между выжившими. Основной критерий для выбора: текущее потребление физической памяти и других ресурсов, плюс есть возможность вмешаться и вручную пометить процессы как более или менее ценные, а также вовсе исключить из рассмотрения. Если отключить OOM killer полностью, то системе в случае полного дефицита ничего не останется, как перезагрузиться.

cgroups

По-умолчанию все пользовательские процессы наравне претендуют на почти всю физически доступную память в рамках одного сервера. Это поведение редко является приемлемым. Даже если сервер условно-однозадачный, например только отдает статические файлы по HTTP с помощью nginx, всегда есть какие-то служебные процессы вроде syslog или какой-то временной команды, запущенной человеком. Если же на сервере одновременно работает несколько production процессов, например, популярный вариант - подсадить к веб-серверу memcached, крайне желательно, чтобы они не могли начать "воевать" друг с другом за память в случае её дефицита.

Для изоляции важных процессов в современных ядрах существует механизм cgroups, c его помощью можно разделить процессы на логические группы и статически сконфигурировать для каждой из групп сколько физической памяти может быть ей выделено. После чего для каждой группы создается своя почти независимая подсистема памяти, со своим отслеживанием вытеснения, OOM killer и прочими радостями.

Механизм cgroups намного обширнее, чем просто контроль за потреблением памяти, с его помощью можно распределять вычислительные ресурсы, "прибивать" группы к ядрам процессора, ограничивать ввод-вывод и многое другое. Сами группы могут быть организованы в иерархию и вообще на основе cgroups работают многие системы "легкой" виртуализации и нынче модные Docker-контейнеры.

Но на мой взгляд именно контроль за потреблением памяти - самый необходимый минимум, который определенно стоит настроить, остальное уже по желанию/необходимости.

NUMA

В многопроцессорных системах не вся память одинакова. Если на материнской плате предусмотрено N процессоров (например, 2 или 4), то как правило все слоты для оперативной памяти физически разделены на N групп так, что каждая из них располагается ближе к соответствующему ей процессору - такую схему называют NUMA.

Таким образом, каждый процессор может обращаться к определенной 1/N части физической памяти быстрее (примерно раза в полтора), чем к оставшимся (N-1)/N.

Ядро Linux самостоятельно умеет это всё определять и по-умолчанию достаточно разумным образом учитывать при планировании выполнения процессоров и выделении им памяти. Посмотреть как это все выглядит и подкорректировать можно с помощью утилиты numactl и ряда доступных системных вызовов, в частности get_mempolicy/set_mempolicy.

Операции с памятью

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

Операции, работающие с памятью:
- В большинстве своем не атомарны (то есть другой поток может их "увидеть" на полпути), без явной синхронизации атомарность возможна только для блоков памяти не больше указателя (т.е. как правило 64 бита) и то при определенных условиях.
- В реальности происходят далеко не всегда в том порядке, в котором они написаны в исходном коде программы: процессоры и компиляторы на правах оптимизации могут менять их порядок, как считают нужным. В случае многопоточных программ эти оптимизации часто могут приводить к нарушению логики их работы. Для предотвращения подобных ошибок разработчики могут использовать специальные инструменты, в частности барьеры памяти - инструкции, которые запрещают переносить операции с памятью между частями программы до неё и после.
Новые процессы создаются с помощью системного вызова fork, который порождает копию текущего процесса (чтобы запустить другую программу в новом процессе существует отдельное семейство системных вызовов - exec), у которого виртуальное пространство практически полностью идентично родительскому, что не потребляет дополнительной физической памяти до тех пор, пока тот или другой не начнут его изменять. Этот механизм называется copy on write и на нем можно играть для создания большого числа однотипных независимых процессов (например, обрабатывающих какие-то запросы), с минимумом дополнительных расходов физической памяти - в некоторых случаях так жить удобнее, чем с многопоточным приложением.
Между процессором и оперативной памятью находится несколько уровней кешей, обращение к которым ещё на порядки быстрее, чем к оперативной памяти. К самому быстрому - доли наносекунд, к самому медленному единицы наносекунд. На особенностях их работы можно делать микро оптимизации, но из высокоуровневых языков программирования до них толком не добраться.

Итого

Подсистему памяти в Linux нельзя бросать на произвол судьбы. Как минимум, стоит следить за следующими показателями и вывести на приборы (как суммарно, так и по процессам или их группам):

Скорость возникновения major page faults;
Срабатывания OOM killer;
Текущий объем использования физической памяти (это число обычно называют RSS, не путать с одноименным форматом для публикации текстового контента).

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

Статья написана с ориентиром на современные Debian-like дистрибутивы Linux и физическое оборудование с двумя процеcсорами Intel Xeon. Общие принципы ортогональны этому и справедливы даже для других операционных систем, но вот детали могут сильно разниться даже в зависимости от сборки ядра или конфигурации.
У большинства упомянутых выше системных вызовов, функций и команд есть man, к которому рекомендую обращаться за подробностями об их использовании и работе. Если под рукой нет linux-машины, где можно набрать man foo - они обычно легко ищутся с таким же запросом.
Если есть желание углубиться в какую-либо из затронутых вскользь тем - пишите об этом в комментариях, любая из них может стать заголовком отдельной статьи.

P.S.

На последок ещё раз повторю цифры, которые настоятельно рекомендую запомнить:

0.0001 мс (100 нс) - обращение к оперативной памяти
0.1-1 мс (0.1-1 млн. нс) - обращение к SSD при major pagefault, на 3-4 порядка дороже
5-10 мс (5-10 млн. нс) - обращение к традиционному жесткому диску при pagefault, ещё на порядок дороже

// мс - миллисекунды, нс - наносекунды.

Реинкарнация сайта

Иван Блинков — Sat, 30 May 2015 20:10:00 +0300

После, пожалуй, самого длительного периода без обновлений в истории Insight IT, сайт прошел через "реинкарнацию" - был переделан с нуля, сохранен лишь контент. Этого сложно не заметить, если Вы здесь не впервые. Желающих получить ответы на вопросы в духе "как так?", "зачем?", "что поменялось?" и "что дальше?" - прошу читать далее.

Как так?

Многие годы, занимаясь Insight IT, я совмещал приятное с полезным: по большому счёту оставаясь просто хобби, сайт помогал мне знакомиться с будущими партнерами, клиентами, коллегами, что долгое время позволяло мне обходиться без стабильного источника дохода. Когда я в итоге "сдался" и пошел работать в крупную компанию за зарплату - эта дополнительная ценность стала менее значимой. Во многом из-за этого здесь нельзя найти ни одной записи датированной прошлым годом (хотя есть и другие причины, конечно, но об этом в заключении).

Зачем?

Резонный вопрос - зачем вкладывать столько сил, чтобы всё переделать на в заброшенном сайте? Началось всё со спортивного интереса: я начал замечать, что постепенно теряю хватку в мирах opensource и веб-разработки. В Яндексе вокруг меня по большей части разный backend внутренней разработки. Кандидат для экспериментов в лице Insight IT нашелся быстро, что из этого получилось - в следующем разделе.

Что поменялось?

R.I.P. WordPress

Первые 6 c половиной лет своего существования Insight IT проработал на WordPress в качестве CMS. С пьедестала самой популярной CMS в мире, насколько я знаю, за всё это время WordPress так никто и не сместил. Думаю, в первую очередь благодаря крайне простому в использовании интерфейсу для управления сайтом, а во вторую - выдающемуся ассортименту плагинов и тем. Плюс имевший место в 2008-м акцент на блоги отходит в сторону, сейчас на нем какие только сайты не делают.

Но за ~~красоту~~ простоту приходится платить:

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

Вопрос с производительностью решается агрессивным кешированием и клиентской оптимизацией. Не раз занимался этим для других сайтов, в том числе и на WordPress, но для некоммерческого проекта не понятно как оправдать трудозатраты на изначальную настройку и поддержание этого всего в рабочем состоянии. Зачастую плагины разрабатываются без оглядки на то, что, например, JavaScript-библиотека, от которой они зависят, может быть ещё не быть загружена и пытаются ей пользоваться в распечатанном прямо вперемешку с HTML JavaScript, что даже само по себе плохо, а с перенесенными вниз зависимостями и вовсе не работает.

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

Уже в 2009-м минусы WordPress для меня начали перевешивать плюсы. Тогда достойной альтернативы, увы, не нашлось и всё осталось как есть. Но не в этот раз.

Статические сайты

Несколько лет назад начал набирать популярность подход с генерацией статических сайтов:

Вместо хранения в базе данных статьи и другой контент приравнивается к исходному коду, то есть:
- Хранятся в системе контроля версий в виде файлов в специализированном формате (как правило, Markdown или ReStructured Text), который удобен для написания человеко-читаемых текстов и однозначно преобразовывается в чистый, валидный, HTML.
- Пишутся в текстовых редакторах, ориентированных на разработчиков, с подсветкой синтаксиса, автодополнением и т.п.
- При необходимости легко начать использовать общепринятые инструменты для работы с кодом, в том числе совместной (ревью кода, ветвление, непрерывная интеграция, отслеживание проблем).
С помощью make или аналога сайт собирается примерно так же, как это делала бы программа на C++:
- Создается output директория с будущим результатом.
- В ней генерируются все страницы сайта - для статей с помощью шаблонизатора добавляется вся необходимая HTML-обвязка, а навигационные страницы (по категориям и тегам, с по-страничным выводом) создаются с нуля, тоже по шаблону.
- Весь клиентский код на JavaScript и CSS, а также статические файлы вроде изображений, группируются и прогоняются через разные фильтры для уменьшения количества файлов и их размеров.
- Внутренние ссылки в исходном коде как правило реализованы по путям в локальной файловой системе, а как они будут выглядеть в итоговом сайте конфигурируется и тоже применяется при сборке.
В итоге, чтобы посмотреть на результат в браузере подойдет любой веб-сервер, умеющий отдавать статические файлы из папки, то есть совсем любой за вычетом специализированных.
Как легко такую папочку кешировать на всех уровнях, а также как быстро и дешево можно такой сайт показывать пользователям, рассказывать, думаю, не нужно.
Но у отсутствия динамической серверной логики есть и минусы:
- ~~Тоска по гламурной админке WordPress.~~
- Для реализации некоторого функционала (в нашем случае - комментариев и поиска по сайту) требуется как-то изворачиваться, возможные варианты:
  - Воспользоваться сторонним сервисом - Disqus уже использовался и раньше, а обе лидирующие поисковые системы предоставляют сервис поиска по конкретному сайту, так что я пошел по этому пути).
  - Поселить рядом с кучей статики какой-о набор скриптов, но не очень понятно как их интегрировать с системой сборки сайта, которая по сути выполняет роль CMS.
  - Реализовать его на JavaScript - скажем для поиска по сайту можно при сборке сложить весь контент в один большой JSON, и искать по нему уже на клиенте. Но я решил пожалеть пользователей с долгоиграющими ноутбуками, особенно новых без вентиляторов. Раньше ещё можно было пожалеть владельцев смартфонов, но когда их стали делать восьми-ядерными...
- Время, которое технически необходимо для публикации нового контента или изменений в шаблонах, начинает зависеть от размера самого сайта - не смотря на попытки реализовать кеширование при сборке, многие изменения требуют перегенерации примерно всего сайта.
И, напоследок, ввиду низкой серверной ресурсоемкости таких сайтов, для него легко найти качественный хостинг бесплатно.

Взвесив "за" и "против", я решил, что для Insight IT такой вариант очень даже подходит. Осталось выбрать конкретную реализацию такой системы сборки сайта.

Первопроходцем и лидером рынка здесь является Jekyll. Всем хорош, очень много кем используется, масса тем и плагинов. Но один субъективный минус поставил на нём лично для меня крест - Ruby. Вот тошнит меня от его синтаксиса и всё.

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

Подходящую альтернативу искать долго не пришлось: выбор пал на Pelican, практически единственный вариант на Python. Готовых плагинов у него не так много, но самое основное есть, а недостающее мне определенно было не сложно допилить, благо с экосистемой Python я тесно знаком. В качестве шаблонизатора используется Jinja2, лучше которого я по-прежнему ничего не видел. Про сам перенос сайта можно написать отдельный пост, и не один, что я надеюсь и сделаю в скором будущем, так что здесь эту тему дальше развивать не буду.

https://

Как при желании можно было заметить, Insight IT уже много лет живет за CloudFlare - многофункциональной распределенной прокси, выполняющей роль CDN, DNS,защиты от разного рода атак и многого другого. Изначально поддержка SSL была доступна только на платном тарифе, который некоммерческому проекту был ни к чему, но с недавних пор это стало не так и я за компанию решил перейти на https://, раз уж всё равно все внутренние ссылки переехали. Плюсы не критичны, но всё же есть:

Само отображение защищенного соединения в адресной строке браузеров внушает уверенность если не всем, то какой-то части посетителей
Поддержка современных протоколов в лице SPDY и, вероятно, со временем HTTP/2.0
Говорят, использование защищенного соединения положительно сказывается на репутации сайта в глазах как минимум поиска Google
Владельцы публичных WiFi точек не могут показывать свою рекламу на сайте

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

К слову, стоявший за CloudFlare простенький VPS тоже заменен, на наиболее популярный среди хостингов статичных сайтов GitHub Pages.

Контент

В состав Pelican входит инструмент для конвертации статей из XML-формата WordPress в Markdown, которым я и воспользоваться. Большую часть работы он сделал, но всё равно потребовался ручной просмотр и адаптация всех страниц сайта. Это заняло уйму времени, но в целом того стоило:

Везде причёсан HTML, во многом благодаря Markdown; лучше оформлены изображения и врезки, ещё раз проверены опечатки.
Исторически статьи раскладывались по рубрикам по мере написания, по-этому общая структура сайта была хаотичной. Теперь разбил их на категории по-другому, на этот раз, надеюсь, более логичным образом.
Пока перечитывал осознал, что значительная часть контента морально устарела и годится только для совсем начинающих или как историческая перспектива. Решил сделать некоторый акцент на годе публикации - теперь он присутствует в URL статей, а также в оглавлении публикаций об архитектуре высоконагруженных интернет-проектов. Совсем-совсем неактуальным пришлось пожертвовать или явно подписать соответствующим образом.
Как следствие из предыдущих двух пунктов, в очередной раз полностью поменялась структура ссылок сайта. По-возможности со старых адресов сохранены редиректы, но, к сожалению, в концепции статических сайтов возможны только клиентские, через meta-тег или JavaScript. Поисковые системы же предпочитают серверные, через 301/307 HTTP-код и заголовок Location.
В общем, позиции Insight IT в поисковых системах определенно пострадают, остается лишь надеяться что не катастрофическим образом - ведь сейчас это основной источник посетителей. Если вам не безразлична судьба сайта - твиты, лайки и прочие входящие ссылки по новым адресам крайне приветствуются.
Теперь весь контент публикуется под лицензией Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License, о чем свидетельствует значок в правом-нижнем углу каждой страницы.

Дизайн

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

За всё те же последние несколько лет Twitter Bootstrap стал решением по-умолчанию для подобных ситуаций благодаря низкому порогу входа и хорошей комбинации встроенного функционала, кроссбраузерности и приличного внешнего вида. По иронии ровно это и стало причиной моего от него отказа в данном случае: уж больно он всем приелся и на каждом углу почти без изменений используется.

В своё время мне приглянулось своей стройностью и логичностью концепция Material Design от Google, которую они активно внедряют сами и всем советуют. Не долго думая, я пошел поискать opensource решения с готовой реализацией для веб-сайтов и остановился на варианте, который одновременно имел достаточный функционал, сколько-либо большое сообщество и минимум зависимостей, особенно от громоздких JavaScript-библиотек, чем грешили альтернативные варианты.

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

Итого, с моей субъективной колокольни получилось заметно лучше прежнего, но хочется всё же услышать и ваше мнение в комментариях.

Что дальше?

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

С закрытием Google Reader два года назад число подписчиков на счетчике от FeedBurner упало почти на два порядка, так что можно считать, что сейчас и правда для Insight IT всё начинается почти с начала.

Вакансии: разработчики облачной IaaS платформы в Крок

Иван Блинков — Thu, 19 Sep 2013 19:40:00 +0400

Вакансии более не актуальны

Ведущая российская ИТ-компания ищет талантливых, креативных и энергичных инженеров и разработчиков для развития коммерческой облачной платформы КРОК, предоставляющей услугу типа «Инфраструктура как сервис» (IaaS). В современном высокотехнологичном офисе Вас ждет дружная сплоченная команда профессионалов, занимающаяся разработкой передовой «облачной» платформы, у которой всегда найдется для Вас множество интересных, сложных и разнообразных задач, способных удовлетворить даже самые заоблачные амбиции!

Разработчик на платформе Linux

Обязанности

Проектирование архитектуры компонентов «облачного» решения;
Разработка и интеграция модулей облачной платформы;
Исследования в области распределенных высоконагруженных систем.

Требования

Опыт в области shell-программирования;
Уверенное знание Python, приветствуется знание С++ или Java;
Владение средствами разработки (autotools, git, svn и др.);
Опыт администрирования ОС Linux от 1 года (преимущественно RHEL, CentOS, Debian или SLES);
Опыт работы с технологиями виртуализации (Qemu/KVM, XEN, Hyper-V или VMware);
Знание «облачных» технологий особенно приветствуется.

Инженер по облачным решениям

Обязанности

Общение с техническими специалистами заказчика для определения задач и специфических требований, предъявляемых к информационной системе;
Исследовательская работа по поиску, тестированию и внедрению различных технологий;
Участие во внедрении решений для автоматизации ИТ-инфраструктуры;
Тестирование различных вариантов исполнения инфраструктурных решений;
Техническая поддержка внедряемых решений решения.

Требования

Навыки администрирования современных ОС GNU/Linux и Windows;
Понимание принципов виртуализации вычислительных ресурсов;
Приветствуется опыт написания сценариев на языках shell и Python;
Личные качества: коммуникабельность, общительность, активная жизненная позиция.

Условия

Конкурентная заработная плата по результатам собеседования;
Возможность профессионального и карьерного роста;
Компания оплачивает обучение и сертификацию;
Социальный пакет (медицинская страховка, бесплатное питание в офисе, спортивные программы и компенсация фитнеса, английский язык);
Компания оказывает помощь при переезде в Москву (оплата стоимости проезда для прохождения собеседований, «подъемные» при выходе на работу).

Куда отправлять резюме?

Вакансии более не актуальны

Горячая замена кода

Иван Блинков — Mon, 29 Apr 2013 10:47:00 +0400

Относительно недавно почитывая RSS через доживающий свои дни Google Reader, о предстоящем закрытии которого не написал только самый ленивый IT-блоггер (к слову, любопытно насколько сильно просядет счетчик RSS-подписчиков Insight IT с текущих 16870, боюсь, что очень сильно...), я наткнулся на статью под заголовком "Горячее обновление кода не нужно?" и с выводом, что мол и правда особо не нужно, которая и подтолкнула меня поделиться своими мыслями на эту тему.

Для начала давайте разберемся в том, что же вообще такое "горячая замена кода" (hot code replacement или hot code swapping)? По сути это возможность обновить (или откатить) код работающей программы без её перезапуска и, как следствие, периода недоступности, потери состояния и повторной инициализации.

В каких ситуациях это может быть полезно? Ответ следует из моего импровизированного определения выше:

Когда простой (downtime) неприемлем
Когда есть какое-то состояние в памяти, которое не хочется терять
Когда инициализация процесса трудоемка и занимает много времени, что чаще всего связано с восстановлением состояния с диска или других внешних источников

Ко многим клиент-серверным приложениям, в том числе и веб-сайтам, предъявляют очень высокие требования по отказоустойчивости, то есть простои как таковые не допустимы даже в экстренных случаях, не говоря уже о регулярном обновлении компонентов системы. Но чтобы обеспечить высокой уровень доступности, измеряемый количеством девяток после запятой в 99.(9)%, одной горячей замены кода не достаточно, нужно в любом случае обеспечить доступность всех данных и ключевых серверных компонентов системы даже в случае выхода из строя сервера, стойки, маршрутизатора и даже целого датацентра. Обычно это делается "на уровень выше" относительно самого кода приложения, путем добавления в систему как минимум резервных (активных или пассивных) копий всех компонентов и балансировщика нагрузки, способного обнаруживать неполадки и соответствующим образом перенаправлять поток запросов. Балансировщик нагрузки также нуждается в выделении под него как минимум двух серверов с переключением на уровне DNS. Возвращаясь к изначальной теме: если уж приложение способно пережить экстренный сбой любого компонента, то и без всякой горячей замены спокойно переживет его плановый перезапуск в связи с обновлением. Хотя на практике даже при резервировании всех компонентов небольшая доля запросов может быть потеряна или обработана за неприемлемо длинный срок в процессе перемаршрутизации их потока.

Казалось бы клиент-серверные приложения чаще всего не имеют состояния, в том плане, что все состояние находится в какой-то внешней сущности вроде СУБД, так что инициализировать особо нечего и состояние потерять не жалко. И на самом деле часто так и бывает, в том же мире PHP довольно популярна практика: положить новую версию кода в соседнюю папочку, поменять document root в конфиге nginx, попросить nginx перечитать свой конфиг - максимум сбросится кэш APC или xcache, что мало кого волнует, так как побочным эффектом будет просто несколько ответов на запросы медленнее обычного.

А как быть с самой СУБД? Например, Redis при запуске зачитывает в память все данные прежде чем начать принимать запросы, что может занимать сколько-то минут. Другие СУБД, которые могут отвечать на запросы и по данным на диске, стартуют относительно быстро, но провал в их производительности до того, как разогреется встроенный в них кэш, заметен невооруженным глазом. Очень похожа ситуация и с брокерами сообщений вроде RabbitMQ: если они и хранят данные на диске, то скорее как резервную копию. А memcached, Redis без персистентности и другие хранилища данных в памяти вовсе могут разогреваться после перезапуска неопределенно долго, так как наполняются по мере поступления запросов на запись.

В языках программирования, основанных на байт-коде и виртуальных машинах, зачастую есть возможность осуществлять горячее обновление кода без перезапуска самой виртуальной машины. Когда говорят про Erlang, очень часто упоминают эту возможность как одно из ключевых преимуществ платформы, так как она хорошо сочетается с её системой легковесных не зависящих от ОС процессов и встроенного в виртуальную машину эффективного хранилища данных в памяти (ETS). В мире Java это тоже возможно, но используется намного реже и позиционируется скорее как инструмент для отладки. В момент подмены кода в работающей виртуальной машине языка программирования с точки зрения ОС ничего не меняется: все открытые соединения, файловые дескрипторы и выделенная оперативная память остаются за ней, то есть она выступает своего рода посредником между одновременно загруженными двумя версиями кода, одна из которых будет выгружена из памяти, как только закончит свою работу и передаст все "дела" новой. Хотя это очень поверхностное описание, на практике всплывает масса нюансов вроде миграции состояний процессов в обе стороны, совместимости протоколов взаимодействия и пр. Плановый перезапуск в данной схеме нужен лишь для обновления самой виртуальной машины, что обычно требуется намного реже, чем обновление кода приложения.

Возможность горячей замены кода на уровне виртуальной машины, казалось бы, выглядит очень привлекательно для разработки обсуждавшихся выше инфраструктурных компонентов, от балансировщика нагрузки до различных хранилищ данных, что позволило бы не терять регулярно в производительности при обновлениях из-за сброса кэша и переустановки сетевых соединений. Но в реальности таких продуктов можно пересчитать по пальцам, почему? Все просто: удобство требует жертв - избегая периодических провалов в производительности из-за минимизации перезапусков процессов при обновлении, приходится проигрывать в производительности постоянно по сравнению с нативным кодом. Для инфраструктуры обычно оказывается приоритетнее постоянная производительность, что практически по-умолчанию означает разработку на одном из диалектов C/C++, где подобная схема с подменой кода на лету хоть и возможна, но сложна в реализации ввиду отсутствия популярных стабильных решений.

Подводя итог: горячая замена кода - скорее удобство, чем жизненная необходимость. Удобство при разработке, позволяющее не инициализировать программу заново при каждом изменении в коде. Удобство при эксплуатации, позволяющее не терять текущее состояние в памяти и минимизировать время простоя каждого отдельного компонента системы. Удобство при поиске сложно воспроизводимых багов, так как есть возможность на ходу загрузить отладочную (debug) сборку на проблемной боевой машине. Но многие проекты прекрасно себе живут и без всего этого, стоит оно того или нет - сугубо индивидуальное решение.

Вакансии: команда Python разработчиков в EVAplacer

Иван Блинков — Fri, 08 Feb 2013 10:20:00 +0400

Вакансии более не актуальны

Новая международная геоинформационная социальная сеть EVAplacer набирает команду разработчиков.

Ведущий разработчик серверной части на Python

Задачи

Разработка серверной части проекта на Python
Проектирование архитектуры системы и схемы базы данных
Организация взаимодействия серверной части проекта с клиентской
Принятие технических решений

Требования

Свежий опыт веб-разработки на Python без использования Django
Суммарный опыт веб-разработки от 5 лет
Самостоятельность и заинтересованность в качестве результата своей работы
Умение делегировать часть работы коллегам

Технологии

Предстоит работать со следующими технологиями:
- Flask + Jinja2
- MongoDB + Solr + memcached
- ZeroMQ
Опыт работы именно с ними очень желателен, но не обязателен

Зарплата

В диапазоне 100-150 тысяч рублей в месяц в зависимости от опыта

Клиентский разработчик

Задачи

Разработка клиентской части проекта
Работа на стыке с серверной частью (Python), создание HTML и других шаблонов на Jinja2
Оптимизация скорости загрузки страниц
Принятие технических решений по клиентской части

Требования

Опыт разработки на JavaScript/CoffeeScript и валидной верстки на HTML5
Понимание основных принципов клиентской оптимизации
Суммарный опыт веб-разработки от 3 лет
Усидчивость, самостоятельность и заинтересованность в качестве результата своей работы

Технологии

Предстоит работать со следующими технологиями:
- Jinja2 + webassets
- CoffeeScript + SASS
- Twitter Bootstrap
- jQuery
- Leaflet
Опыт работы именно с ними очень желателен, но не обязателен

Зарплата

В диапазоне 60-100 тысяч рублей в месяц в зависимости от опыта

Специалист по тестированию

Задачи

Основные:
- Разработка автоматических тестов для серверной части проекта на Python
- Регрессионное тестирование сайта с помощью Selenium или альтернатив
Дополнительные:
- Нагрузочное тестирование с использованием JMeter или альтернатив
- Ручное визуальное тестирование, в т.ч. на кроссбраузерность

Требования

Свежий опыт тестирования интернет-проектов, желательно на Python
Суммарный опыт в тестировании от 3 лет
Внимательность, самостоятельность и заинтересованность в качестве результата работы команды

Зарплата

В диапазоне 50-100 тысяч рублей в месяц в зависимости от опыта

Условия

Премии по достижении ключевых вех проекта
Офис в центре Москвы (м. Охотный ряд, меньше 5 минут пешком)
Работа на MacBook Pro

Вакансии более не актуальны

Вакансия: Java-разработчик

Иван Блинков — Mon, 14 Jan 2013 12:53:00 +0400

Вакансия более не актуальна

В крупный тур-оператор Библио-Глобус нужен ответственный порядочный человек, умеющий работать в команде. Крупная компания, динамичный бизнес, постоянно меняющиеся задачи.

Что нужно будет делать?

Надо будет писать на Java сервлеты и просто программы.
Есть собственное API доступа к данным, через которые надо работать.
В компании используются: Linux (RHEL6/CentOS5), nginx, Java, Oracle

Требования к кандидату

Опыт программирования от 3-х лет. На чем - не так важно.
Ответственность
Порядочность
Заинтересованность в результате

Условия работы

Зарплата - 150000 рублей в месяц
Полный рабочий день
Офис в Москве

Куда отправлять резюме?

Вакансия более не актуальна

5 лет

Иван Блинков — Thu, 03 Jan 2013 23:06:00 +0400

Сегодня у Insight IT первый полу-юбилей, 5 лет, в связи с чем я решил подвести небольшое резюме прошедшего года, да и всего этого довольно значимого как для проекта, так и для меня лично, периода времени. А также чуть-чуть пофилософствовать у будущем. Ничего технического не будет, читающим мой блог чисто из прагматических соображений рекомендую не тратить свое время на нижеизложенное.

Когда я сегодня сообразил, что сегодня как раз 3-е число и надо бы что-то по этому поводу написать, то первое, что попытался вспомнить: когда и про что я последний раз писал? Не вспомнил... Полез смотреть - оказалось всего чуть больше месяца назад, про очередную конференцию, а по делу - полтора месяца, тоже не особо много. При этом оказалось, что за 2012 год я умудрился написать аж 32 поста, когда посчитал - сильно удивился. Хоть среди них и много "левых" постов, у меня никогда не было ощущения, что я публиковал по 2-3 статьи в месяц...

Если попытаться найти объяснение обоим вышеизложенным фактам, оно окажется на поверхности: моя активность на Insight IT имеет ярко выраженную обратную зависимость от моей профессиональной деятельности. С конца весны IT-индустрия "в спячке": написал много статей, наиболее стоящей, на мой взгляд, получилась серия статей про интерактивные сайты. Осень - пора конференций и, как следствие, отчетов по ним. В декабре я после очень долгого перерыва устроился на работу "за зарплату", от необходимости каждый будний день кататься в офис организм до сих пор немного в шоке :)

По последнему пункту сразу попробую ответить на основные вопросы:

В Яндекс;
Официально - менеджером проектов;
По факту - cкорее просто менеджером с сильно техническим уклоном;
Про зарплату рассказывать не положено;
Про технические детали - тоже, так что лежащий у меня в черновиках пост с заголовком "Архитектура Яндекса", видимо, надолго там и останется из-за NDA, а жаль, мог бы выйти неплохим...

Вернемся от лирического отступления обратно к Insight IT. Об итогах года обычно говорят в цифрах. Решив в свое время публиковать полные посты в RSS я обрек Insight IT на минимальную посещаемость, но циферка в 16000+ подписчиков на счетчике FeedBurner мне по-прежнему греет душу, очень рад, что вы со мной :)

Хотя на самом деле с посещаемостью тоже не все так плохо, как кажется, в основном благодаря поисковым системам и разным другим блогам и форумам. Раньше я всегда умалчивал цифры о посещаемости, но что-то не припомню из-за чего именно, так что раз такое дело - опубликую данные из Google Analytics за весь 2012 год, а если вдруг вспомню почему раньше этого не делал - удалю:

116k уникальных посетителей
231k заходов (visits):
- 36% с поисковых систем
- 33% с других сайтов
- 23% напрямую
- 8% с других источников
490k просмотров страниц
58% - Россия, 25% - Украина, 5% - Беларусь, 12% - остальные страны
Всего 2% посетителей используют Internet Explorer, лидирует Chrome с 49%
65% - Windows, 21% - Linux, 9% - Mac OS X, 2% - Android, 2% - iOS, 0,2% - FreeBSD, 0.8% - остальные операционные системы

Если говорить об итогах пяти лет, я, к сожалению, не могу похвастаться стабильным ростом... Insight IT стал "популярным в узких кругах" довольно быстро, буквально в первый же месяц я написал первую успешную статью про Google, которая "выстрелила" 4 февраля 2008г., потом еще несколько и пошло-поехало. Серия статей про архитектуру высоконагруженных проектов до сих пор вне конкуренции по спросу среди всего доступного у меня контента; она, как говорится, к прочтению обязательна. Но быстро выйдя на уровень 1-10 тысяч читателей в день выше я подняться, увы, до сих пор не смог. Практически единственным исключением был, пожалуй, сезон 2010-2011, когда была написана самая популярная моя статья, про Вконтакте. Были и "ямы" - без притока новых постов у Insight IT остаются только "пассивные" источники новых читателей, поисковые системы да старые входящие ссылки. Динамику спада активности уже обсуждали чуть выше, повторяться не буду.

Если Вы следите за моим Twitter, то Вы уже, вероятно, в курсе, что осенью у меня возникло желание отказаться от WordPress, в основном так как мне очень стыдно от того месива в HTML/JavaScript/CSS коде, которое он генерирует. Еще ко всему прочему это все очень медленно грузится, а плагины, призванные исправить данную ситуацию, в 99% случаев ломают или функциональность, или внешний вид, или и то и другое. К слову, стабильность и совместимость плагинов WordPress - отдельная история, думаю многие из вас наблюдали в октябре-ноябре сообщения о недоступности Insight IT, которые как оказалось в ходе разбора полетов были вызваны эпизодической несовместимостью пары плагинов с (возможно излишне) свежей версией PHP. Статус этой истории с переездом пока на паузе, так как устраивающего меня из коробки решения я не нашел, пока ограничился временными полу-мерами. Но желание по-прежнему осталось - как будет возможность постараюсь снова заняться этим вопросом.

Кстати, во вступлении я обещал затронуть тему будущего Insight IT - у меня уже далеко не раз было желание сделать из него что-то большее, чем просто технический блог. И, возможно, переход с WordPress на какую-то другую платформу сможет этому поспособствовать, но пока за проектом стою только я - врядли что-то кардинально изменится. Но так или иначе будущее Insight IT с самых первых дней всегда определял не я, а вы, читатели, без вас я бы давно забросил это дело.

Так что хочу посоветоваться, каким бы вы хотели видеть Insight IT в следующем году или даже через еще 5 лет, в 2018м? Было бы интересно обсудить в комментариях как просто темы для новых статей, так и возможные направления кардинальных перемен.

До новых встреч!

Web Standards Days

Иван Блинков — Sun, 25 Nov 2012 01:22:00 +0400

Моё сегодняшнее путешествие на еще одну конференцию "для общего развития" закончилось с на удивление хорошими впечатлениями. Не смотря на скучные на первый взгляд названия докладов и общую неоднозначную тематику, мероприятие оказалось очень даже не плохим.

Мероприятие вообще независимое и проводится во многих крупных городах СНГ, в Москве проходило на территории Яндекса, который засветился на единственной имеющейся у меня фотографии (к чему пробел перед запятой не знаю):

Вкратце пробежимся по докладам:

Current work on CSS at W3C (Bert Bos): на первое выступление я опоздал, видел лишь его кусочек из дома через трансляцию. На первый взгляд показалось довольно унылым, чуть не передумал вообще ехать из-за этого. Если первый взгляд оказался обманчивым - поправьте меня в комментариях.
New developments in Semantic Web and Internationalization at the W3C (Felix Sasaki): хоть семантический Интернет - по-прежнему все так же "круто", но никто, даже видимо в самом W3C, так толком и не знает зачем он сдался на практике. В докладе, например, был момент где заявлялось, что <a property="http://creativecommons.org..." href="http://creativecommons.org..."> намного более машино-читабельно (machine readable), чем <a href="http://creativecommons.org...">. А Google, Яндекс и прочие поисковые системы значит, видимо, вручную непосильным трудом миллионов китайцев каждый день строят поисковый индекс, так как компьютерам с атрибутом href самостоятельно разобраться нереально. Если хотите мое мнение: из всех этих "семантических" прибабахов на сегодняшний день самым полезным является стандарт hReview, так как с его помощью можно в выдаче Google напротив страниц своего сайта звездочки рисовать, которые здорово привлекают внимание. Остальные - пока лишь теория и практическую пользу среднестатистическому интернет-проекту принести не могут, буду рад, если расскажете мне в комментариях, почему я не прав по этому вопросу..
Yandex and W3C (Charles McCathieNevile aka Chaals): я уже слышал этот доклад на YaC, из нового Чаальз чуть подробнее показал как выглядит продвигаемый в W3C им и Яндексом prefetch. Если раньше я не придавал ему особого значения, то в этот раз мне это предложение показалось очень адекватным. По сути prefetch.txt - подобный robots.txt файлик в корне домена, в котором в простом формате сайт сообщает браузеру, что такие-то статические ресурсы желательно заранее скачать и на особых условиях локально кэшировать для быстрой работы сайта. Пример. Особо находчивые сейчас воскликнут, что для этого же есть AppCache из HTML5! Да, есть, но из-за обилия лишних заморочек эту технологию очень мало кто умеет нормально "готовить", так что у prefetch есть все шансы со временем вытеснить AppCache. Жаль, что на сегодня поддерживается почти никем, лишь Яндекс.Браузером.
SVGO: оптимизатор SVG (Кир Белевич): если вдруг Вы работаете с этим векторным форматом графики, имейте ввиду, что можно значительно уменьшить его объем и ускорить производительность отрисовки выкинув формальности, не влияющие на отображение, в ущерб, правда, соответствию стандартам. Для этого как раз есть некоторое количество утилит, в т.ч. и обсуждавшаяся SVGO.
Чётко и резко. Новая графика для экранов с высоким разрешением (Вадим Макеев): очень доступно об особенностях верстки под современные мобильные и не очень дисплеи. Основной заключительный трюк доклада я слышал уже в третий раз из разных источников, так как все трое о нем восторженно отзываются, наверное и правда работает. Суть в следующем: если для сайта нужно JPEG-изображение размером XxY, подготавливаем вместо него изображение 2*Xx2*Y и сохраняем его с низким качеством, порядка 20-30% вместо обычных 70-90%. По объему во многих случаях оно может оказаться даже меньше, чем традиционный аналог, но при использовании такого изображения оно отлично смотрится (без видимого размытия и JPEG-артефактов) как на обычных экранах, так и на экранах с высоким соотношением физического пикселя к виртуальному (которые как раз и называют "retina"). Про это соотношение краткая справка: физический пиксель - лампочка на матрице, виртуальный - единица измерения, которая и используется в CSS; у обычных экранов это соотношение равно 1 или даже меньше; у Android бывает 1.5; у "ретиновой" продукции Apple и флагманских смартфонов/планшетов - 2; больше двух тоже бывает, но в природе встречается редко, почти никогда.
Паттерны Javascript (Антон Немцев): доклад и правда об очень базовых вещах в JavaScript, но с шутками и картинками, который все равно позволил мне обнаружить некоторые неудачные моменты в своем клиентском коде. По делу и не скучно.
Grunt. Система сборки для фронтенд-разработчиков (Артём Сапегин): в общем-то заголовок передает всю суть доклада, добавлю лишь, что он полностью на JavaScript и имеет 200+ плагинов на все случаи жизни. Я как-то по старинке пользуюсь для этого webassets, хотя возможно и зря, надо будет по-детальнее взвесить за и против этих двух и подобных продуктов.
Адаптивный веб-дизайн — Что? Где? Когда? (Анна Селезнёва): отзывчивый дизайн (responsive web design) - лишь небольшая часть адаптивного (adaptive). Последний включает в себя не только перераспределение содержимого веб-страниц при разном разрешении экрана, но и приспособление под разные типы управляющих устройств (не только сенсорные экраны, но и стилус, клавиатуры, читающий вслух софт для слепых и пр.), а также по-хорошему к нему же относятся и вещи вроде стилей для печати веб-страниц.
Getting touchy (Patrick H. Lauke): докладчик, видимо на досуге, детально ковыряется в том, каким образом в JavaScript создаются события на основе различных жестов, как эмулируется мышь и прочих подобных штуках. Мораль доклада: для большинства простых сайтов стандартная эмуляция мыши мобильными браузерами вполне достаточна, различные трюки с сенсорными (touch) событиями нужны лишь в определенных элементах (вроде слайдшоу или динамики внутри тега <canvas>), требующих повышенной интерактивности, за которую нужно быть готовыми платить. Платить как местами низкой производительностью, так и ограничением стандартных механизмов браузера - как минимум масштабированием (pinch to zoom) и/или пролистыванием (scrolling).
Технолог — тоже дизайнер (Артём Поликарпов): вся соль доклада лежала в одном его слайде: > "Если дизайнер не показал, как делать что-то, нельзя делать вид, что этого нет". Все остальное было лишь примерами того, как это может выглядеть на практике, в духе как будет выглядеть кнопочка, если её отключить, что делать с чрезмерно длинными заголовками и пр. В обсуждении докладчику досталось за то, что он не обратил внимание на то, что не смотря на всяческие плюсы данного подхода, обязательно нужно быть готовым нести полную ответственность за собственное творчество. Если "технолог" не видит всей картины проекта (а это практически всегда так), подобным "творчеством" можно сильно навредить, особенно если никого не предупредить о его существовании, хотя бы дизайнера, а лучше и всех других заинтересованных лиц.
Круглый стол с экспертами W3C, Яндекса и Opera Software  (все иностранные гости): обсуждались всякие формальности взаимодействия внутри и снаружи W3C и проектов вроде webstandards.org. Ничего практически полезного, к сожалению, "со стола" не унес, думаю, и аудитория и выступающие к тому моменту уже порядком подустали. Разве что был интересный момент о том, что независимому эксперту для попадания в подобные организации необходимо активно тусоваться в тематических группах почтовых рассылок (mailing list), мозолить всем глаза, а также реально заниматься чем-то общественно полезным, что может хотя бы чуть-чуть изменит мир в лучшую сторону.

Вместо заключения повторюсь, что мероприятие вопреки моим ожиданиям оказалось довольно качественным. Подробности по докладам, презентации, может быть даже со временем видео и т.п. см. на страничке Яндекса о Web Standards Days.

По традиции рекомендую подписаться на Insight IT через RSS.

Обзор Riak

Иван Блинков — Tue, 13 Nov 2012 02:09:00 +0400

Riak - распределенная opensource база данных, разработанная на Erlang и спроектированная в расчете на:

Высокую доступность и устойчивость к сбоям;
Масштабируемость и простоту обслуживания;
Универсальность.

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

Высокая доступность и устойчивость к сбоям

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

Масштабируемость и простота обслуживания

Добавление нового сервера тривиально путем копирования конфига и одной команды.
Перераспределение данных и все остальное прозрачно происходит за сценой.
Минимальный рекомендуемый размер Riak кластера - 5 серверов, меньшее количество не дает раскрыть весь потенциал.
Одинаково легко обслуживать как маленький, так и большой кластер.
Есть коммерческая Enterprise версия с поддержкой от Basho, компании-разработчика Riak (изначально выходцы из Akamai), равноправной зашифрованной репликацией между датацентрами и поддержкой SNMP.
Есть встроенный веб-интерфейс для мониторинга и управления кластером, у меня правда так и не дошли руки его освоить:

Универсальность

Схема отсутствует, ключи и данные - произвольные бинарные строки. Ключи располагаются в пространствах имен (bucket).
Сериализация - на усмотрение разработчика, популярные варианты - Erlang'овский BERT, JSON для других платформ, можно использовать просто как файловую систему.
Модульная система хранилищ данных, альтернатив много, основная - Google LevelDB; еще интересный вариант с хранением полностью в оперативной памяти - получается продвинутый распределенный кэш с репликацией, поиском и пр.
Гибко настраиваемое количество узлов кластера, которые должны подтвердить успешность операции, чтобы она считалась успешной: можно указывать для всего кластера, пространства имен и даже конкретного запроса. Riak в любом случае остается eventually consistent базой данных (AP из CAP теоремы), но с возможностью управлять балансом производительности операций и надежностью выполнения запросов.
Три интерфейса доступа (API):
- Google ProtocolBuffers - для основного использования в боевых условиях.
- HTTP REST - для использования в языках, где нет готового клиента на ProtocolBuffers и для того, чтобы по-быстрому что-то посмотреть из консоли через curl. Хотя по факту клиенты для большинства языков программирования есть и проще делать запросы через интерпретатор.
- Еще есть прямой интерфейс Erlang-сообщений, но даже из самого Erlang им пользоваться не рекомендуют, не говоря уже о реализациях Erlang node (BERT) на других платформах.
Вместе с данными хранятся метаданные для разных целей, которые используются в соответствующих типах запросов:
- Векторные часы для разрешения конфликтов версий данных (обязательно, есть автоматическое разрешение);
- Индекс для полнотекстного поиска (концептуально позаимствован у Lucene/Solr, опционально);
- Индекс для простых выборок (по бинарным и числовым полям, опционально);
- Связанные ключи (отдаленный аналог внешних ключей, опционально).
Встроенная поддержка MapReduce, фазы можно реализовывать на Erlang или JavaScript; для обоих языков есть библиотека с наиболее популярными случаями, которые можно использовать для образца.
Есть поддержка выполнения операций до/после операций записи/чтения (hooks), чаще всего используются для построения полнотекстного индекса, но можно реализовать и свои, специфичные для приложения.

Недокументированные возможности

Пока я их нашел всего две:

Счетчики: как такового API в для увеличения/уменьшения числовых значений (increment/decrement) в Riak нет, так как он не лезет внутрь хранящихся данных. Зато есть векторные часы, которые растут с каждой операцией записи по ключу. Чтобы реализовать увеличение (increment) необходимо записать в Riak пустую бинарную строку с опцией return_body, и у вернувшегося значения сложить все поля в векторных часах. Пример на Erlang. Если нужно еще и уменьшение (decrement) этого можно добиться с помощью пары счетчиков "плюс и минус" и вычитать второе значение из первого. Для авто инкремента основных ключей не самый лучший вариант, но для не особо критичных случаев вполне себе работает.
Выборка по списку ключей (multiget): такого API тоже нет, но здесь на выручку приходит MapReduce. Это, пожалуй, наиболее популярное его применение. На вход подаем имеющийся список ключей и используем фазы из готовой библиотеки: reduce_set_union и map_identity. Данные возвращаются неотсортированные и требуют небольшой обертки на выходе, но все равно это намного быстрее, чем последовательно проходить по списку ключей и делать для каждого обычный get. Пример на Erlang.

Буду рад, если Вы поможете мне дополнить этот список, оставив известные Вам подобные трюки в комментариях.

Подводные камни

Если в Вашем приложении необходима функциональность постраничного просмотра отсортированных данных (pagination), то будьте готовы реализовать её на клиенте. То есть Riak быстро сделал нужную выборку всех "страниц" и уже на клиенте её придется отсортировать и выкинуть лишнее. Вообще в большинстве случаев результаты запросов к Riak приходят в произвольном порядке из-за его распределенной природы.
В продолжение к предыдущему: в REST Solr интерфейсе есть аргументы (в ProtoBuf это тоже добавили в одной из последних версий), которые, казалось бы, достаточны для реализации постраничного просмотра: sort, start, rows - что еще нужно? На практике оно работает не так, как было бы логично. Сортировка по значению (заданная в sort) применяется ПОСЛЕ того, как была отсчитана страница по start и rows. Они отмеряются по ключам или рейтингу значения в полнотекстном поиске и никак иначе. С тем же успехом эти 5-10 значений можно очень быстро отсортировать и на клиенте. Зачем-то это может быть и нужно, но в моем случае оказалось совершенно бесполезно.
У Riak есть 4 основных типа запросов: простой get/set, полнотекстовый поиск, вторичные ключи (secondary indices), МapReduce и проход по связанным ключам (link walking).
- Если Ваши данные являются сериализованным JSON, BERT или XML, то в большинстве случаев Вам нужны лишь первые два из них, исключение - упомянутая выше выборка по списку ключей через MapReduce.
- Основной сценарий использования вторичных индексов - метаданные к произвольным неструктурированным бинарным данным, например в случае с аналогом файловой системы. Либо совсем примитивные случаи, когда правда нужно сделать простую выборку по одному целочисленному полю, что бывает редко.
- Если данные сериализованы, то связанные ключи проще хранить внутри данных, а не средствами СУБД. Разницы в производительности нет, в итоге делается тот же MapReduce с теми же фазами.
Хоть Riak "из коробки" и правда надежнее многих других СУБД и 1-2 упавших/отключенных сервера в кластере внешне практически не заметны, есть одно но. Если один узел упал - соединения всех подключенных к нему клиентов теряются. Два основных пути преодоления этого момента:
- Если кластер клиентов и кластер Riak расположены на разных серверах, то между ними можно поставить отказоустойчивый TCP балансировщик нагрузки, в частности HAProxy или IPVS здесь наиболее органично вписываются.
- Если на одних и тех же, то есть вариант поставить балансировщик нагрузки перед клиентами (для веба возможно и в HTTP/HTTPS режиме), а каждый клиент подключается к своему локальному серверу Riak и если один, другой или оба сразу упали, то отрубать весь физический сервер целиком.

Выводы

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

Как уже упоминалось, практически единственный сценарий, где Riak совсем не справляется, это выборки по большим объемам данных с сортировкой и постраничным выводом. Но даже в этом случае никто не мешает использовать отдельный сервис, который будет индексировать нужным образом данные и подготавливать список идентификаторов для последующей multiget выборки из Riak. К слову, проекты по этой части уже появляются, например Yokozuna - интеграция полноценного Solr с Riak (Riak Search - лишь частичный порт Solr+Lucene на Erlang).

Оптимизация интерактивных сайтов

Иван Блинков — Sat, 20 Oct 2012 12:32:00 +0400

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

Оглавление серии "Интерактивные сайты"

Общая архитектура

Организация клиентской части

Постоянное соединение между браузером и сервером

Повторное использование шаблонов

Серверная часть интерактивного сайта и потоки сообщений

Оптимизация

Серверная часть

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

Когда разрабатывается первая версия сайта, то многие части функционала проще всего реализовать в виде массовых рассылок, как-то так: произошло какое-то публично-доступное событие, допустим кто-то куда-то поставил "мне нравится", отправляем его в брокер сообщений с пометкой "доставить всем" (fanout). В итоге все подключенные на данный момент клиенты получают это уведомление и каждый сам решает что с ним делать - что-то менять на текущей странице или просто проигнорировать.

Но при большом количестве соединений и потоке событий такой подход становится роскошью. Большинство подобных ситуаций можно реализовать подпиской на тематические (topic) рассылки для каждого пользователя индивидуально, то есть когда пользователь открывает ту или иную страницу - серверная сторона должна подписать его на уведомления, связанные именно с тем контентом, который находится у него на экране. Это позволит свести к минимуму количество доставленных зря сообщений.

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

Чтобы реализовать индивидуальные подписки как изложено выше, вероятно понадобится еще и изменить принцип установления соединений между брокером сообщений и сервером, поддерживающим постоянное соединение. Для схемы массовых рассылок достаточно одного такого соединения на сервер. Каждый сервер хранит список активных соединений с браузерами и, получив новое сообщение от брокера, просто итеративно проходится по нему, ретранслируя сообщение в каждое соединение. В таком случае для последнего соединения в списке задержка может достигать нескольких секунд, что не всегда приемлемо. Для схемы индивидуальных подписок есть два основных варианта:

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

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

Постоянное соединение между браузером и сервером

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

Межвкладочное взаимодействие (cross-tab communication)

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

Вкратце для тех, кто не в курсе: в самой простой реализации постоянное соединение между браузером и сервером устанавливается для каждой вновь открытой вкладки заново. Так как каждое такое соединение ресурсоемко, то этого хотелось бы избежать. Помочь в этом может организация межвкладочного взаимодействия или, другими словами, общения между вкладками/окнами браузера: одна вкладка избирается главной и устанавливает соединение с сервером, когда она получает новое сообщение - она переправляет его конкретной открытой вкладке или же всем сразу; те же, в свою очередь, когда хотят отправить сообщение на сервер, отправляют его сначала главной вкладке, а та уже пересылает на сервер. В итоге все работает как и раньше, но соединений не больше одного на браузер.

Вообще в явном виде общение между вкладками браузера, как Вы, вероятно, знаете, не предусмотрено. Именно из-за этого реализовать это все кроссбраузерно не просто. Для начала приведу список технологий, которые так или иначе можно для этого приспособить, большинство из них принято относить к нынче модному HTML5, в порядке возрастания моих симпатий:

Flash Local Shared Cookies - даже не рассматривал как вариант, так как требуется Adobe Flash, плюс, кажется, постоянно всплывает окно вроде этого.
postMessage - отправка сообщения указанному окну по его идентификатору. Поддержка браузерами хорошая, но большинство примеров показывают общение с iframe, а сопутствующего API для получения списка всех открытых окон/вкладок я не нашел, может быть плохо искал.
Web Workers - в браузере создается не зависящий от вкладок поток, с которым можно общаться из вкладок. Поддержка браузерами хромает, а там где её нет - polyfill'ов пока не придумали.
Web Storage - локальное хранилище пар ключ-значение с ограничением в 5-10Мб на домен. Хорошая поддержка браузерами, а там где её нет - есть polyfill'ы. Еще бывает Web SQL, но для данной задачи это уже перебор.

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

Если есть желание и время можно работать напрямую с API хранилища, но все же самостоятельно разбираться с особенностями браузеров - занятие не благодарное, так что могу посоветовать взглянуть на имеющиеся opensource библиотеки-обертки. Из тех, что я пробовал, мне больше всего нравится jStorage из-за своей "зеленой" таблицы поддержки браузерами и готовому publish/subscribe API.

Итак, вкратце пройдемся по ориентировочному алгоритму реализации межвкладочного взаимодействия:

Каждая вкладка при своем открытии придумывает себе уникальный идентификатор (проще всего на основе Math.random), будем называть его tab_id.
В хранилище будут храниться список всех активных tab_id, допустим, tabs и tab_id главной вкладки, допустим, master. Каждая новая вкладка смотрит есть ли другие открытые вкладки. Если есть - просто дописывает себя в tabs, если нет - то еще и объявляет себя главной и открывает соединение с браузером.
Далее она подписывается на сообщения отправленные лично ей (по её tab_id) и на различные типы сообщений, которые могут быть интересны всем вкладкам.
В обработчике события window.onbeforeunload (происходит сразу же перед закрытием вкладки) каждая вкладка убирает себя из tabs и если она была главной, то и из master тоже. Альтернативный вариант: master сразу может выбирать себе "преемника". Так как это событие срабатывает не всегда (когда компьютер жестко вырубился питанием, фатальный сбой в браузере, плюс оно не поддерживается неоправданно популярной в рунете Оперой и мобильным Safari), то придется создать альтернативный механизм проверки активности master и очистки tabs.
Так как какого-либо API для проверки открыта ли вкладка по её tab_id по очевидным причинам нет, нужно придумать свою схему. Самый простой рабочий вариант, пришедший мне в голову:
- Главная вкладка пишет каждые несколько сотен миллисекунд в хранилище текущую дату/время, теоретически так как все происходит на одном компьютере, то текущее время во всех вкладках должно быть одно и то же;
- Не-главные вкладки каждые 1-3 секунд читают значение из того же места в хранилище и если оно отстает от текущего на, допустим, больше чем секунду, то главную вкладку, вероятно, закрыли и надо её "свергнуть" - удалить из tabs и master и назначить, например, первую или последнюю запись из списка tabs новой главной вкладкой;
- Если выбранная новая вкладка тоже оказалась уже закрыта, не беда - во всех случаях, кроме совсем неадекватных, этот не хитрый механизм переберет все tabs и найдет-таки нормальную открытую;
- Каждая вкладка подписывается на изменения значения master, чтобы если новое значение совпадет с её tab_id открыть соединение с сервером.
Отправка сообщений происходит по простому publish/subscribe, где master подписывается и ретранслирует в соединение с сервером, а отправляют все остальные вкладки. Если вкладка отправляет запрос, ответ на который хочет получить только она сама (чаще всего переход на другую страницу сайта или отправка формы), то она указывает в отправляемом запросе свой "обратный адрес" в виде tab_id. Master, получив ответ на такое сообщение с указанным обратным адресом, перенаправляет его отправителю.
Также в хранилище полезно иметь переменную-флаг (также с подпиской на изменения), обозначающую открыто ли сейчас где-то постоянное соединение, чтобы вместо того, чтобы отправлять сообщения в никуда вкладки использовали какой-то альтернативный способ (AJAX или переход по ссылке / отправка формы средствами браузера). В качестве альтернативы можно реализовать очередь неотправленных сообщений, но по факту когда с соединением проблемы, то неизвестно когда они устранятся и устранятся ли вообще, так что смысла в ней чаще всего мало.

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

Минимизация размера сообщений

JSON хоть и сильно выигрывает у XML по объему сериализованных сообщений, но все же является текстовым форматом с указанием схемы (название для каждого значения) внутри самого сообщения. Почему минимизация объема передаваемых по постоянному соединению данных - дело полезное, объяснять, думаю, не стоит.

Первое, что приходит в голову, чтобы уменьшить объем сообщений - избавиться от включенной в них схемы, оставив только чистые данные. Изобретать свой формат ни к чему, есть неплохой широко распространенный кандидат в виде Google Protocol Buffers. Кстати, недавно нашел библиотеку с JavaScript реализацией Protocol Buffers с хорошими отзывами, в ближайшее время думаю сам опробую: protojs. Если кто уже работал с ней - буду рад, если поделитесь впечатлениями.

Но на практике оказалось, что эта самая схема обычно занимает максимум 10-20% от сообщения, так как большинство данных все же текстовые. Использование Protocol Buffers было бы намного более выгодным, если бы было необходимо "упаковать" много чисел или флагов, для текстовых данных выигрыш намного меньше.

Экономии в разы можно добиться используя обычные алгоритмы компрессии (или, если так привычнее, архивации) данных. JavaScrtipt "из коробки" этого делать не умеет, но есть полно библиотек на любой вкус и цвет, правда все хромают и чаще всего не кроссбраузерные. Приведу несколько, которые запомнились после вечера, проведенного за изучением данного вопроса:

LZW - есть реализации на большинстве языков программирования, но компрессия не очень сильная (раза в полтора-два в лучшем случае), плюс реализация под интересующий меня Erlang оказалась дико неэффективна по памяти, а на бинарных строках сходу не нашлась.
zlib.js - умеет zlib (deflate) и gzip, но, к сожалению, в моем браузере не могла разжать обратно то, что сжала, плюс объем кода библиотеки очень большой.
js-deflate - не обновлялась уже 4 года, отсутствует документация, но зато в целом работает. Подбирать метод компрессии для серверной стороны пришлось почти экспериментально, оказался zlib (deflate) без заголовков и контрольной суммы (в Erlang встроенная функция zlib:zip). Компрессия примерно в 3-4 раза.

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

По поводу дополнительных вычислительных ресурсов, которые будут потребляться на компрессию/декомпрессию, вопрос, конечно, спорный, в целом надо все мерять и делать выводы. Но если учесть, что почти во всех современных устройствах, даже телефонах, как минимум 1Ггц процессор, а на сервере можно кэшировать уже сжатые данные, то это не особо большая проблема. К слову объем сообщений уменьшается тоже не гарантированно, бывает что "сжатая" версия оказывается такой же или даже чуть больше, чем оригинал. В общем, использовать компрессию нужно осторожно :)

Повторное использование шаблонов

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

Кэширование шаблонов - идеальный пример. Получив от сервера шаблоны он кладет их не только в объект-обертку, но и в локальное хранилище. На сервере помимо самого JSON'а с шаблонами генерируем хэш (md5, sha или crc - не важно) текущей версии. Клиент, когда открывает соединение, сообщает серверу есть ли у него какая-то версия и если есть, то какая, сервер отправляет новую версию в ответ только если хэши не совпали.

Аналогичным образом можно кэшировать и другую редко меняющуюся объемную информацию, например данные для автодополнения в текстовых полях (autocomplete).

Заключение

Надеюсь предложенные в этой статье приемы окажутся Вам полезны. Буду рад, если Вы поделитесь своим опытом и приемами по данной теме в комментариях, а также с удовольствием обсужу подробности.

Эта статья - шестая и заключительная в серии про Интерактивные сайты, автор - Иван Блинков, основано на личном опыте. До встречи на страницах Insight IT!

High Performance Conference aka BitByte 2012

Иван Блинков — Tue, 09 Oct 2012 13:12:00 +0400

Когда я наткнулся в RSS на объявление о данном мероприятии я сразу отнесся к нему скептически: если бы "высокая производительность" (high performance) при разработке высоконагруженных интернет-проектов была первым приоритетом, то самым распространенным языком программирования в вебдеве был бы C или даже Ассемблер, а не PHP. Но судя по заголовкам докладов речь все же была о highload, так что в качестве эксперимента я решил съездить.

Дело было 6 октября в Москве. Сама HPC являлась частью некого фестиваля BitByte. В двух других потоках, как я понял, говорили об HR и стартапах, то есть в коридоре между залами была довольно забавная смесь из толпы студентов и небольшого количества технарей и HRов. Хотя самый большой зал почему-то был у HPC-секции. Организация у всего этого была очень минималистичная, без бейджиков и обеда, хотя с интернет-трансляцией. А вот слайды с докладов до сих пор не опубликовали...

Формат мероприятия был довольно необычный: всего 5 докладов на секцию примерно по часу. Два от Badoo и по одному от организаторов (ITmozg), Моего_Мира@mail.ru и Фотостраны. С одной стороны "длинный" формат хорош тем, что докладчики могли не торопиться и было масса времени на Q&A, но по факту тот же объем информации, что излагался за час можно было бы запросто выдать и за стандартные 15-30 минут - какими-то особыми деталями никто не радовал, а жаль. Но обо всем по-порядку.

Оптимизация MongoDB - DO's and DON'Ts

Даниил Павлючков (ITmozg)

Вообще компания-организатор ITmozg - ~~просто HR-агенство в сфере IT~~ специализированный рекрутинговый онлайн ресурс для IT и Телеком сфер, которое ко всему прочему проводит мероприятия вроде этого. Их сайт не отличается особой популярностью (и, как следствие, нагрузками) и содержит помимо новостей и информации о мероприятиях, что-то типа каталога вакансий и резюме. Он частично разработан докладчиком с использованием MongoDB. Так и родился этот доклад.

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

Основной минус такого рода докладов в том, что слушатели обычно делятся на две категории: если им актуальна данная тема, то довольно вероятно, что они уже читали все то, о чем говорит докладчик, а если не актуальна - то они тем более не слушают.

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

Badoo Desktop: оптимизация приложения на миллион юзеров онлайн

Сергей Аверин aka Xek (Badoo)

Про Badoo думаю у меня уже достаточно информации, чтобы написать отдельную статью (если Вам интересно - дайте знать в комментариях), так что в технические подробности вдаваться особо не буду. Скажу лишь, что у них используется вполне стандартный стек технологий (PHP и MySQL), но реализованный в своем особом стиле, который мне даже сложно как-то конкретно охарактеризовать.

Если кто не слышал, Badoo - довольно крупный международный сайт знакомств (в Top200 сайтов мира по версии Alexa). Сергей рассказывал об их десктопном приложении, которое постоянно висит в трее, поддерживает статус онлайн и доставляет уведомления. И, конечно, серверной части, которая его обслуживает.

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

Доклад пестрил разными историями, советами и примерами, что само по себе очень здорово, но по мне так не хватало какой-то общей "сюжетной линии". Из тех, что запомнились:

Они завели специальный режим для экстренных случаев, когда что-то сломалось или пик нагрузки - они могут сказать всем или части десктоп-приложений отправлять им данные реже, чем обычно. Жаль, для веб-сайтов это чуть менее применимо, но всегда полезно заранее подумать в этом направлении и составить план действий и список возможных мер по снижению нагрузки.
Гоняясь за производительностью кода (внутри PHP), можно выиграть максимум десятки процентов. Чтобы добиться выигрыша производительности в десятки раз, нужно менять принцип того, как работает приложение.
Не раз упоминались разного рода проблемы с таймаутами, но у меня не сложилось четкого впечатления, в чем были их причины и что было сделано для их устранения.
В Badoo довольно либерально относятся к единственным точкам отказа (single point of failure), так что некоторые внутренние сервисы у них все же являются таковыми.

Пуш-уведомление и общая архитектура проекта Мой_Мир@Mail.Ru

Дмитрий Казаков (Mail.ru Group)

Если честно, я все же надеялся услышать хоть что-то стоящее на этом докладе... Наверное в свете того, что я недавно довольно тесно интересовался данной темой, что в итоге вылилось в серию статей "Интерактивные сайты". Но Mail.ru оказались в своем репертуаре: "у нас есть свои крутые технологии, они круче всех на свете, но почему именно мы решили их создать и в чем их преимущества/отличия от общеиспользуемых решений, мы не расскажем". В opensource тоже не дождетесь. Исключение из этого правила пока лишь одно - Tarantool (СУБД, работающая в основном в памяти, чем-то напоминает Redis), но из-за такого их поведения на конференциях я и к этому их opensource проекту подозрительно отношусь.

Сам Мой Мир отдельной статьи явно не заслуживает, так что вкратце:

Perl с модулями на C
Хранение данных с использованием собственной технологии "Silver" и вышеупомянутого Tarantool
Плюс немного memcached, а про самое главное - шину обмена сообщениями докладчик забыл
Для взаимодействия между браузером и сервером используют CometD, видимо тот самый на странноватом Bayeux протоколе

И немного статистики:

7.5 миллионов пользователей
40 миллионов просмотров страниц в день
283.5 миллиона показов в день (видимо, просто хитов включая статику)
1 миллион новых друзей в день (февраль 2011)
25 разработчиков
300 фронтендов
Под уведомления: 12 серверов с 16Гб памяти и 4+1 дисками
10 миллионов уведомлений на сервер, при средней длине уведомления в 116 байт

Как слать 150М писем каждый день

Андрей Сас (Badoo)

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

Из того, что было сказано:

Для отправки почты используется две очереди: одна для генерации писем, другая для их отправки.
Несколько удивил тот факт, что обе они реализованы просто на файлах, как я понял с единственной мотивацией "так надежнее".
Сама отправка через команду mail, вызывающую ssmtp (облегченный аналог sendmail), через собственные MTA.
В качестве MTA используется проприетарный Communigate Pro, который, по их мнению, быстрее и надежнее opensource альтернатив.

Архитектура проекта на 30М пользователей

Дмитрий Смирнов (Фотострана)

Фотострана - не имеющая никакого отношения к фото социальная сеть, в Топ20 рунета по данным LiveInternet, но о которой никто не слышал.

Почти традиционный LAMP стек, за исключением того, что по историческим причинам FreeBSD вместо Linux
Мега-короткий цикл разработки - деплой новой версии каждый час (!), недельные спринты в Agile отдыхают
Тоже написали свою альтернативу Redis, которая, судя по графикам, примерно на порядок его быстрее, но не собираются её опубликовывать
Узкоспециализированные сервера - нет не только смешанных серверов вроде СУБД + сервер приложений, но и разные части проекта (анкеты, поиск, "питомцы" и т.п.) разнесены по разным машинам
Собственная система отдачи статики с двухслойным кэшем и, как я понял, без использования CDN

Заключение

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

По традиции напомню, что если Вы хотите оперативно узнавать о новых статьях об архитектуре высоконагруженных интернет проектов, а также других материалах - рекомендую подписаться на Insight IT через RSS.

Yet Another Conference 2012

Иван Блинков — Sun, 07 Oct 2012 01:08:00 +0400

Осень, сезон конференций в самом разгаре. На этой неделе был на двух, еще несколько предстоит в этом месяце. В этом посте вкратце хочу рассказать о прошедшей в понедельник YAC2012 от Яндекса, чуть позже будет пост и о прошедшем сегодня HPC aka BitByte. На "яке" про highload не было совсем практически ничего, так что если Вас это не смущает - приступим.

Начало

Началось все с презентации Яндекс.Браузера - если в двух словах, то это форк Chromium (как следствие - в основе WebKit) с встроенным Opera Turbo и сервисами Яндекса. Я явно не являюсь их целевой аудиторией, но для не-айтишников совсем не знающих английский - может быть и окажется актуальным. К слову, когда проверял "рабочесть" ссылки узнал, что версии под Linux у него нет, что странно, так как сам Chromium прекрасно работает, им и пользуюсь ежедневно.

Всего на конференции было 4 потока, выбрать на какой идти было не сложно методом исключения:

Я не большой фанат виртуализации, так что "Облачные технологии" вычеркнул первыми;
С математикой знаком лишь по наслышке благодаря гуманитарному образованию, так что на "Интернет-математике" ловить тоже особо было нечего;
Разработка приложений под Android - дело неблагодарное, так что "Yandex Mobile Camp" также не стал моим выбором (кстати, у них якобы запустился "конкурент" Google Play);
В итоге я весь день провел во втором зале с названием "Фронтенд", который ближе к вечеру перетек в "Системное администрирование" - темы хоть и не совсем по моей части, но хочешь-не-хочень, а приходится иметь с ними дело чуть ли не каждый день.

Фронтенд

~~Charles McCathieNevile~~ Chaals (Яндекс) - Yandex and W3C
- В прошлом году Chaals выступал на YAC, представляя Opera и W3C, теперь он работает консультантом в Яндекс по этой же части.
- Соответственно Яндекс недавно стал первым полным участником W3C из РФ, думаю в основном благодаря ему.
- Вкратце про W3C - это международное сообщество компаний, которые сообща предлагают и развивают разного рода стандарты в сфере Интернета. Работа организована в ввиде нескольких десятков узкотематических рабочих групп; каждая из компаний-участников может присоединиться к любой из них выделив под это какую-то часть рабочего времени своих сотрудников. Работа и обсуждения в основном ведутся удаленно по e-mail, но регулярно проводятся и оффлайн встречи рабочих групп.
- Участие платное, ориентировочно: полное участие стоит 70 тыс. евро в год, ограниченное участие для исследовательских центров, государств и т.п. - 7 тыс. евро в год, для стартапов - порядка 1 тыс. евро в год.
- Почти неофициально было сказано, что первым стандартом, который предложит Яндекс будет prefetch карт в браузер.
Александр Чупахин (Яндекс) - Профилирование и ускорение сложных JavaScript-систем на примере API Яндекс.Карт
- Мораль данного доклада: если у Вас в проекте много сложного JavaScript, то его стоит профилировать.
- Собственно карты и прочая разного рода графика - один из немногих use case'ов, где есть большой простор для оптимизации производительности JS. Еще из потенциальных вариантов - клиентская часть при постоянном соединении между браузером и сервером. Для типичных же сайтов это актуально довольно редко.
- Помимо собственной системы тестирования и оценки производительности они пользуются Google Speed Tracer - рекомендую взглянуть, если занимаетесь чем-то подобным.
Jan Jongboom (Cloud9) - The Architect Way
- Выступал на хорошем западном уровне, но не знаю, что он забыл на фронтенд секции. Речь шла об их фреймворке под названием Architect для node.js
Дмитрий Барановский (Adobe) - Raphaёl - past, present and future
- Автор, судя по всему, популярной библиотеки для "рисования" в браузере без флеша и canvas, о ней и рассказывал.
Владимир Агафонкин (Cogniance) - Progressive Enhancement: практичный подход к современной кроссбраузерной разработке
- Докладчик - автор еще одной популярной JS-библиотеки, на этот раз для отрисовки карт - Leaflet, которая используется во многих крупных интернет-проектах, например в foursquare, Flickr и Wikimedia.
- Суть доклада: нужно разрабатывать не для современных браузеров и потом добавлять "костыли" для старых и мобильных браузеров, а наоборот - сначала базовый HTML и функционал, потом базовые CSS и JavaScript, которые будут работать практически везде и дадут 80-90% желаемого внешнего вида и уже только потом реализовывать все более и более навороченные "фишки" из HTML5, CSS3 и прочих нынче модных аббревиатур.
- С данным принципом в целом очень даже согласен, сам стараюсь по возможности в этом "направлении" работать, когда приходится иметь дело с фронтендом. Хотя в базовой HTML версии все же иногда имеет смысл пожертвовать частью функционала, но это уже детали.
Алексей Емелин (Яндекс) - Тестирование "безDOMных" объектов современных веб-интерфейсов на примере API Яндекс.Карт
- Яндекс.Карты реализованы довольно хитрым "многослойным" образом - часть на canvas, часть на DOM-дереве, так что тестировать и правда сложновато.
- Поверхностно показывали закрытую систему для тестирования карт, работает примерно так: "создается новый функционал вручную тестируется -> эта версия берется за эталон -> когда появляется новая версия старого функционала - открываются два окна браузера, в одном запускается эталон, в другом новая версия -> если скриншоты совпали - все ок, если нет - вручную смотрим что не так -> повторяем для всех популярных браузеров".
Константин Горский (Яндекс) - Что разработчикам интерфейсов нужно знать о дизайне
- Довольно доходчиво и с картинками излагалась простая мысль, автором которой, кажется, является Стив Джобс: "Дизайн - это не как что-то выглядит, а как оно работает".
- То есть чтобы стать дизайнером, не нужно заканчивать художественный ВУЗ, достаточно начать думать о том что, как и зачем делают пользователи и как сделать так, чтобы им это все давалось легче и приятнее.

Системное администрирование

Demir Ozgur (Snapfish/HP) - System Administration Automation in High Scale
- Не смотря на многообещающее название, доклад оказался чрезвычайно примитивным. Базовая теория автоматизации админских задач, плюс какие-то общеизвестные байки о Facebook и ком-то еще.
Виталий Антоненко (ЦПИ КС) - SDN - технология удобного управления компьютерной сетью
- Доклад был об OpenFlow - альтернативному открытому протоколу сетевой маршрутизации, основной сферой применения которого, по словам докладчика, являются научные и исследовательские проекты.
- Я думаю, в сфере интернет-проектов он тоже применим, но о прецедентах не слышал.
Владимир Неверов (Яндекс) - Отказоустойчивость и балансировка нагрузки без регистрации и смс
- Основная тема доклада - IPVS, метод балансировки нагрузки по-умолчанию в Яндекс.
- Используется в совокупности с балансировкой на уровне DNS и проприетарными аппаратными решениями.
Владимир Иванов (Яндекс) - Как запускали IPv6 в Яндексе
- Не смотря на небольшие проблемы с дикцией, Владимир живо и интересно закрыл секцию, апплодисменты были более чем заслужены.
- IPv6 уже работает. В большинстве случаев. Но у некоторых интернет-провайдеров он капитально сломан, что может приводить к недоступности сайта у некоторого % пользователей.
- Для минимизации ущерба в Яндекс используют whitelist'ы на DNS серверах, которые выдают IPv6 только пользователям определенных интернет-провайдеров.
- К слову, Google вроде как уже перешел наоборот на blacklist'ы ISP, у которых IPv6 точно сломан. Подробнее тут.

Заключение

Конференция от Яндекса оказалась хороша для общего развития. Но практическая ценность подобных мероприятий все же от года к году неуклонно падает. Организаторам определенно нужно более тщательно фильтровать докладчиков на адекватность и темы на востребованность.

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

P.S.: Я все еще в поисках бесплатного билета на HighLoad++ - если кто может с этим помочь, буду благодарен :)

Вакансии: PHP и Python разработчики в Киеве

Иван Блинков — Thu, 20 Sep 2012 20:16:00 +0400

Вакансии более не актуальны

Киевская команда разработчиков игр для социальных и мобильных платформ Level UP ищет опытных специалистов по веб-разработке на Python и PHP.

Senior Python Developer

Задачи:

Разработка высоконагруженных веб-приложений;
Разработка внутренних и публичных API;
Разработка архитектуры комплексных сервисов;
Конвертирование бизнес-задач в технические решения (R&D).

Требования:

Опыт разработки на Python более 3х лет;
Сильные навыки применения реляционных и нереляционных баз данных;
Опыт в разработке высоконагруженных веб-приложений;
Дружба с Linux и Git;
Хорошее знание клиентских технологий (HTML, CSS, Javascript);
Опыт работы в команде.

Плюсом будет:

Опыт разработки комплексных проектов на PHP или серверном Javascript (node.js);
Опыт разработки инструментов для верстки, автоматизации верстки, шаблонизаторов и пр.

Senior PHP Developer

Задачи:

Разработка высоконагруженных социальных веб-приложений;
Работа в небольшой дружной команде до 15 человек;
Решение нетривиальных задач и создание инструментов для внутреннего использования;

Требования:

Опыт разработки на PHP более 3х лет;
Опыт работы с MySQL и MongoDB;
Опыт в разработке высоконагруженных веб-приложений;
Дружба с Linux и Git;
Хорошее знание клиентских технологий (HTML, CSS, Javascript);
Опыт примененения функционарного и юнит тестирования.

Плюсом будет:

Опыт разработки на Python или серверном Javascript (nodejs).

Условия для обоих вакансий

Зарплата в диапазоне \$2500-4000 в месяц по результатам собеседования;
Полный рабочий день в Киевском офисе, иногородним помощь с переездом;
За успешную рекомендацию специалиста по данным вакансиям компания выплачивает бонус в размере $1000 так что сообщите своим знакомым, кому-то это может быть интересно.

Заинтересовало?

Вакансии более не актуальны

Не лишним будет, если кроме резюме Вы напишите - почему Вам нравится серверная разработка на Python или PHP и почему Вам интересна данная вакансия. Плюс упомяните, пожалуйста, что Вы узнали о данной вакансии через Insight IT.

Архитектура Pinterest

Иван Блинков — Wed, 15 Aug 2012 22:26:00 +0400

Pinterest - по непонятным для меня причинам популярная в определенных кругах социальная сеть, построенная вокруг произвольных картинок чаще всего не собственного производства. Как и Instagram проект довольно молодой, с очень похожей историей и стеком технологий. Тем не менее, Pinterest определенно заслуживает внимания как один из самых быстрорастущих по посещаемости вебсайтов за всю историю.

Платформа

Amazon AWS - хостинг и вспомогательные сервисы
nginx - вторичная балансировка нагрузки, отдача статики
Python - язык программирования
Django - фреймворк
MySQL - основная СУБД
memcached - кэширование объектов
Redis - кэширование коллекций объектов
Solr - поиск
Hadoop - анализ данных

Статистика

3 миллиона уникальных посетителей в день
18 миллионов уникальных посетителей в месяц
4-я по популярности социальная сеть в США после Facebook, Twitter и LinkedIn
Порядка 500 виртуальных машин в EC2
80 миллионов объектов в S3
410Тб пользовательских данных

Развитие

Март 2010

1 маленький виртуальный веб-сервер
1 маленький виртуальный сервер MySQL
Все это в Rackspace, 1 разработчик

Январь 2011

1 сервер nginx для балансировки нагрузки, 4 веб-сервера
2 сервера MySQL с master/slave репликацией
3 сервера для отложенного выполнения задач
1 сервер MongoDB
Переехали на Amazon EC2 + S3 + CloudFront

Осень 2011

2 сервера nginx, 16 веб-серверов, 2 сервера для API
5 функционально разделенных серверов MySQL с 9 read slave
Кластер из 4 узлов Cassandra
15 серверов Membase в 3 отдельных кластерах
8 серверов memcached
10 серверов Redis
7 серверов для отложенной обработки задач
4 сервера Elastic Search
3 кластера MongoDB
3 разработчика
Если кто-то может объяснить зачем им сдался такой зоопарк, кроме как потестировать разные варианты, можете взять с полки пирожок.

Зима 2011-2012

Заменили CloudFront на Akamai - вполне объяснимо, так как у Akamai намного лучше покрытие по миру, а качественный CDN для сайта с большим количеством изображений - чуть ли не залог успеха.
90 веб серверов и 50 серверов для API
66 + 66 MySQL серверов на m1.xlarge инстансах EC2
59 серверов Redis
51 серверов memcached
25+1 сервер для отложенной обработки задач на основе Redis
Кластеризованный Solr
6 разработчиков

Весна-лето 2012

Снова сменили CDN, на этот раз в пользу ранее неизвестного мне Edge Cast. Покрытие по всему миру довольно скромное, так что единственное логичное объяснение, которое мне приходит в голову - не потянули Akamai по деньгам.
135 веб серверов и 75 серверов для API
80 + 80 серверов MySQL
110 серверов Redis
60 серверов memcached
60 + 2 сервера для отложенной обработки задач на основе Redis
25 разработчиков

Выбор

Почему Amazon Ec2/S3?

Очень хорошая надежность, отчетность и поддержка
Хорошие дополнительные сервисы: кэш, базы данных, балансировка нагрузки, MapReduce и т.п.
Новые виртуальные машины готовы за считанные секунды

Почему MySQL?

Очень "зрелая", хорошо известная и любимая многими
Редки катастрофичные потери данных
Линейная зависимость времени отклика от частоты запросов
Хорошая поддержка сторонним ПО (XtraBackup, Innotop, Maatkit)
Надежное активное сообщество
Отличная поддержка от Percona
Бесплатна

Почему memcached?

Очень "зрелый", отличная производительность, хорошо известный и любимый многими
Никогда не ломается
Бесплатен

Почему Redis?

Много удобных структур данных
Поддержка персистентности и репликации
Также многим известен и нравится
Стабильно хорошая производительность и надежность
Также бесплатен

Архитектура

Сlustering vs Sharding

Большую часть презентации, на основе которой написана данная статья (ссылка, если не охота листать до секции источников информации), занимает раздел под названием "Clustering vs Sharding". В связи с путаницей в терминологии пришлось несколько раз перечитывать, чтобы понять к чему они клонят, сейчас попробую объяснить.
Вообще есть два фундаментальных способа распределить данные между несколькими серверами:
- Вертикально: разные таблицы (или просто логически разные типы данных) разносятся на разные сервера.
- Горизонтально: каждая таблица разбивается на некоторое количество частей и эти части разносятся на разные сервера по определенному алгоритму.
С первого взгляда казалось, что они пытаются вертикальное разбиение назвать sharding, а горизонтальное - clustering. Хотя вообще они почти синонимы и на русский я их обычно примерно одинаково перевожу.
По факту же оказалось, что под словом clustering они понимают все программные продукты для хранения данных, которые имеют встроенную поддержку работы в кластере. В частности они имеют ввиду Cassandra, Membase, HBase и Riak, которые прозрачно для пользователя горизонтально распределяют данные по кластеру.
За словом sharding в их терминологии стоит аналогичная схема собственной разработки, использующая огромное количество логических БД в MySQL, распределенных между меньшим количеством ~~физических серверов~~ виртуальных машин. Именно по этому пути и пошли в Pinterest, плюс очень похожий подход используется в Facebook.
От себя добавлю, что хоть при наличии должных ресурсов разработка собственной системы распределения данных и может быть целесообразной, в большинстве случаев на начальном этапе проще основываться на готовых решениях вроде перечисленных выше. К слову в opensource доступны и основанные на MySQL подобные решения:
- Vitess от Google / YouTube
- FlockDB от Twitter
В их проекте данная подсистема развивалась следующим образом:
- 1 БД + внешние ключи + join'ы →
- 1 БД + денормализация + кэш →
- 1 БД + master/slave + кэш →
- несколько функциональных разделенных БД + master/slave + кэш →
- вертикально и горизонтально разделенные БД (по идентификаторам) + по резервные БД (пассивный slave) + кэш
При использовании аналогичного решения остерегайтесь:
- Невозможности выполнять большинство запросов с join
- Отсутствия транзакций
- Дополнительных манипуляций для поддержания ограничений уникальности
- Необходимости тщательного планирования для изменений схемы
- Необходимости выполнения одного и того же запроса с последующей агрегацией для построения отчетов

Остальные моменты

Кэширование многоуровневое:
- Коллекции объектов хранятся в списках Redis
- Сами объекты - в memcached
- На уровне SQL запросы в основном примитивны и написаны вручную, так что часты попадания в кэш MySQL
- Кэш файловой системы - само собой
Еще пара фактов про кэширование в Pinterest:
- Кэш разбит также на несколько частей (шардов), для упрощения обслуживания и масштабирования
- В коде для кэширования используются Python'овские декораторы, на вид собственной разработки, хотя точно не уверен
Балансировка нагрузки осуществляется в первую очередь за счет Amazon ELB, что позволяет легко подключать/отключать новые сервера посредством API.
Так как большинство пользователей живут в США по ночам нагрузка сильно падает, что позволяет им по ночам отключать до 40% виртуальных машин. В пиковые часы EC2 обходится порядка 52$ в час, а по ночам - всего 15$.
Elastic Map Reduce, основанный на Hadoop, используется для анализа данных и стоит всего несколько сотен долларов в месяц
Текущие проблемы:
- Масштабирование команды
- Основанная на сервисах архитектура:
  - Ограничения соединений
  - Изоляция функционала
  - Изоляция доступа (безопасность)

Уроки от команды Pinterest

"Оно сломается. Все должно быть просто." - столько раз уже слышу это наставление, но ни разу не видел разработчиков, которые реально к нему прислушивались.
"Кластеризация - страшная штука." - конечно страшная, большая и сложная. Но кому сейчас легко?
"Продолжайте получать удовольствие." - с этим не могу не согласиться, без удовольствия работать совершенно невозможно в любой сфере.

Источники информации

Scaling Pinterest @ MySQL Meetup
- В презентации можно посмотреть примеры кода и SQL-запросов
- Если кто-то знает где можно посмотреть/послушать запись этого мероприятия - поделитесь ссылкой, пожалуйста
Pinterest Architecture Update
Вакансии в Pinterest

Moscow Erlang Factory Lite 2012

Иван Блинков — Sat, 23 Jun 2012 02:40:00 +0400

Давненько я не выбирался на IT-мероприятия, так что продолжу традицию делиться впечатлениями. Как следует из заголовка она была исключительно про Erlang, причем в самых разных его проявлениях. Недавно я написал пару статей про него, можно найти по соответствующему тегу. Конференция была всего на пол дня, так что пост получится явно небольшой - много времени не займет ;)

Организация

Мероприятие проводили совместно Erlang Solutions (международная организация, которая регулярно проводит подобные Erlang-мероприятия, сертификации и т.п.) и Яндекс. Проходило все в двух шагах от офиса Яндекса, плюс они же занимались собственно всеми организационными вопросами. Единственный представитель Erlang Solutions видимо не знал что в Москве бывают пробки и сильно опоздал, к слову у меня на телефоне его фотка нашлась, заодно можно оценить масштабы мероприятия (весь единственный зал):

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

Еще из косяков к началу конференции никто не удосужился проверить звук и удаленный переключатель слайдов.

А в остальном все ок, простенько и со вкусом. Едем дальше.

Доклады

Яндекс

В Яндексе всего три Erlang-программиста, кажется все присутствовали
Используют свой форк ejabberd примерно пятилетней давности для их мессенджера и пуш-уведомлений:
- С момента своего создания изменения из основной ветки развития не мерджились и обратно выкладываться в opensource не собираются из-за "сильной интеграции с другими сервисами Яндекса"
- Для хранения постоянных данных используют MongoDB, на вопрос почему именно докладчик так честно ответил "не знаю"
- Основная часть доклада ушла на рассказ об оптимизациях внутри самого ejabberd, реализованных в их форке, в частности:
  - Добавили проверку на то, жив ли процесс перед тем как отправлять ему сообщение, изначально ejabberd в этом плане был более оптимистичен и их это по непонятным причинам не устроило.
  - Уменьшили объем используемой оперативной памяти за счет "ленивой подгрузки" части данных, которые редко используются. Из зала, кстати, кто-то добавил что у аналогичного форка от Erlang Solutions повсеместное использование бинарных строк вместо обычных дало очень ощутимую экономию оперативной памяти.
  - И, кажется, объединили принимающий и отправляющий сообщения процессы в один.
- На вопрос о цифрах выдали только порядки: несколько десятков серверов обслуживают несколько сотен тысяч пользователей онлайн.

Fedora Project

Обсуждался вопрос сильного "отставания" доступных по-умолчанию в Linux-дистрибутивах версий Erlang, да и не только Erlang, от последней стабильной. Я думаю очень актуальный вопрос для тех, кто занимается продажей коммерческого софта для Linux, или для тех, кто занимается сборкой и поддержкой пакетов для opensource проектов.

Erlang сделан так, что подход "все свое ношу с собой", существенно проще и удобнее, чем управление зависимостями. Хотя докладчик приводил пример, что CouchDB как раз использует альтернативный подход требования точных версий зависимостей и у них в Fedora были большие заморочки с тем, что они обновили JavaScript-движок на одну версию выше, чем от которого зависела последняя версия CouchDB. Я так и не уловил как в итоге эту ситуацию решили, наверное пришлось оставить в репозитории две версии зависимости или дождаться и обновления CouchDB.

Mochi Media

Вместо рассказа о mochiweb речь шла о различных вариантах как можно реализовать случайный выбор элемента из списка и их слабых и сильных сторонах. Причем для примера использовался не реальный проект, где они подобным занимаются (баннерная сеть), а IRC-бот написанный для развлечения. Да и к Erlang практически никакого отношения, единственной что узнал полезного: стандартный модуль random написан по не самому удачному алгоритму, созданному в начале 80-х, и если это сколько-либо критично для приложения - лучше вместо него использовать crypto или сторонние библиотеки.

Макс Лапшин

Докладчик является, пожалуй, самым активным участником российского Erlang-сообщества, известен в узких кругах как автор Erlyvideo, opensource решения для потокового вещания видео. Рассказывал про какой-то другой проект, в частности о парсере протокола FIX, использующегося на фондовых биржах и отличающегося огромной спецификацией с более чем сотней типов сообщений. Основная идея доклада: если нужно написать много однотипного кода, его лучше сгенерировать, чем копипастить.

К счастью, авторы этого протокола заботятся о разработчиках и публикуют спецификацию в виде XML-файла, который Макс предлагает парсить и генерировать на его основе необходимые .erl файлы, не дерево синтаксиса, а прямо текстовые .erl файлы. В конкретно этом случае ему нужно было из proplist-ов создавать record'ы, а сам парсинг сообщений он решил написать на C. Хотя мне кажется эту конвертацию тоже можно было бы убрать в C.

Алекс Гунин

Это был единственный доклад на 80% на русском, так как попытка начать его на английском закончилась полным провалом. Хотя заголовок у доклада был самый, пожалуй, интересный - "как сделать Erlang по-настоящему распределенным и отказоустойчивым". Основная идея была использовать часть распределенной СУБД Riak, отвечающую за распределение и поиск данных в кластере (Riak Core), для маршрутизации простых Erlang сообщений и по аналогии с несколькими репликами данных запускать несколько копий одинаковых процессов. Для реализации этой затеи они написали совместимые со стандартными модули gen_server2, gen_fsm2 и т.п. (что, кстати, плохая практика - из-за таких названий можно легко столкнуться с конфликтами в пространстве имен модулей, например в RabbitMQ и каком-то еще популярном проекте тоже есть gen_server2, как-то сталкивался)

Задумка явно толковая и думаю для многих систем актуальная, но подробностей очень мало, плюс докладчик очень смутно излагал свои мысли даже на русском. Он не сказал для какой компании он все это разрабатывал, но пообещал выложить саму систему маршрутизации сообщений в opensource. Когда и где - не ясно.

Лев Валкин

Это был последний доклад, где я присутствовал, в оставшейся секции из трех докладов мне совсем ничего не приглянулось, но зато этот мне больше всего понравился. Думаю в первую очередь так как Лев косвенно пропагандировал очень близкую мне тему использования Erlang для создания интерактивных веб-сайтов. Большинство докладов были все же про другие предметные области. Раньше про его компанию Echo ничего не слышал, но список клиентов на главной у них солидный, надо будет почитать на досуге.

Сам доклад был про выбор и оценку языков программирования и связанных платформ по относительно объективным критериям (сообщество, ассортимент opensource библиотек, возможности в тестировании, интроспекции и дебаге, плюшки вроде горячей замены кода и пр.). Правда в итоге все свелось к тому, что главное, чтобы разработчикам нравилось что они делают - иначе как бы не была объективно хороша та или иная технология все равно получится черти что :)

Изначально Лев планировал доклад на тему Erlang vs node.js, но её забраковали организаторы, видимо за холиварность. В итоге она все же местами затрагивалась, да и вопросы после доклада в основном были по ней.

Основные моменты:

Повторное использование кода между серверным JavaScript и клиентским - в большинстве случаев миф.
Легко найти серверного node.js-разработчика, так как все и так уже знают JavaScript - тоже миф, клиентская разработка концептуально сильно отличается от серверной, намного больше node.js-разработчиков приходит с других серверных платформ, а не с клиентского JavaScript.
node.js хоть и сильно проигрывает Erlang по ряду объективных показателей применительно к веб разработке, благодаря своей популярности именно среде молодых веб-разработчиков (во многом благодаря вышеизложенным мифам) сильно угрожает популяризации Erlang в этой же самой среде.

Свое мнение про JavaScript в целом и node.js в частности оставлю за кадром, недавно в одном из постов высказывался уже на эту тему.

Основы Erlang: синтаксис и пунктуация

Иван Блинков — Fri, 22 Jun 2012 01:27:00 +0400

Мои теоретичесие рассуждения о месте Erlang в ~~современном мире~~ Интернете Вы можете почитать в отдельной статье. Если сомневаетесь интересно Вам это все или нет - то прочтите сначала её. Сегодня я постараюсь вернуться с небес на землю и пройтись по азам этого пугающего многих языка программирования. Коротко и по делу.

Установка ничем особым не выделяется, дистрибутив рекомендую брать отсюда, если до сих пор пользуетесь отсутствующей в списке ОС - лучше сначала исправить этот факт.

После установки в $PATH окажутся исполняемые файлы:

erl - одновременно интерактивная консоль и запуск приложений;
erlc - компилятор в байт-код для виртуальной машины BEAM или нативный код посредством HiPE, напрямую использовать не придется практически.

Со всем что будет обсуждаться в этой статье можно эксперементировать просто в интерактивной консоли, которая запускается просто командой erl без аргументов.

Пунктуация

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

Все функции заканчиваются точкой
После каждого выражения в функции - запятая;
Все ветви кода (case, if, ...), кроме последней, заканчиваются точкой с запятой
После заголовка функции и условий ветвления пишется стрелка ->

Маленькая демонстрация:

foo(X, Y) ->
  Z = X * X,
  if
    Y > 0 ->
      Z + Y;
    true ->
      Z - Y
  end.

К слову, функции возвращают результат выполнения последнего выражения, в данном случае оно представляет собой весь блок if, а end обозначает его окончание (не функции).

Синтаксис

Foo - все что начинается с английской заглавной буквы - переменная, специально объявлять ничего не нужно
_ - сам знак нижнего подчеркивания и все что с него начинается - особый случай переменной, значение которой не значимо для программы и при первой возможности "выкидывается"
Цифры в основном как обычно, есть научная нотация в духе 1.23e4 (1.23 умножить на 10 в степени 4) и системы исчисления с другим основанием, скажем двоичная - 2#101010
foo - с строчной буквы начинаются атомы, по сути константы, используются повсеместно:
- названия функций и модулей
- true и false - булевые значения
- ok - типичный результат успешный результат выполнения
?FOO - хоть официально и называются константами, но по сути - макросы, перед компиляцией заменяются на заранее определенный кусок кода
{foo, bar} - кортеж, набор данных фиксированной длины
[foo, bar] - простой однонаправленный список произвольной длины
"foo" - текстовая строка, представленная в виде однонаправленного списка (что не эффективно с точки зрения потребления памяти, до 4 байт на символ)
<<"foo">> - бинарная строка, может содержать что угодно, в.т.ч. и текст; все что не цифры по возможности лучше хранить в этом типе данных.

Сопоставление (pattern matching)

Очень мощная концепция сопоставления используется в Erlang на каждом углу. В базовом варианте работает примерно так:

{ok, Result} = foo().

Если в функции foo все прошло нормально, то она возвращает, например {ok, 123}, и переменной Result окажется лишь значение 123.

Если же возникла какая-то проблема, то она вернет что-то другое, скажем {error, timeout}, приложение столкнется с несоответствием левой и правой части (атомы ok и error разные) и прекращает свое выполнение (если бы было чего выполнять).

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

Списки

Со списками есть три особые операции:

[Head | Tail ] = [1, 2, 3, 4] - вытащить элемент с головы списка, работает по принципу сопоставления, в Head окажется 1, а в Tail - [2, 3, 4]
[1, 2] ++ [3, 4] - конкатенация, результатом будет [1, 2, 3, 4]
[N * N || N <- [1, 2, 3], N > 1] - выглядит замороченно, по сути это обычный отображение (map) с фильтрацией (filter) - то есть выражение перед || применяется к каждому элементу списка, значение которых попадает в переменную N, а после запятой - условие, накладываемое на N; таким образом результат будет [4, 9]

Бинарные строки

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

Binary = <<Integer:64>> - преобразовать целое число Integer в бинарную строку Binary длиной 64 бита (для примера, может быть любой
<<Integer1:32, Integer2:32>> = Binary - распокавать обратно бинарную строку в целые числа, но уже два по 32 бита; чем-то похоже на операцию [H | T] у списков, но намного более гибко
Binary3 = <<Binary1/binary, Binary2/binary>> - конкатенация бинарных строк, результат окажется в Binary3
<< <<(N * N)/integer>> || <<N>> <= <<1, 2, 3>>, N > 1 >> - аналог последнего примера для списков, только для бинарных данных; результат аналогичен - <<4, 9>>; к слову официально это называется binary comprehensions, а для списков - list comprehensions

Заключение

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

Удачного освоения Erlang!

Вакансии: развитие поведенческих технологий в рунете (СПб)

Иван Блинков — Mon, 04 Jun 2012 13:35:00 +0400

Вакансии более не актуальны

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

Если Вы способный IT-специалист из Санкт-Петербурга, всегда мечтали написать систему уровня Facebook или Twitter, на одном дыхании читаете статьи о Google Big Table и хотели бы участвовать в создании полезной системы, возможно, одна из этих вакансий будет Вам интересна:

Системный архитектор
Старший разработчик
Младший разработчик

Система RuTarget использует Real Time Bidding API - аукцион показов рекламы в режиме реального времени. За последние три года эта технология совершила революцию в рекламе на Западе. RuTarget - одни из первых, кто внедряет ее в России. Математический алгоритм принимает 170 миллионов решений о показах в день, за доли секунды распознает посетителя и подбирает полезные для него предложения, используя знания о предыдущих его действиях в сети.

Работа в компании RuTarget - это:

Работа над высоконагруженным рекламным проектом, способным выдерживать в штатном режиме 500 миллионов запросов в день с уровнем доступности 99.9%.
Новейшие технологии и компоненты: Apache Hadoop (+Pig, Hive и Mahout), Map-Reduce, Membase, Memcached, Redis.
Отсутствие legacy-кода и необходимости его поддержки.
Работа в режиме Scrum, TDD.
В коллективе только разработчики. У нас нет менеджеров, которые плохо понимают в программировании, но любят навязывать свое мнение.
Интересные технические и алгоритмические задачи для любого уровня квалификации.

От системного архитектора и старшего разработчика мы ожидаем:

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

Senior Developer / System Architect (Java)

Необходимые навыки:

Опыт программирования на Java в коммерческих проектах не менее 3-х лет
Глубокое понимание OOP, опыт многопоточного программирования
Опыт разработки высоконагруженных сервисов. Глубокое понимание принципов масштабирования и отказоустойчивости.
Знание английского языка на уровне, достаточном для чтения и ведения документации.
Опыт разработки на нескольких языках (желательно C/C++ или JavaScript).
Опыт администрирования Linux-систем.

Дополнительными преимуществами будут:

Общая математическая эрудиция. Знакомство с алгоритмами классификации и кластерного анализа, машинного обучения, data mining.
Участие в разработке рекламных сервисов, систем управления медийной и контекстной рекламой. Знакомство с технологиями RTB.

Senior Software Developer / Data Mining (Java)

Необходимые навыки:

Опыт программирования на Java в коммерческих проектах не менее 3-х лет.
Общая математическая эрудиция. Знакомство с алгоритмами классификации и кластерного анализа, статистики, машинного обучения, data mining.
Опыт работы с частью из следующих алгоритмов: K-Means Clustering, Principal Components Analysis, Decision Trees, Random Forests, Expectation Maximization, Support Vector Machines, Nonlinear Regression And Correlation.
Знакомство с пакетами математического и статистического анализа.
Знание английского языка на уровне, достаточном для чтения и ведения документации.

Дополнительными преимуществами будут:

Участие в разработке рекламных сервисов, систем управления медийной и контекстной рекламой. Знакомство с технологиями RTB.
Опыт создания клиент-серверных или распределенных приложений.
Опыт администрирования Linux-систем.

Junior Developer / Intern (Java)

Для Junior Developer это возможность обучаться в коллективе высококлассных профессионалов, а также приобрести бесценный опыт работы с облачными сервисами. Если Вы учитесь, возможен гибкий график с учетом посещения лекций.

От Вас ожидается:

Вы умеете коротко и ясно излагать свои мысли в устной и письменной форме.
Вы любите работать в команде, умеете выслушивать чужую точку зрения и принимать совместные решения.
Вы понимаете, как выбрать оптимальную структуру данных для поставленной задачи, вы способны рассчитать асимптотическую сложность ваших алгоритмов.
Вы разделяете мнение “язык и платформа для задачи, а не наоборот”.
Фразы “консоль Linux” и “bash-скрипт” вас как минимум не пугают.

Необходимые навыки:

Опыт программирования на Java не менее 1 года.
Понимание принципов OOP.
Знание английского языка на уровне, достаточном для чтения и ведения документации.
Опыт администрирования Linux-систем.

Дополнительными преимуществами будут:

Общая математическая эрудиция. Знакомство с алгоритмами классификации и кластерного анализа, машинного обучения, data mining.
Участие в разработке рекламных сервисов, систем управления медийной и контекстной рекламой. Знакомство с технологиями RTB.
Опыт создания клиент-серверных или распределенных приложений.
Опыт разработки на нескольких языках (C/C++ или JavaScript).

Условия работы

Зарплата по результатам собеседования:
- System Architect от 90 тыс. рублей
- Senior Software Developer от 70 тыс. рублей
- Junior Developer от 30 тыс. рублей
Гибкий график работы.
Комфортные рабочие места, быстрые компьютеры, большие мониторы.
Бесплатные горячие обеды.
Круглосуточный доступ в офис.
Возможность удаленной работы из дома при необходимости.
Полная рабочая неделя в офисе в Санкт-Петербурге.

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

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

Вакансии более не актуальны

Серверная часть интерактивного сайта и потоки сообщений

Иван Блинков — Mon, 04 Jun 2012 05:38:00 +0400

Вернемся к теме интерактивных сайтов с обратной стороны, серверной. В ней есть огромный простор для творчества, так как в отличии от клиентской части отсутствуют ограничения, накладываемыми браузерами. С "простором" же приходит и неоднозначность/неопределенность, вариантов как реализовать одно и то же множество, так что возможно приводимые мной примеры Вам окажутся не по душе - и это нормально, правильный путь не единственный, их много :)

Приступим!

Внутренние сервисы

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

Я не буду здесь особо вдаваться в возможные детали реализации самой бизнес-логики - она практически всегда уникальна, скорее заслуживает внимания её "обертка" - сам процесс, принимающий и создающий внутренние запросы.

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

На практике есть масса способов воплотить эту модель в жизнь, перечислю с пояснениями наиболее заслуживающие внимания на мой взгляд:

Функциональные языки программирования, в Erlang и Scala модель акторов является практически "сердцем" всего языка и связанной платформы; у обоих есть библиотеки для реализации надежных, высокопроизводительных и масштабируемых акторов (OTP и Akka, соответственно). Если не боитесь кардинально отличающейся от нынче модного ООП парадигмы разработки, этот вариант наиболее жизнеспособный, рекомендую.
Асинхронный HTTP-сервер, в частности Tornado и node.js - они основаны на epoll и помимо эффективной обработки HTTP-запросов умеют и эффективно их отправлять посредством идущего в комплекте асинхронного же клиента. При таком подходе по сути получается несколько "уровней" HTTP-серверов, первый из которых публично доступен для общения с внешним миром и в ответ на каждый входящий запрос обращается сразу к нескольким внутренним HTTP-сервисам (вероятно параллельно) и на их основе составляет ответ пользователю. Этот подход одно время активно пропагандировали на конференциях ребята из одного крупного отечественного сайта с вакансиями. Особенным бонусом этого варианта является возможность использовать в роли внутреннего сервиса какую-то старую, доставшуюся по наследству (legacy), систему, которая с одной стороны по-прежнему нужна, а с другой - человек, который в ней разбирался уже давно уволился.
С++ и Thrift - хоть одного из участников этой пары можно легко заменить на альтернативу, вместе они смотрятся наиболее органично: потенциально высокопроизводительная реализация бизнес-логики на С++ плюс проверенная в деле многими крупными и очень крупными проектами обертка для создания серверов и клиентов, легко общающихся из разных языков программирования (речь о Thrift, если не очевидно). Если в команде проекта есть гуру C++ - этот вариант Ваш, в противном случае не рекомендую, т.к. очень легко накосячить.

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

База данных и кэширование

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

Из особенностей хочу отметить более-менее четкое разграничение стабильной информации и свежей, актуальной лишь короткое время. Для социальной сети это могут быть, например, профили пользователей (стабильная) и сообщения (свежая).

В соответствии с этим стоит выбирать хранилище данных и политику кэширования:

Стабильная информация, которая редко обновляется и в тысячи раз чаще читается, прекрасно поддается кэшированию и возможно даже прекрасно будет себя чувствовать в реляционной СУБД.
Свежую информацию вероятно вообще важнее доставить в кратчайшие сроки получателю, а сохранять в персистентном виде можно вообще постфактум для архива, на маловероятный случай когда она повторно понадобится. Про кэширование лучше вообще забыть. Для этого самого "архива" часто используют нереляционные распределенные базы данных вроде HBase, Cassandra или Riak. А про оперативную доставку получателю поговорим в следующем разделе.
Хранилища данных в памяти вроде memcached или Redis с отключенной персистентностью можно использовать независимо для временного хранения каких-то побочных данных (восстановимых производных данных или просто чего-то не особо важного, вроде счетчиков пользователей онлайн).

Потоки сообщений

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

Часть системы, отвечающую за маршрутизацию таких сообщений, обычно назвают брокером сообщений (message broker). Для доставки сообщений в браузер чаще всего используют интерфейс сериализованных данных, подробно обсуждавшийся в одной из предыдущих статей серии. Когда пользователь устанавливает соединение с этим интерфейсом, он, в свою очередь, напрямую или через внутренний сервис регистрируется в брокере сообщений для оперативного получения сообщений, предназначенных соответствующему пользователю.

Предлагаю рассмотреть типичные сценарии маршрутизации сообщений, они довольно просты:

Конкретный получатель, к сообщению (которое обычно никак не анализируется брокером) прикрепляется метка-идентификатор, обозначающий кому именно оно предназначено. Такое сообщение получит только процесс, зарегистрировавшийся с аналогичным идентификатором. Типичный пример использования - личные сообщения от пользователя к пользователю.
Группа получателей, актуально для проектов, где пользователи взаимодействуют не на глобальном пространстве, а разбиты на части по какому-то признаку. Скажем это может быть какой-то B2B сервис и сообщения ходят только между сотрудниками одной компании-клиента. Обычно используется такие же метки, как и при конкретном получателе, только с одной из сторон (обычно принимающей) вместо конкретного идентификатора указывается какой-то паттерн, вроде CompanyA.*.
Публичные сообщения - получают все пользователи, метки не используются. Обычно это уведомления о глобальных для сайта событиях или публикации каких-то материалов.

Реализаций брокеров сообщений есть много разных, общий принцип работы у всех примерно одинаковый и соответствует трем изложенным выше пунктам. Для интернет-проектов очень рекомендую RabbitMQ, в нем эти стратегии маршрутизации называются direct, topic и fanout exchange, соответственно.

Отправлять сообщения через брокер в большинстве случаев будут различные внутренние сервисы в случае возникновения определенных событий (читай: получения ими определенных входящих сообщений и попадания в определенную ветвь алгоритма их обработки). Какую стратегию маршрутизации использовать - тоже на их совести.

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

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

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

Заключение

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

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

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

Эта статья - пятая в серии про Интерактивные сайты, автор - Иван Блинков, основано на личном опыте. До встречи на страницах Insight IT!

Вакансии: команда IT-звезд

Иван Блинков — Fri, 04 May 2012 18:20:00 +0400

Вакансии более не актуальны

Благодаря сайту Insight IT, компания RDM-Soft нашла ОТЛИЧНОГО тимлида! Теперь, тимлидер ищет в свою команду единомышленников и просто IT-звезд.

О компании

История компании началась в 2003 году. С этого момента выпущено много проектов. Некоторыми из них Вы, возможно, так или иначе пользовались. Сейчас запускается еще один проект: SEO-биржа. У Вас есть прекрасная возможность оказаться у истоков будущего хита!

Кто нужен?

Mr. Backend. Он же программист. (вакансия закрыта)
Мастер-ломастер. Он же инженер по контролю качества, проще говоря тестер.
Dr. Frontend. Он же фронтендщик. (вакансия закрыта)

Mr. Backend

Требования

Отличные знания: PHP, ООП, SQL, MVC, ZendFramework (либо альтернатив), Linux.
Опыт работы по специальности: от 3 лет.
Опыт работы в команде.
Желание развиваться и изучать новое.
Отсутствие желания искать работу в ближайшие 3 года.

Задачи

Разработка серверной части проекта. Включает в себя :
- бухгалтерия;
- бизнес-логика;
- статистика;
- различные парсеры.

Мастер-Ломастер (SQA)

Требования

Хорошие знания: PHP, SQL, Linux.
Отличные знания принципов whitebox и blackbox тестирования.
Опыт работы по специальности: от 2 лет.
Опыт работы в команде.
Желание развиваться и изучать новое.
Отсутствие желания искать работу в ближайшие 3 года.

Задачи

Написание юнит-тестов, автотестов.
Тестирование:
- бекенда;
- фронтенда;
- бизнес-логики;
- производительности;
- безопасности.
В общем, тоже очень много интересной работы.

Dr. Frontend

Требования

Понимание, как сделать интерфейс удобным и приятным для пользователя
Отличные знания: HTML, CSS, JavaScript (jQuery, ExtJS или других распространенных библиотек)
Опыт проектирования и реализации пользовательского интерфейса

Задачи

Прототипирование UI сервиса
Реализация спроектированного UI
Разработка расширений для Firefox и Chrome.

Условия

Удаленная работа.
Работа в профессиональной команде.
Полный рабочий день (5 дней в неделю по 8 часов).
Карьерный и профессиональный рост.
Прислушивание к Вашему мнению.
Зарплата по результатам собеседования:
- Mr. Backend: от $1500 до $2000
- Мастер-Ломастер: от $700 до $1500
- Dr. Frontend: от $1000 до $2000

Вакансии более не актуальны

Архитектура Instagram

Иван Блинков — Fri, 13 Apr 2012 20:11:00 +0400

Instagram - всего лишь iOS, а теперь и Android, приложение для обмена фотографиями с друзьями. Последнее время находится на слуху благодаря новости о покупке проекта Facebook'ом за кругленькую сумму. Недавно один из основателей проекта, Mike Krieger, выступил на конференции с докладом о техническом аспекте проекта, который я и хотел бы вкратце пересказать.

Статистика

Начало:

1 сервер слабее Macbook Pro
25к регистраций в первый день
2 разработчика

Сегодня:

40+ миллионов пользователей
100+ виртуальных серверов в EC2, в том числе:
Проект куплен Facebook за 1 млрд. долл
1 миллион регистраций за 12 часов после запуска Android-версии
5 разработчиков

Технологии

Ubuntu Linux 11.04 - основная операционная система
Python - основной язык программирования серверной части
Django - фреймворк
Amazon:
- EC2 - хостинг
- ELB - балансировка входящих HTTP-запросов
- Route53 - DNS
- S3 - хранение фотографий
- CloudFront - CDN
nginx - второй уровень балансировки входящихHTTP-запросов
gunicorn - WSGI-сервер
HAProxy - балансировка нагрузки внутри системы
PostgreSQL - основное хранилище данных
postgis - поддержка гео-запросов
pgfouine - отчеты на основе логов
pgbouncer - создание пула соединений
Redis - дополнительное хранилище данных
Memcached - кэширование
Gearman - очередь задач
Solr - гео-поиск
munin, statsd, pingdom - мониторинг
Fabric - управление кластером
xfs - файловая система

Философия

Простота
Минимизация операционных издержек
Использование подходящих инструментов

История

Забыли сделать favicon.ico до запуска - в первый же день логи пестрили ошибками 404
Для хранения данных использовали просто Django ORM и PostgreSQL (из-за postgis)
Начали с одного слабого сервера, после успешного запуска решили переехать на EC2
Довольно быстро пришлось вынести СУБД на отдельный сервер (виртуальный, естественно)
Количество фотографий продолжало расти и расти, даже самый большой инстанс EC2 не справлялся
Решили вертикально разделить данные на несколько баз, с использованием механизма routers из ORM, параллельно избавившись от внешних ключей
Через несколько месяцев суммарный размер базы данных перевалил за 60Гб и перестало справляться и это решение
Следующим шагом стало горизонтальное разбиение данных (sharding):
Создали несколько тысяч логических баз данных.
Распределили их по существенно меньшему количеству физических серверов (читай: виртуальных машин).
Написали свой механизм определения где искать какую базу данных, с поддержкой миграции (вероятно тоже на основе routers).
По последним данным под PostgreSQL используется 12+12 виртуальных машин с максимальной оперативной памятью (68.4Гб), а также сетевые диски EBS, объединенные в программный RAID посредством mdadm. Это необходимо, чтобы весь массив данных помещался в памяти, EBS не в состоянии обеспечить достаточную производительность.
С некоторыми задачами лучше справляется Redis:
Для каждого пользователя в Redis есть список идентификаторов новых фотографий от других пользователей, на которых он подписан.
При отображении потока новых для пользователя фотографий делается выборка части такого списка, после чего посредством multiget достается подробная о них информация из memcached.
Пробовали возложить на него задачу хранения списков подписчиков, но в итоге вернулись к решению на PostgreSQL с небольшим кэшированием.
В Redis также хранится информация о сессиях.
Несколько фактов о Redis:
- Так как все находится в памяти - очень быстрые операции записи и работы с множествами.
- Является не заменой, а дополнением к основному хранилищу данных.
- Redis хорош для структур данных, которые относительно ограничены.
- Отлично подходит для кэширования комплексных структур данных, где нужно большее, чем просто получить значение по ключу (например - счетчики, подмножества, проверка вхождения в множества).
- Механизм репликации (посредством slaveof) позволяет легко масштабировать операции чтения.
Пользователи синхронно загружают фотографии на медиа-сервер с (опциональными) заголовком и месте на карте, все остальное происходит асинхронно посредством очередей, например:
- Сохраняются гео-метки, обновляется Solr (который впоследствии заменил postgis).
- Идентификатор нового фото добавляется в обсуждавшиеся выше списки для всех подписчиков автора.
Поначалу использовали Apache + mod_wsgi для запуска Django, впоследствии перешли к gunicorn из-за меньшего потребления ресурсов и простоты настройки.
С недавних пор начали использовать Amazon ELB вместо DNS round-robin для первичной балансировки входяших HTTP-запросов, что позволило:
избежать необходимости дешифровки SSL посредством nginx;
ускорить исключение из балансировки проблемных серверов.
Благодаря использованию xfs есть возможность "замораживать" и "размораживать" дисковые массивы при резервном копировании.

Подводим итоги

Многие проблемы с масштабируемостью - результат банальных человеческих ошибок.
Масштабирование = замена всех деталей в машине на скорости 150 км/ч.
Заранее сложно узнать как в основном будут обращаться к данным, без реального использования.
В первую очередь попытайтесь адаптировать известные Вам технологии и инструменты для создания простого и понятного решения, прежде чем бросаться на поиски чего-то нетривиального.
Дополните свое основное хранилище более гибким компонентом, вроде Redis.
Постарайтесь не использовать два инструмента для решения одной и той же задачи.
Оставайтесь гибкими и ловкими = напоминайте себе о том, что на самом деле имеет значение.
Разрабатывайте решения, к которым не придется постоянно возвращаться из-за их сбоев.
Активное юнит- и функциональное тестирование стоят потраченного на них времени.
DRY: не делайте одну и ту же работу несколько раз.
Слабая связанность посредством уведомлений или сигналов позволяет легко менять структуру проекта.
Дисковый ввод-вывод часто оказывается узким местом, особенно на EC2.
Спускаться до C нужно только при необходимости, большую часть работы лучше делать в Python.
Короткий цикл разработки - залог быстрого развития.
Частые совместные рассмотрения кода нужны, чтобы все были в курсе происходящего.
Не изобретайте велосипед.
Окружите себя с толковыми консультантами.
Культура открытости вокруг разработки.
Делитесь с opensource сообществом.
Фокусируйтесь на том, что вы делаете лучше всего.
Вашим пользователям абсолютно без разницы, написали ли Вы собственную СУБД или нет.
Не переоптимизируйте и не предполагайте заранее как сайт будет расти.
Не рассчитывайте, что "кто-то еще присоединится к команде и разберется с этим".
Для социальных стартапов очень мало, или даже совсем нет, нерешимых вопросов, связанных с масштабируемостью.

Источник информации

Упоминавшаяся во вступлении неприлично длинная презентация из 185 слайдов:

На видео, к сожалению, это выступление не записывалось.

Часть информации взята из технического блога Instagram.

Повторное использование шаблонов

Иван Блинков — Fri, 13 Apr 2012 08:00:00 +0400

Лень - двигатель прогресса

Сегодня мы рассмотрим способ, позволяющий немного упростить себе жизнь при создании интерактивного сайта путем повторного использования шаблонов. Визуально результат будет примерно таким же, как при дублировании бизнес-логики в браузере, но ценой существенно меньших трудозатрат на разработку JavaScript-клиента, да и на серверной части тоже. Хотите узнать как это провернуть?

Небольшая ремарка, чтобы не было недопонимания из-за терминологии:

Шаблон (template) : HTML-документ с расширенным набором тегов, которые впоследствии используются для подстановки динамических данных.
Шаблонизатор (templating engine) : библиотека, позволяющая на основе шаблона (использующего определенный синтаксис дополнительных тегов) и динамических данных получить итоговый HTML-документ, пригодный для отображения в браузере.
Рендеринг (rendering) : в данном контексте — процесс, которым занимается шаблонизатор.

Общий принцип

Чтобы сразу в голове сложилась нужная картина, начнем с дополненной схемы из статьи про архитектуру интерактивных сайтов:

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

HTML интерфейс просто разбирает HTTP-запросы, отправляет на его основе сообщение(ия) внутренним сервисам, получает в ответ имя шаблона и данные для его заполнения, с помощью шаблонизатора рендерит итоговый HTML и отдает браузеру или роботу.

Интерфейс сериализованных данных (если он, как и обсуждалось ранее, работает через постоянное соединение с браузером) каждому подключившемуся клиенту первым делом отправляет JSON-объект с шаблонами, по крайней мере если их не особо много, иначе лучше "по запросу". При действии пользователя JavaScript-клиент отправляет сообщение с информацией, на его основе интерфейс сериализованных данных передает то же самое (а может и как-то модифицированное) сообщение внутреннему сервису, также получает в ответ имя шаблона и данные и перенаправляет их клиенту (возможно сконвертировав в другой формат). Клиенту остается передать их своему шаблонизатору и заменить результатом его работы какую-то часть уже имеющегося в окне браузера HTML-документа.

Рендеринг

Шаблонизаторов сейчас доступно огромное количество под любую платформу, с разной производительностью и возможностями, но чтобы воплотить эту стратегию в жизнь подойдут далеко не все. Два основных требования:

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

Да, многофункциональные шаблонизаторы вроде Jinja2 - это очень удобно, но конкретно в данном случае богатый ассортимент возможностей не уместен. Наиболее известный кроссплатформенный шаблонизатор, не обремененный ничем лишним, называется mustache. С его использованием иногда получаются довольно замысловатые конструкции, но зато он отлично подходит под этот сценарий использования и прост как три копейки, изучить можно за 5 минут, рекомендую.

В этой схеме напрашивается использование node.js для реализации HTML-интерфейса, что откроет доступ к многочисленным шаблонизаторам, реализованным исключительно на JavaScript. Тем более кроме рендеринга шаблонов эта часть проекта практически ничего и не делает. В качестве бонуса требование про отсутствие внешних вызовов станет не таким строгим, да и в целом, если минималистичное решение вроде mustache по каким-то идеологическим соображениям не устраивает - любой написанный для node.js шаблонизатор наверняка станет отличным выходом.

Структура шаблонов

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

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

Блока <head> документа
Видимой "шапки" сайта
Сайдбара(ов), если они не сильно зависят от основного контентом страниц
Видимого "подвала" сайта плюс тегов для подключения JavaScript

HTML-интерфейс при чтении их из файловой системы "склеивает" их в полные шаблоны для каждой страницы, просто конкатенацией или с использованием механизмов шаблонизатора. Интерфейс сериализованных данных "заворачивает" шаблоны страниц в JSON (или другой используемый формат) прямо в исходном виде для вставки в блок с основным контентом. Из "общесайтовых" шаблонов браузерному клиенту вероятно могут понадобиться только сайдбар(ы), и то не всегда.

Изменения в остальных частях сайта лучше все же отдать на совесть представлений на основе клиентского фреймворка. В первую очередь это касается изменения <title> и других мета-тегов.

Примечания

При использовании минималистичного шаблонизатора без внешних вызовов будьте морально готовы передавать ему "многоуровневые" объекты для вставки в шаблон. Например, если говорить о постраничной навигации, там, где в продвинутом шаблонизаторе было бы что-то вроде {% pagination(current_page, total_pages) %}, может понадобится не только написать саму верстку (что, в целом, хорошая практика), а еще и передать информацию о точном списке страниц, какая именно из них активная, где пропуски и пр.
Стоит обращать внимание на производительность используемого шаблонизатора. Например, под одну из платформ "официальная" реализация mustache, как оказалось, проигрывает сторонней с отрывом в 2 порядка.
Хоть при таком подходе добиться одинакового внешнего вида страниц при рендеринге серверной и клиентской частью достаточно легко, следить за их соответствием все же стоит - какие-то детали можно и упустить.

Заключение

Как я уже намекал в конце предыдущего материала, обсуждавшийся в этой статье подход не совсем "идеологически правильный", по крайней мере с точки зрения используемого клиентского фреймворка. Модели, вероятно, будут использоваться для хранения библиотеки шаблонов и данных для их рендеринга, а не для объектов предметной области проекта. Представления будут отвечать лишь за рендеринг шаблонов и синхронизацию второстепенных элементов интерфейса. Если Вы все же пойдете по этому пути, хочется, чтобы Вы сделали это осознанно. Альтернативный сценарий создания полноценного JavaScript-приложения для работы в браузере для некоторых проектов по-прежнему может оказаться более предпочтительным.

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

Эта статья - четвертая в серии про Интерактивные сайты, автор - Иван Блинков, основано на личном опыте. До встречи на страницах Insight IT!

Вакансия закрыта: PHP-полководец

Иван Блинков — Thu, 12 Apr 2012 20:52:00 +0400

Вакансия более не актуальна

Компания RDM-Soft приглашает на работу полководца команды PHP-разработчиков (тимлидера).

О компании

Обязанности

Руководство группой разработчиков.
Ставить задачи команде и проверять их выполнение.
Бить по рукам за некачественный код, показывать как правильно писать.
Хвалить, раздавать пряники.
Иногда писать самому.

Требования

Опыт руководства командой разработчиков.
Понимание аспектов мотивации и демотивации программистов.
Опыт программирования от 3-х лет.
Отличное знание PHP5 && MVC && SQL.
Базовые знания JavaScript && HTML.
Базовые знания unix shell.
Опыт работы с svn || git || mercurial.
Опыт работы с redmine || mantis || jira.

Плюсом будет

Навыки работы с NoSQL: MongoDB || Redis || Memcached.
Опыт разработки в области HA и HL.
Опыт применения lean- и agile- методологий в разработке.
Знания таких слов как: ДеМарко, КанБан, Таичи Оно, SCRUM.
Понимание цикла Деминга и SDLС в принципе.

Условия

Удаленная работа.
Гибкий график работы.
Работа в слаженной профессиональной команде.
Зарплата от \$2500 до \$3000 в месяц.

Вакансия закрыта

Постоянное соединение между браузером и сервером

Иван Блинков — Tue, 10 Apr 2012 00:47:00 +0400

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

Сегодня мы рассмотрим основные варианты реализации этого принципа и как он сочетается с обсуждавшимися в предыдущих статьях серии темами.

Транспорт

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

Существуют несколько протоколов и связанных с ними технологий, которые позволяют реализовать постоянное с точки зрения приложения соединение между браузером и сервером, обычно их называют транспортами. Каждый из них обладает разной производительностью, особенностями реализации и нагрузкой на серверную часть. Возможно не полный их список c краткими пояснениями:

WebSocket: пожалуй, самый эффективный с точки зрения производительности и нагрузки на сервер транспорт. Протокол относительно новый, появился в рамках работы над HTML5. Доступен только в очень свежих браузерах, имеет несколько более-менее стандартных версий. Используется одно соединение для обоих направлений обмена сообщениями.
EventSource: появился примерно в то же время, что и WebSocket, но по задумке должен использоваться для получения односторонних уведомлений от сервера. В совокупности с простыми AJAX запросами для отправки событий из браузера может использоваться для двустороннего общения. Но так как он доступен примерно в тех же версиях браузеров, что и WebSocket, со сценариями, когда он оказывался бы более предпочтительным, я не сталкивался. Технически очень похож на следующий транспорт.
AJAX Multipart aka HTTP Streaming: после получения HTTP-запроса от клиента сервер не "отпускает" его и по мере поступления отправляет в него свои сообщения. Для отправки сообщений из браузера при необходимости создается второе соединение.
AJAX/HTTP Polling: в отличии от предыдущего транспорта, сервер закрывает HTTP-соединение после каждого отправленного в него сообщения или по прошествии определенного таймаута (обычно порядка 20-40 секунд). А браузер сразу же после получения сообщения открывает новое соединение, таким образом у сервера по-прежнему практически всегда есть соединение, куда можно отправить сообщения. Хоть по нагрузке на сервер этот вариант самый тяжелый, поддерживают его практически все браузеры.
Adobe Flash: эта платформа может эмулировать поддержку WebSocket при определенном стечении обстоятельств (удачная комбинация Flash-плеера и браузера). Немного нетривиальна в настройке из-за своих особенностей.

По поводу поддержки каждого из них различными браузерами было бы неплохо составить табличку, но на самом деле нюансов там много и многое зависит не только от версии браузера, но и от других обстоятельств, вроде наличия и типа прокси, использования трюков с iframe, наличия Flash-плеера и т.п.

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

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

Абстракция

По сути такие библиотеки состоят из двух частей: клиентской на JavaScript и серверной для одной или нескольких платформ. Клиент определяет какой из доступных в текущем браузере транспортов является наиболее эффективным и с его помощью устанавливает соединение с сервером, который поддерживает несколько протоколов. С точки зрения разработчика интерфейс, ими предоставляемый, не зависит от транспорта и примерно одинаков:

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

При выборе такой библиотеки для конкретного проекта очень большую роль играет его основная серверная платформа: обычно хочется использовать тот же язык программирования для обработки сообщений, что и для реализаций основной серверной части. Чаще всего используется основанный на epoll или аналогах HTTP-сервер, что позволяет поддерживать большое количество пользователей онлайн:

Node.js на JavaScript
На Erlang есть несколько очень эффективных HTTP-серверов:
- cowboy
- misultin
- mochiweb
- yaws
Tornado на Python
netty на Java

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

socket.io: поддерживает практически все возможные транспорты, включая Flash. Основная серверная платформа - node.js, силами сторонних разработчиков есть реализации протокола на других платформах. Имеет спорную репутацию, проект довольно громоздкий, в некоторых ситуациях ведет себя непредсказуемо.
SockJS: очень молодой проект, поддерживает необходимый минимум транспортов, прост в эксплуатации. Относительно стабилен и предсказуем. Серверная часть доступна на node.js, Tornado и cowboy/misultin, активно работают над другими платформами.

Существуют коммерческие решения, абсолютно идентичные по принципу работы и функционалу. Аналогичная обсуждавшимся opensource решениям библиотека дополняется брокером сообщений для организации паттерна "публикация-подписка" и в совокупности с хостингом "в облаках" продается с оплатой за количество переданных сообщений (или по подписке с каким-то лимитом), естественно с нехилой наценкой. Плюсы и минусы очевидны: отсутствие необходимости обо всем этом заботиться против относительно высокой стоимости, потере контроля при сбоях или необходимости изменений, привязке к стороннему поставщику услуг и т.п. Рекламировать их не буду, при желании легко гуглятся, ровно как и оставшиеся альтернативные opensource проекты.

Вернемся к интерактивным сайтам

Надеюсь, только что закончившегося лирического отступления на 3/4 статьи Вам будет достаточно, чтобы составить общее представление о построении постоянного соединения между браузером и сервером, а желательно и определиться с каким-то решением для автоматического выбора наиболее эффективного транспорта в контексте именно Вашего проекта.

Получив примитивный интерфейс в виде "отправить сообщение / отреагировать на сообщение" необходимо определиться с тем, что же мы будем передавать в этих сообщениях и как будем на них реагировать.

С форматом сериализации сообщений все довольно просто: выбор между XML и JSON очевиден в пользу последнего, а заморачиваться с чем-то более экзотическим смысла мало (хотя давно хочу попробовать в этой роли Protocol Buffers или BSON, но никак руки не доходят).

Намного интереснее вопрос о том, что, собственно, будет в этих сообщениях содержаться. В предыдущей статье мы остановились на использовании фреймворка для организации кода JavaScript-клиента. Предлагаемая ими концепция модели обычно по-умолчанию предоставляет возможность синхронизации с сервером посредством AJAX запросов и механизм изменения этого поведения. Для использовавшегося в качестве примера Backbone.js для этого необходимо переопределить функцию Backbone.sync. При сохранении модели клиент будет отправлять объект с идентификатором модели и списком её изменений. Запрос изменений с сервера будет происходить асинхронно, то есть после отправки сообщения о том, что нужны данные для такой-то модели, посредством метода fetch он сам не получит ответа. Собственно изменения в модели произведет обработчик получения сообщений, в котором должна быть реализована соответствующая логика. Далее подписанные на события изменений в моделях объекты-представления будут соответствующим образом обновлять DOM-дерево страницы, отображая пользователю нужную информацию. Это, пожалуй, наиболее правильный способ интегрировать постоянное соединение и клиентский фреймфорк.

Основными минусами его является очень серьезный объем работы по разработке клиентской части, а также дублирование достаточно большой части логики и HTML-шаблонов между серверной и клиентской сторонами. Я бы рекомендовал использовать этот подход, только если позволяют трудовые ресурсы (читай: есть хотя бы отдельный специализирующийся на JavaScript разработчик), либо когда проект по каким-то причинам решил отказаться от реализации статичного HTML-интерфейса.

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

Эта статья - третья в серии про Интерактивные сайты, автор - Иван Блинков, основано на личном опыте. До встречи на страницах Insight IT!

Клиентская часть интерактивного сайта

Иван Блинков — Fri, 06 Apr 2012 21:17:00 +0400

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

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

Организация кода

Сборка

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

На вопрос "Какую систему сборки использовать?" в большинстве случаев правильный ответ: ту же, что и для сборки серверной части. Make, rake, maven, ant, rebar... - любому из них без труда можно поручить эту задачу. Для конкатенации можно использовать хоть консольную команду >>, для минимизации есть много альтернативных библиотек, в порядке моих симпатий:

Если хочется чего-то более гибкого, могу порекомендовать воспользоваться Webassets, который я уже упоминал в статье про Jinja2. В консольном режиме прекрасно подключается к любой системе сборки и языку программирования. Описать процесс сборки JavaScript и CSS можно очень подробно и именно так, как считаете нужным, естественно на Python. Сопоставимый по возможностям проект из мира Ruby - Asset Packager, наверняка есть много других.

Читабельный код

Не знаю как Вы, а я тихо ненавижу JavaScript все ~10 лет, которые я с ним знаком. Так как он по сути является монополией на рынке браузерных приложений (Flash, Java апплеты и ActiveX за альтернативы можно даже не считать), использовать его так или иначе приходится в любом сколько-либо серьезном интернет-проекте. Даже Google Dart вряд ли всерьез приживется.

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

Если Вас тоже не раз посещали подобные мысли, то Вы вероятно как и я при первой же возможности пересядете (или уже пересели) на CoffeeScript, компилируемый в JavaScript язык программирования. Немного рекламы этого проекта:

Золотое правило CoffeeScript: "It's just Javascript" (это просто JavaScript)
Прямое преобразование кода в JavaScript
Доступны абсолютно все JavaScript-библиотеки
Никаких точек с запятой в конце каждой строки
Структурирование кода на основе отступов, как в Python
Объявление функций просто стрелочкой ->
При вызове методов даже скобки писать не обязательно

Человеческое наследование: простое class MyClass extends MyParent превращается в довольно хитрую конструкцию с использованием прототипов и замыканий:

MMyClass = (function() {
    __extends(MyClass, MyParent);
    function MyClass() {
        MyClass.__super__.constructor.apply(this,
            arguments);
    }
    MyClass.prototype.initialize = function() {};
    return MyClass;
})();

Много укороченных команд ветвления кода (if, switch, циклы и т.п.)
В целом код выходит раза в полтора-два короче и намного приятнее для глаз
Консольный компилятор с функцией наблюдения за директориями
Легко подключается как фильтр в Webassets
Подробнее с примерами на официальном сайте
В общем рекомендую :)

Логическое разделение кода

Если Вы сталкивались со сколько-либо сложным пользовательским интерфейсом "на jQuery", то скорее всего не по наслышке понимаете откуда взялось выражение "спагетти-код". В связи с событийной парадигмой разработки браузерных приложений, очень часто JavaScript-код с использованием jQuery или альтернатив превращается в так называемый "коллбек на коллбеке, коллбеком погоняет" (коллбек - транслит от английского callback - обработчик события). При отсутствии четкой структуры такой код становится очень сложно поддерживать при его увеличении в объемах. Но это не повод отказываться от jQuery - от событий никуда не деться, и эта библиотека отлично справляется с абстракций от особенностей их реализации в различных браузерах.

На мой взгляд, одним из наиболее резонных способов решения (или заблаговременного предотвращения) этой проблемы является использование в разумных пределах объектно-ориентированные возможности JavaScript (благо CoffeeScript это дело сильно упрощает). Соответственно, используемые классы можно разумно располагать в какой-то иерархии с точки зрения наследования (для обеспечения DRY, don't repeat yourself - "не повторяйся") и с точки зрения расположения в файловой системе (с разложенными по папкам файлами работать намного проще, чем с здоровенной вереницей обработчиков событий в одном файле).

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

Модель (Model) - как и в традиционном MVC представляет собой класс, объект которого содержит локальную копию каких-то данных и предоставляет механизмы для её синхронизации с внешним хранилищем. Основное отличие от серверных моделей - хранилищем выступает не СУБД, а либо локальное хранилище браузера через HTML5, либо удаленный сервис через REST или другой интерфейс. Плюс так как они находятся вне "зоны доверия", то полученные от них данные нужно обязательно валидировать, фильтровать и проверять на серверной стороне, прежде чем что-либо с ними делать.
Представление (View) или контроллер (Controller) - тут, по моим впечатлениям, образовалась путаница и за обоими названиями в нашем контексте имеют ввиду примерно одно и то же. Объект такого класса следит за изменениями и событиями в связанных с ним моделях и элементах DOM, каким-либо образом на них реагируя. Таким образом большая часть кода, которая раньше была "вереницей обработчиков событий", оказывается методами этого класса. При этом базовый класс из библиотеки берет на себя нормальное поведение this и следит за тем, чтобы обработчики автоматически добавлялись на динамические созданные элементы DOM.
Маршрутизатор (Router) - следит за состоянием адресной строки и позволяет обрабатывать изменения, понадобится для восстановления поведения браузера.
Коллекция (Collection) - отсортированный набор однотипных моделей, с которым можно работать как с единым целым.

Не стоит рассматривать эти абстракций как единственный верный способ делать клиентские приложения, но при их использовании появляется хоть какая-то логика и становится более-менее понятно где какой кусок кода должен находиться и где его потом искать. Для абстракции особенностей реализаций браузеров они по-прежнему полагаются на $ в виде jQuery или Zepto.

Мне известны три библиотеки, предоставляющие большую часть изложенных выше абстракций. Вкратце о каждой:

Backbone.js - самая широко распространенная из трех, используется во многих серьезных проектах. Основана на библиотеке Underscore.js, которая с одной стороны предоставляет массу удобных функций и шаблонизатор, но с другой стороны - не особо-то и часто они оказываются нужны.
Spine.js - библиотека по-моложе, которая очень похожа на Backbone.js, но написана на CoffeeScript и из-за отсутствия внешних зависимостей вышла компактнее. Отличия в основном в терминологии и деталях реализации.
Knockout.js - эта библиотека пропагандирует использование data-* атрибутов из HTML5 для хранения метаданных, которые как-то управляют изменениями тегов-владельцев при определенных событиях, практически забирая на себя роль представления. Концепция кажется мне мутноватой, так что лично для себя я её использование всерьез и не рассматривал никогда.

Когда в этой статье дело будет доходить до примеров кода, я буду приводить их на основе Backbone.js, так как в свое время я остановился именно на ней. Почему? В основном из-за того, что она используется в очень многих проектах и стоит за ней целая компания, а не просто один разработчик, которому однажды может надоесть поддерживать проект (как в случае с Spine.js). Но в глубине души я, конечно, надеюсь, что однажды они уберут эту жесткую зависимость от Underscore.js, а то и может быть тоже перепишут все на CoffeeScript.

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

Обработчики событий

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

Напомню, то, что раньше было просто независимым обработчиком событий становится методом представления (по терминологии Backbone.js). У каждого представления создается "оглавление" методов-обработчиков в атрибуте events. Наверное многим хотелось бы увидеть какой-то пример кода, но так как статьями с примерами примитивных приложений на Backbone.js пестрит весь Интернет, тратить на это время желания совершенно никакого, сошлюсь на самый популярный: список задач TODO, для сравнения то же самое на Spine.js. К слову, при использовании CoffeeScript использовать стандартный механизм Backbone.****.extend({ ... }) не обязательно, class MyClass extends Backbone.**** прекрасно делает то же самое.

По мне, так намного интереснее не какие именно события обрабатываются (все равно 90% уникальны для проекта), а как их распределить по разным представлениям. Обычно получается что-то в этом духе:

Пользовательское представление будет модифицировать страницу в тех местах, где оно как-то связано с текущим пользователем: форма авторизации, надпись "Привет, ****!", кнопка выхода и пр. Вероятно, оно будет использовать модель текущего пользователя или в тривиальных случаях просто самостоятельно работать с cookie сессии.
Классы модели и представления, а вероятно и коллекции, понадобятся каждой логической сущности, которая каким-либо образом отражается в пользовательском интерфейсе. Это может быть что угодно, например задача в TODO-списке, статья, комментарий - все зависит от тематики проекта.
Если навигация по сайту каким-то образом динамически видоизменяется, то представление понадобится и для нее. Например, часто подсвечивают пункты в глобальной навигации на основе изменений в текущем адресе страницы.
И, последний пункт, который собственно и относится к сегодняшней теме - одно представление будет общим для всего сайта и будет отвечать за его интерактивность. Давайте его рассмотрим подробнее.

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

События клика на ссылки: по содержимому атрибута href нужно определить, что ссылка внутренняя и вызвать "цепную реакцию" в других представлениях, чтобы в итоге пользователь увидел то, что должен.
При отправке формы есть два сценария:
- Обновляется связанная модель и синхронизируется с сервером. В таком сценарии при необходимости можно вообще скрыть кнопку отправки и "автосохранять" изменения в модели.
- Связанной модели по каким-то причинам нет и нужно просто на основе данных формы что-то сделать, например выполнить поиск по указанной в форме фразе или отправить запрос на авторизацию.
Для отмены стандартной реакции браузера на события у jQuery есть два основных механизма: event.preventDefault() и return false. В данной ситуации (да и большинстве других), целесообразнее пользоваться последним, так как если вдруг в коде обработчика окажется какая-то ошибка, то пользователь просто увидит стандартную реакцию браузера, а не окажется в ситуации "некликающихся ссылок" и "неотправляющихся форм".

Восстановление поведения браузера

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

И первое, с чего стоит начать - с адресной строки, именно там должен появиться тот адрес, который был в href ссылки и action формы. Но на самом деле проще сказать, чем сделать:

Возможность просто полностью поменять текущий адрес в адресной строке из JavaScript без инициализации открытия страницы есть только в совсем свежих браузерах посредством HTML5 History API (pushState).
В старых браузерах переходы между внутренними страницами сайта можно эмулировать через изменения якоря ссылки, который в URL идет после # и обычно используется для "перелистывания" на середину HTML-документа. Для отслеживания таких изменений используется событие onhashchange.
В еще более старых браузерах это событие эмулируют разными трюками с iframe и setInterval.

Backbone.history.start() берет на себя абстракцию изменений в адресной строке, правда поддержку pushState нужно явно включить в аргументах. Заодно восстанавливается нормальное поведение кнопок "Назад" и "Вперед" в браузере.

Для обработки и создания событий, отражающихся в адресной строке, нужно сделать подкласс Backbone.Router. C ситуациями когда их имеет смысл создать несколько, я не сталкивался. По аналогии с серверными фреймворками в атрибуте routes задается соответствие паттернов адресов к методам-обработчикам, которые будут выполниться при переходе. В них вызываются необходимые изменения в коллекциях, моделях и представлениях, чтобы привести в нужное состояние текущий документ.

Для инициации "виртуального" перехода на новую внутреннюю страницу нужно вызвать метод navigate у нашего объекта-маршрутизатора, первым аргументом передав её адрес без первого /, а вторым - настройки:

trigger - вызывать ли обработчик из маршрутизатора?
replace - добавлять ли страницу, с которой мы уходим в историю браузера, чтобы можно было на нее вернуться при нажатии кнопки "назад"?

Таким образом, во внутренних ссылках мы используем нормальные относительные URL, начинающиеся с /. По ним будут нормально ходить роботы и браузеры без JavaScript. В обработчике кликов на них мы:

проверяем правда ли она внутренняя (начинается ли она с /);
"отменяем" стандартный переход, вернув false;
вызываем router.navigate(href.substring(1), {trigger: true}).

Осталась еще несколько атрибутов поведения браузера, которые необходимо починить, чтобы визуально все выглядело "как обычно":

Клик по ссылке с зажатым Shift должен открывать её в новом окне, а с зажатым Ctrl или при клике средней кнопкой мыши - в новой вкладке. Довольно не хитро делается на основе атрибутов объекта-события, который передает обработчику jQuery (button, shiftkey, metakey), для открытия окна или вкладки - window.open.
Если пользователь сделал какое-то действие, а прореагировать на него мгновенно не получается (так как что-то грузится, вероятно) - нужно включить курсор ожидания, установив в CSS cursor: wait, и, желательно, анимированный favicon.ico. И, соответственно, вернуть все как было, когда страница примет нужный вид. Для смены favicon до сих пор пользуюсь каким-то довольно старым плагином к jQuery, который не особо шикарно, но все же работает. Его сайт, видимо, накрылся, так что продублировал: https://gist.github.com/2320740, если кто знает более адекватные альтернативы - дайте знать в комментариях, пожалуйста, руки поискать все никак не доходят.

Синхронизация состояния

По-умолчанию Backbone.js предлагает хранить все состояние клиента в моделях и синхронизировать его с серверным посредством реализации простенького REST API на сервере (подробнее), к которому запросы отправляются посредством обычного $.ajax. Чтобы инициировать процесс нужно вручную вызвать у экземпляра модели метод fetch, чтобы обновить клиентское состояние данными с сервера, или метод save, для обратного процесса.

Для многих приложений этого, в целом, достаточно. Но ограничение очевидно - нет возможности мгновенно узнать, что на сервере что-то изменилось. Чего-то близкого можно достичь вызовом fetch раз в N секунд для каждой модели, но если пользователей предполагается хоть сколько-либо много, нагрузка на серверную часть будет неоправданно велика.

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

Эта статья - вторая в серии про Интерактивные сайты, автор - Иван Блинков, основано на личном опыте. До встречи на страницах Insight IT!

Архитектура интерактивных сайтов

Иван Блинков — Wed, 04 Apr 2012 01:05:00 +0400

В анонсе серии статей "Интерактивные сайты" я постарался максимально доходчиво изложить свою мотивацию к ей созданию, да и актуальность самой темы, так что сразу к делу!

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

Сразу хочу предупредить, что далеко не всем сайтам такая глобальная интерактивность пойдет на пользу. Если пользователи сайта редко что-либо делают и большую часть времени читают длинные тексты, то, вероятно, этот проект как раз из этой категории: быстрота реакции на клик не так радует, когда большую часть времени приходится работать скроллом. Если Ваш интернет-проект является сайтом с длинным контентом в формате блога, новостей или вики - подумайте лишний раз, прежде чем переделывать весь сайт, вероятно будет достаточно интерактивных комментариев и голосований на AJAX. Для социальных сетей, сайтов знакомств, интернет-магазинов, поисковых систем, корпоративных сайтов и многих других визуально заметная интерактивность определенно станет одним из ключевых конкурентных преимуществ.

В этом посте я постараюсь нарисовать крупными мазками картину того, как этого можно достичь. Визуально её я представил следующим образом:

Общие замечания

Здесь и далее я буду описывать "среднестатистический" интернет-проект, в зависимости от специфики могут появляться дополнительные компоненты или убираться за ненадобностью упомянутые. Например, если известно, что пользоваться сайтом будут только сотрудники какой-то компании, то помимо замены Интернета на Интранет, можно запросто избавиться и от HTML-интерфейса и всего, что с ним связано - никаким роботам доступ к нему не нужен.
Наверное стоит прямым текстом сказать, что:
- Голубые элементы - компоненты проекта, а серые - внешние.
- Связи в виде прямых линий означают двусторонний обмен данными, транспорт и формат пока особо не важны.
- Схема логическая, так что вопросы балансировки нагрузки, отказоустойчивости, репликации и т.п. остались в стороне; за каждым блоком может стоять произвольное количество серверов.
Я решил не загромождать схему мониторингом, резервным копированием, почтой, сервисом доменов и прочими хоть и важными, но не связанными напрямую с темой компонентами системы.
В этом посте не будет никаких конкретных примеров реализации и технологий, оставим это на следующие статьи.

Клиентская часть

Начнем наше путешествие. Пользователь вводит в адресной строке браузера адрес нашего сайта и жмет Enter, инициируя тем самым сначала определение IP-адреса через DNS, а затем и HTTP-запрос к нашему HTML-интерфейсу.
Получив в ответ страницу в формате HTML браузер начинает загружать указанные в нем внешние ресурсы, в том числе и Javascript-клиент, которому и передается слово. Сама страница параллельно отрисовывается как и в статичном сайте.
Как уже упоминалось выше, некоторые проекты решают не тратить силы на поддержку двух интерфейсов к сайту, жертвуя тем самым доступом большинства роботов и браузеров без поддержки JavaScript. Стартовый HTML-документ в этом случае превращается просто в практически пустой статичный файл, который служит лишь для загрузки клиента.
Так как наша цель стоит в интерактивном взаимодействии пользователем, повторять эти действия при каждом переходе на другую страницу - непозволительная роскошь. Кстати, можно начинать думать и общаться не в терминах страниц, а в терминах экранов, которые видит пользователь.
Для обеспечения этого JavaScript-клиент должен переопределить стандартные обработчики событий перехода по внутренним ссылкам сайта и отправки форм. Ему нужно отменить стандартный механизм перехода на другую страницу и вместо него отправить запрос через интерфейс сериализованных данных. На основе полученного в ответ сообщения он меняет какую-то часть загруженного ранее HTML-документа, чтобы он соответствовал тому экрану, который ожидал увидеть пользователь. В итоге пользователь видит в браузере ровно ту же картинку, как если бы он ввел тот адрес, на который вела нажатая ссылка, или просто нажал на нее с отключенным JavaScript.
Важно не сломать при этом поведение браузера: кнопка "назад" должна работать как обычно, а в адресной строке должны меняться ссылки (это актуально, например, когда пользователь отправляет содержимое адресной строки кому-то по почте или через мессенджер).
При ожидании ответа от сервера стоит эмулировать курсор и иконку загрузки страницы, чтобы пользователь не паниковал в случае (пускай и редком) визуально заметных задержек.
На резонный вопрос "Почему, собственно, этот трюк обеспечит интерактивность?", ответ хоть и не всегда однозначен, но он все же есть:
- Сериализованные изменения страницы занимают меньший объем, чем полный HTML со всеми связанными ресурсами, заголовками, версткой и прочим - значительно меньше данных нужно передавать по сети.
- Как правило, есть возможность держать постоянное соединение между браузером и интерфейсом сериализованных данных, что позволяет не делать лишние HTTP-запросы. Обратная сторона медали - это самое соединение постоянно же использует часть серверных ресурсов, но есть способы минимизировать эти издержки.
- Для некоторых действий изменения HTML не требуют ответа сервера и могут быть сделаны параллельно с отправкой запроса (например различные вариации на тему +1 или написание комментария, текст которого можно взять из формы).
- Как правило, можно предсказать наиболее вероятные переходы по экранам и загрузить необходимые изменения заранее. Хотя этот вопрос скорее из области оптимизации.
- Таким образом, в большинстве случаев есть техническая возможность снизить время отклика на действие пользователя с 500-2000 мс в случае неплохо сделанного статического сайта до 20-200 мс., что вполне сопоставимо с откликом десктопного приложения.
Как все это сделать на практике - тема следующей статьи из серии.

Серверная часть

С серверной точки зрения основным отличием является четкое разделение двух входных точек:
- HTML-интерфейс отдает готовые документы в ответ на HTTP-запросы.
- Интерфейс сериализованных данных использует какое-то постоянное соединение, хотя в некоторых случаях целесообразно ограничиться просто асинхронными HTTP-запросами.
Если для статичных сайтов полное выделение бизнес-логики в отдельные сервисы - просто хорошее архитектурное решение, то для интерактивных сайтов - это практически необхохимо. Иначе придется реализовывать и поддерживать две копии кода для каждого интерфейса и надеяться, что они постоянно будут оставаться совместимыми и выдавать одинаковый результат.
Хорошей практикой является использование какого-то одного протокола общения между компонентами системы, в частности пользовательских интерфейсов с сервисами бизнес-логики и последних друг с другом. Желательно использовать что-то бинарное и с поддержкой разных языков программирования, хотя если весь проект на одной платформе и не планирует это менять - можно использовать и стандартный для этой платформы протокол.
Чтобы не включать элементы верстки при передаче через интерфейс сериализованных данных, рекомендую использовать кроссплатформенный формат HTML-шаблонов. Об этом будет отдельная статья.
Интерфейс сериализованных данных при необходимости легко может быть адаптирован для использования в роли API для сторонних сервисов или собственных приложений для мобильных платформ или настольных компьютеров.
В целом внутренние сервисы общаются с остальными располагающимися на серверной части компонентами системы вполне обычным образом.
В статье про серверную часть подробно будет рассматриваться использование брокера сообщений для уведомлений пользователей в реальном времени.

Подводим итоги

Глобальная интерактивность сайта требует использования достаточно сложного и комплексного JavaScript-клиента и создания дополнительного более легковесного внешнего инетрфейса на серверной части.
По-настоящему мгновенной реакцией сайта смогут насладиться лишь пользователи с современным браузером и относительно широким интернет-каналом. Из-за возможных сетевых задержек или особенностей устаревших браузеров эффект мгновенного перехода все же может теряться, но при должном тестировании реально добиться нормального поведения сайта и в таких ситуациях. Хотя зачастую "проваливание" до обычного режима статичных страниц в подобных ситуациях - вполне резонное решение.
Архитектура серверной части проекта в большинстве случаев не требует существенных изменений. Хотя если в ней все было хаотично и не продумано, то создание интерактивного клиента может послужить неплохим поводом пересмотреть и привести в порядок и её.
Кроме очевидной потребности в использовании JavaScript для клиента, особых ограничений на используемые технологии и языки программирования, обсуждаемая схема не накладывает.

Эта статья - первая в серии про Интерактивные сайты, автор - Иван Блинков, основано на личном опыте. До встречи на страницах Insight IT!