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

Objetivo

O objetivo desse estudo é abordar a análise da 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, que com o aumento de requisições e separação para a arquitetura de microsserviços, deverá ser gerenciado de outra maneira. Foram levantadas várias formas de se tratar o banco de dados nos microsserviços, uma delas é o Caching.

Figura 3: Representação de caching do banco de dados

O caching atua como uma camada de acesso a dados (cache em memória) adjacente ao seu banco de dados, que os seus aplicativos podem utilizar para melhorar o desempenho, permitindo aumentar a taxa de transferência e diminuir a latência de recuperação dos dados. Uma tecnologia que implementa o cache é o Redis que além de armazenar o banco em cache, também pode auxiliar em filas e mensagens de requisições.

Conclusão

Após todo o estudo de utilização de microsserviços, pode se entender que a implementação de microsserviços no sistema Gov.Doc terá de ser feito em várias etapas, pois existem várias tecnologias que devem ser utilizadas para que tudo funcione corretamente, alguns tópicos valem a pena serem estudados em spikes futuras, como:

- Implementação e uso de filas de mensagens Kafka;
- Comunicação entre microsserviços
- Separação do sistema em microsserviços;
- Utilização de Caching de banco de dados no EF Core.

Glossário

Container - É um ambiente isolado onde o software é executado.
Openshift - Gerenciamento de softwares baseados em contêineres.
Kafka - É um sistema de mensagens usado para criar aplicações com fluxo de dados contínuo.
RabbitMQ - É um servidor de mensageria de código aberto.
HTTP - Protocolo de comunicação utilizado para sistemas de informação.
Producer - É a aplicação que envia mensagens no Kafka.
Consumer - É aplicação que recebe as mensagens do Kafka
Cache - Área de memória onde é mantida uma cópia temporária de dados armazenados.

Referências

[1] REDHAT. O que são os microsserviços? Disponível em: https://www.redhat.com/pt-br/topics/microservices/what-are-microservices. Acesso em: 11 maio 2021.

[2] LENZ, Thiago Alexandre. Conhecimentos necessários antes de adotar microsserviços. 2019. Disponível em: https://inside.contabilizei.com.br/conhecimentos-necess%C3%A1rios-antes-de-adotar-micro-servi%C3%A7os-parte-2-8f8a429ffdd. Acesso em: 11 maio 2021

[3] AMAZON WEB SERVICES. Redis, Datastore de código aberto, rápido e na memória e para uso como banco de dados, cache, agente de mensagens e fila. 2020. Disponível em: https://aws.amazon.com/pt/redis/. Acesso em: 11 maio 2021.

[4] DAKAR, Romulo. Redis – o que é e para que serve? 2015. Disponível em: http://desenvolvedor.ninja/redis-o-que-e-e-para-que-serve/. Acesso em: 11 maio 2021.

[5] PENNA, William. Arquitetura Monolítica e Microsserviços. Disponível em: https://www.zappts.com/blog/arquitetura-monolitica-e-microsservicos/. Acesso em: 11 maio 2021.

[6] REIS, Marco. Como fazer a integração de dados com Apache Kafka. 2021. Disponível em: https://blog.geekhunter.com.br/apache-kafka/. Acesso em: 11 maio 2021.

Gerente de Desenvolvimento
Janderson de Castro Thomaz

Product Owner
Adriano Bonazoni Sol Sol de Oliveira

Scrum Master
Wagner Moreira Melo

Time de Desenvolvimento
Tambaquis