字節跳動在 Rust 微服務方向的探索和實踐

近日， Qcon 全球軟件開發大會 2022（上海站）圓滿落幕，大會是由 InfoQ 中國主辦的綜合性技術盛會，近百位國內外技術大咖現場分享前沿技術案例與創新實踐。本文整理自字節跳動火山引擎基礎架構服務框架工程師吳迪於大會上的分享內容，主題爲《字節跳動在 Rust 微服務方向的探索和實踐》。

01 嘉賓及內容介紹

本次分享內容主要分爲以下三個部分：

1、我們爲什麼選擇了 Rust 語言；

2、我們做了什麼；

3、展望未來：機遇與挑戰。

02 我們爲什麼選擇了 Rust 語言

我會爲大家主要介紹一下我們爲什麼會選擇 Rust 語言，因爲大家可能聽說字節跳動比較有名的框架叫做 Kitex，是一個 Go 的框架，字節跳動在 Go 方向投入了很多，爲何現在開始探索 Rust 方向呢？其次，在這個方向我們做了哪些事情，遇到的一些問題，以及我們的解決方案。其三，會爲大家分享一下我們所認爲目前 Rust 的機遇以及未來挑戰。

一開始，我是做 Go 的語言開發，做 Go 的 RPC 框架，但當時我們遇到了很多 Go 語言的一些問題。

Go 語言的桎梏

• 深度優化困難

在 Go 裏面，你想要深度優化是非常非常困難的一件事情，因爲當我們體量變得越來越大的時候，深度優化是越來越重要了。但是如果在 Go 裏面，想要去做一些深度優化，你經常會發現在跟 runtime 以及編譯器做很多鬥爭，需要用一些很 hack 的辦法去繞過它的一些限制。

• 工具鏈和包管理不夠成熟

Go 裏面的工具鏈和包管理相對來說不太成熟，如果有用過我們開源的 Kitex 框架的同學可能會非常瞭解。舉個例子，比如在 Go 裏面，想調一個 gRPC 的服務，或調一個 Thrift 的服務，需要調一個需要生成代碼的服務，我需要先在開發的時候把代碼生成好，要用一個命令行工具生成完之後，把生成代碼一併地給提交到版本管理裏面。直白來說，這是個很蠢的做法，像 C++、Java，還有 Python 也許都會採用一些其他的方案，但是 Go 就必須這麼操作，因爲它編譯器就沒有這個能力，沒有辦法在編譯時去生成這個東西。還有一點，比如我在編譯時也許可以調個腳本去生成，但問題在於本地沒有這個文件，代碼生成、代碼補全提示都沒有， IDE 會直接給你裏面所有的就下劃線飄紅，這是個體驗很差的事情。

• 抽象能力較弱

Go 裏面的抽象能力是比較弱的，它沒有零成本抽象這麼個概念。

那麼使用 Go 語言的三個桎梏具體應該如何理解呢？下面進行具體分析。

深度優化困難

我分享一個之前遇到的真實、有意思的案例。我們做序列化、反序列化的過程當中，可能會遇到一些出錯的情況。在我們之前的版本里面，代碼是很簡單的，在序列化、反序列化出錯的時候，就直接把 error 返回來。後來我們爲了優化用戶的體驗，想多返回一些錯誤信息，比如我們告訴他是在哪個 struct 裏面，在 read 哪一個字段的時候出的錯。這是一個很好的初衷，但是當我們新的代碼上線了之後，有一個業務方就跑來說：“你這個新的代碼是不是有問題？爲什麼我們的性能下降了 20%？” 我們認爲不可能，我們所有序列化、反序列化邏輯都沒有改，只改了這一行。當時我們也很納悶，認爲是不是業務方自己測試環境有問題，後來我們查了半天，最後終於發現了情況。

Kitex 新版本的代碼

Kitex 舊版本的代碼

大家可以看到這個是新的代碼生成出來的彙編，在 Go 裏面它的彙編生成或編譯器，應該說非常非常不智能，它沒有做一些像代碼位置上的調整，或者沒有做這種代碼的指令的重排，就導致了比如我們剛纔看到的 error 的錯誤信息，他直接把所有的錯誤信息或這些字符串全部插入到了正常的流程當中。帶來了什麼問題？帶來了我們的 L1 的 cache miss 的大量提高，因爲 L1 的 cache 是會很大程度上影響到我們的執行性能、運行性能，所以就導致了性能的下降。

