鄭俊褒,沈林強(qiáng)

(浙江理工大學(xué) 信息學(xué)院,杭州 310018)

日益豐富的業(yè)務(wù)場景和不斷提高的系統(tǒng)性能要求使得軟件系統(tǒng)逐漸走上了分布式的道路.而電商平臺(tái)、物聯(lián)網(wǎng)平臺(tái)這種需要快速響應(yīng)市場變化、系統(tǒng)更新迭代頻繁的軟件系統(tǒng)對(duì)系統(tǒng)擴(kuò)展性、敏捷開發(fā)能力提出了更高的要求,傳統(tǒng)面向服務(wù)(Service-Oriented Architecture,SOA)架構(gòu)[1,2]建設(shè)的系統(tǒng)由于其粗粒度的服務(wù)劃分和企業(yè)服務(wù)總線的設(shè)計(jì)無法滿足這類系統(tǒng)的性能需求,隨著Docker等容器技術(shù)[3]和云計(jì)算技術(shù)的發(fā)展,微服務(wù)架構(gòu)逐漸成為更優(yōu)的選擇.

微服務(wù)架構(gòu)[4-6]是一種架構(gòu)風(fēng)格,將大型復(fù)雜系統(tǒng)細(xì)粒度的拆分成多個(gè)能夠獨(dú)立運(yùn)行、職能單一的服務(wù),服務(wù)之間通過通用的協(xié)議進(jìn)行通訊.微服務(wù)架構(gòu)的系統(tǒng)在系統(tǒng)擴(kuò)展性、敏捷性等方面相比于SOA架構(gòu)的系統(tǒng)都具有明顯的優(yōu)勢,但是這種細(xì)粒度拆分服務(wù)的方式勢必會(huì)使服務(wù)治理變得異常復(fù)雜.傳統(tǒng)服務(wù)治理框架,如Dubbo、Spring Cloud為微服務(wù)服務(wù)治理提供了切實(shí)有效的解決方案,但都存在難以實(shí)現(xiàn)不同技術(shù)框架和通訊協(xié)議建設(shè)的服務(wù)之間互聯(lián)互通和服務(wù)治理與服務(wù)高耦合的問題.本文基于服務(wù)網(wǎng)格的思想對(duì)微服務(wù)服務(wù)治理進(jìn)行改造,從服務(wù)中抽取出服務(wù)治理相關(guān)功能并集成在網(wǎng)絡(luò)代理上,網(wǎng)絡(luò)代理作為服務(wù)治理的獨(dú)立組件解決了服務(wù)治理和服務(wù)高耦合的問題,并且網(wǎng)絡(luò)代理會(huì)對(duì)所有進(jìn)出服務(wù)的流量進(jìn)行攔截,能夠?qū)崿F(xiàn)不同技術(shù)框架和通訊協(xié)議建設(shè)的服務(wù)之間互聯(lián)互通.

1 相關(guān)工作

1.1 服務(wù)治理

在微服務(wù)架構(gòu)中服務(wù)治理是整個(gè)系統(tǒng)正常運(yùn)行的關(guān)鍵技術(shù),在大型復(fù)雜系統(tǒng)環(huán)境下,服務(wù)間的調(diào)用會(huì)變得非常復(fù)雜,如果沒有一套完善的、經(jīng)過大規(guī)模生產(chǎn)環(huán)境驗(yàn)證的服務(wù)治理方案的話,系統(tǒng)將會(huì)處于非常危險(xiǎn)的境地.為解決復(fù)雜環(huán)境下服務(wù)治理的問題,出現(xiàn)了很多服務(wù)治理框架,其中應(yīng)用最廣泛有Dubbo和Spring Cloud.

Dubbo是由阿里巴巴中間件團(tuán)隊(duì)開源的基于Java的高性能遠(yuǎn)程過程調(diào)用[7](Remote Procedure Call,RPC)通訊框架,在其提供的服務(wù)整合能力支持下,使用RPC可以像使用本地調(diào)用一樣輕松便捷,并且Dubbo是阿里巴巴內(nèi)部SOA服務(wù)治理方案的核心框架,每天為2000多個(gè)服務(wù)提供數(shù)億次訪問量支持[8],Dubbo已不只是單純的服務(wù)通訊框架,更是一套完備的服務(wù)治理框架,Dubbo也因?yàn)槠鋬?yōu)秀的服務(wù)治理能力和高效的RPC通訊能力成為了微服務(wù)架構(gòu)的一種優(yōu)秀解決方案.

