解决 Serverless 落地困难的关键，是给开发者足够的“安全感”

​简介：越来越多的云产品都会向全托管、Serverless 形态演进。当云的产品体系 Serverless 化达到一个临界值，通过函数计算这样的 Serverless 计算服务结合其他 Serverless 形态的云服务，能够完整的实现整个应用时，Serverless 就会变成了一个确定的技术趋势，并越来越流行。

作者 | 不瞋

刚刚过去的 2021 年天猫双 11，阿里云函数计算与阿里巴巴运维体系全面实现标准化对接，打通研发的最后一公里，首次实现了业务全链路“ FaaS + BaaS ”的 Serverless 体系化研发，覆盖淘特、淘系、阿里妈妈、1688、高德、飞猪等业务场景，支撑场景数量同比增加 2 倍，峰值流量总数同比增加 3 倍，实现了百万 QPS 的突破，人效提升 40%。

前段时间，我与 InfoQ 大咖说合作了一期直播，跟开发者们聊了聊我眼中的 Serverless。大家对于 Serverless 热情很高，但是顾虑仍然存在，这也是我写作本文的原因。作为这一技术浪潮的见证者，我想跟大家一起思考 Serverless 诞生的原因，阿里云 Serverless 技术和产品的演进历程，以及我对 Serverless 未来趋势的判断。

01 云产品体系的 Serverless 化推动技术演进

虽然 Serverless 对很多人来说，仍然比较新鲜，但其实 Serverless 这种形态早已有之。

2010 年我刚加入阿里云，参与飞天操作系统研发，飞天操作系统最初是通过管理数千台的机器来执行大数据处理的。用户的编程界面是 MapReduce 任务，通过 SQL 语句等来处理海量数据，这就是早期的 Serverless 形态。

阿里云的第一个云服务对象存储 OSS，亚马逊云科技的第一个云服务 S3，它们其实也都是 Serverless 形态的存储服务。用户不需要关心数据如何被分片存储到不同的服务器上来实现负载均衡，也不需要考虑如何做到在服务器宕机或者交换机故障时，保证数据的高可靠性和高可用性，他们只需要用简单的 API 就可以实现海量数据的可靠存储。他们都屏蔽了 Server 的复杂度，让用户有一个非常简洁的 Serverless 体验，这些都是 Serverless 形态。

2012 年，Serverless 概念被首次提出，到亚马逊云科技正式商用 Lambda，Serverless 开始流行并逐渐走红。近 10 年时间，这样的演进过程并不偶然、也非一蹴而就，反而是带着宿命般的必然性，其背后原因是云的产品体系一直都在向 Serverless 化演进。

无论是阿里云、Azure，还是亚马逊云科技，绝大多数新产品都是全托管的 Serverless 形态。时至今日，公有云的用户越来越习惯使用全托管的服务，除了省力以外，对很多用户来说，最重要的是能更高效的解决业务问题。如果全托管的服务能带来更好的性能、更好的稳定性、更少的运维代价，为什么不用呢？

按照这些逻辑，越来越多的云产品都会向全托管、Serverless 形态演进。当云的产品体系 Serverless 化达到一个临界值，通过函数计算这样的 Serverless 计算服务结合其他 Serverless 形态的云服务，能够完整的实现整个应用时，Serverless 就会变成了一个确定的技术趋势，并越来越流行。

02 Serverless 走出幻想破灭的低谷

2017 到 2018 年，我们都有体感 Serverless 热度达到了一个高峰，但和很多新兴技术一样，从概念大讨论到企业落地应用，都会经历幻想破灭的低谷。从 Serverless 这十年的发展来看，无论是学术界还是工业界，都认为这是一项颠覆式的技术，在提升研发效率、资源效率上有着巨大的潜力。但作为一个新概念和新的计算形态，Serverless 最主要的挑战是对开发者心智的改变，在工具链、编程模型、应用架构上，都需要开发者转换思路。



今天，这些问题正在被快速的、持续的解决。

Serverless 正处于稳步上升期，我们能看到业界最主要的云服务商在不断推出不同形态的 Serverless 计算服务，比如 Google Cloud Run，亚马逊云科技的 App Runner，阿里云的 Serverless 应用引擎 SAE。另外，阿里云的函数计算这类最经典的 Serverless 计算服务，也正变得越来越通用，对应用的侵入越来越少。

无论在阿里巴巴上还是在阿里云上，开发者对 Serverless 的认识越来越客观、务实，并在越来越多的场景中引入 Serverless 技术和相关的工具链，驱动 Serverless 生态愈加成熟。

