Учебник по построению высоконагруженных систем презентация

Содержание

Цель доклада Представить набор инструментов, используемых в разработке архитектур высоконагруженных систем. Инструменты разные, правильные, не правильные, используйте на свой вкус ☺

Слайд 1Учебник по построению высоконагруженных систем
Олег Бунин

Слайд 2Цель доклада
Представить набор инструментов, используемых в разработке архитектур высоконагруженных систем. Инструменты

разные, правильные, не правильные, используйте на свой вкус ☺

Слайд 3Монолитное приложение
Приложение представляет из себя монолитный программный код.

Плюсы:
Отсутствие какого-либо оверхеда на

интеркоммуникацию сервисов;

Минусы:
Высокая сложность разработки;
В случае проблемы встает все;
Невозможность вести распределенную разработку.

Слайд 4Сервис-ориентированная архитектура
Каждый сервис решает строго определенную задачу. Основной минус этого подхода

заключается в наличии оверхеда на интеркоммуникацию сервисов между собой и на обработку API взаимодействия между слоями.

Слайд 5Ремесленный подход
Бизнес-логика проекта и инструменты для масштабирования разрабатываются одновременно, учитывая особенности

бизнес-логики именно этого проекта.


Слайд 6Ремесленный подход
Быстрая разработка любых новых решений;

Высокие требования к квалификации разработчиков –

низкая масштабируемость разработки;

Максимально эффективное использование технологий и аппаратного обеспечения;





Слайд 7Промышленный подход
Разработка инструментов для масштабирования происходит отдельно от разработки бизнес-логики прикладных

проектов.

Слайд 8Промышленный подход
Очень долгая разработка общих инструментов;
Очень быстрая разработка приложений – происходит

сборка страниц как в конструкторе Lego;
Возможность использовать для разработки приложений программистов средней и низкой квалификации – высокая масштабируемость разработки;
Повышенные требования к аппаратному обеспечению;



Слайд 9МАСШТАБИРОВАНИЕ АРХИТЕКТУРНОГО РЕШЕНИЯ

Слайд 10Вертикальное масштабирование
Увеличение производительности системы за счет увеличения мощности сервера.

В какой-то момент

мы все равно достигнем предела по процессору, памяти или жесткому диску.

Слайд 11Горизонтальное масштабирование
Увеличение производительности системы за счет подключения

дополнительных cерверов

Слайд 12Масштабирование “во времени”
Различные данные имеют различные требования к обновлению. Это позволяет

нам отложить часть обработки данных до более удобного случая.

Слайд 13ТРЕХЗВЕННАЯ СТРУКТУРА

Слайд 14Трехзвенная структура

Слайд 15МАСШТАБИРОВАНИЕ ФРОНТЕНДА

Слайд 16Для чего нужен фронтенд?
Отдача статического контента;
Буферизация запросов;
Масштабирование бекендов;
Обслуживание медленных клиентов.

Слайд 17Дублирование фронтендов

Слайд 18Балансировка фронтендов

Слайд 19Балансировка бекендов

Слайд 20МАСШТАБИРОВАНИЕ БЕКЕНДА

Слайд 21Функциональное разделение
Разные функциональные части работают и хранятся на разных серверах системы.

Слайд 22Классическое горизонтальное масштабирование
Низкая степень связности кода;
Share-nothing для горизонтального масштабирования;
Слоистость кода;
Минимизация использования

сложных запросов сразу к нескольким таблицам;

Слайд 23Кеширование
Единый кеш для всех бекендов;

Проблема инвалидации кеша;

Проблема старта с непрогретым кешем;

Слайд 24Проблема инвалидации кеша
Обновление по запросу (проблема race condition для нагруженных страниц);

Фоновое

обновление;

Слайд 25МАСШТАБИРОВАНИЕ “ВО ВРЕМЕНИ”

Слайд 26Очереди
Структура данных с дисциплиной доступа к элементам FIFO (First In First

Out).

Применения:
Отложенная обработка (рассылки, обновления лент новостей);
Межсервисная коммуникация;

Слайд 27Очереди: модерация

Слайд 28ИНТЕРКОММУНИКАЦИЯ

Слайд 29Антишквал
Ряд бекендов, выполняющих однотипные задачи. Запрос приходит на первый бекенд, начинает

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

Слайд 30Антишквал: решение с очередью
Промежуточное звено с очередью, бекенды сами забирают из

него задачи. Проблемы этого варианта:

Смешение подходов - синхронную задачу решают асинхронными методами;

