写点什么

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

2019 年 5 月 10 日

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


2019 年 5 月 10 日 10:0128636

评论 4 条评论

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

机器学习(二):理解线性回归与梯度下降并做简单预测

caiyongji

机器学习

脑机接口简史——假如这篇推送是你靠意念打开的

白洞计划

架构实战营-模块一作业

Sun

starforce源码解读一:关键字partial

风翱

C# 源码阅读 4月日更 游戏框架

设计模式-六大设计原则

U+2647

设计模式 设计原则 4月日更

极客架构module 1 作业

Geek_649372

架构实战营

脑机接口简史——假如这篇推送是你靠意念打开的

脑极体

模块一:课后作业

菲尼克斯

架构实战营

Linux grep 命令

一个大红包

4月日更

为什么数据库字段要使用NOT NULL?

艾小仙

作业1--微信的业务架构及学生管理系统

大可

浅聊函数防抖与节流

HaiJun

JavaScript 前端 防抖 节流

学生管理系统方案架构设计

俞嘉彬

架构实战营——作业一:微信架构及学生管理架构

开拓纪

架构实战营 作业一

架构实战营--模块一

永佳

架构实战营

基于二叉树实现Map

Silently9527

Java 二叉树 数据结构与算法

Scrum Patterns:每日Scrum(译)

Bruce Talk

敏捷开发 译文 Agile Scrum Patterns

关于微信架构

俞嘉彬

go每日一库 [go-rate] 速率限制器

happlyfox

golang 学习 4月日更

Wireshark数据包分析学习笔记Day25

穿过生命散发芬芳

Wireshark 数据包分析 4月日更

PCB如何拼版

不脱发的程序猿

嵌入式 电路设计 硬件设计 4月日更 PCB打样

Java 线程同步

anuyyy

Java 4月日更 线程同步 同步代码 同步方法

VUE2,基于vue-cli搭建创建vue项目

Chalk

Vue 前端 4月日更

Vite 2 + React 实践

清秋

less vite antd React 4月日更

机器学习和大数据的区别和联系

大数据技术指南

机器学习 大数据 4月日更

编程好习惯之理清函数参数

顿晓

编程好习惯 4月日更

模块1作业

段吉贵

架构实战营

怎么画出专业的架构图?

秋天

架构师 架构·

架构实战营 模块一作业

netspecial

架构实战营

「架构实战营」课堂作业-G20210698010384

张亮

说人话

ES_her0

4月日更

演讲经验交流会|ArchSummit 上海站

演讲经验交流会|ArchSummit 上海站

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