一種微服務(wù)框架的實(shí)現(xiàn)①

張 晶, 王琰潔, 黃小鋒(北京中電普華信息技術(shù)有限公司, 北京 009)(中國(guó)電建集團(tuán)國(guó)際工程有限公司, 北京 00048)

一種微服務(wù)框架的實(shí)現(xiàn)①

張 晶1, 王琰潔1, 黃小鋒21(北京中電普華信息技術(shù)有限公司, 北京 100192)2(中國(guó)電建集團(tuán)國(guó)際工程有限公司, 北京 100048)

相對(duì)于傳統(tǒng)單塊架構(gòu), 微服務(wù)框架具有技術(shù)選型靈活、獨(dú)立按需擴(kuò)展、可用性高等優(yōu)點(diǎn), 更適合當(dāng)前互聯(lián)網(wǎng)時(shí)代需求. 但微服務(wù)架構(gòu)的應(yīng)用也會(huì)引入新的問(wèn)題, 如跨進(jìn)程通訊、服務(wù)注冊(cè)發(fā)現(xiàn)、分布式Session管理等.本文在對(duì)傳統(tǒng)框架和微服務(wù)框架進(jìn)行分析比較的基礎(chǔ)上, 給出了微服務(wù)框架的一種實(shí)現(xiàn)方案. 該方案設(shè)計(jì)了微服務(wù)框架的功能架構(gòu), 對(duì)微服務(wù)框架引入的關(guān)鍵問(wèn)題給出了解決方案. 采用該實(shí)現(xiàn)方案進(jìn)行業(yè)務(wù)系統(tǒng)開發(fā), 開發(fā)人員只需要關(guān)注微服務(wù)內(nèi)部業(yè)務(wù)功能的開發(fā), 微服務(wù)之間的注冊(cè)、發(fā)現(xiàn)、監(jiān)控和Session管理由微服務(wù)框架完成,簡(jiǎn)化了系統(tǒng)開發(fā)的難度, 提高開發(fā)效率.

微服務(wù)框架; 服務(wù)注冊(cè); 服務(wù)發(fā)現(xiàn); Session管理

軟件的架構(gòu)設(shè)計(jì)是決定應(yīng)用系統(tǒng)是否能夠被正確、有效實(shí)現(xiàn)的關(guān)鍵要素之一. 架構(gòu)設(shè)計(jì)描述了在應(yīng)用系統(tǒng)的內(nèi)部, 如何根據(jù)業(yè)務(wù)、技術(shù)、組織, 以及靈活性、可擴(kuò)展性、可維護(hù)性等多種因素, 將應(yīng)用系統(tǒng)劃分成不同的部分, 并使這些部分相互協(xié)作, 從而為用戶提供某種特定價(jià)值的方式[1,2].

傳統(tǒng)信息化系統(tǒng)的典型架構(gòu)是單塊架構(gòu), 即將應(yīng)用程序的所有功能都打包成一個(gè)應(yīng)用, 每個(gè)應(yīng)用是最小的交付和部署單元, 應(yīng)用部署后運(yùn)行在同一進(jìn)程中.典型的單塊架構(gòu)應(yīng)用, 如基于傳統(tǒng)J2EE平臺(tái)所構(gòu)建的產(chǎn)品或者項(xiàng)目, 它們存在的形態(tài)一般是WAR包或者EAR包. 當(dāng)部署這類應(yīng)用時(shí), 通常是將整個(gè)包作為一個(gè)整體, 部署在同一個(gè)WEB容器, 如Tomcat或者Jetty中. 當(dāng)這類應(yīng)用運(yùn)行起來(lái)后, 所有的功能也都運(yùn)行在同一個(gè)進(jìn)程中. 單塊架構(gòu)應(yīng)用具有IDE友好、易于測(cè)試和部署等優(yōu)勢(shì), 但是, 隨著互聯(lián)網(wǎng)的迅速發(fā)展和企業(yè)應(yīng)用范圍的擴(kuò)展, 單塊架構(gòu)表現(xiàn)出一些不足[3]:

