As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
REL03-BP01 Escolha como segmentar sua carga de trabalho
A segmentação de workloads é importante ao determinar os requisitos de resiliência da sua aplicação. Uma arquitetura monolítica deve ser evitada sempre que possível. Em vez disso, considere cuidadosamente quais componentes da aplicação podem ser distribuídos em microsserviços. Dependendo dos requisitos do seu aplicativo, isso pode acabar sendo uma combinação de uma arquitetura orientada a serviços (SOA) com microsserviços sempre que possível. Workloads com capacidade para serem do tipo sem estado têm maior chance de ser implantadas como microsserviços.
Resultado desejado: as workloads devem ser compatíveis, escaláveis e o mais vagamente agrupadas possível.
Ao tomar decisões sobre como segmentar uma workload, pondere os benefícios e as complexidades. O que é ideal para um novo produto a caminho do seu primeiro lançamento não se aplica a uma workload que foi criada para ajuste de escala a partir das necessidades iniciais. Ao refatorar um monólito existente, será necessário considerar o quanto a aplicação poderá oferecer um bom suporte a uma decomposição em direção à condição sem estado. A divisão dos serviços em pedaços menores permite que equipes pequenas e bem definidas os desenvolvam e gerenciem. No entanto, serviços menores podem introduzir complexidades que incluem maior latência potencial, depuração mais complexa e carga operacional aumentada.
Práticas comuns que devem ser evitadas:
-
O microsserviço Death Star
é uma situação em que os componentes atômicos se tornam tão altamente interdependentes que a falha de um resulta em uma falha muito maior, o que torna os componentes tão rígidos e frágeis quanto um monólito.
Benefícios de estabelecer esta prática:
-
Mais segmentos específicos geram maior agilidade, flexibilidade organizacional e escalabilidade.
-
Redução do impacto das interrupções do serviço.
-
Os componentes da aplicação podem ter requisitos de disponibilidade diferentes, aos quais uma segmentação mais atômica pode oferecer suporte.
-
Responsabilidades bem definidas para as equipes que oferecem suporte à workload.
Nível de risco exposto se esta prática recomendada não for estabelecida: Alto
Orientação para implementação
Escolha o tipo de arquitetura com base no modo como você segmentará a workload. Escolha uma SOA arquitetura de microsserviços (ou, em alguns casos raros, uma arquitetura monolítica). Mesmo que você opte por começar com uma arquitetura monolítica, você deve garantir que ela seja modular e possa evoluir para microsserviços à SOA medida que seu produto se expande com a adoção do usuário. SOAe os microsserviços oferecem, respectivamente, uma segmentação menor, que é preferida como uma arquitetura moderna, escalável e confiável, mas há vantagens e desvantagens a serem consideradas, especialmente ao implantar uma arquitetura de microsserviços.
Uma compensação primária é que você agora tem uma arquitetura de computação distribuída que pode tornar mais difícil alcançar requisitos de latência do usuário final, e há complexidade adicional na depuração e no rastreamento de interações com o usuário. Use o AWS X-Ray para ajudar você a resolver esse problema. Outro efeito a ser considerado é o aumento da complexidade operacional à medida que você aumenta o número de aplicações que está gerenciando, o que requer a implantação de vários componentes de independência.
Arquiteturas monolítica, orientada a serviços e de microsserviços
Etapas de implementação
-
Determine a arquitetura adequada para refatorar ou desenvolver sua aplicação. SOAe os microsserviços oferecem, respectivamente, uma segmentação menor, que é preferida como uma arquitetura moderna, escalável e confiável. SOApode ser um bom compromisso para obter uma segmentação menor e, ao mesmo tempo, evitar algumas das complexidades dos microsserviços. Para obter mais detalhes, consulte Compensações de microsserviços
. -
Se sua workload aceitá-la e sua organização puder sustentá-la, use uma arquitetura de microsserviços para obter a melhor agilidade e confiabilidade. Para obter mais detalhes, consulte Implementando microsserviços em. AWS
-
Considere seguir o padrão Strangler Fig
para refatorar um monólito em componentes menores. Isso envolve a substituição gradual de componentes específicos da aplicação por novos serviços e aplicações. O AWS Migration Hub Refactor Spaces atua como ponto de partida para a refatoração incremental. Para obter mais detalhes, consulte Migração simplificada de workloads on-premises herdadas usando um padrão strangler . -
A implementação de microsserviços pode exigir um mecanismo de descoberta de serviços para permitir que esses serviços distribuídos se comuniquem entre si. AWS App Meshpode ser usado com arquiteturas orientadas a serviços para fornecer descoberta e acesso confiáveis aos serviços. AWS Cloud Map
também pode ser usado para descoberta de serviços dinâmica e DNS baseada. -
Se você estiver migrando de um monólito para, o Amazon SOA MQ pode ajudar a preencher a lacuna como um barramento de serviço ao redesenhar aplicativos legados na nuvem.
-
Para monólitos existentes com um único banco de dados compartilhado, escolha como reorganizar os dados em segmentos menores. Isso pode acontecer por unidade de negócios, padrão de acesso ou estrutura de dados. Nesse ponto do processo de refatoração, você deve optar por avançar com um tipo de banco de dados relacional ou não relacional (Não). SQL Para obter mais detalhes, consulte De SQL até Não SQL.
Nível de esforço do plano de implementação: Alto
Recursos
Práticas recomendadas relacionadas:
Documentos relacionados:
Exemplos relacionados:
Vídeos relacionados:
