基于微服務(wù)架構(gòu)的物聯(lián)網(wǎng)應(yīng)用基礎(chǔ)框架設(shè)計(jì)

吳昌雨，李云松，劉 青，王善勤

滁州職業(yè)技術(shù)學(xué)院信息工程系，安徽滁州,239000

基于微服務(wù)架構(gòu)的物聯(lián)網(wǎng)應(yīng)用基礎(chǔ)框架設(shè)計(jì)

吳昌雨，李云松，劉 青，王善勤

滁州職業(yè)技術(shù)學(xué)院信息工程系，安徽滁州,239000

為構(gòu)建具有分布式、開放式特性的物聯(lián)網(wǎng)生態(tài)系統(tǒng)，提出了基于微服務(wù)架構(gòu)(MSA,Micro-service Architecture)的物聯(lián)網(wǎng)應(yīng)用基礎(chǔ)框架。以農(nóng)作物生長(zhǎng)環(huán)境采集系統(tǒng)為載體，闡述了其運(yùn)行與交互方式，并展示了原型系統(tǒng)實(shí)現(xiàn)方法。該框架采用去中心化設(shè)計(jì)，具有易于訪問(wèn)、易于實(shí)現(xiàn)、易于擴(kuò)展等特性，從應(yīng)用層面提出了一種解決物聯(lián)網(wǎng)異構(gòu)問(wèn)題的解決方案。

微服務(wù)；物聯(lián)網(wǎng)；應(yīng)用基礎(chǔ)框架

物聯(lián)網(wǎng)(Internet of Things,IoT)是指通過(guò)部署具有一定感知、計(jì)算、執(zhí)行和通信等能力的各種設(shè)備,獲得物理世界的信息,通過(guò)網(wǎng)絡(luò)實(shí)現(xiàn)信息的傳輸、協(xié)同和處理,從而實(shí)現(xiàn)人與物通信、物與物通信的互聯(lián)的網(wǎng)絡(luò)[1]。國(guó)際標(biāo)準(zhǔn)化組織協(xié)會(huì)等組織在物聯(lián)網(wǎng)產(chǎn)業(yè)化及標(biāo)準(zhǔn)化上開展了大量工作，產(chǎn)生了許多較為成熟的低功耗的物理層和傳輸層網(wǎng)絡(luò)協(xié)議,如Zigbee、Bluetooth、IEEE 802.15.4等，各種物聯(lián)網(wǎng)設(shè)備在這些協(xié)議的支持下可以實(shí)現(xiàn)物聯(lián)網(wǎng)設(shè)備之間的互聯(lián)互通。然而，這些技術(shù)標(biāo)準(zhǔn)雖然從網(wǎng)絡(luò)層角度實(shí)現(xiàn)了物聯(lián)網(wǎng)設(shè)備的互聯(lián)互通，但從應(yīng)用層的角度看，這些異構(gòu)的物聯(lián)網(wǎng)設(shè)備間仍然是一個(gè)個(gè)信息孤島，還需要開發(fā)者將其整合才能成為一個(gè)具有應(yīng)用價(jià)值的物聯(lián)網(wǎng)應(yīng)用系統(tǒng)。

以物聯(lián)網(wǎng)農(nóng)作物生長(zhǎng)環(huán)境采集系統(tǒng)為例。該系統(tǒng)包含大量傳感器、物聯(lián)網(wǎng)設(shè)備，通過(guò)無(wú)線傳感器網(wǎng)絡(luò)框架(Wireless Sensor Network,WSN)可以解決設(shè)備與設(shè)備之間的大規(guī)模部署及互聯(lián)互通問(wèn)題，然而物聯(lián)網(wǎng)系統(tǒng)用戶、應(yīng)用及設(shè)備之間的交互及信息共享等需求則需要由應(yīng)用層來(lái)解決。本文提出的基于微服務(wù)架構(gòu)的物聯(lián)網(wǎng)應(yīng)用基礎(chǔ)框架設(shè)計(jì)方案適用于對(duì)開放性、可擴(kuò)展性有較高要求的物聯(lián)網(wǎng)應(yīng)用系統(tǒng)，從應(yīng)用層面解決物聯(lián)網(wǎng)異構(gòu)問(wèn)題。

