Dando sequência à nossa série sobre estratégias para recuperar coesão em microserviços, falaremos agora do Serviço Compartilhado. Nesta abordagem, em vez de duplicar ou distribuir uma lógica comum em cada microserviço (replicação de código ou bibliotecas compartilhadas), opta-se por criar um microserviço que oferece funcionalidades para todos os outros. Assim, cada serviço consumidor faz chamadas remotas (APIs) ao serviço central, evitando a repetição de código e mantendo o controle de versões no próprio serviço.
1. Conceito de Serviço Compartilhado
Um Serviço Compartilhado é um microserviço especializado em uma determinada funcionalidade ou conjunto de lógicas, ao qual todos os demais serviços recorrem via rede (REST, gRPC, etc.). É como se fosse uma “autoridade central” sobre certo assunto, porém ainda isolado em um serviço independente (diferente de um monólito).
Por que “Compartilhado”?
- Ele fornece APIs que representam uma fonte única de verdade (Single Source of Truth) para certos dados ou processos (login, billing, relatórios, etc.).
- Em vez de cada microserviço ter de implementar a mesma lógica, eles chamam o serviço compartilhado.
2. Exemplo de Diagrama
Abaixo, um diagrama simples que ilustra a presença de um Serviço Compartilhado (ex.: “Serviço de Pagamentos”) sendo consumido por vários microserviços:
+------------------------+
| Serviço Compartilhado |
| (Ex.: Pagamentos) |
+----------+------------+
^
|
+------------+----------+
| Microserv. A |
+----------------------+
^
| Requisições API
+------------+----------+
| Microserv. B |
+----------------------+
^
| Requisições API
+------------+----------+
| Microserv. C |
+----------------------+
- O Serviço Compartilhado implementa as lógicas específicas (ex.: processar faturas).
- Cada microserviço cliente faz chamadas de rede (REST, gRPC, etc.) quando precisa da funcionalidade.
- Assim, não há duplicação de implementação, e eventuais correções/evoluções ficam centralizadas no serviço compartilhado.
3. Trade-Offs (Vantagens e Desvantagens)
3.1 Vantagens
| Vantagem | Descrição |
|---|---|
| Centralização de Lógica | Todas as atualizações e correções ocorrem em um só lugar, não há replicação de código. |
| Coerência e Fonte Única de Verdade | Ideal para áreas como “autenticação”, “pagamentos”, “cálculo de impostos” ou algo que exige uniformidade. |
| Facilidade de Evolução Interna | O time responsável por esse serviço pode lançar novas versões/rotas sem afetar o deploy dos clientes (desde que mantenha compatibilidade). |
| Menos Overhead de Libs | Não precisa publicar bibliotecas ou versionar pacotes; basta expor uma API estável. |
3.2 Desvantagens
| Desvantagem | Descrição |
|---|---|
| Dependência em Rede | Cada chamada exige rede (latência, possíveis falhas de comunicação). |
| Possível Ponto de Falha | Se o serviço cair ou ficar lento, todos que dependem dele podem ser impactados. |
| Risco de Virar “God Service” | Se abraçar muitas funcionalidades, pode se tornar gigantesco e reintroduzir acoplamento e gargalo. |
| Versão Única para Todos | Se uma mudança for incompatível, é preciso planejar versionamento da API ou conviver com múltiplas versões. |
4. Onde se Aplica
- Funcionalidade Realmente Central e Estável
- Ex.: Processamento de login/segurança, envio de e-mails, notificação, gateways de pagamento.
- Se é algo que muda relativamente pouco e precisa ser unificado para garantir consistência.
- Cálculos Complexos que Devem ser Idênticos
- Regras de negócio (ex.: cálculo de frete e imposto) que não podem divergir entre microserviços, sob risco de confundir usuários.
- Alta Criticidade
- Se a lógica é crítica e as equipes preferem uma implementação oficial para evitar qualquer divergência.
Evitar
- Funcionalidades que variam muito por serviço e precisam evolução rápida/independente.
- Se a latência de chamadas remotas prejudica a performance de cada microserviço, e não há caching adequado.
- Quando um fluxo de alto volume possa sobrecarregar o serviço central, criando gargalos ou fila de requisições.
5. Analogia Fora da Programação
Podemos comparar um Serviço Compartilhado a:
- Um Departamento Especializado em uma empresa.
- Ex.: O “Departamento Financeiro” é responsável por toda contabilidade e relatórios. Todos os setores que precisam de dados de finanças requisitam a esse departamento.
- Prós: A contabilidade mantém regras unificadas e confiáveis.
- Contras: Se o departamento demora ou sai do ar (pede greve?), toda a empresa fica travada em assuntos financeiros.
6. Dicas de Implementação
- API Claramente Definida
- Use REST, gRPC, GraphQL ou outro protocolo bem padronizado, com contratos de versionamento.
- Escalabilidade e Observabilidade
- Se muitos serviços dependem, deve-se cuidar do dimensionamento (auto-scaling?), logs centralizados, métricas e alertas.
- Circuit Breakers e Timeouts
- Em microserviços, dependa de estratégias de resiliência (Hystrix pattern ou configurações no seu orquestrador). Se o serviço ficar lento ou indisponível, não bloquear todo o sistema.
- Evitar Inchar Demais
- Manter o serviço focado em um domínio claro, para não se tornar um “mono-serviço gigante”.
Conclusão
O Serviço Compartilhado pode ser uma estratégia valiosa para evitar replicação de lógicas críticas e manter uma única implementação confiável, acessível via rede a todos os microserviços que dela precisem. Ao mesmo tempo, é preciso cuidar para não criar um ponto único de falha e gargalo, nem concentrar funções demais que acabem reconstruindo um “monólito”.
Nos próximos artigos, trataremos da última estratégia mencionada em nossa visão geral: Sidecars e Malhas de Serviços (Service Mesh), que atuam nos aspectos transversais (monitoramento, segurança, roteamento), oferecendo coesão sem duplicar código ou criar serviços “centrais” de negócio. Fique atento para fechar a nossa série!
Notas Bibliográficas
- Arquitetura de Software: As Partes Difíceis. Editora Alta Books.