Serverless 在大厂用到什么程度了？

导语 | 本文是6月5日Techo TVP开发者峰会 ServerlessDays China 2021 圆桌论坛《聚焦当下，重构未来：Serverless 全球视野碰撞》的分享整理，汇聚AWS、阿里云、字节跳动、腾讯云大咖观点。

点击可观看精彩演讲视频

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

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

一、 Serverless 的概念和价值

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

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

首先看国内的市场和国外的市场，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 就是水到渠成的事情。

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

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

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

二、Serverless 的“大厂”实战

1.阿里巴巴

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

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

(1)人力成本

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

(2)机器成本

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

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

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

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

2.字节跳动

陈屹力：字节跳动在 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的理解。

3. 腾讯

陈屹力：杨老师是专家架构师，经常需要直接面对客户，那么相信有很多客户会提出一些问题，比如有些客户会顾虑厂商绑定Vendor Lock-in的问题。对于头部的企业都在多云、混合云等场景，增加整体系统的可靠性，也提高了议价空间。目前 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 的创新

陈屹力：首先，在解决 Serverless 的冷启动方面，各个云厂商或企业都有哪些比较创新性的举措？这些措施成效如何？

费良宏：谈到 Serverless 的时候，例如Amazon Lambda，我们有非常喜爱它的理由，但是也一定有不喜爱的理由，其中一条就是冷启动。很多人绞尽脑汁解决冷启动的问题，从它出现的第一天，就成为我们挥之不去巨大的挑战。

我认为解决思路有：

第一，今天我谈到的microVM性能的提升，通过它本身的加载速度来提升，解决这个问题，这是重要的环节。

第二，解决的技巧问题。无论microVM如何提升，它的特定延迟由于物理属性不可能完全克服，做不到零延时。在早期的时候，就有非常聪明天才的开发人员想到一个方法，做法就是在watch里定义了一个事件，每5分钟激活一次这个函数，确保这个函数的实例不会被平台所销毁，让它始终处于激活状态。下一次业务请求到达的时候，调用的已经是被激活好的函数，这样就会冲抵掉冷启动带来的延迟。

很多人觉得这个方法看起来可以，但是非常的愚蠢，不够优雅，毕竟我们还要付调用次数的开销；对于平台来说，很多计算的资源就被浪费了。所以，在此之后又有一些改变，改变分两种：第一种方法是预留的并发能力，这是缺省的特性，设定了每一个帐户在某一个特定的区域里面，并发请求的上限。可以针对函数做一定的配置，针对所描述的函数特定场景，设定好一个并发的上限，确保并发的保证被调用激活。这个方式的解决是有限的，所以产生了第二个方式——预配置的并发能力，内部人员提出请求，例如今天要大促，要提前把Lambda Function预热，提出一个具体预热的数量和时间，会提前把这些准备好。准备好之后，跟我们去调用一个被激活好的函数是一样的，延迟是最小的。当然也存在缺点，会付出一笔额外的成本，被激活的这段时间要付出全部的费用。所以，能不能再灵活一点？第三种方法由此出现了：

第三，在Provisioned Concurrency前面配置一个应用负载均衡器。我设计一个策略，当并发调用的请求数量达到90%时，就会自动增加新的Lambda Function实例数量。那这个实例数量会以大约每秒钟150个增加，如果并发请求的增长速度低于这个数字，依然可以维持一个非常好的响应的延迟，能够满足大规模的并发到来。成本的问题怎么解决？并发请求低于设置的最高值，即Provisioned Concurrency70%的时候，就会做一个削减，将它之前激活的函数实例做一定比例的销毁，以确保成本的最终优化。

现在的做法看似某种程度上缓解了冷启动问题，但我认为这并不是最终的完美解决方法。更理想的方法还是在microVM本身的动态化管理能力上，例如参数化配置，不需要人为地申请provision机制，用参数化方法或者是调度机制完全透明给开发人员完成它。另外是microVM自身的演进、加载的速度、初始化的能力、对runtime的优化等等。因为毕竟运行在Lambda的环境当中，需要特定的runtime，如果跟Lambda紧密耦合在一起，做出必要的优化和满足特定环境，还会有进一步的提升空间。所以，我相信这几个方面的发展，某一天都会将我们的冷启动问题更好缓解。那时候我相信大家不会有顾虑，会全面地接受 Serverless。

