藍牙Mesh設備遠程控制平臺設計與實現

俞為 崔佳冬

摘 要：為改進藍牙Mesh設備無法進行遠程控制與管理的缺點，設計并實現了基于分布式服務器的遠程控制平臺。根據分布式特點將平臺拆分為注冊中心、路由網關、Mesh設備管理服務、Mesh控制服務和WebSocket服務5個模塊。注冊中心用于管理其它模塊，路由網關用于分發請求到下游服務器中，Mesh設備管理服務用于查看Mesh設備信息，Mesh控制服務用于處理控制指令，WebSocket服務用于實現對Mesh設備的控制。測試結果表明，與傳統集群設計方式相比，分布式設計方式的平均TPS（每秒事務處理量）提高了約3.3倍，平均響應時間縮短了約3/4，請求成功率提高了1.92%。

關鍵詞：Mesh;遠程控制;分布式服務器;WebSocket

DOI：10. 11907/rjdk. 191562 開放科學（資源服務）標識碼（OSID）：

中圖分類號：TP319文獻標識碼：A 文章編號：1672-7800（2020）002-0039-05

英標：Design and Implementation of Bluetooth Mesh Device Remote Control Platform

英作：YU Wei，CUI Jia-dong

英單：（School of Electronics & Information， Hangzhou Dianzi University， Hangzhou 310018， China）

Abstract：In order to improve the shortcomings of remote control and management of Bluetooth Mesh devices， a remote control platform based on distributed server is designed and implemented. According to the distributed characteristics， the platform is divided into five modules： registration center， routing gateway， Mesh device management service， Mesh control service and WebSocket service. The registration center is used to manage other modules. The routing gateway is used to distribute requests to downstream servers. The Mesh device management service is used to view information about Mesh devices. The Mesh control service is used to process control commands. The WebSocket service is used to control Mesh devices. The test results show that compared with the traditional cluster design method， the average TPS（Transaction Per Second） is increased by about 3.3 times， the average response time is shortened by about 3/4， and the request success rate is increased by 1.92%.

Key Words： Mesh; remote control; distributed server; WebSocket

0 引言

藍牙Mesh技術最早是在2014年由CSR劍橋大學研發團隊提出的，當時僅提出了私有協議（CSR Mesh）。2017年7月19日，藍牙技術聯盟正式宣布藍牙技術開始全面支持Mesh網狀網絡[1]，制定了藍牙Mesh的標準協議（SIG Mesh）[2]。全新的SIG Mesh技術可支持設備多對多傳輸[3]，使其更加適用于樓宇自動化、無線傳感器等需要讓數萬個設備在安全、可靠、穩定環境下進行信息傳輸的物聯網解決方案[4]。雖然SIG Mesh技術可以使整個應用的通信覆蓋面積增大，但整個應用無法接入到互聯網中，只能在樓宇范圍內進行控制，無法實現遠程控制與統一管理[5]，極大限制了其應用范圍，所以需要設計開發一個針對藍牙Mesh應用的遠程控制平臺。

傳統控制平臺采用單機或集群服務器設計方式，雖然后者可以利用Nginx[6-7]的負載均衡原理，使其并發量相比前者明顯提升，但其本質仍是將所有業務都部署在一臺服務器上，每臺服務器并發量并沒有任何提升，并且當某個服務出現錯誤時，整臺服務器都會癱瘓，無法實現平臺的高并發和高可用。藍牙Mesh應用一般用于樓宇與大型商場中，具有高并發、大數據量的特點，而傳統控制平臺設計方式無法滿足該應用場景。針對以上特點，本文提出一個基于分布式服務器的遠程控制平臺[8]，將各個相對完整的業務拆分成獨立模塊，并部署在不同服務器上[9- 10]，使每臺服務器需要處理的業務相對較少，以提高控制平臺的并發量和可用性。

1 系統總體框架