①代碼龐雜, 理解困難, 新人上手也困難;

②維護(hù)困難, 一般由一個(gè)團(tuán)隊(duì)維護(hù), 應(yīng)用越大,則維護(hù)的人越多, 團(tuán)隊(duì)管理成本也越高, 團(tuán)隊(duì)效率也會(huì)

越低下;

③功能升級(jí)困難: 每一次小改動(dòng)都需要重新部署整個(gè)應(yīng)用, 進(jìn)行全面測(cè)試;

④技術(shù)堆棧固化: 嘗試新技術(shù)的代價(jià)太高, 導(dǎo)致技術(shù)僵化;

⑤擴(kuò)展困難: 應(yīng)用某些部分偏I(xiàn)O密集型、某些部分卻偏CPU密集型, 但應(yīng)用卻只部署在一臺(tái)機(jī)器上,很難用單一硬件來(lái)滿足應(yīng)用各部分對(duì)硬件資源的不同要求.

如何找到一種更有效的、更靈活、更適應(yīng)當(dāng)前互聯(lián)網(wǎng)時(shí)代需求的系統(tǒng)架構(gòu)方式, 成為大家關(guān)注的焦點(diǎn).隨著微服務(wù)架構(gòu)的出現(xiàn)以及在國(guó)內(nèi)外的成功應(yīng)用, 基于微服務(wù)框架構(gòu)建系統(tǒng)應(yīng)用成為一種新的選擇.

1 微服務(wù)架構(gòu)

微服務(wù)架構(gòu)是一種架構(gòu)模式, 采用一組服務(wù)的方式來(lái)構(gòu)建一個(gè)應(yīng)用, 服務(wù)獨(dú)立部署在不同的進(jìn)程中,不同服務(wù)通過(guò)一些輕量級(jí)交互機(jī)制來(lái)通信, 例如RPC、HTTP 等, 服務(wù)可獨(dú)立擴(kuò)展伸縮, 每個(gè)服務(wù)定義了明確的邊界, 不同的服務(wù)甚至可以采用不同的編程語(yǔ)言來(lái)實(shí)現(xiàn), 由獨(dú)立的團(tuán)隊(duì)來(lái)維護(hù)[4].

相對(duì)于傳統(tǒng)的單體應(yīng)用架構(gòu), 微服務(wù)架構(gòu)通過(guò)將功能分解到各個(gè)離散的服務(wù)實(shí)現(xiàn)對(duì)應(yīng)用系統(tǒng)的解耦,具有明顯的優(yōu)勢(shì)[5,6]:

①?gòu)?fù)雜度可控: 每一個(gè)微服務(wù)專注于單一功能,并通過(guò)定義良好的接口清晰表述服務(wù)邊界, 體積小、復(fù)雜度低, 提高了系統(tǒng)的可維護(hù)性和開發(fā)效率.

②獨(dú)立部署: 微服務(wù)具備獨(dú)立的運(yùn)行進(jìn)程, 可以獨(dú)立部署. 當(dāng)某個(gè)微服務(wù)發(fā)生變更時(shí)無(wú)需編譯、部署整個(gè)應(yīng)用. 由微服務(wù)組成的應(yīng)用相當(dāng)于具備一系列可并行的發(fā)布流程, 使得發(fā)布更加高效, 同時(shí)降低對(duì)生產(chǎn)環(huán)境所造成的風(fēng)險(xiǎn), 最終縮短應(yīng)用交付周期.

③技術(shù)選型靈活: 每個(gè)團(tuán)隊(duì)可以根據(jù)自身服務(wù)的需求和行業(yè)發(fā)展的現(xiàn)狀, 自由選擇最適合的技術(shù)棧.

④容錯(cuò): 在微服務(wù)架構(gòu)下, 故障被隔離在單個(gè)服務(wù)中. 可通過(guò)重試、平穩(wěn)退化等機(jī)制實(shí)現(xiàn)應(yīng)用層面的容錯(cuò), 避免全局性的不可用.