陈仲寅：刚才费老师讲了几点，很全面，我做些补充。

现阶段我们也是面向用户，有一些用户跟我说的确冷启动调动非常慢，特别在第一次的时候。跟费老师刚刚说的第一个方法，其实是一样的，在云平台上启动一些调度自执行的机制，它的触发器自动每隔5分钟请求自己的函数，把函数拉起来，这样的最终结果是什么？

因为现在Function在运营平台上都有免费的额度，在免费的额度内，每个月只是额外多花8块钱解决饱和的问题，这是非常低成本的，但是同时业务解决了这个问题。不过云厂商并没有得到希望中的效果，因为云厂商的确付出了机器的成本、CPU内存的成本等。所以，虽然可能对用户来说是值得推广的方式，但对云厂商来说并不是很好的答案。虽然这只是一个小小的例子，也说明了这种方式是可行的。

另外一点，在调度或容器的层面，阿里一直也在研究冷启动如何减少。除了刚才所说的方式，现阶段可能只是对并发度来做一个调度的算法，其实还有基于本身容器的状态，比如CPU内存或者QPS以及其他的一些数值反压，反过来告诉上层的管理调度的组件，反推当前容器的用量。这样能够更加灵活快速地调度容器弹性的策略，当然这比较复杂，涉及到弹性的算法，而不是通过单一的指标去调度，这是一层。

还有一些更好的调度减少冷启动的方式，除了容器本身的层面，时间消耗上可能还有一些是浪费在中间接收到的event区隔以及runtime启动的时间，可以做cache或一些其他的优化。还有一些比如Node Js，会对node本身做一些优化，阿里已经做了一些重构的优化，让它启动更快，在现成级别做cache和更多对业务的优化。

第三个层面，是业务本身这层的优化，在初始化的阶段。很多用户把初始化放在代码外面，其实可能是跟容器或者做串行的处理，这部分时间对用户来说，启动也是非常慢的，对业务本身是有影响的。所以，这点可以优化，可以启动之后跟容器做一些并行处理化，将业务组件下沉。对整个容器有掌控力的时候，特别是能够定制自己业务的runtime运行时，来做的一些优化。现在阿里其实是在做这方面的工作。

杨华辉：我们尝试把冷启动问题分类，基本分为系统层面即FaaS带来的冷启动和用户带来的。用户带来的冷启动比较好消除，提供一个函数，让业务的冷启动不在实际的请求中串起来，只有当实际执行成功之后，这个请求流量才会打过来，避免业务的冷启动。

系统的冷启动又分两个方面，一方面是0-1的冷启动，另一方面是1-N的冷启动。它们可以共享一个策略，不需要为每个用户预留实例。整体上FaaS 可以做到给不同的租户共享同样的实力池，container或VM都可以预先做启动。所以整体上microVM、Docker、K8s启动的速度并不在我们关注的冷启动范畴之内，我们关注的范畴是真正的冷启动，是用户下载解压代码的过程。不能用用户runtime的CPU去解压代码包，因为用户的套餐可能很小，直接打满，解压特别慢。所以FaaS解决方案中，基本上都有hostagent，去卸载重CPU的操作。

当然，仅仅做到这点，在01冷启动时会没有达到规模效应，还是得通过内部的cache和用户代码预分发消除冷启动，代码存储到机器上成本相对比较低。所以在代码的分发做好之后，把microVM基本都提成功做load动作，或是Python、Node Js这类动态语言做加载动作、静态语言做拉起动作，这些动作在我们整体的开销内都是100毫秒以下，这是目前的基本现状。

