Entretien technique sur Spring Cloud et les microservices

Questions d'entretien sur Spring Cloud

1. Quels sont les avantages des microservices ?

Inconvénients des applications monolithiques :

  • Extensibilité limitée : Les applications monolithiques doivent être étendues globalement, même si seul un composant spécifique nécessite plus de ressources.
  • Maintenance complexe : La taille et la complexité croissantes rendent la compréhension, la maintenance et les mises à jour plus difficiles.
  • Risque élevé : Une erreur dans un composant peut entraîner la défaillance de l'ensemble du système.
  • Stack technologique figé : Utilisation d'une stack uniforme limitant l'adoption de nouvelles technologies.
  • Collaboration difficile : Un seul dépôt de code peut causer des conflits au sein de grandes équipes.

Avantages des architectures microservices :

  • Scalabilité indépendante : Chaque service peut être mis à l'échelle séparément selon les besoins.
  • Développement agile : Déploiement indépendant permettant des itérations rapides.
  • Tolérance aux pannes : L'isolation des services empêche la propagation des défaillances.
  • Flexibilité technologique : Choix de technologies adaptées à chaque service.
  • Maintenance autonome : Mise à jour indépendante réduisant les risques de déployment.
  • Collaboration optimisée : Équipes spécialisées sur des périmètres fonctionnels.

2. Quels sont les défis des microservices ?

Complexité opérationnelle :

  • Coûts d'infrastructure : Multiplication des instances, orchestration, équilibrage de charge.
  • Gestion de la configuration : Coordonner les configurations entre services multiples.
  • Transactions distribuées : Assurer la cohérence des données entre services.

Surveillance et débogage :

  • Traces distribuées : Nécessité d'outils comme Zipkin pour suivre les requêtes inter-services.
  • Monitoring centralisé : Agréger les métriques de santé des différents services.

Déploiement et CI/CD :

  • Pipeline d'automatisation : Orchestration des builds et déploiements multiples.
  • Versioning : Gestion des compatibilités entre versions des services.

3. Solutions open-source populaires pour les microservices

  1. Dubbo : Framework RPC performant initialement développé par Alibaba, optimisé pour les appels inter-services à faible latence.
  2. Spring Cloud Netflix : Suite d'outils basée sur les composants Netflix OSS (Eureka, Hystrix, Zuul) historiquement intégrée à Spring Cloud.
  3. Spring Cloud Alibaba : Écosystème intégrant Nacos, Sentinel et RocketMQ pour des scénarios cloud-native.

4. Comparaison des solutions

Fonctionnalité Dubbo Spring Cloud Netflix Spring Cloud Alibaba
Découverte de services Nacos/ZooKeeper Eureka/Consul Nacos
Équilibrage de charge Stratégies natives Ribbon Ribbon/Dubbo
Circuit breaker Sentinel Hystrix Sentinel/Resilience4j
API Gateway Higress/APISIX Zuul/Gateway Spring Cloud Gateway
Transactions distribuées Seata Non supporté Seata

5. Composants clés des microservices

  • Registre de services : Eureka, Consul, Nacos (stockage des métadonnées des instances).
  • Configuration dynamique : Spring Cloud Config, Nacos Config (centralisation des paramètres).
  • Communication : REST (Feign) ou RPC (Dubbo, gRPC).
  • Passerelle API : Spring Cloud Gateway (routage, sécurité, limitation de débit).
  • Résilience : Hystrix, Sentinel (contrôle de flux, dégradation).
  • Observabilité : Sleuth+Zipkin, Skywalking (traces distribuées).

6. Rôle d'un registre de services

Centralise l'enregistrement des instances de services et permet :

  • Découverte dynamique : Les clients localisent les endpoints disponibles.
  • Routage intelligent : Distribution des requêtes selon des politiques (round-robin, latence...).
  • Détection de santé : Surveillance des heartbeats pour exclure les instances défaillantes.

7. Options de registres pour Spring Cloud

  • Eureka : Solution historique AP, adaptée aux environnements dynamiques.
  • Consul : Offre CP/CA, intégration avec les services de configuration et de clé-valeur.
  • Nacos : Combinaison de registre de services et de configuration dynamique.
  • ZooKeeper : Garantie CP via le protocole ZAB, adapté aux systèmes critiques.

8. Différences entre Eureka, ZooKeeper et Nacos

Caractéristique Eureka ZooKeeper Nacos
Consistance AP CP AP/CP configurable
Protocole HTTP TCP (ZAB) HTTP/DNS
Auto-protection Oui Non Oui