如何解決這個問題？你們可能會認爲，編譯器的問題是不是無法解決。後來我們用了個非常 hack 的辦法，既然編譯器不會去做代碼重排，我們就只能自己做。我們自己把所有的錯誤都定義到了正常 return 語句的後面，在出錯的時候用 Go to 跳轉到後面，跳轉到 label 上。大家可能在寫代碼或者學的時候都會聽說過說 Goto 要慎用，儘量別用。但是在這種場景下，我們只能這麼做。這個時候 Goto 語句被直接編譯的時候，生成一條彙編的 jmp 指令，最後測出來的性能比之前的舊的版本即直接 return error 還要好。因爲它的 cache 的 miss 直接從大概之前的 2.4 降到了現在的 1.8，又提升了很多。

這個是一個很有意思的例子，也體現出了在 Go 上面我們想要做深度優化其實非常的困難。

零成本抽象

還有一個就是在 Go 裏面其實沒有零成本抽象概念。零成本抽象的意思就是，如果我們沒有用到的東西，是不需要爲之付出代價的；而如果我們用到的東西，不管是編譯器、標準庫還是第三方庫的提供者，都應該是做到最好的，不可能做得更好。可能寫 C++，還有寫 Rust 的同學比較瞭解這個概念，但是在 Go 裏面是沒有的。總結來說：

• 不用的東西，不需要爲之付出代價；

• 用到的東西，你也不可能做得更好。

Thrift 編解碼抽象

而爲什麼說 Go 裏面沒有零成本抽象概念，舉個例子，我們做 Thrift 的編解碼抽象，那麼 Apache 官方的 Thrift，是支持很多種不同的 Transport 和 Protocol 組合。底層傳輸層，還有上層的序列化層，它其實是有很多不同的協議的，比如 transport 層，有個叫 framed 的 transport，有個叫 buffered 的 transport，甚至還有一些像 memory 直接在內存裏面。 除了 transport 還有 protocol，現在基本上是兩種：Binary 和 Compact。大家知道，它有多種不同的組合。官方實現它爲了去支持多種不同的這樣的組合，用了 Go 裏面的 interface 去做了抽象，但是我們後面把抽象給去掉了，我們直接依賴了一個具體的 protocol 的實現，也就是依賴了一個具體的 struct。‍

Interface 的代價

那麼爲什麼我們不用它的抽象？因爲抽象是有代價的。代價就是在 Go 裏面，它的 interface 是動態分發的，即運行時通過類型的元數據和指針，去動態調用所需接口，它可能會造成多一次的內存尋址。

但這並非最主要的，最主要是它會影響到 inline。而且在 Go 裏面沒有提供一種零成本抽象的方案，它不像 Rust 裏面有一個 box dyn，與 interface 很像。還有一種是靜態編譯式的，做靜態分發，在編譯的時候直接把類型給單例化出來了，這就是一個零成本的，但是 Go 裏面沒有。

Sonic

還有一個項目其實是非常有意思的，我們 CloudWeGo 社區開源了一個叫做 Sonic 的項目，應該是在 Go 裏面最快的 JSON 的序列化、反序列化的這麼一個項目。這個項目爲什麼快？因爲它的祕訣就是世界上最快的 Go 代碼，不要用 Go 寫，直接用匯編和 C 寫就完事了。大家可以看 Github 上面代碼語言的統計，實際上 Go 佔 27.1%。

大家會發現其實所有的 Go 的代碼裏面，基本上也是通過 Go 去生成彙編。所以這就是我們的結論，世界上最快的 Go 代碼，不要用 Go 寫，用匯編寫就完事了。

性能最好的 Go JSON 庫

但儘管 JSON 庫用了非常多的黑科技去優化，但是我們可以看到，綠色的這一條是 Rust 裏面比較經典的，叫 serde 庫。serde JSON 這個庫就是 benchmark 的結果，我們做 benchmark 發現它還是比不過這個 rust 的庫。所以我們後面下定決心，想要去研究一下 Rust 方向，去嘗試一下落地。