⑤ 擴(kuò)展: 每個(gè)服務(wù)可以根據(jù)實(shí)際需求獨(dú)立進(jìn)行擴(kuò)展.

采用微服務(wù)架構(gòu)也會(huì)引入新的問(wèn)題: 基于微服務(wù)架構(gòu)的應(yīng)用是分布式系統(tǒng), 服務(wù)獨(dú)立運(yùn)行在不同的進(jìn)程中, 需要有進(jìn)程間通訊機(jī)制來(lái)支撐服務(wù)之間的交互;應(yīng)用由多個(gè)服務(wù)構(gòu)成, 每個(gè)服務(wù)可以有多個(gè)實(shí)例, 當(dāng)一項(xiàng)服務(wù)存在于多個(gè)主機(jī)節(jié)點(diǎn)時(shí), 需要一套服務(wù)發(fā)現(xiàn)機(jī)制,使服務(wù)調(diào)用端可以獲取正確的服務(wù)地址; 微服務(wù)應(yīng)用是分布式系統(tǒng), 需要解決分布式系統(tǒng)中Session管理的問(wèn)題.這些都是在微服務(wù)框架實(shí)現(xiàn)時(shí)需要解決的問(wèn)題.

2 微服務(wù)框架設(shè)計(jì)

通過(guò)對(duì)微服務(wù)框架進(jìn)行分析, 確定了微服務(wù)框架的總體架構(gòu), 如圖1所示.

圖1 架構(gòu)圖

微服務(wù)框架包括服務(wù)注冊(cè)發(fā)現(xiàn)、日志管理、序列化、服務(wù)配置、服務(wù)容器、服務(wù)通信、限流容錯(cuò)、管理接口和服務(wù)安全等組件.

其中, 服務(wù)容器是微服務(wù)運(yùn)行的容器, 通過(guò)內(nèi)嵌服務(wù)器的方式實(shí)現(xiàn). 包含界面展現(xiàn)組件、IOC組件、數(shù)據(jù)持久化組件支撐業(yè)務(wù)系統(tǒng)的功能開發(fā). 界面展現(xiàn)組件提供用于界面設(shè)計(jì)的通用組件, 支持主流瀏覽器兼容性、可視化編程、控件拖拽等功能. IOC組件提供依賴注入功能, 管理程序依賴. 數(shù)據(jù)持久化組件負(fù)責(zé)微服務(wù)數(shù)據(jù)的持久化存儲(chǔ).

日志管理: 記錄重要的框架層日志、度量和調(diào)用鏈數(shù)據(jù), 同時(shí)將日志、度量等接口暴露出來(lái), 讓業(yè)務(wù)層能根據(jù)需要記錄業(yè)務(wù)日志數(shù)據(jù).

序列化: 支持將業(yè)務(wù)邏輯以REST或者RPC方式暴露出來(lái), 支持可定制的序列化機(jī)制. 對(duì)瀏覽器, 框架支持輸出Ajax友好的JSON消息格式; 而對(duì)無(wú)線設(shè)備上的Native App, 框架支持輸出性能高的Binary消息格式.

服務(wù)配置: 支持文件方式配置, 集成動(dòng)態(tài)運(yùn)行時(shí)配置, 能夠在運(yùn)行時(shí)針對(duì)不同環(huán)境動(dòng)態(tài)調(diào)整服務(wù)的參數(shù)和配置.

服務(wù)通信: 提供基于REST/RPC的同步請(qǐng)求響應(yīng)模式和基于消息的異步通信模式.

限流和容錯(cuò): 集成限流容錯(cuò)組件, 能夠在運(yùn)行時(shí)自動(dòng)限流和容錯(cuò), 保護(hù)服務(wù). 同時(shí)和動(dòng)態(tài)配置相結(jié)合,實(shí)現(xiàn)動(dòng)態(tài)限流和熔斷.

