嘉宾 | Michael Yuan   整理 | 夏歌

出品 | CSDN云原生

或许你听说过 WebAssembly 是 W3C 认可的第四种编程语言，C++、C、Rust 等所编写的高性能库可以被编译成 Wasm ，FFMPEG可以用来提升浏览器应用性能……但其实如同 Java 与 JavaScript一样， WebAssembly 也在经历着由客户端向服务端的迁移，服务端的 WebAssembly 正在冉冉升起。WebAssembly 用在服务端有什么优势？与现有云原生的生态是什么样的关系？又有哪些应用场景？

2022年4月28日，在CSDN云原生系列在线峰会第 3 期“WebAssembly 峰会”上，CNCF WasmEdge 开源项目的 Creator Michael Yuan 分享了 WebAssembly 如何解决 SaaS 定制化的问题。

戳👇观看Michael Yuan分享视频

WebAssembly助力SaaS 实现千人千面的定制化需求

SaaS API 是 WebAssembly 在浏览器外之外的一个主战场，这与以往基于 Web 的 API 是有区别的。

对用户、开发者和投资人来说，SaaS 是一个很好的模式。但 SaaS也有困境：SaaS 要有价值，就必须是同一个产品、做中心化的运营，但是不同的用户却有不同的需求。

中心化运营的 SaaS 产品怎么才能满足“千人千面”的定制化需求呢？

在这种情况下产生了 SaaS API。中心化运营的 SaaS 产品虽然对每个人来说都是一样的，但通过提供 API，用户可以自行起 Server 与 SaaS API 进行互动，以此改变其在 SaaS 平台的行为，这样就实现了 SaaS 产品的定制。

API 的应用非常广泛，也带来了非常大的经济效益。例如 Postman 通过提供对 API 进行管理和开发的平台，使其当前的市值已达56亿美元。针对用户并不喜欢维护API程序的特点，Zapier 提供了一个低代码的 API 自动化平台，用以整合两个或以上的应用程序，自动执行重复性工作，从而提高效率。截至今年三月，Zapier 的估值已达50亿美元，ARR 为1.4亿美元。 

API的本质是想要运行用户的代码，用户若想对 SaaS 进行定制，需要使用代码实现逻辑。但这些代码不能直接运行在 SaaS 中，所以就需要 API 使用网络来隔离代码。在该过程中，用户的代码仍然在自己的机器上运行，通过 JSON 或 xml RPC 来与 SaaS 产生交互，这个就叫做 API。通过这种方法便可以在 SaaS 交互过程中运行用户代码。

但是这个实现过程非常低效。从用户角度来看，用户需要去管理整个 Infrastructure、服务器以及服务器上运行的所有软件，同时程序之间的交互过程缓慢，每一步都需要验证。这是 Web API 的痛点。

Shopify 是一个让用户自行建立电商独立站的工具。早前，建设电商网站具有一个相对标准化的需求，但随着电商的快速发展，开店产生了千人千面的需求。于是 Shopify 提供了一套 API 让用户自行编写程序以满足个人需求。

每一个电商独立站在用户结算时都有自己的一套折扣规则，以往 Shopify 如何解决用户的定制化需求呢？

答案是通过模板，不同的规则有不同的模板。但随着 Shopify 用户数量的增多，成为北美最大的电商，模板也有上千个。这会使用户难以选择，因为在上千个模板中找到想要的并进行配置，难度太大。

对 Shopify 来说，更简单的方法是让用户通过类似代码执行的方式创建自己的规则，并上传至 Shopify ，由Shopify 执行。

那么如何实现这个功能呢？

在 WebAssembly 还并不成熟时，首先想到的方法便是使用 API。理论上使用 API可以完成功能实现，但此时交互的时间以秒计算，而用户在结算时候的每一毫秒都非常重要。第二种方法是让店家直接将代码上传至 Shopify ，使用 Docker 运行。但这种方式的缺点依然是速度不够快，因为在大规模的电商平台上，用户购物结算的行为频率非常高，若在此时大量使用 Docker 容器，不但不经济并且处理速度也不理想。

所以在2019年，Shopify 提出一个技术方案：在 Shopify 的系统里使用下一代轻量级容器 WebAssembly 运行店家上传的代码，来定制 Shopify 给用户的体验。

