梁 曉，龍 妍，張 川

（1.廣西開放大學(xué)，廣西 南寧 530022；2.南寧職業(yè)技術(shù)學(xué)院，廣西 南寧 530008；3.廣西衡安睿建數(shù)字科技有限公司，廣西 南寧 530021）

0 引言

近些年隨著物聯(lián)網(wǎng)（Internet of Things，簡稱IoT）技術(shù)的發(fā)展，物聯(lián)網(wǎng)產(chǎn)品的種類日益豐富，應(yīng)用也越發(fā)普及，給人們工作和生活帶來很多便利。在互聯(lián)網(wǎng)的普及，云計(jì)算、大數(shù)據(jù)、手機(jī)APP等新技術(shù)的促進(jìn)下，物聯(lián)網(wǎng)系統(tǒng)的架構(gòu)體系逐漸朝著平臺(tái)化方向發(fā)展。同時(shí)物聯(lián)網(wǎng)具有多學(xué)科綜合性，其涉及的技術(shù)多種多樣，導(dǎo)致涉及的標(biāo)準(zhǔn)也非常多，物聯(lián)網(wǎng)產(chǎn)業(yè)面臨著行業(yè)標(biāo)準(zhǔn)尚未統(tǒng)一的問題。[1]不同類型、不同廠商甚至不同應(yīng)用場(chǎng)景的物聯(lián)網(wǎng)終端的組網(wǎng)方式和接入?yún)f(xié)議都可能存在差異。為了適應(yīng)這一變化和規(guī)范物聯(lián)網(wǎng)產(chǎn)業(yè)，國內(nèi)外各大互聯(lián)網(wǎng)企業(yè)紛紛推出自己的物聯(lián)網(wǎng)平臺(tái)，例如Google的Android Things、亞馬遜的AWS IoT、百度的天工、阿里巴巴集團(tuán)的阿里云物聯(lián)網(wǎng)套件、騰訊的物聯(lián)網(wǎng)通信服務(wù)等。這些物聯(lián)網(wǎng)平臺(tái)都希望通過建立物聯(lián)網(wǎng)終端的接入標(biāo)準(zhǔn)，實(shí)現(xiàn)設(shè)備數(shù)據(jù)采集上傳云端并在云平臺(tái)上集成物聯(lián)網(wǎng)各種應(yīng)用場(chǎng)景的解決方案，從而構(gòu)建物聯(lián)網(wǎng)的生態(tài)鏈。

眾多平臺(tái)的出現(xiàn)的確給物聯(lián)系統(tǒng)的運(yùn)營帶來便利，然而對(duì)于產(chǎn)品研發(fā)初期的中小型物聯(lián)網(wǎng)企業(yè)，研發(fā)的效率直接影響市場(chǎng)競爭力。[2]當(dāng)遇到缺乏硬件產(chǎn)業(yè)鏈支持和研發(fā)團(tuán)隊(duì)尚未成熟的情況時(shí)，物聯(lián)網(wǎng)硬件產(chǎn)品的研發(fā)重點(diǎn)往往優(yōu)先考慮產(chǎn)品的創(chuàng)新多樣，導(dǎo)致產(chǎn)品無法主動(dòng)適應(yīng)各大物聯(lián)網(wǎng)平臺(tái)的接入規(guī)范；當(dāng)企業(yè)需要根據(jù)市場(chǎng)發(fā)展方向反復(fù)調(diào)整產(chǎn)品的功能需求時(shí)，傳統(tǒng)的物聯(lián)網(wǎng)平臺(tái)往往不能做到及時(shí)適應(yīng)產(chǎn)品研發(fā)和運(yùn)營的變化。因此，有必要設(shè)計(jì)和實(shí)現(xiàn)一種適用于多種接入方式的高擴(kuò)展性物聯(lián)網(wǎng)服務(wù)器架構(gòu)，保障各種類型的終端快速接入系統(tǒng)，以滿足物聯(lián)網(wǎng)產(chǎn)品研發(fā)對(duì)物聯(lián)網(wǎng)平臺(tái)的需求。

