我的主要目标是避免在我可以预测我的服务将出现故障时将健康状态更新为“严重”的重大延迟。 我将其与已经进行的http运行状况检查相结合。
考虑的解决方案：
我尝试了TTL检查，但这带来了转换服务以不断发送其当前状态的负担。
我想到了使用ttl很高的TTL检查+在重新启动后发送一次“正常”的消息，但是如果此初始请求失败，服务将保持不正常状态的时间过长。
减少我的http健康检查的间隔可以稍微缓解该问题，但同时也会增加开销。
答案 0 :(得分：2)
如果您可以预测该服务将关闭，则应考虑将其置于维护模式。这会将其立即从DNS和API结果中删除。 Here is the link to the documentation，介绍如何将服务置于维护模式。
运行状况检查将始终有一个延迟，因为它们会定期执行，并旨在监视服务以防意外停机。如果您知道服务由于更新/升级/重启/停用而中断，最好的方法是对用户产生最小影响，那就是在对其进行任何工作之前将其删除。