9. Fonctionnement interne d'Eureka

  1. Enregistrement : Les instances s'enregistrent au démarrage avec leurs métadonnées.
  2. Renouvellement : Mécanisme de heartbeat pour signaler la disponibilité.
  3. Réplication : Les nœuds échangent leurs registres pour assurer la cohérence.
  4. Découverte : Les clients récupèrent une liste mise en cache d'instances disponibles.

10. Haute disponibilité d'Eureka Server

  • Déploiement multi-nœuds : Réplication des registres entre instances.
  • Mode de protection : En cas de partition réseau, les instances existantes restent inscrites.
  • Équilibrage de charge : Les clients utilisent des stratégies comme round-robin pour répartir les requêtes.

11. Pourquoi un centre de configuration ?

Centralise la gestion des paramètres :

  • Externalisation : Séparation du code et des paramètres d'environnement.
  • Dynamisme : Mise à jour à chaud sans redémarrage des services.
  • Versioning : Historique des modifications et possibilité de rollback.

12. Centres de configuration pour Spring Cloud

  • Spring Cloud Config : Stockage Git/SVN avec API REST.
  • Nacos Config : Support des configurations dynamiques et de la découverte de services.
  • Apollo : Solution complète avec gestion des permissions et visualisation.

13. Architecture de Nacos Config

  1. Stockage : Base embarquée (Derby) ou MySQL.
  2. Notification : Mécanisme de long polling pour les mises à jour temps réel.
  3. Versioning : Suivi des modifications par version de configuration.

14. Mécanisme de long polling de Nacos

Le client maintient une connexion ouverte vers le serveur :

  • Requête : Le client envoie périodiquement une requête de vérification.
  • Suspension : Le serveur retient la réponse jusqu'à un changement ou timeout (30s).
  • Notification : En cas de modificasion, le serveur pousse immédiatement la nouvelle configuration.

15. Différence entre HTTP et RPC

Aspect HTTP RPC
Modèle Requête-réponse (REST) Appel de méthode distant
Sérialisation JSON, XML Protobuf, Avro (binaire)
Performance Overhead textuel Optimisé pour faible latence

16. Feign vs Dubbo

Critère Feign Dubbo
Style Déclaratif (annotations) Interface Java
Protocole HTTP/REST TCP (custom ou HTTP/2)
Découverte Intégration Eureka/Consul Nacos/ZooKeeper natif

17. Équilibrage de charge côté client

Le client :

  1. Récupère la liste des instances depuis le registre.
  2. Applique une politique locale (round-robin, random...).
  3. Envoie directement la requête à l'instance sélectionnée.

18. Présentation de Feign

Client HTTP déclaratif simplifiant les appels REST :


@FeignClient(name = "userService", fallback = UserServiceFallback.class)
public interface UserServiceClient {
    @GetMapping("/users/{id}")
    User getUser(@PathVariable("id") Long id);
}

19. Latence initiale de Feign

Ribbon initialise paresseusement ses composants :

  • Chargement : Récupération de la liste des instances.
  • Pool de connexions : Établissement des connexions HTTP.

Solution : Pré-charger le client au démarrage de l'application.

20. Transmission de l'authentification dans Feign

Intercepteur injectant le token dans les headers :


@Bean
public RequestInterceptor authInterceptor() {
    return template -> {
        String token = authenticationContext.getBearerToken();
        template.header("X-Auth-Token", token);
    };
}

21. Équilibrage de charge dans Feign

Ribbon fournit :

  • Cache de services : Liste locale mise à jour périodiquement.
  • Politiques : RoundRobinRule, AvailabilityFilteringRule...
  • Retry : Mécanisme de relance sur échec temporaire.

22. Algorithmes d'équilibrage

  • Round Robin : Distribution cyclique équitable.
  • Pondéré : Affectation selon la capacité des instances.
  • Moins de connexions : Direction vers l'instance la moins chargée.
  • Hashage : Affinité basée sur un identifiant client.

23. Neige de services (Service Snowball)

Propagation des défaillances en cascade :

  1. Surcharge d'un service due à une panne.
  2. Blocage des threads dans les services appelants.
  3. Épuisement des ressources et défaillance globale.

Prévention : Timeouts, circuit breakers, bulkheads.

24. Circuit breaker vs Dégradation

  • Circuit breaker : Coupe les appels vers un service défaillant après seuil d'erreurs.
  • Dégradation : Fournit une réponse alternative (cache, valeur par défaut) quand le service est indisponible.