管理接口: 提供管理接口, 可以在線查看框架和服務(wù)內(nèi)部狀態(tài), 同時(shí)還可以動(dòng)態(tài)調(diào)整內(nèi)部狀態(tài), 對(duì)調(diào)試、監(jiān)控和管理提供快速反饋.

服務(wù)安全: 以插件方式封裝安全和訪問(wèn)控制邏輯,業(yè)務(wù)服務(wù)根據(jù)需要加載相關(guān)安全插件.

2.1 服務(wù)注冊(cè)發(fā)現(xiàn)

微服務(wù)架構(gòu)是由一系列職責(zé)單一的細(xì)粒度服務(wù)構(gòu)成的分布式網(wǎng)狀結(jié)構(gòu), 一個(gè)服務(wù)可以多實(shí)例并存, 這就引入了服務(wù)注冊(cè)發(fā)現(xiàn)問(wèn)題, 服務(wù)提供者要注冊(cè)發(fā)布服務(wù)地址, 服務(wù)消費(fèi)者要能發(fā)現(xiàn)目標(biāo)服務(wù), 同時(shí)服務(wù)提供者一般以集群方式提供服務(wù), 也就引入了負(fù)載均衡問(wèn)題. 目前主要的服務(wù)注冊(cè)發(fā)現(xiàn)方案有兩種:

①提供者服務(wù)發(fā)現(xiàn)

在服務(wù)提供者和服務(wù)消費(fèi)者之間有一個(gè)獨(dú)立的負(fù)載均衡器, 負(fù)載均衡器上有所有服務(wù)的地址映射表.當(dāng)服務(wù)消費(fèi)者調(diào)用某個(gè)目標(biāo)服務(wù)時(shí), 向負(fù)載均衡器發(fā)送請(qǐng)求, 負(fù)載均衡器根據(jù)策略做負(fù)載均衡后將請(qǐng)求轉(zhuǎn)發(fā)到目標(biāo)服務(wù). 這種方式實(shí)現(xiàn)簡(jiǎn)單, 服務(wù)消費(fèi)者無(wú)需實(shí)現(xiàn)服務(wù)發(fā)現(xiàn)邏輯, 但系統(tǒng)中需要維護(hù)一個(gè)高可用的負(fù)載均衡組件. 另外, 負(fù)載均衡組件在服務(wù)消費(fèi)者和服務(wù)提供者之間增加了一跳, 有一定性能開銷.

②消費(fèi)者服務(wù)發(fā)現(xiàn)

服務(wù)消費(fèi)者要訪問(wèn)某個(gè)服務(wù)時(shí), 通過(guò)內(nèi)置的負(fù)載均衡組件向服務(wù)注冊(cè)表查詢目標(biāo)服務(wù)地址列表, 然后以某種負(fù)載均衡策略選擇一個(gè)目標(biāo)服務(wù)地址, 最后向目標(biāo)服務(wù)發(fā)起請(qǐng)求. 這一方案需要一個(gè)服務(wù)注冊(cè)表配合服務(wù)注冊(cè)和發(fā)現(xiàn), 一般采用高可用、分布式一致的組件如Zookeeper、Consul、Etcd等來(lái)實(shí)現(xiàn). 原理如圖2所示.

圖2 消費(fèi)者服務(wù)發(fā)現(xiàn)

和方案一相比, 該方案將服務(wù)發(fā)現(xiàn)能力分散到每一個(gè)服務(wù)消費(fèi)者的進(jìn)程內(nèi)部, 同時(shí)服務(wù)消費(fèi)方和服務(wù)提供方之間是直接調(diào)用, 沒(méi)有額外開銷, 性能比較好.

微服務(wù)框架在實(shí)現(xiàn)時(shí)采用消費(fèi)者服務(wù)發(fā)現(xiàn)的方式.

2.2 會(huì)話管理

基于微服務(wù)框架的系統(tǒng)是一個(gè)分布式系統(tǒng), 用戶的一個(gè)請(qǐng)求可能跨越多個(gè)微服務(wù), 而且一個(gè)服務(wù)可部署多個(gè)實(shí)例, 因此需要實(shí)現(xiàn)分布式環(huán)境下的Session管理, 以解決Session ID共享、Session數(shù)據(jù)復(fù)制及Session生命周期管理等問(wèn)題.

