Serverles是什么？
在讲Knative之前，我们先说一下Serverless。
如同许多新的概念一样，Serverless目前还没有一个普遍公认的权威的定义。最新的一个定义是这样描述的：“无服务器架构是基于互联网的系统，其中应用开发不使用常规的服务进程。相反，它们仅依赖于第三方服务（例如AWS Lambda服务），客户端逻辑和服务托管远程过程调用的组合。”
最开始，“无服务器”架构试图帮助开发者摆脱运行后端应用程序所需的服务器设备的设置和管理工作。这项技术的目标并不是为了实现真正意义上的“无服务器”，而是指由第三方云计算供应商负责后端基础结构的维护，以服务的方式为开发者提供所需功能，例如数据库、消息，以及身份验证等。简单地说，这个架构的就是要让开发人员关注代码的运行而不需要管理任何的基础设施。程序代码被部署在诸如AWS Lambda这样的平台之上，通过事件驱动的方法去触发对函数的调用。很明显，这是一种完全针对程序员的架构技术。其技术特点包括了事件驱动的调用方式，以及有一定限制的程序运行方式，例如AWS Lambda的函数的运行时间默认为3秒到5分钟。从这种架构技术出现的两年多时间来看，这个技术已经有了非常广泛的应用，例如移动应用的后端和物联网应用等。简而言之，无服务器架构的出现不是为了取代传统的应用。然而，从具有高度灵活性的使用模式及事件驱动的特点出发，开发人员／架构师应该重视这个新的计算范例，它可以帮助我们达到减少部署、提高扩展性并减少代码后面的基础设施的维护负担。
传统的 Serverless 解决方案却一直叫好不叫座，这与其自身的问题是分不开的。目前Serverless存在以下问题：
- 缺乏统一标准。呈现碎片化，各家都有各自的实现。
- 厂商锁定。比如使用 AWS Lambda 就必须配套使用 AWS 的 DB, S3 等产品，这样用户就被该厂商绑定，不能进行随意的迁移或者迁移成本非常高。
此时Knative出现了。
Knative
Knative 是谷歌牵头发起的 Serverless 项目，其定位为基于 Kubernetes 的 Serverless 解决方案，旨在标准化 Serverless，简化其学习成本。Knative 是以 Kubernetes 的一组自定义资源类型（CRD）的方式来安装的，因此只需使用几个 YAML 文件就可以轻松地开始使用 Knative 了。这也意味着，在本地或者托管云服务上，任何可以运行 Kubernetes 的地方都可以运行 Knative 和你的代码。
Knative 将重点放在两个关键组件上：为其提供流量serving（服务），以及确保应用程序能够轻松地生产和消费event（事件）。
Serving（服务）
基于负载自动伸缩，包括在没有负载时缩减到零。允许你为多个修订版本（revision）应用创建流量策略，从而能够通过 URL 轻松路由到目标应用程序。
Event（事件）
使得生产和消费事件变得容易。抽象出事件源，并允许操作人员使用自己选择的消息传递层。
关于Serving和Event详细介绍，我们会在后续的文章中一一解读。
knative的优势：
- 便利性：Knative 以 Kubernetes 作为其底层框架，因此无论是线上还是线下，任何 Kubernetes 集群，无论是云上 Kubernetes 服务还是自建 Kubernetes 集群，都能通过安装 knative 插件快速的搭建 serverless 平台。
- 标准化：Knative 联合 CNCF，把所有事件标准化，统一为 CloudEvent，提供事件的跨平台，同时让函数和具体的调用方能够解耦。
- 服务间解耦：使用 Knative 使得应用不在与底层依赖服务强绑定，可以跨云实现业务互通
- 成熟的生态：Knative 基于 Kubernetes 体系构建，与 kubernetes 生态结合更紧密；
- 自动伸缩：监控应用的请求，并自动扩缩容, 借助于istio(ambassador,gloo等)天生支持蓝绿发布、回滚功能，方便应用发布流程。
- 应用监控：支持日志的收集、查找和分析，并支持 VAmetrics 数据展示、调用关系 tracing
结论
Knative 解决了现在Serverless 的诸多问题，如果kubernetes是容器编排的事实上的标准，那么Knative也许就是未来serverless的事实上的标准。
