ASP.NET Core 3.1 — API Gateway Pattern — Azure (Parte 17)

No post ASP.NET Core 3.1 — API Gateway Pattern — Ocelot (Parte 16) eu falei sobre como criar um para proteger a API de Pagamento utilizando Ocelot. O Gateway foi construído utilizando ASP.NET Core.

Caso você possua uma infraestrutura no Azure, podemos pular este passo e utilizar o Azure API Management em substituição ao Gateway que foi construído, mas como um serviço.

Azure API Management

É um gerenciador para nuvem onde as APIs precisam estar publicadas também na nuvem, aqui no caso devem estar no Azure da Microsoft e este serviço vai realizar a segurança, proxy reverso, controle de fluxo entre outras funções para você sem a necessidade de ter que implementar o Ocelot.

Azure API Management Configuration

Nos serviços do Azure, procure por Azure API Management Services, a seguir há uma imagem de referência.

Clique em adicionar ( Add) para criar um novo serviço.
Eu crie um Resource Group específico para o API Management conforme está selecionado na imagem seguir, preencha as informações básicas e clique em criar.

O processo de criação é demorado, pode levar em torno de 20 minutos. Depois do serviço criado ele vai ficar com status “Activating”, este processo também pode levar um tempo para ser concluído. Depois disso o status para ser Online.

Pricing Tier

Sugiro que você sempre revise os custos de manter um serviço de Gateway no Azure, confira os detalhes aqui.
O seriço que eu criei, está configurado como “NO SLA” e no modo Developer, estas informações você pode obter nas colunas de detalhes dos custos

Configuration

Para acessar uma API através do Gateway do Azure, é necessário que a API esteja publicada, em seguida eu utilizei a opção “App Service” conforme imagem a seguir.

A imagem a seguir exemplifica como selecionar a API já publicada, perceba que a URL Base já será exibida e será através dela que acessaremos o Gateway para que ele acesse a API publicada.

O próximo passo é configurar o “endpoint” que ficará disponível para as aplicações de frontend, ou seja o endereço que será acessado após a URL Base da imagem anterior, a imagem a seguir explifica a configuração.

Nosso endereço de frontend será “pay-on-azure”. Um detalhe bem importante aqui, o “pay-on-azure” deve ser o mesmo da rota configurada lá na API, pois durante o roteamento feito pelo gateway, ele vai adicionar esta mesma rota lá no final da URL da API, no backend.

Para testar podemos utilizar a aba “Test” conforme mostra a imagem a seguir.

Overview

Depois de tudo isso, eu não poderia deixar de falar de algo muito importante, onde através da aba Overview do Gateway são mostradas diversas informações de grande relevância para o monitoramento, como: capacidade, erros, número de requisições, tempo que a requisição levou para ser executada no backend entre outras métricas conforme exibido na imagem a seguir.

Originally published at http://alextochetto.com on July 27, 2020.