Microsserviços - compense a falha do serviço com a fila

Estamos usando algum tipo de abordagem de microsserviços em nosso aplicativo (embora não seja realmente respeitado).

Quando um serviço está inoperante ou lança uma exceção, a abordagem é colocá-lo em uma fila (ActiveMQ) e tentar novamente quando o serviço estiver ativo novamente.

Esta é uma solução "padrão"? Ou deveria ser evitado por algum motivo?

Ou existe uma solução melhor ou alternativa para esse problema?

microservices message-queue

— user140547
fonte

Qual é o problema com a solução atual? A melhor / melhor solução é aquela que atende totalmente às suas necessidades. Faça o atual?

— LAIV

@Laiv: Não há nenhum problema em si, mas como eu não sou tão experiente com essa arquitetura, eu estava apenas perguntando se existem problemas ou limitações em potencial dessa abordagem que devem ser considerados.

— user140547

O que acontece se a fila estiver inativa?

— Jon Raynor

@JonRaynor: desistir e retornar um erro, uma vez que seria provavelmente um exagero para implementar um segundo mecanismo de retorno ...

— user140547

Respostas:

Supondo que você possa fazer suas chamadas assíncronas (não é necessário obter uma resposta do serviço para prosseguir), isso geralmente é uma boa idéia.

Ele permite que o serviço de chamada continue trabalhando sem o atraso (ou erro total) causado pela chamada do outro serviço. Ele permite que você tenha uma lógica de repetição mais complexa e espalhe a carga de maneira mais uniforme ao longo do tempo.

Em muitos casos, você pode obter ainda mais benefícios desistindo das garantias de pedidos fornecidas pelas filas e alternando para o Kafka ou outro intermediário de mensagens assíncronas. Hermes fornece uma API REST mais conveniente sobre Kafka.

— Michał Kosmulski
fonte

Voto esta resposta assumindo que o contexto é que estamos falando sobre o cliente. Esta não é realmente uma questão de microsserviços. É uma decisão de design do cliente. Se o serviço for síncrono ou não e estiver ativo ou não. Não está claramente explicitado na pergunta, mas realmente só faz sentido se estivermos falando de um cliente.

— JimmyJames

Esta é uma péssima abordagem na minha opinião. você deveria

Sempre se comunique com uma fila: seu aplicativo não deve esperar uma resposta imediata e, portanto, o processo de trabalho não precisa estar 100% disponível
Sempre use comunicações no estilo RPC. Solicitações de balanceamento de carga em várias instâncias de serviço: se um serviço estiver com defeito, outro responderá à solicitação, para que você tenha 100% de tempo de atividade

Tendo o fluxo, ligue para o serviço, obtenha um erro, coloque na fila, lembre-se de verificar a fila em busca de respostas para algumas das minhas mensagens, mas não para todas elas. acabou mais complicado.

editar: mais complicado, pois você precisa programar o estilo de comunicação sincronizado e assíncrono, em vez de apenas um ou outro.

— Ewan
fonte

Eu meio que concordo com isso. É mais complicado. É muito difícil avaliar se é muito complicado sem entender a arquitetura maior. O problema de ficar 100% baseado em fila é que ele adiciona um novo ponto único de falha e cria alguns outros desafios. Por exemplo, se o seu processo está sendo sobrecarregado com tarefas, escrevendo para a fila é geralmente muito rápido então não há nenhum problema aparente no lado da entrada até boom da fila enche. Se a origem das solicitações não puder ser regulada, você poderá ter um grande problema. Não intransponível, mas acrescenta sua própria complexidade.

— JimmyJames

Se eu puder, sugiro reformular a última frase. 'Lembrar' não é realmente um problema aqui, uma vez que o código é escrito para ser lido na fila, não há nada para lembrar. É simplesmente um código adicional para escrever e manter, mas não deve parecer muito diferente do que você teria se sempre lesse da fila.

— JimmyJames

nos únicos erros que vão para a fila senario E você deseja respostas, você deve escrever a verificação da fila E a manipulação imediata da resposta. Então você tem que 'lembrar' as chamadas errou e não os imediatos

— Ewan

@ Jimmy você obtém esses problemas com qualquer solução. sempre fila, fila algumas vezes ou todo RPC.

— Ewan

Você realmente não tem alguns desses problemas quando os produtores aguardam os consumidores. Por exemplo, se você receber um máximo de 1000 solicitações por segundo e a capacidade interna de seus processos cair para 100 por segundo, seus produtores serão bloqueados de maneira direta. Eles serão limitados também. Se você simplesmente inserir uma fila no meio, os produtores geralmente não serão afetados pela queda de capacidade e continuarão na taxa máxima. A fila vai então encher-se até atingir o seu limite de capacidade e as gravações começam a falhar (em 1000 fracassos um segundo.)

— JimmyJames