洪華軍 吳建波 冷文浩

（中國船舶科學(xué)研究中心軟件工程技術(shù)中心 無錫 214082）

1 引言

隨著企業(yè)信息化的發(fā)展，應(yīng)用系統(tǒng)的數(shù)量、規(guī)模和復(fù)雜度不斷增長，應(yīng)用實現(xiàn)越來越復(fù)雜，代碼規(guī)模越來越大，系統(tǒng)變得更加笨重和龐大，導(dǎo)致應(yīng)用難以維護和更新。原有的單一應(yīng)用架構(gòu)，由于邏輯過于耦合已無法應(yīng)對；垂直應(yīng)用架構(gòu)，由于應(yīng)用之間交互越來越多，越來越復(fù)雜已不再適應(yīng)；分布式服務(wù)架構(gòu)，由于服務(wù)越來越多，容量的評估，小服務(wù)資源的浪費等問題逐漸顯現(xiàn)。

針對當(dāng)前企業(yè)信息化的現(xiàn)狀，對系統(tǒng)的開發(fā)和部署提出了新的挑戰(zhàn)，對企業(yè)應(yīng)用架構(gòu)的高效性和擴展性提出了更高的要求［1］。微服務(wù)架構(gòu)的出現(xiàn)，有效解決了當(dāng)前企業(yè)信息化面臨的一系列問題?？梢酝ㄟ^微服務(wù)架構(gòu)將復(fù)雜應(yīng)用進行服務(wù)化切分，把一個大而復(fù)雜的問題化解為多個小而簡單的問題，使用一套小服務(wù)來開發(fā)單個應(yīng)用，實現(xiàn)微小服務(wù)功能。服務(wù)之間以輕量級通信的協(xié)調(diào)機制，以業(yè)務(wù)為中心，通過契約來約定依賴，構(gòu)建起獨立的自動化運行機制，以實現(xiàn)集中式服務(wù)管理［2］。

2 微服務(wù)原理

2.1 微服務(wù)架構(gòu)定義

微服務(wù)［3］是一些協(xié)同工作的小而自治的服務(wù)。它具有高內(nèi)聚性和高自治性。微服務(wù)根據(jù)業(yè)務(wù)的邊界來確定服務(wù)的邊界。同時，它也是一個獨立的實體，可以獨立地部署在PaaS上，也可以作為一個操作系統(tǒng)進程存在。服務(wù)之間均通過網(wǎng)絡(luò)調(diào)用進行通信，從而加強服務(wù)之間的隔離性，避免緊耦合［3］。

微服務(wù)架構(gòu)是一種架構(gòu)模式，它將單一應(yīng)用程序劃分成一組小的服務(wù)，服務(wù)之間相互協(xié)調(diào)、相互配合。每個服務(wù)運行在其獨立的進程中，服務(wù)與服務(wù)間采用輕量級的通信機制相互溝通。每個服務(wù)都圍繞著具體業(yè)務(wù)進行構(gòu)建，并且能夠被獨立地部署到生產(chǎn)環(huán)境、類生產(chǎn)環(huán)境等。另外，應(yīng)盡量避免統(tǒng)一的、集中式的服務(wù)管理機制，對具體的一個服務(wù)而言，應(yīng)根據(jù)業(yè)務(wù)上下文，選擇合適的語言，工具對其進行構(gòu)建［4］。

2.2 微服務(wù)架構(gòu)優(yōu)勢

微服務(wù)架構(gòu)模式有眾多優(yōu)勢［4～5］。

1）組件化

微服務(wù)可以被認(rèn)為是一種組件。它與傳統(tǒng)組件方式最大的區(qū)別是，傳統(tǒng)組件將應(yīng)用模塊化并為其構(gòu)建相對獨立的單元。隔離獨立的部分或抽取公用的部分，構(gòu)建共享庫，達到解耦和復(fù)用的效果。而微服務(wù)架構(gòu)將系統(tǒng)以組件化的方式分解為多個服務(wù)，服務(wù)之間相對獨立且松耦合，單一功能的改變只需要重新構(gòu)建部署相應(yīng)的服務(wù)。

2）獨立部署

