Aplicação distribuída usando RabbitMQ

5

Estou a caminho de criar um aplicativo com 4 contextos delimitados usando CQRS & fornecimento de eventos.

Para fazer com que esses contextos limitados se comuniquem, eu planejava usar o Rabbit MQ.

Meus requisitos são os seguintes:

  • O contexto limitado não deve conhecer um ao outro
  • O contexto limitado não deve ser impedido se o outro contexto limitado estiver inativo ou se rabbitMQ estiver inativo
  • Se um contexto limitado não estiver disponível, as mensagens, que ele deve receber, devem esperar pacientemente pelo seu retorno, ou seja: todo evento publicado deve ser encaminhado pelo menos uma vez para todos os bc interessados.

Portanto, eu estava pensando em fazer com que cada um deles fizesse referência a uma fila: BandMasterQueue e cria se não for.

Ao produzir um evento, a loja de eventos o armazena e seu envio consiste em duas etapas:

  1. projete em si este evento para cada pequena projeção. Cada projeção tem um pequeno estoque de eventos já projetados para garantir a idempotência ao longo de algum período de tempo.
  2. publique este evento na fila BandMasterQueue

se ele falhar na etapa 2 devido a nenhum rabbitmq disponível, então espero que minha loja de eventos tente enviar novamente a mensagem para o RabbitMQ depois de algum tempo (não exatamente com precisão sobre essa parte, devo dizer ...)

O "contexto limitado" do bandMaster conhece cada BC diferente que ele cuida. Ele é quem está lendo o bandMasterQueue e decide quais eventos são públicos e quais não são. Ele também é responsável por lidar com as "sagas" e pode enviar ações corretivas para cada bc.

Para fazer isso, ele se comunicará com cada contexto limitado usando a fila dedicada do contexto limitado e o criará se não sair.

Cada BC é vinculado a essa fila específica e adiciona o evento proveniente de fora em seu próprio armazenamento de eventos e depois projeta-o para sua própria projeção.

Esta "arquitetura" deve funcionar ou você vê alguma falha importante nela?

    
por Arthis 29.07.2012 / 09:44
fonte

2 respostas

3

Veja a documentação do ZeroMQs, especialmente o guia . Eu acho que você gostaria de algo nos moldes da Figura 19 - Extended Request-reply. se não, há muita documentação lá que deve dar o que você precisa em alguma combinação.

Não tenho certeza do que você quer dizer no ponto 3, mas o restante parece precisar de uma arquitetura de passagem de mensagem desconectada - você dispara mensagens na rede e, se um BC estiver ativo e em escuta, ele receberá a mensagem para processar.

Se você precisar enviar uma mensagem a um BC que esteja inativo, precisará de um corretor que os leia e aguarde o início do BC, com o qual eles serão enviados - entretanto, isso significa que o corretor precisa saber sobre os BCs, a fim de saber se deve armazenar mensagens para um.

    
por 29.07.2012 / 16:01
fonte
0

Você pode considerar o uso de um mecanismo de Pool de Filas para gerenciar Filas do RabbitMQ e também para determinar o tamanho necessário do pool sob carga. Aqui é um tutorial sobre o assunto.

    
por 01.09.2015 / 14:58
fonte