Pourquoi Alibaba n'utilise-t-il pas ZooKeeper pour la découverte de services ?

À l'intersection du futur, il est souvent intéressant de revenir sur le chemin perdu de l'histoire, car nous aurons par inadvertance des pensées folles, comme ce qui se serait passé si quelque chose s'était produit plus tôt, mais qu'une autre chose s'était produite. ça ne s'est pas produit ? Tout comme ce qui serait arrivé si l'archiduc Ferdinand et son épouse, héritiers du trône de l'Empire austro-hongrois, n'avaient pas été abattus par le passionné jeune serbe Princip, et que serait-il arrivé si Qiu Laodao n'était pas passé par là Le village de Niujia ?

Fin 2007, Taobao a lancé un projet de reconstruction interne appelé "Colorful Stone". Ce projet est devenu plus tard la servitisation, l'auto-recherche pour la distribution et est sorti du middleware Internet. du système, et le centre d'enregistrement des services Taobao ConfigServer est né la même année.

Vers 2008, Yahoo, l'ancien géant de l'Internet, a commencé à faire connaître progressivement au public son produit de coordination distribuée Big Data ZooKeeper. Ce produit faisait référence aux articles publiés par Google sur Chubby et Paxos.

En novembre 2010, ZooKeeper est passé d'un sous-projet d'Apache Hadoop à un projet de haut niveau d'Apache, annonçant officiellement que ZooKeeper est devenu un produit de qualité industrielle, mature et stable.

En 2011, Alibaba a ouvert Dubbo afin d'améliorer l'open source, il a dû se départir de ses relations avec les systèmes internes d'Alibaba. Plus tard, en Chine, avec le dur. travail et pratique de tous les acteurs de l'industrie, la solution de service typique de Dubbo + ZooKeeper a rendu ZooKeeper célèbre en tant que centre d'enregistrement.

Double 11 en 2015, près de 8 ans se sont écoulés depuis le lancement du service ConfigServer. L'« échelle de service » interne d'Alibaba a dépassé plusieurs millions, ainsi que la promotion de la stratégie technologique de reprise après sinistre d'IDC « à des milliers de kilomètres », etc. , ce qui a incité conjointement Alibaba à ouvrir le chemin de mise à niveau de l'architecture interne de ConfigServer 2.0 vers ConfigServer 3.0.

Le temps se rapproche de 2018. À l'intersection de 10 ans, combien de personnes sont prêtes à ralentir un peu et à examiner de plus près le domaine de la découverte des services tout en poursuivant les nouveaux concepts technologiques en constante évolution ? Vous y avez pensé ou réfléchi ? Une question :

Service découverte, ZooKeeper est-il vraiment le meilleur choix ?

En regardant l'histoire, nous avons aussi parfois des mythes Dans le contexte de la découverte de services, que se serait-il passé si ZooKeeper était né avant notre centre d'enregistrement HSF ConfigServer ?

Allons-nous faire le détour en utilisant ZooKeeper d'abord, puis transformer et patcher frénétiquement ZooKeeper pour l'adapter aux scénarios et aux besoins orientés services d'Alibaba ?

Cependant, en s'appuyant sur les épaules d'aujourd'hui et de nos prédécesseurs, nous n'avons jamais réalisé aussi fermement qu'aujourd'hui que Dans le domaine de la découverte de services, ZooKeeper n'est tout simplement pas le meilleur choix, tout comme nous l'avons tous été avec nous. Ces années-là, Fellow Eureka et cet article Eureka ! Pourquoi vous ne devriez pas utiliser ZooKeeper pour la découverte de services expliquent clairement pourquoi vous ne devriez pas utiliser ZooKeeper pour la découverte de services !

Je ne suis pas seul sur mon chemin.

Analyse des exigences du centre d'enregistrement et considérations clés de conception

Ensuite, revenons à l'analyse de la demande de découverte de services, combinée à la pratique d'Alibaba dans des scénarios clés, analysons-les un par un et discutons des raisons pour lesquelles ZooKeeper n'est pas le centre d'enregistrement le plus approprié. solution.

Le centre d'enregistrement est-il un système CP ou AP ?

Je pense que les lecteurs connaissent les théories CAP et BASE, et elles sont devenues l'un des principes clés guidant la construction de systèmes distribués et d'applications Internet, je ne développerai pas. sur leurs théories ici. Nous entrerons directement dans l'analyse des exigences de cohérence et de disponibilité des données du centre d'enregistrement :

