吳 磊，湛 健，宋麗華

(北方工業(yè)大學 計算機學院，北京 100144)

0 引 言

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

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

1 微服務

1.1 微服務的來源與設計理念

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

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

采用一組服務的方式來構建一個應用，服務獨立部署在不同的進程中，不同服務通過一些輕量級交互機制來通信，例如RPC、HTTP等。服務可獨立擴展伸縮，每個服務定義了明確的邊界，不同的服務甚至可以采用不同的編程語言來實現(xiàn)，由獨立的團隊來維護[8]。

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

1.2 微服務架構的優(yōu)勢

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

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

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

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

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

1.3 微服務架構的不足與應對措施

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

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

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

圖1 服務管理

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

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

2 微服務智能家居網(wǎng)關管理平臺的需求定位

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

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

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

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

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

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

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

3 微服務架構在智能家居網(wǎng)關管理平臺中的應用

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

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

3.1 服務劃分

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

表1 微服務

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

3.2 技術架構選擇

開發(fā)平臺微服務時使用的技術架構如圖2所示。

圖2 技術架構

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

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

3.3 總體框架

基于微服務架構的智能家居網(wǎng)關管理云平臺架構如圖3所示。

圖3 系統(tǒng)架構

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

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

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

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

①客戶端會多次請求不同微服務，增加客戶端的復雜性；

②存在跨域請求，在一定場景下處理相對復雜；

③認證復雜，每一個服務都需要獨立認證；

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

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

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

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

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

智能家居網(wǎng)關管理平臺的主要功能模塊：

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

圖4 智能家居網(wǎng)關管理平臺功能

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

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

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

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

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

4 實驗與分析

4.1 實驗環(huán)境

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

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

4.2 實驗結(jié)果

4.2.1 管理員登錄耗時對比分析

圖5展示了在使用用戶服務時，管理員進行登錄，

圖5 管理員登錄耗時

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

4.2.2 獲取房間設備列表耗時對比分析

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

圖6 獲取房間設備列表耗時

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

5 結(jié)束語

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

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