1 相關(guān)工作

通過(guò)研究當(dāng)前物聯(lián)網(wǎng)產(chǎn)業(yè)現(xiàn)狀可以發(fā)現(xiàn)，雖然目前物聯(lián)網(wǎng)產(chǎn)業(yè)化應(yīng)用取得了一些成果并積累了不少成功的案例，但從應(yīng)用系統(tǒng)架構(gòu)設(shè)計(jì)角度看仍然存在一些共性的問(wèn)題：一是架構(gòu)設(shè)計(jì)封閉，采用私有接口、協(xié)議實(shí)現(xiàn)通信，即使是同行業(yè)間的應(yīng)用也沒有互操作能力；二是缺乏異構(gòu)終端支持，由于不同類型終端信息處理方式及通信協(xié)議的差異，現(xiàn)有系統(tǒng)很難實(shí)現(xiàn)跨終端應(yīng)用支持；三是采用整體架構(gòu)模式(Monolithic Architecture)設(shè)計(jì)，所有功能封裝在一個(gè)應(yīng)用系統(tǒng)中，系統(tǒng)水平擴(kuò)展性差且缺乏跨應(yīng)用的支持；四是系統(tǒng)耦合性高，聚合度低，程序難以復(fù)用與維護(hù)，與低耦合高內(nèi)聚的軟件開發(fā)原則相悖。

為解決這些問(wèn)題，業(yè)界針對(duì)物聯(lián)網(wǎng)應(yīng)用基礎(chǔ)框架設(shè)計(jì)制定了許多可借鑒的標(biāo)準(zhǔn)和方案，如Device Profiles for Web Services(DPWS)標(biāo)準(zhǔn)將SOA應(yīng)用于物聯(lián)網(wǎng)[2]。該標(biāo)準(zhǔn)基于Web Services 設(shè)計(jì)，可以通過(guò)服務(wù)總線及中間件實(shí)現(xiàn)智能設(shè)備及應(yīng)用軟件的交互，但SOA標(biāo)準(zhǔn)更適用于整合連接靜態(tài)的企業(yè)級(jí)大型應(yīng)用。另一種值得關(guān)注的方案是近年來(lái)才提出的一種開放式物聯(lián)網(wǎng)方案Web of Things (WoT)。該方案主張將所有的物聯(lián)網(wǎng)設(shè)備抽象為資源，通過(guò)REST Web Service API的方式將其公開，在這一方案基礎(chǔ)上Pautasso等人提出了基于REST的業(yè)務(wù)流程管理方案(Business Process Management,BPM)，允許將復(fù)雜的業(yè)務(wù)流程抽象為RESTful Web Service。BPM方案對(duì)于Web2.0及企業(yè)應(yīng)用整合有重要參考價(jià)值。

上述標(biāo)準(zhǔn)和方案大都基于整體架構(gòu)模式設(shè)計(jì)，即采用集中式業(yè)務(wù)平臺(tái)處理業(yè)務(wù)邏輯及存儲(chǔ)數(shù)據(jù)。在物聯(lián)網(wǎng)的復(fù)雜環(huán)境中，這種方式必然帶來(lái)一些系統(tǒng)擴(kuò)展性及伸縮性方面的局限，比如整體架構(gòu)模式采用統(tǒng)一的技術(shù)手段實(shí)現(xiàn)，應(yīng)對(duì)異構(gòu)環(huán)境缺乏針對(duì)性；系統(tǒng)水平功能模塊擴(kuò)展需重新構(gòu)建和部署整個(gè)系統(tǒng)；除重寫整個(gè)應(yīng)用程序外，很難變更新的基礎(chǔ)框架，其結(jié)果是整體架構(gòu)無(wú)法支持復(fù)雜的、變化的、長(zhǎng)期的應(yīng)用。

