Knative 作为 FaaS 平台层

粗看了一遍 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 找到了一层更稳的落脚点。

原微博中的媒体