En savoir plus sur l'architecture des microservices

Les applications modernes sont créées en composant quelques services créés de manière indépendante. Cela permet une mise sur le marché plus agile et plus rapide pour résoudre les problèmes et introduire de nouvelles fonctionnalités.

Ce paradigme est appelé une architecture de microservices, bien que le nombre de services qui se regroupent pour une application complète puisse être de centaines (microservices) ou de 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 entreprises disposent déjà d'une architecture de microservices, les déploiements de microservices sont complexes et les déploiements réussis sont toujours en cours dans la plupart des entreprises. Ce guide stratégique de solution tente de simplifier la création et le déploiement de microservices modernes avec la populaire plate-forme Spring Boot, ainsi que l'infrastructure cloud, les conteneurs, Kubernetes et la plate-forme Backend as a 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 cloud. Dans une architecture de microservices, chaque microservice est associé à une tâche simple, et communique avec les clients ou avec d'autres microservices à l'aide de mécanismes de communication légers tels que les demandes d'API REST.

Le schéma suivant illustre l'architecture d'une application composée de plusieurs microservices.

Description de l'image microservice_architecture.png

Les microservices vous permettent de concevoir votre application en tant qu'ensemble de services faiblement interdépendants. Les microservices suivent le modèle de partage sans partage et s'exécutent en tant que processus sans état. Cette approche facilite le redimensionnement 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 tâche métier unique, ce qui réduit les dépendances aux autres microservices. Cette couche peut être écrite dans un langage différent pour chaque microservice.
La couche de banque 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 pluggables qui permettent aux microservices d'isoler facilement les données pour la sécurité, la haute disponibilité et la mise à l'échelle. En outre, les applications SaaS peuvent tirer parti de l'architecture colocative de manière sécurisée. En outre, une base de données convergée rassemble la variété des données sous un même toit pour des informations 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 les microservices et les 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 d'applications se concentre sur la résolution des besoins métier et l'implémentation de la logique métier. Dans une architecture monolithique, l'ensemble de l'application est construit comme une seule unité qui contient toute la logique métier. Dans l'architecture des microservices, la logique métier est organisée en plusieurs services faiblement interdépendants.

L'illustration suivante présente les architectures monolithiques et de microservices.

Description de l'image monolithic_vs_microservice.png

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

Caractéristique	Architecture des microservices	Architecture monolithique
Conception d'unités	L'application se compose de 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.	Les possibilités de réutilisation des fonctionnalités entre les applications sont limitées.
Communication dans l'application	Pour communiquer entre eux, les microservices d'une application utilisent le modèle de communication demande-réponse. L'implémentation standard utilise des appels d'API REST basés sur le protocole HTTP.	Les procédures internes (appels de fonction) 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 framework qui conviennent le mieux au problème que le microservice est conçu pour résoudre.	En général, l'application entière est écrite dans un seul langage de programmation.
Gestion des données	Décentralisé : chaque microservice peut utiliser sa propre base de données.	Centralisée : 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 un redéploiement et un redémarrage de l'ensemble de l'application.
Facilité de maintenance	Les microservices sont simples, ciblés et indépendants. L'application est donc plus facile à maintenir.	Avec l'augmentation de la portée de l'application, la maintenance du code devient plus complexe.
Résilience	Les fonctionnalités de l'application sont réparties entre plusieurs services. En cas de défaillance d'un microservice, les fonctionnalités offertes par les autres microservices restent disponibles.	Une défaillance d'un composant peut affecter la disponibilité de l'ensemble de l'application.
Evolutivité	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.

Remarques concernant l'adoption de l'architecture de 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 de programmation et une structure 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 ayant 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 les nouvelles fonctionnalités en tant que microservices.

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

La refactorisation 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 n'oubliez pas que les appels à distance sont lents et peuvent échouer. Selon le cas d'emploi, vous devez trouver un équilibre entre la cohérence, la disponibilité et la tolérance de partition.

Préparez-vous à la complexité opérationnelle que l'architecture des microservices implique. Nous vous recommandons de respecter les prérequis suivants avant de déplacer une application monolithique vers l'architecture de microservices :

Provisionnement rapide : possibilité de provisionner des serveurs rapidement
Surveillance de base : capacité à détecter les problèmes de service et les problèmes commerciaux. 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 des microservices l'emportent sur les coûts.

A 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 s'effectue via des protocoles tels que HTTP, AMQP et TCP. HTTP/REST et la messagerie 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 de l'application et les manipuler à l'aide d'un emplacement de ressource uniforme (URL).

Les clients envoient une demande à un service via une API REST qui représente un point d'entrée vers la fonctionnalité de l'application. Les clients peuvent communiquer directement avec les microservices ou via 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 client arrive, la passerelle d'API achemine la demande vers le service approprié.

Une variante du modèle de passerelle d'API est le modèle back-end pour front-end, 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 limiter 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 transmission en continu sont des méthodes idéales pour fournir une communication asynchrone. Lorsqu'ils sont intégrés dans la base de données, ils fournissent une sémantique transactionnelle pour une opération de données et envoient un message. Les microservices sont ainsi plus simples et plus évolutifs à déployer. L'utilisation d'API REST rend exclusivement la communication entre les microservices synchrone et limite généralement le redimensionnement.

A propos des services et rôles requis

Cette solution nécessite les services suivants :

Oracle Cloud Infrastructure Database (nombre de choix parmi lesquels Oracle Autonomous Database)
Oracle Cloud Infrastructure Container Engine for Kubernetes
Oracle Backend for Spring Boot and Microservices

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

Nom de service : rôle	Obligatoire pour...
Oracle Cloud Infrastructure Database : `SYSTEM` ou `ADMIN`	Créez un utilisateur pour proxy 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` fonctionnent, ils sont surprivilégiés et ne doivent pas être utilisés dans les environnements de production.
Oracle Cloud Infrastructure Container Engine for Kubernetes : `CLUSTER_MANAGE`	Créez un cluster Oracle Cloud Infrastructure Container Engine for Kubernetes et un pool de noeuds avec trois noeuds de processus actifs.
Oracle Backend for Spring Boot and Microservices : `ROLE_ADMIN`	Installez Oracle Backend for Spring Boot and Microservices.

Reportez-vous à Produits, solutions et services Oracle pour obtenir ce dont vous avez besoin.