［李中雷 陳楊］

1 前言

物聯(lián)網(wǎng)是以感知技術(shù)和網(wǎng)絡(luò)通信技術(shù)為主要手段，實現(xiàn)人、機、物的泛在連接，提供信息感知、信息傳輸、信息處理等服務(wù)的基礎(chǔ)設(shè)施。隨著經(jīng)濟社會數(shù)字化轉(zhuǎn)型和智能升級步伐加快，物聯(lián)網(wǎng)已經(jīng)成為新型基礎(chǔ)設(shè)施的重要組成部分。隨著云計算技術(shù)以及移動通信技術(shù)發(fā)展，物聯(lián)網(wǎng)技術(shù)應(yīng)用進入了一個蓬勃發(fā)展的階段，云網(wǎng)融合發(fā)展的理念也在電信運營商企業(yè)內(nèi)部貫徹執(zhí)行。

云計算技術(shù)深度發(fā)展在為物聯(lián)網(wǎng)領(lǐng)域應(yīng)用提供敏捷性基礎(chǔ)設(shè)施的同時，也為行業(yè)應(yīng)用的可靠性、靈活性提供便捷的手段。2015 年云原生基金會CNCF 聯(lián)盟成立，云原生技術(shù)相關(guān)開源項目包括Kubernetes容器編排技術(shù)已成為公認的云原生操作系統(tǒng)。Kubernetes 編排技術(shù)與容器、微服務(wù)以及敏捷基礎(chǔ)設(shè)施相輔相成，深度融合，實現(xiàn)在不同行業(yè)、不同應(yīng)用場景的項目落地，加速傳統(tǒng)產(chǎn)業(yè)與云計算技術(shù)融合，助力行業(yè)融合創(chuàng)新。

隨著云計算技術(shù)快速發(fā)展，在智慧水務(wù)、智慧燃氣、智慧水產(chǎn)、物流跟蹤、智慧消防、環(huán)境監(jiān)測、共享經(jīng)濟等領(lǐng)域取得了豐富的成功實踐應(yīng)用，推進千行百業(yè)數(shù)字化改造。中國電信積極踐行云網(wǎng)融合理念，推進“云轉(zhuǎn)數(shù)改”戰(zhàn)略轉(zhuǎn)型，物聯(lián)網(wǎng)設(shè)備上云成為大趨勢，海量物聯(lián)網(wǎng)設(shè)備管理在迎接大發(fā)展機遇的同時也面臨復(fù)雜的技術(shù)挑戰(zhàn)。

傳統(tǒng)移動物聯(lián)網(wǎng)終端接入企業(yè)客戶應(yīng)用系統(tǒng)架構(gòu)單一，且客戶自建系統(tǒng)規(guī)格不一致，架構(gòu)承載能力有限。如何讓海量終端具備高可靠連接入網(wǎng)能力，構(gòu)建更多人機交互場景，增強人員遠程控制設(shè)備能力，在國家規(guī)?；苿游锫?lián)網(wǎng)設(shè)備進行智慧化改造背景下，傳統(tǒng)的應(yīng)用系統(tǒng)已經(jīng)無法滿足海量終端接入需求，亟需提供一種滿足高可靠、高安全、大連接、低時延的物聯(lián)網(wǎng)平臺。

2 物聯(lián)網(wǎng)設(shè)備管理平臺發(fā)展趨勢

對于中小企業(yè)，受限于自身技術(shù)能力與云遷移能力，物聯(lián)網(wǎng)開放平臺的業(yè)務(wù)架構(gòu)設(shè)計采用傳統(tǒng)SOA 面向服務(wù)的單體應(yīng)用架構(gòu)，客戶應(yīng)用部署在自己機房，機房維護及運維人員的維護成本逐步升高。隨著云計算技術(shù)的演進，用戶的業(yè)務(wù)應(yīng)用逐步向云遷移，應(yīng)用上云的過程，為應(yīng)用的業(yè)務(wù)架構(gòu)演進提供了更多可能性，使得業(yè)務(wù)架構(gòu)的演進方向可以向著穩(wěn)定性強、可靠性高、性能更強的方向發(fā)展。

