微服務(wù)架構(gòu)在智能家居網(wǎng)關(guān)系統(tǒng)中的應(yīng)用研究

吳 磊，湛 健，宋麗華

(北方工業(yè)大學(xué) 計(jì)算機(jī)學(xué)院，北京 100144)

0 引 言

隨著科技的蓬勃發(fā)展，智能家居系統(tǒng)功能逐漸完善。智能家居最根本的目標(biāo)是為人們提供舒適、方便、安全和高效的生活環(huán)境[1]。智能家居網(wǎng)關(guān)是管理智能家居環(huán)境的核心設(shè)備之一，負(fù)責(zé)對(duì)智能家居設(shè)備信息的直接管理，包括信息采集、信息輸入輸出與集中控制等功能[2]。智能家居網(wǎng)關(guān)管理系統(tǒng)集中管理用戶家庭的設(shè)備信息，并制定和存儲(chǔ)個(gè)性化情景模式的設(shè)備組合信息[3]。隨著互聯(lián)網(wǎng)的高速發(fā)展，智能家居網(wǎng)關(guān)管理系統(tǒng)給維護(hù)人員提供了非常便利的方式，對(duì)存儲(chǔ)在網(wǎng)關(guān)中各個(gè)家庭設(shè)備的信息進(jìn)行輔助維護(hù)。但是隨著用戶的增長，不同家庭對(duì)部署在云端的網(wǎng)關(guān)管理系統(tǒng)軟件的需求發(fā)生快速變化，系統(tǒng)的單體架構(gòu)已經(jīng)無法適應(yīng)互聯(lián)網(wǎng)時(shí)代的快速變化，導(dǎo)致項(xiàng)目的開發(fā)、維護(hù)、升級(jí)和擴(kuò)展新功能都非常困難。因此需要一種基于組件化開發(fā)、分布式部署的架構(gòu)策略來支撐網(wǎng)關(guān)管理系統(tǒng)的建設(shè)。目前比較流行的微服務(wù)架構(gòu)正是解決該問題的理想方案。

微服務(wù)架構(gòu)是面向服務(wù)架構(gòu)思想的一種體現(xiàn)，旨在通過將功能分解到各個(gè)離散的服務(wù)中以實(shí)現(xiàn)對(duì)解決方案的解耦[4]。近年來隨著敏捷開發(fā)、DevOps、持續(xù)交付等IT建設(shè)理念的不斷發(fā)展[5]以及虛擬化、Docker等技術(shù)的興起和發(fā)展，微服務(wù)架構(gòu)模式受到了學(xué)術(shù)界與工程界的極大關(guān)注，已經(jīng)成為計(jì)算機(jī)科學(xué)領(lǐng)域的重點(diǎn)研究對(duì)象之一[6]。

1 微服務(wù)

1.1 微服務(wù)的來源與設(shè)計(jì)理念

微服務(wù)最早是由國際著名的OO專家，敏捷開發(fā)方法的創(chuàng)始人之一Martin Fowler提出。微服務(wù)是將一個(gè)單體架構(gòu)的系統(tǒng)拆分成若干個(gè)小的服務(wù)，服務(wù)與服務(wù)之間采用http輕量協(xié)議傳輸數(shù)據(jù)，每個(gè)服務(wù)獨(dú)立性強(qiáng)，這些服務(wù)基于業(yè)務(wù)能力構(gòu)建，并能夠通過自動(dòng)化部署機(jī)制來獨(dú)立部署。這些服務(wù)使用不同的編程語言實(shí)現(xiàn)，利用不同的數(shù)據(jù)存儲(chǔ)技術(shù)，并保持最低限度的集中式管理，這樣的設(shè)計(jì)實(shí)現(xiàn)了單個(gè)服務(wù)的高內(nèi)聚，各個(gè)服務(wù)間低耦合的效果。

