基于微服務(wù)架構(gòu)B/S 系統(tǒng)的性能分析①

陳建海, 陳 淼,2, 浦云明

1(集美大學(xué) 計(jì)算機(jī)工程學(xué)院, 廈門(mén) 361021)

2(北京郵電大學(xué) 網(wǎng)絡(luò)技術(shù)研究院, 北京 100876)

常用的B/S 系統(tǒng)開(kāi)發(fā), 一般是基于單體應(yīng)用架構(gòu),例如Java 技術(shù)開(kāi)發(fā)的B/S 系統(tǒng), 一般選用SSH (Struct2、Spring、Hibernate)或者SSM (SpringMVC、Spring、Mybatis)框架, 開(kāi)發(fā)出一個(gè)war 包后將其部署到Tomcat中發(fā)布.單體應(yīng)用架構(gòu)的開(kāi)發(fā)、部署、測(cè)試較為容易,但隨著需求的不斷增加, 每一次系統(tǒng)的更新, 都需要將war 包重新部署, 并且war 包如同滾雪球一般越滾越大, 系統(tǒng)的可維護(hù)性、可靠性、靈活性逐漸降低, 維護(hù)成本越來(lái)越高, 任何一個(gè)bug 都會(huì)導(dǎo)致系統(tǒng)崩潰.隨著時(shí)間的推移, 整個(gè)程序的代碼量變得越來(lái)越大, 使得已有的系統(tǒng)設(shè)計(jì)和代碼變得難以維護(hù), 系統(tǒng)的構(gòu)建和部署時(shí)間也不斷增加.單體應(yīng)用中每次功能變更、bug 修復(fù)都會(huì)導(dǎo)致整個(gè)項(xiàng)目需要進(jìn)行重新部署, 增加了項(xiàng)目部署時(shí)間、成本和風(fēng)險(xiǎn).

為解決單體應(yīng)用的缺陷, Fowler M 提出了微服務(wù)架構(gòu)[1], 它完全不同于單體應(yīng)用架構(gòu), 將應(yīng)用程序邏輯拆分、設(shè)計(jì)、開(kāi)發(fā)為一組小型服務(wù), 這些小型服務(wù)只關(guān)注自身所負(fù)責(zé)的功能, 不關(guān)心其他服務(wù)及其內(nèi)部實(shí)現(xiàn).這些服務(wù)可以獨(dú)立部署在平臺(tái)即服務(wù)PaaS (Platform as a Service)上, 或者運(yùn)行在自己的進(jìn)程中, 進(jìn)程與進(jìn)程之間相互隔離, 降低各服務(wù)的耦合性, 服務(wù)間通信采用輕量級(jí)通信機(jī)制REST 風(fēng)格, REST 是資源表現(xiàn)層狀態(tài)轉(zhuǎn)換(REpresentational State Transfer), 所有獨(dú)立的服務(wù)構(gòu)成了一個(gè)完整的軟件系統(tǒng).這些服務(wù)由于部署在各自獨(dú)立的進(jìn)程中, 各服務(wù)間內(nèi)聚性大, 耦合性小, 可以采用不同的編程語(yǔ)言、不同的數(shù)據(jù)存儲(chǔ)技術(shù)實(shí)現(xiàn)系統(tǒng)功能.微服務(wù)架構(gòu)由于將服務(wù)分割專注化, 因此不會(huì)像傳統(tǒng)的單體應(yīng)用程序一樣, 修改一個(gè)bug 或增加一個(gè)功能就要重新進(jìn)行部署, 只需要將修改的服務(wù)重新部署, 不會(huì)影響其他服務(wù)的運(yùn)行.

