serverless开源框架（IBM、谷歌等一票大佬共同研发的Knative，究竟是什么）

本文目录

• IBM、谷歌等一票大佬共同研发的Knative，究竟是什么
• 闲鱼前端基于serverless的一种多端开发解决方案
• 什么是Serverless架构

IBM、谷歌等一票大佬共同研发的Knative，究竟是什么

Knative是什么？

要了解这个问题，你必须先了解什么是Kubernetes？以及Kubernetes最大的问题是什么？

Kubernetes是一个开源的，用于管理云平台中多个主机上的容器化的应用，Kubernetes的目标是让部署容器化的应用简单并且高效（powerful）,Kubernetes提供了应用部署，规划，更新，维护的一种机制。

那么问题来了！Kubernetes有一个最大的槽点就是入门门槛略高，而Knative正是为了解决这个问题来的。

Knative 的⽬标是在基于 Kubernetes 之上为整个开发⽣命周期提供帮助。它的具体实现⽅式是：⾸先使你作为开发⼈员能够以你想要的语⾔和以你想要的⽅式来编写代码，其次帮助你构建和打包应⽤程序，最后帮助你运⾏和伸缩应⽤程序。

为此，Knative 将重点放在三个关键组件上： Build（构建） 你的应⽤程序，为其提供流量 Serving（服务） ，以及确保应⽤程序能够轻松地⽣产和消费 Event（事件） 。

Build（构建）

通过灵活的插件化的构建系统将⽤户源代码构建成容器。⽬前已经⽀持多个构建系统，⽐如 Google 的 Kaniko，它⽆需运⾏ Docker daemon 就可以在 Kubernetes 集群上构建容器镜像。

Serving（服务）

基于负载⾃动伸缩，包括在没有负载时缩减到零。允许你为多个修订版本（revision）应⽤创建流量策略，从⽽能够通过 URL 轻松路由到⽬标应⽤程序。

Event（事件）

使得⽣产和消费事件变得容易。抽象出事件源，并允许操作⼈员使⽤⾃⼰选择的消息传递层。

Knative 是以 Kubernetes 的⼀组⾃定义资源类型（CRD）的⽅式来安装的，因此只需使⽤⼏个 YAML ⽂件就可以轻松地开始使⽤ Knative。

可以看出，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虽然很年轻，但其成长速度非常快。其作为当今云原生态领域发展最快的开源项目之一，不仅通过提供简化工作流程的工具来解决这些问题，而且还为Kubernetes集群带来了非服务器工作负载的强大功能。目前已有不少项目加入到了年轻的Knative生态系统，且趋势是不断增加的。

目前Knative 还在不断的更新优化中，每一次更新优化都离客户的最终诉求更近了一步，Knative 的未来必定是一片坦途，相信将来通福云以及整个行业将会看到很多选项和机会将Knative 运用起来。

闲鱼前端基于serverless的一种多端开发解决方案

前端的发展太快了，前端框架和技术的发展也层出不穷，还包括不同智能设备的出现，对前端开发同学来说是个很大的跳转，简单列举下：

这样就滋生了一些问题，比如我要开发一个通用的页面，兼容不同的端侧和 小程序 ，显然目前是做不到的，我们只能开发多套页面去适配不同的场景，这样的话成本就太高了。

很多同学都在尝试解决这个问题，也催生了类似taro这样的多端统一开发框架，这是一个好的解决方案，但是比较被动，缺乏一定的扩展性。

这篇文章我们要探讨的是，看能不能换个角度去解决这个问题，提升开发效率。

ViewModel

当我们在开发一个页面的时候，不管用的是哪一种框架，通常都会抽象出一层viewmodel层，它主要有2个作用

从上图中我们可以看出，viewmodel是一段独立的通用代码逻辑，起到了承前启后的作用。它和view层关系更加紧密，因此通常会放在前端测。

既然viewmodel是独立的，那我们能不能把它放在后端呢？这样一个最大的好处就是viewmodel可以进行复用，不需要在重复编写，而且只需要改动一个viewmodel，就可以全量生效。

似乎是一个很美好的想法，但是这部分代码由谁去开发呢，总不可能寄希望于后端同学吧，当然只能是我们自己，也感谢于serverless架构的出现，让这件事情变成了可能。

有些同学可能会问，既然viewmodel后移了，那view呢？后续会考虑结合我们的ui2code技术，那真的就比较完美了。

什么是serverless

架构上，我们可以把serverless分为FaaS和BaaS。

FaaS是用于创建、运行、管理函数服务的计算平台，它支持多种开发语言，比如java、nodejs、dart等，这有利于不同端侧的开发同学介入开发。FaaS是基于事件驱动的思想，只有当一个函数被事件触发时才会占用服务器资源执行，不然都是无需占用服务器资源的。

BaaS提供了用于函数调用的第三方基础服务，比如身份校验、日志、数据库等，它是由服务商直接提供，开发者无需关系实现，直接调用即可。

