Un bref aperçu du framework Spring Cloud

Le concept d’applications distribuées n’est certainement pas nouveau. Quiconque a une longue carrière dans l’informatique se souvient certainement d’un certain nombre de technologies différentes mettant en œuvre des composants distribués, même dans les premières années. De nos jours, tout tourne autour des microservices. Ils sont une nouvelle forme par laquelle on considère aujourd’hui le concept d’informatique distribuée.

Leur particularité est que leurs communications reposent essentiellement sur des protocoles REST et de messagerie, qui ont l’avantage d’être des standards largement répandus. Le concept de base est essentiellement le même, ayant des éléments de l’ensemble du système complètement indépendants les uns des autres et exécutant chacun dans son propre processus.

Le monde des microservices, associé à l’avènement des plates-formes cloud, a ouvert la voie à un essor des technologies connexes. Ce nouveau style architectural a ses inconvénients et un certain nombre de modèles spécifiques sont nécessaires pour les surmonter. Nuage de printemps est un projet Spring basé sur Spring Boot et contient des packages spécifiques qui couvrent de tels modèles, à la fois avec ses propres solutions et en intégrant également des solutions tierces (comme Netflix États-Unis outils). Dans cet article, nous allons montrer une liste des principaux modèles de microservices et un bref aperçu de la façon dont Spring Cloud les gère.

Le présent article est destiné à être une introduction rapide au cadre et le premier d’une série d’articles visant à couvrir les fonctionnalités et les modules les plus importants de Nuage de printemps. Dans le prochain article, nous aborderons les bases de la configuration à distance, qui est un élément fondamental de l’écosystème de microservices Spring Cloud.

Applications monolithiques

Nous pouvons décrire une application monolithique comme un système autonome, le but étant de résoudre une gamme de fonctionnalités dans une seule unité de traitement. L’image suivante montre à quoi pourrait ressembler une application monolithique. Le concept principal est que toute l’application est décomposée en couches spécialisées dans une logique de conception générale, comme la logique métier et les couches de base de données, mais toutes ces couches s’exécutent généralement dans le même processus et communiquent entre elles par des appels de méthode internes (internes au Java Virtual Machine dans laquelle ils tournent).

Applications de microservices

Les applications de microservice ont une structure plus complexe. Nous pouvons considérer un système de microservices comme une évolution d’un système monolithique où ses principales caractéristiques sont séparées en applications indépendantes, chacune s’exécutant dans son propre processus, et éventuellement décomposées en interne en couches comme dans le schéma monolithique décrit ci-dessus.

L’image suivante montre un exemple approximatif de ce à quoi pourrait ressembler un système de microservices. C’est un schéma trop simplifié, mais il sert à avoir une compréhension générale. Dans l’image, nous avons une passerelle, qui représente l’entrée du monde extérieur dans le système, et quelques microservices, chacun dans un nœud séparé (matériel ou machine virtuelle).

Dans l’image ci-dessus, chaque microservice utilise également sa propre instance de base de données exécutée dans un nœud séparé. En réalité, la façon dont nous déployons les services uniques ne suit pas de règles rigides, nous pourrions avoir un seul nœud partagé pour héberger la base de données ou même un seul nœud pour héberger les trois services fonctionnant chacun dans un processus séparé (nous ne parlons pas ici sur conteneurs juste pour garder les choses simples et génériques).

Outre le schéma de déploiement spécifique, la principale différence par rapport au scénario monolithique est que nous avons un certain nombre de fonctionnalités exécutées dans leur propre processus et celles-ci sont généralement connectées avec des protocoles REST ou de messagerie, c’est-à-dire qu’elles communiquent par des appels à distance et qu’elles sont à savoir « distribué » Composants.

Cette « distribué« La nature nous permet de développer chaque élément du système indépendamment. De cette façon, nous pouvons améliorer la logique de réutilisation : il est plus simple de concevoir des conceptions propres et robustes dans ces composants spécialisés et les pièces uniques peuvent être développées par des équipes complètement indépendantes. Malheureusement, cela comporte également un certain nombre d’inconvénients.

Comment coordonnons-nous ces composants distribués ?
Comment gérons-nous la configuration de manière centralisée et cohérente ?

Pour exploiter ce nouveau paradigme logiciel, nous avons besoin de technologies capables de faire face à ses principaux inconvénients. L’avènement des technologies Cloud a offert un moyen amélioré et efficace de traiter ces préoccupations. Cela ne signifie pas que les microservices sont une solution à tous les problèmes. Parfois, une solution monolithique serait le choix le plus naturel. Nous pouvons dire que les microservices pourraient être un excellent choix pour les systèmes volumineux et complexes, mais perdent une partie de leur attrait pour les systèmes plus simples.

Spring Cloud, microservices et Netflix OSS

