Le 19 septembre à Moscou la première réunion thématique HUG (Highload++ User Group), dédiée aux microservices. Il y a eu une présentation « Exploitation de microservices : la taille compte, même si vous avez Kubernetes », dans laquelle nous avons partagé la vaste expérience de Flant dans l'exploitation de projets avec une architecture de microservices. Tout d’abord, il sera utile à tous les développeurs qui envisagent d’utiliser cette approche dans leur projet actuel ou futur.
Présentation (50 minutes, beaucoup plus informatif que l'article), ainsi que l'extrait principal de celui-ci sous forme de texte.
NB : La vidéo et la présentation sont également disponibles à la fin de ce post.
introduction
Habituellement, une bonne histoire a un début, une intrigue principale et une résolution. Ce rapport s’apparente davantage à un prélude, et qui plus est tragique. Il est également important de noter qu’il offre une vision extérieure des microservices. Exploitation.
Je commencerai par ce graphique dont l'auteur (en 2015) Martin Fowler :
Il montre comment, dans le cas d’une application monolithique atteignant une certaine valeur, la productivité commence à décliner. Les microservices sont différents en ce sens que leur productivité initiale est inférieure, mais à mesure que la complexité augmente, la dégradation de l'efficacité n'est pas si perceptible pour eux.
J'ajouterai à ce graphique pour le cas de l'utilisation de Kubernetes :
Pourquoi une application avec des microservices est-elle meilleure ? Parce qu'une telle architecture impose de sérieuses exigences à l'architecture, qui à leur tour sont parfaitement couvertes par les capacités de Kubernetes. D’un autre côté, certaines de ces fonctionnalités seront utiles pour un monolithe, notamment parce que le monolithe typique d’aujourd’hui n’est pas exactement un monolithe (les détails seront plus tard dans le rapport).
Comme vous pouvez le constater, le graphique final (lorsque les applications monolithiques et microservices sont dans l'infrastructure avec Kubernetes) n'est pas très différent de celui d'origine. Nous parlerons ensuite des applications exploitées à l'aide de Kubernetes.
Microservices utiles et nuisibles
Et voici l'idée principale :
Qu'est-ce qu'un normal architecture de microservices ? Cela devrait vous apporter de réels avantages, en augmentant votre efficacité au travail. Si on revient au graphique, le voici :
Si tu l'appelles utile, alors de l'autre côté du graphique il y aura nocif microservices (interfère avec le travail) :
Revenons à « l’idée principale » : dois-je faire confiance à mon expérience ? Depuis le début de cette année, j'ai regardé 85 projets. Tous n’étaient pas des microservices (environ un tiers à la moitié d’entre eux possédaient une telle architecture), mais cela reste un nombre important. Nous (société Flant), en tant qu'externalisateur, parvenons à voir une grande variété d'applications développées aussi bien dans les petites entreprises (avec 5 développeurs) que dans les grandes (~ 500 développeurs). Un avantage supplémentaire est que nous voyons ces applications vivre et évoluer au fil des années.
Pourquoi des microservices ?
À la question sur les avantages des microservices, il y a de Martin Fowler déjà mentionné :
- des limites claires de la modularité ;
- déploiement indépendant ;
- liberté de choisir les technologies.
J'ai beaucoup parlé aux architectes et aux développeurs de logiciels et je leur ai demandé pourquoi ils avaient besoin de microservices. Et j'ai fait ma liste de leurs attentes. Voici ce qui s'est passé :
Si nous décrivons certains points « en sensations », alors :
- limites claires des modules : nous avons ici un terrible monolithe, et maintenant tout sera soigneusement rangé dans des référentiels Git, dans lesquels tout est « sur les étagères », le chaud et le doux ne sont pas mélangés ;
- indépendance de déploiement : nous pourrons déployer les services de manière autonome pour accélérer le développement (publier de nouvelles fonctionnalités en parallèle) ;
- indépendance de développement : nous pouvons donner ce microservice à une équipe/développeur, et celui-là à un autre, grâce auquel nous pouvons développer plus rapidement ;
- боune plus grande fiabilité : si une dégradation partielle se produit (un microservice sur 20 tombe), alors un seul bouton cessera de fonctionner et le système dans son ensemble continuera à fonctionner.
Architecture de microservice typique (nuisible)
Pour expliquer pourquoi la réalité n'est pas celle à laquelle nous nous attendons, je présenterai collectif une image d'une architecture de microservices basée sur l'expérience de nombreux projets différents.
Un exemple serait une boutique en ligne abstraite qui va concurrencer Amazon ou au moins OZON. Son architecture de microservices ressemble à ceci :
Pour diverses raisons, ces microservices sont écrits sur différentes plateformes :
Puisque chaque microservice doit être autonome, beaucoup d’entre eux ont besoin de leur propre base de données et de leur propre cache. L'architecture finale est la suivante :
Quelles sont ses conséquences ?
Fowler a ça aussi — à propos du « paiement » pour l'utilisation des microservices :
Et nous verrons si nos attentes ont été satisfaites.
Délimitations claires des modules...
Mais combien de microservices devons-nous réellement réparer ?déployer le changement ? Pouvons-nous même comprendre comment tout fonctionne sans traceur distribué (après tout, toute demande est traitée par la moitié des microservices) ?
Il y a un modèle "“, et ici, il s’est avéré qu’il s’agissait d’un tas de terre distribué. Pour le confirmer, voici une illustration approximative du déroulement des demandes :
Indépendance du déploiement...
Techniquement, c’est chose faite : nous pouvons déployer chaque microservice séparément. Mais dans la pratique, il faut garder à l'esprit qu'il se déroule toujours de nombreux microservices, et nous devons prendre en compte l'ordre de leur déploiement. Dans le bon sens, nous devons généralement tester dans un circuit séparé si nous déployons la version dans le bon ordre.
Liberté de choisir la technologie...
Elle est. N’oubliez pas que la liberté confine souvent à l’anarchie. Il est ici très important de ne pas choisir des technologies simplement pour « jouer » avec elles.
Indépendance du développement...
Comment faire une boucle de test pour l'ensemble de l'application (avec autant de composants) ? Mais encore faut-il le maintenir à jour. Tout cela conduit au fait que nombre réel de circuits de test, que l'on peut en principe contenir, s'avère minime.
Que diriez-vous de déployer tout cela localement ?.. Il s'avère que souvent le développeur fait son travail de manière indépendante, mais « au hasard », car il est obligé d'attendre que le circuit soit libre pour les tests.
Mise à l'échelle séparée...
Oui, mais c'est limité dans le domaine du SGBD utilisé. Dans l'exemple d'architecture donné, Cassandra n'aura pas de problèmes, mais MySQL et PostgreSQL en auront.
Боune plus grande fiabilité...
Non seulement la défaillance d'un microservice interrompt souvent en réalité le bon fonctionnement de l'ensemble du système, mais un nouveau problème apparaît également : rendre chaque microservice tolérant aux pannes est très difficile. Parce que les microservices utilisent des technologies différentes (memcache, Redis, etc.), pour chacun, il faut tout réfléchir et le mettre en œuvre, ce qui est bien sûr possible, mais nécessite d'énormes ressources.
Mesurabilité de la charge...
Ceci est vraiment bon.
La « légèreté » des microservices…
Nous avons non seulement d'énormes surcharge du réseau (les demandes de DNS se multiplient, etc.), mais aussi du fait des nombreuses sous-requêtes que nous avons lancées répliquer des données (caches de stockage), ce qui entraînait une quantité de stockage importante.
Et voici le résultat à la hauteur de nos attentes :
Mais ce n'est pas tout!
Parce que:
- Nous aurons très probablement besoin d'un bus de messages.
- Comment faire une sauvegarde cohérente au bon moment ? Le seul réel L'option est de désactiver le trafic pour cela. Mais comment faire cela en production ?
- Si nous parlons de soutenir plusieurs régions, alors organiser la durabilité dans chacune d'elles est une tâche très laborieuse.
- Le problème de la centralisation des changements se pose. Par exemple, si nous devons mettre à jour la version PHP, nous devrons nous engager sur chaque référentiel (et il y en a des dizaines).
- La croissance de la complexité opérationnelle est, de prime abord, exponentielle.
Que faire de tout ça ?
Commencez avec une application monolithique. L'expérience de Fowler que presque toutes les applications de microservices réussies ont commencé comme un monolithe devenu trop volumineux puis brisé. Dans le même temps, presque tous les systèmes construits dès le début sous forme de microservices ont connu tôt ou tard de graves problèmes.
Une autre réflexion intéressante est que pour qu'un projet avec une architecture de microservices réussisse, vous devez très bien savoir et le domaine, et comment créer des microservices. Et la meilleure façon d’apprendre un domaine est de créer un monolithe.
Mais que se passe-t-il si nous sommes déjà dans cette situation ?
La première étape pour résoudre un problème est d’être d’accord avec celui-ci et de comprendre qu’il s’agit d’un problème et que nous ne voulons plus souffrir.
Si, dans le cas d'un monolithe envahi (lorsque nous n'avons plus la possibilité d'acheter des ressources supplémentaires pour cela), nous le coupons, alors dans ce cas, l'histoire inverse se produit : lorsque des microservices excessifs n'aident plus, mais gênent - couper l'excédent et agrandir!
Par exemple, pour l’image collective évoquée ci-dessus…
Débarrassez-vous des microservices les plus douteux :
Combinez tous les microservices responsables de la génération du frontend :
... en un seul microservice, écrit dans un langage/framework (moderne et normal, comme vous le pensez vous-même) :
Il aura un ORM (un SGBD) et d'abord quelques applications :
... mais en général, vous pouvez y transférer beaucoup plus, obtenant le résultat suivant :
De plus, dans Kubernetes, nous exécutons tout cela dans des instances distinctes, ce qui signifie que nous pouvons toujours mesurer la charge et les mettre à l'échelle séparément.
résumant
Regardez la situation dans son ensemble. Très souvent, tous ces problèmes avec les microservices surviennent parce que quelqu'un a accepté sa tâche, mais a voulu « jouer avec les microservices ».
Dans le mot « microservices », la partie « micro » est redondante.. Ils sont « micro » uniquement parce qu’ils sont plus petits qu’un énorme monolithe. Mais ne les considérez pas comme quelque chose de petit.
Et pour une dernière réflexion, revenons au tableau original :
Une note écrite dessus (en haut à droite) se résume au fait que les compétences de l'équipe qui réalise votre projet sont toujours primordiales — ils joueront un rôle clé dans votre choix entre les microservices et un monolithe. Si l'équipe n'a pas assez de compétences, mais qu'elle commence à créer des microservices, l'histoire sera définitivement fatale.
Vidéos et diapositives
Vidéo du discours (~50 minutes ; malheureusement, elle ne transmet pas les nombreuses émotions des visiteurs, qui ont largement déterminé l'ambiance du reportage, mais c'est comme ça) :
Présentation du rapport :
PS
Autres reportages sur notre blog :
- «» (Dmitry Stolyarov ; 28 mai 2018 à RootConf);
- «» (Dmitry Stolyarov ; 7 novembre 2017 sur HighLoad++);
- «» (Dmitry Stolyarov ; 6 juin 2017 à RootConf);
- «» (Dmitry Stolyarov ; 8 novembre 2016 sur HighLoad++);
- «» (Dmitry Stolyarov ; 31 mai 2016 à RootConf).
Vous pourriez également être intéressé par les publications suivantes :
- «";
- «";
- «».
Source: habr.com