无服务架构(Serverless)技术白皮书

Posted 2021-04-30 程序猿的精彩生活

                           

 无服务架构技术

白皮书

（2019年）

 

 

 

 

 

中国信息通信研究院

2019年3月

 

版权声明

本白皮书版权属于中国信息通信研究院，并受法律保护。转载、摘编或利用其它方式使用本白皮书文字或者观点的，应注明“来源：中国信息通信研究院”。违反上述声明者，本院将追究其相关法律责。

 

前言

十几年前云计算横空出世，掀起了物理主机托管的基础设施变革风潮，云计算实现了计算资源与物理硬件的解耦，虚拟化技术的发展运用，使得云主机替代了物理主机，基础设施及服务（IaaS）大行其道。随着容器技术普及，PaaS平台逐渐兴起，原本属于IaaS的运维工作持续下沉，PaaS平台将开发人员与运维人员进一步的分离，开发人员能够更加专注于计算与存储资源的分配与使用。尽管PaaS的使用已经取得了骄人成绩，但仍未达到极致，是否能有一种全新的架构，能将业务与基础设施完全剥离？无服务架构（Serverless）应运而生，Serverless将应用与基础设施彻底分离，开发人员无需关心基础设施的运维工作，只需专注于应用逻辑的开发，仅在事件触发时才调用计算资源，真正做到了弹性伸缩与按需付费。

无服务架构在我国仍在初级阶段，业界对无服务架构的认知尚不清晰，项目实践与成功案例亟待普及。本书将给出无服务架构的定义及其涵盖范围，简述无服务架构的发展历程，剖析架构的优势与不足，介绍无服务架构现有的技术生态体系及其体系内的技术对比，本书还将讨论无服务架构在人工智能、IoT等领域的应用前景。

   

 

目录

版权声明........................................................... 2

一、  初识Serverless............................................... 1

（一）源起....................................................... 1

（二）发展....................................................... 2

（三）概念....................................................... 3

（四）关键技术................................................... 3

（五）适用场景................................................... 6

二、Serverless部署如何下手？....................................... 9

（一）云服务器 VS 容器 VSServerless............................ 10

（二）Serverless化改造.......................................... 13

三、Serverless技术生态现状........................................ 13

（一）  平台层.................................................. 14

（二）  开发框架................................................ 14

（三）  监控/可视化............................................. 14

（四）  测试调试................................................ 15

（五）  存储/数据库............................................. 16

（六）  安全.................................................... 16

（七）  虚拟化环境.............................................. 17

四、Serverless技术发展趋势........................................ 17

五、落地应用案例.................................................. 18

一、Serverless架构助力小米音乐曲库更新效能飙升.................. 18

（二）客户案例-深度学习......................................... 20

（三）客户案例-图片处理......................................... 21

（四）客户案例-数据预热......................................... 22

（五）客户案例-文档实时协同办公................................. 22

（六）客户案例-流式文件处理..................................... 23

 

一、 初识Serverless

（一）源起

基础设施架构总是伴随软件架构演进。单体架构时代应用比较简单，应用的整体部署、业务的迭代更新，物理服务器的资源利用效率足以支撑业务的部署。随着业务的复杂程度飙升，功能模块复杂且庞大，单体架构严重阻塞了开发部署的效率，业务功能解耦，单独模块可并行开发部署的微服务架构逐渐流行开来，业务的精细化管理不可避免的推动着基础资源利用率的提升。虚拟化技术打通了物理资源的隔阂，容器技术则将资源利用的粒度更加细化，尽管如此，资源余量的规划、低频业务资源占用问题仍不能很好的解决。

（二）发展

Serverless的概念最早要追溯到2012年，Ken Fromm在《软件和应用的未来是Serverless》中率先提出了Serverless的概念，但却并未引起太多涟漪。2012年，虚拟化技术带来的巨大变革还在席卷整个IT产业，容器技术方兴未艾，Serverless的概念未免太超前了一些。2014年AWS重磅发布函数计算产品Lambda，将Serverless架构的成熟产品带到世人面前，这一石破天惊的发布正式引爆了Serverless的概念，把Serverless提高到一个全新的层面。Lambda为云中运行的应用程序提供了一种全新的系统体系架构，Serverless开始正式走向云计算的舞台，此后短短几年Serverless产品开始遍地开花。

 

