Knative 系列(一):基本概念和原理解读

阅读数:7636 2019 年 5 月 10 日 10:01

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,商业策略上也不同于传统资源的计费模式,按照调用次数进行计费,避免了资源冗余造成的浪费,有效节省应用成本。

Knative系列(一):基本概念和原理解读

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

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 从技术到应用有一个全方位的了解。

收藏

评论

微博

用户头像
发表评论

注册/登录 InfoQ 发表评论

最新评论

用户头像
bluce 2019 年 05 月 16 日 18:48 0 回复
k8s和istio还没吃透呢
用户头像
方方正正 2019 年 05 月 11 日 23:33 0 回复
还以为是kotlin-native
用户头像
这个理解厉害了~ 0 回复
用户头像
赵钰莹 2019 年 05 月 10 日 10:04 0 回复
近期正在关注Knative,很好的学习资料,希望出一些实践内容
没有更多了