2 基于微服務(wù)架構(gòu)的物聯(lián)網(wǎng)應(yīng)用基礎(chǔ)框架設(shè)計(jì)

物聯(lián)網(wǎng)應(yīng)用基礎(chǔ)框架設(shè)計(jì)既要考慮如何將現(xiàn)有的物聯(lián)網(wǎng)設(shè)施整合，同時(shí)也要考慮系統(tǒng)設(shè)計(jì)的開放性及可擴(kuò)展性，比如是否能夠快速地適應(yīng)在現(xiàn)有基礎(chǔ)設(shè)施上的傳感器與物聯(lián)網(wǎng)設(shè)備增加而導(dǎo)致的功能需求變化，因此在設(shè)計(jì)過(guò)程中應(yīng)遵循以下幾點(diǎn)準(zhǔn)則：(1)系統(tǒng)設(shè)計(jì)簡(jiǎn)潔，易于實(shí)現(xiàn)。系統(tǒng)設(shè)計(jì)應(yīng)盡量簡(jiǎn)潔，避免復(fù)雜的架構(gòu)與技術(shù)方案，支持系統(tǒng)的快速原型化。(2)基于標(biāo)準(zhǔn)，降低開發(fā)成本。盡量采用已被廣泛接受且易于實(shí)現(xiàn)的標(biāo)準(zhǔn)及協(xié)議來(lái)構(gòu)建系統(tǒng)，降低開發(fā)成本及開發(fā)門檻。(3)采用輕量級(jí)通信機(jī)制，易于訪問(wèn)。避免復(fù)雜的具有平臺(tái)限制的協(xié)議，易于實(shí)現(xiàn)及訪問(wèn)。(4)分布式、松耦合，易于擴(kuò)展。采用分布式設(shè)計(jì)，避免組件緊耦合設(shè)計(jì)，以利于系統(tǒng)的水平擴(kuò)展及垂直擴(kuò)展。

基于以上準(zhǔn)則，在物聯(lián)網(wǎng)農(nóng)作物生長(zhǎng)環(huán)境采集系統(tǒng)的設(shè)計(jì)過(guò)程中提出了采用微服務(wù)架構(gòu)(MSA,Micro-service Architecture)構(gòu)建應(yīng)用基礎(chǔ)框架。其基本思想是：將功能分解到各個(gè)離散的服務(wù)中，以實(shí)現(xiàn)對(duì)解決方案的解耦，即將復(fù)雜系統(tǒng)拆分為一系列小且功能專一的服務(wù)；并通過(guò)相互協(xié)作來(lái)構(gòu)建應(yīng)用系統(tǒng)。實(shí)踐中，將系統(tǒng)拆分為7個(gè)微服務(wù)，比如其中濕度控制服務(wù)(Temperature control Service)用于獲取和記錄土壤濕度信息等功能，定時(shí)任務(wù)服務(wù)(Timing task Service)用于配置和完成諸如定時(shí)澆灌任務(wù)等功能?？梢?，每個(gè)服務(wù)的功能小且專一，各自完成整個(gè)系統(tǒng)的部分功能。服務(wù)與服務(wù)間可以通過(guò)協(xié)作完成復(fù)雜的系列任務(wù)，比如定時(shí)澆灌功能的實(shí)現(xiàn)需要由定時(shí)任務(wù)服務(wù)來(lái)設(shè)置及發(fā)布任務(wù)、由濕度控制服務(wù)來(lái)監(jiān)測(cè)當(dāng)前土壤區(qū)塊濕度平均值、由設(shè)備狀態(tài)服務(wù)來(lái)控制智能澆灌設(shè)備的開關(guān)?；谖⒎?wù)的物聯(lián)網(wǎng)農(nóng)作物生長(zhǎng)環(huán)境采集系統(tǒng)應(yīng)用層架構(gòu)如圖1所示。

