先行一步，7 大技术创新和突破，阿里云把 Serverless 领域的这些难题都给解了

摘要：函数计算 FC 首创 GPU 实例、业内首发实例级别可观测和调试、率先提供端云联调和多环境部署能力、GB 级别镜像启动时间优化至秒级、VPC 网络建连优化至200ms，Serverless 应用引擎 SAE 支持微服务框架无缝迁移、无需容器化改造、业内首创混合弹性策略，这些创新和突破，将 Serverless 领域的技术难题给解了，彻底跨越了影响 Serverless 进一步落地企业核心生产场景的绊脚石。

“即使云计算已经兴起，但是大家的工作仍然是围绕服务器，不过，这个不会持续太久，云应用正在朝着无服务器的方向发展。”

这是 Ken Form 在 2012 年的一篇《Why The Future of Software and Apps is Serverless》文章中提出的关于未来云计算的观点。

Serverless First：从云厂商主张到客户主见

Serverless 与身俱来的弹性能力和容错能力，很好的契合了企业在线业务的弹性和稳定性的双重诉求，成为企业云上架构演进的新方向。

时至今日，随着越来越多的大中型企业将传统后端领域对扩容有灵活需求的执行单元剥离出来，运行在 Serverless 架构上，以及更注重研发和交付效率的创业团队将业务全部 Serverless 化，Serverless First 的理念更加深入人心，使得越来越多的云上工作负载运行在无服务器上。

数字上的变化代表了技术的市场成熟度。

根据 Datadog 今年的一份报告，Datadog 上一半的 AWS 客户使用了 Lambda，80% 的 AWS 容器客户使用了 Lambda，而且这些用户每天调用函数的次数是两年前的 3.5 倍，运行时长达 900 小时/天。再看看国内的市场，根据 CNCF 今年发布的《2020中国云原生调查报告》，31% 的企业正在生产中使用 Serverless 技术，41% 正在评估选型，12% 计划在未来 12 个月内使用。

10月21日，云栖大会云原生峰会现场，阿里云 Serverless 重磅发布了一系列技术突破，集中解决了行业面临的难点和痛点。随之而来的是各大企业在 Serverless 上的大规模实践，例如网易云音乐使用 Serverless 技术构建离线音视频处理平台、南瓜电影7天全面 Serverless 化，并基于此，建立了业务的监控、发布和弹性系统。

从 First 到 Faster，FC 7大技术突破，跨越影响 Serverless 发展的绊脚石

Serverless 的本质是通过屏蔽底层的计算资源，来实现业务层开发的专注度和自由度。但越是往上抽象，云厂商在底层的实现就越是复杂。函数计算将服务进一步拆分到函数的颗粒度，这势必会给开发、运维、交付等带来新的挑战，例如如何对函数进行端云联调、如何对函数进行可观测和调试、如何优化 GB 级别的镜像冷启动？这些以往在服务的颗粒度时，都不是问题的事情，成了 Serverless 大规模落地企业核心生产业务的绊脚石。

阿里云函数计算团队自去年进入 Forrester 领导者象限后，继续攻克业内的这些技术难题，并在此次云栖大会重磅发布了7大技术创新和突破。

Serverless Devs 2.0：业内首发 Desktop，支持端云联调、多环境部署

开源近一年， Serverless 开发者平台 Serverless Devs 2.0 版本正式发布。相比 1.0 ，2.0在性能、使用体验实现全方位提升，业内首发桌面客户端 Serverless Desktop，对桌面客户端进行了精细设计兼具美感和实用主义，具备更强的企业级服务能力。

作为业内首个支持主流 Serverless 服务/框架的云原生全生命周期管理的平台，Serverless Devs 致力于为开发者打造 Serverless 应用开发一站式服务，Serverless Devs 2.0 提出多模式调试方案，包括打通线上线下环境；本地对接线上环境并进行调试的端云联调方案、本地直接进行开发态调试的本地调试方案、以及云端运维态调试的在线调试/远程调试方案等。新版本增加多环境部署部署能力，Serverless Devs 2.0 已支持一键部署框架 30 余种，包括 Django，Express，Koa，Egg，Flask，Zblog，Wordpress 等。

业内首发实例级别可观测和调试