本文的測(cè)試對(duì)象是基于微服務(wù)架構(gòu)的B/S 應(yīng)用系統(tǒng), 后端使用Spring Cloud 技術(shù), 前端使用JQuery、Bootstrap 以及Thymeleaf 模板, 數(shù)據(jù)庫(kù)使用MySQL,并采用非關(guān)系內(nèi)存數(shù)據(jù)庫(kù)Redis 進(jìn)行Session 模擬和部分基礎(chǔ)功能的實(shí)現(xiàn), 使用Intellij IDEA 集成開(kāi)發(fā)環(huán)境, 由于Spring Cloud 內(nèi)部集成了Tomcat, 所以只需要運(yùn)行啟動(dòng)類, 通過(guò)相應(yīng)地址就可以訪問(wèn)相關(guān)服務(wù).系統(tǒng)使用了Jmeter 測(cè)試工具, 對(duì)單體應(yīng)用和微服務(wù)架構(gòu)進(jìn)行不同級(jí)別的測(cè)試, 性能指標(biāo)上微服務(wù)系統(tǒng)架構(gòu)體現(xiàn)出明顯優(yōu)勢(shì).

1 微服務(wù)技術(shù)

系統(tǒng)前端技術(shù)采用開(kāi)源的Bootstrap 和JQuery 框架, 用戶輸入字符驗(yàn)證采用JQuery validate 框架,Bootstrap 已經(jīng)處于github 上星級(jí)項(xiàng)目(starred project)前列, 利于技術(shù)人員編寫(xiě)用戶體驗(yàn)良好的前端組件和動(dòng)作[2].

后端采用Spring Cloud 框架實(shí)現(xiàn)微服務(wù)的基本框架搭建, 數(shù)據(jù)連接與操作采用Mybatis, 用戶密碼采用Shiro 的MD5 加密, 防止被非法人員侵入數(shù)據(jù)庫(kù)后得到用戶密碼后進(jìn)行非法活動(dòng).系統(tǒng)后端與前端之間的數(shù)據(jù)交互采用json 字符串格式, 方便前端解析后端傳遞的內(nèi)容.數(shù)據(jù)方面, 選用MySQL 來(lái)存儲(chǔ)用戶以及系統(tǒng)文章、評(píng)論等的基本數(shù)據(jù), 由于各微服務(wù)運(yùn)行于各自隔離的進(jìn)程中, 無(wú)法將HTTP Session 交于統(tǒng)一的Servlet 容器, 因此采用內(nèi)存數(shù)據(jù)庫(kù)Redis 模擬實(shí)現(xiàn)Session.系統(tǒng)選用Maven 進(jìn)行Java 的依賴包管理和項(xiàng)目的搭建, 并使用Git 進(jìn)行項(xiàng)目的版本控制.

1) Spring Cloud 是在Java 快速開(kāi)發(fā)框架Spring Boot 基礎(chǔ)上構(gòu)建的一個(gè)開(kāi)發(fā)框架.它在Spring Boot 便利性的基礎(chǔ)上很好地降低了微服務(wù)系統(tǒng)實(shí)現(xiàn)的門(mén)檻,如實(shí)現(xiàn)微服務(wù)的注冊(cè)與發(fā)現(xiàn), 實(shí)現(xiàn)負(fù)載均衡, 實(shí)現(xiàn)REST 通信, 構(gòu)建微服務(wù)網(wǎng)關(guān)等一系列功能, 都可以使用Spring Cloud 通過(guò)最簡(jiǎn)單的配置或者幾行編碼就完成實(shí)現(xiàn)與部署[3].

2) Redis 是一個(gè)非關(guān)系數(shù)據(jù)庫(kù), 它可以存儲(chǔ)鍵與其他五種不同類型的值之間的映射關(guān)系.因?yàn)镽edis 數(shù)據(jù)庫(kù)本身是基于內(nèi)存存儲(chǔ)的, 所以redis 的處理與運(yùn)行速度相比于傳統(tǒng)的數(shù)據(jù)庫(kù)快速高效.Redis 還可以通過(guò)簡(jiǎn)單的設(shè)置就將存儲(chǔ)在內(nèi)存的數(shù)據(jù)持久化到硬盤(pán)中, 使之下次讀取的時(shí)候就可以直接從硬盤(pán)中獲取數(shù)據(jù).因?yàn)镽edis 不使用關(guān)系表結(jié)構(gòu)來(lái)進(jìn)行數(shù)據(jù)的存儲(chǔ), 所以Redis 的數(shù)據(jù)庫(kù)不會(huì)強(qiáng)制要求用戶對(duì)Redis 存儲(chǔ)不同的數(shù)據(jù)進(jìn)行相應(yīng)的關(guān)聯(lián)[4].使用Redis 使得用戶要求進(jìn)行數(shù)據(jù)持久化時(shí), 才將這些數(shù)據(jù)存儲(chǔ)在硬盤(pán)中, 從而提高整個(gè)系統(tǒng)代碼的運(yùn)行效率, 給用戶提供更好的運(yùn)行體驗(yàn).

