Serverless的简单介绍

Serverless架构是近年来迅速兴起的一个技术概念。基于这种架构能构建出多种应用场景，适用于各行各业。只要是对轻计算、高弹性、无状态等场景有诉求，您都可以通过本文来熟悉一些基础概念，并从相关场景中获得启发。

Serverless 演进

关于Serverless架构的演进，网上比较流行用一张人类形态发展史图进行说明。从爬行猿人到蹲着的类猿人，再到直立人类，最后到使用工具的新兴人类。人类的每一次进化都伴随着生产效率的提升。同理，整个IT计算的发展历程，也是一个逐步提高生产效率的历程，具体演进图如下所示：

在这个发展历程中有以下几个渐进的里程碑事件：

1. 通过虚拟化技术将大型物理机虚拟成单个的VM资源。
2. 将虚拟化集群搬到云计算平台上，只做简单运维。
3. 把每一个VM按照运行空间最小化的原则切分成更细的Docker容器。
4. 基于Docker容器构建不用管理任何运行环境、仅需编写核心代码的Serverless架构。

因此，这个发展历程也是一场IT架构的演进，期间经历了一系列代际的技术变革，把资源切分得更细，让运行效率更高，让硬件软件维护更简单。IT架构的演进主要有以下几个特点：

• 硬件资源使用颗粒度变小
• 资源利用率越来越高
• 运维工作逐步减少
• 业务更聚焦在代码层面

Serverless架构主要有以下特点：

• 实现了细粒度的计算资源分配。
• 不需要预先分配资源。
• 具备真正意义上的高度扩容和弹性。
• 按需使用，按需计费。

根据Serverless的这些通用特点，归纳出下面几种典型使用场景，供大家参考。

Serverless的典型应用有哪些？

事件请求场景

• 定制图片网店店家进行商品图片维护时，需要根据商品陈列位置，将图片动态切割成不同尺寸，或者打上不同水印。当店家把图片上传到对象存储 OSS上，会通过函数计算上定制的trigger来触发函数计算。根据计算规则，生成不同尺寸的图片，满足在线商品陈列需求，整个过程无需再搭建额外服务器，也无需网站美工干预。
• 物联网中的低频请求物联网行业中，物联网设备传输数据量小，且往往是以固定时间间隔进行数据传输，因此经常涉及低频请求场景。例如：物联网应用程序每分钟仅运行一次，每次运行 50ms，这意味着CPU的使用率仅为 0.1%/小时，或者说有 1000 个相同的应用可以共享计算资源。而Serverless架构下，用户可以购买每分钟 100ms 的资源来满足计算需求，既能有效解决效率问题，也能降低使用成本。
• 定制事件用户注册时发邮件验证邮箱地址，同样可以通过定制的事件来触发后续的注册流程，而无需再配置额外的应用无服务器来处理后续的请求。
• 固定时间触发事件触发固定时间触发，例如在夜间或者服务空闲时间来处理繁忙时候的交易数据，或者运行批量数据，来生成数据报表，通过Serverless方式，不用再额外购买利用率并不高的处理资源。

流量突发场景

• 弹性扩展应对突发流量移动互联网应用经常会面对突发流量场景。例如：移动应用的通常流量情况是 QPS 20，但每隔 5 分钟会有一个持续 10s 的 QPS 200 流量（10 倍于通常流量）。传统架构下，企业必须扩展 QPS 200 的硬件能力来应对业务高峰，即使高峰时间仅占整个运行时间的4%。在Serverless架构下，您可以利用弹性扩展特性，快速构建新的计算能力来满足当前需求，当业务高峰后，资源能够自动释放，有效节省成本。
• 转码和流量扩容视频直播某次专场活动，由于无法预估会有多少点播的观众视频接入，把转码和流量扩容这部分内容通过Function来处理，无需考虑并发和流量扩容。

处理大数据场景

由于安全审计问题，您需要从OSS（多个地域）过去一年的数据（1 个小时一个文件）中找出特定关键字访问的日志，同时做聚合运算（计算出总值）。如果使用阿里云函数计算，您将高峰期每 2 小时的访问日志，或者低谷期每 4 小时的访问日志交给一个计算函数处理，并将处理结果存到RDS中。使用一个函数分派数据给另一个函数，使其执行成千上万个相同的实例。

这样会同时运行近千个计算函数（24 x 365 / 10），在不到一分钟的时间内完成整个工作。同样的事情交给ECS+计算脚本来做计算，单单为这些instance配置网络就让人头疼（不同地域无法走内网下载OSS文件）：instance的数量可能已经超出了子网中剩余IP地址的数量（比如，您的VPC使用了24位掩码）。

