作者：Mahendra Ramsinghani 是總部位于硅谷的網絡安全種子基金 Secure Octane 的創始人。

[[279424]]

　　阿里巴巴、Pivotal 和 Lightbend 加持，Reactive 大秀其在微服務界的投資回報！

　　Linux 基金會最近宣布設立 Reactive 基金會。該基金會的創始成員有阿里巴巴、Lightbend、Pivotal 和 Netifi。那么，這個 Reactive Kool-Aid 到底是什么？為什么所有這些公司都紛紛追捧它？

　　如果你認可開發人員置身于云原生微服務世界這個前提，你就明白大多數應用程序是分布式、有彈性的。計算分布在集群上，所有數據也是如此。可能是幾個用戶，峰值狀態也可能是成千上萬個用戶。設計的系統其架構需要應對這種峰值情況。不過，微服務的秘密在于復雜性——資源、成本、性能和延遲的管理仍是個挑戰。

　　如果我們將任何應用程序分解成數百個基本模塊（比如容器和微服務），那么最好有一種優雅的方法來管理這些基本模塊。這些服務需要始終彼此聯系、交互數據并確保總體性能很可靠。說起來容易做起來難。

“云端未解決的大問題”

　　據 IBM 云的杰出工程師 Daniel Berg 聲稱：“網絡是云端未解決的問題……我們需要網絡成為云系統的一等公民。”為什么網絡仍是個問題？是因為我們需要重新思考新事物時，沿用舊方法嗎？我們曾經設計的汽車裝有四輪單馬輕便馬車那又大又笨拙的輪子。從概念上來講，這聽起來不錯，但坐起來很不舒服。

　　在網絡協議的分層體系中，中間層是傳輸（傳輸控制協議/互聯網協議即 TCP/IP），而最頂層是應用程序層。我們使用一種名為超文本傳輸?6?7?6?7 協議（或 HTTP）的協議來確保 Web 應用程序可以彼此聯系。TCP 誕生于 1974 年，被稱為“繁瑣的協議”（chatty protocol）——就為了做一些基本的事情它要來回往返多次。一則坊間盛傳的 TCP 笑話證明了這一點。

HTTP 笑話

　　HTTP 誕生于 15 年后的 1989 年，用于在客戶端/服務器時代提供文檔。那個年代，我們所有人都用旋轉風扇給臺式機散熱。我們會使用 Netscape 瀏覽器來打開網頁（超文本），Web 服務器會說：“等一下，讓我為你獲取該內容。”

　　三十年后，計算層呈爆炸之勢，我們試圖用 HTTP 來應對。在機器對機器通信大行其道、交互瞬間達數百萬次的時代，HTTP 是否適用？我們的移動設備、物聯網設備和邊緣設備并沒有頻繁請求大段大段的文本。而且，客戶端/服務器交互不如對點對交互來得多。但是網絡層一直困擾著我們，我們在努力確保：使用某些過時的方法，這些微服務可以留在原處。Pivotal 的首席軟件工程師 Stéphane Maldini 說：“多達 89% 的微服務架構都基于 HTTP。”Pivotal 是 Reactive 基金會的創始成員之一。在此過程中，我們在效率方面做出很大的妥協。我們應使用下一代 iPhone，卻仍使用兩個罐子和一根繩子進行通信。

　　HTTP 不適合微服務

　　如果我們在微服務時代使用 HTTP，會面臨根本性的挑戰。首先，沒有流量控制——“這意味著數據如同從消防水帶噴涌出來，”Netifi 的聯合創始人 Robert Roeser 說。由于可以迅速傳輸數據、打開多個線程，我們最終構建了控制功能，以確保應用程序不會崩潰。

　　反應式編程是架構層面的根本性改變。它注重速度和性能。

　　需要有效地管理諸多方面，比如斷路器、重試邏輯和線程驚群（thundering herd，指大量進程被喚醒，但只有一個進程享有資源，常常導致系統凍結）。在 HTTP 中，一切都是請求/響應，但是如果我們看一下應用程序的簡單通知，我們不需要一直保持輪詢狀態。請求好比剛上路，急不可耐的孩子坐在后座上嚷個不停“我們到了嗎？”

