Crie serviços de programa auxiliar que enviam pedidos de rede em nome de um serviço ou aplicação de consumidor. Um serviço ambassador pode ser considerado como um proxy de fora do processo que está colocalizado com o cliente.
Este padrão pode ser útil para a descarga de tarefas comuns de conectividade de cliente, como monitorização, registo, encaminhamento, segurança (por exemplo, TLS), e padrões de resiliência numa forma agnóstica à linguagem. É frequentemente usado com aplicativos legados, ou outros aplicativos que são difíceis de modificar, a fim de estender seus recursos de rede. Pode também ativar uma equipa especializada para implementar essas funcionalidades.
Contexto e problema
As aplicações resilientes baseadas na cloud precisam de funcionalidades, como disjunção automática, encaminhamento, medição e monitorização, e a capacidade de disponibilizar atualizações de configuração relacionadas com a rede. Poderá ser difícil ou impossível atualizar aplicações legadas ou bibliotecas de código existentes para adicionar estas funcionalidades, porque o código já não é mantido ou não pode ser facilmente modificado pela equipa de desenvolvimento.
As chamadas de rede também poderão requerer uma configuração significativa da ligação, autenticação e autorização. Se estas chamadas forem utilizadas em várias aplicações criadas com várias linguagens e arquiteturas, as chamadas têm de ser configuradas para cada uma destas instâncias. Além disso, a funcionalidade de rede e de segurança poderá ter de ser gerida por uma equipa central dentro da sua organização. Com uma base de códigos grande, pode ser arriscado para essa equipa atualizar o código da aplicação, se não estiver familiarizada com o mesmo.
Solução
Coloque as estruturas e bibliotecas de cliente num processo externo que age como um proxy entre a sua aplicação e os serviços externos. Implemente o proxy no mesmo ambiente anfitrião da aplicação para permitir o controlo das funcionalidades de encaminhamento, resiliência, segurança e para evitar quaisquer restrições de acesso relacionadas com o anfitrião. Também pode utilizar o padrão de ambassador para uniformizar e expandir a instrumentação. O proxy pode monitorizar as métricas de desempenho, como a latência ou utilização de recursos, e esta monitorização acontece no mesmo ambiente anfitrião da aplicação.
As funcionalidades que são descarregadas para o ambassador podem ser geridas de forma independente da aplicação. Pode atualizar e modificar o ambassador sem afetar a funcionalidade legada da aplicação. Também permite que equipas separadas e especializadas implementem e mantenham as funcionalidades de segurança, rede ou autenticação que foram movidas para o ambassador.
Os serviços ambassador podem ser implementados como um sidecar para acompanhar o ciclo de vida de uma aplicação ou serviço de consumo. Em alternativa, se um ambassador for partilhado por vários processos separados num anfitrião comum, pode ser implementado como um daemon ou um serviço do Windows. Se o serviço de consumo estiver em contentor, o ambassador deve ser criado como um contentor separado no mesmo anfitrião, com as ligações adequadas configuradas para comunicação.
Problemas e considerações
- O proxy adiciona alguma sobrecarga de latência. Considere se uma biblioteca de cliente, invocada diretamente pela aplicação, é uma abordagem melhor.
- Considere o possível impacto de incluir funcionalidades generalizadas no proxy. Por exemplo, o ambassador poderia processar várias repetições, mas isto poderá não ser seguro, a menos que todas as operações sejam idempotentes.
- Considere um mecanismo para permitir que o cliente passe algum contexto para o proxy e volte para o cliente. Por exemplo, inclua cabeçalhos de pedido HTTP para recusar as repetições ou especificar o número máximo de vezes a repetir.
- Considere como você empacotará e implantará o proxy.
- Considere se vai utilizar uma única instância partilhada para todos os clientes ou uma instância para cada cliente.
Quando utilizar este padrão
Utilize este padrão quando:
- Tiver de criar um conjunto comum de funcionalidades de conectividade de cliente para várias linguagens ou estruturas.
- Tiver de passar questões transversais de conectividade de cliente para programadores ou outras equipas mais especializadas.
- Tiver de suportar requisitos da cloud ou de conectividade de cluster numa aplicação legada ou numa aplicação que é difícil modificar.
Este padrão pode não ser adequado:
- Quando a latência de pedidos de rede é crítica. Um proxy introduz alguma sobrecarga, embora mínima, e em alguns casos isso pode afetar o aplicativo.
- Quando as funcionalidades de conectividade do cliente são consumidas por uma única linguagem. Nesse caso, uma opção mais adequada pode ser uma biblioteca de cliente que é distribuída pelas equipas de desenvolvimento como um pacote.
- Quando os recursos de conectividade não podem ser generalizados e exigem uma integração mais profunda com o aplicativo cliente.
Design da carga de trabalho
Um arquiteto deve avaliar como o padrão Ambassador 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. | O ponto de mediação de comunicações de rede facilitado por esse padrão oferece uma oportunidade de adicionar padrões de confiabilidade à comunicação de rede, como repetição ou buffering. - RE:07 Autopreservação |
| 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. | Esse padrão oferece uma oportunidade de aumentar a segurança em comunicações de rede que não poderiam ter sido tratadas diretamente pelo cliente. - SE:06 Controles de rede - Encriptação SE:07 |
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 diagrama seguinte mostra uma aplicação a efetuar um pedido a um serviço remoto através de um proxy ambassador. O ambassador fornece o encaminhamento, a disjunção automática e o registo. Chama o serviço remoto e, em seguida, devolve a resposta à aplicação cliente:
