在某些情况下，我们有大量的Spring Boot应用程序运行在容器中（在OpenShift上），这些容器可以访问集中式基础结构（在pod外部），例如数据库，队列等。
如果某个中央基础架构发生故障，则运行状况检查将返回“不正常”（理应如此）。问题在于，活动性检查会看到此情况，然后重新启动Pod（就绪性检查之后还会看到其崩溃，因此不会启动应用程序）。如果只有少数几个可用，这很好，但是如果许多（可能是数百个）应用程序正在使用它，则将强制所有应用程序重新启动（崩溃循环）。
我知道中央基础架构崩溃是一件坏事。它“应该”永远不会发生。但是...如果这样做（墨菲定律），它将使容器陷入疯狂。看起来我们要么做错了什么，要么应该重新配置某些东西。
几个问题：
答案 0 :(得分：1)
在Spring Boot Pod中使用执行器检查活动性/就绪状态是检查健康应用程序的实际方法。理想情况下，应用程序一旦启动，如果中央部分（例如DB或队列服务）发生故障，则应用程序不应停机或运行不正常，理想情况下，您应添加某种弹性，该弹性可连接到备用DR站点或等待特定时间中心服务恢复正常，应用重新连接的时间。这更多是由于后端方面的技术故障，导致您的应用程序在完全启动后无法正常运行。
是的，既需要活跃又要准备就绪，因为它们都有不同的用途。阅读this
在我以前的一个项目中，用于准备状态的设置大约是30秒，而活跃度大约是90，但是说实话，这完全取决于您的应用程序，如果您的应用程序需要1分钟才能启动，是您的准备时间应该在处配置的时间，并且您的活跃度应该与后端服务的故障转移切换所需的时间一样。
希望这会有所帮助。