Arquitetura do sistema de alerta

Eu gostaria de criar um sistema que lida com mensagens de alerta de vários programas e possa processar esses alertas para consumidores de baixa velocidade por email. Tudo isso estaria contido em uma rede interna.

Eu acho que quero que a arquitetura básica fique assim:

A principal preocupação que tenho atualmente é o bit "Message Handler", que será o meu "tipo de API". Desejo que todos os componentes deste sistema enviem dados para a API, que lida com todas as gravações no banco de dados. Eu acho que essa abordagem é mais fácil porque simplifica a segurança e permite que eu contenha muitas das consultas de banco de dados mais complicadas em um único programa.

A preocupação é que eu queira que isso seja independente da linguagem - o que significa que qualquer código deve poder enviar mensagens para o meu manipulador - que as interpretará. Espero fazer isso via arquivos simples JSON - ou via chamadas REST para o programa (dando flexibilidade aos aplicativos de downstream).

Minha pergunta é-

Devo me preocupar com o manipulador de mensagens - ou acrescentaria simplicidade para permitir apenas o acesso direto ao banco de dados dos aplicativos de downstream, bem como dos outros dois componentes (Console de Gerenciamento e Alert Manager)?

Dessa forma, eles podem inserir qualquer alerta que desejarem - desde que o INSERT na (s) tabela (s) do banco de dados seja válido.

Não sou designer de software por profissão, então com licença - só quero que um projeto seja realizado no meu tempo livre.

Você já consultou o AMQP (Advanced Message Queuing Protocol: https://www.rabbitmq.com/protocol.html )?

O RabbitMQ é uma ferramenta incrível para algo assim, eu acho (existem outros também, MSMQ, serviços do Azure / AWS etc.). Você não apenas obtém um manipulador de mensagens independente de um idioma (simples "envia a mensagem ao servidor de mensagens com dados json"), mas também desanexa o processamento de mensagens downstream e o torna bem isolado. Execute um serviço de mensagens que processe as mensagens recebidas da (s) fila (s) necessária (s) e cuspe suas notificações.

Uma das razões pelas quais eu realmente gosto de usar o AMQP é que você começa como se estivesse agora com alguma solução caseira, mas percebe que, depois de algum tempo, precisa lidar com as mensagens de maneira um pouco diferente, dependendo do tipo, para quem precisa ir etc. , então você acaba criando sua própria implementação do AMQP de qualquer maneira.

O que você faz se uma mensagem precisar ir para 5 destinatários diferentes? E se você tiver uma mensagem que deve ser alternada em vários processadores (pense em tarefas de longa execução e com um número X de processadores simultâneos, onde você pode alternar entre as mensagens de um tipo específico). E se a mensagem for direcionada para uma pessoa, mas se não estiver disponível / online, deve ser direcionada para outra? O AMQP lida com tudo isso (muito bem!) Já, com categorizações muito agradáveis, filas, canais, persistência durável, todos os tipos de recursos.

Aqui está uma visão geral básica dos cenários que ele pode lidar (observe que isso não é específico do RabbitMQ: é uma coisa da AMQP, mas o RabbitMQ explica isso bem) - https://www.rabbitmq.com/getstarted.html

Pergunta muito bem enquadrada!

Portanto, todas as decisões de arquitetura envolvem trocas. Se você está curioso para uma discussão sobre compensações, talvez edite sua pergunta nessa direção. Em vez disso, como a pergunta apenas pede uma posição, eu aceitarei o lado da argumentação a favor do MessageHandler. Vou dar um passo adiante para sugerir NÃO incluir um banco de dados - pelo menos não um banco de dados SQL, pelo menos para não iniciar. Basta fazer com que o MessageHandler salve o JSON no sistema de arquivos, digamos um diretório por hora de alertas recebidos (dependendo do volume, é claro) e tenha a API quando consultada pelo Alert Manager, apenas percorra os 2 últimos diretórios de alertas para decidir quais emails serão entregues (dependendo da prioridade, é claro).

Há um monte de coisas boas para tratar desse problema, e manter um banco de dados fora de cena nos estágios iniciais removerá muito ruído incidental e a solução desnecessária de problemas. Claro, talvez você tenha um amor oculto por criar modelos de dados relacionais e sonhe em escrever SQL. Nesse caso, esta resposta está totalmente errada. Mas, de um modo geral, mesmo os bancos de dados mais ágeis são plataformas de aplicativos terríveis e só são incluídos nos sistemas porque são especialistas em durabilidade e consulta indexada.

Boa sorte!