当前位置：网站首页>从云计算到函数计算

从云计算到函数计算

2022-08-04 16:53:00 【InfoQ】

作者：Ethin

点击上方图片了解活动详情！

哈喽各位开发者，为了帮助大家客观了解并使用阿里云函数计算（FC），阿里云开发者社区携手云原生应用平台 Serverless 团队发布 “Serverless 函数计算征集令”，提供免费资源额度邀请你发文评测，

7月31日前参与活动，即有机会获得千元好礼 + 千元函数计算资源包！

立即参加：

https://developer.aliyun.com/topic/serverless2022

悄悄说...现在投稿还可领取优酷视频季卡一张；下面让我们跟随笔友 “Ethin” 的步伐，看看他眼中的 Serverless 世界吧！

函数计算，你的名字

云计算，是一种基于互联网的计算方式，通过这种方式，共享的软硬件资源和信息可以按需求提供给计算机各种终端和其他设备，使用服务商提供的电脑基建作计算资源，因此用 “云” 来指代 “网络计算资源” 这是一种非常恰当的比喻。

美国国家标准和技术研究院的云计算定义中明确了三种服务模式，分别是软件即服务（SaaS）、平台即服务（PaaS）和基础设施即服务（IaaS）。

阿里云的产品能全部覆盖这三种服务模式，如果分别举个例子那么应该是：宜搭（SaaS 加速器）、函数计算 FC 和云服务器 ECS。

Serverless 计算服务，其基于 PaaS 又不同于 PaaS，因而更多时候被称作功能即服务（Function-as-a-Service，缩写为 FaaS）。函数计算 FC 是阿里云的事件驱动的全托管 Serverless 计算服务产品，我想函数计算 Function Compute 的名字就是这样诞生的。

函数计算，直达应用的核心

我们知道应用的核心是逻辑和存储，而代码主要实现业务逻辑和持久化。

函数计算 FC 总体上是：FaaS+BaaS

函数指计算函数，包含了业务逻辑部分，这一部分由 FaaS 来实现；而数据持久化、消息推送和账户系统等，由 BaaS 来实现。

ECS ？FC ？

Serverless 服务并不是没有服务器了，而是作为一种新的架构让我们在以往传统应用维护上的工作得到进一步降低。

以常见的主要基于云服务器的 Web 服务为例，大致有这样的流程：

在服务过程中，服务器可能涉及路由规则、鉴权逻辑以及其他各类复杂的业务代码。同时，开发团队不仅要将精力用于开发，还要付出很大的精力在服务器的运维上面。例如要时刻关注以下问题：

服务器性能能否应对可能突然爆发的用户请求，何时扩容？

服务器上的脚本和业务代码等多少还在健康运行？

外部网络安全威胁到来时如何保障数据安全？

面对诸多问题确实会让人头大，但如果我们摒弃基于服务器的架构而转用 Serverless 架构之后；服务的过程就变成了这样：

当客户端和数据库未发生变化的前提下，服务器变成了 Serverless 的架构。工作的分工发生了巨变。

例如，之前需要开发团队维护的路由模块以及鉴权模块都将接入服务商提供的 API 网关系统以及鉴权系统，开发团队无须再维护这两部分的业务代码，只需要持续维护相关规则即可，再也不用担心应用的构建；业务代码被拆分成了函数粒度，不同函数表示不同的功能，根据请求量还可以实现毫秒级扩容；业务逻辑之外的一部分安全问题、资源调度问题全都交由云厂商负责。

除了开发和维护产品的省心，在具体实现成本上也能达到

降本增效

的效果。相对于传统项目服务的全天候运行来说，函数计算 FC 是基于事件驱动的，只有在用户发起请求时，函数才会被激活并且执行，运行成本按量收费，成本相较于节省计划还有显著的价格优势。

函数计算 FC：解放生产力，更专注于应用的业务本身

使用云服务器，我们不用操心物理机房的运行维护等操作系统层之下的内容；使用函数计算 FC，我们不再需要装操作系统、容器配置、运行环境，更不用担心环境程序会挂掉。

可见，采用函数计算 FC 的 Serverless 架构后,用户仅需运维与应用有关的函数，ECS 架构下需要操心的东西现在只剩下了一个：

函数计算仿佛一场全新的技术革命，当我们使用了函数计算 FC 的 Serverless 架构后：

开发团队不需要再自己维护服务器，也不需要自己操心服务器的各种性能指标和资源利用率，团队的运维可以更加专注的将监控目光放到监控应用程序本身的度量。

应用的部署将变得十分容易。我们只要上传基本的代码，同时不需使用 Puppet、Chef、Ansible 或 Docker 来进行配置管理，大大降低了运维成本。

