聚焦当下，重构未来：Serverless 全球视野碰撞（上）

以下内容来自：「Techo TVP 开发者峰会 ServerlessDays China 2021」圆桌论坛环节，文字内容分为「上下篇」与大家分享，视频请看文末。公众号回复「PPT」，即可领取本届大会演讲 PPT。

由腾讯云发起邀请，首次齐聚 AWS、阿里云、字节跳动等全球 TOP 云厂商和互联网企业于 ServerlessDays China，共同探讨 Serverless 的现在与未来。

论坛主题

聚焦当下，重构未来：Serverless 全球视野碰撞

主持嘉宾：

中国信息通信研究院云计算部副主任、腾讯云TVP，陈屹力

圆桌嘉宾：

Amazon Web Services 首席开发者布道师，费良宏
阿里集团 Serverless 标准化规范负责人，陈仲寅
字节跳动基础架构函数计算负责人，杨华辉
腾讯云 Serverless 专家架构师，杨政权

「灵魂拷问」环节

Q：费老师您作为 AWS 首席开发者布道师，在工作中可能会遇到一个问题：什么是 Serverless？Serverless 并不是一个很容易被理解和广泛接受的概念。在布道的过程中，和国外社区相比，国内开发者社区对于 Serverless 的接受程度怎么样？对于没有接触过 Serverless 的开发者或者非技术人员，如何普及 Serverless 的概念和价值？在布道过程中会遇到哪些挑战，以及有哪些方法值得我们借鉴？

费良宏，AWS 首席开发者布道师

这个问题的内容涉及的范围比较多，我尝试跟大家分享一下我听到、看到、观察到的一些现象。

首先看国内的市场和国外的市场，Serverless 发展的情况。坦率说，我认为在国外的市场发展势头比国内市场要好很多，应用规模、数量、普及程度、开发者的接受程度来说，我看到了非常多有意思的基于 Lambda 或者 Serverless 的项目实践，以及大规模应用的结果。但是同样情况在国内看到的项目以及实战的结果相对少很多。这个原因非常复杂，自己归纳有几点原因：

1. 云计算市场的占有率

在国外市场，云计算的普及程度或者云计算的渗透率相对来说比较高。国内市场的情况，一方面是云计算的渗透率还比较低，传统IT的比例还是比较高。

2. 云计算市场份额的碎片化

在国外市场当中，几个巨头已经把整个云计算市场瓜分得非常充分，所以开发者选择平台的时候，很容易选择头部这样的平台作为开发的基础。但在国内，我相信很多开发者很困惑：究竟用哪种云？而 Serverless 作为一个新出现的技术，它的时间比较短，2014 年底出现这个苗头，成熟只是这几年的时间。这么短的时间出现之后，由于发展趋势非常好，所以大家都去推进自己 Serverless 的产品，这会出现一个结果，百花齐放，缺少统一的标准。换句话说，在 A 云上开发 Serverless 的 Function，其实没有办法平滑地迁移到 B 云上去，更何况去 C 云了。这种情况结果就是选择了某一朵云，注定依赖于某一个 Serverless 平台。

对于很多开发者，更多的是选择跨云部署，或者还有混合部署、本地部署、云端部署。最终的结果，就选择用妥协的结果，不是选择 Serverless，而是选择用传统的方式，Doker、Kubernetes 等方法替代。所以，国内市场的复杂性，云计算的渗透率不高，以及开发者对这个新技术的犹豫不决导致了在国内市场 Serverless 的发展速度，相对于国外来说有点迟缓。

对于这个问题的解决，我想有这么几种思路，跟大家商榷一下是否能改变。

1. Serverless 本身还是需要有标准化。

无论底层技术如何实现，如果从规范 API 或者调用规模方式来说，有一个标准将对开发者的普及是有莫大的帮助。如同像 S3 的出现一样。大家知道在云计算领域当中，对象存储的缺省标准及工业标准是 S3，不论底层实现是否是S3，但大家在接口上统一了。这样应用移植或者匹配都会非常容易实现。如果在Serverless这个环境当中，也能够达成某一种共识的话，用一种标准化方式推进的话，我相信对于广大的开发者来说是一个非常大的福音。

2. 将云计算的概念、平台渗透率提高。

