歷史技術棧體系即將崩潰,我們如何應對?

VoltDB_China發表於2021-03-11

01 前言

當大家都在談論5G和邊緣計算,這意味著新的技術變革即將到來,我們的技術演進迭代也將發生重大變化。簡單來說:

  • 我們對延遲的需求正在逼近物理極限,並且很快就會受到光在光纖電纜傳播速度的物理限制。
  • “終端使用者”曾經是指數千萬的人口,但在不久的將來,數百億的物聯網裝置將取代人類使用者,這些物聯網裝置的連線和資料處理是迫在眉睫的現實需求。
  • 在不造成中斷的情況下,完成系統部署升級也是非常現實的問題。

當延遲的需求達到需要以光速或接近光速的速度執行時,此前可行的簡單處理方式都將失效,將倒逼我們採用更先進的架構和方案。
對5G和邊緣計算的巨大增長需求,使我們走到了技術發展的分水嶺:一方面是舊有的面臨淘汰的技術棧。另一方面是安全和廣闊的新世界。
但是,您需要採用正確的技術方案才能達到目標。

02 為什麼舊有的技術棧即將崩潰?

隨著資料和裝置的爆炸式增長,同時現實又要求這些裝置之間的互動提供更低的延遲,並對各種資料做出實時決策響應。當同時涉及到大資料、低延遲、實時狀態更新需求時,三個因素將迅速讓現有的技術棧崩潰。

2.1物理極限

5G和邊緣計算有望實現連線全球數百億的智慧裝置,並實現遠端控制和智慧編排。5G行動網路提供1-2毫秒的延遲,這比普通的4G網路快23毫秒,但這也向現有的技術棧提出了一個非常棘手的問題:它可以打破物理極限嗎?
藉助5G和邊緣計算,我們到達了一個新場景,當新增更多或者更快的裝置並不能解決問題,並且不再可能遷移到“更快的網路”。下圖說明了這一點,光在WAN網路中的傳播速度每毫秒約120英里(約200公里),將4G的最低延遲時間所需的最大距離與5G的最大無延遲時間距離進行比較,比真空中的速度慢30%。
圖片

理論最大傳輸距離對比:5G VS. 4G
網路技術受到光速的限制,光速在真空中一毫秒內可以傳播181英里,而在光纖中只能在一毫秒內傳播約54英里。這意味著1毫秒的延遲,5G網路理論上最多隻能在54英里以內的裝置間通訊。

當下的網路技術、客戶端-伺服器計算所處的位置、客戶端和伺服器之間的距離導致了各種延遲的增加。
光在10毫秒內移動了1,810英里,這意味著任何需要在10毫秒或更短時間內發生的客戶端-伺服器通訊,其裝置的物理距離都不得超過1,810英里。實際的光纖電纜傳送資料的速度,比光速還要慢30%,也就是WAN中,資料傳輸10毫秒大約才走500英里。
當然,可以透過新技術、例如在專用光纖電纜上追加投資等方式,可以加快網路速度,但是不可能超越光纖電纜的能力,更不用說接近光速了。
5G有望最終產生1毫秒的往返延遲,滿足這麼低延遲的唯一方法是雙方(傳送方-接收方或者客戶端-伺服器)彼此之間相距幾英里,並進行簡短的資訊交換。
沒有物理學上的突破,就沒有技術上的突破。

2.2
數字孿生的激增

數字孿生是虛擬的數字對映,通常由以下元素組成:

  1. 物理裝置上的各種訊號接入後,可以實現遠端控制
  2. 各種線上裝置系統的數字對映關係
  3. 裝置間的可靠資料傳輸可以代表裝置的當前狀態

一旦這三個要素到位,不僅雲端計算應用將變得可行,還可以控制便宜且簡單的裝置,透過使用雲來讓大量的數字孿生裝置一起協同工作,完成同一目標。
到目前為止,許多裝置與網際網路的互動是可選的,或者不必要,而且通常無法控制其核心功能。但是5G和邊緣技術已經可以促使成百上千億的數字孿生,每天都在滿足我們賴以生存的生活需求,而這一切都取決於他們自己在網路中某個地方進行可靠的超低延遲決策。大量的裝置不停的被用到,然而過往的裝置操作過程是“先關閉然後再開啟”,這種方式已經不能滿足我們管理無數裝置的期許了。
延遲還意味著裝置依賴快速連線來完成預期工作,因此未能滿足SLA的情況與裝置中斷區別不大,如果裝置是根據過期的資訊來決策或者執行操作,可能會帶來更為糟糕的後果。
2.3計劃內停機
計劃內的停機時間將為5G和邊緣應用帶來嚴重後果。通常來說,5G的裝置需要實時聯網才能工作,停機意味著重大事故。
這有幾個含義:
1.採用開源元件的複雜技術棧可能無法勝任工作。如果堆疊中的每一層都有其自己的獨立補丁,當補丁達到一定複雜程度或者數量時,停機更新可能是不可避免的。但如果不打補丁,也可能會帶來潛在的法律或者安全問題。當停機更新的時間每分鐘需要花費數千美元時,減少技術棧元件數量或許非常必要。
2.為軟體打補丁和維護相對比較容易,但為韌體打補丁則非常麻煩,所以儘可能不要韌體或者硬體程式碼來完成軟體棧的功能,而是從終端裝置完成韌體的更新與維護。
3.敏捷開發可能並不適用於與數十億數字孿生裝置一起工作,伴隨每個小版本更新可能隨之帶來各種錯誤,從而導致裝置中斷,甚至更嚴重的後果。

03 新常態的不便之處

