肖朋林

（上海市建筑科學(xué)研究院有限公司 上海市 201108）

1 引言

自2007年起，為推進(jìn)建筑能效管理，我國逐步探索推廣了公共建筑分項(xiàng)計(jì)量監(jiān)測(cè)應(yīng)用。從2010年起，上海市作為第三批建筑能耗監(jiān)測(cè)系統(tǒng)建設(shè)試點(diǎn)城市[1]，開始了建筑能源計(jì)量的快速推廣，截至2020年底上海全市已有超過2000 棟建筑實(shí)現(xiàn)了電、水、氣等能源資源的實(shí)時(shí)監(jiān)測(cè)。當(dāng)前建筑能效管理系統(tǒng)主要以單系統(tǒng)的形式部署在建筑內(nèi)。隨著建筑能耗及各類運(yùn)行過程數(shù)據(jù)的增加，系統(tǒng)的運(yùn)行性效率和性能將不斷降低，導(dǎo)致用戶體驗(yàn)不好；同時(shí)系統(tǒng)缺少及時(shí)的交互性的反饋，導(dǎo)致了大部分樓宇業(yè)主新需求無法獲得，進(jìn)而導(dǎo)致能耗監(jiān)測(cè)不能達(dá)到預(yù)期效果。且升級(jí)后的系統(tǒng)無法快速的將原有服務(wù)進(jìn)行替換，且全部替換的成本過大，致使最新功能服務(wù)無法第一時(shí)間交付用戶使用。

為了更好的為建筑業(yè)主提供便捷高效的建筑能效管理服務(wù)，傳統(tǒng)的基于單體式服務(wù)的平臺(tái)架構(gòu)體系不能支撐系統(tǒng)持續(xù)穩(wěn)和高效的運(yùn)行，各類差異化的用戶功能和性能需求也不能得到及時(shí)的滿足。為此本文設(shè)計(jì)了一種基于微服務(wù)的建筑能效管理SaaS云平臺(tái)架構(gòu)，通過微服務(wù)的方式為平臺(tái)提供技術(shù)保障，保障平臺(tái)的性能和可擴(kuò)展性，基于SaaS 的服務(wù)模式構(gòu)建靈活、標(biāo)準(zhǔn)、可配置的平臺(tái)功能服務(wù)，最大限度的提高平臺(tái)的價(jià)值。

2 微服務(wù)架構(gòu)研究

2.1 什么是微服務(wù)架構(gòu)

微服務(wù)架構(gòu)的概念由MartinFowler 在2014年3月發(fā)表[2]，因具有較好靈活性和可擴(kuò)展性，使其逐漸為主流軟件架構(gòu)方案。微服務(wù)架構(gòu)是將功能模塊按照不同分類拆分成多個(gè)小模塊服務(wù)，各服務(wù)獨(dú)立開發(fā)、測(cè)試、部署，各服務(wù)之間使用輕量級(jí)通信規(guī)范進(jìn)行相互通信、數(shù)據(jù)傳遞和協(xié)作，例如通過Restful 風(fēng)格的API 接口、RPC遠(yuǎn)程過程調(diào)用等，極大地降低了服務(wù)之間的耦合性[3]。

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

微服務(wù)技術(shù)棧的優(yōu)點(diǎn)包含以下幾個(gè)方面[3]：

（1）服務(wù)功能開發(fā)和部署速度快：微服務(wù)是將復(fù)雜項(xiàng)目，按照不用的業(yè)務(wù)功能差分成一個(gè)個(gè)微小功能，每個(gè)小功能只關(guān)注一個(gè)功能點(diǎn)，使得此服務(wù)的具有較少的代碼，因此編碼開發(fā)相對(duì)比較快速。針對(duì)小服務(wù)的部署也是可以依托熱部署的技術(shù)，快速的替換部署環(huán)境內(nèi)的全部服務(wù)，部署后的服務(wù)可以快速地支撐系統(tǒng)的運(yùn)行。

（2）需求變更影響小且上線快：一般需求的變更是針對(duì)某個(gè)具體的業(yè)務(wù)功能，由于微服務(wù)模式下已經(jīng)將各個(gè)功能進(jìn)行了服務(wù)劃分，因此只要修改對(duì)應(yīng)服務(wù)的代碼邏輯即可，修改后僅需對(duì)此部分邏輯進(jìn)行測(cè)試，保障符合需求就即可上線；上線部署也無需更好整個(gè)系統(tǒng)的服務(wù)，只需要替換對(duì)應(yīng)修改的服務(wù)即可，且在上線過程極短，極大的降低了功能修改后，系統(tǒng)重新部署對(duì)用戶使用的影響。

（3）各微服務(wù)技術(shù)棧不受限制：由于各個(gè)服務(wù)相互獨(dú)立，通過標(biāo)準(zhǔn)的協(xié)議進(jìn)行通信，因此各個(gè)服務(wù)可以采用不同的語言和技術(shù)棧進(jìn)行開發(fā)。

圖1：平臺(tái)總體架構(gòu)