圖1 基于微服務(wù)的物聯(lián)網(wǎng)農(nóng)作物生長(zhǎng)環(huán)境采集系統(tǒng)應(yīng)用層架構(gòu)

從架構(gòu)圖中可以看出，系統(tǒng)中每個(gè)服務(wù)的功能及數(shù)據(jù)相對(duì)于其他服務(wù)是獨(dú)立的，服務(wù)之間通過(guò)HTTP協(xié)議實(shí)現(xiàn)通信，下面通過(guò)與土壤濕度控制相關(guān)的三個(gè)應(yīng)用場(chǎng)景中具體的業(yè)務(wù)來(lái)說(shuō)明該微服務(wù)架構(gòu)如何工作：任務(wù)1“獲取設(shè)備編號(hào)為Hum01的濕度傳感器當(dāng)前值”，任務(wù)2“獲取區(qū)域編號(hào)Area01的土壤區(qū)塊濕度信息列表”，任務(wù)3“定時(shí)監(jiān)測(cè)某區(qū)域濕度信息，平均值低于臨界值時(shí)啟動(dòng)自動(dòng)灌溉裝置”。

對(duì)于任務(wù)1“獲取設(shè)備編號(hào)為Hum01的濕度傳感器當(dāng)前值”、任務(wù)2“獲取某區(qū)域濕度信息列表”，實(shí)現(xiàn)過(guò)程較為簡(jiǎn)單，其業(yè)務(wù)流程都是通過(guò)HTTP協(xié)議訪問(wèn)預(yù)先定義的資源獲取信息，如客戶端通過(guò)Get請(qǐng)求發(fā)送URI：…/humidity/device/Hum01訪問(wèn)資源，濕度控制服務(wù)接收請(qǐng)求并返回包含Hum01的濕度傳感器當(dāng)前值JSON格式的響應(yīng)；客戶端通過(guò)Get請(qǐng)求發(fā)送URI:…/humidity/area/Area01訪問(wèn)資源，濕度控制服務(wù)接收請(qǐng)求并返回包含Area01的土壤區(qū)塊所有濕度傳感器當(dāng)前值列表的JSON格式響應(yīng)。圖2展示了這兩個(gè)任務(wù)的業(yè)務(wù)流程序列圖及其請(qǐng)求、響應(yīng)樣例。

圖2 任務(wù)1、2業(yè)務(wù)流程序列圖及請(qǐng)求、響應(yīng)樣例

對(duì)于任務(wù)3“定時(shí)監(jiān)測(cè)某區(qū)域濕度信息，平均值低于臨界值時(shí)啟動(dòng)自動(dòng)灌溉裝置”，實(shí)現(xiàn)過(guò)程相對(duì)復(fù)雜，需要三個(gè)微服務(wù)協(xié)同工作，其業(yè)務(wù)流程首先是由定時(shí)任務(wù)服務(wù)通過(guò)發(fā)送包含有灌溉區(qū)域編號(hào)、目標(biāo)濕度值的POST請(qǐng)求至URI:…/humidity/irrigation/，濕度控制服務(wù)接收請(qǐng)求后首先會(huì)監(jiān)測(cè)該區(qū)塊平均濕度值，如未達(dá)到目標(biāo)值則發(fā)送包含由設(shè)備狀態(tài)操作代碼(啟動(dòng)設(shè)備)的PUT請(qǐng)求至URI:…/device/{device.id}，由設(shè)備狀態(tài)服務(wù)接收請(qǐng)求并啟動(dòng)相應(yīng)的智能灌溉設(shè)備，灌溉過(guò)程中濕度控制服務(wù)還需監(jiān)控該區(qū)塊濕度值的變化，一旦達(dá)到目標(biāo)濕度值則再次發(fā)送包含由設(shè)備狀態(tài)操作代碼(關(guān)閉設(shè)備)的PUT請(qǐng)求至URI: …/device/{device.id}，由設(shè)備狀態(tài)服務(wù)接收請(qǐng)求并關(guān)閉相應(yīng)的智能灌溉設(shè)備以最終完成灌溉。圖3展示了該任務(wù)的業(yè)務(wù)流程序列圖及其請(qǐng)求、響應(yīng)樣例。

