- Главная
- →
- Архитектуры, масштабируемость
Как переписать проект c нуля, сохраняя контроль. Опыт domclick.ru Архитектуры, масштабируемость
Тезисы
Рынок недвижимости устоялся, и в нем нет ничего нового и интересного, но так ли это? Забегая вперед, ответ таков: скорей нет, чем да.
В современных реалиях появляются новые и сложные задачи в уже, казалось бы, устоявшейся нише, и наличие готовых “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 за две недели в продуктив.