Saiba Mais sobre a Arquitetura de Microsserviços

Os aplicativos modernos são criados por meio da composição de alguns serviços criados de forma independente. Isso proporciona agilidade e velocidade de comercialização para corrigir problemas e introduzir novos recursos.

Esse paradigma é referido como uma arquitetura de microsserviços, embora o número de serviços que se reúnem para uma aplicação completa possa estar nas centenas (microsserviços) ou nas dezenas (macrosserviços). Há novos termos também sendo usados para monólitos modulares chamados moduliths, e Spring Modulith é um exemplo.

Embora muitas organizações já tenham uma arquitetura de microsserviços, as implantações de microsserviços estão atoladas com a complexidade e as implantações bem-sucedidas ainda estão em andamento na maioria das organizações. Este manual de soluções tenta simplificar a criação e a implantação de microsserviços modernos com a popular plataforma Spring Boot, juntamente com infraestrutura de nuvem, contêineres, Kubernetes e plataforma Backend as a Service com o Oracle Database.

Se você quiser projetar um aplicativo que seja multilíngue, facilmente escalável, fácil de manter e implementar, altamente disponível e que minimize falhas, use a arquitetura de microsserviços para projetar e implantar um aplicativo em nuvem. Em uma arquitetura de microservices, cada microservice possui uma tarefa simples e se comunica com os clientes ou com outros microservices usando mecanismos de comunicação leves, como solicitações de API REST.

O diagrama a seguir mostra a arquitetura de um aplicativo que consiste em vários microsserviços.

Descrição da ilustração microservice_architecture.png

Os microservices permitem que você projete seu aplicativo como uma coleção de serviços fracamente acoplados. Os microsserviços seguem o modelo de não compartilhamento e são executados como processos sem monitoramento de estado. Com essa abordagem, é mais fácil dimensionar e manter o aplicativo.

A camada de API é o ponto de entrada de todas as solicitações do cliente para um microsserviço. A camada API também permite que os microsserviços se comuniquem entre si por HTTP, gRPC e TCP/UDP.
A camada lógica se concentra em uma única tarefa de negócios, minimizando as dependências dos outros microsserviços. Essa camada pode ser gravada em um idioma diferente para cada microsserviço.
A camada de armazenamento de dados fornece um mecanismo de persistência, como um mecanismo de armazenamento de banco de dados, arquivos de log etc. Considere o uso de um armazenamento de dados persistente separado para cada microsserviço. A Oracle oferece contêineres de banco de dados com vários bancos de dados plugáveis que facilitam para microsserviços isolar dados para segurança, HA e dimensionamento. Além disso, os aplicativos SaaS podem aproveitar a multilocação de maneira segura. Além disso, um banco de dados convergente traz a variedade de dados sob o mesmo teto para insights mais ricos dos dados.

Geralmente, cada microsserviço é executado em um contêiner que fornece um ambiente de runtime leve.

Diferenças Entre Microsserviços e Arquiteturas Monolíticas

Antes de começar a projetar aplicativos usando a arquitetura de microsserviços, você deve entender como essa arquitetura difere da arquitetura monolítica tradicional.

O design do aplicativo se concentra na solução de requisitos de negócios e na implementação da lógica de negócios. Em uma arquitetura monolítica, todo o aplicativo é criado como uma única unidade que contém toda a lógica de negócios. Na arquitetura de microsserviços, a lógica de negócios é organizada como vários serviços fracamente acoplados.

A ilustração a seguir mostra as arquiteturas monolíticas e de microsserviços.

Descrição da ilustração monolithic_vs_microservice.png

A tabela a seguir resume as diferenças entre os microsserviços e as arquiteturas monolíticas.

Característica	Arquitetura de Microsserviços	Arquitetura Monolítica
Projeto da unidade	O aplicativo consiste em serviços fracamente acoplados. Cada serviço suporta uma única tarefa de negócios.	Todo o aplicativo é projetado, desenvolvido e implantado como uma única unidade.
Reuso de funcionalidades	Os microservices definem APIs que expõem suas funcionalidades para qualquer cliente. Os clientes podem até ser outros aplicativos.	A oportunidade de reutilizar a funcionalidade em todos os aplicativos é limitada.
Comunicação no aplicativo	Para se comunicar entre si, os microsserviços de um aplicativo usam o modelo de comunicação de solicitação-resposta. A implementação típica usa chamadas da API REST com base no protocolo HTTP.	Os procedimentos internos (chamadas de função) facilitam a comunicação entre os componentes do aplicativo. Não há necessidade de limitar o número de chamadas de procedimento interno.
Flexibilidade tecnológica	Cada microsserviço pode ser desenvolvido usando uma linguagem de programação e uma estrutura que melhor se adapte ao problema que o microsserviço foi projetado para resolver.	Geralmente, todo o aplicativo é escrito em uma única linguagem de programação.
Gerenciamento de dados	Descentralizado: Cada microsserviço pode usar seu próprio banco de dados.	Centralizado: todo o aplicativo usa um ou mais bancos de dados.
Implantação	Cada microsserviço é implantado de forma independente, sem afetar os outros microsserviços no aplicativo.	Qualquer alteração, por menor que seja, requer reimplantação e reinicialização de todo o aplicativo.
Capacidade de Manutenção	Os microsserviços são simples, focados e independentes. Portanto, o aplicativo é mais fácil de manter.	À medida que o escopo do aplicativo aumenta, a manutenção do código torna-se mais complexa.
Resiliência	A funcionalidade do aplicativo é distribuída por vários serviços. Se um microsserviço falhar, a funcionalidade oferecida pelos outros microsserviços continuará disponível.	Uma falha em qualquer componente pode afetar a disponibilidade de todo o aplicativo.
Escalabilidade	Cada microsserviço pode ser dimensionado de forma independente aos outros serviços.	Todo o aplicativo deve ser dimensionado, mesmo quando o requisito de negócios é dimensionar apenas determinadas partes do aplicativo.

