2009 年加州大学伯克利分校发表了一篇文章，预言云计算将是未来重要的技术趋势。十年后的2019年，该校对 Serverless 技术再次进行预测，认为 Serverless 技术是未来十年的技术趋势。Serverless 计算被认为是云主机、容器之后的第三代计算形态。
下图为云计算发展的整个过程，同时也是Serverless的发展过程，共分为四个阶段。
a) 物理机阶段：
此时如果进行一个网站的开发是极为麻烦的，不仅需要购置物理机，还要手动安装 各种运行环境，开发，部署，测试，上线。除此之外，还要在物理层面上解决电，网，硬件磨损等各种问题。
b) IaaS阶段：
IaaS指的是基础设施即服务。随着虚拟化技术的不断发展，出现了很多基于虚拟化的云厂商和产品，如阿里云ECS。这个阶段，无需自建机房，采购以及配置硬件设施，云平台会提供这些基础设施。也正因如此，那些物理层面的电，硬件磨损什么的，用户无需关注。
c) PaaS阶段：
PaaS指的是平台即服务。所谓的平台，其实是结合业务发展，在IaaS基础上，将一些如数据库，中间件等通用功能做成服务。虚拟化技术可以让用户不必关心硬件问题，后来出现的容器技术可以让用户不必关心运行环境差异的问题。容器技术出现后，意味着服务器上部署的不再是应用，而是容器。当容器多了后，可通过k8s进行管理。
d) Serverless阶段：
这个阶段是真正解放生产，专注业务的阶段。在FaaS层面，应用由诸多个独立的函数组成，每个函数实现各自的业务逻辑。在数据获取层面，BaaS 将后端能力封装成了服务，并以接口的形式提供给FaaS。事实上，数据库的增删改查刚好对应Restful API的POST/DELETE/PUT/GET。
作为未来十年云计算的重要趋势之一，Serverless 架构已经展示出不俗的潜力。Forrester 认为：Serverless 架构的兴起，让 FaaS （Function As A Service） 成为继 IaaS、PaaS、SaaS 之后一种新的云计算能力提供方式。预计 2022 年，将会有大量主流企业的核心应用，从原来的主机架构迁移到 Serverless 架构。
Serverless是什么
从单词角度理解,server译为服务，less译为少，Serverless可以理解为无服务器计算。
从语义角度理解，之所以叫无服务器计算，是因为和传统的PaaS(平台即服务)相比，用户不需要关心服务器的部署与配置。但这并不意味着不需要服务器，只是这些东西皆由云平台来提供。
从架构角度理解，Serverless=FaaS+事件驱动+BaaS=无服务器计算(Serverless computing)
- FaaS: Function as a Service,函数即服务
- 事件驱动：通过事件触发的形式去完成函数的调用，处理请求和响应（如定时任务/http请求...）
- BaaS: Backend as a Service 后端即服务
Serverless 优点
Serverless 架构拥有零服务器运维和空闲时无计算成本等特点；其交付心智可以体现为将复杂留给云厂商，把便捷带给更多开发者。综上所述 Serverless 的优势可以体现在如下：
1）降本提效
云厂商为使用者提供服务器的管理和运维工作，为使用者提供数据库、对象存储等 Baas 服务，让用户将更多的注意力放在自身的业务逻辑上，提升研发效率，缩小项目的创新周期，同时 Serverless 的使用者不用更多的担心自身的服务器运维，基础设施的运维等工作，更不用为这部分有额外的费用支出，无需承担更多的运维工作成本等；Serverless 架构提供了较为完善、全面的按量付费模型，使用者只需要按照自己实际使用的资源量付费即可；Serverless 架构在这一层面有较为明确的优势。
- 降低运维成本
- 降低人力成本
- 提高研发效率
- 降低创新周期
- 按量付费、降低支出成本
2）安全、方便、可靠
把更专业的事情交给更专业的人去做，Serverless 架构将更多服务器运维、安全相关的事情交给云厂商来做，大规模提升项目整体的安全性；同时，Serverless 架构明显比其它架构更简单，因为更多的 Baas 服务都是云厂商提供的，使用者将会管理更少的组件，这意味着 Serverless 的使用者可以更简单更方便的管理项目；同时 Serverless 架构拥有着弹性能力，即自动伸缩的能力,该能力可以让项目在流量增加的时候，自动进行扩容，在流量降低的时候，自动进行缩容，进而保证整个业务的安全、稳定。专业团队为用户保障安全，保障性能，这使得 Serverless 架构：
- 安全风险更低
- 资源开销更小
- 符合“绿色”计算思想
- 更加方便管理
- 弹性伸缩，服务更可靠
除国外几大云计算大厂 AWS Lanmbda、Google Cloud Functions 早已布局外，国内各大厂商也在争先布局，包括字节、阿里、腾讯、华为、百度等。
关于阿里的投入可以参考 为什么阿里要举集团之力趟坑 Serverless?
下图是CNCF 列出的 CNCF 列出的 Faas 平台
云原生时代下的 Serverless
毋庸置疑，当前已经进入了云原生的时代，那在云原生时代下的 Serverless 的合理架构是怎样的呢?
答案就是 Knative！！
Knative 是谷歌开源的 Serverless 架构方案，旨在提供一套简单易用的 Serverless 方案，把 Serverless 标准化。Google 内部的 Serverless 产品 CloudRun 就是基于 Knative 建设的。目前参与Knative的主要公司有 Google、Pivotal、IBM、Red Hat。Knative 于2018年7月24日才对外发布，2021 年刚发布了 1.0 版本。
有了 ”k8s，为什么还要 knative”
通常情况下 Serverless = Faas + Baas，Faas 无状态（业务逻辑），Baas 有状态（通用服务：数据库，认证，消息队列）。
既然有了 k8s (paas), 为什么还需要 Knative (Serverless),下面从四个方面来进行解释：资源利用率，弹性伸缩，按比例灰度发布，用户运维复杂性
1) 资源利用率
讲资源利用率之前先看下下面两个应用，左边应用 A 这个是典型的中长尾应用，中长尾应用就是那些每天大部分时间都没有流量或者有很少流量的应用。
想一下，如果用 paas(k8s) 来实现的话，对于应用 A，需按照资源占用的资源最高点来申请规格，也就是 4U10G, 而且 paas 最低实例数**>=1**, 长此以往, 当中长尾应用足够多时，资源利用率可想而知。有可能会出现 大部分边缘集群资源被预占，但是利用率却很低。
而 Knative，恰恰可以解决应用A的资源占用问题，因为 Knative 可以将实例缩容为0，并根据请求自动扩缩容，缩容到零可以大大增加集群的资源利用率，因为中长尾应用都是按需所取，不会过度空占用资源。
比较合理的是对应应用A 用 Knative(Serverless)，对于应用 B 用 k8s（Paas）
2) 弹性伸缩
大家可能会想到，k8s 也有 hpa 进行扩缩容，但是 Knative 的 kpa 和 k8s 的 hpa 有很大的不同：
• Knative 支持缩容到 0 和从 0 启动，反应更迅速适合流量突发场景；
• K8s HPA 不支持缩容到 0 ，反应比较保守
具体比较如下：
Knative KPA | k8s HPA | |
指标类型 | 可以根据 请求量扩速容 | 只能根据 cpu memory 等指标扩缩容（或自定义指标） |
01启动 | 可以缩容到0和冷启动 | 只能缩容到1（如果缩容到0，就没有实例了，流量进不来，metrics数据永远为0，此时HPA也无能为力） |
指标获取方式 | Knative 指标获取有两种方式，Activator 和queue-proxy, activator的metrics 是通过websocket 主动push 给Autoscaler的，反应更迅速 | k8s 只能是通过prometheus 轮询获取。 |
反应速度 | Knative 默认会 计算 60 秒窗口内的平均并发数， 也会计算 6 秒的恐慌窗口，6s内达到目标并发的 2 倍，则会进入恐慌模式。在恐慌模式下，Autoscaler 在更短、更敏感的紧急窗口上工作 | 而且 HPA 本身设计比较保守，有一个稳定期（默认5min）默认在5min内没有重新扩缩容的情况下，才会触发扩缩容。当大流量突发过来时，如果正处在5min内的HPA稳定期，这个时候根据HPA的策略，会导致无法扩容。 |
3) 按比例灰度发布
设想一下，假如通过 k8s来进行灰度发布怎么做，只能是通过两个Deployment和两个service，如果灰度升级的话只能通过修改两个 Deployment 的rs，一个逐渐增加，一个逐渐减少，如果想要按照百分比灰度，只能在外部负载均衡做文章，所以要想 Kubernetes 原生实现，至少需要一个按流量分发的网关，两个 service，两个 deployment ，两个 ingress ， hpa，prometheus 等，实现起来相当复杂。
使用 Knative 就可以很简单的实现，只需一个 ksvc 即可。
4) 用户运维复杂性
使用 Knative 免运维，低成本：用户只关心业务逻辑，由工具和云去管理资源，复杂性由平台去做：容器镜像构建，Pod 的管控，服务的发布，相关的运维等。
k8s 本质上还是基础设施的抽象，对应Pod的管控、服务的发布、镜像的构建等等需要上层的包装。
Knative究竟是什么，这些涉及本质、方法、原理和实践的问题，需要一个权威、前沿和系统的回答。幸好有位大神写了一本书，而我们也刚刚把这本书翻译了过来。
感谢您的阅读，也欢迎您发表关于这篇文章的任何建议，关注我，技术不迷茫！
