Latest / M365.FM – Podcast de Microsoft 365, Copilot e IA em português / API Gateway explicado: roteamento, segurança e limitação de taxa para microsserviços – você precisa de um? (Dublagem IA)

Transcript

API Gateway explicado: roteamento, segurança e limitação de taxa para microsserviços – você precisa de um? (Dublagem IA) · M365.FM – Podcast de Microsoft 365, Copilot e IA em português

• 0:00
  Preparado para 10 dias de Microsoft 365, Copilot e ISO e as pessoas que estão moldando o futuro do trabalho e ISO?
• 0:07
  Em janeiro, a M365 com está de volta, desta vez, em uma escala maior.
• 0:12
  Junte-se a nós em sessões ao vivo, demonstrações reais e conhecimento prático de MVPs e especialistas do setor em todo o mundo.
• 0:18
  Nada de slides genéricos ou palavras da moda sem fim.
• 0:21
  Estamos abordando os desafios reais, Copilot Studio, agentes de A, fábrica, segurança, governança e automação.
• 0:28
  Seja você um profissional de TI, desenvolvedor ou líder de negócios, há sessões criadas para você.
• 0:35
  Com 10 dias completos, você pode explorar várias tecnologias e se conectar com uma comunidade global.
• 0:40
  Assista ao vivo e leve insights práticos para a sua organização.
• 0:45
  Janeiro de 2027, 10 dias, uma única comunidade de Microsoft.
• 0:49
  As inscrições já estão abertas.
• 0:51
  Acesse m35com.net e garanta sua vaga hoje mesmo.
• 0:55
  É m35com.net a...
• 0:59
  Inscreva-se agora em m35com.net e nos vemos.
• 1:03
  Ao vivo em janeiro.
• 1:05
  Você criou um aplicativo que funciona, depois adiciona outro serviço e mais outro.
• 1:08
  E, de repente, direcionar o tráfego entre eles vira um pesadelo.
• 1:11
  Então, o que exatamente é um Gateway de API?
• 1:12
  Você realmente precisa de um?
• 1:14
  Ao final deste episódio, você entenderá o que um Gateway de API faz,
• 1:17
  porque ele resolve o caos de gerenciar vários serviços e como saber se você precisa de um.
• 1:21
  Vamos começar com o problema, depois as partes e, em seguida, como tudo se encaixa.
• 1:27
  Problema? Portas demais.
• 1:29
  Imagine que você está administrando uma empresa que está crescendo rápido.
• 1:32
  Tem uma equipe de vendas no terceiro andar, contabilidade no subsólito e na ala dos fundos.
• 1:37
  Agora, imagine que cada um desses departamentos tenha a sua própria porta de entrada,
• 1:40
  seu próprio número de telefone e seu próprio segurança que não fala com os outros.
• 1:43
  Se você é um visitante tentando entregar um pacote, boa sorte.
• 1:46
  Você precisa saber exatamente qual porta usar, com qual segurança falar e o que fazer quando esse segurança estiver no intervalo.
• 1:50
  É exatamente isso que acontece quando seu aplicativo tem vários serviços de back-end e cada cliente chama cada um diretamente.
• 1:56
  O cliente, seja um aplicativo móvel, um site ou outro serviço, precisa saber onde cada serviço mora,
• 2:01
  como autenticar em cada um e o que fazer quando algo quebra.
• 2:05
  Cada serviço precisa lidar com sua própria segurança, seu próprio limite de taxa e seu próprio tratamento de erros.
• 2:09
  Isso é trabalho duplicado e é fácil as coisas ficarem consistentes.
• 2:12
  Veja um banco, por exemplo.
• 2:13
  Eles têm serviços separados para contas, pagamentos, empréstimos e detecção de fraude.
• 2:17
  Da maneira antiga, cada um é exposto diretamente.
• 2:19
  Um aplicativo móvel precisa conhecer quatro URLs diferentes, quatro métodos de autenticação diferentes de tratar erros.
• 2:25
  Isso representa quatro vezes mais complexidade e quatro vezes mais chances de algo dar errado.
• 2:29
  E é esse o caos que um gateway de API foi projetado para corrigir.
• 2:32
  Então qual é a solução?
• 2:34
  Que é um gateway de API?
• 2:35
  Imagine um gateway de API com a recepção de um hotel.