由于微服務(wù)具備獨立的運行進程，所以每個微服務(wù)也可以獨立部署。當(dāng)某個微服務(wù)發(fā)生變更時無需編譯、部署整個應(yīng)用，大大縮短應(yīng)用交付周期。微服務(wù)架構(gòu)模式使得持續(xù)化部署成為可能。

3）降低復(fù)雜度

微服務(wù)架構(gòu)通過分解單體式應(yīng)用為多個服務(wù)方法，讓復(fù)雜性可控，避免不必要的數(shù)據(jù)孤島。在功能不變的情況下，應(yīng)用被分解為多個可管理的服務(wù)，通過微服務(wù)架構(gòu)模式，讓復(fù)雜的功能，通過模塊化的方式呈現(xiàn)，給采用單體應(yīng)用編碼方式難以實現(xiàn)的功能提供模塊化的解決方案，讓單個服務(wù)更容易開發(fā)和維護。

4）技術(shù)多元化

傳統(tǒng)的開發(fā)模式一般是使用同類技術(shù)構(gòu)建整個應(yīng)用。微服務(wù)架構(gòu)強調(diào)的是去中心化的軟件組織架構(gòu)，使每個服務(wù)根據(jù)自身服務(wù)的需求和行業(yè)發(fā)展?fàn)顩r做出自己的判斷，選擇適合的技術(shù)類型，提供接口服務(wù)。

5）降低維護風(fēng)險

維護龐大且復(fù)雜的單塊架構(gòu)系統(tǒng)，工作量很大，容易出現(xiàn)牽一發(fā)動全身，風(fēng)險很高。相較而言，微服務(wù)架構(gòu)模式下，當(dāng)某一組件發(fā)生故障時，不會發(fā)現(xiàn)單塊架構(gòu)系統(tǒng)的進程內(nèi)擴散等弊端，故障會被隔離在單個服務(wù)中，從而降低維護和再開發(fā)的風(fēng)險。

2.3 微服務(wù)架構(gòu)不足及應(yīng)對措施［6～7］

1）微服務(wù)邊界

應(yīng)用微服務(wù)過程中，容易出現(xiàn)無法很好地界定模塊之間的界限，造成微服務(wù)過大或者過小。微服務(wù)過大，會出現(xiàn)同單塊架構(gòu)系統(tǒng)類似的不足，微服務(wù)過小，管理大量的服務(wù)也很復(fù)雜。

如何確定邊界？采用業(yè)務(wù)領(lǐng)域模型驅(qū)動數(shù)據(jù)模型設(shè)計方法，建立并完善整套業(yè)務(wù)領(lǐng)域模型，包含上下文中關(guān)于邊界的各項定義。這些明確的邊界將是微服務(wù)的邊界，或是微服務(wù)邊界內(nèi)組件。

2）分布式應(yīng)用的復(fù)雜性

分布式應(yīng)用相比單體式應(yīng)用，具有固有的復(fù)雜性。需要在RPC或者消息傳遞之間選擇并完成進程間的通訊。更需要處理消息傳遞中速度過慢或者不可用等局部失效問題。

充分考慮網(wǎng)絡(luò)延遲、容錯、消息序列化、不可靠的網(wǎng)絡(luò)、異步、版本控制、負(fù)載等對微服務(wù)的影響，采用一整套完整的機制來保證各個服務(wù)可以正常運轉(zhuǎn)。

3）分區(qū)的數(shù)據(jù)庫架構(gòu)

在微服務(wù)架構(gòu)應(yīng)用中，一個微服務(wù)對應(yīng)一個數(shù)據(jù)庫，需要更新不同服務(wù)所對應(yīng)的不同數(shù)據(jù)庫。才能夠時刻確保分布式數(shù)據(jù)系統(tǒng)當(dāng)中不同形式數(shù)據(jù)的一致性與并發(fā)性。

