Descarregue a funcionalidade de serviço especializado ou compartilhado para um proxy do gateway. Esse padrão pode simplificar o desenvolvimento de aplicativo movendo a funcionalidade de serviços compartilhados, como o uso de certificados SSL, de outras partes do aplicativo para o gateway.
Contexto e problema
Alguns recursos são comumente usados em vários serviços e esses recursos exigem configuração, gerenciamento e manutenção. Um serviço compartilhado ou especializado que é distribuído com cada implantação de aplicativo aumenta a sobrecarga administrativa e a probabilidade de erro de implantação. Todas as atualizações para um recurso compartilhado devem ser implantadas em todos os serviços que compartilham esse recurso.
Tratar corretamente os problemas de segurança (validação de token, criptografia e gerenciamento de certificados SSL) e outras tarefas complexas pode requerer que os membros da equipe tenham habilidades altamente especializadas. Por exemplo, um certificado necessário para um aplicativo deve ser configurado e implantado em todas as instâncias do aplicativo. Com cada implantação nova, o certificado deve ser gerenciado para se garantir que ele não expire. Qualquer certificado comum que esteja prestes a expirar deve ser atualizado, testado e verificado em todas as implantações de aplicativo.
Outros serviços comuns, como autenticação, autorização, registro em log, monitoramento ou limitação podem ser difíceis de serem implementados e gerenciado em uma grande quantidade de implantações. Talvez seja melhor consolidar esse tipo de funcionalidade para reduzir a sobrecarga e a chance de erros.
Solução
Descarregue alguns recursos em um gateway, particularmente preocupações abrangentes como gerenciamento de certificados, autenticação, término de SSL, monitoramento, conversão de protocolo ou limitação.
O diagrama a seguir mostra um gateway que termina as conexões SSL de entrada. Ele solicita dados em nome do solicitante original de qualquer upstream de servidor HTTP do gateway.
Os benefícios desse padrão incluem:
Simplificar o desenvolvimento de serviços removendo a necessidade de distribuir e manter recursos de suporte, como certificados de servidor Web e a configuração de sites seguros. Uma configuração mais simples resulta em gerenciamento e escalabilidade mais fáceis e simplifica as atualizações de serviço.
Permitir que equipes dedicadas implementem recursos que exigem competências especializadas, como a segurança. Isso permite que sua equipe principal foque a funcionalidade do aplicativo, deixando essas preocupações especializadas, mas abrangentes, para os especialistas relevantes.
Fornecer alguma consistência para registro em log e monitoramento de solicitação e de reposta. Mesmo que um serviço não esteja instrumentado corretamente, o gateway pode ser configurado para garantir um nível mínimo de monitoramento e registro em log.
Problemas e considerações
- Garanta que o gateway seja altamente disponível e resistente a falhas. Evite pontos únicos de falha executando várias instâncias do seu gateway.
- Assegure que o gateway seja projetado para os requisitos de capacidade e dimensionamento de seu aplicativo e pontos de extremidade. Verifique se o gateway não se torna um gargalo do aplicativo e se é suficientemente escalonável.
- Descarregue somente recursos que sejam usados pelo aplicativo inteiro, como a segurança ou transferência de dados.
- A lógica de negócios nunca deve ser descarregada para o gateway.
- Se precisar controlar transações, leve em consideração gerar IDs de correlação para fins de registro de log.
Quando usar esse padrão
Use esse padrão quando:
- Uma implantação de aplicativo tem uma preocupação compartilhada, como certificados SSL ou criptografia.
- Em um recurso que seja comum entre implantações de aplicativos que podem ter requisitos de recursos diferentes, como recursos de memória, capacidade de armazenamento ou conexões de rede.
- Você deseja mover a responsabilidade por problemas, como segurança de rede, limitação ou outras preocupações de limite de rede, para uma equipe mais especializada.
Esse padrão pode não ser adequado caso ele introduza um acoplamento entre serviços.
Design de carga de trabalho
Um arquiteto deve avaliar como o padrão de descarregamento 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 apoia os objetivos do pilar |
|---|---|
| As decisões de design 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. | Transferir essa responsabilidade para um gateway reduz a complexidade do código do aplicativo nos nós de back-end. Em alguns casos, o descarregamento substitui completamente a funcionalidade por um recurso confiável fornecido pela plataforma. - RE:01 Simplicidade e eficiência |
| 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. | Adicionar um gateway ao fluxo de solicitação permite centralizar funcionalidades de segurança, como firewalls de aplicativos web e conexões TLS com clientes. Qualquer funcionalidade descarregada fornecida pela plataforma já oferece segurança aprimorada. - SE:06 Controles de rede - SE:08 Proteção de recursos |
| A otimização de custos se concentra em sustentar e melhorar o retorno sobre o investimento da sua carga de trabalho. | Esse padrão permite redirecionar custos de recursos que seriam gastos por nó na implementação do gateway. Os custos no modelo de processamento centralizado são frequentemente inferiores aos do modelo distribuído. - CO:14 Consolidação |
| A Excelência Operacional ajuda a fornecer qualidade na carga de trabalho por meio de processos padronizados e coesão da equipe. | Nesse padrão, a configuração e a manutenção da funcionalidade transferida são feitas a partir de um único ponto, em vez de gerenciá-la a partir de vários nós. - [OE:04 Ferramentas e processos]/azure/well-architected/operational-excellence/tools-processes) |
| A eficiência de desempenho ajuda sua carga de trabalho a atender com eficiência às demandas por meio de otimizações em dimensionamento, dados e código. | Adicionar um gateway de transferência ao processo de solicitação permite usar menos recursos por nó porque a funcionalidade é centralizada no gateway. Você pode otimizar a implementação da funcionalidade transferida independentemente do código do aplicativo. A funcionalidade descarregada fornecida pela plataforma provavelmente já terá alto desempenho. - PE:03 Seleção de serviços |
Tal como acontece com qualquer decisão de design, considere quaisquer compensações em relação aos objetivos dos outros pilares que possam ser introduzidos com este padrão.
Exemplo
Ao usar o Nginx como o dispositivo de descarregamento de SSL, a configuração a seguir encerra uma conexão SSL de entrada e distribui a conexão para um dos três servidores HTTP de upstream.
upstream iis {
server 10.3.0.10 max_fails=3 fail_timeout=15s;
server 10.3.0.20 max_fails=3 fail_timeout=15s;
server 10.3.0.30 max_fails=3 fail_timeout=15s;
}
server {
listen 443;
ssl on;
ssl_certificate /etc/nginx/ssl/domain.cer;
ssl_certificate_key /etc/nginx/ssl/domain.key;
location / {
set $targ iis;
proxy_pass http://$targ;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Host $host;
}
}
No Azure, isso pode ser obtido configurando a terminação SSL no Gateway de Aplicativo.