[[317069]]

題記：誰具有靈活的外在表現形式，誰就能獲得回報——這正是進化的精髓所在。——凱文·凱利 《失控》

熟知的互聯網協議棧給了我們深刻的“細腰”概念。但這種架構是如何產生的?它是必然的嗎?“細腰”架構在商業、技術、工程上給了我們哪些啟示?互聯網新的細腰結構在哪里?

故事1：CPU指令集的烽火戰事

處理器大戰的這段歷史，已經沉睡在計算機歷史的博物館之中，鮮有人提及。

在20多年前，有許多不同的處理器平臺，戰事一觸即發。

首先是Intel的x86平臺，從8086開始，然后是8088、80286、80386，再到奔騰，等等，這些被稱為CISC(復雜指令集計算機)。

而在戰場的另一邊，則是基于RISC的處理器，蘋果產品、思科路由器和Sun Sparc工作站。

戰事的爭論可以歸結為：Intel x86 ISA是復雜混亂的，有點特別，難以使用，有時有bug，但在芯片級別提供了很多功能。另一方面，基于RISC的處理器有一個更簡單的ISA，更多的功能留給上層的軟件來完成。

二十多年后，戰事的溫度已經消散，Intel x86 ISA輕松獲勝。我們仍然記得蘋果和思科的產品線從基于RISC的處理器轉移到x86平臺;AMD第一次開始制造x86“界面”的處理器，為了運行兼容英特爾處理器的軟件。

x86 ISA能夠獲勝的原因是什么?

英特爾x86 ISA雜亂無章，伴隨著摩爾定律總是在一段時間內增加更多的功能，而與之競爭的RISC處理器則保持非常簡潔，把更多功能留給了上層軟件應用。

這個原因可能是違背了大多數人的直覺。

事實上，微軟首席研究研究員Andrew Baumann在《硬件是新的軟件》一文中總結了 Intel x86 cpu和ISA的復雜性增長，并使用英特爾在2015-2016年圍繞軟件安全向x86 ISA添加12條新指令作為例子，展示了處理器在一段時期內所增加的復雜性。盡管12條新指令聽起來可能不多，但這些特殊的指令要求在CPU中創建新的寄存器、新的堆棧結構(包括聽起來相當復雜的新影子堆棧)、新的異常處理進程(用于中斷)、更改內存頁表格式等等。

這么做的主要目的是使開發人員能夠停止對軟件特定安全部分的信任，而開始信任硬件，而硬件(在理論上)是不能改變的。

原來如此。

Andrew Baumann說道：

摩爾定律(Moore’s Law)的放緩將加大銷售CPU的難度：如果沒有微架構方面的改進，它們的運行速度不會大幅提高，也不會大幅提高能效，而且它們的核心數量與以前的cpu差不多，價格也與以前的CPU差不多。為什么會有人買一個新的CPU?英特爾轉向的一個原因是它的功能：如果新的CPU實現了一個重要的ISA擴展——比如說，一個軟件需要至關重要的安全擴展——消費者將有充分的理由升級。

如果把計算機系統堆棧分層來看，上層是應用程序，底層是實際的硬件，ISA是整個堆棧的細腰部分。Andrew Baumann在《硬件是新的軟件》這樣總結到：“作為當今商品技術堆棧中最穩定的‘細腰’接口，x86 ISA對于很多系統來說都是一個關鍵點。”

[[317070]]

哲學：

• 細腰在應對復雜問題的過程中非常重要。擁有最簡單的細腰是在任何系統中降低復雜性的最重要的事情之一。
• 有些情況下，“精簡”或者簡潔只是工程師的個人品味，和商業無關。
• 反過來看，復雜性是生存的基礎，也并不可怕。關鍵是找到自己增長的“摩爾定律”，比如阿里的復雜性和“雙十一”。
• 細腰總是意味著商品化，而商品化反過來又意味著利潤下降。
• 細腰廠商要么學會用更少的利潤生活，擴展到其他領域，要么學會拓寬腰圍(比如像英特爾的SGX)。而拓寬腰圍意味著復雜性的增加，大多數情況下是以意想不到的方式，而且這又違背設計者簡潔的品味。
• 雖然說軟件吞噬世界，但請小心處理硬件和軟件之間的界限，在更廣泛意義來說，很難區分哪些該是硬件的，哪些該是軟件的。
• 那些承擔更多工作并對外提供簡單接口(隱藏復雜性)的組件(人)將贏得未來。
• 我們總是在拓寬細腰。

