从实践出发，解锁 Serverless 的不同面

2012 年，Serverless 这一概念首次被提出，直到亚马逊商用 Lambda 函数，才被大家熟知。Serverless 和很多词比如微服务一样，是没有精确定义的，也没有事实的标准。虽然现在大家都在提 Serverless First，但在技术选型和落地实践等方面还有不少顾虑。

11 月 1 日，InfoQ 大咖说 邀请到了阿里云资深技术专家不瞋来做 Serverless 的技术分享。不瞋从 Serverless 诞生聊到未来，并结合自身多年实践经验为大家详细讲解了 Serverless，并进一步给出了关于技术选型、落地困扰、开发者角色转变等多方面的思考和建议。

不瞋是阿里云 Serverless 产品体系的负责人，也是国内 Serverless 的早期实践者。以下内容节选自当天的分享，InfoQ 做了不改变原意的编辑：

Serverless 技术十年发展大揭秘

InfoQ：首先请不瞋跟大家做一下自我介绍，包括职业经历，目前在做的事情等等。

不瞋：大家好，我是不瞋，不瞋是我的花名，我的真名叫杨皓然。我是 2010 年加入阿里云，当时主要做飞天平台的研发工作。从 2016 年开始，我转向 Serverless 的研发工作，现在主要负责 Serverless 相关的产品包括函数计算 FC、Serverless 应用引擎 SAE、Serverless 工作流等产品的研发工作。

InfoQ：Serverless 这个概念被提出来已经近十年了，到现在很多人都在提 Serverless 甚至是 Serverless First。但 Serverless 和很多词比如微服务一样，是没有精确定义的，也没有事实的标准。我们想从业内专业的角度听听您是怎么看 Serverless 这个技术？

不瞋：Serverless 的术语是比较新鲜的，但 Serverless 的产品形态其实早已有之。比如阿里云的第一个云服务对象存储 OSS，亚马逊云科技第一个云服务 S3。它们其实是 Serverless 形态的存储服务，用户只需要用简单的 API 就可以实现海量数据的可靠存储。用户不需要关心数据如何被分片存储到不同的服务器上以实现负载均衡，也不需要考虑如何做到在服务器宕机或者交换机故障保证数据的高可靠性和高可用性。

这些都是因为屏蔽掉 Server 的复杂度，让用户有一个非常简洁的 Serverless 产品形态。所以 Serverless 的形态是很古老的，从第一个云服务就有了。

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

但 Serverless 这个概念，是在 2015 年 亚马逊云科技正式商用 Lambda 后变得流行了。背后原因其实是云的产品体系一直在 Serverless 化。无论是阿里云，Azure 还是亚马逊云科技，绝大多数新产品都是全托管的 Serverless 的形态。今天大家，特别是公有云的用户，是不是越来越习惯用全托管的服务？比如越来越多的用户，不会自己再用机器去搭个对象存储，或者消息队列吧？对很多用户来说，最重要的是解决业务问题，如果全托管的服务能带来更好的性能，更好的稳定性，更少的运维代价，为什么不用呢？

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

InfoQ：那么 Serverless 这十年的一个演进的过程是怎么样的？

不瞋：我自己的体感是在 2017-2018 年，Serverless 热度达到了顶峰，但和很多新兴技术一样，Serverless 也经历了开发者幻象破灭的低谷。最主要的挑战是这样一个新的计算形态，对开发者的心智挑战太大，在工具链、编程模型、应用架构上，都需要开发者转换思路。但这些问题正在不断被解决。

从 Serverless 这十年的发展来看，无论是学术界还是工业界，都认为这是一项颠覆式的技术，在提升研发效率，资源效率上有巨大的潜力。所以亚马逊云科技 Lambda 推出后，Serverless 变成了很火热的概念，而且亚马逊云科技也确实在 All in Serverless。

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

我们能看到无论阿里集团还是阿里云上，开发者也对 Serverless 的认识越来越客观、务实，在越来越多的场景中使用 Serverless 的解决方案，工具链和相关生态，也越来越成熟。

所以我认为 Serverless 现在是处于从幻想破灭的低谷走出来，变成一个逐步成熟的过程。

InfoQ：我们经常看到 Serverless 和微服务被一起提及，有人说 Serverless 是来取代微服务的，也有人说这两者是天作之合，从您的角度看，这两者的关系是怎么样的？

不瞋：我觉得 Serverless 和微服务不是一个层面的概念。微服务是一种架构理念，而 Serverless 可以看作是承载应用运行的基础设施。用户以微服务构建应用，可以运行在 Serverless 平台上，也可以运行在 VM 或者容器平台上。

除了计算，用户也可以为他的微服务应用选择 Serverless 或者非 Serverless 的产品。比如可以自己搭建数据库，也可以选择全托管，Serverless 产品的数据库。同理，用户可以在 Serverless 平台上运行微服务架构应用，也可以运行单体架构应用。所以这是两个正交的概念。

