Как настроить балансировку нагрузки Azure для микросервисов?

Question

У нас есть инфраструктура микросервисов API, размещенная на Azure VM. На каждой виртуальной машине будет несколько API-интерфейсов, которые являются отдельными сайтами, работающими на Kestrel. Весь внешний трафик поступает через RP (работает на IIS).

У нас есть некоторые API, которые предназначены для приема внешних запросов, а некоторые - только для внутренних API.

Внутренние API-интерфейсы размещаются на шкалах с каждым виртуальным шкафом, который является репликой, на которой размещаются все внутренние API. Перед шкалой имеется внутренний балансировщик нагрузки (ILB)/vip. Корневая проблема заключается в том, что у нас есть внутренние API, которые вызывают другие внутренние API-интерфейсы, размещенные на одном и том же шкале. В идеале эти вызовы будут поступать в VIP (используя внутренний DNS), и VIP отправится на одну из машин в шкале. Но, похоже, Azure не позволяет это ... в документации:

You cannot access the ILB VIP from the same Virtual Machines that are being load-balanced 

Так как люди установить это с микро-услуг? Я вижу три способа, ни один из которых не идеален:

1. Отделить API от разных шкалеров. Не идеально, так как услуги очень легкие, и я не хочу втрое увеличивать расходы на Azure VM .
2. Преобразование внутреннего LB в внешний LB (добавьте публичный IP-адрес). Затем поместите этот LB в свою собственную сетевую безопасность group/subnet, чтобы разрешать только вызовы из нашего диапазона Azure IP. Я бы ожидал здесь большего латентного времени и выставлял конечные точки извне в в любом случае, создавая большую площадь поверхности атаки, а также более сложность конфигурации.
3. Настройте виртуальную машину на шлейф, если ему нужен вызов в ILB ... что означает, что любые запросы, исходящие от виртуальной машины, будут , обрабатываемые той же виртуальной машиной. Это нарушает цель микро-услуг за VIP. По какой-то причине внутренняя микросервис может быть отключена на той же машине и доступна на другой ... вот почему причина мы настроили медицинские зонды на ILB для каждой услуги отдельно. Если он просто возвращается к той же машине, вы теряете отказоустойчивость.

Любые указатели на то, как другие подошли к этому, будут оценены.

Спасибо!

Answer 1

Я думаю, что ваша проблема связана с обнаружением службы.

Балансиры нагрузки не предназначены для этого, очевидно. Вы должны рассмотреть специализированные программные средства, такие как Eureka (которые могут работать вне AWS). Обнаружение службы заставляет ваши микросервисы звонить друг другу после обнаружения.

Также обратите внимание на инструменты балансировки нагрузки на стороне клиента, такие как Ribbon.

Answer 2

Ответ @Cdelmas является удивительным на сервисе Discovery. Позвольте мне добавить свои мысли:

Для таких услуг, как ваш, вы также можете посмотреть прокси-сервер ZUUL Netflix для балансировки нагрузки на сервер и клиентскую сторону. Вы даже можете использовать Histrix на вершине Eureka для латентности и отказоустойчивости. Netflix опережает игру на этом.

Вы также можете заглянуть в продукт Consul.io для своей причины, если хотите использовать язык GO. Он имеет настраиваемую сценарию конфигурацию для лучшего управления вашими службами, позволяет расширенные конфигурации безопасности и использование конечных точек без останова. Eureka также делает это, но требует добавить сервер конфигурации (Netflix Archaius, Apache Zookeeper, Spring Cloud Config), закодированную защиту и поддержку доступа с помощью ZUUL/Sidecar.