（三）概念

无服务是一种软件架构模型，这种模型将底层基础设施资源彻底剥离出来，由云服务商运维服务器并提供计算资源的动态管理分配，用户无需提前预定资源便可持续的享有弹性资源。

无服务架构具备以下主要特性：

n  以函数（Function）为单位运行代码，用户无需关心容量和底层基础设施资源的配置。

n  触发器通过API将触发事件与执行函数串联起来，执行完整的业务逻辑。

n  自动化的弹性供给运行时环境，包括执行函数以及调用结果反馈所需要的全部必须的底层基础资源（特别是计算、存储、网络和语言环境等）。

n  提供丰富后端服务（BaaS），支撑完整的服务运行。

Serverless架构进一步将运行时环境的配置管理剥离下沉，使得开发人员对服务器的管理配置几乎无感知，仅需专注于应用程序的开发，大大缩减了开发部署时间，更加迅速的响应市场的需求变化。

（四）主要模块

函数即服务（FaaS）是一项基于事件驱动的函数托管计算服务。通过函数服务，开发者只需编写业务函数代码并设置运行的条件，无需配置和管理服务器等基础设施，函数以弹性、免运维、高可靠的方式运行。此外，按函数实际执行资源计费，不执行不产生费用。

使用FaaS有什么好处？

• 改善显影速度

使用FaaS，开发人员可以花更多时间编写应用程序逻辑，而不必担心服务器和部署。这通常意味着更快的开发周转时间。

• 内置可扩展性

横向扩展是完全自动的、有弹性的、且由服务提供者所管理。

• 按需收费

FaaS的计费方式通常是按请求次数及运行时间，一方面可以最大程度利用资源，另一方面真正的按需计费可以降低用户的资源成本。

FaaS的缺点

• 系统控制能力弱

让第三方管理部分基础架构使得很难理解整个系统并增加调试挑战。

• 测试复杂性较高

将FaaS代码合并到本地测试环境中非常困难，使得对应用程序的全面测试成为更加密集的任务。

• 缺乏调试和开发工具

FaaS的生态尚未成熟，配套的工具相对较少，函数化的代码会导致代码提交的次数指数级增长，缺乏监测和调试工具是的故障定位变得异常困难。

后端即服务（BaaS）

后端即服务（BaaS）是一种云服务模型，其中开发人员将Web或移动应用程序的所有幕后方面外包，以便他们只需编写和维护前端。BaaS供应商为在服务器上发生的活动提供预先编写的软件，例如用户身份验证，数据库管理，远程更新和推送通知（用于移动应用程序），以及云存储和托管。

开发人员通过API和由BaaS服务商提供的SDK，能够集成所需的所有后端功能，而无需构建后端应用，更不必管理虚拟机或容器等基础设施，就能保证应用的正常运行。BaaS能让开发人员更加专注于编写前端应用程序代码，以便更快地构建和启动移动应用程序和Web应用程序。

BaaS包含哪些内容？

BaaS提供商提供许多服务器端功能。例如：

• 数据库管理

• 云存储（用于用户生成的内容）

• 用户认证

• 推送通知

• 远程更新

（五）适用场景

CDN边缘网络计算应用

边缘网络计算是指在靠近数据源头的一侧，采用网络、计算、存储、应用核心能力为一体的开放平台，就近提供最近端服务，在网络数据尚未到达服务区域中心之前就能先行处理，减轻中心服务的负担，提升应用的安全等级。使用Serverless技术结合 CDN边缘计算节点，可以提供更加实时、灵活、智能、低成本的边缘计算能力，在流量调度、应用防护、防攻击等层面发挥作用。

多媒体处理

一个常见的用例，也是最早具体化的用例之一，是响应新文件上传执行一些转换过程的函数。 例如，如果将图像上载到诸如Amazon S3的对象存储服务，则该事件触发函数，用于创建图像的缩略图版本并将其存储回另一个对象存储桶或Database-as-a-Service。 这是一个相当原子化，可并行化的计算任务示例，该计算任务不经常运行并根据需求进行伸缩。