Spring Cloud是一系列Spring框架的集合,以SpringBoot作為開發(fā)的基礎(chǔ),通過SpringBoot可以簡單高效地集成服務(wù)發(fā)現(xiàn)注冊(cè)、負(fù)載均衡、斷路器[9]等其他Spring家族的分布式框架[10],相比于Dubbo框架,Spring Cloud最大的特色在于一站式的分布式系統(tǒng)架構(gòu).

但無論是以Dubbo還是Spring Cloud作為服務(wù)治理核心框架的微服務(wù)系統(tǒng)都需要對(duì)所有接入的服務(wù)引入組件,并在業(yè)務(wù)服務(wù)中并暴露或消費(fèi)相關(guān)的服務(wù),這會(huì)大大增加服務(wù)治理和業(yè)務(wù)服務(wù)之間的耦合度,增加服務(wù)開發(fā)的成本;此外這種微服務(wù)架構(gòu)系統(tǒng)雖然從一定程度上為不同技術(shù)框架和通訊協(xié)議建設(shè)的服務(wù)之間互聯(lián)互通提供了條件,但是其實(shí)現(xiàn)的成本是相當(dāng)高昂的,例如在以Dubbo微服務(wù)架構(gòu)的系統(tǒng)中引入另一個(gè)Spring Cloud為技術(shù)框架的服務(wù),那么可能需要對(duì)原先系統(tǒng)的每個(gè)服務(wù)進(jìn)行升級(jí)才能實(shí)現(xiàn),這在實(shí)際場景下很難做到.

1.2 服務(wù)網(wǎng)格

2017年4月,Buoyant的首席執(zhí)行官William Morgan在其公司平臺(tái)首次定義了服務(wù)網(wǎng)格[11],與傳統(tǒng)微服務(wù)架構(gòu)不同,服務(wù)網(wǎng)格另辟蹊徑,其實(shí)現(xiàn)服務(wù)治理的過程不需要改變服務(wù)本身,通過代理或邊車形式部署網(wǎng)絡(luò)代理,所有進(jìn)出服務(wù)的流量都會(huì)被網(wǎng)絡(luò)代理攔截并加以處理.這樣一來微服務(wù)場景下的各種服務(wù)治理能力都委托給一個(gè)高可用的網(wǎng)絡(luò)代理,降低了服務(wù)治理和服務(wù)的耦合;而且當(dāng)具有協(xié)議轉(zhuǎn)換功能的網(wǎng)絡(luò)代理作為服務(wù)之間的傳輸媒介時(shí),可以很方便的實(shí)現(xiàn)基于不同技術(shù)框架和通訊協(xié)議建設(shè)的服務(wù)之間互聯(lián)互通.

當(dāng)一個(gè)系統(tǒng)采用服務(wù)網(wǎng)格化的微服務(wù)架構(gòu)時(shí),系統(tǒng)網(wǎng)絡(luò)拓?fù)鋱D如圖1所示.網(wǎng)絡(luò)代理作為服務(wù)治理的獨(dú)立組件會(huì)和每個(gè)業(yè)務(wù)服務(wù)部署在同一容器中,當(dāng)業(yè)務(wù)服務(wù)需要調(diào)用其他服務(wù)時(shí),業(yè)務(wù)服務(wù)只向同一容器下的網(wǎng)絡(luò)代理發(fā)送請(qǐng)求,實(shí)際的服務(wù)通訊和治理是在兩個(gè)網(wǎng)絡(luò)代理之間完成的,整個(gè)系統(tǒng)以網(wǎng)絡(luò)代理作為服務(wù)間通訊的專用基礎(chǔ)設(shè)施.

圖1 服務(wù)網(wǎng)格化的微服務(wù)系統(tǒng)網(wǎng)絡(luò)拓?fù)鋱D

