後·馮諾依曼時代,一場計算機革命悄然來臨

後·馮諾依曼時代,一場計算機革命悄然來臨

15 人贊了文章

號稱能夠滿足區塊鏈擴展性要求的區塊鏈3.0們,沒有一百也有八十。這其中除開大部分的空氣項目,真正有創新有作為的候選者,在筆者看來屈指可數。 它們大都通過sharding或者Layer 2的方案在傳統的馮諾依曼體系架構下修修補補,不能說這樣的選擇有錯。 但其實可擴展性難題並不僅僅是區塊鏈需要面對的難題,在傳統的軟體工程中可擴展性難題普遍存在。在這些區塊鏈3.0項目中,有一個卻意義非凡,它從計算機基礎理論著手,從最根本的層次上解決可擴展性難題。

可擴展性之痛

可擴展性(scalability)是系統總體容量(吞吐率)能夠隨節點數增加而線性增加的能力。 這個看似簡單的要求卻需要頑強的努力和精湛的技藝才能針對性地在某個特定領域內的實現。

  • 從程序設計的角度來說,必須針對性地設計來協調多台伺服器。設計能夠無限擴展的程序和只需要運行在單節點的程序在難度上不可同日而語。
  • 從運維的角度來說,支撐大規模分散式系統的穩定運行異常的艱辛和繁瑣。為了實現N個9的SLA,從部署、磁碟存儲到網路,都需要針對性地設計運維方案和災備預案。

任何一個簡單的程序只要上了一定的規模,可擴展性就成了必須要面對的問題。它不僅僅是區塊鏈需要解決的問題,同時也是傳統軟體工程中揮之不去的陰霾

跛行千里

來自擴展性的挑戰由來已久,業界一直都在不斷嘗試,尋求一種普適的方法來破解擴展性難題。

  1. DevOps 從PaaS到docker,再到容器編排系統,業界發展了不可勝舉的工具、流程。在一定程度上確實降低了解決擴展性問題的門檻。 比如:在Google Cloud Platform上使用Kubernete部署和運維,特別是通過Autoscaler自動地添加或者裁剪Pod集群,都能夠切身地感受到了K8S帶來的便利。但DevOps並沒有解決擴展性難題 -- 由於各類資源對於程序並不是透明的,因此程序在設計之初就需要考慮運行環境並針對性地設計和優化,特別是對於數據共享、分散式存儲設計仍久有諸多挑戰。

  2. Serverless 近兩年來興起的Serverless框架,典型代表是亞馬遜的AWS Lambda 和谷歌的Google Cloud Functions。它們都致力於提供一個開發框架,在此框架內編寫的代碼能夠在它們的雲平台上獲得無限擴展的能力。 Serverless並不是說沒有伺服器。它指的是代碼的編寫完全不需要考慮運行環境。而支撐Serverless程序運行的基礎設施(伺服器、存儲、網路)的複雜操作都交給了雲平台。 當系統容量不夠時,雲平台自動地擴展基礎設施,而所有這一切對於程序是透明的。 這樣一種解決方略卓有成效,使用這些巨無霸公司提供的產品固然可以解決問題, 它們將最複雜的分散式任務調度、編排、基礎設施災備這些都隱藏起來, 然而使用它們的產品同樣也意味著「技術綁架」,限制擴展性的因素變成了信用卡上的剩餘額度。

一路行來,業界取得的成就有目共睹。但似乎缺乏從根本上徹底解決可擴展性難題的勇氣?

可擴展性難題的根源在哪?

儘管編程語言越來越多, 但它們都走進了同一個死胡同 -- 「λ演算」 。 包括C++、C#、Java、Scala、Haskell、Python、Erlang、Golang等等,基本上只要你能叫出名字的編程語言,都源於「λ演算」 。

