一、loT歷史背景概述和系統分層介紹
（一）loT發展歷史
其實物聯網IoT的發展，從概念的出現至今歷史時間并不長，大概可以劃分為三個階段：
階段一：80年代末到2005年，屬于IoT發展的萌芽期。此時具備物聯網概念雛形的設備開始在市場上涌現，標志性的事件是2005年國際電信聯盟組織在一次國際性峰會上，首次明確了物聯網概念。
階段二：2005-2014年，屬于IoT初步發展期，在這期間更多消費市場的設備開始涌現，比如在2013年Google Glass眼鏡推出，2014年蘋果公司推出了自己健康類家居產品Homekit。2014年MQTT協議正式被推薦成為物聯網傳輸的標準協議。
階段三：自2014年有了協議標準后，從2015年開始各大云廠商相繼推出自己的IoT平臺。借助于平臺的能力，大大降低了硬件接入物聯網的門檻，物聯網應用也如雨后春筍般涌現出來。
什么是物聯網？2005年ITO組織（國際電信聯盟）對物聯網的標準定義：物聯網就是各種信息傳感設備，按照約定的協議將任何物品與互聯網連接起來，從而實現對設備的管理、定位、跟蹤、監控過程。
（二）loT系統分層
物聯網涵蓋的范圍非常廣泛，比如說5G、邊緣、藍牙、蜂窩。涵蓋了整個產業鏈，簡單對它進行系統分層，大概可以劃分幾個層次：
設備感知層：主要和硬件相關，包括各種傳感器、定位系統等等，參與者是各大硬件廠商。
傳輸層：負責網絡信息的傳遞，分為無線/有線傳輸，也可以按照速率，高速的3G、4G、5G、WI-FI，低速的像LoRa、ZGB等等。
平臺層：是目前各大云廠商主要立足的層面，負責設備管理、設備接入、應用管理。
應用層：和實際生活最相關，各大方案解決商依托硬件和平臺能力，提供各種貼近生活場景的應用。
二、騰訊IoT產品能力和服務架構
騰訊的IoT發展歷史如何？最早騰訊IoT發展歷史最早可追溯到2013、2014年左右，當時QQ基于QQ的賬號體系和關系鏈，發布了一款“QQ物聯”產品，實現在QQ上的賬號管理，但當時是基于私有協議。2014年MQTT協議被推進為標準后，騰訊IoT得到重點關注，2015-2016年騰訊內部已經孵化出多個相當出色的IoT產品，2016年對產品能力進行整合，形成了現在的基礎物聯網通信平臺。
2016、2017年基于物聯網通信平臺產品能力和性能進行產品打磨，基本具有高可靠、高可用的服務特性，目前技術通信平臺能支持數億級別的設備接入，上千萬的上下行QPS，提供多種交互方式，比如說公有云、專有云、私有化產品。2017-2019年在基礎平臺之上完成一站式平臺建設，例如騰訊自有能力，AI、大數據提供各種場景應用能力，同時建設了寬帶設備的寬帶通信Hub平臺。從2019年到現在，大概有數億級別的設備接入，每天光上下行消息就超過百T的級別，專區大概有100多個大客戶專區，交付方面有數百個成功的交付案例，整體服務提供99999的可用性承諾。
騰訊IOT有哪些產品能力？騰訊云產品能力主要可以劃分為五大塊，最底層是三個通信平臺，負責窄帶設備的基礎物聯通信平臺，負責寬帶設備的音視頻通信平臺，負責邊緣節點管理的IECP。基于這些通信平臺能力，開發者平臺主要是提供各種開發能力，結合各種場景，提供各種應用能力的平臺。同時還包括一些管理服務平臺，比如說低速網絡管理平臺LPWA、安全方案平臺TID、物聯網平臺、互聯網市場平臺。
截止到目前，騰訊云平臺服務已經在全球部署了數十個數據節點，協助合作伙伴業務出海。騰訊積極利用開發者平臺，推出了騰訊連連平臺，整合了開發者的能力。顧名思義，開發者平臺主要是給開發者使用的，包括硬件開發者和上層SaaS軟件開發者，向下包容了TencentOS對藍牙協議標準化的識別，上層提供各種應用級別的SDK，比如說小的APP和對外開放的API。還提供大量的數據處理能力，基于AI、基于大數據計算提供報表分析、AI場景能力。
接下來我簡單介紹幾個比較突出的平臺能力，地理位置服務支持多種設備上報信息，基于GPS信息上報信息，基于WI-FI說報信息在平臺內部進行數據處理，處理之后進行設備定位，設備定位用來繪制軌跡圖、設備分布狀態。首先是地理位置圍欄服務，可以在地圖上簡單地通過經緯度輸入畫出一個圍欄，關聯某一個設備，當設備進出圍欄的時候觸發場景聯動、告警信息。
其次是提供的可視化數據開發能力，用戶在控制臺上通過簡單的拖拉拽就可以實現數據的開發。最后是應用托管的能力，用戶可以將自己的SaaS應用服務托管，直接在開發者平臺里進行服務托管，實現一站式的產品體驗。
接下來再介紹基礎通信平臺，也是最核心的通信平臺，基本承載了目前超過90%的設備接入能力。其主要的服務架構圖，包括用戶的各種設備、各種協議，比如LoRa、網關設備、第三方平臺等。
此外主要可劃分為四個系統，在這之上是用戶的各個數據出口，用戶個可以用各種PaaS，比如Kafka提供API接口。比如以設備數據上行為例，首先從設備開始發起，到Conn服務、接入服務、消息路由服務，根據消息的類型進行轉發，大部分消息通過規則引擎服務，用戶可以在規則引擎上配置消息目的地，根據規則進行轉發，比如說要將A類設備的消息轉發到Kafka，B類設備的消息轉發到實際數據庫，這是上行該有的鏈路。
下行鏈路通過資料關系，輔助系統層面對外提供云API能力，用戶調用云API找到消息推送服務，首先查找設備的狀態，找到設備當前的連接節點，直接調用節點里的Conn服務再通過連接鏈路將消息推送下去。
整體服務都是基于異步協程的高性能框架設計，以業務服務為例，整個服務由兩個進程組成，一邊是協議處理Conn-proxy進程，另一邊是邏輯處理Conn-logic進程，兩個進程中通過基于內存的消息隊列，兩組消息隊列，一組是上行消息，一組是下行消息。
數據鏈路設備首先收到消息，Proxy進程本身是多線程的進程，主線程監聽到連接后，把連接分發給工作線程，工作線程組里的某一個線程處理后面的連接，進行收包協議處理，收到完整的包之后會扔到上行消息隊列里去，同時通過管道FD喚醒邏輯進程，邏輯進程的主線程被喚醒之后。通過上行消息隊列里取到消息，根據一樣的路由策略路由到自己的工作線程里，工作線程里進行邏輯的處理，比如說調用后端的服務、頻率效率等等。如果需要回包，通過同樣的鏈路扔到下行消息隊列里，同樣喚醒，主線程被喚醒之后，消息路由到工作現成，工作現成找到連接回復給設備。
上述設計最大好處是大部分業務能力變更主要在邏輯處理上，比如會增加頻率限制或者某個功能，增加特殊的連接方式。邏輯服務變更比較頻繁，這樣處理可以導致在邏輯服務變更的時候不會影響接入層和設備連接。同時，這種設計模式形成過載保護，如果上行消息隊列獲取到消息以后，發現消息已經超過了比較長的時間，比如說超過了3秒代表著服務負載較高，通過內部的機制減輕負載，保證服務的可靠性。
三、騰訊IoT在行業場景中的應用和探索
接下來結合實際中的案例探討物聯網技術在場景應用中面臨的問題如何探索。
（一）消費類產品音箱產品
消費類產品大部分的特點首先是數據量級特別大，分布地域非常廣泛，因為都是銷往地域的，不像行業企業的設備非常集中，就集中在幾個城市。其次產品從高端到低端，產品設備資源差距比較大，主要使用蜂窩技術，蜂窩技術主要是產品可以隨身攜帶，路上擺攤隨便一放就可以，網絡環境2G到4G都有，受限于成本，低端產品可能就幾十塊錢，設備資源差異較大，最低端產品業務可用內存不到1兆。
其業務訴求有：信息穩定下發；成本低消耗流量少；鏈路安全。
這個設備主要是兩條鏈路，一條鏈路是定時上報設備的狀態、設備的電量、設備的地理位置信息、設備的網絡信號。第二條鏈路是業務鏈路，用戶發生支付行為后，支付后調用API接口，用戶付了多少錢指令下發下去，音箱收到指令就會進行播報，有一定的延時性要求，如果時間過了太久播報就沒啥意義了。對這些特點和訴求進行了抽象，簡單概括就是在滿足硬件資源的條件下實現服務可靠、服務安全。
接下來，我們來看看消費類產品音箱產品中做了哪些探索？
連接可靠
服務可靠首先就是連接的可靠，用戶有很多弱網設備，分布地域非常廣泛，要解決弱網環境下地理位置帶來的連接延時性。給用戶推薦的部署方式是大專區多地域的部署方式，在全國建了三個大邏輯專區，加上7個接入前置節點，加起來有十幾個接入節點，將移動網絡轉化為機房內部的高速網絡。部署節點以后，怎么保證設備就近連接到接入節點？移動網絡里根據DNS群體的方式是很不可靠的，經過多跳的網絡先到基站，再到核心機房，再到公共網絡，DNS尋址出口非常不可靠。
在SDK里引入了Http-DNS服務，雖然DNS尋址不可靠，但是出口IP一般都比較準確，調用服務獲取某個域名的接入點IP，根據出口IP、IP庫對比獲取就近的節點，從而實現就近的設備接入。發生故障的時候也做了容災處理，增加了主備域名，當Http-DNS出現故障的時候，就切到傳統的local DNS尋址方式，當這兩個服務同時異常的時候，比如說Http-DNS服務發生故障了，同時DNS解析也完全被劫持了，或者DNS發生了解析故障，還有容災兜底的IP，保證它能連接到某一個地區。
通過這一系列的手段，最終保證設備連接到最近的就近節點就近接入，經過測試2G網絡情況下大概有84%的設備能完成1秒內的消息觸達，4G網絡下有98%的設備完成1秒內消息觸達。
服務可靠
客戶對服務可靠及其可用性要求非常高，當服務機器數增多，比如提供99999的可用性，當我們有一萬臺機器的時候，幾乎每天都有各把機器會發生故障。怎么樣保證服務的高可靠性？又會存在哪些問題：機器故障、機房故障、地域故障？
例如，2019年廣州有一個機房，市政施工的時候電纜被挖斷。怎么解決這些問題？我們是多地域部署的方式，把設備就近接入加上容災處理，保證地域的容災可靠。地域的容災可靠是某一個地域故障了進行切換，切換到就近的另外一個地域，地域內根據機房的分布，至少會選擇在兩個機房，每個機房set進行部署，每個set由20-30臺機器組成，完成服務閉環。如果下一個節點失敗了，根據調度系統找到最近的其他set節點重試，全部失敗了會寫到自己的文件里，通過異步的機制回溯。
DB里選型的是騰訊云的TDSQL，具備高容災可靠性機制，在主DB里實現了跨機房的1主2備，進行同步更新的機制，保證在機房故障的時候業務毫無感知，可以做好無縫切換。在異地提供了3個RO容災實例，平時主要負責數據的讀取，故障的時候可以手動切換，分鐘級別內完成故障處理。對于KV緩存類，通過全局性MQ同步到各個地域，保證每個地域的數據一致性，保證地域之內能夠完成業務的完整性。
消息可靠
用戶需要下達一條指令，怎么保證指令最終能夠到達設備？設備的狀態本身是不確定的，可能在線可能離線，可能2G網絡下非常差，發一條消息可能要過十幾秒才能收到，怎么保證呢？這也是QS1的設計思路，一邊是服務，另一邊是8K SDK的設計完成消息的可信保障。從服務可以看到業務后臺通過API接口調用下發的push服務，push服務收到消息以后首先會查找設備狀態，如果設備離線就會將消息存儲到離線消息隊列里，如果發現設備在線，找到剛才提到的接收層的節點，同時消息會存在區域共享內存的數據結構里。
數據結構主要兩部分組成：第一，定時器，記錄了下次觸發的時間及哈希表的位置。第二，哈希表，存儲完整數據。說到push消息，嘗試通過Conn下發消息到設備，這時候會出現多種情況：
第一種消息會很快地到達設備，設備很快地順利處理，回復業務的SDK，業務SDK通過原來的鏈路原路返回，回到push服務，push會認為設備收到了數據，會在設備結構里消除兩部分數據。
第二種如果網絡結構特別差的時候，過一段時間定時器會觸發APP的指數算法，比如說第一次超過1秒沒有收到SDK，第二次超過2秒，第三次超過4秒定時器就會重新觸發，重新獲取消息，重試邏輯。有時候網絡實在是連不通，也不能無限重試，就設定了次數上限，當它達到上限的時候消息不會丟掉，會扔到離線消息隊列里。當設備在再次上線激活的時候，會喚醒右上角的狀態服務，從離線消息隊列里獲取到離線消息，一條一條逐條嘗試進行下發。
SDK設計前面也引入了消息隊列，消息隊列主要有兩個作用：第一，業務非常繁忙的時候防止下發過快，比如說1秒鐘下發了語音播報指令，語音播報是需要時間的，有可能處理的速度跟不上，因此消息隊列起到消峰填谷的作用。第二，弱網環境上下發一條消息，遲遲沒有收到SDK，過一段時間重復下發消息，消息隊列根據消息的唯一標識等性處理，保證不會重復播報一個消息，不然一個用戶付完款可能報了兩次。
安全保障
給用戶提供了全鏈路的安全保證，首先在前面接入層全部都接入了自研的大禹高防系統，進行流量攻擊保護。設備級別還提供了一機一密、軟加固、安全平臺檢測的安全保護。可靠連接方面，提供了Http DNS+主備域名+容災IP的保護方式。鏈路通道保護上提供了多個安全保護級別，包括TLS、DTLS、PSK、自研TID安全解決方案。提供了多維度監控體系。用戶可以自定義產品的關鍵屬性，比如分鐘內設備連接的次數，同向對比超過一定的波動范圍會進行告警，右下角是實時監控狀態。
接下來我們詳細講解一下怎么做到設備保護和鏈路保護。設備保護TID安全平臺提供了多種解決方案，從SE安全芯片、TEE可信執行環境、軟加固等多種信任根方案。相對而言SE和TEE更加安全，軟加固的安全級別會低一點，但消費類設備受限于成本限制，最終還是選擇軟加固的方式。軟加固主要是通過指令亂序、數據混淆的方式增加硬件被破解的成本。
鏈路保護一開始推薦的是標準的TLS加密鏈路，TLS本身是安全的，但后來在實驗過程中發現設備資源非常有限，TLS庫本身也比較大，有些設備已經跑不起來了，所以提供了自研的TID安全鏈路，鏈路的大概原理首先是基于事實，TID協議里有4次握手，前2次握手是客戶端向服務端請求證書，拿到證書之后驗證證書鏈，驗證服務端的合法。比如說HTTVS訪問就是這種，客戶首先請求百度的地址，怎么樣保證地址是正確的呢？瀏覽器里內置的TLS校驗返回來的證書鏈。
物聯網場景中有所不同，設備和服務端預先都知道對方的公鑰，完全把公鑰信息植入到不一樣的兩邊，可以省去交付的過程，同時也可以省去TLS認證證書鏈的過程，對材料進行裁剪，四次握手變成兩次握手，完成身份認證和密鑰加密的過程，提供同等的安全防護。經過裁剪，TLS庫大概減少了80%。
（二）通用接入能力
隨著業務的發展，越來越多傳統硬件行業的廠家、中長尾廠家逐漸向我們咨詢，嘗試接入我們的平臺，我們發現他們有一些業務痛點，硬件開發周期長，一個硬件3-6個月落地還算比較快的，和傳統互聯網節奏相當不同。
其次各種網絡連接方式多樣，比如說藍牙、WI-FI等，通信協議每個廠家都要重新再開發一遍。技術資源有限，尤其硬件廠家很少做SaaS類應用，無法保證SaaS類成果，無法保證底層有很好的平臺、很好的硬件。最終給用戶展示的APP、小程序不美觀也是很遺憾的事情。根據業務痛點進行能力抽象，抽象出三部分能力：SDK接入能力、協議適配接入能力、SaaS應用接入能力，主要是為了解決傳統硬件廠商中長尾客戶如何更加快捷、更加方便地接入平臺。
它做了哪些工作呢？對SDK進行了架構上的優化、硬件抽象、跨平臺解耦，主要分為四層，最底層的Health層，和硬件相關的，已經適配了主流的平臺。再上面是網絡層，根據各種網絡連接方式，比如說藍牙、WI-FI全部都設定好了。再上面是IoT業務層，怎么連接，怎么收發消息，怎么OTA升級。最上面是用戶業務層，主要是設備收到某條消息的時候該怎么去做，或者設備感知到某個條件變化的時候，比如說溫度溫感，感知到溫度變化的時候怎么通過接口上行消息。
通過硬件抽象以后，對主流硬件平臺用戶接入時主動關心上層的用戶代碼，簡單進行開發，大大縮短硬件開發的周期。統一了測試標準，提供完整的測試用例，保證測試的一致性和硬件本身的接入質量。對協議適配能力也做了一定的優化，開發量比較大的藍牙設備基于藍牙協議數據格式，設備端實現一遍，小程序APP端實現一遍，抽樣出來一套Lthink（音）的協議，根據對象的模型和藍牙協議之間進行行為預設，對設備的管理狀態進行標準化，用戶如果要接入藍牙協議的時候，只需要簡單地配置模板，使用SDK調整一下編譯選項，小程序和APP也是一樣的，集成DSK基本做到代碼的開發協議接入。
對于WI-FI類場景，現在WI-FI配網形式非常多樣，常見的SoftAP，設備充當AP，手機連接將賬號密碼發送給他，還有藍牙輔助、藍牙熱點，連接到熱點將賬號密碼發送給它。現在比較新興比較熱門的一鍵配網，和具有一鍵配網功能的路由網關將編碼的格式，將WI-FI的賬號密碼通過類似于ASK（音）編碼發一個包，這個包多少長度，連接設備。
常見的WI-FI配網方式全部進行抽樣化，終端SDK、SaaSSDK全部都進行支持，用戶WI-FI配網的設備基本可以做到零代碼的開發。第三點是SaaS能力的接入，基于連連品牌的小程序、APP，提供了非常強大的SaaS開發能力，提供了強大的OS能力，用來集成各種第三方平臺，開發一款設備，希望同時集成百度平臺上的設備，都可以通過這種方式進行集成。還提供服務托管、關系鏈托管的服務，如果用戶不想開發SaaS應用，完全可以將賬戶托管在服務平臺，開發自己的應用、小程序，通過拖拽API的方式調用后臺，綁定設備，進行操作管理。
提供的小程序開發能力和免代碼開發的面板，用戶基于常見的設備完全可以滿足，用戶也可以自定義一些圖標，集成到小程序里來。同時用戶基于開發能力自己開發的應用場景，比如基于藍牙連接的智能跳繩、智能插座等等。
（三）音視頻場景下的應用
為什么會有音視頻場景的應用？物聯網本身是在高速發展的，隨著5G時代、物聯網提速，越來越多的傳統設備不再滿足于簡單的信令交互，落地的場景，比如說智能家居、智能家電，像空調、冰箱，空調可以進行家庭監控，集成小米攝像頭家庭消費攝像頭的功能，冰箱也是一樣，可能需要監控、音視頻通話的功能，以及智能門鈴、消費類攝像頭、智能穿戴設備需要多人通話的功能訴求。
隨著需求越來越大，2019年內部成立了團隊，團隊主要整合騰訊云內部的音視頻能力，提供技術解決方案。TRTC、XP2P、CSS是騰訊內部基于不同場景抽象出來的，TRTC是常用的騰訊會議的能力抽象，原理是實現雙人/多人通話，通話的時候會把客戶端拉到會議室里多路推流，進行高質量的音視頻協議交互。它沒有P2P能力，全部通過云中轉，具有高聯動性。
同樣它的技術結構決定了它的成本較高，音視頻主要使用成本有兩方面：一是帶寬；二是存儲，存儲是需要錄制時進行存儲。因為它的技術比較復雜，技術成本相對而言門檻比較高。XP2P是騰訊內部P2P能力的提煉，主要是基于標準的STOM以及自研的TERUN（音）服務，它這個方案是完全基于P2P的，技術方案決定了它的使用成本最低，因為它只要打洞成功了就可以使用用戶的流量。云直播CSS技術方案是傳統的直播類領域，比如說斗魚、虎牙這種直播平臺。
基于這三種方案都形成了落地的場景。P2P場景主要用IoT可靠信道作為信令傳輸。攝像頭和播放端時不時通過MQTT信令將自己探測到的信息傳輸到MT服務端，需要進行交互通信的時候，通過MQTT或者MT服務端獲取到對端的信息進行打洞，如果打洞失敗通過IOT協議端協商最近的中繼節點進行交互通信。微信團隊深度合作，首次實現了小程序上對P2P直播流的播放。目前打洞成功率可以達到80%，延時在200-300毫秒左右，接近實時音視頻技術。
再分享一下傳統的槍機類攝像頭，大部分可以分為兩類，一部分是支持國標GB28181協議的，一部分是自有協議的。怎么接入云直播的能力？開發了一款自研的芯片服務，對于支持國標協議的攝像頭，直接接入到芯片服務上去。對于完全自有協議的攝像頭，結合邊緣網關的形式適配協議，邊緣網關進行抽象變成國標協議的節點，或者直接通過標準流推到讓音視頻媒體服務。用戶觀看的時候通過控制臺、接口調用、信令服務器下發指令到IPTP設備，設備將流推到音視頻服務器里，推流大部分是基于國標的RTP推流。音視頻服務對流進行了兼容處理，對接上云直播服務，能夠提出標準化的出流，RTSP、RTMP、小程序、H5播放、FLC等等。
同時，基于云上的資源快速存儲，能夠大大降低存儲使用費用。以前用戶要么使用邊緣的硬件存儲，硬件本身都是非常昂貴的。
通過這種方式可以使得傳統行業的監控類攝像頭有大量的應用場景，如AI算法槍一般使用RTSP進行數據音視頻的AI算法，并且可以在小程序、APP上進行觀看。如前段時間武漢方艙的直播觀看，最多時達幾十萬甚至上百萬人觀看直播，使用的就是類似的基礎方案。控制界面提供了豐富控制應用能力，電視墻大屏管理、云端錄制，小程序則是播放的能力。
綜上所述，結合不同場景分享騰訊云在服務的可靠性、安全性方面怎么樣保證基礎服務的質量，怎么樣在邊界接入、可用性方面降低開發者使用的接入門檻，最后再結合音視頻的場景向大家分享IoT和音視頻的場景落地。