3) REST 是一種軟件架構(gòu)風(fēng)格, 并不是一種軟件設(shè)計(jì)的標(biāo)準(zhǔn), REST 提供了一組設(shè)計(jì)原則和約束條件, 以尋求降低開(kāi)發(fā)的復(fù)雜性, 提高系統(tǒng)的可伸縮性的目的[5].

4) Mybatis 封裝了系統(tǒng)與數(shù)據(jù)庫(kù)的連接、校驗(yàn)、操作實(shí)現(xiàn)等底層代碼的實(shí)現(xiàn), 使得用戶可以使用XML配置或者M(jìn)ybatis 注解完成數(shù)據(jù)庫(kù)的連接, 操作, 關(guān)閉數(shù)據(jù)連接池等基本操作[6].相比于JDBC、Hibernate 操作數(shù)據(jù)庫(kù), Mybatis 代碼更具易讀性優(yōu)勢(shì).

5) Git 是目前軟件開(kāi)發(fā)領(lǐng)域中最好的分布式版本控制工具.是Linux 之父為了幫助管理Linux 內(nèi)核開(kāi)發(fā)所制作的一個(gè)開(kāi)源版本控制軟件[7].

6) Maven 是一個(gè)項(xiàng)目管理工具.開(kāi)發(fā)團(tuán)隊(duì)可以通過(guò)Maven 自動(dòng)完成項(xiàng)目的基礎(chǔ)工具建設(shè), Maven 使用標(biāo)準(zhǔn)的目錄結(jié)構(gòu)和默認(rèn)構(gòu)建生命周期[8].基于Maven 的Java 項(xiàng)目中, 其項(xiàng)目的依賴包是統(tǒng)一管理的, 有效避免Java 項(xiàng)目的依賴包因?yàn)榘姹驹蚨a(chǎn)生沖突.

7) Zuul 是微服務(wù)網(wǎng)關(guān)組件.微服務(wù)網(wǎng)關(guān)是介于客戶端和服務(wù)器端的中間層, 用戶提交的所有外部請(qǐng)求都會(huì)先經(jīng)過(guò)微服務(wù)網(wǎng)關(guān)的處理和過(guò)濾, 可以實(shí)現(xiàn)用戶身份認(rèn)證與安全、審查與監(jiān)控、動(dòng)態(tài)路由、壓力測(cè)試、負(fù)載分配、靜態(tài)響應(yīng)處理等功能.使用Zuul 微服務(wù)網(wǎng)關(guān)后, 實(shí)際上封裝了系統(tǒng)內(nèi)部的所有服務(wù), 用戶只需要和微服務(wù)網(wǎng)關(guān)交互, 不必直接調(diào)用微服務(wù)的相關(guān)接口[9].

8) Eureka 是用于實(shí)現(xiàn)微服務(wù)架構(gòu)中的服務(wù)注冊(cè)與發(fā)現(xiàn)的組件.服務(wù)提供者在服務(wù)啟動(dòng)時(shí), 將自身以及URL 等一些信息注冊(cè)到注冊(cè)組件中, 而服務(wù)注冊(cè)組件會(huì)存儲(chǔ)各個(gè)服務(wù)提供者的這些基本信息.各個(gè)微服務(wù)與服務(wù)發(fā)現(xiàn)組件之間通過(guò)一定機(jī)制進(jìn)行通信, 例如心跳機(jī)制, 即各個(gè)微服務(wù)每隔一定的時(shí)間向服務(wù)發(fā)現(xiàn)組件發(fā)送信息, 表示自己還在運(yùn)行中, 可以被調(diào)用, 若持續(xù)一段時(shí)間未向服務(wù)發(fā)現(xiàn)組件提供信息, 則服務(wù)發(fā)現(xiàn)組件會(huì)認(rèn)為該服務(wù)出現(xiàn)故障或者已被關(guān)閉, 則從注冊(cè)表中注銷該服務(wù)[10,11].

