可程式設計的流式計算框架：YoMo

音影片領域的新技術應用非常多，但是在工業和IoT領域，新技術的應用卻鮮有耳聞。本次LiveVideoStackCon 2021 上海站大會我們邀請到了熹樂科技YoMo框架負責人——洪小堅，為我們分享熹樂科技和YoMo會為工業和IoT帶來哪些新鮮血液。

文 / 洪小堅

整理 / LiveVideoStack

大家好，今天分享的主題是可程式設計的流式計算框架。大家可能都比較關心音影片領域，我們YoMo面對的場景比較偏向工業、IoT等領域。雖然是不同的場景，但是仍然有很多技術的共同點。大家聽完以後會有不少收穫。

今天的大綱分為自我介紹、YoMo專案背景、YoMo典型用例、YoMo技術亮點、對邊緣計算的理解以及總結。

關於我和熹樂科技

首先做一個自我介紹。

我是從2007年開始做技術研發，做了12年歐洲使用者的電商平臺。因為對邊緣計算和工業網際網路都很感興趣，所以2019年加入了現在的創業公司——熹樂科技。目前我正在維護今天的主角——YoMo專案。

熹樂科技很多朋友都是第一次聽到，下面做一個簡單的介紹。熹樂科技專注於工業網際網路和邊緣計算，打造了YoMo開源計算框架和YCloud雲服務。我們從2015年開始將人工智慧技術應用於工業製造領域，例如計算機視覺對於地板的質量檢測。熹樂科技目前持續服務了40餘家工業企業。在2019年與“中國輕工集團”共同成立了“中輕工網際網路有限公司”，主要是將邊緣計算等工業網際網路技術在輕工行業落地。

YoMo專案背景

下面介紹YoMo的專案背景以及設計的原理。

首先要介紹的是開放性。隨著網路的基本設施，例如5G的普及，想要實現低時延看起來還是唾手可得的。5年以後，企業之間比拼的可能就是QUIC協議這種具有開放性的、基於User Space的可以作一些靈活擁塞控制的演算法。未來的軟硬體可能都是可程式設計的、開放性的。

回過頭看看目前業內一些主流的技術，說到實時流式計算就會聯想到像Flink這種、訊息佇列會想到Kafka。甚至我們微服務部署很多人會想到Docker，但這些技術其實都是幾年前開始設計的，都屬於消費者網際網路。未來會進入IoT的時代，之前的技術雖然現在還是主流，但是不一定會適合未來。我們在做產品的時候就想透過新的技術，來創造一些新的機會。

近幾年新聞報道了很多工業的事故，造成了巨大的人員傷亡和經濟損失。加之現在國家政策一直在鼓勵安全生產，所以我們的客戶就想做安全生產，例如數字化檢測和預警系統等。“中輕工網際網路”去年就服務了一家化工企業。

安全生產的最高等級就是實現本質安全的理論。本質安全就是不論是裝置故障還是人為操作不當，都可以提前預測事故的發生。要做到本質安全，就需要做到計算連續3s的資料變化趨勢。同時AI演算法會對不久將來可能發生的事故做出反應。例如未來30s後可能會爆炸，這時就需要提前向化學反應堆里加阻燃劑。要做到這樣的操作，還需要在1s內做到30次的計算，一次大約為33ms。如果這個計算節點部署在雲計算中心，那麼光資料的傳輸可能就已經超過該時限了。上面提到的33ms不僅僅包括資料傳輸，還要包括AI計算的時間。因此想要做到本質安全，就需要對感測器的資料進行實時的採集和計算。

要做到實時採集就需要低時延的傳輸，一是利用類似QUIC的協議，二是隨著5G、WiFi6的普及，對保障低時延傳輸有很大的幫助。另外，我們需要對採集到資料進行毫秒級的計算，這就需要在邊緣端部署才能實現。如果部署在雲端，即便計算速度很快，但因為傳輸速度的不足也會導致毫秒級計算無法實現。除了以上兩點，還需要在邊緣端部署一個Edge AI進行全維度的計算來實現預緊預測。

根據現在的趨勢，將來實時計算比例會越來越高，IDC預測2025年實時資料計算將會佔比30%。

這是目前IoT領域的一些主流協議。TCP是1983年誕生，距離現在已經快40年。另一個主流的MQTT協議也已經誕生20多年。隨著5G的普及，這些老舊技術就像在動車鐵軌上跑的綠皮火車。Google在2012年就提出QUIC協議，在2016年進行 IETF的國際標準化。但是因為極大的升級成本，所以目前在工業領域目前用QUIC的並不是很多，但是在音影片領域國內外用應用的卻很多。熹樂的目標就是將QUIC技術方便的應用到工業領域。

