Projetar um API gateway

01 · CONTEXTO

Uma porta de entrada para muitos serviços

Em uma arquitetura de microsserviços, um cliente pode interagir com mais de um serviço de front-end. Sem um intermediário, o cliente precisa acompanhar vários endpoints e tratar falhas com resiliência, e precisa entender a decomposição dos serviços, o que complica a manutenção e a refatoração. Endpoints públicos também aumentam a superfície de ataque e exigem endurecimento.

Um API gateway é um ponto de entrada centralizado para as interações entre clientes e serviços da aplicação: atua como proxy reverso e roteia as requisições dos clientes para os serviços apropriados. Sem ele, cada serviço público precisa tratar por conta própria preocupações como autenticação, SSL e limitação de taxa por cliente.

02 · ROTEAMENTO E AGREGAÇÃO

Um endpoint, vários serviços

O gateway usa roteamento na camada de aplicação e oferece um único endpoint aos clientes. Algumas requisições são apenas encaminhadas ao serviço apropriado; outras o gateway atende distribuindo a chamada entre vários serviços.

Um exemplo da documentação do padrão é a página de detalhes de um produto: os dados do produto ficam espalhados por vários serviços, como o de informações do produto, o de preço e o de avaliações. Uma rede móvel costuma ser bem mais lenta e ter latência bem maior que uma rede não móvel, e chamadas separadas por uma rede celular de alta latência são ineficientes e podem causar perda de conexão ou respostas incompletas.

1. O aplicativo móvel envia uma única requisição ao gateway, em vez de uma para cada serviço.

2. O gateway despacha a requisição aos serviços necessários para a operação.

3. Os resultados voltam ao gateway, que os agrega antes de devolvê-los ao cliente.

4. Se uma das chamadas demora demais, pode ser aceitável expirar o tempo e devolver um conjunto parcial de dados.

Uma variação do padrão dá a cada tipo de cliente o seu próprio gateway, o chamado back-end para front-end. Quanto à agregação, a documentação da Azure sugere considerar um serviço de agregação atrás do gateway, em vez de embuti-la nele.

03 · TAREFAS DE BORDA

Identidade e outras preocupações transversais

Além de rotear, o gateway pode assumir preocupações transversais em nome dos serviços de back-end: gerenciamento de certificados voltados ao cliente, autenticação, término de TLS, monitoramento, tradução de protocolo e limitação de taxa.

Na autenticação e na autorização, o gateway pode verificar se o cliente está autorizado a fazer a requisição; ele também pode autenticar o usuário e repassar aos serviços um token de acesso com informações sobre ele.

1. O cliente conhece apenas o gateway, que roteia a requisição ao serviço apropriado.

2. A verificação de identidade e de autorização fica na borda, apoiada no provedor de identidade deste desenho.

3. A limitação de taxa é uma das preocupações que o gateway assume em nome dos serviços.

4. O gateway pode repassar aos serviços um token de acesso com informações sobre o usuário.

5. O gateway também dá alguma consistência ao registro e ao monitoramento das requisições.

04 · LIMITAÇÃO DE TAXA

Token bucket e leaky bucket

O Amazon API Gateway limita as requisições com o algoritmo token bucket, em que um token corresponde a uma requisição. A taxa configurada é o ritmo, em requisições por segundo, com que tokens entram no balde, e o burst é a capacidade do balde.

Quando as requisições superam a taxa de regime e o burst, o gateway começa a limitá-las, e o cliente pode receber a resposta de erro 429 Too Many Requests. No token bucket, um burst pode permitir que o limite pré-definido seja ultrapassado.

A escolha da chave também importa. No Amazon API Gateway, o limite por cliente usa como identificador a chave de API associada ao plano de uso. No NGINX podem existir vários limit_req ao mesmo tempo, por exemplo um por endereço IP e outro por servidor virtual, e o parâmetro nodelay evita atrasar os excedentes.

05 · LIMITES DO GATEWAY

A porta de entrada também falha

O gateway pode introduzir um ponto único de falha e também um gargalo. A orientação é evitar o ponto único de falha com várias instâncias do gateway e dimensioná-lo para os picos de tráfego, não só para a carga média.

1. Neste desenho há mais de uma instância do gateway, o que evita o ponto único de falha.

2. Um balanceador na frente reparte as requisições entre as instâncias.

3. Cada instância precisa ser dimensionada para os picos de tráfego, não só para a média.

4. O gateway adiciona um salto de rede a cada requisição antes de ela chegar aos serviços.

Esse salto extra aumenta o tempo de resposta, embora para a maioria das aplicações o custo de uma ida e volta a mais seja insignificante. Comprometer o gateway pode expor todos os serviços a jusante, e a lógica de negócio nunca deve ser descarregada nele.

Na prática, nginx e HAProxy são proxies reversos de código aberto, e a documentação da Azure recomenda preferir as soluções de gateway e ingress que a própria plataforma oferece, quando atendem aos requisitos de segurança e controle.