综上所述，相对于传统项目，函数计算 FC 具备以下优势：

用户无需采购和管理服务器等基础设施，运维成本低，安全性更高。（涵盖了云服务器的优势）。

用户只需专注业务逻辑的开发，使用函数计算支持的开发语言设计、优化、测试、审核以及上传自己的应用代码。结合工作流，代码提交自动部署，直接运行！

函数计算 FC 以事件驱动的方式触发应用响应用户请求。与阿里云对象存储 OSS、API 网关、日志服务和表格存储等服务无缝对接，帮助快速构建应用。

简化运维工作，提供日志查询、性能监控和报警等功能快速排查故障。

不用担心性能问题，架构更富有弹性，毫秒级别弹性伸缩，快速实现底层扩容以应对峰值压力。

使用成本低，按需付费，支持百毫秒级别收费。只需为实际使用的计算资源付费，适合有明显波峰波谷的用户访问场景。

函数计算 FC 似乎是真正实现 “像云一样” 的云计算愿景，它很好的诠释了：

最大程度利用资源、减少空闲资源浪费的环保理念以及降低学习成本和使用成本的现实需求。

如此妙哉的函数计算该如何体验呢？

函数计算 FC 提供运行环境、开发者工具和函数触发器等功能。同时，函数计算 FC 提供有免费执行次数 : 100万 (次)和免费资源使用量 : 40万 (GB-秒)。对于小范围的上线使用，我们只用负担公网流量费用和其他资源付费即可。

最常用的函数计算创建方式是控制台进入服务及函数子页面，依次创建服务和函数。一个服务可以由多个函数组成，一个函数只能隶属于一个服务。

当然，阿里云提供了一键式的在函数计算控制台-应用页面，我们可以通过模板和仓库导入来创建：

目前公测中的模板中心包含了各类来自官方或社区的共计 56 个应用或框架模板，覆盖已经相当全面了。在官方文档的指导下可以实现零基础创建 FC 应用。

由繁到简，从长到短

实践：基于 Node.js + Serverless 的 Web 短网址跳转

主要功能：

实现长连接与短链接的映射。

简要描述：

用户可以为指定 URL 创建对应短链

用户访问短链，自动跳转到相应 URL

如上文所说，用函数计算 FC 构建应用总体上要是 FaaS+BaaS。下面的实践项目涉及到 BaaS 数据库的使用，方便起见使用云开发平台搭建应用。

应用架构图如下：

资源预备：

需要注册开通云开发平台并激活以下服务；

API 网关/API Gateway

函数计算/Function Compute

对象存储/Object Storage Service

日志服务/Log Service

MongoDB Serverless 实例

数据库部分：

购买 MongoDB Serverless 版。

新建集合，新建集合其实就相当于新建一个表。创建集合：links、logs。

通过程序代码连接 Serverless 实例，使用方法参见官方文档：
https://help.aliyun.com/document_detail/185473.html

逻辑代码部分示例：

（Attention: 该项目还使用了 Express 框架，以便于简化路由处理）

import storage from '../storage'

export default async (req, res): Promise<any> => {
 // params from request body or querystring
 const params = req.body ?? req.query
 const { url = '', slug = '' } = params as { url?: string, slug?: string }

 // url is required
 if (url === '') {
 return res.status(400).send({ message: 'Missing required parameter: url.' })
 }

 // url format check
 if (!/^https?://.{3,}/.test(url)) {
 return res.status(400).send({ message: 'Illegal format: url.' })
 }

 // custom slug length check
 if (slug.length !== 0 && (slug.length < 2 || slug.length > 10)) {
 return res.status(400).send({ message: 'Illegal length: slug, (>= 2 && <= 10).' })
 }

 const getForwarded = (name: string): string => req.headers[`x-forwarded-${name}`]?.toString() ?? ''

 try {
 // request origin url
 const origin = `${getForwarded('proto')}://${getForwarded('host')}/`

 // if slug customized
 if (slug !== '') {
 const existUrl = await storage.getUrlBySlug(slug)

 // url & slug are the same.
 if (existUrl === url) {
 return res.send({ slug, link: origin + slug })
 }

 // slug already exists
 if (existUrl != null) {
 return res.status(400).send({ message: 'Slug already exists.' })
 }
 }

 // target url exists
 const existSlug = await storage.getSlugByUrl(url)

 // url exists & no custom slug
 if (existSlug != null && slug === '') {
 return res.send({ slug: existSlug, link: origin + existSlug })
 }

 // create if not exists
 const newSlug = await storage.addLink(url, slug)

 // response
 res.send({ slug: newSlug, link: origin + newSlug })
 } catch (e) {
 return res.status(500).send({ message: e.message })
 }
}