Scopri come distribuire i microservizi Oracle Banking e OCI Kubernetes Engine
Scopri come utilizzare Oracle Cloud Infrastructure Kubernetes Engine e Oracle Banking Microservices per modernizzare la tua infrastruttura bancaria. OCI Kubernetes Engine (OKE) è un servizio completamente gestito, scalabile e ad alta disponibilità che puoi utilizzare per distribuire le tue applicazioni containerizzate nel cloud. Utilizza OKE quando il tuo team di sviluppo desidera creare, distribuire e gestire in modo affidabile applicazioni cloud native. Puoi specificare le risorse di computazione richieste dalle tue applicazioni e OKE le esegue sul provisioning OCI in una tenancy OCI esistente.
Architettura
Questa architettura descrive come implementare i microservizi Oracle Banking e OCI Kubernetes Engine per sfruttare i microservizi in modo efficiente.
Oracle Banking Microservices Architecture
Oracle offre il set più ampio di soluzioni bancarie basate sul dominio del settore, che copre il retail e il corporate banking e offre una panoramica completa, dal livello di esperienza digitale dei clienti ai processori dei prodotti bancari o ai domini bancari di base.
Tutte queste funzionalità sono fornite come un set di moduli autonomi, progettati utilizzando una progettazione basata sul dominio e implementati utilizzando un'architettura di microservizi all'avanguardia. Ogni modulo è composto da un set di microservizi specifici del dominio di business, un set di microservizi funzionali di base comuni (common core) in tutti i moduli e servizi di piattaforma che forniscono le funzionalità tecniche richieste.
Il diagramma riportato di seguito illustra i diversi livelli di microservizi nel modulo della diramazione.
Questa architettura offre la massima flessibilità di implementazione. Ogni microservizio può essere containerizzato in un'immagine docker e distribuito separatamente. Questa opzione fornisce il controllo completo sulla distribuzione, consentendo di aggiornare o eseguire lo scale-up di qualsiasi microservizio specifico in base ai requisiti specifici dei clienti.
Alcuni clienti potrebbero non richiedere tale livello di granularità per la gestione della piattaforma e potrebbero preferire un approccio semplificato, raggruppando i microservizi in un numero ridotto di immagini docker. Anche se questo approccio riduce la flessibilità per l'aggiornamento e la scalabilità a livello individuale, fornisce comunque il livello di controllo richiesto per i clienti con requisiti standard di scalabilità, alta disponibilità e così via. In questo scenario, è importante raggruppare i microservizi considerando le loro implicazioni e la loro natura specifica. In questa architettura di riferimento, proponiamo un raggruppamento che considera questi fattori:
- Tipo di carico di lavoro: basato su REST, basato su batch, basato su eventi e basato su flusso di lavoro.
- Componenti critici: alcuni componenti sono fondamentali per la piattaforma. Hanno un carico di lavoro più elevato di altri.
Il seguente diagramma illustra il raggruppamento proposto.
Descrizione dell'immagine obma-service-landscape-branch-module-proposed.png
Ecco una spiegazione di questi raggruppamenti:
- Domain SD: contiene i microservizi del dominio business del modulo, in questo caso il modulo di diramazione.
- SD CMC: microservizi di base comuni o funzionali.
- Plato SD: contiene i microservizi della piattaforma tecnica che non sono stati distribuiti separatamente.
- Kafka: utilizzato dalla piattaforma Event Hub per la comunicazione tra microservizi e sistemi esterni.
- Conduttore: Motore del flusso di lavoro della piattaforma utilizzata per orchestrare i microservizi e creare flussi di lavoro umani.
- Server batch: esegue i processi batch richiesti dal dominio business.
Questa soluzione raggruppa sette immagini docker.
Architettura di distribuzione che utilizza OKE
OCI Kubernetes Engine utilizza Kubernetes, il sistema open source per automatizzare l'implementazione, la scalabilità e la gestione di applicazioni containerizzate tra cluster di host. Kubernetes raggruppa i container che costituiscono un'applicazione in unità logiche (chiamate pod) per semplificare la gestione e la ricerca automatica.
Per eseguire i container in Kubernetes, devono essere racchiusi in un pod. Un pod è l'unità atomica più piccola di Kubernetes ed è un costrutto che esegue un raggruppamento di container che condividono lo stesso spazio di nomi di rete, storage, memoria e IPC. C'è un contenitore principale in un pod, e i contenitori successivi supportano il contenitore principale. Un esempio potrebbe essere un contenitore di applicazioni con un contenitore di supporto che invia i log dell'applicazione a un server di log. Non entreremo nei dettagli sui casi d'uso dei pod multi-container in questa architettura, ma nella maggior parte dei casi, c'è un solo contenitore per pod.
Per distribuire la nostra soluzione Oracle Banking, racchiuderemo ognuna delle sette immagini di container che stiamo implementando nel proprio pod. A tale scopo, definire un file manifest del pod Kubernetes per ogni immagine del contenitore.
I pod possono essere distribuiti direttamente in Kubernetes, ma è più efficace distribuire i pod con un'implementazione Kubernetes. Una distribuzione Kubernetes consente di definire lo stato o il comportamento desiderato di un pod, ad esempio il numero di copie o repliche di un determinato pod. Una distribuzione Kubernetes può anche eseguire l'upgrade di un pod esistente a una nuova versione dell'applicazione. Spetta a Kubernetes mantenere lo stato specificato di un pod.
Avremo un totale di sette implementazioni per la nostra soluzione bancaria Oracle. A ogni pod in una distribuzione viene assegnato un indirizzo IP, ma gli indirizzi IP per i pod sono effimeri e cambiano man mano che i pod vengono creati e distrutti. Per fornire un modo coerente per accedere ai pod in una distribuzione, viene creato un servizio Kubernetes per ogni distribuzione. Un servizio Kubernetes è un'astrazione che definisce un set di pod. Quando un servizio Kubernetes è associato a una distribuzione, rappresenterà tutti i pod nella distribuzione e caricherà il traffico in ciascuno dei pod. A seconda del modo in cui è necessario accedere ai pod, se sarà accessibile solo da altre risorse nel cluster Kubernetes, da altre risorse all'interno della VCN OCI o esternamente tramite Internet, alla distribuzione vengono assegnati diversi tipi di servizi Kubernetes.
Per fornire resilienza, il nostro pool di nodi OKE si estenderà su tutte e tre le zone di disponibilità nella nostra area. Nel caso in cui una zona di disponibilità non riesca, tutti i pod distribuiti sui nodi nella zona di disponibilità non riuscita verranno ricreati automaticamente sui nodi in un'altra zona di disponibilità.
Per il database Oracle, che memorizza i dati per i microservizi, utilizzando schemi separati per ciascuno di essi, utilizziamo la configurazione di Oracle Real Application Clusters (Oracle RAC) in due domini di errore.
Il seguente diagramma descrive questa architettura.
Descrizione dell'immagine obma-oke-architecture.png
Per il database Oracle in cui vengono memorizzati i dati per i microservizi, utilizzando schemi separati per ciascuno di essi, viene utilizzata una configurazione RAC in due domini di disponibilità (utilizzando due domini di errore non visualizzati nell'immagine). I dati vengono replicati utilizzando Oracle Data Guard nel secondo dominio di disponibilità.
L'architettura presenta i seguenti componenti:
- Area
Un'area geografica Oracle Cloud Infrastructure è un'area geografica localizzata che contiene uno o più data center, denominati domini di disponibilità. Le regioni sono indipendenti da altre regioni e grandi distanze possono separarle (tra paesi o addirittura continenti).
- Domini di disponibilità
I domini di disponibilità sono data center standalone e indipendenti all'interno di un'area geografica. Le risorse fisiche in ciascun dominio di disponibilità sono isolate dalle risorse negli altri domini di disponibilità, il che fornisce tolleranza agli errori. I domini di disponibilità non condividono l'infrastruttura, ad esempio alimentazione o raffreddamento, o la rete interna del dominio di disponibilità. Pertanto, un errore in un dominio di disponibilità non dovrebbe influire sugli altri domini di disponibilità nell'area.
- Domini di errore
Un dominio di errore consiste in un gruppo di hardware e infrastruttura all'interno di un dominio di disponibilità. Ogni dominio di disponibilità dispone di tre domini di errore con alimentazione e hardware indipendenti. Quando distribuisci le risorse su più domini di errore, le tue applicazioni possono tollerare errori fisici del server, manutenzione del sistema e errori di alimentazione all'interno di un dominio di errore.
- Rete cloud virtuale (VCN) e subnet
Una VCN è una rete personalizzabile e definita dal software configurata in un'area Oracle Cloud Infrastructure. Come le tradizionali reti di data center, le reti VCN consentono di controllare l'ambiente di rete. Una VCN può avere più blocchi CIDR non sovrapposti che è possibile modificare dopo aver creato la VCN. Puoi segmentare una VCN in subnet, che possono essere definite in un'area o in un dominio di disponibilità. Ogni subnet è costituita da un intervallo contiguo di indirizzi che non si sovrappongono alle altre subnet nella VCN. È possibile modificare le dimensioni di una subnet dopo la creazione. Una subnet può essere pubblica o privata.
- Load balancer
Il servizio Oracle Cloud Infrastructure Load Balancing fornisce la distribuzione automatica del traffico da un unico punto di accesso a più server nel back-end.
- Host Bastion
L'host bastion è un'istanza di computazione che funge da punto di accesso sicuro e controllato alla topologia dall'esterno del cloud. Il provisioning dell'host bastion viene in genere eseguito in una zona demilitarizzata (DMZ). Ti consente di proteggere le risorse sensibili posizionandole in reti private a cui non è possibile accedere direttamente dall'esterno del cloud. La topologia dispone di un singolo punto di accesso noto che è possibile monitorare e controllare regolarmente. È quindi possibile evitare di esporre i componenti più sensibili della topologia senza compromettere l'accesso a tali componenti.
- Sistemi DB
Per una distribuzione di piccole dimensioni, è sufficiente una forma VM.Standard2.2. Questa architettura utilizza un sistema DB con Oracle Database Enterprise Edition - Extreme Performance, utilizzando Oracle Real Application Clusters (RAC). Inoltre, utilizza Oracle Automatic Storage Management (Oracle ASM) con un minimo di 256 GB.
- Volume a blocchi
Con i volumi di storage a blocchi, puoi creare, collegare, connettere e spostare volumi di storage e modificare le prestazioni dei volumi per soddisfare i requisiti di storage, prestazioni e applicazioni. Dopo aver collegato e connesso un volume a un'istanza, puoi utilizzare il volume come un normale disco rigido. Inoltre, puoi disconnettere un volume e collegarlo a un'altra istanza senza perdere i dati.
- Storage degli oggetti
Lo storage degli oggetti offre un accesso rapido a grandi quantità di dati strutturati e non strutturati di qualsiasi tipo di contenuto, inclusi backup del database, dati analitici e contenuti avanzati come immagini e video. Puoi memorizzare e quindi recuperare i dati direttamente da Internet o dall'interno della piattaforma cloud. Puoi ridimensionare lo storage senza alcun deterioramento delle prestazioni o dell'affidabilità del servizio. Utilizza lo storage standard per lo storage "caldo" a cui è necessario accedere rapidamente, immediatamente e frequentemente. Utilizza lo storage di archivio per lo storage "freddo" che conservi per lunghi periodi di tempo e a cui accedi raramente o raramente.
- Gateway NAT (Network Address Translation)
Un gateway NAT consente alle risorse private in una VCN di accedere agli host su Internet, senza esporre tali risorse alle connessioni Internet in entrata.
- Gateway del servizio
Il gateway di servizi fornisce l'accesso da una VCN ad altri servizi, come Oracle Cloud Infrastructure Object Storage. Il traffico dalla VCN al servizio Oracle viene instradato sul fabric di rete Oracle e non attraversa Internet.