圖3 任務(wù)3業(yè)務(wù)流程序列圖及請(qǐng)求、響應(yīng)樣例

上述應(yīng)用場(chǎng)景所描述的業(yè)務(wù)流程代表了整個(gè)物聯(lián)網(wǎng)農(nóng)作物生長(zhǎng)環(huán)境采集系統(tǒng)業(yè)務(wù)流程的處理方式，服務(wù)和服務(wù)之間、服務(wù)與應(yīng)用之間通過(guò)輕量級(jí)的機(jī)制實(shí)現(xiàn)彼此間的通信，系統(tǒng)設(shè)計(jì)采用Web標(biāo)準(zhǔn)中的HTTP1.1這種與語(yǔ)言、平臺(tái)無(wú)關(guān)的協(xié)議來(lái)傳輸數(shù)據(jù)?；贖TTP協(xié)議構(gòu)建的RESTful(REST風(fēng)格的Web服務(wù))API 的接口包含標(biāo)準(zhǔn)的HTTP方法，如GET、POST、PUT和DELETE。表1描述的是以土壤濕度控制服務(wù)為例所設(shè)計(jì)的API接口使用樣例。

從表1中可以看出，土壤濕度控制服務(wù)的資源命名空間為“humidity”，與土壤濕度相關(guān)的操作可以通過(guò)該命名空間訪問(wèn)。另外在表格中“獲取某濕度傳感器當(dāng)前濕度值”與“刪除某濕度傳感器記錄值”URI示例路徑一致，服務(wù)器將根據(jù)請(qǐng)求類型是GET還是DELETE來(lái)確定執(zhí)行何種操作。當(dāng)其他應(yīng)用或服務(wù)通過(guò)URI訪問(wèn)當(dāng)前土壤濕度控制服務(wù)提供的功能是，通常情況下該服務(wù)會(huì)返回一個(gè)JSON格式數(shù)據(jù)，比如希望獲取某傳感器歷史濕度記錄值，可以通過(guò)訪問(wèn)URI:…/humidity/device/{device.id}/{startTime}/{endTime}得到以下返回值：

{["humDvice.id":"hum01","humidityValue":6,"recordTime":"2014-10-1 19:20:01"],

["humDvice.id":"hum01","humidityValue":5,"recordTime":"2014-10-1 19:30:01"],

["humDvice.id":"hum01","humidityValue":5,"recordTime":"2014-10-1 19:40:01"],……}

表1 土壤濕度控制服務(wù)RESTful API

此外，對(duì)于服務(wù)與物聯(lián)網(wǎng)設(shè)備間的通信，在系統(tǒng)設(shè)計(jì)中同樣也采用HTTP協(xié)議來(lái)實(shí)現(xiàn)，圖4描述了其結(jié)構(gòu)。當(dāng)然，這種方式需要在下位機(jī)網(wǎng)關(guān)將無(wú)線傳感網(wǎng)絡(luò)采集到的物理設(shè)備數(shù)據(jù)轉(zhuǎn)換為HTTP協(xié)議并傳輸。

圖4 微服務(wù)與物聯(lián)網(wǎng)設(shè)備的交互

該微服務(wù)架構(gòu)的主要特點(diǎn)歸納如下：