实例是函数资源最小的可被调度的原子单位，类比容器的 Pod。Serverless 将异构基础资源高度抽象，因此“黑盒问题”是 Serverless 大规模普及的核心落地之痛。业内同类产品均没有透出“实例”概念，也从未在可观测功能中将 CPU、内存等指标透出，但可观测就是开发者的眼睛，没有可观测，何谈高可用呢？

函数计算重磅发布实例级别可观测能力，对函数实例进行实时监控和性能数据采集，并进行可视化展示，为开发者提供函数实例端到端的监控排查路径。通过实例级别指标，您可以查看 CPU 和内存使用情况、实例网络情况和实例内请求数等核心指标信息，让“黑盒”不黑。同时，函数计算将通过开放部分实例登录权限，做到既能观测，还能调试。

业内首发固定数量、定时、水位自动伸缩的实例预留策略

函数计算冷启动受到多个因素影响：代码和镜像大小、启动容器、语言运行时初始化、进程初始化、执行逻辑等，这依赖用户和云厂商的双向优化。云厂商会自动为每个函数分配最合适的实例数量，并进行平台侧的冷启动优化。但对于某些在线业务时延非常敏感，云厂商无法代替用户进行更深层的业务优化，如对代码或依赖进行精简、编程语言的选择、进程的初始化、算法优化等。
业内同类产品普遍是采用预留固定实例数量的策略，即让用户配置 N 个并发值，除非手动调整，否则在分配了 N 个实例后不会再伸或者缩。这种方案只解决了部分业务高峰期的冷启动延时，但大大增加了运维成本和资源成本，对红包大促等带有不定期峰谷的业务，其实并不友好。

因此，函数计算率先将部分实例资源的调度权限授予用户，允许用户通过固定数量、定时伸缩、按水位伸缩、混合伸缩等多维度的实例预留策略，来预留适量函数实例，分别满足业务曲线相对平稳（如AI/ML场景）、峰谷时间段明确（如游戏互娱、在线教育、新零售等场景）、突发流量无法预估（如电商大促、广告等场景）、业务混杂（如Web后台、数据处理等场景）等不同场景的诉求，从而降低冷启动对时延敏感型业务的影响，真正实现弹性和性能兼顾的终极目标。

业内率先推出 GPU 实例

函数计算提供弹性实例和性能实例两种实例类型，弹性实例规格从 128 MB 到 3 GB，隔离粒度做到了整个云生态最细，能真正实现普适场景下资源利用率 100%；性能实例规格区间范围包含4 GB、8 GB、16 GB和32 GB。资源上限更高，主要适用于计算密集型场景，如音视频处理、AI建模和企业级Java应用等场景。

随着专用领域硬件加速的蓬勃发展，各 GPU 厂商均推出了视频编解码专用 ASIC，比如：英伟达从 Kepler 架构集成视频编码专用电路、从 Fermi 架构集成视频解码专用电路。

函数计算正式推出了基于 Turning 架构的 GPU 实例，使得 Serverless 开发者可以将视频编解码的 workload，下沉到 GPU 硬件加速，从而大大加快了视频生产、视频转码的效率。

最高可交付 2w 实例/分钟

所谓“无服务器”，并不是说软件应用不需要服务器就可以运行了，而是指用户无须关心软件应用运行时，涉及的底层服务器的状态、资源（比如 CPU、内存、磁盘及网络）和数量。软件应用正常运行所需要的计算资源由云计算厂商动态提供，但实际上，用户还是会关心云厂商的资源交付能力，以及应对突发流量场景下资源不足导致的访问波动。

函数计算依托于阿里云强大的云基础设施服务能力，通过神龙裸金属资源池和 ECS 资源池双池互备，在业务高峰期，实现最大交付达 2w 实例/分钟，这近一步提升了函数计算在客户核心业务上的交付能力。

VPC 网络建连优化：从 10s 优化至 200ms

当用户需要在函数中访问用户 VPC 中的资源，例如 RDS/NAS 时，需要打通 VPC 网络。业内 FaaS 产品普遍采用动态挂载 ENI 的方式来实现 VPC 打通，即在 VPC 创建一个 ENI，挂载到 VPC 中执行函数的机器上。该方案让用户能非常简单地联动后端云服务，但 ENI 挂载的速度一般需要10秒以上，在延时敏感业务场景下带来极大的性能开销。

