Практический JS: балансировка на стороне клиента

Автор оригинала: Lei Zhu
  • Перевод
Примечание: ниже находится перевод статьи «Client Side Load Balancing for Web 2.0 Applications», в которой затрагиваются вопросы балансировки нагрузки между несколькими серверами и рассматривается решение, обеспечивающее балансировку такой нагрузки прямо на компьютере клиента.

Сервер обрабатывает HTTP (HyperText Transfer Protocol) запросы со стороны браузеров. Если вы введете в адресной строке URL, например, www.digital-web.com, то ваш компьютер отправит поисковый запрос для определения, какие именно сервера будут обрабатывать ваш запрос и пересылать данные. Техника обработки таких запросов для кластера веб-серверов называется балансировкой нагрузки.

Балансировка нагрузки для веб-приложений



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

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


читать дальше на webo.in →

Комментарии 12

    +9
    >Однако, стоит проверять заголовок referrer, чтобы убедиться, что именно ваш клиент осуществляет такие запросы, для безопасности вашего сайта.

    Под стулом
      0
      Voxlite является веб 2.0 приложение

      приложением
        0
        "Преимущества балансировки на стороне клиента..."

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

        Почему нет минусов?

        Балансировка на стороне клиента требует доп. кода, доп. времени ожидания для клиента (если произошел таймаут, и запрос должен идти на другой сервер) + хаки с кросс-доменностью.

        В итоге платим ту же цену, если не больше...

        Или может я что-то пропустил, и в этом все-таки есть рациональное зерно?
          +2
          Большое спасибо за перевод. Посмотрел оригинал, почитал комменты. Автор признает, что есть проверенные временем server-side решения, и они обкатаны, и они работают. У меня сложилось впечатление, что ему эта тема интересна как фича ради фичи. Т.е. раз есть теоретическая (а местами даже практическая, как видно из примеров) возможность сделать такую реализацию, значит надо ее сделать. Похоже, что реально он не имел дела с большими системами, и готов поменять единообразное и подконтрольное server-side решение на зоопарк клиентского софта, приперченный хаками. Иногда энтузиасты с горящими глазами могут быть опасны :))
            +1
            За статью спасибо, но перевод "кривоват", очень тяжело читать.
            Литературное терпение переводчика закончилось примерно в этом месте: "Хотя сервер обеспечивает такие ресурсы, как картинки, в современным веб-технологиях и этот факт существенно меняется"
              –2
              сухо, бредово. Балансировка должна осуществляться на стороне сервера.
                0
                мда. А как же DDOS? Если клиенты будут иметь доступ к каждому серверу - каждый сервер может быть сломан. Злоумышленник вообще может отдосить все сервера один за другим.. =).
                  +1
                  Несмотря на то, что сложновато было читать, было достаточно интересно, спасибо. По этой теме встречал мало обзоров.

                  P.S.: У вас ошибка в коде (<server> s1.myloadbalancedwebsite.com >/server<), закрывающий тег не совсем валиден :)
                    0
                    по-моему это все глупо по одной лишь причине:
                    клиентское приложение нужно изначально загрузить с сервера, и уж если он лежит, то все труды по клиентской балансировке до этого самого клиента просто не дойдут.
                    а если серверная балансировка нужна обязательно, то необходимость балансировки клиентской уже ставится под сомнение...

                    зы: сорри за поднятие старой темы
                      0
                      :) как показал Client Side, проблема актуальна
                      Все сложности начинаются там, где за первой страницей/картинкой клиент захочет увидеть десятую, а потом и сотую. А если у вас веб-приложение, а не веб-сайт, там число запросов вообще тысячами можно измерять
                        0
                        нет, нет, я понимаю. пожалуй, слишком резко сказал, признаю
                        однако использование клиентского баланса как полного решения проблемы нагрузок (автор как раз на этом настаивает, как мне кажется) слишком самоуверенно )
                        и минусы в статье указать действительно стоит.

                        а как идея - хорошо; может придется использовать, надо смотреть на нагрузки
                      0
                      Если вы хоть сколько-нибудь работали с AJAX, то, наверное, подумали: «Это не будет работать по причине кросс-доменной безопасности» (прим.: для предотвращения XSS-атак). Давайте рассмотрим и этот вопрос.
                      Применение техники Dynamic script Tag для осуществления запросов позволяет обойти ограничения по безопасности, ибо разрешает кросс-доменные вызовы.
                      Можно разрешить проблему намного проще. Информация с http://xmlhttprequest.ru :
                      Кросс-доменные запросы между наддоменами httр://a.site.com, httр://b.site.com на httр://site.com допустимы, через свойство document.domain, которое надо установить в site.com
                      // на странице a.site.com
                      ...
                      document.domain='site.com'
                      ...
                      // все, теперь могу делать XmlHttpRequest на site.com
                      req.open("POST", 'http://site.com/giveme.php')

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

                      Самое читаемое