【本文正在参与 “100%有奖 | 我的Serverless 实战”征稿活动】

0.实践

云开发 CloudBase

官网：https://console.cloud.tencent.com/tcb/

文档：https://docs.cloudbase.net/quick-start/create-env.html

Serverless 云原生一体化产品方案，助力小程序、Web应用、移动应用成功

特点

• 无服务器
  • 借助 CloudBase 云数据库、云存储、云函数等强大的后端能力，无需自行搭建或维护服务器即可开发、上线您的应用。
• 跨平台
  • 支持小程序、Web、Flutter、Unity等多个平台，帮助各平台开发者高效开发应用。
• 轻松托管
  • 使用 CloudBase 静态文件、云函数、前端 SSR 应用、容器等托管能力，和简单快捷的部署工具，一键发布您的应用。
• 节约成本
• 极速部署
  • 使用云开发提供的应用模板快速上手，将代码一键部署到您的环境
  • React应用、Vue应用、Ghost、Discuz!Q、WordPress、Express应用、Taro应用
  • 更多可查看：https://cloudbase.net/marketplace.html

云托管 CloudBase Run

云托管（Tencent CloudBase Run）是 云开发（Tencent CloudBase，TCB）提供的新一代云原生应用引擎（App Engine 2.0），支持托管任意容器化应用。

文档：https://cloud.tencent.com/document/product/1243

特性

• 不限语言
  • 开发者可使用任意自己喜爱的语言和框架，包括但不限于Java，PHP，Go，Python。上传镜像即可快速部署，也可上传代码包或提供GitHub/GitLab 代码库授权，由云托管自动构建部署。
• 跨平台
• 低迁移成本
• 流量驱动
• 云开发框架

步骤

开通

1. 登录云开发CloudBase控制台

• CloudBase控制台：https://console.cloud.tencent.com/tcb/

2. 开通云托管服务

• 云托管：https://console.cloud.tencent.com/tcb/service

目前，云托管已开放上海和广州地域。

新建环境

1. 选择应用来源→空模板

2. 选择地域，自定义环境名称，✔开启免费资源

• 本文定义的环境名称：cloud，可自行修改

免费资源一个账户最多开通一个，我已开通了，所以勾不了。

3. 开通成功

4. 开通成功后，自动跳转到云托管的服务列表页面

新建服务

1. 填写服务名称、备注信息（选填）后，单击「提交」

• 公网服务：该项按需勾选

2. 创建完服务后，列表中展示了新的服务项

部署至云托管

1. 在电脑桌面上新建一个文件夹

• 文件夹名称自定义：filecloud，按需修改
• 文件夹中新建一个文件，文件名固定为：Dockerfile

注意：文件名、文件类型，均为固定的。

• 创建Dockerfile 的文件后，并将以下代码（可根据自身需求调整）粘贴到其中：

# Use the official PHP 7.3 image.
# https://hub.docker.com/_/php
FROM php:7.3-apache

