Architektura systemu alertów

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:

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.

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

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!