WebAssembly杀进边缘计算：别再把所有逻辑都扔给云端了

WebAssembly杀进边缘计算：别再把所有逻辑都扔给云端了

大家好，我是 Echo_Wish。

这几年做边缘计算，经常会遇到一个挺尴尬的问题：

设备离用户越来越近了，但业务逻辑却还在云端。

请求从设备出发，跨网络、过网关、进云端，云端算完再返回。

数据量小的时候没啥感觉。

可一旦到了工业现场、智能摄像头、IoT 网关、5G MEC 这些场景，问题就出来了：

数据明明就在设备旁边，为什么非要千里迢迢送到云端算一遍？

更麻烦的是，有些业务逻辑还特别“个性化”。

比如：

• A 客户要求温度超过 80℃报警；
• B 客户要求超过 75℃报警；
• C 客户还要求连续 3 次超过阈值才报警。

如果全部写死在边缘节点里，后面改一次规则，就得重新部署程序。

但如果全部放云端，又会牺牲实时性。

这时候，WebAssembly（Wasm）其实是一个非常有意思的答案。

我的观点很简单：

边缘计算真正需要的，不只是“把服务器搬到边缘”，而是让边缘节点具备安全、低延迟、可动态更新的计算能力。

而 WebAssembly，恰好把这几个需求串了起来。

一、为什么边缘计算特别需要 WebAssembly？

先看一个传统架构。

设备
  ↓
边缘网关
  ↓
网络
  ↓
云服务器
  ↓
业务逻辑
  ↓
返回结果

假设设备每秒产生 1000 条数据。

如果所有数据都上传：

1000条/s
    ↓
网络
    ↓
云端
    ↓
规则判断
    ↓
返回结果

先不说带宽成本。

工业现场最怕的是：

网络一抖，业务跟着瘫。

比如温度报警这种业务：

温度：91℃
   ↓
上传云端
   ↓
网络延迟
   ↓
云端判断
   ↓
返回边缘
   ↓
触发报警

如果网络延迟 500ms，甚至几秒，这个报警就有点“后知后觉”了。

而边缘计算的思路是：

设备
 ↓
边缘节点
 ↓
Wasm业务逻辑
 ↓
直接判断
 ↓
报警

云端只负责：

配置下发
日志汇总
规则管理
版本管理
数据分析

这样一来，云端和边缘各干各的。

需要实时的事情，边缘干。

需要全局分析的事情，云端干。

这其实才是比较合理的架构。

二、问题来了：为什么不是直接运行 Python？

看到这里，有人可能会问：

“边缘节点直接跑 Python、Node.js 不行吗？”

当然可以。

但问题在于：

边缘设备通常比云服务器寒酸多了。

云服务器：

CPU：32核
内存：128GB
磁盘：几TB

边缘网关可能：

CPU：4核
内存：2GB
磁盘：32GB

甚至有些 IoT 设备更惨。

这时候运行一个完整运行时环境，成本就比较高。

WebAssembly 的优势之一就是：

把业务逻辑编译成一种轻量级的中间代码，然后交给 Wasm Runtime 执行。

架构可以变成：

┌─────────────────────────┐
│       Edge Gateway      │
│                         │
│  ┌───────────────────┐  │
│  │   Wasm Runtime    │  │
│  └─────────┬─────────┘  │
│            │            │
│   ┌────────┼────────┐   │
│   ↓        ↓        ↓   │
│ Rule-A   Rule-B   Rule-C│
└─────────────────────────┘

业务规则甚至可以独立升级。

这就很关键了。

三、真正让我觉得 Wasm 香的，是“安全边界”

性能只是 WebAssembly 的一半价值。

我个人更看重另外一个东西：

安全隔离。

假设我们有一个边缘平台。

平台允许客户自己上传业务逻辑：

客户A → 上传规则A
客户B → 上传规则B
客户C → 上传规则C

如果直接让客户上传 Python：

import os

os.system("rm -rf /")

那平台管理员估计当场就想辞职。

因为你实际上是在运行：

别人提交的代码。

这是非常危险的。

而 WebAssembly 的设计思路之一，就是：

代码运行在受控的沙箱环境里。

可以把它理解成：