故事2：SQL語言的峰回路轉

互聯網和個人電腦出現之前，貝爾實驗室的兩位年輕科學家在發明C語言的時候，意識到，“計算機行業的成功在很大程度上取決于培養一批用戶，而不是訓練有素的計算機專家。”

“他們想要一種查詢語言，像英語一樣容易閱讀，而且還包括數據庫管理和操作。對于沒有受過正規數學或計算機編程訓練的用戶來說，這種語言更容易使用。”——20世紀70年代早期，IBM研究院的兩位博士Donald Chamberlin和Raymond Boyce在思考關系數據庫模型時，意識到查詢語言將成為采用該模型的主要瓶頸，于是著手設計一種新的查詢語言。

于是，SQL在1974年首次面試。在接下來的幾十年里，隨著System R、Ingres、DB2、Oracle、SQL Server、PostgreSQL、MySQL(以及更多)等關系數據庫占領了軟件行業，SQL成為與數據庫交互的卓越語言，并成為日益擁擠和競爭激烈的生態系統的通用語言。

然而，隨著互聯網的不斷發展，軟件社區發現當時的關系數據庫無法處理新的數據規模。之后，兩個新的互聯網巨頭取得了突破，開發了自己的非關系型分布式數據庫來應對這種沖擊：谷歌的MapReduce(2004年發表論文)和Bigtable(2006年發表論文)，以及亞馬遜的Dynamo(2007年發表論文)。

這些開創性的論文催生了更多的非關系型數據庫，包括Hadoop(基于MapReduce論文，2006年)、Cassandra(深受Bigtable和Dynamo論文的啟發，2008年)和MongoDB(2009年)。這一切被稱為NoSQL運動。

NoSQL光彩閃耀，似乎是通向工程成功的捷徑。之后不久，巴別塔的語言效應開始出現：每個NoSQL數據庫都提供了自己獨特的查詢語言，這意味著需要學習更多的語言;將這些數據庫連接到應用程序的難度增加，導致大量脆弱的粘合代碼;缺乏第三方生態系統，要求公司開發自己的操作和可視化工具。

[[317071]]

巴別塔的故事：當時地上的人們都說同一種語言，當人們離開東方之后，他們來到了示拿之地。在那里，人們想方設法燒磚好讓他們能夠造出一座城和一座高聳入云的塔來傳播自己的名聲，以免他們分散到世界各地。上帝來到人間后看到了這座城和這座塔，說一群只說一種語言的人以后便沒有他們做不成的事了;于是上帝將他們的語言打亂，這樣他們就不能聽懂對方說什么了，還把他們分散到了世界各地，這座城市也停止了修建。

還記得數據庫領域圖靈獎得主Michael Stonebraker的文章《MapReduce: A major step backwards》嗎?NoSQL語言的不成熟意味著在應用程序級別需要更多的復雜性。連接的缺乏也導致了去正規化，導致數據膨脹和僵化。

反向的摩擦力使得社區重新回到SQL。首先出現的是Hadoop上的SQL接口(后來是Spark)，引領業界從“NoSQL”轉向“Not Only SQL”。然后出現了NewSQL：完全支持SQL的新型可伸縮數據庫。

業界的焦點聚集在谷歌身上。

谷歌分別在2012年和2017年兩次發表Spanner的論文(作者包括最初的MapReduce作者)，聲稱：