(1)去中心化設(shè)計(jì)。每個(gè)服務(wù)相互獨(dú)立運(yùn)行在一個(gè)獨(dú)立的操作系統(tǒng)進(jìn)程中，可以將不同的服務(wù)部署于不同的主機(jī)，適應(yīng)于構(gòu)建分布式物聯(lián)網(wǎng)應(yīng)用系統(tǒng)。由于服務(wù)的獨(dú)立性，每個(gè)服務(wù)都可以選擇不同的技術(shù)平臺(tái)、數(shù)據(jù)庫(kù)實(shí)現(xiàn)，可以根據(jù)不同的業(yè)務(wù)特征有針對(duì)性地選擇合適的技術(shù)方案去解決具體的業(yè)務(wù)問(wèn)題，比如使用Node.js構(gòu)建定時(shí)任務(wù)服務(wù)，使用Grails構(gòu)建濕度控制服務(wù)等。并且，由于每個(gè)服務(wù)的功能單一，在定義好接口的情況下，可以由不同的開發(fā)團(tuán)隊(duì)獨(dú)立開發(fā)而互不干擾。

(2)面向資源的架構(gòu)(Resource Oriented Architecture，ROA)風(fēng)格。繼承Web of Things (WoT)中將所有的物聯(lián)網(wǎng)設(shè)備抽象為資源的做法，通過(guò)微服務(wù)將各種資源以REST Web Service API對(duì)外公開，REST作為一種分布式軟件架構(gòu)風(fēng)格，是一系列實(shí)現(xiàn)Web標(biāo)準(zhǔn)(基于HTTP 1.1和URI)的指導(dǎo)原則。REST所制定的指導(dǎo)原則使得該架構(gòu)可以支持“系統(tǒng)組件間交互的可擴(kuò)展性、接口的一致性、組件的獨(dú)立部署、降低交互延時(shí)的中間組件、安全性的加強(qiáng)、對(duì)遺留系統(tǒng)的封裝”[3]。

(3)開放式設(shè)計(jì)。由于整體架構(gòu)模式系統(tǒng)單進(jìn)程的局限性，水平功能擴(kuò)展時(shí)只能基于整個(gè)系統(tǒng)進(jìn)行擴(kuò)展，新功能的發(fā)布意味著要重新構(gòu)建和部署整個(gè)系統(tǒng)。而該架構(gòu)則可很好解決系統(tǒng)伸縮性的擴(kuò)展問(wèn)題，比如當(dāng)系統(tǒng)需要增加一個(gè)通風(fēng)控制相關(guān)功能模塊時(shí)，可以單獨(dú)開發(fā)一個(gè)微服務(wù)并部署，不會(huì)對(duì)系統(tǒng)的其他服務(wù)產(chǎn)生影響。這意味著該架構(gòu)可以實(shí)現(xiàn)細(xì)粒度的自由擴(kuò)展。并且，由于所有的微服務(wù)都是基于REST Web Service API對(duì)外公開，很容易在此基礎(chǔ)上開發(fā)新的應(yīng)用或?qū)崿F(xiàn)跨應(yīng)用間的交互。

微服務(wù)架構(gòu)的實(shí)施同樣也存在一些挑戰(zhàn)，在實(shí)踐過(guò)程中發(fā)現(xiàn)突出的問(wèn)題有以下兩點(diǎn)：

(1)微服務(wù)協(xié)同事務(wù)處理。當(dāng)一個(gè)業(yè)務(wù)流程需要多個(gè)微服務(wù)協(xié)同工作時(shí)，采用傳統(tǒng)的分布式事務(wù)處理方式會(huì)降低系統(tǒng)的可用性，因?yàn)樗笫聞?wù)參與者均可用，在分散且互相獨(dú)立的微服務(wù)中實(shí)現(xiàn)起來(lái)較為困難，并且包括REST、NOSQL等在內(nèi)的現(xiàn)代軟件技術(shù)棧并不支持分布式事務(wù)，因此建議采用事件驅(qū)動(dòng)的異步模式來(lái)處理事務(wù)，其特點(diǎn)是可以將事件的生產(chǎn)者、消費(fèi)者實(shí)現(xiàn)解耦，即簡(jiǎn)化開發(fā)同時(shí)也提升了可用性。