Rust 的歷史

講到 Rust 這個方向的語言，肯定要了解一下它的歷史。Rust 一開始是由一個名叫 Graydon 的人開發出來的，他是一個 Mozilla 的職業的編程語言的工程師。Mozilla 當時想要去實現一個叫 Servo 的一個引擎，覺得這個語言很有價值，決定去使用它去贊助了這個語言。

在 2015 年的時候， Rust 發佈了 1.0 的版本。1.0 版本其實就代表了一個穩定性的承諾。在 2018 年發佈了 1.31 版本，1.31 版本代表的是生產力。在 edition 2018 時候引入了 Async await 異步的 Rust，在現在來看，我給他的評價是未來可期。

Rust 2024

Rust 在 2024 有一個規劃叫做 scaling empowerment，也就是擴展授權。爲什麼叫擴展授權？因爲這就是我在專場一開始問大家的問題，說 Rust 的目標、願景是什麼？它的願景是 empower everyone to build reliable and efficient software，所以它要授權每個人去創造可靠並且高效的軟件。

在 2024 的規劃裏面，因爲其實大家也都聽說過 Rust 的學習曲線比較陡峭， 目前 Rust 官方其實也已經瞭解到了一些特別是 async 的 Rust 存在一些使用上的問題，並且也非常重視這個事情。所以它 2024 年的目標主要就是爲了讓 Rust 更加好用，更加易用，並且能夠落地更多的項目。

Rust 三大優勢

Rust 在我們看來有三大優勢：性能、安全、協作。性能和安全可能大家都會比較瞭解，或者會聽得比較多一些。

• 性能

比如這是一個 debian 搞的 benchmark game 的一個結果，我選的是一個純計算的 case 的結果。在裏面可以看到， Rust 語言其實是遙遙領先其他幾個語言，特別是 Go 的，大概有 4 倍的提升。

有同學會問，爲什麼 Rust 會比 C 和 C++ 性能還好，其實這也是因爲 Rust 它對於程序員的一個要求，因爲它的代碼的限制更加嚴格，這就直接導致了編譯器可以做更加激進的一些優化。所以它的性能在有部分時候是可以超過 C 和 C++ 的。

• 安全性

其實在網上有很多相關的資料，我也不過多贅述。我只講最重要的一個結論，就是在 Rust 1.0 之後，在非 unsafe 代碼中不可能出現內存安全的問題。

這個結論可能大家聽起來覺得有點雲裏霧裏，其實它的一個推論更加重要，就是一切的內存和併發安全問題都是 unsafe 代碼導致的。這就直接表示，如果在線上一個服務出現了 coredump，或者出現一些內存安全併發安全的問題，不用去看 safe 代碼，直接看 unsafe 代碼就好。 因爲 Rust 裏面 unsafe 代碼是非常少量的，它不像 C 和 C++，可以說全都是 unsafe，如果去找可能不知道要找到何年何月。但是在 Rust 裏面，只要去看變更中新增加了哪些 unsafe 的代碼，這些代碼肯定就是問題的源泉，這就是 Rust 的安全性所帶來的好處。

• 協作

我認爲 Rust 非常適合協作，是因爲它確實是一門真正工程實踐出來的語言。它有非常智能的編譯器，有完善的文檔，有非常齊全的工具鏈，以及成熟的包管理。而且最重要的一點，你可以完全信任別人的代碼，這個是在 C 和 C++ 甚至在 Go 裏面都做不到的。

如果有同學有 review 過其他團隊成員的 C 或 C++ 代碼的經驗或體驗，應該能瞭解到，當你 review 這種 C 和 C++ 代碼的時候，很多程度上根本看不出來它到底哪裏會搞了個什麼野指針出來，或搞了個內存安全問題出來，只有在線上真正 coredown 的時候，而且 coredown 的地方很可能是在十萬八千里之外，你根本聯想不到是這段代碼導致的。因此很多時候沒有辦法去信任別人代碼。但是在 Rust 裏面沒有關係，只要它能編譯過它，代碼就是安全的。所以我們在 review 的時候，只需要去關注那些業務的邏輯是否正確就可以了。

