本篇文章不做深入的技术讨论，仅从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从技术到应用有一个全方位的了解。

创作场景

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