圖2展示了微服務(wù)和服務(wù)網(wǎng)格實(shí)現(xiàn)的系統(tǒng)服務(wù)調(diào)用的區(qū)別,其中圖2(a)是傳統(tǒng)微服務(wù)服務(wù)調(diào)用方式示意圖,圖2(b)是服務(wù)網(wǎng)格服務(wù)調(diào)用方式示意圖.傳統(tǒng)微服務(wù)沒有實(shí)現(xiàn)業(yè)務(wù)服務(wù)和服務(wù)治理的分離,服務(wù)治理通過框架配置等方式和業(yè)務(wù)服務(wù)部署在同一服務(wù)中,耦合性高,不利于服務(wù)的升級(jí)迭代,開發(fā)維護(hù)人員除了要完成業(yè)務(wù)服務(wù)之外還要兼顧服務(wù)發(fā)現(xiàn)注冊(cè)等服務(wù)治理工作,無疑也增加了開發(fā)維護(hù)的成本;此外當(dāng)系統(tǒng)需要接入不同技術(shù)框架和通訊協(xié)議建設(shè)的服務(wù)時(shí),需要對(duì)每個(gè)相連的服務(wù)增加協(xié)議轉(zhuǎn)換功能,這對(duì)于一個(gè)大型系統(tǒng)是不能接受的.服務(wù)網(wǎng)格化的服務(wù)抽取了服務(wù)發(fā)現(xiàn)注冊(cè)等服務(wù)治理功能并集成于獨(dú)立的網(wǎng)絡(luò)代理,降低了服務(wù)和服務(wù)治理的耦合性,服務(wù)只包含具體業(yè)務(wù)服務(wù),開發(fā)維護(hù)人員只需要專注實(shí)現(xiàn)業(yè)務(wù)服務(wù),提高了開發(fā)維護(hù)效率;服務(wù)調(diào)用時(shí)會(huì)請(qǐng)求部署在同一容器的網(wǎng)絡(luò)代理,實(shí)際的服務(wù)通訊在兩個(gè)不同容器的網(wǎng)絡(luò)代理間完成,當(dāng)系統(tǒng)需要接入不同技術(shù)框架和通訊協(xié)議建設(shè)的服務(wù)時(shí),只需要在通用的網(wǎng)絡(luò)代理中支持協(xié)議轉(zhuǎn)換等功能,不會(huì)對(duì)服務(wù)造成侵入.

圖2 服務(wù)網(wǎng)格化的微服務(wù)和傳統(tǒng)微服務(wù)服務(wù)調(diào)用方式

綜上所述克服傳統(tǒng)微服務(wù)的兩大問題的關(guān)鍵是實(shí)現(xiàn)一個(gè)獨(dú)立的、高可用的、具備服務(wù)治理、協(xié)議轉(zhuǎn)換等功能的網(wǎng)絡(luò)代理;另一方面,由于網(wǎng)絡(luò)代理的存在,每次服務(wù)調(diào)用會(huì)增加兩次從服務(wù)到網(wǎng)絡(luò)代理的網(wǎng)絡(luò)開銷,因此網(wǎng)絡(luò)代理還必須具備高并發(fā)、高吞吐量的性能要求.網(wǎng)絡(luò)代理功能、性能需求如下:

(1)良好的服務(wù)治理能力.網(wǎng)絡(luò)代理作為服務(wù)調(diào)用的基礎(chǔ)設(shè)施,服務(wù)治理是其最基礎(chǔ)的能力.

(2)支持協(xié)議轉(zhuǎn)換.目前主流的微服務(wù)架構(gòu)技術(shù)框架有以HTTP作為傳輸協(xié)議的Spring Cloud框架、以DUBBO等作為傳輸協(xié)議的Dubbo框架,技術(shù)框架選擇很多,可選的傳輸協(xié)議也很多,微服務(wù)的架構(gòu)設(shè)計(jì)為不同技術(shù)框架和不同傳輸協(xié)議建設(shè)的服務(wù)之間互聯(lián)互通提供了前提條件,在本文中將協(xié)議轉(zhuǎn)換的功能委托給網(wǎng)絡(luò)代理,在不同傳輸協(xié)議的服務(wù)之間通訊時(shí),只需要通用的網(wǎng)絡(luò)代理實(shí)現(xiàn)了協(xié)議轉(zhuǎn)換功能,而不需要對(duì)每個(gè)服務(wù)都進(jìn)行升級(jí).