微服務(wù)架構(gòu)雖然繼承了面向服務(wù)架構(gòu)(SOA)的特點(diǎn)，但在架構(gòu)本質(zhì)設(shè)計(jì)方面仍存在一定差別[7]。SOA著重于企業(yè)服務(wù)總線，在微服務(wù)中，各個(gè)服務(wù)松散、自治，服務(wù)間低耦合，強(qiáng)調(diào)服務(wù)的“獨(dú)立性”——獨(dú)立開發(fā)、獨(dú)立部署和獨(dú)立運(yùn)行，減少應(yīng)用開發(fā)的復(fù)雜性，從而具有靈活性大、易實(shí)施和可擴(kuò)展等優(yōu)點(diǎn)。

采用一組服務(wù)的方式來構(gòu)建一個(gè)應(yīng)用，服務(wù)獨(dú)立部署在不同的進(jìn)程中，不同服務(wù)通過一些輕量級(jí)交互機(jī)制來通信，例如RPC、HTTP等。服務(wù)可獨(dú)立擴(kuò)展伸縮，每個(gè)服務(wù)定義了明確的邊界，不同的服務(wù)甚至可以采用不同的編程語言來實(shí)現(xiàn)，由獨(dú)立的團(tuán)隊(duì)來維護(hù)[8]。

基于微服務(wù)架構(gòu)規(guī)劃設(shè)計(jì)的辦公平臺(tái)，可以在不影響現(xiàn)有業(yè)務(wù)運(yùn)行的情況下，將傳統(tǒng)PC端復(fù)雜的應(yīng)用分解成不同功能的微服務(wù)接口，快速重構(gòu)適用于移動(dòng)端的低耦合、可拓展、易伸縮的移動(dòng)端應(yīng)用。

1.2 微服務(wù)架構(gòu)的優(yōu)勢(shì)

微服務(wù)的一些優(yōu)勢(shì)是顯而易見的[9]：

(1)將一個(gè)復(fù)雜的業(yè)務(wù)拆分成若干個(gè)小的業(yè)務(wù)，每個(gè)業(yè)務(wù)拆分成小的服務(wù)，這樣將復(fù)雜的問題簡單化，服務(wù)的邊界變得明確。服務(wù)按照業(yè)務(wù)拆分，編寫的代碼也是按照業(yè)務(wù)劃分的，極大提升了程序的可讀性與可拓展性。

(2)微服務(wù)的每個(gè)服務(wù)單元都是獨(dú)立部署的，也就是各自都有自己獨(dú)立的進(jìn)程。當(dāng)某個(gè)服務(wù)模塊發(fā)生代碼變更時(shí)，不需要重新編譯、部署整個(gè)應(yīng)用，這樣單個(gè)服務(wù)的重新部署不會(huì)影響到其他服務(wù)，簡化了測(cè)試與應(yīng)用的部署。

(3)由于微服務(wù)架構(gòu)屬于分布式系統(tǒng)，各個(gè)服務(wù)之間沒有任何的耦合關(guān)系。隨著業(yè)務(wù)的增加，之后的迭代開發(fā)可以根據(jù)業(yè)務(wù)繼續(xù)拆分出微服務(wù)，所以微服務(wù)架構(gòu)系統(tǒng)具有很強(qiáng)的橫向拓展能力[10]。并且開發(fā)出的微服務(wù)可以進(jìn)行集群部署，以解決由于用戶數(shù)量的增加帶來的并發(fā)訪問量的問題。

(4)微服務(wù)架構(gòu)中每個(gè)拆分出來的微服務(wù)都可以由負(fù)責(zé)的團(tuán)隊(duì)獨(dú)立開發(fā)，根據(jù)團(tuán)隊(duì)技術(shù)棧自由選擇任何合適的開發(fā)語言來實(shí)現(xiàn)，只要服務(wù)符合指定的API協(xié)議。開發(fā)人員不再被強(qiáng)迫使用公司以前的技術(shù)或者已經(jīng)過時(shí)的技術(shù)，而是可以根據(jù)業(yè)務(wù)場(chǎng)景自由選擇最新最合適的技術(shù)來實(shí)現(xiàn)服務(wù)。

1.3 微服務(wù)架構(gòu)的不足與應(yīng)對(duì)措施

微服務(wù)架構(gòu)雖然有很多明顯的優(yōu)勢(shì)，但是任何事物的出現(xiàn)都是兩面性的，關(guān)注其優(yōu)勢(shì)的同時(shí)也不能忽視其帶來的一些額外的負(fù)擔(dān)：

