Annuaire d'articles
- Question 1: Parlez de l'enregistrement du service et de la découverte du service?
- Réponse 1:
- Question2: Qu'en est-il de "API Gateway / API Gateway"?
- Réponse2:
- Question3: Présentez brièvement le centre de configuration de l'architecture de microservice?
- Réponse3:
- Question4: Décrivez brièvement la planification des événements (kafka)?
- Réponse4:
- Question5: Une brève introduction au suivi des services (débutant-détective)?
- Réponse5:
- Question6: Quel est le fusible de service (Hystrix)?
- Réponse6:
Les blogs axés sur les entretiens sont présentés dans un style Q / A.
Question 1: Parlez de l'enregistrement du service et de la découverte du service?
Réponse 1:
L'enregistrement de service consiste à tenir un registre, qui gère toutes les adresses de service dans le système. Lorsque le nouveau service est démarré, il avoue ses informations d'adresse au registre. La partie utilisatrice du service demande directement l'adresse du fournisseur de services au registre. Il existe de nombreux outils pour l'enregistrement des services, tels que ZooKeeper, Consul, Etcd et eureka de Netflix. Il existe deux formes d'enregistrement de service: l'enregistrement client et l'enregistrement tiers.
Inscription client (zookeeper) L'
inscription client est le service lui-même responsable de l'inscription et de l'annulation. Lorsque le service démarre, enregistrez-vous auprès du centre d'inscription et annulez votre inscription lorsque le service se déconnecte. Pendant cette période, vous devez toujours garder le rythme avec le centre d'inscription. Le rythme cardiaque ne doit pas être effectué par le client, mais peut également être géré par le centre d'inscription (ce processus est appelé Tanhuo). L'inconvénient de cette méthode est que le travail d'enregistrement est couplé au service, et différentes langues doivent implémenter un ensemble de logique d'enregistrement.
L'inscription du client est indiquée ci-dessous:
Pour l'explication ci-dessus:
le service qui doit s'enregistrer, Sevice, traite directement avec le registre de service Service Register, il existe trois méthodes entre les deux, y compris register register (), heartbeat (), unregister / unregister (), ici, Le service d'enregistrement doit être couplé avec le centre d'enregistrement, qui ne répond pas au concept de couplage bas, et dépend de l'enregistrement tiers (registre de service indépendant).
Enregistrement par un tiers (registraire de service indépendant)
Un registraire de service indépendant est responsable de l'enregistrement et de l'annulation. Lorsque le service est démarré, le bureau d'enregistrement est notifié d'une manière ou d'une autre, puis le bureau d'enregistrement est chargé de lancer le travail d'enregistrement avec le registre. Dans le même temps, le centre d'inscription doit maintenir le rythme cardiaque avec le service. Lorsque le service n'est pas disponible, le service sera annulé au centre d'inscription. L'inconvénient de cette méthode est que le registraire doit être un système hautement disponible, sinon le travail d'enregistrement ne peut pas progresser.
L'inscription d'un tiers est indiquée ci-dessous:
Pour l'explication de la figure ci-dessus:
le service qui doit être enregistré, Sevice, interagit avec le service d'enregistrement tiers indépendant Registrar. Lorsque le service est démarré, le bureau d'enregistrement est notifié d'une certaine manière. Pendant cette période, le bureau d'enregistrement envoie une vérification du rythme cardiaque au service de service à une heure fixe.
De cette façon, le service Service peut accéder à sa propre logique métier, sans enregistrement supplémentaire, annulation supplémentaire, centre d'enregistrement du service de notification de pulsation en temps réel.
Le registraire de service indépendant interagit directement avec le registre de service Registre de service. Il existe trois méthodes entre les deux, notamment le registre de registre (), le battement de cœur () et le désenregistrement / le désenregistrement (). Lorsque le service est démarré, le registraire est averti et le registraire enregistre le service auprès du centre d'inscription du service. Après le démarrage du service, le registraire effectue une vérification des pulsations du service à intervalles. Si le service survit, il appelle heartbeat () pour signaler au centre d'inscription du service. Appelez unregsister () pour annuler le service au centre d'enregistrement du service.
Résumé: L'enregistrement tiers utilise un service indépendant, Registrar, pour séparer le service d'enregistrement du centre d'enregistrement, ce qui est conforme au concept de couplage bas. Bien sûr, cette méthode nécessite un système de registraire hautement disponible supplémentaire par rapport à l'enregistrement client.
Découverte du client La découverte du
client signifie que le client est responsable de l'interrogation des adresses de service disponibles et de l'équilibrage de charge. Cette méthode est la plus pratique et la plus directe, et elle est également pratique pour l'équilibrage de charge. De plus, une fois qu'un service s'est avéré indisponible, il est immédiatement remplacé par un autre, ce qui est très simple. L'inconvénient est également le travail répété en plusieurs langues, chaque langue implémentant la même logique.
La découverte du client est illustrée ci-dessous:
Pour l'explication de la figure ci-dessus: Le
service en cours d'exécution Sevice agit comme un client client, utilise directement la demande http pour traiter avec le serveur et interroge directement les adresses de service disponibles pour réaliser l'équilibrage de charge. La conception est simple de cette manière, mais le service client et le serveur sont couplés ensemble, ce qui ne correspond pas au concept de conception de faible couplage et dépend de l'enregistrement du serveur.
Découverte de serveur La découverte de
serveur nécessite des services de routeur supplémentaires. Les demandes sont d'abord envoyées au routeur, puis le routeur est responsable de l'interrogation des services et de l'équilibrage de charge. Bien que cette méthode ne présente pas les défauts découverts par le client, son défaut est d'assurer la haute disponibilité du routeur.
La découverte du serveur est illustrée ci-dessous:
Pour l'explication de la figure ci-dessus: le
service en cours d'exécution Sevice agit comme un client client et communique avec le routeur via l'utilisation des demandes de demande. Le routeur est responsable de l'interrogation des services et de l'équilibrage de la charge. Le service Service ne pose plus de questions sur l'interrogation des services et l'équilibrage de la charge.
Résumé: L'enregistrement du serveur, la requête du routeur au lieu du serveur de requête du client, réduisent la charge sur le service client, bien sûr, cette méthode nécessite un système de routeur hautement disponible supplémentaire par rapport à la découverte du client.
Question2: Qu'en est-il de "API Gateway / API Gateway"?
Réponse2:
API Gateway est un serveur, et il peut également être considéré comme le seul nœud entrant dans le système. Ceci est similaire au modèle de façade dans le modèle de conception orienté objet. La passerelle API encapsule l'architecture du système interne et fournit des API à divers clients. Il peut également avoir d'autres fonctions, telles que l'autorisation, la surveillance, l'équilibrage de charge, la mise en cache, le partage et la gestion des demandes et le traitement des réponses statiques. La figure suivante montre une passerelle API qui s'adapte à l'architecture actuelle.
La figure ci-dessus montre que la passerelle API doit surveiller presque tous les autres modules commerciaux, service de panier, service de panier, service de magasinage, service d'inventaire, service de liste d'inventaire, service de recommandation, service de recommandation, service de commande, service de révision, service de révision, catalogue de produits service type de produit service.
API Gateway est responsable du transfert des demandes, de la synthèse et de la conversion des protocoles. Toutes les demandes du client doivent d'abord passer par la passerelle API, puis acheminer ces demandes vers les microservices correspondants. API Gateway appelle souvent plusieurs microservices pour traiter une demande et agréger les résultats de plusieurs services. Il peut convertir entre des protocoles Web et des protocoles non compatibles avec le Web utilisés en interne, tels que le protocole HTTP et le protocole WebSocket.
Transfert de demande Le transfert de
service consiste principalement à transmettre la charge de la demande du client d'installer des microservices à différents services.
Fusion de réponse Fusionne
le travail qui doit appeler plusieurs interfaces de service dans l'entreprise en un seul appel pour fournir des services unifiés au monde extérieur.
Conversion de protocole L'
objectif est de prendre en charge la conversion de protocole entre SOAP, JMS et Rest.
La conversion des données
se concentre sur la prise en charge des capacités de conversion de format de message entre XML et Json (facultatif).
Certification de sécurité
- Contrôle d'accès client basé sur des jetons et stratégie de sécurité
- Transmission des données et cryptage des messages, décryptage vers le serveur, vous devez avoir un package d'agent SDK distinct sur le client
- Cryptage de transmission basé sur HTTP, prise en charge des certificats numériques client et serveur
- Authentification de sécurité de service basée sur OAuth2.0 (code d'autorisation, client, mode mot de passe, etc.)
Question3: Présentez brièvement le centre de configuration de l'architecture de microservice?
Réponse3:
Le centre de configuration est généralement utilisé comme configuration des paramètres du système et doit répondre aux exigences suivantes: acquisition efficace, détection en temps réel et accès distribué.
Exemple:
Le diagramme d'architecture mis en œuvre par le centre de configuration de zookeeper est illustré ci-dessous. La méthode de chargement des données en mémoire est utilisée pour résoudre le problème de l'acquisition efficace, et la perception en temps réel est réalisée en utilisant le mécanisme de surveillance des nœuds zookeeper.
La figure ci-dessus montre que le gardien du centre de configuration observera tout changement dans les informations par l'observateur observateur, puis notifiera la couche logique métier, puis la couche d'accès.
Classification des données du centre de configuration
La figure ci-dessus montre que le centre de configuration (centre de configuration, centre de configuration de nom complet) comprend la configuration de service, divers commutateurs et la configuration métier.
La configuration du service comprend la configuration du service de base de données, la configuration du service de file d'attente, la configuration du service de cache, etc.;
divers types de commutateurs comprennent divers commutateurs fonctionnels, divers types de commutateurs commerciaux et divers types de commutateurs de service;
configuration commerciale comme indiqué ci-dessus, y compris le module A application src A + app src A2), module B application src B (app src B1 + app src B2), etc.
Question4: Décrivez brièvement la planification des événements (kafka)?
Réponse4:
Planification unifiée des services de messagerie et des événements, kafka couramment utilisé, activemq, etc.
Question5: Une brève introduction au suivi des services (débutant-détective)?
Réponse5:
Comme le nombre de microservices continue d'augmenter, il est nécessaire de suivre la propagation d'une demande d'un microservice au microservice suivant. SpringCloud Sleuth doit résoudre ce problème. Il introduit un ID unique dans le journal pour garantir la cohérence entre les appels de microservices Sexe, afin que vous puissiez suivre la façon dont une demande est transmise d'un microservice à l'autre.
- Afin de réaliser le suivi des demandes, lorsque la demande est envoyée au point de terminaison d'entrée du système distribué, seul le cadre de suivi des services doit créer un identifiant de suivi unique pour la demande, et le cadre continue de toujours transmettre l'identifiant unique lors de la circulation au sein du système distribué. Tant qu'il n'est pas retourné au demandeur, cet identifiant unique est l'ID de trace mentionné précédemment. Grâce à l'enregistrement de l'ID de trace, nous pouvons corréler tous les journaux de processus de demande.
- Afin de compter le délai de chaque unité de traitement, lorsque la demande atteint chaque composant de service, ou lorsque la logique de traitement atteint un certain état, son début, son processus spécifique et sa fin sont également marqués par un identifiant unique. Cet identifiant est mentionné dans notre article précédent. Pour chaque plage, l'ID de plage doit avoir deux nœuds: début et fin. En enregistrant l'horodatage de la plage de début et de la plage de fin, la temporisation de la plage peut être comptée. Outre l'enregistrement d'horodatage, Il peut également contenir d'autres métadonnées, telles que: nom de l'événement, demande d'informations, etc.
- Dans l'exemple de démarrage rapide, nous avons facilement implémenté l'accès aux informations de suivi au niveau du journal, grâce à la mise en œuvre du composant Spring-Cloud-Starter-Sleuth. Dans l'application Spring Boot, après avoir introduit la dépendance Spring-cloud-starter-sleuth dans le projet, elle créera automatiquement un mécanisme de suivi pour chaque canal de communication pour l'application actuelle, tel que:
(1) Via RabbitMQ, Kafka (ou autre) Tout middleware de message implémenté par n'importe quel classeur Spring Cloud Stream).
(2) La demande est passée par l'agent Zuul.
(3) Demande lancée via RestTemplate.
Question6: Quel est le fusible de service (Hystrix)?
Réponse6:
L'architecture de microservices comporte généralement plusieurs appels de couche de service. L'échec du service de base peut entraîner une défaillance en cascade, qui à son tour entraîne l'indisponibilité de l'ensemble du système. Ce phénomène est appelé effet d'avalanche de service. L'effet avalanche de service est un processus dans lequel le "consommateur de service" devient indisponible en raison de l'indisponibilité du "prestataire de services" et agrandit progressivement l'indisponibilité.
Le principe du fusible est très simple, tout comme un protecteur de surcharge de puissance. Il peut atteindre une défaillance rapide. S'il détecte de nombreuses erreurs similaires dans un laps de temps, il forcera ses multiples appels ultérieurs à échouer rapidement et à ne plus accéder au serveur distant, empêchant ainsi l'application d'essayer continuellement d'effectuer des opérations qui peuvent échouer. , Afin que l'application puisse continuer à s'exécuter sans attendre que l'erreur soit corrigée, ou perdre du temps CPU à attendre longtemps. Le fusible peut également permettre à l'application de diagnostiquer si l'erreur a été corrigée. Si elle a été corrigée, l'application essaiera de rappeler l'opération.
Le disjoncteur du mécanisme du disjoncteur Hystrix
est bien compris. Lorsque le nombre de défaillances du service principal de demande de commande Hystrix dépasse un certain pourcentage (par défaut 50%), le disjoncteur passe à l'état ouvert (ouvert). À ce stade, toutes les demandes échouent directement et ne sont pas envoyées. Vers le service principal. Après que le disjoncteur reste à l'état ouvert pendant une période de temps (5 secondes par défaut), il passe automatiquement à l'état semi-ouvert (DEMI-OUVERT). À ce stade, l'état de retour de la prochaine demande sera évalué. Retour à l'état fermé (FERMÉ), sinon revenir à l'état ouvert (OUVERT). Le disjoncteur de Hystrix est comme un fusible dans notre circuit domestique. Une fois que le service principal n'est pas disponible, le disjoncteur coupera directement la chaîne de demande pour éviter d'envoyer un grand nombre de demandes invalides Affecte le débit du système et le disjoncteur a la capacité de s'auto-détecter et de récupérer.