Obtén más información sobre el despliegue de microservicios bancarios de Oracle y OCI Kubernetes Engine
Descubre cómo utilizar Oracle Cloud Infrastructure Kubernetes Engine y Oracle Banking Microservices para modernizar tu infraestructura bancaria. OCI Kubernetes Engine (OKE) es un servicio totalmente gestionado, escalable y disponible que puede utilizar para desplegar las aplicaciones en contenedores en la nube. Utilice OKE cuando el equipo de desarrollo desee crear, desplegar y gestionar aplicaciones en la nube de forma fiable. Especifique los recursos informáticos que necesitan sus aplicaciones y OKE los aprovisionará en OCI en un arrendamiento de OCI existente.
Arquitectura
En esta arquitectura se describe cómo implantar Oracle Banking Microservices y OCI Kubernetes Engine para aprovechar los microservicios de forma eficiente.
Arquitectura de Oracle Banking Microservices Architecture
Oracle proporciona el conjunto más amplio del sector de soluciones bancarias basadas en el dominio, que abarcan la banca minorista y corporativa, y completa de principio a fin, desde la capa de experiencia digital del cliente hasta los procesadores de productos bancarios o los dominios bancarios principales.
Todas estas capacidades se proporcionan como un conjunto de módulos autónomos, diseñados mediante un diseño controlado por dominio e implementados mediante una arquitectura de microservicios de última generación. Cada módulo se compone de un conjunto de microservicios específicos del dominio de negocio, un conjunto de microservicios básicos funcionales comunes (núcleo común) en todos los módulos y servicios de plataforma que proporcionan las capacidades técnicas necesarias.
El siguiente diagrama ilustra los diferentes niveles de microservicios en el módulo de rama.
Esta arquitectura ofrece la máxima flexibilidad de despliegue. Cada microservicio se puede contenerizar en una imagen de docker y desplegar por separado. Esta opción proporciona un control completo sobre el despliegue, lo que le permite actualizar o ampliar cualquier microservicio específico en función de los requisitos particulares del cliente.
Es posible que algunos clientes no necesiten ese nivel de granularidad para la gestión de plataformas y que prefieran un enfoque simplificado, agrupando los microservicios en un número reducido de imágenes de docker. Aunque este enfoque reduce la flexibilidad para actualizar y escalar a nivel individual, sigue proporcionando el nivel de control necesario para los clientes con requisitos estándar sobre escalabilidad, alta disponibilidad, etc. En este escenario, es importante agrupar los microservicios teniendo en cuenta sus implicaciones y naturaleza específica. En esta arquitectura de referencia, proponemos una agrupación que considera estos factores:
- Tipo de carga de trabajo: basada en REST, basada en lotes, basada en eventos y basada en flujos de trabajo.
- Componentes Críticos: Algunos componentes son críticos para la plataforma. Tienen una mayor carga de trabajo que otros.
El siguiente diagrama ilustra la agrupación propuesta.
Descripción de la ilustración obma-service-landscape-branch-module-proposed.png
A continuación, se muestra una explicación de estas agrupaciones:
- Dominio SD: Contiene los microservicios de dominio de negocio del módulo, en este caso, el módulo de rama.
- CMC SD: microservicios básicos comunes o funcionales.
- Plato SD: Contiene los microservicios de plataforma técnica que no se han desplegado por separado.
- Kafka: utilizado por la plataforma Event Hub para la comunicación entre los microservicios y los sistemas externos.
- Conductor: motor de flujo de trabajo de la plataforma utilizada para orquestar los microservicios y crear flujos de trabajo humanos.
- Servidor de lotes: ejecuta los procesos por lotes requeridos por el dominio de negocio.
Esta solución agrupa siete imágenes de docker.
Arquitectura de despliegue mediante OKE
OCI Kubernetes Engine utiliza Kubernetes: el sistema de código abierto para automatizar el despliegue, el ajuste y la gestión de aplicaciones en contenedores en clusters de hosts. Kubernetes agrupa los contenedores que forman una aplicación en unidades lógicas (conocidas como pod) para facilitar la gestión y detección.
Para ejecutar contenedores en Kubernetes, se deben incluir en un pod. Un pod es la unidad atómica más pequeña de Kubernetes y es una construcción que ejecuta una agrupación de contenedores que comparte el mismo espacio de nombres de red, almacenamiento, memoria e IPC. Hay un contenedor principal en un pod, y los contenedores posteriores soportan el contenedor principal. Un ejemplo sería un contenedor de aplicación con un contenedor de soporte que envía los logs de aplicación a un servidor de registro. No vamos a entrar en detalles sobre los casos de uso de pod de varios contenedores en esta arquitectura, pero en la mayoría de los casos, solo hay un contenedor por pod.
Para desplegar nuestra solución Oracle Banking, adjuntaremos cada una de las siete imágenes de contenedor que estamos desplegando en su propio pod. Para ello, defina un archivo de manifiesto de pod de Kubernetes para cada imagen de contenedor.
Los pods se pueden desplegar directamente en Kubernetes, pero es más sólido desplegar pods con un despliegue de Kubernetes. Un despliegue de Kubernetes permite definir el estado o comportamiento deseado de un pod, como el número de copias o réplicas de un pod determinado. Un despliegue de Kubernetes también puede actualizar un pod existente a una nueva versión de aplicación. Depende de Kubernetes mantener el estado especificado de un pod.
Tendremos un total de siete despliegues para nuestra solución bancaria de Oracle. A cada pod de un despliegue se le asigna una dirección IP, pero las direcciones IP de los pods son efímeras y cambian a medida que se crean y destruyen los pods. Para proporcionar una forma consistente de acceder a los pods de un despliegue, se crea un servicio de Kubernetes para cada despliegue. Un servicio de Kubernetes es una abstracción que define un juego de pods. Cuando un servicio de Kubernetes está asociado a un despliegue, representará todos los pods del despliegue y equilibrará la carga del tráfico en cada uno de los pods. En función de cómo se deba acceder a los pods, si solo accederán a ellos otros recursos del cluster de Kubernetes, otros recursos de la VCN de OCI o externamente a través de Internet, se asignan diferentes tipos de servicios de Kubernetes al despliegue.
Para proporcionar resiliencia, nuestro pool de nodos de OKE abarcará las tres zonas de disponibilidad de nuestra región. En caso de que falle una zona de disponibilidad, todos los pods desplegados en los nodos de la zona de disponibilidad con fallos se volverán a crear automáticamente en los nodos de otra zona de disponibilidad.
Para la base de datos Oracle, que almacena los datos de los microservicios, mediante esquemas separados para cada uno de ellos, utilizamos la configuración de Oracle Real Application Clusters (Oracle RAC) en dos dominios de errores.
En el diagrama siguiente se ilustra esta arquitectura.
Descripción de la ilustración obma-oke-architecture.png
Para la base de datos Oracle que almacena los datos de los microservicios, mediante esquemas separados para cada uno de ellos, utilizamos una configuración RAC en dos dominios de disponibilidad (mediante dos dominios de errores que no se muestran en la imagen). Los datos se replican mediante Oracle Data Guard en el segundo dominio de disponibilidad.
La arquitectura tiene los siguientes componentes:
- Región
Una región de Oracle Cloud Infrastructure es un área geográfica localizada que contiene uno o más centros de datos, denominados dominios de disponibilidad. Las regiones son independientes entre sí y puede haber grandes distancias que las separen (entre países e incluso continentes).
- Dominios de disponibilidad
Los dominios de disponibilidad son centros de datos independientes dentro de una región. Los recursos físicos de cada dominio de disponibilidad están aislados de los recursos de los otros dominios de disponibilidad, lo que proporciona tolerancia a fallos. Los dominios de disponibilidad no comparten infraestructura, como la alimentación o la refrigeración, ni la red interna del dominio de disponibilidad. Por lo tanto, un fallo en un dominio de disponibilidad no debería afectar a los otros dominios de disponibilidad de la región.
- Dominios de errores
Un dominio de errores es una agrupación de hardware e infraestructura dentro de un dominio de disponibilidad. Cada dominio de disponibilidad cuenta con tres dominios de errores con energía y hardware independientes. Al distribuir los recursos entre varios dominios de errores, las aplicaciones pueden tolerar fallos físicos del servidor, mantenimiento del sistema y fallos de energía en un dominio de errores.
- Red y subredes virtuales en la nube (VCN)
Una VCN es una red personalizable y definida por software que puede configurar en una región de Oracle Cloud Infrastructure. Al igual que las redes de los centros de datos tradicionales, las redes virtuales le proporcionan el control de su entorno de red. Una VCN puede tener varios bloques de CIDR no superpuestos que puede cambiar después de crear la VCN. Puede segmentar una VCN en subredes, las cuales se pueden acotar a una región o a un dominio de disponibilidad. Cada subred está formada por un rango contiguo de direcciones que no se solapan con las demás subredes de la VCN. Puede cambiar el tamaño de una subred después de la creación. Una subred puede ser pública o privada.
- Equilibrador de carga
El servicio Oracle Cloud Infrastructure Load Balancing proporciona una distribución automatizada del tráfico desde un único punto de entrada a varios servidores en el backend.
- Host bastión
El host bastión es una instancia informática que sirve como punto de entrada seguro y controlado a la topología desde fuera de la nube. El host bastión se aprovisiona, por lo general, en una zona desmilitarizada (DMZ). Le permite proteger los recursos sensibles, colocándolos en redes privadas a las que no se puede acceder directamente desde fuera de la nube. La topología tiene un único punto de entrada conocido que puede supervisar y auditar con regularidad. Por lo tanto, puede evitar exponer los componentes más sensibles de la topología sin comprometer el acceso.
- Sistemas de base de datos
Para un despliegue pequeño, basta con una unidad VM.Standard2.2. Esta arquitectura utiliza un sistema de base de datos con Oracle Database Enterprise Edition - Extreme Performance, utilizando Oracle Real Application Clusters (RAC). También utiliza Oracle Automatic Storage Management (Oracle ASM) con un mínimo de 256 GB.
- Volumen en bloque
Con los volúmenes de almacenamiento en bloque, puede crear, asociar, conectar y mover los volúmenes de almacenamiento, así como cambiar el rendimiento de volumen para cumplir con sus requisitos de almacenamiento, rendimiento y aplicación. Después de asociar y conectar un volumen a una instancia, puede utilizar el volumen como si se tratara de una unidad de disco duro normal. También puede desconectar un volumen y asociarlo a otra instancia sin perder datos.
- Object Storage
Object Storage proporciona acceso rápido a grandes cantidades de datos estructurados y no estructurados de cualquier tipo de contenido, incluidas copias de seguridad de base de datos, datos analíticos y contenido enriquecido, como imágenes y vídeos. Puede almacenar datos de forma segura y, a continuación, recuperarlos directamente desde Internet o desde la plataforma en la nube. Puede ampliar el almacenamiento sin experimentar ninguna degradación del rendimiento ni de la fiabilidad del servicio. Utilice el almacenamiento estándar para el almacenamiento al que debe acceder de forma rápida, inmediata y frecuente. Utilice el almacenamiento de archivo para el almacenamiento "frío" al que conserva durante largos períodos de tiempo y al que rara vez accede.
- Gateway de traducción de direcciones de red (NAT)
Un gateway de NAT permite que los recursos privados de una VCN accedan a hosts en Internet, sin exponer dichos recursos a conexiones de Internet entrantes.
- Gateway de servicio
El gateway de servicios proporciona acceso desde una VCN a otros servicios, como Oracle Cloud Infrastructure Object Storage. El tráfico de la VCN al servicio Oracle viaja por el tejido de red de Oracle y no atraviesa Internet.