Rust 開發者調研

在 Stack Overflow 上，每年都會有開發者調研。Rust 已經連續七年成爲最受歡迎的語言，而且可以看到它離第二的差距挺明顯。

業界的應用案例

我也簡單介紹一下在業界上有哪些應用案例，因爲一個語言除了在社區應用的比較廣之外，被企業接受也是一個很重要的指標。首先在 Meta （Facebook）接受 ，它已經是一個後端正式的支持語言。在我們公司字節跳動，在很多場景上也已經用到了 Rust，特別是飛書。如果有用過飛書的企業可以瞭解一下，飛書所有的邏輯全都是 Rust 編寫的，在 Google 、螞蟻金服還有下面有很多的企業。

Rust for Linux

Rust 的應用在最近也是越來越廣。還有一個很重量級的項目叫做 Rust for Linux，這個是 Linux 內核至今爲止，唯一接受的除了 C 以外語言，應該是相當重量級的一個代表。

和 C++、Go 對比

我再簡單做一個 C 和  C++ 和 Go 的對比。我覺得學習難度上 C++ 和 Rust 都是高，性能上 C++ 和 Rust 也都是高。但是安全性上面， Rust 其實是完爆這兩個其他語言的，特別是在協作上。正如之前提到過的，對於 C++ 來說沒有一個原生的包管理工具，同時它也沒有辦法讓你去信任別人的代碼。 使用成本上面，我綜合認爲 C++ 使用成本比較高， Go 和 Rust 使用成本都是中等。爲什麼說 Rust 使用成本是中等？因爲使用成本不僅僅是開發的時候所要付出的成本，它還涉及到一個服務要上線之後，要讓它進入到穩定狀態中間的 debug 所需要的成本，以及你如果出事故所帶來的一些損失，這些都是要考量在內的。綜合下來，我認爲 Rust 它的使用成本是中等。

這裏又有一個問題了，爲什麼 Rust 這麼好？它和 C++ 是同一個 level 的語言，爲什麼 C++ 做不到這麼好？當然，其實我們都說軟件工程裏面沒有銀彈，這是因爲 C++ 的歷史包袱確實太多了。 Rust 勝在沒有歷史包袱，所以它設計的時候就不像 C++ 必須要兼容那種舊的使用模式。不能說更新個 C++21，舊的代碼全都編譯不過，那麼大家誰願意做呢。 Rust 其實有點佔了這方面優勢。

03 我們做了什麼

公司內（之前）生態情況

接下來我爲大家介紹一下，我們字節跳動做了些什麼。這是一個很悲傷的故事、很悲傷的數字。在我們開始做的時候，其實公司內的生態是 0，服務端什麼都沒有，什麼都要自己開始建。

如何建立生態

當時考慮這個問題，首先是得讓大家能用起來，這就涉及到了一些編譯打包和運行的基礎設施。我相信每個公司都會有自己的編譯打包流程、上線的流程以及運行的環境。這些是比較關鍵的一些設施，包括內網的一些像 crates.io 還有 docs.rs 這些開發所需要的基礎設施，以及一些基礎庫和開發框架。 可能每個公司的環境不一樣，我介紹的是一個大概的流程，這個流程如果有公司想要去嘗試，是可以一起來參考一下的。

基礎庫

基礎庫大概是像日誌、監控、鏈路追蹤、mysql、 redis 、動態配置、 mq 這些屬於我們認爲非必須的、非常重要的一些基礎庫。這些可能是需要推廣方，比如我們團隊是作爲推廣方，去把這些全部建設起來。

接下來剩下一些非必須的基礎庫，可能是某一些業務單獨的庫，就可以發動羣衆的力量，因爲它只要最基礎的這些東西。比如它能夠完成一個 CRUD 的基礎服務，剩下的東西可以一邊在開發業務過程當中，一邊自己去寫。

開發框架

我們也準備了 3 個開發的框架：

第一個，基於 Axum 的 Web 框架。 Axum 算是 tokio 現在比較火的一個官方的 HTTP 的 Web 框架。

