基于微服務架構B/S 系統的性能分析①

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

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

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

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

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

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

1 微服務技術

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

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

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

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

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

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

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

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

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

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

2 實驗環境和應用場景

2.1 實驗環境

1)操作系統: Windows 10 企業版64 位.

2)數據庫: MySQL 5.7; Redis.

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

4)測試包: Junit4, Jmeter.

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

2.2 應用場景

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

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

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

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

圖1 微服務架構圖

3 微服務性能分析

3.1 雪崩效應處理機制

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

圖2 雪崩效應

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

3.2 實驗性能測試

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

使用Jmeter 測試軟件, 對微服務與單體應用兩個系統設置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 次, 接收數據量為25 583.25 KB/s, 發送數據量為253.88 KB/s.各測試數據匯總后, 性能數據如表1、表2.

表1 20 個用戶性能比較表

表2 50 個用戶性能比較表

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

3.3 部署時間分析

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

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

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

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

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

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

4 結論和下一步工作

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

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

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