Ao adotar uma arquitetura de microserviços, um dos grandes dilemas que os desenvolvedores enfrentam é como compartilhar funcionalidades comuns entre os serviços. A decisão se resume muitas vezes a duas alternativas principais: criar uma biblioteca compartilhada ou desenvolver um serviço compartilhado. Ambas as opções têm vantagens e desvantagens que precisam ser bem analisadas de acordo com o contexto da aplicação. Neste post, vamos abordar as duas estratégias mostrando os prós e contras de cada alternativa.

1. Biblioteca Compartilhada

Uma biblioteca compartilhada é um conjunto de funcionalidades ou componentes que podem ser reutilizados por vários microserviços. As bibliotecas são compiladas e integradas diretamente no código dos serviços que as utilizam.

Exemplos comuns de uso:

• Funções utilitárias, como validação de entrada ou manipulação de data e hora;
• Modelos de domínio compartilhados (como contratos de dados usados por diversos serviços);
• Ferramentas de autenticação/segurança, como integrações com provedores OAuth.

Pontos Positivos da Biblioteca Compartilhada:

1. Desempenho: Como o código da biblioteca é incorporado diretamente no serviço, não há latência de rede para chamadas, resultando em uma execução mais rápida.
2. Facilidade de desenvolvimento: Os desenvolvedores podem iterar rapidamente, já que não há necessidade de gerenciar outra camada de comunicação de serviço.
3. Simplicidade: A estrutura do projeto é mais simples, já que não é preciso lidar com chamadas de API ou dependências externas de forma explícita.

Pontos Negativos da Biblioteca Compartilhada:

1. Deploy complexo: Quando a biblioteca precisa de atualizações, todos os serviços que dependem dela devem ser implantados novamente, o que pode ser trabalhoso em arquiteturas complexas.
2. Problemas de versionamento: Garantir que todas as instâncias de microserviços estejam usando a versão correta da biblioteca pode se tornar um desafio.
3. Risco de acoplamento: Se a biblioteca é atualizada com frequência ou se contém código que é altamente específico de um contexto, ela pode introduzir acoplamento indesejado entre serviços.

2. Serviço Compartilhado

Um serviço compartilhado é um microserviço separado que encapsula uma funcionalidade comum e é acessado por outros serviços via uma API, geralmente por HTTP ou gRPC.

Exemplos comuns de uso:

• Serviço de autenticação centralizado (ex.: gerenciando tokens e sessões).
• Serviço de notificações que envia e-mails, mensagens SMS ou alertas push.
• Processamento de dados centralizado, como serviços de relatórios ou análise.

Pontos Positivos do Serviço Compartilhado:

1. Isolamento e independência: O serviço pode ser atualizado ou escalado de forma independente, sem precisar modificar ou reimplantar outros serviços.
2. Gestão simplificada de versionamento: É mais fácil controlar e evoluir versões da API do serviço em comparação com uma biblioteca que requer atualização em todos os consumidores.
3. Escalabilidade: O serviço pode ser escalado horizontalmente conforme necessário para atender à carga de trabalho.

Pontos Negativos do Serviço Compartilhado:

1. Latência: Cada chamada ao serviço compartilhado adiciona latência de rede, o que pode impactar o desempenho de sistemas sensíveis a tempo de resposta.
2. Resiliência: A falha no serviço compartilhado pode afetar a estabilidade de todos os consumidores, tornando a arquitetura mais vulnerável a pontos únicos de falha.
3. Complexidade de integração: Adicionar um serviço compartilhado pode aumentar a complexidade geral da arquitetura, pois os serviços consumidores precisam lidar com falhas de rede, tempos de espera e outros desafios associados à comunicação entre microserviços.

Quando Usar Cada Abordagem

1. Use uma biblioteca compartilhada quando:

• A funcionalidade é pequena, estável e não precisa de muitas atualizações.
• O desempenho é crítico, e chamadas de rede devem ser minimizadas.
• Você deseja manter uma arquitetura simples sem a necessidade de gerenciar APIs adicionais.

Exemplo prático: Um conjunto de funções de validação de entrada ou lógica de formatação de dados pode ser facilmente incluído como uma biblioteca. Essas funcionalidades são geralmente simples e não requerem atualizações frequentes, tornando a biblioteca uma solução eficiente.

2. Use um serviço compartilhado quando:

• A funcionalidade precisa ser atualizada e melhorada regularmente.
• O isolamento de componentes é importante para a manutenção e escalabilidade da solução.
• Você deseja centralizar lógica crítica, como segurança ou análise de dados, que precisa ser consistente em toda a arquitetura.

Exemplo prático: Um serviço de autenticação centralizado, como o responsável por emitir e validar tokens de acesso, é melhor implementado como um serviço compartilhado. Isso facilita a gestão de segurança e o controle de sessões em um único lugar, enquanto outros serviços apenas consomem a API.

Dicas para Decidir

1. Considere o futuro: Pense em como a funcionalidade evoluirá ao longo do tempo. Se ela for complexa e com alta possibilidade de mudança, um serviço compartilhado é provavelmente a melhor escolha.
2. Avalie a frequência de uso: Se muitos serviços precisam acessar frequentemente uma funcionalidade e a latência é uma preocupação, uma biblioteca pode ser mais adequada.
3. Mantenha a simplicidade: Se possível, comece com uma biblioteca e evolua para um serviço conforme a necessidade. Isso evita over engineering em estágios iniciais.

Conclusão

Não existe uma solução única que funcione para todos os casos. A escolha entre uma biblioteca compartilhada e um serviço compartilhado depende do contexto e das necessidades específicas do sistema. Avalie cuidadosamente os prós e contras de cada abordagem para garantir uma arquitetura escalável, eficiente e fácil de manter.