Digital Web недавно опубликовала статью « Балансировка нагрузки на стороне клиента для приложений Web 2.0 ». Я хотел на минутку объяснить, почему я считаю эту технику балансировки нагрузки плохой идеей. Но сначала, вот концепция вкратце:
- Ваш веб-сайт развернут одинаковым образом на нескольких веб-серверах.
- Браузер вашего клиента получает список серверов веб-приложений с вашего сервера, скажем, в формате XML.
- Затем браузер «случайным образом выбирает серверы для вызова до тех пор, пока один из них не ответит», и «имеет заранее установленное время ожидания для каждого вызова. Если вызов занимает больше заданного времени, клиент случайным образом выбирает другой сервер, пока не найдет тот, который отвечает ».
Независимо от того, как долго и усердно я думаю об этой концепции, я не могу убедить себя, что она даже звучит хорошо в теории . Вот почему:
- У нас все еще есть единственная точка отказа. Что произойдет, если наше веб-приложение не сможет получить действительный список серверов?
- Правильное переключение — это трудно и неуместно. Сколько «заданного времени» клиент должен разрешить, прежде чем пытаться использовать другой сервер? Является ли этот период ожидания приемлемым для наших клиентов? Может ли приложение точно определить разницу между отключенным сервером и старой сетевой перегрузкой?
- Теперь, когда наш клиентский код содержит эту логику балансировки нагрузки, нам нужно еще много тестировать, чтобы убедиться, что она работает в каждом браузере на любой платформе.
- Нагрузка распределяется между серверами совершенно случайным образом. Браузер не может знать, что он только что отправил запрос на сервер, который уже занят.
Аппаратная балансировка нагрузки на стороне сервера предлагает много преимуществ по сравнению с этим методом на стороне клиента, которые слишком велики, чтобы их игнорировать. Некоторые другие вещи, которые вы должны учитывать:
- Аппаратный балансировщик нагрузки может распределять запросы на серверы с наименьшей нагрузкой. Они также могут быстро обнаружить сбой в вашем веб-кластере и направить трафик в зависимости от ситуации. Зачем заставлять наших клиентов ждать, пока их браузер обнаружит этот сбой для нас, а затем решить, какие действия уместны? Качество этого приложения обнаружения (разработчика) зависит и вряд ли гарантировано.
- Устранить отдельные точки отказа. Настройка балансировщика нагрузки с резервированием значительно снижает вероятность сбоя. Есть надежные способы сделать это, что не сделает дыру в вашем кармане.
- Вы можете размещать обновления на своем сайте таким образом, чтобы не запутать ваших клиентов; с помощью балансировщика нагрузки, чтобы скрыть серверы от клиента до тех пор, пока обновления вашего сайта не будут развернуты и протестированы.
- Балансировщик нагрузки также может выступать в качестве слоя кэширования для статических ресурсов. Это снижает нагрузку на ваши веб-серверы и быстрее доставляет контент вашим клиентам!
Наконец, я думаю, что если у вас возникли проблемы с созданием приложения таким образом, чтобы оно работало на нескольких узлах, и вы подписали чеки на 3 или 4 (или более) сервера, это не выглядит слишком сложным Поставьте по крайней мере один балансировщик нагрузки перед всей партией (2, если вы можете себе это позволить и управляете). Внедрение балансировки нагрузки на стороне клиента после того, как вы продвинулись так далеко, кажется порочным на всю вашу тяжелую работу
В моем следующем посте мы рассмотрим масштабирование и балансировку нагрузки. До тех пор… 🙂