25. Solutions de résilience

  • Hystrix : Solution historique avec bulkheads par thread pools.
  • Sentinel : Contrôle de flux et dégradation avec monitoring temps réel.
  • Resilience4j : Bibliothèque légère inspirée de Hystrix.

26. Fonctionnement de Hystrix

  1. Isolation : Exécution dans un thread pool dédié.
  2. Métriques : Surveillance du taux d'erreur et de la latence.
  3. Circuit : Ouverture après dépassement de seuil.
  4. Fallback : Exécution d'une méthode alternative.

27. Contrôle de flux avec Sentinel


@SentinelResource(value = "queryOrder", blockHandler = "handleBlock")
public Order queryOrder(Long orderId) {
    // Logique métier
}

public Order handleBlock(Long orderId, BlockException e) {
    // Logique de dégradation
}

Règles configurables dynamiquement via dashboard ou API.

28. Algorithme de sliding window

Fenêtre glissante divisée en segments :

  • Comptage : Nombre de requêtes par segment temporel.
  • Évaluation : Taux calculé sur la fenêtre complète.

29. Contrôle de flux en cluster

Architecture token-based :

  • Token Server : Distribue les jetons d'accès.
  • Token Clients : Demandent des autorisations avant traitement.

30. Rôle d'une API Gateway

  • Routage : Direction des requêtes vers les services appropriés.
  • Sécurité : Authentification, autorisation, limitation de débit.
  • Agrégation : Combinaison de réponses multiples.
  • Monitoring : Collecte des métriques d'utilisation.

31. Passerelles API pour Spring Cloud

  • Spring Cloud Gateway : Solution officielle basée sur WebFlux.
  • Kong : Plateforme cloud-native avec plugins extensibles.
  • APISIX : Haute performance avec support des protocoles variés.

32. Concepts clés de Spring Cloud Gateway

  • Route : Correspondance chemin-service.
  • Predicate : Conditions de filtrage (header, query param...).
  • Filter : Traitement des requêtes (modification, logging...).

33. Nécessité du tracing distribué

Pour les architectures microservices :

  • Visualisation : Suivi des chemins de requêtes.
  • Débogage : Identification des goulets d'étranglement.
  • Analyse : Mesure des performances inter-services.

34. Solutions de tracing

  • Zipkin : Solution open-source avec stockage Elasticsearch.
  • Jaeger : Développé par Uber, supporte OpenTelemetry.
  • Skywalking : Agent non-intrusif avec APM intégré.

35. Modes de transaction distribuée Seata

  • AT : Compensation automatique via logs d'undo.
  • TCC : Try-Confirm-Cancel avec logique métier explicite.
  • Saga : Orchestration d'événements avec compensation.

36. Architecture de Seata

  • TC (Transaction Coordinator) : Gestion centralisée des transactions globales.
  • TM (Transaction Manager) : Initiation et coordination.
  • RM (Resource Manager) : Gestion des branches transactionnelles.

37. Flux d'exécution Seata

  1. Phase 1 : Exécution locale avec enregistrement des logs.
  2. Phase 2 : Commit asynchrone ou rollback basé sur les logs.

38. Propagation des identifiants transactionnels

Mécanismes de transmission :

  • Contexte implicite : Via les en-têtes HTTP ou le contexte de thread.
  • Paramètres explicites : Transmission dans le corps des messages.

39. Mécanisme de rollback Seata

Basé sur les logs d'undo :

  1. Enregistrement des modifications avant commit.
  2. Exécution des requêtes inverses en cas d'annnulation.

40. Surveillance et alertes

  • Prometheus : Collecte des métriques via exposition de endpoints.
  • Grafana : Visualisation avec tableaux de bord personnalisables.
  • Alertmanager : Configuration de règles d'alerte.

41. Centralisation des logs

Stack ELK :

  • Elasticsearch : Stockage et indexation des logs.
  • Logstash : Collecte et transformation des données.
  • Kibana : Visualisation et recherche.

42. Gestion des secrets dans OAuth2

Bonnes pratiques :

  • Stockage sécurisé : Utilisation de coffres-forts (HashiCorp Vault).
  • Transmission : Obligation de HTTPS.
  • Tokens éphémères : Durée de vie limitée.

43. Modes d'autorisation OAuth2

  • Code grant : Pour applications web avec back end.
  • Implicit grant : Pour applications SPA (déprécié).
  • Client credentials : Pour les communications service-à-service.

