Service Fabric with Azure API Management overview(Service Fabric com descrição geral da Gestão de API do Azure)

  • Artigo

Geralmente, as aplicações da cloud precisam de um gateway de front-end que forneça um único ponto de entrada para utilizadores, dispositivos ou outras aplicações. No Service Fabric, um gateway pode ser qualquer serviço sem estado, como uma aplicação ASP.NET Core ou outro serviço concebido para a entrada de tráfego, como Os Hubs de Eventos, Hub IoT ou Gestão de API do Azure.

Este artigo é uma introdução à utilização do Azure Gestão de API como um gateway para as suas aplicações do Service Fabric. Gestão de API integra-se diretamente com o Service Fabric, permitindo-lhe publicar APIs com um conjunto avançado de regras de encaminhamento para os seus serviços do Service Fabric de back-end.

Disponibilidade

Importante

Esta funcionalidade está disponível nos escalões Premium e Programador do Gestão de API devido ao suporte de rede virtual necessário.

Arquitetura

Uma arquitetura comum do Service Fabric utiliza uma aplicação Web de página única que faz chamadas HTTP para serviços de back-end que expõem APIs HTTP. O exemplo de aplicação de introdução ao Service Fabric mostra um exemplo desta arquitetura.

Neste cenário, um serviço Web sem estado serve como gateway para a aplicação do Service Fabric. Esta abordagem requer que escreva um serviço Web que possa utilizar pedidos HTTP de proxy para serviços de back-end, conforme mostrado no diagrama seguinte:

Diagrama que mostra como um serviço Web sem estado serve como gateway para a aplicação do Service Fabric.

À medida que as aplicações crescem em complexidade, os gateways também têm de apresentar uma API em frente a vários serviços de back-end. O Azure Gestão de API foi concebido para processar APIs complexas com regras de encaminhamento, controlo de acesso, limitação de taxa, monitorização, registo de eventos e colocação em cache de respostas com um trabalho mínimo da sua parte. O Azure Gestão de API suporta a deteção do serviço Service Fabric, a resolução de partições e a seleção de réplicas para encaminhar de forma inteligente pedidos diretamente para serviços de back-end no Service Fabric, para que não tenha de escrever o seu próprio gateway de API sem estado.

Neste cenário, a IU da Web continua a ser servida através de um serviço Web, enquanto as chamadas à API HTTP são geridas e encaminhadas através do Azure Gestão de API, conforme mostrado no diagrama seguinte:

Diagrama que mostra como a IU da Web ainda é servida através de um serviço Web, enquanto as chamadas à API HTTP são geridas e encaminhadas através do Azure Gestão de API.

Cenários de aplicações

Os serviços no Service Fabric podem estar sem estado ou com monitorização de estado e podem ser particionados através de um de três esquemas: singleton, intervalo int-64 e com nome. A resolução do ponto final de serviço requer a identificação de uma partição específica de uma instância de serviço específica. Ao resolver um ponto final de um serviço, o nome da instância de serviço (por exemplo, fabric:/myapp/myservice) e a partição específica do serviço têm de ser especificados, exceto no caso da partição singleton.

O Azure Gestão de API pode ser utilizado com qualquer combinação de serviços sem estado, serviços com monitorização de estado e qualquer esquema de criação de partições.

Enviar tráfego para um serviço sem estado

No caso mais simples, o tráfego é reencaminhado para uma instância de serviço sem estado. Para tal, uma operação de Gestão de API contém uma política de processamento de entrada com um back-end do Service Fabric que mapeia para uma instância de serviço sem estado específica no back-end do Service Fabric. Os pedidos enviados para esse serviço são enviados para uma instância aleatória do serviço.

Exemplo

No cenário seguinte, uma aplicação do Service Fabric contém um serviço sem estado com o nome fabric:/app/fooservice que expõe uma API HTTP interna. O nome da instância de serviço é bem conhecido e pode ser codificado diretamente na política de processamento de entrada Gestão de API.

Diagrama que mostra que uma aplicação do Service Fabric contém um serviço sem estado que expõe uma API HTTP interna.

Enviar tráfego para um serviço com estado

Semelhante ao cenário de serviço sem estado, o tráfego pode ser reencaminhado para uma instância de serviço com monitorização de estado. Neste caso, uma operação de Gestão de API contém uma política de processamento de entrada com um back-end do Service Fabric que mapeia um pedido para uma partição específica de uma instância de serviço com monitorização de estado específica. A partição para a qual mapear cada pedido é calculada através de um método lambda com algumas entradas do pedido HTTP recebido, como um valor no caminho do URL. A política pode ser configurada para enviar pedidos apenas para a réplica primária ou para uma réplica aleatória para operações de leitura.

Exemplo

