作者：不瞋，阿里云 Serverless 技术负责人

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

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

云产品体系的 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 就会变成了一个确定的技术趋势，并越来越风行。

Serverless 走出空想幻灭的低谷

​2017 到 2018 年，咱们都有体感 Serverless 热度达到了一个顶峰，但和很多新兴技术一样，从概念大探讨到企业落地利用，都会经验空想幻灭的低谷。从 Serverless 这十年的倒退来看，无论是学术界还是工业界，都认为这是一项颠覆式的技术，在晋升研发效率、资源效率上有着微小的后劲。但作为一个新概念和新的计算状态，Serverless 最次要的挑战是对开发者心智的扭转，在工具链、编程模型、利用架构上，都须要开发者转换思路。

明天，这些问题正在被疾速的、继续的解决。

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

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

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

​咱们经验了一个从 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。

正在全面落地的 Serverless

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

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

Serverless 全链路、全场景笼罩天猫双 11

2020 年天猫双 11，阿里云实现了国内首例 Serverless 在外围业务场景下的大规模落地，扛住了寰球最大规模的流量洪峰，发明了 Serverless 落地利用的里程碑。

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

网易云音乐音视频算法的 Serverless 摸索

网易云音乐产品背地，理论有十分多的算法服务撑持，比方多种码率的音频转码、听歌识曲中利用的音频指纹生成和辨认、副歌检测、小语种音译歌词等等。这些工作的资源需要和执行工夫变化很大，须要应用 C++、Python 等多种语言实现，对算力的弹性要求十分大。

原先网易是在本人的数据中心搭建这样一个算法服务平台，落地了 60+ 音视频算法，对接 100+ 的业务场景。但随着业务增长，基础设施治理的累赘越来越大。尽管通过了很多形式去简化了外部业务场景、算法等的对接，但越来越多夹杂存量、增量解决的算法；不同流量的业务场景规模，以及不同业务场景可能会复用同一类算法的，导致在业务上的工夫越来越少。

比方上线一种新算法，首先要对超过 6000 万首存量歌曲进行解决，这要求平台在短时间内弹出大量算力，牢靠的执行工作，同时提供欠缺的利用、实例等多维度的监控信息。这些需要是十分匹配函数计算的。网易在函数计算上高峰期一天解决超过 2000 万个工作，算法利用到业务 10 倍速的晋升，稠密调用的算法老本大幅缩减。

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

南瓜电影 7 天全面 Serverless 化

另一个比拟有意思的案例是南瓜视频应用 SAE 实现传统微服务利用的零迁徙革新，只用了一周就残缺迁徙到 SAE 平台。

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

• 运维老本高。要治理基础设施，要布局网络，要降级零碎等等，大量的工夫花在这些低价值的工作上，而不是专一于业务的倒退；

• 机器难以布局容量。热点电影常常造成拜访热点，长期扩容操作简单、慢。南瓜经验了业务的爆发式增长，因为一部热映电影，1 小时新增 80 万注册用户，比失常流量高了 80 倍，零碎很快就崩了。

这次经验促使南瓜进行了技术升级。用户也比照了 K8s 和 SAE，最初认为要玩转 K8s，须要组建好业余团队，代价不小。SAE 的产品状态十分有亲和力，南瓜只花了很短的工夫就迁徙到 SAE，当初所有的利用都运行在 SAE 上。

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 产品研发负责人，致力于构建下一代弹性、高可用的无服务器计算平台。