Erfahren Sie mehr über das Deployment von Oracle Banking Microservices und der OCI Kubernetes Engine
Erfahren Sie, wie Sie Ihre Bankinfrastruktur mit Oracle Cloud Infrastructure Kubernetes Engine und Oracle Banking Microservices modernisieren können. OCI Kubernetes Engine (OKE) ist ein vollständig verwalteter, skalierbarer und hoch verfügbarer Service, mit dem Sie Ihre Containeranwendungen in der Cloud bereitstellen können. Verwenden Sie OKE, wenn Ihr Entwicklungsteam cloudnative Anwendungen zuverlässig erstellen, bereitstellen und verwalten möchte. Sie geben die Compute-Ressourcen an, die Ihre Anwendungen benötigen, und OKE stellt sie in OCI in einem vorhandenen OCI-Mandanten bereit.
Architektur
In dieser Architektur wird beschrieben, wie Sie Oracle Banking Microservices und die OCI Kubernetes Engine implementieren, um Microservices effizient zu nutzen.
Oracle Banking Microservices Architecture
Oracle bietet die branchenweit breiteste Palette an domänengesteuerten Banking-Lösungen, die das Privat- und Firmenkundengeschäft abdecken, und von vorne bis hinten, von der Schicht für digitale Kundenerfahrungen über die Bankproduktprozessoren bis hin zu Core-Banking-Domains.
All diese Funktionen werden als eine Reihe autonomer Module bereitgestellt, die mit domänengesteuertem Design entworfen und mit einer hochmodernen Microservices-Architektur implementiert werden. Jedes Modul besteht aus einer Reihe von unternehmensspezifischen Microservices, einer Reihe gemeinsamer funktionaler Grundlagen-Microservices (gemeinsamer Kern) über alle Module hinweg und Plattformservices, die die erforderlichen technischen Funktionen bereitstellen.
Das folgende Diagramm veranschaulicht die verschiedenen Ebenen von Microservices im Verzweigungsmodul.
Diese Architektur bietet maximale Bereitstellungsflexibilität. Jeder Microservice kann in einem Docking-Image containerisiert und separat bereitgestellt werden. Diese Option bietet vollständige Kontrolle über die Bereitstellung, sodass Sie einen bestimmten Microservice basierend auf bestimmten Kundenanforderungen aktualisieren oder vertikal skalieren können.
Einige Kunden benötigen diese Granularität möglicherweise nicht für das Plattformmanagement und bevorzugen möglicherweise einen vereinfachten Ansatz, bei dem die Microservices in einer reduzierten Anzahl von Docker-Images gruppiert werden. Obwohl dieser Ansatz die Flexibilität bei der Aktualisierung und Skalierung auf individueller Ebene reduziert, bietet er Kunden mit Standardanforderungen an Skalierbarkeit, High Availability usw. dennoch die erforderliche Kontrolle. In diesem Szenario ist es wichtig, die Microservices unter Berücksichtigung ihrer Auswirkungen und ihrer spezifischen Natur zu gruppieren. In dieser Referenzarchitektur schlagen wir eine Gruppierung vor, die folgende Faktoren berücksichtigt:
- Workload-Typ: REST-basiert, Batch-basiert, ereignisbasiert, Workflow-basiert.
- Kritische Komponenten: Einige Komponenten sind für die Plattform von entscheidender Bedeutung. Sie haben eine höhere Arbeitsbelastung als andere.
Das folgende Diagramm veranschaulicht die vorgeschlagene Gruppierung.
Beschreibung der Abbildung obma-service-landscape-branch-module-proposed.png
Hier ist eine Erklärung dieser Gruppierungen:
- Domain-SD: Enthält die Microservices der Geschäftsdomain des Moduls, in diesem Fall das Verzweigungsmodul.
- CMC SD: Gemeinsame Core- oder Functional Foundation-Microservices.
- Plato SD: Enthält die Microservices der technischen Plattform, die nicht separat bereitgestellt wurden.
- Kafka: Wird von der Plattform Event Hub für die Kommunikation zwischen den Microservices und externen Systemen verwendet.
- Leiter: Workflow-Engine der Plattform, mit der die Microservices orchestriert und menschliche Workflows erstellt werden.
- Batch-Server: Führt die Batch-Prozesse aus, die von der Business-Domain benötigt werden.
Diese Lösung gruppiert sieben Docker-Bilder.
Deployment-Architektur mit OKE
OCI Kubernetes Engine verwendet Kubernetes - das Open-Source-System zur Automatisierung von Deployment, Skalierung und Verwaltung containerisierter Anwendungen auf mehreren Hostclustern. Kubernetes gruppiert die Container zu logischen Einheiten (Pods genannt), um Verwaltung und Discovery zu erleichtern.
Um Container in Kubernetes auszuführen, müssen sie in einem Pod eingeschlossen sein. Ein Pod ist die kleinste atomare Einheit in Kubernetes und ein Konstrukt, das eine Gruppierung von Containern ausführt, die denselben Netzwerk-, Speicher-, Speicher- und IPC-Namespace verwenden. In einem Pod befindet sich ein Hauptcontainer, und die nachfolgenden Container unterstützen den Hauptcontainer. Ein Beispiel wäre ein Anwendungscontainer mit einem unterstützenden Container, der die Anwendungslogs an einen Logging-Server sendet. In dieser Architektur werden wir nicht auf Details zu Multi-Container-Pod-Anwendungsfällen eingehen, aber in den meisten Fällen gibt es nur einen Container pro Pod.
Für die Bereitstellung unserer Oracle Banking-Lösung werden wir jedes der sieben Containerimages, die wir bereitstellen, in einen eigenen Pod einschließen. Dazu können Sie eine Kubernetes-Podmanifestdatei für jedes Containerimage definieren.
Pods können direkt in Kubernetes bereitgestellt werden. Es ist jedoch robuster, Pods mit einem Kubernetes-Deployment bereitzustellen. Mit einem Kubernetes-Deployment können Sie den gewünschten Status oder das gewünschte Verhalten eines Pods definieren, wie die Anzahl der Kopien oder Replikate eines bestimmten Pods. Ein Kubernetes-Deployment kann auch ein Upgrade eines vorhandenen Pods auf eine neue Anwendungsversion ausführen. Es liegt an Kubernetes, den angegebenen Status eines Pods beizubehalten.
Wir haben insgesamt sieben Bereitstellungen für unsere Oracle Banking-Lösung. Jedem Pod in einem Deployment wird eine IP-Adresse zugewiesen, IP-Adressen für Pods sind jedoch kurzlebig und ändern sich, wenn Pods erstellt und gelöscht werden. Um eine konsistente Möglichkeit für den Zugriff auf Pods in einem Deployment bereitzustellen, wird für jedes Deployment ein Kubernetes-Service erstellt. Ein Kubernetes-Service ist eine Abstraktion, die eine Gruppe von Pods definiert. Wenn ein Kubernetes-Service mit einem Deployment verknüpft ist, stellt er alle Pods im Deployment dar und verteilt den Traffic auf jeden der Pods. Je nachdem, wie auf die Pods zugegriffen werden muss, ob nur andere Ressourcen im Kubernetes-Cluster, andere Ressourcen in Ihrem OCI-VCN oder extern über das Internet darauf zugreifen, werden dem Deployment verschiedene Typen von Kubernetes-Services zugewiesen.
Um Resilienz zu gewährleisten, umfasst unser OKE-Knotenpool alle drei Verfügbarkeitszonen in unserer Region. Falls eine Verfügbarkeitszone ausfällt, werden alle Pods, die auf Knoten in der ausgefallenen Verfügbarkeitszone bereitgestellt werden, automatisch auf Knoten in einer anderen Verfügbarkeitszone neu erstellt.
Für die Oracle-Datenbank, in der die Daten für die Microservices gespeichert werden, verwenden wir die Oracle Real Application Clusters-(Oracle RAC-)Konfiguration in zwei Faultdomains.
Im folgenden Diagramm wird diese Architektur dargestellt.
Beschreibung der Abbildung obma-oke-architecture.png
Für die Oracle-Datenbank, in der die Daten für die Microservices gespeichert werden, verwenden wir eine RAC-Konfiguration in zwei Availability-Domains (mit zwei im Bild nicht dargestellten Faultdomains). Daten werden mit Oracle Data Guard in der zweiten Availability-Domain repliziert.
Die Architektur umfasst die folgenden Komponenten:
- Region
Eine Oracle Cloud Infrastructure-Region ist ein lokalisierter geografischer Bereich, der mindestens ein Data Center enthält, das als Availability-Domain bezeichnet wird. Regionen sind unabhängig von anderen Regionen, und große Entfernungen können sie trennen (über Länder oder sogar Kontinente).
- Availability-Domains
Availability-Domains sind eigenständige, unabhängige Data Center innerhalb einer Region. Die physischen Ressourcen in jeder Availability-Domain sind von den Ressourcen in den anderen Availability-Domains isoliert, was eine Fehlertoleranz sicherstellt. Availability-Domains haben keine gemeinsame Infrastruktur wie Stromversorgung oder Kühlung oder das interne Availability-Domainnetzwerk. Daher sollte ein Fehler in einer Availability-Domain sich nicht auf die anderen Availability-Domains in der Region auswirken.
- Faultdomains
Eine Faultdomain ist eine Gruppierung aus Hardware und Infrastruktur innerhalb einer Availability-Domain. Jede Availability-Domain umfasst drei Faultdomains mit unabhängiger Stromversorgung und Hardware. Wenn Sie Ressourcen auf mehrere Faultdomains verteilen, können Ihre Anwendungen physische Serverausfälle, Systemwartungen und Stromausfälle innerhalb einer Faultdomain tolerieren.
- Virtuelles Cloud-Netzwerk (VCN) und Subnetze
Ein VCN ist ein anpassbares, softwaredefiniertes Netzwerk, das Sie in einer Oracle Cloud Infrastructure-Region einrichten können. Wie herkömmliche Data Center-Netzwerke erhalten Sie mit VCNs die Kontrolle über Ihre Netzwerkumgebung. Ein VCN kann mehrere sich nicht überschneidende CIDR-Blöcke aufweisen, die Sie nach dem Erstellen des VCN ändern können. Sie können ein VCN in Subnetze segmentieren, die sich auf eine Region oder eine Availability-Domain beschränken. Jedes Subnetz besteht aus einem Bereich zusammenhängender Adressen, die sich nicht mit anderen Subnetzen im VCN überschneiden. Sie können die Größe eines Subnetzes nach der Erstellung ändern. Ein Subnetz kann öffentlich oder privat sein.
- Load Balancer
Der Oracle Cloud Infrastructure Load Balancing-Service ermöglicht automatisierte Trafficverteilung von einem einzelnen Einstiegspunkt auf mehrere Server im Backend.
- Bastionhost
Der Bastionhost ist eine Compute-Instanz, die als sicherer, kontrollierter Einstiegspunkt in die Topologie von außerhalb der Cloud dient. Der Bastionhost wird in der Regel in einer entmilitarisierten Zone (DMZ) bereitgestellt. Sie können damit sensible Ressourcen schützen, indem Sie sie in privaten Netzwerken platzieren, auf die nicht direkt von außerhalb der Cloud zugegriffen werden kann. Die Topologie verfügt über einen einzigen, bekannten Einstiegspunkt, den Sie regelmäßig überwachen und auditieren können. Sie können also vermeiden, die empfindlicheren Komponenten der Topologie freizugeben, ohne den Zugriff auf sie zu beeinträchtigen.
- DB-Systeme
Bei einem kleinen Deployment ist eine VM.Standard2.2-Ausprägung ausreichend. Diese Architektur verwendet ein DB-System mit Oracle Database Enterprise Edition - Extreme Performance mit Oracle Real Application Clusters (RAC). Außerdem wird Oracle Automatic Storage Management (Oracle ASM) mit mindestens 256 GB verwendet.
- Block-Volume
Mit Blockspeicher-Volumes können Sie Speicher-Volumes erstellen, anhängen, verbinden und verschieben sowie die Volume-Performance entsprechend Ihren Speicher-, Performance- und Anwendungsanforderungen ändern. Nachdem Sie ein Volume an eine Instanz angehängt und damit verbunden haben, können Sie es wie eine herkömmliche Festplatte verwenden. Sie können ein Volume auch trennen und an eine andere Instanz anhängen, ohne Daten zu verlieren.
- Object Storage
Mit Object Storage können Sie schnell auf große Mengen an strukturierten und unstrukturierten Daten eines beliebigen Inhaltstyps zugreifen, einschließlich Datenbankbackups, analytischen Daten und umfangreichen Inhalten wie Bildern und Videos. Sie können Daten sicher und geschützt speichern und dann direkt aus dem Internet oder aus der Cloud-Plattform abrufen. Sie können den Speicher skalieren, ohne dass die Performance oder Servicezuverlässigkeit beeinträchtigt wird. Verwenden Sie Standardspeicher für "guten" Speicher, auf den Sie schnell, sofort und häufig zugreifen müssen. Verwenden Sie Archivspeicher für "Cold Storage", den Sie über lange Zeiträume beibehalten und auf den Sie nur selten zugreifen.
- Network Address Translation-(NAT-)Gateway
Ein NAT-Gateway ermöglicht privaten Ressourcen in einem VCN den Zugriff auf Hosts im Internet, ohne dass diese Ressourcen für eingehende Internetverbindungen freigegeben werden.
- Servicegateway
Das Servicegateway bietet Zugriff von einem VCN auf andere Services, wie Oracle Cloud Infrastructure Object Storage. Der Traffic vom VCN zum Oracle-Service wird über die Oracle-Netzwerkstruktur geleitet und durchläuft nicht das Internet.