---
title: Knative 作为 FaaS 平台层
date: '2018-12-05 20:58:21'
draft: false
summary: Knative 真正解决的是源码到镜像、自动伸缩和事件触发统一化这些平台层问题，而不是直接定义完整函数体验。
slug: knative-is-a-faas-platform-layer
syndication:
- platform: Weibo
  url: https://weibo.com/1648815335/H5RuAvPYb
tags:
- knative
- faas
- kubernetes
- serverless
topics:
- software-engineering
type: post
---

粗看了一遍 `KNative` 的文档，再加上敖小剑在 `GIAC` 上分享的材料，我的感觉是：`KNative` 确实把 `Kubernetes` 的可扩展能力发挥出来了，但它本身并不算一个完整的 `FaaS` 产品。

更准确地说，它更像是 `FaaS` 的平台层。

它主要在解决三个问题。

第一，从源码到镜像的 `Build`。

`FaaS` 场景下，开发者理想中的交付对象应该是源码，而不是自己手工构建和管理镜像。镜像当然仍然存在，但那应该是平台负责吸收掉的复杂度，而不该继续暴露给每个函数开发者。

第二，`0-N` 的自动伸缩。

原生 `Kubernetes` 的自动伸缩并不能从 `0` 个 `Pod` 开始。如果一个 `Pod` 都没有，流量先打给谁？`KNative` 为此引入了 `Activator`，在冷启动场景里负责先接住请求，再把 `Pod` 拉起来。除此之外，`FaaS` 场景对伸缩粒度的要求也比原生应用细很多，原来的指标体系不够用。

第三，事件机制。

`Function` 的触发源基本可以分成两类：请求触发和事件触发。`KNative` 的做法，本质上是把事件转换成请求，这样就可以复用同一套服务暴露和伸缩机制。

这个设计我觉得是比较对的。另一种思路是反过来，把请求转换成事件，那样实现自动伸缩可能更顺一些，但请求路径会被拉长，延迟也会更高。

另外一个我比较认可的点是，它没有强推自己的 `SDK`，对应用的侵入比较小，主要通过 `HTTP` 协议和 `Function` 交互。这样一来，它就更适合作为底层平台能力存在，而不是把上层开发体验也一起绑死。

所以如果从系统分层看，`KNative` 比较适合被理解成：一层通用的 `FaaS` 基础设施。至于那些更强调开发便捷性、框架封装、语言体验的实现，其实都可以继续搭在这层之上。

也正因为这样，我会觉得它的价值不只是“又一个 Serverless 项目”，而是在 `Kubernetes` 世界里给 `FaaS` 找到了一层更稳的落脚点。

<!-- WEIBO_MEDIA_START -->
## 原微博中的媒体

![](./weibo-4313972687587943-1.jpg)

![](./weibo-4313972687587943-2.jpg)

![](./weibo-4313972687587943-3.jpg)
<!-- WEIBO_MEDIA_END -->