• Analyse des exigences de cohérence des données

La fonction la plus essentielle du centre d'enregistrement peut être considérée comme une fonction de requête Si = F(service-name)，以 service-name 为查询参数，service-name 对应的服务的可用的 endpoints (ip:port) La liste est la valeur de retour

.

Remarque : Service sera abrégé en svc dans le texte suivant.

Tout d'abord, examinons l'impact de l'incohérence sur les données clés endpoints (ip:port), c'est-à-dire les conséquences de la non-respect de C dans CAP :

Comme le montre la figure ci-dessus, si un svcB déploie 10 nœuds ( copy/ Replica), si pour un même nom de service svcB, les deux requêtes des deux nœuds de l'appelant svcA retournent des données incohérentes, par exemple : S1 = { ip1,ip2,ip3...,ip9 }, S2 = { ip2 , ip3,....ip10}, Alors quel est l'impact de cette incohérence ?

Je crois que vous avez dû remarquer que le trafic de chaque nœud de svcB sera un peu déséquilibré.

Comparé aux 8 autres nœuds {ip2...ip9}, le trafic de requêtes de ip1 et ip10 est un peu plus petit, mais il est évident que dans un système distribué, même pour les services déployés peer-to-peer, en raison de l'heure d'arrivée de la demande, l'état du matériel, la planification du système d'exploitation, le GC de la machine virtuelle, etc., à tout moment, l'état de ces nœuds déployés par les pairs ne peut pas être complètement cohérent, et dans le cas d'un trafic incohérent, aussi longtemps comme le centre d'enregistrement est dans le délai promis par le SLA (par exemple, 1s (dans) les données convergent vers un état cohérent (c'est-à-dire satisfont à une cohérence éventuelle), le trafic aura bientôt tendance à être cohérent au sens statistique, donc le centre d'enregistrement est conçu selon un modèle finalement cohérent, tout à fait acceptable dans la pratique de production.

• Analyse des exigences de tolérance et de disponibilité des partitions

Nous examinons ensuite l'impact de l'indisponibilité du centre d'enregistrement sur les appels de service dans le cas d'une partition réseau (Network Partition), c'est-à-dire lorsque A dans CAP n’est pas satisfait.

