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

一旦您设置了MQ服务，您的Order微服务将发送一条消息，如。这样，注册到特定主题的任何服务都可以使用该消息（也取决于MQ的体系结构）。

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

使用MQ服务允许您根据需要进行扩展，因为您可以水平地扩展您的监视和订购微服务。但是，您需要在监视服务的不同实例之间处理某种锁定/信号量机制，因此您不会由多个实例处理相同的消息。在任何微服务关闭的情况下，您的队列将存储消息，以防止数据丢失。一旦备份，它们就可以处理排队的消息。您还必须考虑如何处理MQ服务的停机时间。