指向"auto“的catch-all处理程序是个坏主意吗？

Question

我的实例几乎没有流量，但我有一个最小空闲实例设置为1。我注意到的是，每当有一个不存在的随机url (通过某个bot)被访问时，它就被认为是一个动态请求，因为我的catch all处理程序是auto。这很好，除非我看到这404个错误(404是因为没有与这些url模式相关联的http处理程序，尽管yaml定义了一个catch all模式)，从而导致实例重启。如果实例运行到404错误，为什么要重启实例？

我让我所有的动态处理程序都遵循"/api“模式，还有一些不遵循，所以我可以显式地列出所有有效的模式，并将它们映射到自动处理程序。这会不会认为这些随机链接是静态的，而不是存在的，并抛出404错误(我对此没有意见)？我希望确保实例不会仅仅因为一些rouge请求而继续运行。

Answer 1

我刚刚做了一个本地实验(我目前还没有任何可快速部署的play应用程序)，看起来你非常有趣的想法可以奏效。

我用特定的模式替换了之前捕获所有落后者的.*模式，并将它们路由到我的默认服务脚本(我使用的是python运行时)，然后在所有其他处理程序之后添加此处理程序：

- url: /(.*)$
  static_files: images/\1
  upload: images/.*

我的images目录是真实的，包含静态图像(但是我已经有了另一个具有更具体模式的处理程序)。

准备就绪后，我像预期的那样向/crap和got发出了一个请求(没有images/crap文件)：

INFO 2019-11-08 03:06:02,463 module.py:861]默认值："GET /crap HTTP/1.1“404 -

我在脚本处理程序的get()和dispatch()调用中添加了日志记录调用，以确认它们实际上没有被调用(开发服务器请求日志记录引起了一些疑问)。

我还检查了一个已经部署的GAE应用程序，它请求一个与静态处理程序模式匹配的镜像，但实际上并不存在，它会获得404应答，而不会导致服务的实例启动(当时没有实例在运行)，也就是说，它直接来自GAE的静态内容CDN。

因此，我认为go运行时值得一试，这可以为应用程序节省一些重要的实例时间，而无需面对随机的机器人流量。

至于实例重启，我怀疑你看到的只是你的最小空闲实例设置为1的症状。与动态实例不同，空闲(又称常驻)实例通常不是用来处理流量的，它只是准备在需要时处理流量。只有当没有动态实例在运行(并且能够有效地处理传入流量)，并且有新的请求进入时，该请求才会立即路由到空闲实例。在那一刻：

• 空闲实例变为动态实例，并将继续为流量提供服务，直到它因不活动而关闭或死亡
• 启动新的空闲实例以满足最小空闲配置，它将保持空闲，直到发生另一个类似事件

注意:您的想法将有助于动态实例使用的实例小时数部分，但不能用于空闲实例部分。

Answer 2

根据引用以下内容的文档：

“当实例响应HTTP状态码为200-299或404的/_ah/ restart请求时，表示实例已正确启动，可以处理额外的请求。否则，App Engine会取消该实例。手动调整规模的实例会立即重启，而调整基本规模的实例仅会在需要投递流量时重启。”

有关如何为Go 1.12的标准应用程序引擎环境管理实例的更多详细信息，请访问链接：https://cloud.google.com/appengine/docs/standard/go112/how-instances-are-managed

同样，我建议您阅读文档“实例是如何管理的”，其中引用了以下内容：

辅助路由如果请求与部分YOUR_PROJECT_ID.appspot.comof主机名匹配，但包含不存在的服务、版本或实例的名称，则默认路由该服务。辅助路由不适用于自定义域；如果主机名无效，则发送到这些域的请求将显示HTTP状态代码404。

https://cloud.google.com/appengine/docs/standard/go112/how-instances-are-managed