音視頻領(lǐng)域的新技術(shù)應(yīng)用非常多，但是在工業(yè)和IoT領(lǐng)域，新技術(shù)的應(yīng)用卻鮮有耳聞。本次上海站大會(huì)我們邀請(qǐng)到了熹樂(lè)科技YoMo框架負(fù)責(zé)人——洪小堅(jiān)，為我們分享熹樂(lè)科技和YoMo會(huì)為工業(yè)和IoT帶來(lái)哪些新鮮血液。

大家好，今天分享的主題是可編程的流式計(jì)算框架。大家可能都比較關(guān)心音視頻領(lǐng)域，我們YoMo面對(duì)的場(chǎng)景比較偏向工業(yè)、IoT等領(lǐng)域。雖然是不同的場(chǎng)景，但是仍然有很多技術(shù)的共同點(diǎn)。大家聽(tīng)完以后會(huì)有不少收獲。

今天的大綱分為自我介紹、YoMo項(xiàng)目背景、YoMo典型用例、YoMo技術(shù)亮點(diǎn)、對(duì)邊緣計(jì)算的理解以及總結(jié)。

關(guān)于我和熹樂(lè)科技

01

首先做一個(gè)自我介紹。

我是從2007年開(kāi)始做技術(shù)研發(fā)，做了12年歐洲用戶的電商平臺(tái)。因?yàn)閷?duì)邊緣計(jì)算和工業(yè)互聯(lián)網(wǎng)都很感興趣，所以2019年加入了現(xiàn)在的創(chuàng)業(yè)公司——熹樂(lè)科技。目前我正在維護(hù)今天的主角——YoMo項(xiàng)目。

熹樂(lè)科技很多朋友都是第一次聽(tīng)到，下面做一個(gè)簡(jiǎn)單的介紹。熹樂(lè)科技專注于工業(yè)互聯(lián)網(wǎng)和邊緣計(jì)算，打造了YoMo開(kāi)源計(jì)算框架和YCloud云服務(wù)。我們從2015年開(kāi)始將人工智能技術(shù)應(yīng)用于工業(yè)制造領(lǐng)域，例如計(jì)算機(jī)視覺(jué)對(duì)于地板的質(zhì)量檢測(cè)。熹樂(lè)科技目前持續(xù)服務(wù)了40余家工業(yè)企業(yè)。在2019年與“中國(guó)輕工集團(tuán)”共同成立了“中輕工互聯(lián)網(wǎng)有限公司”，主要是將邊緣計(jì)算等工業(yè)互聯(lián)網(wǎng)技術(shù)在輕工行業(yè)落地。

YoMo項(xiàng)目背景

02

下面介紹YoMo的項(xiàng)目背景以及設(shè)計(jì)的原理。

首先要介紹的是開(kāi)放性。隨著網(wǎng)絡(luò)的基本設(shè)施，例如5G的普及，想要實(shí)現(xiàn)低時(shí)延看起來(lái)還是唾手可得的。5年以后，企業(yè)之間比拼的可能就是QUIC協(xié)議這種具有開(kāi)放性的、基于User Space的可以作一些靈活擁塞控制的算法。未來(lái)的軟硬件可能都是可編程的、開(kāi)放性的。

回過(guò)頭看看目前業(yè)內(nèi)一些主流的技術(shù)，說(shuō)到實(shí)時(shí)流式計(jì)算就會(huì)聯(lián)想到像Flink這種、消息隊(duì)列會(huì)想到Kafka。甚至我們微服務(wù)部署很多人會(huì)想到Docker，但這些技術(shù)其實(shí)都是幾年前開(kāi)始設(shè)計(jì)的，都屬于消費(fèi)者互聯(lián)網(wǎng)。未來(lái)會(huì)進(jìn)入IoT的時(shí)代，之前的技術(shù)雖然現(xiàn)在還是主流，但是不一定會(huì)適合未來(lái)。我們?cè)谧霎a(chǎn)品的時(shí)候就想通過(guò)新的技術(shù)，來(lái)創(chuàng)造一些新的機(jī)會(huì)。

近幾年新聞報(bào)道了很多工業(yè)的事故，造成了巨大的人員傷亡和經(jīng)濟(jì)損失。加之現(xiàn)在國(guó)家政策一直在鼓勵(lì)安全生產(chǎn)，所以我們的客戶就想做安全生產(chǎn)，例如數(shù)字化檢測(cè)和預(yù)警系統(tǒng)等?！爸休p工互聯(lián)網(wǎng)”去年就服務(wù)了一家化工企業(yè)。

