Concevoir une application basée sur les microservices
Lorsque vous concevez une application à l'aide de l'architecture de microservices, envisagez de respecter les meilleures pratiques en matière de microservices et les 12 modèles de réussite du développement de microservices. Ces modèles intègrent les considérations relatives aux applications à 12 facteurs et s'appuient sur l'expérience acquise dans les déploiements de microservices ainsi que sur une base de données convergée.
Apprenez les meilleures pratiques pour concevoir des microservices
En suivant certaines pratiques exemplaires lors de la conception de microservices, vous pouvez vous assurer que votre application est facile à mettre à l'échelle, à déployer et à tenir à jour. Notez que toutes les meilleures pratiques décrites ici ne sont peut-être pas pertinentes pour votre application.
Chaque microservice doit implémenter une seule partie des fonctionnalités de l'application. Les équipes de développement doivent définir les limites et les responsabilités de chaque microservice. Une approche consiste à définir un microservice pour chaque tâche fréquemment demandée dans l'application. Une autre approche consiste à diviser la fonctionnalité par tâches métier, puis à définir un microservice pour chaque domaine.
Tenez compte des exigences suivantes dans votre conception :
- Microservices réactifs : Les microservices doivent retourner une réponse aux clients demandeurs, même en cas d'échec du service.
- Compatibilité ascendante : Lorsque vous ajoutez ou mettez à jour la fonctionnalité d'un microservice, les modifications apportées aux méthodes et paramètres d'API ne doivent pas affecter les clients. L'API REST doit rester rétrocompatible.
- Communication flexible : Chaque microservice peut spécifier le protocole qui doit être utilisé pour la communication entre les clients et la passerelle d'API et pour la communication entre les microservices.
- Idempotence : Si un client appelle un microservice plusieurs fois, il doit produire le même résultat.
- Opération efficace : La conception doit faciliter la surveillance et le dépannage. Un système de journalisation est couramment utilisé pour mettre en oeuvre cette exigence.
Comprendre les 12 modèles de réussite dans les microservices
Les microservices sont difficiles à mettre en œuvre, et ces 12 modèles facilitent l'exploitation des avantages d'agilité et de simplicité d'une architecture de mircoservices à l'aide d'une plate-forme de base de données convergée aux côtés des conteneurs et de Kubernetes.
- Contextes limités : Concevez-les à l'avance ou fractionnez les monolithes en microservices à l'aide d'une fonction de conseil sur la refactorisation des données.
- Couplage direct : découplez les données en isolant le schéma au microservice et en utilisant un maillage d'événements fiable.
- Intégration et développement en continu pour les microservices : Une base de données multilocataire en fait un choix naturel pour les microservices. Ajoutez une base de données enfichable à déployer et à créer de manière indépendante. Une application (avec Jenkins) et un schéma (Liquibase, Flyway et EBR dans la base de données) sont également de bons choix.
- Sécurité pour les microservices : Sécurisez chaque point d'extrémité de la passerelle d'API, de l'équilibreur de charge, du maillage d'événements et de la base de données.
- Observabilité unifiée pour les microservices : Mesures, journaux et traces dans un tableau de bord unique pour le réglage et l'autoréparation.
- Boîte de réception transactionnelle : Envoi d'un message et d'une opération de manipulation de données dans une seule transaction locale.
- Maillage d'événements fiable : Maillage d'événements pour tous les événements avec messagerie transactionnelle à haut débit, publication et sous-version, avec transformations d'événement et acheminement d'événement.
- Agrégation d'événements : Les événements sont éphémères et avisent ou déclenchent une action en temps réel; après quoi ils sont agrégés dans la base de données, la base de données est le sujet compact ultime.
- Ségrégation des responsabilités d'interrogation de commande (CQRS) : Emplacement des copies opérationnelles et analytiques des données disponibles pour les microservices.
- Sagas : Transactions sur différents microservices, avec prise en charge du maillage d'événements et de la journalisation fiduciaire dans la base de données.
- Programmation polyglotte : Prise en charge des microservices et des formats de message dans divers langages, à l'aide de JSON comme données utiles.
- Précédent-service (BaaS) : Infrastructure de microservices correctement dimensionnée pour les déploiements de test, de développement et de production (petit à moyen) sur n'importe quel déploiement en nuage ou sur place; pour les applications Spring Boot.
Commencer avec un modèle de contexte limité
Le modèle recommandé pour mettre en oeuvre la persistance pour un microservice est d'utiliser une seule base de données enfichable dans une base de données conteneur. Pour chaque microservice, gardez les données persistantes privées et créez la base de données enfichable dans le cadre de la mise en oeuvre du microservice.
Dans ce modèle, les données persistantes privées sont accessibles uniquement au moyen de l'API de microservices.
L'illustration suivante présente la conception de persistance pour les microservices.
![Description de microservices_persistence.png : Description de microservices_persistence.png :](img/microservices_persistence.png)
Description de l'illustration microservices_persistence.png
- Tables privées : Chaque service possède un ensemble de tables ou de documents.
- Schéma : Chaque service possède un schéma de base de données privé, ou collection.
- Base de données : Chaque service possède une base de données enfichable au sein d'une base de données conteneur, comme illustré dans l'illustration.
Un anti-modèle de persistance pour vos microservices consiste à partager un schéma de base de données sur plusieurs microservices. Vous pouvez mettre en oeuvre des transactions atomiques, cohérentes, isolées et durables pour la cohérence des données. Un avantage de cet anti-pattern est qu'il utilise une base de données simple. Les inconvénients sont que les microservices peuvent interférer les uns avec les autres lors de l'accès à la base de données, et les cycles de développement peuvent ralentir car les développeurs de différents microservices doivent coordonner les modifications de schéma, ce qui augmente également les dépendances entre services.
Vos microservices peuvent se connecter à une instance Oracle Database qui s'exécute sur Oracle Cloud Infrastructure. La base de données multilocataire Oracle prend en charge plusieurs bases de données enfichables (PDB) dans un conteneur. C'est le meilleur choix pour la couche de persistance pour les microservices, pour l'isolement contextuel limité des données, la sécurité et la haute disponibilité. Dans de nombreux cas, moins de bases de données enfichables peuvent être utilisées avec un isolement au niveau du schéma.
Comprendre la valeur du déploiement de microservices dans des conteneurs
Après avoir créé votre microservice, vous devez le conteneuriser. Un microservice exécuté dans son propre conteneur n'affecte pas les microservices déployés dans les autres conteneurs.
Un conteneur est une unité de logiciel normalisée, utilisée pour développer, expédier et déployer des applications.
Les conteneurs sont gérés à l'aide d'un moteur de conteneur, tel que Docker. Le moteur de conteneur fournit les outils nécessaires pour regrouper toutes les dépendances d'application en tant que conteneur.
Vous pouvez utiliser le moteur Docker pour créer, déployer et exécuter vos applications de microservices dans des conteneurs. Les microservices exécutés dans des conteneurs Docker présentent les caractéristiques suivantes :
- Standard : Les microservices sont portables. Ils peuvent courir n'importe où.
- Léger : Docker partage le noyau du système d'exploitation, ne nécessite pas de système d'exploitation pour chaque instance et s'exécute en tant que processus léger.
- Sécurisé : Chaque conteneur s'exécute en tant que processus isolé. Les microservices sont sécurisés.
Le processus de conteneurisation d'un microservice consiste à créer un Dockerfile
, à créer et à créer une image de conteneur qui comprend ses dépendances et la configuration de l'environnement, à déployer l'image dans un moteur Docker et à charger l'image dans un registre de conteneurs pour le stockage et l'extraction.
![Description de docker_container_process.png : Description de docker_container_process.png :](img/docker_container_process.png)
Description de l'illustration docker_container_process.png
En savoir plus sur l'orchestration des microservices à l'aide de Kubernetes
Les microservices qui s'exécutent dans des conteneurs doivent pouvoir interagir et s'intégrer pour fournir les fonctionnalités d'application requises. Cette intégration peut être réalisée au moyen de l'orchestration de conteneurs.
L'orchestration de conteneurs vous permet de démarrer, d'arrêter et de regrouper des conteneurs dans des grappes. Il permet également une haute disponibilité et une mise à l'échelle. Kubernetes est l'une des plates-formes d'orchestration de conteneurs que vous pouvez utiliser pour gérer les conteneurs.
Après avoir conteneurisé vos microservices, vous pouvez les déployer dans Oracle Cloud Infrastructure Container Engine for Kubernetes.
Avant de déployer votre application de microservices en conteneur dans le nuage, vous devez la déployer et la tester dans un moteur Kubernetes local, comme suit :
- Créez votre application de microservices.
- Créez des images Docker pour conteneuriser vos microservices.
- Exécutez vos microservices dans votre moteur Docker local.
- Pousser les images de conteneur vers un registre de conteneurs.
- Déployez et exécutez vos microservices dans un moteur Kubernetes local, par exemple Minikube.
Après avoir testé l'application dans un moteur Kubernetes local, déployez-la dans Oracle Cloud Infrastructure Container Engine for Kubernetes comme suit :
- Créez une grappe.
- Télécharger le fichier
kubeconfig
. - Installez l'outil
kubectl
sur un appareil local. - Préparez le fichier
deployment.yaml
. - Déployez le microservice dans la grappe.
- Testez le microservice.
Le diagramme suivant présente le processus de déploiement d'une application de microservices conteneurisée dans Oracle Cloud Infrastructure Container Engine for Kubernetes.
![Description de oke_deployment_process.png : Description de oke_deployment_process.png :](img/oke_deployment_process.png)
Description de l'illustration oke_deployment_process.png
En savoir plus sur Oracle Backend for Spring Boot and Microservices
Spring Boot est le cadre le plus populaire pour la création de microservices en Java. L'un des 12 modèles de réussite du déploiement réussi de l'architecture de microservices est le modèle dorsal-service (BaaS). Oracle BaaS est disponible sur le marché des applications OCI pour un déploiement à l'aide de Terraform et d'Ansible en 30 minutes. Oracle BaaS fournit un ensemble de services de plate-forme requis pour déployer et exécuter des microservices, et fait partie intégrante de l'environnement Spring Boot. Les détails de la plate-forme Oracle Backend for Spring Boot and Microservices sont illustrés dans le diagramme ci-dessous.