# 异步任务场景使用指南

服务常识中有一条描述：

代码中请不要在请求处理程序范围之外启动后台线程或例程，并确保在传送响应之前完成所有异步操作。

有很多开发者不太理解为什么这么建议，如果有异步任务的情况下，应该如何使用才正确呢？本文就来给大家详细解读一下

# 请不要在请求处理程序范围之外启动后台线程或例程

这是一条建议，比如说，你的一个HTTP服务，在收到一个接口后，直接调用sh命令，做系统层面的动作。如系统文件更新，指向，重启等，这都是不建议的，会引发不稳定导致回收。

请不要将云托管服务的实例当成自己的开发调试机器，进行无规程运算，挖矿，阵列控制等不是以应用服务为目的的操作。如果有相关的需要请直接去云厂商购买CVM服务器。

云托管服务目的是提供「小程序/公众号H5/WEB/APP」等应用的资源分发和后端服务，整个形态是经过特殊包装的，不要将其理解成CVM服务器，虽然你可以进行绝大部分的系统操作，但是你无法控制实例服务的重启，新增，销毁，这些权限都是由云托管集群自己控制的。

我们举一个例子帮助理解。

当你的服务最小实例为0（低成本模式），你触发执行一个异步任务，时间达2小时。

这个时间段中如果没有任何访问请求的话，半小时就直接缩容到0了，所以要保证实例不会回收，你需要半小时内触发更新的实例的时间，一直到你的异步任务执行完毕。

当你设置的最小实例等于1（高可用模式），当前确实只有1个实例正在运行，而你的异步任务刚好在这唯一的容器里执行，你无需半小时触发，他一直存在。

但是当你的业务出现高峰，有2个甚至更多实例存在，这时候如果有异步任务2小时，但你2小时内的流量访问不足以支撑2个或多个容器提供服务，那就会缩容到1（你设置的最小实例），你的异步任务如果刚好在缩容的那个容器中，就会夭折。

因为云托管的服务是根据你的流量请求以及你的设置，持续扩缩容，弹性的变化实例数量提供服务。所以这种情况下，你必须约束任务，或者是通过守护请求来支撑住，这个过程需要你自己根据业务需要操作，总体而言需要有比较强的基础和理解能力才能保证顺利。

这也是为什么我们建议尽量在请求响应前完成异步操作的原因。当然你也可以理解上述扩缩容逻辑，来设定异步执行。

以下是一个真实的例子，场景是：每天凌晨开始数据迁移任务，时长大概在3小时。

使用的云函数定时触发器，在凌晨前先将迁移服务拉起来（冷启动1分钟），然后执行异步任务。

在这个过程中，防止容器缩容，每15分钟发起请求，保持活跃。

最终到5点半结束请求，迁移服务半小时后自动缩容。

这里需要注意的是，你的服务规格配置需要满足异步任务的运行要求，不要因为内存/CPU达到扩容条件而产生多个实例。设置内存/CPU条件大于95%，降低因为突刺导致的扩容概率。