（4）易于服務(wù)實(shí)例的擴(kuò)展：當(dāng)某個(gè)功能服務(wù)的需求量增加時(shí)，僅需增加此功能服務(wù)的實(shí)例即可，不需要增加整個(gè)系統(tǒng)的服務(wù)，極大的節(jié)省了服務(wù)器資源。

3 SaaS服務(wù)模式研究

SaaS 是指軟件即服務(wù)的意思，是Software-as-a-service 的簡(jiǎn)寫。SaaS 模式是軟件交付模式，是指軟件部署在供應(yīng)商服務(wù)器端，使用者通過客戶端上的瀏覽器訪問，以此獲取功能[4,5]。SaaS 模式的軟件具有如下優(yōu)點(diǎn)[6]。

（1）服務(wù)商早期投入的開發(fā)成本和基礎(chǔ)資源成本較大，但使用者的成本將大大的降低，這樣降低了系統(tǒng)推廣的難度，使得軟件有更多的人使用，以此獲得更多的回報(bào)，從而達(dá)到盈利的目的。

（2）SaaS 模式的軟件具有快速部署，使用者第一時(shí)間獲得新功能的優(yōu)點(diǎn)。因?yàn)檐浖渴鹪诜?wù)器端，只要服務(wù)器端更新，所有用戶將即時(shí)獲取到最新功能服務(wù)。

圖2：微服務(wù)技術(shù)架構(gòu)圖

（3）SaaS 模式的軟件具有跨平臺(tái)性?；赟aaS 模式的軟件基本是通過Web 瀏覽器為用戶提供服務(wù)，與操作系統(tǒng)和終端無關(guān)，只要軟件服務(wù)的適配做好即可實(shí)現(xiàn)用戶通過PC 或者移動(dòng)終端隨時(shí)訪問使用軟件服務(wù)。

4 平臺(tái)架構(gòu)設(shè)計(jì)

4.1 平臺(tái)整體架構(gòu)設(shè)計(jì)

基于上述研究，本文提出了基于微服務(wù)的建筑能效管理SaaS云平臺(tái)架構(gòu)，通過結(jié)合微服務(wù)技術(shù)架構(gòu)與SaaS 模式，解決當(dāng)前單體服務(wù)架構(gòu)系統(tǒng)的性能、快速部署的難題。圖1 展示了本文設(shè)計(jì)平臺(tái)的架構(gòu)。

平臺(tái)基于微服務(wù)架構(gòu)和SaaS 模式共設(shè)計(jì)了九個(gè)層級(jí)，分別是數(shù)據(jù)感知層、采集傳輸層、集成服務(wù)層、存儲(chǔ)服務(wù)層、數(shù)據(jù)服務(wù)層、業(yè)務(wù)服務(wù)層、功能模塊層、SaaS 服務(wù)層、租賃用戶層。其中數(shù)據(jù)感知層、采集傳輸層是屬于數(shù)據(jù)基礎(chǔ)層，主要在建筑端完成，租賃用戶層是平臺(tái)的服務(wù)對(duì)象層。其余層級(jí)根據(jù)特點(diǎn)分別歸納到微服務(wù)架構(gòu)體系和SaaS 模式體系中。下面分別介紹下平臺(tái)主要層級(jí)的具體設(shè)計(jì)內(nèi)容。

（1）集成服務(wù)層：通過部署MQTT 服務(wù)、TCP 服務(wù)接收數(shù)據(jù)，并通過Kafka 消息中間和ignite 內(nèi)存數(shù)據(jù)庫對(duì)數(shù)據(jù)進(jìn)行緩存，以提高數(shù)據(jù)接收的性能。

（2）存儲(chǔ)服務(wù)層：通過存儲(chǔ)服務(wù)、匯總服務(wù)、指標(biāo)計(jì)算服務(wù)等將數(shù)據(jù)原始數(shù)據(jù)存儲(chǔ)到數(shù)據(jù)庫，并匯總計(jì)算得到用來數(shù)據(jù)。并將匯總計(jì)算后的數(shù)據(jù)存儲(chǔ)到分布式TiDB 數(shù)據(jù)庫。

（3）數(shù)據(jù)服務(wù)層：此層是將各類數(shù)據(jù)操作封裝成不同的服務(wù)，為業(yè)務(wù)服務(wù)層提供服務(wù)，并按照微服務(wù)方式部署，以提高服務(wù)性能和可擴(kuò)展性。

（4）業(yè)務(wù)服務(wù)層：此層是將各類業(yè)務(wù)功能分解成不同的服務(wù)，比如實(shí)時(shí)監(jiān)測(cè)服務(wù)、數(shù)據(jù)統(tǒng)計(jì)服務(wù)、配置管理服務(wù)、權(quán)限服務(wù)等，以此為功能模塊提供各類服務(wù)。

（5）功能模塊層：此層是功能界面展示實(shí)現(xiàn)層，根據(jù)不同的功能需求調(diào)用不同的業(yè)務(wù)層服接口；所有的調(diào)用都通過網(wǎng)關(guān)統(tǒng)一處理，實(shí)現(xiàn)權(quán)限驗(yàn)證和負(fù)載分配。

