Padrão strangler fig

Migre incrementalmente um sistema herdado substituindo gradualmente partes específicas da funcionalidade por novos aplicativos e serviços. À medida que você substitui os recursos do sistema herdado, o novo sistema eventualmente compreende todos os recursos do sistema antigo. Essa abordagem suprime o sistema antigo para que você possa descomissioná-lo.

Contexto e problema

À medida que os sistemas envelhecem, as ferramentas de desenvolvimento, a tecnologia de hospedagem e as arquiteturas do sistema nas quais eles são criados podem se tornar obsoletas. À medida que novos recursos e funcionalidades são adicionados, esses aplicativos se tornam mais complexos, o que pode torná-los mais difíceis de manter ou estender.

É difícil substituir um sistema complexo inteiro. Em vez disso, você pode migrar gradualmente para um novo sistema e usar o sistema antigo para funcionalidades que ainda não foram migradas. No entanto, se você executar versões paralelas de um aplicativo, os clientes deverão acompanhar qual versão contém cada recurso. Ao migrar um recurso ou serviço, você deve direcionar os clientes para o novo local. Para enfrentar esses desafios, adote uma abordagem que dê suporte à migração incremental e minimize as interrupções nos clientes.

Solução

Depois de identificar novos limites de serviço, use um processo incremental para substituir partes específicas da funcionalidade por novos aplicativos e serviços. Os clientes continuam a usar a mesma interface e não sabem que uma migração está em andamento.

Diagramas que mostram o padrão Strangler Fig.

Carrege um arquivo Visio desta arquitetura.

O padrão Strangler Fig oferece uma abordagem de modernização controlada e em fases. Ele permite que o aplicativo existente continue funcionando durante o esforço de modernização. Uma fachada (proxy) intercepta as solicitações que vão para o sistema de back-end herdado. A camada de fachada roteia essas solicitações para o aplicativo legado ou para os novos serviços.

Esse padrão reduz os riscos na migração, permitindo que suas equipes avancem em um ritmo que atenda à complexidade do projeto. À medida que você migra a funcionalidade para o novo sistema, o sistema herdado torna-se obsoleto e você desativa o sistema herdado.

  1. O padrão do Strangler Fig começa introduzindo uma fachada (proxy) entre o aplicativo cliente, o sistema herdado e o novo sistema. A fachada atua como um intermediário. Ele permite que o aplicativo cliente interaja com o sistema herdado e o novo sistema. Inicialmente, a fachada roteia a maioria das solicitações para o sistema herdado.

  2. À medida que a migração progride, a interface gradativamente redireciona as solicitações do sistema legado para o novo sistema. A cada iteração, você implementa mais peças de funcionalidade no novo sistema.

    Essa abordagem incremental reduz gradualmente as responsabilidades do sistema herdado e expande o escopo do novo sistema. O processo é iterativo. Ele permite que a equipe resolva complexidades e dependências em estágios gerenciáveis. Esses estágios ajudam o sistema a permanecer estável e funcional.

  3. Depois de migrar toda a funcionalidade e não houver dependências no sistema herdado, você poderá desativar o sistema herdado. A fachada encaminha todas as solicitações exclusivamente para o novo sistema.

  4. Você remove a fachada e reconfigura o aplicativo cliente para se comunicar diretamente com o novo sistema. Esta etapa marca a conclusão da migração.

Problemas e considerações

Considere os seguintes pontos ao decidir como implementar esse padrão:

  • Considere como lidar com serviços e armazenamentos de dados que o novo sistema e o sistema herdado podem usar. Verifique se ambos os sistemas podem acessar esses recursos ao mesmo tempo.

  • Estruture novos aplicativos e serviços de forma que você possa facilmente interceptá-los e substituí-los em futuras migrações do tipo strangler fig. Por exemplo, procure ter demarcações claras entre partes da sua solução para que você possa migrar cada parte individualmente.

  • Após a migração ser concluída, você de modo geral removerá a fachada strangler fig. Como alternativa, você pode manter a fachada como um adaptador para uso por clientes legados enquanto atualiza o sistema central para clientes mais novos.

    Conceitualize isso como arquitetura de transição e balancee os benefícios de mitigação de risco dessa arquitetura em relação aos custos temporários de infraestrutura.

  • Certifique-se de que a fachada acompanhe a migração.

  • Verifique se a fachada não se torna um único ponto de falha ou um gargalo de desempenho.

  • Planeje dependências entre sistemas. Durante a migração, ambos os sistemas precisam coexistir e se comunicar. Por exemplo, o novo sistema pode precisar chamar a funcionalidade não migrada do sistema herdado e os componentes herdados não modificados podem precisar chamar a funcionalidade migrada do novo sistema. Para gerenciar essas chamadas, use o padrão camada anticorrupção. Uma camada anticorrupção atua como um adaptador que converte solicitações entre os dois sistemas. Essa camada protege o design do novo sistema contra semântica herdada para que o sistema herdado possa alcançar novos serviços sem alterações significativas no código. Sem esse adaptador, as dependências entre sistemas podem interromper componentes ou forçar o novo sistema a adotar convenções herdadas.

Quando usar esse padrão

