Serverless 架构实战指南：从云原生视角理解 Kubernetes 上的无服务器与 FaaS

Serverless（无服务器架构）是云原生技术发展的高级阶段，它让开发者只聚焦业务逻辑代码，而将服务器、运行时与扩缩容等基础设施细节完全交由第三方托管。本篇指南以《Kubernetes 中文指南/云原生应用架构实战手册》中 usecases/serverless.md 为核心骨架，结合仓库中 usecases/understanding-serverless.md、usecases/knative.md、usecases/openfaas-quick-start.md 与 manifests/openfaas 下的真实部署清单，系统讲解 Serverless 的定义与演进脉络、BaaS/FaaS 两大领域、优缺点与适用场景，并给出基于 Kubernetes 的 OpenFaaS 与 Knative 的实战方案。读完本文，你将能够厘清 Serverless 与 IaaS/PaaS 的关系、理解 FaaS 的触发与计费模型，并在自己的 Kubernetes 集群上复现一套可运行的 OpenFaaS 环境。

什么是 Serverless：无服务器架构的核心定义

「无服务器」并非真的没有服务器。正如无线互联网在很多地方仍然依赖有线连接一样，Serverless 架构的背后依然运行着真实的服务器，只是这些服务器的运维细节完全对开发者透明。在《理解 Serverless》（usecases/understanding-serverless.md）中给出了简洁版与进阶版两种定义：

简洁版：Serverless（无服务器架构）指的是服务端逻辑由开发者实现，运行在无状态的计算容器中，由事件触发，完全被第三方管理，而业务层面的状态则记录在数据库或存储资源中。

进阶版：Serverless 是由事件（event）驱动（例如 http、pub/sub）的全托管计算服务。用户无需管理服务器等基础设施，只需编写代码、选择触发器（trigger，例如 RPC 请求、定时器等）并上传。其余工作——实例选择、扩缩容、部署、容灾、监控、日志、安全补丁——全部由 Serverless 系统托管。用户只为代码实际运行消耗的资源付费，代码未运行则不产生费用。

从「serverful」到「serverless」的转变，本质上带来了三个改变（源自伯克利对 Serverless 的总结）：

1. 弱化了存储和计算之间的联系：服务的存储与计算被分开部署和收费，存储演变为独立的云服务，计算因此无状态化，更容易调度和扩缩容，也降低了数据丢失风险。
2. 代码执行不再需要手动分配资源：无需为服务指定使用几台机器、多大带宽、多大磁盘，只需提交代码，由平台处理资源分配；当前阶段仍需用户提供部分策略（如单实例规格、最大并发数、单实例最大 CPU 使用率），理想方向是通过学习算法实现完全自适应的自动分配。
3. 按使用量计费：按调用次数、执行时长等实际使用量计费，而非像传统 serverful 服务那样按 ECS 实例、VM 规格等固定资源计费。

在 CNCF 的云原生 landscape 中，Serverless 被列为核心类别之一，它是云原生发展到更高阶段、面向特定应用场景的简易抽象，其地位与容器、服务网格并列（见 appendix/ecosystem.md 与 cloud-native/cloud-native-definition.md 中对云原生演进脉络的描述）。

从 IaaS 到 FaaS：Serverless 的演进脉络

理解 Serverless 需要先回顾云计算的分层演进，这一脉络在《理解 Serverless》中有清晰的梳理：

• IaaS（基础设施即服务）：以 2006 年 AWS 推出的 EC2 为第一代代表，本质是服务器租赁与基础设施外包。EC2 带来的五个核心收益是：降低劳动力成本、降低风险、降低基础设施成本、按需扩展性、节约时间成本。除 AWS 代表的公有云 IaaS 外，基于 OpenStack 构建的私有云也能提供 IaaS 能力。
• PaaS（平台即服务）：构建在 IaaS 之上，提供操作系统安装、监控和服务发现等功能，用户只需部署应用。最早一代是 Heroku，开源代表是 Cloud Foundry。在 PaaS 上应用最广泛的技术是 Docker 容器，管理云上容器可称为 CaaS（Container as a Service），既可直接构建在 IaaS 之上，也可基于 Kubernetes、Mesos 等开源软件自建。PaaS 是对软件的更高抽象层次，已触及应用运行环境本身。
• Serverless：构建在虚拟机与容器之上、与应用本身关系更密切的一层（见上图「从物理机到函数计算」的分层示意）。

