Здравствуйте, Ночной Смотрящий, Вы писали:

V>>Для джавовских серверов такой диспетчер обычно нейтивный
НС>В облаке он часто вообще железый.

Или на nginx и его аналогах.
"Железный" диспетчер — это тоже тупо линуховый или freebsd бокс с прошивкой.


НС>Но проблема вообще не в нем, а в самих серверах, выполняющих прикладную логику.

Верно, но возражая таким образом, ты делаешь вид, что не понимаешь, о чём тебе говорят. ))

Да, проблема в потенциальном падении проги сервера, однако джавовские серваки обычно не обеспечивают живое дублирование сессии на другом узле.
Т.е. получается или потеря сессии для stateful или подсовывание другого сервака для stateless.
Аналогично происходит с перезапуском нейтивного сервера — с теми же эффектами и примерно теми же таймингами.


НС>Если у тебя такой сервер один, на чем бы он не был писан — с SLA у тебя будут проблемы.

Если б ты еще сценарии внимательно в голове протрассировал, понял бы, как это работает.


V>> и в этом тоже есть свой резон — время его запуска составляет менее секунды, тогда как время запуска сервера приложений может составлять несколько секунд или десятки секунд
НС>В реальности от единиц до десятков минут.

Тем более.
А на что тратится это время, почему бы вслух не озвучить? ))


НС>>>или геораспределенность.
V>>При геораспределенности можно смело говорить о независимой работе серверов приложений
НС>Нельзя.

Можно, бо если используется еще +1 диспетчер на входе (типа как google.com перекидывает на google.ru), то такой +1 диспетчер будет и для нейтивной реализации, а за этим доп. диспетчером работают относительно независимые части системы.


V>>, т.к. это резко отличается от стандартного джавовского сценария,
НС>Нет никакого стандартного джавовского сценария в природе.

Описанный сценарий более-менее устоявшийся при масштабировании джавовских серверов.