Não há mais suporte para esse navegador.
Atualize o Microsoft Edge para aproveitar os recursos, o suporte técnico e as atualizações de segurança mais recentes.
Este artigo apresenta um padrão-chave para arquiteturas críticas no Azure. Aplique esse padrão ao iniciar o processo de design e selecione os componentes mais adequados para seus requisitos de negócios. O artigo recomenda uma abordagem de design de estrela guia e inclui outros exemplos com componentes de tecnologia comuns.
Recomendamos que você avalie as principais áreas de design, defina os fluxos críticos de usuário e sistema que usam os componentes subjacentes e desenvolva uma matriz de recursos do Azure e sua configuração, tendo em mente as características a seguir.
| Característica | Considerações |
|---|---|
| Tempo de vida | Qual é o tempo de vida esperado do recurso em relação a outros recursos na solução? Ele deve sobreviver ou compartilhar o tempo de vida com todo o sistema ou região, ou deve ser temporário? |
| Estado | Qual será o impacto que o estado persistente nessa camada terá sobre confiabilidade ou capacidade de gerenciamento? |
| Reach | O recurso é necessário para ser distribuído globalmente? O recurso pode se comunicar com outros recursos, localizados globalmente ou dentro dessa região? |
| Dependências | Quais são as dependências de outros recursos? |
| Limites de escala | Qual é a taxa de transferência esperada para esse recurso? Qual é a escala fornecida pelo recurso para atender a essa demanda? |
| Disponibilidade/recuperação de desastre | Qual é o impacto na disponibilidade de um desastre nessa camada? Isso causaria uma interrupção sistêmica ou apenas um problema de capacidade ou disponibilidade localizado? |
Importante
Este artigo faz parte da série de carga de trabalho de missão crítica do Azure Well-Architected. Se você não estiver familiarizado com esta série, recomendamos começar com o que é uma carga de trabalho crítica?
Determinados recursos são compartilhados globalmente por recursos implantados em cada região. Exemplos comuns são recursos usados para distribuir o tráfego entre várias regiões, armazenar o estado permanente para todo o aplicativo e monitorar recursos para eles.
| Característica | Considerações |
|---|---|
| Tempo de vida | Espera-se que esses recursos sejam de vida longa (não efêmeros). Seu tempo de vida abrange a vida útil do sistema ou mais. Geralmente, os recursos são gerenciados com dados in-loco e atualizações do plano de controle, supondo que ofereçam suporte a operações de atualização sem tempo de inatividade. |
| Estado | Como esses recursos existem pelo menos durante o tempo de vida do sistema, essa camada geralmente é responsável por armazenar o estado global replicado geograficamente. |
| Reach | Os recursos devem ser distribuídos globalmente e replicados para as regiões que hospedam esses recursos. É recomendável que esses recursos se comuniquem com recursos regionais ou outros com baixa latência e consistência desejada. |
| Dependências | Os recursos devem evitar dependências de recursos regionais porque sua indisponibilidade pode ser uma causa de falha global. Por exemplo, certificados ou segredos mantidos em um único cofre podem ter impacto global se houver uma falha regional onde o cofre está localizado. |
| Limites de escala | Frequentemente, esses recursos são instâncias únicas no sistema e devem ser capazes de escalar de modo que possam lidar com o throughput do sistema como um todo. |
| Disponibilidade/recuperação de desastre | Os recursos regionais e de carimbo podem usar recursos globais. É fundamental que os recursos globais sejam configurados com alta disponibilidade e recuperação de desastre para a integridade de todo o sistema. |
O carimbo contém o aplicativo e os recursos que participam na conclusão de transações comerciais. Um carimbo normalmente corresponde a uma implantação em uma região do Azure. Embora uma região possa ter mais de um selo.
| Característica | Considerações |
|---|---|
| Tempo de vida | Espera-se que os recursos tenham um curto período de vida (efêmero) com a intenção de que possam ser adicionados e removidos dinamicamente enquanto os recursos regionais fora do selo continuam a persistir. A natureza efêmera é necessária para fornecer mais resiliência, escala e proximidade aos usuários. |
| Estado | Como carimbos são efêmeros e serão destruídos a cada implantação, um carimbo deve ser sem estado o quanto for possível. |
| Alcance | Pode se comunicar com recursos regionais e globais. No entanto, a comunicação com outras regiões ou outros selos deve ser evitada. |
| Dependências | Os recursos do selo devem ser independentes. Espera-se que eles tenham dependências regionais e globais, mas não devem depender de componentes em outros selos na mesma ou em outras regiões. |
| Limites de escala | A taxa de transferência é estabelecida por meio de testes. A taxa de transferência do carimbo geral é limitada ao recurso de menor desempenho. A taxa de transferência de selo precisa estimar o alto nível de demanda causado por um failover para outro selo. |
| Disponibilidade/recuperação de desastre | Devido à natureza temporária dos selos, a recuperação de desastre é feita reimplantando o selo. Se os recursos estiverem em um estado não íntegro, o carimbo, como um todo, pode ser destruído e implantado novamente. |
Um sistema pode ter recursos que são implantados na região, mas sobrevivem aos recursos de carimbo. Por exemplo, recursos de observabilidade que monitoram recursos no nível regional, incluindo os selos.
| Característica | Consideração |
|---|---|
| Tempo de vida | Os recursos compartilham o tempo de vida da região e sobrevivem aos recursos do selo. |
| Estado | O estado armazenado em uma região não pode viver além do tempo de vida da região. Se o estado precisar ser compartilhado entre regiões, considere o uso de um armazenamento de dados global. |
| Reach | Os recursos não precisam ser distribuídos globalmente. A comunicação direta com outras regiões deve ser evitada a todo custo. |
| Dependências | Os recursos podem ter dependências de recursos globais, mas não de recursos de selos, pois eles devem ter vida curta. |
| Limites de escala | Determine o limite de escala dos recursos regionais combinando todos os selos dentro da região. |
Esses exemplos de linha de base servem como a arquitetura de estrela do norte recomendada para aplicativos críticos. A linha de base recomenda fortemente a contêinerização e o uso de um orquestrador de contêineres para a plataforma de aplicativo. A linha de base usa o AKS (Serviço de Kubernetes do Azure).
Consulte: Cargas de trabalho de missão crítica bem arquitetadas: Conteinerização.
Se você estiver apenas iniciando sua jornada crítica, use essa arquitetura como referência. A carga de trabalho é acessada por um endpoint público e não requer conectividade de rede privada com outros recursos da empresa.
Essa arquitetura se baseia na arquitetura de linha de base. O design é estendido para fornecer controles de rede estritos para impedir o acesso público não autorizado da Internet aos recursos de carga de trabalho.
Essa arquitetura é apropriada se você estiver implantando a carga de trabalho em uma configuração corporativa em que a integração em uma organização mais ampla é necessária. A carga de trabalho usa serviços compartilhados centralizados, precisa de conectividade local e integra-se a outras cargas de trabalho dentro da empresa. Está implantado em uma assinatura de zona de destino do Azure que herda do grupo de gerenciamento Corp.
Essa arquitetura estende a referência de linha de base considerando os Serviços de Aplicativo como a principal tecnologia de hospedagem de aplicativos, fornecendo um ambiente fácil de usar para implantações de contêiner.
Recomendamos que você use as diretrizes de design fornecidas para navegar pelas principais decisões de design para chegar a uma solução ideal. Para obter informações, consulte Quais são as principais áreas de design?
Examine as práticas recomendadas para criar cenários de aplicativo críticos.