Dando continuidade à série de artigos sobre estratégias para reunir coesão em um ecossistema de microserviços, desta vez focamos na Biblioteca Compartilhada. A ideia é agrupar lógicas comuns em uma “lib” (por exemplo, um pacote npm, jar, gem), para que cada microserviço possa adicioná-la como dependência. Isso difere da Replicação de Código, abordada no artigo anterior, pois aqui existe uma fonte única de verdade, versionada e distribuída.
1. Conceito de Biblioteca Compartilhada
Uma biblioteca compartilhada é um artefato (pacote, jar, etc.) que contém funcionalidades ou utilitários reutilizados por múltiplos microserviços. Cada serviço “consome” essa lib através do seu gerenciador de dependências (Maven, Gradle, npm, pip, etc.), mantendo (em tese) a mesma implementação para todos.
Objetivo: Evitar duplicação de código e inconsistências, centralizando a manutenção de partes comuns, mas sem criar um serviço remoto único (que seria um “Serviço Compartilhado”).
2. Diagrama Simplificado
Abaixo, um diagrama básico mostrando como uma biblioteca compartilhada interage com vários microserviços:
+---------------------------+
| Biblioteca Compartilhada |
| (repo central, versioned)|
+---------------------------+
^ ^
| | Dependências
+-----------+-----+ +--+------------+---+
| Microservice A | | Microservice B |
| (build) | | (build) |
+-----------------+ +-----------------+
^ ^
| | ...
+-----------+-----+ +--+------------+---+
| Microservice C | | Microservice D |
| (build) | | (build) |
+-----------------+ +-----------------+
- A Biblioteca Compartilhada é hospedada em algum repositório (ex.: Artifactory, Nexus, npm registry, PyPI, etc.).
- Cada microserviço declara a dependência de determinada versão dessa biblioteca em seu arquivo de configuração (pom.xml, package.json, etc.).
- Durante o build, o serviço baixa a biblioteca e a inclui para uso.
- Quando a biblioteca é atualizada, cada serviço precisa atualizar sua dependência para receber as mudanças.
3. Trade-Offs (Vantagens e Desvantagens)
3.1 Vantagens
| Vantagem | Descrição |
|---|---|
| Fonte Única de Verdade | Correções e evoluções são feitas em um só lugar, reduzindo divergências de implementação. |
| Menos Duplicação | Diferente da replicação de código, não é preciso copiar e colar; basta atualizar a versão no gerenciador. |
| Controle de Versão | É possível gerenciar releases (1.0, 1.1, etc.), permitindo a cada microserviço decidir quando migrar. |
| Manutenção Mais Fácil | Bugs fixados na lib beneficiam todos os serviços que atualizem a dependência. |
| Menos Rede | Como não é um serviço remoto, não adiciona latência de chamadas de rede para obter a lógica comum. |
3.2 Desvantagens
| Desvantagem | Descrição |
|---|---|
| Atualização Manual | Cada microserviço deve conscientemente atualizar a versão da biblioteca. Se algum esquecer, fica defasado. |
| Possível Acoplamento | Se a biblioteca for muito grande, qualquer mudança (mesmo pequena) pode impactar vários serviços que a usam. |
| Lógica Conflituosa | Caso a equipe adicione muitas funcionalidades diferentes na lib, ela pode se tornar um “monólito de código”. |
| Pipeline de Lib | Requer publicar a lib em um repositório, configurar pipeline de CI/CD para mantê-la, etc. |
| Versão Múltipla | Pode haver casos onde vários serviços usam versões distintas simultaneamente, complicando a gestão. |
4. Onde se Aplica
- Lógica de Negócio Comum
- Regras e validações que diversas equipes/microserviços precisam, mas não justificam um serviço remoto.
- Utilitários e Helpers
- Funções de conversão de datas, formatação de strings, criptografia leve, logs padronizados, etc.
- Protocolos Internos
- Definições de objetos de domínio, modelos de evento, serialização (ex.: Avro schemas, Protobuf) que vários serviços compartilham para trocar mensagens coerentes.
- Equipes que Aceitam Aderência
- Cada time concorda em usar a mesma lib e atualizá-la quando necessário.
5. Onde Evitar
- Código Muito Volátil
- Se a lógica comum está sempre mudando, obrigará frequentes atualizações nos microserviços, causando overhead.
- Funcionalidades Pesadas
- Se a biblioteca se tornar enorme (ou contiver dependências pesadas), pode causar inchaço nos pacotes dos serviços.
- Necessidade de Evolução Independente
- Se cada serviço deseja alterar a lógica de forma distinta, uma biblioteca compartilhada pode gerar conflitos ou divergência de versões.
- Funcionalidades altamente “stateful”
- Se a biblioteca for responsável por manipular estado crítico que precisaria ser unificado em um só local, talvez seja melhor um Serviço Compartilhado.
6. Analogia Fora da Programação
Podemos analogar a biblioteca compartilhada a um “livro de receitas oficial” que os chefs recebem em versão publicada:
- Vantagem: Todos consultam a mesma edição; se há correções/novas receitas, cria-se uma edição 2.0 e distribui-se aos chefs.
- Desvantagem: Cada chef tem liberdade de ficar em versões antigas. Se há um bug na receita de “bolo de chocolate” consertado na edição 2.0, mas algum chef ainda usa a 1.0, mantém o bug.
- Conclusão: Menos risco de divergência do que cada um ter sua própria cópia pessoal (replicação), mas ainda há a necessidade de distribuir e atualizar a versão do livro.
Conclusão
A biblioteca compartilhada é uma abordagem bem equilibrada para centralizar a manutenção de lógicas comuns, evitando a duplicação e inconsistências típicas da replicação de código puro. Ao mesmo tempo, mantém a autonomia relativa de cada microserviço, pois estes só precisam incluir a dependência na build — não há um serviço remoto adicional a ser gerenciado.
Porém, requer boa prática de versionamento (semver), um repositório de artefatos confiável (Nexus, Artifactory, npm registry, etc.), e disciplina por parte de cada equipe para atualizar a biblioteca quando necessário.
Nos próximos artigos, veremos estratégia importante para ganhar coesão em microserviços:
- Serviço Compartilhado
Notas Bibliográficas
- Arquitetura de Software: As Partes Difíceis. Editora Alta Books.