基于服務(wù)網(wǎng)格的微服務(wù)架構(gòu)服務(wù)治理研究①

鄭俊褒,沈林強

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

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

微服務(wù)架構(gòu)[4-6]是一種架構(gòu)風(fēng)格,將大型復(fù)雜系統(tǒng)細(xì)粒度的拆分成多個能夠獨立運行、職能單一的服務(wù),服務(wù)之間通過通用的協(xié)議進(jìn)行通訊.微服務(wù)架構(gòu)的系統(tǒng)在系統(tǒng)擴(kuò)展性、敏捷性等方面相比于SOA架構(gòu)的系統(tǒng)都具有明顯的優(yōu)勢,但是這種細(xì)粒度拆分服務(wù)的方式勢必會使服務(wù)治理變得異常復(fù)雜.傳統(tǒng)服務(wù)治理框架,如Dubbo、Spring Cloud為微服務(wù)服務(wù)治理提供了切實有效的解決方案,但都存在難以實現(xiàn)不同技術(shù)框架和通訊協(xié)議建設(shè)的服務(wù)之間互聯(lián)互通和服務(wù)治理與服務(wù)高耦合的問題.本文基于服務(wù)網(wǎng)格的思想對微服務(wù)服務(wù)治理進(jìn)行改造,從服務(wù)中抽取出服務(wù)治理相關(guān)功能并集成在網(wǎng)絡(luò)代理上,網(wǎng)絡(luò)代理作為服務(wù)治理的獨立組件解決了服務(wù)治理和服務(wù)高耦合的問題,并且網(wǎng)絡(luò)代理會對所有進(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ù)治理是整個系統(tǒng)正常運行的關(guān)鍵技術(shù),在大型復(fù)雜系統(tǒng)環(huán)境下,服務(wù)間的調(diào)用會變得非常復(fù)雜,如果沒有一套完善的、經(jīng)過大規(guī)模生產(chǎn)環(huán)境驗證的服務(wù)治理方案的話,系統(tǒng)將會處于非常危險的境地.為解決復(fù)雜環(huán)境下服務(wù)治理的問題,出現(xiàn)了很多服務(wù)治理框架,其中應(yīng)用最廣泛有Dubbo和Spring Cloud.

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

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

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

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

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

當(dāng)一個系統(tǒng)采用服務(wù)網(wǎng)格化的微服務(wù)架構(gòu)時,系統(tǒng)網(wǎng)絡(luò)拓?fù)鋱D如圖1所示.網(wǎng)絡(luò)代理作為服務(wù)治理的獨立組件會和每個業(yè)務(wù)服務(wù)部署在同一容器中,當(dāng)業(yè)務(wù)服務(wù)需要調(diào)用其他服務(wù)時,業(yè)務(wù)服務(wù)只向同一容器下的網(wǎng)絡(luò)代理發(fā)送請求,實際的服務(wù)通訊和治理是在兩個網(wǎng)絡(luò)代理之間完成的,整個系統(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)格實現(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ù)沒有實現(xiàn)業(yè)務(wù)服務(wù)和服務(wù)治理的分離,服務(wù)治理通過框架配置等方式和業(yè)務(wù)服務(wù)部署在同一服務(wù)中,耦合性高,不利于服務(wù)的升級迭代,開發(fā)維護(hù)人員除了要完成業(yè)務(wù)服務(wù)之外還要兼顧服務(wù)發(fā)現(xiàn)注冊等服務(wù)治理工作,無疑也增加了開發(fā)維護(hù)的成本;此外當(dāng)系統(tǒng)需要接入不同技術(shù)框架和通訊協(xié)議建設(shè)的服務(wù)時,需要對每個相連的服務(wù)增加協(xié)議轉(zhuǎn)換功能,這對于一個大型系統(tǒng)是不能接受的.服務(wù)網(wǎng)格化的服務(wù)抽取了服務(wù)發(fā)現(xiàn)注冊等服務(wù)治理功能并集成于獨立的網(wǎng)絡(luò)代理,降低了服務(wù)和服務(wù)治理的耦合性,服務(wù)只包含具體業(yè)務(wù)服務(wù),開發(fā)維護(hù)人員只需要專注實現(xiàn)業(yè)務(wù)服務(wù),提高了開發(fā)維護(hù)效率;服務(wù)調(diào)用時會請求部署在同一容器的網(wǎng)絡(luò)代理,實際的服務(wù)通訊在兩個不同容器的網(wǎng)絡(luò)代理間完成,當(dāng)系統(tǒng)需要接入不同技術(shù)框架和通訊協(xié)議建設(shè)的服務(wù)時,只需要在通用的網(wǎng)絡(luò)代理中支持協(xié)議轉(zhuǎn)換等功能,不會對服務(wù)造成侵入.

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

綜上所述克服傳統(tǒng)微服務(wù)的兩大問題的關(guān)鍵是實現(xiàn)一個獨立的、高可用的、具備服務(wù)治理、協(xié)議轉(zhuǎn)換等功能的網(wǎng)絡(luò)代理;另一方面,由于網(wǎng)絡(luò)代理的存在,每次服務(wù)調(diào)用會增加兩次從服務(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è)計為不同技術(shù)框架和不同傳輸協(xié)議建設(shè)的服務(wù)之間互聯(lián)互通提供了前提條件,在本文中將協(xié)議轉(zhuǎn)換的功能委托給網(wǎng)絡(luò)代理,在不同傳輸協(xié)議的服務(wù)之間通訊時,只需要通用的網(wǎng)絡(luò)代理實現(xiàn)了協(xié)議轉(zhuǎn)換功能,而不需要對每個服務(wù)都進(jìn)行升級.

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

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

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

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

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

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

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

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

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

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

2.1 服務(wù)治理

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

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

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

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

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

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

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

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

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

3 實驗設(shè)計

3.1 實驗場景

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

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

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

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

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

圖4 實驗場景

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

(5)注冊中心Etcd.

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

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

3.2 實驗結(jié)果

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

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

圖6 壓測10次實驗結(jié)果

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

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

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

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

圖8 不同序列化方式的實驗結(jié)果

4 結(jié)論

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