下面结合阿里云的函数计算产品来讲解各个应用场景中地架构以及如何解决场景中的痛点。阿里云的函数计算是基于Serverless这种架构实现的一个全托管产品，用户只需要上传核心代码到函数计算，就可以通过事件源或者SDK&API来运行代码。函数计算会准备好运行环境，并根据请求峰值来动态扩容运行环境。函数计算是按照执行时间来计费，请求处理完成后，计费停止，对于有业务请求有明显高峰和低谷的应用来说，相对节省成本。下图是函数计算的一个开发者试用操作流程：

1. 开发者编写代码，目前支持的语言Java、NodeJS、Python等语言。
2. 把代码上传到函数计算上，上传的方式有通过API或者SDK上传，也可以通过控制台页面上传上传，还可以通过命令行工具Fcli上传。
3. 通过API&SDK来触发函数计算执行，同样也可以通过云产品的事件源来触发函数计算执行。
4. 函数计算在执行过程中，会根据用户请请求量动态扩容函数计算来保证请求峰值的执行，这个过程对用户是透明无感知的。
5. 函数执行结束后，可以通过账单来查看执行费用，根据函数的实际执行时间按量计费，收费粒度精确到100ms。

讲解完上面的流程后，下面会详细讲解3个Serverless的应用场景，通过案例分享能让您对Serverless这种架构有更清晰的认识。

场景一：事件触发计算能力

场景描述

用户通过手机终端、Web应用、或者PC工具把各种文件包括图片、视频以及文本等上传到OSS（对象存储，下同）后，利用OSS的PutObject事件可以触发函数计算对上传后的文件进行处理。

典型场景

当用户把视频文件上传到OSS后，触发函数计算把对象的Meta信息获取并传输给核心算法库，核心算法库根据算法把相应的视频文件推送CDN源站，达到特定视频热加载的处理。另外一个场景，视频文件上传到OSS后也同时触发函数计算同步做多转码率的处理，并把处理后的视频文件存储到OSS中，完成轻量的数据处理。

在多媒体的处理场景中，经常会碰到海量文件上传到OSS后，还需要对文件进行进一步的加工，例如加水印、转码率、获取文件属性等操作，这个场景中，用户在处理的时候会遇到以下需要解决的技术难点：

• 如何接收文件上传后的动作事件，通常的做法是定制消息通道来接收OSS事件通知，搭建一个运行环境，并编写相关的代码来处理事件通知。
• 如何高效的处理完海量上传的文件。
• 如何无缝的把多个云产品连接起来。

通过函数计算能比较方便解决以上几个技术难点：

• 函数计算可以设置OSS的触发器来接收事件通知，在函数计算中编写业务代码来处理文件，并通过内网把文件传输到OSS中，整个流程简单易用可扩展。
• 可以把核心代码部署到函数计算中，通过函数计算来并发处理事件通知。
• 函数计算目前打通了多款产品的内部交互，通过控制台简单配置就可以高效的解决产品间连接问题。

事件触发场景常规做法：

• 设置消息通道接收事件，并编写业务代码。
• 购买服务器资源做后端数据处理。
• 设计一套多并发框架完成业务上传文件峰值的处理。
• 开通多个产品，并调用SDK代码来完成业务交互。

函数计算解法：

• 在控制台上配置事件源通知，编写业务代码。
• 代码写到函数计算里，不需要管理软硬件环境。
• 业务高峰期函数计算会动态伸缩，无需管理。
• 内置打通多款产品，简单配置就可以无缝对接。

场景二：利用弹性扩容（视频直播多人连麦场景）

场景描述

直播间的客户端把主播和连麦观众的音视频采集发送给函数计算做混流服务，函数计算把数据汇集后交给混流服务进行合成，并把合成画面视频流推送给CDN，终端观众实时拉取直播流，能实时看到混流合成画面。

视频直播应用场景中，有一种场景视频直播的多人连麦，主播可以同时和多个工作进行连麦，把多个观众或者好友画面接入，并把画面合成到一个场景中，供给更多观看直播的观众观看。这个场景中，有几个技术难度需要关注：

• 连麦的观众不固定，需要考虑适度的并发和弹性。
• 直播不可能 24 小时在线，有较为明显的业务访问高峰期和低谷期。
• 直播是事件或者公众点爆的场景，更新速度较快，版本迭代较快，需要快速完成对新热点的技术升级。

综合以上几个特点，可以通过Serverless这种架构来完美地解决以上痛点。

函数计算作为连麦观众和主播接入的实时音频和视频转发集群，当并发量过来时，函数计算自动扩容多个执行环境来处理实时数据流；当业务高峰期过去后，会适度缩减资源使用。代码管理部署在云端，代码迭代可以随时进行修改和维护，无需再多管理一套软件运行环境。

视频直播场景常规做法：

• 购买负载均衡应付并发。
• 购买计算资源做数据处理。
• 业务低谷期需要想办法释放硬件资源来节省成本。
• 多版本要维护多套运行环境。

函数计算解法：

