Saiba mais sobre a implementação de microsserviços bancários da Oracle e do OCI Kubernetes Engine

Saiba como usar o Oracle Cloud Infrastructure Kubernetes Engine e os Microsserviços Bancários da Oracle para modernizar sua infraestrutura bancária. O OCI Kubernetes Engine (OKE) é um serviço totalmente gerenciado, escalável e altamente disponível que você pode usar para implantar seus aplicativos de contêineres na nuvem. Use o OKE quando sua equipe de desenvolvimento quiser criar, implantar e gerenciar de maneira confiável aplicativos nativos da nuvem. Você especifica os recursos de computação que seus aplicativos exigem, e o OKE os provisiona no OCI em uma tenancy existente do OCI.

Arquitetura

Essa arquitetura descreve como implementar os Microsserviços Bancários da Oracle e o OCI Kubernetes Engine para aproveitar os microsserviços com eficiência.

Oracle Banking Microservices Architecture

A Oracle fornece o mais amplo conjunto de soluções bancárias orientadas por domínio do setor, abrangendo bancos corporativos e de varejo, além de front-to-back completo, desde a camada de experiência digital do cliente até os processadores de produtos bancários ou domínios bancários principais.

Todos esses recursos são fornecidos como um conjunto de módulos autônomos, projetados usando design orientado por domínio e implementados usando uma arquitetura de microsserviços de última geração. Cada módulo é composto por um conjunto de microsserviços específicos do domínio de negócios, um conjunto de microsserviços básicos funcionais comuns (núcleo comum) em todos os módulos e serviços de plataforma que fornecem os recursos técnicos necessários.

O diagrama a seguir ilustra os diferentes níveis de microsserviços no módulo de ramificação.



Essa arquitetura oferece flexibilidade máxima de implementação. Cada microsserviço pode ser conteinerizado em uma imagem do docker e implantado separadamente. Essa opção fornece controle completo sobre a implantação, permitindo que você atualize ou amplie qualquer microsserviço específico com base em requisitos específicos do cliente.

Alguns clientes podem não exigir esse nível de granularidade para gerenciamento de plataforma e podem preferir uma abordagem simplificada, agrupando os microsserviços em um número reduzido de imagens do docker. Embora essa abordagem reduza a flexibilidade para atualizar e dimensionar em um nível individual, ela ainda fornece o nível de controle necessário para os clientes com requisitos padrão sobre escalabilidade, alta disponibilidade e assim por diante. Nesse cenário, é importante agrupar os microsserviços considerando suas implicações e natureza específica. Nesta arquitetura de referência propomos um agrupamento que considera estes fatores:

  • Tipo de carga de trabalho: baseado em REST, baseado em lote, baseado em evento, baseado em fluxo de trabalho.
  • Componentes críticos: Alguns componentes são críticos para a plataforma. Eles têm uma carga de trabalho maior do que outros.

O diagrama a seguir ilustra o agrupamento proposto.


Veja a seguir a descrição da obma-service-landscape-branch-module-proposed.png
Descrição da ilustração obma-service-landscape-branch-module-proposed.png

Aqui está uma explicação desses agrupamentos:

  • SD do Domínio: Contém os microsserviços do domínio de negócios do módulo, neste caso, o módulo de ramificação.
  • CMC SD: Microsserviços básicos comuns ou funcionais.
  • Plato SD: Contém os microsserviços técnicos da plataforma que não foram implantados separadamente.
  • Kafka: Usado pela plataforma Event Hub para comunicação entre microsserviços e sistemas externos.
  • Condutor: Mecanismo de fluxo de trabalho da plataforma usada para orquestrar os microsserviços e criar fluxos de trabalho humanos.
  • Servidor Batch: Executa os processos batch exigidos pelo domínio de negócios.

Esta solução agrupa sete imagens do docker.

Arquitetura de Implantação usando o OKE

O OCI Kubernetes Engine usa o Kubernetes - o sistema de código aberto para automatizar a implantação, o dimensionamento e o gerenciamento de aplicativos de contêineres em clusters de hosts. O Kubernetes grupo os contêineres que compõem um aplicativo em unidades lógicas (chamadas pods) para facilitar o gerenciamento e a descoberta.

