Quando seus microsserviços começam a “gaguejar”, ​​talvez o problema esteja escondido em algum lugar invisível.

Imagine o seguinte: você construiu um sistema muito bom, com clara divisão de trabalho entre microsserviços, e ele deve funcionar tão bem quanto uma sinfonia bem orquestrada. Mas não sei quando a velocidade de resposta começou a diminuir, o carregamento da página continuou andando em círculos e vários erros de tempo limite apareceram ocasionalmente. Você verificou o código e expandiu as especificações do contêiner, mas o problema era como uma névoa que se dispersou por um tempo e depois voltou.

Neste momento, você já pensou que o gargalo pode não ser o cálculo, mas os dados indo e voltando?

Cache: Não é uma decoração opcional, mas o mecanismo oculto de desempenho

No mundo dos microsserviços, os serviços frequentemente conversam entre si. Uma solicitação do usuário pode exigir que cinco ou seis serviços peçam uns aos outros para explicar a resposta. Cada consulta é uma jornada na rede, uma consulta ao banco de dados. Quando o tráfego aumenta, a estrada fica congestionada.

O que o cache faz é realmente muito simples: armazenar temporariamente as respostas mais frequentes em um local mais próximo do solicitante. Da próxima vez que alguém fizer a mesma pergunta, o sistema não precisará mais percorrer longas distâncias para verificar, bastando dar a resposta anterior. É como ter um bloco de notas público em um escritório movimentado. Quem precisa procurar um número usado com frequência pode apenas dar uma olhada no bloco de notas sem ter que ir sempre aos arquivos.

Mas fazer cache em microsserviços é muito mais do que apenas “colocar um bloco de notas”. Ele tem que decidir o que deve ser registrado, por quanto tempo lembrar, quando atualizar e também garantir que os dados vistos por vários serviços sejam consistentes. Bem feito, é um acelerador; feito de maneira descuidada, torna-se uma fonte de caos de dados.

Por que sua solução de cache não está funcionando tão bem quanto deveria?

Muitas pessoas inicialmente pensaram que, para o armazenamento em cache, não seria suficiente adicionar Redis ou Memcached? Mas quando realmente o usei, percebi que as coisas não eram tão simples.

Por exemplo, "penetração de cache" - alguém continua consultando dados que não existem e que não estão no cache. A solicitação sempre atinge o banco de dados subjacente, sobrecarregando o banco de dados. Outro exemplo é a "avalanche de cache" - um grande número de caches falha ao mesmo tempo, todas as solicitações chegam ao banco de dados instantaneamente e o sistema pode ficar paralisado no local. Há também um problema mais sutil de “consistência de dados”: o serviço A atualiza os dados, mas o cache do serviço B ainda é uma versão antiga e as informações vistas pelo usuário são inconsistentes.

Por trás desses problemas, muitas vezes ocorre porque a estratégia de cache é tratada como um patch adicionado posteriormente, em vez de um componente central que foi projetado desde o início.

Uma ideia de design mais integrada à textura

Em vez de tratar o cache como um plug-in separado, ele deveria fazer parte da forma como os serviços se comunicam entre si. Para algumas solicitações, o resultado não mudará no curto prazo, então sinta-se à vontade para armazená-lo em cache; para alguns dados, um pequeno atraso é aceitável e, em seguida, atualize-os de forma assíncrona. A chave é deixar claro durante o projeto da arquitetura quais dados são adequados para armazenamento em cache, em que granularidade e como invalidar e sincronizar normalmente.

Isto requer o apoio de ferramentas, mas também requer uma mudança de pensamento. As ferramentas devem ajudá-lo a implementar essa ideia, e não adicionar nova complexidade.

Como isso funciona em um cenário da vida real?

Vejamos um cenário comum: uma página de detalhes do produto precisa chamar serviços de usuário, serviços de inventário, serviços de preços, serviços de avaliação, etc. Se nenhum processamento for feito, essa cadeia de chamadas terá que ser percorrida sempre que a página for aberta.

E se uma camada de cache razoável for introduzida? As informações do usuário podem ser armazenadas em cache por 12 horas, o status do inventário por 30 segundos e os preços e avaliações por 5 minutos. Diferentes tempos de expiração correspondem a diferentes frequências de alteração de dados. O tempo de carregamento da página pode ser reduzido de centenas de milissegundos para dezenas de milissegundos. Por trás dessa mudança está uma redução significativa na pressão do banco de dados e uma melhoria na flexibilidade geral do sistema.

Claro, isso requer ajustes finos - quais dados valem a pena armazenar em cache? Quanto tempo é armazenado em cache? Como o mecanismo de atualização é acionado? Essas decisões dependem de um profundo entendimento da lógica de negócios, e não apenas da configuração técnica.

Na hora de escolher, para onde seus olhos devem olhar?

Precisa ser leve o suficiente para que o processo de inserção não se torne um novo desastre de engenharia. É melhor se adaptar naturalmente aos processos de desenvolvimento existentes, em vez de deixar a equipe aprender um novo conjunto de conceitos complexos do zero.

É menos intrusivo ao código comercial. Os engenheiros devem se concentrar na lógica de negócios em si, em vez de gastar muita energia gerenciando manualmente cada regra de cache. Mecanismos automatizados e inteligentes de invalidação e atualização são particularmente importantes aqui.

Além disso, a observabilidade é essencial. Você precisa ver claramente qual é a taxa de acertos do cache, quantas solicitações são salvas e quais estratégias de cache são mais eficazes. A transparência pode trazer controle real.

Ele precisa resistir ao teste do tráfego real. A solução em si não pode tornar-se um novo ponto único de falha. Deve ter um design de alta disponibilidade e ser capaz de permanecer estável sob pressão.

dê um passo à frente

Quando o sistema fica lento, as pessoas instintivamente desejam atualizar o hardware e o código. Isto é certamente verdade. Mas às vezes, a alavanca mais eficaz está escondida no modelo de comunicação da arquitetura. Ao poupar dados de viagens desnecessárias e reduzir a duplicação de trabalho entre serviços, o potencial do sistema pode ser libertado para além das suas expectativas.

Não se trata de adicionar um componente tecnológico interessante, trata-se de reexaminar a eficiência do fluxo de dados. Quando você começa a pensar no cache não apenas como uma escolha tecnológica, mas como uma filosofia de design, as respostas para muitos gargalos podem surgir naturalmente.

No mundo dos microsserviços, a velocidade muitas vezes não depende da rapidez com que um único serviço é executado, mas da inteligência com que eles colaboram. A estratégia de cache apropriada é a parte que torna esta colaboração mais inteligente e menos trabalhosa. Não é barulhento, mas é vital.

Fundada em 2005,potênciatem se dedicado a um fabricante profissional de unidades de movimento compacto, com sede em Dongguan, província de Guangdong, China. Aproveitando inovações em tecnologia de acionamento modular,potênciaintegra motores de alto desempenho, redutores de precisão e sistemas de controle multiprotocolo para fornecer soluções de sistemas de acionamento inteligentes eficientes e personalizadas.potênciaforneceu soluções profissionais de sistemas de acionamento para mais de 500 clientes empresariais em todo o mundo, com produtos que abrangem vários campos, como sistemas domésticos inteligentes, eletrônica automática, robótica, agricultura de precisão, drones e automação industrial.