第二個，RPC 框架，支持了 GRPC 和 thrift，叫做 Volo。已經開源在 CloudWeGo 的組織下面了，如果之後有 RPC 的需求可以直接來使用這個框架。

第三個，異步的運行時的 Monoio 框架。這個主要是考慮到提供給一些性能非常關鍵的業務以及基礎設施，就是基礎架構的服務去使用。它的好處在於它採用 Thread Per Core 模型，這樣就可以解決 Tokio 的很多問題，比如它的 future 必須加 Sync 的一個問題。因爲 thread per core 的情況之下，它能保證一個 task 一定在一個線程中被運行，這樣很多時候就不需要 send 加 sync 的約束，可以直接用 TLS（ thread local storage ）或者其他的這些技術，以及一些無鎖的技術去編程，這可以很大程度上提高性能。第二個就是它採用了 Linux 最新發布的 io_uring 技術去做 IO 層 ，如果有對於性能要求非常高的同學可以去了解一下。

發現的問題

我們當時畢竟是喫螃蟹，肯定也遇到了一些問題。我們主要遇到開源庫的 bug，以及開源庫不完全滿足需求的問題。比如最近我們就遇到了一個業務，它在使用的是 Snappy 庫，做壓縮和解壓縮的庫。他發現壓縮和解壓縮的 writer 他是不能複用的，我們後面就自己給他提了 PR 去支持上了。

所以在喫螃蟹這個階段，可能需要能夠自己去解決問題，要去提 PR，以及要自己 Fork 一些開源庫出來去用的。這個要做好心理準備，因爲這是我們真正實踐上遇到的問題。還有一個可能跟技術沒有特別強關聯的問題：我們發現有很多一線的同學其實特別喜歡 Rust、特別想用 Rust。正如剛纔提到， Rust 是 stuck workflow 上最受開發者喜愛的語言榜榜首，已經連續第 7 年。但是很多的 leader 管理者會擔心，我們團隊只有一個人會 Rust，如果這個人他轉崗了或離職了，這個服務是不是就沒有辦法維護了？這可能是很多的 leader 會擔心的問題。

如何推動落地

這時其實就需要我們作爲推廣方去介入，並且去幫助他去開發一些項目。這個時候可能不會讓他去開發一個業務的服務，因爲業務服務畢竟有時需要整組一起討論、一起拍板之後才能選擇某個技術站，但是個人的項目是可以用的。

很多對 Rust 非常感興趣的的工程師，只是缺少有一個人帶頭，或者缺少一個契機。最重要的一點就是要尋找一些典型的業務去共同地開發、去獲得收益。在我們看來，這些典型的業務有一個特徵，就是 proxy 的業務，它是一個代理類的業務，重計算，但是邏輯是比較簡單的，因此雖然我們在推動落地時需要一些前期投入，但是是值得的。

實踐：nightly + GAT + TAIT

具體的收益稍後爲大家分享。這裏我先介紹一下我們一些實踐中的感悟。不要視 nightly 爲洪水猛獸，nightly 是真香。nightly 有很多很多的特性是非常棒的，比如像剛穩定的 GAT，還有 TAIT。這兩個特性是能大大的去降低推廣 Rust 的阻力。

一個 Timeout 中間件

我們可以看一下對比是在沒有 TAIT 情況之下，也就是 tower。可能寫 Rust 的同學都知道有 tower 這麼一箇中間件抽象的庫，這裏大家不管會不會 Rust，可以不去過多地關注它的細節。大概看一下在 tower 裏面，我想要沒有成本也沒有性能損耗的去實現一個 Timeout 的超時中間件，需要滿滿兩屏的代碼。

但是如果用我們的採用了 GAT 加 TAIT 這兩個特性之後，代碼量只需要這麼多，這其實是一個非常明顯的對比。其實我們很早就開始用了。

所以在實際推廣的時候，可以去考慮把這些有用的特性都給打開。特別是有一個特性叫 async fn in trait，在 trait 裏面可以定義異步函數了。這個特性已經在 nightly 上達到了 MVP，雖然存在一些問題，但起碼是可用的狀態了。

