据调查报告显示，无服务器架构市场规模在 2018 年达到 42.5亿美元，预计在 2023 年将达到149.3 亿美元，复合年增长率将达 29％。成本和效率两大原因促使无服务器架构的市场规模正在快速增长，并将成为下一代云计算服务的主流形态。在上海召开的 KubeCon 2019大会上，腾讯云重磅发布了 Serverless 2.0，并对 Serverless2.0 做了技术角度的深度剖析，以下是相关内容。

6月24日，在上海召开的 KubeCon 2019大会上，腾讯云技术总监 Yunong Xiao 发表了《Back From the Future: A Time Traveler’s Take on Serverless》的演讲主题。他表示：Serverless 带来了成本和效率的改变，无服务器的产品和生态正走向成熟，并逐步承载起企业核心业务。

Serverless 2.0 重磅发布

Serverless 服务帮助用户从繁冗的开发配置工作中解放出来，没有任何的基础设施建设、管理与运维开销，开发者仅需关注业务代码逻辑的编写，这种模服务式能够极大降低研发门槛，并提升业务构建效率，获得了大量企业和开发者的支持。

Serverless 无疑是下一代云计算服务形态的趋势，但当前复杂的企业业务系统并不能完全基于无服务来实现，我们分析主要有以下几方面的原因：

性能问题。目前无服务器尚未完全成熟，在性能方面仍存在诸多问题，如同步业务的冷启动延时、高并发的函数实例扩缩容，大规模业务下函数实例的集群管理等
缺乏成熟的开发者生态。企业和研发采用无服务器，需要用监控、Debug 调试、DevOps 等上下游的支持；
需要理解和管理底层的基础设施。当前 Serverless 架构下，客户依然会感知到无服务器集群和资源的存在。

而针对当前企业业务系统不能全面向无服务器转移的问题，腾讯云正在进行持续探索研究，并在上海召开的 KubeCon 2019 大会上，重磅发布了下一代无服务器的发展形态：Serverless 2.0。

关于 Serverless 2.0

对于 Serverless 的概念、发展、形态、应用及优劣对比等问题，腾讯云高级产品经理黄文俊也在大会上发表了主题为《下一代无服务器的发展形态：Serverless 2.0》的演讲，以下是具体的内容

Serverless 及其发展

Serverless 无服务器概念，是指满足无需购买、管理、运维服务器，用户按需使用、按使用量付费，同时平台或产品可以根据使用量自动弹性扩缩容等这几个特性的产品或服务。

目前，Serverless 又被分为了 BaaS 和 FaaS，Baas 包含了存储、数据库、队列、缓存等各种形态的 Serverless 服务；而 FaaS 通常指的是函数即服务 Function as a Service 产品。

在目前云中提供的计算产品形态中，包含了虚拟机、容器与云函数。无论使用虚拟机还是容器，除了要关注自身业务代码之外，还需要有复杂的运维管理工作，例如管理启动进程、打安全补丁、选择开发框架、控制访问权限等等。

而通过使用云函数，用户仅需按规范进行业务代码的编写，就可以对外提供服务。进程的启动时机以及运行所在的服务器运维可以完全交给平台。但当前的云函数产品，在开发方式上和已有的基于VM 或容器的开发方式有所不同。

在基于 VM 或容器的开发模式中，通过使用框架处理 http 请求，启动监听，并由外部命令或脚本来启动进程，是当前开发者都熟悉的业务编写模式。

而使用云函数，http 请求会被转变为一个个的事件，业务代码可以直接针对事件进行处理，并按要求返回数据即可。这种由事件触发，接收 event 消息，并根据业务逻辑进行数据处理的云函数模型，是当前 Serverless 的主要模式。这种模式的函数，我们称为 event function。

事件驱动的核心要素，是能够有丰富的事件源，通过打通各种产品和云函数，使得各产品均可以成为云函数的事件源。这种情况下，函数就成为了产品间的粘合剂，通过承载事件或数据从一个产品流转到另外一个产品，一个函数流转到另外一个函数，在这个过程中实现数据处理，最终建立业务逻辑。

当前的事件触发的 FaaS 形态，在针对业务的削峰填谷、为无状态应用提供弹性的并行处理能力，以及类似 crontab 定时任务这些场景中，提供了极大的优势。

但是同时，当前的云函数，具有访问延时高、运行时长受限、无法直接访问、状态持久化等问题，同时由于开发方式的变化，导致已有的业务，也无法直接向 Serverless 架构迁移，无法做到类似从虚拟机到容器的迁移。