• 2:38
  Ao entrar, você não precisa saber em que andar fica a limpeza, onde é a cozinha ou como contatar a equipe de manutenção.
• 2:44
  Você apenas vai até a recepção, diz o que precisa, e eles cuidam do resto.
• 2:48
  Eles encaminham seu pedido à pessoa certa, verificam se você tem autorização e até resolvem solicitações básicas por conta própria.
• 2:54
  Um gateway de API faz a mesma coisa pelo seu software.
• 2:57
  Ele é um ponto de entrada único que fica entre seus clientes e seus serviços de back-end.
• 3:01
  Toda a solicitação passa primeiro pelo gateway.
• 3:03
  Ele decide para onde enviá-la, se deve permiti-la e o que deve retornar.
• 3:07
  Bem, essa não é uma ideia nova.
• 3:09
  Proxies reversos existem há décadas, mas o gateway de API tornou-se essencial com os microserviços.
• 3:14
  Quando você divide seu aplicativo em muitos serviços pequenos, você passa a ter muitas portas.
• 3:17
  O gateway oferece a você uma porta em telemórias.
• 3:19
  No mundo Azure, o Azure API Management é a plataforma completa, e o gateway é o componente central que gerencia o tráfego.
• 3:25
  Mas o padrão é o mesmo em toda parte.
• 3:27
  Um ponto de entrada, controle centralizado.
• 3:29
  Cada solicitação chega.
• 3:30
  O gateway é verifica, roteia e envia a resposta de volta.
• 3:33
  O cliente nunca fala diretamente com seu serviço de back-end.
• 3:35
  Ele só se comunica com o gateway.
• 3:37
  Vamos analisar o que significa na prática.
• 3:39
  Começando com a tarefa mais básica, roteamento.
• 3:42
  Parte 1, roteamento de tráfego.
• 3:44
  A função mais simples de um gateway de API é o roteamento, direcionando cada solicitação para o serviço correto.
• 3:49
  Pense como o site funciona.
• 3:50
  Quando você clica em um link, seu navegador envia uma solicitação.
• 3:53
  Essa solicitação tem um caminho.
• 3:54
  Se o caminho for usuário, o gateway sabe que deve enviá-la para o serviço de usuário.
• 3:57
  Se for pedidos, ele vai para o serviço de pedidos.
• 4:00
  O gateway lê o caminho, descobre para onde deve ir e o encaminha.
• 4:03
  Sem um gateway, seus clientes precisam conhecer a URL de cada serviço individualmente.
• 4:07
  O aplicativo móvel precisa do endereço de serviço de usuários, de pedidos, de pagamentos e de catálogo.
• 4:12
  Isso é um monte de URLs para gerenciar.
• 4:14
  E se qualquer um desses endereços mudar, você terá que atualizar todos os clientes.
• 4:17
  Com o gateway, os clientes conhecem apenas uma URL do gateway.
• 4:20
  Eles não se importam onde o serviço realmente reside.
• 4:22
  Eles apenas enviam sua solicitação ao gateway e ele cuida do resto.
• 4:25
  Este é um dos casos de uso mais comuns de um API Gateway.
• 4:28
  Roteamento baseado em recurso.
• 4:30
  A pesquisa do Apache Pzix destaca isso explicitamente.
• 4:32
  Você roteia com base no caminho, método HTTP, cabeçalhos e até na geolocalização do cliente.
• 4:37
  Se alguém na Europa envia uma solicitação, você pode roteá-lo para um datacenter europeu.
• 4:41
  Se alguém no ZOA envia uma solicitação, vai para um datacenter no ZOA.
• 4:44
  O cliente não sabe que nada disso está acontecendo.
• 4:46
  Eles apenas recebem uma resposta rápida.
• 4:47
  O roteamento também lida com um controle de versão.
• 4:49
  Digamos que é uma nova versão do seu serviço de uso.
• 4:51
  Os clientes antigos ainda usam barra V1 barra users e os novos usam barra V2 barra user.
• 4:56
  O gateway usa o roteio para back-end diferentes.
• 4:58
  Clientes antigos continuam funcionando enquanto você lança a nova versão.
• 5:01
  Você pode alterar seu back-end sem interromper seus clientes.
• 5:04
  Isso é muito importante ao gerenciar uma aplicação ativa com usuários reais.
