編譯 | 徐杰承
在過去的一段時(shí)間里，“用Rust重寫”的潮流席卷了整個(gè)開發(fā)領(lǐng)域。作一顆正在冉冉升起的新星，Rust不僅承諾了更好的內(nèi)存安全保障、更高的技術(shù)穩(wěn)定性，還能夠兼顧開發(fā)與執(zhí)行效率。這也讓越來越多的系統(tǒng)開發(fā)者開始轉(zhuǎn)向這門面向未來的編程語言。
這不，就在最近，又一款知名開源項(xiàng)目Ockam放棄了系統(tǒng)內(nèi)數(shù)萬行的C語言代碼，并最終用Rust實(shí)現(xiàn)了對整個(gè)項(xiàng)目的重寫。在完成這項(xiàng)龐大的工程后，Ockam的創(chuàng)始人Mrinal Wadhwa也在一篇博客中分享了自己帶領(lǐng)團(tuán)隊(duì)從C轉(zhuǎn)向Rust的心路歷程。
圖片
1、C語言：迷人的陷阱
作為一款開源開發(fā)者工具，Ockam在GitHub上擁有3.3k Stars，其核心功能是幫助用戶構(gòu)建可信的動(dòng)態(tài)數(shù)據(jù)，為用戶的應(yīng)用添加端到端的加密和認(rèn)證通信；保障應(yīng)用能夠獲得端到端的數(shù)據(jù)完整性、真實(shí)性和機(jī)密性。
研發(fā)團(tuán)隊(duì)希望Ockam能夠在任何環(huán)境中運(yùn)行，包括受約束的邊緣設(shè)備或是強(qiáng)大的云服務(wù)器。除此之外，Ockam的另一個(gè)目標(biāo)則是可以在任何類型的應(yīng)用程序中使用，無論應(yīng)用程序使用什么語言構(gòu)建。
這樣的訴求使得C語言成為了一個(gè)構(gòu)建Ockam項(xiàng)目的明顯候選者——它能夠被絕大多數(shù)設(shè)備編譯，并且所有流行語言都可以通過某種形式的接口調(diào)用C庫。在這樣的情況下，Ockam能夠?yàn)樗衅渌Z言提供慣用的包裝器。
團(tuán)隊(duì)的想法是將以通信為中心的協(xié)議核心從硬件行為中分離，并為想要支持的硬件提供可插拔的適配器。在這樣的思路下，研發(fā)人員在最初的版本中將項(xiàng)目的Ockam的核心實(shí)現(xiàn)為了一個(gè)C庫，并用其他語言包裝器對庫進(jìn)行了包裝。
2、一觸即潰的安全問題
然而基于Ockam核心所實(shí)現(xiàn)的C庫雖然滿足了項(xiàng)目四處運(yùn)行的需求，但由于C語言內(nèi)存管理的薄弱，團(tuán)隊(duì)所實(shí)現(xiàn)的C庫中許多與加密相關(guān)的代碼容易存在漏洞，一個(gè)微小的失誤就會(huì)導(dǎo)致系統(tǒng)變得不安全。
這與Ockam項(xiàng)目的目標(biāo)簡直背道而馳，為了將這些問題隱藏起來，并提供易于正確使用的開發(fā)者界面。團(tuán)隊(duì)開始嘗試使用C語言構(gòu)建安全簡單的接口。但在多次迭代中，開發(fā)人員漸漸發(fā)現(xiàn)自己不得不掌握大量關(guān)于協(xié)議狀態(tài)和狀態(tài)轉(zhuǎn)換的細(xì)節(jié)，并且即便非常小心，代碼中也總會(huì)出現(xiàn)難以察覺的漏洞。
3、Elixir：并不夠好的繼任者
面對無比痛苦的迭代工作，始終無法解決內(nèi)存安全問題的Ockam決定放棄C語言，并為項(xiàng)目尋找更適合的繼任者——彼時(shí)的他們將視線投到了以Erlang為基礎(chǔ)的Elixir語言之上。
Elixir程序運(yùn)行在Erlang虛擬機(jī)BEAM上，BEAM提供了Erlang過程。Erlang流程是輕量級有狀態(tài)并發(fā)參與者。由于actors可以在維護(hù)內(nèi)部狀態(tài)的同時(shí)并發(fā)運(yùn)行，所以運(yùn)行一個(gè)并發(fā)的有狀態(tài)協(xié)議堆棧Ockam傳輸+Ockam路由+Ockam安全通道非常容易。
圖片
但令人遺憾的是，Elixir天然為支持高負(fù)載項(xiàng)目而生，無法像C語言一樣在小型或受限的計(jì)算機(jī)上擁有良好的運(yùn)行表現(xiàn)，此外生態(tài)并不夠成熟的Elixir也無法成為某些特定語言管理包裝器的良好選擇。
4、Rust：令人興奮的探索之旅
在經(jīng)歷了接二連三的失敗后，Ockam團(tuán)隊(duì)意識到他們的需求核心是在保障安全性的前提下實(shí)現(xiàn)輕量級的actors，但無論是C語言還是Elixir都無法做到完美適配。從這時(shí)起，Wadhwa開始帶領(lǐng)團(tuán)隊(duì)研究Rust，并很快發(fā)現(xiàn)了這門語言獨(dú)特的魅力。
與C語言調(diào)用約定（calling convention）的兼容
Rust庫能夠?qū)С雠cC調(diào)用約定兼容的接口。這意味著任何靜態(tài)/動(dòng)態(tài)鏈接或調(diào)用C庫中函數(shù)的語言都能夠以完全相同的方式調(diào)用Rust庫中的函數(shù)。并且由于大多數(shù)語言都支持C中的原生函數(shù)，所以他們也支持Rust中的原生函數(shù)，從包裝器的角度來看，Rust和C幾乎沒有任何區(qū)別。
支持多目標(biāo)
Rust使用LLVM編譯，這意味著它可以針對非常多的計(jì)算機(jī)。這個(gè)集合不像C用GCC和專用的GCC分支所能達(dá)到的那樣大，但仍然是一個(gè)非常大的子集。隨著新的LLVM目標(biāo)和Rust中潛在的GCC支持的增長，這能夠滿足Ockam到處運(yùn)行的需求。
強(qiáng)大的內(nèi)存安全性
Rust的內(nèi)存安全功能消除了釋放后使用、雙重釋放、溢出、越界訪問等許多常見錯(cuò)誤的可能性。根據(jù)此前的調(diào)查，這些錯(cuò)誤會(huì)導(dǎo)致C或C++庫中60-70%的嚴(yán)重漏洞。Rust在編譯時(shí)提供了這種安全性，使其在編寫需要高性能、受限環(huán)境中運(yùn)行并高度安全的代碼時(shí)具有很大的優(yōu)勢。
Async/await
讓研發(fā)團(tuán)隊(duì)堅(jiān)信Rust與Ockam能成為天作之和的最后一個(gè)原因是Rust中的async/await。Ockam需要輕量級的actors來創(chuàng)建簡單而安全的協(xié)議棧接口。async/await意味著在tokio和async-std這樣的項(xiàng)目中已經(jīng)完成了大量創(chuàng)建actor的工作，團(tuán)隊(duì)能夠很輕松地在此基礎(chǔ)上構(gòu)建Ockam的actor實(shí)現(xiàn)。
5、最終的天作之合
基于Rust的async/await無論在大型計(jì)算機(jī)還是微型計(jì)算機(jī)上運(yùn)行，都可以向用戶呈現(xiàn)完全相同的界面。位于Ockam Workers上的協(xié)議接口也可以在任何不同地方運(yùn)行的情況下呈現(xiàn)完全相同的簡單接口。
最終，在Wadhwa的帶領(lǐng)下，Ockam放棄了系統(tǒng)內(nèi)的數(shù)萬行C語言代碼，并利用一段時(shí)間完成了向Rust的全面轉(zhuǎn)型。在經(jīng)歷了重寫后的多次穩(wěn)定性迭代后，如今任何用戶都能夠使用重獲新生的Ockam包，在任何設(shè)備上利用簡單函數(shù)調(diào)用創(chuàng)建他們想要的端到端的加密和相互認(rèn)證的安全通道。
更重要的是，依托于Rust的內(nèi)存安全優(yōu)勢，這個(gè)函數(shù)調(diào)用的背后能夠隱藏所有潛在的復(fù)雜性和漏洞風(fēng)險(xiǎn)。
6、值得期待的未來
在Rust日漸趨于宏大的敘事中，Ockam的故事其實(shí)只是一個(gè)縮影。對如今絕大多數(shù)受困與內(nèi)存安全問題的項(xiàng)目而言，使用Rust或基于Rust進(jìn)行重構(gòu)已不再是一項(xiàng)實(shí)驗(yàn)或賭注，而是切實(shí)可行且足夠可靠的解決方案。
在Ockam之前，微軟已于4月宣布，出于對內(nèi)存安全的考慮，將使用18萬行Rust代碼重寫核心Windows庫；Python Web框架Flask的作者Armin也在Python 2023發(fā)展趨勢的文章中提出了將Rust融入Python項(xiàng)目和工具的想法；Ruff創(chuàng)始人在成立新公司時(shí)，同樣宣稱了要在未來通過Rust徹底改變Python生態(tài)。
更值得欣喜的是，Rust的進(jìn)化如今仍在繼續(xù)，根據(jù)其發(fā)布的Rust 2024路線中顯示，官方團(tuán)隊(duì)將在未來繼續(xù)在降低學(xué)習(xí)門檻、壯大生態(tài)連接等方面努力，幫助Rust盡快撕下被人詬病的“曲高和寡”的標(biāo)簽，讓其盡快在更多場景中發(fā)揮價(jià)值。對此，Rust的未來，的確值得我們每個(gè)人的期待。
參考鏈接：
https://www.ockam.io/blog/rewriting_in_rust