这一演进回答了核心问题：当应用被迁移进容器与虚拟机时，应用本身的体系结构并未发生根本改变，只是需要遵守 12 因素应用等规则；而 Serverless 对应用体系结构则是一次颠覆——开发者需要重新考虑事件驱动模型、更细粒度的部署形式，以及如何在 FaaS 组件之外保持状态。

BaaS 与 FaaS：Serverless 的两个领域

Serverless 不像 IaaS、PaaS 那样好理解，因为它通常包含两个领域：

• BaaS（Backend as a Service，后端即服务）：一般是一系列 API 调用后端或他人已实现的程序逻辑，例如身份验证服务 Auth0；BaaS 通常用于管理数据，还包括公有云上提供的开源软件商用服务，例如用 Amazon RDS 替代自建 MySQL，以及各类数据库和存储服务。
• FaaS（Function as a Service，函数即服务）：无服务器计算的一种形式，当前使用最广泛的是 AWS Lambda。FaaS 本质上是事件驱动、由消息触发的服务，供应商一般会集成各种同步和异步的事件源，通过订阅事件源可以突发或定期地触发函数运行。

两者的关系可以这样总结：BaaS 依然是服务外包，而 FaaS 使我们更加关注应用程序的逻辑；两者都让我们无需关注应用程序所在的服务器，但服务器在客观上依然存在。

传统服务端软件与 FaaS 的运行方式差异：

• 传统方式：将应用程序部署到拥有操作系统的虚拟机或容器中，长时间驻留在操作系统中运行；
• FaaS 方式：直接将程序部署到平台上，事件到来时触发执行，执行完毕即可卸载，实例无须常驻。

仓库中另外整理了一份 FaaS 开源框架清单（见 usecases/faas.md），其中大部分都是基于 Kubernetes 实现的，包括 faas-netes（OpenFaaS 的 Kubernetes 后端）、fn、funktion、fx、IronFunctions、kubeless、nuclio、OpenFaaS、OpenWhisk 与 Knative 等，可配合后文「Kubernetes 上的 Serverless 生态」一并阅读。

Serverless 中的函数定义

在 CNCF Serverless Whitepaper v1.0 的定义中，FaaS 函数的设计与容器、12 要素应用及 Kubernetes 的运行时设计十分契合：函数是无状态的，输入通过事件/上下文传入，输出返回给调用方，函数本身不保存任何会话状态，状态一律外置到数据库或存储服务。

Serverless 架构的优点

原文档（usecases/serverless.md）与《理解 Serverless》共同总结了 Serverless 架构的核心优势：

• 降低运营成本：Serverless 是非常简单的外包解决方案，可委托服务提供商管理服务器、数据库甚至应用逻辑。海量用户共享服务产生规模经济效应，成本降低体现在基础设施成本和人员（运营/开发）成本两个方面。
• 降低开发成本：IaaS 和 PaaS 存在的前提是服务器与操作系统管理可以商品化，而 Serverless 将整个应用程序组件也商品化了。
• 扩展能力：横向扩展完全自动、有弹性且由服务提供者管理，用户只需为所需的计算能力付费。
• 更简单的管理：更少的组件意味着更少的管理开销。
• 「绿色」计算：据《福布斯》杂志统计，商业和企业数据中心的典型服务器平均仅输出 5%～15% 的最大处理能力，资源浪费严重；Serverless 让服务提供商按实时需求供给算力，从而更有效地利用计算资源。

《理解 Serverless》还进一步补充了以下优点：

• 降低人力成本：部署只需上传基本代码单元（如 JavaScript/Python 源码 zip 包、基于 JVM 语言的纯 JAR 文件），无须使用 Puppet、Chef、Ansible 或 Docker 做配置管理；运维不再监控磁盘使用量、CPU 使用率等底层长期指标，而是直接监控应用本身的度量。需要说明的是，「NoOps」并不存在——只要有应用就有 Ops，只是人员角色发生转变：部署更加自动化、监控更加面向应用本身，底层运维依然需要专业人员。
• 降低风险：组件越多系统越复杂、出故障风险越大。将 BaaS/FaaS 组件外包给专业人员维护，利用专业知识降低停机风险、缩短故障修复时间，反而可能比自建更可靠。
• 减少资源开销：传统方式按峰值容量申请主机资源，往往过度配置，导致闲置时也支付峰值开销；Serverless 按实际需要请求资源、按使用时长与每次申请的计算资源计费，计费粒度更小。这也是对应用本身的优化——每次请求耗时更短、消耗资源更少即可显著节省成本。
• 增加缩放的灵活性：以 AWS Lambda 为例，平台收到第一个触发事件时启动一个容器运行代码；若此时又收到新事件而第一个容器仍在处理，平台会启动第二个实例，这种自动的零管理水平缩放会持续到有足够实例处理全部负载。AWS 只按代码执行时间收费——在一个容器中顺序调用 100 次 Lambda 与在 100 个容器中并发调用 100 次的成本相同。当然平台也不会无限制扩展，AWS Lambda 默认最大并发数为 1000，以避免 DDoS 攻击造成高昂成本。
• 缩短创新周期：小团队可以在几天内从零开发并部署应用到生产，用短而简单的函数和事件粘合强大的数据存储与服务 API。容器技术缩短的是应用迭代周期，而 Serverless 直接缩短了创新周期——从概念到最小可行部署的时间。

Serverless 架构的缺点与适用场景

局限性

• 状态管理：自由缩放要求无状态；有状态服务使用 Serverless 会丧失灵活性，且与存储交互不可避免增加延迟与复杂性。
• 延迟：Serverless 应用高度分布式、低耦合，组件间访问延迟始终是问题。虽然可通过专有网络协议、RPC 调用、数据格式优化，或将实例放在同一机架/主机上来优化，但单纯使用 Serverless 的应用并不现实。
• 本地测试：无服务应用的集成或端到端测试尤其困难，很难在本地模拟生产环境的各种连接，并与性能和缩放特性结合测试；将大量 FaaS 与 BaaS 组件粘合起来本身也颇具挑战。

适用场景

Serverless 比较适合以下场景：

• 异步的并发，组件可独立部署和扩展；
• 应对突发或服务使用量不可预测的场景（主要为节约成本，应用不运行时不收费）；
• 短暂、无状态的应用，对冷启动时间不敏感；
• 需要快速开发迭代的业务（无需提前申请资源，可加快业务上线速度）。

典型使用场景示例：ETL、机器学习及 AI 模型处理、图片处理、IoT 传感器数据分析、流处理、聊天机器人。

游戏应用对比案例：一款移动端游戏通常包含移动端友好的用户体验、用户管理与权限认证、关卡与升级等游戏逻辑及排行数据。传统架构由一个轻量 app 前端 + Java 后端（JBoss/Tomcat）+ MySQL 构成，前端只负责渲染并经由 HTTP 请求后端，所有数据操作由后端 Java 程序完成。这种架构开发容易但维护复杂，需要专业的前后端与数据库人员。而 Serverless 架构中，服务器端代码不再存储任何会话状态，状态直接放入 NoSQL 中，应用因此无状态、便于弹性扩展；前端可直接利用 BaaS 减少后端编码需求，从本质上减少开发人力成本、降低自建基础设施风险，并借助云的能力更快扩展和迭代。

