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

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

阿里巴巴从去年的双 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 和内存两者绑定关系，不同场景下的需求是不一样，这是当下云平台没有办法满足的。但在集团内部的需求是存在的，是允许分开的。所以，未来可能当这种需求出现的时候，云厂商不管是阿里云还是腾讯云，面向这种需求的时候也是一定会放开。因为用户需要，所以厂商一定提供这样的一些能力。

字节跳动的 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 的理解。

欢迎进入千人 QQ 群 (871445853) 交流 Serverless！