15年了，我们到底怎样才能用好 Serverless
15年了，我们到底怎样才能用好 Serverless
作者 | 冯嘉，华为云中间件首席专家、PaaS 云原生中间件团队负责人
编辑 | 褚杏娟
编者按：无论是云厂商还是应用企业，在谈到云计算时都不约而同提到了 Serverless。有的已经已经在核心业务上应用 Serverless；有的已经接受了 Serverless 的稳定性和效率，开始小试牛刀；但还有很多企业在观望，或者想要应用但不知道从哪里开始。 虽然已经发展十多年，经过多次迭代，但再次成为业内热议对象意味着 Serverless 已经发展到一定阶段，业内有了更多成果可以分享。在这篇文章中，作者将详细介绍下 Serverless 的发展和生态情况、大家需要关注的技术问题，以及企业应该如何做好 Serverless 落地等，希望对大家的实践带来帮助。
Serverless 发展历程及现状
Serverless 概念
通常意义上来讲，Serverless 可以看作是一种云计算服务模型，它允许开发者在不需要管理服务器的情况下通过事件驱动的方式运行代码。与传统应用服务开发模式不同，开发者只需编写并上传他们的应用代码到云服务商提供的平台上，云平台会自动为应用分配资源，并处理应用的部署、扩缩容。这使得开发者可以更加专注于自己的业务需求和应用逻辑，而不需要考虑服务资源的申请、创建、管理和维护等。从这个意义上讲，我们也可以认为 Serverless 是一个计算范式，它解决资源托管、调度、运维管理等一系列平台型问题，可以看作是 DevOps 的进一步延伸。
从应用开发视角来看，Serverless 包括 FaaS (Function as a Service) 和 BaaS (Backend as a Service) 两部分。在 FaaS 中，开发者编写的代码会被封装成一个或多个函数，运行在云平台上。当请求到达时，云平台自动为函数分配计算资源，拉起函数并执行。执行完成后，平台根据一定的保活策略决定资源的复用或者释放。FaaS 模型不仅可以提高应用的可伸缩性和弹性，还可以大幅降低应用运维的成本。BaaS 则致力于更广泛意义下的 Serverless 化，包括对象存储、缓存、数据库、消息等全栈后端服务的按需弹性、按用付费等。
发展阶段
谈到 Serverless 发展历程，从 2008 年 Google 推出 App Engine 算起，至今已有 15 年的时间，期间经历了多次迭代，主要经历了以下几个阶段。
- Innovators（2008 年~2014 年）：Google App Engine 的发布，使得开发者无须再关心资源分配，也无需关心底层操作系统、硬件和网络等基础设施，对传统应用开发方式具有变革性意义，但 App Engine 并没有使 Serverless 理念流行起来，Serverless 概念本身是在 2012 年由 Iron.io 公司率先提。2014 年 AWS 发布 Lambda 之后，真正使 Serverless 流行起来。
- Early Adoptors（2016 年~ 2018 年）：这期间，主流云计算平台陆续推出了 Serverless 系列产品，如 Microsoft Azure 发布 Azure Functions、Google Cloud Platform 发布 Cloud Functions 和 Firebase、华为云发布 FunctionGraph 等。2018 年 Gartner 将 Serverless 列为“十大未来将影响基础设施和运维的技术趋势之一”。
- Early Majority（2019 年~ 今）：2019 年 UC Berkeley 发表论文《Cloud Programming Simplified：A Berkeley View on Serverless Computing》，预言 Serverless 将成为云计算下一代的编程范式，提出 Serverless = FaaS + BaaS 的定义框架, 并提出存储等后端的 BaaS 化、异构硬件支持、资源细粒度隔离等 Serverless 的核心问题。同期，华为云提出通用 Serverless（General-purpose Serverless）的理念，支持有状态应用、程序自动并行、大规模异构资源管理等，帮助企业解决更广泛的计算、运行与交付问题。
主流的服务形态
从各大云厂商提供的 Serverless 产品看，目前主要有 FaaS、Serverless 应用托管和 Serverless 容器等 Serverless 服务形态。
FaaS 是发展较早的一个方向，它的特点是开发者以函数为粒度对应用进行封装，在无需管理服务器等基础设施的情况下运行函数，支持毫秒级弹性扩容，同时也是三类技术中与事件驱动架构结合最紧密的，例如 AWS Lambda 与 EventBridge 的深度集成，华为云 FunctionGraph 与 EventGrid 的生态合一等，因此，早期的 FaaS 服务往往适用于需要快速响应的事件驱动式场景，如文件上传、消息发送和定时任务。
Serverless 应用托管主要为应用提供全生命周期管理的能力，代表性服务如 Google App Engine，华为云 CAE (Cloud Application Engine) 等，主要提供面向应用的 Serverless 托管服务，提供秒级部署、极致弹性的一站式应用托管方案，往往多用于 Web 应用程序和移动应用后端等场景。
Serverless 容器服务是近几年发展起来的新服务形态，特点是可以让开发者在无需管理和维护集群的情况下，快速创建容器应用 (如 Kubernetes 容器)，是一种 Serverless 化的容器管理能力，主要适用于 DevOps、CI/CD 等业务场景。
从业务场景看，每种服务都有自己擅长解决的问题域，正如软件复杂性所讲的那样——No Silver Bullet，Serverless 技术正在不断持续演进。
FaaS 对基础设施的抽象程度最高，企业在使用过程中的运维负担相对最小。Serverless 容器则开放了更多资源配置的灵活性，但可能会给开发者带来一定程度上的关注疲劳。我们能看到，随着企业级应用开发从 SOA 时代逐步演进到微服务时代，应用的打包、分发与运行等细节逐步被托管态服务隐藏，人们甚至不用关心底层用的是 Tomcat、jetty 还是 undertow 容器。
我个人认为，Serverless 走向架构统一是对用户更加友好、并能缩短企业核心业务 GTM (Go-to-Market) 时间的最佳做法。正如 FaaS 和应用托管长在 Serverless 容器之上，Serverless 容器向下专注于底层资源池的自动化管理和弹性伸缩。“让专注更加专注”。随之而来的，一种新的支撑通用全场景的 Serverless 服务模型应运而生，新 Serverless 时代终将到来。
开源产品与生态
如前所示，Serverless 当前仍处于快速发展中，无论是框架、平台、开发工具，还是服务在内的生态集成，都还未形成事实上的开放标准与规范。在推动 Serverless 更加成熟、可靠和易用的过程中，开源依旧发挥了举足轻重的作用。
底层沙箱方面，有 Firecracker、gVisor、Kata Container 和 WASMEdge 等优秀开源项目，它们在不同程度上关注轻量级、安全隔离、快速启动以及与其它容器编排工具（如 Kubernetes）的兼容性，虽各有侧重，但总体目标是为 Serverless 应用程序提供一个安全、高效的运行环境。
Firecracker 最初被设计为解决裸金属 EC2 上微服务或者无服务架构的应用现代化问题提供支撑。基于 VirtIO 网络，磁盘和套接字驱动，Firecracker 用 rust 重写了日益庞大且复杂的 VMM 实现 QEMU，采用 guest 模型允许用户访问 KVM 的最小元素。这也是为什么 Firecracker 被称之为 MicroVM 沙箱技术。每个 MicroVM 都是以 KVM 进程的方式运行，由操作系统负责进程调度。为了与容器标准兼容，Firecracker 允许 RunC 容器（或者 Pod）运行在其内部，通过 HostOS 上的 containerd 管理 GuestOS 的容器。从而无缝兼容 OCI (Open Container Initiative) 标准规范，镜像格式以及管理工具。
gVisor 为 Linux 容器提供安全隔离的内核层，主打应用级虚拟化沙箱。作为一个普通的用户态进程运行，gVisor 通过实现内核原语（信号量、文件系统、Futex、管道等）的方式，把应用程序的系统调用重定向给主机内核。Kata 则结合了容器的轻量级优势和虚拟机的安全隔离性能，可以与 Docker 和 Kubernetes 无缝集成，对于 IO 密集型调用更高效友好。本质上讲，这些通过在用户态运行一个操作系统内核（裁剪抑或全功能）来为应用进程提供强隔离的思路正在成为安全沙箱的默认选项，只是在实现方式上，需要权衡好安全、性能与扩展开销。
与之前介绍的实现思路不同，作为 WebAssembly 经典的运行时代表，WASMEdge 旨在寻求面向边缘场景的进程级虚拟技术的定位，也是我个人非常看好的方向之一。虚拟机模拟了计算机，容器模拟了操作系统，WASM 则模拟了进程。不难看出，沙箱技术的发展本质上也在推动虚拟化技术的不断发展。近些年来，随着硬件卸载虚拟化技术的日趋成熟，沙箱技术必将演进到一个全新的高度。
往上，在运行时层，Google 通过开源 Knative，为 Kubernetes 提供 Serverless 扩展，包括可组合、可扩展的 Serverless 构建和运行时组件，以及与 Istio 服务网格的集成。Knative 可以看做是对标准化 Serverless 运行时的一次尝试，是一个独立于底层平台的 Serverless 框架，可以部署在多种基础设施之上，包括 Kubernetes、Mesos 和 Docker Swarm。
Fission 则围绕 Kubernetes，主打简化 Serverless 应用程序的开发、部署和管理过程，提供简单易用的 Serverless 体验。我们也在尝试考虑开放内部的函数计算平台，通过批流一体的大规模调度、近数据亲和计算等技术，来解决现有框架无法支持高性能大数据处理等场景的瓶颈，让 Serverless 走向支持更加通用、多场景复杂应用的时代。
其它一些项目主要聚焦应用开发体验，如 Serverless Framework, Serverless Devs。这类工具帮助开发者实现快速创建 Serverless 应用，并简化调试、部署、调测定位等。过去一年，我们联合上海交大、信通院推出了跨平台的 Serverless 基准测评平台 Serverless Bench 2.0，通过对不同 Serverless 平台之间的异构性进行封装，包括统一函数接口、统一返回格式、统一资源配置等，为开发者提供了快速对比不同 Serverless 产品差异化优势的能力，帮助企业设计并开发出更加高性能、低成本的 Serverless 应用程序。
关于“重复造轮子”
我们都知道，前两次生产力革命，分别大幅提升了劳动者生产力与组织的生产力。第三次生产力变革，则大幅提升了品牌的生产力。借用德鲁克的用语，即开启了“心智力量战略”。在竞争激烈的市场中，通过新的定位重塑整个产品的案例不在少数。基于这样的背景，我认为新轮子的出现有其一定的必然性。不同的 Serverless 产品和方案纷纷涌现，各自展现出独特的特点和优势，正是这种积极的、良性的竞争，推动了技术的不断升级和完善。在这个过程中，企业可以通过明确自己的业务目标、市场定位以及受众目标，来确定能够为自身业务带来最大价值的 Serverless 平台。
Serverless 关键问题选谈
极速冷启动
由于 Serverless 架构的特点，应用实例在长时间不使用后会被自动回收 （Scale-to-Zero），新的请求到来时，有一定概率需要重新创建实例，整个过程会带来一定的冷启动延迟。通常，客户的 Java 类函数、Web 型应用对极致冷启动性能有较高的需求。Serverless 冷启动问题通常需要厂商和企业共同承担 (Shared Responsibility), 这由冷启动时延开销的构成所决定。一般地，冷启动过程包括沙箱启动、沙箱初始化、应用代码 / 镜像加载（包括下载、解压、依赖载入等）、应用代码初始化、请求执行等步骤。其中，企业在减缓应用代码加载、应用代码初始化的耗时方面，比厂商有更强的可操作性和灵活性，包括对应用进行瘦身，如消除冗余代码、减少非必要依赖的使用，以降低代码下载、解压时延。企业开发者也可以尽可能将初始化数据库链接、初始化存储等相关代码片段，放到函数调用入口之前，避免每次冷启动重复执行这类耗时操作。
云厂商在冷启动问题上，推出了一系列解决方案。
- 沙箱预热：通过提前启动一批应用沙箱（比如容器），形成预热资源池，冷启动请求达到时，直接从预热池拉起函数实例，从而消除沙箱创建和初始化的开销。
- 实例保活：请求执行完成后，平台不会即刻将实例回收，而是保活一个固定的时间窗（从几分钟到半小时不等），这样，在该时间窗内有新的请求到来时，可以直接复用保活实例，进行热启动。
- 单实例多并发：用户可以为函数配置一个合理的并发度，这样，平台会为多个并发请求只拉起一个实例进行并发处理，从而减少实例创建的数目，降低冷启动次数。
- 预留实例：企业可以为自己的应用配置一定数目的预留实例，预留实例是一种按照一定策略（如定时、指标）提前创建并常驻在平台上资源，请求到达后，通过热启动响应。值得一提的是，FunctionGraph 即将推出的基于 AI 技术的预留实例智能推荐策略，帮助企业在性能和成本之间取得最佳平衡。
- 快照加速：我们推出的基于快照技术的冷启动解决方案 SnapShot，可以显著提升包括 Java 函数在内的应用冷启动性能。当然还有 Oracle GraalVM 中 Java 静态编译技术，可以有效突破 Java 应用冷启动桎梏，实现启动性能质的飞跃。
其它措施还包括对应用镜像或代码进行缓存、采用高性能解压缩算法、公共依赖包分离，及按需加载技术等。关于 Serverless 冷启动，我们近期会发表另外一篇技术文章进行更加系统和深入的介绍。
自动化的状态管理
我们之前讲，尽管 Serverless 提倡无状态优先，但随着数据密集型应用逐渐成为云上应用的主流，如大规模机器学习、大数据与流处理、实时交互型应用、多人协作类应用等，分布式状态管理是无法回避的任务，而且复杂度很高。开发者既希望在这类应用中发挥 Serverless 解决方案的优势，又不想自己处理门槛较高的状态维护问题，因此对 Serverless 平台支持有状态、自动化状态管理的诉求越来越强烈。
FunctionGraph 是业界首个支持有状态的 Serverless 函数产品，用户可以在函数配置界面开启有状态开关，并在函数代码中编写少量状态初始化的 init 代码；之后, 整个状态管理将由 FunctionGraph 接管，平台为函数状态设定独立的 key，状态 key 具有单独的状态路由，平台根据状态路由，对事件请求进行调度。有状态函数为开发者提供了多种状态一致性模型和自动化的并发处理机制，整个状态管理过程由平台内置提供，无需与外部存储服务之间进行频繁交互，显著减少了涉及大量状态数据操作的网络访问次数，具有自动化、高性能、高可用等特点。
轻量化的伸缩原子
“伸缩原子轻量化”是个“功能性”概念，与事件驱动架构是紧密关联的。以 FaaS 为例，主要指“让一个函数尽可能只做一件事”，如果应用需要完成多个功能，则应尽可能拆分成多个函数实现，多函数间通过工作流编排进行逻辑组合。事件驱动模式下，函数通常具有“即生即灭”的特点，随事件触发而生，随响应结束、保活到期而灭。让单个函数保持功能单一，逻辑内聚，不仅能够支持快速的“独立”扩缩容，也能够最大限度地使得应用的各个微服务函数“按需”扩缩容。
举个例子，假设一个应用包含两个微服务函数 A 和 B，分别实现两类功能，对应内存资源均为 1G。当函数 A 的事件流量增大导致实例需要扩容时，可以对比两种方案下的成本：第一种方案下，函数 A 和 B 作为两个函数独立伸缩，此时只需对函数 A 进行实例扩容，资源成本以 1G 为步长进行累加；第二种方案下，函数 A 和 B 被封装成一个内存大小为 2G 的函数，此时扩容，资源成本将以 2G 为步长进行累加，最后总成本也会显著高于第一种方案。本质上，在第二种方案下，函数 A 和 B 由于功能耦合导致资源扩容互相绑架，从而造成额外的成本浪费。
Serverless 与 FinOps
FinOps 是一个相对较新的概念，主要聚焦云上资源管理和成本优化，通过有机链接技术、业务、和财务专业人士，来优化用户、企业、组织的云资源成本，提高云上业务的投入产出比。
我们之前发表过一篇文章《Serverless 遇到 FinOps：Economical Serverless》，里面有提到 FunctionGraph 为帮助用户实现 FinOps 目标所采取的具体技术和措施，包括用户函数成本研究中心（Cost Analysis and Optimization Center），离线式函数最佳配置调优（Offline Power Tuning）、在线式资源消耗感知与规格动态推荐（Online Resource Recommendation）、预留实例智能推荐（Intelligent Recommendation Policy）等，最大限度降低用户实现应用 FinOps 的门槛，为用户业务开发、Serverless 化改造等提供极致便捷性。
另外，Serverless 本身免运维、自动弹性和按需计费的特点，核心也是帮助企业在保障应用性能与稳定性的前提下，消除成本浪费，因此，采用 Serverless 化的架构及其解决方案，本质也是在践行 FinOps 的理念。
持续优化的重要方面
除上面提到的冷启动问题，云厂商和开源社区都在加强对 Serverless 技术和产品的改进，以下举几个例子：
- 微服务 Serverless 化：过去几年中，微服务一直是企业应用架构的首选，但在微服务 Serverless 化的过程中，如何解决注册发现、服务治理、事务一致性、状态管理等问题，需要进一步的研究。前面讲的有状态函数、批流一体的调度、异构硬件的支持，以及 FunctionGraph 的函数间高性能通信技术等，都是在围绕微服务等通用业务场景下的 Serverless 问题进行的探索与实践。
- 语言运行时支持：尽管 Serverless 平台提供了对多种语言的支持，但不同厂商之间支持的运行时版本和语言特性（如基础依赖库等）略有不同，版本更新频率也存在差异，从而可能影响不同开发者的选择。
- 资源隔离与限额：出于租户间资源隔离的考虑，各厂商的 Serverless 产品有一定约束，如单函数最大实例数、单函数最大内存、单实例最大执行时间等。部分场景的业务对这些隔离措施提出了新的要求，例如，微服务、AI 类业务或大数据批处理作业，通常需要运行较长时间。就拿云地图场景来说，通过异步任务处理大规模图片数据，单次执行时间一般在 12 小时以上。为更好地支持数据密集型业务的 Serverless 化需求，我们提供了 72 小时的异步执行能力。
- 可观测性及调试定位：在 Serverless 环境下，由于实例的创建和销毁是自动的，而且多数是无状态的短时任务，其执行时间一般在几个毫秒到几分钟不等。因此，实现实例级的全生命周期监控能力，及其调试、定位等，有一定的挑战。为此，除平台内置提供的日志、监控、链路追踪等，各大云厂商均推出了运行时扩展程序，企业可以灵活地通过自定义的方式接入 DataDog 、Apache SkyWalking 等第三方监控、追踪工具。
企业的落地与实践
择机与切入点
关于 Serverless 适合场景与选择，市面上已经有很多解读。这里，结合我们的一些客户视角，谈谈其中的几个可能的关键考量：
- 业务拥有较强的增长性。当企业处于数字化转型过程中，或业务量快速增长时，服务器等基础设施的管理成本将变得非常高昂，Serverless 免运维、自动扩缩容、按需计费的优势，可以帮助企业消除服务器管理的压力，降低运维成本和人力成本，从而更好地满足业务的增长需求。
- 业务负载有明显的峰谷波动。Serverless 根据实际业务流量的变化来动态扩缩容，且支持细粒度（如毫秒级）的按量付费模式，在业务负载峰谷波动的场景下，相比于传统云计算模式，能够起到削峰填谷的效果，在高峰期快速弹起足量的资源，保障应用性能，在低峰期精准释放资源，节约成本。
- 企业需要快速开发、部署新功能。通过屏蔽底层基础设施、提供应用程序模板、集成公共依赖服务等，Serverless 简化了应用开发和部署的复杂度，从而提高了发布、上线的速度。进一步，Serverless 与事件驱动式架构的紧密结合，让企业可以快速开发出模块之间尽可能独立、松耦合的应用架构，从而允许开发者在原应用基础上不引入额外代码改动的前提下，增加新的功能，实现新功能的快速部署等。
从决定采用 Serverless 架构，到企业完全掌握之间，通常会经过一个短暂的适应。例如，企业可以先在一些小的项目中试用 Serverless，比如使用函数构建一个简单的 Web 应用，通过小规模的测试和验证，感受 Serverless 架构的优点和适用场景。然后从业务场景中选择能够使用 Serverless 架构解决的子问题，逐步将现有应用程序的组件迁移到 Serverless，如数据处理、日志分析、或消息队列处理等，提高对 Serverless 的应用能力。验证成功后，再快速复制、应用到其它业务场景中。对于全新的项目，也可以直接采用 Serverless 架构，这时只需专注自己业务逻辑的设计与编码，体验快速构建应用及其上线与发布。
二次研发的优势和局限
有时候企业为了满足特定的业务需求，需要定制化的 Serverless 解决方案，或企业希望完全掌控自己的代码和数据，避免供应商锁定等时，选择在开源产品的基础功能上进行二次开发，以缩短开发周期。
然而，二次研发需要企业具备相关的技术能力，包括对 Serverless 技术栈的掌握和对开源 Serverless 产品的理解。同时，应用维护成本通常较高，企业需要自己承担 Serverless 平台本身的维护和升级成本，难以真正发挥 Serverless 免运维的优势。此外，开源产品通常由社区开发和维护，缺乏高效稳定的技术支持和服务保障，二次研发也面临一定的业务连续性风险。
采用云上成熟的 Serverless 服务，企业可以聚焦于业务需求和应用逻辑本身，无需再感知或维护底层的基础设施，如虚拟机，容器和 Serverless 运行时；并可以通过对应用所依赖的其它云服务（如网关、存储、消息和缓存）进行灵活编排，来尽可能减少定制化代码的开发，显著降低代码维护负担。更重要地，云化服务可以为企业提供更加高可靠、可扩展、安全稳定的应用运维体验，以及相应连续、稳定的厂商技术支持，从而在企业业务规模化增长的过程中，降低应用运维的总成本。
这里可以举一些经典的客户案例。一家专注于大规模日志采集与结构化处理的企业，在推出自己的 Serverless 化日志流式 ETL 服务的过程中，早期采用了基于开源 Knative 框架的自建方案，但由于自建方案的资源扩容效率低、底层虚机维护门槛高等问题，使得 ETL 服务的运维效率低，同时成本居高不下。在采用基于 FunctionGraph 的云化方案之后, 其 ETL 服务 TOC（Total Ownership Cost）降低了近 40%。另一个案例是一家云地图处理服务提供商，采用 FunctionGraph 对地图处理过程中的异步请求状态进行持久化，相比于早期采用的自建方案，降低了服务 TOC 近 30%。
Serverless 产品选择
企业在选择云厂商的 Serverless 产品时，需要结合自身的业务特点和应用架构，可以从以下几个方面考虑：
- 产品使用体验：包括对编程语言的支持，对开发工具链的支持以及平台提供的应用可观测性能力、开箱即用的应用程序模板、产品易用性等。
- 生态集成能力：对云服务集成的统一体验，如 API 网关、消息、缓存、存储。对三方应用接入的支持，如 Apache SkyWalking、DataDog。从而尽可能减少对基础设施相关代码的定制化开发和维护，同时也确保产品提供了一定的可扩展性和灵活性，以满足将来业务发生变化后对扩展性的需求。
- 成本与性价比：不同云厂商提供的性能规格不同，包括冷启动速度，实例最大规格、最大临时存储、最大运行时长等。各家计费方式也有所不同，企业需对定价进行对比分析，选择符合自己预期的提供商。同时，也可以考虑平台对 FinOps 的支持，如智能化的资源推荐，透明的成本模型。
- 安全与可靠性：Serverless 应用涉及到用户的核心业务数据和敏感信息，如应用源码，企业需要选择有完备安全措施和可靠性保障的云厂商。
其它需要注意的地方还包括产品是否具备符合企业核心需求的差异化特性，包括支持硬件加速（如 AI 类业务对 GPU 的诉求）、是否支持函数编排（如 FunctionGraph Workflow）、是否支持自动化的状态管理等。
从用户反馈看，通常企业既希望享受开发单体应用或单机程序的便捷性，又希望发挥分布式应用的可扩展性、容错性等优势。因此，在产品选择中企业可以关注 Serverless 平台是否支持自动化的分布式能力，如 FunctionGraph 提供的单机函数自动分布式化特性。值得注意的是，Google 近期针对微服务场景下单机应用分布式化所开源的 Service Weaver 项目，反映了同样的理念。
厂商绑定问题
通常意义上我们讲，开放或者开源可以避免厂商锁定。我个人也有 10 年多的开源软件经验，通过开放 / 开源的方式可以更好地触达到开发者，一则加速产品创新，一则也可以形成良好的品牌效应。
但当他们进一步提出可服务要求的时候，还是会综合考虑选择一家可靠的云厂商进行兜底服务。这个道理很容易理解，就像当年个人主机 DIY 时代，像 Dell、IBM 这种巨头公司仍然生存的很好。对于 Serverless 这种新的计算范式的出现，天生就伴随着开放生态的基因，如编程框架与语言、运行时、可观测性、编码与调度等方面。
华为云 FunctionGraph 基于标准的事件驱动模式，对开放标准进行了大量的创新优化与加固，如毫秒级冷启，全链路监控与诊断，高密度调度，极致弹性等。当然，我们在开放标准方面也投入了大量人力，尤其在轻量级沙箱，Serverless 编排等方面积极推动相关开放 / 开源标准的持续升级。任何人随时可以从开源快速迁移到云上，以便享受更优秀的技术创新与服务。
免运维及其对企业的影响
对于企业而言，Serverless 主要免除了对底层基础设施的运维，包括计算资源、存储、网络等，通常也免除了对公共依赖服务的运维，如 API 网关、缓存、消息、事件网格和日志、监控、链路追踪服务等。而企业需要对应用本身进行监控、调试、维护和升级，以确保应用运行符合预期。不过，在应用全生命周期管理的过程中，云厂商会为企业提供实现深度可观测性的工具和基础设施。
以 FunctionGraph 为例，通过集成华为云 APM（Application Performance Management）服务，企业开发者可以便捷地为应用执行时延、请求并发度、实例个数、CPU/ 内存利用率等配置监控指标，对应用进行实时的性能监控；通过内置支持 LTS（Log Tank Service）服务，为应用提供秒级日志搜索、日志转储等功能，使得企业可以进行高效故障管理和调测定位。同时，为了满足企业对扩展性的需求，FunctionGraph 也支持开发者通过编写扩展程序来对接第三方的 SaaS 应用和服务，如 Apache SkyWalking，DataDog 等，从而可以灵活地按需定制功能更加丰富的高阶可观测性能力。
Serverless 可以有效降低企业的运维负担，从而降低应用 TOC。在使用 Serverless 时，企业开发人员将采用新的应用开发和部署方式，包括 Serverless 编程模型、开发工具、运维流程和工具链等；同时，事件驱动架构、按需计费等理念的优势会进一步提高企业应用迭代的敏捷性与经济性。
企业接入 Serverless 后的反馈
这里可以分享几个 FunctionGraph 用户在采用 Serverless 方案后的真实反馈，数据来自我们去年发起的一次客户调研：
某车联网企业：
“我们的版本迭代速度明显加快了，以前发布一个新功能，前后至少需要一个月，现在最快能够做到天级别，我们能够更快地响应市场和用户需求。”
某云地图服务提供商：
“对我们来说，降低运维成本是感知最强烈的一点，架构改版之前，我们的运维人员经常在机器维护和资源容量规划的专项中焦头烂额，用了函数之后，这部分人力基本都释放出来了。”
某互联网音频服务提供商：
“不用再为过度预置的资源所造成的浪费而感到焦虑了。”
某日志处理公司：
“从我们内部的实践效果看，流式日志分析与 Serverless 的理念可以有完美的结合。没有接触函数之前，我们日志计算、存储和可视化的整个链路是非常复杂的，投入了很大的精力在稳定性保障专项中。函数化改造后，大部分能力直接用平台提供的，自动扩容，我们主要就是配个告警。”
某 SaaS 企业：
“我们把微服务的几个模块拆分出来，放到函数上，发现效果很好，也不用再去管理容器资源，低频访问的模块直接缩容到零，成本有显著改善，所以正在迁移剩下的几个模块，后面都是 Serverless 化的。”
Serverless 走向大规模落地
我们在实践中已经看到，Serverless 能够给企业客户和开发者带来非常直观的收益，包括成本节约和效率提升。但普及度和接收度的扩展和深入，还依赖一些关键点的解决，包括技术成熟度、领域标准、迁移难度等。这里我们提供一些思路：
- 确保新技术能够解决好新问题，为 Serverless 的普及度打好基础。Serverless 仍然是一门相对较新的技术，我们前面有讲，对于新增业务或者处于数字化转型初期时，企业可以考虑直接采用 Serverless 的架构进行开发和交付，这样可以从一开始就发挥 Serverless 降本增效的优势。但我们也能看到，企业 IT 和云计算发展这么多年，大量的存量应用，包括 SOA 架构下的本地部署模型，或混合部署、云化部署的微服务等，都在寻求业务转型或架构升级，对于这类“老问题”，Serverless 也需要十分关注。
- 用新技术更好地解决老问题，提高 Serverless 的接受度和市场渗透率。微服务架构流行了挺长一段时间，但发展瓶颈也越来越明显，比如运维压力、资源开销大、扩展性能和基础设施弹性弱等问题。我们可以用 Serverless 的框架去升级微服务架构，也就是我们提到的微服务 Serverless 化。通过 Serverless 基础设施无感知、全生命周期可观测的特征来实现应用的高效构建和免运维交付；通过流式编排和事件驱动实现组装式开发，享受配置驱动的便捷性。基于交互式控制，帮助企业实现微服务应用的自动驾驶；同时，将复杂的状态管理卸载到云平台侧，并采用轻量化的伸缩模块，实现快速扩容和极致成本。
- 推动行业标准的形成和最佳实践的沉淀，积极寻求共识。目前无论是沙箱层，还是运行时层，或者更上面的工具链层，Serverless 尚未出现属于自己的“K8s 时刻”，缺乏事实标准，而企业客户和开发者则是标准的最直接的受益者。标准意味着规范化的调用、具有良好移植性的统一接口、统一的工具链和统一的企业人力技术栈等，类比 K8s 之于容器、S3 之于对象存储等。所以，我们在 Serverless 领域也要积极寻求共识，然后采用标准化的方式推进，以便实现更好的协同效应，推动 Serverless 的进一步普及和渗透。
- 推动应用现代化的发展，通过产品组合方案降低应用的迁移成本。各大云厂商包在应用现代化方面做了很多探索，我们发现，实现复杂应用的高效上云和现代化转型，仅靠一两种单一技术是很难实现的。将 Serverless 技术与应用托管、AI、低代码等技术相结合，通过产品组合来为企业的不同场景提供灵活且多样化的解决方案，满足差异化的业务需求，是我个人最看好的路径。例如现在流行的 6R 方法论（Replatform，Rehost，Refactor，Replace，Retain，Retire），你会发现每个 R 中都涉及到多种技术、产品的组合使用。当然，产品组合方案的复杂性仍然需要在云厂商一侧实现。
今日好文推荐
警方通报网传中电科加班事件调查结果；拼多多解散恶意功能团队；逼死程序员诈骗千万的“翟欣欣案”一审宣判 ｜ Q资讯
腾讯云开发者
