Преимущества балансировки на стороне клиента

We use cookies. Read the Privacy and Cookie Policy

Преимущества балансировки на стороне клиента

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

Распределение нагрузки между кластером веб-серверов. Так как клиент выбирает сервер, с которого принимает запросы, случайным образом, загрузка будет распределена случайно (практически равномерно) между всеми имеющимися серверами.

Незаметное выключение неработающего сервера из кластера. У клиента всегда есть возможность подключиться к другому серверу, если первый не отвечает дольше заранее определенного времени. Таким образом, подключение клиента «мягко» передается от одного сервера другому.

Работающий кластер доступен для клиента как один сервер. В нашем примере пользователь просто открывает в браузере «http://www.loadbalancedwebsite.ru/», который и является для клиента единственным доступным сервером. Использование всех остальных «зеркал» происходит абсолютно незаметно.

Подведем итог: каковы же преимущества балансировки на стороне клиента перед балансировкой на стороне сервера? Наиболее очевидное заключается в том, что не требуется специальное балансирующее оборудование (хотя сам клиентский код будет являться достаточно сложным, полноценным веб-приложением), и не будет никакой необходимости настраивать аппаратную часть или проверять зеркальность вторичного балансировщика для страховки основного. Если сервер недоступен, его можно просто исключить из файла servers.xml.

Другим преимуществом является то, что все серверы не обязаны быть расположенными в одном месте. Клиент сам выбирает, к какому серверу ему лучше подключиться, в отличие от балансирующего сервера, который рассматривает его запрос и выбирает один из кластерных серверов для его обработки. Расположение серверов ничем не ограничено. Они могут находиться в различных дата-центрах на тот случай, если один из дата-центров окажется недоступен. Если приложению требуется база данных, расположенная в локальной сети, второй дата-центр может быть по-прежнему использован как запасной, если откажет основной. Переключение с одного дата-центра на другой заключается просто в обновлении файла servers.xml вместо того, чтобы ждать распространения изменений в таблице DNS.