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