Criar uma arquitetura de rede distribuída geograficamente
Numa aplicação distribuída, é essencial garantir que os componentes podem comunicar de forma fiável e que os pedidos podem encaminhar para um componente ou região diferente quando ocorrer uma falha.
Decidimos rearquitetar o nosso portal de envios no Azure para reduzir a sua vulnerabilidade a falhas regionais. Queremos garantir que o aplicativo faça failover em componentes em uma região secundária quando a região primária não estiver disponível. O failover deve causar interrupção mínima na entrega do serviço aos usuários.
Aqui, aprendemos como o DNS do Azure, o Gestor de Tráfego, a Front Door e a CDN do Azure suportam a arquitetura de aplicações da nossa empresa de envio.
Azure DNS
Lembre-se de que não precisamos de nenhuma alteração para a implementação do DNS do Azure. Usamos o DNS do Azure para hospedar os registros de nome de domínio que identificam nosso aplicativo.
O DNS do Azure oferece resolução de nomes totalmente através da infraestrutura do Azure. Este serviço é multirregional de origem, pelo que não há necessidade de modificar a nossa configuração do DNS do Azure existente para suportar a funcionalidade na nossa nova estrutura de arquitetura.
O SLA DNS do Azure também tem uma garantia de 100% de que solicitações DNS válidas recebam uma resposta de pelo menos um servidor de nomes DNS do Azure o tempo todo.
Escolher um router de tráfego
Precisamos de um serviço que possa balancear a carga e redirecionar o tráfego entre várias regiões com aplicações Web distribuídas.
O Azure fornece vários serviços diferentes que podem encaminhar o tráfego entre os componentes de front-end. Lembre-se de que precisamos de substituir o nosso Gateway de Aplicação do Azure, pois está associado a uma única região. Se essa região falhar, não há nada para fazer o encaminhamento.
Há dois roteadores de tráfego no Azure que podem fazer roteamento global entre várias regiões e não são vulneráveis a uma única interrupção de região:
- Gestor de Tráfego do Azure
- Azure Front Door
Vamos examinar estes serviços mais detalhadamente para que possamos escolher o router certo para a nossa aplicação.
O que é o Gestor de Tráfego do Azure?
O Gestor de Tráfego do Azure é um balanceador de carga global que utiliza os registos DNS para encaminhar o tráfego para destinos em várias regiões do Azure.
Podemos configurar o Gerenciador de Tráfego para rotear todas as solicitações para nossa região principal e monitorar a capacidade de resposta do Serviço de Aplicativo nessa região. Se o Serviço de Aplicações na região primária falhar, o Gestor de Tráfego redirecionará automaticamente os pedidos do utilizador para o Serviço de Aplicações na região secundária. Este redirecionamento executa a ativação pós-falha que garante o serviço contínuo. Chamamos a esta disposição o modo de encaminhamento prioritário.
Como o Gestor de Tráfego utiliza o sistema DNS para encaminhar o tráfego, encaminha qualquer protocolo e não apenas o tráfego HTTP. No entanto, o Gestor de Tráfego não pode encaminhar ou filtrar o tráfego com base em propriedades HTTP, como o código do país do cliente ou cabeçalhos do agente de utilizador. Também não consegue fazer a terminação do protocolo Transport Layer Security (TLS), em que o router desencripta pedidos e encripta respostas para assumir a carga dos servidores virtuais do Serviço de Aplicações. Se precisarmos de qualquer um desses recursos, teremos que usar o Azure Front Door.
O Gestor de Tráfego utiliza a monitorização de pontos finais altamente configurável. Por exemplo, podemos definir o protocolo, a porta, o caminho, as configurações de cabeçalho personalizadas, os intervalos de códigos de status esperados e o número tolerado de falhas. A monitorização de pontos finais dá-nos uma ideia contínua do estado de funcionamento geral de todas as partes da nossa aplicação.
O que é o Azure Front Door?
Tal como o Gestor de Tráfego, o Azure Front Door é um balanceador de carga global. Ao contrário do Gestor de Tráfego, opera na camada de aplicação de rede (Camada 7) e utiliza as propriedades HTTP e HTTPS para fazer a filtragem e o encaminhamento.
Com o Front Door, podemos fazer muitos tipos de encaminhamento que o Gestor de Tráfego não suporta. Por exemplo, podemos encaminhar o tráfego com base no indicativo do browser. O Front Door também suporta a terminação do protocolo TLS.
No entanto, há uma exceção. Se quisermos rotear o tráfego para qualquer protocolo que não seja HTTP e HTTPS, temos que usar o Gerenciador de Tráfego.
O Front Door permite-nos atribuir prioridades aos vários back-ends que compõem o portal de rastreio. Essas prioridades permitem que a Front Door encaminhe solicitações conforme necessário. Atribuímos os nossos serviços de região primária com uma prioridade máxima e o nosso serviço de região secundária com uma prioridade mais baixa.
O Front Door implementa sondas do estado de funcionamento para monitorizar o estado de funcionamento dos nossos serviços e, se ocorrer uma falha, poderá encaminhar o tráfego corretamente. O modo de encaminhamento com prioridade e a monitorização de pontos finais no Front Door são semelhantes às funcionalidades do Gestor de Tráfego, com a exceção de que as sondas do estado de funcionamento funcionam sempre através de HTTP.
Todo o tráfego para a IU da Web do nosso portal de envios e as respetivas APIs é feito através de HTTPS e permite-nos alternar entre o Gestor de Tráfego do Azure e o Front Door. Também podemos configurar o Front Door com atribuição prioritária de back-end.
CDN do Azure
Na nossa arquitetura de região única, utilizámos a CDN do Azure para colocar em cache os conteúdos estáticos do Armazenamento de Blobs do Azure. O serviço de CDN do Azure é uma rede global de servidores que coloca em cache os conteúdos estáticos próximos dos utilizadores. Não precisamos de modificar este serviço para a arquitetura multirregional. No entanto, há considerações sobre nossa conta de Armazenamento do Azure que abordaremos na próxima unidade.