單體應(yīng)用開發(fā)完成后可以打包部署在一組應(yīng)用服務(wù)器上，然后消費(fèi)端使用負(fù)載均衡即可。每個(gè)應(yīng)用都有相同的基礎(chǔ)服務(wù)地址，例如數(shù)據(jù)庫和消息隊(duì)列。而隨著業(yè)務(wù)量的增加，拆分出的微服務(wù)會(huì)越來越多。每個(gè)服務(wù)都可能有自己單獨(dú)的配置及服務(wù)地址，從而對(duì)配置、部署以及健康性監(jiān)控提出更高的要求。

應(yīng)對(duì)措施：DevOps的快速發(fā)展，使得這一問題得到解決。容器能為應(yīng)用提供隔離的運(yùn)行空間和完整的運(yùn)行環(huán)境[11]。在智能家居網(wǎng)關(guān)管理平臺(tái)中利用Docker容器為系統(tǒng)服務(wù)提供隔離的運(yùn)行空間，使各容器內(nèi)包含一個(gè)資源獨(dú)享、完整封閉的運(yùn)行環(huán)境并在云端部署。平臺(tái)所拆分出的微服務(wù)采用輕量級(jí)的基于HTTP機(jī)制的Restful風(fēng)格的API設(shè)計(jì)，各服務(wù)間通過網(wǎng)關(guān)負(fù)載均衡模塊進(jìn)行通訊，如圖1所示。

圖1 服務(wù)管理

微服務(wù)架構(gòu)模式的應(yīng)用中某個(gè)服務(wù)的改變由于服務(wù)間的調(diào)用關(guān)系可能會(huì)波及多個(gè)服務(wù)。在單體架構(gòu)的應(yīng)用中，需要對(duì)相關(guān)模塊代碼進(jìn)行更改，整合變化，重新部署就可以。對(duì)比之下，微服務(wù)架構(gòu)模式就需要考慮相關(guān)改變對(duì)不同服務(wù)的影響。許多改變一般只影響一個(gè)服務(wù)，而需要協(xié)調(diào)多服務(wù)的改變很少。

應(yīng)對(duì)措施：采用異步消息通訊[12]，整合消息中間件，通過異步的生產(chǎn)者與消費(fèi)者模式來保證服務(wù)間的數(shù)據(jù)一致性。

2 微服務(wù)智能家居網(wǎng)關(guān)管理平臺(tái)的需求定位

伴隨著互聯(lián)網(wǎng)的發(fā)展，用戶生活水平的提高，智能家居環(huán)境已經(jīng)從以設(shè)備的安防和控制為中心發(fā)展到以人為中心涵蓋舒適便捷、綠色節(jié)能等方面。智能家居網(wǎng)關(guān)管理系統(tǒng)需實(shí)現(xiàn)可以隨時(shí)隨地通過網(wǎng)絡(luò)對(duì)家庭網(wǎng)關(guān)中的設(shè)備信息進(jìn)行管理，該平臺(tái)也是以此作為需求定位。

(1)集中式的需求定位。

用戶家庭設(shè)備信息往往獨(dú)立存儲(chǔ)于用戶家庭網(wǎng)關(guān)，這樣管理人員對(duì)設(shè)備信息的維護(hù)往往都需要上門維護(hù)，非常不方便。這就需要一個(gè)統(tǒng)一的管理中心，實(shí)現(xiàn)將分散的智能家居用戶設(shè)備信息進(jìn)行統(tǒng)一管理，提高管理效率。

(2)個(gè)性化的需求定位。

結(jié)合用戶需求不同、天氣以及在家狀態(tài)，尊重用戶意愿，定制多樣的設(shè)備組合，實(shí)現(xiàn)情景模式的個(gè)性化定制。

(3)數(shù)據(jù)一致性的需求定位。