1 物聯(lián)網(wǎng)服務(wù)器架構(gòu)設(shè)計(jì)

1.1 傳統(tǒng)物聯(lián)網(wǎng)服務(wù)器架構(gòu)

傳統(tǒng)的物聯(lián)網(wǎng)利用各種低功耗廣域網(wǎng)絡(luò)（Low Power Wide Area Network，簡稱LPWAN）進(jìn)行數(shù)據(jù)傳輸，上位機(jī)依照傳輸協(xié)議接收和處理下位機(jī)傳送的數(shù)據(jù)，并對(duì)下位機(jī)發(fā)出控制指令。在互聯(lián)網(wǎng)環(huán)境下的物聯(lián)網(wǎng)系統(tǒng)中，上位機(jī)是設(shè)備終端信息傳遞的關(guān)鍵模塊，主要負(fù)責(zé)接收終端設(shè)備的網(wǎng)絡(luò)數(shù)據(jù)進(jìn)行業(yè)務(wù)邏輯處理，對(duì)數(shù)據(jù)進(jìn)行加工后存儲(chǔ)到數(shù)據(jù)存儲(chǔ)系統(tǒng)，并接受管理后臺(tái)的控制。在當(dāng)前互聯(lián)網(wǎng)應(yīng)用場(chǎng)景下上位機(jī)需要承載大量終端設(shè)備，系統(tǒng)將面臨著高并發(fā)連接和海量數(shù)據(jù)處理的壓力。因此需要對(duì)物聯(lián)網(wǎng)系統(tǒng)功能模塊進(jìn)行解耦，設(shè)計(jì)合理的服務(wù)器架構(gòu)，利用服務(wù)器集群資源分解壓力才能保障系統(tǒng)的正常運(yùn)行。

傳統(tǒng)物聯(lián)網(wǎng)服務(wù)器架構(gòu)如圖1所示。其中DNS域名解析負(fù)責(zé)對(duì)網(wǎng)關(guān)服務(wù)器集群進(jìn)行負(fù)載均衡；網(wǎng)關(guān)服務(wù)器（Gateway Server）主要負(fù)責(zé)分流終端設(shè)備的網(wǎng)絡(luò)連接，對(duì)網(wǎng)絡(luò)數(shù)據(jù)進(jìn)行收發(fā)、拆包、加解密、校驗(yàn)和過濾等邏輯處理后傳遞給中心服務(wù)器（Center Server）；中心服務(wù)器負(fù)責(zé)將數(shù)據(jù)按業(yè)務(wù)邏輯處理后把需要存儲(chǔ)的數(shù)據(jù)傳輸?shù)綌?shù)據(jù)庫服務(wù)器（DB Server）中，并從數(shù)據(jù)庫中讀取后臺(tái)控制指令后通過網(wǎng)關(guān)服務(wù)器下發(fā)到終端設(shè)備；數(shù)據(jù)庫服務(wù)器主要負(fù)責(zé)將數(shù)據(jù)寫入數(shù)據(jù)庫（Database）中。系統(tǒng)后臺(tái)網(wǎng)站負(fù)責(zé)終端設(shè)備數(shù)據(jù)的展示和管理，并向手機(jī)APP等應(yīng)用提供服務(wù)接口。手機(jī)APP負(fù)責(zé)向用戶展示數(shù)據(jù)和操控終端設(shè)備。

整個(gè)架構(gòu)按從功能模塊上主要分為4個(gè)模塊：

（1）網(wǎng)絡(luò)模塊，負(fù)責(zé)面向終端設(shè)備的網(wǎng)絡(luò)連接。模塊通過在DNS域名管理中配置多個(gè)網(wǎng)關(guān)服務(wù)器的A記錄，利用DNS基于地理位置的域名解析完成網(wǎng)關(guān)服務(wù)器負(fù)載均衡。通過網(wǎng)關(guān)服務(wù)器集群分流了終端設(shè)備，從而提高了系統(tǒng)對(duì)終端設(shè)備在線數(shù)量的承載力。

