基于微服務(wù)架構(gòu)的病原微生物數(shù)據(jù)分析平臺設(shè)計與應(yīng)用

徐建國，田川

（山東科技大學 計算機科學與工程學院，山東 青島 266590）

0 引言

在Java Web開發(fā)中，中小型企業(yè)一般選擇傳統(tǒng)的MVC架構(gòu)，這種單體應(yīng)用架構(gòu)開發(fā)方式在一個項目中包含了所有的業(yè)務(wù)邏輯[1]。在項目開發(fā)初期這種開發(fā)方式有利于項目功能的水平擴展，并具備一定的業(yè)務(wù)承載能力。首先，隨著業(yè)務(wù)的擴大，系統(tǒng)的代碼量會越來越大，耦合度會越來越高，系統(tǒng)變的難以維護、擴展。其次，隨著服務(wù)量的不斷增長，MVC架構(gòu)的應(yīng)用在一臺機器一個進程里完成所有功能的運行模式無法滿足高并發(fā)訪問的需求[2-4]。

隨著云計算平臺的日益普及，云計算平臺支持高性能的SaaS（Software-as-a-Service,軟件即服務(wù)）應(yīng)用，而微服務(wù)架構(gòu)作為軟件開發(fā)架構(gòu)的演進方向之一，已成為一種SaaS應(yīng)用在云平臺的可行落地方案[5]。微服務(wù)的基本思想是將傳統(tǒng)的單體應(yīng)用按業(yè)務(wù)功能拆分為一系列可被獨立設(shè)計、開發(fā)、部署、運維的軟件服務(wù)單元，服務(wù)間彼此配合、相互協(xié)作以實現(xiàn)最終價值[6-7]。

現(xiàn)有的病原微生物數(shù)據(jù)分析平臺采用了傳統(tǒng)的MVC架構(gòu)，隨著用戶與數(shù)據(jù)量的增多，單體架構(gòu)已經(jīng)遠遠無法滿足現(xiàn)有的需求。本文將提出一套方案，將系統(tǒng)重構(gòu)為微服務(wù)架構(gòu),本文后續(xù)章節(jié)組織如下，第1章節(jié)介紹了前后端分離解耦方案；第2章節(jié)介紹了數(shù)據(jù)庫切分方案；第3章節(jié)介紹了平臺功能服務(wù)化；第4章節(jié)介紹了系統(tǒng)重構(gòu)后的軟件架構(gòu)；第5章節(jié)對工作進行了總結(jié)。

1 前后端分離

前后端分離是目前互聯(lián)網(wǎng)項目開發(fā)的業(yè)界標準，通過nginx+tomcat進行前后端解耦，為之后的平臺功能服務(wù)化打下堅實的基礎(chǔ)[8-9]。前端與后端有兩種協(xié)作方式，一種是服務(wù)器端（后端）渲染的方式，見圖1另一種是客戶端（前端、瀏覽器端）渲染的方式，見圖2。

圖1 服務(wù)器端渲染的方式

圖2 客戶端渲染的方式

原有項目使用的就是第一種方式，該方式收到瀏覽器請求后，使用thymeleaf HTML5模板引擎在服務(wù)器端就將網(wǎng)頁生成，把整個HTML網(wǎng)頁返回給瀏覽器。

本文在前端引入Ajax，后端引入RESTful API，將前端項目部署在nginx服務(wù)器上，后端項目部署在tomcat服務(wù)器上，使得項目變?yōu)榈诙N前后端的協(xié)作方式。在第二種方式下，前后端被分離開來，除了接口以外的其他所有http請求（html、js、css等靜態(tài)文件）全部轉(zhuǎn)移到前端nginx服務(wù)器上，接口的請求是通過Ajax向服務(wù)器端發(fā)出請求，服務(wù)器只返回JSON格式的業(yè)務(wù)數(shù)據(jù)，由瀏覽器將數(shù)據(jù)渲染，這種方式不僅降低了前后端傳遞的數(shù)據(jù)量，而且將數(shù)據(jù)渲染的任務(wù)交給瀏覽器完成，大大降低了服務(wù)器的負載壓力[10]。

2 數(shù)據(jù)庫垂直切分

垂直切分是根據(jù)業(yè)務(wù)來拆分數(shù)據(jù)庫，同一類業(yè)務(wù)的數(shù)據(jù)表拆分到一個獨立的數(shù)據(jù)庫，另一類的數(shù)據(jù)表拆分到其他數(shù)據(jù)庫[11]。

原有的平臺使用的是一個單點數(shù)據(jù)庫，所有的讀寫請求都發(fā)到一個mysql上面，所以數(shù)據(jù)庫的負載太高。通過對原有項目的數(shù)據(jù)庫表結(jié)構(gòu)進行分析研究，發(fā)現(xiàn)數(shù)據(jù)分析的五個主要功能模塊所訪問的數(shù)據(jù)庫表之間并無外鍵約束，故可以將原有單點數(shù)據(jù)庫按業(yè)務(wù)的不同垂直切分，切分結(jié)果如表1所示。

表1 垂直切分方案

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

圖3 客戶端渲染的方式

3 功能服務(wù)化

Spring Cloud Eureka組件提供了一套服務(wù)注冊與發(fā)現(xiàn)機制，通過架設(shè)一個Eureka Server，將原有的每個功能模塊獨立出來改造為Eureka Client并注冊到Eureka Server上，就實現(xiàn)了功能的服務(wù)化。服務(wù)化結(jié)果如圖4所示。

圖4 Eureka服務(wù)注冊中心

4 軟件架構(gòu)設(shè)計

經(jīng)過功能服務(wù)化之后，基于Spring Cloud中的組件完善軟件架構(gòu)：最終的軟件架構(gòu)如圖5所示。

圖5 軟件架構(gòu)設(shè)計

（1）Zuul組件是Spring Cloud中的微服務(wù)網(wǎng)關(guān)，請求首先通過網(wǎng)關(guān)，進行路徑的路由，定位到具體的服務(wù)節(jié)點上。Zuul的第二個功能就是斷路器，如果一個微服務(wù)不可用，會導致一個請求漫長的等待，最終返回超時。而Zuul熔斷機制可以在某個微服務(wù)不可用時立即進入自定義處理邏輯。

（2）Ribbon組件是Spring Cloud中的負載均衡組件，用它可以實現(xiàn)同一種微服務(wù)實例之間的負載均衡。

5 結(jié)語

本文結(jié)合數(shù)據(jù)分析平臺并發(fā)訪問的需求，針對單體架構(gòu)下的不足，通過對原有平臺的設(shè)計文檔的綜合，提出了一種重構(gòu)方案。選擇Spring Cloud框架作為微服務(wù)架構(gòu)一站式解決方案，在前后端分離、單點數(shù)據(jù)庫垂直拆分的基礎(chǔ)上,重新設(shè)計了病原微生物數(shù)據(jù)分析平臺的軟件架構(gòu)。提高了系統(tǒng)的可擴展性、可用性，極大提升了系統(tǒng)并發(fā)訪問性能指標，為平臺的進一步發(fā)展提供了堅實基礎(chǔ)。