在分布式環(huán)境中, Session管理通常有三種方式: Session復(fù)制、粘性Session和緩存集中式管理. Session復(fù)制, 將一臺(tái)機(jī)器上的Session數(shù)據(jù)廣播復(fù)制到集群中其它機(jī)器上; 粘性Session, 當(dāng)用戶訪問(wèn)集群中某臺(tái)機(jī)器后, 強(qiáng)制指定后續(xù)所有請(qǐng)求均落到此機(jī)器上; 緩存集中式管理, 將Session存入分布式緩存中, 當(dāng)用戶訪問(wèn)不同節(jié)點(diǎn)時(shí)先從緩存中獲取Session信息. 這三種方式的對(duì)比如表1所示.

表1 三種方式對(duì)比

為適應(yīng)復(fù)雜的網(wǎng)絡(luò)環(huán)境, 提高Session管理的可靠性, 在微服務(wù)框架實(shí)現(xiàn)時(shí)采用緩存集中式管理方式進(jìn)行Session的管理.

3 框架實(shí)現(xiàn)

3.1 基礎(chǔ)框架

目前開源的微服務(wù)框架主要有Dropwizard和SpringBoot. 兩個(gè)框架在實(shí)現(xiàn)技術(shù)上存在一定差異[7],如表2所示.

表2 Dropwizard和SpringBoot對(duì)比

Spring boot聚焦于Spring應(yīng)用, 可以借力Spring家族體系的其它成員, 完成通信、數(shù)據(jù)訪問(wèn)等功能, 體系龐大沉重; DropWizard從前端網(wǎng)頁(yè)、核心服務(wù)、資料庫(kù)存取到資源監(jiān)控, 提供了一個(gè)輕量級(jí)的開發(fā)架構(gòu),更適用于云開發(fā)環(huán)境. 為了保持微服務(wù)輕量級(jí)特性及向云環(huán)境部署遷移, 應(yīng)用框架在實(shí)現(xiàn)上選取了DropWizard框架.

DropWizard是一個(gè)后臺(tái)服務(wù)開發(fā)框架, 內(nèi)置jetty服務(wù)器, 封裝jersey容器, 幫助開發(fā)者快速的打造一個(gè)Rest風(fēng)格的后臺(tái)服務(wù), 同時(shí)集成hibernate4、log4j、slf4j、jackson等開源組件. DropWizard結(jié)構(gòu)的微服務(wù)主要包括四部分[8]:

①Configuration/config.yml: 用于微服務(wù)配置信息的定義和讀取.

②Application: 該服務(wù)的主入口, 定義服務(wù)使用的配置文件, 開放Resource, 創(chuàng)建數(shù)據(jù)庫(kù)連接對(duì)象等.

③Resource: 定義一個(gè)資源, 包括如何獲取該資源, 對(duì)該資源進(jìn)行g(shù)et、post請(qǐng)求時(shí)對(duì)應(yīng)的業(yè)務(wù)邏輯.

④HealthCheck: 隨時(shí)檢測(cè)當(dāng)前服務(wù)是否可用.

Dropwizard框架本身缺少依賴注入的支持, 在微服務(wù)框架中對(duì)Dropwizard進(jìn)行改造, 引入輕量級(jí)依賴注入框架Google Guice[9], 簡(jiǎn)化系統(tǒng)開發(fā)的難度. 整合代碼如表3所示.

表3 整合Google Guice代碼

3.2 服務(wù)注冊(cè)發(fā)現(xiàn)