我們提出gRPC for IoT的理念。gRPC是一個很主流的微服務RPC框架。gRPC for IoT就是希望在邊緣端可以實現全鏈路的QUIC Transport。例如Client/Server服務可以透過QUIC建連從而變成P2P的模式。傳統Client/Server的問題在於只有在Client請求以後Server才會響應，這種模式是單向的。而用QUIC建連之後，就是雙向連線Peer to Peer，同時又是長連結。為什麼是長連結？因為IoT裝置資料是24小時不間斷的，如果每次請求都斷開、重新建連會造成時延的影響。

另外我們針對IoT領域推出自研的Codec。熹樂科技在IoT領域很重視網路傳輸編解碼的效率方面。IoT資料的實時採集並透過長連結傳送的模式和影片直播是很相像的。

IoT的裝置到2025年將達到750億。這意味將有越來越多的裝置需要進行資料採集，由此產生的APP應用也會越來越多。

現在市場對APP的開發要求越來越快，time to market越快越好，現在很多低程式碼、無程式碼就是為了縮短開發時間。YoMo框架十分重視開發者友好，以便開發者使用時可以節省時間。

為了節省開發時間我們提出了Streaming Serverless的概念。Serverless的優勢在於只需要專注幾行核心程式碼、無需關心 DevOps、自動彈性伸縮，以及按需計費，低成本。IoT領域的資料是24小時不間斷產生的、沒有邊界，是典型的streaming場景，雖然現在已經有很多比較成熟的Serverless框架，但市面上大多數 Serverless 框架是面向傳統的HTTP Request/Response 模式。因此我們針對該場景提出了Streaming Serverless。

這是一條比較有意思的推特。這個推特是Docker的創始人在2019年提出來的，他在推特中提到，如果2008年出現WebAssembly，那麼他們都沒有必要去建立Docker了。WebAssembly之前跑在瀏覽器端比較多，現在的趨勢卻是跑在服務端。

WebAssembly和Docker相比具有哪些優勢呢？WebAssembly的Cold Start會比Docker快100倍。其次前者執行時間較後者也快10%-50%。另外WebAssembly 佔用的空間更小。最後WebAssembly有更靈活的安全策略，可以根據不同模組，在例項化時指定不同許可權。

因為在邊緣節點資源會比較受限，所以WebAssembly綜合了輕量級、更優的效能、更高的安全性和多語言的特點。多語言對於Serverless尤其重要，因為現在很多主流的開發語言都支援把程式編譯成WebAssembly，具有這樣的特點會有很多的好處。

綜合上述的方方面面，我們做了YoMo開源框架。

YoMo應用案例

再來分享幾個典型的案例。

我們在辦公室部署了一個實時噪聲感測器，來測試YoMo框架是否能達到低時延。因為MQTT協議需要安裝MQTT Broker，所以我們在資料採集端做了一個MQTT相容的API，這樣可以減少使用者的負擔，無需安裝 MQTT Broker 即可接入 YoMo。為了測試實驗，我們將Serverless的節點部署在寧夏的AWS，來測量北京到寧夏，再從寧夏返回北京的時延。我們的測試結果顯示時延基本能穩定在30ms以內。另外像螢幕上顯示的分貝值，傳統的做法是把感測器資料先儲存到資料庫，然後再進行查詢顯示，這樣就會造成時延的損失，所以YoMo採取透過WebSocket直接顯示到螢幕上。同時用另外一個 Serverless服務把資料落地到 DB。

白酒智慧釀造平臺是一個工業級的應用。白酒行業的一大特點是很多釀酒工藝是透過老師傅的經驗傳授，這樣是非常主觀的。我們在和一個研究白酒幾十年的專業研究院——中國食品發酵工業研究院合作後，獲得了他們提供的硬體和相關的工業演算法。接著我們對這些裝置進行了實時的工藝採集和計算，把老師傅的經驗數字化，從而獲得穩定的工藝，提高了出酒率和效率。

海外有一個使用者想做使用者行為的跟蹤，分析一些網站上使用者什麼樣的行為會導致轉換率的降低等問題。針對這樣的場景，我們做了Geo-Distributed的分散式解決方案，將傳統的中心化架構拆分成多個靠近使用者的邊緣節點。

最後一個案例是分散式的爬蟲。我們服務了一個海外提供物流查詢的SaaS公司。之前這個公司的查詢都是透過 proxy去獲取，這樣會造成很高的時延，同時穩定性也不高，更加嚴重的是資料隱私可能洩露。透過YoMo框架，我們在更靠近快遞公司的節點部署了一個爬蟲服務，透過QUIC協議，把請求透過長連線返回給美國的使用者。這些伺服器都是部署在使用者自己的機器上，資料隱私得以保障，也節省了proxy代理的開支。