数据库更改或更改数据捕获（CDC）

在此场景中，当从数据库插入，修改或删除数据时调用function。在这种情况下，它的功能类似于传统的SQL触发器，几乎就像是与主同步流并行的副作用或动作。其结果是执行一个异步逻辑，可以修改同一个数据库中的某些内容（例如记录到审计表），或者依次调用外部服务（例如发送电子邮件）或更新其他数据库，例如 DB CDC（更改数据捕获）用例的情况。 由于业务需要和处理变更的服务分布的原因，这些用例的频率以及对原子性和一致性的需要可能不同。

IoT/物联网传感器输入消息

随着连接到网络的自主设备的爆炸式增加，额外的流量体积庞大，并且使用比HTTP更轻量级的协议。 高效的云服务必须能够快速响应消息并扩展以响应其扩散或突然涌入的消息。Serverless功能可以有效地管理和过滤来自IoT设备的MQTT消息。 它们既可以弹性扩展，也可以屏蔽负载下游的其他服务。

大规模流处理

另一种非事务性，非请求/响应类型的工作负载是在可能无限的消息流中处理数据。函数可以连接到消息源，而消息必须从事件流中读取和处理。 鉴于高性能，高弹性和计算密集型处理工作负载，这对于serverless而言非常重要。在许多情况下，流处理需要将数据与一组上下文对象（在NoSQL或in-memDB中）进行比较，或者将数据从流聚合并存储到对象或数据库系统中。

聊天机器人

与人类交互不一定需要毫秒级别的响应时间，并且在许多方面，稍微延迟让回复人类的机器人对话感觉更自然。因此，等待从冷启动加载function的初始等待时间可能是可接受的。当添加到Facebook，WhatsApp或Slack等流行的社交网络时，机器人可能还需要具有极高的可扩展性，因此在PaaS或IaaS模型中预先设置一个永远在线的守护程序，以预测突然或高峰需求，可能不会有作为serverless方法的高效或成本效益。

批处理作业或计划任务

每天只需几分钟就能以异步方式进行强大的并行计算，IO或网络访问的作业非常适合serverless。作业可以在以弹性方式运行时有效地消费他们所需的资源，并且在不被使用的当天剩余时间内不会产生资源成本。

HTTP Restful API服务

传统的基于请求和返回的HTTP Restful API服务也适合使用Serverless场景，甚至是托管一个静态的Web站点也可以使用Serverless。尽管在服务第一个用户请求的时候，可能会出现一个稍长的冷启动延迟，但是在以往一些运行模型中，也会出现类似的情况。使用Serverless的优势在于，API的伸缩容粒度可以控制到非常小的返回，例如一个服务的GET、POST、UPDATE、DELETE方法可以独立进行伸缩容，即使他们共享同一个数据后端。

移动后端

使用serverless进行移动后端任务也很有吸引力。它允许开发人员在BaaS API之上构建REST API后端工作负载，因此他们可以花时间优化移动应用程序，而不是扩展后端。

业务逻辑

当与管理和协调function一起部署时，在业务流程中执行一系列步骤的微服务工作负载的编排是serverless计算的另一个好用例。执行特定业务逻辑的function（例如订单请求和批准，股票交易处理等）可以与有状态管理器一起安排和协调。来自客户端门户的事件请求可以由这样的协调function提供服务，并传递给适当的serverless function。

持续集成管道

传统的CI管道包括一个构建从属主机池，它们处于空闲等待以便分派作业。Serverless是一种很好的模式，可以消除对预配置主机的需求并降低成本。构建作业由新代码提交或PR合并触发。 调用function来运行构建和测试用例，仅在所需的时间内执行，并且在未使用时不会产生成本。这降低了成本，并可通过自动扩展来减少瓶颈以满足需求。

二、Serverless部署如何下手？（暂未想好怎么组织，报一部分内容）

虚拟机、容器和无服务都对IT基础设施资源做了抽象，但三者之间也存在显著差异，虚拟机抽象硬件，容器虚拟化操作系统，无服务器技术则虚拟化运行时。无服务架构并不能够完全替代虚拟机及容器的应用，在部署方式、安全隔离程度、生态完整程度、场景适用性等方面各有千秋，拥有各自有的技术受众。

