google-app-engine - 指向“自动”的包罗万象的处理程序是一个坏主意吗?
问题描述
我的实例几乎没有流量,但我将最小空闲实例设置为 1。我注意到,每当访问不存在的随机 url(通过某个机器人)时,它被视为动态请求,因为我的全部处理程序是自动的。这很好,除了我看到这些 404 错误(404 是因为没有与这些 url 模式关联的 http 处理程序,即使 yaml 定义了 catch all 模式)导致实例重新启动。实例遇到 404 错误为什么要重启?
我的所有动态处理程序都遵循“/api”模式,然后一些不遵循。因此,我可以显式列出所有有效模式并将它们映射到自动处理程序。那么,是否会将这些随机链接视为静态但不存在并抛出 404 错误(我可以接受)?我想确保实例不会仅仅因为一些 rouge 请求而继续运行。
解决方案
我刚刚做了一个本地实验(我目前没有任何可快速部署的游戏应用程序),看起来你非常有趣的想法可以奏效。
我用特定的模式替换了.*
之前捕获所有落后者并将它们路由到我的默认服务脚本(我正在使用 python 运行时)的模式,然后在所有其他模式之后添加了这个处理程序:
- url: /(.*)$
static_files: images/\1
upload: images/.*
我的images
目录是真实的,包含静态图像(但我已经有另一个具有更具体模式的处理程序)。
有了这个,我提出了一个请求/crap
并得到了,正如预期的那样(没有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 运行时非常值得一试,这可以为应用程序节省一些重要的实例时间,而无需面对随机机器人流量的大量活动。
至于实例重启,我怀疑你看到的只是你的 min-idle 实例设置为 1 的症状。与动态实例不同,空闲(又名常驻)实例通常不意味着处理流量,它只是准备好了如果/需要时。只有当没有动态实例运行(并且能够有效地处理传入流量)并且有新请求进入时,该请求才会立即路由到空闲实例。那一刻:
- 空闲实例变为动态实例,并将继续为流量提供服务,直到它因不活动或死亡而关闭
- 一个新的空闲实例被启动以满足最小空闲配置,它将保持空闲直到另一个类似的事件发生
注意:您的想法将有助于动态实例使用的实例小时数部分,但不适用于空闲实例部分。
推荐阅读
- amazon-web-services - Ec2 实例拒绝自定义端口上的 TCP 请求
- mysql - JOIN 中的多个 ON 子句
- android - 使用 kotlin 从 android studio 项目中的 firebase Cloud Firestore 读取和显示数据
- c# - 如何从我的 c#asp.net mvc 应用程序在 azure 上动态创建子域。?
- docker - DBPedia 聚光灯泊坞窗返回 curl:(56)接收失败:对等方重置连接
- python - Robin-Stocks 不会安装在我的 Linux mint 系统上
- azure - 移动时缺少 Azure 资源组、cpu、dataio、logio
- lua - Lua 让树在 Roblox 上再生
- wordpress - 如何根据 get_permalink() 值的结果显示不同的内容
- mysql - sql:选择空值的问题