03 给开发者安全感，是最重要的事

我们经历了一个从 Serverless 非常受关注到落地困难，再到 Serverless 被广泛使用的全过程。这个过程中也确实遇到了不少挑战，解决 Serverless 落地困难的关键，在于给开发者安全感。对开发者来说，Serverless 把更多的技术层面的东西交给了云厂商去做，所以怎么给他们安全感，让他们无负担使用是非常关键的，也是他们做技术选型时最关注的点。

开发者这种安全感的担忧主要来自于两方面：

• 云厂商锁定问题：Serverless 让应用更深度的依赖于云服务商的能力，如何避免 vendor lock-in，从一个云迁移到另一个云，会有哪些障碍？
• 控制黑盒问题：云厂商接管了应用的运行平台，怎么能提供给用户控制力？比如用户怎么能看到足够丰富的指标来优化应用或者掌控应用运行的情况？云平台出问题了怎么办？出现问题时，用户有什么手段能快速查明问题，恢复服务？

对于供应商锁定的担忧。阿里云是以公有云、阿里集团、开源三位一体的方式打造 Serverless 产品，坚定的拥抱开源开放。阿里云函数计算的 Runtime 运行时采用无侵入的标准的 http-server 协议，用户使用 Golang 或者 PHP 写的 Web server 放上来就可以跟 Serverless 平台去交互。

另外函数计算的可观测能力基于开源开放的 OpenTelemetry、OpenTracing 等标准。阿里云推出的 Serverless Devs 工具链也是开源开放的，提供了多个云厂商的 Serverless 应用部署的能力。承载阿里云事件生态的 EventBridge 也是采用 CNCF CloudEvents 开放标准。这些都是希望开发者能够通过开源开放的方式来使用产品，未来，我们会积极推进 Serverless 领域的标准。

对于控制黑盒问题，最主要的是要做好产品设计的平衡，既能给开发者控制力，又能减小开发者的复杂度。阿里云函数计算把给开发者安全感看作最重要的事情，我们在可观测性上是业界首个，也是目前唯一一个透出了实例级别的指标，让用户能更容易调优 Serverless 应用。我们透出了非常细粒度的资源计量数据，让用户能更容易判断费用是否符合预期。

在未来，我们会将系统事件和状态以合适的方式透出给开发者，让他们能更容易预期系统的行为。我们也会在问题诊断等方面开放更多的能力，去贴合开发者已有的开发习惯，让他们能更平滑的使用 Serverless。

04 正在全面落地的 Serverless

在应用场景上来看，Serverless 不再仅仅是小程序，还有电商大促、音视频转码、AI 算法服务、游戏应用包分发、文件实时处理、物联网数据处理、微服务等场景。Serverless 正持续与容器、微服务等生态融合，降低开发者使用 Serverless 技术的门槛，反过来也将促进传统应用的云原生化。

在企业赋能方面，尤其是疫情之后，能够看到用户对 Serverless 的认知变深，在很多场景下，切换到 Serverless 架构确实能够为用户带来明显的收益，用户逐渐认可这项技术。

1、Serverless 全链路、全场景覆盖天猫双 11

2020 年天猫双 11，阿里云实现了国内首例 Serverless 在核心业务场景下的大规模落地，扛住了全球最大规模的流量洪峰，创造了 Serverless 落地应用的里程碑。

今年天猫双 11，阿里云 Serverless 支撑业务场景更多，范围更广，阿里云函数计算与集团内的运维体系全面实现标准化对接，打通研发的最后一公里，首次实现了业务全链路“ FaaS + BaaS ”的 Serverless 体系化研发，覆盖淘特、淘系、阿里妈妈、1688、高德、飞猪等业务场景，支撑场景数量同比增加 2 倍，峰值流量总数同比增加 3 倍，实现了百万 QPS 的突破，人效提升 40%。

2、网易云音乐音视频算法的 Serverless 探索

网易云音乐产品背后，实际有非常多的算法服务支撑，比如多种码率的音频转码、听歌识曲中应用的音频指纹生成和识别、副歌检测、小语种音译歌词等等。这些任务的资源需求和执行时间变化很大，需要使用 C++、Python 等多种语言实现，对算力的弹性要求非常大。

原先网易是在自己的数据中心搭建这样一个算法服务平台，落地了 60+ 音视频算法，对接 100+ 的业务场景。但随着业务增长，基础设施管理的负担越来越大。虽然通过了很多方式去简化了内部业务场景、算法等的对接，但越来越多夹杂存量、增量处理的算法；不同流量的业务场景规模，以及不同业务场景可能会复用同一类算法的，导致在业务上的时间越来越少。