让大家更多用云原生和云优势这样的技术去开发云。而现在很不幸的情况就是，我们在用上个世纪的积累经验来使用云平台，把云只看作基础设施、虚拟机、存储和网络载体，没有充分地利用到云平台之上的那些托管高级的服务。而 Serverless 是这类服务，如果云计算的概念深入人心，我们的架构应用完全基于云计算开发的话，那 Serverless 的普及就是迎刃而解的事情。

对于 Serverless 的推广来讲，我们不要拘泥于 Serverless 本身的定义、看到的一些好处去谈它，更多的是看它未来的发展前景。我非常认同一个说法：云计算 2.0 就是 Serverless。可以设想一下，有一天在开发或者部署新的应用架构的时候，后台或业务逻辑的实现完全基于Serverless。我们先不假设 Serverless 在实现上的难度或者目前的困境，仅假设 Serverless 是理想环境，完全用 Serverless 建立业务逻辑的话，那这个架构将是多么漂亮、简洁、优雅的结构。虽然现在 Serverless 还有些不足，但发展势头一定是非常好的。

希望很多开发者、架构师能够理解到 Serverless 给整个行业带来的冲击，不仅仅是快速部署、快速开发、免维护，甚至某种程度来讲，是无架构的新模式。架构师在 Serverless 环境面前，变得没有那么重要，因为完全可以用函数将一个业务逻辑简单封装连接在一起。如果大家意识到这种变革，这种未来的冲击，给我们今天带来很多启发的话，相信接受 Serverless 就是水到渠成的事情。

Q：还有一个更深层的问题，今天我们看到很多演讲嘉宾分享的内容，不论是从数据库、中间件、AI 推理等方向，对于 Serverless 的应用都有非常丰富的经验。作为云厂商非常坚定地认为 Serverless 是未来的方向，并且有很多实践，但用户对 Serverless 还有很多的担忧或对应用场景有很多疑虑，这中间的 gap，最大的核心点您认为是在哪里？

费良宏，AWS 首席开发者布道师

我认为是 Serverless 标准化的问题。大家会有一个顾虑，当选择某一个 Serverless 平台的话，就会出现所谓的 Vendor Lock-in 的平台绑定的问题，让最终的选择失去了灵活性，由于这个顾虑的存在，可能对于这些独有的技术或者平台特有的技术望而却步了。

如果能够打破这种顾虑，或平台之间能够更平滑地选择迁移，那么后续 Serverless 的普及将会更容易一些。我在设想有一天有这样工具的存在，无论某一个云的平台，可以用一个工具把函数能够无缝非常好地部署在任何一个选择的环境当中的话，可能 Serverless 就变得更为容易被接受。

Q：陈老师经历过多次淘宝双十一大促，对大流量高并发的管理非常有发言权。在运维和成本管控方面，Serverless 是否发挥了优势？目前主流的 FaaS 产品，内存和 CPU 都进行了绑定，按比例扩容，但存在灵活度不足的问题，如何匹配用户的实际使用场景，造成额外的计算开销，在这个维度未来优化的趋势是什么？

陈仲寅，阿里集团 Serverless 标准化规范负责人

阿里巴巴从去年的双 11、双 12 到今年的 618 大促，其实已经使用 Serverless 快 2 年的时间。这 2 年的过程中，我们一直在尝试把传统的业务逐步迁移到 Serverless 上面来。在这个过程中最有感触的一点，Serverless 带给业务的价值：节省成本，这是一个非常直观的方面。Serverless 的弹性、免运维能够节省我们大量的成本，机器成本和人力成本。

人力成本

阿里去年有一个数字，Serverless 给阿里的人力成本降低了 48%，这个数字是我算出来的。阿里内部会有需求管理平台，需求迭代时间，加上最终交付产品，一个较为复杂的计算，最终通过长达一年的时间统计下来得到的。人力成本计算很复杂的，会涉及时间成本、代码量成本、需求管理成本等各类成本。但是最终会定义在同一个基线上，最终按照一致性的算法，相对地得出了 48% 的数字。这个数字是根据需求、人力开发周期、代码量，最终得出了这么一个数字，这是一个人力成本的降低。其中包括业务开发同学无需关心申请机器、流量计算、容器数量以及上线流程方面的优化成本等等，都是算在人力成本里面。

机器成本

机器成本比较容易计算。比如按照以往的流量、规模量，估算出需要几千台的虚拟机。而如今使用 Serverless，只需要在流量高峰的时使用到比较多的容器，在低谷或者平峰的时候，使用较少的容量，通过这样的方式，机器成本会节省得更多。

