其實物聯網IoT的(de)(de)發展,從概念的(de)(de)出(chu)現至今歷史(shi)時(shi)間并不長(chang),大概可以劃(hua)分(fen)為三個階段:
階段一:80年代(dai)末到2005年,屬(shu)于IoT發展的萌芽(ya)期。此時具備(bei)物聯(lian)網概念雛(chu)形的設(she)備(bei)開始在(zai)市場上涌現(xian),標(biao)志性的事(shi)件是2005年國(guo)際電信聯(lian)盟(meng)組織在(zai)一次(ci)國(guo)際性峰會上,首(shou)次(ci)明確了物聯(lian)網概念。
階段二:2005-2014年(nian),屬于(yu)IoT初步發展期(qi),在這期(qi)間更多消(xiao)費市場的設備開始涌現,比如在2013年(nian)Google Glass眼鏡(jing)推(tui)出(chu),2014年(nian)蘋(pin)果(guo)公司推(tui)出(chu)了自(zi)己(ji)健康(kang)類家居(ju)產品Homekit。2014年(nian)MQTT協(xie)議正式(shi)被推(tui)薦成為物聯(lian)網傳輸的標(biao)準協(xie)議。
階段三:自2014年有了協議標準后,從2015年開始各大云廠商相繼推出自己的IoT平臺。借助于平臺的能力,大大降低了硬件接入物聯網的門檻,物聯網應用也如雨后春(chun)筍(sun)般涌現出來。
什么是物聯(lian)網?2005年ITO組織(zhi)(國(guo)際(ji)電信聯(lian)盟(meng))對物聯(lian)網的標準(zhun)定(ding)義:物聯(lian)網就(jiu)是各種信息傳(chuan)感(gan)設備(bei),按照約定(ding)的協議將任何物品(pin)與互(hu)聯(lian)網連接起來,從而實現(xian)對設備(bei)的管理、定(ding)位、跟蹤、監控過程。
物聯網涵蓋(gai)的范圍非(fei)常廣泛,比如說5G、邊緣、藍牙(ya)、蜂窩(wo)。涵蓋(gai)了整個產業(ye)鏈,簡單(dan)對(dui)它進(jin)行系統分層(ceng),大概(gai)可以劃分幾(ji)個層(ceng)次(ci):
設備感知層:主要和硬(ying)件(jian)相關,包括各(ge)種傳感器、定(ding)位系(xi)統等等,參(can)與者是各(ge)大硬(ying)件(jian)廠商(shang)。
傳輸層(ceng):負責網絡(luo)信息的傳遞,分為無(wu)線/有線傳輸,也(ye)可以(yi)按照(zhao)速率,高速的3G、4G、5G、WI-FI,低速的像LoRa、ZGB等(deng)等(deng)。
平(ping)臺層(ceng):是(shi)目前各(ge)大云廠商主(zhu)要立足的層(ceng)面,負責設(she)備(bei)管(guan)理(li)、設(she)備(bei)接入(ru)、應(ying)用管(guan)理(li)。
應用(yong)層(ceng):和實際生活(huo)最相關(guan),各(ge)大方(fang)案解決商依托硬件(jian)和平臺能(neng)力,提供各(ge)種(zhong)貼近(jin)生活(huo)場景的應用(yong)。
騰(teng)(teng)訊(xun)的(de)IoT發展歷史如何?最早騰(teng)(teng)訊(xun)IoT發展歷史最早可(ke)追溯到2013、2014年(nian)左(zuo)右,當時(shi)(shi)QQ基(ji)于QQ的(de)賬號體系和關系鏈,發布了一(yi)款“QQ物(wu)聯”產(chan)品,實(shi)現(xian)在QQ上(shang)的(de)賬號管理,但(dan)當時(shi)(shi)是基(ji)于私有協議。2014年(nian)MQTT協議被推進為標準后,騰(teng)(teng)訊(xun)IoT得到重(zhong)點關注,2015-2016年(nian)騰(teng)(teng)訊(xun)內部已經孵化出多個(ge)相(xiang)當出色的(de)IoT產(chan)品,2016年(nian)對產(chan)品能力進行整合,形成了現(xian)在的(de)基(ji)礎(chu)物(wu)聯網(wang)通信平臺。
2016、2017年(nian)基(ji)于物(wu)聯網通(tong)信(xin)(xin)平臺(tai)(tai)產品(pin)能力(li)(li)和(he)性能進行產品(pin)打磨,基(ji)本(ben)具有(you)(you)(you)(you)高(gao)可靠、高(gao)可用(yong)的(de)(de)服務特性,目前(qian)技(ji)術通(tong)信(xin)(xin)平臺(tai)(tai)能支(zhi)持數(shu)億級別的(de)(de)設(she)備接(jie)入,上(shang)千萬(wan)的(de)(de)上(shang)下行QPS,提供(gong)多種(zhong)交互(hu)方(fang)式,比如說公有(you)(you)(you)(you)云、專(zhuan)有(you)(you)(you)(you)云、私有(you)(you)(you)(you)化產品(pin)。2017-2019年(nian)在(zai)基(ji)礎平臺(tai)(tai)之上(shang)完成一(yi)站式平臺(tai)(tai)建(jian)設(she),例如騰訊(xun)自有(you)(you)(you)(you)能力(li)(li),AI、大數(shu)據提供(gong)各種(zhong)場景(jing)應用(yong)能力(li)(li),同(tong)時建(jian)設(she)了寬(kuan)(kuan)帶(dai)設(she)備的(de)(de)寬(kuan)(kuan)帶(dai)通(tong)信(xin)(xin)Hub平臺(tai)(tai)。從2019年(nian)到(dao)現(xian)在(zai),大概(gai)有(you)(you)(you)(you)數(shu)億級別的(de)(de)設(she)備接(jie)入,每天光上(shang)下行消息就超過百(bai)T的(de)(de)級別,專(zhuan)區大概(gai)有(you)(you)(you)(you)100多個大客(ke)戶專(zhuan)區,交付(fu)方(fang)面(mian)有(you)(you)(you)(you)數(shu)百(bai)個成功的(de)(de)交付(fu)案(an)例,整體服務提供(gong)99999的(de)(de)可用(yong)性承(cheng)諾。
騰(teng)訊(xun)IOT有(you)哪(na)些(xie)(xie)產品能(neng)力(li)?騰(teng)訊(xun)云產品能(neng)力(li)主(zhu)要可以劃分為五大塊,最底層是三個通(tong)信平(ping)(ping)臺(tai)(tai),負責(ze)窄帶(dai)(dai)設備的(de)(de)基礎物(wu)聯(lian)通(tong)信平(ping)(ping)臺(tai)(tai),負責(ze)寬(kuan)帶(dai)(dai)設備的(de)(de)音視頻通(tong)信平(ping)(ping)臺(tai)(tai),負責(ze)邊緣節點管理的(de)(de)IECP。基于這些(xie)(xie)通(tong)信平(ping)(ping)臺(tai)(tai)能(neng)力(li),開發者平(ping)(ping)臺(tai)(tai)主(zhu)要是提供各(ge)種開發能(neng)力(li),結(jie)合各(ge)種場景(jing),提供各(ge)種應用能(neng)力(li)的(de)(de)平(ping)(ping)臺(tai)(tai)。同(tong)時還包括(kuo)一些(xie)(xie)管理服務平(ping)(ping)臺(tai)(tai),比如說(shuo)低速(su)網絡管理平(ping)(ping)臺(tai)(tai)LPWA、安全方案平(ping)(ping)臺(tai)(tai)TID、物(wu)聯(lian)網平(ping)(ping)臺(tai)(tai)、互聯(lian)網市(shi)場平(ping)(ping)臺(tai)(tai)。
截止到目前(qian),騰(teng)訊(xun)云平(ping)(ping)臺(tai)服務(wu)已(yi)經在全球部署了數(shu)十個數(shu)據(ju)節點(dian),協助合(he)作伙伴業務(wu)出(chu)海。騰(teng)訊(xun)積極利用(yong)(yong)開(kai)(kai)(kai)發者(zhe)平(ping)(ping)臺(tai),推(tui)出(chu)了騰(teng)訊(xun)連(lian)連(lian)平(ping)(ping)臺(tai),整合(he)了開(kai)(kai)(kai)發者(zhe)的(de)(de)能(neng)(neng)力(li)。顧名思義,開(kai)(kai)(kai)發者(zhe)平(ping)(ping)臺(tai)主要是(shi)給開(kai)(kai)(kai)發者(zhe)使用(yong)(yong)的(de)(de),包括硬件(jian)開(kai)(kai)(kai)發者(zhe)和(he)上層SaaS軟(ruan)件(jian)開(kai)(kai)(kai)發者(zhe),向下包容(rong)了TencentOS對藍牙協議標準化的(de)(de)識別(bie),上層提供(gong)各種應用(yong)(yong)級別(bie)的(de)(de)SDK,比如(ru)說小(xiao)的(de)(de)APP和(he)對外(wai)開(kai)(kai)(kai)放的(de)(de)API。還提供(gong)大量的(de)(de)數(shu)據(ju)處理能(neng)(neng)力(li),基于(yu)AI、基于(yu)大數(shu)據(ju)計算提供(gong)報(bao)表分析、AI場(chang)景能(neng)(neng)力(li)。
接下來我簡單介(jie)紹(shao)幾個(ge)(ge)比較突出(chu)的平(ping)臺(tai)能力,地理(li)(li)位置服(fu)務支(zhi)持多種設(she)備(bei)(bei)(bei)上報(bao)信(xin)息(xi),基(ji)于(yu)GPS信(xin)息(xi)上報(bao)信(xin)息(xi),基(ji)于(yu)WI-FI說(shuo)報(bao)信(xin)息(xi)在平(ping)臺(tai)內部進(jin)行數據處理(li)(li),處理(li)(li)之后進(jin)行設(she)備(bei)(bei)(bei)定位,設(she)備(bei)(bei)(bei)定位用來繪制軌(gui)跡圖、設(she)備(bei)(bei)(bei)分(fen)布狀(zhuang)態。首先(xian)是地理(li)(li)位置圍(wei)欄服(fu)務,可以在地圖上簡單地通過經(jing)緯度輸入畫出(chu)一(yi)個(ge)(ge)圍(wei)欄,關(guan)聯某一(yi)個(ge)(ge)設(she)備(bei)(bei)(bei),當設(she)備(bei)(bei)(bei)進(jin)出(chu)圍(wei)欄的時(shi)候(hou)觸發場景聯動(dong)、告警(jing)信(xin)息(xi)。
其(qi)次是提供(gong)的(de)可視化數據(ju)開(kai)(kai)發(fa)(fa)能(neng)力(li),用(yong)戶在(zai)控制臺上通(tong)過簡單的(de)拖(tuo)拉拽就可以(yi)實現(xian)數據(ju)的(de)開(kai)(kai)發(fa)(fa)。最后(hou)是應用(yong)托(tuo)管的(de)能(neng)力(li),用(yong)戶可以(yi)將自(zi)己的(de)SaaS應用(yong)服(fu)務托(tuo)管,直接(jie)在(zai)開(kai)(kai)發(fa)(fa)者平(ping)臺里進行(xing)服(fu)務托(tuo)管,實現(xian)一(yi)站式的(de)產品體(ti)驗。
接下來再(zai)介(jie)紹基礎通信平(ping)臺(tai),也是最(zui)核心(xin)的(de)(de)通信平(ping)臺(tai),基本承載了(le)目前超過90%的(de)(de)設備(bei)接入(ru)能力。其(qi)主要的(de)(de)服務(wu)架構圖,包括用戶(hu)的(de)(de)各(ge)(ge)種設備(bei)、各(ge)(ge)種協(xie)議,比(bi)如LoRa、網關設備(bei)、第(di)三方平(ping)臺(tai)等。
此外主要(yao)可劃分為四(si)個(ge)系統,在這(zhe)之上(shang)是用(yong)(yong)戶(hu)的(de)(de)各(ge)個(ge)數(shu)據出口(kou),用(yong)(yong)戶(hu)個(ge)可以用(yong)(yong)各(ge)種PaaS,比(bi)如(ru)Kafka提供API接(jie)口(kou)。比(bi)如(ru)以設(she)(she)備(bei)(bei)數(shu)據上(shang)行(xing)(xing)為例(li),首先從設(she)(she)備(bei)(bei)開始發(fa)(fa)(fa)起(qi),到(dao)Conn服(fu)務、接(jie)入服(fu)務、消(xiao)息(xi)路由(you)服(fu)務,根據消(xiao)息(xi)的(de)(de)類型(xing)進行(xing)(xing)轉(zhuan)發(fa)(fa)(fa),大部(bu)分消(xiao)息(xi)通過(guo)規則引擎(qing)服(fu)務,用(yong)(yong)戶(hu)可以在規則引擎(qing)上(shang)配(pei)置消(xiao)息(xi)目的(de)(de)地,根據規則進行(xing)(xing)轉(zhuan)發(fa)(fa)(fa),比(bi)如(ru)說要(yao)將A類設(she)(she)備(bei)(bei)的(de)(de)消(xiao)息(xi)轉(zhuan)發(fa)(fa)(fa)到(dao)Kafka,B類設(she)(she)備(bei)(bei)的(de)(de)消(xiao)息(xi)轉(zhuan)發(fa)(fa)(fa)到(dao)實際數(shu)據庫,這(zhe)是上(shang)行(xing)(xing)該有的(de)(de)鏈路。
下行鏈路通(tong)過資料關系(xi),輔(fu)助(zhu)系(xi)統層(ceng)面對外提供云API能力,用(yong)(yong)(yong)戶調(diao)用(yong)(yong)(yong)云API找(zhao)(zhao)到消(xiao)息(xi)(xi)推送服(fu)(fu)務,首先查(cha)找(zhao)(zhao)設備(bei)的狀態,找(zhao)(zhao)到設備(bei)當前的連(lian)接(jie)節點(dian),直接(jie)調(diao)用(yong)(yong)(yong)節點(dian)里的Conn服(fu)(fu)務再(zai)通(tong)過連(lian)接(jie)鏈路將消(xiao)息(xi)(xi)推送下去。
整體服(fu)務(wu)都是(shi)基(ji)于(yu)異步協程(cheng)的高性能框架設計,以(yi)業務(wu)服(fu)務(wu)為例,整個服(fu)務(wu)由(you)兩個進(jin)程(cheng)組(zu)成,一(yi)(yi)邊是(shi)協議處理(li)Conn-proxy進(jin)程(cheng),另一(yi)(yi)邊是(shi)邏輯處理(li)Conn-logic進(jin)程(cheng),兩個進(jin)程(cheng)中通過基(ji)于(yu)內(nei)存的消息(xi)隊(dui)列,兩組(zu)消息(xi)隊(dui)列,一(yi)(yi)組(zu)是(shi)上行(xing)消息(xi),一(yi)(yi)組(zu)是(shi)下行(xing)消息(xi)。
數據鏈(lian)(lian)路(lu)設備(bei)(bei)首先收(shou)到(dao)消(xiao)息(xi),Proxy進程(cheng)(cheng)(cheng)(cheng)(cheng)(cheng)本(ben)身是多線(xian)(xian)程(cheng)(cheng)(cheng)(cheng)(cheng)(cheng)的(de)(de)(de)進程(cheng)(cheng)(cheng)(cheng)(cheng)(cheng),主線(xian)(xian)程(cheng)(cheng)(cheng)(cheng)(cheng)(cheng)監聽到(dao)連(lian)(lian)接后(hou)(hou),把連(lian)(lian)接分發給(gei)工(gong)作(zuo)線(xian)(xian)程(cheng)(cheng)(cheng)(cheng)(cheng)(cheng),工(gong)作(zuo)線(xian)(xian)程(cheng)(cheng)(cheng)(cheng)(cheng)(cheng)組里(li)(li)的(de)(de)(de)某一個(ge)線(xian)(xian)程(cheng)(cheng)(cheng)(cheng)(cheng)(cheng)處(chu)(chu)理后(hou)(hou)面的(de)(de)(de)連(lian)(lian)接,進行收(shou)包(bao)(bao)協議處(chu)(chu)理,收(shou)到(dao)完整(zheng)的(de)(de)(de)包(bao)(bao)之(zhi)后(hou)(hou)會扔(reng)到(dao)上(shang)行消(xiao)息(xi)隊(dui)列里(li)(li)去(qu),同(tong)時(shi)通(tong)過管道FD喚醒(xing)邏(luo)輯(ji)(ji)進程(cheng)(cheng)(cheng)(cheng)(cheng)(cheng),邏(luo)輯(ji)(ji)進程(cheng)(cheng)(cheng)(cheng)(cheng)(cheng)的(de)(de)(de)主線(xian)(xian)程(cheng)(cheng)(cheng)(cheng)(cheng)(cheng)被喚醒(xing)之(zhi)后(hou)(hou)。通(tong)過上(shang)行消(xiao)息(xi)隊(dui)列里(li)(li)取(qu)到(dao)消(xiao)息(xi),根據一樣的(de)(de)(de)路(lu)由策略路(lu)由到(dao)自己的(de)(de)(de)工(gong)作(zuo)線(xian)(xian)程(cheng)(cheng)(cheng)(cheng)(cheng)(cheng)里(li)(li),工(gong)作(zuo)線(xian)(xian)程(cheng)(cheng)(cheng)(cheng)(cheng)(cheng)里(li)(li)進行邏(luo)輯(ji)(ji)的(de)(de)(de)處(chu)(chu)理,比(bi)如說調用后(hou)(hou)端的(de)(de)(de)服(fu)務、頻(pin)率效率等等。如果需要回包(bao)(bao),通(tong)過同(tong)樣的(de)(de)(de)鏈(lian)(lian)路(lu)扔(reng)到(dao)下行消(xiao)息(xi)隊(dui)列里(li)(li),同(tong)樣喚醒(xing),主線(xian)(xian)程(cheng)(cheng)(cheng)(cheng)(cheng)(cheng)被喚醒(xing)之(zhi)后(hou)(hou),消(xiao)息(xi)路(lu)由到(dao)工(gong)作(zuo)現(xian)成(cheng),工(gong)作(zuo)現(xian)成(cheng)找到(dao)連(lian)(lian)接回復(fu)給(gei)設備(bei)(bei)。
上(shang)述設計(ji)最大(da)好處是大(da)部分業務(wu)能力(li)變更主(zhu)要在邏(luo)輯處理上(shang),比(bi)如會(hui)增加(jia)頻率限制或者某個(ge)功能,增加(jia)特殊的連接方式。邏(luo)輯服(fu)(fu)(fu)務(wu)變更比(bi)較頻繁,這樣處理可(ke)以導致在邏(luo)輯服(fu)(fu)(fu)務(wu)變更的時(shi)候不會(hui)影響(xiang)接入層和設備連接。同時(shi),這種(zhong)設計(ji)模式形成過(guo)(guo)載保(bao)護,如果上(shang)行消(xiao)息(xi)隊列獲取到消(xiao)息(xi)以后,發現(xian)消(xiao)息(xi)已經(jing)超(chao)過(guo)(guo)了(le)比(bi)較長的時(shi)間,比(bi)如說(shuo)超(chao)過(guo)(guo)了(le)3秒代表著(zhu)服(fu)(fu)(fu)務(wu)負(fu)載較高,通過(guo)(guo)內部的機制減輕負(fu)載,保(bao)證服(fu)(fu)(fu)務(wu)的可(ke)靠性。
接下來(lai)結合實際(ji)中的(de)案(an)例探討物聯網技術在場景應(ying)用中面臨的(de)問題如(ru)何探索。
消費(fei)類產(chan)品(pin)(pin)大部分(fen)(fen)的(de)特(te)點首先是數據量級特(te)別大,分(fen)(fen)布地域非(fei)常廣(guang)泛,因為都(dou)(dou)是銷往地域的(de),不像行業(ye)(ye)企業(ye)(ye)的(de)設(she)備非(fei)常集中,就集中在幾個城市。其次產(chan)品(pin)(pin)從(cong)高(gao)端到(dao)低端,產(chan)品(pin)(pin)設(she)備資源差距比較大,主(zhu)要(yao)(yao)使用蜂窩(wo)技(ji)術,蜂窩(wo)技(ji)術主(zhu)要(yao)(yao)是產(chan)品(pin)(pin)可(ke)以隨(sui)身(shen)攜帶,路(lu)上擺攤隨(sui)便一(yi)放(fang)就可(ke)以,網絡環境2G到(dao)4G都(dou)(dou)有,受限于成本,低端產(chan)品(pin)(pin)可(ke)能就幾十塊(kuai)錢,設(she)備資源差異較大,最低端產(chan)品(pin)(pin)業(ye)(ye)務可(ke)用內存(cun)不到(dao)1兆。
其(qi)業務訴求有:信息穩定(ding)下發(fa);成(cheng)本(ben)低消耗(hao)流量少;鏈(lian)路(lu)安全(quan)。
這(zhe)(zhe)個設(she)備(bei)主要是(shi)兩條(tiao)(tiao)鏈(lian)路,一(yi)條(tiao)(tiao)鏈(lian)路是(shi)定時上(shang)報(bao)(bao)設(she)備(bei)的(de)(de)(de)狀態、設(she)備(bei)的(de)(de)(de)電(dian)量、設(she)備(bei)的(de)(de)(de)地理(li)位置(zhi)信息、設(she)備(bei)的(de)(de)(de)網絡信號。第二條(tiao)(tiao)鏈(lian)路是(shi)業(ye)務(wu)鏈(lian)路,用(yong)(yong)戶發生支付(fu)(fu)行為后,支付(fu)(fu)后調用(yong)(yong)API接口,用(yong)(yong)戶付(fu)(fu)了(le)多少錢指令(ling)下發下去(qu),音箱收(shou)到指令(ling)就(jiu)(jiu)會進行播報(bao)(bao),有一(yi)定的(de)(de)(de)延時性要求(qiu),如果時間(jian)過了(le)太久播報(bao)(bao)就(jiu)(jiu)沒啥意義(yi)了(le)。對這(zhe)(zhe)些特點(dian)和訴(su)求(qiu)進行了(le)抽象(xiang),簡單概括就(jiu)(jiu)是(shi)在(zai)滿足硬件(jian)資源的(de)(de)(de)條(tiao)(tiao)件(jian)下實現(xian)服務(wu)可靠、服務(wu)安全。
接下(xia)來,我(wo)們來看看消費類產品音箱(xiang)產品中做了哪(na)些探索?
連接可靠
服(fu)務可(ke)(ke)靠(kao)首先就是(shi)連(lian)接(jie)的可(ke)(ke)靠(kao),用戶(hu)有(you)很多(duo)弱(ruo)網(wang)(wang)設備,分布地域非(fei)常廣泛(fan),要解決(jue)弱(ruo)網(wang)(wang)環境下地理位置帶來的連(lian)接(jie)延(yan)時性。給用戶(hu)推(tui)薦的部(bu)署方式(shi)是(shi)大(da)專(zhuan)(zhuan)區多(duo)地域的部(bu)署方式(shi),在全國(guo)建了三個(ge)大(da)邏輯專(zhuan)(zhuan)區,加上7個(ge)接(jie)入前置節(jie)點(dian),加起(qi)來有(you)十幾個(ge)接(jie)入節(jie)點(dian),將移動網(wang)(wang)絡轉化為機(ji)房(fang)(fang)內部(bu)的高速網(wang)(wang)絡。部(bu)署節(jie)點(dian)以后,怎么保證設備就近連(lian)接(jie)到(dao)接(jie)入節(jie)點(dian)?移動網(wang)(wang)絡里根據DNS群體的方式(shi)是(shi)很不可(ke)(ke)靠(kao)的,經過(guo)多(duo)跳(tiao)的網(wang)(wang)絡先到(dao)基站,再到(dao)核心機(ji)房(fang)(fang),再到(dao)公共網(wang)(wang)絡,DNS尋址出口(kou)非(fei)常不可(ke)(ke)靠(kao)。
在SDK里引(yin)入(ru)了Http-DNS服(fu)(fu)務,雖然(ran)DNS尋址不(bu)可靠,但是出(chu)口IP一(yi)般都比(bi)較準確(que),調用服(fu)(fu)務獲取(qu)某個域名的(de)(de)接(jie)(jie)入(ru)點IP,根據出(chu)口IP、IP庫對比(bi)獲取(qu)就(jiu)近的(de)(de)節點,從而(er)實現就(jiu)近的(de)(de)設備接(jie)(jie)入(ru)。發(fa)(fa)(fa)生(sheng)故障的(de)(de)時(shi)(shi)候(hou)(hou)也做了容災(zai)處理(li),增加了主備域名,當Http-DNS出(chu)現故障的(de)(de)時(shi)(shi)候(hou)(hou),就(jiu)切到傳統的(de)(de)local DNS尋址方(fang)式,當這兩個服(fu)(fu)務同(tong)時(shi)(shi)異常(chang)的(de)(de)時(shi)(shi)候(hou)(hou),比(bi)如說Http-DNS服(fu)(fu)務發(fa)(fa)(fa)生(sheng)故障了,同(tong)時(shi)(shi)DNS解(jie)析(xi)也完全被(bei)劫(jie)持了,或(huo)者DNS發(fa)(fa)(fa)生(sheng)了解(jie)析(xi)故障,還(huan)有容災(zai)兜底的(de)(de)IP,保證它能(neng)連接(jie)(jie)到某一(yi)個地區。
通(tong)過(guo)這(zhe)一系列的手段,最(zui)終保(bao)證(zheng)設備連接(jie)到最(zui)近的就近節點就近接(jie)入,經(jing)過(guo)測試2G網(wang)絡情況下大概有(you)84%的設備能完成1秒(miao)內的消(xiao)息觸(chu)達,4G網(wang)絡下有(you)98%的設備完成1秒(miao)內消(xiao)息觸(chu)達。
服務可靠
客戶對服(fu)務可(ke)靠及其可(ke)用(yong)性要求(qiu)非常高(gao),當服(fu)務機器(qi)數(shu)增多,比如提供99999的(de)可(ke)用(yong)性,當我們有一萬臺機器(qi)的(de)時候,幾(ji)乎每天都有各把機器(qi)會發生(sheng)故障(zhang)。怎么樣(yang)保(bao)證服(fu)務的(de)高(gao)可(ke)靠性?又會存(cun)在哪些(xie)問題:機器(qi)故障(zhang)、機房故障(zhang)、地(di)域故障(zhang)?
例如,2019年廣州(zhou)有一(yi)個(ge)機(ji)(ji)房,市政施工的時(shi)候電纜被(bei)挖斷。怎么(me)解決這些(xie)問(wen)題?我(wo)們是(shi)多地(di)域(yu)(yu)部署的方(fang)式,把設備就近接(jie)入(ru)加(jia)上容(rong)災處理,保證地(di)域(yu)(yu)的容(rong)災可(ke)靠。地(di)域(yu)(yu)的容(rong)災可(ke)靠是(shi)某(mou)一(yi)個(ge)地(di)域(yu)(yu)故障了進(jin)行(xing)切換,切換到就近的另外一(yi)個(ge)地(di)域(yu)(yu),地(di)域(yu)(yu)內根(gen)據機(ji)(ji)房的分布,至少(shao)會選擇在兩個(ge)機(ji)(ji)房,每個(ge)機(ji)(ji)房set進(jin)行(xing)部署,每個(ge)set由20-30臺機(ji)(ji)器(qi)組成,完(wan)成服(fu)務閉環。如果下一(yi)個(ge)節點失敗(bai)了,根(gen)據調度系統找到最近的其他set節點重試,全部失敗(bai)了會寫到自(zi)己的文件里,通過異步(bu)的機(ji)(ji)制回溯。
DB里選型的是騰訊云的TDSQL,具備高容災(zai)可靠(kao)性(xing)機(ji)制(zhi),在(zai)主DB里實現了(le)(le)跨機(ji)房的1主2備,進行(xing)同步更新的機(ji)制(zhi),保證在(zai)機(ji)房故障的時候業務毫無(wu)感知,可以(yi)做(zuo)好(hao)無(wu)縫切換。在(zai)異地(di)提供了(le)(le)3個(ge)(ge)RO容災(zai)實例,平時主要負責數據(ju)的讀取,故障的時候可以(yi)手動切換,分(fen)鐘級別內完成(cheng)故障處理。對于KV緩存類(lei),通(tong)過全局性(xing)MQ同步到各個(ge)(ge)地(di)域,保證每個(ge)(ge)地(di)域的數據(ju)一致(zhi)性(xing),保證地(di)域之(zhi)內能(neng)夠(gou)完成(cheng)業務的完整性(xing)。
消息可靠
用戶需要(yao)下達(da)(da)一條(tiao)(tiao)指令(ling),怎(zen)么保證(zheng)指令(ling)最終能(neng)(neng)夠到(dao)達(da)(da)設(she)(she)備(bei)(bei)?設(she)(she)備(bei)(bei)的(de)(de)狀態本身(shen)是(shi)不確定的(de)(de),可(ke)能(neng)(neng)在線(xian)(xian)(xian)(xian)可(ke)能(neng)(neng)離線(xian)(xian)(xian)(xian),可(ke)能(neng)(neng)2G網絡下非(fei)常差,發(fa)一條(tiao)(tiao)消(xiao)(xiao)息(xi)可(ke)能(neng)(neng)要(yao)過(guo)十幾秒才(cai)能(neng)(neng)收到(dao),怎(zen)么保證(zheng)呢?這也是(shi)QS1的(de)(de)設(she)(she)計(ji)(ji)思路,一邊是(shi)服務(wu)(wu),另一邊是(shi)8K SDK的(de)(de)設(she)(she)計(ji)(ji)完成(cheng)消(xiao)(xiao)息(xi)的(de)(de)可(ke)信保障。從服務(wu)(wu)可(ke)以看(kan)到(dao)業務(wu)(wu)后(hou)臺通過(guo)API接(jie)口(kou)調用下發(fa)的(de)(de)push服務(wu)(wu),push服務(wu)(wu)收到(dao)消(xiao)(xiao)息(xi)以后(hou)首先會查(cha)找(zhao)設(she)(she)備(bei)(bei)狀態,如果(guo)設(she)(she)備(bei)(bei)離線(xian)(xian)(xian)(xian)就會將消(xiao)(xiao)息(xi)存(cun)儲(chu)到(dao)離線(xian)(xian)(xian)(xian)消(xiao)(xiao)息(xi)隊列里,如果(guo)發(fa)現(xian)設(she)(she)備(bei)(bei)在線(xian)(xian)(xian)(xian),找(zhao)到(dao)剛(gang)才(cai)提到(dao)的(de)(de)接(jie)收層的(de)(de)節點,同時消(xiao)(xiao)息(xi)會存(cun)在區域共享內(nei)存(cun)的(de)(de)數據結構里。
數據(ju)結(jie)構主(zhu)要兩部(bu)分組成(cheng):第一(yi),定時(shi)器,記錄了下次觸(chu)發(fa)(fa)的時(shi)間(jian)及(ji)哈希表的位置(zhi)。第二(er),哈希表,存儲完整數據(ju)。說到push消(xiao)息,嘗試通(tong)過(guo)Conn下發(fa)(fa)消(xiao)息到設備,這時(shi)候會出現多種情(qing)況:
第一種消(xiao)息會很快地到達設(she)備,設(she)備很快地順(shun)利(li)處理,回(hui)復業務的SDK,業務SDK通過原(yuan)來的鏈路(lu)原(yuan)路(lu)返回(hui),回(hui)到push服(fu)務,push會認為設(she)備收到了(le)數據,會在設(she)備結構里消(xiao)除兩(liang)部分數據。
第二(er)種如果網(wang)絡結構特別(bie)差(cha)的時(shi)候(hou),過(guo)(guo)一(yi)段時(shi)間定時(shi)器會(hui)觸(chu)發APP的指數算法,比如說第一(yi)次(ci)超(chao)過(guo)(guo)1秒沒有收到SDK,第二(er)次(ci)超(chao)過(guo)(guo)2秒,第三次(ci)超(chao)過(guo)(guo)4秒定時(shi)器就會(hui)重新觸(chu)發,重新獲取消息(xi),重試(shi)(shi)邏(luo)輯。有時(shi)候(hou)網(wang)絡實在是連不通,也不能無限(xian)重試(shi)(shi),就設(she)定了次(ci)數上(shang)限(xian),當它達到上(shang)限(xian)的時(shi)候(hou)消息(xi)不會(hui)丟掉,會(hui)扔到離(li)線(xian)消息(xi)隊列里(li)。當設(she)備在再次(ci)上(shang)線(xian)激活的時(shi)候(hou),會(hui)喚醒右上(shang)角的狀態服(fu)務,從離(li)線(xian)消息(xi)隊列里(li)獲取到離(li)線(xian)消息(xi),一(yi)條(tiao)一(yi)條(tiao)逐條(tiao)嘗試(shi)(shi)進行下發。
SDK設計前(qian)面也引入了消(xiao)(xiao)(xiao)(xiao)息(xi)(xi)隊(dui)(dui)列,消(xiao)(xiao)(xiao)(xiao)息(xi)(xi)隊(dui)(dui)列主要(yao)有(you)(you)(you)兩個(ge)作用(yong):第(di)一,業務非常繁忙的(de)時(shi)候防(fang)止下發(fa)過(guo)快,比如說1秒鐘下發(fa)了語音播(bo)報指令,語音播(bo)報是需要(yao)時(shi)間的(de),有(you)(you)(you)可(ke)(ke)能處(chu)理的(de)速度跟不上,因(yin)此消(xiao)(xiao)(xiao)(xiao)息(xi)(xi)隊(dui)(dui)列起到(dao)(dao)消(xiao)(xiao)(xiao)(xiao)峰填谷的(de)作用(yong)。第(di)二,弱網環境上下發(fa)一條消(xiao)(xiao)(xiao)(xiao)息(xi)(xi),遲(chi)遲(chi)沒(mei)有(you)(you)(you)收到(dao)(dao)SDK,過(guo)一段時(shi)間重復下發(fa)消(xiao)(xiao)(xiao)(xiao)息(xi)(xi),消(xiao)(xiao)(xiao)(xiao)息(xi)(xi)隊(dui)(dui)列根據(ju)消(xiao)(xiao)(xiao)(xiao)息(xi)(xi)的(de)唯一標識等性處(chu)理,保證不會重復播(bo)報一個(ge)消(xiao)(xiao)(xiao)(xiao)息(xi)(xi),不然一個(ge)用(yong)戶付(fu)完款(kuan)可(ke)(ke)能報了兩次。
安全保障
給用戶提(ti)(ti)供(gong)(gong)了(le)全(quan)(quan)鏈路的(de)安全(quan)(quan)保(bao)證,首(shou)先(xian)在前面接入(ru)層全(quan)(quan)部都接入(ru)了(le)自研(yan)(yan)的(de)大禹高防系統,進行流量攻(gong)擊保(bao)護(hu)。設備級別還提(ti)(ti)供(gong)(gong)了(le)一機一密、軟加(jia)固、安全(quan)(quan)平臺檢測的(de)安全(quan)(quan)保(bao)護(hu)。可(ke)靠連接方(fang)(fang)面,提(ti)(ti)供(gong)(gong)了(le)Http DNS+主備域(yu)名+容災IP的(de)保(bao)護(hu)方(fang)(fang)式。鏈路通(tong)道保(bao)護(hu)上提(ti)(ti)供(gong)(gong)了(le)多個安全(quan)(quan)保(bao)護(hu)級別,包括TLS、DTLS、PSK、自研(yan)(yan)TID安全(quan)(quan)解決方(fang)(fang)案。提(ti)(ti)供(gong)(gong)了(le)多維度(du)監控體系。用戶可(ke)以自定(ding)(ding)義產品的(de)關鍵屬性,比如分(fen)鐘內設備連接的(de)次數(shu),同向(xiang)對比超過一定(ding)(ding)的(de)波動范圍會進行告警(jing),右下角是實時(shi)監控狀態(tai)。
接下來我們詳細講解一下怎么做到設備保護和鏈路保護。設備保護TID安全平臺提供了多種解決方案,從SE安全芯片、TEE可信執行環境(jing)、軟加(jia)固(gu)(gu)等(deng)多(duo)種信任根(gen)方案。相對而(er)言SE和(he)TEE更加(jia)安全(quan),軟加(jia)固(gu)(gu)的(de)安全(quan)級別會低一點,但消費類設備受限(xian)于(yu)成(cheng)本限(xian)制,最終還是(shi)選擇軟加(jia)固(gu)(gu)的(de)方式。軟加(jia)固(gu)(gu)主要是(shi)通(tong)過指令亂序、數據混淆的(de)方式增加(jia)硬件被破解的(de)成(cheng)本。
鏈路(lu)保(bao)護一開始推(tui)薦的(de)是(shi)(shi)標準的(de)TLS加密鏈路(lu),TLS本(ben)身(shen)是(shi)(shi)安(an)全的(de),但(dan)后來在實(shi)驗過程中發現設備資(zi)源(yuan)非(fei)常有限,TLS庫本(ben)身(shen)也比較大(da),有些(xie)設備已經跑不起來了,所(suo)以提供了自研的(de)TID安(an)全鏈路(lu),鏈路(lu)的(de)大(da)概(gai)原理(li)首先(xian)是(shi)(shi)基于事實(shi),TID協議里(li)有4次(ci)握手(shou),前2次(ci)握手(shou)是(shi)(shi)客戶端向服務端請(qing)求證(zheng)(zheng)書(shu),拿到證(zheng)(zheng)書(shu)之后驗證(zheng)(zheng)證(zheng)(zheng)書(shu)鏈,驗證(zheng)(zheng)服務端的(de)合(he)法。比如說HTTVS訪問就(jiu)是(shi)(shi)這種,客戶首先(xian)請(qing)求百度(du)的(de)地址,怎么樣保(bao)證(zheng)(zheng)地址是(shi)(shi)正確的(de)呢?瀏覽(lan)器里(li)內置的(de)TLS校驗返(fan)回(hui)來的(de)證(zheng)(zheng)書(shu)鏈。
物聯(lian)網場景中有所不(bu)(bu)同(tong),設備和(he)服(fu)務端預(yu)先都知(zhi)道對方(fang)的公鑰,完(wan)全把公鑰信息植入到(dao)不(bu)(bu)一樣的兩(liang)邊,可(ke)以省(sheng)去交付的過程,同(tong)時也可(ke)以省(sheng)去TLS認證證書(shu)鏈的過程,對材(cai)料(liao)進(jin)行裁(cai)剪,四(si)次握手變成兩(liang)次握手,完(wan)成身(shen)份認證和(he)密鑰加密的過程,提供同(tong)等的安全防護。經過裁(cai)剪,TLS庫大概減少了(le)80%。
隨著業務(wu)的發展,越來越多傳統硬件行業的廠家(jia)、中長(chang)尾廠家(jia)逐(zhu)漸向(xiang)我們(men)咨詢,嘗試接入我們(men)的平臺,我們(men)發現他們(men)有(you)一(yi)些業務(wu)痛點,硬件開發周期長(chang),一(yi)個(ge)硬件3-6個(ge)月落地還算比較快(kuai)的,和(he)傳統互(hu)聯網節奏相當不同。
其次各種(zhong)網絡連接方式多(duo)樣,比如說藍牙、WI-FI等,通(tong)信協(xie)議(yi)每(mei)個廠(chang)家都要重(zhong)新再開(kai)發(fa)一遍。技術資源有(you)限,尤其硬(ying)(ying)件(jian)廠(chang)家很少做SaaS類應用,無(wu)法保(bao)(bao)證SaaS類成果,無(wu)法保(bao)(bao)證底(di)層有(you)很好的平(ping)臺(tai)、很好的硬(ying)(ying)件(jian)。最終給(gei)用戶展示的APP、小程序不美觀也是很遺憾的事情。根(gen)據業務痛點進行(xing)能(neng)(neng)力(li)抽(chou)象(xiang),抽(chou)象(xiang)出三部分能(neng)(neng)力(li):SDK接入能(neng)(neng)力(li)、協(xie)議(yi)適配接入能(neng)(neng)力(li)、SaaS應用接入能(neng)(neng)力(li),主要是為了解決傳統硬(ying)(ying)件(jian)廠(chang)商中長(chang)尾(wei)客戶如何更(geng)加(jia)快捷、更(geng)加(jia)方便地接入平(ping)臺(tai)。
它做(zuo)了哪些(xie)工作呢(ni)?對SDK進(jin)行(xing)(xing)了架構上的優化(hua)、硬件(jian)抽象、跨(kua)平(ping)臺(tai)解耦,主要分為四(si)層(ceng),最底層(ceng)的Health層(ceng),和硬件(jian)相(xiang)關(guan)的,已(yi)經適(shi)配了主流的平(ping)臺(tai)。再上面(mian)是(shi)網絡(luo)層(ceng),根據(ju)各種網絡(luo)連接方(fang)式,比(bi)如說(shuo)藍(lan)牙、WI-FI全部都(dou)設(she)定好了。再上面(mian)是(shi)IoT業(ye)務(wu)(wu)層(ceng),怎么(me)(me)連接,怎么(me)(me)收(shou)發消(xiao)息,怎么(me)(me)OTA升級(ji)。最上面(mian)是(shi)用戶(hu)業(ye)務(wu)(wu)層(ceng),主要是(shi)設(she)備收(shou)到某條消(xiao)息的時(shi)候該怎么(me)(me)去做(zuo),或(huo)者設(she)備感知(zhi)到某個條件(jian)變化(hua)的時(shi)候,比(bi)如說(shuo)溫度溫感,感知(zhi)到溫度變化(hua)的時(shi)候怎么(me)(me)通過接口(kou)上行(xing)(xing)消(xiao)息。
通過(guo)硬(ying)(ying)件抽(chou)(chou)象以后,對(dui)主流硬(ying)(ying)件平臺用(yong)(yong)戶接(jie)入(ru)時主動關心上(shang)層(ceng)的(de)(de)(de)(de)(de)用(yong)(yong)戶代碼,簡(jian)單進(jin)行開(kai)發,大(da)大(da)縮短(duan)硬(ying)(ying)件開(kai)發的(de)(de)(de)(de)(de)周期。統一(yi)了測試(shi)標(biao)準(zhun),提供完(wan)整的(de)(de)(de)(de)(de)測試(shi)用(yong)(yong)例,保證測試(shi)的(de)(de)(de)(de)(de)一(yi)致性(xing)和硬(ying)(ying)件本(ben)身的(de)(de)(de)(de)(de)接(jie)入(ru)質量(liang)。對(dui)協議(yi)適(shi)配(pei)能力也做了一(yi)定的(de)(de)(de)(de)(de)優(you)化(hua),開(kai)發量(liang)比較大(da)的(de)(de)(de)(de)(de)藍(lan)(lan)牙(ya)(ya)設備(bei)基于(yu)藍(lan)(lan)牙(ya)(ya)協議(yi)數據格式,設備(bei)端(duan)實(shi)現一(yi)遍,小程序(xu)APP端(duan)實(shi)現一(yi)遍,抽(chou)(chou)樣(yang)(yang)出來一(yi)套Lthink(音)的(de)(de)(de)(de)(de)協議(yi),根據對(dui)象的(de)(de)(de)(de)(de)模(mo)型(xing)和藍(lan)(lan)牙(ya)(ya)協議(yi)之(zhi)間(jian)進(jin)行行為預設,對(dui)設備(bei)的(de)(de)(de)(de)(de)管理狀態(tai)進(jin)行標(biao)準(zhun)化(hua),用(yong)(yong)戶如果要接(jie)入(ru)藍(lan)(lan)牙(ya)(ya)協議(yi)的(de)(de)(de)(de)(de)時候(hou),只需要簡(jian)單地配(pei)置(zhi)模(mo)板,使用(yong)(yong)SDK調整一(yi)下編譯選項(xiang),小程序(xu)和APP也是一(yi)樣(yang)(yang)的(de)(de)(de)(de)(de),集成DSK基本(ben)做到代碼的(de)(de)(de)(de)(de)開(kai)發協議(yi)接(jie)入(ru)。
對于WI-FI類場景,現(xian)在WI-FI配網形式(shi)非常(chang)多(duo)(duo)樣(yang),常(chang)見(jian)的(de)SoftAP,設備充當AP,手機連接(jie)將(jiang)(jiang)賬號密碼(ma)發(fa)送(song)(song)給他(ta),還(huan)有藍(lan)(lan)牙(ya)輔(fu)助、藍(lan)(lan)牙(ya)熱點,連接(jie)到熱點將(jiang)(jiang)賬號密碼(ma)發(fa)送(song)(song)給它。現(xian)在比(bi)(bi)較新興(xing)比(bi)(bi)較熱門的(de)一(yi)鍵配網,和具(ju)有一(yi)鍵配網功能的(de)路由(you)網關將(jiang)(jiang)編(bian)碼(ma)的(de)格式(shi),將(jiang)(jiang)WI-FI的(de)賬號密碼(ma)通(tong)過類似于ASK(音)編(bian)碼(ma)發(fa)一(yi)個包,這個包多(duo)(duo)少長(chang)度,連接(jie)設備。
常見的(de)WI-FI配網(wang)方式(shi)全部進行抽(chou)樣化,終端SDK、SaaSSDK全部都(dou)進行支持,用(yong)戶(hu)WI-FI配網(wang)的(de)設備(bei)基本(ben)可以做到(dao)零(ling)代碼的(de)開(kai)發。第三(san)點是SaaS能力(li)的(de)接(jie)入,基于連連品牌的(de)小程序、APP,提供(gong)(gong)了(le)非常強(qiang)大的(de)SaaS開(kai)發能力(li),提供(gong)(gong)了(le)強(qiang)大的(de)OS能力(li),用(yong)來集(ji)成(cheng)各種第三(san)方平(ping)臺(tai),開(kai)發一款(kuan)設備(bei),希望(wang)同時(shi)集(ji)成(cheng)百度平(ping)臺(tai)上的(de)設備(bei),都(dou)可以通過這種方式(shi)進行集(ji)成(cheng)。還(huan)提供(gong)(gong)服務托(tuo)管(guan)(guan)、關系鏈托(tuo)管(guan)(guan)的(de)服務,如果(guo)用(yong)戶(hu)不想(xiang)開(kai)發SaaS應(ying)用(yong),完全可以將賬戶(hu)托(tuo)管(guan)(guan)在服務平(ping)臺(tai),開(kai)發自己的(de)應(ying)用(yong)、小程序,通過拖拽(zhuai)API的(de)方式(shi)調用(yong)后臺(tai),綁定(ding)設備(bei),進行操(cao)作管(guan)(guan)理(li)。
提(ti)供的(de)小程序開(kai)發(fa)能力(li)和免代碼(ma)開(kai)發(fa)的(de)面板,用(yong)戶基于(yu)常見的(de)設備(bei)完全(quan)可(ke)以滿足,用(yong)戶也可(ke)以自定義(yi)一些圖標,集成(cheng)到小程序里來。同時用(yong)戶基于(yu)開(kai)發(fa)能力(li)自己開(kai)發(fa)的(de)應用(yong)場景(jing),比如基于(yu)藍牙連(lian)接的(de)智能跳繩、智能插座等等。
為什么會有音視頻場景的應用?物聯網本身是在高速發展的,隨著5G時代、物聯網提速,越來越多的傳統設備不再滿足于簡單的信令交互,落地的場景,比如說智能家居、智能(neng)家電(dian),像(xiang)空調、冰箱(xiang),空調可(ke)(ke)以進(jin)行家庭監控,集成小米攝像(xiang)頭(tou)(tou)家庭消費(fei)攝像(xiang)頭(tou)(tou)的功能(neng),冰箱(xiang)也(ye)是一樣,可(ke)(ke)能(neng)需(xu)要(yao)監控、音視頻通(tong)話的功能(neng),以及智能(neng)門鈴(ling)、消費(fei)類(lei)攝像(xiang)頭(tou)(tou)、智能(neng)穿(chuan)戴設(she)備需(xu)要(yao)多人(ren)通(tong)話的功能(neng)訴求。
隨著需求越來越大,2019年內(nei)部(bu)成立了(le)團隊,團隊主要(yao)整合騰訊(xun)(xun)云內(nei)部(bu)的(de)音視頻能力(li),提(ti)供技術解決方案。TRTC、XP2P、CSS是(shi)(shi)騰訊(xun)(xun)內(nei)部(bu)基于不同(tong)場景抽(chou)象出(chu)來的(de),TRTC是(shi)(shi)常(chang)用的(de)騰訊(xun)(xun)會(hui)(hui)議(yi)的(de)能力(li)抽(chou)象,原(yuan)理是(shi)(shi)實(shi)現雙人/多人通話,通話的(de)時候會(hui)(hui)把客戶端拉到會(hui)(hui)議(yi)室里多路推流,進行高質量的(de)音視頻協議(yi)交(jiao)互。它沒(mei)有P2P能力(li),全(quan)部(bu)通過云中(zhong)轉,具(ju)有高聯(lian)動性。
同樣(yang)它(ta)的(de)技術(shu)(shu)結構決定(ding)了它(ta)的(de)成本(ben)(ben)較(jiao)高,音視頻主(zhu)要(yao)(yao)使(shi)用(yong)(yong)成本(ben)(ben)有兩方(fang)(fang)面:一(yi)是(shi)(shi)帶寬;二(er)是(shi)(shi)存儲(chu)(chu),存儲(chu)(chu)是(shi)(shi)需要(yao)(yao)錄(lu)制時進行存儲(chu)(chu)。因為它(ta)的(de)技術(shu)(shu)比較(jiao)復雜,技術(shu)(shu)成本(ben)(ben)相對而言門檻比較(jiao)高。XP2P是(shi)(shi)騰訊(xun)內部P2P能力(li)的(de)提煉,主(zhu)要(yao)(yao)是(shi)(shi)基于標準的(de)STOM以及自研的(de)TERUN(音)服務,它(ta)這(zhe)個(ge)方(fang)(fang)案(an)(an)是(shi)(shi)完全(quan)基于P2P的(de),技術(shu)(shu)方(fang)(fang)案(an)(an)決定(ding)了它(ta)的(de)使(shi)用(yong)(yong)成本(ben)(ben)最低,因為它(ta)只(zhi)要(yao)(yao)打洞成功(gong)了就可以使(shi)用(yong)(yong)用(yong)(yong)戶的(de)流量。云直播CSS技術(shu)(shu)方(fang)(fang)案(an)(an)是(shi)(shi)傳統的(de)直播類領域,比如說斗魚(yu)、虎牙這(zhe)種直播平臺。
基于(yu)這三(san)種方案都形成了落地的(de)場(chang)景。P2P場(chang)景主要(yao)用IoT可靠信(xin)道(dao)作(zuo)(zuo)為信(xin)令傳輸。攝像(xiang)頭(tou)和播(bo)放(fang)端(duan)時(shi)不(bu)時(shi)通(tong)過(guo)(guo)MQTT信(xin)令將自己探測到的(de)信(xin)息(xi)傳輸到MT服務端(duan),需要(yao)進(jin)行交(jiao)互通(tong)信(xin)的(de)時(shi)候,通(tong)過(guo)(guo)MQTT或者MT服務端(duan)獲取到對端(duan)的(de)信(xin)息(xi)進(jin)行打(da)洞(dong),如果打(da)洞(dong)失敗通(tong)過(guo)(guo)IOT協議端(duan)協商(shang)最近的(de)中繼節點進(jin)行交(jiao)互通(tong)信(xin)。微信(xin)團隊深(shen)度合作(zuo)(zuo),首次實(shi)現了小程(cheng)序(xu)上(shang)對P2P直播(bo)流的(de)播(bo)放(fang)。目(mu)前打(da)洞(dong)成功率(lv)可以達到80%,延時(shi)在200-300毫秒左右,接近實(shi)時(shi)音視頻技術。
再分(fen)享一下(xia)傳統的(de)(de)槍機類攝(she)像(xiang)(xiang)頭(tou),大部(bu)分(fen)可以分(fen)為(wei)兩(liang)類,一部(bu)分(fen)是支(zhi)持國標(biao)(biao)(biao)GB28181協(xie)議(yi)的(de)(de),一部(bu)分(fen)是自有(you)協(xie)議(yi)的(de)(de)。怎(zen)么(me)接(jie)入云(yun)直(zhi)播的(de)(de)能(neng)力?開發(fa)了(le)一款自研的(de)(de)芯片(pian)服(fu)務(wu)(wu),對于支(zhi)持國標(biao)(biao)(biao)協(xie)議(yi)的(de)(de)攝(she)像(xiang)(xiang)頭(tou),直(zhi)接(jie)接(jie)入到(dao)芯片(pian)服(fu)務(wu)(wu)上(shang)去。對于完(wan)全自有(you)協(xie)議(yi)的(de)(de)攝(she)像(xiang)(xiang)頭(tou),結合邊緣(yuan)網(wang)關的(de)(de)形式適(shi)配協(xie)議(yi),邊緣(yuan)網(wang)關進行(xing)抽象變成(cheng)國標(biao)(biao)(biao)協(xie)議(yi)的(de)(de)節(jie)點,或者直(zhi)接(jie)通過標(biao)(biao)(biao)準流(liu)推到(dao)讓音視頻媒體(ti)服(fu)務(wu)(wu)。用戶觀看的(de)(de)時候通過控制臺、接(jie)口調(diao)用、信令服(fu)務(wu)(wu)器(qi)下(xia)發(fa)指令到(dao)IPTP設備(bei)(bei),設備(bei)(bei)將流(liu)推到(dao)音視頻服(fu)務(wu)(wu)器(qi)里,推流(liu)大部(bu)分(fen)是基于國標(biao)(biao)(biao)的(de)(de)RTP推流(liu)。音視頻服(fu)務(wu)(wu)對流(liu)進行(xing)了(le)兼(jian)容處理,對接(jie)上(shang)云(yun)直(zhi)播服(fu)務(wu)(wu),能(neng)夠(gou)提出標(biao)(biao)(biao)準化的(de)(de)出流(liu),RTSP、RTMP、小程序(xu)、H5播放、FLC等(deng)等(deng)。
同時,基于云上的資源快速存(cun)儲(chu),能(neng)夠大大降低存(cun)儲(chu)使(shi)用費用。以前用戶要么使(shi)用邊緣的硬件存(cun)儲(chu),硬件本身都是非常昂貴(gui)的。
通過這種方(fang)式可(ke)以(yi)使(shi)得傳統行業(ye)的(de)(de)監控類攝像頭(tou)有大量的(de)(de)應用場景,如AI算法槍一般(ban)使(shi)用RTSP進行數據(ju)音視頻的(de)(de)AI算法,并且可(ke)以(yi)在小(xiao)程序、APP上進行觀看。如前(qian)段時(shi)間武漢(han)方(fang)艙的(de)(de)直播觀看,最多(duo)時(shi)達幾十萬甚至上百萬人觀看直播,使(shi)用的(de)(de)就是類似的(de)(de)基礎(chu)方(fang)案。控制(zhi)界面(mian)提供了豐富控制(zhi)應用能力(li),電視墻大屏管理、云端錄制(zhi),小(xiao)程序則是播放的(de)(de)能力(li)。
綜上(shang)所(suo)述,結合不同場景分(fen)享(xiang)騰訊云(yun)在服務(wu)(wu)的(de)(de)可靠(kao)性、安全性方(fang)面(mian)怎(zen)么樣(yang)(yang)保(bao)證基礎服務(wu)(wu)的(de)(de)質量(liang),怎(zen)么樣(yang)(yang)在邊界接入(ru)(ru)、可用性方(fang)面(mian)降(jiang)低開發者使用的(de)(de)接入(ru)(ru)門(men)檻(jian),最后(hou)再結合音(yin)(yin)視頻(pin)的(de)(de)場景向大家分(fen)享(xiang)IoT和音(yin)(yin)視頻(pin)的(de)(de)場景落地。