Не решает проблему с тем, если фронт отключился, то запрос остался;

Те задачи, которые попали на тормозящий бекенд - пропадают. Это решается перестартом очереди.

Слайд 31Антишквал: умные запросы
Умные запросы от фронтенда:

Первый запрос к первому бекенду идет

с таймаутом 1 секунду. Второй запрос идет с таймаутом 2 секунды, третий - 3 секунды, а четвертого уже нет. То есть ограничиваем количество запросов;

Бекенд может принимать решение о том, что он перегружен (раз в секунду спрашивать LA и кэшировать его). При начале обработке запроса происходит проверка и если LA слишком высокий - отдаем фронту Gone Away (штатная ситуация - перейди к другому бекенду).

Слайд 32Интеркоммуникация сервисов
Задача: необходимо уведомлять одни части системы о событиях, которые происходят

в других частях:

размещение информации в пользовательских лентах (feeds) о событиях, произошедних в сообществах;
лайки;
комментарии;
рассылка писем;

Слайд 33Интеркоммуникация: решение с очередью

Слайд 34Интеркоммуникация: решение с очередью

Слайд 35МАСШТАБИРОВАНИЕ БАЗ ДАННЫХ

Слайд 36Типы баз данных
Реляционная модель: данные в базе данных представляют собой набор

отношений;
Иерархическая модель: база данных состоит из объектов с указанием отношений родитель ⬄ ребенок;
Сетевая модель: база данных со структурой в виде графа;
Объектно-ориентированная модель: база данных, в которой данные представлены в виде моделей объектов.

Слайд 37Шардинг
Базовый принцип: те данные, которые в дальнейшем потребуются вместе, так же

должны храниться вместе.

Примеры:
Пользователи;
Посты в сообществах;
Блоги;

Принципы разбиения данных на шарды:
Центральный диспетчер, знающий, что где лежит;
Хэш-функция, по ключу вычисляющая шард;
Хэш-функция, по ключу вычисляющая виртуальный шард + таблица соответствий виртуальных шардов реальным.

Слайд 38Виртуальные шарды

Слайд 39Партиционирование
Функциональное разделение базы данных.

Разные данные хранятся в разных таблицах.
или
Разные данные хранятся

в разных СУБД.
или
Разные данные хранятся в разных типах СУБД.

Слайд 40Кластеризация

Слайд 41Репликация

Слайд 42Денормализация данных
Денормализация  — намеренное приведение структуры базы данных в состояние, не

соответствующее критериям нормализации, обычно проводимое с целью ускорения операций чтения из базы за счет добавления избыточных данных.

Слайд 43НАДЕЖНОСТЬ

Слайд 44Принципы надежности
Взаимозаменяемость серверов;
Избыточность данных, дублирование узлов:
Фронтенд: DNS-балансировка, CARP, heartbeat;
Бекенд: гомогенные взаимозаменяемые

бекенды;
База данных: дублирование данных, репликации, кластера;

Слайд 45ЭКСПЛУАТАЦИЯ

Слайд 46Мониторинг
Вы должны с абсолютной точностью знать, что происходит в системе. Мониторинг

бизнес-показателей.

Слайд 47Мониторинг: pinba

Слайд 48Мониторинг: pinba

Слайд 49Деплоймент
Регулярный быстрый автоматический деплоймент с возможностью сплит-тестирования и возможностью быстрого отката.

Слайд 50oleg.bunin@ontico.ru
facebook.com/oleg.bunin

Похожие презентации

Мистер Шерлок Холмс 501
Ученые химики. 336
Правила пользования библиотекой 387
Триггеры. Схемы простейших триггеров 1144
ПРОИЗВОДСТВО УСТРОЙСТВ ДЛЯ ИНТЕЛЛЕКТУАЛЬНОГО УПРАВЛЕНИЯ БЫТОВЫМИ ЭЛЕКТРОПРИБОРАМИ 197
Қауіпті өндірістік объектілерді 543

Обратная связь

Если не удалось найти и скачать презентацию, Вы можете заказать его на нашем сайте. Мы постараемся найти нужный Вам материал и отправим по электронной почте. Не стесняйтесь обращаться к нам, если у вас возникли вопросы или пожелания:

Email: Нажмите что бы посмотреть 

Что такое ThePresentation.ru?

Это сайт презентаций, докладов, проектов, шаблонов в формате PowerPoint. Мы помогаем школьникам, студентам, учителям, преподавателям хранить и обмениваться учебными материалами с другими пользователями.

Для правообладателей

Яндекс.Метрика