拜拜 HTTP，哈嘍 Reactive：解決云端的大問題

作者：Mahendra Ramsinghani 2019-10-17 09:19:24

新聞

云計算 如果你認可開發(fā)人員置身于云原生微服務世界這個前提，你就明白大多數(shù)應用程序是分布式、有彈性的。計算分布在集群上，所有數(shù)據(jù)也是如此。

 作者：Mahendra Ramsinghani 是總部位于硅谷的網(wǎng)絡安全種子基金 Secure Octane 的創(chuàng)始人。

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

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

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

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

“云端未解決的大問題”

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

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

HTTP 笑話

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

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

　　HTTP 不適合微服務

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

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

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

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

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

　　拜拜 HTTP，哈嘍 Reactive

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

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

　　的確，F(xiàn)acebook 已采用 RSocket 來減少移動網(wǎng)絡中繼段（hop）上的斷開連接，并大大精簡邊緣基礎設施。Facebook 的軟件工程師 Steve Gury 在 SpringOne Platform 上發(fā)言時稱：“未來是R-Socket 的天下?！?/p>

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

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

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

　　比較服務網(wǎng)格和使用場景

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

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

　　Istio 由谷歌、IBM 和 Lyft 發(fā)起，因此它是強大的老牌技術，品牌老牌度很高。但是當阿里巴巴和 Facebook 之類的公司開始展示 RSocket 的投資回報時，好戲剛剛開始上演。在倫敦最近的一次演講中，支持 Ractive 的陣營一派興奮表情。Facebook 的軟件工程師 Ondrej Lehecka 和 Andy Shi 談到了 RSocket 如何應對現(xiàn)實世界的架構挑戰(zhàn)。Shi 說：“RSocket 旨在在微服務和物聯(lián)網(wǎng)設備當?shù)赖臅r代大放異彩?；?RSocket 協(xié)議和 Reactive Streams 構建的項目將顛覆微服務架構生態(tài)圈。Reactive 基金會是這些令人興奮的項目的核心組織?！?/p>
網(wǎng)站欄目：拜拜HTTP，哈嘍Reactive：解決云端的大問題
分享URL：http://www.5511xx.com/article/dhcecgh.html