腾讯云 Serverless 2.0

对于已有的 Serverless 产品，以及在产品推广过程中的业务上线的痛点、客户声音，我们重新梳理了 Serverless 产品的发展路线，并将其定义为 Serverless 2.0。

event function

在 Serverless 2.0中，团队从客户的实际使用场景出发，进行了产品的梳理。针对事件驱动的函数，定义为 event function。

事件函数仍然遵循现有的函数触发模式，并将持续增加与腾讯云其他各产品的对接，持续丰富应用场景，例如与日志服务对接，提供日志记录处理；与数据库对接，由数据修改动作触发函数运行；与云监控告警对接，针对告警事件可以进行自动化代码处理等。

而针对 http 场景，通过提供 http function 和 http service 两种形态，更好的支持网络访问处理的场景。

接下来，将对 http function 和 http service 两种模式进行进一步的解读说明。

http function

通过使用 http function，函数可以直接提供外部可访问到的 url 地址，无论是 app 应用，web 应用，还是微信小程序，都可以通过发起 http 调用，访问 url 来调用函数。

而云函数开发中通常的 event 事件结构，优化为 http request、http response 结构，更符合 Web 服务开发的习惯。通过 request 结构，可以获取到 http 请求的相关信息，而通过 response 结构，可以自行构造出所需的 http 响应。

通过这种模式，用户可以专注于业务逻辑的开发，而将原有基于 VM 或容器中需要考虑的扩缩容、进程启动、并发处理等事情都交给平台来解决。

而针对实际业务，通常不仅仅是单个函数就可以实现。在 Serverless 架构中，单个 function 通常仅提供独特单一的功能实现，整个应用通常是由多个函数、以及围绕着函数的数据存储、文件存储、消息队列、API 管理等多种资源构成。

团队从面向 Application 角度出发，基于全套 Serverless 架构，进行了 Serverless 编排框架的设计。通过编排框架，我们可以将应用相关的资源统一到一起，不仅包括了函数，同样会包含数据库、文件存储、消息队列、API 管理等多种资源。无论从应用开发、还是调试部署，开发部署框架均将为我们带来难度的降低、效率的提升。

http service

产品形态中提供的 http service，在同样对外提供 url 访问地址，支持应用直接访问的基础上，我们提供了针对已有代码或框架的支持。

基于常用框架已经开发完成的业务代码，可以无缝迁移至 http service 中，直接开始以 Serverless 模式对外提供服务。而服务中原有提供的高性能通讯协议如 websocket，gRPC，同样可以通过 http service 对外提供。

通过使用 http service 形态，用户无需理解容器、镜像，而是仍然同当前 Serverless 的使用模式一样，同使用云函数一样，通过提交已经开发完成的代码包，就可以开始对外提供服务。

Serverless 2.0 上下游能力

Serverless 2.0 ，关注的不仅仅是计算、开发模式、使用方式，而是要从更全面的角度来支持 Serverless 架构或应用的发展。通过协助开发者更好的使用产品、提供全流程的开发管理支持、运维监控、调试支持等，进行全方面的发力，真正去推动 Serverless 架构或应用的落地。

工具建设

为了协助开发者更好的进行开发、调试、上线、发布，腾讯云 Serverless 团队从多个方面入手，提供可以满足多种开发场景的相关工具或能力。

通过提供命令行工具，我们可以在本地开发环境中实现项目创建、本地调试打包、一键部署上线
而通过 vscode 插件以及正在持续扩展的更多开发 IDE 插件，函数的本地管理、开发调试、上线发布，可以通过开发 IDE 直接可视化操作。将函数的线上线下管理，与代码的编写调试，都整合在一个界面中完成。
为了方便用户进行代码的调整或查看，我们也通过提供 web ide，可以在控制台上实时的开发调试，达到与本地开发调试的相同体验。
针对已经进行了 git 托管的代码，团队增加了 git 对接能力；通过与用户 git 打通，以及依赖包的在线安装，提供了更简单的代码提交部署能力，进一步简化操作过程。

DevOps

在 Serverless 的 DevOps 方面，通过与 coding.net 的合作，我们提供了 Serverless 的 DevOps 方案。通过打通 coding.net 的 DevOps 平台，从项目创建开始，我们就可以进入完全适配 Serverless 的全管理流程中。

无论是项目管理、需求管理、代码管理，还是 CI 持续集成、test 测试管理、制品库管理、CD持续部署，Serverless 架构应用都可以适配整个 DevOps 流程，协助用户构建完全云原生的 Serverless DevOps 过程。

