Русский
Русский
English
Статистика
Реклама

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


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

Помните "Черные Пятницы", которые так популярны среди людей? Знаете ли вы, что иногда сайты и веб-приложения не выдерживают такого огромного наплыва пользователей и в результате этого нередко теряют много денег?

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

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

Ознакомьтесь с некоторыми фактами о высокой нагрузке:

  • Высокая нагрузка возникает, когда один физический сервер становится не в состоянии эффективно выполнять обработку данных.

  • Если один экземпляр (instance) одновременно обслуживает 10 000 соединений - это высокая нагрузка. Высокая нагрузка - это одновременное обслуживание тысяч и миллионов пользователей

  • Если вы развертываете веб-решение на AWS (Amazon Web Services), Microsoft Azure или Google Cloud Platform, вы поддерживаете архитектуру для работы с высокой нагрузкой.

Вы можете столкнуться со следующими проблемами, если ваше веб-решение не выдерживает высоких нагрузок:

  • Медленная или бесконечная загрузка страниц

  • Случайные ошибки

  • Разрывы соединений с веб-сервером

  • Неполная загрузка контента

  • Снижение активности пользовательской аудитории

  • Потери клиентов

Как видите, архитектура проекта влияет на его успешность. Нет довольных клиентов - нет успеха и прибыли. Чтобы реализовать масштабируемые веб-приложения, необходимо понимать принципы разработки высокопроизводительных программных решений.

Принципы построения высокоэффективных решений

Динамика и гибкость

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

Либо потребуется добавить различные функции. А может вы решите продвигать свое приложение и привлекать клиентов. Поэтому вы должны обеспечить возможность эластичного масштабирования и обработки высоких нагрузок.

При разработке крупномасштабных веб-решений уделяйте особое внимание гибкости, так как это позволит вам легко вносить изменения и расширения. Гибкость, отсутствие предварительного планирования всех аспектов - важнейшая характеристика любой быстрорастущей программной системы.

Постепенный рост проекта

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

Если вы запускаете новый продукт, нет смысла сразу же создавать инфраструктуру, способную выдержать миллионы пользователей и одновременно обрабатывать их многочисленные запросы.

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

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

Масштабирование веб-решения - это постепенный процесс, состоящий из 4 основных этапов:

  • Анализ нагрузки

  • Определение областей, на которые в основном воздействует нагрузка

  • Передача этих областей отдельным узлам и их оптимизация

  • Анализ нагрузки

Разработка масштабируемой архитектуры веб-проекта

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

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

Разделение базы данных

Чаще всего первым узлом, который подвергается нагрузке, является база данных. Каждый запрос от пользователя к приложению - это, как правило, от 10 до 100 запросов к базе данных. Вынесение базы данных на отдельный сервер повысит ее производительность и снизит негативное воздействие на другие компоненты (PHP, Nginx и т.д.).

Миграция базы данных

В некоторых случаях перенос базы данных на другой сервер может стать проблемой для работающего веб-решения. Для эффективного переноса необходимо сделать следующее:

  • Используйте простое решение - разместите объявление о планируемых работах на сайте и сделайте перенос. Лучше сделать это ночью, когда активность пользовательской аудитории минимальна.

  • Используйте репликацию для синхронизации данных с одного сервера на другой. После настройки необходимо изменить IP-адрес базы данных в приложении на новый сервер. Затем - выключить старый сервер.

Разделение веб-сервера

Далее следует отделить веб-сервер, выделение которого на отдельный узел позволит оставить больше ресурсов для приложения. Если говорить о примере с PHP, то необходимо настроить развертывание продукта как на сервер Nginx, так и на сервер PHP, представляющий бэкенд.

Тогда Nginx сам отдаст статические файлы, а PHP-сервер будет занят только обработкой скриптов. Nginx обеспечивает подключение к бэкенду по IP-адресу:

server {server_name ruhighload.com;root /var/www/ruhighload;index index.php;location ~* .(php)$ {fastcgi_pass 10.10.10.1:9000;fastcgi_index index.php;include fastcgi_params;fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;}}

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

Используйте несколько бэкендов

Когда нагрузка возрастает, веб-приложение начинает работать медленнее. В какой-то момент причина будет заключаться уже в самой имплементации. Чтобы избежать подобных проблем, следует использовать несколько бэкендов PHP.

При инсталляции бэкендов убедитесь, что они имеют одинаковую конфигурацию. Используйте Nginx для балансировки нагрузки между ними. Для этого следует определить список бэкендов в апстрим (upstream) и использовать его в конфигурации:

upstream backend {server 10.10.10.1;server 10.10.10.2;server 10.10.10.3;}server {server_name ruhighload.com;root / var / www / ruhighload;index index.php;location ~ * . (php) $ {fastcgi_pass backend;fastcgi_index index.php;include fastcgi_params;fastcgi_param SCRIPT_FILENAME $ document_root $ fastcgi_script_name;}}

Когда вы начнете использовать несколько бэкендов, запросы от одного и того же пользователя будут отправляться на разные серверы. Это потребует единого репозитория для всех сессий.

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

Очереди задач и балансировка DNS

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

DNS поддерживает балансировку по принципу Round Robin, позволяя указать несколько IP-адресов принимающих веб-серверов, называемых фронтендами. В данном случае необходимо инсталлировать несколько одинаковых фронтендов, чтобы DNS выдавал разные IP-адреса разным клиентам. Таким образом, вы обеспечите балансировку между фронтендами.

Файловые хранилища

Загрузка и обработка файлов обычно происходит на стороне бэкенда. Наличие нескольких бэкендов совершенно неудобно и неэффективно, поскольку инженеры-программисты должны помнить, на какой бэкенд они загружают каждый файл.

Более того, это может снизить производительность бэкенда. Чтобы избежать подобных трудностей, следует использовать отдельные серверы для загрузки, хранения и обработки файлов.

Сделать это можно следующим образом:

  • Определить отдельный поддомен для файлового сервера.

  • Развернуть на сервере Nginx и небольшое приложение, которое может хранить файлы и обрабатывать их

  • Масштабирование путем добавления новых серверов и поддоменов (например, images1, images2, images3 и т.д.)

  • Перенести загрузку файлов на сторону клиента, чтобы форма отправляла запрос на определенный сервер.

Нет ничего сложного в том, чтобы создать приложение, которое пропорционально масштабируется по серверам по мере роста потока трафика. Отсутствие статических данных, балансировка нагрузки, 90% кэширования, надежная сеть доставки контента и так далее - и у вас готова архитектура для работы с высокой нагрузкой.

Однако ключевым моментом является экономическая эффективность. Скажем, у вас 100 тысяч пользователей и один сервер. Значит, чтобы получить 130 тысяч из них, нужно разместить еще один сервер. Кажется, что это довольно сложно, не так ли?

Поэтому следует сделать один шаг назад и подумать - какая часть системы вызывает проблему? Если это база данных, то перед началом разработки проекта выберите высокомасштабируемую базу данных. Или вы можете использовать несколько баз данных, например, одну для записи и одну для чтения (CQRS).

Определение и решение подобных проблем производительности заранее и без резкого увеличения затрат на инфраструктуру является эффективной практикой для решения возникающих высоких нагрузок.


Перевод материала подготовлен в рамках запуска курса "Highload Architect".

Всех желающих приглашаем на бесплатный демоурок Выбор архитектурного стиля (микросервисы, СОА и монолиты).

- ЗАПИСАТЬСЯ НА ДЕМОУРОК

Источник: habr.com
К списку статей
Опубликовано: 26.05.2021 16:17:30
0

Сейчас читают

Комментариев (0)
Имя
Электронная почта

Блог компании otus

Высокая производительность

Разработка веб-сайтов

Программирование

Высокие нагрузки

Архитектура приложений

Архитектурные стили

Монолит

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru