作者简介
邢奇（薯片）
蚂蚁团体技术专家，云原生和 Service Mesh 领域专家
长期从事服务治理和服务发现等相干畛域的钻研和实际，在 RPC 框架（Dubbo、Spring Cloud 和 SOFARPC 等）方面有源码级的钻研和奉献；在 Service Mesh、云原生、容器和 K8s 等方面有深刻的钻研和实践经验。
参加了多个开源我的项目的奉献，包含 MOSN、SOFA、Dubbo 和 Nacos 等。目前负责蚂蚁云开发技术负责人，负责支付宝云开发产品的研发和实际。
本文 5689 字，预计浏览 16 分钟
概述
什么是 FaaS？
在 ChatGPT 外面输出 FaaS 关键字，失去的后果是：FaaS 是一种云计算服务模型。它容许开发者编写和部署函数，而不须要治理底层基础设施的运行，即 Function as a Service。
同时通过 ChatGPT 能够生成对应的函数代码——
FaaS 的崛起
FaaS 的理念和函数研发模式，为传统的利用模式解决了许多问题，有着超前的劣势。
传统利用模式的窘境
在研发态，不论是单体利用还是微服务利用，亦或是 Mesh 架构或者利用运行时，在研发态，开发者除了要关注业务逻辑自身之外，常常会被中间件所打搅，须要配合去做 SDK 降级革新，性能或者性能优化等。同时在应用云产品或者云服务的时候，须要被迫去感知多云的差别。
在运维态，开发者面临着更重的运维压力。当一个利用上线，开发者须要对这个业务的将来倒退进行一个简单且不确定的容量评估，再去为这个容量去申请对应的资源，最初通过一个简单的上线流程进行公布。在公布完结之后，开发者还得时刻关注线上流量的变动，去进行一直的扩容和缩容的调整。
总而言之，整个中间件和基础设施对开发者的打搅是十分重大的：
- 利用研发模式的代码耦合重大，复杂度高；
- 运维流程繁琐，效率低；
- 容量评估个别很难合乎真实情况，线上的资源利用率个别都较低，存在着节约。
于是 FaaS 函数的研发模式应运而生。
能够很直观地看到，在传统利用和微服务利用的革新和优化的根底之上，FaaS 心愿做得更进一步，更面向未来。以函数为编程对象，用户无需关注利用、机器等数据和基础设施信息。
通过这样的扭转，大大晋升研发效力，做到疾速开发；并且进步运维效率，提供一站式免运维的 Serverless 平台；最初，函数会随着流量进行创立和销毁，最终降低成本和资源的耗费。
FaaS 应用场景
只管 FaaS 具备许多劣势，但并非所有场景都适宜采纳函数编程模式。上面介绍一些 FaaS 实用的广泛场景：
1、BFF 的场景。 即一些胶水代码（对接多个接口、进行数据的组装和适配等）。胶水代码的逻辑绝对简略，但同时需要变动快、生命周期短。对应的利用场景如经营 / 营销流动等。流动完结之后，就不再有流量进入，也没有必要再进行代码和机器的保护。
2、事件驱动的场景。 例如音视频转码，用户上传文件触发工作，或者通过音讯触发调度，或者业务上有显著的波峰和波峰的流量特色。
3、中台型业务。 例如算法平台的算子。算子计算是十分独立的业务逻辑，然而参加的研发人数十分多，逻辑相对来说不可控，须要有更高的隔离能力。
FaaS 落地面临的技术问题
FaaS 技术产品的落地，可能会面临以下问题和挑战：
性能问题：
1、在传统的微服务架构下，开发者会为 RPC 调用性能进行了大量的优化；在 FaaS 的场景，也须要保障函数调用的性能。
2、弹性扩缩容的反馈时效性。很多 FaaS 产品会采纳弹性的模型去采集 CPU、QPS 并发等指标，再通过平台去计算指标，进而进行一些扩容和缩容的操作，时效性很低。
3、函数启动的速度。函数启动的速度在 FaaS 场景中至关重要，函数容器的创立和启动不仅仅是公布态的事件，而是一个数据面流量的依赖。
平安问题：
1、想要充沛地利用计算资源以降低成本，其必要的前提就是无效地利用和隔离资源。
2、代码容器。用户的函数代码跑在容器外面，避免容器逃逸就是重中之重。
3、相较传统的编程模型而言，FaaS 的编程模型到底是如何屏蔽中间件以及云服务的烦扰的呢？
蚂蚁 FaaS 技术架构
蚂蚁在 FaaS 实际之初设定了 3 个 FaaS 技术架构实际的根本准则。
准则 1：流量模型。 蚂蚁的函数容器是随着流量进行创立和销毁的，而不是通过指标数据进行剖析的弹性模型。
准则 2：函数冷启动。 只管有 Warm Pool 或者 cache 技术可作抉择，但为了最大水平降低成本和利用资源，蚂蚁将指标定为 100ms 以内的极致的冷启动。
准则 3：平安隔离。 用户的函数都跑在咱们的容器外面，因而必须保障高水位的平安隔离个性。
其实，蚂蚁在实际 FaaS 技术架构时，有一个总的准则就是 one request per instance—极致的状况下，是创立一个函数容器去解决一个申请，相似编程模型创立一个线程去解决一个申请。在这里，创立函数容器就相当于创立一个线程，具备类似的疾速、耗费低的长处，同时还有线程所不具备的平安隔离个性。
架构阐明
组件介绍和性能阐明
函数网关：负责对函数申请进行转发和管制，并为每一个申请发动一次容器调度工作。
容器调度引擎 ：负责对容器进行调度，保护容器的整个生命周期，并且能够对函数容器进行并发度和复用等状态管制，同时也负责管理整个集群的函数 Pod 资源池。（ 函数 Pod 资源池是函数容器运行的一个环境，一个集群内会有 N 多个 Pod 资源池。）
函数运行时：函数运行时是 OCI 规范的实现，它负责疾速地启动函数容器，并对容器的 runtime 进行无效的管制。
函数容器：函数容器能够了解为是函数运行时 +runtime+ 用户代码的一个运行态，用户的函数代码就跑在函数容器中。
数据面流量和调度流程阐明
从上图能够看到，所有申请都会通过函数网关进入到函数集群，函数网关会发动一次调度工作：通过容器调度引擎 Scheduler 为这一申请疾速调配一个 Pod 资源。而后网关就会把这个流量转发给这个 Pod 资源外面的节点网关，节点网关随即缓存对应的申请，并且期待函数容器启动。同时函数节点调度器会并发地创立函数容器并且为容器挂载函数代码。函数容器在启动实现之后，就会立即作为一个客户端去节点网关上拉取申请，而后进行业务逻辑解决。
从上述流程中能够看到，蚂蚁 FaaS 场景中的 Serverless 有了第二层含意——no server（没有 server）。函数容器永远是作为一个 client 去解决申请。这样的形式从设计上就防止了对基础设施环境的依赖，同时缩小了须要去关上一些网络端口、解决网络连接的损耗，也不须要像微服务利用那样去做一些 checkhealth 和 readliness 探针等之后能力进行注册，而后再进行服务发现和调用。
性能优化实际
函数网关
FaaS 函数网关采纳 Go 语言进行编写，网络编程模型是通过一个 go routine 解决一个申请的同步编程，比拟合乎开发者的习惯。同时因为 Go 语言良好的垃圾回收机制和 GPM 调度模型，网关也有了不错的性能。然而随着业务的一直增长，整个网关在高并发下会呈现毛刺景象，P99 长尾也比较严重。
基于以上状况，新版的 FaaS 函数采纳 Go 语言的 Gateway 运行在 C++ 语言的 Envoy 运行时上。咱们晓得，越凑近 Linux 原生语言的形式性能越好。同时 Envoy 采纳高性能的同步非阻塞网络编程模型，性能更优。所有的函数申请通过 Envoy 的网络接口进入，并且进行网络解决，而后通过 cgo 调用 Go 语言网关实现的 API 接口，这样 Gateway 网关就能在七层去做一些 filter 和路由的逻辑。最初将申请转发给对应的节点网关。节点网关会进行申请的缓存，同时能够收敛网关连接数。同时函数容器在 running 之后会通过 UDS 和节点网关进行交互。
通过上述优化，能够看到整个函数网关的吞吐回升，并且在同样吞吐的状况下，网关的 CPU 可能降落 50% 以上，而申请耗时降落 30% 左右。
容器调度引擎
HUSE 容器调度引擎，作为蚂蚁容器调度引擎的下一代架构，是专门面向高吞吐、低提早、低成本、急速启动的 Serverleess 场景而设计的。目前利用在 FaaS 场景，以及一些 batch job、ODPS、大数据等场景。
为了可能实现高吞吐、低提早等性能，HUSE 提供了如：多级自适应缓存、高速的协定通信栈、智能包加载等性能优化，同时也反对高可用和自运维性能。
在性能上，能够看到 HUSE 容器调度引擎的性能数据，在全集群 1 万 QPS 吞吐压力下，整个 HUSE 的调度耗时 P50 基本上在 21ms 左右，P99 在 50ms 以内。相比于传统的容器调度引擎，有着数量级级别的晋升。
全集群 10000 QPS 调度吞吐下，HUSE 能够实现均匀 21ms 的容器调度提早
100ms 函数容器冷启动
最初也最重要的一部分，函数容器冷启动性能优化实际。尽管在服务端也做了一些优化，然而服务端整顿的耗时自身也不过几毫秒，可优化空间很小。因而整个函数申请耗时的大头还是在函数容器的冷启动上。而对于函数容器冷启动，有四个方面能够进行性能优化。
第一，是 从 Warm P ool 模式变成齐全的冷启动。在并发的场景下，cache 技术自身也会占用 CPU 核数和计算资源，并不会有太多的性能晋升。
第二，容器资源实时调配改为缓存资源。容器运行依赖一些资源，比方 IP，下载镜像，挂载 volume，设置 cgroup 和 namespace 等。这些资源分配都很慢，根本是分钟级别。而蚂蚁 FaaS 对容器所依赖的所有资源，只有不占用 CPU 和 Mem 的话，都会对其进行缓存，最终将资源分配的速度做到 0ms。
第三，传统的文件系统，创立、挂载以及拜访都比较慢，蚂蚁 FaaS 采纳 ROFS 的文件格式，即 Read Only File System 的形式去进行优化。
第四，是 容器的启动形式。规范的 OCI 容器的启动形式是 create+ start，启动速度很慢，而蚂蚁 FaaS 采纳了 checkpoint+restore 技术进行性能优化。
蚂蚁函数运行时介绍
容器运行时分为 runC、runD 和 runSC 等不同类型。runC 的平安隔离太差，runD 的启动速度太慢并且资源耗费太高，都不适宜 FaaS 的场景。NanoVisor 是蚂蚁 runSC 平安容器。它是 Go 语言编写的平安容器，重构于开源的 gVisor 我的项目，是为云原生设计优化的、弹性平安容器。它也是轻量级 HyperVisor，进行 syscall interception 和 host syscall 减速。反对多个平台的运行，同时在性能方面尤为杰出，能够反对一些火焰图性能剖析，并且对 Go Runtime 进行优化，同时引入了高性能的用户态协定栈。目前利用在 FaaS 和一些加强平安的场景。
ROFS 文件系统优化
上图中能够看到，一个容器会有两个过程，runSC Sandbox 过程和 Gofer 过程，容器镜像解压成 Rootfs 文件 bindmount 到 Gofer 过程中，用户函数代码也一样。Sandbox 须要拜访函数和系统文件，须要通过 syscall 而后被 Gofer 过程拦挡和管制。这种形式是为了保障平安，然而多了一个过程占用 CPU 核数，同时函数拜访系统文件都须要进行 syscall，拉低了速度。
ROFS 文件系统优化，就是将镜像和用户代码都编译成 ROFS 能够解析的格局，并且在沙箱内部关上。同时通过 mmap() 映射到沙箱过程中去。通过这样的形式，能够升高一半的 CPU 占用，同时所有文件的操作都变成了内存操作。不仅更加疾速，而且更加平安。
容器启动形式优化
一个规范的 OCI 容器会提供两个相干的接口：create 和 start。create 是依据容器镜像和配置文件创立容器运行的环境，对应 NanoVisor 容器沙箱的创立和应用程序内核的初始化；start 则是启动容器，对应 NanoVisor 容器沙箱内一号过程 (Nodejs Runtime) 的创立和启动。这个过程十分慢。
蚂蚁 FaaS 采纳的是 checkpoint + restore 形式进行容器的复原。首先依照传统形式创立、启动一个容器，期待容器内的 Nodejs Runtime 初始化实现之后，应用 checkpoint 技术对 Nodejs Runtime 过程和应用程序内核 sentry 进行状态、数据的保留。能够了解为对整个容器进行了一个内存快照，而后导出 checkpoint.img 的种子文件。这样的话，下一次有申请过去，间接从 checkpoint.img 种子复原函数容器，也就是 restore 的过程。所以 restore 就是间接利用之前保留好的过程、内核状态和数据进行复原，不再须要从新初始化 Nodejs Runtime。在复原实现之后，Nodejs Runtime 就能够立即进行业务逻辑解决。
通过以上的优化，目前 FaaS 函数容器落地的启动速度达到了 90ms 以内，额定的内存开销要小于一兆，这一晋升相当可观。其中应用到的 NanoVisor 作为蚂蚁的第三代平安容器，始于平安。因而之后能够期待在性能进步和老本缩减上可能做到十倍甚至百倍的一个晋升。
目前业界的相似产品中，AWS Lambda 函数的冷启动性能是比拟好的：在 Node.js 运行时环境，均匀冷启动工夫为 200ms。
须要留神的是，此数据仅供参考，理论状况会受多种因素影响。
平安能力建设
性能优化的同时，平安性能也必须失去保障。以蚂蚁 FaaS 平安性能的建设为参考。函数容器 (runSC Sandbox) 是一个齐全隔离的 runSC 沙箱环境，配置有 ACL 规定和虚构的 veth pair 网卡。这个网卡是齐全虚构的，没有任何意义，而且在 FaaS 的场景下基础设施从设计上自身就是通明的。网卡的另一端插在 bridge 网桥设施上，并且通过 eBPF 进行高效的网络过滤、管制和转发。因而整个函数容器沙箱是齐全隔离的。
纵向容器防逃逸
函数程序运行在虚拟化的 guest 态，它的零碎调用会被 sentry（运行在 Guest Kernel 态和 Host Kernel 态) 也就是 NanoVisor 解决和响应。NanoVisor 运行在 Guest Kernel 态和 Host Kernel 态，解决所有函数实例的零碎调用，进行限度和管控。同时 NanoVisor sentry 自身的零碎调用也会由 seccomp 进行限度。
FaaS 的场景根本隔离掉了基础设施信息，因而限度的接口会更多，攻击面会更小更平安。同时 NanoVisor 提供过程级别的 NanoVM 虚拟化技术，是一个轻量级的 VMM 治理，作为 host 上的一个内核模块，能够无效保障内核平安。
横向平安能力
在横向管制上，NanoVisor 也做了很多能力建设，包含对所有的网络操作，包含 accept 一些端口、监听 DNS 申请等，都会进行网络审计。同时基于四层网络的五元组信息，都能够进行 ACL 管制。
免鉴权调用
隔离之外，互通也值得关注。所有函数都通过函数网关进入，然而用户函数代码也须要拜访其余的服务。一些场景比方函数代码外面能够拜访其余的函数、拜访云服务、拜访 DB 和 OSS 等，或者拜访公网，或者拜访多云的 VPC 或者 IVS 的 VPC。
在这样的状况下，蚂蚁 FaaS 建设了对应的代理服务和网络设备，在四层为这些服务关上 ACL 管制，同时会在七层进行应用层的认证和受权。认证和受权的过程齐全由 runtime 和代理服务实现，整个过程对开发者是齐全通明和无感的。所以开发者也不须要设置 IP、账号 / 明码等信息，这样能够最大限度地屏蔽中间件、基础设施和多云的烦扰。
体验
有着这样的整体架构，再加上性能的优化实际和平安能力建设，蚂蚁 FaaS 的产品应用体验是什么样的呢？
研发态的体验： 从创立函数到编写函数到执行函数，基本上几秒钟就可能实现一个函数代码的上线。和传统利用模式比照显明，不须要去申请利用创立代码仓库，编写代码，编译打包等。已经在 7 月的一次流动中，一个六年级的小朋友现场花 5 分钟，就实现了整个支付宝小程序 +FaaS 云函数的开发。
运维体验： 因为整个蚂蚁 FaaS 的设计都是合乎 Serverless 理念，所以这里看不到任何基础设施信息，然而可观测性相干的链路日志指标告警是齐全具备的。作为 Serverless 的一站式免运维的平台，它可能主动集成监控和告警性能。
总结
总之，蚂蚁 FaaS 的扭转和劣势在于：
- 从老本上来说，更小内存开销、更快启动速度。用户只用为流量付费，甚至只用为其函数代码的运行工夫付费。（而运行工夫可压缩至一个毫秒。）
- 更高保的平安隔离，可能进行免鉴权的调用。更快的研发速度、更高效的运维。
- 能够疾速开发，没有简单的流程，也没有碎片化的代码版本的困扰。
- 齐全 Serverless 一站式免运维平台，可能集成监控和告警。
瞻望：FaaS + AI 开启编程新纪元
蚂蚁 FaaS 对将来的瞻望包含对 极致性能 与极致效力 的谋求，将通过 fork 等技术去实现更高的性能，同时通过 AIGC 等智能化形式去达到极致研发效力。
极致性能
在极致性能的实现中，蚂蚁目前正在调研的 fork 技术，函数冷启动工夫曾经达到了 3.5ms，稳固地跑进 10ms 以内。有着这样的启动速度，函数容器的创立跟创立一个线程一样又快、开销又低。同时 fork 技术还能够进行和 runtime、和 user code 的组合，让启动再减速。
极致效力
谋求极致效力的形式，就是 FaaS+AI。在文章最开始，能够看到 ChatGPT 生成的一段函数代码，只有十几行代码就能够实现一个业务逻辑的解决。所以 AIGC+FaaS 并非夸夸其谈，而是很有前景的，并且将会在不远的将来落地实际。AI+ 函数开发模式会联合一些低代码平台，并且利用蚂蚁团体的 NLP GPT/ Code GPT/ OpsGPT 等智能化平台，去演进和诞生一些新的产品状态和编程体验。设想将来 PD 或经营通过自然语言，和 AI 平台沟通，由 AI 平台生成一些格式化的 PRD，再输出到相似低代码 / 无代码的平台，平台一方面集成 AI 的代码生成能力，一方面集成 FaaS 的 Serverless 性能，这样将大大提高研发效力。
在过来的几年里，云原生技术曾经扭转了整个运维体验。然而直到明天，研发模式继续了二十多年，还是变化无穷，开发者们还是在电脑背后苦哈哈地敲着键盘。心愿将来 FaaS+AI 能开启编程新纪元，颠覆整个研发体验。
FaaS 延长支付宝云开发
FaaS 技术体系在蚂蚁曾经非常成熟，往年基于蚂蚁 FaaS 技术体系积淀，打造了一款支付宝小程序云开发产品，欢送大家理解试用。
欢送大家搜寻钉钉群号：25600034150，退出支付宝云开发钉钉反对群理解试用：
产品官网：https://cloud.alipay.com/main/product/cloudbase
举荐浏览
1、如何对待 Dapr、Layotto 这种多运行时架构？
2、Service Mesh 的下一站是 Sidecarless 吗？
3、MoE 系列（七）| Envoy Go 扩大之沙箱平安
4、Seata-DTX|分布式事务金融场景案例介绍