比如上线一种新算法，首先要对超过 6000 万首存量歌曲进行处理，这要求平台在短时间内弹出大量算力，可靠的执行任务，同时提供完善的应用、实例等多维度的监控信息。这些需求是非常匹配函数计算的。网易在函数计算上高峰期一天处理超过 2000 万个任务，算法应用到业务 10 倍速的提升，稀疏调用的算法成本大幅缩减。

网易这个案例最有意思的点，在于他们在应用层融合了自有机房和公有云上的服务。以往大家谈到 Serverless，觉得它很难在混合云的场景下应用。网易的案例证明了专有云和公有云融合不是只有资源纳管这一种方式，在应用层考虑融合方案，有时候效果会更好。

网易云音乐音视频算法的 Serverless 探索之路

3、南瓜电影 7 天全面 Serverless 化

另一个比较有意思的案例是南瓜视频使用 SAE 实现传统微服务应用的零迁移改造，只用了一周就完整迁移到 SAE 平台。

南瓜原有的微服务平台面临几个挑战：

• 运维成本高。要管理基础设施，要规划网络，要升级系统等等，大量的时间花在这些低价值的工作上，而不是专注于业务的发展；
• 机器难以规划容量。热点电影经常造成访问热点，临时扩容操作复杂、慢。南瓜经历了业务的爆发式增长，因为一部热映电影，1 小时新增 80 万注册用户，比正常流量高了 80 倍，系统很快就崩了。

​

这次经历促使南瓜进行了技术升级。用户也对比了 K8s 和 SAE，最后认为要玩转 K8s ，需要组建好专业团队，代价不小。SAE 的产品形态非常有亲和力，南瓜只花了很短的时间就迁移到 SAE，现在所有的应用都运行在 SAE 上。

南瓜电影 7 天内全面 Serverless 化实践

05 Serverless 不是未来，是现在

云的发展一定是往更高的抽象层面发展，让用户研发效率更高更敏捷，资源使用更高效。因此云的产品体系一定是 Serverless 化，也就是越来越多的云服务是全托管、Serverless 的形态。如果我们把云看作一台计算机，那么 IaaS 层是硬件，以 K8s 为代表的容器编排系统是操作系统，而 Serverless 计算则是应用的运行时。所以 Serverless 是云的未来，这实际上不算是对未来的预测，而是正在发生的事实。

接下来，Serverless 的产品形态会变得多样，早些年大家都把 Lambda 这样形态的产品等同于 Serverless 计算，这几年我们看到 Google Cloud Run，亚马逊云科技 App Runner 等针对 Web 应用场景的 Serverless 服务，阿里云函数计算也在不断演进，比如支持容器镜像、更少的运行限制等等。而且针对传统微服务等存量市场，我们还推出了 SAE 这样形态的服务，让用户能够非常方便的把存量应用迁移上来，享受 Serverless 的红利。

Serverless 底层技术发展上也有一些值得关注的趋势。包括在资源调度上更加智能，因为 Serverless 的计算模式给平台提供了更多的负载信息，使得平台有机会通过数据驱动的方式在资源调度、流量路由等方面做得更加精准。另外，Serverless 有望支持更多类型的硬件，包括 ARM 类型的 CPU、GPU 或者 FPGA 等异构硬件，给用户提供更有性价比的计算类型。

谈未来，就不免说到对 Serverless 终点的判断，我想云就像一台计算机，在过去的 10 年，云主要是通过 Cloud Hosting 的模式，在兼容原有编程模式的同时，为开发者提供了海量的算力。但这种模式有点像使用汇编语言编程，开发者需要处理相当多的细节。微软预测未来 5 年将新增 5 亿个应用，超过过去 40 年的总和，这是传统的开发模式难以支撑的。

所以我们看到现代应用、低代码等理念开始流行。下一个 10 年，云的编程模型将迎来巨大的创新。过去 PC、移动互联网，都从一开始的硬件创新，发展到形成自己的原生编程模型，形成完整的、繁荣的产业生态，云也正在经历这样的过程。最终，云会有属于自己的、原生的、高效的编程模型和应用研发模式。而 Serverless 在云的生态中，扮演应用运行时的角色，是承载应用运行的基础设施。

作者简介：

不瞋：阿里云 Serverless 产品研发负责人，致力于构建下一代弹性、高可用的无服务器计算平台。

原文链接

本文为阿里云原创内容，未经允许不得转载。

​