宿主程序
   │
   ├── 文件系统权限
   ├── 网络权限
   ├── 内存限制
   └── CPU限制
        │
        ↓
   Wasm Sandbox
        │
        ↓
   用户代码

Wasm 模块默认并不能随便访问宿主机资源。

例如业务逻辑可能只能获得：

读取传感器数据
调用指定 API
返回计算结果

而不能随便：

读取 /etc/passwd
访问任意网络
操作宿主机进程
修改系统文件

这对边缘计算来说非常重要。

因为边缘节点往往部署在：

• 工厂；
• 仓库；
• 门店；
• 基站；
• 车辆；
• 摄像头；
• IoT 网关。

这些地方不像云服务器机房那么容易管理。

一旦边缘节点被搞崩，远程维护成本非常高。

四、来看一个最简单的 Wasm 业务逻辑

我们假设做一个工业温度检测。

使用 Rust 写：

#[no_mangle]
pub extern "C" fn check_temperature(temp: f32) -> i32 {
    if temp >= 80.0 {
        1
    } else {
        0
    }
}

逻辑非常简单：

温度 >= 80
    ↓
返回 1
    ↓
报警

温度 < 80
    ↓
返回 0

然后编译成 Wasm。

cargo build --target wasm32-wasi --release

边缘节点不需要重新编译整个业务系统。

只需要加载：

temperature.wasm

然后调用：

check_temperature(85)

得到：

1

然后边缘节点自己决定：

触发报警
停止设备
记录日志

这里有一个非常重要的思想：

宿主程序负责“能力”，Wasm 负责“逻辑”。

例如：

宿主：
我允许你读取温度。

Wasm：
好的，我判断一下温度。

宿主：
我允许你返回报警结果。

Wasm：
返回：需要报警。

这比直接把整个系统权限交出去要安全得多。

五、真正牛的地方：业务逻辑可以动态更新

这才是 WebAssembly 在边缘场景里特别有意思的地方。

假设现在规则是：

温度 >= 80℃ → 报警

后来客户要求：

温度 >= 75℃ → 报警

传统方案可能：

修改代码
 ↓
重新编译
 ↓
重新打包
 ↓
重新部署
 ↓
重启服务

如果有 1000 台边缘设备：

那就有点酸爽了。

Wasm 可以把业务逻辑抽出来：

Edge Agent
    ↓
下载 rule-v2.wasm
    ↓
校验签名
    ↓
启动新版本
    ↓
切换流量

甚至可以做成：

rule-v1.wasm
rule-v2.wasm
rule-v3.wasm

然后：

设备1 → v3
设备2 → v3
设备3 → v2
设备4 → v1

出现问题还能快速回滚：

v3
 ↓
发现异常
 ↓
rollback
 ↓
v2

这时候你会发现：

Wasm 不只是一个运行时技术，它其实正在变成边缘节点的“插件系统”。

六、性能方面，到底有没有那么神？

这里我反而想泼一点冷水。

网上经常有人把 WebAssembly 吹成：

“比原生还快！”

这种说法我个人不太认同。

Wasm 真正的优势不是：

任何情况下都比原生快。

而是：

接近原生的执行性能 + 跨平台 + 沙箱隔离 + 轻量运行时。

比如一个简单计算：

#[no_mangle]
pub extern "C" fn calculate(a: i32, b: i32) -> i32 {
    a * b + 100
}

这种计算非常适合放到边缘执行。

但如果你的业务是：

Wasm
 ↓
调用数据库
 ↓
HTTP请求
 ↓
读取磁盘
 ↓
再调用数据库

那么性能瓶颈根本不在 Wasm。

而是在：

网络
磁盘
数据库
序列化
锁
I/O

所以千万别看到 Wasm 就想着：

“我要不要把整个 MES 系统全部编译成 Wasm？”

没必要。

适合的逻辑才放进去。

七、我更推荐一种“边缘 Wasm + 云端控制面”的架构

如果让我自己设计，我大概率会这么做：

                    Cloud
          ┌────────────────────┐
          │   Rule Management   │
          │   Version Control   │
          │   Config Center     │
          │   Monitoring       │
          └─────────┬──────────┘
                    │
              Rule Distribution
                    │
       ┌────────────┼────────────┐
       ↓            ↓            ↓
   Edge-01      Edge-02      Edge-03
       │            │            │
   Wasm v3       Wasm v3       Wasm v2
       │            │            │
       ↓            ↓            ↓
    Device        Device        Device

