Architecture pour une application décentralisée distribuée

Question

Nous maintenons une application de planification qui est déployée sur plusieurs sites physiquement séparés. Les sites utilisent une réplication multimaître (utilisant Oracle 10g DB), ce qui signifie qu'il n'y a pas de site central (système décentralisé). Cependant, au fur et à mesure que le nombre de sites augmente, nos malheurs se multiplient: davantage de conflits qui devraient être résolus manuellement.

Nous allons ré-implémenter l'application, et aimerions envisager des alternatives à cette architecture.

Les données qui sont partagées entre les sites est de 2 saveurs:

• Cartes (données Append uniquement, stockées sous forme de fichiers de métadonnées dans le DB.)
• plans et des données connexes (stockées sous forme relationnelle données dans la base de données)

Toutes les données doivent être présentes dans tous les sites, mais il n'est pas essentiel qu'elles soient disponibles instantanément.

Les sites doivent pouvoir fonctionner même lorsqu'ils sont déconnectés du réseau.

Toute aide serait appréciée.

Answer 1

Les meilleures architectures sont celles qui s'intègrent de manière appropriée dans le contexte du problème: quels sont les pilotes qui définissent en fin de compte à quoi ressemblent la meilleure architecture et la meilleure solution? Par exemple (en reprenant le point Yuriys): vos problèmes peuvent être liés aux performances et/ou à la gestion des données - les deux nécessitent une adresse mais il est peu probable que vous ayez une solution qui s'adresse aux deux, elles peuvent même être contradictoires.

En termes de gestion de données, je suggère que vous ayez besoin d'avoir une copie maîtresse des données qui est "vérité". Mais cela pourrait ne pas être si bon pour la performance - bien sûr, cela dépend de l'approche. En termes de détails: Je commencerais par les données: modélisez-le, assurez-vous de le comprendre, de comprendre les flux de données actuels et leur relation avec les processus métier. Vous voulez arriver au point où vous pouvez dire «nous le faisons parce que le processus d'affaires l'exige légitimement» et «nous le faisons en raison d'une limitation technique que nous ne devrions pas avoir».

Dans un sens général, vous devez:

1. Prenez le contexte de votre problème en entrée.
2. Cela aidera à façonner votre critères de notation (c'est ainsi que vous évaluerez les idées que vous proposerez).
3. Définir options de solution de niveau haut initial/instructions. Ce sont des discussions à ciel ouvert qui peuvent être relativement libres de toute contrainte: pensez grand, sortez des sentiers battus. Le point critique est de ne pas commencer à penser en termes de mise en œuvre - ou même de technologies spécifiques. Vous pouvez également mettre les contraintes métier à l'écart: "nous le faisons parce que le processus métier actuel est X, si nous avons fait Y (en utilisant cette nouvelle technologie) nous pourrions alors faire Z et réduire les coûts opérationnels".
4. Revoyez et marquez par rapport à vos critères de notation.
5. Poursuivre options logiques: prendre fondamentalement la sortie de 3 & 4 et les prendre au prochain niveau. Vous voudrez peut-être commencer à réfléchir aux modèles d'entreprise/conception à ce stade.
6. examen et le score ceux-ci contre vos critères de notation
7. Poursuis options de mise en œuvre: vous avez besoin d'un composant à faire « X »: vous réutilisez, acheter ou construire? Y a-t-il les meilleurs outils de race que vous pouvez utiliser? Sont-ils compatibles avec votre infrastructure actuelle? Etc.
8. Revoyez et marquez par rapport à vos critères de notation.
9. Enregistre résultat (les raisons pour lesquelles) dans un registre de décisions architecturales pour référence future; cela devrait/doit inclure les entrées et les sorties des étapes précédentes. L'idée ici est d'empêcher les gens qui viennent après vous de faire tout ce travail à nouveau - ou d'écraser aveuglément votre décision bien réfléchie avec une mauvaise.

Mise à jour: Specifics

• Vous utilisez la réplication "Multi-Master" - Qu'en est maître-esclave?
• Vous utilisez la réplication de base de données. Qu'en est-il d'une solution non centrée sur la base de données?
• Recherchez les modèles de conception spécifiques aux systèmes de données et/ou distribués; Data Patterns semble être un bon début (je ne l'ai pas lu moi-même, et peut-être qu'Oracle propose-t-il un matériel similaire qui pourrait être plus adapté aux spécificités de votre plate-forme).
• Si les sites sont hors ligne, pouvez-vous verrouiller certaines tables/données de façon à ce qu'elles ne puissent plus être modifiées avant d'être mises en ligne?
• Utilisez une approche de contrôle à la source «check-out» pour vous assurer que les changements de données sont bien contrôlés. Jetez un oeil à différentes approches de mise en cache, qui pourraient vous donner quelques idées utiles car le concept de base est de garder les locaux des copies de données pour un accès rapide - sans les laisser obsolètes. Jetez un coup d'œil aux architectures multi-locataires, car elles doivent souvent gérer la séparation des données de différentes manières et travailler dans des environnements distribués.

Oui, j'a fourni une réponse générale - mais l'information donnée était aussi assez général :)