Общие сведения об управлении API Azure с помощью Service Fabric

Обычно, облачным приложениям требуется интерфейсный шлюз, который предоставляет единую точку передачи входящего трафика пользователей, устройств или других приложений. В Service Fabric шлюз может быть любой службой без отслеживания состояния, например приложением ASP.NET Core или другой службой, предназначенной для входящего трафика, таких как Центры событий, Центр Интернета вещей или управление API Azure.

В этой статье приведены общие сведения об использовании службы "Управление API Azure" в качестве шлюза для приложений Service Fabric. Служба управления API непосредственно интегрируется с Service Fabric. Это позволяет публиковать интерфейсы API с широким набором правил маршрутизации к внутренним службам Service Fabric.

Доступность

Архитектура

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

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

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

В этом сценарии веб-интерфейс по-прежнему обслуживается через веб-службу, а вызовы API HTTP управляются и направляются через управление API Azure, как показано на следующей схеме:

Сценарии приложений

Службы в Service Fabric могут быть как без отслеживания состояния, так и с отслеживанием состояния, и они могут быть секционированы с помощью одной из трех схем: одноэлементного, диапазона int-64 и именованного. Для разрешения конечной точки службы требуется идентификация определенной секции конкретного экземпляра службы. При разрешении конечной точки службы необходимо указать имя экземпляра службы (например, fabric:/myapp/myservice), а также конкретную секцию службы, за исключением случаев одноэлементной секции.

Управление API Azure можно использовать с любым сочетанием служб без отслеживания состояния, служб с отслеживанием состояния и любой схемы секционирования.

Отправка трафика в бестрансляционную службу

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

Пример

В следующем сценарии приложение Service Fabric содержит бестейтовую службу fabric:/app/fooservice, которая обеспечивает внутренний HTTP API. Имя экземпляра службы хорошо известно и может быть жестко закодировано непосредственно в политике входящего обработки управления API.

Отправка трафика в службу с отслеживанием состояния

Аналогично сценарию службы без отслеживания состояния, трафик можно перенаправить в экземпляр службы с отслеживанием состояния. В этом случае операция управления API содержит политику входящей обработки с серверной частью Service Fabric, которая сопоставляет запрос с определенным разделом конкретного экземпляра службы с сохранением состояния. Секция для сопоставления каждого запроса вычисляется с помощью лямбда-метода, используя некоторые входные данные из входящего HTTP-запроса, например значение в пути URL-адреса. Политика может быть настроена для отправки запросов только первичной реплике или случайной реплике для операций чтения.

Пример

В следующем сценарии приложение Service Fabric содержит разделенную службу с сохранением состояния, которая предоставляет внутренний HTTP API fabric:/app/userservice. Имя экземпляра службы хорошо известно и может быть жестко закодировано непосредственно в политике входящего обработки управления API.

Служба разделена на две части с помощью схемы секционирования Int64 и диапазоном ключей, охватывающим значения от Int64.MinValue до Int64.MaxValue. Политика back-end вычисляет ключ партиции в этом диапазоне, преобразуя значение, указанное в пути запроса URL-адреса, в 64-разрядное целое число, хотя здесь можно использовать любой алгоритм для вычисления ключа партиции.

Направление трафика в несколько бесcостояничных служб

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

Для достижения этого операция управления API Management содержит политику обработки входящих данных с сервером Service Fabric, который связывается с экземпляром службы без состояния в системе Service Fabric на основе значений, полученных из входящего HTTP-запроса. Запросы к службе отправляются в случайный экземпляр службы.

Пример

В этом примере создается новый экземпляр службы без отслеживания состояния для каждого пользователя приложения с динамически созданным именем с помощью следующей формулы:

• fabric:/app/users/<username>

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

  • Запрос к /api/users/foo направляется к экземпляру службы fabric:/app/users/foo
  • Запрос к /api/users/bar направляется к экземпляру службы fabric:/app/users/bar

Отправка трафика в несколько служб с отслеживанием состояния

Как и в примере службы без отслеживания состояния, операция управления API может сопоставить запросы с несколькими экземплярами службы с отслеживанием состояния , в этом случае также может потребоваться выполнить разрешение секций для каждого экземпляра службы с отслеживанием состояния.

Для этого операция управления API содержит политику обработки входящих данных с использованием инфраструктуры Service Fabric, которая сопоставляется с экземпляром управляемой службы с состоянием в серверной части Service Fabric на основе значений, полученных из входящего HTTP-запроса. Помимо сопоставления запроса с конкретным экземпляром службы, запрос также можно сопоставить с определенным разделом в экземпляре службы, а также при необходимости с первичной репликой или случайной вторичной репликой в разделе.

Пример

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

• fabric:/app/users/<username>

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

  • Запрос к /api/users/foo направляется в экземпляр службы fabric:/app/users/foo
  • Запрос к /api/users/bar направляется к экземпляру службы fabric:/app/users/bar

Каждый экземпляр службы также секционируется с помощью схемы секционирования Int64 с двумя секциями и диапазоном ключей, который охватывает от Int64.MinValue до Int64.MaxValue. Политика back-end вычисляет ключ партиции в этом диапазоне, преобразуя значение, указанное в пути запроса URL-адреса, в 64-разрядное целое число, хотя здесь можно использовать любой алгоритм для вычисления ключа партиции.

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

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