Considérez une structure de déploiement typique à 5 nœuds et à trois nœuds de reprise après sinistre de ZooKeeper à trois salles informatiques (c'est-à-dire une structure 2-2-1), comme indiqué ci-dessous :

Lorsqu'une partition réseau se produit dans la salle informatique 3, c'est-à-dire l'ordinateur la salle 3 est Le réseau est devenu un îlot isolé. Nous savons que bien que l'ensemble du service ZooKeeper soit disponible, le nœud ZK5 n'est pas accessible en écriture car le Leader n'est pas joignable.

En d'autres termes, à l'heure actuelle, le service d'application svcB dans la salle informatique 3 ne peut pas être nouvellement déployé, redémarré, étendu ou réduit, mais du point de vue des appels de réseau et de service, bien que svcA dans la salle informatique 3 ne puisse pas appeler la salle informatique 1. et Le svcB dans la salle informatique 2, mais le réseau avec le svcB dans la salle informatique 3 est évidemment OK. Pourquoi ne pas me laisser appeler le service de cette salle informatique ?

Maintenant, parce que le centre d'enregistrement lui-même a renoncé à la disponibilité afin d'assurer la cohérence des données (C) sous split-brain (P), les services d'une même salle informatique ne peuvent pas être appelés. Ce n'est absolument pas autorisé ! On peut dire qu'en pratique, le centre d'enregistrement ne peut pas détruire la connectivité entre les services pour quelque raison que ce soit. C'est une loi d'airain que la conception du centre d'enregistrement doit suivre ! Nous continuerons à discuter de la reprise après sinistre du client du centre d'enregistrement plus tard.

En même temps, considérons l'incohérence des données dans ce cas. Si les salles informatiques 1, 2 et 3 deviennent toutes des îles isolées, alors si svcA dans chaque salle informatique obtient uniquement la liste IP de svcB dans cette salle informatique, elle Cela signifie également que les données de la liste IP de svcB dans chaque salle informatique sont complètement incohérentes. Quel est l'impact ?

En fait, cela n'a pas un grand impact, mais dans ce cas, ils deviennent tous des appels provenant de la même salle informatique. Lorsque nous concevons le centre d'inscription, nous utilisons même parfois activement les données du centre d'inscription pour être incohérentes. pour aider l'application à réaliser des appels de manière proactive dans la même salle informatique, optimisant ainsi l'effet du lien d'appel de service RT !

Grâce à notre explication ci-dessus, nous pouvons voir que dans le compromis CAP, la disponibilité du centre d'enregistrement est plus précieuse que la forte cohérence des données, de sorte que la conception globale devrait être davantage orientée vers les données AP plutôt que vers les données CP. l'incohérence se situe dans la plage acceptable, tandis que P Dropping A viole complètement le principe selon lequel le centre d'enregistrement ne peut pas détruire lui-même la connectivité du service pour quelque raison que ce soit.

Échelle du service, capacité, connectivité des services

Quelle est l'ampleur des « microservices » de votre entreprise ? Des centaines de microservices ? Vous avez déployé des centaines de nœuds ? Et 3 ans plus tard ? Internet est un endroit où les miracles se produisent. Peut-être que votre « service » devient un nom connu du jour au lendemain, votre trafic double et votre échelle double !

Lorsque l'échelle de service du centre de données dépasse un certain nombre (échelle de service = F{nombre de pubs de service, nombre de sous-services}), ZooKeeper en tant que centre d'enregistrement sera bientôt submergé comme l'âne sur la photo ci-dessous

En fait, cela devrait être le cas. Lorsque ZooKeeper est utilisé au bon endroit, c'est-à-dire dans des scénarios de verrouillage distribué et de coordination distribuée à gros grain, les tps et le nombre de connexions pris en charge par ZooKeeper sont suffisants, car ces scénarios n'exigent pas beaucoup de L'évolutivité et la capacité de ZooKeeper.

Mais dans les scénarios de découverte de services et de surveillance de l'état, à mesure que l'échelle du service augmente, qu'il s'agisse de requêtes d'écriture provoquées par l'enregistrement du service lorsque les applications sont fréquemment publiées, ou de requêtes d'écriture provoquées par le brossage de l'état de santé du service au niveau de la milliseconde, ou si toutes les machines ou les conteneurs de l'ensemble du centre de données ont de longues connexions au centre d'enregistrement, ZooKeeper sera bientôt incapable de faire face à la pression de connexion qu'il entraîne. Cependant, ZooKeeper n'est pas évolutif et ne peut pas résoudre le problème d'évolutivité horizontale en ajoutant des nœuds.

Si vous souhaitez résoudre le problème de la croissance de l'échelle des services basée sur ZooKeeper, une méthode pratique qui peut être envisagée consiste à trouver des moyens de trier l'entreprise, de diviser verticalement le domaine commercial et de le diviser en plusieurs centres d'enregistrement ZooKeeper, mais en tant qu'universel Est-il vraiment possible pour le groupe d'organisation de la plate-forme de services de diviser et de gérer l'activité selon le bâton technique en raison de capacités de service insuffisantes ?

Et cela viole le fait que le centre d'enregistrement lui-même (capacité insuffisante) détruit la connectivité du service. Pour donner un exemple simple, une entreprise de recherche, une entreprise de cartographie, une grande entreprise de divertissement et une entreprise de jeux, les services devraient-ils être entre eux. s'excluent-ils mutuellement ? Peut-être qu’aujourd’hui c’est oui, mais qu’en sera-t-il demain, dans un an, dans dix ans ? Qui sait qu'à l'avenir, plusieurs domaines commerciaux seront ouverts pour créer d'étranges innovations commerciales ? En tant que service de base, le centre d'enregistrement ne peut pas prédire l'avenir et ne peut certainement pas entraver la demande du service commercial en matière de connectivité future inhérente.

Le centre d'enregistrement a-t-il besoin d'un stockage persistant et de journaux de transactions ?

Besoin ou pas.

Nous savons que le protocole ZAB de ZooKeeper continuera à écrire un journal de transactions sur chaque nœud ZooKeeper pour chaque demande d'écriture, et en même temps, il mettra régulièrement en miroir (Snapshot) les données de la mémoire sur le disque pour assurer la cohérence et la durabilité du data. Il s'agit d'une très bonne fonctionnalité, ainsi que la récupération de données après un crash. Cependant, nous devons nous demander, dans le scénario de découverte de services, les données de base - la liste d'adresses en temps réel des services sains - ont-elles vraiment besoin de persistance des données ? ?

Pour ces données, la réponse est non.

Comme le montre la figure ci-dessus, si svcB est passé par le service d'enregistrement (ip1), l'expansion à 2 nœuds (ip1, ip2) et le rétrécissement dû au temps d'arrêt (temps d'arrêt ip1), ce processus s'est produit 3 fois. Écrivez opérations pour ZooKeeper.