用戶家庭設(shè)備信息保存在自己的家庭網(wǎng)關(guān)中，而管理人員統(tǒng)一管理的是存儲(chǔ)在云端的設(shè)備信息，是用戶家庭網(wǎng)關(guān)中數(shù)據(jù)的備份。在維護(hù)過程中為了保證雙方的數(shù)據(jù)一致，需要采取相應(yīng)的通訊措施。

3 微服務(wù)架構(gòu)在智能家居網(wǎng)關(guān)管理平臺(tái)中的應(yīng)用

當(dāng)前開發(fā)和維護(hù)的智能家居網(wǎng)關(guān)管理平臺(tái)，隨著用戶的增加，不同用戶的需求變化可能會(huì)出現(xiàn)單體架構(gòu)應(yīng)用解決不了的問題，從而引入微服務(wù)架構(gòu)對(duì)該平臺(tái)架構(gòu)進(jìn)行重構(gòu)，提升平臺(tái)的橫向拓展能力。

智能家居網(wǎng)關(guān)管理平臺(tái)是由服務(wù)人員通過獲取用戶授權(quán)來代替客戶管理各自家庭網(wǎng)關(guān)中保存的設(shè)備數(shù)據(jù)。系統(tǒng)部署在云端，通過服務(wù)器端與家庭網(wǎng)關(guān)的通訊來保持兩邊數(shù)據(jù)的一致性。

3.1 服務(wù)劃分

根據(jù)微服務(wù)架構(gòu)原理[13],與當(dāng)前系統(tǒng)的實(shí)際情況，將智能家居網(wǎng)關(guān)管理平臺(tái)進(jìn)行拆分，劃分出符合用戶需求的定制性服務(wù)和平臺(tái)的基礎(chǔ)性服務(wù)。定制服務(wù)提供目前根據(jù)系統(tǒng)功能需求劃分的能夠?qū)崿F(xiàn)基礎(chǔ)業(yè)務(wù)功能的服務(wù)；基礎(chǔ)平臺(tái)服務(wù)目前包括日志服務(wù)與數(shù)據(jù)模塊服務(wù)。系統(tǒng)劃分出的微服務(wù)如表1所示。

表1 微服務(wù)

各微服務(wù)都定義成獨(dú)立的服務(wù)接口，相比于之前難以維護(hù)的單體結(jié)構(gòu)的情況，新的智能家居網(wǎng)關(guān)管理平臺(tái)由不同的微服務(wù)構(gòu)成，每個(gè)服務(wù)只關(guān)注單一獨(dú)立的業(yè)務(wù)功能，

3.2 技術(shù)架構(gòu)選擇

開發(fā)平臺(tái)微服務(wù)時(shí)使用的技術(shù)架構(gòu)如圖2所示。

圖2 技術(shù)架構(gòu)

其中微服務(wù)的基礎(chǔ)開發(fā)框架選用Spring-Boot。Spring-Boot提供了各個(gè)服務(wù)敏捷開發(fā)的方式并包含了依賴注入、持久化和嵌入式容器等功能。服務(wù)的注冊(cè)與發(fā)現(xiàn)通過集成Eureka組件進(jìn)行實(shí)現(xiàn)；各個(gè)服務(wù)的客戶端調(diào)用引入Feign；Hystrix組件實(shí)現(xiàn)各個(gè)服務(wù)的熔斷機(jī)制與延遲；API網(wǎng)關(guān)的路由選擇，監(jiān)控及負(fù)載均衡通過整合Zuul路由網(wǎng)關(guān)加以實(shí)現(xiàn)。最后通過各個(gè)功能框架組件的整合實(shí)現(xiàn)了平臺(tái)微服務(wù)的設(shè)計(jì)開發(fā)和調(diào)用。

由于各個(gè)組件相互獨(dú)立，為了開發(fā)方便，引入了Spring-Cloud[14]組件。Spring-Cloud是一個(gè)基于Spring-Boot[15]實(shí)現(xiàn)的云應(yīng)用開發(fā)工具，為基于JVM的云應(yīng)用開發(fā)中的配置管理、服務(wù)發(fā)現(xiàn)、熔斷器、動(dòng)態(tài)路由、分布式與集群狀態(tài)管理等操作提供了一種簡單的開發(fā)方式。

3.3 總體框架

