Serverless 开源架构方案

2014 年 11 月，AWS 发布了新产品 Lambda，开启了全新的 Serverless 时代。按照当时的描述，Lambda 是一种计算服务，它按需运行用户的代码，用户无须关注底层的计算资源。继 AWS Lambda 之后，很多公有云提供商都推出了自己的 Serverless 支持。2016 年 Google、Microsoft Azure 相继推出自己的 Cloud Function 服务，2017 年国内公有云提供商阿里云和腾讯云也分别推出了各自的 Serverless 产品。

整体来说，Serverless 当前还处于发展初期，正在快速地迭代，并且各个云厂商均推出一套自己的 Serverless 标准，所以这些 Serverless 是无法互通的，从而导致一旦选定了某个云厂商，就会被这个云厂商的技术体系绑住，无法自如地迁移。面对 Serverless 领域当前的无序和混乱，Google 联合 IBM、Pivotal、Redhat 和 SAP，一起推出了 Knative，目的是实现 Serverless 标准化。

Knative 是一个以 Kubernetes 和 Istio 为基础的 Serverless 开源架构方案，目的是解决 Kubernetes 环境下 Serverless 应用的构建、部署和运行。Knative 和以往 Serverless 解决方案最大的不同是，Knative 不仅管理函数，它的定位是管理所有的工作负载，除了 Serverless 关注的函数外，还包括普通的微服务，因此 Knative 强调的是通过相应的机制，用户不用再关注应用的伸缩和运维。

此外，Knative 不是实现一个具体的 Serverless，而是构建一个能够运行标准化 Serverless 的平台，Knative 提供大量的扩展性支持，允许其他 Serverless 产品在其上运行。

架构上，Knative 由 Build、Serving 和 Eventing 3 个核心组件组成。其中 Build 负责构建工作，把用户定义的函数和应用构建成容器镜像；Serving 负责计算工作，具体包含 Serverless 实例的路由和访问，以及 Serverless 实例的按需伸缩；Eventing 负责事件工作，自动完成事件的绑定和触发执行。

Serving 系统基于 Kubernetes 和 Istio 进行开发，利用 Kubernetes 强大的容器调度和生命周期管理能力以及 Istio 的通信和通信链路治理能力。另外，为了屏蔽 Kubernetes 和 Istio 的复杂度，Knative Serving 自身有更高一层的抽象能力，提供一组用来对应用和通信进行管理的抽象概念（可使用 Kubernetes CRD 对这些抽象概念进行管理）。Knative Serving 的主要概念如下。

1）Route：工作负载的路由规则，对应 Istio 的 VirtualService。

2）Configuration：应用的最新配置，对应 Kubernetes 的 Deployment。

3）Revison：每次对工作负载进行修改的快照，对应 Istio 的 Subset。

4）Service：对工作负载的整个生命周期进行管理。

Knative 的 Serving 系统做的事情和 Kubernetes、Istio 大体相同，但通过提供更高的抽象，屏蔽了 Kubernetes、Istio 的细节，自动帮应用管理好 Deployment、VirtualService 以及 auto scaling 之间的关系。

auto scaling 是 Knative Serving 实现工作负载自动伸缩的关键组件，当前还处于发展早期，有不少性能问题，很不成熟，Knative 后续计划将 auto scaling 下沉，直接复用 Kubernetes 原生的 auto scaling 能力。

基于 Kubernetes 的 Serverless 产品和解决方案市场上已经有不少，比如 Fission、Funktion、Kubeless 等，但同时依赖 Kubernetes 和 Istio 这两个重量级的项目，Knative 还是第一个。Kubernetes 和 Istio 的复杂度都很高，同时基于 Kubernetes 和 Istio，再加上 Serverless 自身的复杂度，会导致整个 Serverless 解决方案的复杂度非常高，学习曲线上也非常陡峭，因此很多人都有如下疑问和质疑：Knative 中为什么采用 Kubernetes 和 Istio 这么重的通信解决方案？

从架构和通信功能实现来看，确实没有必要，为了对上层用户屏蔽底层 Kubernetes 和 Istio 的实现细节，Knative 又引入了一层抽象概念，对 Kubernetes 的容器和通信功能进行封装。如果通信直接放在 Knative 层面上做，只聚焦 Kubernetes 平台对 Serverless 的通信支持，不需要平台扩展性和场景扩展性支持，架构设计上会特别简单，同时灵活性也会比现在好。

从短期和静态的角度看，Knative 引入 Istio，确实没有那么大的必要，因为增加了复杂度，减少了灵活性。但从云计算基础设施的大趋势来看，Kubernetes 已经成为容器调度和生命周期管理的事实标准，可以看成云原生时代的 Linux 操作系统；Istio 虽然产生时间不长，但已经显现出强大的发展势头，当前在 Service Mesh 和 Kubernetes 生态中的地位已经不可撼动，可以看成云原生时代的 TCP/IP 协议。

因此，如果从云计算的发展趋势上看，通信功能会被 Istio 完全接管，并下沉为基础设施的一部分。在通信层面，Istio 肯定更聚焦、更专业，Knative 从大趋势出发，直接复用 Istio 的通信层功能，避免后续架构上的修改和返工，可以将自身聚焦到 Serverless 层面的功能和生态打造上。从架构的角度看，这也是 Unix 设计哲学的体现——整个系统采用模块化设计，每个模块只聚焦一件事情，并且做好做到极致。