10多年前，馬克·安德烈森在《華爾街日報》上發(fā)表了他的著名文章《為什么軟件正在“吞噬”世界》。他從投資者的角度，解釋了為什么軟件公司正在接管全部行業(yè)。

作為一名公司創(chuàng)始人，我們公司的業(yè)務就是在邊緣支持GraphQL，因此，我想就為什么邊緣正在“吞噬”整個世界這個話題，來分享一下我的看法。我們將快速回顧過去，再俯瞰當下，并根據目前的觀察結果，用第一性原理進行推理，去窺探一眼未來。

讓我們開始吧。

CDN的簡史

Web應用程序使用客戶機－服務器模型已逾40多年了?！翱蛻舳恕毕蜻\行Web服務器程序的服務器發(fā)送請求，并返回Web應用程序的內容。客戶端和服務器都只是連接到互聯網上的計算機。

1998年，五名麻省理工學院的學生觀察到了這一點，并有了一個簡單的想法：讓我們把這些文件分發(fā)到世界各地的許多數據中心，與電信供應商合作，使用他們的網絡。就這樣，所謂的內容分發(fā)網絡（CDN）的想法誕生了。

CDN不僅開始存儲圖像，還開始存儲視頻文件和任何你能想到的要儲存的數據。順便說一下，這些網點（PoPs）就是邊緣。它們是分布在世界各地的服務器——有時這些成百上千服務器的所有目的就是存儲那些常被訪問的數據的副本。因為CDN最初的重點就只是提供正常的基礎設施，而且目標也“只是讓它正常運轉起來”，所以這么多年來，它其實一直很難使用。

2014年，一場關于CDN的開發(fā)者經驗（DX）革命開始了。網站文件和CDN文件被直接打包捆綁在一起使用，于是，人們就不再需要手動上傳網站文件，然后再用CDN進行鏈接這么麻煩了。用CDN連接起來，這兩個部分被打包在一起。自動部署化工具像surge.sh，Netlify，Vercel（如今叫fka Now）誕生了。

到目前為止，通過CDN分發(fā)靜態(tài)網站已經成為一個絕對的行業(yè)標準。所以我們現在將靜態(tài)資產移到了邊緣。但是關于計算呢？還有那些存儲在數據庫中的動態(tài)數據呢？我們是否可以通過把它放在離用戶更接近的地方來降低延遲呢？如果可以，那我們該怎么做呢？

歡迎來到邊緣

讓我們來看看邊緣的兩個優(yōu)勢：

①計算

②數據

在這兩個領域，我們都看到發(fā)生了難以置信的創(chuàng)新，這將完全改變未來應用程序的工作方式。

計算

如果一個傳入的HTTP請求不需要一直輸送到遠處的數據中心，會怎么樣？如果可以直接在用戶旁邊提供呢？歡迎來到邊緣計算。

如果我們把數據從一個集中式數據中心轉移到許多分散的數據中心，我們就越需要處理一套新的權衡決策體系。在邊緣，你無需使用“豪華”的配置，無需為你的應用程序增配一臺擁有數百GB內存的強大機器。試想一下，你的應用程序能夠在500個邊緣位置上部署，而所有這些位置都靠近您的用戶。而如果在您的用戶的身邊分別買500臺強大的機器很明顯根本不經濟。

因為成本實在太高昂。我們當然要選擇的是，一個更小的、更簡單的配置方案。

一個能夠很好地適配這些約束的架構模式是無服務器模式。您無需自己購置托管主機，只需寫一個函數，然后當需要的時候，智能系統(tǒng)就會自動執(zhí)行。您不需要擔心單個服務器的抽象問題；您只需編寫運行基本上可以無限擴展的函數。

你應該能想到，這些函數應該是又小又快。我們怎樣才能實現這個目標呢？對于那些又快又小的函數來說，好的運行環(huán)境是什么呢？目前，業(yè)界有兩個普遍的答案：使用JavaScript V8 isolates或使用WebAssembly (WASM)。

JavaScript V8 isolate，在一家叫Cloudflare的美國公司較為普遍地使用。它允許您在邊緣運行一個完整的JavaScript引擎。2017年，當Cloudflare引入這一工作機制時，第一次為邊緣提供了這種新的簡化計算模型。

從那時起，包括Stackpath、Fastly和我們優(yōu)秀的Akamai，也發(fā)布了他們的邊緣計算平臺——一場新的革命開始了。相較于V8 JavaScript 引擎，另一種能夠完美適配邊緣的計算模型WebAssembly。

WebAssembly于2017年首次面世，如今正在高速增長；像Mozilla、亞馬遜云科技、ARM、谷歌這些大公司都在大量使用，還有微軟和英特爾都在大量投資。WebAssembly允許您用任何語言編寫代碼，并將其編譯成一個可移植的二進制文件。無論是在瀏覽器中，還是在各種服務器環(huán)境中，它都能夠在任何地方運行。

