研发的未来在哪里？Serverless 云开发来了！

【CSDN 编者按】过去几年间，Serverless 发展迅猛，与其相伴的还有从小程序、移动端等到前后端一体化的演进与实践，也正因如此，从云计算到前端，众多开发者都极为关注。本文作者腾讯云云开发研发副总监罗云所代表的 CloudBase 团队对 Serverless 进行了产品化的技术落地实践，并取得了包括多端支持、大幅节约资源成本、免运维等成果验证，接下来，一起来看 CloudBase 的 Serverless 实践，相信会对关注 Serverless 以及研发模式的开发者有所裨益。

作者 | 罗云，腾讯云云开发研发副总监

责编 | 唐小引

头图 | CSDN 下载自 VCG

出品 | CSDN（ID：CSDNnews）

随着云计算行业的不断发展，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 有较深的互动。

• 腾讯云 Serverless Cloud Fucntion，来自腾讯云的公有云计算产品，和腾讯云的云开发有较深的结合落地。

BaaS: Backend as a Service， 后端即服务。

对于 BaaS，覆盖的范围会更广阔一些，需要去解决 Serverless 落地过程中除去计算而外的所有后端场景，例如数据库服务，消息队列和存储服务等。开发者在使用 BaaS 服务的时候，不再需要去感知后端的服务运维，提出服务需求，享受服务即可。例如在数据库服务部分，通常又被细称为 DBaaS（Database as a Service）。传统场景下，开发者的运维团队要关心数据库运维的细节问题，而基于 DBaaS，开发者只需要关注业务逻辑即可。

CloudBase 的 Serverless 落地实践

作为国内落地实践 Serverless 较早的团队，我们结合 Serverless 理念打造了一套服务开发者的多端一站式应用开发平台 CloudBase。基于云开发 CloudBase 的能力，开发者只需要关注自己的核心业务逻辑，后台服务的可用性、可靠性、故障处理恢复等其它分布式难题全部交给云开发来应对。

以下是云开发 CloudBase 的一个产品矩阵图：

在落地 Serverless 理念的过程中，我们服务了 50 万的开发者，涉及的领域包含小程序、Web 应用和终端应用。开发者们可以基于云开发 CloudBase 平台快速构建自己的业务逻辑，释放创意。

然而随着云开发 CloudBase 不断服务各式各样的开发者的过程中，云函数也暴露出一些在解决用户业务场景乏力的短板出来。主要包含以下几个方面：

• 改造成本

在云函数的模式下，开发者需要进行一系列的云函数适配性改造才可以将已有业务搬迁到云开发上来。特别是，开发者部分业务还需要基于后台常驻模式才可以有效运行，而云函数的事件触发、用完即回收的特点却无法支持开发者的这一重要诉求。

• 语言生态限制

云函数对于不同的语言需要针对性的提供不同的 Runtime，例如 Node.js 场景，随着版本的不断更新迭代，需要平台不停去适配新的 Runtime 版本。另外，不同的开发语言往往还有很多的配套框架。例如 Node.js 生态的 Koa 和 Express 等等，这些框架往往依赖于系统平台的一些机制，而云函数本身需要额外的成本去适配这些框架，对框架的适配度也将大大影响相关语言开发者的使用意愿。

• 性能

云函数的按需使用，在请求真正触发时才产生计算成本的特性大大降低了开发者的运维成本，但也同时带来了启动时的时延问题，也就是「冷启动」问题。

为了解决这个冷启动问题，云函数可以采用首次启动后延迟销毁、资源预留等方法来优化，但是对于一些对性能要求较高的业务，云函数始终无法提供逼近传统计算模型的服务，也影响了开发者使用云函数的意愿。

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 之间关系的架构图：

云开发 CloudBase 是怎么落地这个理念的？

云开发 CloudBase 的 Serverless 云应用是基于 Knative 来构建整个体系的，围绕 Knative 进行了相关理念的实际落地。下面我们会从 CloudBase Serving、CloudBase Build、CloudBase 云应用生态三个方面进行具体的阐述。

▐  CloudBase Serving

• URL 到容器

在用户使用 CloudBase Serverless 云应用新建服务的时候，会产生一个与之对应的 URL，通过这个 URL，用户即可访问到对应的服务。那么这个 URL 是如何通过版本进行流量管理，映射到对应的容器的呢？如下图：

