Les microservices sont un moyen de diviser une grande application en modules faiblement couplés qui communiquent entre eux via une simple API.
Dernièrement, seuls les imbéciles n'ont pas parlé de microservices. Cela devient de plus en plus populaire. Le style architectural modulaire semble particulièrement bien adapté aux environnements basés sur le cloud et gagne en popularité. Avant d’entrer dans les détails, regardons tout à vol d’oiseau . Par conséquent : Les microservices sont un moyen de diviser un grand projet en petits modules indépendants et faiblement couplés. Les modules indépendants sont responsables de tâches clairement définies et discrètes et communiquent entre eux via une API simple et accessible. En d’autres termes, les microservices constituent simplement un style architectural différent pour la conception d’applications complexes, principalement Web. Mais qu'y a-t-il de si mauvais dans les solutions architecturales existantes telles que SOA (architecture orientée services) ? La plupart des solutions d'entreprise modernes écrites à l'aide de SOA semblent fonctionner plutôt bien. C'est peut-être le moment idéal pour parler de certains des défis auxquels l'industrie est confrontée ces jours-ci... Commençons par un exemple simple. Disons que je dois exécuter une application classique écrite en Java. Je développerai d'abord l'interface utilisateur, puis la couche de logique métier, avec plusieurs composants qui interagiront avec l'UI, et enfin la couche base de données, qui sera accessible à la base de données persistante. Maintenant, selon le fait que je souhaite exécuter l'application, je vais créer un WAR/EAR/JAR et le monter sur un serveur (comme JBoss, Tomcat ou WebLogic). Comme cela se fait tout en un, j'obtiens une application monolithique, ce qui signifie que tous les composants sont au même endroit... Exemple dans l'image :
Très probablement, vous connaissez déjà cette approche et l'avez utilisée, mais l'idée est d'utiliser cet exemple pour montrer à quels défis les développeurs devront faire face en utilisant cette solution architecturale. Application monolithique : défis défis
À mesure que l'application grandit, la quantité de code écrit augmente également, ce qui risque de surcharger l'environnement de développement à chaque fois que vous devez l'ouvrir. Cela réduit définitivement l'efficacité du développeur.
Étant donné que tout doit être monté au même endroit, cela conduit au fait que le passage à un autre langage de programmation ou à d'autres technologies est un gros problème. Par exemple, vous avez écrit une application en Java, et après un certain temps, Kotlin est sorti et vous aviez hâte de la réécrire, car elle était présentée comme plus cool, meilleure et plus rapide. Avec une application monolithique, même penser à une refactorisation entraînera de réelles difficultés, sans parler du processus lui-même. Il existe actuellement de nombreuses applications réalisées de cette manière et le nombre de lignes de code est tout simplement incroyable.
Si l’un des composants cesse de fonctionner pour une raison quelconque , l’ensemble de l’application plantera également. Imaginez simplement qu'il existe une application Web comportant des modules tels que l'autorisation, le paiement, l'historique, etc. Et pour une raison quelconque, l'un d'eux se brise. C'est tout simplement un choc pour les entreprises et, par conséquent, pour les développeurs.
La mise à l'échelle d'une application monolithique ne peut être réalisée qu'en développant une autre application du même type. Mais que se passe-t-il si vous n’avez besoin de mettre à l’échelle qu’un seul composant, et non l’ensemble de l’application. Combien de ressources seront gaspillées ?...
Cela peut avoir un impact important sur le processus de développement et le processus d’installation de l’application. Plus l'application est volumineuse, plus il est important que les développeurs puissent la diviser en parties de travail plus petites. Étant donné que tous les modules d'une application monolithique sont connectés les uns aux autres, les développeurs ne peuvent pas travailler/monter ces modules indépendamment les uns des autres. Puisque les développeurs dépendent les uns des autres, le temps de développement augmente.
Dans le même temps, nous sommes prêts à réfléchir et à comprendre la signification des microservices, à savoir comment ils peuvent être utilisés pour restaurer la flexibilité perdue avec le style SOA. Dieu Les microservices à la rescousse L'une des caractéristiques les plus importantes de toute solution architecturale est l'évolutivité. Alors que j'apprenais les microservices pour la première fois, j'ai vu que tout ressemblait tellement aux citations du livre « The Art of Scalability ». C’est un excellent début et un excellent lieu de discussion. Cet ouvrage définit le modèle dit « Scalability Cube », qui décrit un système de scalabilité tridimensionnelle :
Comme vous pouvez le voir, l'axe X décrit la « mise à l'échelle horizontale » (qui, comme nous l'avons vu, est également disponible pour les architectures monolithiques), l'axe Y représente la mise à l'échelle dans le sens de séparer les différents composants de service . L'idée de l'axe Z est comprise lorsque les données sont divisées et que l'application envoie des requêtes exactement là où se trouvent les données. Autrement dit, ils ne sont pas tous au même endroit. L’idée de l’axe Y est celle sur laquelle nous nous concentrerons plus en détail. Cet axe représente une décomposition fonctionnelle . Dans cette stratégie, différentes fonctions peuvent être considérées comme des services indépendants. Par conséquent, en montant l'intégralité de l'application uniquement lorsque tout est terminé, les développeurs peuvent monter des services individuels indépendamment les uns des autres et ne pas attendre que les autres aient fini de travailler sur leurs modules. Cela permettra non seulement d'améliorer le temps de développement, mais offrira également la flexibilité de modifier et de recâbler sans avoir à se soucier du reste des composants de l'application. Comparons ce schéma avec le précédent monolithique :
Microservices : avantages Les avantages des microservices semblent tout à fait suffisants pour convaincre les développeurs d'entreprise tels qu'Amazon, Netflix, Ebay de commencer à utiliser cette approche. Contrairement aux applications architecturales monolithiques, les microservices :
Améliore l'isolation des pannes de composants : les applications volumineuses peuvent continuer à s'exécuter efficacement même en cas de panne d'un seul module.
Élimine l'engagement de l'application envers une seule pile technologique : si vous souhaitez essayer une nouvelle pile technologique sur un service, allez-y. Les dépendances seront beaucoup plus légères qu'avec une dépendance monolithique, et il sera également beaucoup plus facile de tout restaurer. Moins il y a de code dans une application, plus il est facile de travailler.
Permet aux nouveaux employés de comprendre beaucoup plus facilement les fonctionnalités du service.
Microservices : fonctionnalités de montage et de virtualisation Nous comprenons maintenant ce que sont les microservices. Et le plus grand avantage est qu'il est monté par plus d'une archive WAR/EAR/JAR. Mais comment s’installe-t-il ? La meilleure façon de monter des microservices dans des conteneurs. Un conteneur est un système d'exploitation virtuel entièrement configuré avec l'environnement nécessaire configuré, ce qui permet d'isoler l'accès aux ressources du système matériel sur lequel le conteneur est installé. La solution la plus connue du marché est bien entendu Docker . Les machines virtuelles IaaS (infrastructure as a service) telles qu'AWS peuvent également fonctionner correctement pour le montage de microservices, mais les microservices relativement légers peuvent ne pas utiliser toutes les ressources présentes dans la machine virtuelle, ce qui peut réduire la rentabilité de leur utilisation. Vous pouvez également monter vos microservices à l’aide du package OSGI (Open Service Gateway Initiative). Dans ce cas, tous les microservices fonctionneront dans une seule JVM, mais cela implique des problèmes de compromis entre contrôle et isolation. Microservices : inconvénients Ce n’est pas parce que « tout cela est cool » et « nous n’avons jamais vu cela auparavant » qu’il n’y a pas d’inconvénients. Vous trouverez ci-dessous une liste des domaines problématiques possibles que l’architecture des microservices entraîne :
Développer des systèmes distribués peut être difficile. J'entends par là que tous les composants sont désormais des services indépendants - vous devez gérer très soigneusement les requêtes transmises entre les modules. Il peut arriver qu'un module ne réponde pas, vous obligeant à écrire du code supplémentaire pour éviter de planter le système. Cela peut être plus difficile si les appels à distance sont sensibles à la latence .
Plusieurs bases de données et gestion des transactions peuvent être très pénibles.
tester les applications de microservices peut être fastidieux. En utilisant une application monolithique, il suffit d'exécuter l'archive WAR/EAR/JAR sur le serveur et de s'assurer qu'elle est connectée à la base de données. Et dans les microservices, chaque service individuel doit être démarré avant que les tests puissent commencer.
Les applications de montage peuvent être délicates. Ils peuvent nécessiter une coordination autour de plusieurs services qui ne sont peut-être pas aussi faciles à monter qu'un conteneur WAR.
.... Bien entendu, avec les bons outils et approches, ces inconvénients peuvent être évités. Mais ils ont eux-mêmes besoin de soutien et ne résolvent pas complètement tous les problèmes. L'article a été traduit du site Web CloudAcademy . Traduction gratuite. Chacun est libre d'exprimer toutes ses réflexions dans les commentaires. Ils seront certainement lus. Article original Mon compte Github
GO TO FULL VERSION