Padrão Ambassador

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 pensado como um proxy fora do processo que é co-localizado com o cliente.

Esse padrão pode ser útil para descarregar tarefas comuns de conectividade do cliente, como monitoramento, registro, roteamento, segurança (como TLS) e padrões de resiliência de forma independente de linguagem. É frequentemente usado com aplicativos legados, ou outros aplicativos que são difíceis de modificar, a fim de estender seus recursos de rede. Ele também pode permitir que uma equipe especializada implemente esses recursos.

Contexto e problema

Aplicativos resilientes baseados em nuvem exigem recursos como circuit breaking, roteamento, medição e monitoramento, e a capacidade de fazer atualizações de configuração relacionadas à rede. Pode ser difícil ou impossível atualizar aplicativos herdados ou bibliotecas de código existentes para adicionar esses recursos, porque o código não é mais mantido ou não pode ser facilmente modificado pela equipe de desenvolvimento.

As chamadas de rede também podem exigir uma configuração substancial para conexão, autenticação e autorização. Se essas chamadas forem usadas em vários aplicativos, criadas usando várias linguagens e estruturas, as chamadas deverão ser configuradas para cada uma dessas instâncias. Além disso, a funcionalidade de rede e segurança pode precisar ser gerenciada por uma equipe central dentro da sua organização. Com uma base de código grande, pode ser arriscado para essa equipe atualizar o código do aplicativo com o qual não está familiarizado.

Solução

Coloque estruturas e bibliotecas de cliente em um processo externo que atua como um proxy entre seu aplicativo e serviços externos. Implante o proxy no mesmo ambiente de host que seu aplicativo para permitir o controle sobre roteamento, resiliência, recursos de segurança e para evitar quaisquer restrições de acesso relacionadas ao host. Você também pode usar o padrão ambassador para padronizar e estender a instrumentação. O proxy pode monitorar métricas de desempenho, como latência ou uso de recursos, e esse monitoramento acontece no mesmo ambiente de host que o aplicativo.

Os recursos que são descarregados para o embaixador podem ser gerenciados independentemente do aplicativo. Você pode atualizar e modificar o ambassador sem perturbar a funcionalidade herdada do aplicativo. Ele também permite que equipes separadas e especializadas implementem e mantenham recursos de segurança, rede ou autenticação que foram movidos para o embaixador.

Os serviços Ambassador podem ser implantados como um sidecar para acompanhar o ciclo de vida de um aplicativo ou serviço consumidor. Como alternativa, se um embaixador for compartilhado por vários processos separados em um host comum, ele poderá ser implantado como um daemon ou serviço do Windows. Se o serviço de consumo for conteinerizado, o ambassador deve ser criado como um contêiner separado no mesmo host, com os links apropriados configurados para comunicação.

Questões e considerações

• O proxy adiciona alguma sobrecarga de latência. Considere se uma biblioteca de cliente, invocada diretamente pelo aplicativo, é uma abordagem melhor.
• Considere o possível impacto da inclusão de recursos generalizados no proxy. Por exemplo, o embaixador poderia lidar com tentativas, mas isso pode 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 solicitação HTTP para desativar a repetição ou especifique o número máximo de vezes para tentar novamente.
• Considere como você empacotará e implantará o proxy.
• Considere se deve usar uma única instância compartilhada para todos os clientes ou uma instância para cada cliente.

Quando usar este padrão

Use este padrão quando:

• Necessidade de criar um conjunto comum de recursos de conectividade de cliente para vários idiomas ou estruturas.
• Necessidade de descarregar preocupações transversais de conectividade do cliente para desenvolvedores de infraestrutura ou outras equipes mais especializadas.
• Necessidade de suportar requisitos de conectividade de nuvem ou cluster em um aplicativo herdado ou um aplicativo difícil de modificar.

Este padrão pode não ser adequado:

• Quando a latência da solicitação de rede é crítica. Um proxy introduz alguma sobrecarga, embora mínima, e em alguns casos isso pode afetar o aplicativo.
• Quando os recursos de conectividade do cliente são consumidos por um único idioma. Nesse caso, uma opção melhor pode ser uma biblioteca de cliente que é distribuída para as equipes 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:

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 a seguir mostra um aplicativo fazendo uma solicitação para um serviço remoto por meio de um proxy ambassador. O embaixador fornece roteamento, disjuntor e registro. Ele chama o serviço remoto e, em seguida, retorna a resposta para o aplicativo cliente:

Recursos relacionados

• Padrão de Sidecar