我正在 Google Cloud Run 中运行 PHP (8.1) 后端应用程序。后端连接到在 Google Cloud SQL 中运行的 MYSQL 数据库。
在过去的两周里,我们发生了三次完全中断的情况。后端服务器不响应任何请求,导致我们的应用程序和网站完全关闭。
在第一次发生这种情况之前,服务器已经运行了好几个月,没有出现任何类似问题。我首先怀疑这与后端或数据库的某些规格有关,但查看图表,我看不出任何明显的原因说明为什么它应该全部下降。
Notice how the traffic goes down every night, but is still spiky, before it went completely flat around 4PM today:
然后,我查看了 Cloud Run 服务器的统计数据,以查找其中的任何迹象。我们正在以相对较高的规格和灵活的容器实例大小运行,因此这不应该引起任何这样的麻烦。容器内存和CPU利用率突然下降。在服务决定终止之前似乎没有发生任何异常活动。
我们的 Sentry 仪表板显示在停机时间段内没有捕获任何事件。
然而,在 Google Cloud Logs Explorer 中查看后端服务的日志,在这个时间间隔内似乎有 200 个响应堆。通过查看日志,我没有看到任何迹象表明有什么问题。
我唯一能想到的解决这个问题的办法就是在 Google Cloud Run 中重新部署服务,有效地启动一个具有完全相同代码和规格的新容器。然后它又开始工作了,从那以后一直在工作,但我不知道发生了什么。
据我所知,我们没有任何可能导致此类问题的代码或配置相关更改。
有人有想法吗?我唯一能想到的是某种突然失控的内存泄漏。但我认为应该能够以某种方式追溯到。如果是这样的话,我也认为在很长一段时间内这种情况应该发生得更频繁。很长一段时间运行不佳,然后在两周内下降了 3 次。
任何帮助或指示将不胜感激!
此错误可能是由 Cloud Run 网络基础架构内的预期内部行为引起的。有时,此网络基础设施确实会进行维护,这可能会导致某些连接关闭。由于 Cloud Run 的运行状况检查不依赖于网络,因此这可能会导致容器卡住并无法与服务器通信。某些 Cloud Run 应用程序也对这种网络连接中断很敏感。由于您能够重新部署 Cloud Run 容器,因此您能够“取消粘连”该容器,并且它能够按预期运行。
推荐的解决方法和实践是在服务代码中实现重试逻辑。这将使 Cloud Run 服务能够在网络连接断开时重新连接到服务器。
您有一个向您的 Cloud Run 服务发出请求的网站。
Cloud Run 服务刚刚停止服务/响应任何请求。
这也反映在 Cloud SQL 中,因为 Cloud Run 服务连接到 Cloud SQL,因此对 Cloud Run 的请求的减少反映在 Cloud SQL 使用情况中。
如果这是正确的,那么重试逻辑应该位于前端。目的是重试从您的网站(前端)到 Cloud Run 服务(后端)的请求。
不同的框架提供不同的资源来实现重试逻辑。这里有一个有关重试逻辑的 Google Cloud 文档 https://cloud.google.com/iot/docs/how-tos/exponential-backoff#example_algorithm.
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)