对于大规模情况下的冷启动，即1-N的问题，怎么批量把代码下载？比如阿里前段时间的论文设想了一个方案，希望做到规模情况下，把代码二定制下载到批量的机器上，可能1秒钟下载1千台。整体需要控制二进制的安全性，不用P2P的网络实现，而是用平衡二叉树，在根节点向原栈拉，下面的分支节点，儿子向根节点拉、孙子向儿子拉，尽量地收敛二进制的传输，把网络整体的带宽做到可控范围之内，就解决了1-N的冷启动。另外前面的Gateway可以帮忙打一部分流量，只是你的冷启动能够承载多少？因为前面可以帮你把请求拦住，拦住15秒都行。所以，整体要看用户对冷启动设的阈值是多少，这是关键。

所以，刚才那部分基本解决了传统FaaS 上0-1，1-N的冷启动问题，再往下是预留实例、定时扩缩容等运营手段上的事情了。另外，WebAssembly和V8已经是字节跳动函数计算内部的一等公民，我们不需要在容器或VM的基础上再用WebAssembly runtime或V8引擎隔离去run起来，多层概念无异于把带来的冷启动能力消磨掉。字节跳动的 FaaS 支持利用JS进来用V8跑，这样的冷启动基本上在5毫秒以内，边缘场景都基本上没有太大问题，大概冷启动问题通过这样的方式去解决。

杨政权：大部分都已经说完了，从我的角度来说冷启动这件事情从来都不是平台，只需要平台负责。如果按比例可能是各占50%，平台可以做很多优化，但是在设计应用的时候，也有很多考量点。比如10兆codebase和100兆的，需要的启动时间不一样，和微服务相比，我认为FaaS以及 Serverless 形态，给了我们另外的设计方法，可以把微服务基于场景化进行细粒度的拆分。启动时不需要加载太多代码模块，也不需要构建一个庞大各种各样数据库的连接池，都是有效降低冷启动时间的有效举措。在平台级别，我关注的更多是Java生态类的工具，比如传统的Java应用不需要运行在JVM里，以native image形式直接运行在云函数之上，这也是一个值得关注的点。

四、Severless 距离大规模应用还有多远？

陈屹力：谢谢老师们的分享，Serverless 冷启动是一个持续性的话题。无论如何，冷启动归根结底还是在运维层面，调度算法、调度机制的问题。可能针对消费方或服务方，对于不同的行业、客户、业务类型、时间等各维度，调度机制的优化，我们还在做再优化的过程中。

第二个问题是，目前的 Serverless 概念非常流行，出现越来越多的场景和案例。那距离 Serverless 成为默认的应用设计风格大规模应用还有哪些差距？各位老师可以从产品能力、开源生态、开发者工具、方法论等角度进行阐述。

费良宏：这又是一个范围非常大的问题。

第一，工具层面。坦率说，Serverless 的运行环境跟我们以前熟悉的环境完全不同，所以无论是监控它或是从比较时髦的可建性概念来说，有很大的不足。甚至对一个代码函数进行调试的时候，我们只能采用模拟器的方法，对大规模应用来说有很多不便利的地方。比较理想的是，希望未来看到更多好的 IDE 环境，和具体的 Serverless 环境集成在一起，和可以简单地做profile、debug、obserability能力的功能集成在一起。可喜的是这样一些工具已经出现了，不过这个功能还需要丰富，将它的适用范围推广。未来会在工具层面有更丰富的选择，将管理、维护和优化的能力进一步提升。所以，在工具链的丰富程度上还有很大提升的空间。

第二，架构设计方面。今天的架构师习惯的方法是传统的设计模式，大家已经非常熟练了。Serverless 出现之后，很多人非常谨慎，只是在局部相对次要的环境当中引入 Serverless，需要逐步地改变。在观念上将 Serverless 变成架构设计的中心，虽然有技术上的不足，冷启动或者函数运行的生命周期也好，随着技术进步会越来越好，架构设计方面应该更多地开始考虑如何将现有的架构，例如微服务和 Serverless 做一个很好的集成，这是我看到的两点。

陈仲寅：我看到的其实最大的问题在于用户的使用习惯，也就是用户的心智停留在原来传统应用开发的状态上，这是现在国内开发者最大的“痛点”。