WebAssembly毫無疑問是過去20年來Web最重要的發(fā)展之一。它已經在瀏覽器中驅動了國際象棋引擎和設計工具，在區(qū)塊鏈上運行，并很可能取代Docker。

數據

雖然我們已經有了一些邊緣計算產品，但邊緣革命的最大阻礙是如何把數據帶到邊緣。如果你的數據存儲在一個遙遠的數據中心，即便把你的電腦移到用戶身邊，你也毫無所得——因為那些“遙遠”的數據仍是瓶頸。為了實現邊緣的主要承諾和提升用戶速度，你也無法同時找到數據分發(fā)的解決方案。

你可能會想，“我們就不能把地球上的數據通通復制到我們的500個數據中心，并時刻保持最新狀態(tài)？”雖然在世界各地都有一些新的方法復制數據，比如Litestream，最近加入了fly.io。

不幸的是，這并不是那么容易的。假設您有100TB的數據需要在多臺機器的分片集群中運行，那么將這些數據復制500次根本不劃算。我們真正需要的方法是既能夠存儲“成噸”的數據，同時還能將其帶到邊緣。

換句話說，在資源受限的情況下，我們如何智能的、高效地分發(fā)數據，使得我們在邊緣仍能快速地獲取這些數據？囿于資源有限，業(yè)內正在使用兩種方法（并且已使用了幾十年）：切片和緩存。

是否要切片

切片會根據特定條件將數據分割為多個數據集。例如，選擇用戶的國家/地區(qū)作為分割數據的一種方式，這樣就可以把數據存儲在不同的地理位置。

實現一個適用于所有應用程序的通用切片框架是相當具有挑戰(zhàn)性的。過去幾年來，在這一領域涌現出許多研究。例如，Facebook提出了他們的切片框架，稱為碎片管理器，但即使這樣，它也只能在某些特定條件下工作，還需要許多研究人員來運行它。我們仍然將在這個領域看到很多創(chuàng)新，但這并不是將數據帶到邊緣的唯一解決方案。

緩存才是王道

另一種方法是緩存。如果不能將所有的100TB數據庫都存儲在邊緣，那就設置一個上限，例如，設置1GB的限制，并且只存儲那些訪問次數最多、頻繁被訪問的數據。在計算機科學中，只保留最普遍的數據很容易被理解，LRU（最近最少使用）算法就是其中最著名的解決方案之一。

你可能會問，“為什么我們不使用LRU來緩存邊緣的數據，然后結束工作呢？”沒那么快。我們希望這些數據正確無誤、最新的：最終，數據還要保持一致性。但，等等，在數據一致性方面，緩存都有一系列的優(yōu)勢：從“最弱一致性”或“最終一致性”一直到“強一致性”。在兩者之間也分了許多層級，例如，“讀取我自己輸入的數據的一致性?！?/p>

邊緣是一個分布式系統(tǒng)。而在處理分布式系統(tǒng)中的數據時，CAP定理適用。這意味著，如果你希望自己的數據具有很強的一致性，你要做出權衡。換句話說，當寫入新數據時，你永遠不想再看到之前的舊數據。

要想要在全局設置中保持如此高的一致性，只有在分布式系統(tǒng)的各部分之間就剛剛發(fā)送的數據信息達成共識，或者至少有一次達成共識。這意味著如果您使用全局分布式數據庫，它至少仍需把消息發(fā)送到世界各地的所有其他數據中心一次，這就不可避免地引入了延遲。即使是像FaunaDB這樣出色的新SQL數據庫，也無法避免這樣的延遲。

老實說，這里沒有免費的午餐：如果你想要高一致性，你就得接受這一點，包括一定的延遲費用。現在你也許會問，“但是我們總是需要強一致性嗎？”答案是：看情況。許多應用程序的功能并不需要具有很高的一致性。比如，其中有一個你可能聽說過的小體量的網上商店：亞馬遜。

亞馬遜云科技創(chuàng)建了一個名為DynamoDB的數據庫，它是一個可擴展的分布式系統(tǒng)運行，然而，卻不總是完全一致的。正如DynamoDb說他們不保證高一致性那樣，亞馬遜云科技使用了很多巧妙的方法，“盡可能更多地保持一致性”。

我相信，所有這一代的應用程序都將能夠達到最終很好的一致性。實際上，您可能已經想到了一些用例：社交媒體的推送有時會有點過時，但它通常速度非?？旌涂捎玫摹Ｔ诓┛秃蛨蠹埳?，發(fā)表文章只有幾毫秒甚至幾秒的延遲。正如你看到的，有很多情況下最終的一致性是可以接受的。

如果我們假設都接受最終的一致性：我們會從中得到什么？這個意思就是，我們不需要等到大家都接受變化了再這樣做。因為如果我們現在就接受改變，那么在全局分布數據時，延遲費用就不復存在了。

然而，最終要達到“良好”的一致性也并不容易。因為，還要處理一個叫做“緩存失效”的小問題。當底層數據發(fā)生變化時，緩存也需相應進行更新。是的，你猜對了：這是一個極其困難的問題。它的困難程度讓它已成為計算機科學界的一個玩笑梗。

