[Gov.Doc] Estudo sobre utilização de microsserviços

Objetivo

O objetivo desse estudo é analisar a utilização de microsserviços no sistema Gov.Doc que atualmente é monolítico, quais as alterações devem ser realizadas e com quais tecnologias.

Por que mudar?

O Gov.Doc nasceu com um grande potencial de crescimento, e para que futuramente não haja problemas de expansão e manutenção e também, para que melhore no desempenho, escalabilidade e publicação, foi idealizada pelo time a mudança de arquitetura monolítica para a de microsserviços, sendo implantada com o tempo, aproveitando que o sistema ainda não é muito grande, facilitando sua migração para microsserviços.

Arquiteturas de aplicações

Uma arquitetura de aplicação indica como o projeto é construído e integrado, geralmente para aplicações web são utilizados os seguintes padrões de arquitetura, sistemas com arquitetura Monolítica ou sistemas com arquitetura de Microsserviços.

Arquitetura Monolítica

Um sistema que segue essa arquitetura, é um sistema único e não dividido, concentrado e interligado apenas em um projeto e rodando apenas em um único processo, porém, possuindo suas vantagens e desvantagens.

Figura 1: Representação de um sistema Monolítico

Arquitetura de Microsserviços

A arquitetura de microsserviços é estruturar seu sistema através de uma coleção de serviços independentes se comunicando e cada um com sua responsabilidade, melhorando a escalabilidade, implementação, publicação e manutenção.

Figura 2: Representação de um sistema em Microsserviços

Separação de serviços do Gov.Doc

Para iniciar a migração de arquitetura no Gov.Doc, foram analisados e escolhidos alguns serviços que potencialmente podem se tornar microsserviços, sendo eles o serviço de Log do sistema e o serviço de envio de E-mail. Para executar essa separação, serão criados dois projetos separados cada um com sua responsabilidade e executados em contêineres no openshift.

Comunicação entre microsserviços

A comunicação entre os microsserviços e da aplicação web pode ser feita com de requisições HTTP (REST) através de mensagens em filas como RabbitMQ ou Kafka, onde atualmente, existe um projeto de implantação. O funcionamento é relativamente simples, um microserviço publica uma mensagem na fila (Producer), essa mensagem pode ser uma requisição para outro microserviço, que está consumindo a fila (Consumer), que recebe essa mensagem e trata a requisição. O Conceito de filas é indicado para microsserviços, para que não haja nenhuma condição de corrida ou inconsistência no banco, para coordenar os microsserviços e para aumentar a escalabilidade, confiabilidade e desempenho.

Figura 3: Representação de filas de mensagens KAFKA

Banco de Dados em microsserviços

Outra grande questão no ambiente de microsserviços é o banco de dados,