(2)分布式系統(tǒng)的復(fù)雜性。微服務(wù)通過(guò)REST Web Service API相互交互，對(duì)于物聯(lián)網(wǎng)系統(tǒng)而言，在實(shí)際運(yùn)行過(guò)程中必須要考慮網(wǎng)絡(luò)延遲、網(wǎng)絡(luò)故障、消息序列化等問(wèn)題，比如當(dāng)網(wǎng)絡(luò)出現(xiàn)故障時(shí)，微服務(wù)間通信中斷時(shí)如何處理？在物聯(lián)網(wǎng)農(nóng)作物生長(zhǎng)環(huán)境采集系統(tǒng)中，通過(guò)設(shè)計(jì)消息總線(Message Bus)實(shí)現(xiàn)消息隊(duì)列，微服務(wù)可以通過(guò)監(jiān)聽消息總線當(dāng)網(wǎng)絡(luò)故障恢復(fù)時(shí)從消息隊(duì)列中取出滯留的信息。

3 原型系統(tǒng)實(shí)現(xiàn)

目前，有許多輕量級(jí)的技術(shù)框架可以用來(lái)實(shí)現(xiàn)微服務(wù)架構(gòu)，比如基于Ruby語(yǔ)言的Sinatra Web開發(fā)框架，其突出的特點(diǎn)就是輕量、快速[4]；基于JavaScript 的Node.js，其特點(diǎn)是借助事件驅(qū)動(dòng)，非阻塞I/O 模型，非常適合運(yùn)行在分布式設(shè)備的數(shù)據(jù)密集型的實(shí)時(shí)應(yīng)用[5]；Spring Boot遵循“約定優(yōu)于配置”的理念，能夠極大地簡(jiǎn)化基于Spring MVC的Web應(yīng)用和REST服務(wù)開發(fā)[6]。本文為了實(shí)現(xiàn)原型系統(tǒng)快速構(gòu)建，以基于Groovy語(yǔ)言且同樣遵循“約定優(yōu)于配置”的Grails敏捷開發(fā)框架為例，就微服務(wù)的實(shí)現(xiàn)展開研究[7]。

以濕度控制微服務(wù)為例，首先要將資源抽象為領(lǐng)域類，下面的Humidity 領(lǐng)域類(Domain)代碼中將濕度相關(guān)資源抽象為類的屬性，包括設(shè)備編號(hào)、記錄時(shí)間等，Grails框架將自動(dòng)為該領(lǐng)域類動(dòng)態(tài)注入包括save、delete、update、find等方法，即自動(dòng)提供CRUD等功能支持。

class Humidity {

String deviceId //設(shè)備編號(hào)

Date recordTime //記錄時(shí)間

double humidityValue //記錄值

static mapping = {

id generator:‘uuid.hex'

}

……

}

其次是基于Humidity 領(lǐng)域類生成HumidityController控制器，控制器用戶獲取請(qǐng)求并返回響應(yīng)，下面的代碼中show方法用于獲取某濕度傳感器當(dāng)前濕度值，以調(diào)用Humidity領(lǐng)域類findByDeviceId(該方法由Grails動(dòng)態(tài)注入)方法獲取Humidity實(shí)例，將結(jié)果render為JSON格式并返回。另外，代碼中allowedMethods用于定義請(qǐng)求類型與方法的綁定關(guān)系，即show方法只能通過(guò)GET請(qǐng)求訪問(wèn)，其他類型請(qǐng)求無(wú)效。