综合这两方面，机器成本 + 人力成本，最后的确得出整个 Serverless 体系让我们阿里的大促成本降低得非常多。所以，这也是 Serverless 一个非常大的优势。从今天开始，我们所有淘系的大促，包括周边像飞猪、高德、考拉都是用 Serverless 逐步把传统的业务迁移到 Serverless 体系上来。目前来看，是非常的成功和值得去推广的。

CUP 和内存的绑定缺少灵活度，如何优化？这个问题在我们看来还不是问题，因为目前来说阿里集团大部分使用 Serverless 的基本上都是前端的业务，前端的业务使用 Node.js 作为底层的容器，其实没有对资源有非常大的需求，是非常小、轻量快的引擎，只需要非常少量的内存，CPU 只需要固定的量。整个综合起来，其实按照现在阿里集团前端使用 Serverless 的体系来看，没有明确一定要把 CPU 和内存的比例分开或者怎么样。但是，从最广的层面，从其他语言 Java、Python 的层面看，可能有这种诉求，特别是 Java，可能一开始就需要一定内存比例。至少目前来看，在前端领域还没有这么严重地说，一定要把这两个关系分开。但是，其他特定语言可能需要这么一种自定义解法。

不同语言、技术栈不一样，对资源的需求也是不一样的。比如底层有些 Agent 的确需要大量的资源，的确需要解开 CPU 和内存两者绑定关系，不同场景下的需求是不一样，这是当下云平台没有办法满足的。但在集团内部的需求是存在的，是允许分开的。所以，未来可能当这种需求出现的时候，云厂商不管是阿里云还是腾讯云，面向这种需求的时候也是一定会放开。因为用户需要，所以厂商一定提供这样的一些能力。

Q：字节跳动在 Serverless 大规模落地方面也有丰富的实战经验，能否和我们分享实际项目。在进行 Serverless 架构设计以及规模化落地时有哪些误区？比如技术选型、业务粒度拆分、成本、分布式事务管理、部署运维等方面，可以结合具体的案例给大家分享一下常见的 Serverless 应用误区。

杨华辉，字节跳动基础架构函数计算负责人

字节跳动的 FaaS 产品有两个特点。第一个特点，从一开始就是基于 K8S 来构建的，打破 FaaS 无法在 K8S 上构建的谣言。第二点，字节跳动的 FaaS 承载的 QPS 规模相对其他云厂商来说是比较大的。在线场景 QPS 是几十万的规模，换作是每天是几百亿的调用。Pulsar 消息处理高峰期有 2000 多万的 QPS，换算成每天是万亿次调用规模。这两点就是字节跳动整体的 FaaS 的特点。基于这两点的一些经验，可以简单地谈一谈我们的想法。

首先，规模性。对于这种大规模性，大家可以看到在 FaaS 的早期，都是以独占模式作为第一次推出来的 feature 去落地的，用户进来的话就是一个容器或一个 instance（函数实例）在同一时间运行一个请求。对于管理来说很简单，但是带来的一个坏处很明显，中小企业部署 FaaS 技术一开始都是免费的。但是规模大的话，可能会造成成本急剧的上升，怎么解决这个问题？目前各大云厂商的 FaaS 产品都逐渐支持在一个 instance 中配置并发数。字节跳动对于这件事情来看，一开始就是支持在一个instance 上配置多并发，而且默认并发比较高，基本上不太能达到限制。

因为我们觉得并发的强控制是对于一些 CPU 或者内存的密集型的场景比较有用，但是大部分的数据处理，并不是数据密集型，在整体的 pipeline 中，过于管控并发将会导致整个系统非常不稳定，Overhead（系统开销）数值特别高。我们在一定并发量上会做 soft limit （软限制）和 hard limit（硬限制），在每个 container 上会有 sidecar 来进行管控，去避免 instance 被洪峰流量打垮。但是反过来，因为 FaaS 都会进行流量管控，我们在 gateway 或者流量调度层面做的流量管控也是比较薄，这种有利于去承载大规模流量。如果几千万的 QPS 流量打过来，经过中心化的七层 LB，再经过流量调度成本是非常高的。整体 MQ 流量我们是可以接管的，MQ 的流量相当于 event source，这就是 FaaS 内部的范围，某种意义上绕过内部一些七层和流量管控的组件，直接把流量打到 instance 上面。通过这样方式，可以做到比较好的扩展性和比较强的整体的水平扩容性。

