У нас есть служба .NET, размещенная в Azure (в настоящее время на виртуальной машине, а затем в виде веб-задания), которая выполняет запросы HTTP / HTTPS к внешней общедоступной службе через сторонний API. Для масштабируемости и надежности (поскольку служба ненадежна и, вероятно, будет отключаться в течение более длительных периодов времени при выполнении слишком большого количества запросов), мы хотели бы сбалансировать нагрузку на эту службу.
Я думаю, что это гораздо лучше решить с помощью инфраструктуры, чем с помощью кода, но я недостаточно знаю об инфраструктуре, предлагаемой Azure, чтобы знать, можно ли решить даже с помощью инфраструктуры. Я прочитал обзорную документацию о балансировщике нагрузки Azure, но они говорят только о балансировке запросов в Azure (общедоступная и внутренняя балансировка нагрузки), а не о запросах, исходящих из него в Интернет.
Итак, предлагает ли Azure некоторую инфраструктуру, позволяющую мне выполнять запросы балансировки нагрузки, идущие из моего приложения в Интернет?
Конкретные требования:
- Сопоставьте одну конечную точку HTTP с несколькими настроенными конечными точками, в идеале с использованием настроенных весов (т. Е. Выберите конечную точку A в 66% случаев, конечную точку B в 22%, конечную точку C в 12%).
- Когда одна из настроенных конечных точек выходит из строя, прозрачно переключитесь на другую конечную точку и игнорируйте отказавшую в течение некоторого времени.
Обновление (06.05.2018): ответ @kim ниже привлек мое внимание к диспетчеру трафика Azure, который использует балансировку нагрузки и опрос на основе DNS для автоматического переключения при отказе. Вероятно, это стандартный способ балансировки нагрузки, но идеальным решением для моей проблемы был бы прокси-сервер, который получает запросы, воспроизводит их на одной из конечных точек с балансировкой нагрузки, обнаруживает сбой прямо для одного запроса и немедленно выполняет отработку отказа, повторная попытка запроса с другой конечной точкой. Таким образом, вызывающее приложение никогда не заметит, что что-то не так, если рабочая конечная точка не будет доступна. Я понимаю, что это, вероятно, слишком специфично для моей проблемы, чтобы иметь стандартное инфраструктурное решение, но я все равно добавляю это, на всякий случай ...
