天天看點

無伺服器、Rust,都是舊技術的二次創業

無伺服器、Rust,都是舊技術的二次創業

譯者 | 蔡柱梁

還記得大型機嗎?無伺服器就好比如:我們擁有這台機器,你來我這裡租借。創新往往都是在踩在巨人肩膀上誕生!

分時度假是一種源于歐洲的度假模式,就是把酒店或度假村的一間客房或一套旅遊較高價的電梯大廈,将其使用權分成若幹個周次,按10至40年甚至更長的期限,以會員制的方式一次性出售給客戶,會員獲得每年到酒店或度假村住宿7天的一種休閑度假方式。并且通過交換服務系統會員把自己的客房使用權與其他會員異地客房使用權進行交換,以此實作低成本的到各地旅遊度假的目的。

回過頭看,無伺服器就是新的分時度假!

我們都有健忘症。當我與年輕的開發人員談論過去的技術時,我經常會得到茫然的目光。公平地說,有些是因為我有點“緊張”或“怪異”,但有些是因為年輕的技術人員并不了解過去的技術。

舉個例子:有些年輕的技術人員根本不清楚什麼是兩端送出(2 Phase Commit)。難道是事務管理已經不需要了嗎?

銀行是否不再需要一緻性?如果你不在“同一頁”上,該技術通過在不同的伺服器之間傳輸事務上下文來工作。是以,一台伺服器上的送出是一個多階段過程,幾乎可以保證所有伺服器都成功或作為一個伺服器復原。這是相當驚人的,實際上效果相當好(顯然有一些警告)。令人驚訝的是,這是通過方法調用實作的。你不需要做任何事,即使在完全不同的伺服器上調用遠端方法,它也能好好工作。

幾年前,我與銀行業的一家叫 Node-based 的初創公司交談。他們表示,銀行對與Node合作非常開放。我知道他們在更“成熟”的環境中重寫他們的東西。當我使用一些“較新”的工具,如Node時,我總是對缺少的基本功能感到驚訝。當然,如果你不把我們需要的一切都融入其中,它會更簡單、更小。當您放棄核心功能時,很容易建構簡單的東西。

2010 年代的 NoSQL 戲劇

早在 1999 年,我正在組建自己的咨詢公司,一位朋友讓我見見他的老闆。我去了這個辦公室,“老闆”說他有一個沒有人想到的最驚人的想法。他們有資金,将在 6 個月内推出産品,并在第一天就向 100 萬使用者推出!

我:好的。什麼想法?

他:我會在你報名為我們工作後告訴你。

我:我會簽署 NDA(NON-DISCLOSURE AGREEMENT,即不公開協定)。

他:不。這個主意太好了。那些保密協定一文不值。你注冊然後…

不知道為什麼,我居然能夠頂住為這家公司工作的誘惑。大概一年後,他們顯然沒有推出,但我的咨詢公司做得很好。朋友又打電話給我了。這一次他們需要産品方面的幫助,是以我以咨詢的身份去那裡幫助他們。

他們的想法是在網站中内置一個聊天應用程式,這樣網站的通路者就可以互相聊天。一個競争對手已經推出,我正在咨詢其他幾家具有相同想法的公司。他們轉而專注于與電子商務相關的聊天。但我離題了……

他們的系統表現非常糟糕。一個使用者的速度就像黏了蜜糖的螞蟻一樣慢。顯然,CEO 堅持他們需要在第一天就能支援 100 萬使用者(正如他告訴我的那樣)。他們将這一點傳達給Oracle公司,Oracle說他們需要一個由三台伺服器組成的叢集來支援這個容量。然後他們與一家面向對象的資料庫供應商進行了交談,後者承諾他們可以用一台機器處理 100 萬使用者。是以他們全神貫注于面向對象的資料庫。當我對此表示震驚時,他們聲稱他們的資料非常“面向對象”,因為每個使用者都可以擁有多個項目……呃。

他們不了解事務邊界,存儲代碼與所有代碼混合在一起,而且速度很慢。這是不可靠的,無法了解。您可能不記得面向對象的資料庫時期,但它是 2010 年代席卷我們行業的 NoSQL 時尚的先驅。在擔任顧問的那段時間裡,我重新觀看了這個故事的重播。這一次大多數公司都成功推出了。

但後來他們發現擁有非結構化資料并不是萬能的。與僅使用良好的緩存和經過良好調整的 SQL 相比,他們在性能方面獲得的好處是微不足道的。部署故事非常複雜,輔助工具可能永遠無法達到我們在 SQL 世界中所擁有的水準。

需要明确的是:NoSQL有自己擅長的領域,但是這些資料庫常見的用途并不是很好,并且源于 RDD(恢複驅動開發)。這是我們這些已經在街區附近轉過幾次的人一遍又一遍地看到的模式:

• 舊技術笨重複雜

• 人們發明了一些幹淨簡單的東西

• 忘記舊技術的存在

• 新東西過于簡單化,并沒有做很多基本的東西

• 重塑這些複雜性

• 新的東西變成了需要重新發明的舊的和笨重的複雜性……沖洗/重複