　　如果我們使用錯誤的協議，這種低效的機制會導致計算資源嚴重浪費。IBM 記錄下了微服務的低效率：

　　得出這個結論：微服務的性能比傳統的整體式模型低 79% 左右。研究人員總結道：“我們發現，用于處理 HTTP 通信的 Node.js 和 Java EE 運行時庫在微服務模型中消耗的 CPU 周期比在整體式模型中多很多。”

　　拜拜 HTTP，哈嘍 Reactive

　　Reactive 基金會隸屬 Linux 基金會，旨在加速下一代網絡技術。它采納反應式編程框架（Reactive Programming Frameworks）的優點，建立了社區。Reactive 基金會主席兼 Netifi 聯合創始人 Ryland Degnan 還是 Netflix 邊緣平臺會員的時候對 HTTP 帶來的痛苦深有體會。

　　Ryland 比大多數人更了解規模、延遲和用戶體驗。Netflix 平臺會收到來自數億會員的數十億個請求。他說：“我們生活在多維世界中，用戶體驗至關重要。開發人員必須處理以下三個方面：（a）部署（b）框架和（c）協議。時斷時續的連接不可接受。為什么我們不能從上次停止的地方繼續下去呢？如果我們單單做到這一點，可以減少我們基礎設施 90% 的部分。”

　　的確，Facebook 已采用 RSocket 來減少移動網絡中繼段（hop）上的斷開連接，并大大精簡邊緣基礎設施。Facebook 的軟件工程師 Steve Gury 在 SpringOne Platform 上發言時稱：“未來是R-Socket 的天下。”

　　反應式編程（Reactive programming）是架構層面的根本性改變。它注重速度和性能。Reactive 的主要優勢之一是異步I/O，這可以將邊緣基礎設施精簡幾個數量級。

　　阿里云的開發倡導者 Andy Shi 是 Reactive 基金會的創始成員之一。他說：“阿里巴巴有數千名開發人員，我們是世界上最大的電子商務平臺之一。我們采用微服務時看到計算的使用率只有 10% 左右，因此往服務網格投入更多的基礎設施不是解決之道。pod 使用 REST API 彼此聯系，這不是出路。”

　　REST API 需要多個端點和多趟往返才能獲取數據。十多年來，Reactive 基金會的另一位創始成員、Lightbend 的代理首席技術官 Viktor Klang 一直在大力宣傳 Reactive，他感覺現在時機終于到來。他說：“我們的系統需要在所需的時間段內獲得結果。試想一下，如果你可以計算出重大問題（比如生命意義）的答案，但如果答案在你死后才獲得，系統就是失敗的。”

　　比較服務網格和使用場景

　　如果說 Istio 是最適合平移的 18 輪重型卡車，RSocket 就是法拉利，注重速度與優雅。專家們預示將來兩者可能會共存。不過在一些應用領域（比如物聯網使用場景），RSocket 顯然有優勢。Istio 提供負載均衡、服務發現、日志記錄和流量管理等功能，不過開銷很大。

　　在研究中，Netifi 相比之下能夠處理數量多 16 倍的請求，吞吐量提高 4 倍，同時延遲只有三分之一——也就是說，吞吐量提高了 372%，延遲縮短了 300%。戴爾科技資本公司的投資者 Creighton Hicks 說：“Netifi 有可能如同思科——微服務界的路由器。”

　　Istio 由谷歌、IBM 和 Lyft 發起，因此它是強大的老牌技術，品牌知名度很高。但是當阿里巴巴和 Facebook 之類的公司開始展示 RSocket 的投資回報時，好戲剛剛開始上演。在倫敦最近的一次演講中，支持 Ractive 的陣營一派興奮表情。Facebook 的軟件工程師 Ondrej Lehecka 和 Andy Shi 談到了 RSocket 如何應對現實世界的架構挑戰。Shi 說：“RSocket 旨在在微服務和物聯網設備當道的時代大放異彩。基于 RSocket 協議和 Reactive Streams 構建的項目將顛覆微服務架構生態圈。Reactive 基金會是這些令人興奮的項目的核心組織。”