Architektura systemu alertów

10

Chciałbym stworzyć system, który obsługuje wiadomości alarmowe z różnych programów i może przetwarzać te alarmy do mniej wymagających klientów za pośrednictwem poczty elektronicznej. Wszystko to byłoby zawarte w jednej sieci wewnętrznej.

Myślę, że chcę, aby podstawowa architektura wyglądała mniej więcej tak:wprowadź opis zdjęcia tutaj

Główny problem, który mam obecnie, to bit „modułu obsługi komunikatów”, który będzie moim „rodzajem API”. Chcę, aby wszystkie komponenty tego systemu wysyłały dane do interfejsu API, który obsługuje wszystkie zapisy do bazy danych. Myślę, że takie podejście jest łatwiejsze, ponieważ upraszcza bezpieczeństwo i pozwala mi zawrzeć wiele bardziej skomplikowanych zapytań DB w jednym programie.

Chodzi o to, że chcę, aby była to niezależna od języka - co oznacza, że ​​każdy kod powinien móc wysyłać wiadomości do mojego modułu obsługi - który je interpretuje. Mam nadzieję, że zrobię to za pomocą plików płaskich JSON - lub poprzez wywołania REST do programu (zapewniając elastyczność aplikacjom pobierającym strumień).

Moje pytanie brzmi-

Czy powinienem zawracać sobie głowę procedurą obsługi wiadomości - czy też uprościłbym to, aby umożliwić bezpośredni dostęp do bazy danych aplikacjom pobierającym strumień, a także dwóm innym komponentom (Management Console i Alert Manager)?

W ten sposób mogą wstawić dowolny alert, o ile chcą - o ile INSERT w tabeli / tabelach DB jest prawidłowy.

Z zawodu nie jestem projektantem oprogramowania, więc przepraszam - po prostu chcę projekt w wolnym czasie.

Krzysztof
źródło

Odpowiedzi:

4