基于微服務(wù)架構(gòu)的智能家居網(wǎng)關(guān)管理云平臺(tái)架構(gòu)如圖3所示。

圖3 系統(tǒng)架構(gòu)

進(jìn)行基于微服務(wù)的智能家居網(wǎng)關(guān)管理平臺(tái)的架構(gòu)設(shè)計(jì)時(shí)，遵循“高內(nèi)聚、松耦合”的設(shè)計(jì)思想，實(shí)現(xiàn)平臺(tái)的開放性、軟性和可擴(kuò)展性?；谖⒎?wù)架構(gòu)理念，對(duì)系統(tǒng)提供的業(yè)務(wù)功能加以重構(gòu)，使之解耦成相互獨(dú)立且功能專一的服務(wù)，服務(wù)間以輕量級(jí)的通訊方式進(jìn)行溝通，通過服務(wù)間的相互協(xié)作構(gòu)建供外部訪問的應(yīng)用平臺(tái)。

智能家居網(wǎng)關(guān)管理平臺(tái)框架主要包括四層：

(1)外部訪問層：管理員獲取用戶授權(quán)，通過建立的web服務(wù)來聚合調(diào)用所需要的微服務(wù)接口，從而對(duì)授權(quán)家庭的網(wǎng)關(guān)設(shè)備信息加以維護(hù)。

(2)服務(wù)網(wǎng)關(guān)：系統(tǒng)中拆分出每個(gè)微服務(wù)一般有不同的訪問地址，在完成一個(gè)業(yè)務(wù)需求時(shí)客戶端調(diào)用方可能需要調(diào)用多個(gè)微服務(wù)接口才能滿足需要。如果客戶端直接和拆分出的不同微服務(wù)進(jìn)行通信，可能會(huì)存在以下問題：

①客戶端會(huì)多次請(qǐng)求不同微服務(wù)，增加客戶端的復(fù)雜性；

②存在跨域請(qǐng)求，在一定場(chǎng)景下處理相對(duì)復(fù)雜；

③認(rèn)證復(fù)雜，每一個(gè)服務(wù)都需要獨(dú)立認(rèn)證；

④難以復(fù)用和重構(gòu)，隨著項(xiàng)目的迭代更新，可能需要根據(jù)業(yè)務(wù)需求重新拆分微服務(wù)，如果客戶端直接和微服務(wù)通信，那么代碼的重構(gòu)將會(huì)變得難以實(shí)施；

⑤某些微服務(wù)可能使用了其他協(xié)議，直接訪問有一定困難。

上述問題，都可以借助微服務(wù)API路由網(wǎng)關(guān)解決。微服務(wù)網(wǎng)關(guān)是介于調(diào)用端和接口提供端之間的中間層，所有的外部請(qǐng)求都會(huì)先經(jīng)過微服務(wù)的API網(wǎng)關(guān)，這樣調(diào)用端只需要和API網(wǎng)關(guān)交互，而無需直接調(diào)用特定微服務(wù)的接口，而且方便對(duì)所有微服務(wù)接口進(jìn)行監(jiān)控，并且易于權(quán)限認(rèn)證，減少調(diào)用端和各個(gè)微服務(wù)接口之間的交互次數(shù)。

(3)服務(wù)層：由拆分出來的多個(gè)相互獨(dú)立、可拓展的微服務(wù)構(gòu)成，包括業(yè)務(wù)相關(guān)的微服務(wù)與基礎(chǔ)服務(wù)。業(yè)務(wù)微服務(wù)包括用戶微服務(wù)、設(shè)備微服務(wù)、情景模式微服務(wù)等，基礎(chǔ)微服務(wù)包括權(quán)限認(rèn)證、日志管理等服務(wù)。根據(jù)服務(wù)的重要性排序后，進(jìn)行早期版本開發(fā)，服務(wù)根據(jù)業(yè)務(wù)需要封裝擴(kuò)展和實(shí)現(xiàn)迭代開發(fā)。在微服務(wù)架構(gòu)中，每個(gè)服務(wù)根據(jù)實(shí)際情況采用各自獨(dú)立數(shù)據(jù)庫或共享數(shù)據(jù)庫，采用Mysql、redis等數(shù)據(jù)庫進(jìn)行相關(guān)數(shù)據(jù)信息的存儲(chǔ)。

