根據(jù)預(yù)測,2020年全球物聯(lián)網(wǎng)(IoT)連接設(shè)備數(shù)預(yù)計(jì)將達(dá)到260億臺(tái);而到2025年,該數(shù)字將接近700億。而根據(jù)更為詳細(xì)分析統(tǒng)計(jì),數(shù)量龐大的物聯(lián)網(wǎng)連接中建有60%屬于廣域低功耗(LPWA)連接需求。NB-IoT技術(shù)是3GPP為LPWA領(lǐng)域?qū)iT定制發(fā)布的無線接入標(biāo)準(zhǔn),具備大連接、廣覆蓋、低功耗等諸多優(yōu)點(diǎn)。國內(nèi)NBIoT產(chǎn)業(yè)鏈目前已進(jìn)入快速發(fā)展時(shí)期,應(yīng)用觸角也日漸延伸到智慧家庭、公共服務(wù)、生產(chǎn)制造、可穿戴智能設(shè)備等眾多領(lǐng)域。未來,預(yù)計(jì)將會(huì)有更為龐大數(shù)量的智能終端通過NB-IoT和云端應(yīng)用服務(wù)器交互。
開發(fā)穩(wěn)定優(yōu)良的NB-IoT物聯(lián)網(wǎng)應(yīng)用,需要對(duì)NBIoT的芯片/模組/無線接入深入專研,云端應(yīng)用系統(tǒng)的軟件結(jié)構(gòu)和功能上相應(yīng)的調(diào)整和優(yōu)化也比不可少。部分服務(wù)端系統(tǒng)直接套用移動(dòng)互聯(lián)網(wǎng)應(yīng)用框架開發(fā),雖然實(shí)現(xiàn)了簡單的“云-端”物聯(lián)對(duì)接,但是進(jìn)入大規(guī)模實(shí)施和推廣階段后,會(huì)遇到各種各樣的問題,例如終端耗電大,云端消息丟失嚴(yán)重,功能迭代升級(jí)困難等,NB-IoT的技術(shù)優(yōu)勢也沒有發(fā)揮。
良好的NB-IoT應(yīng)用系統(tǒng),云端應(yīng)用服務(wù)器應(yīng)該考慮終端的行為模式和物聯(lián)網(wǎng)應(yīng)用場景的特點(diǎn)。較為典型的包括如下三個(gè)方面。
(1)云端應(yīng)用匹配NB-IoT終端連接方式。
根據(jù)3GPP規(guī)范,NB-IoT終端使用COAP協(xié)議和應(yīng)用服務(wù)器交互,COAP是專門針對(duì)資源限制型終端(供電/計(jì)算/存儲(chǔ)/網(wǎng)絡(luò)能力弱)的協(xié)議。如云端沿用現(xiàn)有的連接協(xié)議框架和NB-IoT終端對(duì)接,例如MQTT、TCP長連接、HTTP等,會(huì)導(dǎo)致終端程序變得更復(fù)雜、軟硬件研制成本、耗電急劇上升。目前通信運(yùn)營商一般已自建COAP服務(wù)器,應(yīng)用服務(wù)器僅需要通過HTTP和COAP服務(wù)器對(duì)接即可;應(yīng)用云端應(yīng)遵循通信運(yùn)營商的接入指引與自己的終端對(duì)接。
(2)考慮NB-IoT終端能力開放平臺(tái)多個(gè)并存的實(shí)際情況。
大規(guī)模的NB-IoT應(yīng)用中,終端有可能分布在全國廣泛的地區(qū),例如不同地市,不同省份等,需要考慮NBIoT終端可能通過不同途徑接入的現(xiàn)實(shí)情況。例如應(yīng)用大部分終端通過通信運(yùn)營商A的網(wǎng)絡(luò)接入,但特定地域由于信號(hào)覆蓋或價(jià)格原因,當(dāng)?shù)亟K端需接入通信運(yùn)營商B的網(wǎng)絡(luò)。應(yīng)用云端需要考慮兼容不同NB-IoT終端接入和能力開放方式,必要時(shí)需要具備對(duì)接不同通信運(yùn)營商能力開放平臺(tái)的能。同時(shí)在應(yīng)用云端軟件的設(shè)計(jì)上,降低終端接入方式差別對(duì)應(yīng)用功能的影響。
(3)應(yīng)對(duì)NB-IoT終端行為給服務(wù)器造成的沖擊。
廣域低功耗(LPWA)物聯(lián)網(wǎng)應(yīng)用中,數(shù)量眾多的終端有可能加載同一版本程序,行為會(huì)存在有很高的同步性,會(huì)給應(yīng)用服務(wù)器的業(yè)務(wù)處理帶來浪涌沖擊壓力。例如水務(wù)公司下屬數(shù)量眾多的智能表終端,在程序預(yù)設(shè)的時(shí)間點(diǎn)(例如凌晨1:00)集中上報(bào)采集的用水情況數(shù)據(jù)。應(yīng)用服務(wù)器需要短時(shí)間內(nèi)處理大量的上報(bào)信息,如果沒有合適手段應(yīng)對(duì)這種浪涌壓力,會(huì)造成應(yīng)用側(cè)丟失上報(bào)數(shù)據(jù),終端指令錯(cuò)誤,服務(wù)器關(guān)鍵進(jìn)程出錯(cuò)等。同時(shí),龐大數(shù)量終端采集上報(bào)的數(shù)據(jù),隨著應(yīng)用運(yùn)行時(shí)間增加也會(huì)在云端形成數(shù)據(jù)積累現(xiàn)象,如果缺乏良好的處理手段,同樣會(huì)影響應(yīng)用處理的性能。
目前,利用開源軟件搭建企業(yè)級(jí)應(yīng)用系統(tǒng)已經(jīng)成為業(yè)界常態(tài)。隨著開源軟件種類、數(shù)量和質(zhì)量的不斷提升,應(yīng)用系統(tǒng)的開源軟件解決方案在成本、靈活定制、可靠性、快速上線等方面的優(yōu)勢也變得更有吸引力。
豐富的開源軟件也為搭建性能優(yōu)良/運(yùn)行穩(wěn)定/可擴(kuò)展性好的NB-IoT應(yīng)用云端服務(wù)器提供了良好的材料。
NB-IoT應(yīng)用服務(wù)器承擔(dān)用戶交互、終端管理、業(yè)務(wù)處理、數(shù)據(jù)存儲(chǔ)分析等多種功能,也需要和多個(gè)外部網(wǎng)元對(duì)接交互,需要有良好的整體框架設(shè)計(jì),保證各個(gè)功能之間的獨(dú)立、降低開發(fā)難度和易維護(hù)性。
(1)微服務(wù)架構(gòu)(Microservice Architecture)通過將功能分解到各個(gè)離散的服務(wù)(應(yīng)用服務(wù)組件)中以實(shí)現(xiàn)相互之間解耦。單個(gè)應(yīng)用服務(wù)組件僅實(shí)現(xiàn)功能明確定義、處理邏輯清晰的服務(wù),可獨(dú)立開發(fā)/管理迭代。多個(gè)應(yīng)用服務(wù)組件組合承接復(fù)雜的應(yīng)用業(yè)務(wù)邏輯。
(2)起源于主機(jī)虛擬化的容器(Container)技術(shù)為服務(wù)器端的應(yīng)用開發(fā)部署和維護(hù)管理提供了極大的靈活性,也為微服務(wù)的實(shí)現(xiàn)提供了良好的工具。容器為應(yīng)用服務(wù)組件提供了一個(gè)類似于虛擬機(jī)、環(huán)境獨(dú)立的運(yùn)行環(huán)境,并具備快速啟動(dòng)和便捷移植部署的優(yōu)點(diǎn)。
(3)NB-IoT應(yīng)用云端服務(wù)器可劃分為如下幾個(gè)微服務(wù),每個(gè)服務(wù)組件封裝在獨(dú)立的容器中。
●數(shù)據(jù)庫:對(duì)其他組件提供數(shù)據(jù)保存、增刪改的服務(wù)。
●終端連接:專職負(fù)責(zé)與NB-IoT能力開放平臺(tái)對(duì)接,對(duì)上層應(yīng)用屏蔽終端連接方式的差異。
●消息總線/隊(duì)列:在各個(gè)服務(wù)功能組件之間提供消息傳送服務(wù)。
●應(yīng)用業(yè)務(wù)邏輯:容器內(nèi)封裝應(yīng)用業(yè)務(wù)邏輯的實(shí)現(xiàn)代碼。
●服務(wù)器門戶(Portal):提供應(yīng)用的界面功能。
●性能監(jiān)控:收集主機(jī)、各個(gè)服務(wù)功能組件(容器)的運(yùn)行情況以及業(yè)務(wù)日志。
上述不同類型的服務(wù)組件,封裝的容器實(shí)際部署中還可以進(jìn)一步拆分。例如不同數(shù)據(jù)庫,連接不同運(yùn)營商能力開放平臺(tái),不同的門戶(Web/公眾號(hào)/移動(dòng)端)等,可以進(jìn)一步單獨(dú)容器封裝。在實(shí)際部署中,低負(fù)荷的容器可以集中部署在一臺(tái)主機(jī)中,關(guān)鍵/負(fù)荷高的功能組件可單獨(dú)主機(jī)部署,甚至部署在多臺(tái)主機(jī)實(shí)現(xiàn)負(fù)荷分擔(dān)。
(4)目前已有豐富的開源軟件資源幫助搭建“微服務(wù)+容器”的應(yīng)用服務(wù)端系統(tǒng),小型系統(tǒng)中可以僅利用Docker技術(shù),在不同容器中封裝上述各個(gè)功能組件,實(shí)現(xiàn)相互隔離。容器外部通過腳本配置各個(gè)服務(wù)組件容器的啟動(dòng)和連接。隨著微服務(wù)組件數(shù)量的增加和分布式部署,可以利用開源的容器編排軟件,如Kubernetes、Docker Swarm等,完成對(duì)微服務(wù)的集中管理。
NB-IoT應(yīng)用服務(wù)器端功能組件封裝到不同微服務(wù)容器后,可通過消息總線/隊(duì)列服務(wù)組件在微服務(wù)容器之間建立消息傳送管道,進(jìn)一步解耦服務(wù)組件的同時(shí),提升整體系統(tǒng)的處理性能,同時(shí)應(yīng)對(duì)終端集中數(shù)據(jù)上報(bào)造成的浪涌壓力。
(1)應(yīng)用可以參照業(yè)界成熟的消息模型用于應(yīng)用層之間的信息交互。通常消息模型均包含Message(消息體)、Producer(消息生產(chǎn)者)、Consumer(消息消費(fèi)者)、Broker(消息服務(wù)端)等幾個(gè)部分。在此模型中,消息由Producer發(fā)出后,又經(jīng)過Broker路由送至Consumer。應(yīng)用服務(wù)組件(如應(yīng)用業(yè)務(wù)邏輯、終端連接等)以Producer或Consumer身份注冊成為消息隊(duì)列客戶端,成為發(fā)送消息和接收消息的主體;消息的緩存、路由、分發(fā)等操作,由模型中的Broker完成。
(2)有多個(gè)開源軟件實(shí)現(xiàn)了上述消息模型中的Broker功能,如ActiveMQ,Kafka,RabbitMQ等,提供靈活、高效的消息轉(zhuǎn)發(fā)和路由。上述軟件支持通過配置文件(.xml)調(diào)整Broker處理消息隊(duì)列策略,提升轉(zhuǎn)發(fā)消息的性能,例如消息隊(duì)列個(gè)數(shù)/長度,調(diào)整Topics/Partitions數(shù)量(Kafka),優(yōu)化對(duì)處理失敗或者過期的消息處理策略(ActiveMQ)等;同時(shí)上述軟件均提供了開發(fā)接口,不同語言開發(fā)的功能組件遵循接口即可與消息隊(duì)列服務(wù)交互。
(3)以NB-IoT應(yīng)用服務(wù)端系統(tǒng)中,終端上報(bào)信息的處理流程為例,可以通過開源軟件Kafka提供的消息處理,處理終端集中上報(bào)數(shù)據(jù)行為造成的浪涌沖擊。(如圖1所示)
圖1
在浪涌高峰時(shí)間點(diǎn),負(fù)責(zé)與通信運(yùn)營商能力開發(fā)平臺(tái)對(duì)接的功能組件以消息Producer的身份接入Kafka,收到終端上報(bào)消息后不做復(fù)雜的處理直接放入消息隊(duì)列,避免業(yè)務(wù)邏輯處理不及時(shí)造成上報(bào)消息丟失,緩解應(yīng)用業(yè)務(wù)邏輯功能組件的處理壓力;Consumer端運(yùn)行與Partition數(shù)量相同應(yīng)用業(yè)務(wù)邏輯功能組件,同時(shí)內(nèi)部啟動(dòng)多條線程并發(fā)處理隊(duì)列送來的消息。利用上述消息處理機(jī)制可有效提升云端應(yīng)用的消息處理能力,在業(yè)務(wù)忙時(shí)可應(yīng)對(duì)閑時(shí)運(yùn)行幾十倍的浪涌壓力。
數(shù)據(jù)庫是每個(gè)信息應(yīng)用系統(tǒng)必不可少的部分,包括NB-IoT應(yīng)用云端服務(wù)器。NB-IoT應(yīng)用的特性決定了隨著系統(tǒng)運(yùn)行時(shí)間的增加,終端數(shù)量/采集數(shù)據(jù)/監(jiān)控?cái)?shù)據(jù)在云端的累積也會(huì)急劇增加,單一的關(guān)系型數(shù)據(jù)庫在應(yīng)對(duì)數(shù)據(jù)I/O、海量數(shù)據(jù)分析、NoSql數(shù)據(jù)存儲(chǔ)、全文數(shù)據(jù)檢索等方面會(huì)面臨瓶頸。應(yīng)用云端需要有完備的策略來應(yīng)對(duì)這種壓力,而細(xì)分?jǐn)?shù)據(jù)的類型和用途區(qū)別處理是其中的關(guān)鍵。
開源軟件中已有很多高質(zhì)量數(shù)據(jù)庫軟件,包括關(guān)系型數(shù)據(jù)庫MySql,PostgreSQL;非關(guān)系型數(shù)據(jù)庫MongoDB、Redis;還有如建立在Apache Lucene? 基礎(chǔ)上的搜索引擎Elasticsearch,這些軟件專注于不同的數(shù)據(jù)處理細(xì)分領(lǐng)域。應(yīng)用云端可以根據(jù)數(shù)據(jù)類型和用途的差異,針對(duì)性的選用不同開源數(shù)據(jù)庫,讓NB-IoT應(yīng)用系統(tǒng)具備更良好的運(yùn)行性能,同時(shí)發(fā)掘數(shù)據(jù)中的更多價(jià)值。
(1)使用關(guān)系型數(shù)據(jù)庫如Mysql、PostgreSQL等支撐云端應(yīng)用基本功能的運(yùn)行,例如業(yè)務(wù)邏輯、UI界面等。關(guān)系型數(shù)據(jù)庫配套的開發(fā)資源十分豐富,從需求分析到系統(tǒng)設(shè)計(jì),從開發(fā)語言接口到優(yōu)良代碼框架都有成熟的資源,可以有效提升開發(fā)效率和代碼質(zhì)量。
(2)系統(tǒng)中需要頻繁讀寫、快速返回檢索結(jié)果的業(yè)務(wù)數(shù)據(jù),放入memcache、redis等支持內(nèi)存緩存的數(shù)據(jù)庫單獨(dú)管理,避免加重RDBMS負(fù)擔(dān),致使服務(wù)器響應(yīng)惡化,影響應(yīng)用系統(tǒng)的整體功能。例如,NB-IoT應(yīng)用到不同能力開放平臺(tái)的連接token、服務(wù)功能組件之間消息路由策略數(shù)據(jù)、系統(tǒng)公共參數(shù)等。如redis支持內(nèi)存保存數(shù)據(jù),并對(duì)外提供遠(yuǎn)高于Mysql的高速查詢服務(wù)。
(3)利用NoSql數(shù)據(jù)庫存儲(chǔ)隨著應(yīng)用系統(tǒng)運(yùn)行累積產(chǎn)生的數(shù)據(jù),包括終端歷史上報(bào)累積的數(shù)據(jù),進(jìn)程產(chǎn)生的業(yè)務(wù)日志等。針對(duì)此類數(shù)據(jù)的查詢和復(fù)雜分析需求,也均由NoSql數(shù)據(jù)庫,降低RDBMS負(fù)荷。同時(shí)大量NoSql形式的原始信息存儲(chǔ)更為直接方便,Nosql數(shù)據(jù)的分析和檢索也有豐富的開源工具,如Mongdo和Elasticsearch均支持更為靈活的分析聚合,也能進(jìn)行復(fù)雜的數(shù)據(jù)建模。
結(jié)合容器和消息隊(duì)列的使用,組合不同開源數(shù)據(jù)庫軟件并不需要增加太多的開發(fā)工作,卻能幫助NB-IoT應(yīng)用系統(tǒng)能更有效應(yīng)對(duì)業(yè)務(wù)量的增長。
目前,豐富的開源軟件為開發(fā)者提供了大量的功能組件“素材”,而對(duì)NB-IoT技術(shù)特性和終端行為特點(diǎn)的充分了解和仔細(xì)分析,是幫助開發(fā)者選取合適“素材”搭建穩(wěn)固、高效的NB-IoT應(yīng)用云端服務(wù)器的基礎(chǔ)。