开发者学堂课程【通过 Knative 轻松实现应用 Serverless 化交付：Knative 极致 Serverless 体验】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/753/detail/13226
Knative 极致 Serverless 体验
主要内容
七、Knative Serving 架构
八、平台成本和负责度
九、Gateway 和云的融合
十、管控组件下沉
十一、优雅的保留实例
十二、动手实践
十三、总结
七、Knative Serving 架构
Service
对应用 Serverless 编排的抽象，通过 Service 管理应用的生命周期
Configuration
当前期望状态的配置。每次更新 Service 就会更新 Configuration
Revision
Service 的每次更新都会创建一个快照，一个快照就是一个 Revision
Route
将请求路由到 Revision ,并可以向不同的 Revision 转发不同比例的流量
Serving 的核心是 Knative Service，通过 servive 配置，自动操作 Configuration service 和 deployment，从而实现简化应用管理的目标。另外 Configuration service 定义了 Configuration 资源，每次 service 变化如果要创建就进行更新Configuration。每次 Configuration 更新都会创建唯一的 revision，revision 可以认为是一个版本管理机制，理论上 revision 创建之后是不需要修改的。Route 主要负责 Knative 的流量管理，通过 route 配置自动生成两种配置，所有编排是通过流量配置的，流量首先到达 knative，根据 route 的配置，自动把流量转化为不同比例的流量。每一个 revision 都有独立的弹性策略当流量需求变多的时候。当前的revision 进行扩容，每个 revision 的策略都是独立的，相互不影响，基于流量百分比对不同的 revision 进行灰度，knative serving 通过对流量的控制，实现了流量管理、弹性和灰度的完美结合。以上是 knative serving 核心模块介绍。在介绍原来的过程中，可以感受到 knative 用起来用了很多的 controllwe 和 gateway 组件，做到这些使用，运维成本是必须要考虑的。
八、平台成本和负责度
gateway 组件使用的 Istio 实现的话，Istio 本身就需要很多个 controller，如果要做高可用，可能需要更多的 controller，knative service controller 如果完全高可用输出，也是需要十几个。这些 controller 的成本都比较高。另外，冷启动问题明显，缩绒到零虽然能降低一些成本，但是流量很有可能遇到超时问题。
九、Gateway 和云的融合
降成本:减少了十几个组件,大大降低运维成本和laaS成本
更稳定: SLB 云产品服务更稳定、可靠性更高，易用性也更好
为了解决上述问题，把 gateway 和阿里云做了一个深度的融合，用户还是按照knative 的原生语义使用，但底层的 controller 和 gateway 都深层嵌入到阿里云体系之中，这样基本上降低了风险，以 Knative API 的方式使用云资源，还能享受到阿里云基础设施带来的优势，首先 gateway 和云的融合，使用云产品 SLB 的好处有以下几点，一是云平台级别的支撑提供 SRA 保障，另外无需付费，不需要支出laas 资源，用户无需承担运维成本，不用考虑高可用问题，因为产品自动带了高可用的能力。
十、管控组件下沉
1.开箱即用
用户直接使用 Serverless Framework,不需要自己安装
2.免运维、低成本
Knative 组件和 K8s 集群进行融合，用户没有运维负担，也无需承担额外的资源成本
3.高管控
所有组件都在管控端部署，升级和迭代更容易
用户只需要使用 serverless 并开通 knative 功能，就可以基于 knative API 云的能力，并且无需为 knative controller 付出任何成本。可以做到开箱即用，用户使用serverless framework，不需要自己安装。
十一、优雅的保留实例
1.免冷启动:
通过保留规格消除了从0到1的30秒冷启动时间
为了解决第一个问题，推出了实例保留的功能，保留实例是阿里云的能力，没有流量的时候默认为0，但是0到1冷启动的问题很难解决，冷启动除了要解决 ISSA 的资源分配，Kubernetes 的调动，垃圾问题，还涉及到应用自身的启动时长，应用启动市场从毫秒到分钟都是有的，这些启动时间完全是业务行为。
2.成本可控:
通过低成本的保留实例来平衡成本。在 Knative 业务波谷的时候，使用突发性能实例替换标准规格实例。当第一个请求来无缝切换至标准性能实例。突发性能实例成本比标准规格实例降低40%的成本，如果和 Spot 实例结合还能再进一步降低成本。
十二、动手实践
实践包括部署coffee服务、访问coffee服务，最后观察一下保留实例。
首先清理一下之前部署的资源，在里面打印一个 coffee 信息，执行一下 kubectl 部署一下服务，部署完成以后观察一下 pod，pod 正在创建中，在 pod 创建中，
可以来获取一下相关的访问地址，输入 knative-serving，针对于集群的网关是阿里云 SRB。访问通过 SRB 可以直接访问 coffee 服务，查看一下当前 pod 的状态，正在running，可以观察到，如果有一段时间是否会送到保留实例上，可以观察一下。
正常没有在服务访问的时候进行松容，为了解决问题松容到保留实例上面去，在没有流量进来的情况下，保留实例开始进行创建，保留实例创建完成之后会下线到正常的实例，保留实例启动完成以后，正常实例就会下线掉。
十三、总结
●回顾
◎为什么需要 Knative
◎Knative Serving
◎Knative 与云的结合
●下期
Knative 冷启动
通过原生的 kubemetes 创建 serverless，容易遇到一些问题，这时候knative提供了 serverless 应用编排框架，接下来讲了 knative serving 相关的内容，包括servce，configration 信息，下面讲了 knative 与云的结合，把相关的一些组件knative controller、网关和阿里云做了一些深度的融合，serverless 做了一个极致的体验。下期介绍 knative 冷启动的内容，在没有访问的时候出现了保留实例，如何通过保留实现冷启动是下期介绍的内容。
