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 star norte e inclui outros exemplos com componentes de tecnologia comuns.
Recomendamos que você avalie as principais áreas de design, defina os fluxos críticos do usuário e do 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 impacto o estado persistente nessa camada terá na confiabilidade ou na 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 cargas de trabalho críticas do Azure Well-Architected . Se você não estiver familiarizado com esta série, recomendamos que comece 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 de todo o aplicativo e monitorar recursos para eles.
| Característica | Considerações |
|---|---|
| Tempo de vida | Espera-se que esses recursos sejam de longa vida (não efêmeros). Seu tempo de vida abrange a vida útil do sistema ou mais. Geralmente, os recursos são gerenciados com atualizações de plano de controle e dados in-loco, supondo que eles dão suporte a operações de atualização de tempo de inatividade zero. |
| 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 para falhas globais. Por exemplo, certificados ou segredos mantidos em um único cofre podem ter impacto global se houver uma falha regional em que o cofre está localizado. |
| Limites de escala | Geralmente, esses recursos são instâncias singleton no sistema e devem ser capazes de dimensionar de modo que possam lidar com a taxa de transferência do sistema como um todo. |
| Disponibilidade/recuperação de desastre | Os recursos regionais e de selo podem usar recursos globais. É fundamental que os recursos globais sejam configurados com alta disponibilidade e recuperação de desastres para a integridade de todo o sistema. |
O selo contém o aplicativo e os recursos que participam da 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 eles 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 os selos são efêmeros e serão destruídos a cada implantação, um selo deve ser sem estado o máximo possível. |
| Reach | 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 de 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 selo 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 selo, como um todo, poderá ser destruído e reimplantado. |
Um sistema pode ter recursos que são implantados na região, mas sobrevivem aos recursos de selo. 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 ativam os recursos de 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 usar 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 em recursos de selo porque os selos devem ser de curta duração. |
| 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 star norte recomendada para aplicativos críticos. A linha de base recomenda fortemente a conteinerização e o uso de um orquestrador de contêiner para a plataforma de aplicativo. A linha de base usa Serviço de Kubernetes do Azure (AKS).
Consulte Cargas de trabalho críticas de missão bem arquiteta: conteinerização.
Se você estiver apenas iniciando sua jornada crítica, use essa arquitetura como referência. A carga de trabalho é acessada em um ponto de extremidade 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. Ele é 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 Aplicativos 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.