Utilize um gateway para agregar vários pedidos individuais num único pedido. Este padrão é prático quando um cliente tem de fazer várias chamadas para diferentes sistemas de back-end para realizar uma operação.
Contexto e problema
Para executar uma única tarefa, um cliente pode ter de fazer várias chamadas para vários serviços de back-end. Uma aplicação que depende de vários serviços para realizar uma tarefa tem de expandir os recursos em cada pedido. Quando um serviço ou uma funcionalidade novos são adicionados à aplicação, são precisos pedidos adicionais, o que aumenta ainda mais os requisitos de recursos e as chamadas de rede. Este diálogo entre um cliente e um back-end pode afetar negativamente o desempenho e o dimensionamento da aplicação. As arquiteturas de microsserviços tornaram este problema mais comum, uma vez que as aplicações criadas em torno de vários serviços mais pequenos possuem naturalmente um número superior de chamadas de serviço cruzado.
No diagrama seguinte, o cliente envia pedidos para cada serviço (1, 2 e 3). Cada um dos serviços processa o pedido e envia a resposta de volta para a aplicação (4, 5 e 6). O envio de pedidos individuais através de uma rede celular, com a habitual elevada latência, torna-se ineficaz e pode resultar em conectividade interrompida ou em pedidos incompletos. Apesar de cada pedido poder ser realizado em paralelo, a aplicação tem de enviar, aguardar e processar os dados de cada pedido, tudo em ligações separadas, o que aumenta a possibilidade de falha.
Solução
Utilize um gateway para reduzir o diálogo entre o cliente e os serviços. O gateway recebe pedidos de clientes, envia pedidos para os vários sistemas de back-end e, em seguida, agrega os resultados e envia-os de volta para o cliente solicitador.
Este padrão pode reduzir o número de pedidos que a aplicação faz para os serviços de back-end e melhorar o desempenho da aplicação em redes de alta latência.
No diagrama seguinte, a aplicação envia um pedido para o gateway (1). O pedido contém um pacote de pedidos adicionais. O gateway decompõe-nos e processa cada pedido ao enviá-lo para o serviço relevante (2). Cada um dos serviços devolve uma resposta ao gateway (3). O gateway combina as respostas de cada serviço e envia a resposta para a aplicação (4). A aplicação envia um único pedido e recebe apenas uma única resposta do gateway.
Problemas e considerações
- O gateway não deve introduzir ligações de serviços entre os serviços de back-end.
- O gateway deve estar localizado junto dos serviços de back-end para reduzir a latência sempre que possível.
- O serviço do gateway pode introduzir um ponto único de falha. Confirme se o gateway foi corretamente concebido para satisfazer os requisitos de disponibilidade da aplicação.
- O gateway pode introduzir um estrangulamento. Confirme se o gateway tem um desempenho adequado para processar a carga e se pode ser dimensionado para satisfazer o seu crescimento previsto.
- Realize testes de carga no gateway para garantir que não introduz falhas em cascata nos serviços.
- Implemente uma estrutura resiliente, com técnicas como bulkheads, disjuntor de circuito, repetição e tempos limite.
- Se uma ou mais chamadas de serviço demorarem muito, pode ser aceitável atingir o tempo limite e retornar um conjunto parcial de dados. Considere a forma como a aplicação vai processar este cenário.
- Utilize E/S assíncrona para garantir que um atraso no back-end não causa problemas de desempenho na aplicação.
- Implemente o rastreio distribuído com IDs de correlação para controlar cada chamada individual.
- Monitorize as métricas do pedido e os tamanhos das respostas.
- Considere devolver dados em cache como uma estratégia de ativação pós-falha para processar as falhas.
- Em vez de criar a agregação no gateway, considere colocar um serviço de agregação atrás do gateway. A agregação de pedidos terá, provavelmente, requisitos de recursos diferentes relativamente a outros serviços no gateway e pode afetar a funcionalidade de encaminhamento e descarregamento do gateway.
Quando utilizar este padrão
Utilize este padrão quando:
- Um cliente precisa de comunicar com vários serviços de back-end para realizar uma operação.
- O cliente pode utilizar redes com uma latência significativa, tal como redes celulares.
Este padrão pode não ser adequado quando:
- Pretende reduzir o número de chamadas entre um cliente e um único serviço em várias operações. Nesse cenário, poderá ser melhor adicionar uma operação em lote ao serviço.
- O cliente ou aplicativo está localizado perto dos serviços de back-end e a latência não é um fator significativo.
Design da carga de trabalho
Um arquiteto deve avaliar como o padrão de Agregação de Gateway pode ser usado no design de sua carga de trabalho para abordar as metas e os princípios abordados nos pilares do Azure Well-Architected Framework. Por exemplo:
| Pilar | Como esse padrão suporta os objetivos do pilar |
|---|---|
| As decisões de projeto de confiabilidade ajudam sua carga de trabalho a se tornar resiliente ao mau funcionamento e a garantir que ela se recupere para um estado totalmente funcional após a ocorrência de uma falha. | Essa topologia permite, entre outras coisas, mudar o tratamento de falhas transitórias de uma implementação distribuída entre clientes para uma implementação centralizada. - RE:07 Falhas transitórias |
| As decisões de design de segurança ajudam a garantir a confidencialidade, integridade e disponibilidade dos dados e sistemas da sua carga de trabalho. | Essa topologia geralmente reduz o número de pontos de contato que um cliente tem com um sistema, o que reduz a área de superfície pública e os pontos de autenticação. Os back-ends agregados podem ficar totalmente isolados da rede dos clientes. - SE:04 Segmentação - SE:08 Endurecimento |
| A Excelência Operacional ajuda a fornecer qualidade de carga de trabalho por meio de processos padronizados e coesão da equipe. | Esse padrão permite que a lógica de back-end evolua independentemente dos clientes, permitindo que você altere as implementações de serviço encadeadas, ou até mesmo as fontes de dados, sem a necessidade de alterar os pontos de contato do cliente. - OE:04 Ferramentas e processos |
| A Eficiência de Desempenho ajuda sua carga de trabalho a atender às demandas de forma eficiente por meio de otimizações em escala, dados e código. | Esse design pode incorrer em menos latência do que um design no qual o cliente estabelece várias conexões. O cache em implementações de agregação minimiza as chamadas para sistemas de back-end. - PE:03 Seleção de serviços - PE:08 Desempenho dos dados |
Como em qualquer decisão de design, considere quaisquer compensações em relação aos objetivos dos outros pilares que possam ser introduzidos com esse padrão.
Exemplo
O exemplo seguinte ilustra como criar um serviço NGINX de agregação do gateway simples com Lua.
worker_processes 4;
events {
worker_connections 1024;
}
http {
server {
listen 80;
location = /batch {
content_by_lua '
ngx.req.read_body()
-- read json body content
local cjson = require "cjson"
local batch = cjson.decode(ngx.req.get_body_data())["batch"]
-- create capture_multi table
local requests = {}
for i, item in ipairs(batch) do
table.insert(requests, {item.relative_url, { method = ngx.HTTP_GET}})
end
-- execute batch requests in parallel
local results = {}
local resps = { ngx.location.capture_multi(requests) }
for i, res in ipairs(resps) do
table.insert(results, {status = res.status, body = cjson.decode(res.body), header = res.header})
end
ngx.say(cjson.encode({results = results}))
';
}
location = /service1 {
default_type application/json;
echo '{"attr1":"val1"}';
}
location = /service2 {
default_type application/json;
echo '{"attr2":"val2"}';
}
}
}