為什么這件事這么難？因為，不僅要跟蹤緩存的所有數據，還需要在基礎數據源更改后正確地使其失效或進行更新。有時甚至出現根本無法控制該底層數據源的問題。例如，試想使用像Stripe API這樣的外部API。

這時，需要構建一個定制解決方案來使該數據無效。簡而言之，這就是為什么我們要建立Stellate的原因，這樣這個棘手的問題才能變得更易接受，甚至可以通過為開發(fā)人員配備正確的工具來進行解決。如果GraphQL（一種強類型的API協議和模式）不存在的話，我可以坦率地說：我們就不會創(chuàng)建這家公司。只有在強約束下，這個問題才能著手解決。

我相信，碎片還有緩存都要更多地去適應這些新需求，沒有一家公司能夠“解決數據問題”，我們需要整個行業(yè)都為此努力。關于這個話題還有太多話要說，但現在，我覺得這個領域前景光明。對未來即將發(fā)生的事，我感到興奮。

未來：它在這里，就是現在

伴隨著所有的技術進步和技術瓶頸，讓我們來展望未來。但如果不提到凱文·凱利，那未免顯得過于無禮。

與此同時，我承認，我們不可能精準地預測技術革命的未來走勢，也無從得知哪些具體的產品或公司將會在未來25年成為領軍人物。甚至，可能會有一家全新的公司，在邊緣云領域異軍突起。然而，有一些趨勢是可以預測到的，因為它們已經在發(fā)生了。

凱文·凱利在2016年出版了《不可避免》一書。在書中，他討論了十二種將會塑造未來的科技勢力。正如書名說的那樣，這些都是在未來必定會發(fā)生的，以下摘取了其中八種：

認知：對事物的認知，也就是讓事物更智能化。要實現這一點，需要直接在需要計算的地方提供越來越多的算力。例如，讓自動駕駛汽車在云端去進行道路分類就不太實際，對吧？

流動：我們將有越來越多的實時信息流，人們對這些實時信息流十分依賴。延遲的問題在這就顯得至關重要的：讓我們想象一下，如果要控制一個機器人來完成一項任務。如果非必需，你應該不會想把控制信號跨越半個地球傳送過去吧？然而，對于，持續(xù)不斷的信息流、聊天應用程序、實時儀表板或在線游戲來說，不能有延遲是至關重要的，因此，我們需要使用邊緣。

屏讀：我們生活中越來越多的東西會有屏幕。從智能手表到冰箱，甚至是你的電子秤。于是就這樣，這些設備通常會頻繁地接入互聯網，形成了新一代的邊緣。

分享：在未來，大規(guī)模合作會不可避免地增長。想象一下，你和一個同城的朋友共同編輯同一份文件。為什么要把所有這些數據都寄回到地球另一邊的數據中心呢？為什么不把文檔就地儲在你倆的身邊？

過濾：我們將利用很強的個性化來預測我們的欲望。這實際上可能是邊緣計算的最大驅動因素之一。由于個性化是針對個人或團隊的，所以這是在他們旁邊運行邊緣計算的完美用例。使用邊緣能夠加快速度，而節(jié)約的毫秒相當于利潤。我們不僅已經在社交網絡中看到了個性化的身影，也在電子商務中看到了其更多地運用。

互動：通過越來越多地沉浸在電腦中，人們可以更多地與他人保持連接。而這種沉浸感將不可避免地被個性化，并直接或在用戶的設備很近的地方運行。

跟蹤：不可避免地，我們會被更多地跟蹤著。所有事物上都會裝有更多傳感器，他們都會收集到海量的數據。但這些數據并不能總是被傳輸到中央數據中心。因此，現實世界中的應用程序需要快速地做出實時決策。

開始：很諷刺的是，最后但同樣重要的是，這是“開始”的因素。過去的25年是一個至關重要的平臺期。然而，不要指望我們初窺的那些趨勢。讓我們去擁抱它們，這樣我們就能創(chuàng)造出最大的利益。這不僅是為了我們這些開發(fā)者，也是為了整個人類。

我預測在未來的25年里，如今的“胡說八道”都將會變成現實。這就是為什么說邊緣正在“吞噬”這個世界。正如我之前提到的，我們程序員面臨的問題不是某個公司的利益問題，而是需要整個行業(yè)的幫助。

蒂姆·蘇查內克，Stellate公司首席技術官。

編譯：邊緣計算社區(qū)@Julian

原文鏈接：

https://venturebeat.com/data-infrastructure/why-edge-is-eating-the-world/

全球邊緣計算大會深圳站圓滿落幕，上圖鏈接是視頻回放及PPT下載鏈接，謝謝您對邊緣計算社區(qū)的支持，歡迎參加全球邊緣計算大會·上海站！文章來源地址http://www.zghlxwxcb.cn/news/detail-797194.html