Quando os microsserviços são usados em excesso, a complexidade e os custos disparam. Veja como consolidamos 25 serviços em 5 – simplificando a arquitetura e reduzindo os gastos em nuvem sem sacrificar a estabilidade.
É difícil prever exatamente como a arquitetura do microsserviço evoluirá, quais prós e contras surgirão e que impacto a longo prazo ela terá. Os microsserviços podem oferecer benefícios significativos – como escalabilidade, implantações independentes e aprimoramento do isolamento de falhas – mas também introduzem desafios ocultos, como aumento da complexidade, sobrecarga de comunicação e custos de manutenção.
Embora essa abordagem arquitetônica traga flexibilidade no gerenciamento de sistemas, priorizando componentes críticos e simplificando os processos de liberação e teste, ela não consertará magicamente tudo – a arquitetura ainda precisa fazer sentido. A aplicação da arquitetura errada pode criar mais problemas do que resolve. Os microsserviços mal projetados podem levar a ineficiências, acoplamento apertado em lugares inesperados e sobrecarga operacional que supera suas vantagens.
Ponto de entrada: Recuperando a simplicidade arquitetônica
O projeto que assumimos foi um exemplo de arquitetura de microsserviços aplicada sem adaptá -lo à forma e necessidades reais do sistema. Aplicações relativamente pequenas e simples foram exageradas. Não foram apenas diferentes módulos e domínios divididos em serviços separados, mas mesmo camadas individuais – como API REST, serviços contendo lógica de negócios e repositórios de banco de dados – foram extraídos em microsserviços separados. Este é um caso clássico de resolver um problema simples com uma ferramenta complexa, sem se adaptar ao contexto.
Nossa missão era refatorar o sistema -não apenas no nível do código, mas no nível arquitetônico-com o foco principal na redução dos custos de manutenção de longo prazo. Para conseguir isso, decidimos manter a abordagem de microsserviço, mas com um nível mais pragmático de granularidade. Em vez de 25 microsserviços, consolidamos o sistema em apenas 5 serviços agrupados cuidadosamente, reduzimos instâncias de cache de 3 para 1 e migramos 10 bancos de dados para 5.
Consultando o sistema
Antes de tomar decisões, realizamos uma auditoria completa da arquitetura, desempenho do aplicativo, eficiência e custo geral do sistema. Olhar apenas para o diagrama arquitetônico bruto raramente é suficiente – queríamos observar o sistema em ação e prestar muita atenção às principais métricas. Essa análise ao vivo forneceu informações críticas para a configuração dos novos aplicativos para melhor atender aos requisitos originais do sistema, reduzindo os custos operacionais.
Acesso ao provedor de nuvem
Para entender verdadeiramente a arquitetura de um sistema, é essencial ter acesso ao ambiente do provedor de nuvem – com um amplo conjunto de permissões. Esse nível de visibilidade compensa significativamente. Quanto mais detalhou sua compreensão nesta fase, mais oportunidades você descobrir para otimização e economia de custos durante a consolidação.
Acesso às ferramentas de monitoramento
A maioria dos sistemas inclui ferramentas de monitoramento para rastrear sua saúde e desempenho. Esses insights ajudam a identificar quais métricas são mais críticas para o sistema. Dependendo do caso de uso, o fator -chave pode ser o poder de computação, uso de memória, contagem de instâncias ou simultaneidade. No nosso caso, descobrimos que alguns microsserviços estavam sendo desnecessariamente autocal. O uso da CPU estava aumentando – não devido à falta de recursos, mas por acumular solicitações nos próximos microsserviços na cadeia que realizou cálculos pesados e interagiu com APIs externas. A compreensão desses padrões nos permitiu tomar decisões informadas sobre configurações de contêiner de aplicativos e estratégias de escala automática.
Refatoração, consolidação e otimização da arquitetura em nuvem
Consolidamos com sucesso 25 microsserviços em 5 aplicativos independentes e auto-suficientes, cada um apoiado por um dos 5 bancos de dados padronizados-abaixo de um conjunto anteriormente fragmentado de 10 e uma única instância de cache em vez de 3. Ao longo desta transformação, mantemos um princípio de refatoração do núcleo: as entradas e saídas do sistema devem permanecer inalterados. Internamente, no entanto, a arquitetura e o fluxo de dados foram redesenhados para melhorar a eficiência e a manutenção.
Nós definimos cuidadosamente os limites do domínio para determinar quais serviços poderiam ser mesclados. Na maioria dos casos, camadas anteriormente separadas – proxies de repouso, lógica de serviço e repositórios – foram reunidos em um aplicativo unificado em um único domínio. Alguns aplicativos exigiam migrações de banco de dados, resultando em bancos de dados consolidados estruturados em vários esquemas para preservar os limites do legado.
Embora tenhamos estimado os requisitos de recursos para os novos serviços, o comportamento da produção pode ser imprevisível-especialmente quando o teste de carga de trabalho antes do lançamento não é possível. Para permanecer seguro, provisionamos um buffer de desempenho para lidar com picos inesperados.
Embora a redução de custos fosse nossa meta principal, sabíamos que estávamos lidando com aplicativos voltados para o cliente, onde a estabilidade e a experiência do usuário vêm em primeiro lugar. É por isso que adotamos uma abordagem segura e atenciosa – com foco na consolidação e otimização inteligentes sem arriscar a confiabilidade. Nosso objetivo não era apenas reduzir custos, mas fazê-lo de uma maneira que também melhorasse o sistema sem impactar os usuários finais.
Desafios e riscos de arquitetura refatorando
Conhecimento limitado de domínio comercial
É um desafio difícil quando você está trabalhando com aplicativos e domínios sem uma visão profunda da lógica de negócios. Por um lado, não era estritamente necessário, pois estávamos operando em um nível arquitetônico mais alto. Mas toda vez que precisávamos testar e corrigir problemas após a consolidação, tínhamos que investigar do zero – geralmente sem orientação clara ou experiência em domínio.
Falta de oportunidades de teste
Em projetos de fase de manutenção, é comum que suporte dedicado ao controle de qualidade ou testadores com conhecimento profundo do sistema não esteja disponível-o que é totalmente compreensível. Nesse ponto, geralmente confiamos no trabalho realizado por desenvolvedores anteriores: verificando quais tipos de testes existem, quão bem eles cobrem o código e a lógica de negócios e a eficácia de capturar problemas reais.
Limitações de consolidação paralela
A granularidade do sistema original dificultava que mais de um desenvolvedor trabalhe na consolidação de um único microsserviço simultaneamente. Normalmente, cada domínio foi tratado por um desenvolvedor, mas em alguns casos, ter várias pessoas trabalhando juntas poderia ter ajudado a prevenir problemas durante um processo tão complexo.
Compatibilidade com versões anteriores
Todo aplicativo consolidado teve que ser 100% compatível com os microsserviços de pré-consolidação para permitir reversões, se necessário. Isso significava que não poderíamos introduzir mudanças de ruptura durante a transição – adicionando pressão extra para acertar as coisas da primeira vez.
Configuração distribuída
A configuração dispersa de design excessivo do sistema antigo em vários serviços e um servidor de configuração. A reconstrução disso em uma configuração unificada exigiu uma investigação cuidadosa para localizar, alinhar e centralizar tudo em uma aplicação.
Impacto do usuário final
Como o sistema estava voltado para o cliente, qualquer lacuna de bug ou funcionalidade após a consolidação pode afetar diretamente os usuários. Isso levantou as apostas para todas as mudanças e reforçou a necessidade de um lançamento cauteloso e atencioso.
A refatoração arquitetônica vem com riscos e entendê -los antecipadamente é essencial para oferecer confiabilidade do sistema e eficiência de custos.
O que ganhamos: custos mais baixos, maior confiabilidade e um sistema sustentável
Redução de custos de nuvem
Após a consolidação, Os custos gerais de infraestrutura em nuvem foram reduzidos em 82%. Este foi um resultado direto da refatoração arquitetônica, redução de microsserviços e uso de recursos mais eficiente.
Eficiência da ferramenta de monitoramento
A nova arquitetura também reduziu a carga em ferramentas de monitoramento externas, levando até 70% de queda nos custos relacionados.
Economia indireta de custos
Embora não tivéssemos acesso total a algumas métricas de cobrança, sabemos que muitas ferramentas cobram com base em fatores como volume de solicitação, contagem de microsserviços e tráfego interno. Simplificar o núcleo do sistema também trouxe economia nessas áreas.
Manutenção simplificada
Encolhendo de 25 microsserviços a 5 reduziu drasticamente o esforço necessário para o desenvolvimento de recursos, liberações específicas de domínio e gerenciamento de pipeline de CI/CD. Depois que removemos a fachada da complexidade, ficou claro que o sistema não era tão complicado quanto parecia. A integração de novos desenvolvedores agora é muito mais rápida e fácil – o que também abre a porta para repensar quantos engenheiros são realmente necessários para o suporte contínuo.
Implantação zero de tempo de inatividade
Como estávamos trabalhando com um sistema voltado para o cliente, minimizar o tempo de inatividade para cada liberação foi crítico. Ao consolidar a funcionalidade em 5 aplicativos de domínio claramente definidos, tornamos possível obter implantações zero de tempo de inatividade na produção.
Complexidade reduzida
A consolidação esclareceu como o sistema funciona e deu aos desenvolvedores uma visão mais ampla de seus componentes. Com domínios coesos e lógica em menos aplicativos, agora é mais fácil seguir os fluxos de negócios, implementar soluções eficientes, problemas de depuração e escrever testes eficazes.
–
Toda decisão tomada em um determinado momento geralmente parece a certa – e muitas vezes é. Mas se algo permanecer importante ao longo do tempo, vale a pena revisar essa decisão à luz de um novo contexto e em circunstâncias em evolução. Como mostra o nosso caso, reservar um tempo para reavaliar pode realmente pagar – literal e figurativamente.