2 實(shí)驗(yàn)環(huán)境和應(yīng)用場(chǎng)景

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

1)操作系統(tǒng): Windows 10 企業(yè)版64 位.

2)數(shù)據(jù)庫(kù): MySQL 5.7; Redis.

3)軟件包: Java 8; Spring Cloud Camden.SR7;Spring Boot 1.5.3.RELEASE.

4)測(cè)試包: Junit4, Jmeter.

5)開(kāi)發(fā)工具: Intellij IDEA; Maven 3.3.9; Git.

2.2 應(yīng)用場(chǎng)景

測(cè)試系統(tǒng)分為前臺(tái)和后臺(tái)兩部分, 前臺(tái)為基本頁(yè)面, 用戶可以對(duì)前臺(tái)進(jìn)行查看和操作, 后臺(tái)是系統(tǒng)管理頁(yè)面, 系統(tǒng)管理員需要通過(guò)驗(yàn)證后進(jìn)行相關(guān)操作.

前臺(tái)頁(yè)面完成以下場(chǎng)景: (1)一般用戶訪問(wèn)主頁(yè)面,根據(jù)類別或者文章題目進(jìn)行文章查看; (2)用戶登錄后,可以查看個(gè)人信息, 并對(duì)部分個(gè)人信息進(jìn)行修改;用戶可以根據(jù)自己的需求發(fā)布文章; (3)用戶登錄后, 可以對(duì)所有文章進(jìn)行評(píng)論, 也可以對(duì)他人的評(píng)論進(jìn)行回復(fù),但一旦回復(fù)均無(wú)法刪除.

后臺(tái)頁(yè)面完成以下場(chǎng)景: (1)對(duì)非法用戶進(jìn)行刪除;(2)對(duì)違法文章和之下的所有評(píng)論進(jìn)行清理; (3)增加文章類別和發(fā)布文章; (4)將表現(xiàn)良好的用戶賦予管理員頭銜.

系統(tǒng)整體采用微服務(wù)架構(gòu), 如圖1 所示.每一個(gè)服務(wù)采用MVC架構(gòu)并擁有自己獨(dú)立數(shù)據(jù)源, 每個(gè)服務(wù)不需要其他服務(wù)的支持就可以獨(dú)立運(yùn)行.同時(shí)這些服務(wù)都注冊(cè)到Eureka 組件中, 相互之間使用REST 進(jìn)行通信, 充分降低了各服務(wù)之間的耦合度, 增加了系統(tǒng)的內(nèi)聚性[12].

圖1 微服務(wù)架構(gòu)圖

3 微服務(wù)性能分析

3.1 雪崩效應(yīng)處理機(jī)制

微服務(wù)之間是使用輕量級(jí)通信機(jī)制進(jìn)行通信, 當(dāng)某一個(gè)服務(wù)提供者因?yàn)榫W(wǎng)絡(luò)原因無(wú)法被調(diào)用時(shí), 其后的服務(wù)消費(fèi)者都會(huì)出現(xiàn)“級(jí)聯(lián)故障”, 即雪崩效應(yīng), 如圖2.

圖2 雪崩效應(yīng)

使用Spring Cloud 的Hystrix 提供的熔斷機(jī)制, 一旦服務(wù)提供者出現(xiàn)錯(cuò)誤導(dǎo)致服務(wù)消費(fèi)者無(wú)法調(diào)用, 系統(tǒng)會(huì)立即根據(jù)編碼人員的設(shè)置, 對(duì)請(qǐng)求失敗、超時(shí)執(zhí)行回退代碼, 防止雪崩效應(yīng), 從而提升整個(gè)系統(tǒng)的可用性.

