前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >WebAssembly Serverless 飞入寻常百姓家

WebAssembly Serverless 飞入寻常百姓家

原创
作者头像
陈少文
修改2023-05-09 08:52:39
2930
修改2023-05-09 08:52:39
举报
文章被收录于专栏:陈少文

原文链接 https://www.chenshaowen.com/blog/webassembly-serverless-will-be-a-common-arch-in-the-future.html

1. 基于容器的 Serverless 无法支撑下一代应用的形态

如上图,我们正经历着一次运行时态的变革。

从裸金属机到虚拟机,应用不在受限于本地服务器的数量、机房稳定性,具有更好的弹性和可用性。

从虚拟机到容器,应用不再受限于操作系统、配置漂移,具有更好的可移植性和可扩展性。

下一个运行时态是什么?很多文章说是 Serverless,但是 Serverless 本身并不是一个运行时态,而是一种运行时态的使用方式,是一种软件架构。下面是一个典型的 Serverless 系统流量图:

Container Serverless 接收到流量之后,分为两种情况:

  • Active,已经有 Ready 的容器,直接转发流量到容器
  • Inactive,没有 Ready 的容器,需要先将流量转发到 Activator,Activator 会冷启动一个容器,然后将流量转发到容器

这种方式与 Kubernetes 的 Pod、Service、Ingress 的流量转发方式是一致的,只是多了一个 Activator 承载冷启动流量的概念。

至于其弹性,也是借助了 Kubernetes 的能力,再辅助一些 HPA、KPA、KEDA 的弹性策略。

Kubernetes 有三种使用形态:

  • 全托管,master、worker 全都交给厂商
  • 半托管,master 交给厂商,worker 自己维护
  • 自建,基于 IaaS 自己搭建 Kubernetes 集群

利用全托管的 Kubernetes,例如 EKS,很容易实现 Serverless 的弹性能力。

这种形态的 Serverless 并不具备革命性,只是一种使用方式的变化。

另外一种就是 FaaS 形态的 Serverless,关注的粒度是函数,而不是容器,通常还需要外部的 BaaS 服务来支撑其状态存储。

如上图,有两种形态的 FaaS Serverless:

  • Container
  • Native Runtime

容器形态的 FaaS 会借助 Kubernetes 的能力,而 Native Runtime 的 FaaS 支持的语言有限,一般是 TypeScript、JavaScript、Python 等解释型语言。

更为关键的是 FaaS 形态的 Serverless 定制性太强。不是与厂商的 FaaS 服务绑定 Vendor Lock-in,就是与平台的应用 Framework 绑定,只能用指定的语言、框架、组件,局限性很大。在某些细分的领域,可能会有一些机会,比如离线计算、数据处理、数据分析等。

总的来说,Container Serverless 不具颠覆性,FaaS Serverless 不具通用性,不足以支撑下一次的应用形态变革。

2. 未来王者非 WebAssembly 莫属

WebAssembly 是一种新的运行时态,它是一种二进制格式,可以在浏览器、Node.js、Deno、WASI 等环境中运行。

实际上,只要实现了 WebAssembly 的运行时、系统接口,就可以在其上运行 WebAssembly。如果操作系统集成了 WebAssembly 的运行时,那么就可以在操作系统上运行 WebAssembly。WebAssembly 有机会成为 Container 之后新的交付格式。

如上图是 WebAssembly Serverless 的流量图。WebAssembly Serverless 没有 Scale To Zero 和 冷启动的问题,在成本和性能上都有很大的优势。

借助于 WAGI 能够将 HTTP 请求转换为 WebAssembly 的调用。此时的运行时,不再直接是 Container,而是 WebAssembly Runtime。至于底层是 Container、VM、Metal 已经无关紧要,WebAssembly 已经摆脱了这些限制,甚至可以是一个 IoT 设备。只需要这些设备能组成一个巨大的计算、存储池即可。

WebAssembly Serverless 不会有 Vendor Lock-in,任何语言编写的代码只要编译为 WebAssembly 都可以运行在 WebAssembly Serverless 上。

3. 前端后端化、后端轻量化

当前的主流算力集中在后端,前端是一个简单的 UI 层,前端的算力很少,只是简单的渲染、事件处理等。

但近年有一些变化:

  • 前端的算力越来越强,手机、电脑的性能越来越好
  • 前端工程能力越来越强,能够替代后端完成很多工作,例如文档渲染(WPS 在研)、图像处理(PS、CAD)、视频处理(B站视频上传)等
  • 后端的算力成本越来越高,需要更多的机器
  • 后端人力很贵,后端的薪资普遍比前端高很多

因此我绘制了下图:

计算、存储下推到前端,这里的前端包括 IoT、手机、电脑、浏览器等贴近用户的终端。后端的趋势是轻量化,仅提供一些基础 BaaS 服务即可。

这与 Serverless = FaaS + BaaS 的思路是一致的,但 FaaS 在前端,BaaS 在后端。也就是我说的前端后端化,后端轻量化。

前端开始变得厚重,提供运行算力;后端轻量化,只提供基础服务,甚至只是静态文件的分发能力。

如上图,后端提供的只是一个访问入口,前端加载完成,下载好 WebAssembly 之后,就与后端无关了。甚至可以不用单独开发后端,直接利用 CDN 网络即可。

4. 分布式应用会更加容易开发

前面说到下一代应用的形态,那么下一代的应用到底是什么形态呢?分布式应用

在区块链领域有一个很好的例子,就是 DApp 应用。DApp 有两个特点:

  • 去中心化
  • 分布式

去中心化是指没有中心化的服务器,分布式是指应用的数据分布在多个节点上。

当前网络世界最大的问题就是中心化。互联网上的流量、关注度、数据都集中在少数几家公司,财富也随之集中在少数几个人手里。这是很多矛盾的来源。

分布式应用的出现,可以解决这些问题。

如上图,每个设备既是消费者,也是生产者,每个设备都可以提供算力、存储、网络,也可以消费算力、存储、网络。

此时的数据才是用户自己的,而不是被中心化的服务器所控制。

而足够这样多的节点,就可以组成一个全新的分布式网络,基于此建造的应用才是面向未来的应用。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 1. 基于容器的 Serverless 无法支撑下一代应用的形态
  • 2. 未来王者非 WebAssembly 莫属
  • 3. 前端后端化、后端轻量化
  • 4. 分布式应用会更加容易开发
相关产品与服务
容器服务
腾讯云容器服务(Tencent Kubernetes Engine, TKE)基于原生 kubernetes 提供以容器为核心的、高度可扩展的高性能容器管理服务,覆盖 Serverless、边缘计算、分布式云等多种业务部署场景,业内首创单个集群兼容多种计算节点的容器资源管理模式。同时产品作为云原生 Finops 领先布道者,主导开源项目Crane,全面助力客户实现资源优化、成本控制。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档