业务落地

我们是通过gaia平台开发后端接口，gaia可以理解为上文提到的FaaS平台。

日常开发中有这样一个需求，下面是这个需求的一个页面。

因为这个页面上的数据比较多，先把它切分成一个个小的模块，后台返回数据的时候也根据模块来返回数据。

我们是根据viewmodel来设计接口，首先肯定有一个首屏数据接口；然后是页面上的交互，比如切换卡片、切换芝麻信用按钮，切换会引起页面数据变化，我们可以统一封装一个页面更新的接口；最后是一个开通的接口。

后端接口

前后端交互最重要的数据结构的设计，我们省略了中间的业务逻辑处理，看下接口的数据结构。

首屏接口返回的数据主要有几个特征：

更新接口的返回数据结构和首屏接口类似，但是入参有所不同，主要包括2个字段：

前端处理

从后端返回的数据可以看到，数据是及其详细的，无需我们做任何的业务逻辑处理，直接映射到页面即可。这样，前端已经变成了很薄的一层数据，没有任务的业务逻辑处理，变的很简单，当需要迁移到其他端时，只需要迁移视图层即可。当有任何的业务变动时，只需要修改后端的接口，就能生效。

收益与总结

通过具体的实践，我们发现，对于前端开发同学来说，变的简单了，开发效率有很大的提升，前端同学甚至都不需要去理解具体的业务逻辑，就能完成页面的开发。而且，提取的viewmodel可以复用到不同的端侧，设置还包括native端。我们还可以将viewmodel拆分成更小粒度的viewmodel，方便在不同的页面接口中进行复用。我们有同学还在FaaS侧基于redux的思想封装了一个通用的状态管理框架，规范了前后端的交互。

后面， 还有一些问题待我们去解决，比如开发成本、viewmodel的逻辑拆分、具体接口问题定位等。

闲鱼团队是Flutter+Dart FaaS前后端一体化新技术的行业领军者，就是现在！ 客户端／服务端java／架构／前端／质量工程师 面向 社会 招聘，base杭州阿里巴巴西溪园区，一起做有创想空间的社区产品、做深度顶级的开源项目，一起拓展技术边界成就极致！

*投喂简历给小闲鱼→ guicai.gxy@alibaba-inc .com

开源项目、峰会直击、关键洞察、深度解读

请认准 闲鱼技术

什么是Serverless架构

Serverless（无服务器架构）是指服务端逻辑由开发者实现，应用运行在无状态的计算容器中，由事件触发，完全被第三方管理，其业务层面的状态则存储在数据库或其他介质中。

Serverless可以使开发者更聚焦在业务逻辑，而减少对基础设施的关注。

Serverless通常包含了两个领域 BaaS（Backend as a Service）和 FaaS（Function as a Service）

• BaaS是一种广泛依赖于第三方应用和服务的无服务器计算方法。BaaS供应商可以提供加密、用户认证、云数据库的使用。这些服务可以通过调用云供应商提供的API进行访问；相比自己重新开发，这些功能可以更方便地整合到各个类型的系统中。

• FaaS 是一种事件驱动的由消息触发的服务，FaaS 供应商一般会集成各种同步和异步的事件（如AWS的SNS），通过订阅这些事件，可以触发指定的函数运行，例如当前使用很广泛的 AWS 的 Lambda函数。

Serverless架构的优点

• 降低运营成本：

Serverless是非常简单的外包解决方案。它可以让您委托服务提供商管理服务器、数据库和应用程序甚至逻辑。由于这个服务使用者的数量会非常庞大，于是就会产生规模经济效应。在降低成本上包含了两个方面，即基础设施的成本和人员（运营/开发/维护）的成本。

• 降低开发成本：

Serverless作为一种云服务，使得整个应用程序组件被商品化。

• 扩展能力：

横向扩展是完全自动的、有弹性的、且由服务提供者所管理。从基本的基础设施方面受益最大的好处是，您只需支付您所需要的计算能力。

• 更简单的管理：

Serverless架构明显比其他架构更简单。更少的组件，就意味着您的管理开销会更少。

• 有效利用计算资源：

据《福布斯》的统计，在商业和企业数据中心的典型服务器仅提供5%～15%的平均最大处理能力的输出。这无疑是一种资源的巨大浪费。Serverless让服务提供商提供我们的计算能力最大限度满足实时需求，更有效地利用计算资源。




Serverless架构的缺点

• 状态管理：

要想实现自由的缩放，无状态是必须的，而对于有状态的服务，使用serverless这就丧失了灵活性。

• 延迟：

Serverless应用程序是高度分布式、低耦合的，这就意味着延迟将始终是一个问题，单纯使用serverless的应用程序是不太现实的。

• 本地测试：

Serverless应用的本地测试困难是一个很棘手的问题。虽然可以在测试环境下使用各种数据库和消息队列来模拟生产环境，但是对于无服务应用的集成或者端到端测试很困难。