本文整理自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容器適合服務器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的編排技術出現。”