如圖1 所示為使用單體應(yīng)用SOA 服務(wù)架構(gòu)，所有的應(yīng)用服務(wù)均部署在同一個虛擬機上，利用統(tǒng)一的ESB（Enterprise Service Bus，企業(yè)服務(wù)總線）實現(xiàn)服務(wù)之間數(shù)據(jù)通信轉(zhuǎn)發(fā)、業(yè)務(wù)調(diào)度管理等能力。單體應(yīng)用架構(gòu)簡單，開發(fā)成本低，開發(fā)周期短，主要面向小型開發(fā)項目時可以快速落地。但是面向大型企業(yè)開發(fā)項目時，SOA 應(yīng)用架構(gòu)弊端就非常明顯，業(yè)務(wù)處理邏輯不能復(fù)用，應(yīng)用部署在同一個虛擬機導(dǎo)致應(yīng)用管理復(fù)雜度高，并且后續(xù)的服務(wù)變更也會更加困難，一次小的調(diào)整就需要進行全服務(wù)的迭代升級。

圖1 SOA 面向服務(wù)架構(gòu)

由于單體應(yīng)用架構(gòu)在項目開發(fā)、項目管理、迭代升級、運維管理、容災(zāi)管理等方面的嚴重弊端，面對大中型平臺項目，傳統(tǒng)SOA 單體架構(gòu)不能實現(xiàn)項目開發(fā)敏捷管理，采用單流水線作業(yè)效率相對較低。此外SOA 單體架構(gòu)平臺在能力迭代升級方面需要進行全服務(wù)中斷升級管理，客戶業(yè)務(wù)感知較差，對于頭部客戶而言，中斷業(yè)務(wù)升級方式影響范圍愈加廣泛。

如圖2 所示為當(dāng)前業(yè)內(nèi)流行的微服務(wù)（μs，Microservice），可以實現(xiàn)容器和微服務(wù)應(yīng)用管理，在項目開發(fā)管理及版本能力迭代升級方面，可以實現(xiàn)相對SOA 架構(gòu)較高的效率，運維人員只需重點關(guān)注業(yè)務(wù)服務(wù)運行情況。但這種微服務(wù)架構(gòu)在容災(zāi)能力依然需要自建機房，并且采用一主一備或者一主兩備方式，該方式云資源利用率低，投入成本較高。

圖2 微服務(wù)架構(gòu)

因此需要對微服務(wù)業(yè)務(wù)架構(gòu)進行深度優(yōu)化，提供更加靈活、便捷、可靠的業(yè)務(wù)服務(wù)架構(gòu)，并利用更敏捷高效的基礎(chǔ)設(shè)施實現(xiàn)業(yè)務(wù)靈活部署、高效迭代并且降低運維管理成本，提高平臺可用性。

面向超大型平臺開發(fā)現(xiàn)實，服務(wù)實例可能多達上萬個，同時需要滿足服務(wù)狀態(tài)生命周期維護、狀態(tài)檢測、彈性伸縮等能力。微服務(wù)彈性伸縮能力可根據(jù)業(yè)務(wù)高峰及低谷期自動進行服務(wù)數(shù)量縮減，以最大化提升資源使用效能，同時保障業(yè)務(wù)使用安全，在出現(xiàn)單服務(wù)故障時可以進行異常狀態(tài)服務(wù)隔離，降低用戶對單服務(wù)實例故障問題感知，從而大大提升平臺業(yè)務(wù)使用可靠性。如圖3 所示為本文實現(xiàn)的云原生架構(gòu)圖。

圖3 云原生架構(gòu)

隨著物聯(lián)網(wǎng)設(shè)備數(shù)量持續(xù)增長，采用云原生架構(gòu)，物聯(lián)網(wǎng)平臺可以滿足海量設(shè)備穩(wěn)定、可靠、安全接入管理成為必然面臨的課題?？紤]到未來物聯(lián)網(wǎng)業(yè)務(wù)特性及產(chǎn)業(yè)持續(xù)發(fā)展，物聯(lián)網(wǎng)平臺需要在海量異構(gòu)網(wǎng)絡(luò)終端接入管理、平臺能力快速迭代、靈活擴容解決業(yè)務(wù)快速增長帶來的計算壓力、層次清晰分明的業(yè)務(wù)架構(gòu)、便捷高效的研發(fā)運維體系等方面進行深入思考，打造高效、智能、可靠、穩(wěn)定、靈活的物聯(lián)網(wǎng)設(shè)備管理平臺。

3 物聯(lián)網(wǎng)平臺上云思路

3.1 短期物聯(lián)網(wǎng)平臺目標(biāo)架構(gòu)