安全生產(chǎn)的最高等級(jí)就是實(shí)現(xiàn)本質(zhì)安全的理論。本質(zhì)安全就是不論是設(shè)備故障還是人為操作不當(dāng)，都可以提前預(yù)測(cè)事故的發(fā)生。要做到本質(zhì)安全，就需要做到計(jì)算連續(xù)3s的數(shù)據(jù)變化趨勢(shì)。同時(shí)AI算法會(huì)對(duì)不久將來(lái)可能發(fā)生的事故做出反應(yīng)。例如未來(lái)30s后可能會(huì)爆炸，這時(shí)就需要提前向化學(xué)反應(yīng)堆里加阻燃劑。

要做到這樣的操作，還需要在1s內(nèi)做到30次的計(jì)算，一次大約為33ms。如果這個(gè)計(jì)算節(jié)點(diǎn)部署在云計(jì)算中心，那么光數(shù)據(jù)的傳輸可能就已經(jīng)超過(guò)該時(shí)限了。上面提到的33ms不僅僅包括數(shù)據(jù)傳輸，還要包括AI計(jì)算的時(shí)間。因此想要做到本質(zhì)安全，就需要對(duì)傳感器的數(shù)據(jù)進(jìn)行實(shí)時(shí)的采集和計(jì)算。

要做到實(shí)時(shí)采集就需要低時(shí)延的傳輸，一是利用類似QUIC的協(xié)議，二是隨著5G、WiFi6的普及，對(duì)保障低時(shí)延傳輸有很大的幫助。另外，我們需要對(duì)采集到數(shù)據(jù)進(jìn)行毫秒級(jí)的計(jì)算，這就需要在邊緣端部署才能實(shí)現(xiàn)。如果部署在云端，即便計(jì)算速度很快，但因?yàn)閭鬏斔俣鹊牟蛔阋矔?huì)導(dǎo)致毫秒級(jí)計(jì)算無(wú)法實(shí)現(xiàn)。除了以上兩點(diǎn)，還需要在邊緣端部署一個(gè)Edge AI進(jìn)行全維度的計(jì)算來(lái)實(shí)現(xiàn)預(yù)緊預(yù)測(cè)。

根據(jù)現(xiàn)在的趨勢(shì)，將來(lái)實(shí)時(shí)計(jì)算比例會(huì)越來(lái)越高，IDC預(yù)測(cè)2025年實(shí)時(shí)數(shù)據(jù)計(jì)算將會(huì)占比30%。

這是目前IoT領(lǐng)域的一些主流協(xié)議。TCP是1983年誕生，距離現(xiàn)在已經(jīng)快40年。另一個(gè)主流的MQTT協(xié)議也已經(jīng)誕生20多年。隨著5G的普及，這些老舊技術(shù)就像在動(dòng)車鐵軌上跑的綠皮火車。Google在2012年就提出QUIC協(xié)議，在2016年進(jìn)行 IETF的國(guó)際標(biāo)準(zhǔn)化。但是因?yàn)闃O大的升級(jí)成本，所以目前在工業(yè)領(lǐng)域目前用QUIC的并不是很多，但是在音視頻領(lǐng)域國(guó)內(nèi)外用應(yīng)用的卻很多。熹樂(lè)的目標(biāo)就是將QUIC技術(shù)方便的應(yīng)用到工業(yè)領(lǐng)域。

我們提出gRPC for IoT的理念。gRPC是一個(gè)很主流的微服務(wù)RPC框架。gRPC for IoT就是希望在邊緣端可以實(shí)現(xiàn)全鏈路的QUIC Transport。例如Client/Server服務(wù)可以通過(guò)QUIC建連從而變成P2P的模式。傳統(tǒng)Client/Server的問(wèn)題在于只有在Client請(qǐng)求以后Server才會(huì)響應(yīng)，這種模式是單向的。而用QUIC建連之后，就是雙向連接Peer to Peer，同時(shí)又是長(zhǎng)鏈接。為什么是長(zhǎng)鏈接？因?yàn)镮oT設(shè)備數(shù)據(jù)是24小時(shí)不間斷的，如果每次請(qǐng)求都斷開(kāi)、重新建連會(huì)造成時(shí)延的影響。

另外我們針對(duì)IoT領(lǐng)域推出自研的Codec。熹樂(lè)科技在IoT領(lǐng)域很重視網(wǎng)絡(luò)傳輸編解碼的效率方面。IoT數(shù)據(jù)的實(shí)時(shí)采集并通過(guò)長(zhǎng)鏈接發(fā)送的模式和視頻直播是很相像的。

