У меня есть служба, которая выполняет 4 запроса R(R1, R2, R3, R4) для выполнения задачи. Предположим, что первый R1 для получения проверки доступности ресурса, второй R2 для бронирования таблицы, 3-й R3 для пакета празднования дня рождения и окончательный запрос на генерацию PNR R4. Все эти запросы R(R1, R2, R3, R4) поступают от одной службы (одного физического сервера). Представьте, что R (R1, R2, R3, R4) является синхронным запросом, где после завершения R1 инициируются запросы R2, а после завершения R2, Инициируются запросы R3 и т. Д.
Я интегрирую стороннего провайдера с правилом белого списка IP-адресов.
Правила:
- Если вы сделали все 4 запроса от одного и того же Ip, то сторонний провайдер удовлетворил запрос и позволил завершить поток.
- Если запросы поступают с другого Ip, он просто отклоняет запросы.
Моя текущая реализация и архитектура: -
Яиспользование обратного прокси-сервера squid для балансировки нагрузки и внесения в белый список нашего запроса. Текущая архитектура поясняется на приведенной ниже схеме. 
Проблема: Я столкнулся с проблемой, что у NLB нет контекста относительно запроса, то есть нет способа узнать, что предыдущий подзапросприходил и шел к s1 или s2 или s3 прокси squid. Документация Aws NLB DOC , в которой предлагается использовать конфигурацию на основе IP, но это невозможно, когда я пытался это сделать.
Текущая конфигурация NLB - это TCP на порт 80 и пересылка в целевую группу.
Мой вопрос к сообществу
- Естьвозможно ли это с помощью NLB для достижения вышеуказанного?
- Если нет, то каковы все альтернативы?
- Это очень важный ресурс, мы хотели получить высокодоступное и экономически эффективное решение.
PS Мне известно, что alb (балансировщик 7-го уровня) обладает липкостью, и его можно включить, чтобы подзапрос мог перенаправить на соответствующий сервер squid.