（2）業(yè)務(wù)邏輯模塊，架構(gòu)的核心模塊。中心服務(wù)器對(duì)接收到的設(shè)備數(shù)據(jù)加工后通過數(shù)據(jù)模塊進(jìn)行存儲(chǔ)，并按業(yè)務(wù)邏輯通過網(wǎng)絡(luò)模塊向終端設(shè)備發(fā)送指令。

（3）數(shù)據(jù)模塊，負(fù)責(zé)對(duì)數(shù)據(jù)進(jìn)行存儲(chǔ)。通過數(shù)據(jù)庫服務(wù)器利用讀寫分離、間接批量寫入等技術(shù)方式把數(shù)據(jù)寫入數(shù)據(jù)庫中，緩解架構(gòu)面對(duì)海量數(shù)據(jù)存儲(chǔ)的壓力。

（4）后臺(tái)管理模塊，負(fù)責(zé)系統(tǒng)的業(yè)務(wù)管理功能。后臺(tái)網(wǎng)站主要面向管理員提供終端設(shè)備的管理，手機(jī)APP主要面向用戶提供終端設(shè)備的管理。

該架構(gòu)有效地解決了互聯(lián)網(wǎng)環(huán)境下大量終端設(shè)備帶來的系統(tǒng)壓力，但在實(shí)際應(yīng)用中還存在以下問題：

（1）系統(tǒng)功能擴(kuò)展性不足，架構(gòu)面對(duì)功能需要擴(kuò)展或改變時(shí)彈性不足。當(dāng)前物聯(lián)網(wǎng)系統(tǒng)朝著支持多種應(yīng)用場(chǎng)景、多種類型設(shè)備接入的綜合性系統(tǒng)的方向發(fā)展，當(dāng)有新的終端設(shè)備接入或系統(tǒng)需要加入其他平臺(tái)聯(lián)合運(yùn)營時(shí)，網(wǎng)關(guān)服務(wù)器和中心服務(wù)器不可避免地需要調(diào)整功能，架構(gòu)需要迭代才能滿足新的業(yè)務(wù)需求，缺乏高可用性。

（2）系統(tǒng)承載能力不足，架構(gòu)里終端設(shè)備的數(shù)據(jù)包經(jīng)過網(wǎng)關(guān)服務(wù)器接收和校驗(yàn)后直接傳遞給中心服務(wù)器進(jìn)行業(yè)務(wù)邏輯處理，適合面對(duì)流量相對(duì)平穩(wěn)的業(yè)務(wù)。但當(dāng)每秒事務(wù)處理數(shù)（Transactions Per Second，簡稱TPS）發(fā)生激增時(shí)，架構(gòu)缺乏削峰填谷的手段，容易造成數(shù)據(jù)因處理不及時(shí)而發(fā)生擠壓，導(dǎo)致整個(gè)系統(tǒng)癱瘓。

（3）缺乏服務(wù)器之間通訊的手段。后臺(tái)網(wǎng)站和中心服務(wù)器由于使用不同的編程技術(shù)和隸屬于不同模塊，它們之間沒有直接的數(shù)據(jù)連接，當(dāng)業(yè)務(wù)模塊有指令需要下達(dá)給終端設(shè)備時(shí)，往往使用數(shù)據(jù)庫作為中轉(zhuǎn)。如表1所示，后臺(tái)網(wǎng)站將需要發(fā)送的指令數(shù)據(jù)存入數(shù)據(jù)庫的指令下發(fā)表中，中心服務(wù)器需要反復(fù)地查詢表中數(shù)據(jù)，并在設(shè)備在線時(shí)把指令下發(fā)。該方式效率低且不優(yōu)雅，難以勝任復(fù)雜的業(yè)務(wù)流程，例如第三方平臺(tái)身份驗(yàn)證、充值、計(jì)費(fèi)等功能。

表1 指令下發(fā)表

