questions d'entretien chez springcloud alibaba

Qu'est-ce que Nacos ?

Produit open source d'Alibaba, il s'agit d'une solution complète pour la découverte de services, la gestion de la configuration et la gouvernance des services dans l'architecture des microservices.

(utilisé pour implémenter le centre de configuration et le registre des services)

Présentation des fonctionnalités de Nacos

Découverte de services et surveillance de l'état des services (facilite l'enregistrement et la découverte d'autres services par les services via des interfaces DNS ou HTTP, et fournit également des vérifications de l'état en temps réel des services pour empêcher les demandes à des hôtes ou des instances de service non sains.)

La découverte de service basée sur DNS et RPC est prise en charge. Une fois que le fournisseur de services a enregistré le service à l'aide du SDK natif, d'OpenAPI ou d'un agent TODO indépendant, le client du service peut utiliser DNS TODO ou HTTP&API pour trouver et découvrir le service.
Nacos fournit des contrôles de santé en temps réel sur les services, empêchant les requêtes vers des hôtes ou des instances de service non sains. Nacos prend en charge les vérifications de l'état de la couche de transport (PING ou TCP) et de la couche d'application (telles que HTTP, MySQL, définies par l'utilisateur). Pour le bilan de santé des services dans des environnements cloud complexes et des environnements de topologie de réseau (tels que VPC, réseaux de périphérie, etc.), Nacos propose deux modes de bilan de santé : le mode de rapport d'agent et la détection active du serveur. Nacos fournit également un tableau de bord de vérification de l'état unifié pour vous aider à gérer la disponibilité des services et le trafic en fonction de l'état de santé.

Service de configuration dynamique

Gérez la configuration des applications et la configuration des services pour tous les environnements de manière centralisée, externalisée et dynamique.
Élimine le besoin de redéployer les applications et les services lorsque la configuration change, ce qui rend la gestion de la configuration plus efficace et agile.
La gestion centralisée de la configuration facilite la mise en œuvre de services sans état et facilite la mise à l'échelle élastique des services à la demande.
Fournit une interface utilisateur simple et facile à utiliser (exemple de console démo) pour aider à gérer toutes les configurations de service et d'application.
Nacos fournit également une série de fonctionnalités de gestion de configuration prêtes à l'emploi, notamment le suivi de la version de configuration, la version canari, la configuration de restauration en un clic et le suivi de l'état de la mise à jour de la configuration client, qui peuvent gérer plus en toute sécurité les changements de configuration dans les environnements de production et réduire le risque de changement de configuration.

Service DNS dynamique

Le service DNS dynamique prend en charge le routage pondéré, ce qui facilite la mise en œuvre de l'équilibrage de charge de niveau intermédiaire, des politiques de routage plus flexibles, le contrôle du trafic et des services de résolution DNS simples pour l'intranet du centre de données. Les services DNS dynamiques facilitent également la mise en œuvre de la découverte de services basée sur le protocole DNS, éliminant ainsi le risque de couplage aux API de découverte de services propriétaires du fournisseur.
Nacos fournit quelques API DNS simples TODO, le nom de domaine associé du service de gestion et la liste des IP:PORT disponibles

Les services et leur gestion des métadonnées

Gérer tous les services et métadonnées dans le centre de données du point de vue de la construction de la plate-forme de microservices, y compris la gestion de la description du service, du cycle de vie, de l'analyse des dépendances statiques du service, de l'état de santé du service, de la gestion du trafic du service, des politiques de routage et de sécurité et du service SLA Et le plus important statistiques métriques.

découverte de services

Dans l'architecture de microservices, un processus métier nécessite plusieurs microservices pour effectuer le traitement métier via des appels d'interface réseau. Le consommateur de services obtient l'adresse du fournisseur de services à partir du registre de services pour effectuer des appels à distance. Ce processus est appelé découverte de services.

Processus de découverte de service :
l'instance de service elle-même n'enregistre pas l'adresse réseau du producteur de service, et toutes les instances de service contiennent des clients de découverte de service.

Lorsque chaque service démarre, il signale son propre emplacement réseau au centre de découverte de service. Un registre de service sera formé à l'intérieur du centre de découverte de service. Le registre de service est la partie centrale de la découverte de service et est une base de données contenant les adresses réseau de toutes les instances de service.

Le client de découverte de service synchronise périodiquement le registre de service à partir du centre de découverte de service et le met en cache sur le client.

Lorsqu'un service doit être demandé, l'instance de service localise l'adresse réseau du service cible via le registre. S'il existe plusieurs adresses réseau pour le service cible, un algorithme d'équilibrage de charge est utilisé pour sélectionner une instance de service parmi plusieurs instances de service, puis une demande est envoyée.

En résumé, dans un environnement de microservices, étant donné que l'adresse réseau de l'instance en cours d'exécution du service change constamment et que le nombre d'instances de service change de manière dynamique, il est impossible d'utiliser un fichier de configuration fixe pour enregistrer l'adresse réseau du fournisseur de services, et la découverte dynamique des services doit être utilisée. Des mécanismes sont utilisés pour parvenir à une prise de conscience mutuelle entre les microservices. Chaque instance de service rapportera sa propre adresse réseau, de sorte que le centre de service forme un registre de service complet, et chaque instance de service obtiendra l'adresse réseau du service cible via le centre de découverte de service, réalisant ainsi le mécanisme de découverte de service.

Processus de mise en œuvre:

Le fournisseur de services s'enregistre dans le registre de services et le
consommateur de services obtient l'adresse de service à partir du registre et
passe un appel à distance

Comparaison des produits de découverte de services

Actuellement, il existe de nombreux centres de découverte de services sur le marché : Nacos, Eureka, Consul et Zookeeper.

Comparer les articles	Nef	Eurêka	Consul	Gardien de zoo
Protocole de conformité	Prise en charge des modèles AP et CP	Modèle PA	Modèle PC	Modèle PC
Examen de santé	TCP/HTTP/MYSQL/Client Beat	Battement de client	TCP/HTTP/gRPC/Cmd	Rester en vie
stratégie d'équilibrage de charge	pondération/métadonnées/Sélecteur	Ruban	fabio	-
Protection contre les avalanches	Avoir	Avoir	rien	rien
Se déconnecter automatiquement de l'instance	Support	Support	pas de support	Support
accord d'accès	HTTP/DNS	HTTP	HTTP/DNS	TCP
Prise en charge de la surveillance	Support	Support	Support	Support
Plusieurs centres de données	Support	Support	Support	pas de support
Synchronisation entre les registres	Support	pas de support	Support	pas de support
Intégration SpringCloud	Support	Support	Support	pas de support
Intégration Dubbo	Support	pas de support	pas de support	Support
intégration k8s	Support	pas de support	Support	pas de support

Modèle de données de découverte de service

Conception d'isolation d'espace de noms

L'espace de noms est utilisé pour isoler la granularité des locataires.L'un des scénarios courants d'espace de noms est l'isolation de différents environnements, comme l'isolation des ressources (telles que les configurations et les services) entre les environnements de développement et de test et les environnements de production.

Du point de vue d'un locataire (utilisateur), s'il existe plusieurs ensembles d'environnements différents, à ce stade, différents espaces de noms peuvent être créés en fonction de l'environnement spécifié pour obtenir l'isolation de plusieurs environnements. S'il existe trois environnements différents pour le développement, les tests et la production, l'utilisation d'un ensemble de clusters nacos peut générer respectivement les trois espaces de noms différents suivants.

Du point de vue de plusieurs locataires (utilisateurs), chaque locataire (utilisateur) peut avoir son propre espace de noms, et les données de configuration et les données de service enregistrées de chaque locataire (utilisateur) appartiendront à son propre espace de noms.

gestion de l'espace de noms

L'espace de noms est utilisé pour isoler plusieurs environnements (tels que le développement, les tests, la production), et la valeur de la même configuration (telle que la source de données de la base de données) pour chaque application dans différents environnements est différente. Par conséquent, nous devons planifier le processus et l'environnement réels de R&D des projets d'entreprise. Si une société de logiciels dispose de trois environnements pour le développement, les tests et la production, nous devons établir trois espaces de noms pour ces trois environnements.

Une fois tous les espaces de noms établis, toutes les pages des modules de gestion de la configuration et de gestion des services contiendront des boutons d'onglet pour changer d'espaces de noms (environnements) ;

Avis:

Namesace est public, qui est un espace réservé de nacos. Si vous avez besoin de créer votre propre espace de noms, n'utilisez pas le même nom que public, et nommez-le avec un nom avec une sémantique spécifique dans un scénario d'entreprise réel, afin de ne pas faire il est difficile de distinguer littéralement quel espace de noms.

Lors de l'écriture d'un programme pour obtenir un jeu de configuration, le paramètre d'espace de noms spécifié doit être rempli avec l'ID de l'espace de noms, pas le nom

modèle de données

Le modèle de données extrait par Nacos après des années d'expérience de production chez Alibaba est un modèle à trois niveaux de service-cluster-instance, qui peut essentiellement répondre au stockage des données et à la gestion des services dans tous les scénarios.

Service : Fonctions logicielles fournies en externe, accédant à des interfaces prédéfinies via le réseau.

Instance : un processus avec une adresse réseau accessible (IP:Port) qui fournit un ou plusieurs services. Lorsqu'un service est démarré, une instance de service est générée.

Méta-informations : informations de description des données Nacos (telles que la configuration et le service), telles que la version du service, le poids, la stratégie de reprise après sinistre, la stratégie d'équilibrage de charge, la configuration de l'authentification, diverses étiquettes personnalisées (étiquette),

Du point de vue de l'action, il est divisé en : méta-informations de niveau de service, méta-informations de cluster et méta-informations d'instance.

Cluster : ensemble d'instances de service. Les instances de service forment un cluster par défaut. Le cluster peut être subdivisé en fonction des besoins. L'unité de division peut être un cluster virtuel. Seules les instances d'un même cluster peuvent se percevoir.

Grâce à la configuration de l'espace de noms, du service et du cluster (DEFAULT), l'application décrit dans quel environnement (tel que l'environnement de développement) le service s'enregistre auprès de quel cluster.
Exemple :
Spécifiez l'identifiant de l'espace de noms : a1f8e863-3117-48c4-9dd3-e9ddc2af90a8 (faites attention à définir l'identifiant de l'espace de noms en fonction de votre propre environnement)
Spécifiez le nom du cluster : DEFAULT signifie le cluster par défaut, vous pouvez le laisser vide

spring:
application:
name: transaction-service
cloud:
nacos:
discovery:
server-addr: 127.0.0.1:8848 # Espace de noms d'adresse de registre
 : a1f8e863-3117-48c4-9dd3-e9ddc2af90a8 #Nom du
cluster d'environnement de développement : DEFAULT #Cluster par défaut, Ne pas remplir

Utiliser Nacos comme centre de configuration

En plus de réaliser l'enregistrement et la découverte de services, Nacos intègre également des fonctions de centre de configuration. Grâce à la fonction de gestion de la configuration de Nacos, nous pouvons stocker de manière centralisée toutes les configurations dans l'ensemble du système d'architecture de Nacos. Les avantages de ceci sont également mentionnés dans l'introduction de Spring Cloud Config dans les tutoriels précédents, principalement dans les points suivants :

La configuration multi-environnement séparée permet des droits de gestion plus flexibles et une sécurité accrue.
L'emballage de l'application est plus pur, afin de réaliser les caractéristiques d'un package et de plusieurs opérations.
Configurez l'actualisation dynamique (vous pouvez ajouter l'annotation @RefreshScope à la classe qui lit la configuration pour obtenir une actualisation dynamique)
et configurez la restauration (vous pouvez afficher les enregistrements de modification du fichier de configuration dans la version historique et vous pouvez choisir la version correspondante à restaurer ).
Gestion de la configuration Nacos, le niveau de base utilise DataId et Group pour localiser le contenu de la configuration, en plus d'ajouter de nombreuses autres fonctions de gestion.

Principe de mise en œuvre du centre de configuration distribué

L'application locale lit le fichier du centre de configuration distribué dans le cloud (une connexion persistante est établie lors de sa première lecture). Une
fois que l'application locale a lu le fichier de configuration, la jvm locale et le disque dur en mettront une copie en cache.
Appliqué localement côté serveur du centre de configuration distribué pour maintenir une longue connexion
lorsque notre fichier de configuration change (à en juger par le numéro de version | MID). Avertissez l'application locale du résultat de la modification pour actualiser le fichier de configuration à temps.

Pour la gestion de la configuration Nacos, un ensemble de configuration peut être localisé via l'espace de noms, le groupe et l'ID de données.

Jeu de configuration (ID de données) :
dans le système, un fichier de configuration est généralement un jeu de configuration, et un jeu de configuration peut contenir diverses informations de configuration du système, telles que : un jeu de configuration peut contenir des sources de données, des pools de threads, des niveaux de journalisation, etc. élément de configuration. Chaque jeu de configuration peut définir un nom significatif, qui est l'ID du jeu de configuration, c'est-à-dire l'ID de données.

Élément de configuration :

Le contenu de configuration contenu dans le jeu de configuration est l'élément de configuration. Il représente un paramètre configurable spécifique et sa plage, généralement sous la forme clé=valeur. Comme nous configurons habituellement le niveau de sortie du journal du système (logLevel=INFO|WARN|ERROR) est un élément de configuration.

Groupe de configuration (Groupe) : un
groupe de configuration est un regroupement d'ensembles de configuration, représenté par une chaîne significative (telle que Acheter ou Échanger). Différents groupes de configuration peuvent avoir le même ensemble de configuration (ID de données). Lors de la création d'une configuration sur Nacos, si le nom du groupe de configuration n'est pas renseigné, le nom du groupe de configuration sera par défaut DEFAULT_GROUP. Scénarios courants de regroupement de configuration : il peut être utilisé pour distinguer différents projets ou applications. Par exemple, l'ensemble de configuration du système de gestion des étudiants peut définir un groupe comme suit : STUDENT_GROUP.

Espace de noms (Namespace):
L'espace de noms peut être utilisé pour l'isolation de la configuration de différents environnements. Par exemple, l'environnement de développement, l'environnement de test et l'environnement de production peuvent être isolés car leurs configurations peuvent être différentes, ou différents utilisateurs peuvent être isolés. Différents développeurs utilisent le même nacos pour gérer leurs propres configurations, qui peuvent être isolées par un espace de noms. Des groupes de configuration ou des ensembles de configuration portant le même nom peuvent exister dans différents espaces de noms.

Utilisation en pratique courante :

Nacos définit abstraitement les concepts d'espace de noms, de groupe et d'ID de données. Ce que ces concepts représentent dépend de ce que nous en pensons, par exemple :

Espace de noms : représente différents environnements, tels que les environnements de développement, de test et de production ;

Groupe : représente un projet ;

DataId : Il y a souvent plusieurs projets sous chaque projet, et chaque jeu de configuration (DataId) est le fichier de configuration principal d'un projet

SpringCloud LoadBalancer (ci-après dénommé SCL)

La solution originale d'équilibrage de charge côté client de SpringCloud, Ribbon, a été abandonnée et remplacée par SpringCloud LoadBalancer.
Les appels de microservices internes dans Spring Cloud sont des requêtes HTTP par défaut, principalement via les trois API suivantes :

1. RestTemplate : API http synchrone

2. WebClient : API http réactive asynchrone

3. Encapsulation de client tripartite, telle que openfeign,
   si la dépendance spring-cloud-loadbalancer est ajoutée au projet et que la configuration est activée, la fonctionnalité d'équilibrage de charge sera automatiquement ajoutée au bean concerné.

4. Pour RestTemplate, Interceptor est automatiquement ajouté à tous les beans RestTemplate annotés avec @LoadBalanced pour ajouter des fonctionnalités d'équilibrage de charge.

5. Pour WebClient, ReactorLoadBalancerExchangeFilterFunction est automatiquement créé, et nous pouvons ajouter la fonctionnalité d'équilibrage de charge en ajoutant ReactorLoadBalancerExchangeFilterFunction.

6. Pour les clients tiers, nous n'avons généralement pas besoin de configurer quoi que ce soit de plus.

(cloud de printemps 2020) Round robin intégré, stratégie d'équilibrage de charge aléatoire, stratégie de round robin par défaut.

Les stratégies d'équilibrage de charge au niveau du service peuvent être spécifiées via l'annotation LoadBalancerClient

@LoadBalancerClient(valeur = "demo-provider", configuration = RandomLoadbalancerConfig.class)

public class RandomLoadbalancerConfig {
	@Bean
	public ReactorLoadBalancer<ServiceInstance> reactorServiceInstanceLoadBalancer(Environment environment,
			LoadBalancerClientFactory loadBalancerClientFactory) {
		String name = environment.getProperty(LoadBalancerClientFactory.PROPERTY_NAME);
		return new RandomLoadBalancer(
				loadBalancerClientFactory.getLazyProvider(name, ServiceInstanceListSupplier.class), name);
	}
}

Stratégie d'équilibrage de charge personnalisée

Comme on peut le voir ci-dessus, la stratégie d'équilibrage de charge prise en charge par SCL est toujours inférieure à celle de Ribbon, et les développeurs doivent l'implémenter eux-mêmes. Heureusement, SCL fournit une API pratique pour une expansion et une utilisation faciles. Voici une démonstration de la personnalisation d'une stratégie d'équilibrage de charge en niveaux de gris basée sur les métadonnées du registre.

Définir la politique d'équilibrage de charge en niveaux de gris

@Slf4j
public class GrayRoundRobinLoadBalancer extends RoundRobinLoadBalancer {

	private ObjectProvider<ServiceInstanceListSupplier> serviceInstanceListSupplierProvider;

	private String serviceId;

	@Override
	public Mono<Response<ServiceInstance>> choose(Request request) {
		ServiceInstanceListSupplier supplier = serviceInstanceListSupplierProvider
				.getIfAvailable(NoopServiceInstanceListSupplier::new);
		return supplier.get(request).next().map(serviceInstances -> getInstanceResponse(serviceInstances, request));
	}

	Response<ServiceInstance> getInstanceResponse(List<ServiceInstance> instances, Request request) {

		// 注册中心无可用实例 抛出异常
		if (CollUtil.isEmpty(instances)) {
			log.warn("No instance available {}", serviceId);
			return new EmptyResponse();
		}

		DefaultRequestContext requestContext = (DefaultRequestContext) request.getContext();
		RequestData clientRequest = (RequestData) requestContext.getClientRequest();
		HttpHeaders headers = clientRequest.getHeaders();

		String reqVersion = headers.getFirst(CommonConstants.VERSION);
		if (StrUtil.isBlank(reqVersion)) {
			return super.choose(request).block();
		}

		// 遍历可以实例元数据，若匹配则返回此实例
		for (ServiceInstance instance : instances) {
			NacosServiceInstance nacosInstance = (NacosServiceInstance) instance;
			Map<String, String> metadata = nacosInstance.getMetadata();
			String targetVersion = MapUtil.getStr(metadata, CommonConstants.VERSION);
			if (reqVersion.equalsIgnoreCase(targetVersion)) {
				log.debug("gray requst match success :{} {}", reqVersion, nacosInstance);
				return new DefaultResponse(nacosInstance);
			}
		}
		// 降级策略，使用轮询策略
		return super.choose(request).block();
	}
}

Injectez la stratégie d'équilibrage de charge en niveaux de gris
@LoadBalancerClient(value = "demo-provider", configuration = GrayRoundLoadbalancerConfig.class) pour le client

Optimisation de l'injection de stratégies d'équilibrage de charge
Comme mentionné ci-dessus, il est très peu pratique d'injecter manuellement toutes les stratégies de charge personnalisées via LoadBalancerClient. Nous pouvons nous référer à la logique d'injection par lots de LoadBalancerClients pour construire notre propre BeanRegistrar

public class GrayLoadBalancerClientConfigurationRegistrar implements ImportBeanDefinitionRegistrar {

	@Override
	public void registerBeanDefinitions(AnnotationMetadata metadata, BeanDefinitionRegistry registry) {
		Field[] fields = ReflectUtil.getFields(ServiceNameConstants.class);

		// 遍历服务名称，注入支持灰度策略的负载均衡器
		for (Field field : fields) {
			Object fieldValue = ReflectUtil.getFieldValue(ServiceNameConstants.class, field);
			registerClientConfiguration(registry, fieldValue, GrayLoadBalancerClientConfiguration.class);
		}
	}
}