ENV Koddownload_URL http://static.kodcloud.com/update/download/kodbox.1.13.zip
##下载kodexplorer
RUN apt-get update && apt-get install -y --no-install-recommends unzip ca-certificates wget  \
    && wget -q -O /var/www/kodexplorer.zip ${Koddownload_URL} \
    && unzip -q /var/www/kodexplorer.zip -d /var/www/html \ 
    && rm -rf /var/cache/apk/* && rm -rf /var/lib/apt/lists/* 
##安装相关拓展
RUN apt-get update && apt-get install -y \
        libfreetype6-dev \
        libjpeg62-turbo-dev \
        libpng-dev \
        exiftool \
  && docker-php-ext-install -j$(nproc) iconv \
  && docker-php-ext-configure gd --with-freetype-dir=/usr/include/ --with-jpeg-dir=/usr/include/ \
  && docker-php-ext-install -j$(nproc) gd \
  && docker-php-ext-install exif \
  && docker-php-ext-configure exif --enable-exif \
  && docker-php-ext-install pdo pdo_mysql \
  && cd /usr/local/bin && ./docker-php-ext-install mysqli \
  && rm -rf /var/cache/apk/*
##文件权限
RUN chmod -R 777 /var/www/html/
##工作目录
WORKDIR /var/www/html
##声明端口
EXPOSE 80

2. 点击刚创建的服务filecloud，进入版本列表

3. 点击「新建版本」，按照图中步骤依次操作后，单击「开始部署」（部署时间可能需要5-10分钟）

4. 等待部署完成后，单击上方「服务配置」，单击「路径」

• 新建「路径」为 /

5. 返回至版本列表，单击「访问服务」

配置网盘

1. 跳转至网盘配置页，直接下一步

2. 数据库配置页，按需配置，然后下一步

注：使用 Mysql 数据库需要把腾讯云 Mysql 数据库设置为与云托管同一私有网络下，其他类型数据库同理。

3. 转至账号设置页

网盘首页

1. 登录

2. 访问网盘界面

以上为所有实践内容~

---

1. 说一说 Serverless 到底是什么？

Serverless 是一种云原生开发模型，可使开发人员专注构建和运行应用，而无需管理服务器。简单来说 Serverless 就是让你不与或少与运行应用程序所需的服务器和基础设施进行交互，当今天我们提到 "serverless" 这个词的时候通常它可以指 CaaS 和 FaaS 这两种服务。

CaaS - 容器即服务

当我们创建容器后，把它扔到 CaaS 上，它就会自动运行、服务和扩展，比如 Azure Container Instances、Google Cloud Run 或 AWS Fargate 这些服务。

FaaS - 函数即服务

当我们写好代码，扔给 FaaS，它就会自动运行、服务和扩展。比如 Azure Functions、Google Functions 或者 AWS Lambda 这些服务。

FaaS 可以用不同的方式来运行你的代码，一种方式可能是 FaaS 为每一次代码变化构建一个容器，就类似于使用 CaaS 这种服务。

FaaS 构建成容器发送给 CaaS

另一种方式是 FaaS 在启动过程中动态地将函数的源码拉到一个预定义的环境（容器）中，不同的语言会有不同的环境，当使用像 Go 这样的编译语言时，那么编译必须在启动时进行。

事件或伸缩

FaaS 大多数时候与函数实例的触发器事件系统一起使用，事件可以来源于 API 网关、Github、Kafka、RabbitMQ、CronJobs 等。

FaaS 封装了与事件源的通信

对于每个事件，将创建一个新的函数来处理它，如果有多个事件同时发生，将创建多个实例来处理这些事件。这样我们就有了自动伸缩的功能。

FaaS 与各种事件源进行通信，所以函数本身不需要去实现，它们只需要与 FaaS 使用的一种事件格式进行通信，比如 CloudEvents 或者通过 HTTP 传输。

FaaS - 函数即服务

在 FaaS 服务中的 function.yml 文件中将包含一个来自 FaaS 系统的 K8s 资源，通过 CRD 引入，在该资源中，我们可以配置函数名称、源代码位置、语言运行时和触发事件等内容。

有了 FaaS，我们也就拥有了 CaaS 解决方案的一切能力了，现在我们进一步减少了工作量，因为我们有工具在 Kubernetes 集群中运行，可以直接执行/构建我们的应用源代码。

为我们构建的容器已经包含了必要的库，比如 HTTP 或 CloudEvents，来接收来自 FaaS 的事件，所以我们不必担心这个问题。

源码可能存储在 Git 仓库中，也可能是通过 web 界面上传的，或者是在其他地方提供的。FaaS 将访问代码，监听变化，构建容器，然后将其传递给 CaaS，用于服务终端事件。

TriggerMesh 的web 界面，用于上传代码并作为一个函数进行部署

冷热启动

冷启动将意味着没有 Pod 已经在运行处理事件，所以需要一些时间来创建它。通常情况下，这些 Pod 在最后一次使用后会保持一段时间，可以重复使用。在 “已经运行” 期间的调用被称为热启动，热启动的速度较快，但也会消耗资源。

Fission

Fission 是一个典型的运行在 Kubernetes 环境下面的 Faas 服务，实际上并没有为每个函数的代码变化构建一个不可变的容器，而是使用了可变的环境容器（“Generic pods”）的概念，动态地将代码拉进来，然后将这些容器转换成 “Specific Function pods”，这也是 AWS Lambda 使用用 AWS Firecracker 的工作方式。

可观测性

从容器化的微服务转向函数，可能会导致不得不管理比以前更多、更小的服务。这是因为创建小型函数是很容易的，这些函数只是监听和处理一个单一事件。

为了管理更多的服务或功能，所以非常有必要保持可观察性（指标、日志、跟踪），这就是为什么大多数 Kubernetes 的 FaaS 和 CaaS 已经与Prometheus、Jaeger 和 Istio 或 Linkerd 等服务网格进行了集成。

总结

最后我们来回顾下传统的 K8s 应用和 serverless 应用的区别。

传统 K8s 应用

Serverless 应用

我认为现代 serverless 事件驱动的架构已经证明了自己的能力，并且在未来几年会越来越普遍。Kubernetes上的 Serverless 只是持续自动化掉手工作业的结果。

2. 微服务和 Serverless

现在业界关于微服务和 Serverless，会有部分这样的认知：认为当前云计算典型代表技术是微服务，下一代的代表技术是 Serverless，这会让你 Serverless 比微服务要先进，甚至会觉得未来有了 Serverless 就没有微服务了，类似下面这张图：

个人认为产生这一认知还是因为将 Serverless 的理念具象化到函数计算（FaaS）这样的产品。现在我们聊到微服务，会想到背后的技术框架，比如 Spring Cloud、Dubbo，但是其实微服务这个词已经远远超出了纯技术框架的范畴，它背后也有核心的支撑思想，包括：

• 微服务虽然一定程度上增加了技术复杂度，但是在一定规模下他会降低系统复杂度和组织复杂度。
• 现代业务系统越来越复杂，很多业务系统会基于领域驱动设计（DDD）设计，微服务其实是 DDD 背后的支撑技术。

单体、微服务和复杂度

所以如果到了 Serverless 时代就没法用微服务，我相信很多开发者会觉得不知所措，或者会“抵触未来”，因为他们会觉得有人给我描绘了一个未来，但是完全不知道怎么走过去。

抛开各种具体的技术实现，回到背后的理念，Serverless 代表的是一种无需关注服务器，降低使用云计算服务的理念，所以它和微服务其实不冲突，完全可以共存。在阿里云的 SAE 中，集成了微服务的能力（依托于阿里云产品 MSE），这意味着：

• 部署在 SAE 这类 S erverless 平台上的应用，完全可以继续使用微服务开发，不需要经过任何改造。
• 在 SAE 上甚至提供了很多微服务能力增强，包括了注册中心托管、服务治理等等，进一步降低开发者使用微服务的门槛和负担。

所以在 Serverless 类的 PaaS 产品上，Serverless 和微服务不再是对立的，开发者完全可以继续使用微服务技术开发，同时也可以享受 Serverless 理念所带来的【智能弹性】、【更低成本】等。

函数计算 FC

讲完 Serverless Application（应用），我们再来看看 Serverless Function（函数），FC 作为”根正苗红“的 Serverless 产品，相信大家都对它不陌生，经过这么些年的发展，它已经在前端 Serverless、多媒体处理、AI、事件类的场景（云产品事件、数据库变更事件等等）、物联网消息等场景得到了很好的应用，甚至也有越来越多的公司将业务完全构建在 FC 之上，比如：世纪联华的 Serverless 实践。

另外针对早期的很多技术限制，现在也已经有了解决方案：

• 早期大多数的函数计算产品都对磁盘大小、代码包大小、运行时长、内存规格等有限制，阿里云函数计算推出了性能实例基本解决了这些限制。
• 针对冷启动问题，可以使用预留性能实例解决。

下面我们就具体介绍部分使用 FC 的典型的场景。

1. 前端 Serverless

前端经过了 Ajax、Nodejs、React 等技术迭代后，已经形成了相对成熟的技术体系，特别是 Nodejs，使前端和服务端产生了联系。

前端和后端的分工发挥了各个的优点，但是在协作的过程中也一直存在一个问题，后端同学通常是面向领域和服务提供接口，但是前端是面向用户具体的数据接口，有时候一个简单的需求会因为两边的定义和联调搞半天。所以也诞生了 BFF（Backends For Frontends）这样一层，谁使用谁开发，专门解决领域模型 - UI 模型的转换。

理想很美好，现实也很骨干，如果前端同学去做 BFF 这一层，发现要学习后端的 DevOps、高可用、容量规划等等，这些其实是前端同学不想关心的，这种诉求在 Serverless 时代得到了很好的解决，由 BFF 变为了 SFF（Serverless For Frontend），让前端同学只要写几个 Function，其他都交给 Serverless 平台。

类似的还有服务端渲染 SSR（Server Side Rendering），本来前后端分工后，后端只需要写接口，前端负责渲染，但是在 SEO 友好以及快速首屏渲染等需求背景下，有时候会用到服务端渲染的方案，同样，使用 Serverless 前端同学又可以愉快的玩耍了。

其实现在很多偏前端产品里面（比如各类小程序以及语雀等产品），前端同学会全栈完成整体开发，越来越多的会用到 Serverless 相关技术。

当然，要用好 Serverless，需要完整的生态，包括相关的框架，运行时，工具链，配置规范等等，这方面可以参考阿里 Midway。

2. 多媒体处理

现在在线教育、直播、短视频等等行业都蓬勃发展，也催生了很多视频需求，包括视频的处理，包括视频剪辑、切分、组合、转码、分辨率调整、客户端适配等等，典型场景的比如：

• 每周五定期产生几百个 4G 以上的 1080P 大视频， 但是希望当天几个小时后全部处理完。
• 甚至您有更高级的自定义处理需求，比如视频转码完成后， 需要记录转码详情到数据库， 或者在转码完成后， 自动将热度很高的视频预热到 CDN 上， 从而缓解源站压力。

这些诉求在 Serverfull 的场景下，你可能需要搭建一套复杂的系统来支撑，但是如果使用 FC 那么你会发现一切都变得那么简单。

3. AI Serverless

AI Model Serving 是函数计算一个比较典型的应用场景。数据科学家训练好模型以后往往需要找软件工程师把模型变成系统或者服务，通常把这个过程称之为 Model Serving。函数计算无需运维和弹性伸缩的特性，正好符合数据科学家对高可用分布式系统的诉求。

Serverless 容器 - ASK

Kubernetes 作为生产级别的容器编排系统，现在已经成为了容器编排的事实标准，被广泛用于自动部署，扩展和管理容器化应用。它也有相应的 Serverless Kubernetes 产品，比如阿里云的 ASK、AWS Fargate 等。在这类产品中，你无需购买节点即可直接部署容器应用，无需对集群进行节点维护和容量规划，并且根据应用配置的 CPU 和内存资源量进行按需付费。ASK 集群提供完善的 Kubernetes 兼容能力，同时降低了 Kubernetes 使用门槛，让您更专注于应用程序，而不是管理底层基础设施。

如果您是 K8s 的重度用户，那么使用 Serverless Kubernetes 是一个不错的选择，典型客户场景包括：

• 微博：在 30s 之内可以极速扩容 500 个应用实例，应对跨年活动和热点事件。
• 旷视科技：基于 ASK 开发智能、免运维的 AI 应用平台。
• 趣头条：基于 ASK 构建 Serverless 大数据计算平台。

BaaS

上面提到的都是”计算类“Serverless 产品，FC、SAE、ASK 等，但是我们都知道，开发过程中不可能只有计算逻辑，还有很多其他依赖，比如存储、中间件等。BaaS(Backend-as-a-Service，后端即服务）类产品，提供基于 API 的服务，这些 API 一般都是按需使用、免运维、自动扩缩容的，所以他们也是 Serverless 的。

典型的比如阿里云的 OSS，具有与平台无关的 RESTful API 接口，可以在任何应用、任何时间、任何地点存储和访问任意类型的数据。

值得一提还有开发企业级应用时大家非常熟悉的中间件，以阿里为例当前也在进行 4.0 技术架构升级，全面 BaaS 化，统一运维、交付、计费、支持模式，开箱即用，产品化程度持续提升。

总 结

总结一下，上面提到的一系列 Serverless 的产品，覆盖了前端，后端，容器，BaaS 各个领域，包括很多上面没有提到的（比如 CDN）其实也算是 Serverless 的产品，所以我不认同伯克利的 Serverless=BaaS+FaaS 的观点，但是我非常认可他的另一个观点：“Serverless will dominate cloud computing”。

Serverless 首先是一个理念，不是某一种具体的技术，当未来某一天，99% 的云产品都有 Serverless 化的形态时，云计算也就 Serverless 化了，这种变化我认为不是非黑即白的，不是推翻重来这种革命性的，而是全面的降低用户使用云的成本，全面的提升开发者的研发效率。

---

【本文正在参与 “100%有奖 | 我的Serverless 实战”征稿活动】