因此，需要對(duì)該服務(wù)器框架做進(jìn)一步的改進(jìn)以滿足系統(tǒng)需求?？紤]到中小企業(yè)研發(fā)力量有限的問題，架構(gòu)在技術(shù)上盡量考慮使用成熟的第三方組件，同時(shí)根據(jù)物聯(lián)網(wǎng)應(yīng)用場(chǎng)景的特點(diǎn)和系統(tǒng)運(yùn)營的需求對(duì)架構(gòu)做進(jìn)一步解耦，使框架具備高擴(kuò)展性和高伸縮性，以便能快速完成新終端設(shè)備和新平臺(tái)的接入等擴(kuò)展功能。

1.2 消息列隊(duì)

消息列隊(duì)是分布式系統(tǒng)中重要的組件，眾多成功案例證明消息列隊(duì)能優(yōu)化系統(tǒng)架構(gòu)和提高系統(tǒng)抗壓性能，[3-4]起到降低架構(gòu)的耦合性及削峰填谷的作用。成熟的消息列隊(duì)例如Kafka、RabbitMQ、ZeroMQ等，各有特點(diǎn)及適合運(yùn)用場(chǎng)景。從中小型物聯(lián)網(wǎng)企業(yè)對(duì)系統(tǒng)架構(gòu)伸縮性的需求上分析，要求具備以下的特點(diǎn)：

（1）系統(tǒng)研發(fā)期架構(gòu)的部署盡可能簡單。架構(gòu)中的所有模塊能同時(shí)運(yùn)行在同一臺(tái)服務(wù)器設(shè)備上，以降低研發(fā)所需硬件資源，程序應(yīng)方便安裝、運(yùn)行、升級(jí)和演示。

（2）系統(tǒng)運(yùn)營期可根據(jù)生產(chǎn)情況進(jìn)行調(diào)整架構(gòu)部署。在系統(tǒng)運(yùn)營初期系統(tǒng)壓力較小的情況下，架構(gòu)可以減少部署所需服務(wù)器設(shè)備甚至多個(gè)系統(tǒng)同時(shí)部署在一臺(tái)服務(wù)器上，以便節(jié)約資源，降低運(yùn)營成本和減少維護(hù)工作量；當(dāng)系統(tǒng)壓力較大時(shí)可根據(jù)情況增加服務(wù)器設(shè)備及網(wǎng)絡(luò)資源，以集群部署實(shí)現(xiàn)高可用性和吞吐量，提高系統(tǒng)的承載力。

（3）系統(tǒng)支持多種程序編碼語言。從敏捷開發(fā)的角度上開發(fā)主要以人為核心，系統(tǒng)是迭代和循序漸進(jìn)的開發(fā)方法。[5-6]架構(gòu)在研發(fā)初期常會(huì)遇到編碼語言和運(yùn)行平臺(tái)不統(tǒng)一，需要取舍以優(yōu)先保證研發(fā)速度的情況。

考慮到系統(tǒng)要求滿足支持多編解碼和跨語言跨平臺(tái)、支持多種連接方式、各組件相互獨(dú)立和組件熱插拔的條件，選用ZeroMQ作為架構(gòu)的消息列隊(duì)。

ZeroMQ支持在同一進(jìn)程中的不同線程之間（inproc）、本地進(jìn)程之間（ipc）、遠(yuǎn)程進(jìn)程之間（TCP）等數(shù)據(jù)傳輸方式，支持Request-Reply、Publish-Subscribe、Parallel Pipeline等模式，支持Router-Dealer、Router-Req、Router-Rep等消息轉(zhuǎn)發(fā)方式（Broker），以及使用多段消息的信封機(jī)制（Message Envelopes）。[7]通過這些特性可以改進(jìn)架構(gòu)里請(qǐng)求-響應(yīng)（Request Client-Reply Server）模型，并利用ROUTER對(duì)架構(gòu)中的網(wǎng)關(guān)服務(wù)器和中心服務(wù)器的全互聯(lián)連接模式進(jìn)行簡化。在實(shí)際運(yùn)用中，為了方便管理網(wǎng)絡(luò)中的服務(wù)器和數(shù)據(jù)的走向，需要人工對(duì)服務(wù)器設(shè)置唯一的標(biāo)識(shí)。如下代碼所示，初始化ZeroMQ對(duì)象成功后，利用zmq_setsockopt接口設(shè)置ZMQ_IDENTITY屬性綁定服務(wù)器標(biāo)識(shí)。當(dāng)Broker收到ZMQ傳遞的數(shù)據(jù)時(shí)，通過標(biāo)識(shí)可以判斷數(shù)據(jù)來源及控制數(shù)據(jù)走向。