我們面臨的根本問題是,由於5G場景對於延遲的需求,很大程度上是由於技術元件棧太深,而導致了額外的延遲,從而浪費了真正的有效資料處理時間。
請記住:5G和邊緣計算不會在真空中發生,也不會慢慢發生。5G和邊緣計算的實施意味著裝置和使用者會話的數量將迅速飆升。當前5G規範,聯網裝置的密度約為每平方公里100萬臺。
其中許多裝置將是執行在SLA保障較高的數字孿生場景,需要不斷與遠端計算能力保持聯機通訊,並實時做出決策。
聯網裝置的爆炸式增長與對延遲和連線性的期望將同時發生。
圖片

延遲預期 VS. 連線裝置數
隨著時間的流逝,我們使用的裝置數量激增,現在已經超過了人類總量。但是裝置不像人類,它期望以毫秒為單位的實時決策響應。

在以前,“我們希望更快”就可以了。而現在,“我們在4毫秒內得到響應”很可能是SLA的需求。
如果我們認可5G和邊緣計算對於低延遲需求的價值,那麼我們也必須接受對當前的技術和架構的挑戰。

04 如何避免技術堆疊的責任

當接近延遲要求的拐點,到達物理極限時,我們需要對管理資料和執行技術棧的方式進行革新,每項革新都會帶來不同的挑戰和開放式的方案。
他們是:
1.邊緣處理
儘管我們仍將在資料中心計算上進行大量投資,但由於新應用程式對低延遲的要求很高,因此,在邊緣端執行大量對延遲敏感的功能是很有必要的。從技術和業務角度來看,邊緣處理意味著更加複雜的部署架構。
2.更簡單的技術元件棧
在5G和邊緣計算之前,業務問題通常透過建立包含多個元件的分層架構來解決架構間的解耦問題。但是,每一層都會增加延遲,在5G世界中,需要節省與邊緣裝置間的通訊延遲,而不是在軟體元件邏輯層之間的額外通訊上浪費時間。現實是,只有推動架構向前發展,使用更少的技術元件棧,將資料流、流處理和事務狀態管理合併在一起,才能從根本上解決這個問題。
3.“ 啞巴”裝置
早期的IoT專案涉及向裝置新增感測器,以便它們可以傳送資料到伺服器端,在遠端完成資料分析。這些早期架構中,裝置會使用有限的本地計算能力來執行部分核心功能。
而5G和邊緣應用的連線無處不在,沒有理由在每臺終端裝置上保留強大的處理能力。這樣做會增加裝置成本,而且也會造成無休止的裝置端補丁更新噩夢。
邊緣計算,邏輯上就有可能發生從裝置中刪除儘可能多的智慧處理單元。

05 下一步:您需要評估的五個需求問題

5G不僅僅是營銷術語,還是用稍好的硬體代替一般硬體的藉口。但真正需要改變的是我們做事的方式。
從以下五個問題來評估您的應用場景是否適合5G:

  1. 它適用於OLTP嗎?如果是,它是否可以在單位延遲時內從大規模資料中做出準確的決策?
  2. 它可以在架構上最小化資料在網路中傳輸的次數嗎?
  3. 它是否足夠簡單且垂直整合,從而以高可用的方式用最少的時間來處理資料?
  4. 它是否用於IoT或流訊息?如果是,它是否具與Kafka,Kinesis等訊息中介軟體的入站和出站連線,方便整合多個資料流?
  5. 如果您的下一代5G應用依賴開源技術,您是否真正考慮過停機和故障的後果?

如果您對以上任何一個問題的回答都是“否”,那麼您很可能將面臨技術堆疊導致應用崩潰的境地,應該尋求有專業支援的整合解決方案來主動避免這場災難。

06 VOLTDB如何滿足5G的需求?

隨著我們步入5G和邊緣計算場景,您必須接受這樣一個事實,現有的軟體堆疊或開發技術可能很快就會過時。在技術領域,情況一直如此:昨天可以穩定工作的平臺軟體今天會失效,明天更可能會面臨系統崩潰。
低延遲需求將大多數技術堆疊的功能擴充套件到其極限,許多公司都會試圖找到最便宜或開發效率最快的方法。但他們不會從整體上或者根本上進行架構思考,而是從拼圖和創可貼的角度開展工作,從而導致更大的後果。
沒錯:5G和邊緣計算就在這裡,並正在取代資料世界的執行方式。
如果您正在尋找可以在毫秒延遲內實現高可用性、可擴充套件性和實時決策的平臺,請立即透過  與我們聯絡,來聊聊我們如何提供幫助。


如果您希望整合VoltDB到您的技術棧中,或者想和更多小夥伴一起交流
請私信與我們聯絡。

關於VoltDB
VoltDB支援強ACID和實時智慧決策的應用程式,以實現互聯世界。沒有其它資料庫產品可以像VoltDB這樣,可以同時需要低延時、大規模、高併發數和準確性相結合的應用程式加油。
VoltDB由2014年圖靈獎獲得者Mike Stonebraker博士建立,他對關聯式資料庫進行了重新設計,以應對當今不斷增長的實時操作和機器學習挑戰。Stonebraker博士對資料庫技術研究已有40多年,在快速資料,流資料和記憶體資料庫方面帶來了眾多創新理念。
在VoltDB的研發過程中,他意識到了利用記憶體事務資料庫技術挖掘流資料的全部潛力,不但可以滿足處理資料的延遲和併發需求,還能提供實時分析和決策。VoltDB是業界可信賴的名稱,在諾基亞、金融時報、三菱電機、HPE、巴克萊、華為等領先組織合作有實際場景落地案例。

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69903219/viewspace-2762261/,如需轉載,請註明出處,否則將追究法律責任。

相關文章