Como começar a lidar com código duplicado em Microsserviços

#microservices #programming #learning #backend

Esse artigo é um guia introdutório sobre técnicas de reutilização de código em microsserviços, voltado principalmente para desenvolvedores iniciantes e intermediários que estão começando a lidar com arquitetura distribuída. É mais um um mapa inicial para quem deseja entender os trade-offs entre diferentes técnicas de reutilização em microsserviços.

Na minha postagem anterior, comentei sobre duplicação de código em microsserviços e que uma das possibilidades de resolvê-la seria a criação de uma biblioteca compartilhada.

Recentemente recebi o livro Arquitetura de software: as partes difíceis (https://amzn.to/4oPp4cD, link de associado caso queira comprar). A primeira coisa que fiz foi analisar o sumário para ver os tópicos abordados já que comprei pelo título do livro e pelas avaliações rs.

Um dos capítulos aborda exatamente as técnicas de reutilização de código entre microsserviços, descrevendo com diagramas, trade-offs e as situações que cada técnica é mais adequada.

Não sei vocês, mas eu amo de paixão quando consigo conectar diferentes informações e de fato começar a entender algo mais profundamente... e foi isso que aconteceu ao ler esse capítulo haha.

O livro traz 4 técnicas que os desenvolvedores utilizam:

Replicação de Código
Biblioteca Compartilhada
Serviço Compartilhado
Side-cars com malha de serviços

Vou falar brevemente sobre cada uma e deixo pros senhores e senhoras se aprofundarem por conta própria :)

Replicação de Código

Nome autoexplicativo, o desenvolvedor replica o mesmo trecho de código em todos os microsserviços. Essa solução é a menos recomendada (rs) pois a depender do tipo de código que você está replicando, terá um retrabalho enorme sempre que haver modificações... tendo que dar ctrl v em todos os projeto, trabalhar dessa forma aumenta muito as chances de cometer erro.

A melhor aplicação dessa técnica, é quando estamos tratando de códigos que mudam muito pouco ou que são específicos para cada projeto. Por exemplo, uma classe Útil que fez o tratamento de strings ou formatação de datas... Todos os projetos podem possuir uma classe "DataUtil" mas cada um teria apenas os métodos necessários.

Biblioteca Compartilhada

A biblioteca compartilhada é bem interessante. Você cria um projeto a parte que vai armazenar toda a lógica que será reutilizada pelos outros serviços. No caso citado na minha postagem anterior, temos um serviço que é responsável pelo tratamento de exceção. Como trabalhamos com java, sempre que a versão é alterada, é gerado um novo .jar e esse arquivo é copiado para os outros projetos.

Você instala ele como se fosse uma biblioteca interna e tem acesso ao código do projeto. Você tem acesso as classes em tempo de compilação, então consegue executar os testes e verificar se a nova versão causou ou não problemas no projeto.

Um ponto negativo seria justamente o controle de versão dessa biblioteca e a quantidade de projetos que a utilizam... Por exemplo, se ela for altamente acoplada, ou seja, uma modificação nela afeta muitos outros projetos... você precisa ter um plano de atualização de versão da biblioteca.

No livro, é feita uma discussão entre a criação de uma única biblioteca compartilhada que armazena toda lógica duplicada nos serviços vs criação de bibliotecas mais especializadas como, biblioteca de autorização, de logging, de tratamento de exceção...

Levando em consideração os seus conhecimentos... Qual das opções seria mais vantajosa no desenvolvimento de software? Tira um tempinho pra pensar a respeito dos pontos positivos, pontos negativos e impactos de cada uma dessas duas opções.

Bom, normalmente a melhor opção é evitar a criação de bibliotecas grandes em que as alterações afetem muitos serviços... dê preferência sempre a criação de bibliotecas menores e mais especializadas... dessa forma, o impacto das alterações dessas bibliotecas menores não vai atingir muitos serviços, diminuindo o tempo gasto em testes.

Serviço Compartilhado

Nessa técnica, temos a criação de um serviço que vai armazenar a lógica duplicada. Diferente da biblioteca compartilhada, que você tem acesso ao código em tempo de compilação, no serviço compartilhado você terá acesso em tempo de execução.

As alterações nesse serviço, afetam todos os outros que o utilizam. Então caso ele fique fora do ar, todos os outros ficarão sem acesso ao mesmo.

Outro ponto é que os serviços que utilizam esse serviço compartilhado precisam realizar requisições para ele, essas requisições levam um tempo por conta da latência de rede e segurança.

E aqui vem um ponto interessante, há um tempo atrás eu estava estudando a respeito de Remote Procedure Call (RPC), que é uma forma de comunicação entre serviços. Eu havia entendido o que era RPC mas não tinha em mente uma situação interessante para utilizá-lo. Uma das características do RPC é que as chamadas tendem a ser mais rápidas que as chamadas para API's REST... então nessa situação do serviço compartilhado, a utilização de RPC seria mais vantajosa.

E além disso, essa técnica é recomendada também quando temos um projeto de microsserviços que utilizam linguagens diversas... porque, caso a gente prefira utilizar a técnica de biblioteca compartilhada, teríamos que criar a biblioteca em diferentes linguagens, o que já não acontece com o serviço compartilhado... que para acessá-lo, basta realizar chamadas/requisições.

Side Cars com Malha de Serviço

Por fim, temos os Side Cars e as Malhas de Serviços. Essas técnicas são bem mais complexas do que as anteriores e eu não pretendo explicá-las sem a devida profundidade que merece rs.

Então, fica como recomendação de tópico para aprofundamento para caso você se interesse.

Alguns links de vídeos que resumem bem essas técnicas:

Julguei esse conteúdo interessante de ser compartilhado e talvez eu aborde de forma mais aprofundada no futuro algumas dessas soluções :P