(3)支持高吞吐量的網(wǎng)絡(luò)通訊能力.系統(tǒng)吞吐量是系統(tǒng)每秒鐘處理完的事務(wù)數(shù),是衡量一個(gè)系統(tǒng)性能的關(guān)鍵指標(biāo).本文通過代理的方式講服務(wù)治理從服務(wù)中獨(dú)立,同時(shí)也增加了額外的網(wǎng)絡(luò)開銷,如果網(wǎng)絡(luò)代理的性能不佳,會(huì)大幅提高系統(tǒng)的響應(yīng)時(shí)間,因此高吞吐量的網(wǎng)絡(luò)傳輸能力也是網(wǎng)絡(luò)代理必不可少的.

2 網(wǎng)絡(luò)代理實(shí)現(xiàn)

針對(duì)上文網(wǎng)絡(luò)代理功能和性能的需求,本文以圖3網(wǎng)絡(luò)代理的實(shí)現(xiàn)機(jī)制對(duì)網(wǎng)絡(luò)代理進(jìn)行構(gòu)建.其中consumer-agent和provider-agent是網(wǎng)絡(luò)代理對(duì)應(yīng)于服務(wù)調(diào)用的消費(fèi)者網(wǎng)絡(luò)代理和生產(chǎn)者網(wǎng)絡(luò)代理,圖中以Spring Cloud為技術(shù)框架的consumer去調(diào)用以Dubbo為技術(shù)框架的provider為例,服務(wù)調(diào)用的流程如下:

(1)啟動(dòng) provider-agent后,會(huì)通過Etcd客戶端向Etcd注冊(cè)中心注冊(cè)服務(wù)信息.

(2)consumer通過HTTP協(xié)議請(qǐng)求consumeragent,consumer-agent內(nèi)部的HTTP服務(wù)端接收HTTP請(qǐng)求并交給HTTP編解碼器解碼,得到請(qǐng)求信息.

(3)HTTP服務(wù)端將請(qǐng)求信息轉(zhuǎn)交給TCP客戶端,TCP客戶端會(huì)根據(jù)請(qǐng)求信息獲取需要調(diào)用的服務(wù),并通過Etcd客戶端向Etcd注冊(cè)中心拉取提供該服務(wù)的provider信息,如果有多個(gè)提供該服務(wù)的provider,會(huì)根據(jù)加權(quán)輪詢負(fù)載均衡算法選擇路由.確定provider之后,將請(qǐng)求信息通過protobuf編解碼器進(jìn)行編碼,并通過TCP協(xié)議傳輸給provider-agent的TCP服務(wù)端.

(4)TCP服務(wù)端通過protobuf編解碼器將信息解碼,并交給DUBBO客戶端,再通過DUBBO編解碼器將信息以DUBBO協(xié)議傳輸給provider.

(5)Provider將請(qǐng)求解析并進(jìn)行具體的業(yè)務(wù)處理,而后逆反上續(xù)步驟將處理結(jié)果返回給consumer,完成一次服務(wù)調(diào)用.

網(wǎng)絡(luò)代理的關(guān)鍵技術(shù)點(diǎn)有三: 服務(wù)治理、網(wǎng)絡(luò)傳輸和協(xié)議轉(zhuǎn)換,下文對(duì)這三個(gè)關(guān)鍵技術(shù)點(diǎn)的具體實(shí)現(xiàn)和技術(shù)選型進(jìn)行了詳細(xì)的闡述.在這之前本文確定選擇Java語言實(shí)現(xiàn)網(wǎng)絡(luò)代理,選擇Java語言的原因有兩點(diǎn): 其一Java是分布式系統(tǒng)領(lǐng)域使用最為廣泛的語言,切合網(wǎng)絡(luò)代理的使用場景;其二Java語言從誕生開始就主打的幾乎完美的跨平臺(tái)能力,這對(duì)于分布式場景特別是異構(gòu)系統(tǒng)場景是相當(dāng)重要的能力.

圖3 網(wǎng)絡(luò)代理實(shí)現(xiàn)機(jī)制

2.1 服務(wù)治理

