Как строить архитектуру для отказоустойчивой службы такси / Минкин Андрей (Na...Ontico
Такси — это популярная тема для обсуждений, после того, как появились стартапы в виде Uber, GetTaxi, GrabTaxi и тому подобные. Ведущий разработчик службы Namba Taxi расскажет про то, как строилась текущая отказоустойчивая архитектура в Namba Taxi, с какими проблемами и неудачами мы сталкивались и как решали.
Тезисы - http://www.highload.ru/2015/abstracts/1661.html
Самые частые проблемы и пути решения при росте нагрузки и масштабировании про...Andrew Minkin
ы начали делать проект и запустили его в продакшн. Со временем пользователей становится больше и текущих ресурсов вам начинает не хватать. В этом докладе я расскажу о основных путях борьбы с нагрузкой, путях решения и проблемах, связанных с ними.
В докладе мы поговорим о:
0. Что такое нагрузка? Пути борьбы с нагрузкой. Оптимизация кода, кеширование, масштабирование
1. Какие проблемы возникают при внедрении кеширования
2. Как оценивать качество работы кеширования?
3. Путь масштабирования и борьба за ресурсы
4. Проблемы балансировки
5. Проблемы БД. Конкурентный доступ и данным и целостность их
Пути решения проблем будут на примере Python/Django
Тестирование через мониторинг или холакратия на практике / Максим Чистяков (U...Ontico
Чтобы быстро двигаться, надо быстро двигаться :-)
Скоростная разработка продукта невозможна без непрекращающегося выкатывания свежих изменений в боевое окружение. Именно это позволяет Ultimate-Guitar оставаться #1 world's guitar service.
Когда-то давным-давно мы приняли для себя, что "мы движемся очень быстро и иногда из-за этого что-то ломаем. Недоставленный пользователям продукт/непроверенная гипотеза хуже, чем временная неработоспособность части сервиса. Поэтому мы убираем преграды между новым кодом и продакшном: не тратим время ни на тестирование, ни на строгий релиз-менеджмент".
Многие возникающие проблемы касаются только обслуживания (датацентр, OS, каналы) и мониторинг, естественно, необходим. Ну, а раз уж у нас есть мониторинг, то давайте считать систему единым целым, которая может выходить из строя по различным причинам, одной из которых является ошибка в коде. Это привело нас к идее использовать мониторинг вместо тестирования. К чему это привело, почему мы любим Anturis, Graylog, Grafana, что главное в деплое - это быстрый откат и другие прелести управления звездолётом Ultimate-Guitar с дневным населением больше Москвы на скорости 10 деплоев/час - обо всё этом пойдёт речь в этом докладе:
- Про скорость и цену быстрого развития (Innovation Costs).
- Холакратия в бранчах, "сам себе релиз-инженер", ответственность и честность.
- Скорость отката > скорость деплоя.
- Как умер QA или демоны с tail и Graylog.
- Когда не нужны микросервисы: успеть за 30 секунд, медленный Mercurial и шустрое комбо Git + Capistrano + Ansible.
- Бесполезные фичи, бритва Оккама и пользователи, которые на самом деле любят изменения :-)
Как строить архитектуру для отказоустойчивой службы такси / Минкин Андрей (Na...Ontico
Такси — это популярная тема для обсуждений, после того, как появились стартапы в виде Uber, GetTaxi, GrabTaxi и тому подобные. Ведущий разработчик службы Namba Taxi расскажет про то, как строилась текущая отказоустойчивая архитектура в Namba Taxi, с какими проблемами и неудачами мы сталкивались и как решали.
Тезисы - http://www.highload.ru/2015/abstracts/1661.html
Самые частые проблемы и пути решения при росте нагрузки и масштабировании про...Andrew Minkin
ы начали делать проект и запустили его в продакшн. Со временем пользователей становится больше и текущих ресурсов вам начинает не хватать. В этом докладе я расскажу о основных путях борьбы с нагрузкой, путях решения и проблемах, связанных с ними.
В докладе мы поговорим о:
0. Что такое нагрузка? Пути борьбы с нагрузкой. Оптимизация кода, кеширование, масштабирование
1. Какие проблемы возникают при внедрении кеширования
2. Как оценивать качество работы кеширования?
3. Путь масштабирования и борьба за ресурсы
4. Проблемы балансировки
5. Проблемы БД. Конкурентный доступ и данным и целостность их
Пути решения проблем будут на примере Python/Django
Тестирование через мониторинг или холакратия на практике / Максим Чистяков (U...Ontico
Чтобы быстро двигаться, надо быстро двигаться :-)
Скоростная разработка продукта невозможна без непрекращающегося выкатывания свежих изменений в боевое окружение. Именно это позволяет Ultimate-Guitar оставаться #1 world's guitar service.
Когда-то давным-давно мы приняли для себя, что "мы движемся очень быстро и иногда из-за этого что-то ломаем. Недоставленный пользователям продукт/непроверенная гипотеза хуже, чем временная неработоспособность части сервиса. Поэтому мы убираем преграды между новым кодом и продакшном: не тратим время ни на тестирование, ни на строгий релиз-менеджмент".
Многие возникающие проблемы касаются только обслуживания (датацентр, OS, каналы) и мониторинг, естественно, необходим. Ну, а раз уж у нас есть мониторинг, то давайте считать систему единым целым, которая может выходить из строя по различным причинам, одной из которых является ошибка в коде. Это привело нас к идее использовать мониторинг вместо тестирования. К чему это привело, почему мы любим Anturis, Graylog, Grafana, что главное в деплое - это быстрый откат и другие прелести управления звездолётом Ultimate-Guitar с дневным населением больше Москвы на скорости 10 деплоев/час - обо всё этом пойдёт речь в этом докладе:
- Про скорость и цену быстрого развития (Innovation Costs).
- Холакратия в бранчах, "сам себе релиз-инженер", ответственность и честность.
- Скорость отката > скорость деплоя.
- Как умер QA или демоны с tail и Graylog.
- Когда не нужны микросервисы: успеть за 30 секунд, медленный Mercurial и шустрое комбо Git + Capistrano + Ansible.
- Бесполезные фичи, бритва Оккама и пользователи, которые на самом деле любят изменения :-)
Мы в Avito не так давно начали использовать Golang, но он уже успел занять важное место в различных частях проекта. В докладе мы расскажем о том, какие задачи нам помогает решать Go, почему выбор пал именно на этот язык, с какими подводными камнями мы столкнулись, и как их обходили. В частности поговорим про:
• Сервисы. Как мы начали использовать Go для разработки микросервисов, как это сказалось на их поддержке, а также отдельно расскажем про “шаблон сервиса”, который мы используем.
• Поиск. Как мы с помощью Go мы реализовали RtIndexer для обновления Sphinx Rt индексов в кластере из множества машин (поиск по активным объявлениям), который устойчиво работает с отставанием не более 10 секунд при нагрузке до 1000 rps.
• Автоматизацию тестирования. Как мы пишем тестовые сервисы и API на Go. Подробней остановимся на использовании общих моделей тел запросов и ответов для отправки и получения, использовании горутин как воркеров для обработки очереди.
My talk on Hadoop stack operations engineering at OSPConAlex Chistyakov
My talk on Hadoop stack operations engineering at OSPCon Nov 2015 (http://www.ospcon.ru/event/prakticheskaya-konferentsiya-tekhnologii-bolshikh-dannykh_130.html)
Сравнение решений по балансировке высоконагруженных систем / Евгений Пивень (...Ontico
+ Функционал разных решений для балансировки.
+ Виды балансировщиков (DNS, hardware, software, облачные решения).
+ Поведение при скачках трафика и возможности скалирования сервиса.
+ Специфика трафика RTB в контексте балансировки.
+ Проблемы, которые возникали у нас, и как мы их решали.
«Как 200 строк на Go помогли нам освободить 15 серверов» – Паша Мурзаков (Badoo)AvitoTech
В Badoo я работаю в команде, которая разрабатывает на PHP. Одна из фич, которой мы занимаемся, со временем начала отъедать всё больше и больше железячных ресурсов. В итоге мы едва успевали добавлять серверы под растущую нагрузку. При этом вечера, проведённые с Go дома, подсказывали, что можно сделать на порядки производительнее, не затратив на разработку много времени.
Я расскажу о том, почему наша фича так плохо ложится на PHP и хорошо – на Go, как уговорить всех всё переписать и не показаться сумасшедшим, ну и, конечно же, как из 19 серверов оставить только 4.
101 способ приготовления RabbitMQ и немного о pipeline архитектуре / Филонов ...Ontico
Архитектурный шаблон проектирования конвейер (pipeline) хорошо зарекомендовал себя при проектировании высоконагруженных (highload) систем. Использование шины сообщений (message bus) при реализации каналов взаимодействия позволяет достигать хороших показателей масштабируемости (scalability), но при этом появляются дополнительные накладные расходы, которые сказываются на показателях производительности (performance).
В докладе обсуждаются варианты использования системы обмена сообщениями RabbitMQ в качестве связующего программного обеспечения (middleware) для построения конвейерной архитектуры. Рассматриваются вопросы производительности и масштабирования как stateless так и statefull фильтров.
В качестве примера рассматривается реализация системы обработки сложных событий (complex event processing) применительно к управлению журналированием (log management).
Booking.com - популярный сервис по онлайн-бронированию отелей. Поиск отеля, отвечающего заданным характеристикам - это неотъемлемая часть бизнес-модели и основной инструмент для клиента.
При постоянном росте компании вопросу производительности и масштабируемости поиска уделяется много внимания. В результате за время своего существования архитектура поиска претерпела несколько глобальных переделок, начиная от простой базы в MySQL до многокомпонентного распределенного сервиса.
В своей текущей реинкарнации поиск в Booking.com состоит их трех подсистем:
1) сервис auto-complete и устранения неоднозначности (disambiguation) в геопозиции;
2) сервис поиска по отелям и проверки их доступности (availability);
3) система предрасчета цен.
Первые две системы - это высокопроизводительные приложения, написанные на Java. Сервис поиска хранит свои индексы в in-memory хранилище, а данные - во встраиваемой базе данных RocksDB. Логика системы предрасчета цен написана на Perl, а в качестве хранилища используется MySQL.
Приходите на мой доклад, и я расскажу вам, как эволюционировал поиск вместе с ростом компании. Мы подробно рассмотрим текущую архитектуру, и почему мы решили ее сделать именно такой. Ну и, конечно, с какими проблемами нам пришлось бороться и как мы это делали.
Кортунов Никита. Как ускорить разработку приложений или есть ли жизнь после P...AvitoTech
икита расскажет о возможностях backend as a service, ответит на вопрос есть ли жизнь после Parse, поделится опытом разработки BaaS Scorocode, особенностями архитектуры и кейсами применения, как можно ускорить разработку с помощью BaaS.
SOA: послать запрос на сервер? Что может быть проще?! / Иван Круглов (Booking...Ontico
РИТ++ 2017, HighLoad Junior
Зал Конгресс-холл, 5 июня, 10:00
Тезисы:
http://junior.highload.ru/2017/abstracts/2577.html
Микросервисы - это круто, модно и интересно. Переход на их использование принесет команде заметные преимущества. Но сервис-ориентированная архитектура (SOA) не лишена недостатков. Один их них - это то, что, заменяя простой вызов функции на RPC, мы в неявном виде вводим в уравнение, отвечающее за стабильность системы, целую плеяду новых неизвестных. Например, простейший HTTP-запрос за время своей жизни проходит через множество всевозможных буферов, очередей и алгоритмов на своем пути от клиента к серверу и обратно. Совокупное поведение этих составляющих трудно предсказать, понять и правильно интерпретировать. И особенно трудно это сделать в нестандартных ситуациях.
В своем докладе я хочу поделиться опытом решения проблем, с которыми я столкнулся за время работы в Booking.com. Я расскажу, как небольшой тюнинг сервера и клиента существенно влиял на конечную стабильность системы.
Работа с геоданными в Go GDGNSK / Work with Geodata in GoMad Devs
Слайды с GDG DevFest Новосибирск про го, геоданные, ненависть к нод.жс и UDP.
Slides from GDG DevFest Novosibirsk about Go, geodata and hatred to Nod.js and UDP.
Автор: Андрей Минкин / Andrew Minkin
Рефакторинг монолита в микросервисы на Go / Refactoring of Monolithe to Micro...Mad Devs
Презентация с GDG Devfest Алматы, рассказывающая о том, как мы рефакторили мололит в микросервисы на Go.
Presentation at GDG Devfest Almaty describing how we refactored monolithe to microservices on Go.
Автор: Андрей Минкин / Andrew Minkin
Как строить архитектуру для отказоустойчивой службы такси / How to Build a ...Mad Devs
Доклад с конференции Highload++ 2015 об отказоустойчивой архитектуре
A report from the Highload++ 2015 conference in Moscow, describing the fallover architectures
Автор: Андрей Минкин / Andrew Minkin
http://www.highload.ru/2015/abstracts/1661.html
RTB и его проблематика должны быть знакомы участникам конференции - мало кто сегодня не слышал об этом способе получить много krps с жесткими ограничениями на время генерации ответа.
Вот и компания Qmobi решила поучаствовать в этой гонке и отхватить свой кусок пирога под названием “рынок мобильной рекламы”.
При первом подходе к снаряду задача выглядит довольно простой: вот запрос с критериями, вот база данных с ответами - выбирай по индексу и отвечай.
На самом деле все несколько сложнее. Начать с того, что некоторые критерии отбора - негативные. Затем мы имеем дело с выборкой по десятку индексов, каждый из которых обладает низкой cardinality. И, наконец, мы имеем дело с большими объемами: около 10М строк в исходных данных, около 10К строк в финальной выборке. Ах, нет, еще финальная выборка должна быть отсортирована по приоритету! И надо не забыть про атомарные блокировку и списание средств...
От идеи прототипа на perl пришлось отказаться еще на этапе постановки задачи :)
Итак, мы имеем задачу с интенсивным IO, высокой нагрузкой, высокими скоростями, сложными структурами данных и эвристическими алгоритмами.
Анализ имеющихся вариантов показал, что Go должен прекрасно подойти для этой задачи. О том, на основании каких соображений мы сделали такой вывод, и какие из этих соображений прошли проверку практикой, а какие - нет, будет рассказано в докладе.
Также в докладе будет рассказано о том, как сортировка была заменена случайной выборкой, и чем пришлось заплатить за то, чтобы эта замена оказалась равноценной.
Будет показано, почему мы наплевательски отнеслись к гипотетической потере 20% возможностей поучаствовать в аукционе, и почему реальный процент потерь много ниже.
Будет раскрыта роль СУБД MySQL в этом проекте, со всем блеском высокой производительности и нищетой отказоустойчивости.
Вопросы геотаргетинга, использования PostGIS и кэширования результатов поиска региона по координатам будут затронуты вскользь, как неоднократно обсуждавшиеся на этой и подобных конференциях.
А вот анатомия производительности приложения на Go будет рассмотрена подробнейшим образом - с графиками и числами.
Также подробно будут рассмотрены наши победы и поражения в борьбе со статис
RTB DSP на языке Go укрощение buzzwords / Даниил Подольский (Qmobi.Com)Ontico
RTB и его проблематика должны быть знакомы участникам конференции — мало кто сегодня не слышал об этом способе получить много krps с жесткими ограничениями на время генерации ответа.
Вот и компания Qmobi решила поучаствовать в этой гонке и отхватить свой кусок пирога под названием “рынок мобильной рекламы”.
Анализ имеющихся вариантов показал, что Go должен прекрасно подойти для этой задачи. О том, на основании каких соображений мы сделали такой вывод, и какие из этих соображений прошли проверку практикой, а какие — нет, будет рассказано в докладе.
Мы в Avito не так давно начали использовать Golang, но он уже успел занять важное место в различных частях проекта. В докладе мы расскажем о том, какие задачи нам помогает решать Go, почему выбор пал именно на этот язык, с какими подводными камнями мы столкнулись, и как их обходили. В частности поговорим про:
• Сервисы. Как мы начали использовать Go для разработки микросервисов, как это сказалось на их поддержке, а также отдельно расскажем про “шаблон сервиса”, который мы используем.
• Поиск. Как мы с помощью Go мы реализовали RtIndexer для обновления Sphinx Rt индексов в кластере из множества машин (поиск по активным объявлениям), который устойчиво работает с отставанием не более 10 секунд при нагрузке до 1000 rps.
• Автоматизацию тестирования. Как мы пишем тестовые сервисы и API на Go. Подробней остановимся на использовании общих моделей тел запросов и ответов для отправки и получения, использовании горутин как воркеров для обработки очереди.
My talk on Hadoop stack operations engineering at OSPConAlex Chistyakov
My talk on Hadoop stack operations engineering at OSPCon Nov 2015 (http://www.ospcon.ru/event/prakticheskaya-konferentsiya-tekhnologii-bolshikh-dannykh_130.html)
Сравнение решений по балансировке высоконагруженных систем / Евгений Пивень (...Ontico
+ Функционал разных решений для балансировки.
+ Виды балансировщиков (DNS, hardware, software, облачные решения).
+ Поведение при скачках трафика и возможности скалирования сервиса.
+ Специфика трафика RTB в контексте балансировки.
+ Проблемы, которые возникали у нас, и как мы их решали.
«Как 200 строк на Go помогли нам освободить 15 серверов» – Паша Мурзаков (Badoo)AvitoTech
В Badoo я работаю в команде, которая разрабатывает на PHP. Одна из фич, которой мы занимаемся, со временем начала отъедать всё больше и больше железячных ресурсов. В итоге мы едва успевали добавлять серверы под растущую нагрузку. При этом вечера, проведённые с Go дома, подсказывали, что можно сделать на порядки производительнее, не затратив на разработку много времени.
Я расскажу о том, почему наша фича так плохо ложится на PHP и хорошо – на Go, как уговорить всех всё переписать и не показаться сумасшедшим, ну и, конечно же, как из 19 серверов оставить только 4.
101 способ приготовления RabbitMQ и немного о pipeline архитектуре / Филонов ...Ontico
Архитектурный шаблон проектирования конвейер (pipeline) хорошо зарекомендовал себя при проектировании высоконагруженных (highload) систем. Использование шины сообщений (message bus) при реализации каналов взаимодействия позволяет достигать хороших показателей масштабируемости (scalability), но при этом появляются дополнительные накладные расходы, которые сказываются на показателях производительности (performance).
В докладе обсуждаются варианты использования системы обмена сообщениями RabbitMQ в качестве связующего программного обеспечения (middleware) для построения конвейерной архитектуры. Рассматриваются вопросы производительности и масштабирования как stateless так и statefull фильтров.
В качестве примера рассматривается реализация системы обработки сложных событий (complex event processing) применительно к управлению журналированием (log management).
Booking.com - популярный сервис по онлайн-бронированию отелей. Поиск отеля, отвечающего заданным характеристикам - это неотъемлемая часть бизнес-модели и основной инструмент для клиента.
При постоянном росте компании вопросу производительности и масштабируемости поиска уделяется много внимания. В результате за время своего существования архитектура поиска претерпела несколько глобальных переделок, начиная от простой базы в MySQL до многокомпонентного распределенного сервиса.
В своей текущей реинкарнации поиск в Booking.com состоит их трех подсистем:
1) сервис auto-complete и устранения неоднозначности (disambiguation) в геопозиции;
2) сервис поиска по отелям и проверки их доступности (availability);
3) система предрасчета цен.
Первые две системы - это высокопроизводительные приложения, написанные на Java. Сервис поиска хранит свои индексы в in-memory хранилище, а данные - во встраиваемой базе данных RocksDB. Логика системы предрасчета цен написана на Perl, а в качестве хранилища используется MySQL.
Приходите на мой доклад, и я расскажу вам, как эволюционировал поиск вместе с ростом компании. Мы подробно рассмотрим текущую архитектуру, и почему мы решили ее сделать именно такой. Ну и, конечно, с какими проблемами нам пришлось бороться и как мы это делали.
Кортунов Никита. Как ускорить разработку приложений или есть ли жизнь после P...AvitoTech
икита расскажет о возможностях backend as a service, ответит на вопрос есть ли жизнь после Parse, поделится опытом разработки BaaS Scorocode, особенностями архитектуры и кейсами применения, как можно ускорить разработку с помощью BaaS.
SOA: послать запрос на сервер? Что может быть проще?! / Иван Круглов (Booking...Ontico
РИТ++ 2017, HighLoad Junior
Зал Конгресс-холл, 5 июня, 10:00
Тезисы:
http://junior.highload.ru/2017/abstracts/2577.html
Микросервисы - это круто, модно и интересно. Переход на их использование принесет команде заметные преимущества. Но сервис-ориентированная архитектура (SOA) не лишена недостатков. Один их них - это то, что, заменяя простой вызов функции на RPC, мы в неявном виде вводим в уравнение, отвечающее за стабильность системы, целую плеяду новых неизвестных. Например, простейший HTTP-запрос за время своей жизни проходит через множество всевозможных буферов, очередей и алгоритмов на своем пути от клиента к серверу и обратно. Совокупное поведение этих составляющих трудно предсказать, понять и правильно интерпретировать. И особенно трудно это сделать в нестандартных ситуациях.
В своем докладе я хочу поделиться опытом решения проблем, с которыми я столкнулся за время работы в Booking.com. Я расскажу, как небольшой тюнинг сервера и клиента существенно влиял на конечную стабильность системы.
Работа с геоданными в Go GDGNSK / Work with Geodata in GoMad Devs
Слайды с GDG DevFest Новосибирск про го, геоданные, ненависть к нод.жс и UDP.
Slides from GDG DevFest Novosibirsk about Go, geodata and hatred to Nod.js and UDP.
Автор: Андрей Минкин / Andrew Minkin
Рефакторинг монолита в микросервисы на Go / Refactoring of Monolithe to Micro...Mad Devs
Презентация с GDG Devfest Алматы, рассказывающая о том, как мы рефакторили мололит в микросервисы на Go.
Presentation at GDG Devfest Almaty describing how we refactored monolithe to microservices on Go.
Автор: Андрей Минкин / Andrew Minkin
Как строить архитектуру для отказоустойчивой службы такси / How to Build a ...Mad Devs
Доклад с конференции Highload++ 2015 об отказоустойчивой архитектуре
A report from the Highload++ 2015 conference in Moscow, describing the fallover architectures
Автор: Андрей Минкин / Andrew Minkin
http://www.highload.ru/2015/abstracts/1661.html
RTB и его проблематика должны быть знакомы участникам конференции - мало кто сегодня не слышал об этом способе получить много krps с жесткими ограничениями на время генерации ответа.
Вот и компания Qmobi решила поучаствовать в этой гонке и отхватить свой кусок пирога под названием “рынок мобильной рекламы”.
При первом подходе к снаряду задача выглядит довольно простой: вот запрос с критериями, вот база данных с ответами - выбирай по индексу и отвечай.
На самом деле все несколько сложнее. Начать с того, что некоторые критерии отбора - негативные. Затем мы имеем дело с выборкой по десятку индексов, каждый из которых обладает низкой cardinality. И, наконец, мы имеем дело с большими объемами: около 10М строк в исходных данных, около 10К строк в финальной выборке. Ах, нет, еще финальная выборка должна быть отсортирована по приоритету! И надо не забыть про атомарные блокировку и списание средств...
От идеи прототипа на perl пришлось отказаться еще на этапе постановки задачи :)
Итак, мы имеем задачу с интенсивным IO, высокой нагрузкой, высокими скоростями, сложными структурами данных и эвристическими алгоритмами.
Анализ имеющихся вариантов показал, что Go должен прекрасно подойти для этой задачи. О том, на основании каких соображений мы сделали такой вывод, и какие из этих соображений прошли проверку практикой, а какие - нет, будет рассказано в докладе.
Также в докладе будет рассказано о том, как сортировка была заменена случайной выборкой, и чем пришлось заплатить за то, чтобы эта замена оказалась равноценной.
Будет показано, почему мы наплевательски отнеслись к гипотетической потере 20% возможностей поучаствовать в аукционе, и почему реальный процент потерь много ниже.
Будет раскрыта роль СУБД MySQL в этом проекте, со всем блеском высокой производительности и нищетой отказоустойчивости.
Вопросы геотаргетинга, использования PostGIS и кэширования результатов поиска региона по координатам будут затронуты вскользь, как неоднократно обсуждавшиеся на этой и подобных конференциях.
А вот анатомия производительности приложения на Go будет рассмотрена подробнейшим образом - с графиками и числами.
Также подробно будут рассмотрены наши победы и поражения в борьбе со статис
RTB DSP на языке Go укрощение buzzwords / Даниил Подольский (Qmobi.Com)Ontico
RTB и его проблематика должны быть знакомы участникам конференции — мало кто сегодня не слышал об этом способе получить много krps с жесткими ограничениями на время генерации ответа.
Вот и компания Qmobi решила поучаствовать в этой гонке и отхватить свой кусок пирога под названием “рынок мобильной рекламы”.
Анализ имеющихся вариантов показал, что Go должен прекрасно подойти для этой задачи. О том, на основании каких соображений мы сделали такой вывод, и какие из этих соображений прошли проверку практикой, а какие — нет, будет рассказано в докладе.
Разгоняем ASP.NET Core / Илья Вербицкий (WebStoating s.r.o.)Ontico
HighLoad++ 2017
Зал «Рио-де-Жанейро», 8 ноября, 18:00
Тезисы:
http://www.highload.ru/2017/abstracts/2905.html
Прошло более года с того момента, как Microsoft выпустила первую версию своего нового фреймворка для разработки web-приложений ASP.NET Core, и с каждым днем он находит все больше поклонников. ASP.NET Core базируется на платформе .NET Core, кроссплатформенной версии платформы .NET c открытым исходным кодом. Теперь у С#-разработчиков появилась возможность использовать Mac в качестве среды разработки, и запускать приложения на Linux или внутри Docker-контейнеров.
...
Самые частые проблемы и пути решения при росте нагрузки и масштабировании про...Mad Devs
Презентация описывает самые частые проблемы и пути их решения при росте нагрузки и масштабировании проекта.
The presentation describes the most frequent problems and solutions for increasing loads and scaling of projects.
Автор: Андрей Минкин / Andrew Minkin
Рельсы прекрасный инструмент, но в некоторых ситуациях они не справляются.
В этом докладе рассказывается о таких ситуациях и одном из вариантов решения
2. Кто я
• Team Lead/Maddevs.io
• Nambataxi.kg
• Nambafood.kg
• 10 лет опыта(Sysadmin, Python/Go)
• https://github.com/meshbird/meshbird
• https://github.com/maddevsio/ariadna
25. Вытекающие задачи
• Собирать больше треков водителей
• Показывать ближайшие анимированные машины на
главном экране
• Хранить промежуточную стоимость на сервере
• Экономить трафик водителю
• Собирать трек раз в секунду
26. Расходы водителя за смену в Бишкеке
• 550 р бензин
• 200 р еда
• 200 р комиссия
• Средний чек – 100р
49. Как хранить
• В памяти
• R-tree
• Карта с водителями (ключ сессия)
• Карта с водителями (ключ номер борта)
50. Какой алгоритм на бэкенде?
• Получили пакет по UDP
• Получаем водителя со стораджа
• Если нет – получаем с Redis
• Проверяем, есть ли все нужные данные
• Делаем set в сторадже
51. Какой алгоритм на бэкенде?
• Если есть – обновляем
• Если нет – инициализируем LRU для координат
• Обновляем инфу в R-tree
65. Как стало в мобильных приложениях
• Получаем местоположение клиента
• Получаем ближайших водителей с маршрутом
• Анимируем каждую машинку
• Обновляем раз в 15 секунд
70. Самый главный слайд
• UDP+Protobuf для экономии трафика
• In-memory
• R-tree для выдачи ближайших водителей
• LRU cache для хранения последних координат
• OSRM для выравнивания треков на дороге