【问题标题】:How to design a proactive monitoring system?如何设计主动监控系统?
【发布时间】:2021-01-08 14:31:15
【问题描述】:

这是一个关于设计的模糊问题。我有执行订单管理的微服务。该服务协调从已下达到已交付的每个订单。中间发生了很多事情。假设这些是订单的状态。

  1. 已放置
  2. 授权
  3. 已发货
  4. 已交付

我有一个弹性搜索仪表板,它可以可视化订单是否停留在特定状态并且没有前进 - 这是一种反应性方法。我想设计一个监控子系统,它实际上监控系统中的每个订单都在配置的 SLA 中移动到下一个状态。

一般的想法是标记每个下达的订单并让 cron 工作人员检查订单是否超过了为每个状态配置的 SLA。但我认为,如果我们在一天内下达 10 万份订单,这将无法很好地扩展,cron 并不是设计此类系统的更好方法。

那么人们是如何解决这些设计问题的呢?欢迎指出任何现有方法/任何想法。

【问题讨论】:

  • 我认为即使每分钟(可能是几秒钟)扫描所有 100k 订单也不会有问题。
  • 并且您只需要重新检查您知道已通过的那些(例如,那些明天到期的显然不会在今天过期)。这大约是每秒 2 个项目,几乎没有问题。
  • 但是@appleapple 大部分操作都在 1 小时内到期。
  • 那您要监控的东西少了?好:)
  • (因为大多数工作都会结束)

标签: javascript node.js design-patterns statistics monitoring


【解决方案1】:

您提到了微服务,所以我认为在尊重微服务架构的同时,最“可扩展”的方式应该是以异步方式执行监控。如果您还没有,您可以设置消息队列服务,例如 Google PubSub 或 RabbitMQ。有很多不同的消息队列服务具有特定的功能和性能,因此您需要进行一些研究以找到最适合您的用例的服务。

一旦您设置了 MQ 服务,您的 Order 微服务将发送一条消息,例如 { orderId: 12345, status: 'Authorized', timestamp: 1610118449538, whatEver: 'foo' }。这样,注册到您的特定主题的任何服务都可以使用此消息(并且还取决于您的 MQ 的架构)。

然后我会开发另一个微服务:监控微服务。该微服务将注册到由 Order 微服务分派的主题。这样它就会知道任何订单状态的变化,你可以在你的微服务上设置 crons 来检查,即每 5 分钟你没有收到关于它们状态变化的消息的订单并采取相应的行动。该微服务可以与您的 ElasticSearch 进行通信。我还建议您尽可能多地将管理关于订单和监控微服务之间订单状态更改的业务逻辑的代码相互化。你可以使用私有 NPM 包。这样您就不太可能最终导致两个微服务之间的业务需求不匹配。

使用 MQ 服务可以根据需要进行扩展,因为您可以水平扩展 Monitoring 和 Order 微服务。您需要在监控服务的不同实例之间处理某种锁定/信号量机制,这样您就不会通过多个实例处理相同的消息。如果任何微服务关闭,您的队列将存储消息以防止数据丢失。一旦备份,他们就可以处理排队的消息。您还必须考虑如何处理 MQ 服务的停机时间。

【讨论】:

    猜你喜欢
    • 2017-08-24
    • 1970-01-01
    • 2011-09-05
    • 2021-03-02
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2019-12-10
    相关资源
    最近更新 更多