开发者学堂课程【如何通过 Knative 轻松实现应用 Serverless 化交付： Knative 冷启动（一）】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/291/detail/3433
Knative 冷启动（一）
内容介绍
一.前言
二.什么是冷启动
三.当前冷启动中存在的问题。
四.如何解决冷启动存在问题。
五.实例演示
六.总结
一、 前言
Knative 提供通用的编排调度服务，提供面向应用层的操作，保证 Knative 生态链的完美融和。
Knative 与云的结合，介绍了 issay 网关，Knative 默认支持多种 gateway 的实现。
但是这些常驻网关实际的 issay 费用和运维都是需要支付额外的成本，为了给用户提供极致的体验。我们通过阿里云实现了 connective gateway，不需要常驻示例，不但节省了 issay 成本，还省去了很多运维的负担。
另外我们也介绍了一个保留实例，保留实例是 SK connective 独有的功能，社区的 connective 默认在没有流量的情况下可以送入到0，但是送到0之后，0~1的启动问题很难解决。issay connective 对这个问题的解法是通过低价格的保留实例，来平衡成本和人情的问题。
二、什么是冷启动
Serverles 核心是按需使用，在请求到来时才运营服务，这就意味着当没有请求的时候，服务会进入休眠状态。当下次请求过来的时候，服务需要一个启动时间，也就是冷启动。
从这个图表也可以很直观的看一下，首先随着请求的逐渐减少，资源也在使用上逐渐在减少，当请求为0的时候，进入一种休眠状态，这时候是不需要任何资源的。当有请求进来的时候，会接收请求之后进行扩容，等第一个资源准备好之后，才开始真正的去处理服务。
在这个从接收请求到第一个资源的过程中准备，称为一个冷启动的一个事件。
connective 中如何实现从0~1的冷启动机制。
这里面包括几个关键的一些组件，ingress gateway 是请求入库网关的角色，请求发送给 activator，activator 进入到0~1的请求，然后把请求的数据通知给autoscaler 接收到请求数据之后，计算需要扩容多少 pod ，然后相应的修改development 的数量，创建相应相应请求的 pod ,在这个过程中，activator 会不断的轮巡探测，pod 是不是 ready,一旦 pod ready，将请求转发到已经 ready 的 pod 中，这个过程就完成了0~1的启动过程，后续的请求直接通过 ingress gateway 转发到相应的业务上。
所以整个流程下来，activator 其实就扮演了一个冷启动的角色，他接收流量请求，然后同时 autoscaler 进行扩容，最后当 pod ready 之后将流量转发到相应的 pod 上面。
三、当前冷启动中存在的问题。
Knative 中 Serverles 在没有流量情况下会送到0，传统应用在流量低谷的时候，即使没有业务请求处理，实例数还是会保持不变，这其实是资源浪费的，但优点就是随时过来的请求都可以及时响应。而如果到0第一个请求到达以后，才会触发扩容的过程。Knative 的模型，从0~1扩容需要4个步骤，串行处理，这4个步骤完成之后才会响应第一个请求。
此外，资源的分配，的调度，拉近相应的应用启动市场，综合这些因素往往会导致第一个请求想超时，所以 Knative 送到0虽然降低了常驻资源的成本，但第一批冷启动问题也比较明显。
这个图也可以很直观的看到，当请求到达 gateway 的位置后，会转到 activator，activator 会将信息发送到 autoscaler，通知相应的获得进行扩容完成之后，然后activator 才会把流量转换过滤，整个过程链路还是比较长的，并且带来了响应，延迟的一情况。另外 pod 本身启动也是耗时较差的。
四、如何解决冷启动存在问题。
可以先了解一下阿里云的突发性能实例。阿里云中有很多规格，不同规格的计算能力不一样，价格也不一样。
如图所示是对2c4G的配置的计算型是内核突发型实例的一个价格对比。通过上图可知突发性能实例比计算型便宜 46%，可见如果在没有流量时，使用突发性能实例提供服务不单单解决了冷启动的问题，还能节省很多成本。
突发性能实例除了价格优势以外，还有一个非常亮眼的功能就是 CPU 积分。突发性能实例可以利用 CPU 积分应对突发性能需求。突发性能实例可以持续获得 CPU 积分，在性能无法满足负载要求时，可以通过消耗积累的 CPU 积分无缝提高计算性能，不会影响部署在实例上的环境和应用。通过 CPU 积分，您可以从整体业务角度分配计算资源，将业务平峰期剩余的计算能力无缝转移到高峰期使用。
那么为了解决0~1的冷启动问题，推出了保留实例的能力，保留实例是阿里云容器服独有的功能，在没有流量的情况下送到0，但是送到0之后，从0~1的能行的问题很难解决。应用启动时长从毫秒到分钟都是有的。应用启动的这些时间完全也是业务行为在底层平台是无法控制的。
connective 对这个问题的解法就是通过低价格的保留实例来平衡成本和冷清的问题。当第一个请求来临时无缝迁移到侵犯到标准的计算器实例，这样可以帮助降低流量低估值等成本，并且在低谷的时候获得 CPU 积分，还能在高峰的时候消耗掉。
另外使用突发型势力作为保留实例只是一个默认策略，可以通过指定其他实例作为一个保留实例的规格。当然如果进行一个标准的实例，也就可以关闭保留实例的功能。从图中也可以很直观的看到，随着业务量的降低，会逐渐缩容，在没有业务量的时候，并没有把它缩容到0，而缩容到了一个保留实例。
通过第一时间通过保留实例，响应业务实际业务的请求，同时会扩容正常的实例出来。当正常的实例扩容出来，ready 之后，就是无缝下线掉保留了实例，从而解决一个冷启动的问题。可以概括为两点，首先是免冷启动，通过保留实例消除了0~130秒冷启动的时间，另外成本可控，突发性性能实例的成本标准性实例将近45%的降低，如果通过实例，还能做一进一步的成本降低。