服務(wù)治理包括服務(wù)注冊(cè)發(fā)現(xiàn)、負(fù)載均衡等,其中服務(wù)的注冊(cè)發(fā)現(xiàn)是最重要最基礎(chǔ)的服務(wù)治理能力,而負(fù)載均衡能力是一個(gè)穩(wěn)定、高性能微服務(wù)系統(tǒng)不可缺少的能力,本文的網(wǎng)絡(luò)代理設(shè)計(jì)服務(wù)治理包括服務(wù)發(fā)現(xiàn)注冊(cè)和負(fù)載均衡.

服務(wù)注冊(cè)和發(fā)現(xiàn)依賴服務(wù)注冊(cè)中心實(shí)現(xiàn),在本設(shè)計(jì)中,網(wǎng)絡(luò)代理的輕量化會(huì)是更優(yōu)雅的選擇,因此選用輕量、簡單、可靠的注冊(cè)中心及其客戶端會(huì)是更優(yōu)的選擇.Etcd是一個(gè)分布式的key-value存儲(chǔ)系統(tǒng),其特點(diǎn)就是簡單安全,方便可靠,特別由于Etcd提供HTTP+JSON、gRPC接口,能很好地實(shí)現(xiàn)跨語言跨平臺(tái)的要求,并且Etcd已經(jīng)在Google 著名的容器管理工具 Kuberbetes有廣泛應(yīng)用,是一款完善的、經(jīng)過大規(guī)模生產(chǎn)環(huán)境驗(yàn)證的注冊(cè)中心產(chǎn)品,與傳統(tǒng)的注冊(cè)中心Zookeeper相比,Etcd在一致性協(xié)議、運(yùn)維管理、社區(qū)活躍度等方面都完勝于Zookeeper[12].本文采用Etcd作為服務(wù)的注冊(cè)中心,在網(wǎng)絡(luò)代理中通過Etcd Java客戶端實(shí)現(xiàn)服務(wù)的發(fā)現(xiàn)和注冊(cè).

負(fù)載均衡算法主要有輪詢法、加權(quán)輪詢法、隨機(jī)法、原地址哈希法等,對(duì)于配置性能相同的服務(wù)來說采用輪詢或隨機(jī)的方法簡單有效,但是多數(shù)分布式場景中服務(wù)的性能是不相同的,熱點(diǎn)服務(wù)或需要大量計(jì)算服務(wù)的配置往往更好,這是分布式系統(tǒng)的一大優(yōu)勢.本文采用加權(quán)輪詢的方法作為負(fù)載均衡的算法,這種方式能實(shí)現(xiàn)對(duì)不同配置的服務(wù)按需分配不同比例的負(fù)載,提高系統(tǒng)抗壓能力,而且結(jié)合Etcd注冊(cè)中心,能很好地實(shí)現(xiàn)負(fù)載調(diào)整.上文說到Etcd是一個(gè)key-value存儲(chǔ)系統(tǒng),在服務(wù)注冊(cè)的時(shí)候,把key作為服務(wù)提供者的IP地址,value作為負(fù)載權(quán)重,就可以實(shí)現(xiàn)對(duì)不同服務(wù)的加權(quán)處理.在服務(wù)消費(fèi)者網(wǎng)絡(luò)代理選擇路由時(shí),消費(fèi)者網(wǎng)絡(luò)代理將服務(wù)發(fā)現(xiàn)得到的對(duì)應(yīng)服務(wù)生產(chǎn)者網(wǎng)絡(luò)代理信息保存記錄,并在內(nèi)部維護(hù)一個(gè)線程安全的計(jì)數(shù)器,每次需要選擇負(fù)載的時(shí)候根據(jù)計(jì)數(shù)器和權(quán)重選擇路由就可以實(shí)現(xiàn).

2.2 網(wǎng)絡(luò)傳輸