（6）SaaS 服務(wù)層：此層是通過配置將功能組合成不同的服務(wù)場(chǎng)景，服務(wù)于不同的用戶類型。

4.2 服務(wù)模式設(shè)計(jì)

SaaS 服務(wù)模式有四個(gè)等級(jí)的成熟度[6]，依此是：

（1）定制開發(fā)級(jí)：此級(jí)的SaaS 模式與傳統(tǒng)軟件模式的區(qū)別主要在于商業(yè)模式的不同，在部署方式和功能開發(fā)上基本一致。

（2）可配置級(jí)：此級(jí)的SaaS 模式創(chuàng)新在于通過實(shí)例配置為用戶提供服務(wù)，但是針對(duì)不同的用戶還是進(jìn)行獨(dú)立的部署。

（3）高性能多租戶架構(gòu)級(jí)：此級(jí)的SaaS 模式創(chuàng)新在于僅部署一個(gè)實(shí)例，通過配置的方式為全部用戶提供服務(wù)，這樣規(guī)避了以上2 級(jí)的缺點(diǎn)，但此級(jí)的模式還不能達(dá)到最優(yōu)化，因?yàn)楫?dāng)用戶量和使用量增加時(shí)，單一實(shí)例的部署將無法為用戶提供可靠的性能保障。

（4）可伸縮多租戶架構(gòu)級(jí)：此級(jí)的SaaS 模式創(chuàng)新在于通過負(fù)載均衡的方式部署多個(gè)相同的實(shí)例，以此來彌補(bǔ)單個(gè)實(shí)例部署的性能不足問題。

本文設(shè)計(jì)架構(gòu)采用第四級(jí)可伸縮多租戶架構(gòu)級(jí)，結(jié)合微服務(wù)理念，不僅部署多個(gè)實(shí)例，而且將實(shí)例分解成多個(gè)服務(wù)，最大限度的發(fā)揮微服務(wù)技術(shù)和SaaS 模式的融合優(yōu)勢(shì)。

4.3 微服務(wù)技術(shù)架構(gòu)設(shè)計(jì)

目前微服務(wù)技術(shù)體系架構(gòu)主要有Dubbo、.Net Core、Dubbogo、Spring Cloud 等。通過對(duì)比，本文所設(shè)計(jì)平臺(tái)架構(gòu)的微服務(wù)技術(shù)體系選擇阿里巴巴公司在Spring Cloud 基礎(chǔ)上擴(kuò)展的Spring Cloud Alibaba 技術(shù)棧，圖2 展示了此技術(shù)棧的主要技術(shù)內(nèi)容。

此技術(shù)架構(gòu)體系采用的主要技術(shù)介紹如下：

（1）Web 服務(wù)：采用Nginx 為應(yīng)用提供Web 服務(wù)。Nginx 具有占用系統(tǒng)內(nèi)存少，運(yùn)行穩(wěn)定性高等特性，是目前世界上使用最多的Web 服務(wù)器；負(fù)載均衡也是其提供基礎(chǔ)功能之一，它將為應(yīng)用提供分流的功能。

（2）服務(wù)網(wǎng)關(guān)與驗(yàn)證：設(shè)計(jì)采用Spring Cloud Gateway 網(wǎng)關(guān)作為統(tǒng)一的服務(wù)接口請(qǐng)求入庫，并采用OAuth2 對(duì)請(qǐng)求接口進(jìn)行驗(yàn)證，以此完成服務(wù)請(qǐng)求的驗(yàn)證與分發(fā)。

（3）服務(wù)注冊(cè)發(fā)現(xiàn)：設(shè)計(jì)采用Nacos 作為此技術(shù)體系的服務(wù)注冊(cè)發(fā)現(xiàn)技術(shù)。通過Nacos 我們可以簡(jiǎn)單的實(shí)現(xiàn)服務(wù)的動(dòng)態(tài)發(fā)現(xiàn)，配置和流量管理。

（4）熔斷限流：設(shè)計(jì)采用Sentinel 作為熔斷限流技術(shù)。

5 結(jié)束語

本文提出一種基于微服務(wù)的建筑能效管理SaaS 云平臺(tái)架構(gòu)設(shè)計(jì)。采用微服務(wù)架構(gòu)體系使得平臺(tái)的性能具有可擴(kuò)展性，保障了在建筑能耗及系統(tǒng)運(yùn)行數(shù)據(jù)不斷增長(zhǎng)的情況下，始終提供高性能服務(wù)。采用融合了微服務(wù)技術(shù)的可伸縮多租戶架構(gòu)模，保障了功能需求的多樣性和需求變化的快速響應(yīng)。按此設(shè)計(jì)實(shí)現(xiàn)的建筑能效管理云平臺(tái)，彌補(bǔ)了采用傳統(tǒng)架構(gòu)體系單體系統(tǒng)的不足，具有性能可擴(kuò)展、功能可擴(kuò)展性、資源可擴(kuò)展等特性，極大提高了建筑能效管理的水平和平臺(tái)價(jià)值。