但确实，我认为 Serverless 和微服务架构配合是更好的。因为微服务架构背后蕴含的松耦合，更细粒度的开发和运维发布边界，更敏捷的应用发布频度等理念，和 Serverless 弹性、轻量、端对端集成的特点非常合拍。

比如应用采用微服务架构后，在开发调试，流量控制，负载均衡和容错处理，可观测性等方面都会面临挑战。这里面有很多部分都被 Serverless 平台内置的能力简化了，比如 Serverless 平台内置了流控、多维度自动伸缩，负载均衡和容错，能够很好的支撑 Stateless 应用的弹性高可用。

当然，Serverless 架构也在问题诊断和可观测性上和用户原有体验不一致，这是所有厂商要重点解决的。我相信在未来，大部分微服务应用都将以 Serverless 的方式运行。

InfoQ：那么什么样的企业，什么样的业务适合 Serverless，什么样的适合微服务，这两者又该如何取舍？

不瞋：我们做任何一个技术选型都要对这个技术有一个客观的认识，任何技术都有优劣，有适合和不适合。比如微服务，虽然有很多优点，但要想落地好，也需要在应用运行基础设施、工具链、可观测上有完善的配套支撑。比如把应用拆成很多细粒度的微服务、都使用独立的数据库、数据的同步、全局状态/事务管理、大量微服务之间的依赖管理和可视化等等，都需要有相对应的软件和服务，才能充分发挥微服务的优势。

所以无论是 Serverless 还是微服务，技术选型时主要还是从场景和团队两个维度出发。

从场景来看，今天 Serverless 在 API serving、微服务、Web 单体应用、基于事件驱动的数据处理、离线批处理任务等场景已经很成熟，在研发效率和成本上都有优势。

从团队的角度看，我认为任何团队或者个人，都需要搞清楚最重要的事情是什么，把精力聚焦在最重要的事情上。如果没有非常强的基础设施团队来构建自己的应用运行平台，以满足业务需求为导向，那么选择 Serverless 是比较合适的。

落地案例解释 Serverless 是困扰还是机遇

InfoQ：刚才开始您也提到了 Serverless 的一些挑战，对开发者心智的挑战，在实际应用的时候有没有技术障碍和落地困扰。

不瞋：我们其实经历了一个从 Serverless 非常受关注到落地困难，再到看到 Serverless 被广泛使用的过程，这个过程中也确实遇到了不少挑战。

我个人觉得 Serverless 落地困扰最大的挑战还是在于给开发者安全感。因为 Serverless 是把更多的技术层面的东西交给了云厂商去做，对开发者来说是怎么给他们安全感是非常关键的，也是他们做技术选型时最担忧的点。

这种安全感的担忧主要来自于两方面。

1. Serverless 让应用更深度的依赖了云服务商的能力，如何避免 vendor lock-in，就是供应商锁定？我从一个云迁移到另一个云会有什么障碍？

1. 云厂商接管了应用的运行平台，怎么能给我控制力？比如我怎么能看到足够丰富的指标来优化应用或者掌控应用运行的情况？云平台出问题了怎么办？出现问题时，我有什么手段能快速查明问题，恢复服务？

InfoQ：阿里作为在这个领域深耕多年的引领者，是如何解决这两个问题的，是否有已经落地的案例来给大家讲解一下？

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

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

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

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

InfoQ：不瞋还有其他的案例分享吗？

不瞋：我可以给大家分享几个在我们平台上的几个经典案例，一个就是网易云音乐。云音乐的产品背后，实际有非常多的算法服务支撑，比如多种码率的音频转码、听歌识曲中应用的音频指纹生成和识别、副歌检测、小语种音译歌词等等。这些任务的资源需求和执行时间变化很大，使用 C++，Python 等多种语言实现，对算力的弹性要求非常大。

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

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

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

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

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

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

最后一个案例是内部的高德，用函数计算实现 API 服务，在十一等出行繁忙的时候，它在函数计算上的峰值 tps 接近 50 万，日平均 tps 也有 35 万。我们相信这是业界流量最高，最繁忙的一个 Serverless 应用。

InfoQ：在应用 Serverless 这个技术体系的这个过程中，有没有您觉得比较难解决的问题，或者是当下不好解决，需要留到未来的。

不瞋：在技术层面，Serverless 没有特别难解的问题，都是可以攻克的。最难的还是心智教育，标准化和生态建设。技术的演进不是一蹴而就的，就像 PC 时代高级语言、软件工程的发展也是经过很长时间的累积。我绝对相信云是下一个十年最有影响力的平台。未来的开发者，第一天开始编程就是在云上，接触的是云原生的编程理念，他们是云的原住民。

InfoQ：关于开发者心智挑战或者角色转变上，您有没有比较好的建议？（担心技术转型的问题）

不瞋：关于角色转变，我觉得大家不必纠结因为使用了某项技术，就削弱了我的技术竞争力。最主要还是看要解决的问题是什么，我在其中的核心竞争力到底在哪？如果平台替换的是无差别的工作，例如繁琐的机器运维或者容错，那这对开发者是好事，能够帮助他们做更有技术含量的事情。

