Serverless 在大厂都怎么用？

以下内容来自：「Techo TVP 开发者峰会 ServerlessDays China 2021」圆桌论坛环节，文字内容分为「上下篇」，点击查看《聚焦当下，重构未来：Serverless 全球视野碰撞（上）》，完整视频请看文末。公众号回复「PPT」，即可领取本届大会演讲 PPT。

Techo TVP开发者峰会 ServerlessDays China 2021 的压轴环节是圆桌对话，首次齐聚 AWS、阿里云、字节跳动等全球 TOP 云厂商和互联网企业，深入探讨 Serverless 当前现状、发展趋势，并针对具体挑战和应对举措进行深度交流。本文是对本次圆桌论坛《聚焦当下，重构未来：Serverless 全球视野碰撞》的分享整理，希望带大家从更加全面的视角了解 Serverless 的价值、使用场景和收益，共同促进 Serverless 在中国的探索和落地。

论坛主题

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

主持嘉宾：

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

圆桌嘉宾：

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

01. 

Serverless 的创新

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

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

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

我认为解决思路有： 1. microVM 性能的提升

通过它本身的加载速度来提升，解决这个问题，这是重要的环节。

2. 解决的技巧问题

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

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

3. 在 Provisioned Concurrency 前面配置一个应用负载均衡器

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

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

陈仲寅，阿里集团 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 的操作。 当然，仅仅做到这点，在 0-1 冷启动时会没有达到规模效应，还是得通过内部的 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 毫秒以内，边缘场景都基本上没有太大问题，大概冷启动问题通过这样的方式去解决。

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

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

02. 

Serverless 距离大规模应用还有多远

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

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

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

这又是一个范围非常大的问题。 1. 工具层面。

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

2. 架构设计方面。

今天的架构师习惯的方法是传统的设计模式，大家已经非常熟练了。Serverless 出现之后，很多人非常谨慎，只是在局部相对次要的环境当中引入 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 的应用设计，应该用什么样的方法论？业务应该拆成多少函数？函数的粒度是多少？

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

03. 

Serverless 的未来

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

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

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

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

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

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

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

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

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

陈仲寅，阿里集团 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 的未来，我是这么想的。

1. Serverless 是 FaaS+BaaS

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

2. 对于 FaaS，其实 runtime 都是开放式的。

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

3. 微服务和 FaaS 慢慢融为一体。

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

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

点击观看精彩演讲视频

推荐阅读

One More Thing

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

• GitHub: github.com/serverless
• 官网: cloud.tencent.com/product/serverless-catalog

点击「阅读原文」，轻松体验 Serverless 应用部署。