網(wǎng)絡(luò)代理需要支持高吞吐量的遠(yuǎn)程調(diào)用能力,異步非阻塞的網(wǎng)絡(luò)I/O模型會(huì)是更優(yōu)的選擇,異步非阻塞的網(wǎng)絡(luò)I/O模型是應(yīng)用程序接收到I/O操作請(qǐng)求后將I/O處理交給操作系統(tǒng),應(yīng)用程序并不直接參與,通過事件通知或輪詢的方式得到I/O操作的結(jié)果,這種方式的I/O處理模型在高并發(fā)或I/O處理耗時(shí)長等場景都具有不阻塞網(wǎng)絡(luò),系統(tǒng)資源利用率高的優(yōu)點(diǎn).網(wǎng)絡(luò)代理采用Netty作為網(wǎng)絡(luò)I/O模型技術(shù)框架,Netty是基于Java的NIO框架,是Java生態(tài)圈首選的網(wǎng)絡(luò)通訊框架.Netty提供異步的、非阻塞的、事件驅(qū)動(dòng)的網(wǎng)絡(luò)應(yīng)用程序框架和工具,用以快速開發(fā)高性能、高可靠性的網(wǎng)絡(luò)服務(wù)器和客戶端程序,由于其良好的線程模型設(shè)計(jì),以Netty實(shí)現(xiàn)的服務(wù)端可以花費(fèi)少量系統(tǒng)開銷就能實(shí)現(xiàn)上萬的并發(fā)連接[13].圖3中包括HTTP服務(wù)端、TCP客戶端、TCP服務(wù)端和DUBBO客戶端都是基于Netty實(shí)現(xiàn)的.

除了網(wǎng)絡(luò)I/O模型外,網(wǎng)絡(luò)傳輸協(xié)議也是網(wǎng)絡(luò)傳輸性能的關(guān)鍵因素.TCP面向連接的傳輸協(xié)議相比于UDP無連接傳輸協(xié)議最大的特點(diǎn)在于可靠安全,這在本文的微服務(wù)場景下是非常重要的性能.在生產(chǎn)環(huán)境下,集群的網(wǎng)絡(luò)環(huán)境常常是不穩(wěn)定的,網(wǎng)絡(luò)傳輸?shù)目煽啃允钦麄€(gè)系統(tǒng)的一項(xiàng)重要指標(biāo).網(wǎng)絡(luò)代理之間的傳輸協(xié)議采用TCP協(xié)議,為了保證傳輸效率,不多次反復(fù)創(chuàng)建TCP連接,采用TCP長連接的方式.

網(wǎng)絡(luò)代理具備高吞吐量的遠(yuǎn)程調(diào)用能力的另一個(gè)關(guān)鍵是網(wǎng)絡(luò)傳輸時(shí)的序列化方式,不同的序列化方式產(chǎn)生的字節(jié)流是不同的,一般來說,碼流越小的網(wǎng)絡(luò)傳輸傳輸效果更快.本文采用protobuf作為網(wǎng)絡(luò)代理之間連接的序列化編解碼器,相比于原生JDK序列化、JackSon、Hessian等序列化方式無論是在處理時(shí)間、空間占用方面都有較大優(yōu)勢[14].

2.3 協(xié)議轉(zhuǎn)換

HTTP和DUBBO協(xié)議是目前微服務(wù)最常用的通訊協(xié)議,本文的網(wǎng)絡(luò)代理需要實(shí)現(xiàn)這兩種協(xié)議的互相轉(zhuǎn)換.上文提到網(wǎng)絡(luò)傳輸?shù)脑O(shè)計(jì)是基于Netty實(shí)現(xiàn)的,Netty提供了一整套完善的NIO客戶端、服務(wù)端處理框架,能夠很好地處理網(wǎng)絡(luò)代理之間的連接心跳、協(xié)議轉(zhuǎn)換等問題,網(wǎng)絡(luò)代理的協(xié)議轉(zhuǎn)換功能就是基于Netty的編解碼器實(shí)現(xiàn).

3 實(shí)驗(yàn)設(shè)計(jì)

3.1 實(shí)驗(yàn)場景

實(shí)驗(yàn)設(shè)計(jì)一個(gè)以Spring Cloud實(shí)現(xiàn)的consumer來消費(fèi)三個(gè)性能不同的以Dubbo實(shí)現(xiàn)的provider的場景,并通過wrk壓測工具向consumer施壓,通過lua腳本獲取壓力測試結(jié)果,實(shí)驗(yàn)場景并不復(fù)雜(如圖4),評(píng)測系統(tǒng)只涉及單接口評(píng)測,將壓力測試得到的QPS作為吞吐量的評(píng)價(jià)分?jǐn)?shù),以此來評(píng)價(jià)網(wǎng)絡(luò)代理的性能.

