Google Cloud Run中@response.call_on_close调用Selenium报错问题

• Google Cloud Run默认开启CPU节流机制：仅在请求处理周期内分配CPU资源，接口返回响应、请求结束后CPU会被限制使用。@response.call_on_close装饰的逻辑执行时机在响应发送给客户端之后，此时Cloud Run已经回收了当前请求的可用资源，Selenium启动Chrome时无法分配足够资源生成devToolsActivePort文件，因此抛出对应错误。
• 你注释装饰器同步执行逻辑时，整个执行过程都在请求生命周期内，CPU资源充足，所以Selenium可以正常运行，和Selenium本身配置无关。

方案1：关闭Cloud Run CPU节流 #

部署Cloud Run服务时添加--cpu-no-throttling参数，开启「CPU始终分配」配置，允许响应返回后仍可使用CPU执行后续逻辑。
注意：开启该配置后服务会持续产生CPU计费，成本高于默认配置，仅适合低并发的场景使用。

方案2：改用异步任务队列替代call_on_close #

放弃使用@response.call_on_close实现异步逻辑，使用任务队列实现异步处理，是生产环境的推荐方案：

1. 接口收到请求后，先将需要处理的参数推送到任务队列
2. 直接返回响应给调用方
3. 由任务队列异步触发处理逻辑执行Selenium相关操作
   该方案完全适配Cloud Run的请求生命周期模型，不需要修改CPU分配配置，稳定性更高。

当前代码存在两处潜在问题，可提前修复避免额外报错：

1. 调用scrap(keyword, topic, tztimezone)时，topic变量未定义，会直接抛出变量不存在错误，需要补充对应参数的取值逻辑。
2. @app.after_request装饰的函数会对所有请求生效，包括返回405的GET请求，此时调用request.get_json()会返回空值，后续取keyword等字段会报错。建议将参数解析逻辑放到main路由函数中，通过Flask的g全局对象传递参数到after_request中使用。

内容的提问来源于stack exchange，提问作者damiantaubaso