Uyarı Sistem Mimarisi

Çeşitli programlardan gelen uyarı mesajlarını işleyen ve bu uyarıları e-posta yoluyla tüketicilere indirgeyen bir sistem oluşturmak istiyorum. Tüm bunlar tek bir dahili ağ üzerinden sağlanacaktır.

Bence temel mimarinin şöyle görünmesini istiyorum:

Şu anda sahip olduğum temel endişe benim "API-çeşit" ne olacak "Message Handler" bit. Bu sistemin tüm bileşenlerinin veritabanına tüm yazmaları işleyen API'ya veri göndermesini istiyorum. Bence bu yaklaşım daha kolay çünkü güvenliği kolaylaştırıyor ve çok daha karmaşık DB sorgularını tek bir programa dahil etmeme izin veriyor.

Endişe bu dil agnostik olmasını istiyorum - yani herhangi bir kod Handler benim mesaj göndermek gerekir - bu onları yorumlayacak. Bunu JSON düz dosyaları aracılığıyla veya programa REST çağrıları (aşağı akış uygulamalarına esneklik vererek) yapmayı umuyorum.

Benim sorum-

İleti işleyicisiyle uğraşmalı mıyım - yoksa yalnızca aşağı akış uygulamalarına ve diğer iki bileşene (Yönetim Konsolu ve Uyarı Yöneticisi) doğrudan veritabanı erişimine izin vermek için basitlik ekleyebilir miyim?

Bu şekilde, DB tablosuna / tablolarına INSERT geçerli olduğu sürece istedikleri uyarıyı ekleyebilirler.

Ben ticaret tarafından bir yazılım tasarımcısı değilim, bu yüzden affedersiniz - sadece boş zamanlarımda bir proje yapmak istiyorum.

AMQP'ye (Gelişmiş Message Queuing Protokolü: https://www.rabbitmq.com/protocol.html ) baktınız mı ?

RabbitMQ böyle bir şey için harika bir araçtır, sanırım (başkaları da var, MSMQ, Azure / AWS hizmetleri, vb.). Sadece bir dil agnostik mesaj işleyici almakla kalmaz (basit "mesajı mesaj sunucusuna json verileri ile gönderir"), aşağı yönlü mesaj işlemeyi ayırır ve iyi yalıtılmış hale getirirsiniz. İhtiyacınız olan kuyruklardan gelen mesajları işleyen bir mesaj servisi çalıştırın ve bildirimlerinize tükürün.

AMQP'yi kullanmaktan gerçekten hoşlanmamın nedenlerinden biri, şimdi ev yapımı bir çözümle olduğu gibi başlamanızdır, ancak zamanla, türe, kime gitmesi gerektiğine bağlı olarak iletileri biraz farklı şekilde ele almanız gerektiğinin farkına varın. , sonuçta kendi AMQP uygulamanızı zaten oluşturursunuz.

Bir iletinin 5 farklı alıcıya gitmesi gerekiyorsa ne yaparsınız? Bir dizi işlemcide döndürülmesi gereken bir mesajınız varsa (uzun süren görevleri düşünün ve belirli bir türdeki iletileri yuvarlayabileceğiniz X sayıda eşzamanlı işlemciye sahip olun). İletinin bir kişiye gitmesi gerekiyorsa, ancak çevrimiçi / uygun değilse başka birine gitmelidir? AMQP, tüm bunları (oldukça güzel!) Çok güzel kategorizasyon, kuyruklar, kanallar, dayanıklı kalıcılık, her türlü özellik ile zaten ele alıyor.

İşte işleyebileceği senaryoların temel bir özeti (bunun RabbitMQ'ya özgü olmadığını unutmayın: bu bir AMQP olayı, ancak RabbitMQ bunu iyi açıklıyor) - https://www.rabbitmq.com/getstarted.html

Çok iyi çerçeveli bir soru!

Bu yüzden tüm mimari kararlar ödünleşim içerir. Eğer denemeler hakkında bir tartışma merak ediyorsanız, sorunuzu belki bu yönde düzenleyin. Bunun yerine, soru sadece bir pozisyon istediğinden, MessageHandler lehine tartışmayı benimseyeceğim. Bir veritabanı dahil DEĞİL önermek için bir adım daha ileri gidecek - en azından bir SQL veritabanı değil, en azından başlatmak için. MessageHandler'ın JSON'u dosya sistemine kaydetmesini sağlayın, alınan saat başına dizin başına uyarıları söyleyin (elbette birime bağlı olarak) ve Alert Manager tarafından sorgulandığında API'nın son 2 dizininde geçiş yapmasını sağlayın hangi e-postaların dağıtılacağına karar vermek için uyarılar (elbette önceliğe bağlı olarak).

Bu problemde çiğnemek için bir ton iyi şey var ve bir veritabanını erken aşamalarda resimden uzak tutmak çok fazla gürültü ve gereksiz problem çözmeyi ortadan kaldıracak. Tabii ki, belki de ilişkisel veri modelleri oluşturma ve SQL yazma hayali gizli bir sevginiz var. Bu durumda, bu cevap tamamen yanlıştır. Ancak genel olarak konuşursak, en çevik veritabanları bile korkunç uygulama platformlarıdır ve yalnızca sistemlere dahil edilirler, çünkü bunlar dayanıklılık ve dizine alınmış sorguda uzmandırlar.

İyi şanslar!