之前有听到说Docker支持Wasmtime了,刚好.NET7也支持WASM,就带大家来了解一下这个东西,顺便试试它怎么样。
因为WASM(WebAssembly) 一开始是一个给浏览器的技术,比起JS解释执行,WASM能用于提升浏览器的用户体验,因为在一些场景中它有着比JS更好的性能。
大家可以将WASM理解为C#的MSIL或者Java的字节码,它并不是二进制代码,还是会由JIT编译执行,JIT有很多优化,另外大多数场景也只会JIT一次,加上省略了JS加载,语法分析各种的过程,才会有着比JS更好的性能。
另外因为WASM是中间码的格式,所以理论上任何语言C#、RUST、Java、Go都可以将代码编译为WASM,然后放到浏览器中执行。比如C#火热的Blazor项目,就是将C#编译为WASM,然后使C#代码能在浏览器中运行。
另外聊一聊WASI(WebAssembly System Interface),我们知道WASM有着不错的可移植性和安全性(目前浏览器运行都是沙箱运行,对于权限管控很严格),那么就有一群大佬就说,我们是不是能脱离浏览器单独运行WASM程序呢?于是就产生了一个标准的系统接口,大家都按照这样的方式来生成WASM,调用系统API,然后我们开发一个Runtime,让大家的WASM程序都能在这上面运行。
举个不严谨的例子说明一下WASI就是比如:
各位应该就明白了,WASI其实就是个运行时的规范,大家编译成WASM放上去就能跑。
所以现在对于它的观点就是,觉得它在Server后端领域目前来说不是一个很价值的东西,因为可移植性好的语言比比皆是,比如C#、Java、Go等等。
拿性能来说,对于这样的中间语言性能无关就是JIT和GC,WASI的JIT和GC能做的像C#、Java这样的JIT、GC性能那么好吗?这个目前来说是存在疑问的,至少在短时间内很难追平其它平台十多年的优化。
再说WASM的另一个优点,就是体积小和启动快,现在C#支持NativeAOT、Java有GraalVM、Go和Rust之类的本身就是编译型语言,启动速度和体积都很不错,WASM在这个方面其实不占优势。
好了,言归正传,我们来试试.NET7上面的WASM。.NET7目前已经发布,我们需要使用最新的版本,如下图所示:
然后我们创建一个简单的控制台项目,用于输出斐波那契数列和执行耗时,代码如下所示 (这并不性能最优的实现,只是这样子实现简单):
using System.Diagnostics;
namespace PublishDotNetToWASM;
public static class Program
{
public static void Main()
{
// warm
ulong sum = 0;
foreach (var i in Fibonacci().Take(1000))
{
sum += i;
}
// run
sum = 0;
var sw = Stopwatch.StartNew();
foreach (var i in Fibonacci().Take(100000))
{
sum += i;
}
sw.Stop();
Console.WriteLine($"Result:{sum}, Timespan:{sw.ElapsedTicks} Ticks");
}
private static IEnumerable<ulong> Fibonacci()
{
ulong current = 1, next = 1;
while (true)
{
yield return current;
next = current + (current = next);
}
}
}
接下来为了将.NET程序发布成WASM,我们需要安装Wasi.Sdk
预览包,这个预览包是Steve Sanderson
大佬做的支持,可以将.NET程序编译为WASM,截止至目前版本信息如下所示:
<PackageReference Include="Wasi.Sdk" Version="0.1.2-preview.10061" />
运行dotnet publish -c Release
命令,将我们的应用程序发布为WASM格式,在发布过程中,需要下载MinGW
作为编译器,网络环境不好的同学,需要使用proxy,稍微等待一会就顺利的发布成功了:
此时我们可以安装一下Wasmtime
来执行我们的程序,通过https://wasmtime.dev/
下载安装:
然后就可以直接使用wasmtime
命令运行我们的程序,我分别使用wasmtime
和dotnet
运行了我们的程序:
可见目前来说WASM的性能还是惨不忍睹的,等一等后续的优化吧。
再来看看我们的Docker,对于Docker支持WASI我感到并不意外,因为Docker的容器化对于直接执行的WASM来说还是比较重,支持它是一个拓宽影响力的好事。具体的执行模型如下所示,对于WASM应用有着不同的执行方式。不再使用runc
而是wasmedge
。
wasmedge
也是一个实现了WASI标准的WASM运行时,和上文提到的wasmtime一样。
要实现在Docker上运行WASM程序需要安装Docker的预览版,链接https://docs.docker.com/desktop/wasm/
。
然后我们整一个Dockerfile,我们直接依赖scratch镜像即可,因为它不需要其它的基础镜像(暂时我没有使用.NET7的多段构建镜像,听大佬说目前貌似有问题)。
FROM scratch
COPY ./bin/Release/net7.0/PublishDotNetToWASM.wasm /PublishDotNetToWASM.wasm
ENTRYPOINT [ "PublishDotNetToWASM.wasm" ]
再使用下面的命令构建Docker镜像,由于是wasm镜像,所以需要带额外的参数。
docker buildx build --platform wasi/wasm32 -t publishdotnettowasm .
可以看到打包出来的镜像是非常小的,只有3.68MB。
运行的话也很简单,用下方的命令即可,需要指定runtime为io.containerd.wasmedge.v1
,另外也需要指定paltform。
docker run --rm --name=publishdotnettowasm --runtime=io.containerd.wasmedge.v1 --platform=wasi/wasm32 publishdotnettowasm
我把dotnet原生运行、wasmtime运行、docker WASI运行都跑了一下,可以发现目前来说性能是惨不忍睹。
以上就是如何将.NET7程序发布到WASM,然后在Docker最新的WASI中运行的样例,目前来看基本的运行都已经OK,不过正如前面提到的,现在性能还是太受影响了。
这不仅仅是在.NET平台上,其它语言Rust、C、C++编译为WASM上都有明显的性能下降。
思来想去可能在一些插件化和不需要性能很好的场景WASI会比较用。不过这些都需要时间慢慢见证,毕竟存在即合理,像JS这样的语言不一样好好的?
我们可以拭目以待,看看WASM/WASI会不会给我们带来其它惊喜,期待后续Steve Sanderson大佬和WASM社区的相关优化。
https://github.com/InCerryGit/PublishDotNetToWASM
https://www.docker.com/blog/docker-wasm-technical-preview/
https://www.zhihu.com/question/304577684/answer/1961085507
https://arghya.xyz/articles/webassembly-wasm-wasi/
https://laurentkempe.com/2022/10/31/experimenting-with-dotnet-7-wasm-and-wasi-on-docker/
为大家推荐一个专注于“画图”本身的工具 PlantUML,通过写代码的方式完成满足各种需求场景的画图工作,将人的精力集中到思想的表达与传递,避免无谓的图形页面样式修改调整,进而提升工作效率
椭圆曲线加密算法(ECC)中,公钥与私钥具有固定的功能分工,不可互换使用。公钥用于加密和验证,私钥用于解密和签名,确保系统安全性和协议兼容性。任何试图互换角色的尝试都将导致严重的安全风险和实施困难。