根據(jù)CAP定理，分布式系統(tǒng)中有三方面需要彼此權(quán)衡：C（一致性）、A（可用性）和P（分區(qū)容忍性），最多只能保證三個中的兩個。做為一個系統(tǒng)整體，不需要全部是AP或者CP。如目錄服務(wù)可以是AP，因為不關(guān)注歷史信息，但是數(shù)據(jù)臺帳信息一般需要CP，因為不能讓用戶看到修改前的記錄信息。因此需要為每個服務(wù)調(diào)用做不同的權(quán)衡，來解決微服務(wù)架構(gòu)應(yīng)用中分布式數(shù)據(jù)問題。

4）部署復(fù)雜

相比于單體式應(yīng)用，一個微服務(wù)應(yīng)用一般由大批服務(wù)構(gòu)成，且是多實例化的。這需要整個應(yīng)用有眾多的配置、部署、擴展和監(jiān)控功能。

通過使用PaaS服務(wù)實現(xiàn)部署自動化，PaaS提供一個部署和管理微服務(wù)的簡單方法，它把所有這些問題都打包內(nèi)置。并使用一個集群化方案，比如配合Docker容器技術(shù)使用Mesos，在微服務(wù)層面提供緩存、權(quán)限控制、API統(tǒng)計和監(jiān)控。

3 基于微服務(wù)架構(gòu)的設(shè)計

針對當(dāng)前開發(fā)和維護的綜合業(yè)務(wù)管理系統(tǒng)應(yīng)用過程中出現(xiàn)的單體結(jié)構(gòu)應(yīng)用無法解決的問題，對其核心架構(gòu)進行設(shè)計。

綜合業(yè)務(wù)管理系統(tǒng)是一種兩級業(yè)務(wù)系統(tǒng)，分為一個集團級系統(tǒng)和20個所級系統(tǒng)，每個系統(tǒng)包含合同管理子系統(tǒng)，計劃管理子系統(tǒng)，項目管理子系統(tǒng)，財務(wù)管理子系統(tǒng)，成果管理子系統(tǒng)，質(zhì)量管理子系統(tǒng)，器材管理子系統(tǒng)等20個子系統(tǒng)。從職能上講，集團級系統(tǒng)對所級系統(tǒng)有計劃下發(fā)，項目監(jiān)管，財務(wù)預(yù)算等宏觀總體上的把控，每個所級系統(tǒng)更關(guān)注對計劃執(zhí)行，項目執(zhí)行，財務(wù)結(jié)算，質(zhì)量過程管理等具體執(zhí)行過程進行管理。集團級和所級系統(tǒng)既有共性，又有區(qū)別。不同的所級系統(tǒng)由于獨立運作，組織結(jié)構(gòu)和具體執(zhí)行情況也有所區(qū)別。

3.1 微服務(wù)劃分

根據(jù)當(dāng)前系統(tǒng)建設(shè)的實際情況，將微服務(wù)分為共享微服務(wù)和定制微服務(wù)。共享微服務(wù)又分為基礎(chǔ)平臺共享微服務(wù)和業(yè)務(wù)共享微服務(wù)，都提供集團級、所級系統(tǒng)相同的微服務(wù)。定制微服務(wù)是對共享微服務(wù)無法滿足單位實際業(yè)務(wù)需求的情況下的擴展。表1列出系統(tǒng)部分微服務(wù)。

表1 微服務(wù)列表

各微服務(wù)都定義成獨立的服務(wù)接口，相比于原來單體結(jié)構(gòu)的難以維護的情況，新的系統(tǒng)由實現(xiàn)不同功能的微服務(wù)組成，每個微服務(wù)只關(guān)注單一的業(yè)務(wù)功能。

3.2 微服務(wù)框架的選擇

通過對主流開源微服務(wù)框架的比對，和現(xiàn)有系統(tǒng)的實際情況：使用Spring作為容器框架、SpringMVC作為模型控制器框架。故選擇Spring Cloud作為本系統(tǒng)的微服務(wù)應(yīng)用框架，它能夠與當(dāng)前系統(tǒng)無縫集成。

Spring Cloud［8］是一套完整的分布式系統(tǒng)解決方案，從網(wǎng)關(guān)服務(wù)Zuul，到服務(wù)發(fā)現(xiàn)Eureka，再到Hystrix熔斷機制，它的子項目涵蓋所有實現(xiàn)分布式系統(tǒng)所需要的基礎(chǔ)軟件設(shè)施?；赟pring Boot，使得開發(fā)部署變?yōu)楹唵?，通過加依賴和注解，就能運行。

