背景
函数计算是一个事件驱动的全托管 serverless 计算服务。使用函数计算构建应用，用户只需要专注于实现应用层的逻辑实现；服务器等基础设施的容错、伸缩以及运维工作由平台来完成。因此用户能在很短的时间内实现弹性高可用的云原生应用。
函数计算在容器中执行用户函数代码，这样的环境我们称为函数实例。实例的生成需要一些额外的系统准备工作，比如选择执行函数的引擎，下载用户的代码，启动容器，加载函数等等。如果请求的调用链路里包含了上述环节，我们就称之为冷启动。实例一旦生成，会持续服务请求；当一段时间内没有请求后，系统将回收实例。因此，冷启动通常发生在函数首次调用或者负载升高需要更多的实例来处理对应的请求。
"冷启动"对于毛刺敏感的业务会显得不那么友好，所以冷启动的优化对于函数计算在延时敏感型场景中的应用尤为重要。
系统冷启动简介
在探讨调度优化之前，我们先简要介绍一下函数实例系统冷启动的概念。
为了保证用户业务逻辑运行时使用的资源，一个函数实例只能同时服务一个请求，所以在用户请求并发较大的情况下，系统会自动弹性伸缩调度更多的资源来创建函数实例，消费该用户的请求。
而函数实例创建的过程，就是系统层的“冷启动”。系统层的"冷启动"就是从函数执行引擎的获取到函数实例创建的整个过程，主要的步骤如下:
而冷启动的快慢受限于很多情况，主要因素有用户代码大小、网络因素、runtime 环境因素等，所以，对于实时性要求高的业务场景来说，冷启动的存在是不友好的。
调优策略
冷启动问题导致了大量并发到来的时候，毛刺加剧，根源在现存的实例调度方式无法快速响应请求而引起请求在整条链路中长时间处于系统新资源的分配等待中。
所以，要提高实例调度速率、快速响应请求，减少排队请求数，主要着手于如下两个方面:
- 加快空闲实例投入使用，提高利用率；
- 在峰值到来时，加快新实例生成，增加实例储备。
加快空闲实例投入使用速率这一点，能很大程度上减少请求在链路上等待冷启动的时间，从而加快请求被处理的速率。在用户函数逻辑执行较快的情况下，实例能够被快速释放，如果此时一个正在等待冷启动的请求能够探测到已经有实例进入空闲状态，那么就会被处理。而之前的冷启动则转入后台继续进行，生成新的实例，增大实例储备，应对更多的请求处理。
另外一方面，因为用户的资源配额在系统层面有限制，比如在超大并发的请求下用户可能会遇到 ServiceUnavailable 错误。而调度策略上如果能够加快空闲实例投入使用的速率，那么实际上也减少了冷启动的次数，即减少了对资源配额的开销，增加资源利用率，从而减少了被系统流控的可能。
调优结果
根据用户实际使用场景，我们设计如下两种测试case来验证调优效果:
- 负载持续增加模式
- 波峰 burst 模式
测试函数的特性如下:
- 函数自身逻辑运行时间为 100ms;
- 函数代码包大小为 50MB;
- runtime 为 python2.7;
- Memory 为 3GB 。
这样的函数，如果带有冷启动，单次端到端的请求 latency 在 1.7s - 3s，不带冷启动的请求端到端 latency 在 105 - 120ms。
负载持续增加模式
该模式下，用户的请求在一段时间内会持续增长。设计请求行为如下:
- 每波请求并发数翻倍递增: 1, 2, 4, 8, 16, 32;
- 每波请求的时间间隔为 10s。
TPS情况如下，增长率为100%：
优化前后对比
10s 聚合的 latency 指标如下监控:
优化前, 平均 latency 在 1000ms 左右，而99%的请求 latency 均在 1.8s 以上。
优化后，平均 latency 为 200ms 以下(排除第一个完全冷启动)，99% 的请求 latency 大部分在 200ms 左右，较之前下降一个数量级。
单个请求情况分析
更直观的分析，我们把每一个请求的端到端 latency列出来比较，如下图。每一波请求中，都有一半的请求能够直接使用前一波请求现存下来的实例，而另一半请求都需要等待新的调度。明显看到，旧的调度策略上，这一半请求几乎全部都在傻傻等待处于完全冷启动状态；新的调度策略中，明显看到这一半请求都被调度到了提前释放的实例上被处理，从而大大优化了毛刺情况。
优化前:
优化后:
波峰 burst 模式
波峰burst模式是指用户请求比较平稳，但是会有突然的波峰流量场景。设计请求行为如下：
- 每波请求时间间隔 10s;
- 每波平稳请求数 2;
- burst 请求数 20;
TPS请求如下，burst 流量猛增 10 倍:
优化前后对比
10s 聚合的 latency 指标如下监控:
对比99%的请求 latency，毛刺下降了整整一倍多。
优化前
优化后
单个请求情况分析
按处理顺序，我们罗列出优化前和优化后处于 burst 时期 20 个请求的每一个 latency 的情况，如下表。不难发现，除了最前面的两个请求直接使用了现存的 2 个实例，其他请求全部都是需要等待调度的。优化前，所有的请求都在完全等待冷启动；而优化后，不难发现，每两个请求的 latency 处于相同的水平，而前后两组之间相差 100ms (正好是函数执行时间)，从而说明新的调度方式有效的复用了已有的"热"的容器。
| 请求序列(按执行顺序) | 优化前 latency(ms) | 优化后 latency(ms) |
|---|---|---|
| 1 | 113.45 | 112.93 |
| 2 | 116.45 | 116.20 |
| 3 | 1933.43 | 179.26 |
| 4 | 1941.58 | 174.65 |
| 5 | 1783.99 | 275.03 |
| 6 | 2049.12 | 279.75 |
| 7 | 1938.68 | 377.43 |
| 8 | 2041.51 | 382.53 |
| 9 | 2961.99 | 481.34 |
| 10 | 1919.09 | 485.56 |
| 11 | 1968.41 | 581.29 |
| 12 | 1921.32 | 588.19 |
| 13 | 1927.44 | 684.82 |
| 14 | 1965.75 | 695.01 |
| 15 | 1997.35 | 788.08 |
| 16 | 2086.58 | 798.03 |
| 17 | 1955.57 | 890.27 |
| 18 | 1899.22 | 900.41 |
| 19 | 1941.02 | 955.13 |
| 20 | 1988.23 | 1348.59 |
实际在线用户请求优化结果
对在线某一用户的实时流量跟进分析，看到优化前后明显对比，如下图所示。优化前 TPS 在某一时间点从 11 上升到25，此时 99% 的 latency 出现一个明显的毛刺现象。在2个小时之后，优化开关打开，某一时间点 TPS 达到了 32，此时 latency 无明显波动。
总结
综上数据分析，在典型的负载变化情况下，冷启动对 99% 的请求 latency 的影响已经忽略不计，本次调度上的调优大大改善了函数计算在延时敏感场景下的表现。
未来调度优化
下一步调度优化工作正在紧锣密鼓进行中，先不剧透，敬请期待！
