Knative 系列（一）：基本概念和原理解读

本篇文章不做深入的技术讨论，仅从 Knative 的基本概念及诞生背景入手，让读者对 Knative 的产生初步了解。

Knative 是什么？

2018 年 7 月，Google 在 Google Cloud Next 2018 上发布了Knative，将其定位为基于 Kubernetes 的 Serverless 解决方案，旨在标准化 Serverless，简化其学习成本。自开源以来，Knative 项目备受关注，在 github 上已经获得 1000+的 start， Pivotal、IBM、Red Hat 等公司也纷纷成为其重要的合作伙伴。

传统 Serverless 之殇

既然 Knative 的定位是 Serverless 解决方案，那我们不不妨看看 Knative 之前的 Serverless 解决方案是什么样子。

提到 Serverless，开发者往往可以想到一张经典的图片，它描述了传统互联应用架构与 Serverless 架构的不同点，Serverless 架构让开发者在构建应用的过程中无需关心计算资源的获取和运维，由服务提供商按需分配计算资源并保证应用执行的 SLA，商业策略上也不同于传统资源的计费模式，按照调用次数进行计费，避免了资源冗余造成的浪费，有效节省应用成本。

Serverless 大体上可以分为两种类型：“Backend as a Service” 和 “Functions as a Service”。

BaaS(Backend as a Service) 后端即服务，服务商为客户(开发者)提供整合云后端的服务，如提供文件存储、数据存储、推送服务、身份验证服务等功能，以帮助开发者快速开发应用。

FaaS(Function as a Service) 函数即服务，服务商提供一个平台，允许客户开发、运行和管理应用程序功能，而无需构建和维护基础架构。按照此模型构建应用程序是实现“无服务器”体系结构的一种方式，通常在构建微服务应用程序时使用。

传统的互联网 APP 主要采用 B/S 架构，服务器端需长期维持业务进程来处理客户端请求，并调用代码逻辑完成请求响应流程。而在 Serverless 架构中，应用的业务逻辑将基于 FAAS 架构拆分成多个相互独立的功能组件，并以 API 的形式向外提供服务；同时，不同功能组件间的代码将存储在云服务厂商的函数服务（Function Service）上，如：Amazon Lambda，Azure Function，Google Cloud Functions 等，业务代码仅在被调用时运行，在响应结束时释放资源。

然而，传统的 Serverless 解决方案却一直叫好不叫座，这与其自身的问题是分不开的:

• 厂商绑定

Serverless 只提供了应用本身部署和运行的便利性，但应用依赖的其它服务，比如 API 网关、数据库、消息、缓存管理组件等，会因为选用了某个厂商的 Serverless 平台，而必须使用该厂商提供的配套服务，比如使用 AWS Lambda 就必须配套使用 AWS 的 DB, S3 等产品，这样用户就被该厂商绑定，不能进行随意的迁移或者迁移成本非常高。在 Baas 行业内，一个比较典型的事件是：2016 年 1 月 19 日，Facebook 关闭曾经花巨额资金收购的 Parse，造成用户不得不迁移在这个平台中产生一年多的数据，无疑需要花费比较大的人力和时间成本。

• 没有行业标准

因为对 Serverless 缺乏统一认知以及相应的标准，Serverless 应用无法适应所有的云平台，只适合简单的应用开发，无法推动形成大型成功案例。

Knative：Serverless 大规模商业化实施的基石

Knative 提供了一组标准中间件，专注于在云原生平台上构建和运行应用的通用任务，比如源码到容器的构建、将服务绑定到事件生态系统（通过事件触发工作负载的执行）、管理部署期间的路由和流量以及工作负载的自动扩展。该框架为用户提供了“部署任何负载都需要的熟悉的、惯用的语言支持以及标准化的模式，这些负载包括传统的应用，也包括函数或容器应用”。

相对于传统的 Serverless 解决方案，Knative 的优良性得到开发者和企业认可，这也是其短时间内得到业内各大厂商追捧的主要原因。

细数一下 Knative 的优势，包括：

• 便利性：Knative 以 Kubernetes 和 istio 作为其底层框架，因此无论是线上还是线下，任何 Kubernetes 集群，无论是云上 Kubernetes 服务还是自建 Kubernetes 集群，都能通过安装 istio 和 knative 插件快速的搭建 serverless 平台。

• 标准化：Knative 联合 CNCF，把所有事件标准化，统一为 CloudEvent，提供事件的跨平台，同时让函数和具体的调用方能够解耦。

• 服务间解耦：使用 Knative 使得应用不在与底层依赖服务强绑定，可以跨云实现业务互通

• 成熟的生态：Knative 基于 Kubernetes 体系构建，与 kubernetes 生态结合更紧密；

• 自动伸缩：监控应用的请求，并自动扩缩容,得益于 Istio 能力加持，天生支持蓝绿发布、回滚功能，方便应用发布流程。

• 应用监控：支持日志的收集、查找和分析，并支持 VAmetrics 数据展示、调用关系 tracing

目前，Knative 已经发布到 0.5 版本，每一次更新都离客户的最终诉求近了一步，加上 Google, IBM ，Pivotal，Redhat 这样的豪华社区阵营支持，Knative 的未来必定是一片坦途，相信在很短的时间内，我们就能看到基于 Knative 的成功商业化案例。

下一篇文章开始，我们将对 Knative 的核心组件：Build、Serving、Event 进行深入解读，并结合我们在日常工作中的案例，让大家对 Knative 从技术到应用有一个全方位的了解。