Para executar contêineres no Kubernetes, eles devem estar em um pod. Um pod é a menor unidade atômica do Kubernetes e é uma construção que executa um agrupamento de contêineres que compartilham a mesma rede, armazenamento, memória e namespace IPC. Há um contêiner principal em um pod, e os contêineres subsequentes suportam o contêiner principal. Um exemplo seria um contêiner de aplicativos com um contêiner de suporte que envia os logs do aplicativo para um servidor de logs. Não entraremos em detalhes sobre casos de uso de pods com vários contêineres nessa arquitetura, mas na maioria dos casos, há apenas um contêiner por pod.

Para implementar nossa solução Oracle Banking, incluiremos cada uma das sete imagens de contêiner que estamos implantando em seu próprio pod. Isso pode ser feito definindo um arquivo de manifesto de pod do Kubernetes para cada imagem de contêiner.

Os pods podem ser implantados diretamente no Kubernetes, mas é mais robusto implantar pods com uma implantação do Kubernetes. Uma implantação do Kubernetes permite definir o estado ou o comportamento desejado de um pod, como o número de cópias ou réplicas de um determinado pod. Uma implantação do Kubernetes também pode fazer upgrade de um pod existente para uma nova versão do aplicativo. Cabe ao Kubernetes manter o estado especificado de um pod.

Teremos um total de sete implementações para nossa solução bancária da Oracle. Cada pod em uma implantação recebe um endereço IP, mas os endereços IP dos pods são efêmeros e mudam à medida que os pods são criados e destruídos. Para fornecer uma maneira consistente de acessar pods em uma implantação, um serviço do Kubernetes é criado para cada implantação. Um serviço Kubernetes é uma abstração que define um conjunto de pods. Quando um serviço do Kubernetes estiver associado a uma implantação, ele representará todos os pods na implantação e balanceará a carga do tráfego para cada um dos pods. Dependendo de como os pods precisam ser acessados, se eles serão acessados apenas por outros recursos no cluster do Kubernetes, outros recursos dentro da sua VCN do OCI ou externamente pela internet, diferentes tipos de serviços do Kubernetes são designados à implantação.

Para fornecer resiliência, nosso pool de nós do OKE abrangerá todas as três zonas de disponibilidade em nossa região. Caso uma zona de disponibilidade falhe, todos os pods implantados nos nós da zona de disponibilidade com falha serão recriados automaticamente nos nós de outra zona de disponibilidade.

Para o banco de dados Oracle, que armazena os dados dos microsserviços, usando esquemas separados para cada um deles, usamos a configuração do Oracle Real Application Clusters (Oracle RAC) em dois domínios de falha.

O diagrama a seguir ilustra essa arquitetura.


Veja a seguir a descrição da obma-oke-architecture.png
Descrição da ilustração obma-oke-architecture.png

obma-oke-architecture.zip

Para o banco de dados Oracle que armazena os dados dos microsserviços, usando esquemas separados para cada um deles, usamos uma configuração RAC em dois domínios de disponibilidade (usando dois domínios de falha não mostrados na imagem). Os dados são replicados usando o Oracle Data Guard no segundo domínio de disponibilidade.