設(shè)置ZMQ對(duì)象標(biāo)識(shí)代碼：

//以DEALER模式初始化ZMQ對(duì)象

auto server=zmq_socket(_context,ZMQ_DEALER);

if(server==nullptr)

{

return nullptr;

}

//設(shè)置zmq對(duì)象標(biāo)識(shí)

if(zmq_setsockopt(server,ZMQ_IDENTITY,&_id,sizeof(uint8_t))!=0)

{

return nullptr;

}

對(duì)架構(gòu)的所有服務(wù)器進(jìn)行標(biāo)識(shí)管理后，通過ROUTER模式可以設(shè)計(jì)Broker作為所有數(shù)據(jù)的轉(zhuǎn)發(fā)層。如圖2所示，架構(gòu)中所有服務(wù)器都通過DEALER模式連接上消息轉(zhuǎn)發(fā)服務(wù)器（Broker Server），1號(hào)服務(wù)器并不直接連接10號(hào)服務(wù)器。當(dāng)1號(hào)服務(wù)器收到網(wǎng)絡(luò)數(shù)據(jù)后，需要把數(shù)據(jù)傳遞給10號(hào)服務(wù)器進(jìn)行業(yè)務(wù)處理時(shí)，數(shù)據(jù)是先通過Router-Dealer的連接投遞給消息轉(zhuǎn)發(fā)服務(wù)器，通過消息列隊(duì)的負(fù)載均衡處理后，再發(fā)送到10號(hào)服務(wù)器上。

架構(gòu)中消息轉(zhuǎn)發(fā)服務(wù)器起到中間層的作用，所有數(shù)據(jù)傳遞都通過其進(jìn)行中轉(zhuǎn)。對(duì)于Socket服務(wù)器內(nèi)部，無論是IOCP還是EPOLL模型，都需要使用I/O線程池處理Socket事件。如果多線程環(huán)境使用同一個(gè)ZeroMQ對(duì)象與Broker交換數(shù)據(jù)，將不可避免地需要對(duì)其加鎖防止資源競爭，從而影響處理Socket事件的效率。為了避免產(chǎn)生額外的開銷，在每個(gè)I/O線程創(chuàng)建后根據(jù)線程ID關(guān)聯(lián)一個(gè)ZeroMQ對(duì)象，以inproc連接方式把數(shù)據(jù)發(fā)送到消息線程。在消息線程中采用zmq_poll處理連接信號(hào)，把I/O線程數(shù)據(jù)再統(tǒng)一發(fā)送給Broker。如圖3所示，由于每個(gè)I/O線程都使用專用的ZeroMQ對(duì)象，無需再使用加鎖影響數(shù)據(jù)的收發(fā)，實(shí)現(xiàn)無鎖消息發(fā)送模型。

通過消息列隊(duì)的設(shè)計(jì)，架構(gòu)中所有模塊都直接通過消息轉(zhuǎn)發(fā)服務(wù)器轉(zhuǎn)發(fā)數(shù)據(jù)，解耦了架構(gòu)中的網(wǎng)絡(luò)連接，連接數(shù)從M×N簡化為M+N，降低了架構(gòu)的網(wǎng)絡(luò)復(fù)雜度。同時(shí)由于ZeroMQ的連接和收發(fā)的透明性程度高，提高了架構(gòu)的橫向擴(kuò)展性。在系統(tǒng)抗壓性方面，數(shù)據(jù)在消息轉(zhuǎn)發(fā)服務(wù)器通過消息列隊(duì)和負(fù)載均衡處理，起到了削峰填谷的作用。雖然數(shù)據(jù)中轉(zhuǎn)產(chǎn)生了系統(tǒng)性能上額外的開銷，但各個(gè)模塊與消息轉(zhuǎn)發(fā)服務(wù)器的連接處于內(nèi)網(wǎng)環(huán)境下，數(shù)據(jù)因中轉(zhuǎn)投遞帶來的延時(shí)對(duì)于物聯(lián)網(wǎng)系統(tǒng)可以忽略。