GitHub 的 Email 通知数量较多，部分使用者会在 Gmail 里设置规则对 Email 进行筛选后放至不同的文件夹，再找时间统一去看，这也是一种用户体验的定制。

对 GitHub来说，要把用户体验做好，是一件很重要的事。

那能不能在收到 Notification 时执行用户自己定义的规则？用户根据自己的需求制定不同的处理规则，例如通过设置关键词来判断 issue 的重要程度，重要的 issue 使用自定义的规则处理；例如直接发送至 Slack或电话通知。

这就又回到之前的问题，能不能用 Web API 来做？理论上可以，这就需要开发者自己起 Server，让消息在开发者的 Server 和 GitHub 之间来回交互。这对于开发者来说，开发过程复杂而且维护成本较高。

这个过程的本质是：当有 Notification 时便执行用户的代码，这段代码中包含用户自定义的规则，然后根据该规则决定 Notification 的发送方式。那自然会想到使用 GitHub Actions：

Repo events 会 trigger 一个 action 来处理消息

但是同样存在缺点：

每一个 action 都需要一个VM

开销非常大

在这种情况下， 用 WebAssembly 来执行用户上传的信息处理逻辑是一个非常好的方法。WebAssembly 能够很快地执行一段代码，冷启动时间几乎可以忽略不计，能够支持多语言，能够极大地提高性能。

传统数据库如 Oracle 数据库，能够把数据处理及对数据的简单计算一起运行，这样可以最大程度地利用数据库的处理能力。

云数据库同样需要这样的能力，要把用户上传的代码嵌入数据库中，这样能够先在本地处理数据库中产生的数据，然后再返还给用户。

WebAssembly 是一个非常好的选择，它能够让用户采用不同的语言书写 User defined function，也支持在数据库中直接对数据进行处理。

从 Shopify 到 GitHub 到云数据库都有“千人千面”的定制化需求，都可以用 Docker 嵌入一段代码到 SaaS 里来解决此问题。

但通过上面这三个例子不难发现，WebAssembly 在这种情况下比 Docker 要更加合适，因为它资源占用少、速度快、安全隔离性好，而且对语言的支持要比 Docker 好。

这里也介绍下我所在的 WasmEdge 项目，是一个轻量级、高性能和可扩展的 WebAssembly Runtime，目前是 CNCF 的沙箱项目。

GitHub地址：https://github.com/WasmEdge/WasmEdge

在已有 WebAssembly runtime 的场景下，具体要怎么做呢？有以下两个选择：

在SaaS 内部支持PaaS 风格的SDK与嵌入式函数

用第三方的 Serverless 函数服务链接SaaS

我们自己开发了一个实验性的应用，叫做“打了鸡血的 SaaS 连接器 / API”，即 Zapier on Steroid。这是一个 SaaS API 之间的 connector，但不是像 Zapier 简单地把一个 SaaS 的 Message 发到另外一个 SaaS 去，而是让用户能够在中间加一段 Serverless 函数、在中间进行 Transformation。

来看一个例子，连接 GitHub 到邮箱和 Slack。

Step 1：在服务上面新建一个 flow，选择GitHub 为 inbound connector ，outbound connector 根据自己的需求选 SendGrid 或 Slack。

Step 2：完善中间逻辑，写 Serverless function，可以用 Rust 或 JavaScript语言。该函数的输入就是 GitHub 的 event，而函数的输出取决于另一头连的是 SendGrid 还是 Slack。最后把编译出来的函数上传到建好的 flow中。

Step 3：配置 GitHub connector ，将 GitHub connector 连接到 GitHub 账号、SendGrid connector 连接到 SendGrid 的 API key，这样一个 flow 就完成了，可以实现 GitHub 和 SendGrid 的连接。

 感兴趣的读者可以来尝试获取一封定制邮件：

https://github.com/WasmEdge/FaaS

5月10日Apache SkyWalking 峰会，期待你的到来

扫描图片二维码获取峰会PPT

聚焦云原生新技术、新实践，帮助开发者群体赢在开发范式转移的新时代。欢迎关注CSDN云原生微信公众号～