class HumidityController {

static allowedMethods=[save: "POST",

delete: "DELETE",show: "GET"]

def show(String deviceId) {

def humidityInstance = Humidity.findBy

DeviceId(deviceId)

if (!humidityInstance) {

render(status: 404)

} else {

render(contentType: "text/json") {

humidityInstance(deviceId:humidi

tyInstance.deviceId,

humidityValue:humidityInstance.

humidityValue

)

}

}

}

……

}

由以上代碼示例可見，在合適的開發(fā)框架支持下，開發(fā)一個(gè)微服務(wù)相對(duì)于傳統(tǒng)軟件開發(fā)技術(shù)更為簡(jiǎn)單、快速。即使是完整的濕度控制微服務(wù)，其代碼量?jī)H約1 000行。當(dāng)然，編碼工作量的降低并不意味著功能打折，只能更加充分地說(shuō)明合理的設(shè)計(jì)加上適當(dāng)?shù)募夹g(shù)將大大降低開發(fā)成本與開發(fā)門檻。

4 結(jié) 語(yǔ)

如上所述，采用微服務(wù)架構(gòu)設(shè)計(jì)的應(yīng)用基礎(chǔ)框架將系統(tǒng)按照功能拆分為若干微服務(wù)，每個(gè)服務(wù)專注于完成各自核心的業(yè)務(wù)邏輯，這種微服務(wù)架構(gòu)設(shè)計(jì)的物聯(lián)網(wǎng)應(yīng)用基礎(chǔ)框架從應(yīng)用層面解決了物聯(lián)網(wǎng)異構(gòu)問(wèn)題，適用于對(duì)開放性、可擴(kuò)展性有較高要求的物聯(lián)網(wǎng)應(yīng)用系統(tǒng)。此外，其分布式、開放式設(shè)計(jì)特性易于實(shí)現(xiàn)跨應(yīng)用的交互，從而可以將不同的物聯(lián)網(wǎng)應(yīng)用系統(tǒng)整合為物聯(lián)網(wǎng)生態(tài)系統(tǒng)。

[1]孫其博,劉杰,黎舞,等.物聯(lián)網(wǎng)：概念、架構(gòu)與關(guān)鍵技術(shù)研究綜述[J].北京郵電大學(xué)學(xué)報(bào),2010,33(3):1-9

[2]OASIS.Device Profiles for Web Services (DPWS) specification[EB/OL].[2014-12-01].http://docs. oasis-open.org/ ws-dd/ns/dpws/2009/01

[3]Roy Thomas Fielding.Architectural Styles and the Design of Network-based Software Architectures[D].California Department of Information and Computer Science,University of California Irvine,2000:5-8

[4]Blake Mizerany.Sinatra Documentation[EB/OL].[2014-12-15].http://www.sinatrarb.com

[5]Google Nodejs.API DOCS[EB/OL].[2014-12-20].http://www.nodejs.org/api

[6]SpringSource.Spring Boot Documentation[EB/OL].[2014-12-21]. http://http://spring.io/docs/

[7]SpringSource.Grails Documentation[EB/OL].[2014-12-21].http://grails.org/Documentation

(責(zé)任編輯：汪材印)

10.3969/j.issn.1673-2006.2015.07.025

2015-03-15

安徽省高等學(xué)校省級(jí)自然科學(xué)研究重點(diǎn)項(xiàng)目“基于物聯(lián)網(wǎng)的農(nóng)作物生長(zhǎng)環(huán)境信息采集系統(tǒng)研究——以滁州貢菊生長(zhǎng)環(huán)境為例”(KJ2014A189)；滁州職業(yè)技術(shù)學(xué)院校科重點(diǎn)項(xiàng)目“基于CC2530的ZigBee溫室智能無(wú)線傳感器網(wǎng)絡(luò)設(shè)計(jì)”(YJZ-2013-06)。

吳昌雨(1977-)，安徽滁州人，碩士，講師，主要研究方向：軟件技術(shù)。

TP311.5

A

1673-2006(2015)07-0088-05