雖然這些系統提供了數據庫系統的一些優點，但它們缺乏應用程序開發人員經常依賴的許多傳統數據庫特性。一個關鍵的例子是健壯的查詢語言，這意味著開發人員必須編寫復雜的代碼來處理和聚合應用程序中的數據。因此，我們決定把Spanner變成一個功能齊全的SQL系統，查詢執行與Spanner的其他架構特性緊密結合(比如強一致性和全局復制)。

在論文的后面，他們進一步闡述了從NoSQL到SQL轉換的基本原理:

Spanner的原始API提供了NoSQL方法，用于對單個表和交錯表進行點查找和范圍掃描。雖然NoSQL方法提供了啟動Spanner的簡單路徑，并且在簡單的檢索場景中仍然很有用，但是SQL在表達更復雜的數據訪問模式和將計算推給數據方面提供了重要的附加價值。

這篇文章還描述了SQL的采用并沒有止步于Spanner，而是實際上擴展到了谷歌的其余部門，在這些部門，多個系統共享一個共同的SQL語言:

Spanner的SQL引擎共享一種常見的SQL語言，稱為“標準SQL”，與谷歌上的其他幾個系統包括內部系統，如F1和Dremel(以及其他系統)，以及外部系統，如BigQuery…

對于谷歌內的用戶，這降低了跨系統工作的障礙。針對扳手數據庫編寫SQL的開發人員或數據分析人員可以將他們對語言的理解轉移到Dremel，而不必考慮語法、空處理等方面的細微差異。

這種方法的成功不言自明。Spanner已經是主要谷歌系統(包括AdWords和谷歌Play)的“真實來源”，而“潛在的云客戶對使用SQL非常感興趣”。

因此，有人質疑：谷歌這個老司機是不是把大數據行業給帶偏了?

目前，所有主要的云供應商都提供流行的托管關系數據庫服務：例如，Amazon RDS、谷歌云SQL、用于PostgreSQL的Azure數據庫、當然也有阿里巴巴的數據庫體系。Hadoop、Spark和Kafka上的SQL接口也繼續蓬勃發展。

亞馬遜 CTO甚至說：(與PostgreSQL和mysql兼容的)Aurora數據庫產品是“AWS歷史上增長最快的服務”。

這段歷史意味著SQL重新回歸數據的通用接口。數據分析軟件堆棧的細腰已經形成。

哲學：

• 從巴別塔的失敗中汲取教訓。
• 所有的細腰都是語言接口，而SQL更明顯。
• 我們總是在拓寬細腰。

故事3：系統調用原語永存

這張地圖，描繪了免費開源軟件與微軟帝國的史詩般的斗爭。

在操作系統的戰場上，《軟件戰爭之后》的作者如此評價Unix家族樹：Unix和Linux還沒有打敗Windows的最大原因是工作站供應商沒有在軟件上一起工作，因此不斷地重新實現彼此的特性。

1980年代的“ UNIX戰爭”之所以發生，是因為許多UNIX供應商(他們的產品均基于原始Bell Labs UNIX的不同版本)，其產品略有不同，并引起了激烈的競爭。

Unix在商業爆發之前已經流行了很多年，但是其商業成功的關鍵是一波低成本工作站的迅速涌現，它迅速將集中式微型計算機推到了一邊。這些工作站運行的操作系統在許多情況下幾乎與大型系統上的操作系統相同，但是它們更小，更便宜，以至于它們可以部署在單個員工的桌面上。一些供應商進入了該市場以及相關的存儲和計算服務器市場。

問題是這些供應商中的每一個都有自己的Unix版本。所有的Unix變體可能都有某種共同的遺產，但是，當它們出現在已部署的系統上時，它們已經完全不同了。類Unix系統的異構網絡給系統管理員，開發人員和用戶都帶來了挑戰。每種新的系統類型都有其自己的一套怪癖，錯誤和不完善的特性要處理。隨著各種Unix實現的分歧，它們變得越來越令人討厭。結果，許多組織試圖標準化單個供應商，希望他們選擇了正確的供應商。

