En savoir plus sur l'architecture des microservices

Les applications modernes sont conçues en composant quelques services indépendants. Cela procure agilité et rapidité de mise sur le marché pour résoudre les problèmes et introduire de nouvelles fonctionnalités.

Ce paradigme est appelé architecture de microservices, bien que le nombre de services qui se réunissent pour une application complète peut être dans les centaines (microservices), ou dans les dizaines (macroservices). De nouveaux termes sont également utilisés pour les monolithes modulaires appelés modulithes, et Spring Modulith en est un exemple.

Bien que de nombreuses organisations disposent déjà d'une architecture de microservices, les déploiements de microservices sont embourbés de complexité et les déploiements réussis sont toujours en cours dans la plupart des organisations. Ce livre de jeu de solutions tente de simplifier la création et le déploiement de microservices modernes avec la populaire plate-forme Spring Boot ainsi que l'infrastructure en nuage, les conteneurs, Kubernetes et la plate-forme dorsale-service avec Oracle Database.

Si vous souhaitez concevoir une application multilingue, facilement évolutive, facile à maintenir et à déployer, hautement disponible et qui minimise les défaillances, utilisez l'architecture de microservices pour concevoir et déployer une application en nuage. Dans une architecture de micros services, chaque microservice possède une tâche simple et communique avec les clients, ou avec d'autres micros services à l'aide de mécanismes de communication légers tels que les demandes d'API REST.

Le diagramme suivant présente l'architecture d'une application composée de plusieurs microservices.

Description de l'illustration microservice_architecture.png

Les microservices vous permettent de concevoir votre application en tant que collection de services faiblement couplés. Les microservices suivent le modèle de partage de rien et s'exécutent en tant que processus sans état. Cette approche facilite l'évolution et la maintenance de l'application.

• La couche API est le point d'entrée de toutes les demandes client à un microservice. La couche API permet également aux microservices de communiquer entre eux via HTTP, gRPC et TCP/UDP.
• La couche logique se concentre sur une seule tâche métier, en minimisant les dépendances avec les autres microservices. Cette couche peut être écrite dans un langage différent pour chaque microservice.
• La couche de stockage de données fournit un mécanisme de persistance, tel qu'un moteur de stockage de base de données, des fichiers journaux, etc. Envisagez d'utiliser un magasin de données persistant distinct pour chaque microservice. Oracle propose des conteneurs de base de données avec plusieurs bases de données enfichables, qui facilitent l'isolement des données pour la sécurité, la haute disponibilité et l'évolutivité. En outre, les applications SaaS peuvent tirer parti de la multilocation de manière sécurisée. En outre, une base de données convergée regroupe la variété des données sous un même toit pour obtenir des renseignements plus riches à partir des données.

En général, chaque microservice s'exécute dans un conteneur qui fournit un environnement d'exécution léger.

Différences entre microservices et architectures monolithiques

Avant de commencer à concevoir des applications à l'aide de l'architecture de microservices, vous devez comprendre en quoi cette architecture diffère de l'architecture monolithique traditionnelle.

La conception des applications se concentre sur la résolution des besoins de l'entreprise et la mise en œuvre de la logique métier. Dans une architecture monolithique, l'ensemble de l'application est construit en une seule unité qui contient toute la logique métier. Dans l'architecture de microservices, la logique métier est organisée en plusieurs services faiblement couplés.

L'illustration suivante montre les architectures monolithiques et microservices.

Description de l'illustration monolithic_vs_microservice.png

Le tableau suivant résume les différences entre les microservices et les architectures monolithiques.

Caractéristique	Architecture des microservices	Architecture monolithique
Conception d'unité	L'application consiste en des services faiblement couplés. Chaque service prend en charge une seule tâche métier.	L'ensemble de l'application est conçu, développé et déployé en une seule unité.
Réutilisation des fonctionnalités	Les microservices définissent des API qui exposent leurs fonctionnalités à n'importe quel client. Les clients peuvent même être d'autres applications.	La possibilité de réutiliser les fonctionnalités entre les applications est limitée.
Communication au sein de l'application	Pour communiquer entre eux, les microservices d'une application utilisent le modèle de communication demande-réponse. La mise en oeuvre standard utilise des appels d'API REST basés sur le protocole HTTP.	Les procédures internes (appels fonctionnels) facilitent la communication entre les composants de l'application. Il n'est pas nécessaire de limiter le nombre d'appels de procédure interne.
Flexibilité technologique	Chaque microservice peut être développé à l'aide d'un langage de programmation et d'un cadre qui conviennent le mieux au problème que le microservice est conçu pour résoudre.	En général, l'ensemble de l'application est écrit dans un seul langage de programmation.
Data Management	Décentralisé : Chaque microservice peut utiliser sa propre base de données.	Centralisé : L'ensemble de l'application utilise une ou plusieurs bases de données.
déploiement	Chaque microservice est déployé indépendamment, sans affecter les autres microservices de l'application.	Toute modification, aussi petite soit-elle, nécessite le redéploiement et le redémarrage de l'ensemble de l'application.
Facilité de maintenance	Les microservices sont simples, concentrés et indépendants. L'application est donc plus facile à entretenir.	Au fur et à mesure que la portée de l'application augmente, la maintenance du code devient plus complexe.
Résilience	Les fonctionnalités de l'application sont réparties entre plusieurs services. Si un microservice échoue, les fonctionnalités offertes par les autres microservices continuent d'être disponibles.	Une défaillance d'un composant peut affecter la disponibilité de l'ensemble de l'application.
Extensibilité	Chaque microservice peut être mis à l'échelle indépendamment des autres services.	L'ensemble de l'application doit être mis à l'échelle, même lorsque les besoins de l'entreprise ne concernent que certaines parties de l'application.

