告警系统体系结构

Question

我想创建一个系统，它可以处理来自各种程序的警报信息，并可以通过电子邮件处理这些警告给顺风的消费者。所有这些都将通过一个内部网络加以控制。

我想我希望基本架构看起来像这样：

我目前关心的主要问题是"Message“位，这就是我的”类API“。我希望这个系统的所有组件将数据发送到API，API处理对数据库的所有写入。我认为这种方法更容易，因为它简化了安全性，并允许我将许多更复杂的DB查询包含到一个程序中。

关注的是，我希望这是语言不可知论-意味着任何代码都应该能够发送消息给我的Handler -它将解释它们。我希望通过JSON平面文件-或通过对程序的REST调用(给下游应用程序灵活性)来实现这一点。

我的问题是-

我应该使用消息处理程序吗?还是只允许数据库直接访问下游应用程序以及另外两个组件(管理控制台和警报管理器)，这会增加简单性吗？

这样，只要插入到DB表/S是有效的，他们就可以插入他们想要的任何警报。

我不是一个专业的软件设计师，所以请原谅-我只是想在我的空闲时间做一个项目。

Answer 1

您看过AMQP (高级消息队列协议：https://www.rabbitmq.com/protocol.html)吗？

我认为，RabbitMQ是这样的一个很棒的工具(还有其他工具，MSMQ、Azure/AWS服务等等)。您不仅获得了一个与语言无关的消息处理程序(简单的“将消息发送到消息服务器w/ json数据”)，还分离了下游消息处理，并使其完全隔离。运行消息服务，该服务处理来自所需队列(S)的传入消息，并发出通知。

我非常喜欢使用AMQP的原因之一是，您一开始就像现在一样拥有一些家常便饭的解决方案，但是经过一段时间之后，您会意识到，您需要根据不同的类型、需要向谁发送的消息来稍微不同地处理消息，等等，所以您最终还是构建了自己的AMQP实现。

如果一条消息需要发送给5个不同的收件人，您会做什么？如果您有一条消息应该在多个处理器中旋转(考虑长时间运行的任务，同时有X个处理器，在其中可以循环特定类型的消息)，该怎么办？如果消息应该传递给一个人，但如果他们不能在线，那么信息应该发给另一个人呢？AMQP处理了所有这些(非常好！)已经有了非常好的分类，队列，通道，持久的持久性，各种各样的特性。

下面是它可以处理的场景的基本概述(注意，这并不是RabbitMQ特有的:这是一个AMQP问题，但RabbitMQ恰好很好地解释了它)- https://www.rabbitmq.com/getstarted.html

Answer 2

结构很好的问题！

因此，所有的架构决策都涉及权衡。如果你对权衡的讨论很好奇，也许可以朝这个方向修改你的问题。相反，既然这个问题只是要求一个立场，我会站在支持MessageHandler的立场上。我将进一步建议不包括数据库--至少不是SQL数据库，至少不要开始。只需让MessageHandler将JSON保存到文件系统，比如接收到的警报的目录--每小时一个目录(当然，这取决于音量)，当警报管理器查询时，让API遍历过去的两个警报目录，以决定发送哪些电子邮件(当然，这取决于优先级)。

在这个问题上有大量的好东西要考虑，并且在早期阶段保持一个数据库，将消除许多杂乱无章和不必要的问题解决。当然，您可能对创建关系数据模型和编写SQL的梦想有着隐藏的爱好。在这种情况下，这个答案是完全错误的。但是一般来说，即使是最敏捷的数据库也是糟糕的应用程序平台，它们只会被包含在系统中，因为它们是耐用性和索引查询方面的专家。

祝好运!