Padrões de projeto e práticas recomendadas para microsserviços

Os Padrões de Projeto (do inglês: Design Patterns) são um conjunto de soluções típicas para problemas comuns em sistemas de software. No contexto da arquitetura de microsserviços, não há uma catalogação dos padrões de projeto tida como "oficial" (diferente dos sistemas gerais de software, cujos padrões principais foram descritos no livro "A pattern Language").

Devido à natureza distribuída e em nuvem dos microsserviços, existem diversas práticas recomendadas para sua implementação, por conta da alta complexidade. Quando serviços precisam comunicar-se entre si, por meio de API's, é necessário clareza e simplicidade na comunicação. Daí a necessidade de se adotar padrões de projeto corretos e boas práticas de implantação.

Conceitos

Padrões de projeto

Padrões de projeto são soluções reutilizáveis para problemas recorrentes no desenvolvimento de software. Eles ajudam a organizar o código, torná-lo mais legível e a promover boas práticas de programação. Esses padrões não são código em si, mas guias para implementar soluções eficientes.

Microsserviços

Microsserviços são uma arquitetura de software em que o sistema é dividido em pequenos serviços independentes, cada um responsável por uma funcionalidade específica. Esses serviços são autônomos, podendo ser desenvolvidos, implantados e escalados de forma independente. A utilização de serviços em nuvem, escaláveis e com reutilização de componentes popularizou a arquitetura de microsserviços.

Padrões de projeto

Embora não haja uma catalogação formal dos padrões, diversas fontes apontam os seguintes padrões como principais:

API Gateway

um gateway de API é como um roteador de requisições. Todas as requisições passam por um "gateway" que a direciona para o serviço correspondente e devolve as saídas para o usuário. As vantagens podem ser resumidas no fato de que um request com falha parcial não bloqueará o processo inteiro, resultando em uma melhor experiência para o usuário final. O usuário, inclusive, não terá ciência da forma como os serviços são distribuídos no sistema.

Um exemplo de aplicação do API Gateway é um sistema de e-commerce, onde o sistema tem que lidar com autenticação, catálogo, preços, pagamentos e gerenciamento de pedidos. Um API gateway facilita a integração de todos os módulos do sistema.

Base de Dados por Serviço

Separar as bases de dados por serviço é uma estratégia que favorece o desempenho e a organização de código. Em sistemas que realizam tarefas com necessidades de dados diferentes, é mais prático e eficiente separar as bases de dados em favor de criar bases extremamente complexas de se manter e acessar.

Um sistema que demanda cadastro de usuários, métricas de análise e cobranças, por exemplo, pode demandar diferentes tecnologias para cada base (SQL, NoSQL, vetorial) e portanto é mais fácil ter bases de dados dedicadas para cada serviço. A desvantagem é o aumento dos sistemas de redundância e tolerância à falhas, já que cada base de dados deve ter seu próprio sistema de recuperação.

Circuit Breaker

O Circuit Breaker implementa um sistema detecção de falhas, que pode agir bloqueando requisições a algum serviço caso esse apresente uma falha ou um alto tempo de resposta. Esse padrão é extremamente útil quando o sistema utiliza serviços de terceiros. Após "quebrar o cricuito", um circuit breaker pode exibir uma mensagem de erro padrão ou buscar alternativas (um serviço semelhante, por exemplo) para lidar com a falha. Isso evita que o sistema fique esperando respostas indefinidamente, causando frustração no usuário final.

Command Query Responsibility Segregation

O CQRS (em português: Segregação da Responsabilidade Comando-Consulta) consiste em separar as operações de consulta das operações de comando. Assim, pode-se otimizar as consultas para exibir dados rapidamente em diversas visualizações, enquanto os comandos (que escrevem dados em um banco) são separados e podem também ser otimizados.

Saga

O padrão Saga gerencia operações distribuídas. Cada operação bem-sucedida publica um evento, que serve como gatilho para operações que dependam da última. Assim, pode-se distribuir melhor os microsserviços de modo a garantir que a falha de um serviço possa ser compensada por processos de rollback.

Event Sourcing

O padrão Event Sourcing é útil quando se quer ter um registro das mudanças de estado do sistema. As mudanças são registradas através de uma aplicação utilitária, que serve como um agente de mensagens, que facilita a troca de informações entre os diferentes microsserviços. Além disso, o registro de mudanças pode ajudar a restaurar o estado do sistema em caso de falha.

Strangler

O padrão Strangler é utilizado para a transição entre um sistema monolítico e um sistema de microsserviços. Ele funciona a partir da implementação de um microsserviço que substitui uma funcionalidade atual do sistema. Assim, essa funcionalidade é "estrangulada" a partir do momento que é substituída por um microsserviço.

Boas práticas de implementação

Com o crescimento da arquitetura de microsserviços, é importante se atentar a algumas práticas que podem facilitar e melhorar os sistemas gerados, além de evitar erros, retrabalho e má otimização. São elas:

Uso do DDD (Domain-Driven Design)

O uso do DDD pode melhorar a produtividade da equipe que implementa os microsserviços. O DDD consiste de duas fases que são igualmente úteis:

Fase estratégica: Garante que a arquitetura do sistema aborda as necessidades e capacidades do sistema

Fase tática: Permite o desenvolvimento de um modelo de domínio a partir de um padrão diferente

Essa estratégia ajuda a entender quais as necessidades e capacidades do sistema a ser implementado e avaliar a forma de implementar a arquitetura de microsserviços.

Utilização de serviços de nuvem e DevOps

A migração de um sistema monolítico é uma tarefa trabalhosa e complexa. Além da organização e planejamento, é necessário também ter uma estrutura robusta, com automação de monitoramento e suporte de nuvem. De outra forma, não faz sentido utilizar uma arquitetura de microsserviços

Cuidado com a atualização das API's

É importante atualizar e modificar as API's para melhorar e atualizar o serviço. Porém, é necessário verificar se a API continua compatível com os serviços que dependem dela. É responsabilidade da API criar testes de compatibilidade. Quando há muitas dependências, é muito difícil modificar todos os componentes. É mais fácil manter suas API's compatíveis entre si.

Não criar microsserviços pequenos demais

Quebrar os microsserviços em componentes pequenos demais pode reduzir a agilidade do sistema, uma vez que a comunicação entre serviços (principalmente em nuvem) leva algum tempo. Quanto mais comunicações são necessárias, maior o tempo total de execução de um serviço. Portanto, a melhor estratégia é dividir os serviços somente quando estes se tornarem muito complexos.

Monitoramento e documentação

Em desenvolvimento de software é importante manter uma documentação atualizada a respeito das mudanças e implementações. Essa importância aumenta quando se fala em serviços distribuídos, que implementam diversos sistemas. Portanto, é necessário ter um registro claro e conciso sobre as mudanças, decisões de projeto, atualizações e melhorias.

Liberação individual

Para facilitar o diagnóstico de erros é importante, junto com a documentação e com a integração dos serviços, liberar novas features em um serviço por vez. Assim, garante-se que caso ocorra uma falha, sabe-se exatamente qual sistema falhou, facilitando a correção de erros.

Referências

Capital One Tech. "10 microservices design patterns for better architecture" https://www.capitalone.com/tech/software-engineering/microservices-design-patterns/

navlaniwesr. "Microservices Design Patterns" https://www.geeksforgeeks.org/microservices-design-patterns/

lognoroy2000. "10 Best Practices for Microservices Architecture in 2024". https://www.geeksforgeeks.org/best-practices-for-microservices-architecture/

IBM. "O que são microsserviços?" https://www.ibm.com/br-pt/topics/microservices