虚拟机、容器、Serverless如何选择？

（二）Serverless化改造

增加现有业务serverless化改造的描述。方法论、具体改造方法。

 

三、Serverless技术生态现状

目前我国Serverless的技术生态主要活跃在公有云的fPaaS领域，国内主要云服务商都具备fPaaS产品，与之匹配的BaaS服务也日臻完善，公有云服务基本可满足用户无服务应用的搭建。私有云的解决方案领域仍旧以国外开源技术为主，Serverless私有云解决方案提供商多处在产品研发阶段，成熟产品尚属稀缺。独立BaaS服务（开源、商业产品）主要集中在国外，国内BaaS服务主要供给各家公有云产品配套使用。

文章下述将对Serverless技术生态中的每一环做简要介绍，并对其中的典型产品予以剖析：

（一）          平台层

平台层提供全托管的运行环境，提供函数单元所需的计算环境并自行维护服务器资源、网络资源、消息分发和负载均衡等功能。是整个Serverless架构的基础。

• 华为云函数工作流

函数工作流（FunctionGraph）是华为云提供的一款无服务器（Serverless）计算服务，无服务器计算是一种托管服务，服务提供商会实时为你分配充足的资源，而不需要预留专用的服务器或容量，真正按实际使用付费。华为无服务器计算包含函数和工作流两个功能模块，分别实现函数计算和函数编排的功能。

FunctionGraph函数是一项基于事件驱动的函数托管计算服务。使用FunctionGraph函数，只需编写业务函数代码并设置运行的条件，无需配置和管理服务器等基础设施，函数以弹性、免运维、高可靠的方式运行。此外，按函数实际执行资源计费，不执行不产生费用，具有以下特点。

Ø  提供多种Runtime，适应各种编程需求。

Ø  支持多种事件源触发函数，满足复杂的业务需求。

Ø  提供图像化函数指标页，实时监控函数运行情况。

Ø  提供详细的日志信息，方便排查函数错误。

Ø  提供多种使用场景的函数模板，实现模板代码、触发器、运行环境自动填充，快速构建应用程序。

Ø  提供函数初始化入口，分离初始化逻辑和请求处理逻辑。

FunctionGraph提供可视化的工作流，用以编排分布式应用函数和微服务组件。用户可以使用一系列能够单独执行的离散函数构建应用程序，并且能够快速扩展和更改，满足快速增长的、复杂的业务需求，具有以下特点。

Ø  提供图形控制台

Ø  使函数（程序）编排可视化，简化多步骤应用函数（程序）的构建和运行。

Ø  自动触发和跟踪各个步骤

Ø  使应用程序按照预期顺序执行，并在出现错误时重试。

Ø  记录每个步骤的状态

Ø  在出现错误时，能够迅速定位并调试问题。

Ø  简化应用程序的扩展和更改

Ø  无需编写代码就可以更改和添加步骤，可以轻松地完善应用程序。

函数平台	华为云	阿里云	腾讯云	京东云	百度云	Lambda
函数内存（MB）						64*K (K=2,3,4…24)
CPU						与内存成比例
Runtime OS						Amazon Linux
部署方式						只支持zip包上传
语言环境						Java、C、C#、Python、php、Go等
环境依赖						每种语言不同的
触发器类型						AWS服务+API Gateway
函数最长执行时间						300S
日志监测工具						CloudWatch Logs and X-Ray
计费特点						函数执行时间 分配内存大小

私有云解决方案

Knative

Knative扩展了Kubernetes，提供了一组中间件组件，这些组件对于构建可在任何地方运行的现代，以源为中心和基于容器的应用程序至关重要：内部部署，云端部署，甚至是第三方数据中心。

Knative项目下的每个组件都尝试识别常见模式，并编纂成功的，真实的，基于Kubernetes的框架和应用程序共享的最佳实践。 Knative组件专注于解决平凡但困难的任务，

 

 

（二）          开发框架

• Serverless Framework