44. Avantages et inconvénients d'OAuth2

Avantages Inconvénients
Séparation des responsabilités Complexité d'implémentation
Interopérabilité Risques de mauvaise configuration
Granularité des permissions Dépendance aux providers externes

45. Algorithmes de limitation de débit

  • Leaky bucket : Traitement à vitesse constante.
  • Token bucket : Permet les bursts contrôlés.
  • Sliding window : Comptage précis sur fenêtre mobile.

46. Rôle de la passerelle dans l'architecture

  • Point d'entrée unique : Centralisation des politiques de sécurité.
  • Découplage : Isolation des clients des implémentations backend.
  • Optimisation : Cache, compression, agrégation.

47. Scénarios pour les transactions distribuées

Cas d'utilisation :

  • Opérations multi-bases : Cohérence entre plusieurs sources de données.
  • Sagas : Processus métier longs avec compensation.
  • Événements : Publication/subcription avec garanties de livraison.

48. Flux d'exécution détaillé de Seata

  1. Phase de préparation : Exécution des transactions locales avec logs.
  2. Phase de validation : Vérification des contraintes d'intégrité.
  3. Phase de finalisation : Commit asynchrone ou rollback.

49. Présentation de Seata

Solution de transaction distribuée légère :

  • Non-intrusif : Peu de modifications du code métier.
  • Haute performance : Optimisé pour les microservices.
  • Polyvalent : Support de multiples modes de transaction.

50. Comparaison Sentinel vs Hystrix

Caractéristique Sentinel Hystrix
Approche Contrôle de flux Isolation par thread pool
Configuration Dynamique via dashboard Statique
Métriques Temps réel avec historique Fenêtre glissante

51. Gestion des erreurs dans Sentinel

Personnalisation possible :

  • BlockExceptionHandler : Traitement global des blocages.
  • Fallback : Logique métier alternative.
  • Logging : Journalisation détaillée des refus.

52. Fonctionnement de Sentinel

Architecture modulaire :

  • Entrée : Définition des ressources à protéger.
  • Évaluation : Application des règles en temps réel.
  • Action : Contrôle, dégradation ou blocage.

53. Définition du circuit breaker

Mécanisme de protection :

  • Fermé : Traitement normal des requêtes.
  • Ouvert : Court-circuit en cas de dépassement de seuil.
  • Semi-ouvert : Test de récupération avec trafic limité.

54. Architecture de Seata

Composants principaux :

  • TC : Coordonnateur central des transactions globales.
  • TM : Gestionnaire pour l'initiation des transactions.
  • RM : Gestion des branches transactionnelles.

55. Différences entre Ribbon et Feign

Aspect Ribbon Feign
Abstraction Client HTTP avec load balancing Client déclaratif
Configuration Programmatique Par annotations
Intégration Autonome Tightly coupled avec Spring

56. Structure du registre Nacos

Hiérarchie :


Namespace
  └── Group
       └── Service
            └── Cluster
                 └── Instance

57. Organisations avec les namespaces

Isolation des environnements :

  • Production : Configuration et services de prod.
  • Développement : Environnement de test isolé.

58. Comparaison des registres

Critère Nacos Eureka ZooKeeper
CAP AP/CP AP CP
Fonctionnalités Registre + Config Registre seul Coordination

59. Principes du DDD

Concepts fondamentaux :

  • Modèle de domaine : Représentation du métier dans le code.
  • Bounded contexts : Découpage en sous-domaines cohérents.
  • Événements : Communication asynchrone entre agrégats.

60. Différences techniques Hystrix/Sentinel

  • Isolation : Thread pools (Hystrix) vs sémaphores (Sentinel).
  • Métriques : Fenêtre glissante (Hystrix) vs temps réel (Sentinel).
  • Configuration : Statique (Hystrix) vs dynamique (Sentinel).

61. Comparaison des architectures

  • Monolithe : Application unique, déploiement atomique.
  • SOA : Services réutilisables, ESB centralisé.
  • Microservices : Services autonomes, communication légère.

62. Philosophie des microservices

Principes directeurs :

  • Indépendance : Développement, déploiement et mise à l'échelle autonomes.
  • Résilience : Conception pour l'échec.
  • Observabilité : Monitoring, tracing et métriques.

Étiquettes: Spring Cloud Microservices Service Discovery Nacos Eureka

Publié le 11 juin à 01h23

Étiquettes Populaires

©2026 L'Atelier Monstre