3.2 實(shí)驗(yàn)性能測(cè)試

使用Jmeter 測(cè)試工具, 在近似相同環(huán)境下對(duì)基于微服務(wù)架構(gòu)系統(tǒng)與基于單體應(yīng)用的系統(tǒng)進(jìn)行測(cè)試, 為了盡可能保持測(cè)試數(shù)據(jù)的客觀性, 兩個(gè)系統(tǒng)的業(yè)務(wù)功能邏輯代碼實(shí)現(xiàn)基本相同.微服務(wù)系統(tǒng)測(cè)試結(jié)構(gòu)如圖3所示.

使用Jmeter 測(cè)試軟件, 對(duì)微服務(wù)與單體應(yīng)用兩個(gè)系統(tǒng)設(shè)置20 個(gè)用戶和50 個(gè)用戶, 進(jìn)行100 000 個(gè)樣本測(cè)試, 50 個(gè)用戶的單體應(yīng)用測(cè)試結(jié)果參見(jiàn)圖4.

圖3 微服務(wù)測(cè)試結(jié)構(gòu)圖

圖4 單體應(yīng)用(50 個(gè)線程)

以圖4 為例, 在100 000 個(gè)樣本中, 平均響應(yīng)時(shí)間為21 ms, 50%的響應(yīng)時(shí)間在2 ms 之內(nèi), 90%的響應(yīng)時(shí)間不超過(guò)80 ms, 最小響應(yīng)時(shí)間為1 ms, 最大響應(yīng)時(shí)間為489 ms, 出錯(cuò)率為0, 吞吐量為每秒2222 次, 接收數(shù)據(jù)量為25 583.25 KB/s, 發(fā)送數(shù)據(jù)量為253.88 KB/s.各測(cè)試數(shù)據(jù)匯總后, 性能數(shù)據(jù)如表1、表2.

表1 20 個(gè)用戶性能比較表

表2 50 個(gè)用戶性能比較表

由兩表對(duì)比可知, 在樣本數(shù)量近似相同的情況下,微服務(wù)架構(gòu)的論壇系統(tǒng)的響應(yīng)時(shí)間低于單體應(yīng)用的響應(yīng)時(shí)間, 吞吐量則比單體應(yīng)用的論壇系統(tǒng)高.原因是微服務(wù)架構(gòu)的論壇系統(tǒng)具有容錯(cuò)機(jī)制, 一旦基本服務(wù)發(fā)生無(wú)法訪問(wèn), 系統(tǒng)也將立即終止訪問(wèn), 從而返回用戶一個(gè)編碼時(shí)設(shè)定的缺省值, 之后會(huì)再重試調(diào)用出錯(cuò)的服務(wù), 所以無(wú)論系統(tǒng)是否出現(xiàn)錯(cuò)誤, 用戶都會(huì)得要一個(gè)友好界面和內(nèi)容, 保證了用戶的體驗(yàn)感.

3.3 部署時(shí)間分析

微服務(wù)架構(gòu)相較于單體應(yīng)用的最大優(yōu)勢(shì)就是部署效率較高, 傳統(tǒng)單體應(yīng)用每修改一個(gè)功能或者缺陷就必須關(guān)閉服務(wù)器重新部署整個(gè)項(xiàng)目, 隨著需求的不斷增大, 項(xiàng)目代碼量不斷增多, 重新部署耗費(fèi)更多時(shí)間.微服務(wù)由于采用領(lǐng)域驅(qū)動(dòng)設(shè)計(jì), 每個(gè)微服務(wù)之間相互隔離, 低耦合、高內(nèi)聚性使得微服務(wù)每修改一個(gè)功能或者缺陷只需要重新部署相對(duì)應(yīng)的微服務(wù), 其他服務(wù)可以繼續(xù)運(yùn)行不必停止.

實(shí)驗(yàn)1.分別對(duì)單體應(yīng)用和微服務(wù)架構(gòu)系統(tǒng)進(jìn)行部署, 記錄不同服務(wù)修改的部署平均時(shí)間, 每個(gè)服務(wù)修改一個(gè)功能, 部署時(shí)間見(jiàn)表3.