• 5:07
  Pense em uma plataforma de e-commerce.
• 5:09
  Você tem serviços separados para o catálogo, carrinho de compras, checkout e contas de usuário.
• 5:13
  Se um gateway é um aplicativo móvel, precisa conhecer quatro URLs diferentes.
• 5:17
  Com um gateway, ele conhece apenas uma.
• 5:18
  O gateway lê o caminho, catálogo, carrinho, checkout, conta e envia cada solicitação ao serviço certo.
• 5:25
  O roteamento simples é a parte fácil.
• 5:26
  A próxima função é onde ele se torna realmente útil.
• 5:29
  Parte 2. Segurança na porta de entrada.
• 5:31
  Cada chamada de API precisa se verificar.
• 5:33
  Quem está fazendo essa solicitação?
• 5:34
  Eles têm as permissões corretas?
• 5:36
  Sem um gateway, cada serviço precisa lidar com sua própria autenticação.
• 5:39
  Isso significa trabalho duplicado e é fácil errar.
• 5:42
  Um serviço pode verificar tokens corretamente.
• 5:44
  Outro pode pular uma etapa e um terceiro pode usar um método diferente.
• 5:47
  Você acaba com uma segurança inconsistente em toda a sua aplicação.
• 5:51
  Gateway muda isso.
• 5:52
  Ele lida com autenticação e autorização em um único lugar central.
• 5:55
  Um local para verificar, um para aplicar e um para atualizar quando as políticas mudarem.
• 5:59
  Essa é uma das principais práticas de segurança.
• 6:01
  Ele valida chaves de API, JWTs, tokens ou ALF ou certificados em cada solicitação.
• 6:07
  Cada solicitação passa pela aplicação.
• 6:09
  Sem exceções.
• 6:10
  Gateway também pode aplicar regras.
• 6:12
  Você pode dizer, esta chave de API só pode chamar endpoints de leitura.
• 6:15
  Ou, este cliente só pode acessar o serviço de catálogo, não de pagamento.
• 6:19
  Você define permissões granulares no nível do Gateway e elas são aplicadas automaticamente.
• 6:23
  Serviços de back-end nunca precisam se preocupar com a autorização.
• 6:26
  Eles apenas processam a solicitação e enviam os dados de volta.
• 6:28
  Ponto é o seguinte.
• 6:29
  O Gateway é um lugar único para revogar o acesso quando algo dá errado.
• 6:33
  Se a chave de API de um cliente for comprometida, você a revoga no Gateway.
• 6:36
  Uma alteração, pronto.
• 6:37
  Você não precisa atualizar cada serviço ou reiniciar nada.
• 6:40
  A próxima solicitação com essa chave é rejeitada imediatamente.
• 6:43
  Vejamos um exemplo real.
• 6:44
  Um banco tem um serviço de pagamento sem um serviço de cobrança.
• 6:46
  Apenas o serviço de pagamento precisa de acesso descrito ao sistema de cobrança.
• 6:49
  O Gateway impõe isso.
• 6:51
  Se um cliente tentar escrever no sistema de cobrança pelo endpoint errado, o Gateway bloqueia.
• 6:55
  O serviço de cobrança nem chega a ver a solicitação.
• 6:57
  O Gateway também pode suportar MTLS e integração com o AF para maior proteção.
• 7:02
  Mas, em essência, é a sua primeira linha de defesa.
• 7:04
  Segurança é uma coisa.
• 7:05
  Mas e quando chegam muitas solicitações de uma vez?
• 7:08
  Parte 3.
• 7:09
  Gerenciamento de tráfego.
• 7:10
  O que acontece quando 10 mil usuários acessam seu app ao mesmo tempo?
• 7:14
  Talvez uma promoção relâmpago, lançamento de um produto viral ou uma terça-feira normal
• 7:18
  onde todos decidiram o lugar de uma vez.
• 7:20
  Sem um Gateway, seus serviços de back-end são atingidos diretamente e podem travar.
• 7:24
  Não lentamente, mas tudo de uma vez.
• 7:26
  É aí que entra o gerenciamento de tráfego.
• 7:28
  O Gateway pode limitar quantas solicitações cada cliente pode fazer.
• 7:32
  Rate Limiting e Throttling são recurso padrão.
