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 críticas para a missão no Azure. Aplique este padrão quando iniciar o processo de conceção e, em seguida, selecione os componentes mais adequados para os seus requisitos empresariais. O artigo recomenda uma abordagem de design star norte e inclui outros exemplos com componentes de tecnologia comuns.
Recomendamos que avalie as principais áreas de design, defina os fluxos críticos do utilizador e do sistema que utilizam os componentes subjacentes e desenvolva uma matriz de recursos do Azure e a respetiva configuração, tendo em conta as seguintes características.
| Característica | Considerações |
|---|---|
| Duração | Qual é a duração esperada do recurso, relativamente a outros recursos na solução? O recurso deve sobreviver ou partilhar a duração com todo o sistema ou região, ou deve ser temporário? |
| Estado | Que impacto terá o estado persistente nesta camada na fiabilidade ou na capacidade de gestão? |
| Alcançar | O recurso tem de ser distribuído globalmente? O recurso pode comunicar com outros recursos, localizados globalmente ou nessa região? |
| Dependências | Quais são as dependências de outros recursos? |
| Limites de dimensionamento | Qual é o débito esperado para esse recurso? Quanto dimensionamento é fornecido pelo recurso para corresponder a essa procura? |
| Disponibilidade/recuperação após desastre | Qual é o impacto na disponibilidade de um desastre nesta camada? Causaria uma indisponibilidade sistémica ou apenas um problema de disponibilidade ou capacidade localizada? |
Importante
Este artigo faz parte da série de cargas de trabalho críticas para a missão do Azure Well-Architected . Se não estiver familiarizado com esta série, recomendamos que comece com o que é uma carga de trabalho crítica para a missão?
Determinados recursos são partilhados globalmente pelos recursos implementados em cada região. Exemplos comuns são recursos que são utilizados para distribuir o tráfego por várias regiões, armazenar o estado permanente de toda a aplicação e monitorizar recursos para as mesmas.
| Característica | Considerações |
|---|---|
| Duração | Espera-se que estes recursos sejam de longa duração (não efémeros). A sua duração abrange a vida útil do sistema ou mais tempo. Muitas vezes, os recursos são geridos com dados no local e atualizações do plano de controlo, assumindo que suportam operações de atualização de tempo de inatividade zero. |
| Estado | Uma vez que estes recursos existem pelo menos durante a duração do sistema, esta camada é muitas vezes responsável por armazenar o estado global e georreplicado. |
| Alcançar | Os recursos devem ser distribuídos e replicados globalmente para as regiões que alojam esses recursos. Recomenda-se que estes recursos comuniquem com recursos regionais ou outros com baixa latência e consistência pretendida. |
| Dependências | Os recursos devem evitar dependências de recursos regionais porque a indisponibilidade pode ser uma causa para falhas globais. Por exemplo, certificados ou segredos mantidos num único cofre podem ter impacto global se existir uma falha regional onde o cofre está localizado. |
| Limites de dimensionamento | Muitas vezes, estes recursos são instâncias singleton no sistema e devem ser capazes de dimensionar de modo a que possam lidar com o débito do sistema como um todo. |
| Disponibilidade/recuperação após desastre | Os recursos regionais e de carimbo podem utilizar recursos globais. É fundamental que os recursos globais sejam configurados com elevada disponibilidade e recuperação após desastre para o estado de funcionamento de todo o sistema. |
O selo contém a aplicação e os recursos que participam na conclusão de transações empresariais. Normalmente, um carimbo corresponde a uma implementação a uma região do Azure. Embora uma região possa ter mais do que um selo.
| Característica | Considerações |
|---|---|
| Duração | 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 proporcionar mais resiliência, escala e proximidade aos utilizadores. |
| Estado | Uma vez que os selos são efémeros e serão destruídos com cada implementação, um selo deve ser sem estado tanto quanto possível. |
| Alcançar | 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 de selo têm de ser independentes. Espera-se que tenham dependências regionais e globais, mas não devem depender de componentes noutros selos nas mesmas regiões ou noutras regiões. |
| Limites de dimensionamento | O débito é estabelecido através de testes. O débito do selo global está limitado ao recurso de menor desempenho. O débito de selo tem de estimar o elevado nível de procura causado por uma ativação pós-falha para outro selo. |
| Disponibilidade/recuperação após desastre | Devido à natureza temporária dos selos, a recuperação após desastre é feita através da reimplementação do selo. Se os recursos estiverem num estado de mau estado de funcionamento, o carimbo, como um todo, pode ser destruído e reimplementado. |
Um sistema pode ter recursos que são implementados na região, mas sobrevivem aos recursos de selo. Por exemplo, recursos de observação que monitorizam recursos ao nível regional, incluindo os selos.
| Característica | Consideração |
|---|---|
| Duração | Os recursos partilham a duração da região e vivem os recursos de selo. |
| Estado | O estado armazenado numa região não pode viver além da duração da região. Se o estado precisar de ser partilhado entre regiões, considere utilizar um arquivo de dados global. |
| Alcançar | Os recursos não precisam de 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 em recursos de selo, porque os selos devem ser de curta duração. |
| Limites de dimensionamento | Determine o limite de dimensionamento dos recursos regionais ao combinar todos os selos na região. |
Estes exemplos de linha de base servem como a arquitetura de star norte recomendada para aplicações críticas para a missão. A linha de base recomenda vivamente a contentorização e a utilização de um orquestrador de contentores para a plataforma de aplicações. A linha de base utiliza Azure Kubernetes Service (AKS).
Veja Cargas de trabalho fundamentais para a missão Bem Arquiteted: Containerization.
Se estiver apenas a iniciar o seu percurso crítico para a missão, utilize esta arquitetura como referência. A carga de trabalho é acedida através de um ponto final público e não requer conectividade de rede privada a outros recursos da empresa.
Esta arquitetura baseia-se na arquitetura de linha de base. A estrutura é expandida para fornecer controlos de rede rigorosos para impedir o acesso público não autorizado da Internet aos recursos da carga de trabalho.
Esta arquitetura é adequada se estiver a implementar a carga de trabalho numa configuração empresarial onde a integração numa organização mais ampla é necessária. A carga de trabalho utiliza serviços partilhados centralizados, precisa de conectividade no local e integra-se com outras cargas de trabalho na empresa. É implementada numa subscrição de zona de destino do Azure que herda do grupo de gestão Corp.
Esta arquitetura expande a referência de linha de base ao considerar os Serviços Aplicacionais como a tecnologia de alojamento de aplicações primária, proporcionando um ambiente fácil de utilizar para implementações de contentores.
Recomendamos que utilize a documentação de orientação de estrutura fornecida para navegar pelas principais decisões de conceção para alcançar uma solução ideal. Para obter informações, consulte Quais são as principais áreas de design?
Reveja as melhores práticas para conceber cenários de aplicações fundamentais para a missão.
Brevemente: Ao longo de 2024, vamos descontinuar progressivamente o GitHub Issues como mecanismo de feedback para conteúdos e substituí-lo por um novo sistema de feedback. Para obter mais informações, veja: https://aka.ms/ContentUserFeedback.
Submeter e ver comentários