En savoir plus sur le déploiement des microservices bancaires Oracle et d'OCI Kubernetes Engine
Découvrez comment utiliser Oracle Cloud Infrastructure Kubernetes Engine et les microservices bancaires Oracle pour moderniser votre infrastructure bancaire. OCI Kubernetes Engine (OKE) est un service entièrement géré, évolutif et hautement disponible que vous pouvez utiliser pour déployer vos applications en conteneur vers le cloud. Utiliser OKE lorsque votre équipe de développement souhaite créer, déployer et gérer des applications cloud natives en toute fiabilité. Vous pouvez indiquer les ressources de calcul requises par vos applications et OKE les provisionne sur OCI dans une location OCI existante.
Architecture
Cette architecture explique comment implémenter les microservices bancaires Oracle et OCI Kubernetes Engine pour tirer efficacement parti des microservices.
Oracle Banking Microservices Architecture
Oracle fournit l'ensemble le plus large de solutions bancaires axées sur le domaine du secteur, couvrant les services bancaires de détail et d'entreprise, et de manière complète, de la couche d'expérience numérique du client aux processeurs de produits bancaires, ou aux domaines bancaires principaux.
Toutes ces fonctionnalités sont fournies sous la forme d'un ensemble de modules autonomes, conçus à l'aide d'une conception orientée domaine et implémentés à l'aide d'une architecture de microservices de pointe. Chaque module est composé d'un ensemble de microservices propres au domaine d'activité, d'un ensemble de microservices de base fonctionnels communs (noyau commun) sur tous les modules et de services de plate-forme qui fournissent les fonctionnalités techniques requises.
Le diagramme suivant illustre les différents niveaux de microservices dans le module de branchement.
Cette architecture offre une flexibilité de déploiement maximale. Chaque microservice peut être mis en conteneur dans une image docker et déployé séparément. Cette option offre un contrôle total sur le déploiement, ce qui vous permet de mettre à jour ou d'augmenter n'importe quel microservice spécifique en fonction des besoins particuliers des clients.
Certains clients peuvent ne pas avoir besoin de ce niveau de granularité pour la gestion de plate-forme et préférer une approche simplifiée, en 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 à un niveau individuel, elle fournit toujours le niveau de contrôle requis pour les clients avec 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 prend en compte ces facteurs :
- Type de charge globale : basée sur REST, par lot, basée sur les événements et basée sur le workflow.
- Composants critiques : certains composants sont essentiels pour la plate-forme. Ils ont une charge de travail plus élevée que les 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 du domaine d'activité du module, dans ce cas, le module de branchement.
- 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 plate-forme Event Hub pour la communication entre les microservices et les systèmes externes.
- Conducteur : Moteur de workflow de la plate-forme utilisée pour orchestrer les microservices et créer des workflows humains.
- Serveur par lots : exécute les traitements par lots requis par le domaine fonctionnel.
Cette solution regroupe sept images docker.
Architecture de déploiement à l'aide d'OKE
OCI Kubernetes Engine utilise Kubernetes, un système open source conçu pour automatiser le déploiement, le redimensionnement et la gestion des applications en conteneur sur des clusters d'hôtes. Kubernetes regroupe les conteneurs qui constituent une application en unités logiques (appelées pods) pour en faciliter la gestion et le repérage.
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 réseau, stockage, mémoire et espace de noms IPC. Il y a un conteneur principal dans un pod, et les conteneurs suivants prennent en charge le conteneur principal. Par exemple, un conteneur d'application avec un conteneur de prise en charge qui envoie les journaux d'application à un serveur de journalisation. Nous n'entrerons pas dans les détails sur les cas d'utilisation de pod multi-conteneurs dans cette architecture, mais dans la plupart des cas, il n'y a qu'un seul conteneur par pod.
Pour le déploiement de notre solution Oracle Banking, nous allons inclure 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 Kubernetes vous permet de définir l'état ou le comportement souhaité d'un pod, tel que le nombre de copies ou de répliques d'un pod donné. Un déploiement Kubernetes peut également mettre à niveau un pod existant vers une nouvelle version d'application. Il appartient à Kubernetes de conserver l'état indiqué d'un pod.
Au total, nous aurons sept déploiements pour notre solution bancaire 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 lors de la création et de la destruction des pods. Afin de 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 manière dont les pods doivent être accessibles, qu'ils soient accessibles uniquement par d'autres ressources du cluster Kubernetes, par d'autres ressources au sein de votre VCN OCI ou en externe via Internet, différents types de services Kubernetes sont affectés au déploiement.
Pour assurer la résilience, notre pool de noeuds OKE couvre 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 sont automatiquement recréés sur les noeuds d'une autre zone de disponibilité.
Pour la base de données Oracle, qui stocke les données des microservices à l'aide de schémas séparés pour chacun d'eux, nous utilisons la configuration Oracle Real Application Clusters (Oracle RAC) dans deux domaines de pannes.
Le diagramme suivant illustre cette architecture.
Description de l'illustration obma-oke-architecture.png
Pour la base de données Oracle qui stocke les données des microservices, à l'aide de schémas séparés pour chacun d'eux, nous utilisons une configuration RAC dans deux domaines de disponibilité (à l'aide de deux domaines de pannes non affiché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 précise, incluant 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 (entre pays, voire continents).
- Domaines de disponibilité
Les domaines de disponibilité sont des centres de données autonomes indépendants au sein d'une région. Les ressources physiques de chaque domaine de disponibilité sont isolées de celles des autres, ce qui garantit la tolérance aux pannes. Les domaines de disponibilité ne partagent ni infrastructure (par exemple, alimentation, système de refroidissement), ni réseau de domaine de disponibilité interne. Par conséquent, une panne sur un domaine de disponibilité ne doit pas affecter les autres domaines de disponibilité de la région.
- Domaines de pannes
Un domaine de pannes est un regroupement de matériel et d'infrastructures au sein d'un domaine de disponibilité. Chaque domaine de disponibilité comporte trois domaines de pannes avec du matériel et une alimentation indépendants. Lorsque vous répartissez les ressources entre plusieurs domaines de pannes, vos applications peuvent tolérer les pannes physiques du serveur, la maintenance du système et les pannes d'alimentation au sein d'un domaine de pannes.
- Réseau cloud virtuel (VCN) et sous-réseaux
Un VCN est un réseau personnalisable défini par logiciel que vous configurez dans une région Oracle Cloud Infrastructure. Comme les réseaux de centre de données traditionnels, les réseaux cloud virtuels vous donnent le contrôle sur l'environnement réseau. Un réseau cloud virtuel peut comporter plusieurs blocs CIDR qui ne se chevauchent pas et que vous pouvez modifier après l'avoir créé. Vous pouvez segmenter un réseau cloud virtuel en plusieurs sous-réseaux ciblant une région ou un domaine de disponibilité. Chaque sous-réseau est composé d'une plage contiguë d'adresses qui ne chevauchent pas celles des autres sous-réseaux du réseau cloud 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é.
- Equilibreur de charge
Le service Oracle Cloud Infrastructure Load Balancing fournit une répartition de trafic automatique à partir d'un seul point d'entrée vers plusieurs serveurs dans le back-end.
- Bastion
L'hôte de bastion est une instance de calcul qui sert de point d'entrée sécurisé et contrôlé de la topologie en dehors du cloud. L'hôte de 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 auxquels vous ne pouvez pas accéder directement depuis l'extérieur du cloud. La topologie dispose d'un point d'entrée unique connu que vous pouvez surveiller et auditer régulièrement. Vous pouvez donc éviter d'exposer les composants les plus sensibles de la topologie sans compromettre l'accès à ces composants.
- Systèmes de base de données
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 de blocs
Avec les volumes de stockage de blocs, vous pouvez créer, attacher, connecter et déplacer des volumes de stockage, et modifier leurs performances afin de répondre à vos exigences en matière de stockage, de performances et d'application. Une fois un volume attaché et connecté à une instance, vous pouvez l'utiliser comme un disque dur classique. Vous pouvez également déconnecter un volume et l'attacher à une autre instance sans perdre de données.
- Object Storage
Le stockage d'objets permet d'accéder rapidement à de grandes quantités de données, structurées ou non, de tout type de contenu, y compris des sauvegardes de base de données, des données analytiques et du contenu riche tel que des images et des vidéos. Vous pouvez stocker les données, puis les extraire directement à partir d'Internet ou de la plate-forme cloud, et ce, en toute sécurité. Vous pouvez redimensionner le stockage sans dégradation des performances ni de la fiabilité des services. Utilisez le stockage standard pour le stockage "à chaud" auquel vous devez accéder rapidement, immédiatement et fréquemment. Utilisez le stockage d'archive pour le stockage "à froid" que vous conservez pendant de longues périodes et auquel vous accédez rarement.
- Passerelle NAT (Network Address Translation)
Une passerelle NAT permet aux ressources privées d'un VCN d'accéder aux hôtes sur Internet, sans les exposer aux connexions Internet entrantes.
- Passerelle de service
La passerelle de service fournit un accès à partir d'un VCN à d'autres services, tels qu'Oracle Cloud Infrastructure Object Storage. Le trafic entre le VCN et le service Oracle passe par la structure du réseau Oracle et ne traverse pas Internet.