В ASP.NET есть способ написать собственный балансировщик нагрузки?

Question

Я работал над реализацией (1) сервера, (n) настройки серверов рабочей роли через WCF.Один сервер обрабатывает запросы, передает работу через WCF доступной рабочей роли, которая обрабатывает запрос и передает данные обратно на сервер.Это слишком сложно для того, с чем я могу справиться.Я пытаюсь упростить решение и подумал, что могу удалить компонент WCF, создав (n) серверы, каждый из которых способен обрабатывать как службу рабочих ролей, так и роль веб-сервера.Предположим, что каждый рабочий сервер может выполнять только (1) рабочую роль.

Таким образом, при поступлении запроса некоторый обработчик в стиле циклического перебора выбирает доступный сервер и перенаправляет HTTP-запрос этому серверу / работнику.,Этот сервер / работник выполняет свою работу и возвращает данные непосредственно запрашивающей стороне.

Это осуществимый подход?Я понимаю, что для некоторых продвинутых разработчиков решение WCF не представляет проблемы.Я спрашиваю, существует ли более простой, более взломанный подход, который позволил бы мне с моими ограниченными возможностями создать решение на 1 сервере, а затем реплицировать и сбалансировать нагрузку на несколько версий этого решения?

Любые предложения muchoapprecianado!

Answer 1

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

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

Например: Rackspace предлагает балансировку нагрузки в качестве дополнительной функции некоторых из своих планов хостинга.

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

Кроме того, рассмотрите возможность организации очереди / шины сообщений между вашим интерфейсным веб-сайтом и внутренней обработкой пакетной / интенсивной рабочей нагрузки. Таким образом, вы можете независимо масштабировать переднюю и заднюю части вашей системы.

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

---

Обновление 2012-01-31 на основе комментариев ОП:

Если вы хотите, чтобы ваши рабочие роли выполняли одну задачу за раз и возвращались к другой части работы, когда они больше не заняты, я предлагаю вам перевернуть вашу архитектуру:

Вместо того, чтобы использовать какой-либо интерфейсный сервер, попробуйте выяснить, кто из рабочих «занят» и распределить работу соответствующим образом, подумайте о том, чтобы ваш интерфейсный сервер помещал в очередь входящие сообщения во «входящую» очередь.

Рабочие "вытягивают" новый рабочий элемент из внешнего интерфейса, выполняют все необходимые работы, а затем информируют внешний интерфейс о завершении работы и запрашивают другой рабочий элемент.

Прелесть этого подхода в том, что он может масштабироваться линейно и может быть НАИБОЛЕЕ устойчивым.

Когда работник «вытягивает» новый рабочий элемент, интерфейсная метка времени отправляет сообщение и перемещает его во вторичную «ожидающую» очередь. Рабочие сообщают клиенту о завершении работы с рабочим элементом; внешний интерфейс перемещает завершенные элементы в «завершенную» очередь (или удаляет их, если это не имеет значения).

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

Очереди могут доставлять массу удовольствия :) Однако создание такой системы массового обслуживания может быть сложным, а обеспечение ее подлинной надежности может быть трудоемким и дорогостоящим.

К счастью, вы можете воспользоваться некоторыми очень эффективными реализациями шины сообщений, которые обеспечат вам 90% того, что вам нужно для этого! Мой фаворит - облачная Microsoft Azure Message Bus , которая предоставляет вам пуленепробиваемую инфраструктуру для длительных сообщений, пабов и очередей, которая идеально подходит для вашего сценария.

НТН.

Answer 2

Я бы не рекомендовал это.На первый взгляд балансировка кажется простой разработчикам («эй, я просто буду отслеживать каждый запрос и перенаправлять следующий на следующий сервер в очереди и т. Д.»), Но на самом деле это сложно, если это не совсем тривиально.Вам нужно подумать о поддержании квот нагрузки на сервер, об обработке отключившихся серверов и т. Д.

Если вы уже используете Server 2008, возможно, дешевле и проще (и гораздо эффективнее) использовать функции NLBОС вместо того, чтобы придумывать свою собственную. Этот , например, является хорошим примером настройки кластера NLB.

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

Удачи:)

Answer 3

Я бы посоветовал вам использовать совершенно другой подход.

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

Основной причиной этого является ваше требование, чтобы каждый сервер«способен обслуживать только 1 клиента за раз».

---

Итак, чтобы настроить:

1. Запрос приходит.
2. Запросзаписан в рабочую таблицу
3. Один из ваших рабочих серверов отправляет запрос на следующее задание.
4. Он назначен этому серверу.
5. Как только работа завершена,сервер помечает это как выполненное.

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

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

---

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

Может выполняться задание SQL так часто, что назначает работу.Он также может быть ответственным за переназначение в случае, если машине потребовалось слишком много времени для его обработки.