對于云原生架構(gòu)業(yè)務(wù)的簡單理解是一個架構(gòu)是否是云原生，就看這個架構(gòu)是否是生長在云上。“生長在云上”不是簡單的使用云的IaaS 服務(wù)，比如ECS、OBS 這些基本的計算或者存儲，而是應(yīng)該理解為是否使用云上的分布式服務(wù)，比如緩存數(shù)據(jù)庫服務(wù)DCS、關(guān)系型數(shù)據(jù)庫服務(wù)RDS、文檔數(shù)據(jù)庫服務(wù)DDS 等，這才是直接影響到業(yè)務(wù)架構(gòu)的服務(wù)。在微服務(wù)框架下，分布式服務(wù)是必須，在非云原生架構(gòu)的時代，研發(fā)運維人員基于開源版本軟件搭建服務(wù)，自行運維。而到了云原生時代，業(yè)務(wù)則可以直接使用云上的服務(wù)，研發(fā)人員只需要調(diào)用云服務(wù)的API 接口使用服務(wù)即可，底層的軟件和機器維護都由運維人員負責(zé)。

另外兩個不得不提的技術(shù)就是Docker和Kubernetes。其中，前者標(biāo)準化了應(yīng)用分發(fā)的標(biāo)準，不論是Spring Boot寫的應(yīng)用，還是Node.JS 寫的應(yīng)用，都以鏡像的方式分發(fā)；而后者在前者的技術(shù)上又定義了應(yīng)用生命周期的標(biāo)準，一個應(yīng)用從啟動到上線，到健康檢查，再到下線，都有了統(tǒng)一的標(biāo)準。Kubernetes 在容器的應(yīng)用領(lǐng)域上，由于其高性能及靈活可用性，目前默認已經(jīng)成為容器編排以及生命周期管理的操作系統(tǒng)。

容器技術(shù)的應(yīng)用，隔離了微服務(wù)應(yīng)用和底層計算資源的耦合性，微服務(wù)可以做到彈性擴容、縮減，并通過標(biāo)簽方式實現(xiàn)業(yè)務(wù)分發(fā)的隔離，即可以實現(xiàn)相同處理業(yè)務(wù)邏輯的微服務(wù)，一部分可以承載業(yè)務(wù)，一部分可以不承載業(yè)務(wù)，這可以實現(xiàn)業(yè)務(wù)功能的灰度發(fā)布，或者說在功能運行時，可以先升級一部分微服務(wù)，確認正常之后，再升級另外一部分，業(yè)務(wù)灰度發(fā)布流程如圖4 所示。

圖4 業(yè)務(wù)灰度發(fā)布流程

隨著云計算技術(shù)向超大規(guī)模分布式云計算體系方向發(fā)展，物聯(lián)網(wǎng)開放平臺的可擴展性、承載容量也相應(yīng)獲得利好，平臺依托云的發(fā)展可實現(xiàn)彈性伸縮容，多節(jié)點分布，可以滿足多地域、海量設(shè)備接入的需求。

4 基于云原生多活業(yè)務(wù)架構(gòu)實踐

中國電信聯(lián)合華為，2017 年開始全力推進NB-IoT 窄帶物聯(lián)網(wǎng)平臺的商業(yè)應(yīng)用，目前已經(jīng)應(yīng)用在燃氣、水務(wù)、煙感、路燈等小數(shù)據(jù)量低頻次通信場景，設(shè)備連接規(guī)模已經(jīng)近億。在海量物聯(lián)網(wǎng)設(shè)備接入場景下，設(shè)備管理平臺需要滿足高并發(fā)接入，高可用，彈性擴容等能力，以滿足未來更多設(shè)備接入需求。本文介紹在NB-IoT 業(yè)務(wù)發(fā)展以及云計算技術(shù)迭代更新過程中，物聯(lián)網(wǎng)設(shè)備連接管理平臺能力建設(shè)的思考實踐。

4.1 云原生技術(shù)實踐

物聯(lián)網(wǎng)平臺面向物聯(lián)網(wǎng)設(shè)備提供接入管理服務(wù)，設(shè)備傳感器采集數(shù)據(jù)通過NB-IoT 窄帶網(wǎng)絡(luò)上傳到平臺。隨著設(shè)備數(shù)量增加，傳統(tǒng)自建基礎(chǔ)設(shè)施搭建的單體架構(gòu)應(yīng)用平臺面臨以下幾個方面的挑戰(zhàn)。

（1）設(shè)備上傳數(shù)據(jù)的消息并發(fā)量持續(xù)增長，平臺并發(fā)計算處理能力以及業(yè)務(wù)處理效率面臨巨大的挑戰(zhàn)。

