我们先通过一段视频来看看函数计算和容器相结合后，在视频转码场景下的优秀表现。点击观看视频 >>
FaaS 的门槛
Serverless 形态的云服务帮助开发者承担了大量复杂的扩缩容、运维、容量规划、云产品打通集成等责任，使得开发者可以专注业务逻辑、提高交付速度 (Time-to-market) ，持续优化成本。Function-as-a-Service (FaaS) 作为云上最早也是应用最广泛的 Serverless 计算形态，在几年的时间内吸引了大批开发者，逐渐建立了 Serverless 优先的选型逻辑。 然而从传统应用迁移到 FaaS 在开发者体验上还面临诸多挑战:
- 环境不统一：各厂商定义的交付物格式，运行环境兼容性、丰富度都不尽相同，需要开发者适配，甚至重新编译；
- 学习成本：打包依赖库、构建成压缩代码包和熟悉的开发部署方式不同；
- 服务限制：如代码包限制在百 MB 级别，迫使交付物代码依赖分离，加大管理和发布难度；
- 交付物缺乏版本管理：格式不标准，最佳实践不统一，需要开发者自行负责；
- 生态不成熟：缺少流行开源工具（如 CI/CD 流水线）的支持和集成。
另一方面，容器在可移植性和交付敏捷性上实现了颠覆式创新。围绕容器的生态沉淀非常丰富且成熟，被广泛接受使用，应用容器化正在快速成为开发和部署的事实标准。然而，容器本身并没有减轻运维、扩缩容、闲置成本、和云服务集成等难题。因此，实现 FaaS 和容器生态的融合，将帮助开发者获得更多的技术红利。
| 比较项 | 容器技术 | FaaS |
|---|---|---|
| 应用可移植性 | Builds once, runs anywhere | 云厂商锁定 |
| 开发、构建工具链 | 丰富、标准的开源生态 | 云厂商锁定 |
| 持续构建、交付 （CI/CD） | 丰富、标准的开源生态 | 云厂商锁定 |
| 代码、环境分享复用 | 标准镜像 Layer | FaaS 优化的 Layer |
| 运行时环境 | 高度灵活、自定义 | 平台指定的运行环境 |
| 运维责任 | Serverfull, 开发运维人员负责 | Serverless, 云厂商负责 |
| 成本优化 | 容器细粒度编排、部署 | 请求粒度计费，无闲置成本 |
| 伸缩速度 | 和镜像大小相关，10s-分钟级 | 极速，100ms 级别 |
| 事件驱动、云产品集成 | 弱，需自建 | 核心能力 |
函数计算支持容器镜像
阿里云函数计算（简称FC）现已支持容器镜像作为函数交付物，将容器优秀的开发、部署、生态（上线前）融合进函数计算自身的免运维、零闲置成本、云服务集成等特性（上线后），全面升级开发者体验：
- 简化应用 Serverless 化：无需修改代码或是重新编译二进制、共享对象（*.so），本地调试，保持开发和线上环境一致；
- 更大函数代码限制：解压前镜像最大支持1 GB（相比代码包最大解压前 50MB），避免代码和依赖分离，简化分发和部署；
- 容器镜像分层缓存：增量代码上传和拉取，提高开发效率和降低冷启动延迟；
- 镜像分享、复用：逻辑可以移植、减少重复开发建设；
- 混合部署：同一应用 Serverfull (ECS, 容器 ACK)、Serverless (FC, ASK, SAE)，不同应用混合部署或同一应用不同服务间切流，达到性能一致、资源刚性交付、快速扩容、运维最小化的平衡；
- CI/CD： 持续构建、集成测试、代码上传、存储和标准的版本管理，丰富的开源生态 CI/CD 工具可以复用。
典型客户场景
A. 事件驱动音视频处理
音视频处理有流量波动较大、对计算资源弹性要求高、监听视频上传事件以及依赖工作流和队列等服务的特性使得 FaaS 成为自建音视频业务上云的首选。然而这类场景中最常用的软件 FFmpeg 往往需要定制编译满足不同的需求。编译的二进制依赖编译环境中的共享对象（*.so）和 glibc 等库，与 FaaS 运行环境不兼容无法运行。重新编译不仅带来了额外工作，不同的依赖和版本也给业务稳定性带来了挑战。 如下图示例，使用已有 Dockerfile 将转码逻辑以及相关依赖保持现有的安装方式和完全隔离的容器沙箱运行环境，极大降低迁移成本，稳定性风险和 FaaS 的开发部署学习成本。
B. Serverless AI/ML 模型预测、推理 serving
AI/ML 推理预测服务同样可以享受 FaaS 免运维、自动伸缩、低成本的好处。然而社区流行的框架如 TensorFlow 都默认以容器镜像的方式分享和复用。不仅官方提供了完整的版本覆盖，基于官方镜像的社区生态也非常活跃。在离线模型训练阶段以容器镜像部署在 ECS 或 ACK/ASK GPU 集群。 在服务推理/预测（serving inference/prediction）阶段，CPU 往往是性价比更高的选择。Serving 的特点是请求量驱动，既需要能快速响应突发（burst）流量，又要在波谷周期释放资源，甚至是缩容至0节省成本。而这些需求天然就是函数计算所擅长的。
在没有容器镜像支持之前，想要将一个 TensoflowFlow serving 的示例部署在函数计算上并不容易。TensorFlow 本身的库大小远超过代码包 50MB 的限制，将依赖打包进 NAS 可以绕过这个问题，然而却增大了上手和迁移的难度。不规范的依赖和版本管理也为变更引入稳定性风险。而使用容器镜像以及函数计算 HTTP server 的编程模型，简单的几行 Dockerfile 就可以在 FC 跑起来 Tensorflow Serving 的示例：
函数计算支持容器镜像帮助 AI/ML 场景平滑地混合部署容器和函数，统一 CI/CD 工具、流程和最佳实践。函数计算免运维、高并发、百毫秒级别的实例扩容和 100% 资源利用率进一步优化了服务质量和成本。
C. 传统 Web 单体 HTTP 应用的 Serverless 演进
传统 Web 单体 (monolithic) 应用现代化有三个主要的诉求：责任拆分、减轻运维压力（资源规划、系统升级、安全补丁等运维负担）以及成本优化。虽然采用职责单一的函数是一种最佳实践，但是进行职责拆分往往需要更长时间的设计和重构。借助函数计算的镜像支持能力，单体应用可以很容易的迁移至 FaaS 服务以满足免运维，弹性水平扩展和100%成本效率的诉求。
传统 Web 应用由于历史原因或者业务复杂度，运行环境（容器镜像）和业务逻辑往往高度耦合且解耦代价较高。为了 Serverless 化改造有时不得不升级操作系统及依赖库版本，在 FaaS 厂商提供的环境中重新编译。迁移至 Serverless 架构有时间成本和稳定性风险。函数计算对容器镜像的支持帮助传统容器化 Web 应用无改造，更快地享受 Serverless 的价值，将时间和精力专注于业务逻辑创新和迭代而非重复枯燥的环境、依赖版本管理、升级维护和容量规划和伸缩。
D. 云上云下，跨云厂商混合部署
企业上云的节奏在不断加快，然而由于业务特性，私有云和公共云混合的运行方式将是未来相当长一段时间内作为常态。企业甚至需要多云厂商来保证迁移、容灾、资源刚性交付的需求。容器镜像是云上、云下的软件交付物统一的默认选择。函数计算自定义 runtime 选择 HTTP server 标准的交互方式，函数代码编程方式不与厂商绑定，减轻企业对云厂商锁定（vendor-lockin）的顾虑，在云上可以运行的函数，在云下甚至其他云厂商同样可以作为独立的 HTTP Web 应用单独部署，服务请求。容器打包的函数可以运行在其他云服务的容器服务或 IaaS 自建服务，实现多云的容灾、弹性资源的保障。
E. 冷启动最佳实践
FaaS 代码包的交付物将业务逻辑和执行环境剥离，最小化运行业务逻辑所需要加载的数据量，最大程度优化了冷启动速度。容器镜像则是将运行环境和业务逻辑统一交付，在可移植和冷启动速度之间做了取舍。自定义运行环境的引入必然会增加额外的冷启动延迟，对此我们推荐以下的冷启动优化最佳实践：
- 容器镜像地址推荐使用与函数计算同地域的 VPC 镜像地址，例如
registry-vpc.cn-hangzhou.aliyuncs.com/fc-demo/helloworld:v1beta1, 以获得最优的镜像拉取延时和稳定性 - 镜像最小化，使用类似 docker-slim 工具仅保存必要的依赖和代码，避免不需要的文档、数据或其他文件造成的额外延迟
- 在资源允许和线程安全的情况下，搭配单实例多并发一同使用，可避免不必要的冷启动，同时降低成本。
- 容器镜像配合预留实例一起使用，消除冷启动。
F. DevOps/GitOps 最佳实践
容器镜像的支持标准化了构建步骤和函数交付产物，让复用 CI/CD 工具成为可能。函数计算与阿里云云效 DevOps 服务集成，推出了 CI/CD 流水线。如下图所示，当有新的代码被 push 进入代码仓库（Github/Gitlab） Master 分支, 构建流水线任务被开启，按照代码中指定的 Dockerfile, 容器镜像会被构建并推送至阿里云容器镜像服务。流水线的最后一个步骤会部署发布新版本的函数，完成一次自动化的发布。
除了云效 DevOps 完整自动化的持续集成交付体验，阿里云容器镜像服务和自建开源 CI/CD 流水线也同样可以用下图展示的方式自动化函数发布。函数计算发布方式的标准化使得企业可以用统一的工具持续交付多个不同的服务，降低开发运维人员对部署工具的学习成本，自动化部署提高成功率和交付速度 (time-to-market)。
和 Custom Runtime 的异同
函数计算在 2019 年已经推出了自定义运行时 Custom runtime，那么这次发布的自定义容器（custom-container）和已有的运行时有和异同呢？
- 相同的编程模型和函数计算系统的交互方式：完全相同的 HTTP server 协议，已有的 custom runtime 函数可以直接移植到环境兼容的自定义容器环境中，不需要修改代码：
- 两个 runtime 有不同的适用场景和取舍：
a. 对于非容器化的应用，您可以持续使用 custom runtime
b. 对于冷启动延迟容忍度较低的场景，推荐您使用 custom runtime 节省镜像拉取时间
c. 对于异步离线且已经容器化的任务（Job 类型），推荐您使用 cutome-container runtime
d. 使用函数计算预留实例，且部署环境和业务逻辑耦合紧密的应用可以优先考虑使用 custom-container runtime
未来规划
随着容器逐渐成为应用交付部署的标准方式，FaaS 会和容器生态做更紧密的融合，帮助容器化的应用以更低的成本 Serverless 化，包括周边配套生态例如声明式的部署方式的融合，同 K8s 相似的应用抽象，云原生可观测性软件集成。
基于容器镜像拉取加速，让函数计算能兼顾可移植和快速启动的性能。容器技术和 Serverless 的初心都是要帮助用户更快地交付（time-to-market）和持续优化成本，消除资源闲置产生的浪费，增加企业竞争力。最终，云原生的两大技术领域：Serverless 和容器技术的联系将会变得更加紧密，开发部署运维差异不断缩小，让开发者几乎不需要修改业务逻辑即能为不同的工作负载选择合适的技术方案，用开放、标准、统一的云原生技术持续创新，为客户创造更多价值。
