Cet article présentera l'architecture des microservices et les composants associés, présentera ce qu'ils sont et pourquoi utiliser l'architecture des microservices et ces composants. Cet article se concentre sur l’expression concise de l’image globale de l’architecture des microservices, il n’entrera donc pas dans les détails tels que la façon d’utiliser les composants.
Pour comprendre les microservices, vous devez d'abord comprendre ceux qui ne sont pas des microservices. Habituellement, le contraire des microservices est une application monolithique, c'est-à-dire une application qui regroupe toutes les fonctions dans une unité indépendante. Passer d’une application monolithique aux microservices ne se fait pas du jour au lendemain. Il s’agit d’un processus évolutif progressif. Cet article prendra comme exemple une application de supermarché en ligne pour illustrer ce processus.
Il y a quelques années, Xiao Ming et Xiao Pi ont lancé ensemble un supermarché en ligne. Xiao Ming est responsable du développement du programme et Xiao Pi est responsable d'autres questions. À cette époque, Internet n’était pas encore développé et les supermarchés en ligne représentaient encore un océan bleu. Tant que la fonction est mise en œuvre, vous pouvez gagner de l'argent à volonté. Leurs besoins sont donc très simples : ils ont uniquement besoin d'un site Web sur le réseau public sur lequel les utilisateurs peuvent parcourir et acheter des produits. Ils ont également besoin d'un backend de gestion capable de gérer les produits, les utilisateurs et les données de commande.
Trions la liste des fonctions :
En raison de besoins simples, Xiao Ming a simplement déplacé ses mains gauche et droite au ralenti et le site Web était prêt. Pour des raisons de sécurité, le backend de gestion n'est pas colocalisé avec le site Web. La main droite et la main gauche de Xiao Ming sont relues au ralenti et le site Web de gestion est prêt. Le schéma global de l'architecture est le suivant :
Xiao Ming a agité la main, a trouvé un service cloud à déployer et le site Web était en ligne. Après avoir été lancé en ligne, il a reçu des critiques élogieuses et a été apprécié par toutes sortes de grosses maisons. Xiao Ming et Xiao Pi commencèrent joyeusement à s'allonger et à récupérer l'argent.
Les bons moments n'ont pas duré longtemps. En quelques jours, divers supermarchés en ligne ont vu le jour, ce qui a eu un fort impact sur Xiao Ming Xiaopi.
Sous la pression de la concurrence, Xiaoming Xiaopi a décidé de mettre en œuvre quelques méthodes de marketing :
Ces activités nécessitent le soutien du développement du programme. Xiao Ming a enrôlé son camarade de classe Xiao Hong pour rejoindre l'équipe. Xiaohong est responsable de l'analyse des données et du développement lié aux terminaux mobiles. Xiao Ming est responsable du développement des fonctions liées aux activités promotionnelles.
Parce que la tâche de développement était relativement urgente, Xiao Ming et Xiao Hong n'ont pas planifié soigneusement l'architecture de l'ensemble du système. Il s'est simplement tapoté la tête et a décidé de mettre la gestion des promotions et l'analyse des données en arrière-plan de la gestion, ainsi que WeChat et l'application mobile. ont été construits séparément. Après avoir travaillé toute la nuit pendant quelques jours, les nouvelles fonctions et les nouvelles applications sont pratiquement terminées. Le schéma d'architecture à ce moment est le suivant :
Il y a beaucoup de choses déraisonnables à ce stade :
Même si les problèmes sont nombreux, on ne peut nier les résultats de cette étape : le système s'est construit rapidement en fonction des évolutions du business. Cependant, les tâches urgentes et lourdes peuvent facilement amener les gens à adopter une réflexion partielle et à court terme et à prendre des décisions de compromis. Dans ce type de structure, chacun se concentre uniquement sur son propre tiers d’acre, sans conception globale et à long terme. Si les choses continuent ainsi, la construction du système deviendra de plus en plus difficile et pourrait même tomber dans un cycle de renversement et de reconstruction constants.
Heureusement, Xiao Ming et Xiao Hong sont de bons jeunes avec des activités et des idéaux. Après avoir pris conscience du problème, Xiao Ming et Xiao Hong ont libéré un peu d'énergie des besoins commerciaux insignifiants, ont commencé à trier la structure globale et se sont préparés à transformer le problème.
Pour opérer une transformation, il faut d'abord avoir suffisamment d'énergie et de ressources. Si votre côté demande (personnel commercial, chef de projet, patron, etc.) est si fort dans la poursuite de la progression de la demande que vous ne pouvez pas allouer d'énergie et de ressources supplémentaires, alors vous ne pourrez peut-être rien faire...
Dans le monde de la programmation, la chose la plus importante est la capacité d'abstraction. Le processus de transformation des microservices est en réalité un processus abstrait. Xiao Ming et Xiao Hong ont organisé la logique commerciale du supermarché en ligne, résumé les capacités commerciales communes et créé plusieurs services publics :
Chaque backend d'application n'a besoin que d'obtenir les données requises de ces services, supprimant ainsi une grande quantité de code redondant, ne laissant qu'une fine couche de contrôle et un front-end. L'architecture de cette étape est la suivante :
Cette étape ne sépare que les services, et la base de données est toujours partagée, donc certains défauts du système de cheminée existent toujours :
Si vous conservez le modèle de base de données partagée, l'ensemble de l'architecture deviendra de plus en plus rigide et perdra le sens de l'architecture des microservices. Par conséquent, Xiao Ming et Xiao Hong ont travaillé ensemble pour diviser la base de données. Toutes les couches de persistance sont isolées les unes des autres et relèvent de la responsabilité de chaque service. De plus, afin d'améliorer les performances en temps réel du système, un mécanisme de file d'attente de messages est ajouté. L'architecture est la suivante :
Après un découpage complet, chaque service peut utiliser des technologies hétérogènes. Par exemple, les services d'analyse de données peuvent utiliser des entrepôts de données comme couche de persistance pour effectuer efficacement certains calculs statistiques ; les services de base et les services promotionnels sont consultés plus fréquemment, un mécanisme de mise en cache est donc ajouté.
Une autre façon d'abstraire la logique publique est de transformer cette logique publique en une bibliothèque de cadre public. Cette méthode peut réduire la perte de performances des appels de service. Cependant, le coût de gestion de cette méthode est très élevé, et il est difficile d’assurer la cohérence de toutes les versions de l’application.
Le fractionnement des bases de données présente également certains problèmes et défis : tels que la nécessité d'une mise en cascade entre les bases de données, la granularité des requêtes de données via les services, etc. Mais ces problèmes peuvent être résolus grâce à une conception raisonnable. Dans l’ensemble, le fractionnement d’une base de données présente plus d’avantages que d’inconvénients.
L'architecture des microservices présente également un avantage non technique. Elle rend la division du travail dans l'ensemble du système plus claire et les responsabilités plus claires. Chacun se consacre à fournir de meilleurs services aux autres. À l’ère des applications monolithiques, les fonctions des entreprises publiques n’ont souvent pas de propriété clairement définie. En fin de compte, soit chacun fait ce qu'il veut et chacun le met en œuvre à nouveau ; soit une personne aléatoire (généralement une personne plus compétente ou plus enthousiaste) met en œuvre l'application dont elle est responsable. Dans ce dernier cas, en plus d'être responsable de sa propre application, cette personne est également responsable de fournir ces fonctions publiques à d'autres - et cette fonction n'est à l'origine responsable de personne, simplement parce qu'elle est plus capable/enthousiaste de prendre le relais. blâmer (cette situation est aussi appelée par euphémisme « les capables font le travail dur »). En fin de compte, personne n’était disposé à assurer des fonctions publiques. Au fil du temps, les membres de l’équipe sont progressivement devenus indépendants et ne se souciaient plus de la conception globale de l’architecture. Suivez le compte officiel Java Journey pour recevoir des e-books.
De ce point de vue, l'utilisation de l'architecture des microservices nécessite également des ajustements correspondants de la structure organisationnelle. Par conséquent, la transformation des microservices nécessite le soutien des managers.
Une fois la transformation terminée, Xiao Ming et Xiao Hong ont clairement divisé leurs rôles respectifs. Ils étaient tous les deux très satisfaits, tout était aussi beau et parfait que les équations de Maxwell.
Cependant...
Le printemps est là, tout reprend vie et c'est à nouveau le carnaval annuel du shopping. Voyant le nombre de commandes quotidiennes augmenter régulièrement, Xiaopi, Xiaoming et Xiaohong ont souri joyeusement. Malheureusement, les bons moments n’ont pas duré longtemps. Soudain, le système s’est effondré.
Dans le passé, pour des applications uniques, le dépannage impliquait généralement la consultation des journaux, l'étude des messages d'erreur et des piles d'appels. Dans l'architecture microservice, l'ensemble de l'application est dispersée en plusieurs services, ce qui rend très difficile la localisation du point de défaillance. Xiao Ming a vérifié les journaux un par un et a appelé manuellement chaque service un par un. Après plus de dix minutes de recherche, Xiao Ming a finalement localisé le point faible : le service de promotion ne répondait plus en raison du grand nombre de demandes qu'il recevait. D'autres services appellent directement ou indirectement le service de promotion, ils tombent donc également en panne. Dans une architecture de microservices, une panne de service peut avoir un effet d'avalanche, provoquant la panne de l'ensemble du système. En fait, avant les vacances, Xiao Ming et Xiao Hong ont procédé à une évaluation du volume des demandes. Comme prévu, les ressources du serveur sont suffisantes pour prendre en charge le volume de demandes du jour férié, il doit donc y avoir un problème. Cependant, la situation était urgente. Chaque minute et chaque seconde écoulée était de l'argent gaspillé, donc Xiao Ming n'a pas eu le temps de résoudre le problème. Il a immédiatement pris la décision de créer plusieurs nouvelles machines virtuelles sur le cloud, puis a déployé de nouveaux services promotionnels. par un nœud. Après quelques minutes de fonctionnement, le système est finalement revenu à la normale. On estime que des centaines de milliers de ventes ont été perdues pendant toute la panne, et le cœur de tous les trois saignait...
Ensuite, Xiao Ming a simplement écrit un outil d'analyse des journaux (le volume était si volumineux qu'il était presque impossible de l'ouvrir avec un éditeur de texte et n'était pas visible à l'œil nu), a compté les journaux d'accès aux services promotionnels et a trouvé que lors de la panne, les services du produit étaient Il y a un problème de code Dans certains scénarios, un grand nombre de demandes seront adressées au service promotionnel. Ce problème n'est pas compliqué. Xiao Ming a corrigé ce bug valant des centaines de milliers d'un simple mouvement du doigt.
Le problème a été résolu, mais personne ne peut garantir que d'autres problèmes similaires ne se reproduiront pas. Bien que l'architecture des microservices semble parfaite dans sa conception logique, elle ressemble à un magnifique palais construit à partir de blocs de construction et ne peut pas résister au vent et aux vagues. Bien que l'architecture des microservices résolve d'anciens problèmes, elle en introduit également de nouveaux :
Xiao Ming et Xiao Hong ont tiré les leçons de cette expérience et sont déterminés à résoudre ces problèmes. Le dépannage implique généralement deux aspects : d’une part, on essaie de réduire la probabilité d’une panne, et d’autre part, on réduit l’impact de la panne.
Dans les scénarios distribués à haute concurrence, les échecs se produisent souvent soudainement comme une avalanche. Par conséquent, un système de surveillance complet doit être mis en place pour détecter autant que possible les signes de défaillance.
Il existe de nombreux composants dans l'architecture des microservices, et chaque composant doit surveiller différents indicateurs. Par exemple, le cache Redis surveille généralement la valeur de mémoire occupée et le trafic réseau, la base de données surveille le nombre de connexions et l'espace disque, et le service métier surveille le nombre de simultanéités, les délais de réponse, les taux d'erreur, etc. Par conséquent, il n’est pas réaliste de construire un système de surveillance vaste et complet pour surveiller chaque composant, et l’évolutivité sera très faible. L'approche générale consiste à laisser chaque composant fournir une interface (interface de métriques) pour signaler son état actuel. Le format de données généré par cette interface doit être cohérent. Déployez ensuite un composant collecteur d'indicateurs pour obtenir et maintenir régulièrement l'état des composants à partir de ces interfaces, tout en fournissant des services de requête. Enfin, une interface utilisateur est nécessaire pour interroger divers indicateurs du collecteur d'indicateurs, dessiner une interface de surveillance ou émettre des alarmes basées sur des seuils.
La plupart des composants n'ont pas besoin d'être développés par vous-même, il existe des composants open source sur Internet. Xiao Ming a téléchargé RedisExporter et MySQLExporter. Ces deux composants fournissent respectivement des interfaces d'indicateur pour le cache Redis et la base de données MySQL. Les microservices implémentent des interfaces d'indicateurs personnalisées basées sur la logique métier de chaque service. Ensuite, Xiao Ming utilise Prometheus comme collecteur d'indicateurs et Grafana configure l'interface de surveillance et les alertes par e-mail. Un tel système de surveillance des microservices est construit :
Dans l'architecture du microservice, la demande d'un utilisateur implique souvent plusieurs appels de service internes. Afin de faciliter la localisation des problèmes, il est nécessaire de pouvoir enregistrer le nombre d'appels de service générés au sein du microservice lorsque chaque utilisateur le demande, ainsi que leurs relations d'appel. C’est ce qu’on appelle le suivi des liens.
Utilisons un exemple de suivi de lien dans le document Istio pour voir l'effet :
L'image provient du document Istio
Comme vous pouvez le voir sur l'image, il s'agit d'une demande d'utilisateur pour accéder au page de la page produit. Au cours du processus de demande, le service productpage appelle séquentiellement les interfaces des services de détails et d'avis. Le service d'avis appelle l'interface d'évaluation pendant le processus de réponse. L'enregistrement de l'ensemble du suivi des liens est un arbre :
Pour mettre en œuvre le suivi des liens, chaque appel de service enregistrera au moins quatre éléments de données dans des HEADERS HTTP :
De plus, vous devez également appeler des composants pour la collecte et le stockage des journaux, ainsi que des composants d'interface utilisateur pour afficher les appels de lien.
Ce qui précède n'est qu'une explication minimaliste. La base théorique du suivi des liens peut être trouvée dans Dapper de Google
Après avoir compris la base théorique, Xiao Ming a choisi Zipkin, une implémentation open source de Dapper. Puis, d'un simple mouvement du doigt, j'ai écrit un intercepteur de requêtes HTTP, généré ces données et les ai injectées dans HEADERS lors de chaque requête HTTP, et en même temps envoyé le journal des appels de manière asynchrone au collecteur de journaux de Zipkin. Une mention supplémentaire ici est que l'intercepteur de requêtes HTTP peut être implémenté dans le code du microservice, ou il peut être implémenté à l'aide d'un composant proxy réseau (mais dans ce cas, chaque microservice doit ajouter une couche de proxy).
Le suivi des liens peut uniquement localiser le service qui présente un problème et ne peut pas fournir d'informations d'erreur spécifiques. La capacité de trouver des informations d'erreur spécifiques doit être fournie par le composant d'analyse des journaux.
Le composant d'analyse des journaux aurait dû être largement utilisé avant l'essor des microservices. Même avec une architecture d'application unique, lorsque le nombre d'accès augmente ou que la taille du serveur augmente, la taille des fichiers journaux augmente au point qu'il devient difficile d'y accéder avec un éditeur de texte. Le pire, c'est qu'ils sont dispersés. sur plusieurs serveurs. Pour résoudre un problème, vous devez vous connecter à chaque serveur pour obtenir les fichiers journaux et rechercher les informations de journal souhaitées une par une (et l'ouverture et la recherche sont très lentes).
Par conséquent, lorsque l'échelle de l'application devient plus grande, nous avons besoin d'un journal "Search Engine". Pour que vous puissiez trouver avec précision le journal que vous souhaitez. De plus, le côté source de données a également besoin de composants pour collecter les journaux et de composants d'interface utilisateur pour afficher les résultats :
Xiao Ming a étudié et utilisé le célèbre composant d'analyse des journaux ELK. ELK est l'abréviation de trois composants : Elasticsearch, Logstash et Kibana.
La dernière petite question est de savoir comment envoyer les logs à Logstash. Une solution consiste à appeler directement l'interface Logstash pour envoyer le journal lors de la sortie du journal. De cette façon, le code doit être modifié à nouveau (Hé, pourquoi utiliser "et")... Alors Xiao Ming a choisi une autre solution : les journaux sont toujours générés dans des fichiers, et un agent est déployé dans chaque service pour analyser le journal. fichiers, puis les exporter vers Logstash.
Pause publicitaire : Suivez le compte public : Java Learning Guide pour obtenir plus d'articles techniques.
Après la scission en microservices, un grand nombre de services et d'interfaces sont apparus, rendant toute la relation d'appel désordonnée. Souvent, pendant le processus de développement, lors de l'écriture et de l'écriture, je ne me souviens plus quel service doit être appelé pour certaines données. Ou bien c'était écrit de manière tordue, appelant un service qui ne devait pas être appelé, et une fonction en lecture seule a fini par modifier les données...
Pour faire face à ces situations, l'appel des microservices a besoin d'un vérificateur, c'est-à-dire , une passerelle. Ajoutez une couche de passerelle entre l'appelant et l'appelé et effectuez une vérification des autorisations à chaque appel. En outre, la passerelle peut également être utilisée comme plate-forme pour fournir des documents d'interface de service.
L'un des problèmes liés à l'utilisation d'une passerelle est de décider du degré de granularité de son utilisation : la solution la plus grossière est une passerelle pour l'ensemble du microservice. L'extérieur du microservice accède au microservice via la passerelle, et l'intérieur du microservice appelle. directement ; la granularité la plus fine est que tous les appels, qu'ils soient internes au microservice ou provenant de l'extérieur, doivent passer par la passerelle. Une solution de compromis consiste à diviser les microservices en plusieurs zones selon les domaines d'activité, à les appeler directement au sein de la zone et à les appeler via la passerelle.
Étant donné que le nombre de services dans l'ensemble du supermarché en ligne n'est pas particulièrement important, Xiao Ming a adopté la solution la plus grossière :
Les composants précédents sont tous conçus pour réduire la possibilité d'échec. Cependant, des échecs se produiront toujours. Un autre aspect à étudier est donc la manière de réduire l’impact des échecs.
La stratégie de gestion des pannes la plus grossière (et la plus couramment utilisée) est la redondance. De manière générale, un service déploiera plusieurs instances, afin de pouvoir partager la pression et améliorer les performances, et deuxièmement, même si une instance échoue, d'autres instances peuvent toujours répondre.
Un problème avec la redondance est de savoir combien de redondances sont utilisées ? Il n’y a pas de réponse définitive à cette question sur la chronologie. En fonction de la fonction de service et de la période, différents nombres d'instances sont requis. Par exemple, en semaine, 4 instances peuvent suffire ; lors des promotions, lorsque le trafic augmente de manière significative, 40 instances peuvent être nécessaires. Par conséquent, le montant de la redondance n’est pas une valeur fixe, mais peut être ajusté en temps réel selon les besoins. De manière générale, l'opération d'ajout d'une nouvelle instance est la suivante :
La solution à ce problème est l'enregistrement et la découverte automatiques du service. Tout d’abord, vous devez déployer un service de découverte de services qui fournit des informations d’adresse pour tous les services enregistrés. Le DNS peut également être considéré comme un service de découverte de services. Ensuite, chaque service d'application s'enregistre automatiquement auprès du service de découverte de services lors de son démarrage. Et une fois le service d'application démarré, la liste d'adresses de chaque service d'application sera synchronisée du service de découverte de services vers le local en temps réel (régulièrement). Le service de découverte de services vérifiera également régulièrement l'état de santé des services d'application et supprimera les adresses d'instances défectueuses. De cette façon, lors de l'ajout d'une instance, il vous suffit de déployer la nouvelle instance. Lorsque l'instance est hors ligne, vous pouvez directement arrêter le service. La découverte de services vérifiera automatiquement l'augmentation ou la diminution des instances de service.
Il existe de nombreux composants parmi lesquels choisir pour la découverte de services, tels que Zookeeper, Eureka, Consul, Etcd, etc. Cependant, Xiao Ming se sentait plutôt bon et voulait montrer ses compétences, alors il en a écrit un basé sur Redis...
Lorsqu'un service cesse de répondre pour diverses raisons, l'appelant attend généralement un certain temps, puis expire ou reçoit un retour d'erreur. Si le lien appelant est relativement long, les demandes peuvent s'accumuler et l'ensemble du lien consomme beaucoup de ressources et attend des réponses en aval. Par conséquent, lorsque l'accès à un service échoue plusieurs fois, le disjoncteur doit être cassé, marquant le service comme ayant cessé de fonctionner et renvoyant directement une erreur. Attendez que le service revienne à la normale avant de rétablir la connexion.
Image de "Microservice Design"
Lorsque le service en aval cesse de fonctionner, si le service n'est pas l'activité principale, le service en amont doit être rétrogradé pour garantir que l'activité principale n'est pas interrompu. Par exemple, l'interface de commande des supermarchés en ligne dispose d'une fonction permettant de collecter les commandes de produits recommandés. Lorsque le module de recommandation est en panne, la fonction de commande ne peut pas être désactivée en même temps. Il vous suffit de désactiver temporairement la fonction de recommandation.
Après le blocage d'un service, le service ou l'utilisateur en amont réessaye généralement l'accès. Cela signifie qu'une fois le service revenu à la normale, il est susceptible de raccrocher immédiatement en raison d'un trafic réseau excessif et de sit-ups répétés dans le cercueil. Le service doit donc être capable de se protéger lui-même, c'est-à-dire de limiter le trafic. Il existe actuellement de nombreuses stratégies de limitation. La plus simple consiste à éliminer les requêtes excédentaires lorsqu'il y a trop de requêtes par unité de temps. De plus, une limitation du courant de partition peut également être envisagée. Refusez uniquement les demandes provenant de services qui génèrent un grand nombre de demandes. Par exemple, le service produit et le service de commande doivent accéder au service de promotion. Le service produit lance un grand nombre de demandes en raison de problèmes de code. Le service de promotion limite uniquement les demandes du service produit et les demandes du service de commande répondent. normalement.
Dans l'architecture des microservices, les tests sont divisés en trois niveaux :
La facilité de mise en œuvre des trois tests augmente de haut en bas, mais l'effet du test diminue. Les tests de bout en bout sont les plus longs et les plus laborieux, mais après avoir réussi le test, nous avons le plus confiance dans le système. Les tests unitaires sont les plus simples à mettre en œuvre et les plus efficaces, mais rien ne garantit que l’ensemble du système se déroulera sans problème après le test.
En raison de la difficulté de mise en œuvre des tests de bout en bout, les tests de bout en bout ne sont généralement effectués que sur les fonctions principales. Une fois qu'un test de bout en bout échoue, il doit être décomposé en tests unitaires : la raison de l'échec est ensuite analysée, puis des tests unitaires sont écrits pour reproduire le problème afin que nous puissions détecter la même erreur plus rapidement dans le processus. avenir.
La difficulté des tests de service est que le service dépend souvent de certains autres services. Ce problème peut être résolu via Mock Server :
Tout le monde est familier avec les tests unitaires. Nous écrivons généralement un grand nombre de tests unitaires (y compris des tests de régression) pour tenter de couvrir tout le code.
Interface d'indicateur, injection de suivi de lien, détournement de journaux, découverte d'enregistrement de service, règles de routage et autres composants, ainsi que des fonctions telles que le disjoncteur et la limitation de courant, tous doivent ajouter du code d'accueil au service d'application . La mise en œuvre de chaque service d'application individuellement prendrait beaucoup de temps et de main d'œuvre. Sur la base du principe de DRY, Xiao Ming a développé un framework de microservices, extrayant le code qui s'interface avec chaque composant et d'autres codes publics dans le framework, et tous les services d'application sont développés à l'aide de ce framework.
De nombreuses fonctions personnalisées peuvent être réalisées à l'aide du framework microservice. Vous pouvez même injecter des informations sur la pile d'appels de programme dans le suivi des liens pour obtenir un suivi des liens au niveau du code. Ou affichez les informations d'état du pool de threads et du pool de connexions et surveillez l'état sous-jacent du service en temps réel.
L'utilisation d'un framework de microservices unifié pose un sérieux problème : le coût de mise à jour du framework est très élevé. Chaque fois que le framework est mis à niveau, tous les services d'application doivent coopérer avec la mise à niveau. Bien entendu, une solution de compatibilité est généralement utilisée, permettant une période d'attente parallèle pour que tous les services applicatifs soient mis à niveau. Cependant, s'il existe de nombreux services d'application, le temps de mise à niveau peut être très long. Et il existe des services d'application très stables qui sont rarement mis à jour, et le responsable peut refuser de mettre à niveau... Par conséquent, l'utilisation d'un cadre de microservices unifié nécessite des méthodes complètes de gestion des versions et des spécifications de gestion du développement.
Une autre façon d'abstraire le code commun consiste à extraire ce code directement dans un composant de proxy inverse. Chaque service déploie en outre ce composant proxy, et tout le trafic sortant et entrant est traité et transmis via ce composant. Ce composant s'appelle Sidecar.
Sidecar n'entraînera pas de frais de réseau supplémentaires. Sidecar sera déployé sur le même hôte que le nœud du microservice et partagera la même carte réseau virtuelle. Par conséquent, la communication entre les nœuds side-car et microservice n’est en réalité réalisée que via une copie de mémoire.
Photo de : Modèle : Service Mesh
Sidecar est uniquement responsable de la communication réseau. Un composant est également nécessaire pour gérer uniformément la configuration de tous les side-cars. Dans Service Mesh, la partie responsable de la communication réseau est appelée le plan de données et la partie responsable de la gestion de la configuration est appelée le plan de contrôle. Le plan de données et le plan de contrôle constituent l’architecture de base de Service Mesh.
Photo de : Modèle : Service Mesh
L'avantage de Service Mesh par rapport au framework de microservices est qu'il n'envahit pas le code et qu'il est plus pratique à mettre à niveau et à maintenir. Il est souvent critiqué pour des problèmes de performances. Même si le réseau de bouclage ne génère pas de requêtes réseau réelles, il existe toujours un coût supplémentaire lié à la copie de la mémoire. De plus, certains traitements centralisés du trafic affecteront également les performances.
Les microservices ne sont pas la fin de l'évolution de l'architecture. Pour aller plus loin, il existe le Serverless, le FaaS et d'autres directions. D'un autre côté, il y a aussi des gens qui chantent qu'il faut diviser l'harmonie dans le temps et redécouvrir l'architecture monolithique...
En tout cas, la transformation de l'architecture des microservices est pour le moment terminée. être. Xiao Ming tapota sa tête de plus en plus lisse avec satisfaction et prévoyait de faire une pause ce week-end et de rencontrer Xiao Hong pour une tasse de café.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!
Comment définir une bordure pointillée CSS
Comment ouvrir le fichier VSD
Qu'est-ce qui fait que l'écran de l'ordinateur devient jaune ?
Comment obtenir le numéro d'entrée en Java
Solution au blocage de Gmail
Top 10 des applications de trading de crypto-monnaie
Comment lire une colonne dans Excel en python
Comment utiliser la fonction fréquence
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