（2）業(yè)務(wù)持續(xù)增長面臨計算資源擴容情況，傳統(tǒng)單體應(yīng)用架構(gòu)擴容需要購買物理計算機，并且安裝上架，打通與現(xiàn)存設(shè)備網(wǎng)絡(luò)，并且納入資源管理，流程時間長，操作復(fù)雜。

（3）傳統(tǒng)SOA 單體應(yīng)用架構(gòu)軟件版本隔離性差，業(yè)務(wù)處理邏輯打包在一起，如果對業(yè)務(wù)處理漏洞進行補丁修復(fù)或者新功能上線升級，需要中斷全平臺業(yè)務(wù)進行升級，客戶業(yè)務(wù)感知差。

隨著云計算技術(shù)快速發(fā)展，以Kubernetes 和docker容器應(yīng)用為代表的云原生技術(shù)，為解決上述問題打開思路。在NB-IoT 窄帶物聯(lián)網(wǎng)場景下，NB-IoT 設(shè)備使用UDP 協(xié)議上傳數(shù)據(jù)，在平臺內(nèi)部需要經(jīng)過負載分發(fā)，微服務(wù)做業(yè)務(wù)邏輯處理并及時響應(yīng)。LVS 負載均衡服務(wù)在OSI 七層模型的網(wǎng)絡(luò)層，只進行路由轉(zhuǎn)發(fā)，可以實現(xiàn)萬級TPS 的消息接入，滿足海量設(shè)備高并發(fā)接入需求。LVS 與業(yè)務(wù)處理微服務(wù)μs采用最小連接數(shù)原則進行業(yè)務(wù)均衡分發(fā)，微服務(wù)μs運行在Kubernetes 集群中，可以進行動態(tài)伸縮，如果業(yè)務(wù)量突然有增長，可以增加微服務(wù)實例數(shù)量，緩解高峰業(yè)務(wù)壓力；如果業(yè)務(wù)進入低谷期，可以縮減微服務(wù)實例數(shù)量，節(jié)省計算資源。

相比傳統(tǒng)單體應(yīng)用架構(gòu)，微服務(wù)在原有單體架構(gòu)基礎(chǔ)上，將業(yè)務(wù)處理邏輯進行拆分，將一個應(yīng)用拆分成多個應(yīng)用實例，不同應(yīng)用之間通過開放API 接口進行業(yè)務(wù)交互。業(yè)務(wù)處理邏輯拆分之后，不僅可以實現(xiàn)業(yè)務(wù)邏輯隔離，業(yè)務(wù)處理流程清晰，而且如果出現(xiàn)單個微服務(wù)狀態(tài)出現(xiàn)異常情況，可以將該微服務(wù)直接停止，而不會影響相同微服務(wù)的其他實例。同時在服務(wù)版本升級時候，可以直接針對同一種微服務(wù)進行單個滾動升級，極大降低業(yè)務(wù)邏輯代碼耦合以及服務(wù)升級的影響，提升平臺整體可靠性以及服務(wù)感知。如圖5 所示為基于云原生底座的微服務(wù)業(yè)務(wù)處理流程。

圖5 基于云原生底座的微服務(wù)業(yè)務(wù)處理

4.2 3AZ 多活架構(gòu)

自建基礎(chǔ)設(shè)施的方式，雖然在物理計算資源上做到很好的隔離，提供強有力的安全保障。但是在業(yè)務(wù)可靠性、資源擴展性方面相比云計算基礎(chǔ)設(shè)施存在較大的不足。

（1）自建機房部署計算設(shè)施，需要進行站址選擇，部署冷卻系統(tǒng)、消防系統(tǒng)，做好人員進出管控。更重要的是在單個機房的條件下，無法滿足業(yè)務(wù)容災(zāi)的需要。如果建設(shè)多個異地機房，則投入成本則會翻倍，資源利用率不高。

（2）自建機房的選址面積需要考慮到業(yè)務(wù)長期發(fā)展的需要，如果業(yè)務(wù)發(fā)展較快，對計算資源要求較高，沒有更多的機架部署設(shè)備，則在資源擴展性方面很容易受限制。

在云計算時代，海量計算資源匯聚，并通過虛擬化技術(shù)實現(xiàn)計算資源分配及隔離，可以根據(jù)客戶業(yè)務(wù)需要動態(tài)調(diào)配資源數(shù)據(jù)。且云服務(wù)提供商可以在一個region 資源池內(nèi)建立多個可用區(qū)AZ，每個可用區(qū)即是一個機房，多個可用區(qū)之間距離一般在50 km 以內(nèi)，通過光纖方式進行直連，確?？捎脜^(qū)服務(wù)之間時延在0.01 ms 以內(nèi)。如圖6 所示為本文設(shè)計的云原生3AZ 多活場景下的業(yè)務(wù)服務(wù)架構(gòu)。