λ演算(Lambda-Calculus)是最基本的編程語言。 它最早是由Alonzo Church(圖靈的博導)在20世紀30年代引入,之後的Church–Turing thesis證明了λ演算與圖靈機是等價的。 隨後的50年代,以隨機存儲器為特徵、通過紙帶輸入的馮諾依曼計算機的面世,λ演算有了用武之地。 在輸入指令的時候,為了避免重複勞動復用某個功能,將這個功能的指令打包成一條紙帶。 每當需要用到這個功能時就輸入這條紙帶,這條紙帶就可以視為λ演算中的函數(function),它將一組指令打包後允許重複地調用。 即使發展到今天,雖沒有了紙帶,但本質上並沒有任何改變 -- 基於「λ演算」的語言的特徵就是對函數調用的聚集。

λ演算和馮諾依曼計算機相輔相成,奠定了當今信息時代的輝煌成就。但是單一計算節點總是存在容量瓶頸,為了提高系統的整體容量,必須讓多台計算機組成一個整體協同工作。

可擴展性難題的根源就在於目前主流的馮諾依曼體系架構,因為它是不可組合的; 計算機與計算機之間的邊界對於λ演算並不是透明的。 即,兩台馮諾依曼計算機加在一起還是兩台獨立的計算機。這種隔閡對於程序來說是不可忽視的,也就導致了前文中提到的難題。

破解之道

既然根源在於缺乏可組合性(Compositionality),那麼根本性的解決之道呼之欲出。

λ演算從上世紀創立後並沒有停止發展,在它的基礎上逐漸發展出了以Rho演算(Rho-Calculus)和?演算(Phi-Calculus)為代表的高階演算(Higher Order Calculus)。 其中Rho演算最為接近實用,它已經被成功地應用到了微軟BizTalk服務中。從Rho演算衍生出的Rholang編程語言以及RhoVM虛擬機現在發布了0.6版本。 RhoVM虛擬出基於Rho演算的計算機--RhoMachine,而Rholang就運行在RhoMachine中。 RhoMachine雖然運行於馮諾依曼計算機之上,卻和馮諾依曼計算機有本質的區別--它虛擬出的RhoMachine是可組合的

RhoMachine的組合

多台RhoMachine可以組成一台RhoMachine,這對於Rholang程序來說是完全透明的。從程序的視角來看,只有一台RhoMachine,這台RhoMachine可能由多台RhoMachine組成,但是程序並不關心,這樣RhoMachine的總體容量不再受限於單個物理節點, 同時程序在設計和運維上也不需要為特定場景針對性地制定方案。

想知道Rho演算為什麼具有可組合性?最直觀的方式是從Rholang切入理解它的工作方式。在《初識Rholang》和《元組空間》這兩篇文章中解釋了可組合性的緣由。

Rholang設計為一種通用的編程語言,而RChain區塊鏈項目只是它實踐的第一個項目--搭建一台可以無限擴展的超級計算機。 因此可以說Rho演算的征途是星辰大海,它的目光不僅僅局限在區塊鏈上,它的願景是一勞永逸地從根本上解決馮諾依曼體系帶來的弊端。

後·馮諾依曼

後·馮諾依曼時代已經悄然來臨,這是一片荒蕪之地,也是一片可以大展拳腳的「藍海」。可擴展性難題只是馮諾依曼計算機被詬病的眾多缺點之一。 Rho演算帶來的不僅僅是可組合性一個特性,它還有其它許多方面的優勢,比如程序可以隨時中斷隨後恢復、數據優先、代碼與數據一體 等。

IBM和惠普這樣的大公司正在研究憶阻器計算機; Intel業已發布了相變內存等新技術。而作為後·馮諾依曼時代的計算機基礎理論 -- Rho演算,必將指引著人類掀起一場計算機體系結構的革命!


推薦閱讀:

C++: Abstract Classes and Pure virtual Functions
W3C近期要聞:W3C重點報告發布,綜述2018年發展路線圖
Safety and Liveness Properties
PDF加密工具及方法
Python基礎:字元串格式化--完整版

TAG:科技 | 電子計算機 | 計算機科學 |