得益于Docker容器技術(shù)可快速方便地部署本實(shí)驗(yàn)的場景.實(shí)驗(yàn)環(huán)境部署在兩臺(tái)物理機(jī)上,一臺(tái)為施壓機(jī),配置為MACOS,4核8 G,通過wrk壓測工具向另一臺(tái)物理機(jī)施壓;另一臺(tái)為被壓機(jī),配置為CentOS7,8核16 G,通過Docker容器技術(shù)部署5個(gè)Docker實(shí)例:

(1)以Spring Cloud為技術(shù)框架實(shí)現(xiàn)的consumer及其網(wǎng)絡(luò)代理agent,JVM參數(shù)為1536 M的堆內(nèi)存分配.

(2)以Dubbo為技術(shù)框架實(shí)現(xiàn)的small-provider及其網(wǎng)絡(luò)代理agent,JVM參數(shù)為512 M的堆內(nèi)存分配.

(3)以Dubbo為技術(shù)框架實(shí)現(xiàn)的medium-provider及其網(wǎng)絡(luò)代理agent,JVM參數(shù)為1536 M的堆內(nèi)存分配.

圖4 實(shí)驗(yàn)場景

(4)以Dubbo為技術(shù)框架實(shí)現(xiàn)的large-provider及其網(wǎng)絡(luò)代理agent,JVM參數(shù)為2560 M的堆內(nèi)存分配.

(5)注冊(cè)中心Etcd.

實(shí)驗(yàn)整體流程如下: consumer在接收到客戶端請(qǐng)求以后,會(huì)生成一個(gè)隨機(jī)字符串,該字符串經(jīng)過consumeragent和provider-agent后到達(dá)provider,為了模擬現(xiàn)實(shí)情況下查詢數(shù)據(jù)庫等耗時(shí)的操作,provider人為增加50 ms延時(shí),并計(jì)算哈希值后返回,client會(huì)校驗(yàn)該哈希值與其生成的數(shù)據(jù)是否相同,如果相同則返回正常(200),否則返回異常(500).每個(gè)通信環(huán)節(jié)的通訊協(xié)議如表1所示.

表1 通訊環(huán)節(jié)與遠(yuǎn)程通訊協(xié)議

3.2 實(shí)驗(yàn)結(jié)果

實(shí)驗(yàn)通過網(wǎng)絡(luò)代理實(shí)現(xiàn)以Dubbo為技術(shù)框架、DUBBO為傳輸協(xié)議建設(shè)的服務(wù)和以Spring Cloud為技術(shù)框架、HTTP為傳輸協(xié)議建設(shè)的服務(wù)之間的通訊,并且網(wǎng)絡(luò)代理和業(yè)務(wù)服務(wù)互相獨(dú)立,實(shí)現(xiàn)了網(wǎng)絡(luò)代理的功能要求.另一方面,實(shí)驗(yàn)通過wrk壓測工具對(duì)實(shí)驗(yàn)場景進(jìn)行施壓,并將QPS作為網(wǎng)絡(luò)代理性能的評(píng)價(jià)分?jǐn)?shù).為了模擬不同的業(yè)務(wù)環(huán)境,并發(fā)數(shù)分別為128,256和512,單次實(shí)驗(yàn)結(jié)果如圖5所示,為減少實(shí)驗(yàn)環(huán)境的不穩(wěn)定,進(jìn)行10次不同壓測記錄,結(jié)果如圖6所示.

圖5 單次壓測128、256、512并發(fā)實(shí)驗(yàn)結(jié)果

圖6 壓測10次實(shí)驗(yàn)結(jié)果

由圖5和圖6可知,系統(tǒng)平均響應(yīng)時(shí)間去除provider中50 ms的人為延時(shí),128并發(fā)下能做到整個(gè)流程的傳輸時(shí)間在4 ms以內(nèi),256并發(fā)下整個(gè)流程的傳輸時(shí)間在12 ms以內(nèi),并且10次壓測結(jié)果波動(dòng)很小,網(wǎng)絡(luò)代理在并發(fā)量不大的環(huán)境下響應(yīng)速度快,性能穩(wěn)定;在512并發(fā)下,整個(gè)流程的傳輸時(shí)間在40 ms以內(nèi),10次壓測結(jié)果雖然有一定的波動(dòng),但波動(dòng)浮動(dòng)不大,并且將近400萬的請(qǐng)求中沒有出現(xiàn)異常錯(cuò)誤的情況,網(wǎng)絡(luò)代理能滿足高并發(fā)、高吞吐量的性能要求.