Considerações para Adotar a Arquitetura de Microsserviços

Ao projetar um novo aplicativo, considere a arquitetura de microsserviços para aplicativos que exigem altos níveis de escalabilidade, flexibilidade e confiabilidade. Você pode usar uma linguagem de programação e uma estrutura diferentes para desenvolver cada componente.

Considere migrar um aplicativo monolítico para microsserviços se você puder dividir a funcionalidade do aplicativo em serviços focados, cada um com um escopo limitado. Para aplicativos monolíticos complexos que não podem ser migrados para a arquitetura de microsserviços, considere o desenvolvimento apenas da nova funcionalidade como microsserviços.

As interdependências entre os serviços podem afetar o quanto do aplicativo está indisponível durante uma reimplantação de serviço. Resolva esses problemas de dependência durante o design do aplicativo.

A refatoração de uma aplicação monolítica é difícil. Se você pretende usar a arquitetura de microsserviços, planeje-a desde o início do projeto.

Considere as complexidades dos sistemas distribuídos ao desenvolver microsserviços e lembre-se de que as chamadas remotas são lentas e podem falhar. Dependendo do caso de uso, você deve equilibrar entre consistência, disponibilidade e tolerância a partição.

Esteja preparado para a complexidade operacional que a arquitetura de microsserviços envolve. Recomendamos atender aos seguintes pré-requisitos antes de mover um aplicativo monolítico para a arquitetura de microsserviços:

Provisionamento rápido: Capacidade de provisionar servidores rapidamente
Monitoramento básico: Capacidade de detectar problemas de serviço e problemas de negócios. Os problemas de serviço incluem disponibilidade do serviço, erros funcionais e problemas de desempenho
Implementação rápida de aplicativos: Capacidade de implantar qualquer serviço rapidamente nos ambientes de teste e produção

Certifique-se de que os benefícios da arquitetura de microsserviços superem o custo.

Sobre o mecanismo de comunicação em uma arquitetura de microsserviços

Em uma arquitetura de microsserviços, os serviços são executados em vários servidores. A comunicação entre esses serviços ocorre por meio de protocolos como HTTP, AMQP e TCP. HTTP/REST e mensagens assíncronas são os protocolos mais utilizados.

Uma API REST para web services geralmente usa o protocolo HTTP. Com métodos HTTP (como GET, POST, PUT e DELETE), os clientes podem acessar e manipular os recursos do aplicativo usando um localizador de recursos uniforme (URL).

Os clientes enviam uma solicitação a um serviço por meio de uma API REST que representa um ponto de entrada para a funcionalidade do aplicativo. Os clientes podem se comunicar com microsserviços diretamente ou por meio de um gateway de API.

Um padrão de gateway de API define um único ponto de entrada para todas as solicitações aos serviços. Quando uma solicitação do cliente chega, o gateway de API roteia a solicitação para o serviço apropriado.

Uma variante do padrão de gateway de API é o padrão de backend para frontend, que define um gateway de API separado para cada tipo de cliente (por exemplo, um gateway para clientes móveis e outro para aplicativos Web).

Minimizar a comunicação entre os serviços é uma prática recomendada. Quando a comunicação é essencial, a comunicação assíncrona é preferível. O serviço que envia a solicitação pode continuar operando sem aguardar uma resposta.

Filas de mensagens e sistemas de streaming são métodos ideais para fornecer comunicação assíncrona e, quando integrados no banco de dados, fornecem semântica transacional para uma operação de dados e envio de uma mensagem. Isso torna os microsserviços mais simples e escaláveis de implementar. O uso de APIs REST torna exclusivamente a comunicação entre microsserviços síncrona e geralmente limita o dimensionamento.

Sobre Serviços e Atribuições Necessários

Esta solução requer os seguintes serviços:

Oracle Cloud Infrastructure Database (uma variedade de opções, incluindo Oracle Autonomous Database)
Oracle Cloud Infrastructure Container Engine for Kubernetes
Oracle Backend for Spring Boot and Microservices

Estas são as atribuições necessárias para cada serviço.

Nome do Serviço: Atribuição	Obrigatório para...
Oracle Cloud Infrastructure Database: `SYSTEM` ou `ADMIN`	Crie um usuário para acessar o banco de dados proxy ao configurar o Oracle Backend for Spring Boot and Microservices. Embora `SYSTEM` ou `ADMIN` funcionem, eles têm privilégios excessivos e não devem ser usados em ambientes de produção.
Oracle Cloud Infrastructure Container Engine for Kubernetes: `CLUSTER_MANAGE`	Crie o cluster do Oracle Cloud Infrastructure Container Engine for Kubernetes e um pool de nós com três nós de trabalho.
Oracle Backend for Spring Boot and Microservices: `ROLE_ADMIN`	Instale o Oracle Backend for Spring Boot and Microservices.

Consulte Produtos, Soluções e Serviços Oracle para obter o que você precisa.