Este browser já não é suportado.
Atualize para o Microsoft Edge para tirar partido das mais recentes funcionalidades, atualizações de segurança e de suporte técnico.
Este artigo apresenta um padrão chave para arquiteturas de missão crítica no Azure. Aplique esse padrão ao iniciar o processo de design e, em seguida, selecione os componentes mais adequados aos seus requisitos de negócios. O artigo recomenda uma abordagem de design de estrela do norte e inclui outros exemplos com componentes tecnológicos 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 seguintes características.
| Característica | Considerações |
|---|---|
| Tempo de vida | Qual é o tempo de vida esperado do recurso, em relação a outros recursos na solução? O recurso deve sobreviver ou partilhar o tempo de vida com todo o sistema ou região, ou deve ser temporário? |
| Estado | Que impacto terá o estado persistente nesta camada na fiabilidade ou capacidade de gestão? |
| Alcance | É necessário que o recurso seja 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? Quanta escala é fornecida pelo recurso para atender a essa demanda? |
| Disponibilidade/recuperação de desastres | Qual é o impacto na disponibilidade de um desastre nesta camada? Isso causaria uma interrupção sistêmica ou apenas um problema de capacidade ou disponibilidade localizada? |
Importante
Este artigo faz parte da série de cargas de trabalho críticas para a missão do Azure
Certos recursos são compartilhados globalmente pelos recursos implantados em cada região. Exemplos comuns são recursos que são 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 estes recursos sejam de longa duração (não efémeros). A sua vida útil abrange a vida do sistema ou mais. Muitas vezes, os recursos são geridos com dados locais e atualizações do plano de controlo, assumindo que suportam operações de atualização sem interrupção. |
| Estado | Como esses recursos existem pelo menos durante a vida útil do sistema, essa camada geralmente é responsável por armazenar o estado global replicado geograficamente. |
| Alcance | Os recursos devem ser distribuídos globalmente e replicados para as regiões que hospedam esses recursos. Recomenda-se que esses recursos se comuniquem com recursos regionais ou outros com baixa latência e a consistência desejada. |
| Dependências | Os recursos devem evitar dependências de recursos regionais, porque a sua indisponibilidade pode ser uma causa de fracasso 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 singleton no sistema, e devem ser capazes de escalar para lidar com a taxa de transferência do sistema como um todo. |
| Disponibilidade/recuperação de desastres | Recursos regionais e de carimbo 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 carimbo contém o aplicativo e os recursos que participam da conclusão de transações comerciais. Um selo normalmente corresponde a uma implementação numa região do Azure. Embora uma região possa ter mais de um carimbo.
| Característica | Considerações |
|---|---|
| Tempo de vida | Espera-se que os recursos tenham uma vida útil curta (efêmera) 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 com os usuários. |
| Estado | Como os selos são efémeros e serão destruídos a cada implementação, um selo deve ser sem estado o máximo possível. |
| Alcance | Pode 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 região ou em outras regiões. |
| Limites de escala | A taxa de transferência é estabelecida por meio de testes. O rendimento do carimbo geral é limitado pelo recurso menos eficiente. A taxa de transferência de carimbo precisa estimar o alto nível de demanda causado por um failover para outro carimbo. |
| Disponibilidade/recuperação de desastres | Devido à natureza temporária dos selos, a recuperação de desastres é feita reimplantando o carimbo. Se os recursos estiverem em mau estado, o carimbo, como um todo, pode ser destruído e redistribuído. |
Um sistema pode ter recursos que são implantados na região, mas sobrevivem aos recursos de carimbo. Por exemplo, recursos de observabilidade que monitorizam os recursos a nível regional, incluindo os selos.
| Característica | Consideração |
|---|---|
| Tempo de vida | Os recursos partilham o tempo de vida da região e duram mais que os recursos do selo. |
| Estado | Estado armazenado numa região não pode viver além da duração da região. Se o estado precisar ser compartilhado entre regiões, considere o uso de um armazenamento de dados global. |
| Alcance | Os recursos não precisam ser distribuídos globalmente. A comunicação direta com outras regiões deve ser evitada a todo o custo. |
| Dependências | Os recursos podem ter dependências de recursos globais, mas não de recursos de carimbo porque os selos devem ser de curta duração. |
| Limites de escala | Determinar 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 norte recomendada para aplicações de missão crítica. A linha de base recomenda fortemente a conteinerização e o uso de um orquestrador de contêineres para a plataforma de aplicativos. A linha de base usa o Serviço Kubernetes do Azure (AKS).
Consulte Well-Architected cargas de trabalho de missão crítica: Contentorização.
Se você está apenas começando sua jornada de missão crítica, use essa arquitetura como referência. A carga de trabalho acede-se através de um endpoint público e não necessita de conectividade à rede privada com os restantes recursos da empresa.
Essa arquitetura se baseia na arquitetura de linha de base. O design é estendido para fornecer controles de rede rigorosos para impedir o acesso público não autorizado da Internet aos recursos da carga de trabalho.
Essa arquitetura é apropriada se você estiver implantando a carga de trabalho em uma configuração corporativa onde a integração dentro de 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á implementado numa subscrição da zona de receção do Azure que herdou do grupo de gestão 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 projeto fornecidas para navegar pelas principais decisões de projeto para chegar a uma solução ideal. Para obter informações, consulte Quais são as principais áreas de design?
Analise as práticas recomendadas para projetar cenários de aplicativos de missão crítica.