【2018.Q3】預測5G對移動互聯網基礎設施的影響

09-07

來自專欄互聯網在孫嘉龍低維認知中的投影6 人贊了文章

TL;DR

5G的幾個主要特性，跟技術人員相關有：

由於之前無線網路本身是最主要瓶頸，所以可以猜測，換代到5G網路之後，這個最大的阻礙會被大大削弱，其他部分都是改造成本相對可控的，所以必然會一波新的應用場景是基於這種優勢的。

而這些殺手應用的出現又會反推全鏈路的所有環節的性能都要向5G的標準看齊。

什麼樣的應用能夠利用上面這些特性呢？

大量的物聯網設備接入估計是一類，但這類設備主要是因為無線接入成本更低了，對高帶寬和低延遲的需求感覺都不高。高帶寬應用一般都需要更高的能源供應，而各類感測器是否需要1ms級的網路也是個問題，畢竟感測器自己的延遲也很可觀。

單純的低延遲應用可能是有的，但在移動場景下似乎單純的低延遲用處不多，能想到的就是無人車了。能提前30ms告訴我轉角視野外正有車過來的信息就已經非常重要了，都無需把完整的環境信息傳過來。

類似的可能有工業用的高速設備，但如果是在廠房裡感覺還是有線比較靠譜吧……這方面的需求不太了解。

很多大眾應用之所以不需要低延遲是因為人的錄入信息和接受信息速度都是有限的，唯一的例外是VR、AR場景，延遲太高會嚴重降低體驗，這跟遊戲的需求是一樣的。但這類場景光靠低延遲是無法滿足的，往往還需要高帶寬。

接下來我們主要討論這類的應用：低延遲+高帶寬需求。

在下面正式開始之前，先說一下這個。

其實高鏈接數的問題互聯網的人之前已經研究過了，雖然還沒有完全成為顯學，但挖個人應該還是不難的。而且實在不行還可以砸點錢水平擴展。

由於5G只是解決了無線傳輸時的低延遲問題，基站到伺服器的時間還是很可觀，受地理距離影響，這個時間也有幾十ms。

解決的辦法只有拉近距離，能想到的有兩種：

1是霧計算（霧計算_百度百科），也就是在應用附近設立小型廉價的類雲計算節點，應用可以將計算部署在上面。但目前看來，這類節點和廣泛部署和公司的接受度都值得懷疑。

2是更廣泛的部署雲計算的機房，降低雲計算機房到所有主要大城市的網路延遲。

我覺得2相對更可行一些，只需要服務端進行改造。但廣泛的部署機房並非一般公司所能承受，所以預計後面覆蓋全國的低延遲機房可能會是雲計算服務廠商的撒手鐧。

能在地理局部閉環的應用可以相對簡單的做水平擴展，而那種跨長途距離的低延遲應用對於系統跨機房分散式的能力要求會更高，這同時是對雲計算廠商和應用開發公司而言的。雲計算廠商需要更好的跨機房資料庫方案，同時在如何降低機房間的延遲上也會面對很多工作。

不過在這之前，各公有雲廠商首先要面對的問題是如何提高自己服務的可靠性，以及如何能讓更多的大客戶信任自己不會偷數據。

更為複雜的問題恐怕是如何在一個機房內進一步降低延遲。

目前很多的互聯網應用對延遲的要求其實都不太高，整個業務總延遲一兩百ms並不是個事，拆到每個部門每個組件，部分組件浪費個1ms也沒有那麼痛。所以才能夠比較靈活的進行解耦，分解到各個部門各個服務上。

但在低延遲時代，這個方式行不通。在低延遲高帶寬的需求下，不能隨意的加深調用鏈路，這不光會導致延遲顯著增加，也會導致巨量的流量在機房網路中成倍增長。高性能的交換機也是很昂貴的。

先不說服務開發語言，首先，同一個請求涉及到的所有服務要盡量部署在一個物理機上這個就已經是不小的挑戰了：

由於越來越多的任務會跑到一個物理機器上，之前似乎沒那麼重要的序列化/反序列化開銷、日誌、監控開銷是否已經變得重要？探活一個服務實例的超時設置是否需要更加仔細思考？

有GC的語言能夠滿足新的需求么？我們是否需要一個GC時間更可控的方案，還是再切換到C/C++/Rust這類無GC的方案上？

新的業務場景是否對GPU這類加速硬體有更多的依賴？目前互聯網的大部分同學還尚不熟悉異構系統上開發的坑，我們是否需要新的開發解決方案？

我估計目前做視頻和直播的工程同學已經遇到了一些大流量和開銷的問題，但可能低延遲上的要求還沒有達到那麼高。

低延遲這個要求真的是破壞了互聯網工程之前的解耦假設，現在很多地方很多系統都還是人肉估計瓶頸，遇到問題人肉排查，把業務複雜度和性能問題糾纏到一起。

能達到我上面標準的，能充分解耦業務邏輯、性能優化、運維成本，但又不會導致太明顯的延時開銷的大一統方案我沒見到過，也沒聽說過。哪怕是從外部開起來技術很高大上的阿里，我也沒聽聞有在這個方向上下大力氣。

最後，這讓我想到了什麼呢？DL框架，很多問題分散式的DL訓練框架也會遇到，不過目前DL框架還沒有很好的解決這些問題，只是說做到了基本能用。

當然這裡的要更複雜的多，畢竟目前DL框架還沒有面對太複雜的業務邏輯需求。