IoT的設(shè)備到2025年將達(dá)到750億。這意味將有越來(lái)越多的設(shè)備需要進(jìn)行數(shù)據(jù)采集，由此產(chǎn)生的APP應(yīng)用也會(huì)越來(lái)越多。

現(xiàn)在市場(chǎng)對(duì)APP的開(kāi)發(fā)要求越來(lái)越快，time to market越快越好，現(xiàn)在很多低代碼、無(wú)代碼就是為了縮短開(kāi)發(fā)時(shí)間。YoMo框架十分重視開(kāi)發(fā)者友好，以便開(kāi)發(fā)者使用時(shí)可以節(jié)省時(shí)間。

為了節(jié)省開(kāi)發(fā)時(shí)間我們提出了Streaming Serverless的概念。Serverless的優(yōu)勢(shì)在于只需要專注幾行核心代碼、無(wú)需關(guān)心 DevOps、自動(dòng)彈性伸縮，以及按需計(jì)費(fèi)，低成本。IoT領(lǐng)域的數(shù)據(jù)是24小時(shí)不間斷產(chǎn)生的、沒(méi)有邊界，是典型的streaming場(chǎng)景，雖然現(xiàn)在已經(jīng)有很多比較成熟的Serverless框架，但市面上大多數(shù) Serverless 框架是面向傳統(tǒng)的HTTP Request/Response 模式。因此我們針對(duì)該場(chǎng)景提出了Streaming Serverless。

這是一條比較有意思的推特。這個(gè)推特是Docker的創(chuàng)始人在2019年提出來(lái)的，他在推特中提到，如果2008年出現(xiàn)WebAssembly，那么他們都沒(méi)有必要去創(chuàng)建Docker了。WebAssembly之前跑在瀏覽器端比較多，現(xiàn)在的趨勢(shì)卻是跑在服務(wù)端。

WebAssembly和Docker相比具有哪些優(yōu)勢(shì)呢？WebAssembly的Cold Start會(huì)比Docker快100倍。其次前者執(zhí)行時(shí)間較后者也快10%-50%。另外WebAssembly 占用的空間更小。最后WebAssembly有更靈活的安全策略，可以根據(jù)不同模塊，在實(shí)例化時(shí)指定不同權(quán)限。

因?yàn)樵谶吘壒?jié)點(diǎn)資源會(huì)比較受限，所以WebAssembly綜合了輕量級(jí)、更優(yōu)的性能、更高的安全性和多語(yǔ)言的特點(diǎn)。多語(yǔ)言對(duì)于Serverless尤其重要，因?yàn)楝F(xiàn)在很多主流的開(kāi)發(fā)語(yǔ)言都支持把程序編譯成WebAssembly，具有這樣的特點(diǎn)會(huì)有很多的好處。

綜合上述的方方面面，我們做了YoMo開(kāi)源框架。

YoMo應(yīng)用案例

03

再來(lái)分享幾個(gè)典型的案例。

我們?cè)谵k公室部署了一個(gè)實(shí)時(shí)噪聲傳感器，來(lái)測(cè)試YoMo框架是否能達(dá)到低時(shí)延。因?yàn)镸QTT協(xié)議需要安裝MQTT Broker，所以我們?cè)跀?shù)據(jù)采集端做了一個(gè)MQTT兼容的API，這樣可以減少用戶的負(fù)擔(dān)，無(wú)需安裝 MQTT Broker 即可接入 YoMo。為了測(cè)試實(shí)驗(yàn)，我們將Serverless的節(jié)點(diǎn)部署在寧夏的AWS，來(lái)測(cè)量北京到寧夏，再?gòu)膶幭姆祷乇本┑臅r(shí)延。

我們的測(cè)試結(jié)果顯示時(shí)延基本能穩(wěn)定在30ms以內(nèi)。另外像屏幕上顯示的分貝值，傳統(tǒng)的做法是把傳感器數(shù)據(jù)先保存到數(shù)據(jù)庫(kù)，然后再進(jìn)行查詢顯示，這樣就會(huì)造成時(shí)延的損失，所以YoMo采取通過(guò)WebSocket直接顯示到屏幕上。同時(shí)用另外一個(gè) Serverless服務(wù)把數(shù)據(jù)落地到 DB。