3.3 微服務(wù)應(yīng)用總體架構(gòu)設(shè)計

微服務(wù)應(yīng)用總體架構(gòu)［6，9］如圖1所示。

圖1 微服務(wù)應(yīng)用總體架構(gòu)圖

由Spring Cloud組件和構(gòu)建的微服務(wù)組成。通過Zuul實現(xiàn)服務(wù)網(wǎng)關(guān)，統(tǒng)一向外系統(tǒng)提供REST API；Ribbon實現(xiàn)服務(wù)的消費以及均衡負(fù)載；Eureka實現(xiàn)服務(wù)注冊中心以及服務(wù)注冊與發(fā)現(xiàn)；Spring Cloud Config實現(xiàn)應(yīng)用多環(huán)境的外部化配置以及版本管理；Hystrix的融斷機制來避免在微服務(wù)架構(gòu)中個別服務(wù)出現(xiàn)異常時引起的故障蔓延。

定制微服務(wù)、業(yè)務(wù)共享微服務(wù)、基礎(chǔ)平臺共享微服務(wù)都注冊與訂閱微服務(wù)到Eureka，并通過均衡負(fù)載向外提供微服務(wù)調(diào)用。各微服務(wù)都有對應(yīng)的獨立業(yè)務(wù)數(shù)據(jù)子庫。

3.4 系統(tǒng)功能結(jié)構(gòu)設(shè)計

提供一套完整的平臺，由基礎(chǔ)平臺、業(yè)務(wù)共享微服務(wù)共同構(gòu)成，供集團、所兩級使用。集團總部將一套完整平臺派發(fā)到20個所級單位。各所級單位根據(jù)自身的實際業(yè)務(wù)情況，對完整平臺的子系統(tǒng)進行選配，構(gòu)成本單位的綜合管理業(yè)務(wù)系統(tǒng)。當(dāng)實際業(yè)務(wù)與完整平臺不一致的情況，通過業(yè)務(wù)定制微服務(wù)的方式，進行個性化定制開發(fā)，滿足各單位的實際需要。系統(tǒng)功能結(jié)構(gòu)圖，如下圖2所示。

圖2 系統(tǒng)功能結(jié)構(gòu)圖

4 基于微服務(wù)架構(gòu)的程序?qū)崿F(xiàn)

4.1 創(chuàng)建spring cloud配置服務(wù)器

1）配置依賴 pom.xml［10］

4.2 微服務(wù)注冊

使用eureka作為Spring cloud的微服務(wù)注冊及發(fā)現(xiàn)。所有的服務(wù)端及訪問微服務(wù)的客戶端都需要連接到eureka。通過創(chuàng)建ywgl-eureka-server作為eureka的服務(wù)端，提供注冊服務(wù)［11］。

4.3 微服務(wù)發(fā)現(xiàn)和微服務(wù)應(yīng)用

通過添加@EnableDiscoveryClient注解，微服務(wù)在啟動時，將自動注冊到y(tǒng)wgl-eureka-server注冊中心［13］。

5）前端html頁面

前端html頁面，使用AngularJS，綁定模型數(shù)據(jù)到頁面變量［12］。planList.html核心代碼展示如下：

3）4）5）展示了計劃管理中獲取計劃列表的微服務(wù)程序?qū)崿F(xiàn)，其他微服務(wù)按此方式進行創(chuàng)建。

5 結(jié)語

實現(xiàn)了一種基于微服務(wù)框架的業(yè)務(wù)系統(tǒng)設(shè)計和實現(xiàn)。微服務(wù)具有高內(nèi)聚性和高自治性。并有組件化、獨立部署、降低復(fù)雜度、技術(shù)多元化、降低維護風(fēng)險等優(yōu)勢。特別適合既有共性，又有區(qū)別的集團、所兩級的復(fù)雜業(yè)務(wù)系統(tǒng)的建設(shè)。為企業(yè)信息化建設(shè)過程中遇到的問題提出了一種解決途徑。