Лучшее решение не полагаться на близость к серверу - это делает вашу систему хрупкой. Я бы не ожидал, что ответ из учебника будет таким же, как я не ожидал бы ответа из учебника о том, как играть с тостером в ванне или как выполнять операции на головном мозге с помощью отвертки.
Если вам нужна липкая маршрутизация, то как вы ее реализуете, во многом зависит от того, как вы предлагаете работать с недоступным сервером - выполняете ли вы отработки отказа при запросах? Или просто прекратить обработку запросов, которые были бы направлены на этот сервер?
Сначала я подумал, что это очень глупый вопрос - какая уместность, если вы не пишете свой собственный прокси / балансировщик нагрузки (в этом случае вы уже должны знать, что он отвечает), но есть доступные прокси, которые позволяют вам реализовать ваш собственный директор.
Таким образом, в конечном итоге все сводится к тому, какие характеристики сеанса видны в HTTP-запросе. Поскольку IP-адрес может изменить средний поток, единственной практической характеристикой, которую вы можете использовать, является идентификатор сеанса - обычно реализуемый как cookie.