Czy zajrzałeś do AMQP (Advanced Message Queuing Protocol: https://www.rabbitmq.com/protocol.html )?

RabbitMQ to niesamowite narzędzie do czegoś takiego, jak sądzę (są też inne, MSMQ, usługi Azure / AWS itp.). Nie tylko otrzymujesz agnostyczny program obsługi komunikatów w jednym języku (proste „wyślij wiadomość do serwera komunikatów z danymi json”), ale odłączysz dalsze przetwarzanie wiadomości i zapewnisz jej dobrą izolację. Uruchom usługę wiadomości, która przetwarza wiadomości przychodzące z potrzebnych kolejek i wypluj powiadomienia.

Jednym z powodów, dla których naprawdę lubię korzystać z AMQP, jest to, że zaczynasz tak, jakbyś miał teraz jakieś domowe rozwiązanie, ale zdajesz sobie sprawę, że po pewnym czasie musisz obsługiwać wiadomości nieco inaczej, w zależności od typu, do kogo musi się udać itp. , więc i tak ostatecznie budujesz własną implementację AMQP.

Co robisz, jeśli wiadomość musi dotrzeć do 5 różnych odbiorców? Co się stanie, jeśli masz komunikat, który powinien zostać obrócony na wielu procesorach (pomyśl o długich zadaniach i liczbie X równoczesnych procesorów, w których możesz zaokrąglać komunikaty określonego typu). Co się stanie, jeśli wiadomość powinna dotrzeć do jednej osoby, ale jeśli nie jest ona dostępna / online, powinna trafić do innej osoby? AMQP radzi sobie z tym wszystkim (całkiem ładnie!), Z bardzo ładną kategoryzacją, kolejkami, kanałami, trwałą trwałością, wszelkiego rodzaju funkcjami.

Oto podstawowy przegląd scenariuszy, które może obsłużyć (pamiętaj, że nie jest to specyficzne dla RabbitMQ: to sprawa AMQP, ale RabbitMQ zdarza się to dobrze wyjaśnić) - https://www.rabbitmq.com/getstarted.html

Jleach
źródło
Wcześniej widziałem RabbitMQ zaimplementowany dla innego oprogramowania - zawsze wydawało się interesujące (jeśli nie trochę skomplikowane). Zajrzę do tego! Wydaje mi się, że początkowo się tego unikałem, ponieważ chciałem zapewnić dużą elastyczność oferowania nadawcom danych. Więc jeśli trudno byłoby zaimplementować wywołanie REST na istniejącym Powershell lub Javascript, lub też nie zabronić aplikacji VB6, zwykle mogą one dość łatwo wyprowadzić dane do płaskiego pliku. Ale możliwość zastąpienia większości obsługi wiadomości z pewnością skróciłaby czas i wysiłek!
Christopher
2
Byłem trochę onieśmielony, kiedy po raz pierwszy dostałem się do RabbitMQ, ale po weekendzie nauki było jak wow, to jest naprawdę bardzo, naprawdę miłe, a teraz, gdy rozumiem, na co patrzę, to jest naprawdę bardzo proste
Jleach
Podobał mi się pomysł AMQP, ale sposób, w jaki RabbitMQ obsługuje interfejsy API klienta dla każdego języka, nie udaje się, jeśli chodzi o użycie protokołu niezależnego od języka. Co się stanie, jeśli mam klienta z językiem, który nie ma napisanego obsługiwanego interfejsu API? Niektóre z tych funkcji są naprawdę fajne ... ale przesada, gdy wszystko, co muszę zrobić, to dostać 1 wiadomość z punktu A do punktu B, bez żadnych pośrednich.
Christopher
Zastanawiałem się nad dodaniem do niego interfejsu API szybkiego odpoczynku, który zaspokoiłby twoje obawy związane z agnostyką, ale zgodziłem się, że jeśli nigdy nie będziesz potrzebować żadnej funkcji oferowanej przez AMQP, byłoby to przesadą (przepraszam, gdybym uruchomił dziką grę goose
goase
Tak - szybki interfejs API REST na jego pokrycie działałby ... ale równie dobrze mógłbym po prostu stworzyć własny interfejs API REST. I nie wymaga przeprosin - jest to świetna technologia i nauka jest niezbędna do postępu :) jeśli nie teraz - jestem pewien, że przyda się w przyszłości.
Christopher
3

Bardzo dobrze sformułowane pytanie!

Wszystkie decyzje architektoniczne wiążą się z kompromisami. Jeśli jesteś zainteresowany dyskusją na temat kompromisów, może edytuj swoje pytanie w tym kierunku. Zamiast tego, ponieważ pytanie dotyczy tylko stanowiska, zajmę się argumentowaniem na korzyść MessageHandler. Pójdę o krok dalej, aby zasugerować NIE uwzględnianie bazy danych - przynajmniej nie bazy danych SQL, przynajmniej nie uruchamiać. Po prostu poproś, aby MessageHandler zapisał JSON w systemie plików, powiedz katalog na godzinę otrzymanych alertów (oczywiście w zależności od wolumenu) i posiadaj interfejs API, gdy zapyta go Menedżer alertów, po prostu przejrzyj ostatnie 2 katalogi alerty, aby zdecydować, które e-maile mają zostać dostarczone (oczywiście w zależności od priorytetu).

W tym problemie jest mnóstwo dobrych rzeczy do przeżuwania, a utrzymywanie bazy danych poza obrazem na wczesnych etapach usunie wiele przypadkowych szumów i niepotrzebnego rozwiązywania problemów. Oczywiście być może masz ukrytą miłość do tworzenia relacyjnych modeli danych i marzysz o pisaniu SQL. W takim przypadku odpowiedź jest całkowicie błędna. Ale ogólnie rzecz biorąc, nawet najbardziej zwinne bazy danych są okropnymi platformami aplikacji i są włączane tylko do systemów, ponieważ są specjalistami w zakresie trwałości i indeksowanych zapytań.

Powodzenia!

Jonah Benton
źródło
1
Po prostu podoba mi się możliwość kontrolowania grup e-mail, członków i różnych innych fajnych rzeczy związanych z używaniem relacyjnej bazy danych. Projekt bazy danych jest naprawdę tym, co zacząłem w projekcie - więc nawet nie pomyślałem o jego usunięciu. Dziękuję za ten wkład i punkt widzenia !!
Christopher
Wiedziałam! :) Najważniejsze jest zrozumienie, co tak naprawdę chcesz z czegoś wyciągnąć. Twoje zdrowie!
Jonah Benton