而如果已有 DevOps 或 CICD 系统的用户，Serverless 2.0 也可以通过提供通用方案及工具，协助用户完成整合及融入，在已有流程中实现针对 Serverless 应用的适配。

由于 Serverless 本身的平台调度、按需启动的特性，无法提供和虚拟机或容器类似的登录到环境、手工操作的能力。因此，在协助用户排障、保障运行的透明性方面，Serverless 平台需要做的更多。

运维监控

除了通过对接云的日志服务和监控服务，支持基于日志和监控的多种查询、过滤、告警之外，我们还在规划更多为用户提升调试能力的工具建设，例如通过调用链追踪，可以跟踪请求的经过的各个产品、服务或函数；通过故障现场捕捉，可以抓取函数运行失败时的现场及事件，便于进一步分析代码故障；而应用性能分析，可以了解到函数内部的代码或模块性能，便于进一步提升应用性能。

多种工具的建设，目标都是期望为客户提供更多的分析排障支持，提升运行的透明性，降低对于 Serverless 架构的运维担忧。

技术能力

回到产品实现的底层技术上，针对腾讯云 Serverless 2.0 中提供的三种形态，目前采用了相同的技术架构，包括了微虚拟机、容器、调度平台等多种基础能力；通过采用相同底层能力，提供了高度的产品可扩展能力。

在 Serverless 平台通常碰到的延迟性能方面，通过应用机器学习，预热，扩展策略等多种技术，极大的降低了冷启动。通过当前平台分析，目前97%的事件型函数启动延迟均低于 200ms，对业务基本做到了极低感知，满足了各种场景的应用。

多可用区、多集群、自动运维、平台监控技术的应用，进一步的在提升整体产品的可靠性及安全性。

应用案例

2018年9月，由腾讯云和微信联合推出的小程序云开发解决方案，将 Serverless 概率推向了广大的国内小程序开发者，获得了大量的客户及使用。小程序云开发解决方案，通过整合腾讯云的对象存储，云数据库，云函数，形成了一套可以直接提供给最终开发者的解决方案，带来了一站式的开发体验。

原有小程序开发过程中，针对后端服务，用户需要自行完成服务器搭建，存储选择，数据库配置、负载均衡配置等各种操作。
而通过使用小程序云开发，用户可以直接获得开箱即用的云能力。存储、数据库、以及作为后台服务的函数，直接由小程序端发起调用，而无需自行管理通讯链路、业务扩缩、访问安全等问题。

通过与小程序开发 IDE 整合，用户可以在 IDE 中同时完成小程序端，以及后端云函数的开发、调试、部署，以及文件存储、数据库的的管理工作，大大减轻了开发及管理工作量。小程序云开发为Serverless 概念及应用在国内市场中的推广，起到了及其重要的作用。

结语

Serverless 2.0 在已有的事件触发函数的基础之上，根据实际的用户使用场景，进一步提供了面向 HTTP 场景的 HTTP Function 和 HTTP Service，提供了高层次的通用开发框架，不仅更好的支持开发者面向 Web Service 的开发诉求，也可以支持已有业务代码向 Serverless 架构的无缝迁移。

在技术上，我们在控制流和数据流的模块、虚拟化层、网络层、调度层都做了彻底的重构优化，在安全，可用性，性能上也进行了全面升级。通用统一的底层架构通过采用轻量级虚拟化技术、VPC proxy 转发方案等多种优化手段，以及针对实时自动扩缩容核心的能力优化，彻底规避了传统无服务器架构中，饱受诟病的冷启动问题。

除此之外，Serverless 2.0 还关注开发者从本地开发、代码调试、到业务的持续集成、上线运维等整个软件开发生命周期。围绕着 Serverless 产品，腾讯云构建了全面的开发支持、DevOps、运维监控等能力，协助开发者可以更好的向 Serverless 架构迁移，为 Serverless承载起企业核心业务奠定基石。

去年腾讯云团队与微信小程序进行了深度合作，推出了小程序云开发 Serverless 服务，帮助企业和开发者快速构建小程序核心应用。我们相信，随着 Serveless 2.0 的发展，无服务器不仅可以逐渐承载起企业核心业务，并且能帮助打通监控、Debug 调试、DevOps 等上下游生态，助力互联网和传统企业业务的快速建设与迭代。

本文转载自公众号云加社区（ID：QcloudCommunity）。

原文链接：

https://mp.weixin.qq.com/s/hnQjaqcvV5RSe03LOALZQA

创作场景

Serverless 2.0 重磅发布，无服务器时代来临