圖6 云原生3AZ 多活場景下的業(yè)務(wù)服務(wù)架構(gòu)

本文所涉及的物聯(lián)網(wǎng)NB-IoT 設(shè)備管理平臺，除應(yīng)用微服務(wù)3AZ 部署之外，其他關(guān)鍵組件也同樣實現(xiàn)3AZ 方式部署，如圖7 所示為MongoDB 的3AZ 部署模式。DDS數(shù)據(jù)庫服務(wù)包含3 個業(yè)務(wù)組件mongos、shard 和config，其中mongos用于處理數(shù)據(jù)庫連接請求，shard用于數(shù)據(jù)請求的處理且shard 為一主兩從模式，config 用于數(shù)據(jù)庫配置管理。

圖7 MongoDB 的3AZ 部署模式

傳統(tǒng)機房的部署模式會將3 個組件部署在同一臺虛擬機上，如果虛擬機出現(xiàn)問題，或者其中一個組件出現(xiàn)問題，都會導(dǎo)致數(shù)據(jù)庫崩潰，無法提供服務(wù)。采用3AZ 部署方式，將3 個組件拆分開部署，每個組件獨立虛擬機部署，計算資源相互不影響，如果單個組件出現(xiàn)問題，不影響其他組件工作，極大地擺脫了對底層計算資源的依賴性，提升服務(wù)可靠性。

圖8 所示為傳統(tǒng)主備部署和云原生多活部署的設(shè)備管理平臺方案對比，可以實現(xiàn)億級NB-IoT 終端的設(shè)備管理和能力開放，支持彈性擴容、灰度發(fā)布、服務(wù)分級等能力；突破傳統(tǒng)主備部署能力瓶頸，實現(xiàn)物聯(lián)網(wǎng)業(yè)務(wù)無感知升級及倒換，在單個數(shù)據(jù)中心發(fā)生故障情況下，平臺還可快速完成業(yè)務(wù)遷移，確保用戶業(yè)務(wù)“零”損失，平臺安全可靠性取得極大突破。

圖8 傳統(tǒng)主備部署與分布式多活部署方案對比

目前國內(nèi)外運營商物聯(lián)網(wǎng)網(wǎng)絡(luò)系統(tǒng)采用傳統(tǒng)主備容災(zāi)模式，故障倒換影響業(yè)務(wù)時長達30 分鐘以上，而在移動互聯(lián)網(wǎng)領(lǐng)域采用多活部署的例如支付寶平臺，僅在云平臺業(yè)務(wù)側(cè)實現(xiàn)多活技術(shù)，尚未實現(xiàn)網(wǎng)絡(luò)側(cè)多活技術(shù)的部署應(yīng)用。本文研究并實現(xiàn)的從網(wǎng)絡(luò)到平臺融合的多活部署，在單數(shù)據(jù)中心故障的情況下，用戶“0”感知。

不僅在PaaS 服務(wù)上實現(xiàn)微服務(wù)可靠性大幅度提升，在SaaS 應(yīng)用服務(wù)上，平臺通過CCE 云容器引擎服務(wù)進行SaaS 微服務(wù)的業(yè)務(wù)編排管理，同時通過心跳保護等異常檢測機制，如果微服務(wù)所在宿主機所在的機房出現(xiàn)異常情況，微服務(wù)也會漂移到其他正常狀態(tài)的機房宿主機上，這就依賴于服務(wù)的彈性伸縮能力，可以實現(xiàn)容器微服務(wù)的全生命周期管理。

5 云原生技術(shù)未來研究方向

云原生技術(shù)經(jīng)過短短幾年的發(fā)展，目前已經(jīng)開始在多個業(yè)務(wù)領(lǐng)域開始投入使用，越來越多的企業(yè)開始投入到云原生技術(shù)使用場景：

（1）數(shù)據(jù)共享機制

云原生數(shù)據(jù)庫僅開放API 接口提供服務(wù)，如果存在大量數(shù)據(jù)需要進行多站點之間備份，通過API 接口的方式，勢必對PaaS 服務(wù)的計算能力產(chǎn)生影響，因此如何平衡好PaaS 服務(wù)和客戶業(yè)務(wù)需求之間關(guān)系，是未來需要重點考量的問題。