實(shí)驗(yàn)也對(duì)隨機(jī)法、輪詢法和加權(quán)輪詢法的負(fù)載均衡算法進(jìn)行對(duì)比,通過記錄每個(gè)provider處理的請(qǐng)求數(shù)和壓測結(jié)果QPS分析不同負(fù)載均衡算法的性能,實(shí)驗(yàn)結(jié)果如圖7所示.實(shí)驗(yàn)表明,輪詢和隨機(jī)的負(fù)載均衡算法三個(gè)provider處理的請(qǐng)求數(shù)基本相同,輪詢法的QPS相對(duì)更加穩(wěn)定,并且這兩種負(fù)載均衡算法在512并發(fā)情況下均出現(xiàn)了請(qǐng)求異常的情況,這是因?yàn)闆]有合理分配負(fù)載,過量的請(qǐng)求將配置低的smallprovider線程池?fù)螡M溢出,造成請(qǐng)求失敗的情況.而加權(quán)輪詢的負(fù)載均衡算法三個(gè)provider處理的請(qǐng)求數(shù)基本按照small:medium:large=1:2:3分配,負(fù)載合理,QPS比另外兩種負(fù)載均衡算法都高,并且全程沒有出現(xiàn)請(qǐng)求失敗的情況.實(shí)驗(yàn)結(jié)果表明,加權(quán)輪詢的負(fù)載均衡算法更適合網(wǎng)絡(luò)代理的設(shè)計(jì).

圖7 不同負(fù)載均衡算法實(shí)驗(yàn)結(jié)果

為了比較不同序列化方式對(duì)網(wǎng)絡(luò)傳輸性能的影響,實(shí)驗(yàn)對(duì)Java原生序列化、JackSon、Hessian和protobuf進(jìn)行了對(duì)比,通過10次256并發(fā)下的壓測結(jié)果分析不同序列化方式網(wǎng)絡(luò)傳輸?shù)男阅?實(shí)驗(yàn)結(jié)果如圖7所示.實(shí)驗(yàn)結(jié)果表明,基于protobuf序列化方式的系統(tǒng)QPS總是優(yōu)于其他幾種序列化方式,更適合網(wǎng)絡(luò)代理的設(shè)計(jì).

圖8 不同序列化方式的實(shí)驗(yàn)結(jié)果

4 結(jié)論

本文基于服務(wù)網(wǎng)格思想實(shí)現(xiàn)了一個(gè)具有服務(wù)注冊(cè)發(fā)現(xiàn)、負(fù)載均衡、協(xié)議轉(zhuǎn)換的網(wǎng)絡(luò)代理作為微服務(wù)架構(gòu)的服務(wù)治理獨(dú)立組件,解決了傳統(tǒng)微服務(wù)架構(gòu)中服務(wù)治理與服務(wù)之間高耦合的問題;并且在每個(gè)服務(wù)容器中部署網(wǎng)絡(luò)代理實(shí)現(xiàn)了對(duì)所有進(jìn)出服務(wù)的流量攔截控制,通過網(wǎng)絡(luò)代理能優(yōu)雅的實(shí)現(xiàn)不同技術(shù)框架和通訊協(xié)議建設(shè)的服務(wù)之間互聯(lián)互通.實(shí)驗(yàn)結(jié)果表明,本文的設(shè)計(jì)實(shí)現(xiàn)了以Dubbo技術(shù)框架、DUBBO通訊協(xié)議建設(shè)的服務(wù)和以Spring Cloud技術(shù)框架、HTTP通訊協(xié)議建設(shè)的服務(wù)之間的互聯(lián)互通和服務(wù)治理從服務(wù)中的獨(dú)立;另一方面,實(shí)驗(yàn)對(duì)系統(tǒng)進(jìn)行不同并發(fā)的壓力測試,實(shí)驗(yàn)結(jié)果表明本文的設(shè)計(jì)具備高并發(fā)、高吞吐量、高可用的性能要求.