Бөлісу құралы:

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

  • Мақала

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

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

Availability

Внимание

Эта функция доступна в ценовой категории Премиум и Разработка управления API, так как необходима поддержка виртуальной сети.

Архитектура

Общая архитектура Service Fabric основана на одностраничном веб-приложении, которое выполняет HTTP-вызовы к внутренним службам, предоставляющим API-интерфейсы HTTP. Пример такой архитектуры см. в статье Service Fabric Getting Started Sample (Пример приложения для начала работы с Service Fabric).

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

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

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

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

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

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

На платформе Service Fabric могут размещаться как службы с отслеживанием состояния, так и службы без отслеживания состояния. Их секционирование осуществляется на основе одной из трех схем: одноэлементное, по диапазонам значений Int64 и по именам. Разрешение конечной точки службы требует определения отдельного раздела конкретного экземпляра службы. При разрешении конечной точки службы следует указать имя экземпляра службы (например, fabric:/myapp/myservice), а также определенный раздел службы. Это не требуется делать при использовании одноэлементного секционирования.

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

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

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

Пример

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

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

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

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

Пример

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

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

Обзор топологии Service Fabric со службой управления API Azure

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

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

С этой целью операция службы управления 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.

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

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

Так же как и в примере со службой без отслеживания состояния, операция службы управления 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. Серверная политика вычисляет ключ раздела в пределах диапазона, преобразовав значение id в пути запроса URL-адреса в 64-битное целое число. Ключ раздела можно вычислить с помощью любого алгоритма.

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

Следующие шаги

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