Как настроить стратегию балансировки нагрузки для HTTP-реле WCF
Мы создаем платформу, которая позволит вызывать локальный API из облака, для этого мы используем реле WCF, что на самом деле является подходящим сервисом для нас, поскольку нам нужно создавать реле динамически (у нас есть встроенный API который отвечает за проверку клиентской лицензии и создает ретранслятор в Azure в случае действительной лицензии, чтобы обеспечить связь между облачным API и локальным API).
В данный момент наша команда QA работает над нагрузочными тестами, чтобы узнать, сколько трафика поддерживает платформа, во время тестов наша команда QA обнаружила странное поведение, когда они запускают тест с 50 одновременными запросами от JMeter.
По сути, в этом сценарии (50 одновременных запросов) некоторые запросы не выполняются из-за 502 ответов Bad Gateway, эти ответы поступают от ретранслятора, поскольку тип контента - XML.
Ответ 502 Bad Gateway говорит о том, что слушатель не принял соединение в пределах разрешенного интервала, но странно то, что как только мы получим ответ 502 Bad Gateway, больше не будут поступать запросы к слушателю (локальный API), Единственный способ восстановить связь - закрыть слушателя и запустить его снова.
Насколько я знаю, ретрансляторы WCF поддерживают балансировку нагрузки с использованием случайной стратегии выбора слушателя, ответственного за обработку запроса, я обнаружил поток в репозитории Github, принадлежащий службе ретрансляции WCF, где описан алгоритм балансировки нагрузки следующим образом:
- Получить локальную копию списка всех известных прослушивателей с балансировкой нагрузки для адреса, запрошенного отправителем (это происходит из кэша, который обновляется каждые 500 мс).
- Если список слушателей пуст, и мы не обновили список слушателей ровно один раз, принудительно обновите список известных слушателей с балансировкой нагрузки для конечной точки.
- Если список слушателей пуст, верните отправителю исключение и остановитесь.
- Выберите случайный индекс в списке потенциальных слушателей.
- Попробуйте встретиться с выбранным слушателем.
- Если это свидание удастся, тогда остановитесь.
- Если попытка сближения с выбранным слушателем не удалась в течение 10 секунд, удалите выбранного слушателя из списка слушателей, чтобы попробовать.
- Если прошло более 60 секунд, верните отправителю исключение.
- Переходите к шагу 2.
Если алгоритм работает описанным выше образом, то поведение по умолчанию очень чувствительно к DoS-атакам, поскольку после неудачной попытки сближения прослушиватель будет удален из списка прослушивателей, чтобы попытаться, это очень плохая идея, поскольку способ восстановить связь - подключить прослушиватель, в нашем случае это означает, что пользователь выполняет действие вручную, поскольку мы размещаем службу WCF в службе Windows (пользователь должен перезапустить службу Windows в случае неудачной попытки сближения).).
Самое смешное, что мы применяем "ConnectionStatusBehaviour" к конечной точке, чтобы регистрировать любые проблемы с подключением, и мы не видим ничего странного в журналах, по-видимому, служба остается подключенной / подключенной, а в мониторе Azure слушатель остается подключенным как Что ж.
Есть какой-то способ настроить другое поведение, когда попытка свидания не удалась?
Наша текущая конфигурация WCF выглядит следующим образом:
Конфигурация фактической привязки (WebHttpRelayBinding)
- SecurityMode = Transport
- RelayClientAuthenticationType = RelayAccessToken
- IsDynamic = false
- UseDefaultProxy = false
- OpenTimeout = 10 секунд
- CloseTimeout = 10 секунд
- SendTimeout = 10 секунд
- ReceiveTimeout = TimeSpan.MaxValue
Актуальные услуги
- MaxConcurrentCalls = 160
- MaxConcurrentInstances = 1000
- MaxConcurrentSessions = 1160
Фактическое поведение службы Wcf
- InstanceContextMode = PerCall
- ConcurencyMode = Single
Сторона клиента
Реле WCF вызывается из приложения AspNetCore 2.2 с использованием HttpClient, поскольку адрес реле обнаруживается во время выполнения (в этом случае мы не можем использовать прокси WCF).
Приложение AspNetCore размещается в Azure.
слушатель
Развертывание на виртуальной машине в Azure. Режим подключения к системе настраивается со значением ConnectivityMode.Https.