白酒智能釀造平臺(tái)是一個(gè)工業(yè)級(jí)的應(yīng)用。白酒行業(yè)的一大特點(diǎn)是很多釀酒工藝是通過(guò)老師傅的經(jīng)驗(yàn)傳授，這樣是非常主觀的。我們?cè)诤鸵粋€(gè)研究白酒幾十年的專業(yè)研究院——中國(guó)食品發(fā)酵工業(yè)研究院合作后，獲得了他們提供的硬件和相關(guān)的工業(yè)算法。接著我們對(duì)這些設(shè)備進(jìn)行了實(shí)時(shí)的工藝采集和計(jì)算，把老師傅的經(jīng)驗(yàn)數(shù)字化，從而獲得穩(wěn)定的工藝，提高了出酒率和效率。

海外有一個(gè)用戶想做用戶行為的跟蹤，分析一些網(wǎng)站上用戶什么樣的行為會(huì)導(dǎo)致轉(zhuǎn)換率的降低等問(wèn)題。針對(duì)這樣的場(chǎng)景，我們做了Geo-Distributed的分布式解決方案，將傳統(tǒng)的中心化架構(gòu)拆分成多個(gè)靠近用戶的邊緣節(jié)點(diǎn)。

最后一個(gè)案例是分布式的爬蟲(chóng)。我們服務(wù)了一個(gè)海外提供物流查詢的SaaS公司。之前這個(gè)公司的查詢都是通過(guò) proxy去獲取，這樣會(huì)造成很高的時(shí)延，同時(shí)穩(wěn)定性也不高，更加嚴(yán)重的是數(shù)據(jù)隱私可能泄露。通過(guò)YoMo框架，我們?cè)诟拷爝f公司的節(jié)點(diǎn)部署了一個(gè)爬蟲(chóng)服務(wù)，通過(guò)QUIC協(xié)議，把請(qǐng)求通過(guò)長(zhǎng)連接返回給美國(guó)的用戶。這些服務(wù)器都是部署在用戶自己的機(jī)器上，數(shù)據(jù)隱私得以保障，也節(jié)省了proxy代理的開(kāi)支。

YoMo features

04

通過(guò)之前的講座，在座的嘉賓多少對(duì)QUIC協(xié)議有一定的了解，這些內(nèi)容就快速通過(guò)。

QUIC優(yōu)點(diǎn)是非常多的。最好的就是最下面的兩點(diǎn)。一個(gè)是User space，我在開(kāi)頭開(kāi)放性那里也提到過(guò)User space，可以更方便的進(jìn)行軟件升級(jí)。TCP內(nèi)核態(tài)的升級(jí)就沒(méi)有那么方便。二是擁塞控制算法。根據(jù)不同的場(chǎng)景進(jìn)行靈活的控制，具有更高的可編程性。

QUIC在業(yè)內(nèi)的應(yīng)用實(shí)踐音視頻方面比較多。國(guó)內(nèi)很多的大廠在兩三年前就開(kāi)始研究音視頻方面的應(yīng)用。QUIC對(duì)性能的提升幫助很大，包括卡頓率等等。因?yàn)榭春肣UIC 的前景，加之工業(yè)領(lǐng)域應(yīng)用很少，所以我們想推動(dòng)QUIC在工業(yè)、IoT領(lǐng)域的運(yùn)用。

這里視頻借用了阿里手機(jī)淘寶的視頻，左邊采用多通道的QUIC，右邊沒(méi)有采用。如果WiFi出現(xiàn)抖動(dòng)的，左邊可以通過(guò)蜂窩網(wǎng)絡(luò)流暢運(yùn)行，而右邊只用到 WiFi 就出現(xiàn)卡頓的情況。

自研的 Y3 Codec我們稱它為faster than real-time。如果是傳統(tǒng)的JSON的話，就需要拿到完整數(shù)據(jù)以后進(jìn)行解碼。針對(duì)IoT，例如之前提到的噪聲，只要獲取噪聲分貝的字段即可。對(duì)此，我們使用了TLV的結(jié)構(gòu)。結(jié)構(gòu)里的Tag相當(dāng)于 JSON的key。通過(guò)監(jiān)聽(tīng)Tag是不是用戶關(guān)心的，如果是就直接獲取，不是則skip，再根據(jù)Length判斷需要skip多少字節(jié)。

性能測(cè)試中Y3 Codec相比JSON提升超10倍以上，與Protobuf相比也有明顯的提升。下表所展示的是一些性能報(bào)告。