以阿里云为例，以前阿里云每个产品都有专门的运维团队，后面就没有了。因为很多繁琐的工作可以通过技术的手段自动化，运维团队可以转型为更有价值的工作。比如解决方案架构师，自动化工具等工程技术开发。技术总是向前演进的，无论是团队还是个人，都需要思考自己的核心价值在哪，然后围绕核心价值去沉淀积累。

另外就是要对技术保持开放式的态度，更有好奇心。像容器、Serverless 等新兴技术都做一些了解，先上手实验，有一些体感，对比他们各自的优劣，然后去理解这些技术趋势背后的演进逻辑，我认为这是一个比较好的习惯。像我刚工作，周围都是 C++，大家提起 Java，都觉得太慢。但是现在我们不这么看，Java 在企业级应用开发已经完全证明了自己的能力，影响力和生态都非常大。所以我们不要单一维度去评判一个技术的好坏，选择合适的技术解决场景问题是最重要的。

InfoQ：在多年的 Serverless 实践过程中有没有什么里程碑的事件，比如刚才提到的 SAE。

不瞋：SAE 肯定算一个，我觉得这里面有几个里程碑事件，有国外的，也有我们自己做得比较好的。比如亚马逊云科技推出 Lambda，把 Serverless 带到了大家面前，这绝对是一个里程碑。比如函数计算推出预留实例解决冷启动问题，支持容器镜像，拥抱开源生态；阿里云推出 Serverless 应用引擎解决存量应用 Serverless 化的问题，都代表我们在 Serverless 领域的创新。

Serverless 会是云的未来吗？

InfoQ：大家对 Serverless 未来发展方向有很多预测，也有一些对未来的猜想您是怎么看的？

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

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

InfoQ：还有其他方向上的趋势吗？

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

InfoQ：所以 Serverless 不只是云的未来，那么您认为 Serverless 的终点会是什么？

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

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

Q&A 环节：

InfoQ：评论区有提问，小规模的服务是否适合 Serverless？

不瞋：我觉得小规模服务是更没有负担的，完全可以探索尝试 Serverless，熟悉 Serverless 架构和产品。无论是函数计算 FC 还是 Serverless 应用引擎 SAE ，在兼容性、从传统应用平滑迁移以及工具成熟度上都有明显的提升。

InfoQ：还有观众提问，为什么 Serverless 只有云厂商可以做？

不瞋：这是一个非常好的问题。首先是为什么 2015 年 Serverless 才火起来，原因就是背后必须要有全托管的 Serverless 化的产品做支撑。举个例子，比如你要做一个应用，这个应用不会只依赖一个计算，如果在 VM 上做一些非常轻量的应用，比如搭建一个网站，不需要考虑高可用的情况，就在一台机器上把数据库、Web Server 等全放进去就可以。但 Serverless 不同，你不可能把一个应用需要的存储、数据库这些计算全部放在一个地方。这个模式是依赖很多其他服务做支撑和联动的，比如事件驱动，比如函数计算，都需要很多事件源接进来，把这个事件触发集成做的很细腻。

Serverless 计算是需要跟云的其他产品联动的，然后才能对用户产生更大的价值，这就是为什么云厂商做更适合一些。

InfoQ：最后一个问题，有观众提问 Serverless 的数据安全如何保障？

不瞋：这也是一个非常好的问题，我觉得数据安全跟上面提到的安全感其实是有非常大的关系的，我们可以从几个层面去看 Serverless 的数据安全。

首先就是用户对于 Serverless 的一个普遍担忧是 Serverless 是一个多租场景，你怎么保证我的数据安全性，这里其实可以定义一个非常清晰安全的模型。就是系统跟用户的边界在哪，哪些部分是系统负责，哪些是用户负责。

以阿里云为例，无论函数计算 FC 还是 Serverless 应用引擎 SAE 在安全方面的保障做的是比较充分的。从底层使用安全容器的技术做强隔离，一直到上面应用层，有身份认证、应用级别的访问控制，甚至可以设置只允许来自于某个 VPC 的请求来访问函数，类似于这些能力。所以安全上面隔离的能力是比较立体的。

另外从本身的模式来看，很多用户自身在使用传统方式运行应用的安全隐患是更大的。比如说出现了内核漏洞或者容器漏洞，是否能及时升级？但是现在平台可以保证这个安全性，可以及时升级，对用户来说也是无感的。还有一些用户在使用传统比较粗糙的平台时，直接把 AK 写到了代码里，这都是不提倡的模式。

新的 Serverless 应用模式，用户配置了对应资源的角色权限，平台可以自动扮演角色生成临时 token。你不需要管过程，只需要拿着 token 访问就可以，整个过程都是更规范更安全的。

另外现在对多租的担忧是可以通过内部合规的系统操作记录下来给用户查询，比如内部人员是否有人查看你的代码，或者我们在系统层面做了什么操作。现在用户的代码，镜像都是加密存储的。

所以不管是从平台层面还是用户层面使用新的模式在安全性方面是越来越提高的。