A arquitetura tem os seguintes componentes:

  • Região

    Região do Oracle Cloud Infrastructure é uma área geográfica localizada que contém um ou mais data centers, denominada domínios de disponibilidade. As regiões são independentes de outras regiões, e grandes distâncias podem separá-las (entre países ou até mesmo continentes).

  • Domínios de disponibilidade

    Domínios de disponibilidade são data centers stand-alone e independentes dentro de uma região. Os recursos físicos de cada domínio de disponibilidade são isolados dos recursos de outros domínios de disponibilidade, o que oferece tolerância a falhas. Os domínios de disponibilidade não compartilham infraestrutura como energia ou refrigeração ou a rede interna do domínio de disponibilidade. Portanto, uma falha em um domínio de disponibilidade não deve afetar os outros domínios de disponibilidade na região.

  • Domínios de falha

    Um domínio de falha é um agrupamento de hardware e infraestrutura dentro de um domínio de disponibilidade. Cada domínio de disponibilidade tem três domínios de falha com energia e hardware independentes. Quando você distribui recursos entre vários domínios de falha, seus aplicativos podem tolerar falha no servidor físico, manutenção do sistema e falhas de energia dentro de um domínio de falha.

  • Rede virtual na nuvem (VCN) e sub-redes

    Uma VCN é uma rede personalizável definida por software que você configura em uma região do Oracle Cloud Infrastructure. Como as redes tradicionais de data center, as VCNs oferecem controle sobre seu ambiente de rede. Uma VCN pode ter vários blocos CIDR não sobrepostos que você pode alterar após a criação da VCN. Você pode segmentar uma VCN em sub-redes, com escopo definido para uma região ou para um domínio de disponibilidade. Cada sub-rede consiste em um intervalo contíguo de endereços que não se sobrepõem a outras sub-redes da VCN. Você pode alterar o tamanho de uma sub-rede após a criação. Uma sub-rede pode ser pública ou privada.

  • Balanceador de carga

    O serviço Oracle Cloud Infrastructure Load Balancing fornece distribuição automatizada de tráfego de um único ponto de entrada para vários servidores no back-end.

  • Bastion host

    O bastion host é uma instância de computação que atua como um ponto de entrada seguro e controlado para a topologia de fora da nuvem. O bastion host geralmente é provisionado em uma zona desmilitarizada (DMZ). Ele permite proteger recursos confidenciais colocando-os nas redes privadas que não podem ser acessadas diretamente de fora da nuvem. A topologia tem um único ponto de entrada conhecido que você pode monitorar e auditar regularmente. Desse modo, você pode evitar expor os componentes mais confidenciais da topologia sem comprometer o acesso a eles.

  • Sistemas de BD

    Para uma implantação pequena, uma forma VM.Standard2.2 é suficiente. Essa arquitetura usa um sistema de BD com o Oracle Database Enterprise Edition - Extreme Performance, usando o Oracle Real Application Clusters (RAC). Ele também usa o Oracle Automatic Storage Management (Oracle ASM) com um mínimo de 256 GB.

  • Volume em blocos

    Com volumes de armazenamento em blocos, você pode criar, anexar, conectar e mover volumes de armazenamento e alterar o desempenho do volume para atender aos seus requisitos de armazenamento, desempenho e aplicativo. Depois de anexar e conectar um volume a uma instância, você pode usar o volume como disco rígido comum. Também é possível desconectar um volume e anexá-lo a outra instância sem perder dados.

  • Object Storage

    O armazenamento de objetos oferece acesso rápido a grandes quantidades de dados estruturados e não estruturados de qualquer tipo de conteúdo, incluindo backups de bancos de dados, dados de análise e conteúdo avançado, como imagens e vídeos. Você pode armazenar de forma segura e depois recuperar dados diretamente da internet ou de dentro da plataforma da nuvem. Você pode dimensionar o armazenamento sem prejudicar o desempenho ou a confiabilidade do serviço. Use o armazenamento padrão para armazenamento de acesso frequente que você precisa para acessar de forma rápida, imediata e com frequência. Use o armazenamento de arquivos compactados para armazenamento "frio" que você mantém por longos períodos de tempo e raramente acessa.

  • Gateway NAT (Network Address Translation)

    Um gateway NAT permite que recursos privados em uma VCN acessem hosts na internet, sem expor esses recursos a conexões de internet de entrada.

  • Gateway de serviço

    O gateway de serviço fornece acesso de uma VCN a outros serviços, como o Oracle Cloud Infrastructure Object Storage. O tráfego da VCN para o serviço Oracle percorre a malha da rede Oracle e não passa pela internet.

Explorar Mais

Saiba mais sobre como implementar o Oracle Banking Microservices e o OCI Kubernetes Engine.

Revise estes recursos adicionais:

Reconhecimentos

  • Author: Javier Vidal
  • Contributor: Chiping Hwang