ServerlessFramework是一款开源的命令行工具，方便用户快速构建和部署Serverless化的应用。通过framework用户可直接通过YAML文件定义函数参数、上传代码、函数编排，完成应用的serverless化部署。使用单一工具便可轻松在各个Function PaaS间进行切换，目前serverless framework支持谷歌云、微软云、AWS、OpenWhisk以及基于kubernetes构建的fPaaS平台。

 

（三）          监控/可视化

无服务架构的应用通常会部署成百上千个function和API，访问调用的复杂性急剧上升。通过监控/可视化工具，可帮助用户/运维人员监测链路状态，快速定位问题源头。

• Cloud Zero

Cloud Zero无服务器可靠性管理平台是一种功能强大的SaaS技术，可帮助开发人员监控无服务器系统并定期获取必要的见解。无服务器可靠性管理是一种解决方案，可以在复杂性影响系统之前预测并主动发现问题。与其他技术不同，CloudZero平台预测系统脆弱性，以便工程师可以在信任受损之前主动优化系统可靠性。该工具侧重于变更管理，通过识别异常行为，找出系统中发生的变化，然后发现负责变更的内容。

（四）          测试调试

Dashbird的用户界面简单易用，可以实时的查看更新和强大的警报系。由于Serverless没有开发环境（development staging），开发人员必须运行Functions查看它们真实的运行情况，若没有按预期执行要找出原因。 Dashbird有一个用于Serverless框架的开源Serverless离线插件可以模拟Lambda操作和API网关，用来创建测试环境并用于调试。

Dashbird可以检测所有编程语言类型的故障。包括无服务器特有的崩溃，早期退出，超时和配置错误。Dashbird目前具有仪表板视图，可提供无服务器架构性能的概述，并可与Slack集成以根据需要提供关键报告。可以查看有关错误，调用，持续时间，内存使用情况和代码。获取使用日志和运行时数据进行故障排除和分析调用所需的可观察性

（五）          存储/数据库

Firebase主要利用实时后端数据库帮助开发者很快的写出Web端和移动端的应用。在存储和数据库方面，使用专为类似于 Google 这种规模级别的应用打造的功能强大、操作简单且经济有效的对象存储服务，轻松地存储和分享图片、音频、视频或其他用户生成的内容。无论网络质量如何，适用于 Cloud Storage 的 Firebase SDK 都能为Firebase 应用提供安全品质的文件上传和下载服务。使用云托管的数据库存储数据以及在各个用户和设备之间实时同步数据。更新后的数据会在数毫秒内同步到各个已连接的设备，且数据在应用离线后仍然可用，无论网络连接状况如何，都能提供良好的用户体验。

（六）          安全

Snyk是一家网络安全公司，可帮助开发人员使用开源代码并保持安全。Snyk独特的以开发人员为中心的产品使开发人员和企业安全性能够在不降低速度的情况下持续查找和修复易受攻击的依赖项，并与Dev＆DevOps工作流程无缝集成。Snyk通过自动更新和修补程序查找存储库中的漏洞并修复风险。阻止CI / CD中易受攻击的库并监视PaaS /无服务器应用程序的依赖性缺陷。

（七）          虚拟化环境

Firecracker是一种基于Linux内核的虚拟机（KVM）技术的开源虚拟机监控程序(VMM)。Firecracker允许创建微型虚拟机。它仅包含运行安全、轻量的虚拟机所需的组件。其设计依据安全性、速度和效率等要求来优化 Firecracker。它以极低的开销执行容器和无服务工作负载的更多信息，结合了硬件虚拟化技术提供的安全性与隔离性和容器的速度与灵活性。Firecracker的开源原则有如下几条，内置安全性：提供了支持多租户工作负载并且不会被客户错误禁用的计算安全性屏障。轻量虚拟化：重视瞬时性或无状态的工作负载，而非长时间运行或持续性的工作负载。其硬件资源开销是明确且又保障的。功能极简主义：不会构建非任务所明确要求的功能。仅维护每个功能的单独实现。

四、Serverless技术发展趋势

