Обратный прокси-сервер в Azure Service Fabric

Обратный прокси-сервер, встроенный в Azure Service Fabric, помогает микрослужбам, работающим в кластере Service Fabric, обнаруживать и взаимодействовать с другими службами, имеющими конечные точки HTTP.

Модель связи микрослужб

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

  1. Определите местоположение сервиса с помощью службы именования.
  2. Подключитесь к службе.
  3. Объедините предыдущие шаги в цикле, который реализует политики разрешения служб и повторных попыток, применяемые к сбоям подключения.

Дополнительные сведения см. в разделе "Подключение и взаимодействие с службами".

Взаимодействие с помощью обратного прокси-сервера

Обратный прокси-сервер — это служба, которая выполняется на каждом узле и обрабатывает разрешение конечных точек, автоматическую повторную попытку и другие ошибки подключения от имени клиентских служб. Обратный прокси-сервер можно настроить для применения различных политик, так как он обрабатывает запросы от клиентских служб. Использование обратного прокси-сервера позволяет клиентской службе использовать любые клиентские библиотеки связи HTTP и не требует специального разрешения и логики повторных попыток в службе.

Обратный прокси-сервер предоставляет одну или несколько конечных точек на локальном узле, которые клиентские службы используют для отправки запросов другим сервисам.

Внутренняя связь

Примечание.

Поддерживаемые платформы

Обратный прокси-сервер в Service Fabric в настоящее время поддерживает следующие платформы

  • Кластер Windows: Windows 8 и более поздней версии или Windows Server 2012 и более поздних версий
  • Кластер Linux: обратный прокси-сервер в настоящее время недоступен для кластеров Linux

Достижение микрослужб за пределами кластера

Модель внешней связи по умолчанию для микрослужб — это модель согласия, из-за которой доступ к каждой службе невозможно получить непосредственно из внешних клиентов. Azure Load Balancer, который является сетевой границей между микрослужбами и внешними клиентами, выполняет преобразование сетевых адресов и пересылает внешние запросы во внутренние конечные точки IP:port. Чтобы сделать конечную точку микрослужбы доступной непосредственно внешним клиентам, необходимо сначала настроить Load Balancer для пересылки трафика на каждый порт, используемый службой в кластере. Однако большинство микрослужб, особенно микрослужб с отслеживанием состояния, не живут на всех узлах кластера. Микрослужбы могут перемещаться между узлами при отработки отказа. В таких случаях Load Balancer не может эффективно определить расположение целевого узла реплик, к которому он должен пересылать трафик.

Достижение микрослужб через обратный прокси-сервер извне кластера

Вместо настройки порта отдельной службы в Load Balancer можно настроить только порт обратного прокси-сервера в Load Balancer. Эта конфигурация позволяет клиентам за пределами кластера подключаться к службам внутри кластера с помощью обратного прокси-сервера без дополнительной настройки.

Внешнее взаимодействие

Предупреждение

При настройке порта обратного прокси-сервера в Load Balancer все микрослужбы в кластере, предоставляющие конечную точку HTTP, доступны за пределами кластера. Это означает, что микрослужбы, предназначенные для внутренних, могут быть обнаружены определенным злоумышленником. Это потенциально представляет серьезные уязвимости, которые могут быть использованы; Например:

  • Злоумышленник может запустить атаку типа "отказ в обслуживании", неоднократно вызывая внутреннюю службу, которая не имеет достаточно защищенной области атаки.
  • Злоумышленник может доставлять искаженные пакеты во внутренний сервис, что приводит к непреднамеренному поведению.
  • Служба, предназначенная для внутреннего использования, может возвращать частную или конфиденциальную информацию, не предназначенную для предоставления служб за пределами кластера, таким образом, предоставляя эту конфиденциальную информацию злоумышленнику.

Прежде чем сделать обратный прокси-порт общедоступным, убедитесь, что вы полностью понимаете и устраняете потенциальные последствия безопасности для кластера и приложений, работающих на нем.

Формат URI для адресации служб с помощью обратного прокси-сервера

