En savoir plus sur le déploiement de microservices bancaires Oracle et de OCI Kubernetes Engine
Découvrez comment utiliser Oracle Cloud Infrastructure Kubernetes Engine et les microservices bancaires d'Oracle pour moderniser votre infrastructure bancaire. Le moteur Kubernetes pour OCI (OKE) est un service entièrement géré, évolutif et hautement disponible que vous pouvez utiliser pour déployer vos applications conteneurisées dans le nuage. Utilisez OKE lorsque votre équipe de développement souhaite créer, déployer et gérer des applications en nuage natives en toute fiabilité. Vous indiquez les ressources de calcul requises par vos applications, et OKE les provisionne sur OCI dans une location OCI existante.
Architecture
Cette architecture décrit comment mettre en oeuvre les microservices bancaires Oracle et le moteur Kubernetes pour OCI pour tirer parti des microservices de manière efficace.
Oracle Banking Microservices Architecture
Oracle propose la plus vaste gamme de solutions bancaires par domaine de l'industrie, couvrant les services bancaires de détail et d'entreprise, et ce, de la couche d'expérience numérique du client aux processeurs de produits bancaires, ou aux domaines bancaires de base.
Toutes ces capacités sont fournies sous la forme d'un ensemble de modules autonomes, conçus à l'aide d'une conception axée sur le domaine et mis en œuvre à l'aide d'une architecture de microservices de pointe. Chaque module est composé d'un ensemble de microservices propres au domaine d'affaires, d'un ensemble de microservices de base fonctionnelle communs (coeurs communs) pour tous les modules et de services de plate-forme qui fournissent les capacités techniques requises.
Le diagramme suivant illustre les différents niveaux de microservices dans le module arborescent.
Cette architecture offre une flexibilité de déploiement maximale. Chaque microservice peut être conteneurisé dans une image docker et déployé séparément. Cette option offre un contrôle complet sur le déploiement, ce qui vous permet de mettre à jour ou d'augmenter n'importe quel microservice spécifique en fonction des exigences particulières des clients.
Certains clients peuvent ne pas avoir besoin de ce niveau de granularité pour la gestion de la plate-forme et peuvent préférer une approche simplifiée, regroupant les microservices dans un nombre réduit d'images docker. Même si cette approche réduit la flexibilité de mise à jour et de mise à l'échelle au niveau individuel, elle fournit toujours le niveau de contrôle requis pour les clients ayant des exigences standard en matière d'évolutivité, de haute disponibilité, etc. Dans ce scénario, il est important de regrouper les microservices en tenant compte de leurs implications et de leur nature spécifique. Dans cette architecture de référence, nous proposons un regroupement qui tient compte de ces facteurs :
- Type de charge de travail : basée sur REST, basée sur des lots, basée sur des événements et basée sur des flux de travail.
- Composants critiques : Certains composants sont essentiels pour la plate-forme. Ils ont une charge de travail plus élevée que d'autres.
Le diagramme suivant illustre le regroupement proposé.
Description de l'illustration obma-service-landscape-branch-module-proposed.png
Voici une explication de ces regroupements :
- Domaine SD : Contient les microservices de domaine d'affaires du module, dans ce cas, le module de branche.
- CMC SD : microservices de base communs ou fonctionnels.
- Plato SD : Contient les microservices de plate-forme technique qui n'ont pas été déployés séparément.
- Kafka : Utilisé par la plateforme Event Hub pour la communication entre les microservices et les systèmes externes.
- Conducteur : Moteur de flux de travail de la plate-forme utilisée pour orchestrer les microservices et créer des flux de travail humains.
- Serveur par lots : Exécute les traitements par lots requis par le domaine d'affaires.
Cette solution regroupe sept images docker.
Architecture de déploiement à l'aide d'OKE
Le moteur Kubernetes pour OCI utilise Kubernetes, un système à source ouverte pour l'automatisation du déploiement, de l'ajustement et de la gestion des applications en conteneurs dans des grappes d'hôtes. Kubernetes regroupe les conteneurs qui composent une application en unités logiques (appelées pods) pour faciliter la gestion et la détection.
Pour exécuter des conteneurs dans Kubernetes, ils doivent être inclus dans un pod. Un pod est la plus petite unité atomique de Kubernetes et est une construction qui exécute un regroupement de conteneurs partageant le même espace de noms réseau, de stockage, de mémoire et IPC. Il y a un conteneur principal dans un pod, et les conteneurs suivants prennent en charge le conteneur principal. Un exemple serait un conteneur d'application avec un conteneur de soutien qui envoie les journaux d'application à un serveur de journalisation. Nous n'entrerons pas dans les détails sur les cas d'utilisation de pods à conteneurs multiples dans cette architecture, mais dans la plupart des cas, il n'y a qu'un conteneur par pod.
Pour déployer notre solution Oracle Banking, nous inclurons chacune des sept images de conteneur que nous déployons dans son propre pod. Pour ce faire, vous pouvez définir un fichier manifeste de pod Kubernetes pour chaque image de conteneur.
Les pods peuvent être déployés directement dans Kubernetes, mais il est plus robuste de déployer des pods avec un déploiement Kubernetes. Un déploiement de Kubernetes vous permet de définir l'état ou le comportement souhaité d'un pod, par exemple le nombre de copies ou de répliques d'un pod donné. Un déploiement de Kubernetes peut également mettre à niveau un pod existant vers une nouvelle version de l'application. Il appartient à Kubernetes de maintenir l'état spécifié d'un pod.
Nous aurons un total de sept déploiements pour notre solution bancaire d'Oracle. Une adresse IP est affectée à chaque pod d'un déploiement, mais les adresses IP des pods sont éphémères et changent au fur et à mesure que les pods sont créés et détruits. Pour fournir un moyen cohérent d'accéder aux pods d'un déploiement, un service Kubernetes est créé pour chaque déploiement. Un service Kubernetes est une abstraction qui définit un ensemble de pods. Lorsqu'un service Kubernetes est associé à un déploiement, il représente tous les pods du déploiement et équilibre la charge du trafic vers chacun des pods. Selon la façon dont les pods doivent être accessibles, qu'ils soient accessibles uniquement par d'autres ressources de la grappe Kubernetes, d'autres ressources de votre VCN OCI ou à l'externe par Internet, différents types de services Kubernetes sont affectés au déploiement.
Pour assurer la résilience, notre groupe de noeuds OKE couvrira les trois zones de disponibilité de notre région. En cas d'échec d'une zone de disponibilité, tous les pods déployés sur les noeuds de la zone de disponibilité en échec seront automatiquement recréés sur les noeuds d'une autre zone de disponibilité.
Pour la base de données Oracle, qui stocke les données pour les microservices, à l'aide de schémas séparés pour chacun d'entre eux, nous utilisons la configuration Oracle Real Application Clusters (Oracle RAC) dans deux domaines d'erreur.
Le diagramme suivant présente cette architecture.
Description de l'illustration obma-oke-architecture.png
Pour la base de données Oracle qui stocke les données pour les microservices, à l'aide de schémas séparés pour chacun d'entre eux, nous utilisons une configuration RAC dans deux domaines de disponibilité (à l'aide de deux domaines d'erreur non représentés dans l'image). Les données sont répliquées à l'aide d'Oracle Data Guard dans le deuxième domaine de disponibilité.
L'architecture comprend les composants suivants :
- Région
Une région Oracle Cloud Infrastructure est une zone géographique localisée qui contient un ou plusieurs centres de données, appelés domaines de disponibilité. Les régions sont indépendantes les unes des autres, et de grandes distances peuvent les séparer (dans différents pays ou continents).
- Domaines de disponibilité
Les domaines de disponibilité sont des centres de données indépendants et autonomes dans une région. Les ressources physiques de chaque domaine de disponibilité sont isolées des ressources des autres domaines de disponibilité, ce qui garantit la tolérance aux pannes. Les domaines de disponibilité ne partagent pas les éléments d'infrastructure (alimentation ou refroidissement, par exemple) ni le réseau de domaines de disponibilité interne. Par conséquent, une défaillance d'un domaine de disponibilité ne devrait pas affecter les autres domaines de disponibilité de la région.
- Domaines d'erreur
Un domaine d'erreur est un regroupement de matériel et d'infrastructure au sein d'un domaine de disponibilité. Chaque domaine de disponibilité comporte trois domaines d'erreur avec une puissance et un matériel indépendants. Lorsque vous répartissez des ressources entre plusieurs domaines d'erreur, vos applications peuvent tolérer les pannes physiques de serveur, la maintenance du système et les pannes d'alimentation au sein d'un domaine d'erreur.
- Réseau en nuage virtuel (VCN) et sous-réseau
Un VCN est un réseau défini par logiciel personnalisable que vous avez configuré dans une région Oracle Cloud Infrastructure. Comme les réseaux en nuage virtuels traditionnels, ils vous offrent un contrôle sur votre environnement de réseau. Un VCN peut disposer de plusieurs blocs CIDR sans chevauchement que vous pouvez modifier après avoir créé le VCN. Vous pouvez segmenter un VCN en sous-réseaux, dont la portée peut concerner une région ou un domaine de disponibilité. Un sous-réseau est constitué d'un intervalle contigu d'adresses qui ne chevauchent pas les autres sous-réseaux dans le réseau en nuage virtuel. Vous pouvez modifier la taille d'un sous-réseau après sa création. Un sous-réseau peut être public ou privé.
- Équilibreur de charge
Le service Oracle Cloud Infrastructure Load Balancing permet une répartition automatisée du trafic à partir d'un point d'entrée unique vers plusieurs serveurs dorsaux.
- Hôte bastion
L'hôte bastion est une instance de calcul qui sert de point d'entrée sécurisé et contrôlé à la topologie en dehors du nuage. L'hôte bastion est généralement provisionné dans une zone démilitarisée (DMZ). Il vous permet de protéger les ressources sensibles en les plaçant dans des réseaux privés qui ne sont pas accessibles directement depuis l'extérieur du nuage. La topologie dispose d'un point d'entrée unique et connu que vous pouvez surveiller et vérifier régulièrement. Ainsi, vous pouvez éviter d'exposer les composants les plus sensibles de la topologie sans compromettre l'accès à ces composants.
- Systèmes de BD
Pour un petit déploiement, une forme VM.Standard2.2 est suffisante. Cette architecture utilise un système de base de données avec Oracle Database Enterprise Edition - Extreme Performance, à l'aide d'Oracle Real Application Clusters (RAC). Il utilise également Oracle Automatic Storage Management (Oracle ASM) avec un minimum de 256 Go.
- Volume par blocs
Les volumes de stockage par blocs vous permettent de créer, d'attacher, de connecter et de déplacer des volumes de stockage afin de répondre à vos exigences en matière de stockage, de performance et d'applications. Une fois un volume attaché et connecté à une instance, vous pouvez l'utiliser comme un disque dur classique. Vous pouvez également connecter un volume et l'associer à une autre instance sans perte de données.
- Stockage d'objets
Le service de stockage d'objets offre un accès rapide à de grandes quantités de données structurées et non structurées de tous types, notamment des sauvegardes de base de données, des données analytiques et du contenu enrichi, comme des images et des vidéos. Vous pouvez stocker des données en toute sécurité, puis les extraire directement à partir d'Internet ou de la plate-forme en nuage. Vous pouvez adapter le stockage sans que la performance ou la fiabilité des services soit affectée. Utilisez le stockage standard pour le stockage "à chaud" auquel vous devez accéder rapidement, immédiatement et fréquemment. Utilisez le stockage d'archives pour le stockage "à froid" que vous retenez pendant de longues périodes et auquel vous accédez rarement.
- Passerelle de traduction d'adresses de réseau (NAT)
Une passerelle NAT permet aux ressources privées d'un VCN d'accéder à des hôtes sur Internet, sans les exposer aux connexions Internet entrantes.
- Passerelle de service
La passerelle de service fournit l'accès d'un VCN à d'autres services, tels qu'Oracle Cloud Infrastructure Object Storage. Le trafic entre le réseau VCN et le service Oracle circule sur la matrice réseau Oracle et ne passe pas par Internet.