我相信今天来参加的各位同学，应该不仅是 FaaS 的使用者，也有像我很多年前坐在台下的感受：我想构建 FaaS 系统，应该注意什么？这也是我今天想跟大家分享的另外一点。如果想在目前的生态的事实标准上面构建 FaaS 系统，去沿用 PaaS 一些已有的生态以及已有的基础能力，这是必要的。这可以加快你的迭代速度，最快地推向市场。如果在未来 FaaS 成为 PaaS 的下一代，可以做到无缝迁移。那对于 K8S 的技术，我们更多情况下把它当作分布式的运维系统，如 ansible 或 saltstack，帮你把东西给搭起来就可以了，不需要太多依赖它的服务发现或是冷启 Pod 的能力，在使用它们之前应该记住这样一个预设前提，这些能力只能作为异步捞回的兜底机制。所以，整体内部的路由发现以及拉起 Pod 都应该 FaaS去实现。所以 FaaS 之上运行的各种应用的收益，也主要得益于 FaaS 在 PaaS 层面上多做的这些工作。这是整体上是我对 FaaS 的理解。

Q：杨老师是专家架构师，经常需要直接面对客户，那么相信有很多客户会提出一些问题，比如有些客户会顾虑厂商绑定 Vendor Lock-in 的问题。对于头部的企业都在多云、混合云等场景，增加整体系统的可靠性，也提高了议价空间。目前 Serverless 在对于多云支持的现状如何？还有哪些亟待解决的问题？

杨政权，腾讯云 Serverless 专家架构师

从我的视角来看，刚才费老师也提到标准化以及兼容多个云平台的标准，这固然重要，但在我看来，很多时候从企业的视角来说，需要考虑这是否是第一优先级。在我们提到 Cloud Native 概念的时候，重点是 Native 这个词，如果用 Native 的隐喻来思考一些同类的问题，会有非常惊讶的发现。比如我们作为中文的 Native Speaker，我们去国外的时候并不会要求我们说出同样流畅的英语。如果我们是海外的 Native Speaker，来国内时同样也不会有类似的要求。

所以在提到 Cloud Native 这个概念的时候，关键的点应该在于如何更加充分利用云所提供的原生能力？我们在提 Multi-cloud 时，很容易出现这样的现象，我们做出了一个通用性的产品，但没有办法充分利用每个云平台所提供的独特能力。在做很多研发同学一定会熟悉，比如在做一些继承或提供公共抽象接口的时候，我们找的一定是一个共性。但是各个云厂商在实现上往往还是会有一定差异性，比如同样是 COS 对象存储、K8S 调度平台在能力方面都会有些许差异。寻找共性的同时也意味着一定程度上失去了充分利用平台能力、使用平台特性的机会，这是我对于 Multi-cloud 的想法。

另外想分享的是 Hybrid Cloud 混合云的架构。我在接触一些客户时，更多的场景是说客户在自己的 IDC 里面有很多机器，但是容量不足，希望能够充分利用 IDC 的算力，同时把溢出的流量放到 Serverless 上面去处理，这是一个很自然的现象，也存在合理性。但是如果说站在一个企业的角度去思考，到底是不是一个最佳的实践？其实未必，经济学里面有个词叫做 Sunk Cost （沉没成本），所有一次性的机器硬件投入都是沉没成本，但是企业关注沉没成本的同事，往往忽略了其他可变成本，比如继续维护这台机器所产生的运维成本，需要有专业的运维团队来做这件事情，即人力成本，除此之外还有如服务器开销、服务器保费等。对于 Hybrid Cloud ，看上去是合理的架构，但未必是最佳的解决方案。也许更好的方式是充分利用云所提供的基础设施，把应用放到云上执行从而充分利用各种云原生能力。

关于腾讯云对 Multi-cloud 的支持，我们也在做相关的事情，比如业界已经有一些 OAM、Dapr 这样一些解决方案，包括腾讯云容器团队在做的一些 EKS、TKE 在做些标准化的工作。此外腾讯云云函数和 Serverless Framework 有深度集成，不需要关注基础设施，只需描述对于函数的定义，比如通过 YAML 这种声明式定义基础设施定义，不依赖于某一个云厂商，Serverless Framework 提供不同云平台的适配器，基于 AWS、阿里云或者腾讯云可以做相关的资源的管理、编排工作。

- 聚焦当下，重构未来：Serverless 全球视野碰撞（下），即将更新，敬请期待！

推荐阅读