Peringatkan Arsitektur Sistem

Saya ingin membuat sistem yang menangani pesan-pesan peringatan dari berbagai program dan dapat memproses peringatan itu untuk konsumen yang tidak bersemangat melalui email. Ini semua akan terkandung dalam satu jaringan internal.

Saya rasa saya ingin arsitektur dasar terlihat seperti ini:

Perhatian utama yang saya miliki saat ini adalah bit "Message Handler", yang akan menjadi "sort-of-API" saya. Saya ingin semua komponen sistem ini mengirim data ke API, yang menangani semua penulisan ke basis data. Saya pikir pendekatan ini lebih mudah karena menyederhanakan keamanan, dan memungkinkan saya untuk memuat banyak pertanyaan DB yang lebih rumit ke dalam satu program tunggal.

Kekhawatirannya adalah bahwa saya ingin ini menjadi bahasa agnostik - yang berarti bahwa kode apa pun harus dapat mengirim pesan ke Handler saya - yang akan menafsirkannya. Saya berharap untuk melakukan ini melalui file flat JSON - atau melalui panggilan REST ke program (memberikan fleksibilitas untuk aplikasi down-stream).

Pertanyaanku adalah-

Haruskah saya repot-repot dengan penangan pesan - atau apakah akan menambah kesederhanaan untuk hanya memungkinkan akses database langsung ke aplikasi down-stream, serta dua komponen lainnya (Management Console, dan Alert Manager)?

Dengan begitu, mereka dapat memasukkan peringatan apa pun yang mereka inginkan - selama INSERT ke dalam tabel DB valid.

Saya bukan perancang perangkat lunak berdagang, jadi permisi - saya hanya ingin proyek dilakukan di waktu senggang saya.

Sudahkah Anda melihat AMQP (Protokol Antrian Pesan Tingkat Lanjut: https://www.rabbitmq.com/protocol.html )?

RabbitMQ adalah alat yang luar biasa untuk hal seperti ini, saya pikir (ada juga yang lain, MSMQ, layanan Azure / AWS, dll.). Anda tidak hanya mendapatkan satu penangan pesan agnostik bahasa (sederhana "kirim pesan ke server pesan dengan data json"), Anda melepaskan pemrosesan pesan hilir dan membuatnya terisolasi dengan baik. Jalankan layanan pesan yang memproses pesan masuk dari antrian yang Anda butuhkan dan keluarkan pemberitahuan Anda.

Salah satu alasan saya sangat suka menggunakan AMQP adalah bahwa Anda memulai seperti Anda sekarang dengan beberapa solusi buatan sendiri, tetapi menyadari setelah beberapa saat Anda perlu menangani pesan sedikit berbeda tergantung pada jenisnya, kepada siapa ia perlu pergi, dll. , jadi pada akhirnya Anda tetap membangun implementasi AMQP Anda sendiri.

Apa yang Anda lakukan jika sebuah pesan perlu menuju ke 5 penerima yang berbeda? Bagaimana jika Anda memiliki pesan yang harus diputar di sejumlah prosesor (pikirkan tugas yang sudah berjalan lama dan memiliki jumlah prosesor simultan X, di mana Anda dapat memotong-motong pesan dari jenis tertentu). Bagaimana jika pesan tersebut ditujukan ke satu orang, tetapi jika tidak tersedia / online, pesan tersebut harus dikirim ke orang lain? AMQP sudah menangani semua ini (dengan sangat baik!), Dengan kategorisasi yang sangat bagus, antrian, saluran, ketekunan yang tahan lama, segala macam fitur.

Berikut ini gambaran umum dasar dari skenario yang dapat ditangani (perhatikan ini tidak spesifik untuk RabbitMQ: ini adalah hal AMQP, tapi RabbitMQ menjelaskannya dengan baik) - https://www.rabbitmq.com/getstarted.html

Pertanyaan berbingkai sangat baik!

Jadi- semua keputusan arsitektur melibatkan pengorbanan. Jika Anda penasaran dengan diskusi tentang tradeoffs mungkin edit pertanyaan Anda ke arah itu. Alih-alih, karena pertanyaannya hanya meminta posisi, saya akan mengambil sisi berdebat demi MessageHandler. Saya akan melangkah lebih jauh untuk menyarankan TIDAK memasukkan database - setidaknya bukan database SQL, setidaknya untuk tidak memulai. Hanya saja MessageHandler menyimpan JSON ke sistem file, katakanlah direktori-per-jam-dari-penerimaan yang diterima (tergantung pada volume, tentu saja), dan miliki API ketika ditanyai oleh Alert Manager yang hanya melintasi 2 direktori terakhir dari peringatan untuk memutuskan email yang akan dikirim (tergantung prioritas, tentu saja).

Ada banyak hal baik untuk dikunyah dalam masalah ini, dan menjaga database dari gambar pada tahap awal akan menghilangkan banyak suara tak terduga dan pemecahan masalah yang tidak perlu. Tentu saja, mungkin Anda memiliki cinta tersembunyi untuk menciptakan model data relasional dan impian untuk menulis SQL. Dalam hal ini, jawaban ini sepenuhnya salah. Tetapi secara umum bahkan database yang paling gesit adalah platform aplikasi yang mengerikan, dan mereka hanya dimasukkan dalam sistem karena mereka adalah spesialis pada daya tahan dan permintaan yang diindeks.

Semoga berhasil!