Kubernetes 上的 Serverless 架构

Kubernetes 的蓬勃发展催生了一系列以它为基础的 Serverless 项目。原文档整理了如下核心开源项目清单：

• faas（OpenFaaS）——面向 Docker 与 Kubernetes 的 Functions as a Service 框架
• faas-netes——以 Kubernetes 作为 OpenFaaS 后端的实现
• fn——容器原生、云无关的无服务器平台
• funktion——funktion 的 CLI 工具
• fx——基于 Docker 的轻量 FaaS 框架
• IronFunctions——无服务器微服务平台
• knative——基于 Kubernetes 的现代 Serverless 工作负载构建、部署与管理平台
• kubeless——Kubernetes 原生无服务器框架
• OpenWhisk——Apache 开源、事件驱动、任意规模的函数执行云平台

《理解 Serverless》在此基础上补充了更多生态项目：dispatch（VMware 的无服务器应用框架）、knative/eventing（Knative 事件绑定与投递规范实现）、firecamp（有状态服务的无服务器平台）、fission（Kubernetes 上的快速无服务器函数）、gloo（基于 Envoy 的函数网关）、knative-lambda-runtime（在 Knative/Kubernetes 上运行 AWS Lambda 函数）、nuclio（高性能无服务器事件与数据处理平台）、riff（函数即服务项目）、serverless（Serverless Framework，支持 AWS Lambda、Azure Functions、Google Cloud Functions 等）、cloudevents/spec（CloudEvents 规范）以及 thanos（高可用 Prometheus 长期存储方案）。

这些项目共同印证了 FaaS 与 Kubernetes 的天然契合：Kubernetes 的调度、扩缩容、服务发现与声明式 API 能力，恰好为「事件触发、按需运行、用完即释放」的函数生命周期提供了运行时底座。

实战：在 Kubernetes 上部署 OpenFaaS

OpenFaaS 是高人气的开源 FaaS 框架，可直接运行在 Kubernetes 上（也支持 Swarm 或纯容器方式）。仓库 manifests/openfaas 目录下提供了三份部署清单，部署时用到的镜像包括：

• faas-netesd:0.3.4（Kubernetes 控制器，负责将函数请求转换为 Kubernetes 资源）
• gateway:0.6.14（API Gateway/UI，函数入口与调用代理）
• prometheus:latest-k8s（函数指标监控）
• alertmanager:latest-k8s（告警组件）

注意：仓库中的镜像地址为 harbor-001.jimmysong.io/library/... 私有仓库镜像，实际部署时可替换为 DockerHub 官方镜像（如 functions/faas-netesd:0.3.4、functions/gateway:0.6.14 等）。

部署清单解析

faas.yml（manifests/openfaas/faas.yml）包含两组 Service + Deployment + ServiceAccount：

• faas-netesd Service 以 NodePort 31111 暴露 8080 端口，对应 faas-netesd Deployment（副本数 1，通过 serviceAccountName: faas-controller 关联服务账户）；
• gateway Service 以 NodePort 31112 暴露 8080 端口，对应 gateway Deployment，其环境变量 functions_provider_url 指向 http://faas-netesd.default.svc.cluster.local:8080/，即 gateway 通过集群内 DNS 调用 faas-netesd 控制器来创建与管理函数。

rbac.yml（manifests/openfaas/rbac.yml）为 faas-controller 服务账户授予了必要的集群权限：对 services 的增删改查、对 secrets 的只读，以及对 extensions/deployments 的增删改查——这正是 faas-netesd 控制器「为每个函数创建对应 Deployment 与 Service」的权限基础。

monitoring.yml（manifests/openfaas/monitoring.yml）部署了监控与告警组件：

• Prometheus 以 NodePort 31119 暴露 9090 端口，启动参数指定了配置文件路径、本地存储路径、内存块数，并关联 alertmanager.default:9093；
• Alertmanager 以 NodePort 31113 暴露 9093 端口，负责接收 Prometheus 的告警并进行通知分发。

