本文整理自5miles CTO吕艺在WOT 2023大会上的主题分享，更多精彩内容及现场PPT，请关注51CTO技术栈公众号，发消息【WOT2023PPT】即可直接领取。
日前，在51CTO主办的WOT全球技术创新大会——云时代技术专场上，5miles CTO吕艺带来主题演讲：《混合容器在微服务架构中的实践》，为大众呈现出全新的视角。
混合容器为微服务带来更多选择，可以根据实际需要进行优化，构建出灵活高效的云原生应用。在微服务架构中，可以通过按需选择、流量分离、渐进迁移、混合调度、统一管理等方式使用混合容器。
文章摘选自吕艺WOT期间演讲的精彩内容，详细讲述了混合容器在微服务架构中的实践。
1、微服务架构及应用场景
微服务架构（Microservice Architecture）是一种将单体应用拆分成多个小型服务的架构风格，实现松耦合、高内聚的服务部署，在云原生应用快速迭代方面有显著优势，但也需要注意引入的复杂性。每个微服务负责实现单一功能，多个微服务组合起来就能实现完整的业务。
一开始，吕艺的5miles电商创业团队需要从小规模做起，不需要将系统构建成标准的微服务，只需要系统能够承载业务即可。
但随着业务规模的变大，系统需要面临诸多考验。用户从几万增加到几十万，任何小规模系统都会面临极大的压力。
此时，需要将面临压力较大的模块抽离，压力较小的模块继续按照原来的方式运行，确保发展有序，减少一个问题搞跨整个系统的可能性，微服务逐渐派上了用场。
标准微服务示意图
上图展示出标准的微服务架构，“实践中，我们会针对不同业务选取不同的开发语言，将业务拆离，不‘跑’在同一服务之中，”吕艺说。
当流量从getway进来后，会被分发到不同的服务之中。这些服务有用Python写的，也有用go写的，有些则是用Java写的。
在微服务架构中，不同服务之间是独立存在的。每个服务拥有独立的存储和缓存，服务间既可以通过RPC调用，也可以通过队列调用进行解耦合。
图片
上图是AWS部署服务示意图，几年前，该部署模式曾具体负责出海业务，旨在将中国的研发能力推广至美国。
“回顾过去十年的演进过程，刚开始，我们只用虚拟机，并没有用到容器；后来，才开始使用云技术和ECS，一段时间后把ECS换成了EKS，旨在与业界同行处于同一调度技术体系，很多经验就互通了，实现降本增效的目的。另外，当流量激增时也更容易实现自动扩缩容，”吕艺回忆说。
2、为什么使用混合容器？
为什么我们要考虑混合容器呢？
上文提及的微服务在容器之中运行后，虽然Docker比之前的虚拟机轻很多、占用资源也比较少，但是，它需要耗费CPU和存储资源运行容器的基础设施。
混合容器能够充分利用不同容器的技术优势，如，Docker的成熟生态，Wasm的轻量和快速启动都提升了整体资源的利用率。
3、WebAssembly：打造容器新时代
在大型系统里，单一容器安全性和某些可疑代码的执行存在问题，此时就需要WebAssembly的支持。
该技术最早出现在浏览器端，Chrome、Firefox、Safari和Edge等主流浏览器现在都在支持WebAssembly。它正在成为Web开发的主流组件，特别对于游戏、CAD、VR/AR、图像/视频编辑、密码学和机器学习等。
图片
2019年，Docker联合创始人Solomon Hykes在推特上说：“如果当时有WASM和WASI技术，就不用再发明Docker了。”因为，发明Docker的初衷就是为了更好提供隔离计算能力。但是，WebAssembly更符合对未来的期望。
2022年，云原生计算基金会提出，容器技术将成为新常态，而WebAssembly是全新容器技术的代表。
图片
从统计学数据看，37%的用户已在无形之中用过WebAssembly；如上图，针对WebAssembly runtime技术应用，排名第一的是WasmEdge，第二则是Wasm。实践中，更多会用到WasmEdge。
WebAssembly镜像的体积很小，大概是Linux镜像的1/100。它可以为每个Wasm实例提供独立的运行环境、隔离性好、占用内存小。与Docker等传统容器不同，Wasm容器不需要操作系统级虚拟化，启动时间可以在毫秒级。
Wasm的运行性能比较好，损耗也是较小，特别适用于高性能计算。它默认有沙箱机制，安全能力比Docker粒度更细，更容易控制。
Wasm主要的应用场景包括：在浏览器中运行沙箱代码、serverless计算、边缘计算、承载AI推理计算等。相比虚拟机，Wasm容器更轻量和高效。
此外，它的代码隔离性比较好，各种语言都可以编译成WebAssembly，这对开发者特别友好。
未来，Wasm容器有望成为云原生应用和微服务的重要运行环境，可以跨平台、快速部署和启动微服务、函数即服务等。
4、Wasm容器 VS Linux容器
Wasm容器和Linux容器（如，Docker）作为两种不同的容器技术，优势不同，通常作为互补技术混合使用，发挥各自的特性。不过，Wasm的云原生应用逐渐走向主流。
二者在隔离级别、启动时间、编程语言和应用场景方面各有不同。Wasm容器适合服务器less和边缘计算，Linux容器更适合规模化部署。
5、WasmEdge：打破传统、应用更友好
WasmEdge是由CNCF云原生计算基金会托管的项目，团队的理念跳出传统固有思维，除了支持标准外，还将很多标准里没有涉及到或还没商定的事做了对接和实践，对应用更加友好。（GitHub链接：https://github.com/WasmEdge/WasmEdge）
它对各种主流的Rust库的支持更加完善，支持tokio、Hyper、reqwest等库，能够被K8s等容器工具管理。
此外，它对网络库支持也较好，对MySQL数据库也进行了一些优化。这些能力可以帮助我们做轻量级serverless。
两者可以很好地协同使用：比如，用Docker部署一个完整的微服务，然后用WasmEdge运行该服务中的热点函数等，提升效率，共同推进云原生应用的发展。
6、主流容器工具对Wasm容器的支持
主流容器工具对Wasm容器的支持很重要，可以帮助开发者将Wasm容器部署到Kubernetes或Docker components之中。
图片
上图中展示出基本调度管理平台模式：Highlevel容器运行时和lowlevel容器时的关系。
其中一个重要的lowlevel运行名称是crun。crun从1.5版本时就开始支持WasmEdge。每个版本里都对WasmEdge容器进行了各种修订和扩展支持。所以，目前来讲，Crun对Wasm体系的支持比较友好。
所以，当用Crun“跑”Wasm镜像时，Crun一般会根据镜像注释里的标记判断它要启动的是Linux容器还是wasm容器。
7、总结与展望：用更先进的容器技术控制计算力度
微服务发展至今已深入人心。未来，我们期待用更先进、力度更小的容器技术减少微服务计算力度。
“我们会与开源团队努力开展实验，在实验成功之时能够汇报给大家，也希望大家能够用更先进的容器控制计算力度，”吕艺说。
吕艺最后强调：“现在，我们将轻量级WebAssembly容器都部署到重量级Kubernetes上；我们期待未来有更轻量化、更适合WebAssembly的编排技术出现。”
