Я зашел на несколько веб-сайтов и заметил, что все они используют технологию AJAX для многих задач, таких как чат, сообщения и т. Д. Очевидно, они используют много httprequest. Мой вопрос в том, если вы создаете простой веб-сайт с использованием AJAX и ожидаете, что в час будет только несколько человек, а затем у вас начнется примерно 1000 пользователей, которые будут регистрироваться в час - может ли одно веб-приложение обрабатывать больше запросов в час, если вы просто обновитесь до более быстрых серверов большего размера или код надо переписывать? Как именно «масштабировать» веб-приложение?
Это очень сложный вопрос, над которым много умных людей думают.
Тем не менее, вы можете ввести несколько проверенных и надежных механизмов, которые помогут повысить масштабируемость. Однако в конечном итоге все сводится к вашему приложению и к тому, как его конкретно масштабировать. Например, вы бы масштабировали Oracle иначе, чем Apache.
Прежде всего, не беспокойтесь слишком сильно о том, что может случиться. Слишком многие разработчики беспокоятся о «возможно» вместо того, чтобы беспокоиться о «сейчас». Подавляющее большинство приложений и веб-сайтов не требуют ничего необычного.
Помимо этого отказа от ответственности, как правило, существуют некоторые принципы, которых следует придерживаться при разработке и кодировании высокомасштабируемого приложения. На ум приходит понятие «ничего общего». Разделение проблем. Хорошие разработчики осознают это и могут использовать это с первого дня.
Список часто применяемых техник:
Кеширование. Реализация внешнего уровня, чтобы изображения и запросы данных не попадали на серверную часть. Также снова на уровне объекта через что-то вроде memcached. Цель состоит в том, чтобы минимизировать рабочую нагрузку и ответить клиенту как можно дальше.
Шардинг хранилища данных. Это позволяет горизонтально масштабировать уровень данных, так что можно добавлять дополнительные системы баз данных и серверы по мере достижения нашей емкости. Обычно существует «ключ осколка» или виды, определяющие, на каком сервере базы данных доступен данный фрагмент данных. Это не ограничивается уровнем РСУБД. Также следует учитывать файловое хранилище и многое другое.
Балансировки нагрузки. Позволяет нам добавлять больше внешних клиентов (веб-серверов) для обработки нагрузки запроса. Вот тут-то и появляется весь подход «без общего доступа». Эти веб-серверы не должны иметь состояния, чтобы отказ не имел значения. Затем можно масштабировать по горизонтали, добавляя больше машин. Поскольку наши данные распределены на внутреннем уровне, они просто переходят и обрабатывают запросы. Алгоритмы балансировки используются для выбора сервера, который не занят. Разложите нагрузку так сказать.
CDN. Этот вид основан на №1, но полагается на провайдеров CDN. Мы снова основываемся на концепции максимально возможного ответа на запрос. Есть даже целый язык "Edge Side Includes" для управления этим материалом.
Репликация данных. Например, один узел записи, который реплицируется на пару узлов чтения. Поскольку большинство веб-приложений поддерживают чтение, мы можем направлять чтение на узлы чтения, прокачивая записи через узлы записи. MySQL, Postgres, Oracle, MSSQL - все это поддерживают, как и согласованные в конечном итоге варианты NoSQL, такие как MongoDB. Это не обязательно является взаимоисключающим для №2.
Я уверен, что что-то забываю, когда вытаскиваю все это из памяти, но идею вы поняли. По сути, приложение должно быть масштабируемым. Если у вас есть это, можно распределять нагрузку и расти бесконечно за счет развертывания интеллектуальной архитектуры.