1.3 內(nèi)存數(shù)據(jù)庫

通過消息列隊(duì)優(yōu)化了架構(gòu)中的數(shù)據(jù)傳遞，使得系統(tǒng)可以通過分布式的方式靈活實(shí)現(xiàn)業(yè)務(wù)邏輯的拆分。當(dāng)對(duì)復(fù)雜的業(yè)務(wù)邏輯通過拆分解耦時(shí)，架構(gòu)中拆分出來的多個(gè)服務(wù)器會(huì)產(chǎn)生對(duì)訪問同一組數(shù)據(jù)的需求。常規(guī)數(shù)據(jù)共享的解決方案中，無論是通過服務(wù)器之間的數(shù)據(jù)交換還是通過數(shù)據(jù)庫中轉(zhuǎn)，都影響系統(tǒng)的運(yùn)行效率和提高研發(fā)的復(fù)雜度。而內(nèi)存數(shù)據(jù)庫的出現(xiàn)，提供了一種解決分布式架構(gòu)下數(shù)據(jù)共享的有效方法。[8]在眾多內(nèi)存數(shù)據(jù)庫產(chǎn)品中，Redis作為開源的高性能鍵值對(duì)（key-value）內(nèi)存數(shù)據(jù)庫，可以在系統(tǒng)中可以起到作數(shù)據(jù)庫、緩存和消息中間件的作用。通過Redis對(duì)架構(gòu)中的存儲(chǔ)模塊進(jìn)行改進(jìn)，可以降低數(shù)據(jù)庫的查詢量和提高數(shù)據(jù)訪問速度。[9]

架構(gòu)引入Redis后系統(tǒng)邏輯的關(guān)鍵數(shù)據(jù)應(yīng)盡可能加載到Redis后再對(duì)其進(jìn)行操作。當(dāng)服務(wù)器需要操作數(shù)據(jù)時(shí)，先請(qǐng)求Redis判斷數(shù)據(jù)是否存在，如果不存在就先從數(shù)據(jù)庫中把數(shù)據(jù)讀取出來并初始化到Redis中，數(shù)據(jù)根據(jù)業(yè)務(wù)邏輯運(yùn)算過后，需要對(duì)Redis的數(shù)據(jù)進(jìn)行更新，同時(shí)更新數(shù)據(jù)庫，如圖4所示。

由于服務(wù)器的業(yè)務(wù)數(shù)據(jù)不再存儲(chǔ)在進(jìn)程內(nèi)存里，雖然增加了研發(fā)的工作量和代碼復(fù)雜度，但新增的Redis模塊給整個(gè)架構(gòu)帶來了以下優(yōu)勢(shì)：

（1）提供便捷的數(shù)據(jù)共享方式。當(dāng)系統(tǒng)需要接入其他平臺(tái)運(yùn)營時(shí)，可以在不改變系統(tǒng)原有服務(wù)器的情況下，通過增加一個(gè)平臺(tái)業(yè)務(wù)邏輯服務(wù)器，通過Redis輕松完成數(shù)據(jù)的共享。同時(shí)數(shù)據(jù)共享也為復(fù)雜的跨服務(wù)器業(yè)務(wù)流程開發(fā)提供了方便。

（2）引入數(shù)據(jù)容災(zāi)機(jī)制。一般服務(wù)器上數(shù)據(jù)存儲(chǔ)在服務(wù)器進(jìn)程的內(nèi)存中，當(dāng)服務(wù)器程序崩潰時(shí)業(yè)務(wù)數(shù)據(jù)有可能丟失。此時(shí)數(shù)據(jù)存儲(chǔ)在Redis中，服務(wù)器發(fā)生崩潰并不會(huì)影響到數(shù)據(jù)，只需要重啟服務(wù)器即可恢復(fù)生產(chǎn)狀態(tài)。同時(shí)Redis自帶數(shù)據(jù)永久化功能，保證了架構(gòu)的健壯性。[10]

