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.
Contrôle de l'accès à l'aide du modèle de service d'encapsulation de base de données
Un service wrapper est une couche de service qui sert de façade à la base de données. Cette approche est particulièrement utile lorsque vous devez conserver les fonctionnalités existantes tout en préparant une future décomposition. Ce schéma suit un principe simple : lorsque quelque chose est trop salissant, commencez par le contenir. Le service wrapper devient le seul moyen autorisé d'accéder à la base de données, fournissant une interface contrôlée tout en masquant la complexité sous-jacente.
Utilisez ce modèle lorsque la décomposition immédiate de la base de données n'est pas possible en raison de schémas complexes ou lorsque plusieurs services nécessitent un accès continu aux données. Il est particulièrement utile pendant les périodes de transition, car il permet de procéder à une refactorisation minutieuse tout en préservant la stabilité du système. Ce modèle fonctionne bien lors de la consolidation de la propriété des données entre les mains d'équipes spécifiques ou lorsque les nouvelles applications nécessitent des vues agrégées sur plusieurs tables.
Par exemple, appliquez ce modèle lorsque :
-
La complexité du schéma empêche une séparation immédiate
-
Plusieurs équipes ont besoin d'un accès permanent aux données
-
Une modernisation progressive est préférable
-
La restructuration de l'équipe nécessite une propriété claire des données
-
Les nouvelles applications ont besoin de vues de données consolidées
Avantages et limites du modèle de service d'encapsulation de base de données
Les avantages du modèle d'enveloppe de base de données sont les suivants :
-
Croissance contrôlée — Le service wrapper empêche d'autres ajouts incontrôlés au schéma de base de données.
-
Limites claires — Le processus de mise en œuvre vous aide à établir des limites claires en matière de propriété et de responsabilité.
-
Liberté de refactorisation — Un service d'emballage vous permet d'apporter des modifications internes sans affecter les consommateurs.
-
Observabilité améliorée — Un service d'encapsulation est un point unique de surveillance et de journalisation.
-
Tests simplifiés — Un service d'encapsulation permet aux utilisateurs de services de créer plus facilement des versions fictives simplifiées à des fins de test.
Les limites du modèle d'enveloppe de base de données sont les suivantes.
-
Couplage technologique — Un service d'encapsulation fonctionne mieux lorsqu'il utilise la même pile technologique que les services consommateurs.
-
Frais généraux initiaux — Le service d'encapsulation nécessite une infrastructure supplémentaire susceptible d'affecter les performances.
-
Effort de migration — Pour mettre en œuvre le service d'encapsulation, vous devez coordonner l'ensemble des équipes afin de passer à l'abandon de l'accès direct.
-
Performances — Si le service d'encapsulage est soumis à un trafic élevé, à une utilisation intensive ou à un accès fréquent, les services consommateurs risquent de connaître des performances médiocres. En plus de la base de données, le service wrapper doit gérer la pagination, les curseurs et les connexions à la base de données. Selon votre cas d'utilisation, il se peut qu'il ne soit pas bien évolutif et qu'il ne soit pas adapté aux charges de travail d'extraction, de transformation et de chargement (ETL).
Implémentation du modèle de service d'encapsulation de base de données
La mise en œuvre du modèle de service d'encapsulation de base de données comporte deux phases. Vous devez d'abord créer le service d'encapsulation de base de données. Ensuite, vous dirigez tous les accès par son intermédiaire et vous documentez les modèles d'accès.
Phase 1 : Création du service d'encapsulation de base de données
Créez une couche de service légère qui agit comme un gardien d'accès à votre base de données. Dans un premier temps, il devrait refléter toutes les fonctionnalités existantes. Ce service wrapper devient le point d'accès obligatoire pour toutes les opérations de base de données, ce qui convertit les dépendances directes de la base de données en dépendances au niveau du service. Mettez en œuvre une journalisation et une surveillance détaillées au niveau de cette couche pour suivre les modèles d'utilisation, les indicateurs de performance et les fréquences d'accès. Conservez vos procédures stockées existantes, mais assurez-vous qu'elles ne sont accessibles que via cette nouvelle interface de service.
Phase 2 : Mise en œuvre du contrôle d'accès
Redirigez systématiquement tous les accès à la base de données via le service wrapper, puis révoquez les autorisations directes de base de données des systèmes externes qui accèdent directement à la base de données. Documentez chaque modèle d'accès et chaque dépendance au fur et à mesure que les services sont migrés. Cet accès contrôlé permet de refactoriser en interne les composants de la base de données sans perturber les consommateurs externes. Par exemple, commencez par des opérations en lecture seule à faible risque plutôt que par des flux de travail transactionnels complexes.
Phase 3 : surveillance des performances de la base de données
Utilisez le service Wrapper comme point de surveillance centralisé pour les performances de la base de données. Suivez les indicateurs clés, notamment les temps de réponse aux requêtes, les modèles d'utilisation, les taux d'erreur et l'utilisation des ressources. Configurez des alertes pour les seuils de performance et les modèles inhabituels. Par exemple, surveillez les requêtes lentes, l'utilisation du pool de connexions et le débit des transactions pour identifier de manière proactive les problèmes potentiels.
Utilisez cette vue consolidée pour optimiser les performances de la base de données grâce au réglage des requêtes, aux ajustements de l'allocation des ressources et à l'analyse des modèles d'utilisation. La nature centralisée du service d'emballage facilite la mise en œuvre des améliorations et la validation de leur impact auprès de tous les consommateurs, tout en maintenant des normes de performance cohérentes.
Bonnes pratiques pour la mise en œuvre d'un service d'encapsulation de base de données
Les meilleures pratiques suivantes peuvent vous aider à implémenter un service d'encapsulation de base de données :
-
Commencez modestement : commencez par un wrapper minimal qui se contente de reproduire les fonctionnalités existantes
-
Maintien de la stabilité : maintien de la stabilité de l'interface de service tout en apportant des améliorations internes
-
Surveiller l'utilisation : mettre en œuvre une surveillance complète pour comprendre les modèles d'accès
-
Responsabilité claire — Désignez une équipe dédiée chargée de maintenir à la fois le wrapper et le schéma sous-jacent
-
Encourager le stockage local — Motivez les équipes à stocker leurs données dans leurs propres bases de données
Exemple basé sur un scénario
Cette section décrit un exemple de la façon dont une société fictive, nommée AnyCompany Books, pourrait utiliser le modèle d'encapsulation de base de données pour contrôler l'accès à son système de base de données monolithique. Chez AnyCompany Books, il existe trois services essentiels : l'expédition, les finances et le traitement des commandes. Ces services partagent l'accès à une base de données centrale. Chaque service est géré par une équipe différente. Au fil du temps, ils modifient indépendamment le schéma de base de données pour répondre à leurs besoins spécifiques. Cela a conduit à un enchevêtrement de dépendances et à une structure de base de données de plus en plus complexe.
L'architecte d'application ou d'entreprise de l'entreprise reconnaît la nécessité de décomposer cette base de données monolithique. Leur objectif est de doter chaque service de sa propre base de données dédiée afin d'améliorer la maintenabilité et de réduire les dépendances entre les équipes. Cependant, elles sont confrontées à un défi de taille : il est presque impossible de décomposer la base de données alors que les trois équipes continuent de la modifier activement pour leurs projets en cours. Les changements constants de schéma et le manque de coordination entre les équipes font qu'il est extrêmement risqué de tenter une restructuration significative.
L'architecte utilise le modèle de service d'encapsulation de base de données pour commencer à contrôler l'accès à la base de données monolithique. Tout d'abord, ils ont configuré le service d'encapsulation de base de données pour un module particulier, appelé service Order. Ensuite, ils redirigent le service de traitement des commandes pour accéder au service wrapper au lieu d'accéder directement à la base de données. L'image suivante montre l'infrastructure modifiée.