Cependant, après une analyse minutieuse, il est en réalité peu important d'enregistrer en permanence ce processus de modification via les journaux de transactions, car dans la découverte de services, l'initiateur de l'appel de service est davantage préoccupé par la liste d'adresses en temps réel et l'état de santé en temps réel de le service qu'il souhaite appeler, chaque fois qu'un appel est lancé, il ne se soucie pas de la liste d'adresses du service historique et de l'état de santé passé du service à appeler.

Mais pourquoi est-ce nécessaire ? Parce qu'un centre d'enregistrement complet disponible en production, en plus de la liste d'adresses en temps réel et de l'état de santé en temps réel du service, stockera également certaines informations de métadonnées du service, telles que la version du service. , regroupement, méta-informations telles que le centre de données où il se trouve, poids, informations sur la politique d'authentification, étiquette de service, etc. Ces données doivent être stockées de manière persistante et le centre d'enregistrement doit offrir la possibilité de récupérer ces méta-informations.

Vérification de l'état du service

Lors de l'utilisation de ZooKeeper comme centre d'enregistrement du service, la détection de l'état du service utilise souvent le mécanisme de suivi actif de session de ZooKeeper et le mécanisme combiné avec Ephemeral ZNode, la surveillance de l'état du service est liée à ZooKeeper. . Surveillance de l’état de la session ou liaison à la détection de l’activité des liaisons longues TCP.

Cela peut également causer des problèmes fatals dans de nombreux cas. Lorsque la détection de l'activité de liaison longue TCP entre ZK et la machine du fournisseur de services est normale, le service est-il sain ? La réponse est bien sûr non ! Le centre d'enregistrement devrait fournir une solution de surveillance de l'état de santé plus riche, et la logique selon laquelle le service est sain ou non devrait être laissée au fournisseur de services à définir, plutôt que d'en faire un test d'activité TCP unique !

L'un des principes de conception de base de la détection de l'état de santé est de fournir un retour d'information aussi précis que possible sur l'état de santé réel du service lui-même. Dans le cas contraire, un résultat de détermination de l'état de santé auquel les appelants ne croient pas est pire qu'une absence de détection de l'état de santé.

Considérations de reprise après sinistre pour le centre d'enregistrement

Comme mentionné précédemment, En pratique, le centre d'enregistrement ne peut pas détruire la connectivité entre les services pour quelque raison que ce soit, donc en termes de disponibilité, il s'agit d'un problème essentiel si le centre d'enregistrement est utilisé. enregistrement Le centre (registre) lui-même est complètement en panne. Le lien svcA appelle svcB doit-il être affecté ?

Oui, cela ne devrait pas être affecté.

Le lien d'appel de service (flux de réponse à la demande) doit dépendre faiblement du centre d'enregistrement. Il ne doit s'appuyer sur le centre d'enregistrement que lorsque cela est nécessaire pour la libération du service, la machine en ligne et hors ligne, l'expansion et la contraction du service, etc.

