Балансировка нагрузки внешнего сервиса в Azure

Question

У нас есть служба .NET, размещенная в Azure (в настоящее время на виртуальной машине, а затем в качестве веб-задания), которая выполняет запросы HTTP / HTTPS к внешней общедоступной службе через сторонний API. В целях масштабируемости и надежности (поскольку служба ненадежна и, вероятно, будет недоступна в течение более длительных периодов времени при слишком большом количестве запросов), мы хотели бы сбалансировать нагрузку на эту службу.

Я думаю, что это гораздо лучше решается с помощью инфраструктуры, чем с помощью кода, но я не знаю достаточно об инфраструктуре, предлагаемой Azure, чтобы знать, может ли это быть решено даже с помощью инфраструктуры. Я прочитал обзорные документы о Azure load Balancer , но они говорят только о балансировке запросов в Azure (общедоступная и внутренняя балансировка нагрузки), а не о запросах, выходящих из это в интернет.

Итак, предлагает ли Azure некоторую инфраструктуру, позволяющую мне балансировать запросы, поступающие из моего приложения в Интернет?

Конкретные требования:

• Сопоставить одну конечную точку HTTP с числом настроенных конечных точек, в идеале с использованием настроенных весов (то есть выбрать конечную точку A в 66% случаев, конечную точку B в 22%, конечную точку C в 12%).
• Когда одна из настроенных конечных точек выходит из строя, прозрачно переключается на другую конечную точку и игнорирует отказавшую в течение некоторого времени.

Обновление (2018-05-06): @ kim, приведенный ниже, привлек мое внимание к диспетчеру трафика Azure, который использует балансировку нагрузки на основе DNS и опрос для автоматического переключения при сбое. Вероятно, это стандартный способ балансировки нагрузки, но идеальным решением для моей проблемы был бы прокси-сервер, который получает запросы, воспроизводит их на одной из конечных точек с балансировкой нагрузки, обнаруживает сбои прямо для одного запроса и немедленно переключается на другой ресурс, повторить запрос с другой конечной точкой. Таким образом, вызывающее приложение никогда не заметит, что что-то не так, если не будет рабочей конечной точки. Я понимаю, что это, вероятно, слишком специфично для моей проблемы, чтобы иметь стандартное инфраструктурное решение, но я все равно добавляю это, на всякий случай ...

Answer 1

Вы также можете настроить три конечные точки как часть внутреннего пула шлюза приложений. Это обеспечит проверку работоспособности и переключение на исправные конечные точки в случае сбоя данной конечной точки. Однако сегодня Application Gateway выполняет только циклический, а не взвешенный цикл.

Answer 2

Мне никогда не приходилось делать то, что вы описываете, но вот некоторые из моих мыслей. Следующие услуги могут быть полезны для вас:

• Azure Traffic Manager
  • Позволяет балансировать нагрузку внешних конечных точек
  • Работает на уровне DNS
  • Поддерживает взвешенную и приоритетную маршрутизацию Методы балансировки нагрузки
  • и т.д.
• Управление API Azure
  • Позволяет защищать доступ к API
  • Мониторинг и сбор аналитики
  • и т.д.

То, что вы можете попробовать, - это разместить диспетчер трафика перед вашими API, чтобы сбалансировать их нагрузку и следить за тем, чтобы они работали.

Затем поместите службу управления API поверх диспетчера трафика, чтобы защитить API и обеспечить контроль доступа к нему. Если в будущем вам понадобится переместить API, вы можете легко перенастроить службу управления API, чтобы она указывала куда-то еще.