Gestion de données décentralisée - Encapsulation de bases de données dans les microservices
J'ai récemment pris un cours sur la conception de logiciels et il y avait une récente discussion/recommandation concernant l'utilisation d'un modèle "Microservices" dans lequel les composants d'un service sont séparés dans des sous-composants de Microservice qui sont aussi indépendants que possible.
Une partie qui a été mentionnée était au lieu de suivre le modèle très souvent vu de disposer d'une seule base de données que toutes les microservices parlent, vous auriez une base de données distincte pour chacun des microservices.
Une meilleure explication formulée et plus détaillée de cela peut être trouvée ici: http://martinfowler.com/articles/microservices.html Sous la section Données de données décentralisées
la partie la plus saillante disant ceci:
Les microservices préfèrent laisser chaque service gérer sa propre base de données, soit des instances différentes de la même technologie de base de données, ou de systèmes de base de données entièrement différents - une approche appelée persistance de Polyglot. Vous pouvez utiliser Polyglot Persistence dans un monolithe, mais il semble plus fréquemment avec des microservices.
Figure 4
J'aime ce concept et, parmi d'autres choses, je vois que comme une forte amélioration de la maintenance et d'avoir des projets avec plusieurs personnes qui travaillent sur eux. Cela dit, je ne suis en aucun cas un architecte logiciel d'expérience. Quelqu'un a-t-il déjà essayé de le mettre en œuvre? Quels avantages et obstacles avez-vous rencontré?
Parlons des positifs et des négatifs de l'approche de microservice.
Premiers négatifs. Lorsque vous créez des microservices, vous ajoutez une complexité inhérente dans votre code. Vous ajoutez des frais généraux. Vous faites plus de difficulté à reproduire l'environnement (par exemple pour les développeurs). Vous faites du débogage de problèmes intermittents plus difficiles.
Laissez-moi illustrer un véritable inconvénient. Considérons hypothétiquement le cas où vous avez 100 microservices appelés tout en générant une page, chacun de chacun fait 99,9% du temps. Mais 0,05% du temps qu'ils produisent des résultats erronés. Et 0,05% du temps, il existe une demande de connexion lente où, par exemple, un délai d'attente TCP/IP est nécessaire pour se connecter et cela prend 5 secondes. Environ 90,5% du temps que votre demande fonctionne parfaitement. Mais environ 5% du temps que vous avez de mauvais résultats et environ 5% du temps, votre page est lente. Et chaque échec non reproductible a une cause différente.
Sauf si vous avez mis beaucoup de réflexion sur l'outillage pour la surveillance, reproduire, etc., cela va devenir un gâchis. Particulièrement lorsqu'un microservice appelle une autre qui appelle une autre couche de profondeur. Et une fois que vous avez des problèmes, cela ne s'aggravera que dans le temps.
Ok, cela ressemble à un cauchemar (et plus d'une entreprise a créé d'énormes problèmes pour eux-mêmes en descendant ce chemin). Le succès n'est possible que vous êtes clairement conscient de la réduction potentielle et de travailler systématiquement pour y remédier.
Alors qu'en est-il de cette approche monolithique?
Il s'avère qu'une application monolithique est tout aussi facile à modulariser que les microservices. Et un appel de fonction est à la fois moins cher et plus fiable en pratique qu'un appel RPC. Vous pouvez donc développer la même chose, sauf qu'il est plus fiable, fonctionne plus rapidement et implique moins de code.
OK, alors pourquoi les entreprises vont-elles à l'approche de Microservices?
La réponse est parce que lorsque vous échelle, il y a une limite à ce que vous pouvez faire avec une application monolithique. Après tant d'utilisateurs, tant de demandes, etc., vous atteignez un point où les bases de données ne sont pas échouées, les serveurs Webs ne peuvent pas conserver votre code en mémoire, etc. En outre, des approches de microservice permettent des mises à niveau indépendantes et incrémentielles de votre application. Par conséquent, une architecture de microservice est une solution pour réduire votre application.
Ma règle générale personnelle est que passer du code dans une langue de script (python) à optimiser C++ peut généralement améliorer 1-2 ordres de grandeur sur les performances et l'utilisation de la mémoire. Aller dans l'autre sens d'une architecture distribuée ajoute une ampleur aux exigences des ressources, mais vous permet de réduire indéfiniment. Vous pouvez faire un travail d'architecture distribué, mais cela est plus difficile.
Par conséquent, je dirais que si vous commencez un projet personnel, allez monolithique. Apprenez à le faire bien. Ne soyez pas distribué car (Google | eBay | Amazon | etc) sont. Si vous atterrissez dans une grande entreprise distribuée, prenez une attention particulière à la façon dont ils fonctionnent et ne le fassent pas. Et si vous vous entendez avoir à faire la transition, soyez très très prudent parce que vous faites quelque chose de difficile qui est facile à obtenir très, très faux.
Divulgation, j'ai près de 20 ans d'expérience dans les entreprises de toutes tailles. Et oui, j'ai vu des architectures monolithiques et distribuées de près et de personnels. Il est basé sur cette expérience que je vous dis que une architecture de microservice distribuée est vraiment quelque chose que vous faites parce que vous devez, et pas parce que c'est un peu plus propre et mieux.
Je suis tout à fait d'accord avec la réponse de Btilly, mais je voulais juste ajouter un autre positif aux microservices, que je pense être une inspiration originale derrière elle.
Dans un monde de Microservices, les services sont alignés sur des domaines et sont gérés par des équipes distinctes (une équipe peut gérer plusieurs services). Cela signifie que chaque équipe peut libérer des services entièrement séparément et indépendamment de tout autre service (en supposant des versions correctes, etc.).
Bien que cela puisse ressembler à un avantage trivial, considérez le contraire dans un monde monolithique. Ici, où une partie de l'application doit être mise à jour fréquemment, elle aura une incidence sur l'ensemble du projet et toutes les autres équipes qui y travaillent. Vous devrez alors introduire la planification, les avis, etc., etc., et l'ensemble du processus ralentit.
Donc, comme pour votre choix, ainsi que de considérer vos exigences d'échelle, considérez également les structures d'équipe requises. Je conviendrais avec la recommandation de Btilly que vous démarrez monolithique puis vous identifiez plus tard où des microservices pourraient devenir bénéfiques, mais sachez que l'évolutivité n'est pas la seule prestation.
J'ai travaillé à un endroit qui avait une bonne quantité de sources de données indépendantes. Ils les ont tous mis dans une seule base de données, mais dans différents schémas consultés par Webservices. L'idée était que chaque service ne pouvait accéder que la quantité minimale de données qu'ils avaient nécessaires pour effectuer leur travail.
Ce n'était pas beaucoup de surcharge comparé à une base de données monolithique, mais je suppose que c'était principalement due à la nature des données déjà dans des groupes isolés.
Les webservices ont été appelés à partir du code du serveur Web qui génèlait une page, c'est donc beaucoup comme votre architecture de Microservices, bien que cela ne soit pas aussi micro que le mot le suggère et non distribué, bien qu'ils auraient pu être (notez qu'un WS a appelé. Pour obtenir des données d'un service tiers, il y avait donc une instance d'un service de données distribuée). La Société qui a fait plus intéressée par la sécurité que la balance, cependant, ces services et les services de données fournissaient une surface d'attaque plus sécurisée en ce qu'une faille exploitable n'aurait pas permis d'accéder pleinement à l'ensemble du système.
Roger Sessions dans ses excellentes lettres d'information ObjectWatch a décrit quelque chose de similaire avec son concept de forteresses logiciels (malheureusement, les newsletters ne sont plus en ligne, mais vous pouvez acheter son livre).