Classificação de Antipadrões em Microsserviços ‐ Parte 03
Tags: softwareengineering, architecture, microservices, braziliandevs
Published: 2024-05-09 00:47:35

**YAN JUSTINO**
[MSc. Software Engineering](https://repositorio.ufrn.br/handle/123456789/26370) · [PhD. Student](https://www.cesar.school/doutorado-profissional-em-engenharia-de-software/)
[AWS](https://www.youracclaim.com/users/yan-justino/badges) · [MCSD](https://www.youracclaim.com/users/yan-justino/badges) · [OCA](https://www.youracclaim.com/users/yan-justino/badges) · [ORCID](https://orcid.org/0000-0001-7248-716X)  · [Tech Lead at ITAÚ Unibanco]()

![Static Badge](https://img.shields.io/badge/post-design-50A6C5?style=for-the-badge)

---

## 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](https://dev.to/yanjustino/classificacao-de-antipadroes-em-microsservicos-parte-01-27c9), 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](https://dev.to/yanjustino/classificacao-de-antipadroes-em-microsservicos-parte-02-4e92) 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).

---

<div>
<center>
<H3>✍️ No Health Check (NHC)</H3>
<br/>
<small>
Microsserviços são por natureza instáveis, podendo ser implementados em variados locais e ficarem indisponíveis temporariamente ou sob certas condições. Esse antipadrão ocorre quando não existe um endpoint disponível para avaliar o estado operacional do microsserviço. 
</small>
<br/>
<br/>
</center>
</div> 

#### 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](https://microservices.io/patterns/observability/health-check-api.html)

---

<div>
<center>
<H3>✍️Local Logging (LL)</H3>
<br/>
<small>
Cada microsserviço gera uma grande quantidade de informações que são registradas em sistemas de arquivos diferentes. Essas informações são extremamente úteis para monitoramento e devem ser acessíveis e armazenadas de maneira eficiente. Esse Antipadrão ocorre quando cada microsserviço registra suas informações em um armazenamento local. Indícios desse antipadrão incluem a presença de arquivos de log dentro dos microsserviços, arquivos sendo escritos pelo microsserviço, uso de bancos de dados conscientes de tempo e ferramentas e frameworks de registro.
</small>
<br/>
<br/>
</center>
</div> 

#### 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](https://microservices.io/patterns/observability/application-logging.html)

---

<div>
<center>
<H3>✍️ Insufficient Monitoring (IM)</H3>
<br/>
<small>
Dado que os microsserviços fornecidos são frequentemente sujeitos a acordos de nível de serviço (SLA), monitorar seu comportamento e desempenho é crucial. Esse Antipadrão ocorre quando o desempenho e as falhas dos microsserviços não são rastreados. Algumas indicações desse antipadrão incluem o uso de registros locais para alguns microsserviços ou a ausência de endpoints de verificação de saúde.
</small>
<br/>
<br/>
</center>
</div>

#### 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](hhttps://microservices.io/tags/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?