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

в 10:03, , рубрики: badoo, highload, баду, Блог компании Badoo, Веб-разработка, Учебный процесс в IT, метки: , , ,

Встреча разработчиков со студентами МФТИ или «Как собрать 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

Источник

Поделиться

* - обязательные к заполнению поля