Como lidar com mensagens com falha no DDD?

5

Temos um conjunto de micro-serviços, todos construídos de acordo com o Domain Driven Design (DDD). Os micro-serviços se comunicam via Eventos de Domínio entre si ( OrderSubmittedEvent , CustomerBilledEvent , ...). Implementamos tudo com o Spring Boot e usamos o JMS com o ActiveMQ como intermediário de mensagens. Todos os eventos são publicados em um tópico e cada micro-serviço pode implementar um ouvinte JMS para um evento de interesse.

Mas, para o tratamento de erros, dependemos strongmente do ActiveMQ. Como eu disse, todos os eventos são enviados para um tópico. No entanto, configuramos o ActiveMQ para usar os Tópicos Virtuais para os ouvintes, o que significa que o ActiveMQ criará uma fila separada para cada ouvinte e copiará a mensagem do tópico para a fila. Se um ouvinte falhar, a mensagem será enviada para uma fila de devoluções (DLQ). Isso nos ajuda, porque podemos monitorar o DLQ, ver erros, corrigi-los e colocar a mensagem de volta na fila do ouvinte que falhou em outra tentativa.

Temos alguns problemas com isso:

  • Acabamos com muitas filas, pois cada ouvinte terá sua própria fila.
  • Não podemos alternar o intermediário de mensagens, pois confiamos nos tópicos virtuais do ActiveMQ.
  • Não podemos usar o ActiveMQ fora da caixa, pois devemos configurá-lo sempre. Nosso cliente para o qual desenvolvemos o software faz a configuração manualmente em seu sistema. Como temos tantas filas e pequenas armadilhas, é muito complicado para ele.

Bem, não temos uma ideia melhor, é por isso que estou entrando em contato com você. Como podemos lidar com mensagens com falha? Qual o seu caminho?

    
por Thomas Uhrig 27.12.2017 / 17:34
fonte

1 resposta

5

Uma maneira de lidar com isso é usar ouvintes baseados em pull em vez de baseados em push. Cada ouvinte acompanha sua última mensagem lida e pode solicitar "mensagens desde X". Você pode usar a pesquisa ou uma notificação quando um novo evento entrar ou ambos para acionar solicitações de mensagens. Não há mais filas, mas o ouvinte precisará armazenar seu último ID de mensagem processada. Você também precisa armazenar os eventos de uma maneira que preserve a ordem para suportar solicitações de ouvinte.

Sempre que um ouvinte falha em processar um evento, ele pode registrar a falha em qualquer infraestrutura de registro configurada. Então você observará ou será notificado da falha por sua infraestrutura de monitoramento. Depois de corrigir esse listener específico e reimplementá-lo, o ouvinte será iniciado de volta de onde parou.

    
por 27.12.2017 / 18:14
fonte