• 7:34
  Você define as regras no Gateway e ele as impõe.
• 7:37
  Seu serviço de back-end nunca assenta o pico.
• 7:39
  Você pode definir cotas por usuário, por chave de API ou por endereço IP.
• 7:43
  Digamos que você tem um nível gratuito de sua API.
• 7:45
  Usuários gratuitos têm 100 solicitações por hora.
• 7:47
  Usuários premium têm 10 mil.
• 7:48
  O Gateway rastreia cada solicitação e aplica esses limites na entrada.
• 7:51
  Um usuário gratuito atinge o limite e o Gateway envia uma mensagem educada para tentar mais tarde.
• 7:56
  Os serviços de back-end nem ficam sabendo da solicitação.
• 7:59
  Eles continuam funcionando normalmente e atendem os clientes pagados.
• 8:01
  O Gateway também lida com o balanceamento de carga.
• 8:04
  Se você tiver várias instâncias do mesmo serviço rodando, o Gateway distribui as solicitações entre elas.
• 8:09
  A instância 1 recebe uma, a instância 2 recebe a próxima, a 3 é a seguinte.
• 8:13
  É automático.
• 8:14
  E se uma instância cair, o Gateway roteia para outra.
• 8:16
  Os clientes nunca pensam ver.
• 8:17
  Eles apenas recebem a resposta.
• 8:19
  O balanceamento de carga com verificações de saúde mantém tudo funcionando perfeitamente.
• 8:22
  O Gateway pinga cada instância para garantir que esteja ativo.
• 8:25
  Se não estiver, ele para de enviar tráfego para lá.
• 8:27
  Isso é especialmente importante para APIs de alto tráfego.
• 8:29
  Sem o Gateway, um pico de tráfego atinge seus serviços diretamente.
• 8:33
  Com o Gateway, o pico atinge primeiro o Gateway, que o absorve, distribui e protege seus serviços de ficarem sobrecarregados.
• 8:40
  Certo, mas e se os dados não parecerem corretos ao chegar?
• 8:44
  Parte 4, transformação de dados.
• 8:47
  Às vezes, os dados que seu cliente envia não correspondem ao que seu back-end espera.
• 8:50
  Talvez o cliente envie JSON, mas seu back-end só entenda XML.
• 8:53
  Talvez os nomes dos campos não sejam compatíveis.
• 8:55
  O cliente usa a first name e seu back-end espera nome.
• 8:59
  Essas incompatibilidades.
• 9:00
  Da maneira antiga, você teria que corrigir cada cliente ou reescrever o back-end.
• 9:05
  Gateway pode transformar os dados antes que cheguem ao back-end.
• 9:08
  Pense nele como tradutor.
• 9:09
  Ele fica no meio e pode alterar os dados na entrada, na saída ou em ambos.
• 9:13
  Isso é a transformação de solicitação e resposta em poucas palavras.
• 9:15
  Deixe-me dar um exemplo real.
• 9:17
  Digamos que você tem um sistema legado que espera XML.
• 9:19
  Ele está funcionando há 15 anos.
• 9:21
  Ele funciona bem.
• 9:21
  Mas agora você está criando um novo aplicativo móvel.
• 9:23
  E aplicativos móveis falam em JSON.
• 9:25
  Sem um Gateway, você teria que reescrever o sistema legado ou forçar o app a enviar XML.
• 9:30
  Com o Gateway, você não faz nenhum dos dois.
• 9:31
  O aplicativo móvel envia JSON.
• 9:33
  O Gateway o converte para XML.
• 9:34
  O sistema recebe o que espera.
• 9:36
  O aplicativo móvel recebe uma resposta já em JSON.
• 9:39
  Ninguém precisou reescrever nada.
• 9:40
  Essa é beleza disso.
• 9:41
  O Gateway também pode adicionar ou remover cabeçalhos, alterar URLs ou máscara dados sensíveis.
• 9:46
  Imagine que uma resposta inclua o número de cartão de crédito.
• 9:48
  Você não quer que isso retorne ao cliente.
• 9:49
  O Gateway pode removê-lo antes que a resposta saia ou substituí-lo por uma versão mascarada.
• 9:54
  O back-end nunca precisa mudar.
• 9:56
  O Gateway resolve isso.
• 9:57
  Isso é especialmente útil ao modernizar sistemas antigos.
