На чем написан вконтакте
На чем написан вконтакте
Платформа
Статистика
Архитектура
Общие принципы
Волшебная база данных на C
Этому продукту, пожалуй, уделялось максимум внимания аудитории, но при этом почти никаких подробностей о том, что он собственно говоря собой представляет, так и не было обнародовано. Известно, что:
Аудио и видео
1000-1500 серверов используется для перекодирования видео, на них же оно и хранится.
Как известно, некоторое время назад появилась возможность общаться на Вконтакте через протокол Jabber (он же XMPP). Протокол совершенно открытый и существует масса opensource реализаций.
По ряду причин, среди которых проблемы с интеграцией с остальными сервисами, было решено за месяц создать собственный сервер, представляющий собой прослойку между внутренними сервисами Вконтакте и реализацией XMPP протокола. Основные особенности этого сервиса:
Интеграция со внешними ресурсами
Во Вконтакте считают данное направление очень перспективным и осуществляют массу связанной с этим работы. Основные предпринятые шаги:
Интересные факты не по теме
Подводим итоги
Завеса тайны насчет технической реализации Вконтакте была немного развеяна, но много моментов все же остались секретом. Возможно в будущем появится более детальная информация о собственной СУБД Вконтакте, которая как оказалось является ключом к решению всех самых сложных моментов в масштабируемости системы.
Как я уже упоминал этот пост написан почти на память, на основе небольшого конспекта «круглого стола Вконтакте», так что хочется сразу извиниться за возможные неточности и недопонимания. Я лишь структурировал хаотичную кучу ответов на вопросы. Буду рад уточнениям и дополнениям.
ВКонтакте снова выкладывает KPHP
Привет! Сейчас будет дежавю.
Мы снова выложили на GitHub наш PHP-компилятор — KPHP. Он проделал большой путь, и чтобы рассказать о нём, сначала телепортируемся на шесть лет назад.
Поясню для тех, кто не в теме: платформа ВКонтакте изначально была написана на PHP. Со временем нас перестала устраивать производительность, и мы решили ускорить VK. Сделали компилятор — KPHP, который поддерживал узкое подмножество PHP. Это было давно, и с тех пор мы о нём не рассказывали, так как KPHP почти не развивался до 2018-го года.
Но два года назад мы взялись за него, чтобы вдохнуть в эту разработку новую жизнь. Что сделали и какой получили результат — расскажу в этой статье. Она будет не о громком релизе, который можно прямо сейчас внедрять в свои проекты, а о внутренней разработке ВКонтакте, которую мы показываем сообществу и продолжаем развивать. Представлюсь: меня зовут Александр Кирсанов, я руковожу командой Backend-оптимизаций.
А теперь — телепортация.
Из 2020-го в 2014-й
Идёт 2014 год, и ВКонтакте опенсорсит репозиторий kphp-kdb. Наверняка многие из вас помнят этот момент.
Там было много движков от VK, а также первая версия KPHP. Тогда многие заинтересовались и пошли смотреть, но… Но. На тот момент там не было подробной инструкции по сборке, а также документации и сравнения с аналогами. Не было канала связи с разработчиками и поддержкой. Дальнейших апдейтов на GitHub также не случилось. И всё равно некоторые энтузиасты пробовали пользоваться этими инструментами — возможно, кому-то даже удалось, но доподлинно не известно.
Что касается KPHP — на тот момент он поддерживал версию PHP… даже не знаю. Что-то среднее между 4 и 5. Были функции, примитивы, строки и массивы. Но не было классов и ООП, не было современных (на момент 2014-го) паттернов разработки. И весь бэкенд-код ВКонтакте был написан в процедурном стиле, на ассоциативных массивах.
В общем, инфоповод был интересным, но во что-то большее не развился.
Из 2014-го в 2020-й
Сейчас, в конце 2020 года, весь бэкенд-код ВКонтакте по-прежнему на PHP. Пара сотен разработчиков, миллионы строк.
Но наш нынешний PHP-код мало чем отличается от актуального в индустрии. Мы пишем на современном PHP: у нас есть классы, интерфейсы и наследование; есть лямбды, трейты и Composer; а ещё строгая типизация, анализ PHPDoc и интеграция с IDE. И KPHP делает всё это быстрым.
В 2014 году в техническую команду пришли новые люди, которые начали заниматься движками. (Да, ВКонтакте до сих пор десятки собственных закрытых движков, хотя точечно мы используем ClickHouse и другие известные.) Но KPHP долго никто не трогал. До 2018-го бэкенд-код действительно был на уровне PHP 4.5, а IDE плохо понимала код и почти не подсказывала при рефакторинге.
В середине 2018 года мы возродили работу над KPHP — и за пару сумасшедших лет не только подтянули его к современным стандартам, но и добавили фичи, которых нет и не может быть в PHP. Благодаря этому провели ряд ключевых оптимизаций бэкенда, и это позволило продуктовым командам интенсивно наращивать функциональность. Да, тем самым снова замедляя бэкенд.
И сейчас мы решились на второй дубль: готовы поделиться инструментами, которые помогают нам в работе. Какими именно и что о них стоит знать — расскажу далее.
Давайте про KPHP: что это и как работает
KPHP берёт PHP-код и превращает его в С++, а уже этот С++ потом компилирует.
Эта часть — техническая, она большая. Мы заглянем внутрь и увидим, что происходит с PHP-кодом: как из него получается С++ и что следует за этим. Не слишком кратко, чтобы обозначить базовые вещи, но и не чересчур детально — в дебри не полезем.
KPHP выводит типы переменных
Если бы KPHP пошёл по такому пути, он бы не смог стать быстрым. Залог скорости — прежде всего в типизации. KPHP заставляет думать о типах, даже когда вы их явно не указываете.
В PHP мы не пишем типы переменных (за исключением редких type hint для аргументов) — поэтому KPHP сам выводит типы. То есть придумывает, как бы объявить переменную в C++, чтобы это было лучше.
Давайте посмотрим сниппеты на примерах.
Тут KPHP понял, что $a — это целое число, то есть int64_t в C++, и сгенерил такой код.
И последний пример:
А здесь мы получим Compilation error. Потому что нельзя вызывать функции по имени — нельзя и всё. Нельзя обращаться по имени к переменным, к свойствам класса — KPHP напишет ошибку, несмотря на то что это работает в PHP.
KPHP хоть и выводит типы, но позволяет их контролировать
Выше мы видели: когда разработчик типы не пишет, они выводятся автоматом.
Но их можно писать — с помощью PHPDoc @var/@param/@return или через PHP 7 type hint. Тогда KPHP сначала всё выведет, а потом проверит.
KPHP превращает PHP class в C++ struct
Если в обычном PHP классы — это более-менее те же хеш-таблицы, то в KPHP не так. На выходе получаются обычные плюсовые структуры, которые ведут себя ссылочно, как и в PHP (очень похоже на std::shared_ptr идеологически).
Каждое поле получается своего типа. Обращение к полю — это обращение к типизированному свойству с известным на момент компиляции смещением в памяти. Это в десятки раз эффективнее, чем хеш-таблицы, — как по скорости, так и по памяти.
Наследование — плюсовое (за исключением late static binding, но оно разруливается на этапе компиляции). Интерфейсы — это тоже плюсовое множественное наследование, там главное — refcount запрятать куда нужно. Правда, методы классов — это отдельные функции, принимающие this явно, так оно логичнее с нескольких позиций.
В общем, когда разработчики пишут код, они всегда думают о типах и об их сходимости. Глупо ожидать, что напишешь фигню, а она заработает. Если ты следуешь ограничениям, получаешь скорость — иначе не бывает.
Как конкретно происходит конвертация PHP в C++
Многие знакомы с этой терминологией — те, кто занимался языками, или компиляторами, или статическим анализом.
Сначала PHP-файл превращается в линейный список токенов. Это такие минимальные неразрывные лексемы языка.
Потом линейный набор токенов превращается в синтаксическое дерево (abstract syntax tree). Оно согласовано с приоритетами операций и соответствует семантике языка. После этого этапа есть AST для всех достижимых функций.
Далее выстраивается control flow graph — это связывание функций и получение высокоуровневой информации о том, откуда и куда может доходить управление. Например, try/catch и if/else синтаксически похожи, но изнутри try можно добраться до внутренностей catch, а из if до тела else — нет. На выходе получается информация о соответствии вершин и переменных, какие из них используются на чтение, а какие на запись, и тому подобное.
Потом происходит type inferring. Это тот магический вывод типов, который ставит в соответствие всем PHP-переменным — переменные С++ с явно проставленными типами, а также определяет возвращаемые значения функций, поля классов и другое. Этот этап согласуется с тем, как код впоследствии будет исполняться на С++, какие там есть функции-хелперы, их перегрузки и прочее.
Имея типы, можно провести ряд оптимизаций времени компиляции. Например, заранее вынести константы, безопасно заинлайнить простые функции, а нетривиальные аргументы только для чтения передавать по const-ссылке, чтобы не вызывать конструктор копирования и не флапать рефкаунтер лишний раз.
И наконец, кодогенерация: все PHP-функции превращаются в С++ функции, а PHP-классы — в С++ структуры. Изменённые файлы и их зависимости перезаписываются, и код проекта на С++ готов.
Что дальше происходит с С++ кодом
Сгенерировать С++ из PHP — этого мало. Собственно говоря, это самое простое.
Во-вторых, PHP-сайт — это веб-сервер. Следовательно, и в KPHP должна быть вся серверная часть, чтобы можно было в том же nginx подменить PHP-шный upstream на KPHP-шный — и всё продолжало работать так же. KPHP поднимает свой веб-сервер, оркестрирует процессы, заполняет суперглобалы и переинициализирует состояние, как и PHP… Это тоже хардкорная часть — называется server, квадратик снизу.
Многие технические проблемы остаются за кадром — их не опишешь в статье на Хабре. Чего стоит один только сбор трейсов при ошибках: ведь в С++ не получить человекочитаемый стек, а хочется разработчику вообще его на PHP-код намаппить. Гигантское количество внутренних нюансов, множество подпорок и легаси — но в итоге продукт хорошо работает и развивается.
KPHP vs PHP: что мы не поддерживаем
Если код работает на PHP — это не значит, что он заработает на KPHP.
KPHP — это отдельный язык, со своими ограничениями и правилами.
KPHP vs PHP: в чём мы превосходим
В скорости. Если использовать KPHP грамотно, то код будет работать значительно быстрее, чем на PHP 7.4. А некоторых вещей нет в PHP — и чтобы при разработке он не падал с ошибками, там просто заглушки.
Итак, в чём наш профит:
Например, нам нужно загрузить пользователя и одновременно посчитать какую-то подпись запроса (CPU-работа — допустим, это долго). В обычном (синхронном) варианте это выглядит так:
Но эти действия независимы — пока грузится пользователь, можно считать хеш, а потом дождаться загрузки. В асинхронном варианте это происходит так:
В итоге: с одной стороны, мы следим за типами. С другой, можем делать запросы к движкам параллельно. С третьей, zero-cost abstractions (плохой термин, но пусть) — константы напрямую инлайнятся, всякие простые геттеры и сеттеры тоже, и оверхед от абстракций в разы меньше, чем в PHP.
Если говорить про бенчмарки, то на средних VK-страничках у нас профит от 3 до 10 раз. А на конкретных участках, где мы прицельно выжимали максимум, — до 20–50 раз.
Это значит, что PHP-код можно превратить в быстрый, если думать о типах и использовать built-in KPHP-функции.
KPHP и IDE
Система типов в KPHP значительно шире и строже, чем в PHP. Мы уже говорили, что нельзя смешивать в массиве числа и объекты — потому что какой тогда тип элементов этого массива?
Нельзя! А как можно? Например, сделать отдельный класс с двумя полями и вернуть его. Или вернуть кортеж (tuple) — специальный KPHP-тип.
К функции можно даже PHPDoc написать, KPHP его прочитает и после стрелочки (->) поймёт:
Но вот проблема: KPHP-то понимает, а вот IDE нет. Ведь tuple — это наша придумка, как и разные другие штуки внутри PHPDoc.
Не так давно у нас появился KPHPStorm — плагин для PhpStorm, который расширяет подсказки, оставляя рабочим рефакторинг. А ещё сам трекает сходимость типов значительно строже нативного.
Если вы интересуетесь разработкой плагинов для IDEA — загляните, все исходники открыты. KPHPStorm глубоко внедряется во внутренности IDE (через кучу недокументированного API). Многое пришлось пройти, чтобы всё заработало. Спасибо ребятам из JetBrains за помощь.
Закругляемся: вот он Open Source, что дальше?
Мы усовершенствовали KPHP и показываем его вам: можно посмотреть, покомпилировать что-то простое — теперь есть все инструкции и даже Docker-образ. Но будем честны: KPHP пока остаётся инструментом, заточенным под задачи VK, и для более широкого применения в реальных сторонних проектах он ещё не адаптирован.
Почему так? Мы всегда поддерживали в первую очередь собственные движки ВКонтакте. KPHP не умеет в Redis, MongoDB и другое. Даже Memcache у нас свой, который по RPC работает. Даже перед ClickHouse, который у нас развёрнут, стоит собственная proxy, куда мы тоже ходим по TL/RPC.
Мы никогда не поддерживали стандартные базы, потому что это не было нужно. Но знаете, в чём прикол? Если мы не выйдем в Open Source, этого никогда и не произойдёт — потому что это так и не потребуется. За последние два года KPHP прошёл огромный путь, возродился. Мы можем ещё пару лет продержать его у себя. Можем покрыть возможности PHP 8, сделать ещё ряд оптимизаций, освоить микросервисы и интеграцию с Kubernetes — но нам не будут нужны стандартные базы. И через два года будет то же самое.
Только открытость и внешняя заинтересованность помогут выделить дополнительные ресурсы, чтобы пилить фичи не только для нас, но и наружу. Может, уже среди читателей этой статьи найдутся те, кому интересно с нами развивать это направление? Почему нет — у нас очень маленькая команда, и мы занимаемся интересными, глубокими и совершенно не продуктовыми вещами.
Теперь вся разработка KPHP будет вестись на GitHub. Правда, CI пока останется в приватной инфраструктуре. Движки по-прежнему будут закрыты — но когда-нибудь команда движков, надеемся, тоже решится вынести в сообщество хотя бы часть кода.
У вас может возникнуть вопрос: а сложно ли добавить поддержку протоколов MySQL, Redis и других? И да и нет. Если пробовать интегрировать готовые модули — скорее всего, будет фейл. Особенно если они порождают дополнительные потоки, ведь воркеры принципиально однопоточные. К тому же, просто поддержать протокол, может, и не проблема — но сложно сделать его «прерываемым», чтобы это стыковалось с корутинами. А вот к этому сейчас код совершенно не готов: там корутины тесно переплетены с сетью и TL. Непростая история, в общем 🙂 Но выполнимая, и над этим надо работать.
Итак: где ссылки, как попробовать
Мы рассчитываем, что в дальнейшем нашей команде — возможно, при помощи сообщества — удастся развить KPHP так, чтобы он стал полезным инструментом и вне ВКонтакте. Не так важно, как быстро это произойдёт. В любом случае, это тот ориентир, который теперь стоит перед проектом.
ВКонтакте: как устроена социальная сеть
Содержание статьи
Без малого 100 миллионов пользователей — такова аудитория ВКонтакте, которую
надо обслуживать. Быстро и без перебоев. Долгое время подробности технической
реализации ВКонтакте оставались секретом. Но недавно самая популярная в России
социальная сеть пролила немного света на то, как она все-таки устроена. В конце
октября в Москве состоялась конференция HighLoad++, на которой представители
ВКонтакте в лице Павла Дурова и Олега Илларионова, наконец, рассказали кое-что
об архитектуре социальной сети.
Парней буквально завалили вопросами по совершенно различным аспектам работы
ВКонтакте, в том числе и техническим. Еще бы. Легко представить нагрузку на
серверную часть сервиса: как много людей ты знаешь, которые не пользуются этой
социальной сетью? А сколько времени ты там проводишь, тратя бесценные часы своей
жизни на общение с друзьями, просмотр видео, игры, музыку? Математика довольно
проста: баснословное количество пользователей * масса проведенного времени на
ресурсе = запредельное количество запросов к веб-серверам и базе данных +
терабайты постоянно загружаемых и просматриваемых фотографий, видео и аудио.
Взаимодействие участников социальной сети происходит практически в режиме
реального времени: все друзья должны немедленно узнавать о том, что произошло с
каждым из участников. Сайт должен быть доступен 100% времени. Как это удается?
Статистика ВКонтакте
Платформа
Для нас, конечно, особый интерес представляет именно архитектура проекта: как
взаимодействуют основные компоненты системы, какие собственные разработки
потребовались, какими трюками пришлось воспользоваться. Но прежде, чем перейти к
ней, необходимо ознакомиться с базовыми вещами — используемыми технологиями и
продуктами.
В качестве основной операционной системы используется Debian Linux — решение,
проверенное временем, один из самых старых и стабильных современных
дистрибутивов. Для балансировки нагрузки между серверами приложений используется
HTTP-сервер nginx, работающий в режиме reverse proxy. В его обязанности входит
держать соединение с браузером пользователя и передавать запросы серверам,
ответственным за исполнение PHP-кода, а также контролировать попадание
результата обратно в браузер. PHP-код исполняется посредством модуля mod_php для
Apache — альтернативных вариантов довольно много, особенно на основе протокола
FastCGI, но руководство ВКонтакте пошло по более консервативному пути в этом
вопросе, воспользовавшись самым проверенным временем решением. Никаких особых
систем оптимизации производительности PHP-кода не используется (например, в
Facebook написали свой компилятор из PHP в C под названием HipHop), единственной
внешней оптимизацией является кэширование оп-кода посредством всем доступного
решения XCache.
Ситуация с хранением данных выглядит достаточно размыто: с одной стороны,
активно используется собственная система управления базами данных, написанная на
C и созданная «лучшими умами» России, с другой — часто упоминалась MySQL в роли
основного хранилища. Подробнее про собственную базу данных ВКонтакте я расскажу
ниже. Говоря о хранении данных, нельзя не упомянуть о таком важном аспекте, как
кэширование часто используемой информации (расположение её в оперативной памяти
для быстрого доступа). Для этого используется очень популярный продукт в этой
области — memcached. Если ты не слышал: эта система позволяет осуществлять очень
простые атомарные операции, такие как расположение и получение произвольных
данных по ключу. Основной фишкой является молниеносно быстрый доступ и
возможность легкого объединения оперативной памяти большого количества серверов
в общий массив для временного хранения «горячих» данных.
Сторонние проекты, не являющиеся ключевыми для ВКонтакте, часто реализуются
либо с использованием довольно экзотических решений, либо, наоборот, на самых
простых технологиях. Например, сервис мгновенного обмена сообщениями реализован
на node.js (подробнее об этой разработке ты можешь прочитать в статье «Серверный
JavaScript» в ][
08/2010) с использованием протокола XMPP aka Jabber (мы еще к нему
вернемся). Конвертирование видео реализовано на самой простой и эффективной
библиотеке — ffmpeg, на ней же работает очень популярный видео-плеер VLC.
Основные используемые технологии
Архитектура
Самым заметным отличием от архитектуры многих других крупных
интернет-проектов является тот факт, что сервера ВКонтакте многофункциональны.
Т.е. нет четкого разделения на серверы баз данных, файловые серверы и т.д. — они
одновременно используются в нескольких ролях. При этом перераспределение
ролей происходит в полуавтоматическом режиме с участием системных
администраторов. С одной стороны, это оптимизирует эффективность использования
системных ресурсов, что хорошо, но с другой — повышает вероятность конфликтов на
уровне операционной системы в рамках одного сервера, что влечет за собой
проблемы стабильности. Впрочем, несмотря на использование серверов в разных
ролях, вычислительные мощности проекта обычно используются менее чем на 20%.
Балансировка нагрузки между серверами происходит по многоуровневой схеме,
которая включает в себя балансировку на уровне DNS (домен обслуживается с
помощью 32 IP-адресов), а также маршрутизацию запросов внутри системы, причем
разные сервера используются для разных типов запросов. Например, генерация
страниц с новостями (теперь это принято называть микроблогом) работает по хитрой
схеме, использующей возможности протокола memcached по параллельной отправке
запросов на получение данных по большому количеству ключей. В случае отсутствия
данных в кэше, аналогичный запрос отправляется системе хранения данных, а
полученные результаты подвергаются сортировке, фильтрации и отбрасыванию лишнего
уже на уровне PHP-кода. Похожим образом этот функционал работает и в Facebook
(они недавно обменивались опытом), только вместо собственной СУБД в Facebook
используют MySQL.
В стенах ВКонтакте было разработано большое количество софта, который более
точно удовлетворяет потребностям проекта, чем доступные opensource и
коммерческие решения. Помимо упоминавшейся собственной СУБД у них есть система
мониторинга с уведомлением по СМС (Павел сам помогал верстать интерфейс),
автоматическая система тестирования кода и анализаторы статистики и логов.
В проекте используется достаточно мощное оборудование, ориентировочно были
названы следующие характеристики серверов:
Примечательно, что сервера не брендированные, а собираются специализированной
российской компанией. Сейчас оборудование проекта расположено в 4 датацентрах в
Санкт-Петербурге и Москве, причем вся основная база данных располагается в
питерском датацентре, а в Москове хостится только аудио и видео. В планах
сделать репликацию базы данных с другим датацентром в Ленинградской области, а
также использовать Content Delivery Network для повышения скорости скачивания
медийного контента в регионах.
Многие проекты, сталкивающиеся с большим количеством фотографий, часто
изобретают собственные решения по их хранению и отдаче пользователям. Об этом
был первый вопрос, заданный Павлу из зала: «Как вы храните изображения?» — «На
дисках!». Так или иначе, представители ВКонтакте заявили, что вся эта куча
фотографий всех цветов и размеров просто хранится и отдается с файловой системы
(используют xfs) большого количества серверов, без дополнительных изысков.
Смущает разве что тот факт, что у других крупных проектов такой подход не
сработал — наверное, они не знали волшебного слова :).
Не менее волшебной представляется та самая собственная база данных на C.
Этому продукту, пожалуй, было уделено основное внимание аудитории, но при этом
почти никаких подробностей о том, что он, собственно говоря, собой представляет,
так и не было обнародовано. Известно, что СУБД разработана «лучшими умами»
России, победителями олимпиад и конкурсов TopCoder, а также что она используется
в самых высоконагруженных сервисах ВКонтакте:
В отличие от MySQL используется нереляционная модель данных, а большинство
операций осуществляется в оперативной памяти. Интерфейс доступа представляет
собой расширенный протокол memcached. Специальным образом составленные ключи
возвращают результаты сложных запросов (чаще всего специфичных для конкретного
сервиса).
Система проектировалась с учетом возможности кластеризации и автоматической
репликации данных. Разработчики хотели бы сделать из данной системы
универсальную СУБД и опубликовать под GPL, но пока не получается из-за высокой
степени интеграции с остальными сервисами.
Интересные факты о ВКонтакте
Подпроекты
Сервисы аудио и видео являются побочными для социальной сети, на них
создатели проекта особо не фокусируются. В основном это связано с тем, что они
редко коррелируют с основной целью использования социальной сети — общением, а
также создают большое количество проблем. Видеотрафик — основная статья расходов
проекта, плюс всем известные проблемы с нелегальным контентом и претензиями
правообладателей. 1000—1500 серверов используются для перекодирования видео, на
них же оно и хранится. Медиа-файлы банятся по хэшу при удалении по просьбе
правообладателей, но это неэффективно и планируется усовершенствовать этот
механизм. Очевидно, речь идет о разработке более интеллектуального алгоритма
распознавания аудио- и видео-контента по тегам, как это, к примеру, реализовано
в YouTube, где загруженный видеоролик, нарушающий лицензию, может быть
автоматически удален уже через несколько минут после загрузки.
Как известно, некоторое время назад появилась возможность общаться на
ВКонтакте через протокол Jabber (он же XMPP). Протокол совершенно открытый и
существует масса opensource реализаций. По ряду причин (среди которых проблемы
интеграции с остальными сервисами ВКонтакте) было решено за месяц создать
собственный сервер, представляющий собой прослойку между внутренними сервисами
ВКонтакте и реализацией XMPP протокола. Реализован он на node.js — выбор
обусловлен тем, что JavaScript знают практически все разработчики проекта, к
тому же это хороший набор инструментов для реализации задачи. Сложным моментом
стала работа с большими контакт-листами. У многих пользователей количество
друзей ВКонтакте измеряется сотнями и тысячами, высока активность смены
статусов: люди появляются и исчезают из онлайна чаще, чем в других аналогичных
ситуациях. К тому же необходимо было реализовать тесную интеграцию с внутренней
системой обмена личными сообщениями ВКонтакте. В результате на сервисе 60-80
тысяч человек онлайн, в пике — 150 тысяч. TCP/HTTP-балансировщик нагрузки
HAProxy обрабатывает входящие соединения и используется для распределения
запросов по серверам, а также развертывания новых версий.
При выборе системы хранения данных думали о нереляционных системах хранения
данных (в частности, о MongoDB), но в итоге решили воспользоваться привычной
MySQL. Сервис функционирует на 5-ти серверах разной конфигурации, на каждом из
которых работает код на node.js (по 4 процесса на сервер), а на трех самых
мощных — еще и MySQL. Интересной особенностью является отсутствие связи между
группами друзей в XMPP с группами друзей на сайте — сделано по просьбе
пользователей, которые не хотели, чтобы их друзья из-за плеча видели, в какой
группе они находятся.
Важным подпроектом является также интеграция с внешними ресурсами, которую в
условиях высоконагруженного сервиса реализовать далеко не так просто. Все чаще
на страницах сторонних проектов можно увидеть виджеты «Мне нравится»,
позволяющими быстро поделиться интересным постом со своими друзьями, а также
небольшие блоки «Мы ВКонтакте» с данными о пользователях внутри привязанной
группы. Основные шаги, предпринятые в этом направлении, с небольшими
комментариями:
Не секрет
Завеса тайны насчет технической реализации ВКонтакте была немного развеяна,
опубликовано куча интересных аспектов, но все же многие моменты по-прежнему
остаются секретом. Возможно, в будущем появится более детальная информация о
собственной СУБД ВКонтакте, которая, как оказалось, является ключом к решению
всех самых сложных моментов в масштабируемости системы. Сейчас, как бы кто ни
относился к ВКонтакте, сервис является очень интересным с точки зрения
построения высоконагруженных систем. Все-таки 11 миллиардов запросов в день,
высочайший аптайм и почти 100 миллионов пользователей — дорогого стоят.
Warning
Далеко не все крупные проекты публично раскрывают аспекты построения
архитектуры. Даже примерная информация о том, что у них происходит и как они
работают, часто держится в секрете. Источником информации чаще всего
оказываются либо выступления представителей проектов на конференциях, либо
различные интервью/публикации сотрудников. Информация для этого материала
была собрана автором из этих же источников и не является официально
подтвержденной со стороны ВКонтакте.