Информация

Дата основания
2006
Местоположение
Россия
Сайт
badoo.com
Численность
501–1 000 человек
Дата регистрации

Блог на Хабре

Обновить
165,7
Рейтинг
Badoo
Big Dating

Встреча разработчиков со студентами МФТИ или «Как собрать Badoo на коленке»

Блог компании BadooРазработка веб-сайтов
В эту среду наши разработчики, выпускники МФТИ, проведут встречу со студентами МФТИ и расскажут как создаются большие проекты и как сделать Badoo своими силами.
Никакого маркетинга, пиара и прочего булшита. Только разработка, только хардкор!
Общаться со студентами будут разработчики из отдела A-team — они специализируются на разработке инфраструктурных проектов компании. В Badoo отдел A-team занимается созданием масштабируемых и отказоустойчивых платформ для приложений, разрабатывает приложения для управления кластерами, утилиты автоматизации тестирования/деплоя кода, собирает и исследует тонны данных для повышения качества и производительности много-серверных продакшн-систем.
Работа ведётся на стыке приложений для конечных пользователей и системного ПО.
Если вдруг кто-то из вас учится в другом ВУЗе, но хочет попасть на встречу, то напишите об этом в комментариях к посту или личным сообщением до 15-00 23 октября. Ждем письмо с названием ВУЗа, ФИО, курсом и специальностью.

Где: Долгопрудный, МФТИ, главный корпус, 117 аудитория
Когда: 23 октября, среда, в 19-00
Бонус: Возможность задать каверзные вопросы fisher, antonstepanenko, youROCK и Деми (без аккаунта на Хабре).

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

Про что будем говорить на встрече:

Badoo: сделай сам


1.Начало проекта
  • 1 сервер, LAMP;
  • База MySQL потому что она простая, быстрая, дешёвая в обслуживании, а функционал Oracle нам не нужен, так как мы не хотим логику в базе;
  • PHP потому что быстрая разработка, хороший перфоманс, легче найти девелоперов, да и при старте проекта альтернатив не было;
  • nginx + fpm потому что проблема медленных клиентов;
  • Запустились, работаем.
Итого:
* LAMP: Linux/Apache/Mysql/PHP
Apache -> nginx+php-fpm

2. Кеширование
  • Большой траффик, серьезная нагрузка, база не справляется;
  • Ставим memcache, есть и другие варианты (redis, cassandra, etc.), но memcache простой, надёжный и быстрый, а persistent обеспечит база;
  • Шардируем ключи по пулу серверов, все ключи одного пользователя в одном сервере;
  • Prolongate;
  • Cброс по коммиту транзакции;
  • Cишные демоны для специальных случаев, интерфейс gpb.

3. Масштабируем веб
  • Морда перестала справляться;
  • Увеличиваем количество морд, ставим перед ними балансер (простейший вариант — nginx as reverse proxy, но у нас своя дорогая железка с умным балансингом и failover);
  • Храним сессии в memcache.

4. Мониторинг и логи
  • Pinba — мониторинг realtime, отсылка пакетов по UDP, аггрегация данных, графики;
  • Cбор логов через scribe в базу, поиск по логам сфинксом, фильтры;
  • Ошибки будут всегда, надо просто контролировать их количество и критичность.

5. Масштабируем базу
  • Увеличили число морд — база перестала справляться;
  • Попробовали мастер-слэйв — write intensive приложениям не помогает;
  • Будем шардировать базу;
  • Остатки от деления и подобное не подходят;
  • UDB, споты;
  • Выборка данных на такой архитектуре, поиск (прикручиваем сфинкс, но у нас своя магия);
  • Очереди, посылка событий в одной транзакции с изменениями, проблема двухфазного коммита, отложенная обработка событий, асинхронность;

6. Скриптовый фреймворк
  • Сделали много очередей — разгребающих скриптов стало много, нужен пул машин;
  • Сделали пул, жестко привязали скрипт к машине — плохо, машина падает, скрипт не работает;
  • Существующие решения (Slurm и т.п.) не подходят, либо плохой балансинг, либо очень специфичные требования к задачам;
  • Делаем облако;
  • На каждой машине специальный агент для запуска и heartbeat;
  • Центральная нода менеджит очередь на исполнение, распихивает задания по живым машинам, следит за нагрузкой.

7. Деплой
  • У нас более 2000 машин, надо на них как-то деплоить код;
  • Простейшее решение — git pull, медленно и неатомарно;
  • Следующий этап — rsync, уже быстрее, но всё равно неатомарно, плюс сильно нагружает сеть и 2000 форков это тяжело;
  • Наш вариант — uftp + aio, то есть multicast, работает быстро и не грузит сеть;
  • Атомарное перекидывание симлинка, libpssh на aio;
  • Uimages: пофайловое версионирование статики;
  • Автоматическая сборка билда, прогон юнит- и прочих тестов, деплой дважды в день.

8. А ещё у нас есть:
  • Свой собственный CDN;
  • Форматтер кода;
  • Репликация на php;
  • Антиспам;
  • Быстрый шаблонизатор blitz.

Приходите!
Теги:BadooБадуhighloadучебный процесс в it
Хабы: Блог компании Badoo Разработка веб-сайтов
Рейтинг +50
Количество просмотров 13,3k Добавить в закладки 62
Комментарии
Комментарии 11

Похожие публикации

Лучшие публикации за сутки