要么，要么他們轉向那些當時沒有以任何令人信服的方式運行Unix的廉價新PC系統。但是它們確實運行DOS(最終運行Windows)，一旦運行它們，它們都是一樣的。打包的軟件變得隨時可用，到1990年代中期，越來越清楚的是，未來的桌面系統將不再運行Unix。令人沮喪的是，幾乎所有Unix工作站供應商都在與Microsoft進行交易，并宣布未來的工作站(和服務器)將改為運行Windows NT。那是一個黑暗的時期。

Linux是在Windows幾乎遍布全世界的情況下，嘗試拯救世界。但是，幾乎從一開始，批評者就開始說Linux會像Unix一樣嚴重地分裂。

事情發展正是如此。

在商業面前，Unix和Linux的似乎沒有辦法汲取巴別塔的教訓。

操作系統的細腰在拓寬，但Unix的哲學卻保留了下來。

作為細腰模型的案例經常被提及的，一個互聯網協議棧，一個是Unix系統調用接口。

正是Unix的哲學讓系統調用的原語一直保存下來：

• 模塊化規則：編寫通過干凈接口連接的簡單零組件。
• 平行思考：大多數任務由可能并行運行的子任務組成。這也適用于用戶交互。并行可以節省大量時間和挫敗感。
• 分層思考：層次結構允許跨嵌套元素統一應用任務和屬性。這是一個鼓勵分解和模塊化的重大想法。

哲學：

• 簡單。簡單性的一個關鍵方面是正交性。在服務接口中，正交性意味著只有一種方法可以訪問任何基本的底層服務或資源。冗余特性增加了接口的復雜性，卻沒有使它在邏輯上更強大。系統架構師理解接口設計中正交性的價值，并且接受這種簡單形式的設計標準。Unix系統調用接口中的一個正交性示例是將目錄之間的文件移動分解為三個操作：創建物理鏈接(使用link())、在目標位置創建鏈接的副本，然后刪除原始鏈接(使用unlink())。這種復合性的文件移動操作是在用戶級命令(mv)中實現的。這使得用戶級文件移動操作可以很容易地一般化，包括物理卷之間的移動(這需要復制內容)，以及使用link()在同一個卷中實現有效的文件共享。
• 原語。人們經常注意到，操作系統和互聯網支持的應用程序的多樣性遠遠超過了其初始設計者所預見的。設計人員創建了一組通用原語，以便這些目標應用處于原語所支持的空間中。這個空間還包括許多其他的應用，包括許多最初沒有預見到的應用。
• 抽象。實現資源限制和信息隱藏。細腰層提供其實現中的資源抽象，防止應用程序直接訪問它們。信息隱藏是通過隱藏模塊的實現細節來實現模塊化編程，從而使用戶無需了解模塊內部的復雜性。

故事4：IP協議適者生存

毫無疑問，互聯網的細腰是網絡層IP協議。盡管有很多文章宣稱UDP，TCP，HTTP成為新的細腰，但并沒有得到廣泛認可。

美國計算機學會(SIGCOMM)數據通信特別興趣小組在2011年的一項研究表明：互聯網細腰結構的出現遵循一個進化模型，稱為EvoArch。在自然界中，共享同一生態系統的物種經常爭奪資源，導致較弱的競爭者滅絕。互聯網架構演變也發生了類似的事情：網絡的結構隨著不同層新協議的創建而變化，現有協議由于與同一層其他協議的競爭而被刪除。

在分組交換網絡的發展過程中，開發了許多不同的協議(或協議棧)。隨著時間的推移，所有這些協議都被放棄了，轉而支持IP協議棧。例如，Banyan Vines有自己基于IP協議的協議棧，稱為VIP(Vines Internet Protocol)，而Novell NetWare也有自己的基于IPX協議的協議棧，叫做IPX。其他標準化組織同樣創建了各自標準的協議族，如國際電信聯盟(International Telecommunications Union，ITU)就構建了無連接模式網絡服務的協議族(Connectionless Mode Network Service，CLNS)。

