一文搞懂SaaS困境、API经济与Serverless WebAssembly
本文整理自 WasmEdge 在神州数码 『TECH数字中国2021技术年会』"武汉技术嘉年华" 的分享。
SaaS 的困境与 API 经济
SaaS 已经成为 deliver software 越来越重要的一种方法。但是中心化运营的 SaaS 产品怎么才能满足“千人千面”的定制化需求呢？这个问题在中美两国都有，但是中国的问题更严重一些。
SaaS 公司普遍面临着一个问题，就是如果为用户定制化过多，SaaS 慢慢就不是一个产品公司了，而变成一个咨询公司。当然这个问题并不是今天才有的。这个问题的解决方法其实也很简单，就是 API，所以就有 APIeconomy (API 经济)的说法。
Postman 这家印度公司最近融了2.5亿美金，估值已经是56亿美金。可能很多程序员会觉得惊讶，因为 Postman 这个事其实并不复杂，就是为 SaaS 提供 API 测试和 API 管理的平台。这件事说起来技术含量并不大，但是 Postman 产品做得比较好，而且入行的时间比较早，所以取得了成功。这就是 API 经济，就是帮 SaaS 管理 API 这件事情，其实是有很大需求的，而且今天有人做出了 Postman 这样五十几亿美金的公司。
但是对于用户和开发者来说，其实都是对 API 有 mixed feeling 的，因为每个 SaaS 的 API 都不一样，管理起来也比较复杂。有没有更好的方法呢？我们来看另外一家公司叫做 Zapier。
Zapier 这家公司总共才融了不到200万美金，但是今天它的估值也是50亿美元，每年的收入11.4亿美元。Zapier 就是做 API 自动化的，或者用今天比较流行的话来讲就叫无代码平台。就是开发者不需要直接去管理API，也不需要直接为 API 应用专门起服务器。具体来说，如果 SaaS 的用户要开发 SaaS 的应用程序，不需要起服务器，就也不需要去管理运维，而是直接用 Zapier 来管理 API。在 Zapier 建立一个 Zap，然后在那个 Zap 里面点击授权登录 SaaS，就可以把 API 的功能给串起来，或者把 API 的功能给自动化。Zapier 让比较初级的开发者或者甚至没有代码能力的商务人员能够对 SaaS 进行定制化。
解决 SaaS 定制化的问题中，API 是给程序员用的，低代码的解决方案是给商务人员用的，总的来说这两个生意都能做得挺大的，这两家公司都在50亿美金的规模了。
API 是什么
那么下面具体来讲 API 到底是什么？SaaS 的 API 为什么会这么有用，为什么会有这种低代码解决方案出现？
API 的作用就是典型的网络隔离代码的作用。SaaS 是一个中心化运营的软件环境，所以说不能千人千面的为每一个客户进行定制，不能为每个客户改代码，那怎么办呢？可以让用户自己改代码，把代码放在自己的服务器上，然后跟 SaaS 之间有某种交流的机制，这就叫 API。
用户写了什么代码，要对 SaaS 进行什么样的定制，作为 SaaS 提供商来说是不知道的，只有用户自己知道。所以用户写了之后放在自己的服务器上，不会放在 SaaS 的服务器上，然后跟 SaaS 的交互就是通过API、通过网络来进行交互，用网络把代码隔离开，这个是在云计算早期一个大家都用的方法。
这个缺点是什么呢？缺点就在于用户自己要管理 服务器，这是一个开发也慢、deploy 也慢，安全性低，可靠性低，而且是一个非常昂贵的工作。
上图下面的这三张表就是飞书的应用上架流程，我下面会讲到它其实是一个正面例子，不过为了要讲痛点，所以我们现在把他当做负面例子来讲。
飞书有一个核心功能，就是用户可以在飞书平台上定制自己的机器人，让机器人来处理一些事务。要搭建一个聊天机器人，标准的做法就是用飞书的 API。这个 API 的设置是用户去起一个服务器，用这个服务器监听飞书的 API 来的 event 的。如果有人在飞书里面和机器人对话了，就会产生一个事件，然后飞书通过 API 发回开发者的服务器上来，然后开发者的服务器就会按照写好的逻辑把回答通过 API 发回到飞书去，这个机器人对用户回答了一句话，整个过程就完成了。
为了要干这件事情，需要开发者自己起个服务器。要求很多，服务器需要在大陆，需要在工信部备过案，需要有 https，需要有 SSL certificate，飞书同时需要应用开发者能够管理自己的内容，不能有黄色内容和反动内容，需要 99.9% 以上的时间是可用的，当飞书用户与机器人对话的时候，机器人能立马要回应。如果把这些东西全部加起来，其实是运营的工作很多，其实开发的工作不多。
下面这几个图讲的就是我们当时就为了在飞书里面加一个春节的时候发贺卡的机器人，这需要经过的 check list 是好几十项，要好几个人干好几天才能完成。所以 API 这东西听起来是很有用的，也很有价值，可是其实用起来还是挺困难的，这就是为什么会有无代码这样的平台出现。
有没有一种更好地使用 API 的方式？
怎么解决 API 今天的问题呢？其实在 SaaS 跟 PaaS 之间的这条线其实一直都是模糊的，SaaS 是 software as a service，PaaS是 platform as a service。从 Salesforce 开始，SaaS 公司其实一直想做 PaaS 的，就是说把 API 做成一个开发者的平台。但我们来看看真正的 PaaS 平台，比如说腾讯云、Heroku、字节的轻服务，其实都是以 API 与托管代码的形式共存的。我要做一个平台，让大家能够在我的平台上进行扩展，能够加自己的业务逻辑，需要的不仅是 API，需要的还是在平台上要能够直接运行客户自己的代码。
SaaS 为什么要用 API 来隔离网络，因为他不想让用户把自己的代码放到中心化运营的 SaaS 上面去。但是在 PaaS 平台里面，这种做法经常是反过来的，就是让用户直接把代码上传到平台上来，然后在平台上运行用户的代码。举刚刚那个聊天机器人的例子，那就变成了开发者不需要自己起个 API server 去监听从飞书来的 events 和信息，只需要给飞书上传一个函数，这个函数的输入就是用户对机器人说的话，这是个字符串。函数的输出就是机器人要回答的话，也是一个字符串。我把这个函数上传上去之后，不用购买任何服务器，就能够运行起来。而且，因为是在 SaaS 这个环境里面运行的，这样域名就不需要认证、99.9% 的可用性，这些都是有保证的。显然这是一个更简单的做法，就是在平台上直接运行用户的代码来实现定制化。
在 PaaS 平台里这样的传统做法是什么？就是用 Docker。在平台里面用户上传了一段代码、上传了一个函数，这个函数在平台上是不能被信任的，平台不能直接去运行这个函数，所以它就起一个 Docker instance，然后在 Docker 里面去运行用户的代码。这个就是所谓 Serverless 的概念，这是目前 PaaS 平台里面常用的一种方法。
现在在云计算这个行业里面， serverless 是一个非常大的趋势。
再借用我上面举的那个例子，用一个函数来做飞书机器人的，我就只管业务逻辑了，就不用再管 infrastructure 逻辑了，只是把函数上传上来就可以了。从容器到函数这一步是我们现在正在走的这一步。当然在这一步里面，今天大部分人实际上就是所谓的 Function as a service，就是函数即服务，这种函数的方法还是用容器，但是我们下面会讲到还有其他更好的方法。
总结一下观点，今天的 SaaS 虽然是用 API 来做的，是用 API 来实现扩展的，但是如果说我们需要更轻更快更安全，跨平台的扩展方法，我们其实是可以用嵌入式的函数，我们就让用户上传一段函数给一个平台，然后让这个函数去定制 SaaS 的行为和 SaaS 里面的业务逻辑。
SaaS 里的嵌入式函数用 Docker 合适吗？
下面就要问个问题，Docker 真的合适吗？做嵌入式的函数、做 Function as a service，今天主流的做法是用 Docker 来做。用户把函数代码上传上来了，然后放在 Docker 里面运行，然后通过这个函数运行的结果来定制这个 PaaS 平台或者 SaaS 平台的行为。但是 Docker 干这件事情真的合适吗？
Solomon Hykes 是 Docker 的 CTO 和 Co-founder。他说 If WASM+WASI existed in 2008, we wouldn’t have needed to created Docker. That’s how important it is. Webassembly on the server is the future of computing. 这是他在2019年说的话。如果说 Webassembly 这种容器在2008年就存在的话，我们就不需要 Docker 了。作为 Docker 的发明人说这样的话，自然在社区里面引起了很大的反响。
在云原生的行业里，我们在用 Docker 做嵌入式函数的隔离，但是 Docker 真的合适吗？像 Webassembly 这样的新标准会不会是一个更好的选择呢？
我们来看看 Shopify 的故事。Shopify 是电商行业最大的 SaaS 之一了，Shopify 用 SaaS 的方法在北美市场上挑战电商巨头AWS。Shopify 今天的流量比亚马逊要大了，已经是北美第一的电商了。这是 Shopify 的 CTO 说的话，Shopify is an API first company。
补充一下 Shopify 的背景，Shopify 就是开店的平台。如果用亚马逊的话，开的店都必须在亚马逊的平台上。Shopify 提供了一个 SaaS 工具，让用户可以开自己的独立电商店，然后就可以建立自己的品牌，所有的东西都可以在 shopify 上定制。
所以说 Shopify 是一个 API first company，因为 shopify 的用户、开发者是跟 shopify 的 API 进行交互。可是在 API 里面有很多事情是做不了的。
Shopify 在2019年做了一件事情。比如我开了一个店，但是这个店里面有一些逻辑是需要在用户购买的时候发生的，比如一个折扣的逻辑。每个店家有自己的折扣逻辑，比如买三送一、买三包邮、买三打折。店家有千人千面的折扣逻辑，那怎么把不同的折扣逻辑做到一个 SaaS 的平台里，让用户可以定制呢？
第一种方法就是做模板化。模板化问题就在于选择是有限的，如果真的有几千几万个模板，用户要找到他真正需要的模板可能还挺难的。Shopify 以前一直是在用模板这个做法。或者也可以用 API，但是这个体验很差。就是在用户购买的那一瞬间，Shopify 产生一个 Event，发到店家的 Server上面去，然后让店家计算这个折扣应该是什么，然后店家把结果返回给 shopify，然后再让用户继续往下走付款的流程。可是这是一个很差的用户体验。因为在网络的一来一往至少就要一秒钟左右，而在用户去付款的过程中，每一毫秒都很重要。有研究表明，每延迟10毫秒，用户不买的可能性就会增大很多。所以用 API 这种办法其实不行的。
那只剩下一种方法，把这段逻辑以代码的形式嵌入在购物车里面，也就是说让商家上传一般代码，然后在 Shopify 的平台里运行。在用户结算购物车的时候，运行这段代码，根据购物车的内容去运行这段代码决定它的价格是什么。这段代码可以在 Docker 里面运行，但如果在 Docker 里面运行的话，仍然面临一个问题：Docker 的启动时间很慢。
在 Docker 里面引进一段函数，其实是一个效率非常低的事，要起 Docker，就要起 Docker 里面的操作系统，然后再起 nodejs 或者起 python ，取决于这个函数用什么语言写的，然后运行一个20行的函数，运行完了之后再把 Docker 关掉，99% 的时间花在setup inferstructure上面，而只有大概1%的时间在真正运行这段代码。
所以 Shopify 想了一种新的方法。Shopify 当时专门写了篇文章《Making commerce Extensible with WebAssembly》，在业界有挺大的反响。Shopify 就用 WebAssembly Runtime 来干这件事。通过这个 workflow 图可以看到， Shopify Cloud 就是 Shopify这个 SaaS 平台。用户进来一个 web request，它去 call 了开发者/商户商户提供的一段 WebAssembly 代码去计算折扣和其他定制逻辑。
Shopify 里面现在这样的应用场景越来越多，因为跟 API 相比，这种优势是非常明显的，对于开发者来说，需要管理的东西大大减少，而且性能有了大幅提升，占用资源也大大下降了。而相比于 Docker 来说，WebAssembly 的资源占用率也只有 Docker 的1%，并且没有冷启动时间。最大的电商 SaaS Shopify 有了这个落地的实践，用 WebAssembly在 SaaS 里面作为提供扩展的一种方式，现在变得越来越流行。
在这儿很多人很可能有这个问题，就是 WebAssembly 真的能取代 Docker 吗？这听起来是两个不同的东西，WebAssembly是从浏览器里面来的技术，Docker 一开始就是一个开发者工具。
但如果仔细看的话，Docker 与 WebAssembly 之间是有很多相似之处的。比如说它们都能提供在运行时的隔离，是可移植的，事实上 WebAssembly 的可移植性比 Docker 要好很多，Docker 还取决于下面的 CPU，如果基于 RAM 64 的 Docker 镜像在 X86 的机器上是运行不起来。但是WebAssembly 是 bytecode，所以 WebAssembly 下面所有的 CPU、GPU 之类的都被抽象了，所以 WebAssembly 是真的可以跨平台，这有点像JVM。然后都是比较容易部署的， Docker 能把程序打包成一个镜像，然后就部署了。WebAssembly 也是同样的，能够把程序打包成一个 bytecode application，然后所有的部署与依赖都在这个Application里面。把字节码应用直接把复制过来就可以部署了。所以从某种角度上讲，WebAssembly 和 Docker 在最重要的feature上面是非常相像的。
同时 WebAssembly 又比 Docker 轻和快很多，这是我们在2021年初在IEEE Software上面发表了一篇学术论文，那时候我们的开源项目叫 SSVM，现在叫 WasmEdge。所以大家看一个比较重要的点是这幅图的最后。那就是说在启动时间，WebAssembly 比 Docker 或者 Docker+Node.js 是快了100倍以上。
WebAssembly 是一个比 Docker 抽象层次更高的 runtime，或者说容器。我们把容器分成三种，一种就是VM，第二种就是Docker这样的容器，第三种是 high level language VM WebAssembly，VM 在模拟一个计算机，容器在模拟一个操作系统，而WebAssembly这样的 VM 是在模拟操作系统里面的一个process。
我们的开源项目是CNCF里面第一个云原生的 WebAssembly 项目，叫WasmEdge，这个项目在 github上面，欢迎大家来围观。
WasmEdge 源代码：https://github.com/WasmEdge/WasmEdge
WasmEdge 的重要场景当然有很多，比如说有Cloud-native Microservices ，微服务；在公有云里面的 Serverless runtime，然后最后一个当然很重要的是在应用和 SaaS 里面的嵌入式的 Serverless runtime。
同时 WasmEdge runtime 全面支持了 JavaScript。大家对 WebAssembly 的一个“诟病”，就在于 WebAssembly 前端的语言需要是编译性的语言，比如说 Rust、 C++、C、Swift 这样的语言比较好。可是 Python JavaScript 的支持就比较差，但在云原生这个行业里面，其实 JavaScript 挺重要的，我们做了很多努力，让 WasmEdge 能够比较全面地支持JavaScript。然后甚至能够在JavaScript里面支持几乎所有C native 或者 Rust native 的 API。就是 C Native 或者 Rust Native 的 API 能够 import 到 JavaScript 里来。
比如说我们这里的一个例子是用 JavaScript 作为AI推理，是用到下面的GPU 和 Tensorflow library，能够达到的performance 跟你用 C++ 写Tensorflow 的 performance 是差不多的。
如何用 Serverless 的方式扩展 SaaS
所以我们刚刚讲到了 SaaS 的可扩展性和用嵌入式函数来扩展SaaS。具体做法其实主要有两种，一种就是刚刚我们讲的在SaaS内部直接支持 PaaS 风格的 SDK 与嵌入式函数，就是改造 SaaS 内部的 infrastructure。让用户除了 API 之外，还能够用嵌入式函数跟 SaaS 进行互动。SaaS平 台本身提供一个让用户上传函数的地方，这就是 Shopify 干的事。
因为很多 SaaS 内部采用的是微服务或者采用的是 Kubernetes 来管理 SaaS 内部的各种服务与服务的集群，所以在这种架构下面，我们可以把 WebAssembly 加进来。在 SaaS 平台内部进行改造，让 SaaS 内部的微服务，有的微服务用Docker容器，有的微服务用 WebAssembly，特别是用户上传的函数做成一个微服务，就用 WebAssembly 容器，然后能够带来性能的提高和通过嵌入式函数给用户带来更自由的可扩展的好处。
这上面我们也做了很多工作，比如说我们跟 dapr 有比较深的合作，然后我们跟几个基于 kubernetes 的 service mesh有比较深的合作，如果大家有兴趣的话，希望大家来找我们一起讨论。
这个方法的难点在于需要 SaaS 的开发者与运营商配合，需要在SaaS软件内部的结构进行一些改动。
第二个做法，就是说对 SaaS 进行无缝对接。SaaS 仍然是提供 API，但是我们提供一个第三方的服务，把 SaaS API 用嵌入式函数给联系起来，这其实就是 Zapier 的做法，我们用第三方 Serverless 服务链接 SaaS，具体怎么做呢？
首先来解释一下为什么要这么做。SaaS 仍然是有 API，但是对于开发者来说它不用关心 infrastructure了。开发者不用为了拓展 API 专门买服务器来监听这个 API 的消息。只需要上传代码给一个第三方的服务就好了。这个第三方的服务会帮开发者设置一切底层的内容。这叫 Serverless。
同时一个 Serverless 可以连接好几个 SaaS，可以把好几个 API 给串起来，而不是一个服务器监听一个SaaS。
同时这种方法对今天的 SaaS 是没有入侵性的，所以可以利用现有的API。
但它一个缺点就是没有非常深度的集成，比如说我们刚刚讲的 Shopify 这个 case 用这种方法是做不了的，Shopify 那个case要做的事情不只是要让开发变得容易，对反应时间也有很大的要求，所以说用 API 这 个做法其实做不了的，必须得要在它的平台内部嵌入函数。而我们这里讲的还是在平台外部嵌入函数，同时因为我们是用 SaaS 现有的API，所以只有现有 API能做的事情我们才能做。如果说我们要去改 SaaS 的 UI ，就是一个就比较困难的事情。这种方法也有优势和劣势。
我们有一个内测的服务，用我们的 WebAssembly runtime WasmEdge 把这样的服务给写出来了，这服务叫做Serverless Reactor。一个是Serverless，另外 Reactor 是个 reactative programming model，是反应式的。这个函数什么时候被调用(triger)，是看 SaaS 的 API 会不会监听到事件。
http://reactor.secondstate.info/zh/
所以我们来讲两个例子。比如说我们开发一个飞书或者 Slack 的聊天机器人，在我们这个平台里面要怎么做呢？
第一是在 Reactor 里面创建一个 flow。这个 flow 有两个 connector (接口)，第一个接口是配置飞书的 inbound connector，就是从这个 flow 登录飞书，然后让飞书的 event 送到这个 flow来。然后再给这个 flow 配飞书的 outbound 的 connector，同样的过程 log in飞书，然后把这个flow的event flow产生的数据发回给飞书。这样就创建一个 flow。
第二个是开发一个函数，这个函数可以用 Rust 或者 JavaScript 语言开发。这函数的输入是一个字符串，就是一个 JSON message，也就是飞书的event，输出就是需要回复的消息。所以输入的是别人对机器人说的话，输出的是机器人要回复说的话，
第三是把函数开发好了，编译好了之后把它上传到 flow，这件事情就完成了。刚才在第一步创建一个 flow 的时候已经把 connector setup 好了。对于用户来说不需要管理任何服务器，只需要写业务代码，也不需要知道飞书的 check list 是什么。开发者只需要知道进来的数据格式是什么，出去的数据格式是什么，业务逻辑是什么，在这个过程中可以通过 WasmEdge 的 SDK连接数据库，网络，所以这就形成了一个闭环，让用户开发一个聊天机器人变得更容易。
第二个例子是链接两个SaaS服务。是 Liga AI 跟飞书联系起来。比如说在研发管理里面有ticket，有issues。如果一个issue 截止时间到了，它就应该给相应的飞书用户发一个通知，提醒用户时间快到了。
Liga AI是个深圳的公司，是做研发服务的SaaS，有点像中国的 JIRA.
我们也是同样的 123，先是建个flow。但这个 flow 里面，inbound 事件是从 Liga 来的，所以在这个 flow 里要去登录 Liga，让 Liga 的 event 送到这个 applications 里面来。同时给 flow 配的 outbound connector是飞书的，所以在配 outbound connector 的时候，登录飞书，然后发出去的 message 送给飞书。
然后是开发这个函数，可以用 Rust 或者JavaScript，输入是 Liga 的 event，输出是飞书的 message。flow 设置好了，函数编译好了，最后就把函数上传到 flow 里面去，这个机器人就可以用了。
如果 Liga 里面产生了一个event，event 被这个函数收到了，这个函数看到这个 event 的时候就去给飞书发一个消息，然后发给 对应的飞书用户。这是我们两个 use case 现在在这个内测的平台上现在就可以用了。
我们这个平台现在还没有完全公开使用，我们也愿意把这个平台提供出来，给有兴趣的朋友能够内部测试使用。一个是往 SaaS 里面直接加嵌入函数，第二个是通过一个第三方平台连接 SaaS 的 API，通过嵌入的方式直接连接SaaS的API。这两个想法如果大家有什么想讨论的东西，欢迎大家大家来找我们讨论。非常感谢。
关于 WasmEdge
WasmEdge 是轻量级、安全、高性能、实时的软件容器与运行环境。目前是 CNCF 沙箱项目。WasmEdge 被应用在 SaaS、云原生，service mesh、边缘计算、汽车等领域。
✨ GitHub：https://github.com/WasmEdge/WasmEdge
页:
[1]