J'ai récemment suivi un cours sur la conception de logiciels et il y a eu récemment une discussion / recommandation sur l'utilisation d'un modèle de `` microservices '' où les composants d'un service sont séparés en sous-composants de microservices 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 d'avoir une seule base de données à laquelle tous les microservices parlent, vous auriez une base de données distincte en cours d'exécution pour chacun des microservices.
Une explication plus claire et plus détaillée de ceci peut être trouvée ici: http://martinfowler.com/articles/microservices.html dans la section Gestion décentralisée des donné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 différentes instances de la même technologie de base de données, soit des systèmes de base de données entièrement différents - une approche appelée Polyglot Persistence. Vous pouvez utiliser la persistance polyglotte dans un monolithe, mais elle apparaît plus fréquemment avec les microservices.
Figure 4
J'aime ce concept et, entre autres choses, je vois cela comme une forte amélioration de la maintenance et des projets avec plusieurs personnes qui y travaillent. 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és?
la source
Réponses:
Parlons positifs et négatifs de l'approche microservice.
Premiers négatifs. Lorsque vous créez des microservices, vous ajoutez une complexité inhérente à votre code. Vous ajoutez des frais généraux. Vous compliquez la réplication de l'environnement (par exemple pour les développeurs). Vous rendez plus difficile le débogage de problèmes intermittents.
Permettez-moi d'illustrer un véritable inconvénient. Considérons hypothétiquement le cas où vous avez 100 microservices appelés lors de la génération d'une page, dont chacun fait la bonne chose 99,9% du temps. Mais 0,05% du temps, ils produisent des résultats erronés. Et 0,05% du temps, il y a une demande de connexion lente où, par exemple, un délai d'expiration TCP / IP est nécessaire pour se connecter et cela prend 5 secondes. Environ 90,5% du temps, votre demande fonctionne parfaitement. Mais environ 5% du temps, vous obtenez de mauvais résultats et environ 5% du temps, votre page est lente. Et chaque défaillance non reproductible a une cause différente.
À moins que vous ne réfléchissiez beaucoup aux outils de surveillance, de reproduction, etc., cela va devenir un gâchis. En particulier lorsqu'un microservice en appelle un autre qui en appelle un autre à quelques couches de profondeur. Et une fois que vous avez des problèmes, cela ne fera qu'empirer avec le temps.
OK, cela ressemble à un cauchemar (et plus d'une entreprise s'est créée d'énormes problèmes en s'engageant dans cette voie). Le succès n'est possible que si vous êtes clairement conscient des inconvénients potentiels et travaillez constamment 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'elle est plus fiable, s'exécute plus rapidement et implique moins de code.
OK, alors pourquoi les entreprises adoptent-elles l'approche des microservices?
La réponse est que lorsque vous évoluez, 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 s'adaptent pas, les serveurs Web ne peuvent pas conserver votre code en mémoire, etc. De plus, les approches de microservices permettent des mises à niveau indépendantes et incrémentielles de votre application. Par conséquent, une architecture de microservices est une solution pour faire évoluer votre application.
Ma règle d'or personnelle est que le passage du code dans un langage de script (par exemple Python) au C ++ optimisé peut généralement améliorer 1-2 ordres de grandeur sur les performances et l'utilisation de la mémoire. Dans l'autre sens, une architecture distribuée ajoute de l'ampleur aux besoins en ressources mais vous permet de vous adapter indéfiniment. Vous pouvez faire fonctionner une architecture distribuée, mais cela est plus difficile.
Je dirais donc que si vous démarrez un projet personnel, optez pour le monolithique. Apprenez à bien le faire. Ne soyez pas distribué car (Google | eBay | Amazon | etc) le sont. Si vous atterrissez dans une grande entreprise qui est distribuée, portez une attention particulière à la façon dont cela fonctionne et ne le gâchez pas. Et si vous finissez par devoir faire la transition, soyez très, très prudent parce que vous faites quelque chose de difficile qui est facile à très, très mal.
Divulgation, j'ai près de 20 ans d'expérience dans des entreprises de toutes tailles. Et oui, j'ai vu des architectures monolithiques et distribuées de près et personnelles. C'est sur la base de cette expérience que je vous dis qu'une architecture de microservices distribués est vraiment quelque chose que vous faites parce que vous en avez besoin, et non pas parce qu'elle est en quelque sorte plus propre et meilleure.
la source
Je suis entièrement d'accord avec la réponse de btilly, mais je voulais juste ajouter un autre point positif pour les microservices, qui, selon moi, est une inspiration originale.
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 publier des services entièrement séparément et indépendamment de tout autre service (en supposant un versionnement correct, etc.).
Bien que cela puisse sembler un avantage insignifiant, considérez le contraire dans un monde monolithique. Ici, où une partie de l'application doit être mise à jour fréquemment, cela aura un impact sur l'ensemble du projet et sur toutes les autres équipes qui y travaillent. Vous devrez ensuite introduire la planification, les révisions, etc., et l'ensemble du processus ralentit.
Pour ce qui est de votre choix, tout en tenant compte de vos exigences de mise à l'échelle, tenez également compte des structures d'équipe requises. Je suis d'accord avec la recommandation de btilly que vous commenciez Monolithic et que vous identifiiez plus tard où les microservices pourraient devenir bénéfiques, mais sachez que l'évolutivité n'est pas le seul avantage.
la source
J'ai travaillé dans un endroit qui avait une bonne quantité de sources de données indépendantes. Ils les ont tous regroupés dans une seule base de données, mais dans différents schémas accessibles par les services Web. L'idée était que chaque service ne pouvait accéder qu'à la quantité minimale de données dont il avait besoin pour effectuer son travail.
Ce n'était pas beaucoup de frais généraux par rapport à une base de données monolithique, mais je suppose que cela était principalement dû à la nature des données qui étaient déjà dans des groupes isolés.
Les services Web ont été appelés à partir du code du serveur Web qui a généré une page, donc cela ressemble beaucoup à votre architecture de microservices, bien que peut-être pas aussi micro que le mot le suggère et non distribué, bien qu'ils auraient pu l'être (notez qu'un WS a appelé pour obtenir des données d'un service tiers, il y avait donc 1 instance d'un service de données distribué). La société qui a fait cela était plus intéressée par la sécurité que par l'échelle, cependant, ces services et les services de données offraient une surface d'attaque plus sécurisée dans la mesure où une faille exploitable ne donnerait pas un accès complet à l'ensemble du système.
Roger Sessions dans ses excellentes newsletters Objectwatch a décrit quelque chose de similaire avec son concept Software Fortresses (malheureusement les newsletters ne sont plus en ligne, mais vous pouvez acheter son livre).
la source