Base de données bon point de découplage du système?

Question

Nous avons deux systèmes où le système A envoie des données à un système B. Il est nécessaire que chaque système peut fonctionner indépendamment de l'autre et ne va exploser si l'autre est en panne. La question est de savoir quelle est la meilleure façon pour le système A de communiquer avec le système B tout en respectant l'exigence de découplage.

Le système B dispose actuellement d'un processus qui interroge les données dans une table db et traite les nouvelles lignes qui ont été insérées.

Une conception proposée est que le système A insère simplement des données dans la table db du système b et que le système B traite les nouvelles lignes par le processus existant. La question est de savoir si cette solution répond à l'exigence de découpler les deux systèmes? Une base de données est-elle considérée comme faisant partie d'un système B qui pourrait devenir indisponible et faire exploser le système A?

Une autre solution consiste pour le système A à placer des données dans une file d'attente MQ et à avoir un processus qui serait lu par MQ puis inséré dans la base de données du système B. Mais est-ce juste des frais supplémentaires? En fin de compte, une file d'attente MQ est-elle plus tolérante aux pannes qu'une table db?

Answer 1

D'une manière générale, le partage de base de données est un couplage étroit et ne doit pas être préféré, sauf peut-être à des fins de rapidité. Non seulement pour des raisons de disponibilité, mais aussi parce que les systèmes A et B seront changés et améliorés à plusieurs endroits dans le futur, et devraient avoir des dépendances minimales - le passage de message est une dépendance évidente, alors que les bases de données partagées tendent à vous mordre vos héritiers) sur le postérieur quand moins attendu. Si vous allez sur la route de partage de base de données, au moins rendre l'interface de partage explicite avec des tables ou des vues dédiées.

Il existe quatre niveaux communs d'intégration:

1. Base de données de partage
2. Partage de fichiers
3. appel de procédure à distance
4. message passant

qui peut être appliqué et combiné à divers situations, avec une disponibilité et une maintenabilité différentes. Vous avez un excellent aperçu au enterprise integration patterns site.

Comme pour toute infrastructure d'intégration centrale, MQ doit être hébergé dans un environnement avec une grande disponibilité, un basculement total & c. Il existe d'autres solutions de file d'attente qui vous permettent de distribuer la coordination de file d'attente.

Answer 2

Utilisez Queues pour la communication. Ne «passez» pas les données du système A au système B via la base de données. Vous utilisez la base de données comme une file d'attente de messages géante, coûteuse et complexe.

Utiliser une file d'attente de message en tant que file d'attente de message.

Ce n'est pas en tête "Extra". C'est le meilleur moyen de découpler les systèmes. C'est ce qu'on appelle l'architecture orientée services (SOA) et l'utilisation de messages est absolument essentielle à la conception.

Un file d'attente MQ est beaucoup plus simple qu'une table DB. Ne comparez pas la "tolérance aux pannes", car un SGBDR utilise des surdébits énormes (presque inimaginables) pour obtenir un niveau d'assurance raisonnable que votre transaction s'est terminée correctement. Verrouillage. Buffering. Écrire des files d'attente. Gestion du stockage. Etc. Etc.

Une implémentation de file d'attente de messages fiable utilise une banque de sauvegarde pour conserver l'état de la file d'attente. Les frais généraux sont beaucoup, beaucoup moins qu'un SGBDR. La performance est bien meilleure. Et c'est beaucoup, beaucoup plus simple d'interagir avec.

Answer 3

Dans SQL Server, je le ferais via un package SSIS ou un travail (en fonction du nombre d'enregistrements et de la complexité de ce que je déplaçais). D'autres bases de données ont également des solutions ETL. J'aime la solution ETL parce que je peux garder des traces de ce qui a été changé et quelles erreurs ont été traitées, je peux envoyer des documents qui pour une raison quelconque ne vont pas à l'autre système (les structures de données sont rarement les mêmes) table sans tuer le reste du processus. Je peux aussi faire des changements dans les données pour ajuster les différences de base de données (comme les valeurs de table de recherche, disons que l'état complété dans db1 est 5 et 7 dans db2 ou disons que db2 a un champ obligatoire que db1 ne fait pas et ajouter une valeur par défaut au fichier s'il est nul). Si l'un ou l'autre des servers est inactif, le travail en cours d'exécution du paquet SSIS échouera et aucun des deux systèmes ne sera affecté. Les bases de données seront donc découplées car les triggers ou la réplication ne le seront pas.