Чтобы балансировщик нагрузки был полезен, ваше приложение должно иметь возможность распределяться по нескольким «внутренним» серверам. Самая «чистая» версия этой настройки - та, в которой серверы бэкэнда полностью не сохраняют состояния и не имеют никакого понятия «соединения» или «сеансов», и каждый запрос потребует примерно одинакового объема работы / ресурсов. В этом случае вы можете настроить loadbalancer на случайный прокси-запрос к пулу внутренних серверов. Примером такого приложения может быть статический веб-сервер.
Далее, чуть менее чистыми, будут те приложения, в которых фоновому серверу не требуется какое-либо определенное состояние в начале «соединения» или «сеанса», но необходимо поддерживать состояние, пока продолжаются эти сеансы, и поэтому каждый Клиент должен быть назначен на тот же сервер на время этого сеанса. Это немного усложняет ситуацию, так как тогда вам нужны «залипшие» соединения и, возможно, какой-то способ выбрать наименее загруженные серверы для маршрутизации новых соединений, а не делать это произвольно (поскольку сессии будут разной длины). SMTP-сервер является примером этого типа.
Худший тип приложений в этом смысле - это тот, в котором бэкэнд-сервер должен поддерживать глобальное состояние, чтобы быть полезным. Сервер базы данных - классический пример. Такого рода приложения практически невозможно сбалансировать нагрузкой без большого количества компромиссов, и, как правило, это самые большие и самые плохие серверы, которые используются типичными приложениями, потому что зачастую дешевле и проще с точки зрения разработки просто купить самую дешевую, самое дорогое из возможных аппаратных средств, по сравнению с суровыми реалиями распределенных систем, особенно если существуют зависимые системы (годы накопленного кода приложения), которые неявно делают предположения о целостности данных и т. д., которые не могут быть выполнены, например, при CAP теорема .