Considérations relatives à l'adoption de l'architecture des microservices

Lors de la conception d'une nouvelle application, tenez compte de l'architecture de microservices pour les applications qui nécessitent des niveaux élevés d'évolutivité, de flexibilité et de fiabilité. Vous pouvez utiliser un langage et une structure de programmation différents pour développer chaque composant.

Envisagez de migrer une application monolithique vers des microservices si vous pouvez diviser les fonctionnalités de l'application en services ciblés, chacun avec une portée limitée. Pour les applications monolithiques complexes qui ne peuvent pas être migrées vers l'architecture de microservices, envisagez de développer uniquement la nouvelle fonctionnalité en tant que microservices.

Les interdépendances entre les services peuvent avoir une incidence sur la quantité d'applications non disponibles lors d'un redéploiement de service. Résolvez ces problèmes de dépendance lors de la conception de l'application.

Le réusinage d'une application monolithique est difficile. Si vous avez l'intention d'utiliser l'architecture de microservices, planifiez-la dès le début du projet.

Tenez compte de la complexité des systèmes distribués lorsque vous développez des microservices, et rappelez-vous que les appels distants sont lents et peuvent échouer. Selon le cas d'utilisation, vous devez équilibrer la cohérence, la disponibilité et la tolérance de partition.

Soyez prêt pour la complexité opérationnelle que l'architecture de microservices implique. Nous vous recommandons de respecter les conditions préalables suivantes avant de déplacer une application monolithique vers l'architecture de microservices :

• Provisionnement rapide : Possibilité de provisionner les serveurs rapidement
• Surveillance de base : Capacité à détecter les problèmes de service et les problèmes d'affaires. Les problèmes de service incluent la disponibilité du service, les erreurs fonctionnelles et les problèmes de performances
• Déploiement rapide des applications : Possibilité de déployer n'importe quel service rapidement dans les environnements de test et de production

Assurez-vous que les avantages de l'architecture de microservices l'emportent sur le coût.

À propos du mécanisme de communication dans une architecture de microservices

Dans une architecture de microservices, les services s'exécutent sur plusieurs serveurs. La communication entre ces services se fait via des protocoles tels que HTTP, AMQP et TCP. La messagerie HTTP/REST et asynchrone sont les protocoles les plus utilisés.

Une API REST pour les services Web utilise généralement le protocole HTTP. Avec les méthodes HTTP (telles que GET, POST, PUT et DELETE), les clients peuvent accéder aux ressources d'application et les manipuler à l'aide d'un localisateur de ressources uniforme (URL).

Les clients envoient une demande à un service au moyen d'une API REST qui représente un point d'entrée vers la fonctionnalité de l'application. Les clients peuvent communiquer avec des microservices directement ou au moyen d'une passerelle d'API.

Un modèle de passerelle d'API définit un point d'entrée unique pour toutes les demandes adressées aux services. Lorsqu'une demande de client arrive, la passerelle d'API achemine la demande au service approprié.

Une variante du modèle de passerelle d'API est le modèle backend pour frontend, qui définit une passerelle d'API distincte pour chaque type de client (par exemple, une passerelle pour les clients mobiles et une autre pour les applications Web).

Il est recommandé de réduire au minimum la communication entre les services. Lorsque la communication est essentielle, la communication asynchrone est préférable. Le service qui envoie la demande peut continuer à fonctionner sans attendre de réponse.

Les files d'attente de messagerie et les systèmes de diffusion en continu sont des méthodes idéales pour fournir une communication asynchrone. Lorsqu'ils sont intégrés à la base de données, ils fournissent une sémantique transactionnelle pour une opération de données et l'envoi d'un message. Le déploiement des microservices est ainsi plus simple et plus évolutif. L'utilisation d'API REST rend exclusivement la communication entre les microservices synchrone et limite généralement l'ajustement.

À propos des services et des rôles requis

Cette solution nécessite les services suivants :

• Oracle Cloud Infrastructure Database (une variété de choix, y compris Oracle Autonomous Database)
• Service Container Engine pour Kubernetes pour Oracle Cloud Infrastructure
• Oracle Backend for Spring Boot and Microservices

Il s'agit des rôles nécessaires pour chaque service.

Nom de service : Rôle	Requis pour...
Oracle Cloud Infrastructure Database : SYSTEM ou ADMIN	Créez un utilisateur pour mandater l'accès à la base de données lors de la configuration d'Oracle Backend for Spring Boot and Microservices. Bien que SYSTEM ou ADMIN fonctionne, ils ont des privilèges excessifs et ne doivent pas être utilisés dans les environnements de production.
Oracle Cloud Infrastructure Container Engine for Kubernetes : CLUSTER_MANAGE	Créez une grappe Oracle Cloud Infrastructure Container Engine for Kubernetes et un groupe de noeuds avec trois noeuds de travail.
Oracle Backend for Spring Boot and Microservices : ROLE_ADMIN	Installez Oracle Backend for Spring Boot and Microservices.

Voir Produits, solutions et services Oracle pour obtenir ce dont vous avez besoin.