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

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 monitoração de estado, como um aplicativo ASP.NET Core, ou outro serviço projetado para entrada de tráfego, como Hubs de Eventos, Hub IoT ou Gerenciamento de API do Azure.

Este artigo é uma introdução ao uso do Gerenciamento de API do Azure como um gateway para seus aplicativos do Service Fabric. O Gerenciamento de API integra-se diretamente ao Service Fabric, permitindo que você publique APIs com um rico conjunto de regras de roteamento para seus serviços back-end do Service Fabric.

Disponibilidade

Importante

Esse recurso está disponível nas camadas Premium e Developer do Gerenciamento de API devido ao suporte de rede virtual necessário.

Arquitetura

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

Nesse cenário, um serviço Web sem estado serve como o gateway para o aplicativo Service Fabric. Essa abordagem requer que você escreva um serviço Web que possa fazer proxy de solicitações HTTP para serviços back-end, conforme mostrado no diagrama a seguir:

À medida que os aplicativos crescem em complexidade, o mesmo acontece com os gateways que devem apresentar uma API na frente de inúmeros serviços de back-end. O Gerenciamento de API do Azure foi projetado para lidar com APIs complexas com regras de roteamento, controle de acesso, limitação de taxa, monitoramento, log de eventos e cache de resposta com o mínimo de trabalho de sua parte. O Gerenciamento de API do Azure dá suporte à descoberta de serviços, resolução de partições e seleção de réplicas do Service Fabric para rotear solicitações de forma inteligente diretamente para serviços back-end no Service Fabric para que você não precise escrever seu próprio gateway de API sem monitoração de estado.

Nesse cenário, a interface do usuário da Web ainda é servida por meio de um serviço Web, enquanto as chamadas de API HTTP são gerenciadas e roteadas por meio do Gerenciamento de API do Azure, conforme mostrado no diagrama a seguir:

Cenários de aplicações

Os serviços no Service Fabric podem ser stateless ou stateful, e podem ser particionados usando um dos três esquemas: singleton, int-64 range e named. A resolução do ponto de extremidade do 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 de extremidade de um serviço, tanto o nome da instância de serviço (por exemplo, fabric:/myapp/myservice) quanto a partição específica do serviço devem ser especificados, exceto no caso de partição singleton.

O Gerenciamento de API do Azure pode ser usado com qualquer combinação de serviços sem monitoração de estado, serviços com monitoração de estado e qualquer esquema de particionamento.

Enviar tráfego para um serviço sem estado

No caso mais simples, o tráfego é encaminhado para uma instância de serviço sem monitoração de estado. Para conseguir isso, uma operação de Gerenciamento 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 monitoração de estado específica no back-end do Service Fabric. As solicitações enviadas para esse serviço são enviadas para uma instância aleatória do serviço.

Exemplo

No cenário a seguir, um aplicativo do Service Fabric contém um serviço sem estado chamado 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 do Gerenciamento de API.

Enviar tráfego para um serviço com monitoração de estado

Semelhante ao cenário de serviço sem estado, o tráfego pode ser encaminhado para uma instância de serviço com monitoração de estado. Nesse caso, uma operação de Gerenciamento de API contém uma política de processamento de entrada com um back-end do Service Fabric que mapeia uma solicitação para uma partição específica de uma instância de serviço com monitoração de estado específica. A partição para mapear cada solicitação é calculada por meio de um método lambda usando alguma entrada da solicitação HTTP de entrada, como um valor no caminho da URL. A política pode ser configurada para enviar solicitações somente para a réplica primária ou para uma réplica aleatória para operações de leitura.

Exemplo

No cenário a seguir, um aplicativo do Service Fabric contém um serviço stateful particionado nomeado 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 do Gerenciamento de API.

O serviço é particionado usando o esquema de partição Int64 com duas partições e um intervalo de Int64.MinValue chaves que se estende até Int64.MaxValue. A política de back-end calcula uma chave de partição dentro desse intervalo convertendo o id valor fornecido no caminho da solicitação de URL em um inteiro de 64 bits, embora qualquer algoritmo possa ser usado aqui para calcular a chave de partição.

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

Em cenários mais avançados, você pode definir uma operação de Gerenciamento de API que mapeie solicitações para mais de uma instância de serviço. Nesse caso, cada operação contém uma política que mapeia solicitações para uma instância de serviço específica com base em valores da solicitação HTTP de entrada, como o caminho da URL ou a cadeia de caracteres de consulta e, no caso de serviços com monitoração de estado, uma partição dentro da instância de serviço.

Para conseguir isso, uma operação de Gerenciamento 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 em valores recuperados da solicitação HTTP de entrada. As solicitações para um serviço são enviadas para uma instância aleatória do serviço.

Exemplo

Neste exemplo, uma nova instância de serviço sem estado é criada para cada usuário de um aplicativo com um nome gerado dinamicamente usando 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 à entrada do usuário ou administrador e, portanto, não podem ser codificados em políticas APIM ou regras de roteamento. Em vez disso, o nome do serviço para o qual enviar uma solicitação é gerado na definição de política de back-end a name partir do valor fornecido no caminho da solicitação de URL. Por exemplo:

  • Uma solicitação para /api/users/foo é roteada para a instância de serviço fabric:/app/users/foo
  • Uma solicitação para /api/users/bar é roteada para a instância de serviço fabric:/app/users/bar

Enviar tráfego para vários serviços com monitoração de estado

Semelhante ao exemplo de serviço sem estado, uma operação de Gerenciamento de API pode mapear solicitações para mais de uma instância de serviço com monitoração de estado, caso em que você também pode precisar executar a resolução de partição para cada instância de serviço com monitoração de estado.

Para conseguir isso, uma operação de Gerenciamento 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 monitoração de estado no back-end do Service Fabric com base em valores recuperados da solicitação HTTP de entrada. Além de mapear uma solicitação para uma instância de serviço específica, a solicitação também pode ser mapeada para uma partição específica dentro da instância de serviço e, opcionalmente, para a réplica primária ou uma réplica secundária aleatória dentro da partição.

Exemplo

Neste exemplo, uma nova instância de serviço stateful é criada para cada usuário do aplicativo com um nome gerado dinamicamente usando 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 à entrada do usuário ou administrador e, portanto, não podem ser codificados em políticas APIM ou regras de roteamento. Em vez disso, o nome do serviço para o qual enviar uma solicitação é gerado na definição de política de back-end a name partir do valor fornecido pelo caminho da solicitação de URL. Por exemplo:

  • Uma solicitação para /api/users/foo é roteada para a instância de serviço fabric:/app/users/foo
  • Uma solicitação para /api/users/bar é roteada para a instância de serviço fabric:/app/users/bar

Cada instância de serviço também é particionada usando o esquema de partição Int64 com duas partições e um intervalo de Int64.MinValue chaves que se estende até Int64.MaxValue. A política de back-end calcula uma chave de partição dentro desse intervalo convertendo o id valor fornecido no caminho da solicitação de URL em um inteiro de 64 bits, embora qualquer algoritmo possa ser usado aqui para calcular a chave de partição.

Próximos passos

Siga o tutorial para configurar seu primeiro cluster do Service Fabric com Gerenciamento de API e solicitações de fluxo por meio do Gerenciamento de API para seus serviços.