Classificação de Antipadrões em Microsserviços ‐ Parte 03

YAN JUSTINO
MSc. Software Engineering · PhD. Student
AWS · MCSD · OCA · ORCID · Tech Lead at ITAÚ Unibanco

1. CONTEXTO

Olá, Dev! Neste post listaremos um catálogo de antipadrões associados a implementação de Microsserviços. Esse catálogo contém uma breve descrição de cada antipadrão, os problemas que eles podem causar e as possíveis soluções que podem ser aplicadas para sanar possíveis problemas de design.

Na parte 01, listamos 5 antipadrões do catálogo de antipadrões de microsserviços. Os antipadrões apresentados foram Wrong Cuts (WC); Cyclic Dependencies (CD); Mega Service (MS); Nano Service (NS); e Shared Librararies (SL).

Já na parte 02 aparesentamos quatro antipadrões: Multiple Service Instances Per Host (MSIPH); Shared Persistence (SP); No API Versioning (NAV); No API Gateway (NAG).

2. ANTIPADRÕES

Nesta terceira e última parte vamos abordar alguns Antipatterns relacionados a monitoria de microsserviços. Eles são: No Health Check (NHC); Local Logging (LL); e Insufficient Monitoring (IM).

PROBLEMAS

• A ausência de verificações de status regulares através de requisições HTTP, ou a falta de um gateway de API ou sistema de descoberta de serviços, podem sugerir esse antipadrão.
• Consumidores do microsserviço podem enfrentar atrasos ou falhas ao receber respostas se o microsserviço estiver fora do ar.

SOLUÇÃO

• Incorporar endpoints de verificação de estado nos microsserviços que verifiquem periodicamente sua disponibilidade e capacidade de resposta: Introduzindo endpoints de verificação de estado, microsserviços desativados não processarão requisições, e os consumidores serão informados sobre a indisponibilidade antes de fazerem suas solicitações. Isso evita atrasos e tempos de espera desnecessários.

LEITURAS RECOMENDADAS

• Pattern: Health Check API

PROBLEMAS

• Logs locais podem ser muito difíceis de agregar e analisar. Isso desacelera o processo de monitoramento proporcionalmente ao número de microsserviços e ao tamanho do log.

SOLUÇÃO

• Implementar um sistema de registro distribuído que seja responsável por agregar os logs de todos os microsserviços: Utilizar um mecanismo de registro distribuído permite ter um repositório único de logs, força os microsserviços a usar o mesmo formato de log e simplifica os processos de monitoramento e análise.

LEITURAS RECOMENDADAS

• Pattern: Log aggregation

PROBLEMAS

• Um monitoramento insuficiente pode prejudicar as atividades de manutenção em um sistema baseado em microsserviços. Falhas tornam-se mais difíceis de detectar e rastrear problemas de desempenho torna-se mais tedioso. Isso pode até afetar a capacidade de cumprir com o SLA.

SOLUÇÃO

• Utilizar uma ferramenta de monitoramento que colete dados de desempenho e estatísticas de falhas de cada microsserviço no sistema: Monitorar todos os aspectos de um sistema baseado em microsserviços fornece uma compreensão completa do comportamento da aplicação. Ele também fornece dados que podem ser usados para melhorar o desempenho e a qualidade de toda a aplicação.

LEITURAS RECOMENDADAS

• observability

3. CONCLUSÃO

Nesse post listamos alguns antipadrões associados a microsserviços. Cada antipadrões de microsserviços aponta para desafios comuns que podem comprometer a eficiência, escalabilidade e manutenibilidade de arquiteturas baseadas em microsserviços.

Desde problemas de design, como dependências cíclicas e serviços excessivamente grandes ou pequenos, até questões operacionais como configuração manual, falta de integração e entrega contínuas, e monitoramento insuficiente, cada antipadrão destaca uma área crítica onde as práticas inadequadas podem levar a falhas sistêmicas e degradar a qualidade do serviço.

Reconhecer e refatorar esses antipadrões é essencial para maximizar os benefícios de uma arquitetura de microsserviços, garantindo que eles permaneçam robustos, ágeis e capazes de atender às demandas dinâmicas dos ambientes de TI modernos.

ATENÇÃO!!!

Os artigos referenciados possuem outros antipadrões não abordados nesse post. Recomendo fortemente sua leitura.

REFERÊNCIAS

1. MENDONCA, N. C. et al. The monolith strikes back: Why istio migrated from
   microservices to a monolithic architecture. IEEE Software, Institute of Electrical and
   Electronics Engineers (IEEE), v. 38, n. 5, p. 17–22, set. 2021. ISSN 1937-4194.

2. BOGNER, J. et al. Industry practices and challenges for the evolvability assurance of
   microservices: An interview study and systematic grey literature review. Empirical
   Software Engineering, Springer Science and Business Media LLC, v. 26, n. 5, jul. 2021.

3. FORD, N. Software architecture: The hard parts : modern trade-off analyses for
   distributed architectures. First edition. Cambridge, Massachusetts: The MIT Press, 2021.
   Made available through: Safari, an O’Reilly Media Company. ISBN 1492086843.

4. NEWMAN, S. Building microservices: Designing fine-grained systems. Second edition.
   Beijing: O’Reilly, 2021. ISBN 9781492033998.

5. Tighilt, R., Abdellatif, M., Trabelsi, I., Madern, L., Moha,
   N., and Guéhéneuc, Y.-G. (2023). On the maintenance
   support for microservice-based systems through the
   specification and the detection of microservice antipatterns.
   Journal of Systems and Software, 204:111755. DOI:
   https://doi.org/10.1016/j.jss.2023.111755.

6. Taibi, D. and Lenarduzzi, V. (2018). On the definition of microservice
   bad smells. IEEE Software, 35(3):56–62. DOI:
   10.1109/MS.2018.2141031.

Caro leitor,

Espero que tenham encontrado insights valiosos na discussão sobre a co-localização de arquivos de teste e código de produção, uma prática que pode transformar significativamente o desenvolvimento de software.

Se você já experimentou essa metodologia em seus projetos, como foi? Quais vantagens e obstáculos você encontrou? Se ainda não tentou, consideraria implementá-la após essa leitura?