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

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

1(集美大學 計算機工程學院, 廈門 361021)

2(北京郵電大學 網(wǎng)絡技術研究院, 北京 100876)

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

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

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

1 微服務技術

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

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

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

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

3) REST 是一種軟件架構風格, 并不是一種軟件設計的標準, REST 提供了一組設計原則和約束條件, 以尋求降低開發(fā)的復雜性, 提高系統(tǒng)的可伸縮性的目的[5].

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

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

6) Maven 是一個項目管理工具.開發(fā)團隊可以通過Maven 自動完成項目的基礎工具建設, Maven 使用標準的目錄結構和默認構建生命周期[8].基于Maven 的Java 項目中, 其項目的依賴包是統(tǒng)一管理的, 有效避免Java 項目的依賴包因為版本原因而產(chǎn)生沖突.

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

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

2 實驗環(huán)境和應用場景

2.1 實驗環(huán)境

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

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

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

4)測試包: Junit4, Jmeter.

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

2.2 應用場景

測試系統(tǒng)分為前臺和后臺兩部分, 前臺為基本頁面, 用戶可以對前臺進行查看和操作, 后臺是系統(tǒng)管理頁面, 系統(tǒng)管理員需要通過驗證后進行相關操作.

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

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

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

圖1 微服務架構圖

3 微服務性能分析

3.1 雪崩效應處理機制

微服務之間是使用輕量級通信機制進行通信, 當某一個服務提供者因為網(wǎng)絡原因無法被調用時, 其后的服務消費者都會出現(xiàn)“級聯(lián)故障”, 即雪崩效應, 如圖2.

圖2 雪崩效應

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

3.2 實驗性能測試

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

使用Jmeter 測試軟件, 對微服務與單體應用兩個系統(tǒng)設置20 個用戶和50 個用戶, 進行100 000 個樣本測試, 50 個用戶的單體應用測試結果參見圖4.

圖3 微服務測試結構圖

圖4 單體應用(50 個線程)

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

表1 20 個用戶性能比較表

表2 50 個用戶性能比較表

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

3.3 部署時間分析

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

實驗1.分別對單體應用和微服務架構系統(tǒng)進行部署, 記錄不同服務修改的部署平均時間, 每個服務修改一個功能, 部署時間見表3.

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

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

表4 同個服務中修改不同功能后部署平均時間(ms)

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

4 結論和下一步工作

微服務是一個細粒度的SOA (Service-Oriented Architecture, 面向服務架構), 服務的劃分基于領域驅動設計, 每個微服務只專注自己的職責, 符合軟件設計高內聚、低耦合原則.微服務單獨部署, 服務之間使用REST 風格通信機制, 各個微服務部署在不同主機并采用分布式管理機制.

傳統(tǒng)單體應用程序在項目變得越來越龐大時, 任意一個bug 將導致整個應用系統(tǒng)重新部署.微服務架構只需要部署更新的微服務, 任何一個功能修改, 只需要停止對應的微服務, 不需要暫停整個系統(tǒng), 解決了bug 修復和系統(tǒng)更新需要停止整個系統(tǒng)訪問的問題.從實驗結果看, 系統(tǒng)的性能在微服務架構系統(tǒng)上具有明顯優(yōu)勢.

未來將使用容器引擎Docker 更快地將微服務進行打包、測試以及部署.基于進程隔離技術的Docker,將縮短從編碼到部署運行的周期.