Основы масштабирования web прилжений

24 июня 2019 г.

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

Для начала рассмотрим типичную архитектуру сайта, ну а потом о масштабировании.

Итак, типичный web-проект — это обычно один Apache сервер, который обслуживает все HTTP запросы. Этот сервер формирует HTML страницы при помощи PHP скриптов и отдает статику. Под статикой подразумеваются картинки (jpg, gif, png), файлы стилей css, скрипты js.

Минус такой схемы в том, что разные по типу запросу – отдача статических файлов и вычислительная работа скриптов, обрабатываются одним сервером. Чтобы решить эту задачу необходимо разделить сервер на frontend, который будет отдавать статику. И backend, который будет формировать страницы. Для frontend обычно используют nginx. Для такого frontend сервера ожидание медленных соединений (когда у клиента медленный канал связи) почти не стоит каких-либо системных ресурсов.

Так же следует отметить еще один компонент обычного web сайта – это база данных. Наиболее популярными являются MySQL и PostgreSQL.

Теперь можно представить схематически архитектуру

web-scale

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

Дальше можно перенести frontend на другой сервер, но здесь выигрыш системных ресурсов будет уже не такой заметный как базой данных. Поэтому дальше лучше масштабировать backend сервер.

Дальше гам нужно произвести распределение вычислений на несколько серверов. Тут потребуется купить второй сервер и разместить на нем свои скрипты. После нужно сделать так, чтобы запросы пользователей распределялись (балансировались) между нашими серверами.

Балансирующий узел.

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

Балансировка на стороне клиента

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

Теги: рубрика Интернет