Qu'est-ce qu'un microservice?
Microservice pour ceci, microservice pour cela, mais expliquer à une personne simple ce qu'est le microservice? Je suis un simple programmeur avec un peu de formation théorique. Mais je n'ai pas besoin d'un terme microservice pour faire ce que je fais. Quelqu'un pourrait-il m'expliquer en termes simples et paysans ce qu'est le microservice? Amazon AWS = microservice?
J'ai lu ceci: https://en.wikipedia.org/wiki/Microservices mais apparemment je suis trop stupide pour comprendre ce que c'est.
Microservices dans mes propres termes, je l'espère simples
Monolithes
Traditionnellement, les applications Web sont volumineuses. Vous écrivez un logiciel qui s'exécute sur un serveur et répond aux demandes sous forme de HTML, XML ou JSON. Si vous voulez que votre application Web fasse quelque chose de nouveau, vous ajoutez cette fonctionnalité à l'application existante. De tels grands systèmes sont appelés "monolithiques" (un monolithe est un très gros rocher).
Les monolithes sont problématiques, car ils augmentent généralement en taille et en complexité au fil du temps. C'est un problème lors du développement de quelque chose en équipe. Les développeurs ajoutent du nouveau code au système et ne peuvent pas modifier ou réutiliser le code existant, car il existe de nombreuses dépendances entre les éléments de code. Ils ont également trop peur de supprimer l'ancien code car il pourrait être utilisé quelque part.
Lors de la livraison de ce code aux clients, par exemple en le mettant sur Internet, nous appelons cela "déployer". Le déploiement et les tests habituels après le déploiement sont difficiles, car dans un grand système, il y a beaucoup de choses qui peuvent casser. Trouver ce qui ne va pas et qui devrait y remédier est très difficile et nécessite que les gens sachent tout.
Un autre inconvénient est l'évolutivité. Nous entendons par là "comment pouvons-nous servir plus d'utilisateurs en même temps?" Un ordinateur serveur Web unique ne peut gérer qu'un certain nombre d'utilisateurs y accédant en parallèle. La mise à niveau de cet ordinateur vers un meilleur matériel le rend plus utile aux utilisateurs, mais vous allez bientôt dépasser les limites de ce qui est possible avec le matériel. Cette mise à niveau est appelée mise à l'échelle verticale. Nous pourrions également mettre notre application Web sur deux serveurs ou plus, afin de pouvoir gérer plus d'utilisateurs. C'est ce qu'on appelle la mise à l'échelle horizontale. Les applications monolithiques sont traditionnellement faites uniquement avec une mise à l'échelle verticale à l'esprit.
Microservices
Afin de simplifier le flux de travail avec de grandes applications, nous pouvons le diviser en parties plus petites. Chaque partie sert un objectif particulier. Nous appelons cela un "service (Web)". Ces services Web sont très flexibles à utiliser. Vous pouvez les utiliser à partir de votre application monolithique existante, soit dans la partie serveur, soit dans la partie client. Vous pouvez également disposer d'un service Web qui utilise d'autres services Web.
La division en services Web uniques vous permet de coupler librement votre application. Cela signifie qu'en tant qu'utilisateur du service, vous ne dépendez que de la disponibilité, de la disponibilité et du fonctionnement du service. Vous n'avez plus besoin de vous occuper de ses dépendances, de sa compilation, de son déploiement ou de ses tests.
Vous pouvez confier cette responsabilité à un développeur ou une équipe différent. Vous ne pouvez pas interrompre leur service Web car vous n'y accédez pas via le code source. Ils peuvent même utiliser un langage de programmation différent et vous pouvez toujours utiliser leur service.
Cette indépendance est rendue possible en décidant d'utiliser un format commun et commun protocoles (un protocole est un moyen de communication). Pour les services Web, les formats les plus courants sont JSON et XML . Le protocole le plus utilisé est HTTP , car il est simple, bien pris en charge par tous les logiciels existants et votre navigateur l'utilise également.
Le mot "micro" dans "microservices" souligne simplement l'idée de rendre ces services Web aussi petits que possible. Si vous avez besoin d'un service plus complexe, il est généralement préférable de créer un nouveau service qui dépend d'un ou plusieurs autres.
Quand utiliser quoi?
Utilisez des microservices si:
- vous vous attendez à ce que beaucoup de gens travaillent sur le système à long terme (couplés de manière lâche)
- vous devez évoluer vers des millions d'utilisateurs simultanés (à l'échelle horizontale)
- vous avez besoin d'un système hautement disponible avec redondance (modularisé)
Les applications monolithiques ne sont pas à l'ancienne ou obsolètes! Ils présentent de nombreux avantages par rapport aux microservices dans certains scénarios. Utilisez-les lorsque:
- le système est développé par une seule personne ou une petite équipe (base de code unique)
- le système n'a pas besoin d'être super évolutif, par ex. il n'est utilisé que par des centaines ou des milliers de personnes au sein d'une entreprise ou d'un cercle limité de clients (à l'échelle verticale)
- vous avez besoin d'une architecture simple, facile à comprendre, à entretenir, à déployer et à surveiller (infrastructure simple)
Exemple d'un système construit avec des microservices
Disons que vous avez une application où les utilisateurs peuvent créer des cartes postales virtuelles.
Voici un schéma montrant les composants essentiels d'une telle application construite dans un style monolithique: 
(Le composant Interface utilisateur traverse la frontière du système, car dans la plupart des cas, nous utilisons un navigateur pour afficher le code HTML généré dans l'application.)
Voici comment une telle application pourrait être réalisée en utilisant une architecture de microservices: 
Notez comment chaque composant est autonome et n'est adressé qu'à partir de l'interface utilisateur.
En détail:
- Une page Web statique mince qui se compose uniquement de HTML, CSS et JavaScript
- Une microservice bibliothèque de cartes qui propose une liste de modèles de cartes, y compris leurs dimensions et leur intention.
- Un microservice thumbnailer qui, étant donné un nom de modèle de carte, vous offre un petit aperçu de la carte.
- Un rendu de microservice qui attend un modèle et le texte à remplir. Il rend ensuite une image de carte et la renvoie.
Comment ils sont câblés:
- La page Web contient les URL de la bibliothèque de cartes et du moteur de rendu. Le navigateur de l'utilisateur appelle ces services comme émis par le code JavaScript.
- La bibliothèque utilise la vignette pour renvoyer une liste de cartes, y compris leurs vignettes
- Lorsque l'utilisateur en a sélectionné un, le navigateur envoie ce modèle avec l'entrée utilisateur au moteur de rendu et le navigateur affiche l'image renvoyée.
Avec cette approche, vous vous retrouvez avec trois microservices et une interface graphique Web partagée. Vous pouvez donner chaque service à son propre développeur ou équipe, le tester indépendamment, déployer quand vous le souhaitez et même échanger contre quelque chose de complètement nouveau, le tout sans toucher aux autres services. En même temps, vous devrez vous assurer que les services sont tous compatibles les uns avec les autres, ce qui pourrait nécessiter un versionnage API, une découverte de service dynamique (par exemple, un service supplémentaire hautement disponible qui vous connecte à tous les autres services) et d'autres techniques plus avancées.
Notez que l'interface utilisateur partagée n'est qu'une approche (bien que la plus courante). Vous pouvez également avoir une interface utilisateur par service ou des services dédiés à la fourniture de différents frontaux pour les multiples services backend. Il y a aussi beaucoup de discussions et de différends sur les magasins de données (pensez aux bases de données, aux files d'attente, etc.) et à savoir s'ils doivent être utilisés par plusieurs services ou si chaque service devrait plutôt posséder ses données. C'est là que le paradigme est défini de façon assez vague.
Le bon mot pour microservice est un service de bonne taille. La portée et la taille du microservice doivent être basées sur les éléments suivants:
- SRP - Microservice devrait avoir une seule raison de changement. Il devrait faire une chose et bien le faire.
- Capacité commerciale - Elle doit représenter une capacité commerciale qui devrait être de nature relativement autonome et peut être exécutée par une équipe avec une interaction minimale avec d'autres capacités
- BC/UL Elle doit être basée sur BC et UL . Ce sont des concepts de DDD. Veuillez consulter le lien pour plus de détails.