Use esse padrão quando:

  • Você migra gradualmente um aplicativo de back-end para uma nova arquitetura, especialmente quando a substituição de sistemas grandes, componentes-chave ou recursos complexos introduz riscos.

  • O sistema original pode continuar a existir por um longo período de tempo durante o esforço de migração.

O padrão pode não ser adequado nestes casos:

  • As solicitações ao sistema de back-end não podem ser interceptadas.

  • Você não pode acessar o código-fonte do sistema herdado. Para desabilitar recursos migrados e redirecionar chamadas internas, você precisa ser capaz de modificar o código-fonte do sistema herdado.

  • Você migra um sistema pequeno e substituir todo o sistema é simples.

  • Você precisa desativar totalmente a solução original rapidamente.

Design de carga de trabalho

Avalie como usar o padrão do Strangler Fig no design de uma carga de trabalho para abordar as metas e os princípios dos pilares do Azure Well-Architected Framework. A tabela a seguir fornece diretrizes sobre como esse padrão dá suporte às metas de cada pilar.

Pilar Como esse padrão apoia os objetivos do pilar
As decisões de design de confiabilidade ajudam sua carga de trabalho a se tornar resiliente ao mau funcionamento e a garantir que ela se recupere para um estado totalmente funcional após a ocorrência de uma falha. A abordagem incremental desse padrão pode ajudar a reduzir os riscos durante uma transição de componente em comparação com fazer grandes alterações sistêmicas de uma só vez.

- RE:08 Testes
A Otimização de Custos concentra-se na manutenção e na melhoria do ROI (retorno sobre o investimento) da carga de trabalho. O objetivo dessa abordagem é maximizar o uso de investimentos existentes no sistema atualmente em execução, modernizando-se incrementalmente. Ele permite que você execute substituições de ALTA ROI antes de substituições com baixo ROI.

- CO:07 Custos de componentes
- CO:08 Custos ambientais
A Excelência Operacional ajuda a fornecer qualidade na carga de trabalho por meio de processos padronizados e coesão da equipe. Esse padrão fornece uma abordagem de melhoria contínua. As substituições incrementais que fazem pequenas alterações ao longo do tempo são preferíveis a grandes alterações sistêmicas que são mais arriscadas de implementar.

- OE:06 Cadeia de fornecimento para desenvolvimento de carga de trabalho
- OE:11 Práticas de implantação segura

Considere as compensações em relação às metas dos outros pilares que esse padrão pode introduzir.

Exemplo

Os sistemas herdados normalmente dependem de um banco de dados monolítico centralizado que atende a vários domínios. Com o tempo, esse banco de dados compartilhado se torna difícil de gerenciar e melhorar devido a suas dependências entre domínios. Para resolver esse desafio, o padrão Strangler Fig extrai, de forma incremental, tabelas específicas do domínio, procedimentos armazenados e dados relacionados do banco de dados monolítico para bancos de dados de domínio isolados. Cada banco de dados contém apenas um domínio. Repita o processo de extração até que o banco de dados monolítico esteja totalmente decomposto.

Diagramas que mostram o padrão Strangler Fig aplicado a um banco de dados.

  1. Introduza um novo serviço de sistema, que começa a gerenciar solicitações para seu domínio. O novo serviço do sistema ainda lê e grava no banco de dados monolítico para suas tabelas de domínio. O sistema herdado continua atendendo a todos os outros domínios.

  2. Introduza um banco de dados de domínio isolado para o novo sistema. Migre as tabelas de domínio relevantes e seus dados históricos para o novo banco de dados usando um processo de ETL (extração, transformação e carregamento). Um processo de CDC (captura de dados de mudanças) sincroniza os dados de domínio do banco de dados monolítico para o novo banco de dados de domínio. Durante essa fase, o sistema herdado continua a ler e gravar no banco de dados monolítico e o novo sistema grava no novo banco de dados de domínio. Valide a consistência entre ambos os bancos de dados antes da substituição.

  3. Após a validação, o novo banco de dados de domínio é o sistema de registro para esse domínio. O novo sistema executa todas as operações de leitura e gravação no banco de dados de domínio. Remova as tabelas de domínio correspondentes, os procedimentos armazenados e as dependências do banco de dados monolítico. Repita esse processo para cada domínio até que o banco de dados monolítico esteja totalmente decomposto.

    Você pode reverter para o banco de dados monolítico durante a fase 2 e no início da fase 3, quando as tabelas de domínio e os processos de sincronização ainda existem no banco de dados monolítico. Para reverter para o banco de dados monolítico depois de remover as tabelas de domínio, os procedimentos armazenados e os processos de sincronização do banco de dados monolítico, você deve restaurar esses objetos e reproduzir as alterações de dados. No entanto, esse processo aumenta significativamente o esforço e o risco. Trate a remoção de objetos herdados como uma etapa final deliberada para cada domínio. Remova objetos herdados somente depois que o novo sistema for validado.

Contribuidores

A Microsoft mantém este artigo. Os colaboradores a seguir escreveram este artigo.

Autores principais:

Para ver perfis de LinkedIn não públicos, entre em LinkedIn.

Próxima etapa

  • Last updated on