消費(fèi)者服務(wù)發(fā)現(xiàn)需要一個(gè)服務(wù)注冊(cè)表, 采用開源組件Consul來(lái)實(shí)現(xiàn). 相對(duì)于Zookeeper、Etcd等其它服務(wù)注冊(cè)組件, Consul具有以下優(yōu)點(diǎn)[10]: 支持多數(shù)據(jù)中心下分布式高可用的服務(wù)發(fā)現(xiàn)和配置共享; 成員管理和消息廣播采用Gossip協(xié)議, 去中心化; 支持健康檢查, 允許鍵值對(duì)存儲(chǔ); 支持ACL訪問(wèn)控制. 服務(wù)注冊(cè)發(fā)現(xiàn)的架構(gòu)如圖3所示.

圖3 服務(wù)注冊(cè)發(fā)現(xiàn)架構(gòu)圖

微服務(wù)啟動(dòng)時(shí), 將服務(wù)信息注冊(cè)到consulClient, consulClient將注冊(cè)信息提交給consulServer, consulServer將信息提交給consulLeader, consulLeader將自身的數(shù)據(jù)復(fù)制給其他的consulServer, 實(shí)現(xiàn)所有服務(wù)信息同步. 當(dāng)微服務(wù)B訪問(wèn)微服務(wù)A時(shí), 首先從consulServer上獲取微服務(wù)A所有可用的服務(wù)地址,根據(jù)負(fù)載均衡策略選擇一個(gè)進(jìn)行訪問(wèn), 訪問(wèn)的過(guò)程中通過(guò)熔斷器來(lái)進(jìn)行超時(shí)容錯(cuò)處理.

Consul采用Go語(yǔ)言進(jìn)行編寫, 引入開源的consul-client庫(kù)實(shí)現(xiàn)Java對(duì)Consul的訪問(wèn). 在微服務(wù)啟動(dòng)的時(shí)候進(jìn)行服務(wù)注冊(cè), 注冊(cè)代碼如表4所示.

AgentClient agentClient = consul.agentClient(); try { agentClient.register(prop.getServicePort(), URI.create(prop.getHealthUrl()).toURL(), prop.getHealthInterval(), prop.getServicename(), prop.getServicename(), // serviceId: prop.getServiceTag()); } catch (MalformedURLException e) { logger.error ("服務(wù)注冊(cè)異常: " + e.printStackTrace()); }

3.3 Session管理

為了解決分布式環(huán)境中Session共享的問(wèn)題, 微服務(wù)框架在實(shí)現(xiàn)時(shí)選擇分布式緩存方式進(jìn)行Session的管理. 通過(guò)對(duì)網(wǎng)絡(luò)I/O模型、內(nèi)存管理、數(shù)據(jù)一致性、存儲(chǔ)方式等方面對(duì)開源的分布式緩存組件進(jìn)行對(duì)比,最終選擇redis作為緩存組件.redis是一個(gè)開源的Key-Value存儲(chǔ)系統(tǒng), 具有快速、支持?jǐn)?shù)據(jù)類型豐富、所有操作都是原子操作等優(yōu)點(diǎn). 同時(shí)使用Haproxy組件實(shí)現(xiàn)負(fù)載均衡和redis故障遷移, 保證Session信息的高可用性. 架構(gòu)如圖4所示.

圖4 Session管理架構(gòu)圖

當(dāng)redis master故障時(shí), 通過(guò)haproxy設(shè)置redis slave為臨時(shí)master, redis master重新恢復(fù)后, 再切換回去. redis-master與redis-slave雙向同步, 解決redis單點(diǎn)問(wèn)題.

Session共享原理: 借助HttpServletRequest Wrapper對(duì)HttpServletRequest對(duì)象進(jìn)行包裝, 覆蓋getSession()方法, 接管創(chuàng)建和管理Session的工作. 通過(guò)Filter, 完成請(qǐng)求包裝操作, 并觸發(fā)事件完成Session的保存. Session保存流程如圖5所示.

圖5 Session保存流程

圖6 Session獲取流程

由于對(duì)HttpServletRequest進(jìn)行了包裝, 當(dāng)系統(tǒng)中獲取Session時(shí), 調(diào)用包裝類的getSession方法從redis緩存中獲取Session, 流程如圖6所示.

4 結(jié)語(yǔ)