(4)通訊層：智能家居網(wǎng)關(guān)管理平臺(tái)是為了輔助維護(hù)用戶家庭網(wǎng)關(guān)數(shù)據(jù)，要保證兩邊數(shù)據(jù)一致性，平臺(tái)通過實(shí)驗(yàn)室制定的通訊協(xié)議，實(shí)現(xiàn)網(wǎng)關(guān)與平臺(tái)的及時(shí)通訊，以實(shí)現(xiàn)異構(gòu)數(shù)據(jù)庫的增量同步。

智能家居網(wǎng)關(guān)管理平臺(tái)的主要功能模塊：

由于微服務(wù)架構(gòu)中每個(gè)服務(wù)僅包含功能單一、獨(dú)立、復(fù)雜度可控的業(yè)務(wù)，開發(fā)人員可根據(jù)自己的技術(shù)棧負(fù)責(zé)某個(gè)服務(wù)整個(gè)生命周期的開發(fā)和維護(hù)工作，從而保證整個(gè)應(yīng)用系統(tǒng)的可維護(hù)性和開發(fā)效率，實(shí)現(xiàn)系統(tǒng)的快速迭代與升級(jí)。該智能家居網(wǎng)關(guān)管理平臺(tái)結(jié)合互聯(lián)網(wǎng)技術(shù)部署在服務(wù)器上，管理員通過獲取用戶授權(quán)與用戶均可以遠(yuǎn)程管理用戶自己家庭網(wǎng)關(guān)的設(shè)備數(shù)據(jù)。未來還可以根據(jù)不同家庭的各自需求，對(duì)系統(tǒng)平臺(tái)做出快速的修改和升級(jí)。根據(jù)現(xiàn)有業(yè)務(wù)功能，將平臺(tái)劃分為以下模塊，如圖4所示。

圖4 智能家居網(wǎng)關(guān)管理平臺(tái)功能

用戶模塊：用戶模塊是管理網(wǎng)關(guān)管理平臺(tái)的兩類用戶信息(管理員和家庭用戶)，模塊包括注冊(cè)、登錄和用戶授權(quán)三項(xiàng)子業(yè)務(wù)。平臺(tái)管理員由系統(tǒng)預(yù)先設(shè)定，家庭用戶信息由用戶自行錄入。在登錄界面，管理員錄入登錄信息，申請(qǐng)用戶授權(quán)，通過API接口獲取返回的用戶授權(quán)碼，輸入之后完成系統(tǒng)登錄。

設(shè)備模塊：該模塊是管理用戶家庭網(wǎng)關(guān)中的設(shè)備相關(guān)信息的微服務(wù)。包括新設(shè)備信息的錄入與修改等功能。在管理員獲取用戶授權(quán)登錄后，可以在智能家居網(wǎng)關(guān)管理平臺(tái)上查看該用戶家庭網(wǎng)關(guān)中已錄入的設(shè)備信息，根據(jù)用戶的意愿進(jìn)行輔助維護(hù)。

情景模式模塊：管理員獲取用戶授權(quán)后，根據(jù)當(dāng)時(shí)天氣情況、用戶歸家與離家狀態(tài)以及用戶需求，通過設(shè)備服務(wù)接口對(duì)用戶家庭設(shè)備進(jìn)行按需組合，從而一鍵控制設(shè)備的運(yùn)行狀態(tài)。

日志模塊：記錄平臺(tái)登錄人員的信息與操作記錄，從而可以在出現(xiàn)某些人為操作失誤后可以找出失誤源頭，從而可以回滾誤操作結(jié)果。