访问端口汇总

服务	TCP 端口
API Gateway/UI	31112
Prometheus	31119
Alertmanager	31113

部署完成后，通过任意节点的 NodePort 即可访问 UI：http://172.20.0.113:31112（示例地址，请替换为你的集群节点 IP）。UI 中已内置一些函数应用可供试用，例如 NodeInfo 应用可获取函数所部署主机的信息。Prometheus 可在 http://172.20.0.113:31119 查看函数运行指标；如需 Grafana 可视化，可向 Grafana 配置 Prometheus 数据源后导入官方 Dashboard JSON（dashboard id 3526）。

使用 faas-cli 管理函数

OpenFaaS 提供命令行工具 faas-cli 管理函数，可下载对应操作系统的二进制，或执行一键安装：

curl -sL cli.openfaas.com | sudo sh

查看当前部署的函数状态：

faas-cli list --gateway http://172.20.0.113:31112
Function                      	Invocations    	Replicas
hubstats                      	0              	1
nodeinfo                      	0              	1

调用函数 nodeinfo：

echo ""|faas-cli invoke nodeinfo --gateway http://172.20.0.113:31112
Hostname: nodeinfo-699d4bdcbc-s2jfz

Platform: linux
Arch: x64
CPU count: 40
Uptime: 1728200

注意：OpenFaaS UI 中部分 js/css 资源需要科学上网才能正常加载，否则页面可能出现样式错乱。

Knative：构建与管理现代 Serverless 工作负载

在 Kubernetes Serverless 生态中，Knative 是另一个重量级项目。Knative 开源于 2018 年 7 月，由 Pivotal、Google、IBM 等公司共同发起，定位为基于 Kubernetes 的平台，用来构建、部署和管理现代 Serverless 工作负载，它将云原生应用开发在三个领域的最佳实践结合起来：服务构建部署的自动化、服务编排的弹性化、事件驱动基础设施的标准化（详见 usecases/knative.md）。

Knative 包含两个核心组件：

• Eventing：提供使用和生成符合 CloudEvents 规范的事件的构建块，包含对事件源信息流的抽象，以及通过可插拔发布/订阅代理服务支持的消息传递通道实现交付解耦。
• Serving：可缩放至零、请求驱动的计算运行环境，利用 Istio 在各版本之间路由流量，为 Kubernetes 提供用于部署和运行 Serverless 工作负载的扩展功能。

注：Knative 0.8 版本之前还包含 Build 组件（基于 Google 容器构建服务、提供从源码构建容器的可插拔模型），0.8 之后 Build 组件被 Tekton Pipelines 取代。

Knative 的特性包括：面向常用应用用例的更高级别抽象；安全、无状态、可扩展应用的秒级启动；功能松耦合、可任意组装；组件可插拔（可自选日志、监控、网络和服务网格）；可移植——在任意 Kubernetes 集群上运行，无供应商锁定；顺应开发者习惯，支持 GitOps、DockerOps、ManualOps 等通用模式；可与 Django、Ruby on Rails、Spring 等通用工具及框架一起使用。

总结

从 IaaS 到 PaaS 再到 Serverless，云计算不断将基础设施的复杂度向下封装、将开发者注意力向上提升。Serverless 并非银弹（如《人月神话》所言 "No silver bullet"），它有自己的状态管理、延迟与本地测试等局限，但对于异步并发、突发流量、短生命周期与快速迭代的业务场景，它提供了一条「只关注业务逻辑」的高效路径。在 Kubernetes 生态中，以 OpenFaaS、Knative、Kubeless 为代表的开源项目让无服务器能力可以运行在自己的集群之上，将 FaaS 的事件触发模型与 Kubernetes 的调度扩缩容能力深度绑定。本仓库的相关主题还包括 云原生应用架构总览、云原生定义与哲学 与 从 Kubernetes 到云原生，读者可继续深入阅读。