響應(yīng)式的編程用excel的應(yīng)用來(lái)形象的說(shuō)明。假設(shè)a=b+c，那么對(duì)b、c進(jìn)行修改a也會(huì)有動(dòng)態(tài)的響應(yīng)，這種模式是十分適合數(shù)據(jù)隨著時(shí)間變化的場(chǎng)景。

ReactiveX也針對(duì)異步數(shù)據(jù)提供了一個(gè)良好的編程模型。ReactiveX最早是由微軟提出。在操作異步數(shù)據(jù)時(shí)可以使用一些通用的方法，就會(huì)像操作同步數(shù)據(jù)一樣方便，只要組合幾個(gè)常用的函數(shù)就可以操作異步數(shù)據(jù)流。

假設(shè)每30ms都會(huì)傳遞一次數(shù)據(jù)，可實(shí)際場(chǎng)景可能是連續(xù)兩個(gè)30ms都沒(méi)有數(shù)據(jù)，第三個(gè)30ms突然出現(xiàn)三個(gè)數(shù)據(jù)。針對(duì)這種場(chǎng)景我們實(shí)際只要獲取最新的數(shù)據(jù)即可。使用 Rx 可以簡(jiǎn)化這個(gè)問(wèn)題，使用 debounce 即可獲取每 30ms 內(nèi)的最新一條數(shù)據(jù)。

Streaming Serverless讓用戶不需要操作QUIC Stream，只需要操作Rx Stream?？梢愿鶕?jù)業(yè)務(wù)需求進(jìn)行Operator方法的組合即可。另外市面上很多Serverless服務(wù)在本地調(diào)試比較麻煩，所以YoMo支持CLI的方式本地運(yùn)行和調(diào)試。

邊緣計(jì)算

05

邊緣計(jì)算各位多多少少也有一定了解

整個(gè)行業(yè)的趨勢(shì)是從之前的大型機(jī)通過(guò)終端連接變成PC端去中心化場(chǎng)景。發(fā)展到移動(dòng)互聯(lián)時(shí)代又回到了中心化的云計(jì)算中心。到IoT時(shí)代因?yàn)閿?shù)據(jù)量的巨大，需要邊緣端進(jìn)行分布式來(lái)緩解云計(jì)算中心的壓力。邊緣計(jì)算雖然越來(lái)越重要，但是邊緣計(jì)算并不會(huì)取代云計(jì)算，他們會(huì)共同存在。

邊緣計(jì)算的優(yōu)勢(shì)一是降低傳輸距離。二是就近計(jì)算更快的響應(yīng)。第三，比較重要，邊緣計(jì)算可以保護(hù)安全隱私。很多工業(yè)企業(yè)并不是很愿意把數(shù)據(jù)傳輸?shù)焦性品?wù)上，所以隱私保護(hù)顯得格外重要。最后一點(diǎn)就是低成本。邊緣計(jì)算可以減少帶寬傳遞的成本。

云計(jì)算和邊緣計(jì)算的對(duì)比發(fā)現(xiàn)，云計(jì)算的性能更強(qiáng)但時(shí)延、帶寬成本較高，邊緣計(jì)算恰恰相反。云計(jì)算和邊緣計(jì)算在使用上互補(bǔ)，以滿足不同場(chǎng)景的使用需求。

對(duì)此我們做了Geo-Distributed Edge Cloud。用戶可以根據(jù)時(shí)延需求來(lái)部署在不同的地方。低時(shí)延可以部署在城市級(jí)節(jié)點(diǎn)。如果有數(shù)據(jù)監(jiān)管要求則可以部署在私有云。另外部署在云計(jì)算中心也是可以實(shí)現(xiàn)的。

總結(jié)

06

最后對(duì)今天的匯報(bào)進(jìn)行一個(gè)總結(jié)。

YoMo的項(xiàng)目背景是面向未來(lái)可編程的開(kāi)放性。針對(duì)網(wǎng)絡(luò)傳輸提出gRPC for IoT——全鏈路采用QUIC以及Y3 Codec 高性能編解碼。另外為了加快用戶開(kāi)發(fā)APP的速度，提出了Streaming Serverless的框架。針對(duì)YoMo的使用場(chǎng)景，運(yùn)行在WebAssembly會(huì)比Docker更加具有優(yōu)勢(shì)。最后邊緣計(jì)算方面YoMo可以基于Geo-Distributed Cloud進(jìn)行就近部署。

以上就是YoMo的開(kāi)源計(jì)劃，希望對(duì)YoMo感興趣的朋友們可以多多關(guān)注。

謝謝大家！

編輯：jq