Serverless的概念&定义-无服务计算详解
过去几年间，Serverless 发展迅猛，与其相伴的还有从小程序、移动端等到前后端一体化的演进与实践，也正因如此，从云计算到前端，众多开发者都极为关注
在国内，Serverless 通常被称呼为「无服务计算」。但 Serverless 不是一种具体的框架、代码库或者工具集，而是一个为了减轻开发者的服务运营/运维成本而提出来的一套理论思想。
为了简化开发者们的理解成本，业界对 Serverless 有一种结合云计算行业的定义方式：
Serverless = FaaS + BaaS
FaaS：Function as a Service，函数即服务
对于 FaaS，业界已经有比较多的成熟厂商提供了线上产品，例如：
- AWS Lambda，起步最早的 FaaS 云产品，和 AWS 的云产品有很好的互动，开发者使用较多。
- Azure Functions，来自微软的公有云函数计算产品，晚于 AWS lambda 发布。
- Google Cloud Functions，来自 Google 的公有云计算产品，和 Google 的 Firebase 有较深的互动。
- 腾讯云 云函数，来自腾讯云的公有云计算产品，和腾讯云的云开发有较深的结合落地。
BaaS: Backend as a Service， 后端即服务
对于 BaaS，覆盖的范围会更广阔一些，需要去解决 Serverless 落地过程中除去计算而外的所有后端场景，例如数据库服务，消息队列和存储服务等。开发者在使用 BaaS 服务的时候，不再需要去感知后端的服务运维，提出服务需求，享受服务即可。例如在数据库服务部分，通常又被细称为 DBaaS（Database as a Service）。传统场景下，开发者的运维团队要关心数据库运维的细节问题，而基于 DBaaS，开发者只需要关注业务逻辑即可。
FaaS在解决用户业务场景乏力，存在一定局限，如下
局限1：改造成本
在FaaS的模式下，开发者需要进行一系列的云函数适配性改造才可以将已有业务搬迁到云开发上来。特别是，开发者部分业务还需要基于后台常驻模式才可以有效运行，而云函数的事件触发、用完即回收的特点却无法支持开发者的这一重要诉求。
局限2：语言生态限制
FaaS对于不同的语言需要针对性的提供不同的 Runtime，例如 Node.js 场景，随着版本的不断更新迭代，需要平台不停去适配新的 Runtime 版本。另外，不同的开发语言往往还有很多的配套框架。例如 Node.js 生态的 Koa 和 Express 等等，这些框架往往依赖于系统平台的一些机制，而云函数本身需要额外的成本去适配这些框架，对框架的适配度也将大大影响相关语言开发者的使用意愿。
局限3：性能
FaaS的按需使用，在请求真正触发时才产生计算成本的特性大大降低了开发者的运维成本，但也同时带来了启动时的时延问题，也就是「冷启动」问题。
为了解决这个冷启动问题，云函数可以采用首次启动后延迟销毁、资源预留等方法来优化，但是对于一些对性能要求较高的业务，云函数始终无法提供逼近传统计算模型的服务，也影响了开发者使用云函数的意愿。
从而促进Serverless的发展
那除了 FaaS，Serverless 的计算载体还有其他的选项么？
答案是肯定的，2019 年 4 月谷歌科技大会，Google Cloud 宣布将专注电信、零售、金融等垂直领域，与成熟的大型企业合作。针对此类用户在使用 Serverless 产品时的语言生态支持有限、改造成本过大、性能等问题推出基于 Knative 的 Serverless 容器产品 CloudRun。
这里是 Google Cloud Run 的一个产品时间轴：
那 CloudRun 背后的 Knative 理念又是怎样的呢？
Knative 是由 Google 提出，尝试去解决 Kubernetes 入门门槛略高的问题，这个理念已得到业界的一致认可。Knative 将重点放在三个关键组件上：build（构建）你的应用程序，为其提供流量 serving（服务），以及确保应用程序能够轻松地生产和消费 event（事件），以下是一个直观的表述 Knative 和 Kubernetes 之间关系的架构图：
为了让应用开发者更高效地落地创意，作为国内落地实践 Serverless 较早的团队，腾讯云云开发结合 Serverless 理念打造了一套服务开发者的多端一站式应用开发平台 CloudBase，并取得了包括多端支持、大幅节约资源成本、免运维等成果验证。
目前，腾讯云云开发服务了 50 万的开发者，涉及的领域包含小程序、Web 应用和终端应用。开发者们可以基于云开发平台快速构建自己的业务逻辑，释放创意。
当然在云应用模式下，开发者需要理解更多的一些计算服务概念（镜像，框架，Dockerfile），会比云函数的使用上更重一些，云函数在快速落地原型验证，上线轻量能力上有更多的应用场景。
在传统定义 Serverless 概念中，「Serverless=FaaS+BaaS」，这是一种前后串联的组合关系，彼此之间的互动是单向的，FaaS 的行为单向传递到 BaaS。
将 Serverless 云应用（Serverless 容器）补充到 Serverless 计算场景之后，CaaS（Container as a Service）的理念也将慢慢走近开发者，服务开发者。
因为加入 CaaS 概念的 Serverless 生态等式将会变更为：「Serverless = FaaS+CaaS+BaaS」，但是这里仅仅是在原概念上多了一个加数么？考虑到计算能力之间的相互传递，Serverless 的作用关系将会发生本质的形态变化，如下图所示：
CaaS 会重新定义 Serverless 的语义（Serverless = FaaS+CaaS+BaaS）么，给 Serverless 生态带来多大的组合变化？
让我们拭目以待。
