共计 7228 个字符，预计需要花费 19 分钟才能阅读完成。
以下内容来自：「Techo TVP 开发者峰会 ServerlessDays China 2021」圆桌论坛环节，文字内容分为「高低篇」与大家分享，在 TencentServerless 公众号回复「PPT」，即可支付本届大会演讲 PPT。
首次！腾讯云、AWS、阿里云、字节跳动，寰球 TOP 云厂商和互联网企业齐聚一堂，独特探讨 Serverless 的当初与将来。
论坛主题：聚焦当下，重构将来：Serverless 寰球视线碰撞
主持嘉宾：
- 中国信息通信研究院 云计算部副主任、腾讯云 TVP，陈屹力
圆桌嘉宾：
- Amazon Web Services 首席开发者布道师，费良宏
- 阿里团体 Serverless 标准化标准负责人，陈仲寅
- 字节跳动基础架构函数计算负责人，杨华辉
- 腾讯云 Serverless 专家架构师，杨政权
<img src=”https://main.qcloudimg.com/raw/016da87f9308de31ce7c2c42fa41e276.jpg” width=”700″/>
「灵魂拷问」环节
Q：中国信息通信研究院 云计算部副主任、腾讯云 TVP，陈屹力
费老师您作为 AWS 首席开发者布道师，在工作中可能会遇到一个问题：什么是 Serverless？Serverless 并不是一个很容易被了解和宽泛承受的概念。在布道的过程中，和国外社区相比，国内开发者社区对于 Serverless 的接受程度怎么样？对于没有接触过 Serverless 的开发者或者非技术人员，如何遍及 Serverless 的概念和价值？在布道过程中会遇到哪些挑战，以及有哪些办法值得咱们借鉴？
A：费良宏，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：中国信息通信研究院 云计算部副主任、腾讯云 TVP，陈屹力
还有一个更深层的问题，明天咱们看到很多演讲嘉宾分享的内容，不论是从数据库、中间件、AI 推理等方向，对于 Serverless 的利用都有十分丰盛的教训。作为云厂商十分动摇地认为 Serverless 是将来的方向，并且有很多实际，但用户对 Serverless 还有很多的担心或对利用场景有很多疑虑，这两头的 gap，最大的外围点您认为是在哪里？
A：费良宏，AWS 首席开发者布道师
我认为是 Serverless 标准化的问题。大家会有一个顾虑，当抉择某一个 Serverless 平台的话，就会呈现所谓的 Vendor Lock-in 的平台绑定的问题，让最终的抉择失去了灵活性，因为这个顾虑的存在，可能对于这些独有的技术或者平台特有的技术望而生畏了。
如果可能突破这种顾虑，或平台之间可能更平滑地抉择迁徙，那么后续 Serverless 的遍及将会更容易一些。我在构想有一天有这样工具的存在，无论某一个云的平台，能够用一个工具把函数可能无缝十分好地部署在任何一个抉择的环境当中的话，可能 Serverless 就变得更为容易被承受。
Q：中国信息通信研究院 云计算部副主任、腾讯云 TVP，陈屹力
陈老师经验过屡次淘宝双十一大促，对大流量高并发的治理十分有发言权。在运维和老本管控方面，Serverless 是否施展了劣势？目前支流的 FaaS 产品，内存和 CPU 都进行了绑定，按比例扩容，但存在灵便度有余的问题，如何匹配用户的理论应用场景，造成额定的计算开销，在这个维度将来优化的趋势是什么？
A：陈仲寅，阿里团体 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：中国信息通信研究院 云计算部副主任、腾讯云 TVP，陈屹力
字节跳动在 Serverless 大规模落地方面也有丰盛的实战经验，是否和咱们分享理论我的项目。在进行 Serverless 架构设计以及规模化落地时有哪些误区？比方技术选型、业务粒度拆分、老本、分布式事务管理、部署运维等方面，能够联合具体的案例给大家分享一下常见的 Serverless 利用误区。
A：杨华辉，字节跳动基础架构函数计算负责人
字节跳动的 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：中国信息通信研究院 云计算部副主任、腾讯云 TVP，陈屹力
杨老师是专家架构师，常常须要间接面对客户，那么置信有很多客户会提出一些问题，比方有些客户会顾虑厂商绑定 Vendor Lock-in 的问题。对于头部的企业都在多云、混合云等场景，减少整体零碎的可靠性，也进步了议价空间。目前 Serverless 在对于多云反对的现状如何？还有哪些亟待解决的问题？
A：杨政权，腾讯云 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 寰球视线碰撞（下），行将更新，敬请期待！
One More Thing
立刻体验腾讯云 Serverless Demo，支付 Serverless 新用户礼包 👉 腾讯云 Serverless 老手体验。
