Имеет ли смысл иметь такую архитектуру, в которой пользователи подключаются к https://a.com затем HAProxy выполняет перенаправление TCP на один из серверов, определенных в кластере, затем, как только этот сервер получает данные (NGINX), он расшифровывает SSL и затем передает запрос серверу приложений (COldFusion) на другом компьютере. Итак, в основном данные проходят через 3 машины: HaProxy, NGIX и, наконец, CF.
Задержка здесь большая проблема?
Похоже, вы делаете преждевременную оптимизацию. если ты уже есть нагрузка, которая гарантирует эту архитектуру, тогда вы также должны иметь факты о загрузке процессора и т. д. с ваших текущих серверов.
Итак, в основном данные проходят через 3 машины: HaProxy, NGIX и, наконец, CF. Задержка здесь большая проблема?
Обычно нет. Конечно, каждый уровень добавляет немного задержки, но обычно она составляет менее 10 миллисекунд, даже с серверами общего назначения и программным обеспечением.
Но:
Как насчет того, чтобы сначала сделать:
---------------
Internet -> | nginx -> CF |
---------------
А потом позже:
------------- ------
Internet -> | nginx(SSL)| -> | -> | CF |
------------- | ------
| ------
| -> | CF |
| ------
И, наконец, чтобы полностью ответить на ваш вопрос: да, ваша установка имеет смысл; когда только расшифровка SSL - это больше, чем может обработать один сервер.
По сути, вы предлагаете модифицированную версию о чем писал Вилли Тарро в этом прекрасном обзоре техники балансировки нагрузки. Во многих случаях может быть проще просто использовать хеширование межсетевого экрана, уловки маршрутизации или циклический перебор DNS в самом начале (перед ускорителями SSL) вместо использования HAPRoxy в режиме TCP, как вы предлагаете - возможно, подумайте об этом.
Я считаю, что вы также можете расшифровать на уровне HAProxy, устраняя необходимость в nginx. Если HAProxy видит много трафика, я полагаю, вам может не понадобиться дополнительная нагрузка на обработку SSL, однако наличие трех машин кажется на одну больше, чем необходимо.