No cenário seguinte, uma aplicação do Service Fabric contém um serviço com estado particionado com o nome fabric:/app/userservice que expõe uma API HTTP interna. O nome da instância de serviço é bem conhecido e pode ser codificado diretamente na política de processamento de entrada Gestão de API.

O serviço é particionado com o esquema de partição Int64 com duas partições e um intervalo de chaves que abrange Int64.MinValue o Int64.MaxValue. A política de back-end calcula uma chave de partição dentro desse intervalo ao converter o id valor fornecido no caminho do pedido de URL para um número inteiro de 64 bits, embora qualquer algoritmo possa ser utilizado aqui para calcular a chave de partição.

Descrição geral da topologia do Service Fabric com o Azure Gestão de API

Enviar tráfego para vários serviços sem estado

Em cenários mais avançados, pode definir uma operação de Gestão de API que mapeia pedidos para mais do que uma instância de serviço. Neste caso, cada operação contém uma política que mapeia pedidos para uma instância de serviço específica com base nos valores do pedido HTTP recebido, como o caminho do URL ou a cadeia de consulta e, no caso dos serviços com monitorização de estado, uma partição na instância de serviço.

Para tal, uma operação de Gestão de API contém uma política de processamento de entrada com um back-end do Service Fabric que mapeia para uma instância de serviço sem estado no back-end do Service Fabric com base nos valores obtidos a partir do pedido HTTP recebido. Os pedidos a um serviço são enviados para uma instância aleatória do serviço.

Exemplo

Neste exemplo, é criada uma nova instância de serviço sem estado para cada utilizador de uma aplicação com um nome gerado dinamicamente com a seguinte fórmula:

  • fabric:/app/users/<username>

    Cada serviço tem um nome exclusivo, mas os nomes não são conhecidos antecipadamente porque os serviços são criados em resposta a entradas de utilizadores ou administradores e, portanto, não podem ser codificados em políticas apIM ou regras de encaminhamento. Em vez disso, o nome do serviço para o qual enviar um pedido é gerado na definição de política de back-end a name partir do valor fornecido no caminho do pedido de URL. Por exemplo:

    • Um pedido para /api/users/foo é encaminhado para a instância de serviço fabric:/app/users/foo
    • Um pedido para /api/users/bar é encaminhado para a instância de serviço fabric:/app/users/bar

Diagrama que mostra um exemplo em que é criada uma nova instância de serviço sem estado para cada utilizador de uma aplicação com um nome gerado dinamicamente.

Enviar tráfego para vários serviços com estado

Semelhante ao exemplo de serviço sem estado, uma operação de Gestão de API pode mapear pedidos para mais do que uma instância de serviço com monitorização de estado, caso em que também poderá ter de efetuar a resolução de partições para cada instância de serviço com monitorização de estado.

Para tal, uma operação de Gestão de API contém uma política de processamento de entrada com um back-end do Service Fabric que mapeia para uma instância de serviço com monitorização de estado no back-end do Service Fabric com base nos valores obtidos a partir do pedido HTTP recebido. Além de mapear um pedido para uma instância de serviço específica, o pedido também pode ser mapeado para uma partição específica na instância de serviço e, opcionalmente, para a réplica primária ou uma réplica secundária aleatória na partição.

Exemplo

Neste exemplo, é criada uma nova instância de serviço com monitorização de estado para cada utilizador da aplicação com um nome gerado dinamicamente com a seguinte fórmula:

  • fabric:/app/users/<username>

    Cada serviço tem um nome exclusivo, mas os nomes não são conhecidos antecipadamente porque os serviços são criados em resposta a entradas de utilizadores ou administradores e, portanto, não podem ser codificados em políticas apIM ou regras de encaminhamento. Em vez disso, o nome do serviço para o qual enviar um pedido é gerado na definição de política de back-end a name partir do valor fornecido pelo caminho do pedido de URL. Por exemplo:

    • Um pedido para /api/users/foo é encaminhado para a instância de serviço fabric:/app/users/foo
    • Um pedido para /api/users/bar é encaminhado para a instância de serviço fabric:/app/users/bar

Cada instância de serviço também é particionada com o esquema de partição Int64 com duas partições e um intervalo de chaves que abrange Int64.MinValue o Int64.MaxValue. A política de back-end calcula uma chave de partição dentro desse intervalo ao converter o id valor fornecido no caminho do pedido de URL para um número inteiro de 64 bits, embora qualquer algoritmo possa ser utilizado aqui para calcular a chave de partição.

Diagrama que mostra que cada instância de serviço também é particionada com o esquema de partição Int64 com duas partições e um intervalo de chaves que abrange Int64.MinValue para Int64.MaxValue.

Passos seguintes

Siga o tutorial para configurar o seu primeiro cluster do Service Fabric com pedidos de fluxo e Gestão de API através de Gestão de API para os seus serviços.