無伺服器是新的大型機

在過去的一個月裡,我做了很多無伺服器的工作,我覺得這是一個很大的倒退。這是重蹈覆轍我們在 PaaS 上遇到的問題。它實際就是一個大型機。過去,我們曾經為在共享使用的大型機上運作工作付出代價。這有點像​虛拟化環境​​,但想法相似:我們不擁有該環境。可以說這對于雲 SaaS 也是如此,但無伺服器将這個概念帶到了很遠的地方。

甚至調試體驗也很糟糕。我們沒有對我們的代碼或基本應用程式邏輯的基本控制。我正在努力弄清楚為什麼人們将它用于基本任務之外。

我能想到一個很好的用例:webhook。擷取 webhook 的管道代碼總是很痛苦。他們不經常觸發,處理它是一件苦差事。使用無伺服器功能将内容添加到資料庫并完成工作可能非常簡單。由于無論如何都很難調試回調,是以無伺服器中糟糕的調試體驗并不是一個巨大的障礙。但是對于其他所有用例,我絕對感到困惑。

人們花費大量時間檢查和測量吞吐量,但僅使用一台稍大的伺服器,并且隻有本地調用會産生超出您可能需要的吞吐量。沒有我們陷入的所有供應商捆綁。使用 Linode、Digital Ocean 等托管會節省很多錢。在上市時間方面,僅使用緩存和快速本地工具将比您可以在雲中建構的任何東西容易得多。

容器是一個很好的進步,它們讓這一切變得簡單多了,但我們會被為了使用容器而帶來的複雜性累垮,比如K8S。不要誤會我的意思。K8S很棒。但我們 98% 的人并不真正需要它,也不應該使用它。如果你是一家小型的創業公司,Kubernetes 是在浪費你的時間和精力。

回到 Java 和 Rust

Java 就是一個在“健忘方面”做得很好的例子。我們有 Smalltalk,它很棒。當 Java 剛出現時,它是一種具有怪異 C 文法風格的劣質解決方案。Java 在 Smalltalk 和 C++ 中抛棄了許多偉大的想法。它采用了一些有争議的想法(檢查異常、原語等)。然而它成功了。它吸引了人們的注意力;它能夠利用這一點。

它最初是一種輕量級語言,可以丢棄其他平台添加的所有垃圾和過度工程。現在看看,再也沒有人将其描述為“輕量級”。開發人員正忙于建立更輕、更簡單的語言來抱怨 Java 的錯誤。成功會讓他們回到我們開始的地方。一種成長太多的輕量級語言。Java 目前處于應有的位置。這是一個好的重寫的少數例子之一。

Rust 似乎也是少數例外之一。它以一種全新的方式重新發明了 C。很難說它是否能長期生存。但毫無疑問,它需要在此過程中承擔很多複雜性。

有意識的重塑

是什麼讓對現有語言或工具的重新發明成功赢取大衆市場,又是什麼讓這些工具被擱置一旁?

SQL 起死回生,再次受到新創業公司的青睐。對于 C++ 則不能這樣說。它們有何不同?

盡管缺少我們在 JVM 世界中擁有的基本功能,但 Node 和 Python 仍然很受歡迎。那是怎麼回事,他們會維持這種受歡迎程度嗎?他們會把這些東西加回去嗎?

直到青少年時期,我們的大腦不斷地增加突觸。在我們十幾歲的時候,我們把它們砍掉了。一種理論是,這是我們作為青少年所經曆的所有變化的根源。我們需要斷開不再為我們工作的東西。否則,我們隻會學習父母所知道的。我們不能通過犯自己的錯誤來改進。再次嘗試那一代人失敗的事情。

結果,我們重複了錯誤,犯了一些新的可怕的錯誤。我們也取得了一些驚人的飛躍和發現。這是創新起飛的地方,工程也是如此。

我們如何區分:青少年焦慮與光明的新方向?

老實說,我們不能。作為一個年長者,當我第一次看到這些東西時,我覺得很多東西都很愚蠢。我們已經嘗試過這些事情并且失敗了。為什麼要重複那個錯誤的方向?這就是創新所在。但是,如果我們仔細觀察成功的嘗試,我們可以看到對他們有用的東西。

Java 并非旨在結束 C++。當然,這可能是一個幻想。但高斯林設計它是為了簡單和輕小。要解決非常狹窄的利基市場,請關注安全性、規模和網絡。

Rust 并非旨在終結 C。它旨在使 Firefox 等項目更加穩定和高性能。

我認為,當我們最初将自己限制在一個非常小而狹窄的用例時,二次發明就像任何初創公司一樣,效果很好。通過這樣做并保持最初的關注點,我們可以建立一些好的東西,然後實作偉大的飛躍。

譯者介紹

蔡柱梁,51CTO社群編輯,從事Java後端開發8年,做過傳統項目廣電BOSS系統,後投身網際網路電商,負責過訂單,TMS,中間件等。

原文标題:​​Serverless Is the New Timeshare​​,作者:Shai Almog

來源: 51CTO技術棧