就我观察而言，架构师也好，开发者也好，都是按照传统的巨石应用开发模式，从传统的应用直接跨度到了 Serverless 体系上，其实跳过了分解、分拆微服务的阶段。缺失的阶段导致了从传统巨石应用到 Serverless 之间，不仅是工具层面，还有用户的开发习惯层面、运维层面等所有的体系都是断层的。导致现在很多人希望从原始的开发模式一步直接把迁到Serverless 体系上，以完整的大应用形式迁到 Serverless 上，把Serverless 当做传统的容器在使用，不去改造原有的代码，这种对现有来说是最便捷最快速的方式，但是长期来看，其实是一种非常偷懒的方式。这样迁移，对于整个基建设施和环境，其实都是非常地不了解，很容易产生各种各样的问题。因为毕竟Serverless环境还是属于弹性的容器，它的基建、网络、调度策略和传统所熟知的应用开发模式，就是不一样的。造成了直接迁移可以，但是后面所配套的一些可观测性，一些监控的环境（监控报警、链路、排错环境）都处于黑核状态的情况。

从最开始的架构层面直接不修改上到 Serverless，其实产生了非常大的隐患和问题。尽可能地我们要推荐用户，用全新的思维理解 Serverless 这种架构，去拆分应用，合理地把应用变成细粒度的接口、服务，慢慢拆完之后才去上 Serverless，这可能是比较优雅或者合适的方式，而不是把传统最大的应用直接一股脑怼到大的 Serverless 的容器中。我碰到很多同学说为什么应用代码包有300兆，容器上不去了，跑着跑着启动特别慢？其实都是由于架构的思维、开发模式没有转变过来造成的。如果真的是一个很细粒度、很微的接口，在 Serverless 的演变过程当中，其实代码包越来越小，可能就是3兆—5兆都已经挺大了。那么3兆、5兆其实冷启动也没有这么大的问题，基本都是毫秒级以内起来。通过一步一步的方式是最好的，而不是一股脑上去，这是想要告诉给大家的。

杨华辉：这个问题更多是说FaaS形态和传统的PaaS的微服务形态，最终是否是会归一。按照现状来看，重服务PaaS、轻服务FaaS好像是大家固有的一种理念，我的观念不太一样，我觉得未来微服务就应该all in FaaS。

FaaS不需要自己把自己关闭在狭窄的通道里，要打破自己的一些已有的看法，比如不需要把运行时限制在900秒内、不支持自定义镜像；而是支持异步运行跑个24小时之类，这些各大云厂商都在支持了。阿里也有SAE和FC系统，完全是可以共享架构，这样的做法会让原先以镜像描述微服务的形态很容易落到FaaS的统一架构里，有什么优势？FaaS以及PaaS都做的事情就是你的优势，这就是可见的优势。包括能否缩零？能否在静默时把长尾的服务缩了节省成本？包括代码的编写，用户原来在PaaS不会发现的问题，在FaaS上就会暴露出问题，而这些问题本身是应用开发常有的问题，之前没有暴露出来，这时候在 Serverless runtime生态当中会更容易暴露，整体是一个好事。整体PaaS向FaaS形态的发展，在技术上面需要解决那些问题之外，剩下的应该是大家的一个运动，这个运动慢慢进行，其实整体上的微服务体系上了FaaS之后，发布、编译、部署流程完全可以替代，用户只需要感知如何写代码即可，这是我们的演进思路。

基于这个演进思路，我没有在技术上看到FaaS无法承载PaaS的微服务那一套，只是时间进程上的broker。另外，对于用FaaS的同学，demo就是handler有误导，你未必要是handler，FaaS支持非常通用的两个参数去做你的入口，完全也可以把FaaS实践起来。这样的好处是，对已有的正在存在的框架很好的理解，大家不要局限。在谷歌前几个月推出的GRPC上，FaaS 也支持GRPC上传统被认为的RPC的调用链，字节也已经支持了。字节还有一个庞大的生态，transport可能是TCP的，我们最终想把所有的RPC、微服务生态放到FaaS里面去跑，在这种情况下，其实不损失任何 FaaS 带来的已有收益。如果这样还是不能满足，那就支持自定义镜像，先有用户再谈优化。