Cela nécessite que le centre d'enregistrement conçoive soigneusement le client qu'il fournit. Le client doit disposer de moyens de reprise après sinistre lorsque le service du centre d'enregistrement est complètement indisponible. Par exemple, la conception d'un mécanisme de données de cache client (nous l'appelons instantané du client) est acceptable. .un moyen efficace. En outre, le mécanisme de contrôle de santé du centre d'enregistrement doit être soigneusement conçu afin que des situations telles que le vidage ne se produisent pas dans cette situation.

Le client natif de ZooKeeper n'a pas cette fonctionnalité, donc lorsque vous utilisez ZooKeeper pour implémenter le centre d'enregistrement, nous devons nous demander si tous les nœuds ZooKeeper sont supprimés, tous les liens d'appel de service dans votre production ne seront-ils pas affectés ? Et des exercices d’échec devraient être effectués régulièrement sur ce point.

Avez-vous un expert ZooKeeper sur qui compter ?

ZooKeeper semble être un produit très simple, mais il n'est pas évident de l'utiliser à grande échelle et de bien l'utiliser en production. Si vous décidez d'introduire ZooKeeper en production, vous feriez mieux d'être prêt à demander l'aide des experts techniques de ZooKeeper à tout moment. Les manifestations les plus typiques se présentent sous deux aspects :

• Machine à états client/session difficile à maîtriser.

Le client natif de ZooKeeper n'est certainement pas facile à utiliser. Curator ne sera pas si bon, mais en fait ce n'est pas si simple de comprendre pleinement le protocole d'interaction entre le client ZooKeeper et le serveur. comprendre et maîtriser parfaitement ZooKeeper. La machine à états Client/Session (photo ci-dessous) n'est pas si simple et claire :

Mais la solution de découverte de services basée sur ZooKeeper s'appuie sur la gestion des connexions/sessions longues, le ZNode éphémère, l'événement et la notification, et les mécanismes de ping fournis par ZooKeeper. Par conséquent, pour faire bon usage de ZooKeeper pour la découverte de services, vous devez comprendre ces mécanismes et principes fondamentaux de ZooKeeper. Cela vous rend parfois irritable. Pourquoi ai-je besoin d'en savoir autant. ? Et si vous comprenez tout cela et ne tombez dans aucun piège, félicitations, vous êtes devenu un expert technique de ZooKeeper.

• Gestion insupportable des exceptions

Lorsque nous avons connecté ZooKeeper aux applications internes d'Alibaba, il y avait un WIKI appelé "Ce que vous devez savoir sur l'intégration des applications ZooKeeper", qui traitait de la gestion des exceptions comme suit :

Si vous souhaitez choisir quoi les développeurs d'applications doivent savoir très clairement lorsqu'ils utilisent ZooKeeper ? Donc, sur la base de notre expérience de support précédente, il doit s’agir d’une gestion des exceptions.

Quand tout (hôte, disque, réseau, etc.) fonctionne correctement, l'application et ZooKeeper peuvent également bien fonctionner, mais malheureusement, nous serons confrontés à diverses surprises tout au long de la journée, et cela suit la loi de Murphy, de mauvaises choses inattendues toujours se produire lorsque vous vous inquiétez le plus pour eux.

Assurez-vous donc de bien comprendre les exceptions et les erreurs qui peuvent survenir dans ZooKeeper dans certains scénarios, assurez-vous de bien comprendre ces exceptions et erreurs et de savoir comment votre application gère correctement ces situations.

• ConnectionLossException et événement Disconnected

En termes simples, il s'agit d'une exception qui peut être récupérée dans la même session ZooKeeper (récupérable), mais le développeur de l'application doit être responsable de la restauration de l'application dans le bon état.

Il existe de nombreuses raisons pour cette exception, telles qu'une interruption du réseau entre la machine d'application et le nœud ZooKeeper, un temps d'arrêt du nœud ZooKeeper, le temps de GC complet côté serveur est trop long, ou même votre processus de candidature se bloque et le processus de candidature Temps de GC complet est trop long. La récupération est possible plus tard.

Pour comprendre cette exception, vous devez comprendre un problème typique dans les applications distribuées, comme indiqué ci-dessous :

Dans une requête client typique et une réponse du serveur, lorsque la longue connexion entre eux est interrompue, lorsque le client détecte cet événement flash , il se trouvera dans une situation embarrassante, c'est-à-dire qu'il ne pourra pas déterminer l'état de la requête à proximité lorsque l'événement s'est produit. Le serveur a-t-il reçu cette requête ? A-t-il été traité ? Comme cela ne peut pas être déterminé, lorsque le client se reconnecte au serveur, un point d'interrogation apparaît quant à savoir si la demande doit être réessayée (Réessayer).

Ainsi, lors de la gestion de l'événement de déconnexion de connexion, le développeur de l'application doit savoir quelle est la requête proche de l'interruption (c'est souvent difficile à juger), si la requête est idempotente et pour les requêtes métier dans le traitement des services côté serveur. La sémantique de « traiter une seule fois », « traiter au plus une fois » et « traiter au moins une fois » doivent être sélectifs et attendus.

Par exemple, si l'application reçoit une ConnectionLossException et que la requête précédente était une opération de création, alors si l'application détecte cette exception, une logique de récupération possible pour l'application consiste à déterminer si le nœud créé par la requête précédente existe déjà. Ne le créez pas s'il existe, sinon créez-le.

