Da terminação de conexões à aplicação de políticas, governança, observabilidade e alta disponibilidade em plataformas corporativas de APIs
Edição aprofundada - material de estudo e consulta profissional
Por João Ricardo Dutra••Material integral
Do consumidor ao : controle centralizado no caminho da
Figura de abertura - O ocupa uma posição de mediação entre consumidores e .
Princípio central
O divide uma chamada em duas relações independentes: consumidor- e - .
Edição aprofundada - material de estudo e consulta profissional
Apresentação do capítulo
Os capítulos anteriores construíram as bases necessárias para compreender o funcionamento real de um . Endereçamento, , , , , certificados, autenticação, autorização, , OpenID Connect, , e federação não são temas periféricos ao : são mecanismos que ele frequentemente termina, valida, transforma, registra ou encaminha. Este capítulo reúne esses conhecimentos em uma arquitetura coerente.
Um é apresentado muitas vezes como uma caixa simples que fica na frente dos serviços. Essa representação é útil em diagramas de alto nível, porém insuficiente para operação. Na prática, o mantém listeners, termina conexões, seleciona , executa políticas, consulta repositórios, aplica limites, cria conexões com , transforma mensagens e produz telemetria. Cada chamada passa por estados diferentes, e uma falha pode acontecer antes de qualquer código de negócio ser executado.
A arquitetura também inclui elementos que não participam diretamente de cada requisição. Control planes distribuem configurações, management planes organizam ciclo de vida, portais atendem desenvolvedores, bancos armazenam metadados e componentes analíticos agregam eventos. Um desenho robusto precisa distinguir esses planos e decidir como o runtime se comporta quando algum componente de gestão está indisponível.
O objetivo deste capítulo é fornecer um modelo mental completo, independente de produto. Conceitos serão relacionados a arquiteturas encontradas em comerciais, serviços gerenciados, programáveis e plataformas híbridas. Os próximos capítulos entrarão nas políticas, no Axway e no Azure Management; por isso, este material enfatiza responsabilidades, fronteiras e decisões arquiteturais que permanecem válidas entre implementações diferentes.
Como estudar este capítulo
Acompanhe cada seção desenhando duas setas: consumidor para e para . Para cada seta, registre , , porta, , protocolo, , identidade e telemetria. Essa separação evita atribuir ao uma falha que ocorreu no ou atribuir ao consumidor uma falha criada no trecho de saída.
Objetivos de aprendizagem
Definir e diferenciá-lo de , , , controller e service mesh.
Explicar a separação entre , , e developer plane.
Descrever o ciclo completo de uma requisição desde o até o e a resposta.
Compreender roteamento, políticas, transformação, autenticação, quotas, e observabilidade.
Comparar topologias centralizadas, por domínio, em camadas, regionais, híbridas e gerenciadas.
Projetar alta disponibilidade, tolerância a falhas, consistência de configuração e continuidade operacional.
Relacionar , , certificados, pools de conexão, , e circuit breakers ao .
Analisar multitenancy, isolamento, governança e ciclo de vida de .
Dimensionar capacidade com base em conexões, throughput, latência, CPU, memória e dependências externas.
Diagnosticar falhas por etapa e construir evidências correlacionadas entre consumidor, e .
Estrutura do capítulo
21.1 O que é um
21.2 O que um não é
21.3 Planos de dados, controle, gestão e desenvolvedores
21.4 Anatomia de uma requisição no
21.5 Listeners, virtual hosts e seleção de
21.6 Motor de políticas e cadeia de processamento
21.7 Roteamento, descoberta e conectividade com
21.8 Segurança na entrada e na saída
21.9 Controle de tráfego, proteção e
21.10 Topologias e modelos de implantação
21.11 Alta disponibilidade e consistência
21.12 Estado, sessões e dependências externas
21.13 Observabilidade, auditoria e correlação
21.14 Governança, portal e ciclo de vida
21.15 Desempenho e planejamento de capacidade
21.16 Falhas, antipadrões e
21.17 Estudos de caso e laboratórios
Resumo, checklist, exercícios, glossário e referências
21.1 O que é um
Um é um componente de mediação que recebe chamadas de consumidores em um conjunto controlado de e as encaminha para serviços de conforme regras de segurança, tráfego, transformação e roteamento. Ele funciona como um ponto de aplicação de políticas no caminho da mensagem. A centralização de controles reduz duplicação entre serviços, melhora consistência e permite que sejam protegidos de exposição direta.
A palavra indica mudança de contexto. O componente não apenas encaminha bytes; ele pode encerrar uma conexão , interpretar , validar credenciais, converter uma identidade externa em contexto interno, selecionar uma versão de , transformar , chamar um serviço de autorização e criar uma nova conexão para o . Por isso, consumidor- e - são relações independentes.
Em termos de arquitetura, o atua principalmente no . A cada requisição, ele toma decisões com base em configuração publicada e em dados de runtime. Essas decisões precisam ser rápidas, determinísticas e observáveis. O não deve depender de uma chamada remota lenta para cada política simples, nem pode se tornar um ponto único de falha que bloqueia toda a plataforma.
Uma plataforma de pode incluir vários . Um externo protege públicas; outro atende integrações internas; um terceiro fica em uma região específica; dedicados podem ser usados por domínios regulados. A definição é funcional: todos são pontos de mediação e política, ainda que os produtos, topologias e responsabilidades variem.
Modelo mental
O não é apenas um endereço. Ele é um runtime que transforma uma chamada recebida em uma decisão de política e em uma nova chamada para um destino selecionado.
21.2 O que um não é
Um reverse aceita conexões em nome de servidores e encaminha mensagens. Todo executa alguma forma de reverse , mas nem todo reverse oferece catálogo, publicação, subscrição, analytics, autenticação delegada ou governança de ciclo de vida. O conceito de acrescenta uma camada de produto e política sobre a intermediação básica.
Um distribui conexões ou requisições entre destinos elegíveis. O também pode balancear , porém seu papel não se reduz a isso. Ele compreende a , a identidade do consumidor, a operação chamada e políticas associadas. Um balanceador L4 pode escolher uma instância sem interpretar ; um normalmente opera em L7, embora dependa de componentes L4 ao redor.
Um procura padrões de ataque em tráfego web. Ele complementa o , mas não substitui autorização de negócio, validação de , quotas por aplicação ou transformação de contratos. Um controller publica serviços de um Kubernetes e pode ter recursos de ; um service mesh controla tráfego entre workloads e pode possuir e . As fronteiras se sobrepõem, mas as responsabilidades de governança e exposição precisam continuar claras.
Finalmente, o não deve se tornar um disfarçado. Quando lógica de domínio, regras de negócio complexas e orquestrações extensas são acumuladas em políticas, a plataforma fica difícil de testar, versionar e evoluir. O deve executar mediação e controles transversais; a lógica que define o negócio continua pertencendo aos serviços responsáveis.
Tabela 1 - Conceitos próximos não devem ser tratados como sinônimos.
Componente
Responsabilidade principal
Relação com o gateway
Reverse proxy
Terminar e recriar conexões para upstreams.
É uma capacidade de base do gateway.
Load balancer
Distribuir fluxo entre destinos.
Pode existir antes, dentro ou depois do gateway.
WAF
Detectar e bloquear ataques web genéricos.
Complementa políticas específicas de API.
Ingress controller
Publicar serviços de um cluster.
Pode implementar ou integrar um gateway.
Service mesh
Controlar comunicação entre workloads.
Complementa o gateway na malha interna.
21.3 Planos de dados, controle, gestão e desenvolvedores
O é o conjunto de runtimes que processa tráfego. Ele mantém listeners, conexões, tabelas de rotas, políticas compiladas, e pools de . Sua prioridade é disponibilidade e baixa latência. Um problema no portal ou no banco de configuração não deveria interromper chamadas já publicadas, desde que o runtime tenha uma cópia válida e suficiente da configuração.
O transforma intenção em configuração distribuída. Ele recebe definições de , políticas, certificados, e parâmetros, valida consistência e publica estado para os runtimes. Dependendo da plataforma, essa distribuição ocorre por push, pull, banco compartilhado, arquivos, administrativas ou mecanismos de configuração dinâmica. O desenho precisa tratar versionamento, confirmação de aplicação e .
O concentra operações administrativas e de governança: criação de , controle de ambientes, administrativo, auditoria, catálogo, relatórios e automação de CI/CD. O developer plane atende consumidores e produtores por meio de portal, documentação, credenciais, produtos, planos e analytics. Esses planos podem estar no mesmo produto, mas possuem requisitos de segurança e disponibilidade diferentes.
A separação protege o runtime contra acoplamento excessivo. Também melhora segurança: a interface administrativa não precisa estar exposta na mesma rede ou porta do tráfego de . Em ambientes regulados, mudanças no podem exigir aprovação, assinatura de artefatos, segregação de funções e trilha auditável antes de alcançar o .
Figura 1 - A plataforma de possui planos com responsabilidades e criticidades diferentes.
21.4 Anatomia de uma requisição no
A jornada começa antes do . O consumidor resolve um nome, seleciona um endereço, estabelece ou e negocia . Um balanceador ou front door pode receber a conexão antes do . Quando o runtime finalmente aceita a mensagem, ele precisa associá-la a um e a uma definição de com base em , Host, método, caminho, ou outras propriedades.
Depois da seleção, o executa uma cadeia de processamento. Algumas etapas são comuns: validação de tamanho e formato, autenticação, autorização, quotas, transformação, enriquecimento, roteamento e observabilidade. A ordem importa. Aplicar uma transformação antes de validar assinatura pode alterar o conteúdo protegido; consultar um antes de autorizar pode vazar informação por tempo de resposta; registrar antes de mascarar dados pode violar privacidade.
No trecho de saída, o resolve o nome do , escolhe rota e endereço de origem, abre ou reutiliza uma conexão, negocia e envia a requisição transformada. A resposta percorre políticas de retorno, pode ser convertida, filtrada, armazenada em e registrada. Só então é devolvida pela conexão de entrada. Os dois lados podem usar versões diferentes de , certificados diferentes e diferentes.
Uma arquitetura operacional deve tornar essa sequência visível. com apenas status final não informam onde ocorreu a falha. O runtime precisa expor estágio, política, ID, escolhido, tempo de conexão, tempo de resposta e motivo de rejeição sem revelar segredos.
Figura 2 - Uma chamada é processada por estágios que podem aceitar, transformar, encaminhar ou interromper o fluxo.
21.5 Listeners, virtual hosts e seleção de
Um associa o runtime a endereços e portas nos quais aceitará conexões. Ele pode escutar em um específico, em todas as interfaces ou em endereços virtuais fornecidos por um . O define protocolos permitidos, versões de , certificados, limites de conexão e opções de . Uma configuração incorreta pode fazer a parecer indisponível mesmo quando as políticas estão corretas.
Virtual hosts permitem que várias compartilhem endereço e porta, diferenciadas por nome. Em , o participa da seleção do certificado durante o ; depois, o Host ou a autoridade identifica o destino lógico da requisição. e Host normalmente coincidem, mas não são o mesmo objeto. Divergências podem causar certificado incorreto, roteamento inesperado ou rejeição de segurança.
A seleção de costuma usar método e path após a escolha do host. Regras precisam ser determinísticas. Caminhos sobrepostos, curingas amplos, versões ambíguas e diferenças de barra final podem encaminhar uma chamada à política errada. É recomendável testar a tabela de rotas como um contrato, incluindo casos negativos e conflitos.
O também deve normalizar entradas com cuidado. Decodificação de , tratamento de barras duplicadas, case sensitivity e normalização de podem afetar segurança. Se o e o interpretam o caminho de formas diferentes, um atacante pode explorar a discrepância para contornar autorização ou .
O motor de políticas é a parte do que avalia regras sobre a requisição e a resposta. Uma política pode ser declarativa, como validar com issuer e audience específicos, ou procedimental, como executar um script. Produtos diferentes usam fluxos gráficos, , , linguagens próprias ou filtros encadeados. Independentemente da forma, a política precisa ter entradas, saídas, falhas e efeitos colaterais conhecidos.
Políticas transversais incluem autenticação, autorização, , quotas, , validação de , transformação, masking, , roteamento, e . A ordem de execução deve ser projetada. Por exemplo, autenticação normalmente precede quotas por consumidor; validação de tamanho deve ocorrer antes de parsing caro; sanitização de deve ocorrer antes da emissão do evento de auditoria.
O precisa distinguir falhas técnicas e decisões de negócio. Uma assinatura inválida pode gerar 401; escopo insuficiente, 403; limite excedido, 429; indisponível, 503; erro de conexão ou protocolo, 502. Respostas padronizadas melhoram experiência do consumidor e observabilidade, mas não devem esconder a causa interna nos administrativos.
Scripts e extensões oferecem flexibilidade, porém aumentam risco. Código arbitrário pode bloquear threads, consumir memória, vazar segredos ou criar dependências difíceis de governar. Prefira capacidades nativas e declarativas para controles comuns; use extensões apenas quando houver revisão, testes, limites e estratégia de manutenção.
Tabela 2 - Políticas precisam ser avaliadas pelo efeito operacional, não apenas pela funcionalidade.
Categoria
Exemplos
Pergunta de arquitetura
Segurança
JWT, mTLS, API Key, autorização.
A decisão é local ou depende de serviço externo?
Tráfego
Rate limit, quota, spike arrest.
O estado é por nó, cluster ou serviço global?
Mediação
Headers, JSON/XML, versionamento.
A transformação preserva semântica e assinatura?
Resiliência
Timeout, retry, circuit breaker.
A operação é idempotente e segura para repetir?
Observabilidade
Logs, métricas, traces, auditoria.
Como correlacionar inbound e outbound?
21.7 Roteamento, descoberta e conectividade com
Roteamento transforma a lógica em um destino físico. O destino pode ser uma fixa, um pool de servidores, um serviço descoberto por , um privado, um Kubernetes ou uma função gerenciada. O deve decidir como resolver nomes, quanto tempo manter respostas em , quando reavaliar e como reagir a mudanças de saúde.
A conexão com o é independente da conexão de entrada. O usa um endereço e uma porta de origem, possivelmente sujeitos a , allowlists e esgotamento de portas. Ele pode reutilizar conexões por , negociar /2, enviar diferente do Host e apresentar certificado de cliente em . Todos esses detalhes precisam estar alinhados com a expectativa do .
indicam se um destino está elegível, mas não garantem que todas as operações funcionem. Um teste superficial em /health pode retornar sucesso enquanto dependências críticas estão indisponíveis. Readiness deve representar capacidade real de receber tráfego. Drenagem é necessária durante para impedir que novas requisições sejam enviadas a uma instância em encerramento.
e circuit breakers melhoram resiliência quando aplicados com cuidado. Repetir automaticamente uma operação não idempotente pode duplicar pagamento ou criação de recurso. O precisa considerar método, idempotency key, estágio da falha e tempo restante do orçamento. Circuit breakers devem proteger o sistema sem transformar um problema local em indisponibilidade prolongada por configuração agressiva.
Tabela 3 - A conectividade de saída concentra grande parte dos problemas 502 e 503.
Elemento
Função
Falha típica
DNS / discovery
Localizar endpoints atuais.
Cache obsoleto ou resolução privada ausente.
Pool de conexões
Reutilizar transporte e reduzir handshakes.
Conexões ociosas fechadas pelo peer.
Health check
Retirar destinos incapazes.
Falso positivo por teste superficial.
Retry
Recuperar falhas transitórias.
Duplicação ou tempestade de chamadas.
Circuit breaker
Conter falhas persistentes.
Abertura indevida ou recuperação lenta.
21.8 Segurança na entrada e na saída
Na entrada, o costuma terminar , validar certificado do servidor e, em , verificar o certificado do cliente. Depois, interpreta mecanismos de aplicação como , , , ou convertido por um broker. Autenticação identifica o principal; autorização decide se ele pode chamar a operação e acessar o recurso solicitado.
O não deve confiar automaticamente em de identidade recebidos da Internet. Cabeçalhos como X-User, X-Roles ou X-Client-ID precisam ser removidos ou sobrescritos antes de propagar contexto interno. Caso contrário, o consumidor pode forjar identidade. O contexto confiável deve nascer de um mecanismo validado e ser protegido no trecho de saída, preferencialmente por e autenticação entre workloads.
Na saída, o pode apresentar uma identidade própria ao por , managed identity, exchange ou credencial técnica. Essa identidade representa o ou a aplicação consumidora, conforme o modelo. Preservar apenas uma identidade genérica simplifica integração, mas pode reduzir auditoria e autorização fina. Propagar o original aumenta contexto, porém expõe o à semântica externa e pode ampliar a superfície de confiança.
Segredos, chaves e certificados devem ser obtidos de repositórios apropriados, rotacionados e auditados. Configuração em texto claro, de Authorization e exportação irrestrita de chaves privadas são falhas graves. O runtime precisa continuar operando durante rotações, aceitando períodos controlados de sobreposição quando necessário.
Fronteira de confiança
O protege o apenas quando o acesso direto é bloqueado ou rigidamente controlado. Se o serviço continua exposto por outra rota, políticas do podem ser contornadas.
21.9 Controle de tráfego, proteção e
controla a velocidade de chamadas em uma janela; quota controla consumo acumulado em um período; descreve a redução ou rejeição de tráfego quando limites são alcançados; spike arrest suaviza picos. Os termos variam entre produtos, mas a arquitetura precisa definir chave de contagem, granularidade, armazenamento de estado e comportamento quando o serviço de contagem falha.
Contar por endereço é insuficiente em ambientes com e . Contar por application ID, subscription, subject, tenant ou operação produz controle mais alinhado ao contrato. Em , limites locais por nó podem permitir consumo agregado acima do esperado. Limites globais exigem coordenação distribuída e adicionam latência e dependência.
reduz latência e carga, mas precisa respeitar semântica , identidade e privacidade. A chave de pode incluir método, , query, de negociação e contexto do consumidor. Armazenar resposta personalizada sem variar por usuário pode vazar dados. O também deve definir invalidação, , tratamento de erro e comportamento durante indisponibilidade do .
Proteções de tamanho, , parsing e concorrência devem ocorrer antes de operações caras. Limites muito baixos quebram casos válidos; limites muito altos permitem abuso de memória e CPU. A plataforma deve publicar valores, medir rejeições e ajustar com base em tráfego real.
Tabela 4 - Controles de tráfego dependem de chave, estado e semântica.
Controle
Chave possível
Decisão importante
Rate limit
cliente + API + operação.
Janela fixa, deslizante ou token bucket.
Quota
subscription + período.
Comportamento ao atingir o total.
Concorrência
backend + rota.
Fila, rejeição ou backpressure.
Cache
URI + headers + identidade.
Variação, TTL e dados sensíveis.
Payload
operação + content-type.
Tamanho antes e depois de descompressão.
21.10 Topologias e modelos de implantação
Na topologia centralizada, um compartilhado publica de várias áreas. O modelo simplifica governança e operação, mas pode criar fila de mudanças, blast radius amplo e limites de capacidade comuns. A plataforma precisa de multitenancy, isolamento de configuração e processos claros para evitar que uma equipe afete outra.
por domínio ou produto aproximam ownership do runtime e reduzem blast radius. Em contrapartida, aumentam quantidade de instâncias, custos, atualização e risco de padrões divergentes. Um modelo federado pode combinar uma plataforma central de padrões e automação com runtimes delegados a domínios.
Arquiteturas em camadas usam externo na borda e internos próximos aos serviços. A camada externa concentra proteção contra Internet, identidade de parceiros e contratos públicos; a interna controla tráfego entre zonas e domínios. É preciso evitar duplicação de políticas e latência acumulada. Cada camada deve ter responsabilidade explícita.
Modelos gerenciados transferem operação de parte da infraestrutura ao provedor. Modelos self-hosted oferecem maior controle de rede e customização. Arquiteturas híbridas mantêm central e em datacenters, ou regiões privadas. A escolha depende de conectividade, soberania, latência, compliance, equipe e requisitos de continuidade.
Figura 3 - A topologia deve equilibrar centralização, autonomia, isolamento e custo operacional.
21.11 Alta disponibilidade e consistência
Alta disponibilidade começa pelo . Múltiplas instâncias devem receber tráfego por ou roteamento equivalente. Instâncias precisam ser substituíveis, com estado mínimo local e configuração reproduzível. A perda de um nó não pode interromper todo o serviço nem exigir recuperação manual prolongada.
O também precisa ser resiliente, porém sua indisponibilidade pode ter impacto diferente. Se os já possuem configuração válida, podem continuar processando chamadas enquanto novas publicações ficam bloqueadas. Esse modo degradado é desejável. O risco surge quando o runtime consulta o em cada requisição ou não mantém configuração local suficiente.
Distribuição de configuração precisa de versionamento e confirmação. Uma publicação parcial pode deixar nós com políticas diferentes. O sistema deve identificar a versão ativa em cada instância, rejeitar artefatos inválidos, aplicar mudanças atomicamente quando possível e permitir . Canary de configuração reduz risco ao expor uma pequena parcela do tráfego antes da propagação total.
Alta disponibilidade regional exige decidir sobre , tráfego global, replicação de chaves, quotas, e dados de subscrição. Active-active aumenta capacidade e reduz tempo de recuperação, mas exige consistência e prevenção de dupla contagem. Active-passive simplifica alguns estados, porém precisa de testes frequentes para que o ambiente passivo esteja realmente pronto.
Figura 4 - A continuidade do runtime não deve depender de uma única instância ou do portal administrativo.
21.12 Estado, sessões e dependências externas
funcionam melhor quando o processamento de requisições é predominantemente . Entretanto, várias políticas introduzem estado: quotas, rate limits distribuídos, , sessões, , listas de revogação e circuit breakers. A arquitetura precisa identificar onde esse estado vive, como é replicado, qual consistência é necessária e o que acontece quando o repositório fica indisponível.
Dependências externas incluem provedores de identidade, introspection , PDPs, bancos, serviços de segredo, , e sistemas de analytics. Chamar um serviço remoto em cada requisição aumenta latência e disponibilidade composta. controlados, validação local de , decisões pré-compiladas e curtos podem reduzir risco, desde que revogação e atualização sejam consideradas.
A política de falha precisa ser explícita. permite tráfego quando um controle está indisponível; bloqueia. Para autorização e validação de credenciais, costuma ser necessário. Para telemetria não crítica, o runtime pode armazenar eventos temporariamente ou descartá-los de modo controlado para preservar disponibilidade. Não existe uma única regra; existe classificação de criticidade.
Sessões no devem ser evitadas quando não são necessárias. Afinidade pode reduzir flexibilidade de escala e dificultar recuperação. Quando um protocolo exige estado de conexão, como , esse estado deve ser tratado como parte explícita da arquitetura, com drenagem, reconexão e distribuição de eventos.
Tabela 5 - Cada dependência externa aumenta a disponibilidade composta do gateway.
Dependência
Uso
Estratégia de resiliência
IdP / JWKS
Validar tokens e chaves.
Cache com atualização e rotação controlada.
PDP
Decisão de autorização.
Timeout curto, cache por risco e fail-closed.
Redis / contador
Quotas e rate limits globais.
Cluster, degradação conhecida e métricas.
Secret store
Credenciais e certificados.
Cache seguro, rotação e acesso mínimo.
Analytics
Eventos e relatórios.
Buffer assíncrono e backpressure.
21.13 Observabilidade, auditoria e correlação
Observabilidade do precisa mostrar o que ocorreu em cada trecho. Métricas inbound medem conexões, , status e latência percebida pelo consumidor. Métricas outbound medem resolução, conexão, , tempo até o primeiro byte e resposta do . A diferença entre as duas ajuda a identificar custo de políticas e espera interna.
devem registrar timestamp, , operação, versão, consumidor, identidade, política de falha, ID, , status e tempos relevantes. Segredos e dados pessoais precisam ser mascarados. O não deve registrar Authorization, ou integral por padrão. Auditoria administrativa deve ser separada de access e registrar quem alterou configuração, o que mudou e quando entrou em vigor.
distribuído conecta consumidor, e . O deve preservar ou gerar context conforme a política da organização, criando spans para processamento interno e chamada outbound. Quando múltiplos existem, cada camada precisa contribuir sem sobrescrever a correlação. IDs de requisição proprietários ainda podem ser úteis, mas devem coexistir com padrões de .
Cardinalidade é um risco. Colocar subject, completa ou valores de query em labels de métrica pode explodir séries temporais e custo. Dados de alta cardinalidade pertencem a ou . Métricas devem usar dimensões controladas, como , operação, status class, região e pool.
Figura 5 - A correlação precisa acompanhar a chamada nas duas conexões mantidas pelo .
21.14 Governança, portal e ciclo de vida
O é parte de uma plataforma, não o ciclo de vida completo. Produtores precisam registrar , publicar contratos, definir ownership, ambientes, versões, produtos e políticas. Consumidores precisam descobrir documentação, solicitar acesso, obter credenciais e acompanhar consumo. O portal de desenvolvedores materializa parte dessa relação, mas depende de processos e dados confiáveis.
Governança deve ser automatizada no . , políticas, certificados, configurações de e testes podem ser versionados como código. Linting, validação de segurança, diff de contrato e promoção entre ambientes reduzem mudanças manuais. A interface administrativa do não deve ser o único lugar onde a verdade existe.
O ciclo de vida inclui draft, revisão, publicação, operação, depreciação e retirada. O precisa permitir coexistência de versões, comunicação de sunset e medição de consumidores ainda ativos. Remover uma rota sem telemetria e sem plano de migração transforma governança em indisponibilidade.
Produtos e planos agrupam com regras comerciais ou operacionais. Uma subscription pode vincular consumidor, credencial, quota e conjunto de operações. Esses objetos precisam de ownership, expiração, rotação e auditoria. Credenciais órfãs são um risco tão relevante quanto órfãs.
Governança prática
A configuração publicada no deve ser reproduzível por , revisável por pares e associada a um contrato. Mudanças exclusivamente manuais dificultam auditoria, e consistência entre ambientes.
21.15 Desempenho e planejamento de capacidade
Desempenho do não pode ser resumido a requisições por segundo. O custo depende de tamanho de , , algoritmo criptográfico, número de políticas, transformações, chamadas externas, , compressão, protocolos e latência do . Duas com o mesmo RPS podem consumir recursos muito diferentes.
Conexões são uma dimensão própria. Um pode receber muitas conexões curtas, poucas conexões /2 multiplexadas ou milhares de persistentes. Limites de file descriptors, , portas efêmeras, pools e precisam ser dimensionados. A CPU pode ficar baixa enquanto o sistema esgota ou memória de .
Testes de carga devem reproduzir distribuição real de operações, autenticação, tamanhos, erros e think time. Testar apenas uma rota simples em loop fornece um número de laboratório, não capacidade de produção. É necessário observar percentis de latência, saturação, filas, retransmissões, garbage collection, conexões e dependências externas.
Planejamento inclui headroom para falhas. Se o suporta apenas a carga normal com todos os nós, a perda de uma instância causa saturação. A capacidade deve considerar manutenção, , pico, crescimento e regional. Autoscaling ajuda, mas possui atraso; o sistema precisa sobreviver até que novas instâncias estejam prontas e aquecidas.
Tabela 6 - Capacidade é multidimensional e precisa de teste representativo.
Dimensão
Indicadores
Pergunta de capacidade
Tráfego
RPS, bytes/s, operações.
Qual é a mistura real de chamadas?
Conexões
ativas, novas/s, reutilização.
Há pooling, HTTP/2 ou WebSocket?
CPU
criptografia, parsing, scripts.
Quais políticas dominam o custo?
Memória
buffers, cache, payloads.
Qual o pior tamanho simultâneo?
Dependências
latência e erro externo.
O gateway satura aguardando terceiros?
21.16 Falhas, antipadrões e
Um erro 404 pode ser produzido porque o host não correspondeu, a rota não foi encontrada, a versão não existe ou o retornou 404. Um 401 pode vir do , do , de uma política customizada ou do serviço. Um 502 normalmente indica falha ao falar com , mas pode envolver , , , inválido ou conexão encerrada. A investigação precisa localizar o emissor da resposta.
O antipadrão mais comum é tratar o como uma caixa opaca. Sem métricas por estágio e sem acesso a correlacionados, equipes alteram políticas, e por tentativa. Outro antipadrão é acumular lógica de negócio no , criando fluxos longos e frágeis. Também é perigoso publicar todas as em um sem isolamento ou capacidade de contenção de falhas.
deve seguir camadas. Primeiro confirme e endereço. Depois conexão , , e seleção de . Em seguida examine autenticação, autorização, quotas e transformações. Só então investigue rota, do , conexão de saída e resposta . A captura precisa indicar o ponto de observação, porque o e a porta mudam ao atravessar o .
Mudanças de configuração são uma fonte importante de incidentes. Registre versão ativa, horário de publicação e diferença em relação à versão anterior. Se apenas alguns nós apresentam erro, suspeite de propagação parcial, ou estado local. Se o problema aparece após rotação de certificado, verifique , cadeias, e sobreposição de validade.
Tabela 7 - O código final é apenas o início do diagnóstico.
Sintoma
Etapas a verificar
Evidência útil
Connection refused
listener, firewall, IP/porta.
SYN/RST, socket em escuta, health do nó.
TLS handshake failed
certificado, SNI, trust, versão.
alerta TLS e cadeia apresentada.
401 / 403
credencial, claims, política e PDP.
issuer, audience, scope e policy ID.
429
chave de contagem e estado.
contador, janela, nó e consumidor.
502 / 503
rota, DNS, pool, connect e health.
upstream escolhido e tempos outbound.
Latência alta
fila, política externa, backend.
spans e decomposição de tempos.
Checklist operacional de
Roteiro mínimo de diagnóstico 1. Resolver nome e confirmar destino. 2. Testar e até o . 3. Confirmar host, método, path e selecionada. 4. Identificar política que aceitou ou rejeitou. 5. Confirmar rota e escolhido. 6. Medir , connect, e tempo do . 7. Correlacionar resposta com versão de configuração.
21.17 Estudos de caso e laboratórios
Caso 1 - externo e interno: uma instituição expõe a parceiros por um de borda e encaminha chamadas a um interno próximo aos serviços. O externo valida certificado de parceiro e ; o interno aplica autorização por domínio e roteia para privados. O desenho funciona quando cada camada possui responsabilidade distinta e a correlação atravessa ambas.
Caso 2 - Configuração parcial: após uma publicação, metade das chamadas retorna 401. O balanceador distribui tráfego entre quatro nós, mas dois não receberam a nova chave . A versão de configuração registrada por instância revela a divergência. O incidente demonstra a necessidade de publicação atômica, confirmação e health de configuração, não apenas health de processo.
Caso 3 - Esgotamento de saída: o recebe tráfego normalmente, mas começa a retornar 502 em picos. CPU e memória estão estáveis. Métricas de mostram grande quantidade de conexões curtas e portas em TIME_WAIT por ausência de . O ajuste de , limites e estratégia de resolve a causa, que não estava em políticas .
Caso 4 - Dependência de autorização: todas as requisições consultam um PDP remoto. Quando o PDP apresenta latência, o acumula threads e aumenta o tempo de resposta de não relacionadas. A solução combina , bulkhead, de decisões de baixo risco e dimensionamento separado, preservando para operações sensíveis.
Laboratórios sugeridos
1) Configure um reverse simples e observe as duas conexões. 2) Simule falha de do e compare com indisponível. 3) Aplique uma política de e registre o estágio da rejeição. 4) Teste , e com um lento. 5) Publique duas versões de configuração e verifique .
Resumo do capítulo
é um runtime de mediação e aplicação de políticas entre consumidores e . Ele termina uma relação de transporte e cria outra, podendo alterar identidade, protocolo, , formato e destino. Essa posição concentra valor de segurança e governança, mas também cria criticidade operacional.
Uma plataforma madura separa , , e developer plane. O runtime precisa permanecer disponível com configuração válida mesmo durante falhas de gestão. Publicações devem ser versionadas, confirmadas e reversíveis. Topologia, alta disponibilidade e estado distribuído precisam ser definidos de forma explícita.
O ciclo da requisição inclui , seleção de , políticas, roteamento, conexão outbound e processamento da resposta. Segurança, tráfego, , resiliência e observabilidade dependem da ordem e do estado dessas etapas. Diagnóstico confiável separa inbound e outbound e localiza o componente que produziu a decisão.
O não substitui lógica de negócio, , , service mesh ou governança completa. Ele integra-se a esses componentes. A arquitetura correta equilibra centralização, autonomia, isolamento, capacidade e continuidade. O próximo capítulo aprofundará as políticas executadas pelo motor do .
Próximo passo do curso
O Capítulo 22 aprofundará Políticas de : estrutura, ordem de execução, variáveis de contexto, autenticação, autorização, transformação, roteamento, resiliência, scripts, tratamento de erros e boas práticas de governança.
Checklist de arquitetura de
As responsabilidades do estão diferenciadas de , , e service mesh.
, , e developer plane possuem fronteiras e definidos.
A indisponibilidade do plano de gestão não interrompe tráfego já publicado.
Listeners, , Host, paths e regras de seleção são determinísticos e testados.
A ordem das políticas evita bypass, custo desnecessário e vazamento de dados.
O acesso direto aos está bloqueado ou rigidamente controlado.
Conexões outbound, , , , e estão dimensionados.
são aplicados somente quando a operação pode ser repetida com segurança.
Rate limits e quotas têm chave, escopo e armazenamento de estado conhecidos.
variam por identidade e não armazenam dados sensíveis de forma insegura.
Configurações são versionadas, publicadas por , confirmadas e reversíveis.
, métricas e correlacionam inbound, políticas e outbound.
O suporta perda de nós e possui headroom para picos e .
Dependências externas possuem , estratégia de falha e observabilidade.
Há runbooks para 401, 403, 429, 502, 503, e latência.
Exercícios
Explique por que consumidor- e - são conexões independentes.
Diferencie , reverse , , e service mesh.
Descreva os quatro planos lógicos de uma plataforma de .
Monte a sequência de processamento de uma requisição e justifique a ordem das políticas.
Explique como e Host participam da seleção de .
Compare topologias centralizada, por domínio, em camadas e híbrida.
Proponha arquitetura de alta disponibilidade que sobreviva à perda do .
Discuta quando a validação local de é preferível à introspection remota.
Explique como e afetam conectividade com .
Proponha métricas para separar latência do e latência do .
Analise os riscos de armazenar lógica de negócio extensa em políticas.
Crie um roteiro para investigar respostas 502 intermitentes em apenas uma região.
Glossário
Tabela 8 - Vocabulário essencial do capítulo.
Termo
Definição
API Gateway
Runtime de mediação e aplicação de políticas entre consumidores e backends.
Control plane
Plano que distribui configuração e estado desejado aos runtimes.
Data plane
Plano que processa o tráfego efetivo das APIs.
Developer portal
Interface de descoberta, documentação, onboarding e consumo.
Drain
Processo de parar novas requisições antes de encerrar uma instância.
Egress
Tráfego de saída do gateway em direção ao backend.
Fail-closed
Comportamento que bloqueia quando um controle crítico falha.
Fail-open
Comportamento que permite continuidade quando um controle falha.
Ingress
Tráfego que entra no runtime pelo listener.
Listener
Endpoint local que aceita conexões e protocolos.
Management plane
Plano administrativo de publicação, catálogo e governança.
Policy
Regra executada sobre requisição, resposta ou erro.
Route
Mapeamento entre API lógica e destino de backend.
SNAT
Tradução do endereço e porta de origem no trecho de saída.
Upstream
Servidor ou pool de destino chamado pelo gateway.
Virtual host
Identidade lógica de host compartilhando endereço e porta.
Referências técnicas
. 9110 - Semantics.
. 9111 - .
. 8446 - The Transport Layer Security Protocol Version 1.3.
. 9457 - Problem Details for .
. SP 800-204 - Security Strategies for Microservices-based Application Systems.
. SP 800-207 - Zero Trust Architecture.
Initiative. Specification.
Microsoft Azure Architecture Center. pattern.
Envoy Documentation. Architecture overview and filters.
. Security Top 10.
CNCF. and service mesh architectural materials.
Nota de atualização
Produtos de evoluem em ritmo próprio. Ao aplicar os conceitos em uma plataforma específica, confirme a documentação da versão implantada, principalmente para protocolos, políticas, clustering, limites, integração com identidade e comportamento de alta disponibilidade.