表3 不同服務(wù)數(shù)修改一個(gè)功能部署平均時(shí)間(ms)

實(shí)驗(yàn)2.分別修改單體應(yīng)用和微服務(wù)架構(gòu)系統(tǒng)中的同個(gè)服務(wù)中的多個(gè)功能, 平均部署時(shí)間數(shù)據(jù)見(jiàn)表4 所示.修改并部署較少服務(wù)的時(shí)候, 相比于單體應(yīng)用架構(gòu)的系統(tǒng), 微服務(wù)架構(gòu)在部署時(shí)間上花費(fèi)更少, 節(jié)省了約60%的部署時(shí)間.

表4 同個(gè)服務(wù)中修改不同功能后部署平均時(shí)間(ms)

基于微服務(wù)架構(gòu)的測(cè)試系統(tǒng)共由8 個(gè)不同服務(wù)構(gòu)成, 由表3 數(shù)據(jù)可得, 當(dāng)修改服務(wù)數(shù)不超過(guò)兩個(gè)時(shí), 即修改服務(wù)數(shù)占總系統(tǒng)服務(wù)數(shù)的20%左右時(shí), 微服務(wù)部署時(shí)間少于單體應(yīng)用架構(gòu)的部署時(shí)間.實(shí)驗(yàn)結(jié)果也符合軟件故障80/20 原則.依據(jù)表4 可知, 當(dāng)所有修改的功能模塊是位于同個(gè)服務(wù)中時(shí), 微服務(wù)架構(gòu)的部署的時(shí)間相比于單體應(yīng)用架構(gòu)明顯加快, 原因在于微服務(wù)修改功能模塊都在同一個(gè)服務(wù)中, 只要部署該服務(wù)而不必重新部署整個(gè)系統(tǒng), 所以避免花費(fèi)許多不必要的部署時(shí)間和資源, 相反, 單體應(yīng)用架構(gòu)的系統(tǒng), 無(wú)論修改的功能是否在同一個(gè)模塊中, 都得重新部署整個(gè)系統(tǒng), 大大浪費(fèi)了部署資源和時(shí)間.因此, 微服務(wù)架構(gòu)對(duì)于軟件系統(tǒng)的維護(hù)與部署有著很好的性能優(yōu)勢(shì).

4 結(jié)論和下一步工作

微服務(wù)是一個(gè)細(xì)粒度的SOA (Service-Oriented Architecture, 面向服務(wù)架構(gòu)), 服務(wù)的劃分基于領(lǐng)域驅(qū)動(dòng)設(shè)計(jì), 每個(gè)微服務(wù)只專注自己的職責(zé), 符合軟件設(shè)計(jì)高內(nèi)聚、低耦合原則.微服務(wù)單獨(dú)部署, 服務(wù)之間使用REST 風(fēng)格通信機(jī)制, 各個(gè)微服務(wù)部署在不同主機(jī)并采用分布式管理機(jī)制.

傳統(tǒng)單體應(yīng)用程序在項(xiàng)目變得越來(lái)越龐大時(shí), 任意一個(gè)bug 將導(dǎo)致整個(gè)應(yīng)用系統(tǒng)重新部署.微服務(wù)架構(gòu)只需要部署更新的微服務(wù), 任何一個(gè)功能修改, 只需要停止對(duì)應(yīng)的微服務(wù), 不需要暫停整個(gè)系統(tǒng), 解決了bug 修復(fù)和系統(tǒng)更新需要停止整個(gè)系統(tǒng)訪問(wèn)的問(wèn)題.從實(shí)驗(yàn)結(jié)果看, 系統(tǒng)的性能在微服務(wù)架構(gòu)系統(tǒng)上具有明顯優(yōu)勢(shì).

未來(lái)將使用容器引擎Docker 更快地將微服務(wù)進(jìn)行打包、測(cè)試以及部署.基于進(jìn)程隔離技術(shù)的Docker,將縮短從編碼到部署運(yùn)行的周期.