Spring Cloud repose sur le framework Spring Boot. Il propose un certain nombre de solutions par lui-même et s’intègre à des outils externes pour faire face aux principales préoccupations architecturales des microservices. Netflix OSS est une série de solutions logicielles qui couvrent les principaux modèles de microservices. Les packages Spring Cloud offrent une couche d’intégration vers ces solutions: il suffira d’utiliser les dépendances de démarrage Spring Boot associées et certaines configurations spécifiques.

Définition des dépendances en tant que trains de versions

Pour simplifier la gestion des dépendances, le concept de train de libération a été introduit. Spring Cloud est une collection de modules, chacun spécialisé sur une fonctionnalité spécifique, et chacun d’eux est développé indépendamment. UN train de libération identifie un ensemble de versions de modules qui sont vérifiées comme entièrement compatibles les unes avec les autres. Une fois que nous avons choisi le Botte de printemps version à utiliser, nous devons choisir un train de versions Spring Cloud compatible avec cette version et le définir dans un Maven gestion des dépendances section:

    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>org.springframework.cloud</groupId>
                <artifactId>spring-cloud-dependencies</artifactId>
                <version>2021.0.5</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
        </dependencies>
    </dependencyManagement>

Ensuite, nous pouvons définir les dépendances du module spécifique par Spring Cloud entrées dans le « rubrique dépendances.” La section de gestion des dépendances a pour seul but de spécifier l’ensemble des modules et des versions associées que nous voulons utiliser. De cette façon, nous n’avons pas à spécifier de version pour le module individuel dans la section dependency. Cette fonctionnalité Maven est appelée BOM (Bill of Materials).

En suivant les paramètres de gestion des dépendances ci-dessus, si nous voulons que notre application utilise les fonctionnalités du Configuration cloud de printemps module, on peut simplement ajouter un morceau de configuration comme celui-ci :

    <dependencies>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-config-server</artifactId>
        </dependency>
    </dependencies>

Pour éviter de chercher une matrice de compatibilité dans la documentation Spring lors de la configuration d’une application à partir de zéro, un moyen pratique serait d’utiliser le site start.spring.io. Là, vous pouvez d’abord sélectionner la version Spring Boot, puis les modules Spring Cloud souhaités.

Spring Cloud et modèles de microservice

Nous listons ici les principaux modèles impliqués dans l’architecture des microservices et ce que le package Spring Cloud propose pour eux :

Configuration distribuée/versionnée
Inscription et découverte du service
Routage
Appels de service à service
L’équilibrage de charge
Disjoncteurs
Messagerie distribuée

Configuration distribuée

Une préoccupation importante avec les architectures de microservices est de savoir comment gérer la configuration. Étant donné que nous avons un certain nombre de services s’exécutant chacun dans son propre processus, nous pourrions simplement penser que chaque service est responsable de sa propre configuration. Du point de vue de l’administration système, ce serait un cauchemar. Spring Cloud fournit sa propre solution pour fournir une fonctionnalité de configuration centralisée et surmonter ce problème, nommée Spring Cloud Config. Spring Cloud Config utilise Git comme premier choix pour une installation de stockage backend (une alternative serait Vault de Hashicorp). Deux alternatives de Spring Cloud Config sont Consul par Hashicorp et Apache ZooKeeper (tous deux avec des fonctionnalités non strictement limitées à la configuration distribuée).

Enregistrement et découverte de service

L’une des principales caractéristiques de l’architecture des microservices est l’enregistrement et la découverte des services. Chaque service s’enregistre auprès d’un serveur central (éventuellement distribué sur plusieurs nœuds pour une haute disponibilité) et utilise ce serveur central pour trouver d’autres services avec lesquels communiquer. Spring Cloud fournit une intégration avec l’outil Netflix OSS Eurêka. Eureka possède à la fois un package client et un package serveur. Le client est fourni par spring-cloud-starter-eureka et le serveur par un spring-cloud-starter-eureka-server dépendance. Un service qui implémente le côté client utilisera le serveur pour s’enregistrer et trouver en même temps d’autres services déjà enregistrés.

Journalisation et traçage distribués

La journalisation et le traçage dans les applications de microservices ne sont pas des tâches triviales. Nous devons collecter l’activité de journalisation de manière centralisée et proposer en même temps un moyen avancé de tracer les interactions de service sur l’ensemble du système. La bibliothèque Spring Cloud Sleuth est un choix disponible pour résoudre ces problèmes. La fonctionnalité la plus importante de Sleuth consiste à associer toutes les requêtes secondaires des microservices à la requête d’entrée unique qui les a déclenchées. Ainsi, il collecte toute la journalisation impliquée par certaines informations d’identification et fournit en même temps une image complète des interactions impliquées dans chaque demande, y compris les informations de synchronisation. Ces informations peuvent ensuite être exportées vers un autre outil nommé Zipkin, spécialisé dans l’analyse des problèmes de latence dans une architecture de microservices.

Routage

Pour établir la communication entre le monde extérieur et notre système de microservices, nous devons acheminer la demande entrante vers les bons services. Une solution Netflix OSS est Zuul, qui peut être utilisée à l’intérieur d’un…