Pour un autre exemple, si l'application utilise Existe Watch pour surveiller l'événement de création d'un nœud inexistant, alors lors de l'exception ConnectionLossException, il est possible de rencontrer la situation où pendant cette période d'interruption, d'autres processus clients peuvent avoir été créés. le nœud a été supprimé et il a été supprimé, alors pour l'application en cours, l'événement de création du nœud concerné est manqué. Quel est l'impact de ce manque sur l'application ? Est-ce tolérable ou inacceptable ? Les développeurs d’applications doivent les évaluer et les traiter selon la sémantique métier.

• SessionExpiredException et événement SessionExpired

Le délai d'expiration de la session est une exception irrécupérable. Cela signifie que lorsque l'application détecte cette exception, l'application ne peut pas restaurer l'état de l'application dans la même session et doit rétablir une nouvelle session. le nœud temporaire associé à l'ancienne session peut également avoir expiré et le verrou qu'il possède peut avoir expiré. ...

En train d'essayer d'utiliser ZooKeeper pour la découverte de services par eux-mêmes, les amis d'Alibaba ont un jour résumé un partage d'expérience sur notre forum technologique intranet

à cela. L'article mentionne pertinemment :

... De nombreux pièges possibles ont été découverts au cours du processus de codage, selon une estimation approximative, plus de 80 % des personnes qui utilisent zk pour implémenter la gestion de cluster pour la première fois tomberont dans des pièges, certains pièges sont relativement cachés. ils n'apparaîtront qu'en cas de problèmes de réseau ou de scénarios anormaux, et ils risquent de ne pas être exposés avant longtemps...

Allez à gauche, allez à droite

L'utilisation d'Alibaba n'est-elle pas totalement gratuite ? Pas vraiment.

Tous ceux qui connaissent le système technique d'Alibaba savent qu'Alibaba gère en fait le plus grand cluster ZooKeeper en Chine, avec une échelle globale de près d'un millier de nœuds de service ZooKeeper.

Dans le même temps, le middleware Alibaba maintient également une branche de code de ZooKeeper, TaoKeeper, qui est orientée vers la production à grande échelle, est hautement disponible et plus facile à surveiller et à exploiter. Basée sur notre pratique d'utilisation de ZooKeeper dans diverses entreprises. lignes et production au cours des 10 dernières années, si vous utilisez une expression pour évaluer ZooKeeper, alors nous pensons que ZooKeeper devrait être « le roi de la coordination pour le Big Data » !

Il joue un rôle irremplaçable dans des scénarios tels que les verrous distribués à gros grain, la sélection de maître distribué, la commutation haute disponibilité active-veille, etc. qui ne nécessitent pas de prise en charge TPS élevée, et ces besoins sont souvent concentrés dans le big data , tâches hors ligne, etc. Dans le domaine des affaires, en raison du domaine du Big Data, il est important de segmenter les ensembles de données, et la plupart du temps, ces ensembles de données sont divisés en tâches et traités en parallèle par plusieurs processus/threads. , il y a toujours des points où ces tâches et processus doivent être unifiés et coordonnés. À l'heure actuelle, ZooKeeper Un endroit pour jouer un rôle énorme.

Cependant, dans le lien de transaction du scénario de transaction, il existe des lacunes naturelles dans l'accès aux principales données de l'entreprise, la découverte de services à grande échelle, la surveillance de l'état à grande échelle, etc. Nous devrions faire de notre mieux pour éviter d'introduire ZooKeeper dans ces scénarios. Dans la production d'Alibaba En pratique, les applications doivent procéder à une évaluation stricte des scénarios, de la capacité et des exigences SLA lorsqu'elles postulent à l'utilisation de ZooKeeper.

Vous pouvez donc utiliser ZooKeeper, mais allez à gauche pour le big data, à droite pour les transactions, à gauche pour la coordination distribuée et à droite pour la découverte de services.

Conclusion

Merci pour votre patience en lisant jusqu'ici, je pense que vous avez compris que nous n'écrivons pas cet article pour nier complètement ZooKeeper, mais uniquement en nous basant sur la production de servitisation à grande échelle par Alibaba dans le passé. 10 ans. En pratique, nous résumerons notre expérience et nos leçons dans la conception et l'utilisation de centres de découverte et d'enregistrement de services. Nous espérons inspirer et aider l'industrie sur la façon de mieux utiliser ZooKeeper et de mieux concevoir ses propres centres d'enregistrement de services. Enfin, tous les chemins mènent à Rome, et j'espère sincèrement que votre centre d'inscription verra le jour directement à Rome.

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!