company_banner

Встреча разработчиков со студентами МФТИ или «Как собрать 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
    252,00
    Big Dating
    Поделиться публикацией

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

    Комментарии 11

      +3
      Конечно приду)
        +9
        А после встречи выложите видео?
          +3
          Мы снимем видео, если организаторы со стороны МФТИ будет не против
          +1
          А только студентам можно присутствовать?
            +3
            А пришлите имя и фамилию (можно личным сообщением) и мы внесем в список
            +7
            Выложите плиз в инет потом видео! Жудко хочу посмотреть но не буду же я с Украины ехать. :(
              0
              Видео есть-таки?
                0
                Видео не получилось записать, так как освещение в аудитории было не очень хорошее. В планах есть запись этой лекции в офисе.
                  0
                  Если запишите, выложите плиз ссылку здесь в комментариях. Спасибо!
                +2
                Спасибо за встречу! И особенно спасибо докладчику — очень доходчиво удалось рассказать о не самых простых вещах.
                  0
                  Вам спасибо!

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

                Самое читаемое