• 9:59
  Você não precisa reescrever o back-end.
• 10:01
  Você não precisa forçar os clientes a mudar.
• 10:03
  Você apenas altera o Gateway.
• 10:04
  É como um tradutor em uma conferência internacional.
• 10:06
  Todos falam seu próprio idioma, mas o tradutor garante que todos se entendam.
• 10:10
  O Gateway é esse tradutor para o seu software.
• 10:12
  Então, roteamento, segurança, limitação, transformação é muita coisa.
• 10:15
  Mas não são quatro coisas separadas.
• 10:17
  Deixa eu mostrar como ele se conecta.
• 10:18
  Como tudo se conecta.
• 10:20
  Aqui está o...
• 10:21
  Essas quatro tarefas não são separadas.
• 10:23
  Elas trabalham juntas em cada solicitação toda vez que uma chega.
• 10:26
  O Gateway verifica a autenticação.
• 10:28
  Ele valida o limite de taxa.
• 10:29
  Ele roteva o serviço correto.
• 10:31
  Ele transforma os dados se necessário.
• 10:32
  Ele recebe a resposta de volta.
• 10:34
  Ele transforma isso também, se preciso.
• 10:36
  Então envia tudo de volta ao cliente.
• 10:37
  Pipeline.
• 10:38
  Cada etapa ocorre automaticamente, em ordem, sem que nenhum serviço precise pensar nisso.
• 10:42
  O verdadeiro poder não é um recurso único.
• 10:44
  É integração.
• 10:46
  Você pode adicionar uma nova política de segurança sem tocar no roteamento.
• 10:49
  O serviço de back-end sem alterar o cliente.
• 10:52
  Você pode atualizar os limites de taxa sem reimplantar nada.
• 10:54
  Cada parte é independente, mas todas funcionam no mesmo pipeline.
• 10:58
  E como tudo passa por um só lugar, você tem visibilidade total do que acontece.
• 11:02
  Logs, métricas, análises, tudo em um só ponto.
• 11:05
  Você pode ver quantas requisições chegaram, quais falharam, quais foram lentas e quais
• 11:08
  clientes usam mais recursos.
• 11:10
  Sem um Gateway, você teria que coletar esses dados de cada serviço individualmente.
• 11:14
  Com um Gateway está tudo ali.
• 11:15
  Essa é a grande sacada.
• 11:16
  O Gateway não é apenas um roteador.
• 11:18
  É um centro de controle para toda a sua plataforma de API.
• 11:20
  Cada requisição, cada resposta, cada erro, tudo flui por um só lugar.
• 11:23
  Você tem uma visão centralizada de tudo o que está acontecendo.
• 11:26
  Então, como você usa isso na prática?
• 11:28
  Vamos falar sobre o que você pode fazer agora mesmo.
• 11:30
  Dicas práticas.
• 11:31
  Vamos ser realistas.
• 11:32
  Se você tem um ou dois serviços, provavelmente ainda não precisa de um Gateway de API.
• 11:35
  Você pode lidar com o roteamento sozinho, gerenciando a autenticação em cada serviço.
• 11:38
  Não é elegante, mas funciona.
• 11:40
  Mas no momento em que você chega a três serviços ou expõe APIs a clientes externos,
• 11:43
  a complexidade aumenta rápido.
• 11:45
  O Gateway se paga rapidamente.
• 11:47
  Então, qual é o seu melhor primeiro passo?
• 11:49
  Centralize a autenticação no Gateway.
• 11:50
  Faça isso antes de qualquer outra coisa.
• 11:51
  Escolha um serviço e mova a verificação de autenticação dele para o Gateway.
• 11:54
  Você notará imediatamente que o código do seu serviço fica mais limpo.
• 11:57
  Chega de lógica de validação de token espalhada por toda parte.
• 12:00
  Chega de se perguntar se você implementou da mesma forma em todos os serviços.
• 12:03
  O Gateway resolve uma vez e todos os serviços se beneficiam.
• 12:06
  O próximo passo é o limite de taxa.
• 12:09
  Tem um limite simples para ter seu back-end de sobrecarga.
• 12:11
  Comece com algo básico como 100 requisições por minuto por cliente.
• 12:14
  Isso impede que um cliente descontrolado tire seus serviços.
• 12:16
  E até a próxima.