Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Migración de la lógica empresarial de la base de datos a la capa de aplicación
La migración de la lógica empresarial de los procedimientos, desencadenantes y funciones almacenados en la base de datos a los servicios de la capa de aplicación es un paso fundamental para descomponer las bases de datos monolíticas. Esta transformación mejora la autonomía del servicio, simplifica el mantenimiento y mejora la escalabilidad. En esta sección se proporciona orientación sobre el análisis de la lógica de la base de datos, la planificación de la estrategia de migración y, posteriormente, la implementación de la transformación sin dejar de mantener la continuidad empresarial. También se analiza el establecimiento de un plan de reversión eficaz.
Esta sección contiene los siguientes temas:
Fase 1: Análisis de la lógica empresarial
Al modernizar las bases de datos monolíticas, primero debe realizar un análisis exhaustivo de la lógica de la base de datos existente. Esta fase se centra en tres categorías principales:
-
Los procedimientos almacenados suelen contener operaciones empresariales críticas, como la lógica de manipulación de datos, las reglas empresariales, las comprobaciones de validación y los cálculos. Como componentes fundamentales de la lógica empresarial de la aplicación, requieren una descomposición cuidadosa. Por ejemplo, los procedimientos almacenados de una organización financiera pueden gestionar los cálculos de intereses, la conciliación de cuentas y las comprobaciones de conformidad.
-
Los desencadenantes son componentes clave de la base de datos que gestionan los registros de auditoría, la validación de los datos, los cálculos y la coherencia entre tablas. Por ejemplo, una organización minorista puede utilizar activadores para gestionar las actualizaciones de inventario en todo su sistema de procesamiento de pedidos, lo que demuestra la complejidad de las operaciones automatizadas de las bases de datos.
-
Las funciones de las bases de datos gestionan principalmente las transformaciones de datos, los cálculos y las operaciones de búsqueda. Suelen estar integradas en varios procedimientos y aplicaciones. Por ejemplo, una organización sanitaria puede utilizar funciones para normalizar los datos de los pacientes o buscar códigos médicos.
Cada categoría representa diferentes aspectos de la lógica empresarial que está integrada en la capa de base de datos. Debe evaluar y planificar cuidadosamente cada uno de ellos para migrarlos a la capa de aplicación.
Durante esta fase de análisis, los clientes suelen enfrentarse a tres desafíos importantes. En primer lugar, las dependencias complejas surgen a través de llamadas a procedimientos anidadas, referencias entre esquemas y dependencias de datos implícitas. En segundo lugar, la gestión de las transacciones se vuelve fundamental, especialmente cuando se trata de transacciones de varios pasos y se mantiene la coherencia de los datos en los sistemas distribuidos. En tercer lugar, las consideraciones de rendimiento deben evaluarse cuidadosamente, especialmente en el caso de las operaciones de procesamiento por lotes, las actualizaciones masivas de datos y los cálculos en tiempo real, que actualmente se benefician de estar cerca de los datos.
Para abordar estos desafíos de manera efectiva, puede usar AWS Schema Conversion Tool (AWS SCT) para el análisis inicial y luego usar herramientas detalladas de mapeo de dependencias. Este enfoque le ayuda a comprender todo el alcance de la lógica de su base de datos y a crear una estrategia de migración integral que mantenga la continuidad empresarial durante la descomposición.
Al comprender a fondo estos componentes y desafíos, podrá planificar mejor su proceso de modernización y tomar decisiones informadas sobre qué elementos priorizar durante la migración a una arquitectura basada en microservicios.
Al analizar los componentes del código de la base de datos, cree una documentación completa para cada procedimiento, desencadenante y función almacenados. Comience por describir claramente su propósito y funcionalidad principal, incluidas las reglas comerciales que implementa. Detalle todos los parámetros de entrada y salida y anote sus tipos de datos y rangos válidos. Planifique las dependencias con respecto a otros objetos de la base de datos, sistemas externos y procesos posteriores. Defina claramente los límites de las transacciones y los requisitos de aislamiento para mantener la integridad de los datos. Documente cualquier expectativa de rendimiento, incluidos los requisitos de tiempo de respuesta y los patrones de utilización de los recursos. Por último, analice los patrones de uso para comprender los picos de carga, la frecuencia de ejecución y los períodos comerciales críticos.
Fase 2: Clasificación de la lógica empresarial
La descomposición efectiva de las bases de datos requiere una categorización sistemática de la lógica de la base de datos en sus dimensiones clave: complejidad, impacto en el negocio, dependencias, patrones de uso y dificultad de migración. Esta clasificación le ayuda a identificar los componentes de alto riesgo, determinar los requisitos de prueba y establecer las prioridades de migración. Por ejemplo, los procedimientos almacenados complejos con un alto impacto empresarial y un uso frecuente requieren una planificación cuidadosa y pruebas exhaustivas. Sin embargo, las funciones simples, poco utilizadas y con dependencias mínimas, pueden ser adecuadas para las primeras fases de migración.
Este enfoque estructurado crea una hoja de ruta de migración equilibrada que minimiza las interrupciones empresariales y, al mismo tiempo, mantiene la estabilidad del sistema. Al comprender estas interrelaciones, puede mejorar la secuencia de sus esfuerzos de descomposición y asignar los recursos de manera adecuada.
Fase 3: Migración de la lógica empresarial
Una vez que haya analizado y clasificado su lógica empresarial, es el momento de migrarla. Existen dos enfoques a la hora de migrar la lógica empresarial desde una base de datos monolítica: mover la lógica de la base de datos a la capa de aplicación o mover la lógica empresarial a otra base de datos que forme parte del microservicio.
Si migra la lógica empresarial a la aplicación, las tablas de la base de datos almacenan solo los datos y la base de datos no contiene ninguna lógica empresarial. Este es el enfoque recomendado. Puede usar Ispirer
Si migra la lógica empresarial a otra base de datos, puede utilizar AWS Schema Conversion Tool (AWS SCT) para convertir los esquemas de bases de datos y los objetos de código existentes en la base de datos de destino. Es compatible con servicios de AWS bases de datos diseñados específicamente, como Amazon DynamoDB, AmazonAurora y Amazon Redshift. Al proporcionar un informe de evaluación integral y capacidades de conversión automatizadas, AWS SCT ayuda a agilizar el proceso de transición y le permite centrarse en optimizar la nueva estructura de su base de datos para mejorar el rendimiento y la escalabilidad. A medida que avance en su proyecto de modernización, AWS SCT podrá gestionar las conversiones incrementales para adoptar un enfoque gradual, lo que le permitirá validar y ajustar cada paso de la transformación de su base de datos.
Estrategia de reversión de la lógica empresarial
Dos aspectos fundamentales de cualquier estrategia de descomposición son mantener la compatibilidad con versiones anteriores e implementar procedimientos integrales de reversión. Estos elementos funcionan en conjunto para ayudar a proteger las operaciones durante el período de transición. En esta sección se describe cómo gestionar la compatibilidad durante el proceso de descomposición y establecer capacidades eficaces de reducción de emisiones en caso de emergencia que eviten posibles problemas.
Mantenga la compatibilidad con versiones anteriores
Durante la descomposición de la base de datos, es esencial mantener la compatibilidad con versiones anteriores para que las transiciones sean fluidas. Mantenga los procedimientos de bases de datos existentes de forma temporal e implemente gradualmente las nuevas funcionalidades. Utilice el control de versiones para realizar un seguimiento de todos los cambios y gestionar varias versiones de la base de datos simultáneamente. Planifique un período de coexistencia prolongado en el que tanto el sistema de origen como el de destino deban funcionar de forma fiable. Esto proporciona tiempo para probar y validar el nuevo sistema antes de retirar los componentes antiguos. Este enfoque minimiza las interrupciones de la actividad empresarial y proporciona una red de seguridad que se puede revertir en caso necesario.
Plan de reversión de emergencia
Una estrategia integral de reversión es esencial para una descomposición segura de la base de datos. Implemente indicadores de características en su código para controlar qué versión de la lógica empresarial está activa. Esto le permite cambiar instantáneamente entre las implementaciones nuevas y originales sin cambios en la implementación. Este enfoque proporciona un control detallado de la transición y le ayuda a revertirla rápidamente en caso de que surjan problemas. Mantenga la lógica original como una copia de seguridad verificada y mantenga procedimientos de reversión detallados que especifiquen los factores desencadenantes, las responsabilidades y los pasos de recuperación.
Pruebe periódicamente estos escenarios de reversión en diversas condiciones para validar su eficacia y asegúrese de que los equipos estén familiarizados con los procedimientos de emergencia. Los indicadores de características también permiten la implementación gradual al habilitar nuevas funciones de forma selectiva para transacciones o grupos de usuarios específicos. Esto proporciona un nivel adicional de mitigación de riesgos durante la transición.