无服务器的未来尚不确定，因为它仍然是一项相对年轻的技术。随着生态系统环境不断完善和安全以及物联网的发展，我们目前所知道的IT基础设施在未来几年可能会发生根本变化。IBM Cloud副总裁兼首席技术官Jason McGee 在2017年ServerlessConf上表示，IBM分析师预测到2021年无服务器市场将增长7-10倍，这意味着云供应商正在注意AWS Lambda的早期成功。一个市场和市场报告预测较小，但也相当可观增长，预测无服务器市场从$ 1.88十亿的市场在2016年到2021年（411％）的将增长到$ 7.72十亿。

从Serverless技术自身的发展角度，未来的发展趋势：

无服务器和安全性

无服务器架构提供了独特的安全优势，在一定程度上降低了网络攻击的风险。通过Serverless，由于计算是在外部进行管理的，DDoS攻击和其他威胁对企业的影响会减小很多。此外，无服务器功能的弹性和自动缩放功能可在系统中留下更少的漏洞和软点，同时也降低了服务器上被安装恶软件或者遭受攻击的概率。

。。。。。。

从Serverless与产业行业的应用前景角度，未来的发展趋势：

无服务器和物联网

当与世界上越来越多的物联网  连接设备协同工作时，无服务器计算可以带来很大的好处。由于第三方的管理，它不仅在分配资源方面为公司提供了更大的灵活性，而且还提高了速度，因为它只运行公司实际使用的业务功能。

因此，如果配送公司使用物联网传感器通过无服务器模型跟踪车队，则可以在迟到的情况下触发传感器以通知接收方。或者，更重要的是，如果发生事故或紧急情况，可以触发传感器，以便向最近的医院提供位置和严重程度的数据。

。。。。。。

五、落地应用案例

一、Serverless架构助力小米音乐曲库更新效能飙升

小米音乐需要定期更新曲库，从而给用户提供更好的音乐服务，更新曲库的时间不确定，但是更新一次需要处理的数据量比较大，一般是几百个TB的音乐数据，处理完成需要数天。处理的流程如下：

小米音乐早期架构

音乐文件存储到小米的文件存储服务器FDS Bucket之后，需要有一个控制结点来不断扫描FDS Bucket的文件，然后把已处理的文件记录到数据库中，对于未处理的文件，推入到小米的消息队列当中。另外还需要工作结点集群来处理这些音乐文件，对文件进行转码，加密，最后把音乐入库。

业务痛点：

• 工作结点扩容和缩容，完全依赖经验，一般会根据最大的量评估工作结点的规模，没有任务处理的时候浪费资源。

• 需要有控制结点来不断的轮询FDS Bucket，但并不是需要一直来处理音乐文件，只有在需要新增或者更新曲库的时候才需要处理，在空闲的时候造成了资源的浪费。

• 部署困难，即使一次小的改动，也需要去重新编译部署整个项目。

在小米函数计算服务上线后，小米音乐决定重构自己的架构，采用无服务器的方式来处理音乐文件，重构后的架构如下：

Serverless改造后的架构

重构后的架构去除了所有的服务器资源，也不需要使用消息队列来接受任务，只需要编写核心的业务逻辑就可以了，由此带来的提升是很显著的：

• 小米音乐团队不需要去运维和管理服务器资源了，大大节约了运维成本

• 音乐转码，加密的任务只会在需要的时候才会被触发，函数计算服务才会给任务分配计算资源，从整体上提高了资源利用率

• 不需要担心任务执行失败，函数计算服务会自动重试失败的任务

• 部署发布更方便，小米音乐可以根据不同的功能打包成干个函数，使用函数计算服务管理函数的不同版本，并能够方便的切换不同的版本。

（二）客户案例-深度学习

当某公司的客户上传大量图像数据后，需要尽快把图像按照客户指定的方式处理，包括商品识别，纺织面料等柔性材质识别分析，内容审查，以图搜图等等。图像处理基于预先训练好的深度学习模型，要求在短时间内准备大量的计算资源进行大规模并行处理。

• 解决方案

客户将深度学习推理逻辑实现为函数，在函数中加载模型后对图像数据进行处理。通过函数计算提供的大规模计算能力，客户能够短时间处理大量图像，平稳应对峰值压力。

• 使用效果

