如何设计主动监控系统？
How to design a proactive monitoring system?
这是一个关于设计的模糊问题。我有执行订单管理的微服务。该服务协调从下达到交付的每个订单。中间发生了很多事情。假设这些是订单的状态。
- 放置
- 授权
- 已发货
- 已送达
我有一个弹性搜索仪表板，如果订单停留在特定状态并且没有继续前进，它可以可视化 - 这是一种反应式方法。我想设计一个监控子系统，它实际上监控系统中的每个订单是否正在配置的 SLA 内移动到下一个状态。
一般的想法是标记每个下达的订单，并让 cron worker 检查订单是否超过每个状态的配置 SLA。但是我认为，如果我们在一天之内下达 10 万个订单，那么它的扩展性就不会很好，cron 并不是设计此类系统的更好方法。
那么人们是如何解决这些设计问题的呢？欢迎指出任何现有方法/任何想法。
你提到了微服务，所以我认为在尊重微服务架构的同时，最“可扩展”的方式是以异步方式执行监控。如果您还没有，您可以设置一个消息队列服务，例如 Google PubSub 或 RabbitMQ。有许多具有特定功能和性能的不同消息队列服务，因此您需要进行一些研究以找到最适合您的用例的服务。
设置 MQ 服务后，您的订单微服务将发送一条消息，如 { orderId: 12345, status: 'Authorized', timestamp: 1610118449538, whatEver: 'foo' }。这样，这条消息就可以被注册到您的特定主题的任何服务使用（并且还取决于您的 MQ 的架构）。
然后我会开发另一个微服务：监控微服务。该微服务将注册到由 Order 微服务分派的主题。这样它就会知道任何订单状态的变化，你可以在你的微服务上设置 cron 来检查，即每 5 分钟检查哪些订单你没有收到关于他们状态变化的消息并相应地采取行动。该微服务可以与您的 ElasticSearch 通信。我还建议您尽可能多地共享管理业务逻辑的代码，这些代码与订单和监控微服务之间的订单状态变化有关。您可以使用私有 NPM 包。这样您就不太可能最终导致两个微服务之间的业务需求不匹配。
使用 MQ 服务允许您根据需要进行扩展，因为您随后可以水平扩展您的监控和订购微服务。不过，您需要在监控服务的不同实例之间处理某种 lock/semaphore 机制，这样您就不会通过多个实例处理同一消息。如果任何微服务关闭，您的队列将存储消息以防止数据丢失。一旦备份，他们就可以处理排队的消息。您还必须考虑如何处理 MQ 服务的停机时间。
这是一个关于设计的模糊问题。我有执行订单管理的微服务。该服务协调从下达到交付的每个订单。中间发生了很多事情。假设这些是订单的状态。
- 放置
- 授权
- 已发货
- 已送达
我有一个弹性搜索仪表板，如果订单停留在特定状态并且没有继续前进，它可以可视化 - 这是一种反应式方法。我想设计一个监控子系统，它实际上监控系统中的每个订单是否正在配置的 SLA 内移动到下一个状态。
一般的想法是标记每个下达的订单，并让 cron worker 检查订单是否超过每个状态的配置 SLA。但是我认为，如果我们在一天之内下达 10 万个订单，那么它的扩展性就不会很好，cron 并不是设计此类系统的更好方法。
那么人们是如何解决这些设计问题的呢？欢迎指出任何现有方法/任何想法。
你提到了微服务，所以我认为在尊重微服务架构的同时，最“可扩展”的方式是以异步方式执行监控。如果您还没有，您可以设置一个消息队列服务，例如 Google PubSub 或 RabbitMQ。有许多具有特定功能和性能的不同消息队列服务，因此您需要进行一些研究以找到最适合您的用例的服务。
设置 MQ 服务后，您的订单微服务将发送一条消息，如 { orderId: 12345, status: 'Authorized', timestamp: 1610118449538, whatEver: 'foo' }。这样，这条消息就可以被注册到您的特定主题的任何服务使用（并且还取决于您的 MQ 的架构）。
然后我会开发另一个微服务：监控微服务。该微服务将注册到由 Order 微服务分派的主题。这样它就会知道任何订单状态的变化，你可以在你的微服务上设置 cron 来检查，即每 5 分钟检查哪些订单你没有收到关于他们状态变化的消息并相应地采取行动。该微服务可以与您的 ElasticSearch 通信。我还建议您尽可能多地共享管理业务逻辑的代码，这些代码与订单和监控微服务之间的订单状态变化有关。您可以使用私有 NPM 包。这样您就不太可能最终导致两个微服务之间的业务需求不匹配。
使用 MQ 服务允许您根据需要进行扩展，因为您随后可以水平扩展您的监控和订购微服务。不过，您需要在监控服务的不同实例之间处理某种 lock/semaphore 机制，这样您就不会通过多个实例处理同一消息。如果任何微服务关闭，您的队列将存储消息以防止数据丢失。一旦备份，他们就可以处理排队的消息。您还必须考虑如何处理 MQ 服务的停机时间。