為什么這些協議族都半途而廢了呢?因為其中一些協議是私有的，許多政府和大型組織出于各種原因拒絕了分組交換網絡中私有性質的解決方案。私有協議通常是由少數人群開發和維護的，通常也會缺乏深思熟慮。基于標準的協議可能更復雜，但它們也往往由更多經驗豐富的工程師開發和維護。基于CLNS的協議棧在過去的一段時間里一直是個有力的競爭者，但它從未真正在全球互聯網上流行起來，而當時全球互聯網正成為一股重要的經濟力量。還有一些具體的技術原因，例如，CLNS不對線路編號，而是對主機編號。可達性信息的聚合由此受到了許多方面的限制。

——《計算機網絡：問題與解決方案》

EvoArch的研究指出：

• 細腰的上部在拓寬，但競爭是你死我活。文件傳輸協議(FTP)和HTTP提供的服務在特定于應用程序的層中重疊。當HTTP因其自身的高層產品(如Web瀏覽器等應用程序)而變得更有價值時，FTP就消失了。
• 細腰的底層模塊每一個都必不可少，對于網絡來說，其主要原因可能是這些協議模塊靠近硬件，迭代周期長，沒有一個協議能夠占絕對的主導地位，所以長時間共同存在。
• 細腰部分出現古老而強大的協議。這些協議被稱為演化核心，很難進行重大修改。
• 競爭必然導致細腰，保持細腰多樣性的一個建議是在設計服務和功能時候不要重疊，以避免競爭。
• 最好的協議不一定在競爭中獲勝。

EvoArch的研究表明，即使未來的互聯網架構最初不是以細腰的形狀構建的，隨著它們的發展，它們也可能演進為細腰的形狀。

哲學：

• 自由軟件在復雜的環境中工作得很好。也許根本沒有人了解全局，但進化并不需要全球的理解，它只需要局部的小改進和一個開放的市場(“適者生存”)。——Linus Torvalds
• 進化的結果，細腰緩慢地沿著協議棧向上移動。
• 良好的細腰設計帶來互操作性。
• 細腰結構帶來部署擴展性。
• 保持較低的層次通用，以便最有效地滿足較高層次的特定要求。

互聯網新的細腰結構在哪里?

IP成為互聯網協議的細腰之后，業界有兩個力量推進細腰結構的演進。

第一個是社區推動整個網絡協議棧成為細腰。

第二個是NDN推動IP細腰向內容細腰的轉變。

IPFS是一個雄心勃勃的項目，融合了NDN, Git, BitTorrent, IPFS, Tahoe-LAFS, SFS等多種思想，旨在取代HTTP構建新的互聯網細腰。

在IPFS協議的腰部，是一個稱為星際鏈式數據(InterPlanetary Linked Data，IPLD)的數據結構。簡單來說，IPLD是將傳統Posix語義的文件目錄樹映射為不同節點上的DAG圖，稱為IPFS unixfs 。IPFS unixfs 使用可插拔的數據分片算法對傳統posix 語義的文件進行分片。傳統posix 語義的文件是順序存儲的字節，IPFS unixfs 是基于分片的有向無環圖。IPFS unixfs的最小單位是分片，這些分片被稱為葉子或者數據片，為了構建有向無環圖，必然需要引入中間文件對象，這些中間對象通過一定拓撲hash為一個root CID。IPFS unixfs 這種構建圖式數據存儲的方式被稱為IPLD，即是星際鏈式數據，這也是IPFS 內容尋址的基礎。

把IPLD這樣的數據結構映射在互聯網的網絡結構之上，IPFS就有了星際互聯的能力。

協議在變胖，應用在變瘦，Web正在走向Web3。

和區塊鏈(Filecoin)一起，IPFS正在成為Web3的基礎設施。

分布式，模塊化，邊緣生長，元變化，。。。很多IPFS正在踐行的哲學需要IPFS自身給出證明。

我們拭目并報以溫暖的期待。

混沌和隨機是兩回事

在混沌中存在著秩序。——凱文·凱利 《失控》

[[317072]]