Обратный прокси-сервер использует определенный универсальный формат идентификатора ресурса (URI) для идентификации секции службы, в которую следует перенаправлять входящий запрос:

http(s)://<Cluster FQDN | internal IP>:Port/<ServiceInstanceName>/<Suffix path>?PartitionKey=<key>&PartitionKind=<partitionkind>&ListenerName=<listenerName>&TargetReplicaSelector=<targetReplicaSelector>&Timeout=<timeout_in_seconds>

  • http(s): Обратный прокси-сервер можно настроить для приема трафика HTTP или HTTPS. Для перенаправления HTTPS обратитесь к безопасной службе с обратным прокси-сервером после установки обратного прокси-сервера для прослушивания HTTPS.

  • Полное доменное имя кластера (FQDN) | внутренний IP-адрес: Для внешних клиентов можно настроить обратный прокси-сервер таким образом, чтобы он был доступен через домен кластера, например mycluster.eastus.cloudapp.azure.com. По умолчанию обратный прокси-сервер выполняется на каждом узле. Для внутреннего трафика обратный прокси-сервер можно получить на локальном узле или на любом внутреннем IP-адресе узла, например 10.0.0.1.

  • Порт: Это порт, например 19081, который был указан для обратного прокси-сервера.

  • ServiceInstanceName: Это полное имя развернутой инстанции службы, к которой вы хотите получить доступ без схемы fabric:/. Например, чтобы получить доступ к фабрике:/myapp/myservice/ службе, вы используете myapp/myservice.

    Имя экземпляра службы чувствительно к регистру. Использование другого регистра для имени экземпляра службы в URL-адресе приводит к тому, что запросы завершаются неудачей с ошибкой 404 (не найдено).

  • Суффикс путь: Это фактический путь URL-адреса, например myapi/values/add/3, для службы, к которой требуется подключиться.

  • PartitionKey: Для секционированных служб это вычисляемый ключ секции, к которой вы хотите обратиться. Обратите внимание, что это не идентификатор раздела GUID. Этот параметр не требуется для служб, использующих схему одноэлементного разделения.

  • PartitionKind: Это схема секционирования службы. Это может быть "Int64Range" или "Named". Этот параметр не требуется для служб, использующих схему одноэлементного раздела.

  • ListenerName Конечные точки из службы имеют форму {"конечные точки":{"Листенер1":"Endpoint1","Листенер2":"Endpoint2" ...}}. Когда служба предоставляет несколько конечных точек, это определяет конечную точку, в которую должен пересылаться запрос клиента. Это может быть опущено, если служба имеет только один прослушиватель.

  • TargetReplicaSelector Это указывает, как следует выбрать целевую реплику или экземпляр.

    • Если целевая служба находится в состоянии, targetReplicaSelector может быть одним из следующих вариантов: PrimaryReplica, RandomSecondaryReplica или RandomReplica. Если этот параметр не указан, значение по умолчанию — PrimaryReplica.
    • Если целевая служба не сохраняет состояние, обратный прокси-сервер выбирает случайный экземпляр раздела службы для пересылки запроса.

  • Времени ожидания: Это указывает время ожидания HTTP-запроса, созданного обратным прокси-сервером службы от имени клиентского запроса. Значение по умолчанию — 120 секунд. Этот параметр является необязательным.

Пример использования

Например, давайте рассмотрим структуру:/MyApp/MyService , которая открывает прослушиватель HTTP по следующему URL-адресу:

http://10.0.0.5:10592/3f0d39ad-924b-4233-b4a7-02617c6308a6-130834621071472715/

Ниже приведены ресурсы для службы:

  • /index.html
  • /api/users/<userId>

Если служба использует схему одиночного секционирования, параметры строки запроса PartitionKey и PartitionKind не требуются, и к службе можно обращаться через шлюз следующим образом:

  • Внешне: http://mycluster.eastus.cloudapp.azure.com:19081/MyApp/MyService
  • Внутренне: http://localhost:19081/MyApp/MyService