客户不再需要维护基础设施的工作，开发效率大幅提高，两周内功能开发上线。客户能够便捷的创建多个函数来验证不同深度学习模型的推理效果，快速迭代系统，加速业务创新。函数计算的实时伸缩确保客户应用在遇到峰值负载时提供足够的计算资源，改善了服务质量。此外，客户只需要为实际使用的资源付费，避免了资源闲置，整体成本节省了30%。

（三）客户案例-图片处理

某公司的客户端上显示多种格式的图片，为了适配不同的手机屏幕和操作系统，需要对图片进行个性化 的处理。微博有海量用户，系统每日要能处理海量 的调用请求，并保持稳定的延时。

• 解决方案

公司客户端将用户上传的图片存储到阿里云对象存储中，在函数中实现个性化的图片处理逻辑。手机客户端 获取图片时，通过阿里云 CDN 服务回源到函数计 算，函数从阿里云对象存储中下载原图，实时处理后将结果图片返回。

• 使用效果

客户只需要专注于图片处理逻辑的开发，工程效率大幅提高。函数计算自动实时扩容底层计算资源， 确保应用在负载动态变化时仍能保持稳定的延时， 平滑处理海量的调用请求。客户不再为峰值负载预 留计算资源，降低了成本。

（四）客户案例-数据预热

某广电视频公司的短视频上传后，客户的后端系统需要实时处理上传的数据，当数据量较大的时候会有排队现象，如果设置多台服务器处理，在业务低谷的时候，资源闲置浪费。

• 解决方案

当用户把视频文件上传到对象存储后，会自动触发对应的函数把视频文件的属性信息记录下来，并传输给客户的核心算法系统，核心算法系统计算出视频文件的热度，并把视频文件的源文件推送到最近的 CDN 的节点上，起到数据预热的功能。

• 使用效果

整个流程无需人工干预，函数计算高效的监听阿里云对象存储的事件，并能快速把数据传输到后端算法系统，提高处理效率。在上传视频高峰期利用函数计算的弹性伸缩，确保所有事件都能被及时处理。

（五）客户案例-文档实时协同办公

多位用户在同一文档/表格上协同编辑时，有可能对同一内容进行了修改，产生冲突。该公司需要实现一套服务来实时处理文档编辑冲突，并能在合理的成本下平滑处理峰值负载。

• 解决方案

将文档实时协作等计算密集型的逻辑实现为函数，通过 HTTP 请求触发函数执行。

• 使用效果

借助函数计算毫秒级别的资源伸缩能力，解决了早晚高峰用量突增的计算资源扩容问题，并节省了 58% 的服务器成本。由于不用再考虑 CPU 密集型计算的负载均衡问题，大大提高了开发效率和进程稳定性。

（六）客户案例-流式文件处理

用户访问某网盘公司产生海量的访问日志。客户需要对日志数据进行压缩，格式转换等操作，并把处理后的数据存储到数据库或者对象存储里，整个系统架构需要考虑高并发和实时处理能力。

• 解决方案

客户使用阿里云日志服务（LogHub）存储日志，使用函数计算处理日志。当日志以流的方式源源不断写入时，阿里云日志服务会自动触发客户的函数对数据进行处理，按照业务规则把日志进行压缩、转换后存放到数据库或者对象存储中。

• 使用效果

用户无需维护服务器，只需要把处理逻辑实现为函数就能流式的，实时的处理日志，开发效率大幅提高。客户将日志写入阿里云日志服务后，函数被自动触发处理日志数据。系统的每个环节都是可靠而弹性的，轻松应对客户动态变化的负载。

对话式语音助理应用

语音助理类应用利用对话式人工智能技术与用户建立交互场景。语音助理类应用平台可以通过「技能」的形式将引入各类对话场景。第三方开发者可以通过技能开放平台将自己的产品与服务集成到搭载了语音助理类应用的产品中，例如智能音箱。一则「技能」一般会包含多轮语音对话，第三方开发者需要提供相应的服务满足技能的对话需求。

语音对话往往不需要非常快的响应速度，甚至略带延迟的响应会让对话的节奏变得更加自然。因此，对话技能服务对Serverless技术带来的冷启动延迟并不敏感。同时，使用Serverless部署该类服务，相比于PaaS或IaaS的模式，在应对突发的对话高峰时，服务的伸缩容会更加灵活。