Messaging persistente / Bus Service - rolo meu próprio, ou arriscar a curva de aprendizagem?

Question

Nós temos uma aplicação cliente que precisa enviar mensagens para um servidor de várias notificações. A fim de que o cliente pode executar ocasionalmente conectado estou indo para ir com uma abordagem mensagem de-fila. O processamento de fila terá mensagens fora da fila e chamar um serviço web que irá colocá-los em outra fila para finalmente ser processado. Esta pergunta é sobre o ambiente do cliente; o ambiente de servidor já está decidida.

Eu não quero usar MSMQ porque não temos controle sobre todos os PCs clientes para instalar / configurar e proteger MSMQ adequadamente, e porque o apoio é mais difícil devido à qualidade de ferramentas para investigar o conteúdo de filas MSMQ. SQL Server 2005 Express é em todas as máquinas, e é usado para armazenar dados para a nossa aplicação.

Eu tenho atualmente-lo a duas opções:

1. Escreva uma mensagem-fila persistente bastante básico que armazena as mensagens em uma mesa depois serializadas-los, em seguida, utiliza ThreadPool.QueueUserWorkItem para tê-los processados ??por manipuladores configurados contra cada tipo de mensagem. Tudo em um System.Transactions.TransactionScope para que eles só são removidos da fila persistente se eles são processados ??com sucesso.
2. Use NServiceBus (este é o barramento de serviço temos ido com como uma equipe, então MassTransit etc não são opções) no cliente, com um transporte do Service Broker que usa o banco de dados local.

Eu tenho pouca experiência com autocarros de serviço (eu ainda realmente não entendo a terminologia barramento de serviço) por isso estou preocupado com a curva de aprendizagem comparado a escrever algo muito mais simples que atende as minhas necessidades da maneira que eu preciso que ele ( implementação é um grande consideração).

Alguém tem alguma ideia?

Answer 1

No final, eu escrevi messagebus básicos configurado com minha própria SqlTransport para que as mensagens são serializados e salvos em uma tabela de banco de dados SQL Server, antes que os eventos são levantadas e um segmento separado é sinalizado para processar as mensagens.

Answer 2

Bem, eu não sei que eu vou sugerir MSMQ, mas vou sugerir que há um monte de casos de ponta para pensar para 'roll seu próprio'.

Mesmo com uma abordagem pool de threads, estar ciente de que pode haver encomendar problemas se você se importa - dois itens postou sequencialmente para piscinas thread pode não ser executadas em ordem, devido à forma como a alça thread pools itens de trabalho.

Você também precisa pensar sobre a persistência de mensagens, e quanto tempo eles devem existir, como detectar o estado de não-entrega 'fatal', eo que fazer nesse caso.

Há também um número de casos de ponta potenciais em cenários onde a sua aplicação vai para baixo em torno do mesmo tempo em que está na fila uma mensagem - por exemplo, pode não obter o reconhecimento de que a mensagem foi na fila, mesmo que fosse. Sim, você pode ack o reconhecimento fila, mas você pode infinitamente entrar em círculos ack ...

Porque não basta ter o aplicativo detectar quando fica conectado, e enviar todos os dados nesse ponto?

Answer 3

Depois de ter escrito o nosso próprio barramento de serviço posso dizer-lhe que não é uma tarefa trivial e você vai correr para os mesmos casos de ponta que todos os outros implementadores já funcionar. Kyoryu traz dois muito importantes.

Se você rolar o seu próprio também depende das habilidades que você tem em casa e vai ter no futuro para manter a solução.

Outra consideração é o eventual escala do sistema e é requisitos de confiabilidade. Será que a escala solução in-house suficientemente?

Nosso ônibus peer-to-peer mensagem, zebus, com base em ZeroMq (transporte), Cassandra (peer descoberta e persistência) e Protobuf (serialização).

1. Sem a implementação do cliente como no cliente é apenas uma biblioteca
2. mensagem persistência é fornecido usando Cassandra como diferentes casos de ponta bem e lida com muitos (esta é regularmente testada em nosso ambiente de produção)
3. Ele executa bem e como é uma solução brokerless não existe um único gargalo de desempenho
4. Não há pontos únicos de falha como o Diretório pode ser usado com um conjunto de dados disponíveis loja, como Cassandra

É open source e produção testado https://github.com/Abc-Arbitrage/Zebus