1.4 高擴(kuò)展物聯(lián)網(wǎng)服務(wù)器架構(gòu)

針對(duì)物聯(lián)網(wǎng)復(fù)合型平臺(tái)系統(tǒng)的特點(diǎn)以及當(dāng)前中小企業(yè)研發(fā)的需求，通過ZeroMQ、Redis等技術(shù)對(duì)原有架構(gòu)進(jìn)行改造，為架構(gòu)提供數(shù)據(jù)列隊(duì)、數(shù)據(jù)交換、數(shù)據(jù)共享等服務(wù)，使架構(gòu)具有高擴(kuò)展性。消息轉(zhuǎn)發(fā)服務(wù)器作為架構(gòu)的核心以星形拓?fù)錇槠渌?wù)器提供數(shù)據(jù)交換服務(wù)，并通過標(biāo)識(shí)對(duì)其他服務(wù)器進(jìn)行管理，如圖5所示。架構(gòu)把不同終端設(shè)備的服務(wù)器進(jìn)行分組，根據(jù)終端設(shè)備的特點(diǎn)來規(guī)劃服務(wù)器組的功能需求。如設(shè)備1服務(wù)器組作為傳統(tǒng)的網(wǎng)關(guān)服務(wù)器加中心服務(wù)器的組合；設(shè)備2服務(wù)器組作為兼容消息隊(duì)列遙測(cè)傳輸（MQTT）協(xié)議，并為第三方物聯(lián)網(wǎng)平臺(tái)提供交互數(shù)據(jù)的組合。不同服務(wù)器組之間相互獨(dú)立，架構(gòu)可以根據(jù)業(yè)務(wù)需求添加新的服務(wù)器組，以豐富系統(tǒng)功能，實(shí)現(xiàn)復(fù)合型物聯(lián)網(wǎng)平臺(tái)。

架構(gòu)中的服務(wù)器與消息轉(zhuǎn)發(fā)服務(wù)器都使用相同的ZeroMQ連接模型，減輕了開發(fā)工作量，使開發(fā)團(tuán)隊(duì)可以把精力集中在業(yè)務(wù)邏輯上。消息轉(zhuǎn)發(fā)服務(wù)器作為系統(tǒng)的核心只負(fù)責(zé)維護(hù)數(shù)據(jù)列隊(duì)和數(shù)據(jù)交換，不涉及復(fù)雜業(yè)務(wù)邏輯，避免因崩潰引發(fā)整個(gè)系統(tǒng)的癱瘓。Redis內(nèi)存服務(wù)器提供了便捷的數(shù)據(jù)共享及容災(zāi)機(jī)制，保證了架構(gòu)的健壯性。經(jīng)過優(yōu)化的架構(gòu)具有高擴(kuò)展性，可快速接入新的功能模塊，如根據(jù)業(yè)務(wù)和運(yùn)維需求添加第三方支付功能、日志管理和服務(wù)監(jiān)控功能等模塊，以保障當(dāng)前物聯(lián)網(wǎng)系統(tǒng)整個(gè)生命周期的功能需求。

2 測(cè)試與分析

為了保證測(cè)試環(huán)境的廣泛性，本文采用常見的云服務(wù)器ECS(Elastic Compute Service)作為測(cè)試服務(wù)器，在不改變操作系統(tǒng)默認(rèn)配置的情況下僅對(duì)程序使用-O3優(yōu)化的情況下測(cè)試架構(gòu)的測(cè)試環(huán)境。測(cè)試模擬物聯(lián)網(wǎng)系統(tǒng)典型的事務(wù)流程，以下位機(jī)通過TCP協(xié)議連接平臺(tái)后發(fā)送64 Byte字節(jié)的上報(bào)數(shù)據(jù)，服務(wù)器進(jìn)行數(shù)據(jù)解析并模擬數(shù)據(jù)寫入數(shù)據(jù)庫后返回16 Byte字節(jié)的數(shù)據(jù)為一完整事務(wù)流程，對(duì)架構(gòu)進(jìn)行ping-pong測(cè)試。