函数计算通过将 VPC 网关服务化，实现计算和网络解耦，计算节点的伸缩不再受限于 ENI 挂载的能力。该方案由网关服务负责 ENI 的挂载、网关节点的高可用和自动伸缩，而函数计算专注于计算节点的调度，最终实现 VPC 网络建连时，函数冷启动时间降至 200 ms。

GB 级别镜像启动：从分钟级优化至秒级

函数计算在 2020 年 8 月率先发布了容器镜像的函数部署方式，AWS Lambda 在 2020 年 12 月 Re-Invent，国内友商在 2021 年 6 月也相继宣布了 FaaS 支持容器的重磅功能。冷启动一直都是 FaaS 的痛点，引入比代码压缩包大几十倍的容器镜像后，加重了冷启动过程带来的时延。

函数计算创新性的发明了 Serverless Caching，根据不同的存储服务特点，构建数据驱动、智能高效的缓存体系，实现软硬件协同优化，将 Custom Container 体验进一步提升。到目前为止，函数计算已经将镜像加速优化到了较高的水准。我们在函数计算的公开用例（https://github.com/awesome-fc）里面，挑选了 4 个典型的镜像，并将它们适配至国内外几个大型云厂商进行横向对比，每间隔3小时调用上述镜像，重复数次。

实验证明，在 GB 级别镜像冷启动的场景下，函数计算已经实现了分钟级到秒级的跨越。

从专用到通用，从复杂到简单，SAE 让 All on Serverless 成为可能

如果说 FaaS 大规模落地企业核心生产业务的难题需要通过技术攻坚来解决，以 SAE 为代表 Serverless PaaS 则将更多的突破放在产品易用性和场景覆盖度上。

从专用到通用，SAE 天然适合企业核心业务的大规模落地

不同于 FaaS 形态的 Serverless，SAE 以“应用为中心”，提供了面向应用的 UI 和 API，保持了服务器和经典 PaaS 形态下的使用体验，即应用看得见、也摸得着，避免了 FaaS 对应用的改造和可观测、可调式相对较弱的体验，可以做到在线应用的零代码改造和平滑迁移。

SAE 打破了 Serverless 的落地实施边界，使得 Serverless 不再是前端全栈、小程序的专宠，后台微服务、SaaS 服务、物联网应用等一样也可以构建在 Serverless 之上，天然适合企业核心业务的大规模落地。此外，SAE 支持 PHP 、Python 等多语言源码包的部署，支持多运行时环境和自定义扩展，真正让 Serverless 实现专用到通用。

从复杂到简单，SAE 天然适合企业应用快速容器化

传统的 PaaS 被诟以使用复杂、迁移难、扩展麻烦，SAE 底层将虚拟化技术改造成容器技术，充分利用了容器的隔离技术，来提升启动时间和资源利用率，实现应用等快速容器化，而在应用管理层，则保留了原有的 Spring Cloud/Dubbo 等微服务应用的管理范式，不必动用庞大而复杂的 K8s 来管理应用。

此外，底层计算资源池化后，其天然的 Serverless 属性使得用户不必再单独购买和持续保有服务器，而是按 CPU 和内存资源量来配置所需的计算资源，再加上经过多年双 11 考验的高级微服务治理能力，让容器 + Serverless + PaaS 得以合三为一，使得技术先进性、资源利用率优化、高效的开发运维体验可以融合在一起。因此，让新技术落地更加简单、平稳。

可以说，SAE 几乎全覆盖了应用上云的所有场景，既是应用上云的最佳选择，也是 All on Serverless 的典范。

4 大变化，Serverless 加速企业现代应用架构革新

单是技术的领先性，并无法推动行业的发展，Serverless 给企业客户和开发者带来的切身变化，这两者组成了市场成熟度的双轮驱动，技术在自我演进，客户在落地反哺，这是任何一项新技术得以持续发展的正确姿势。

变化一：服务器 vs 代码

创业公司的全栈工程师：“我的工作不再是围绕冰冷枯燥的服务器，告别了服务器的处理时间比我写代码的时间还长的窘境，可以让我把更多的时间放在业务上，并且用最熟悉的代码来保障应用的稳定运行。”
一个主攻前端方向的全栈工程师的日常可能是这样的：掌握至少一门前端语言例如 Node.js 或者 Puppeteer，会写一些 API 接口，再修改一些后端的bug，还要花费大量的精力在服务器的运维上，公司的业务量越大，花在运维上的时间越多。