落地成果

接下來爲大家介紹一下我們的落地的一些成果。首先是有一個 proxy 類的業務，它的 CPU 的佔用從大概 630% 降低到了 380%，幾乎是提升了一倍。第二個就是它的 memory，也就是它的內存佔用大概從 9GB 降到了 2GB。然後它的 P99 和 AVG 也有非常大量的提升了。

1. 業務 A（Proxy 類）

• CPU Usage 630% -> 380%

• MEM 9GB -> 2GB

• P99 150-200ms -> 20-35ms

• AVG 4-5ms -> 1.5ms

2. 業務 B（有大量業務邏輯）

• CPU 400% -> 130%

3. 業務 C（有大量業務邏輯）

• CPU-50% ，MEM-95%

4. 業務 B（有大量業務邏輯）。業務 B 是一個計算密集型的業務，使用 Volo 框架後 CPU 400% -> 130%。因此在計算密集型的業務中，CPU 的提升更加明顯。

可以看到左邊這張圖，紅線這條線是我們上線的時間點，在之前和之後，它的尖刺有很明顯的對比。另外一個業務 b，有大量的業務邏輯，它大概是 CPU 佔用從 400% 降到了 130%，大概三倍的提升。另外一個業務 c 也是有很明顯的提升。

還有某一個比較重要的線上業務，它的提升量也是非常明顯。舉個例子，它的成本是降低了 50%。大家就會問：這些數據能證明什麼、代表什麼？我光知道好， CPU 降低了， memory 降低了， ABG 降低了，延遲降低了，它能說明什麼？我們來簡單地算一下。

5. 業務 D（線上重要業務）

• 吞吐 + 95.96%

• 成本 - 48.97%

• avg -14.29%

• P99 -18.18%

• P999 -10.26%

算一算

這是某雲的一個價格截圖，64 核 128G 的機器，一個月的價格是 6262 元。因爲某雲買 5 年可以打 3 折，所以我就按照最優惠的方案給大家算。28000 一年，相當於算下來是 437 元 / CPU * 年。業務使用了 1 萬個核心，我們剛纔計算下來成本減去了 48.97%，我就按 50% 算，節省 5000 核 ，相當於一年節省的數量就是 200 多萬。這就是一年省下來成本。

我們又有同學會說了，你沒把開發的人力算上。我再把開發的人力給算上，已經是一個非常非常高的，幾乎不可能達到的一個開發的成本了。因爲我們服務大概就花了大概兩三個月，寫完就重構完了，我就算 6 個月，開發的加辦公的成本，我也選了一個非常非常高的值，其實應該是達不到這個值的。假如他是 120 萬，他第一年的淨收益就是接近 100 萬，再往後每一年都是純收益了，已經沒有成本了。當然實際上它的收益應該是遠不止這個值的，因爲 CPU 成本是沒有這麼便宜的。

有做過成本覈算、效益覈算的同學，可能會比較瞭解一些它的成本的值。一個經驗值大概是在 1000 一核，可以按照這個值去計算。因爲除了 CPU 單純的 CPU 價格之外，還有網絡的成本，比如機房運維人員的成本，其實成本是遠不止 437 一個 CPU 的。還有一點，如果 AVG，也就是 latency 延遲有降低的情況之下，其實是能夠帶動業務的增長的。 

04 展望未來：機遇和挑戰

Rust 現狀

Rust 現在的現狀：好用。它確實挺好用，它的功能很多，很符合人體工程學，但是它還不夠好用。

其次，它的抽象能力、表達能力是挺強的，但是它的高階抽象還有些問題，特別是寫 Rust。可能用過 HRTB 的同學會知道， HRTB 配合 GAT 或和 TAIT 使用的時候會有些坑，但是使用場景實在太高階，基本上業務開發是用不到的，所以也可以接受。 第三， Rust 的異步生態現在較爲完善，但是它和同步的生態存在一些割裂。比如一個函數 Fn，它不能同時是異步和同步的，異步版本和同步版本必須寫兩個不同的函數。

