Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Migration de la logique métier de la base de données vers la couche application
La migration de la logique métier des procédures, des déclencheurs et des fonctions stockés dans les bases de données vers les services de couche applicative est une étape essentielle de la décomposition des bases de données monolithiques. Cette transformation améliore l'autonomie des services, simplifie la maintenance et améliore l'évolutivité. Cette section fournit des conseils sur l'analyse de la logique de base de données, la planification de la stratégie de migration, puis la mise en œuvre de la transformation tout en maintenant la continuité des activités. Il traite également de l'établissement d'un plan de réduction efficace.
Cette section contient les rubriques suivantes :
Phase 1 : Analyse de la logique métier
Lorsque vous modernisez des bases de données monolithiques, vous devez d'abord effectuer une analyse complète de la logique de votre base de données existante. Cette phase se concentre sur trois catégories principales :
-
Les procédures stockées contiennent souvent des opérations commerciales critiques, notamment la logique de manipulation des données, les règles métier, les contrôles de validation et les calculs. En tant que composants essentiels de la logique métier de l'application, ils nécessitent une décomposition minutieuse. Par exemple, les procédures stockées d'une organisation financière peuvent gérer le calcul des intérêts, le rapprochement des comptes et les contrôles de conformité.
-
Les déclencheurs sont des composants clés de la base de données qui gèrent les pistes d'audit, la validation des données, les calculs et la cohérence entre les tables. Par exemple, une entreprise de vente au détail peut utiliser des déclencheurs pour gérer les mises à jour des stocks dans l'ensemble de son système de traitement des commandes, ce qui montre la complexité des opérations de base de données automatisées.
-
Les fonctions des bases de données gèrent principalement les transformations de données, les calculs et les opérations de recherche. Ils sont souvent intégrés dans de multiples procédures et applications. Par exemple, un établissement de santé peut utiliser des fonctions pour normaliser les données des patients ou rechercher des codes médicaux.
Chaque catégorie représente différents aspects de la logique métier intégrée dans la couche de base de données. Vous devez évaluer et planifier soigneusement chacune d'elles afin de les faire migrer vers la couche application.
Au cours de cette phase d'analyse, les clients sont généralement confrontés à trois défis importants. Tout d'abord, des dépendances complexes apparaissent par le biais d'appels de procédures imbriqués, de références entre schémas et de dépendances de données implicites. Ensuite, la gestion des transactions devient essentielle, en particulier lorsqu'il s'agit de transactions en plusieurs étapes et que l'on assure la cohérence des données entre les systèmes distribués. Troisièmement, les considérations relatives aux performances doivent être soigneusement évaluées, en particulier pour les opérations de traitement par lots, les mises à jour massives des données et les calculs en temps réel qui bénéficient actuellement de la proximité des données.
Pour relever efficacement ces défis, vous pouvez utiliser AWS Schema Conversion Tool (AWS SCT) pour l'analyse initiale, puis utiliser des outils détaillés de mappage des dépendances. Cette approche vous permet de comprendre l'étendue complète de la logique de votre base de données et de créer une stratégie de migration complète qui assure la continuité des activités pendant la décomposition.
En comprenant parfaitement ces composants et ces défis, vous pouvez mieux planifier votre parcours de modernisation et prendre des décisions éclairées quant aux éléments à prioriser lors de la migration vers une architecture basée sur les microservices.
Lorsque vous analysez les composants du code de base de données, créez une documentation complète pour chaque procédure stockée, déclencheur et fonction. Commencez par décrire clairement son objectif et ses fonctionnalités de base, y compris les règles métier qu'il met en œuvre. Détaillez tous les paramètres d'entrée et de sortie, et notez leurs types de données et leurs plages valides. Cartographiez les dépendances vis-à-vis d'autres objets de base de données, de systèmes externes et de processus en aval. Définissez clairement les limites des transactions et les exigences d'isolation afin de préserver l'intégrité des données. Documentez toutes les attentes en matière de performance, y compris les exigences en matière de temps de réponse et les modèles d'utilisation des ressources. Enfin, analysez les modèles d'utilisation pour comprendre les pics de charge, la fréquence d'exécution et les périodes commerciales critiques.
Phase 2 : Classification de la logique métier
Une décomposition efficace des bases de données nécessite une catégorisation systématique de la logique de base de données selon des dimensions clés : complexité, impact commercial, dépendances, modèles d'utilisation et difficulté de migration. Cette classification vous aide à identifier les composants à haut risque, à déterminer les exigences de test et à établir les priorités de migration. Par exemple, les procédures stockées complexes ayant un impact commercial important et une utilisation fréquente nécessitent une planification minutieuse et des tests approfondis. Cependant, des fonctions simples, rarement utilisées avec des dépendances minimales peuvent convenir aux premières phases de migration.
Cette approche structurée crée une feuille de route de migration équilibrée qui minimise les interruptions d'activité tout en préservant la stabilité du système. En comprenant ces interrelations, vous pouvez améliorer la séquence de vos efforts de décomposition et allouer les ressources de manière appropriée.
Phase 3 : Migration de la logique métier
Après avoir analysé et classé votre logique métier, il est temps de la migrer. Il existe deux approches lors de la migration de la logique métier depuis une base de données monolithique : déplacer la logique de base de données vers la couche application ou déplacer la logique métier vers une autre base de données faisant partie du microservice.
Si vous migrez la logique métier vers l'application, les tables de base de données stockent uniquement les données et la base de données ne contient aucune logique métier. Il s'agit de l'approche recommandée. Vous pouvez utiliser Ispirer
Si vous migrez la logique métier vers une autre base de données, vous pouvez utiliser AWS Schema Conversion Tool (AWS SCT) pour convertir les schémas de base de données et les objets de code existants vers votre base de données cible. Il prend en charge des services de AWS base de données spécialement conçus, tels qu'Amazon DynamoDB, Amazon Aurora et Amazon Redshift. En fournissant un rapport d'évaluation complet et des fonctionnalités de conversion automatisées, AWS SCT cela permet de rationaliser le processus de transition, ce qui vous permet de vous concentrer sur l'optimisation de votre nouvelle structure de base de données pour améliorer les performances et l'évolutivité. Au fur et à mesure que vous progressez dans votre projet de modernisation, vous AWS SCT pouvez gérer des conversions incrémentielles afin de soutenir une approche progressive, vous permettant de valider et d'affiner chaque étape de la transformation de votre base de données.
Stratégie de rétrogradation pour la logique métier
Deux aspects essentiels de toute stratégie de décomposition sont le maintien de la rétrocompatibilité et la mise en œuvre de procédures de restauration complètes. Ces éléments fonctionnent ensemble pour aider à protéger les opérations pendant la période de transition. Cette section décrit comment gérer la compatibilité pendant le processus de décomposition et établir des capacités de restauration d'urgence efficaces qui protègent contre les problèmes potentiels.
Maintenir la rétrocompatibilité
Lors de la décomposition de la base de données, le maintien de la rétrocompatibilité est essentiel pour des transitions fluides. Maintenez les procédures de base de données existantes temporairement en place tout en implémentant progressivement de nouvelles fonctionnalités. Utilisez le contrôle de version pour suivre toutes les modifications et gérer simultanément plusieurs versions de base de données. Prévoyez une période de coexistence prolongée pendant laquelle les systèmes source et cible doivent fonctionner de manière fiable. Cela laisse le temps de tester et de valider le nouveau système avant de retirer les composants existants. Cette approche minimise les interruptions d'activité et fournit un filet de sécurité permettant de revenir en arrière si nécessaire.
Plan de réduction d'urgence
Une stratégie de restauration complète est essentielle pour une décomposition sûre des bases de données. Implémentez des indicateurs de fonctionnalité dans votre code pour contrôler quelle version de la logique métier est active. Cela vous permet de basculer instantanément entre les nouvelles implémentations et les implémentations d'origine sans modifier le déploiement. Cette approche permet un contrôle précis de la transition et vous aide à revenir en arrière rapidement en cas de problème. Conservez la logique d'origine sous forme de sauvegarde vérifiée et maintenez des procédures de restauration détaillées qui spécifient les déclencheurs, les responsabilités et les étapes de restauration.
Testez régulièrement ces scénarios de réduction dans différentes conditions pour valider leur efficacité et assurez-vous que les équipes connaissent bien les procédures d'urgence. Les indicateurs de fonctionnalité permettent également des déploiements progressifs en activant de manière sélective de nouvelles fonctionnalités pour des groupes d'utilisateurs ou des transactions spécifiques. Cela fournit un niveau supplémentaire d'atténuation des risques pendant la transition.