為了測(cè)試架構(gòu)的伸縮性，測(cè)試分成兩個(gè)方向進(jìn)行，分別測(cè)試架構(gòu)的橫向擴(kuò)展性和縱向擴(kuò)展性。在橫向擴(kuò)展性方面，把測(cè)試服務(wù)器分成單機(jī)模式和群組模式進(jìn)行對(duì)比測(cè)試。兩組測(cè)試模式的服務(wù)器配置如表2所示，服務(wù)器實(shí)例的CPU為Intel Xeon(Cascade Lake)Platinum 8269，其中單機(jī)模式把架構(gòu)中所有模塊都部署在同一臺(tái)服務(wù)器上運(yùn)行；群組模式采用服務(wù)器群組架構(gòu)，并按模塊的運(yùn)行特點(diǎn)對(duì)硬件配置進(jìn)行了調(diào)整。

表2 測(cè)試服務(wù)器配置表

在縱向擴(kuò)展性方面，通過調(diào)整架構(gòu)服務(wù)器端線程的數(shù)量來測(cè)試在不同線程數(shù)目下架構(gòu)的性能。服務(wù)器端的I/O線程和Worker線程開啟數(shù)量分別為2線程、4線程、CPU個(gè)數(shù)+2線程數(shù)。兩種測(cè)試方向的測(cè)試結(jié)果如圖6～圖7所示，架構(gòu)在多線程和群組模式下的性能良好，群組模式和提升線程數(shù)都能提升架構(gòu)的TPS。而由于組群模式下數(shù)據(jù)包需要在不同服務(wù)器實(shí)例之間傳遞，導(dǎo)致事務(wù)的響應(yīng)時(shí)間（Response Time，簡稱RT）要大于單機(jī)模式，但通過調(diào)整線程數(shù)量的方式，提高系統(tǒng)的事務(wù)處理速度來緩解其帶來的影響。

測(cè)試結(jié)果表明，架構(gòu)的配置非常靈活。架構(gòu)在單機(jī)模式下可用于研發(fā)、測(cè)試和演示環(huán)境，為企業(yè)降低研發(fā)成本。在群組模式下，架構(gòu)表現(xiàn)出了良好的事務(wù)吞吐量，可用于生產(chǎn)環(huán)境并有充足的擴(kuò)展空間。整個(gè)架構(gòu)只需要更改部署方式就能快速切換工作場(chǎng)景，顯示了良好的擴(kuò)展性，適用于物聯(lián)網(wǎng)平臺(tái)的搭建。

3 結(jié)語

本文針對(duì)當(dāng)前復(fù)合型物聯(lián)網(wǎng)平臺(tái)功能需求的特點(diǎn)，基于ZeroMQ和Redis技術(shù)對(duì)傳統(tǒng)物聯(lián)網(wǎng)服務(wù)器架構(gòu)進(jìn)行解耦，設(shè)計(jì)和實(shí)現(xiàn)了一種高擴(kuò)展性物聯(lián)網(wǎng)服務(wù)器架構(gòu)。使物聯(lián)網(wǎng)系統(tǒng)具有分布式系統(tǒng)的橫向擴(kuò)展性，滿足中小型物聯(lián)網(wǎng)企業(yè)對(duì)產(chǎn)品研發(fā)和運(yùn)營的要求，為靈活地接入多種物聯(lián)網(wǎng)終端設(shè)備及與第三方平臺(tái)聯(lián)運(yùn)提供保障。該架構(gòu)已接入智能路燈、智能充電樁、智能安檢門等多種終端設(shè)備，并與第三方智慧城市管理系統(tǒng)和充電平臺(tái)進(jìn)行了數(shù)據(jù)對(duì)接，整個(gè)系統(tǒng)在生產(chǎn)環(huán)境中運(yùn)行狀態(tài)良好，達(dá)到了設(shè)計(jì)目標(biāo)。