• 把负载分发程序写到函数里。
• 多版本迭代无需更换运行环境，仅仅替换代码版本即可。
• 业务访问按需付费，业务低谷期无费用。

场景三：物联网数据处理场景

整个架构图分成 2 部分内容：

• Web应用：模拟一个社交内容更新和数据处理的流程，Web用户通过API网关把请求转发到函数计算进行处理，函数计算把处理后的内容更新到数据库中，并更新索引，另外一个函数计算把索引更新推送的搜索引擎供给外部客户进行检索，完成整个数据闭环处理。
• 智能设备：通过IoT网关把设备状态推送到函数计算处理，函数计算通过API接口把消息通过移动推送服务，推送给移动端进行状态确认和管理。

在智能设备状态处理的场景中，同样也会碰到几个核心技术问题要解决。当海量设备把状态发送到IoT平台后，如何设计一套高效非轮询的技术框架来处理设备状态数据；如何把处理后的数据高效透传其他产品，例如写数据库或者推送给移动端。

IoT设备状态场景常规做法：

• 设置消息通道接收事件，并编写业务代码。
• 购买服务器资源做后端数据处理。
• 开通多个产品，并调用SDK代码来完成业务交互。
• 维护相关硬件软件环境。

函数计算解法：

• 定制IoT平台的事件通知，直接把业务代码写到函数计算中。
• 不需要维护运行环境，用完即可释放。
• 控制台配置，就可以把信息透传给相关产品。

通过 2 种方式的对比，能看出函数计算的解法更具备通用性，可以大量减少维护工作。

场景四：共享派单系统详解

客户通过派单平台选着某种商家提供的服务，可能是餐饮、商品、或者服务。派单平台通知最近的骑手到最近的商家拿到服务并派送到客户手里。一个简单的流程图如下：

流程详解：

1. 客户通知派单平台下单某商品。
2. 派单平台通知最新骑手。
3. 派单平台同时通知商家商品售卖出去。
4. 骑手到指定的商家获取商品。
5. 骑手配送到客户所在地。

这个派单场景中，要解决几个棘手的技术：

• 整合多种资源，计算资源会涉及到，骑手位置信息、最优路径规划、车况情况、调度系统等。
• 低延迟：派单系统对订单的响应要求很高，从接单到商家在到客户，整个闭环都需要在段时间内完成。
• 海量数据：涉及到三方面的数据，客户数据、商家数据、平台骑手数据、位置信息、商品信息等。
• 请求明显波峰波谷：派单系统在一天中的资源使用非常不均衡，波峰期，例如外卖，在中午和晚饭达到高峰，平时空闲。

通过技术选型转化成阿里云产品的解决方案后，函数计算结合其他产品比较完美地解决上述问题，解决方案如下图所示：

流程详解：

1. 客户APP把订单请求通过API网关透传给函数计算。
2. 函数计算把处理后的数据传输给表格存储。
3. 表格存储存放了骑行数据、商家信息、位置信息等。说明 其中骑行日志会存放到日志服务里，便于后续做报表分析。骑行过程中骑手头像、随手拍街景会存放到OSS中，骑手位置可以通过函数计算去拉取第三方地图信息，例如高德地图等。

这个方案中，函数计算可以完成动态扩容问题，API网关可以解决鉴权和安全访问问题，函数计算打通了多款产品，可以无缝使用其他资源和内容。所有处理后的数据可以存放到表格存储数据库中，所有日志都可以直接加载到日志服务为后续数据报表服务。

共享派单系统常规做法：

• 购买多台服务器来支持高峰期的访问，访问波谷期自行设置释放原则。
• 通过编程方式完成多个产品的交互。
• 为了保证负载均衡，需要购买相关的产品来支撑。
• 维护相关硬件软件环境。

函数计算解法：

• 定制IoT平台的事件通知，直接把业务代码写到函数计算中。
• 不需要维护运行环境，用完即可释放。
• 控制台配置，就可以把信息透传给相关产品。
• 2种解法都能达到目标，从资源利用率和可维护性来看，使用Serverless架构的方式会更优。

总结

通过上面几个场景的详解，大致可以得出这样的结论：通过事件触发场景；有业务访问高峰和低谷的场景，迭代次数较多，需要快速打通多款产品场景；通过函数计算能完美地解决成本、效率、联通等问题。

函数计算虽然适用于很多场景，但也不是覆盖全部应用场景的万金油。例如某些业务在一天中没有明显的请求波峰波谷，请求相对平缓，那么使用函数计算成本不见得会节省多少。

Serverless框架作为新兴的技术，目前相应的支持开发工具较少，整体框架还在探索中。另外，函数计算的执行环境是不记录状态的，有些耦合性较强的应用也不太适合用Serverless这种框架。受限于资源大小分配，一些大型的应用程序也不太容易能拆分搬上来。