函数计算降低 Nodejs 等前端语言的服务器维护门槛，只要会写 JS 代码就可以维护 Node 服务，而无需学习 DevOps 相关知识。

变化二：计算集群 vs 计算资源池

算法领域的 Java 工程师：“我不再担心算法的增多和复杂度的增高导致的服务器规格多、采购烦杂、运维难，而是通过无限的资源池、快速的冷启动以及预留实例，来提升弹性能力和自由度。”

网易云音乐已经落地了 60+ 的音视频算法，100+ 的业务场景，用到了 1000+ 台不同规格的云主机和物理机。虽然通过了很多方式去简化了内部业务场景、算法等的对接，但越来越多夹杂存量、增量处理的算法，不同流量的业务场景规模，以及不同业务场景可能会复用同一类算法的，导致在业务上的时间越来越少。

网易云音乐基于函数计算升级离线音视频处理平台，应用于听歌、K 歌、识曲等业务场景，实现 10 倍速的业务落地，并大幅降低了稀疏算法的计算成本和运维成本。

变化三：负载 vs 调度

游戏主程：“我不再担心 SLB 的轮询机制导致无法感知 Pod 的实际负载，由此引起的负载不均，函数计算的调度系统会合理安排每个请求，来保证战斗校验场景下的高 CPU 消耗和高弹性处理请求。”

战斗校验是莉莉丝众多战斗类游戏的必备业务场景，用来验证玩家客户端上传的战斗是否有作弊的情况。战斗校验一般需要逐帧计算，CPU 消耗会非常高，通常1队v1队的战斗需要n毫秒，而5队v5队的战斗则需要相应 5n 毫秒，对弹性要求很高。此外，容器架构下挂载的 SLB，会因为轮询机制导致无法感知 Pod 的实际负载，由此引起的负载不均，产生死循环和稳定性风险。

函数计算的调度系统帮助莉莉丝合理安排每个请求，对于死循环问题，也贴心的提供了超时杀进程机制。函数计算将调度系统的复杂性下沉到了基础设施，厂商深度优化后的冷启动时延大幅下降，从调度、到获取计算资源、再到服务启动，基本在 1s+ 左右。

变化四：脚本 vs 自动化

互娱行业运维工程师：我不再担心传统服务器模式下，发版慢和易出错、环境一致性难保证、权限分配繁琐和回滚麻烦的问题，SAE 的全套服务治理能力提升开发运维效率70%，而弹性资源池则将业务端的扩容时间缩短70%。

一场热映，南瓜电影日注册用户突破 80w，导致流量入口 API 网关撑不住，紧接着后端的所有服务都面临了极大的稳定性挑战，随后开始紧急扩容，买 ECS，上传脚本到服务器，运行脚本，扩容数据库，整个过程耗时 4 小时。然而，因为这样的热映带来的自然爆点并不少见，这加速了南瓜电影的技术升级思考。

南瓜电影借助 Serverless 应用引擎 SAE 7 天内全面 Severless 化，零门槛拥抱 K8s，轻松应对热映电影的突发流量，相比传统服务器运维模式，开发运维效率提升70%，成本下降 40%，扩容效率提升 10 倍以上。

先行一步，志在千里

2009 年，伯克利就当时兴起的云计算提出 6 点预测，包括服务的按需付费成为可能、物理硬件的利用率将大大提高等，在过去的12年间，这些都已成为事实。2019 年，伯克利再次预测 Serverless 计算将会成为云时代默认的计算范式，并取代 Serverful （传统云）计算模式。

参照云计算这12年的发展历程，Serverless 正处于验证伯克利预测的第3年，刚过四分之一。这3年间，从云的未来的美好畅想，到云厂商倡导的 Serverless First 和大规模投入，再到企业用户充分利用 Serverless 的优势来优化现有架构，并客观的面对影响 Serverless 大规模落地企业核心业务的绊脚石，再到今天，通过技术创新和突破来化解行业共同的痛点。这不仅需要先行一步的勇气和魄力，更需要志在千里的使命和责任。