Если служба использует схему секционирования Uniform Int64, параметры строки запроса PartitionKey и PartitionKind должны использоваться для доступа к секции службы:

  • Внешне: http://mycluster.eastus.cloudapp.azure.com:19081/MyApp/MyService?PartitionKey=3&PartitionKind=Int64Range
  • Внутренне: http://localhost:19081/MyApp/MyService?PartitionKey=3&PartitionKind=Int64Range

Чтобы получить доступ к ресурсам, предоставляемым службой, просто поместите путь к ресурсу после имени службы в URL-адресе:

  • Внешне: http://mycluster.eastus.cloudapp.azure.com:19081/MyApp/MyService/index.html?PartitionKey=3&PartitionKind=Int64Range
  • Внутренне: http://localhost:19081/MyApp/MyService/api/users/6?PartitionKey=3&PartitionKind=Int64Range

Затем шлюз перенаправит эти запросы на URL-адрес службы:

  • http://10.0.0.5:10592/3f0d39ad-924b-4233-b4a7-02617c6308a6-130834621071472715/index.html
  • http://10.0.0.5:10592/3f0d39ad-924b-4233-b4a7-02617c6308a6-130834621071472715/api/users/6

Специальная обработка служб совместного использования портов

Обратный прокси-сервер Service Fabric пытается заново определить адрес службы и повторить запрос, если служба недоступна. Как правило, если служба недоступна, экземпляр службы или реплика перемещается на другой узел как часть его обычного жизненного цикла. В этом случае обратный прокси-сервер может получить сообщение об ошибке сетевого подключения, указывающее, что конечная точка больше не открыта в исходно разрешенном адресе.

Однако реплики или экземпляры служб могут совместно использовать процесс узла, а также предоставлять общий доступ к порту при размещении веб-сервера на основе http.sys, включая:

В этой ситуации, скорее всего, веб-сервер доступен в узле и отвечает на запросы, но разрешенный экземпляр службы или реплика больше недоступен на узле. В этом случае шлюз получит ответ HTTP 404 с веб-сервера. Таким образом, ответ HTTP 404 может иметь два разных значения:

  • Случай 1. Адрес службы правильный, но ресурс, запрошенный пользователем, не существует.
  • Случай 2. Адрес службы неверный, а ресурс, запрошенный пользователем, может существовать на другом узле.

Первым случаем является обычная ошибка HTTP 404, которая считается ошибкой пользователя. Однако во втором случае пользователь запросил ресурс, который существует. Обратному прокси-серверу не удалось её обнаружить, поскольку сама служба перемещена. Обратный прокси-сервер должен снова устранить адрес и повторить запрос.

Таким образом обратный прокси-сервер должен различать эти два случая. Чтобы сделать это различие, необходимо указание от сервера.

  • По умолчанию обратный прокси-сервер предполагает вариант #2 и пытается разрешить и вновь отправить запрос.

  • Чтобы указать вариант #1 обратному прокси-серверу, служба должна вернуть следующий заголовок ответа HTTP:

    X-ServiceFabric : ResourceNotFound

Этот заголовок ответа HTTP указывает обычную ситуацию HTTP 404, в которой запрошенный ресурс не существует, и обратный прокси-сервер не попытается снова устранить адрес службы.

Специальная обработка для служб, работающих в контейнерах

Для служб, работающих в контейнерах, можно использовать переменную среды для Fabric_NodeIPOrFQDN создания URL-адреса обратного прокси-сервера , как показано в следующем коде:

    var fqdn = Environment.GetEnvironmentVariable("Fabric_NodeIPOrFQDN");
    var serviceUrl = $"http://{fqdn}:19081/DockerSFApp/UserApiContainer";

Для локального кластера Fabric_NodeIPOrFQDN по умолчанию задано значение localhost. Запустите локальный кластер с параметром -UseMachineName, чтобы убедиться, что контейнеры могут подключаться к обратному прокси, который работает на узле. Дополнительные сведения см. в разделе "Настройка среды разработчика для отладки контейнеров".

Для служб Service Fabric, выполняемых в контейнерах Docker Compose, требуется специальная конфигурация раздела ports в docker-compose.yml с http: или https:. Дополнительные сведения см. в статье о поддержке развертывания Docker Compose в Azure Service Fabric.

Дальнейшие действия

  • Last updated on