如圖1所示，系統不再只有藍牙一種通信方式，而是在原有藍牙Mesh應用基礎上添加了網關、分布式服務器、數據庫和瀏覽器部分，實現了一個遠程控制平臺。手機APP可通過原有藍牙通信方式進行控制[11]，也可以通過HTTP請求訪問服務器，再由服務器通過WebSocket[12-14]通信下發指令到網關，最終實現遠程控制。瀏覽器可通過HTTP請求訪問服務器，再由服務器訪問MySQL數據庫，最終實現對設備信息的遠程查看功能。

2 分布式服務器設計與實現

本文控制平臺是基于分布式服務器的，如圖2所示為分布式服務器設計框架，共有5個模塊，分別是注冊中心[15]、路由網關[16]、Mesh設備管理服務、Mesh控制服務與WebSocket服務[17]。在注冊中心、Mesh設備管理服務和Mesh控制服務3個重要模塊中還增添了集群形式，以保證每個模塊在一臺服務器崩潰時不會受到影響，從而提高了控制平臺的可用性。

2.1 注冊中心設計與實現

注冊中心在整個分布式服務器中的作用是管理其它模塊及提供其它模塊的IP與端口。所有模塊都需要在注冊中心進行注冊（上傳模塊IP、端口與模塊名稱到注冊中心），注冊完成后，每個模塊需要每隔30s向注冊中心發送心跳請求，若注冊中心90s內沒有收到心跳請求，則認為該模塊出現故障。當模塊1需要調用模塊2的服務時，模塊1會根據模塊2的模塊名稱從注冊中心得到相應IP和端口，通過得到的IP和端口實現對模塊2服務的調用。表1為各模塊在注冊中心注冊的信息表。

本文注冊中心采用Eureka[18]集群形式。從圖2中可以看出有兩個Eureka充當注冊中心，它們之間的相互注冊可以使注冊信息同步。其它模塊需要配置這兩個注冊中心的IP和端口，模塊會尋找一個正常運行的注冊中心進行注冊，所以當其中一個注冊中心無法使用時，整個平臺并不會受到影響，因而提高了平臺的可用性。其它模塊在注冊中心注冊配置如下：

spring：

application：

//注冊時的模塊名稱

name：xxx

eureka：

client：

service-url：

//配置兩個注冊中心

defaultZone：http：//xxx/eureka/，http：//xxx/eureka/

2.2 路由網關設計與實現

路由網關在整個分布式服務器中的作用是接收用戶所有請求與路由分發請求，用戶所有請求都會經過路由網關。根據請求路徑，路由網關對照自己配置的路由表獲得需要轉發的模塊名稱，再從注冊中心中獲得對應IP和端口，最后完成請求轉發。本文采用Zuul組件充當網關[19]。

例如當前有請求118.24.110.30/meshmanage/ login，則該請求首先經過Zuul路由網關，通過查看路由表可以發現該請求需要轉發到模塊名為mesh-manage的服務器上，即請求路徑為mesh-manage/login，再從注冊中心中獲取mesh-manage的信息。可以從表1看出mesh-manage已有兩臺服務器進行了注冊，分別是39.106.119.55：1112和106.12.196.14：1112，此時真正要轉發的請求路徑為39.106.119.55：1112/login或106.12.196.14：1112/login。由于兩臺服務器都可以處理服務，所以Zuul路由網關會自動進行負載均衡，以保證轉發到每臺服務器的請求數基本相同。路由表配置如下：

zuul：

routes：

manage：

