本文来自滴滴内部人士观点分享，不代表本机构观点。欢迎大家点评交流！
本篇由来
如果你是一个程序员，你可能在最近这两年或多或少的听到过一堆莫名其妙的名词，例如CaaS、BaaS、FaaS等类似的以aaS结尾的as-a-service名词，同时也可能听到ServiceMesh、Serverless等名词，对于从事相关工作的同学可能知道每个名词都代表什么，但我相信肯定还是会有部分人听到之后是黑人问号脸，我们不具体介绍每个都是什么意思，因为这些概念也出现很早了已经，不明白的可以自行google，这里我们重点聊一下最近挺火的Serverless是个什么鬼，因为我发现我们在日常探讨过程中好像每个人对其理解不一样，也是在听完一次讨论之后有感而发，并不是在抱怨什么，只是想跟大家探讨一下到底什么是Serverless，在继续开展后续工作之前，我认为有必要再统一一下概念，不谈细节，也不扯什么性能，那都是可以优化的，不是不可逾越的障碍。
什么是Serverless
要说Serverless是什么，直译过来就是无服务器。根据 CNCF 的定义，Serverless 是指构建和运行不需要服务器管理的应用程序的概念。CloudFlare对其定义：
Serverless computing is a method of providing backend services on an as-used basis. A Serverless provider allows users to write and deploy code without the hassle of worrying about the underlying infrastructure. A company that gets backend services from a serverless vendor is charged based on their computation and do not have to reserve and pay for a fixed amount of bandwidth or number of servers, as the service is auto-scaling. Note that although called serverless, physical servers are still used but developers do not need to be aware of them.
google翻译结果：
无服务器计算是一种按需提供后端服务的方法。无服务器提供程序允许用户编写和部署代码，而不必担心底层基础结构。从无服务器供应商处获得后端服务的公司将根据其计算费用，而不必保留和支付固定数量的带宽或服务器数量，因为该服务是自动扩展的。请注意，尽管称为无服务器，但仍使用物理服务器，但开发人员无需了解它们。
Serverless == FaaS?
在我们讨论Serverless的时候，经常能听到FaaS、事件触发之类的词组，但是为啥从官方的定义中丝毫没有看到这些字样呢？FaaS又和Serverless有什么关系呢？
其实这一块业界也没有统一的定义，但是普遍认为Serverless = FaaS + BaaS，可以参考这篇和这篇介绍的内容，通俗的理解一下就是无服务期计算相当于函数计算和后端即服务两种模式的组合，也是就说Serverless和FaaS不是一个概念，这个很重要，这是我们后续讨论和做事情的基础，我们不能简单的认为Serverless就是FaaS，这种理解太狭隘了。可以举个栗子来描述一下为什么这么说，例如已经被大家玩烂了的hello world，当我们写了一段hello world的代码并填写完访问规则后就可以通过FaaS平台部署，然后当我们访问指定Url后可以得到运行结果，典型的函数即服务。但是，又有谁会真正这么用呢，可以说没有任何作用，这只是个单纯的例子（在aws lambda上玩过这个例子的就敢号称使用过serverless产品），在最早的aws lambda官方推荐的使用场景里也都是和其他服务如S3搭配使用。毕竟每个业务都有自己的业务逻辑，或多或少都会涉及到一些基础组件的依赖或者第三方服务的调用（硬要抬杠的话，其实直接把依赖项都打包到一个程序里也不是不可以，但是这么做的人估计也不会用FaaS这种东西），很少或者不会有hello world这种自嗨式的场景，执行完什么记录都没有，单纯打印一下内容就返回的，除非在测试环境或者线下自己玩。而那些被使用的基础组件或服务就是BaaS。说了这么多到底是想说什么呢，其实就是想表达Serverless不等价于FaaS。
关于Serverless许多时髦的词儿都来自FaaS。抛开部署模式，FaaS本质上是事件驱动的途径或者事件流，这就包含两层意思，一层是事件，说到事件，自然联想到各种MQ组件，用MQ来解耦事件的生产者（事件源）和消费者（服务实例或者function），以及一些相关事件类型、触发规则、通知等概念，在这一点上确实和消息中间件有很大关系；另一层是驱动，也就是说是有流量属性的，MQ里的事件要被消费肯定是要经过网络传给消费者的。看起来就是一个用消息队列来解耦生产者消费者的通用模型，根据事先配置好的触发规则拿到想要的事件，执行预先写好的函数。他的关注点在于对用户屏蔽服务器，用户只需要告诉平台触发条件及触发后的逻辑即可，极大的减轻用户的工作量，提升开发效率。
Knative是什么
官方定义如下：Kubernetes-based platform to build, deploy, and manage modern serverless workloads，即基于k8s的，集构建、部署和管理serverless工作负载的平台。它包含三个模块，Build、Serving、Eventing，其中Build已经归档并被Tekton替代，其分别实现容器构建、工作负载管理、事件模型的功能，且分别对应不同的github项目，可以按需独立部署使用。
Knative和Serverless是什么关系
Knative 是通过整合容器构建(或者函数)、工作负载管理(和动态扩缩)以及事件模型这三者来实现的一套Serverless标准。
三个模块各司其职，Eventing制定了FaaS所需要的事件模型标椎，Serving制定了工作负载与外部或内部其他服务之间交互的标准、Tekton制定了容器构建的标准。
Eventing组件正是FaaS的本质，且制定了事件处理标准流程，并且抽象出来event source、broker、trigger等概念，且内置了许多事件源和消息队列，也支持自定义，非常灵活的。用户通过在集群内创建对应的事件源、队列、broker，trigger及service（真正的消费者）即可，其实这些信息在FaaS产品上也是需要配置的，但是由于每个FaaS平台的实现没有统一的标准，所以在lambda上实现的功能无法直接搬到kubeless上使用，这也是为什么knative出现原因，制定标准。
Serving组件主要治理刚才提到的service，这里的service并不仅限于刚才提到的消费者的角色，因为像普通的BaaS服务，或者就是简单的容器服务也是可以注册为一个service来享受Serving组件提供的基于流量或者资源或者自定义指标的动态扩缩容的功能及生命周期管理功能的。
再加上Tekton组件（本身也是service），就形成了一套完整的Serverless生态。例如用户编辑函数并配置触发规则后提交，然后Tekton利用Eventing检测到相关事件后获得代码，按需编译（解释型的不需要），然后制作镜像，推到镜像仓库，并根据配置的触发规则和镜像信息配置好事件源、队列、broker、trigger、service，剩下就是等待事件的到来，最终通过Eventing模块把流量打到对应的service上，但是此时Serving模块发现集群内还没有对应service的实例，于是就会按需启动指定副本数的service实例，请求处理完之后再按需缩容。最后既屏蔽了用户对服务器的感知，减轻了其工作量，提升了效率，又可以根据事件触发，并且按需使用服务器资源，提升资源利用率。在没有流量时甚至可以使用在离线混部的技术跑一些离线任务，在有流量时通过k8s的调度能力缩容一些离线任务的实例，为在线任务腾出资源来，类似容量调度的功能（给你划分的资源你用不了那么多的时候可以给别人用，当你需要的时候再给你，优先保证你够用）。
Knative工作流程展示
接下来我们举个例子来展示一下Knative的工作流程和现在的区别，例如在阿里云上使用Knative实现人脸识别的功能。场景如下：
通过 OSS 控制台上传照片，MnsOss 事件源接收图片上传的事件信息，发送到 Knatvie Eventing，通过Broker/Trigger事件处理模型之后，接着触发 Knative Serving 中的人脸识别服务进行分析。最后把分析之后的图片回传到 OSS。
整个流程就是上图所绘，大家可以体会一下。
应用场景
大家都在思考的共同问题就是Serverless的适用场景及预期的规模，能带来多大收益，以此来判断是否值得做。最终预期的规模和收益其实都和适用场景有关，场景多了，自然规模就大了，也和技术有关，如资源闲着你混部，那自然使用率就高了，降低了整体成本，带来收益的增加。但是具体有哪些适用场景呢，好像也没能说得清楚，一提到Serverless总会被带到FaaS上（无奈）。我们不妨直接去问问需求方到底是为什么想用Serverless的功能，Way社区里就有各团队之前对Serverless的探索，里面也总结过使用场景有哪些，或者网上随便一搜也能搜到很多，再结合实际业务，找出其他的适用场景我想应该没那么难吧。三个前端前端团队都有类似需求，不只是FaaS，还有BaaS等，而且需求方的提的FaaS也不一定就是上面提到的FaaS，有的时候我们理解用户需求不能只听他说了什么，还要看他为什么有这个需求，是想实现什么目的。
对前端的影响
大家一直在探讨前端的边界是什么。现在的前端开发早已不是以往的前端开发，前端不仅可以做网页，还可以做小程序，做 APP，做桌面程序，甚至做服务端。而前端之所以在不断拓展自己的边界、不断探索更多的领域，则是希望自己能够产生更大的价值。最好是用我们熟悉的工具、熟悉的方式来创造价值。
而 Serverless 架构的诞生，则可以最大程度帮助前端工程师实现自己的理想。使用 Serverless，我们不需要再过多关注服务端的运维，不需要关心我们不熟悉的领域，我们只需要专注于业务的开发、专注于产品的实现。我们需要关心的事情变少了，但我们能做的事情更多了。
Serverless 也必将对前端的开发模式产生巨大的变革，前端工程师的职能也将再度回归到应用工程师的职能。
为什么进行的不顺畅
因为认知不同。为什么认知会不同呢，...此处省略1000字。Whatever，结果就是大家认知不同，讨论的时候相较于倾听，又比较喜欢发言，so...
团队分工
...此处省略1万字
总结
如果要用一句话来总结 Serverless，那就是 Less is More。
作者：李鹤【滴滴出行资深软件开发工程师】
来源：oschina
链接：https://my.oschina.net/u/4244677/blog/4277377