數(shù)據(jù)模塊：該模塊定時(shí)對(duì)云端數(shù)據(jù)庫數(shù)據(jù)信息在每日的凌晨2點(diǎn)到4點(diǎn)這段時(shí)間段內(nèi)隨機(jī)選擇一個(gè)時(shí)間點(diǎn)，執(zhí)行數(shù)據(jù)備份操作，將數(shù)據(jù)庫中存放的所有設(shè)備信息和情景模式信息進(jìn)行一次備份操作，備份的文件存放在默認(rèn)備份目錄中，以日期命名，且覆蓋掉上個(gè)月同一天備份數(shù)據(jù)。同時(shí)可以與用戶家庭網(wǎng)關(guān)進(jìn)行通訊以保持兩邊的數(shù)據(jù)一致。

4 實(shí)驗(yàn)與分析

4.1 實(shí)驗(yàn)環(huán)境

該實(shí)驗(yàn)在1 MB/S以太網(wǎng)的網(wǎng)絡(luò)環(huán)境中進(jìn)行測(cè)試，阿里云服務(wù)器(4 GB內(nèi)存、Windows Server 2012，處理器為Intel雙核2.60 GHz)，軟件環(huán)境有Jdk1.8的Java平臺(tái)，數(shù)據(jù)庫Mysql 5.5.27，項(xiàng)目管理工具Apache Maven 3.5.0，各微服務(wù)部署在Docker容器。記錄智能家居網(wǎng)關(guān)管理系統(tǒng)在調(diào)用服務(wù)時(shí)產(chǎn)生的數(shù)據(jù)，包括當(dāng)前調(diào)用的客戶端、調(diào)用時(shí)間等等。

下面對(duì)比分析重構(gòu)前方法調(diào)用與重構(gòu)后微服務(wù)調(diào)用在性能方面的差異。以管理員登錄耗時(shí)以及獲取房間設(shè)備列表為例進(jìn)行分析。

4.2 實(shí)驗(yàn)結(jié)果

4.2.1 管理員登錄耗時(shí)對(duì)比分析

圖5展示了在使用用戶服務(wù)時(shí)，管理員進(jìn)行登錄，

圖5 管理員登錄耗時(shí)

智能家居網(wǎng)關(guān)管理系統(tǒng)通過方法調(diào)用與服務(wù)調(diào)用所消耗的時(shí)間，耗時(shí)差距平均基本維持在20 ms以內(nèi)。

4.2.2 獲取房間設(shè)備列表耗時(shí)對(duì)比分析

圖6展示了在使用用戶服務(wù)與設(shè)備服務(wù)時(shí)，根據(jù)用戶家庭信息，獲取房間設(shè)備列表，智能家居網(wǎng)關(guān)管理系統(tǒng)通過方法調(diào)用與服務(wù)調(diào)用所消耗的時(shí)間，耗時(shí)差距平均基本維持在30 ms以內(nèi)。

圖6 獲取房間設(shè)備列表耗時(shí)

經(jīng)過實(shí)驗(yàn)結(jié)果分析，重構(gòu)后采用微服務(wù)調(diào)用與之前方法調(diào)用，實(shí)現(xiàn)功能耗時(shí)在可接受范圍內(nèi)。以微服務(wù)架構(gòu)實(shí)現(xiàn)智能家居網(wǎng)關(guān)管理系統(tǒng)方案實(shí)現(xiàn)了內(nèi)部邏輯的松耦合，服務(wù)可復(fù)用，提高了平臺(tái)的可拓展性。

5 結(jié)束語

文中詳細(xì)介紹了微服務(wù)架構(gòu)的發(fā)展來源和概念，并結(jié)合傳統(tǒng)的單體應(yīng)用架構(gòu)與微服務(wù)架構(gòu)的對(duì)比，闡述了微服務(wù)架構(gòu)的優(yōu)點(diǎn)、劣勢(shì)以及應(yīng)對(duì)的方法，然后闡明了智能家居網(wǎng)關(guān)管理平臺(tái)目前的實(shí)際需求，最后基于微服務(wù)架構(gòu)設(shè)計(jì)并實(shí)現(xiàn)了服務(wù)高可用、可拓展的智能家居網(wǎng)關(guān)管理平臺(tái)。

目前在微服務(wù)架構(gòu)的實(shí)踐中，仍處于起步階段，還有很大的發(fā)展空間，在后續(xù)的智能家居網(wǎng)關(guān)管理平臺(tái)建設(shè)中將不斷摸索并完善。