微服務(wù)框架已經(jīng)在國(guó)家電網(wǎng)統(tǒng)一應(yīng)用開發(fā)平臺(tái)V2.9.0版本中實(shí)現(xiàn), 該版本經(jīng)過(guò)第三方安全、性能測(cè)試, 于2016年7月27日正式發(fā)版. 目前, 已選中兩個(gè)項(xiàng)目組進(jìn)行框架的試點(diǎn)應(yīng)用.

本文對(duì)目前流行的微服務(wù)框架進(jìn)行分析, 提出了一種微服務(wù)框架的實(shí)現(xiàn)方案. 該方案設(shè)計(jì)了微服務(wù)框架的功能架構(gòu), 重點(diǎn)分析了微服務(wù)架構(gòu)所帶來(lái)的服務(wù)注冊(cè)、服務(wù)發(fā)現(xiàn)、Session管理等問(wèn)題, 并給出了實(shí)現(xiàn)方案. 基于該微服務(wù)框架進(jìn)行業(yè)務(wù)系統(tǒng)開發(fā), 開發(fā)人員只需要關(guān)注微服務(wù)內(nèi)部業(yè)務(wù)功能的開發(fā), 微服務(wù)之間的注冊(cè)、發(fā)現(xiàn)、監(jiān)控和Session管理由微服務(wù)框架完成, 簡(jiǎn)化了系統(tǒng)開發(fā)難度, 提高開發(fā)效率.

1 溫昱.軟件架構(gòu)設(shè)計(jì):程序員向架構(gòu)師轉(zhuǎn)型必備.北京:電子工業(yè)出版社,2012.

2 王磊.解析微服務(wù)架構(gòu)(一)單塊架構(gòu)系統(tǒng)以及其面臨的挑戰(zhàn)[2015-05-11].http://www.infoq.com/cn/articles/analysis-thearchitecture-of-microservice-part-01.

3 Richardson C. Introduction to Microservices [2015-05-19]. https://www.nginx.com/blog/introduction-to-microservices/

4 Fowler M, Lewis J. Microservices. [2014-03-25]. http:// martinfowler.com/articles/microservices.html.

5 Parmar K. Microservice Architecture-A Quick Guide [2014-06]. http://www.kpbird.com/2014/06/microservice-architecture-quick-guide.html.

6 Richardson C. Introduction to Microservices [2015-05-19]. https://www.nginx.com/blog/introduction-to-microservices/.

7 Ullah R. Dropwizard vs Spring Boot—A Comparison Matrix. https://dzone.com/articles/dropwizard-vs-spring-boot? utm_source=tuicool&utm_medium=referral,2015-02-02.

8 Yammer.Getting Started.http://www.dropwizard.io/0.9.1/docs/ getting-started.html.

9 Sameb. Getting Started. [2014-07-08]. https://github.com/ google/guice/wiki/GettingStarted.

10 HashiCorp. Introduction to Consul. https://www.consul.io/ intro/index.html.

Implementation of Microservice Architecture

ZHANG Jing1, WANG Yan-Jie1, HUANG Xiao-Feng21(Beijing China Power Information Technology Co. Ltd., Beijing 100192, China)2(Power China International Group Limited, Beijing 100048, China)

Compared with traditional monolithic architecture, microservice architecture has many advantages, such as flexible technology selection, independent scalability, high availability and so on, and is more suitable for the current needs of the Internet age. But microservice architecture also introduces new problems, such as cross-process communication, service registration, service discovery, and distributed session management. On the basis of analysis and comparison between the traditional framework and microservice framework, this paper shows one implementation method of microservice framework. First, we design a scheme of microservices architecture framework and the functional framework, and then give the solutions of some key issues that microservice architecture introduces. With this scheme, developers only need to focus on the development of business functions, service registration, discovery, monitoring and session management provided by the framework to simplify the development and improve development effectiveness.

microservice architecture; service registration; service discover; session management

2016-07-21;收到修改稿時(shí)間:2016-08-18

10.15888/j.cnki.csa.005684