杨政权：非常认同刚才大家提到的关于应用设计方面的观点。微服务能够大行其道，背后跟它的方法论是离不开的。现在领域驱动设计成为微服务设计的第一原则、第一渠道方法论，那我们看 Serverless 的应用设计，应该用什么样的方法论？业务应该拆成多少函数？函数的粒度是多少？

现在我们设计 Serverless 应用的时候，缺少设计方法，很多时候识别设计问题都是后延时。比如在扩容方面遇到一些问题，我们意识到应该拆成两个函数，使用不同的配置、timeup时间，可能是更好的设计方法。但是这其实获得反馈是后置的，需要一种设计方法，在开始思考解决方案、设计期间，就能够设计恰如其分的 Serverless 架构风格。另一方面是开发者体验，要真正是一个完全云原生的开发环境、开发体验，至少目前从工具方面看，还是有很大的提升空间。比如代码变更需要部署到云上，中间即使不考虑网络延迟，大概需要多长时间生效？如果做一些图片处理或者视频处理的场景，比对图片、视频清晰度，这个时候甚至要把图片下载，去找一个很好的显示器去比对，才能发现原来代码有问题。所以，在云原生环境，开发体验和本地截然不同，在工具生态方面还有很长的路要走。

五、Serverless 的未来

陈屹力：Serverless 还处于早期阶段，我相信未来从生态、工具、方法论等方面都会逐步地成熟。但我们主动融入和被动接受，这是两个截然不同的差距。总有第一个吃螃蟹的人，单体应用开发模式总是要转变到基于云上的开发模式，这是不可逆的。所以，Serverless 未来还是有很多需要提升的地方，我们一起去完善、丰富它。

最后一个问题，在各位老师看来，未来3—5年，Serverless 会呈现怎样的发展趋势？背后的原因和推动力又有哪些？大家看到未来 Serverless 的趋势是怎样的？我们需要去做哪些工作？

杨政权：我非常看好一个趋势，就是Serverless as an Engine Serverless 作为一种基层资源、应用的执行引擎。从外在看并不知道它是不是一个 Serverless 应用，但是更关注的是功能，它提供了同样的功能，而并不关心底层是什么，随着这种流行——弹性伸缩、按量计费，可以给产品带来很多成本优势，以及弹性收缩的优势。所以会看到越来越多的产品或者SaaS类的服务，会采用把 Serverless 作为底层的执行引擎、作为基座。

费良宏：我有一个判断，不知道对不对，大家未来一起见证下发展。

第一是关于hypervisor的发展。社区里面类似microVM的开源项目贡献非常地踊跃，发展得非常迅速，虽然看起来很多项目都在齐头并进，但我非常希望未来会出现一个统一的结果，在整个社区当中出现完全对于云计算而出现的全新的hypervisor，它具有强烈的隔离性，性能非常高，甚至某种程度来说可以取代今天看到的绝大多数VM，甚至应用于 Serverless。这样的话，我们未来的资源管理部署会在统一的VM框架之下进行调度，也许Serverless 不会作为单独的概念存在，会完全融合在云的各种服务当中，这是我第一个判断，不知道是不是过于激进。

第二，其实我最早看到 Serverless 的感觉是它非常像早年出现的数据库的存储过程。我们有triger、有预置好的PLC或者其他脚本，当事件满足之后就调用。是否可能未来发展到一定阶段，Serverless 不再作为独立的服务存在，完全是由在云计算上托管的所有服务都内置的特性？我们的数据库、计算环境有 Serverless，其他的任何一种服务本身都是通过事件去驱动，可以同步去调度的。这样的话，Serverless 技术已经和我们所有的云原生服务融合在一起，是不是更美妙的场景？使用这些服务、进行调度管理和价值设计的时候，是不是能更从容、更灵活去使用这些资源？

所以我个人非常期望，首先未来cloud hypervisor能够统一、轻量化、性能更好。其次，Serverless 成为普遍的特性而不是服务，存在于云计算平台之上。