其中创建的 CloudBase 服务下允许存在多个版本（Revision）。用户可以针对每个版本进行流量设置，Router 会根据流量占比来进行请求路由，从而实现服务维度的定制化灰度策略。

• 扩缩至 0

在 Serverless 场景下，我们还允许用户设置最小副本数为 0，对于一些需要常驻的服务，开发者设置最小副本数不为 0 即可，这样可以有效应对冷启动。

可以看到，每个 Revision 对应了 Deployment 管理的一组 Pod。

Pod 会自动上报 metrics 数据到 Autoscaler，Autoscaler 会根据请求量和资源使用情况修改 Deployment 的副本数量，从而实现自动扩缩容。Serverless 容器一个重要的特点是它会 scale to 0，也就是当应用没有流量访问时，它会自动销毁所有的 Pod。

Activator 是为了处理 0→1 而出现的。当某个 revision 后面的 Pod 缩容到 0 时，Route 的流量会指向 Activator，Activator 接收到请求之后会自动拉起 Pod，然后把流量转发过去。

▐  CloudBase Build

CloudBase 提供三种能力来进行云应用的交付，用户可以通过镜像、源代码+Dockerfile、源代码这三种方式中任一的一种进行 Serverless 云应用部署。

下面阐述下三种方式的落地实践：

方案选型：考虑到目前 Knative Build 仍然处于快速演进变化中（从 Knative Build → tekton pipeline），CloudBase Build 这块暂时是复用腾讯云现有的 build pipeline 能力进行构建交付。

• 镜像方式

用户可用已有的镜像或者在本地生成的镜像，通过 docker push 原生命令，将镜像推送到腾讯云个人私有镜像仓库中，即可进行 CloudBase 云应用的部署运行了。

• 源代码+Dockerfile

用户可以通过源代码+Dockerfile 的方式进行云应用部署运行。源代码+Dockerfile 的方式支持本地代码上传，以及云端代码（GitHub/GitLab/Coding 等）授权拉取部署运行。在该模式下，开发者不再需要关心镜像是如何构建的，CloudBase BuildServer 会在云端进行镜像的构建。

• 源代码

Dockerfile 还是需要一定的入门门槛，我们一直在思考有没有办法进一步降低用户的使用门槛，推出了基于源代码的方式。用户只需要在 CloudBase Framework 下进行源代码编写，通过 CloudBase CLI 命令行工具就可以进行云端构建+部署。

▐  CloudBase 云应用生态

为了更加方便 CloudBase 云应用的开发者，CloudBase 云应用还将兼容 CloudBase 的生态（比如 CloudBase Server SDK，CloudBase 云调用，CloudBase 云支付等）。

当云应用和 CloudBase 现有生态进行了结合，用户就可以复用现有 CloudBase 生态的能力了。

举一个例子：比如用户的一个网站，可以将静态资源放到静态托管中，实现加速。将动态资源放到云应用中，实现流量驱动。并且代码无需实现跨域访问设置。云应用可和云函数以统一的域名对外提供访问。

这只是生态结合的一种场景，基于云函数可以在微信生态使用的能力（云调用、云支付），在云应用中都可以正常的使用，这里就不一一介绍了，期待大家的探索。

结语

云开发 CloudBase 的 Serverless 云应用是云开发团队在落地 Serverless 云端一体化实践过程中推出的新一代计算托管平台。基于该平台能力，开发者既可以享受 Serverless 带来的免运维，专注业务快速落地创意的优势；也没有云函数模式下面临相关（改造，冷启动，Runtime 有限）限制，云应用将是 Serverless 计算场景的一个有效补充。

当然在云应用模式下，开发者需要理解更多的一些计算服务概念（镜像，框架，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 生态带来多大的组合变化？

让我们拭目以待。

作者简介：罗云，腾讯云云开发研发副总监，从事多年的云计算后台研发和研发管理工作，对如何构建高可靠，高可用分布式系统有较深入的理解和落地经验。目前在负责腾讯云云开发后台研发工作，致力于打造一个多端一站式的云原生 Serverless 开发平台，让应用开发者更快落地创意。

【END】

更多精彩推荐

你点的每个“在看”，我都认真当成了喜欢