path： /meshmanage/**

//Mesh設備管理模塊路由配置

serviceId： mesh-manage

control：

path： /meshcontrol/**

//Mesh控制模塊路由配置

serviceId： mesh-control

2.3 業務模塊設計與實現

Mesh設備管理服務、Mesh控制服務和WebSocket服務3個模塊屬于業務模塊。Mesh設備管理服務模塊接收指令查詢請求，并通過查詢MySQL數據庫獲得網關信息（已綁定的網關MAC地址、綁定網關對應用戶、該網關下綁定設備數）或設備信息（設備的DeviceID，設備綁定對應網關及用戶，設備所實現的Model與設備訂閱組地址）返回給用戶。Mesh控制服務模塊接收控制指令請求，并調用WebSocket服務模塊完成控制指令操作，最后對綁定信息進行MySQL數據庫存儲。WebSocket服務模塊通過WebSocket協議實現與網關的長連接，并可實時下發指令操作網關及網關下的設備[20]。同時WebSocket服務模塊也提供接口供Mesh控制服務模塊調用。平臺業務模塊如圖3所示，業務中涉及的專有標識符如表2所示。

業務操作流程如圖4所示，值得注意的是，Mesh控制服務模塊需要調用WebSocket服務模塊才能完成相應業務，所以需要在分布式處理中實現模塊與模塊之間的調用。

本文采用ribbon+restTemplate[21]組件實現這種調用，調用原理即上文所述的模塊1調用模塊2的原理。具體調用程序如下：

//調用WebSocket服務獲得未綁定的設備

List devUUIDs = restTemplate.getForObject （“http：//MESH-WEBSOCKET/getAllUnbindDevice？gwID=” + gwID， List.class）;

3 測試與分析

3.1 性能測試

（1） 測試環境。本文測試中使用的服務器性能參數如表3所示。

由于需要對采用分布式設計方式與集群設計方式的服務器進行性能比較，所以分別對兩種設計方式進行測試，兩種設計方式測試環境對比如表4所示。

測試并發人數采用階梯遞增方式。并發用戶初始值為100人，每過30s人數增加100人，一直增加到1 000人結束，每個用戶每500ms發送一次請求模擬真實環境。并發人數設置如表5所示。

（2） 測試工具。測試工具使用騰訊的壓測大師，這是一款專業且方便的壓測工具。只要給出并發人數設置與需要測試的請求路徑，該工具就會自動進行壓力測試并得到測試結果。

（3） 測試內容。測試內容有平臺的平均TPS（每秒事務處理量）、平臺平均響應時間以及請求成功率。

（4） 測試結果。分布式設計方式測試結果如圖5所示，集群設計方式測試結果如圖6所示。

（5） 結果分析。從圖5、圖6中發現本文介紹的分布式設計方式相比集群設計方式，平均TPS提高了約3.3倍，平均響應時間縮短了約3/4，請求成功率提高了1.92%。總體來看，分布式設計方式遠優于集群設計方式，更適合應用于藍牙Mesh設備遠程控制平臺。

3.2 功能測試

3.2.1 手機APP遠程功能測試

測試功能有掃描網關、綁定網關、掃描設備、綁定設備與設備控制。手機APP遠程功能測試圖如圖7所示，圖7左半部分表明，手機APP可以對網關和網關下的設備進行遠程掃描與綁定。圖中掃描出兩個網關（用Mac地址表示），其中一個網關與用戶（用手機號表示）完成了綁定，在該綁定的網關下對設備進行掃描，可以發現有兩個設備，其中一個設備未綁定（用UUID表示），另一個完成了綁定（用DeviceID表示）;圖7右半部分表明，手機APP的Light Model遠程控制界面可實現開關控制、RGB燈顏色控制與冷暖燈亮度控制等功能。

3.2.2 瀏覽器遠程功能測試

測試功能有網關信息查詢與設備信息查詢。瀏覽器遠程功能測試圖如圖8所示，圖8上半部分表明，可以查看綁定的網關信息（包括綁定對應用戶，以及在該網關下綁定的設備數量）;圖8下半部分表明，可以查詢某個具體網關下的綁定設備信息（包括設備DeviceID，綁定對應網關及用戶，該設備實現的Model與該設備訂閱的組地址）。

4 結語

本文設計并實現了一個藍牙Mesh設備遠程控制平臺，針對藍牙Mesh應用高并發與大數據量的特點，平臺采用分布式設計方式，相比集群設計方式，該方式提高了平臺的并發量與請求成功率，縮短了平臺響應時間。該平臺實現了對藍牙Mesh應用的遠程管理與控制，彌補了藍牙Mesh的不足。未來該平臺還將針對藍牙Mesh的特點實現更加豐富的功能（例如對所有Model的遠程控制），以搭建一個更為通用的藍牙Mesh設備遠程控制平臺。

參考文獻：

[1] 迎九. 藍牙Mesh出臺，15.4等面臨挑戰[J].電子產品世界， 2017， 24（9）：79-80.

[2] 王熙. 藍牙mesh驅動創新打造安全可靠物聯網解決方案[J]. 通信世界， 2017 （25）：46.

[3] NEIL TYLER. The next frontier in mesh networking[J]. New Electronics， 2017， 50（14）：10.

[4] 程琳琳. 藍牙技術聯盟發布mesh標準將提供多點互聯的工業級解決方案[J]. 通信世界， 2017 （21）：49.

[5] 單片機與嵌入式系統應用編輯部. 藍牙技術聯盟開放網關架構[J]. 單片機與嵌入式系統應用， 2016， 16（4）：9.

[6] LERNER R M. At the forge： Nginx[J]. Linux Journal， 2016.

[7] 林麗麗. 使用高性能Web服務器Nginx實現開源負載均衡[J]. 大眾科技， 2010 （7）：37-38

[8] CERNY T. Aspect-oriented challenges in system integration with microservices， SOA and IoT[J]. Enterprise Information Systems， 2018：1-23.

[9] 王方旭. 基于Spring Cloud和Docker的微服務架構設計[J]. 中國信息化， 2018 （3）：53-55.

[10] CHRISTOPH F S.Microservice based tool support for business process modelling[J]. Computing reviews， 2016， 57（8）：495-495.

[11] 錢建平，李曉兵，茅梅芳，等. 基于藍牙Mesh組網的智能燈絲燈產品設計[J]. 中國照明電器， 2018 （8）：25-29.

[12] WITTHAYAWIROJ N，NILAPHRUEK P. The development of smart home system for controlling and monitoring energy consumption using websocket protocol[J]. IOP Conference Series： Materials Science and Engineering， 2017， 185（1）：012019.

[13] 陳淏，高守瑋，岳金冬. 基于WebSocket實時物聯網數據傳輸關鍵技術的研究[J]. 工業控制計算機，2016， 29（11）：33-34，36.

[14] 謝佳柏，陳賢祥，胡欣宇，等. 基于低功耗藍牙和WebSocket的物聯網數據網關[J]. 儀表技術與傳感器， 2016 （1）：76-78.

[15] 李春陽，劉迪，崔蔚，等. 基于微服務架構的統一應用開發平臺[J]. 計算機系統應用， 2017， 26（4）：43-48.

[16] 劉罡. 基于微服務架構的汽車經銷商管理系統[J]. 計算機應用， 2018， 38（z2）：243-249.

[17] LIU W T. Research on the development of WebSocket server[J]. Advanced Materials Research， 2014， 886：4.

[18] 劉賢義，馮向陽，馮文和，等. 一種WEB應用無縫接入分布式系統的方法和系統[P]. 北京：CN108667925A， 2018-10-16.

[19] 張杰，司維超，王麗娜，等. 一種面向微服務的通用考核系統設計與應用[J]. 計算機與數字工程，2018，46（12）：2463-2467，2533.

[20] PIMENTEL V，NICKERSON B G. Communicating and displaying real-time data with WebSocket[J]. IEEE Internet Computing， 2012， 16（4）：45-53.

[21] 丁振凡. Spring REST風格Web服務的Json消息封裝及解析研究[J]. 智能計算機與應用， 2012 （2）：9-10.

（責任編輯：黃 健）