陈屹力：认同。Serverless 具有两种普遍形态，FaaS和BaaS。但是BaaS相对来说比较泛一点，FaaS可能大家听得最多，有几个优势比较明显：颗粒度细、弹性极致，是其它不可比拟的。BaaS就像刚刚费老师说的，未来云上是不是所有的 Serverless 都处于ready的状态，只需要发起请求这样的理想状态，我们的 Serverless 现在不管是数据库、中间件，其实在不断地去做相应的改造，适应现在高并发、大规模的弹性需求，不需要降低开发者的门槛，这是核心的价值。

陈仲寅：从人的角度讲一讲，Serverless 在国内发展被大众所熟知可能已经到了2018年。那个时候可能阿里、腾讯，国外的Amazon、谷歌都慢慢地被人们所熟知、应用，阿里其实在2018年之后才真正地使用Serverless，前面都在观望。到了今天，越来越多的人使用Serverless，但是我觉得未来3—5年内可能慢慢会出现两拨极端的人群。一拨完全支持Serverless 的存在，另外一拨可能还是坚守原来传统应用的底线，毕竟有一些应用真的没有办法做到stateless，需要传统应用作为基石存在。这两部分人群预估比例大概8：2，80%的人能够用 Serverless 解决大部分的问题；还有20%的人可能会继续使用传统应用的用法，因为他们还是有状态，毕竟现在有些技术问题 Serverless 没有办法解决，未来3—5年内也不一定能够解决完。这和阿里集团内部现有的体系比例、我看到的业务来说，其实也是这样的分布态，也是并存的现状。

第二，越来越多的人使用了 Serverless 是必然的。现在的前端同学更加激进，所以前端同学更多使用 Serverless，脚本语言在 Serverless 体系上不管是启动、开发、运行、调试都有非常大的优势。所以未来，前端同学会更多尝试 Serverless 的体系，而后端的其他的语言会慢一些。这是天然语言层面上的优势。

第三，目前看来国内的云厂商，3—5年内这套 Serverless，包括入餐的标准、login等，锁定的事情还会继续存在，这也是必然的现象。因为现在基建其实不会太大地去做在API层面上的更新，所以平台锁定可能还要继续下去。在业界，国内的做法是阿里和腾讯，全球来说就是再加上Lambda、微软和谷歌，这五家分庭抗礼，不会有太大的变化。毕竟Serverless 虽然是初期，Amazon为首，但是目前看起来还是一个比较平衡的状态，除非有非常大的一个变革出现，否则基本还会这样进行下去。

杨华辉：Serverless 的未来，我是这么想的。

第一点，因为 Serverless 是FaaS+BaaS，FaaS的计算如果做到充分可伸缩了，BaaS 跟不上，那么connection refuse这类的错误会越来越多，所以终端计算与存储分离应该是一个趋势，这也是配合整体的弹性计算去做的一个升级。

第二点，对于FaaS，其实runtime都是开放式的，特别是在一个大公司来看，我们做FaaS的这些同学其实对于各个领域的一些语言以及语言下面的一些SDK包括终端 Serverless 对的一些 Serverless mango等是无意接触的，所以开放标准，让更多的一些其他平台接入，就像字节跳动内部也有很强大的团队推出这样的产品，这会成为主流趋势。如果一个团队对runtime有特别的建树，就可以参与建设FaaS，把FaaS的生态铺到各个地方。

第三点，微服务和FaaS慢慢融为一体。因为用户不期望用两个平台，轻量用FaaS、重的用微服务，这样是有额外的开发学习和运维成本的，也需要两套人员，所以最终也会变成一体，这样的一体整体上跟我们经常说的端跟云的一体，也是基本吻合的。

第四点，云边一体。传统的比较重的runtime是无法cover的，如果在边缘部署，总有回到主机房的时间，我们期望写一份代码，直接部署到全球、全地域，达到云边一体的可接入性。

以上四点，我觉得未来可能是会发生的。

参考阅读：

• 《微服务架构设计模式》的一点总结

• 如何基于磁盘 KV 实现 Bitmap

• 实时计算，连接时序数据库和核心业务

• AfterShip 亿级流量 API 网关的演进

• TiDB 的架构进化之道
  

技术原创及架构实践文章，欢迎通过公众号菜单「联系我们」进行投稿。

高可用架构

改变互联网的构建方式