Il s'agit de la première partie d'une série d'articles sur les bases des architectures de microservices.
Dans ce document, vous vous familiariserez avec le concept de microservices et apprendrez à créer des microservices à l'aide de Spring Boot et Spring Cloud.
Ce guide vous aidera à apprendre les bases des architectures de microservices. Nous allons également commencer à examiner l'implémentation de base des microservices avec Spring Boot.
Nous allons créer une paire de microservices et les faire communiquer entre eux à l'aide des serveurs de noms Eureka (Eureka Naming Server) et Ribbon pour équilibrer la charge côté client.
Cet article fait partie de la série Spring Boot Microservices:
Vous apprendrez
- Qu'est-ce qu'un monolithe?
- Qu'est-ce qu'un microservice?
- Quels sont les problèmes avec les microservices?
- Comment Spring Boot et Spring Cloud facilitent-ils le développement de microservices?
- Comment implémenter l'équilibrage de charge côté client à l'aide du ruban?
- Comment implémenter un serveur de noms (Eureka Naming Server)?
- Comment connecter des microservices avec un serveur de noms et un ruban?
Présentation des ressources
Dans ce didacticiel, nous allons créer une ressource pour les étudiants qui fournit trois services à l'aide des URI et des méthodes HTTP appropriées:
- Obtenez une liste de tous les étudiants - @GetMapping ("/ étudiants")
- Obtenir des informations sur un étudiant spécifique - @GetMapping ("/ étudiants / {id}")
- Supprimer les informations sur les étudiants - @DeleteMapping ("/ étudiants / {id}")
- Créer une nouvelle entrée étudiante - @PostMapping ("/ étudiants")
- Mettre à jour les informations sur les étudiants - @PutMapping ("/ étudiants / {id}")
Aperçu des microservices - vue d'ensemble
Dans cette série d'articles, nous allons créer deux microservices:
- Service Forex - FS pour faire court
- Service de conversion de devises - CCS pour faire court
Ne vous inquiétez pas si certaines choses ne vous sont pas claires. L'idée est de vous donner une vue d'ensemble avant de commencer le développement et de créer des microservices étape par étape.
Service Forex
Le service Forex (FS, Forex Service) est un fournisseur de services. Il fournit des taux de change pour différentes devises. Supposons qu'il communique avec Forex Exchange et fournit la valeur actuelle de l'échange entre les devises. Un exemple de demande et de réponse est présenté ci-dessous:
GET to http:
{ id: 10002, from: "EUR", to: "INR", conversionMultiple: 75, port: 8000, }
La réponse à la demande ci-dessus est le taux de change Euro / INR. La réponse de ConversionMultiple est 75.
Nous parlerons du champ portuaire un peu plus tard.
Service de conversion de devises
Le service de conversion de devises (CCS) peut convertir de nombreuses devises dans une autre devise. Il utilise le service Forex pour obtenir les valeurs de change actuelles. CCS est un consommateur de services. Un exemple de demande et de réponse est présenté ci-dessous:
GET to http:
{ id: 10002, from: "EUR", to: "INR", conversionMultiple: 75, quantity: 10000, totalCalculatedAmount: 750000, port: 8000, }
La demande ci-dessus vous permet de déterminer la valeur de 10 000 euros en roupies indiennes.
Le montant total calculé est de 750 000 INR. Le diagramme ci-dessous montre la relation entre CCS et FS.
Serveur de nommage et ruban Eureka
Selon la charge, nous pouvons avoir plusieurs copies du service de conversion de devises et du service Forex.
Et le nombre d'instances pour chaque service peut changer au fil du temps. La figure ci-dessous montre un exemple spécifique où 5 instances du service Forex sont créées.
Ce qui devrait se produire dans la situation ci-dessus est que la charge doit être répartie uniformément entre ces 5 instances.
Dans cette série d'articles, nous utiliserons Ribbon pour l'équilibrage de charge et le serveur de noms Eureka pour enregistrer tous les microservices.
Qu'est-ce qu'une application monolithique?
Avez-vous déjà travaillé dans un projet ...
- Qui est produit (mis en production) une fois tous les quelques mois
- Qui a un large éventail de fonctionnalités et de capacités.
- Dans lequel travaille une équipe de plus de 50 personnes
- Où les problèmes de débogage sont un gros problème
- Où l'introduction de nouvelles technologies et de nouveaux processus est presque impossible
Ce sont des caractéristiques typiques des applications monolithiques.
Les applications monolithiques sont généralement énormes - plus de 100 000 lignes de code. Dans certains cas, même plus d'un million de lignes de code.
Les monolithes se caractérisent par les éléments suivants:
- Grande taille d'application
- Cycles de libération longs
- Grandes équipes
Les problèmes typiques incluent:
- Problèmes d'évolutivité
- Adoption de nouvelles technologies
- Nouveaux processus - Agiles?
- Difficile d'automatiser les tests
- Il est difficile de s'adapter aux pratiques de développement actuelles
- Il est difficile de s'adapter à la croissance rapide d'un projet
Microservices
Les architectures de microservices ont évolué pour relever les défis de l'évolutivité et de l'innovation avec les architectures monolithiques. Il existe un certain nombre de définitions suggérées pour les microservices.
Petits services autonomes qui fonctionnent ensemble - Sam Newman
Développement d'une application distincte sous la forme d'un ensemble de petits services, chacun fonctionnant dans son propre processus et interagissant avec des mécanismes légers, souvent l'API de ressources HTTP. Ces services reposent sur des opportunités commerciales et peuvent être déployés indépendamment en utilisant un mécanisme de déploiement entièrement automatisé. Il existe un niveau minimum de gestion centralisée de ces services, qui peut être écrit dans différents langages de programmation et utiliser différentes technologies de stockage - James Lewis et Martin Fowler
Bien qu'il n'y ait pas de définition unique acceptée pour les microservices, il existe plusieurs caractéristiques importantes:
- REST - construit autour des ressources RESTful. La communication entre les services peut être basée sur des événements ou le protocole HTTP.
- Petits blocs déployables bien sélectionnés - Contexte limité
- Fonctionnalités du cloud - Mise à l'échelle dynamique
À quoi ressemble l'architecture de microservices?
Voici à quoi ressemblera le monolithe. Une application pour tout.
Cela ressemblera à la même application lors du développement à l'aide de l'architecture de microservices.
Les architectures de microservices comprennent plusieurs petits composants de messagerie bien conçus.
Avantages des microservices
Avantages:
- L'utilisation de nouvelles technologies et de nouveaux processus d'adaptation devient plus facile. Vous pouvez essayer de nouvelles technologies avec les nouveaux microservices que nous allons créer.
- Cycles de libération plus rapides
- Mise à l'échelle du cloud
Problèmes d'architecture de microservice
Bien que le développement de quelques petits composants puisse sembler facile, il existe un certain nombre de difficultés inhérentes associées aux architectures de microservices.
Examinons certains des problèmes:
- Configuration rapide requise : vous ne pouvez pas passer un mois à configurer chaque microservice. Vous devriez pouvoir créer rapidement des microservices.
- Automatisation : étant donné qu'au lieu du monolithe, il existe un certain nombre de composants plus petits, vous devez tout automatiser - assemblages, déploiement, surveillance, etc.
- Visibilité : vous disposez désormais de plusieurs petits composants pour le déploiement et la maintenance. Peut-être 100 ou 1000 composants. Vous devriez pouvoir suivre et identifier les problèmes automatiquement. Vous avez besoin d'une excellente visibilité autour de tous les composants.
- Contexte limité : définir les limites d'un microservice n'est pas une tâche facile. Le contexte limité de la conception de domaine est un bon point de départ. Votre compréhension du domaine évolue au fil du temps. Vous devez vous assurer que les limites du microservice évoluent.
- Gestion de la configuration : vous devez gérer les configurations de centaines de composants dans différents environnements. Vous aurez besoin d'une solution de gestion de configuration
- Augmentation et diminution dynamiques : les avantages des microservices ne seront réalisés que si vos applications peuvent facilement évoluer dans le cloud.
- Jeu de cartes : si le microservice en bas de la chaîne d'appel échoue, il peut affecter tous les autres microservices. Les microservices doivent être tolérants aux pannes.
- Débogage : lorsqu'un problème survient qui doit être résolu, vous devrez peut-être examiner plusieurs services dans différents composants. Une journalisation et des tableaux de bord centralisés sont nécessaires pour faciliter les problèmes de débogage.
- Cohérence : vous ne pouvez pas avoir une large gamme d'outils qui résolvent le même problème. S'il est important de stimuler l'innovation, il est également important d'avoir une gestion décentralisée des langues, des plates-formes, des technologies et des outils utilisés pour implémenter / déployer / surveiller les microservices.
Solutions d'architecture de microservices
Botte de printemps
Spring Boot vous permet de créer rapidement des applications prêtes à l'emploi et offre les fonctionnalités non fonctionnelles suivantes:
- serveurs embarqués (facilité de déploiement à l'aide de conteneurs)
- surveillance des métriques
- surveillance de la santé
- configuration externe
Nuage de printemps
Spring Cloud fournit des solutions d'activation cloud pour vos microservices. Il utilise et s'appuie sur certaines des solutions cloud créées par Netflix (Netflix OSS).
Modules Cloud importants de printemps
- Mise à l'échelle dynamique de haut en bas. En utilisant une combinaison de:
- Serveurs de noms Eureka
- Ruban (équilibrage de charge côté client)
- Feign (simplifie le développement des clients REST)
- Visibilité et suivi avec:
- Trace Zipkin distribuée
- Passerelle API Netflix
- Gestion de la configuration avec Spring Cloud Config Server
- Tolérance aux pannes avec Hystrix
Dans cette série d'articles, nous allons créer deux microservices:
Remarque perev. L'auteur répète en outre partiellement ce qui a été dit. Édition originale enregistrée (sans supprimer les relectures)
- Service Forex - FS pour faire court
- Service de conversion de devises - CCS pour faire court
Le diagramme ci-dessous montre la relation entre CCS et FS. Nous établirons une connexion entre ces deux composants.
Nous aimerions pouvoir augmenter et diminuer dynamiquement le nombre d'instances de chacun de ces services.
Et le nombre d'instances pour chaque service peut changer au fil du temps. La figure ci-dessous montre un exemple spécifique où 5 instances du service Forex sont créées.
L'implémentation d'une solution de montée en puissance et de descente dynamique nécessite de répondre à deux questions:
- Comment le service de conversion de devises (CCS) détermine-t-il le nombre d'instances du service Forex (FS) actives?
- Comment le service de conversion monétaire (CCS) répartit-il la charge entre les instances actives?
Puisque nous voulons que cela soit dynamique, nous ne pouvons pas coder en dur les URL des services FS vers CCS. C'est pourquoi nous introduisons un serveur de noms.
Toutes les instances de composants (CCS et FS) sont enregistrées sur le serveur de noms Eureka. Lorsque FS doit appeler CCS, il demande à Eureka Naming Server des informations sur les instances actives. Nous utiliserons le ruban pour équilibrer la charge côté client entre les différentes instances FS.
Vous trouverez ci-dessous un diagramme de séquence de haut niveau de ce qui se passera lors de la demande de CCS à FS.
Plus loin dans cette série d'articles:
- Création d'un microservice Forex. Nous allons créer un service REST simple basé sur le Web Spring Boot Starter et Spring Boot Started JPA. Nous utiliserons Hibernate pour implémenter JPA et nous connecter à la base de données H2.
- Création du service de conversion de devises CCS. Nous allons créer un service REST simple en utilisant Feign pour appeler le microservice Forex.
- Utilisez le ruban pour l'équilibrage de charge.
- Implémentez Eureka Naming Service et connectez FS et CCS via Eureka.