徐建國,田川
(山東科技大學 計算機科學與工程學院,山東 青島 266590)
在Java Web開發中,中小型企業一般選擇傳統的MVC架構,這種單體應用架構開發方式在一個項目中包含了所有的業務邏輯[1]。在項目開發初期這種開發方式有利于項目功能的水平擴展,并具備一定的業務承載能力。首先,隨著業務的擴大,系統的代碼量會越來越大,耦合度會越來越高,系統變的難以維護、擴展。其次,隨著服務量的不斷增長,MVC架構的應用在一臺機器一個進程里完成所有功能的運行模式無法滿足高并發訪問的需求[2-4]。
隨著云計算平臺的日益普及,云計算平臺支持高性能的SaaS(Software-as-a-Service,軟件即服務)應用,而微服務架構作為軟件開發架構的演進方向之一,已成為一種SaaS應用在云平臺的可行落地方案[5]。微服務的基本思想是將傳統的單體應用按業務功能拆分為一系列可被獨立設計、開發、部署、運維的軟件服務單元,服務間彼此配合、相互協作以實現最終價值[6-7]。
現有的病原微生物數據分析平臺采用了傳統的MVC架構,隨著用戶與數據量的增多,單體架構已經遠遠無法滿足現有的需求。本文將提出一套方案,將系統重構為微服務架構,本文后續章節組織如下,第1章節介紹了前后端分離解耦方案;第2章節介紹了數據庫切分方案;第3章節介紹了平臺功能服務化;第4章節介紹了系統重構后的軟件架構;第5章節對工作進行了總結。
前后端分離是目前互聯網項目開發的業界標準,通過nginx+tomcat進行前后端解耦,為之后的平臺功能服務化打下堅實的基礎[8-9]。前端與后端有兩種協作方式,一種是服務器端(后端)渲染的方式,見圖1另一種是客戶端(前端、瀏覽器端)渲染的方式,見圖2。

圖1 服務器端渲染的方式

圖2 客戶端渲染的方式
原有項目使用的就是第一種方式,該方式收到瀏覽器請求后,使用thymeleaf HTML5模板引擎在服務器端就將網頁生成,把整個HTML網頁返回給瀏覽器。
本文在前端引入Ajax,后端引入RESTful API,將前端項目部署在nginx服務器上,后端項目部署在tomcat服務器上,使得項目變為第二種前后端的協作方式。在第二種方式下,前后端被分離開來,除了接口以外的其他所有http請求(html、js、css等靜態文件)全部轉移到前端nginx服務器上,接口的請求是通過Ajax向服務器端發出請求,服務器只返回JSON格式的業務數據,由瀏覽器將數據渲染,這種方式不僅降低了前后端傳遞的數據量,而且將數據渲染的任務交給瀏覽器完成,大大降低了服務器的負載壓力[10]。
垂直切分是根據業務來拆分數據庫,同一類業務的數據表拆分到一個獨立的數據庫,另一類的數據表拆分到其他數據庫[11]。
原有的平臺使用的是一個單點數據庫,所有的讀寫請求都發到一個mysql上面,所以數據庫的負載太高。通過對原有項目的數據庫表結構進行分析研究,發現數據分析的五個主要功能模塊所訪問的數據庫表之間并無外鍵約束,故可以將原有單點數據庫按業務的不同垂直切分,切分結果如表1所示。

表1 垂直切分方案
如圖3所示,垂直切分后的數據庫讀寫請求被分散到了多個mysql數據庫節點上,雖然在一定程度上增加了服務器租賃成本,但是有效的解決了原有數據庫負載過高的問題。

圖3 客戶端渲染的方式
Spring Cloud Eureka組件提供了一套服務注冊與發現機制,通過架設一個Eureka Server,將原有的每個功能模塊獨立出來改造為Eureka Client并注冊到Eureka Server上,就實現了功能的服務化。服務化結果如圖4所示。

圖4 Eureka服務注冊中心
經過功能服務化之后,基于Spring Cloud中的組件完善軟件架構:最終的軟件架構如圖5所示。

圖5 軟件架構設計
(1)Zuul組件是Spring Cloud中的微服務網關,請求首先通過網關,進行路徑的路由,定位到具體的服務節點上。Zuul的第二個功能就是斷路器,如果一個微服務不可用,會導致一個請求漫長的等待,最終返回超時。而Zuul熔斷機制可以在某個微服務不可用時立即進入自定義處理邏輯。
(2)Ribbon組件是Spring Cloud中的負載均衡組件,用它可以實現同一種微服務實例之間的負載均衡。
本文結合數據分析平臺并發訪問的需求,針對單體架構下的不足,通過對原有平臺的設計文檔的綜合,提出了一種重構方案。選擇Spring Cloud框架作為微服務架構一站式解決方案,在前后端分離、單點數據庫垂直拆分的基礎上,重新設計了病原微生物數據分析平臺的軟件架構。提高了系統的可擴展性、可用性,極大提升了系統并發訪問性能指標,為平臺的進一步發展提供了堅實基礎。