我們的項目托管在 OpenShift 中（準確地說，OKD。我們自己托管）。設(shè)置如下：路由服務(wù)器（帶有 Zuul 的 Spring Boot 1.5.8）：該服務(wù)器獲取所有傳入流量并將其路由到正確的服務(wù)多個服務(wù)（全部使用 Spring Boot）：這是所有業(yè)務(wù)邏輯我們在這個項目中使用 SOAP 來調(diào)用其他服務(wù)。目前，當我們調(diào)用應(yīng)用程序時，調(diào)用會轉(zhuǎn)到路由服務(wù)器，然后路由服務(wù)器將其路由到主要業(yè)務(wù)服務(wù)。經(jīng)過大約一小時的短暫不活動后，我們的主要業(yè)務(wù)服務(wù)無法通過外部呼叫訪問。然而，邊緣服務(wù)器在 100% 的時間內(nèi)可用且可調(diào)用。當我們調(diào)用它時，我們確實會504 Gateway Timeout從系統(tǒng)中得到一個異常。我們已經(jīng)算出這是openshift中的路由超時（haproxy.router.openshift.io/timeout在路由中）。核心問題是，OpenShift 似乎在閑置約一小時后休眠了主要業(yè)務(wù)服務(wù)。然而，在 15 分鐘的延遲后，呼叫似乎找到了目的地，并且數(shù)據(jù)得到了正確的處理。我們怎樣才能關(guān)閉這種行為？編輯1：我們在生產(chǎn)中的普通“老式”虛擬機中也有相同的應(yīng)用程序。我們在那里沒有任何問題。我們注意到，當我們定期調(diào)用服務(wù)時，它們可以“保持活動狀態(tài)”。我們構(gòu)建了一個定期調(diào)用主題的小型服務(wù)（每 15 分鐘一次）。這樣看來是可行的。但這不是一個可用于生產(chǎn)的解決方法。編輯2：我們的 pod 配置（有些名稱是匿名的）：https://gist.github.com/moritzluedtke/6867499b0acbb2d7b5a9a70e49b0d45c我們不使用自動縮放器。編輯3：我們的部署配置（有些名稱是匿名的）：https://gist.github.com/moritzluedtke/dc7c1078fe9cc7e4aeb737094849fc1bOpenShift Master:      v3.11.0+1c3e643-87 Kubernetes Master:     v1.11.0+d4cacc0 OpenShift Web Console: v3.11.0+ea42280編輯4：看來這不是 OpenShift 的問題，而是我們的技術(shù)堆棧的問題。一旦我們有解決方案，我會更新這個問題。