Да, согласен, стормозил про апстрим. Ваши советы весьма разумны, более того, сейчас все приблизительно так и сделано, только как я сказал, помимо простого раунд-робина текущий балансировщик умеет динамически менять коэффициент веса бекенда, основываясь на задержке отклика GET-запроса к каждому из них. Я всего лишь спросил, может ли энджи так, или нет, простая функция ведь. Если нет, то как говорится "будем искать" того, кто умеет. Убеждать меня в том, что это бессмысленно - бессмысленно ), я ищу то, что ищу, не более.
> Очень просто определяется.
> На фронтенеде:
> -DNS-имя
> -Если домен один, то по URI
> На бекенде URI+Port
>
в этом случае, что мешает для одного DNS имени - один upstream (см. выше), ведущий на нужное приложение с проставленными внутри группы как нужно весами,
для другого - еще один upstream и т. п.
тогда в вашем примере:
> Приведу пример: скажем
> есть 10 бекендов, на которых крутится 16 разных веб-приложений.
> Аудитория у приложений разная как по количеству, так и по периодам
> пиковой нагрузки. Из этих 16 приложений одно самое "толстое" и для
> него полностью зарезервировано 3 бекенда, остальные бекенды
> универсальны. Так вот, при помощи простого раунд-робина не получится
> честно размазать нагрузку, "толстое" приложение будет периодически
> мешать остальным.
толстое приложение можно вынести в отдельный апстрим и никому оно при раундробине мешать не будет
