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á.
Migração da lógica de negócios do banco de dados para a camada do aplicativo
A migração da lógica de negócios de procedimentos, acionadores e funções armazenados no banco de dados para serviços da camada de aplicativos é uma etapa essencial na decomposição de bancos de dados monolíticos. Essa transformação melhora a autonomia do serviço, simplifica a manutenção e melhora a escalabilidade. Esta seção fornece orientação sobre como analisar a lógica do banco de dados, planejar a estratégia de migração e, em seguida, implementar a transformação, mantendo a continuidade dos negócios. Também discute o estabelecimento de um plano de reversão eficaz.
Esta seção contém os seguintes tópicos:
Fase 1: Analisando a lógica de negócios
Ao modernizar bancos de dados monolíticos, você deve primeiro realizar uma análise abrangente da lógica de seu banco de dados existente. Essa fase se concentra em três categorias principais:
-
Os procedimentos armazenados geralmente contêm operações comerciais críticas, incluindo lógica de manipulação de dados, regras de negócios, verificações de validação e cálculos. Como componentes principais da lógica de negócios do aplicativo, eles exigem uma decomposição cuidadosa. Por exemplo, os procedimentos armazenados de uma organização financeira podem lidar com cálculos de juros, reconciliação de contas e verificações de conformidade.
-
Os acionadores são os principais componentes do banco de dados que lidam com trilhas de auditoria, validação de dados, cálculos e consistência entre tabelas. Por exemplo, uma organização de varejo pode usar gatilhos para gerenciar atualizações de estoque em todo o sistema de processamento de pedidos, o que demonstra a complexidade das operações automatizadas do banco de dados.
-
As funções em bancos de dados gerenciam principalmente transformações de dados, cálculos e operações de pesquisa. Eles geralmente são incorporados em vários procedimentos e aplicativos. Por exemplo, uma organização de saúde pode usar funções para normalizar os dados do paciente ou consultar códigos médicos.
Cada categoria representa aspectos diferentes da lógica de negócios que está incorporada na camada do banco de dados. Você precisa avaliar e planejar cuidadosamente cada uma delas para migrá-las para a camada de aplicação.
Durante essa fase de análise, os clientes normalmente enfrentam três desafios significativos. Primeiro, dependências complexas surgem por meio de chamadas de procedimentos aninhadas, referências entre esquemas e dependências de dados implícitas. Em segundo lugar, o gerenciamento de transações se torna essencial, principalmente ao lidar com transações em várias etapas e manter a consistência dos dados em sistemas distribuídos. Em terceiro lugar, as considerações de desempenho devem ser cuidadosamente avaliadas, especialmente para operações de processamento em lote, atualizações de dados em massa e cálculos em tempo real que atualmente se beneficiam da proximidade com os dados.
Para enfrentar esses desafios de forma eficaz, você pode usar AWS Schema Conversion Tool (AWS SCT) para análise inicial e, em seguida, usar ferramentas detalhadas de mapeamento de dependências. Essa abordagem ajuda você a entender o escopo completo da lógica do seu banco de dados e a criar uma estratégia de migração abrangente que mantenha a continuidade dos negócios durante a decomposição.
Ao entender completamente esses componentes e desafios, você pode planejar melhor sua jornada de modernização e tomar decisões informadas sobre quais elementos priorizar durante a migração para uma arquitetura baseada em microsserviços.
Ao analisar os componentes do código do banco de dados, crie uma documentação abrangente para cada procedimento, acionador e função armazenados. Comece descrevendo claramente sua finalidade e funcionalidade principal, incluindo as regras de negócios que ela implementa. Detalhe todos os parâmetros de entrada e saída e anote seus tipos de dados e intervalos válidos. Mapeie dependências em outros objetos de banco de dados, sistemas externos e processos posteriores. Defina claramente os limites da transação e os requisitos de isolamento para manter a integridade dos dados. Documente todas as expectativas de desempenho, incluindo requisitos de tempo de resposta e padrões de utilização de recursos. Por fim, analise os padrões de uso para entender os picos de carga, a frequência de execução e os períodos comerciais críticos.
Fase 2: Classificando a lógica de negócios
A decomposição eficaz do banco de dados requer a categorização sistemática da lógica do banco de dados em todas as principais dimensões: complexidade, impacto nos negócios, dependências, padrões de uso e dificuldade de migração. Essa classificação ajuda você a identificar componentes de alto risco, determinar os requisitos de teste e estabelecer prioridades de migração. Por exemplo, procedimentos armazenados complexos com alto impacto nos negócios e uso frequente exigem um planejamento cuidadoso e testes extensivos. No entanto, funções simples, raramente usadas, com dependências mínimas, podem ser adequadas para as fases iniciais da migração.
Essa abordagem estruturada cria um roteiro de migração equilibrado que minimiza a interrupção dos negócios e, ao mesmo tempo, mantém a estabilidade do sistema. Ao entender essas inter-relações, você pode melhorar a sequência de seus esforços de decomposição e alocar recursos de forma adequada.
Fase 3: Migração da lógica de negócios
Depois de analisar e classificar sua lógica de negócios, é hora de migrá-la. Há duas abordagens ao migrar a lógica de negócios de um banco de dados monolítico: mover a lógica do banco de dados para a camada do aplicativo ou mover a lógica comercial para outro banco de dados que faça parte do microsserviço.
Se você migrar a lógica de negócios para o aplicativo, as tabelas do banco de dados armazenarão somente os dados, e o banco de dados não conterá nenhuma lógica comercial. Essa é a abordagem recomendada. Você pode usar o Ispirer
Se você migrar a lógica de negócios para outro banco de dados, poderá usar AWS Schema Conversion Tool (AWS SCT) para converter esquemas de banco de dados e objetos de código existentes em seu banco de dados de destino. Ele oferece suporte a serviços de AWS banco de dados específicos, como Amazon DynamoDB, Amazon Aurora e Amazon Redshift. Ao fornecer um relatório de avaliação abrangente e recursos de conversão automatizada, AWS SCT ajuda a simplificar o processo de transição, permitindo que você se concentre na otimização de sua nova estrutura de banco de dados para melhorar o desempenho e a escalabilidade. À medida que você avança em seu projeto de modernização, AWS SCT pode lidar com conversões incrementais para oferecer suporte a uma abordagem em fases, permitindo validar e ajustar cada etapa da transformação do banco de dados.
Estratégia de reversão para lógica de negócios
Dois aspectos críticos de qualquer estratégia de decomposição são manter a compatibilidade com versões anteriores e implementar procedimentos abrangentes de reversão. Esses elementos trabalham juntos para ajudar a proteger as operações durante o período de transição. Esta seção descreve como gerenciar a compatibilidade durante o processo de decomposição e estabelecer recursos eficazes de reversão de emergência que protejam contra possíveis problemas.
Mantenha a compatibilidade com versões anteriores
Durante a decomposição do banco de dados, manter a compatibilidade com versões anteriores é essencial para transições suaves. Mantenha os procedimentos de banco de dados existentes temporariamente em vigor enquanto implementa gradualmente novas funcionalidades. Use o controle de versão para rastrear todas as alterações e gerenciar várias versões do banco de dados simultaneamente. Planeje um período de coexistência prolongado em que os sistemas de origem e de destino devem operar de forma confiável. Isso dá tempo para testar e validar o novo sistema antes de retirar os componentes antigos. Essa abordagem minimiza a interrupção dos negócios e fornece uma rede de segurança para reversão, se necessário.
Plano de reversão de emergência
Uma estratégia abrangente de reversão é essencial para a decomposição segura do banco de dados. Implemente sinalizadores de recursos em seu código para controlar qual versão da lógica de negócios está ativa. Isso permite que você alterne instantaneamente entre as implementações nova e original sem alterações na implantação. Essa abordagem fornece controle refinado sobre a transição e ajuda você a reverter rapidamente se surgirem problemas. Mantenha a lógica original como um backup verificado e mantenha procedimentos detalhados de reversão que especificam acionadores, responsabilidades e etapas de recuperação.
Teste regularmente esses cenários de reversão sob várias condições para validar sua eficácia e garantir que as equipes estejam familiarizadas com os procedimentos de emergência. Os sinalizadores de recursos também permitem lançamentos graduais ao habilitar seletivamente novas funcionalidades para grupos de usuários ou transações específicas. Isso fornece uma camada adicional de mitigação de riscos durante a transição.
