YAN JUSTINO
MSc. Software Engineering · PhD. Student
AWS · MCSD · OCA · ORCID · Tech Lead at ITAÚ Unibanco
1. CONTEXTO
Olá, Dev! Neste post estamos listando 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 primeira parte, listamos 5 antipadrões do catálogo de antipadrões de microsserviços apresentado pelos pesquisadores Taibi, D. and Lenarduzzi, V. (2018)[6] e Tighilt at al (2023)[5]. Os antipadrões apresentados foram Wrong Cuts (WC); Cyclic Dependencies (CD); Mega Service (MS); Nano Service (NS); e Shared Librararies (SL).
2. ANTIPADRÕES
Nesta parte 02 apresentaremos os antipadrões Multiple Service Instances Per Host (MSIPH); Shared Persistence (SP); No API Versioning (NAV); No API Gateway (NAG).
✍️ Multiple Service Instances Per Host (MSIPH)
Acontece quando vários microsserviços são implantados em um único host, que pode ser um container, uma máquina física ou uma máquina virtual. Isso pode parecer conveniente ou eficiente em termos de utilização de recursos, mas traz consigo uma série de desvantagens significativas que podem afetar negativamente a arquitetura e a operação de um sistema baseado em microsserviços.
PROBLEMAS
Impacto na autonomia: com o antipadrão MSIPH, a autonomia é comprometida, pois a falha de um serviço no host pode impactar outros serviços compartilhando o mesmo ambiente.
Impacto na Escala: no contexto do MSIPH, a escalabilidade é afetada, pois escalar um serviço pode exigir mais recursos do host, potencialmente afetando o desempenho de outros serviços que compartilham o mesmo ambiente
Possíveis conflitos dentro do host: Com múltiplos serviços compartilhando o mesmo host, há um risco aumentado de conflitos de recursos, como uso de CPU, memória e I/O. .
SOLUÇÃO
Para evitar os problemas associados ao MSIPH, é recomendável adotar estratégias como:
Containerização: Utilizar containers para encapsular cada serviço individualmente, garantindo que eles operem em ambientes isolados mesmo quando implantados na mesma máquina física ou virtual.
Orquestração de Containers: Usar sistemas de orquestração, como Kubernetes, que gerenciam a implantação, escalonamento e operação de containers de forma eficiente, garantindo que os serviços não interfiram uns com os outros.
Escalonamento Dinâmico: Implementar políticas de escalonamento automático que permitam que cada serviço escale baseado em suas próprias demandas de recursos, sem afetar outros serviços.
Monitoramento e Gerenciamento de Recursos: Adotar ferramentas avançadas de monitoramento e gerenciamento de recursos para detectar e mitigar problemas de contenção de recursos rapidamente.
LEITURAS RECOMENDADAS
Multiple service instances per host
Microservices Deployment Patterns
✍️ Shared Persistence (SP)
Acontece quando vários microsserviços acessam o mesmo banco de dados relacional. No pior dos cenár.ios, diferentes serviços acessam a mesma entidade do mesmo banco de dados. Um Microsserviço deve ser dono apenas dos dados que ele precisa.
PROBLEMAS
Acoplamento via banco de dados
Diminuição da autonomia da equipe e do serviço
SOLUÇÃO
Isso antipadrão pode levar a uma série de problemas, principalmente relacionados ao acoplamento e à perda de autonomia, como mecionado. Aqui estão algumas das principais soluções para superar este antipadrão:
Bancos de Dados Independentes: A solução mais alinhada com os princípios de microsserviços é que cada serviço tenha seu próprio banco de dados, garantindo assim a total autonomia dos dados. Isso reduz o acoplamento e permite que cada equipe seja responsável por sua parte da infraestrutura de dados, facilitando escalabilidade e manutenção.
Banco Compartilhado com Tabelas Privadas:
Uma alternativa menos isolada, mas ainda viável, é utilizar um banco de dados compartilhado onde cada serviço tem seu próprio conjunto de tabelas. Essas tabelas não são acessíveis por outros serviços, o que ajuda a manter certo grau de isolamento e controle sobre os dados.
Uso de Esquemas de Banco de Dados:
Outra abordagem é o uso de esquemas dentro de um banco de dados compartilhado, onde cada esquema é dedicado a um microsserviço específico. Isso ajuda a manter o isolamento lógico dentro de um mesmo banco de dados físico, facilitando a gestão de permissões e visibilidade de dados.
Integradores de granularidade:
Para casos em que a granularidade vá contra a integridade de dados em um processo que deveria ser transacionalmente simples, a equipe pode deliberar sobre a doção de estratégias integradoras de granularidade.
LEITURAS RECOMENDADAS
Shared-database-per-service pattern
Shared database
✍️ No API Gateway (NAG)
Ocorre quando uma arquitetura de microsserviços é implementada sem um API Gateway, levando a que os clientes tenham que interagir diretamente com os microsserviços individuais. Esse antipadrão pode trazer vários problemas e desafios, especialmente em ambientes de produção com várias interfaces de serviço.
PROBLEMAS
Complexidade para os Clientes: Sem um API Gateway, os clientes precisam conhecer e gerenciar os pontos de acesso de todos os microsserviços que precisam consumir, aumentando a complexidade do lado do cliente.
Dificuldades de Autenticação e Autorização: Cada serviço pode precisar implementar seu próprio mecanismo de autenticação e autorização, o que pode levar a inconsistências e brechas de segurança.
Gestão de Carga e Falhas: Em uma configuração NAG, a lógica para balanceamento de carga e tratamento de falhas pode precisar ser implementada em cada serviço ou no lado do cliente, o que pode complicar o desenvolvimento e a manutenção.
Versionamento de APIs: Gerenciar diferentes versões de API diretamente nos serviços pode tornar-se problemático, especialmente em um ambiente com muitos serviços que evoluem rapidamente.
SOLUÇÃO
Implementar um API Gateway é uma prática comum em arquiteturas de microsserviços modernas devido às suas vantagens em simplificar a gestão de APIs, segurança, e resiliência. Ferramentas populares para este propósito incluem Kong, Apigee e AWS API Gateway, cada uma oferecendo conjuntos robustos de funcionalidades para lidar com as necessidades complexas de microsserviços em ambientes de produção.
Implementação de um API Gateway: A solução mais direta para o antipadrão NAG é introduzir um API Gateway na arquitetura. O API Gateway atua como um ponto de entrada único para todas as chamadas de API, simplificando a interação do cliente com os microsserviços.
Centralização de Autenticação e Autorização: Com um API Gateway, é possível centralizar processos de autenticação e autorização, proporcionando um mecanismo consistente e seguro para controlar o acesso aos serviços.
Balanceamento de Carga e Resiliência: O API Gateway pode gerenciar o balanceamento de carga e implementar padrões de resiliência, como circuit breakers e retries, para lidar com falhas nos serviços de forma transparente.
Gestão de Tráfego e Versionamento: O Gateway permite a gestão eficiente do tráfego e facilita a implementação de estratégias de versionamento de API, permitindo que diferentes versões de serviços sejam acessadas sem impactar os clientes existentes.
LEITURAS RECOMENDADAS
Overcoming the Common Microservices Anti-Patterns
Using an API Gateway in Your Microservices Architecture
✍️ No API Versioning (NAV)
Refere-se a uma falha de design no desenvolvimento de software onde uma interface de programação de aplicações (API) não é projetada para suportar múltiplas versões simultaneamente. Isso pode criar problemas significativos ao longo do tempo à medida que as APIs evoluem.
PROBLEMAS
Mudanças Que Quebram a Compatibilidade: Sem versionamento, qualquer atualização ou modificação pode potencialmente quebrar as aplicações existentes que dependem da API, levando a malfuncionamentos de software e interrupções no serviço.
Dificuldade na Manutenção: A falta de versionamento torna desafiador manter a compatibilidade com versões anteriores, forçando os clientes a se adaptarem rapidamente às mudanças ou enfrentarem problemas de incompatibilidade.
Barreiras à Adoção: Novos usuários podem hesitar em adotar a API se perceberem que ela muda frequentemente sem um gerenciamento claro de versões, pois isso pode implicar em custos de manutenção mais altos.
SOLUÇÃO
Abordar o antipadrão NAV é crucial para garantir que as APIs permaneçam robustas, confiáveis e fáceis de usar, melhorando assim a sustentabilidade geral dos sistemas de software. Os itens a seguir podem auxiliar a lidar com os problemas listados anteriormente.
Implementar Estratégia de Versionamento: Introduza uma estratégia sistemática de versionamento, como o Versionamento Semântico (SemVer), onde as versões são incrementadas com base na natureza das alterações (maior, menor, correção) para comunicar claramente o impacto das atualizações.
Política de Depreciação de Versões: Estabeleça uma política clara de depreciação para versões antigas, fornecendo aos usuários bastante aviso e orientação sobre a transição para versões mais novas.
Suportar Múltiplas Versões: Mantenha suporte para múltiplas versões de API simultaneamente para permitir que os usuários façam a transição em seu próprio ritmo sem interromper seus sistemas atuais.
LEITURAS RECOMENDADAS
A Mixed-Method Approach to Recommend Corrections and Correct REST Antipatterns
REFERÊNCIAS
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.
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.
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.
NEWMAN, S. Building microservices: Designing fine-grained systems. Second edition.
Beijing: O’Reilly, 2021. ISBN 9781492033998.
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.
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.
Caros leitores,
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?