YoMo features

透過之前的講座，在座的嘉賓多少對QUIC協議有一定的瞭解，這些內容就快速透過。

QUIC優點是非常多的。最好的就是最下面的兩點。一個是User space，我在開頭開放性那裡也提到過User space，可以更方便的進行軟體升級。TCP核心態的升級就沒有那麼方便。二是擁塞控制演算法。根據不同的場景進行靈活的控制，具有更高的可程式設計性。

QUIC在業內的應用實踐音影片方面比較多。國內很多的大廠在兩三年前就開始研究音影片方面的應用。QUIC對效能的提升幫助很大，包括卡頓率等等。因為看好QUIC 的前景，加之工業領域應用很少，所以我們想推動QUIC在工業、IoT領域的運用。

這裡影片借用了阿里手機淘寶的影片，左邊採用多通道的QUIC，右邊沒有采用。如果WiFi出現抖動的，左邊可以透過蜂窩網路流暢執行，而右邊只用到 WiFi 就出現卡頓的情況。

自研的 Y3 Codec我們稱它為faster than real-time。如果是傳統的JSON的話，就需要拿到完整資料以後進行解碼。針對IoT，例如之前提到的噪聲，只要獲取噪聲分貝的欄位即可。對此，我們使用了TLV的結構。結構裡的Tag相當於 JSON的key。透過監聽Tag是不是使用者關心的，如果是就直接獲取，不是則skip，再根據Length判斷需要skip多少位元組。

效能測試中Y3 Codec相比JSON提升超10倍以上，與Protobuf相比也有明顯的提升。下表所展示的是一些效能報告。

響應式的程式設計用excel的應用來形象的說明。假設a=b+c，那麼對b、c進行修改a也會有動態的響應，這種模式是十分適合資料隨著時間變化的場景。

ReactiveX也針對非同步資料提供了一個良好的程式設計模型。ReactiveX最早是由微軟提出。在操作非同步資料時可以使用一些通用的方法，就會像操作同步資料一樣方便，只要組合幾個常用的函式就可以操作非同步資料流。

假設每30ms都會傳遞一次資料，可實際場景可能是連續兩個30ms都沒有資料，第三個30ms突然出現三個資料。針對這種場景我們實際只要獲取最新的資料即可。使用 Rx 可以簡化這個問題，使用 debounce 即可獲取每 30ms 內的最新一條資料。

Streaming Serverless讓使用者不需要操作QUIC Stream，只需要操作Rx Stream。可以根據業務需求進行Operator方法的組合即可。另外市面上很多Serverless服務在本地除錯比較麻煩，所以YoMo支援CLI的方式本地執行和除錯。

邊緣計算

邊緣計算各位多多少少也有一定了解

整個行業的趨勢是從之前的大型機透過終端連線變成PC端去中心化場景。發展到移動互聯時代又回到了中心化的雲計算中心。到IoT時代因為資料量的巨大，需要邊緣端進行分散式來緩解雲計算中心的壓力。邊緣計算雖然越來越重要，但是邊緣計算並不會取代雲計算，他們會共同存在。

邊緣計算的優勢一是降低傳輸距離。二是就近計算更快的響應。第三，比較重要，邊緣計算可以保護安全隱私。很多工業企業並不是很願意把資料傳輸到公有云服務上，所以隱私保護顯得格外重要。最後一點就是低成本。邊緣計算可以減少頻寬傳遞的成本。

雲計算和邊緣計算的對比發現，雲計算的效能更強但時延、頻寬成本較高，邊緣計算恰恰相反。雲計算和邊緣計算在使用上互補，以滿足不同場景的使用需求。

對此我們做了Geo-Distributed Edge Cloud。使用者可以根據時延需求來部署在不同的地方。低時延可以部署在城市級節點。如果有資料監管要求則可以部署在私有云。另外部署在雲計算中心也是可以實現的。

總結

最後對今天的彙報進行一個總結。

YoMo的專案背景是面向未來可程式設計的開放性。針對網路傳輸提出gRPC for IoT——全鏈路採用QUIC以及Y3 Codec 高效能編解碼。另外為了加快使用者開發APP的速度，提出了Streaming Serverless的框架。針對YoMo的使用場景，執行在WebAssembly會比Docker更加具有優勢。最後邊緣計算方面YoMo可以基於Geo-Distributed Cloud進行就近部署。