Highload++ 2017 завершён!

Профессиональная конференция разработчиков высоконагруженных систем

СКОЛКОВО, Москва 7 и 8 ноября

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

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

  • Главная
  • Архитектуры, масштабируемость

Как переписать проект c нуля, сохраняя контроль. Опыт domclick.ru
Архитектуры, масштабируемость

Доклад отклонён
domclick

Технический руководитель разработки.

Тезисы

Рынок недвижимости устоялся, и в нем нет ничего нового и интересного, но так ли это? Забегая вперед, ответ таков: скорей нет, чем да.

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

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

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

Тезисно о проблемах и решениях.

Проблема #1: Cложно разворачивать микросервисную архитектуру на локальных машинах, долгий ввод новых сотрудников.
Решение #1: docker, docker-compose.

Проблема #2: появляется большое количество сервисов, их сложно деплоить и масштабировать через админов, если не подключать команду разработки.
Решение #2: nomad/kubernetes.

Проблема #3: нужно понимать, что происходит с сервисами в кластере, вовремя получать оповещения.
Решение #3: железо - zabbix, grafana + influxdb (сбор метрик о том, кто к кому ходит (логи nginx) + время ответов + статусы, метрики куба в графану - текущий rps + сеть + память, Алерты в телеграм/почту/смс, newrelic.

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

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

Проблема #6: типичные проблемы при оптимизации многосервисного проекта.
Решение #6: как и когда профилировать, на что тратить время в первую очередь при оптимизации (из нашего субъективного опыта), когда нужно писать на go/c++/…, а когда хватит и Python/любой скриптовый, синхронка/асинхронка, когда оно имеет смысл.Tarantool за две недели в продуктив.

Технологии “быстрых решений”, “быстрого прототипирования”
,
Web-scale IT / другое

Другие доклады секции
Архитектуры, масштабируемость

Rambler's Top100