（2）函數(shù)式計算

FaaS，英文全稱為Function as a Service，即函數(shù)即服務(wù)，是在微服務(wù)基礎(chǔ)上進一步進行更細粒度的計算拆分，這種方式可以實現(xiàn)計算能力隨時啟用和銷毀，且業(yè)務(wù)邏輯簡單，用戶只需要做好某一個業(yè)務(wù)邏輯的規(guī)劃，在FaaS 平臺上可以進行簡單的函數(shù)編寫，即可運行起來一個應(yīng)用程序，不需要深厚的代碼編寫能力。

（3）設(shè)備管理平臺異地多節(jié)點

云原生3AZ 平臺是在單region 節(jié)點內(nèi)實現(xiàn)，物聯(lián)網(wǎng)設(shè)備是在全國范圍內(nèi)鋪開使用，客戶要求可以通過單點的方式實現(xiàn)對全國業(yè)務(wù)管理，平臺的分布式節(jié)點必然有需求，同涉及到多節(jié)點之間的數(shù)據(jù)同步，即多個region 之間業(yè)務(wù)活躍的技術(shù)實現(xiàn)，未來需要進行更多新技術(shù)需要滿足該業(yè)務(wù)場景需求。

6 結(jié)語

隨著云計算、5G、物聯(lián)網(wǎng)的大力發(fā)展，新型基礎(chǔ)設(shè)施的強力推進建設(shè)，傳統(tǒng)企業(yè)借助新型基礎(chǔ)設(shè)施進行企業(yè)信息化、數(shù)字化轉(zhuǎn)型。中國電信以“網(wǎng)是基礎(chǔ)、云為核心、網(wǎng)隨云動、云網(wǎng)一體”為發(fā)展理念，全力踐行云轉(zhuǎn)數(shù)改戰(zhàn)略，推進新興技術(shù)在各行各業(yè)的落地應(yīng)用。本文分析傳統(tǒng)企業(yè)應(yīng)用架構(gòu)在物聯(lián)網(wǎng)領(lǐng)域面臨業(yè)務(wù)處理能力、服務(wù)可靠性、架構(gòu)靈活性等問題，提出通過云原生多活的技術(shù)打造可靠、靈活、穩(wěn)定的業(yè)務(wù)服務(wù)架構(gòu)實現(xiàn)方案，并在實際生產(chǎn)業(yè)務(wù)中完成實踐，對于未來海量物聯(lián)網(wǎng)設(shè)備管理平臺的架構(gòu)演進具有較大的實踐指導(dǎo)意義。

當(dāng)前經(jīng)濟社會數(shù)字化轉(zhuǎn)型和智能升級步伐加快，物聯(lián)網(wǎng)已成為新型基礎(chǔ)設(shè)施重要組成部分，本文提供的NBIoT 設(shè)備管理平臺云原生多活技術(shù)在社會治理、鄉(xiāng)村振興、節(jié)能環(huán)保等方面帶來了顯著的社會效益。在社會治理方面，通過系列應(yīng)用，為基礎(chǔ)設(shè)施建設(shè)提供堅實保障，可以有效解決了傳統(tǒng)人工抄表入戶難、計數(shù)不準、管網(wǎng)漏水與水質(zhì)檢測等問題，減少水資源浪費，此外通過創(chuàng)新的應(yīng)用不斷挖掘社會價值；通過城市生命線安全運行監(jiān)測物聯(lián)網(wǎng)，建立全過程、全天候、立體化的城市生命線安全運行監(jiān)測系統(tǒng)，實現(xiàn)多源傳感器信息采集融合，運用城市生命線監(jiān)測數(shù)據(jù)與空間地理信息云融合技術(shù)，實現(xiàn)城市生命線系統(tǒng)風(fēng)險的及時感知、早期預(yù)測預(yù)警、和高效處置應(yīng)對，類似的解決方案和應(yīng)用創(chuàng)新案例不勝枚舉。

通過系列技術(shù)融合創(chuàng)新，持續(xù)優(yōu)化NB-IoT 終端低時延、低功耗、大連接接入，充分發(fā)揮物聯(lián)網(wǎng)在推動數(shù)字經(jīng)濟發(fā)展、賦能傳統(tǒng)產(chǎn)業(yè)轉(zhuǎn)型升級等方面的重要作用，為推進物聯(lián)網(wǎng)新型基礎(chǔ)設(shè)施建設(shè)做出重要貢獻。