云端负责：

控制
管理
分发
监控
审计

边缘负责：

执行
计算
过滤
决策

这样就形成：

控制平面在云端，数据平面和业务执行在边缘。

这才是我比较看好的方向。

八、但是千万别忽略 Wasm 的坑

Wasm 虽然香，但不是银弹。

第一个问题：

运行时管理。

你需要考虑：

模块加载
模块缓存
版本管理
实例生命周期
资源限制
异常处理

第二个问题：

权限控制。

虽然 Wasm 有沙箱，但如果宿主程序给的权限太大：

Wasm
 ↓
host.call()
 ↓
任意执行系统命令

那沙箱也就失去了意义。

所以必须遵循一个原则：

能力按需开放。

第三个问题：

升级安全。

千万别：

云端生成 wasm
 ↓
直接下发
 ↓
边缘直接运行

至少应该：

生成
 ↓
签名
 ↓
版本校验
 ↓
完整性校验
 ↓
权限检查
 ↓
灰度发布
 ↓
运行

否则 Wasm 反而可能成为攻击者进入边缘节点的新入口。

九、还有一个特别容易被忽略的问题：别为了 Wasm 而 Wasm

这是我自己比较强烈的一个观点。

现在技术圈经常出现一种现象：

看到一个新技术，就想着“这个场景能不能用上它”。

其实应该反过来：

先看业务问题，再决定技术。

比如：

适合 Wasm

规则计算
数据过滤
协议转换
轻量 AI 推理
实时计算
插件系统
租户自定义逻辑
边缘函数

不一定适合

复杂数据库业务
大型 ETL
重度 I/O
复杂 GUI
强依赖操作系统的程序

尤其是边缘环境。

如果一个业务：

每天只执行10次
一次耗时100ms

你为了它引入一整套 Wasm 平台：

这不是技术架构，这是技术装修。

十、最后聊聊我对 WebAssembly + Edge 的看法

我觉得未来的边缘计算不会是：

云端代码
    +
边缘代码

这么简单。

更可能是：

Cloud
  │
  │ 控制
  ↓
Edge Runtime
  │
  ├── Wasm Rule
  ├── Wasm Plugin
  ├── Wasm Function
  └── Wasm AI
  │
  ↓
Device

边缘节点本身会越来越像一个：

“小型、安全、可编程的计算平台”。

以前我们部署边缘设备，想的是：

“这台机器能跑什么程序？”

以后可能更多想的是：

“这台机器允许运行哪些逻辑？”

这个变化其实非常大。

因为一旦业务逻辑可以被封装成 Wasm 模块，那么：

业务逻辑
   ↓
编译
   ↓
Wasm
   ↓
签名
   ↓
分发
   ↓
边缘执行

就可以形成一套类似“应用商店”的边缘计算模式。

今天下发一个温控规则。

明天下发一个数据过滤插件。

后天再下发一个 AI 推理模块。

而边缘设备本身不用频繁更换、不用频繁重装系统。

写在最后

以前我们谈边缘计算，重点往往是：

“怎么把计算放到离用户更近的地方？”

但现在我越来越觉得，真正的问题应该变成：

“怎么让这些靠近现场的计算节点，既能快速运行，又敢于让别人往里面塞业务逻辑？”

性能解决的是：

跑得快。

Wasm 沙箱解决的是：

敢让它跑。

动态加载解决的是：

方便换。

版本管理和灰度发布解决的是：

出了问题能撤。

这几个东西组合起来，WebAssembly 才真正有机会在边缘计算里发挥价值。

所以我对 Wasm 的理解一直不是：

“又出现了一门新的编程语言。”

而更像是：

“给边缘节点装上了一个安全的、可插拔的业务逻辑引擎。”

这可能才是 WebAssembly 在边缘计算里最值得期待的地方。

云端负责大脑，边缘负责反应，而 Wasm 负责让边缘拥有一套可以随时更换、又不至于把系统搞崩的“神经末梢”。

这，可能才是下一阶段边缘计算真正值得关注的方向。

—— Echo_Wish