當然，其實 Rust 官方也已經感受到了這些問題，都在解決，特別在 2024 的 roadmap 裏面都有提到這些問題。像 Niko 也在嘗試一個新的方案，它希望一個函數可以同時是 async 以及 sync 的兩個版本。如果調用方是 async，它就會調一個 async 的，在編譯時生成一個 async 的實現。他會做這樣的一件事情。

還有一些比較好的消息是開發者非常喜愛，用戶的忠誠度是非常高的。我相信寫出來的同學應該不會再考慮轉到轉回到其他語言去了，起碼我是不會再回去寫 go 了。開源項目也是爆炸性的增長，特別是這兩年，可以明顯感覺到越來越多的開源項目採用 Rust 。不管是新增項目還是重構的項目，有越來越多的公司接受開始使用 Rust。

Rust 應用的方向

Rust 其實它的應用的方向非常非常的廣，我大概簡單列了一下，包括像 Rust for Linux 其實已經相當於補足了。Rust 應用的最後一塊拼圖，也就是 OS 層和嵌入式層，都是可以使用 Rust 去寫的。還有一個最近很有名很火的一個方向，就是 WebAssembly，基本上 Rust 也屬於是第一梯隊的，就是最佳的語言了。

面臨的挑戰

目前面臨的一些哪些挑戰，第一個是 Rust 的職位不夠多，人才不夠多，其實是一個相互的關係，如果人才多起來，職位也會多。如果職位多，人才也會多。所以這可能需要的不僅是某一家公司去投入做什麼，而是希望所有喜愛 Rust 的程序員，共同地一起去把整個生態建設起來。 

第二是 Rust 在中國的名聲不夠響，雖然現在已經在慢慢地提升當中了，但是它和 Go 確實還有一些的名氣上的差距，通過培訓班的數量就能看得出來。

第三是 Rust 缺少像 K8S 一樣的殺手機應用。這也是大家一直提到的一點，下面是 Rust 官方做的調研的一個圖，有 22.51% 的人認爲 Rust 是 for the majority of my coding，他們大部分的主要代碼都是用 Rust 寫的。有 17 % 的人說是自己所有使用的語言中之一，有 18% 的人說他只是偶爾去使用。但是這張圖其實就說明了 Rust 語言它是否真的能夠產生價值。

再下面這張圖是 Rust 官方來問，你覺得 Rust 語言有沒有幫助你真的去實現一些什麼東西？有 80% 的人認爲 Rust has helped us achieve our goal ，Rust 已經幫助我們達到了我們的目標。但是有一個壞消息是 47% 的人認爲用 Rust 是 challenge 的，是有挑戰性的。後面有 70%。有 80% 的人認爲 Rust 是值得我們的付出的，以及有 90% 的人認爲我們在未來還願意去使用 Rust。

機遇

現在我們還遇到了一個新的機遇，降本增效，以及現在其實大家都對底層技術越來越關注，而 Rust 它的掌控力非常的強，所以在底層技術領域它是一個非常非常趁手的工具。而且現在 Rust 關注度足夠高，社區也是在快速發展的過程當中。

擁抱開源，回饋社區

我們在公司內部也建設了很多的，投入了很大量的時間精力去開發了一些相關的這樣的基礎設施。我們也是取之開源，用之開源。我們把我們最核心能力全部都暴露了出來。一個 Volo 是我們的 RPC 框架，如果有使用有微服務的框架需求的同學或公司，可以考慮使用一下。 

Monoio 剛纔已經介紹過了，是一個 Thread Per Core 模型的，使用了 io_uring 的一個超高性能的異步框架。我們也出了一個對標 tower 的中間件的抽象，就是 Motore 直接使用了 GAT 加 TAIT 這兩個重要的特性。以及爲了解決一些國內衆所周知的網絡問題，我們也做了一個 proxy 給大家，大家如果經常遇到拉包拉不下來的問題，也可以考慮使用一下。

• Volo：https://github.com/cloudweGo/volo

• Monoio：https://github.com/bytedance/monoio

• Motore：https://github.com/cloudweGo/motore

• RsProxy：https://rsproxy.cn/

項目地址

GitHub：https://github.com/cloudwego

官網：www.cloudwego.io

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/FAaQ5VYtDbLAnE4FDfNCfw