基于服務網格的微服務架構服務治理研究①

鄭俊褒,沈林強

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

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

微服務架構[4-6]是一種架構風格,將大型復雜系統細粒度的拆分成多個能夠獨立運行、職能單一的服務,服務之間通過通用的協議進行通訊.微服務架構的系統在系統擴展性、敏捷性等方面相比于SOA架構的系統都具有明顯的優勢,但是這種細粒度拆分服務的方式勢必會使服務治理變得異常復雜.傳統服務治理框架,如Dubbo、Spring Cloud為微服務服務治理提供了切實有效的解決方案,但都存在難以實現不同技術框架和通訊協議建設的服務之間互聯互通和服務治理與服務高耦合的問題.本文基于服務網格的思想對微服務服務治理進行改造,從服務中抽取出服務治理相關功能并集成在網絡代理上,網絡代理作為服務治理的獨立組件解決了服務治理和服務高耦合的問題,并且網絡代理會對所有進出服務的流量進行攔截,能夠實現不同技術框架和通訊協議建設的服務之間互聯互通.

1 相關工作

1.1 服務治理

在微服務架構中服務治理是整個系統正常運行的關鍵技術,在大型復雜系統環境下,服務間的調用會變得非常復雜,如果沒有一套完善的、經過大規模生產環境驗證的服務治理方案的話,系統將會處于非常危險的境地.為解決復雜環境下服務治理的問題,出現了很多服務治理框架,其中應用最廣泛有Dubbo和Spring Cloud.

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

Spring Cloud是一系列Spring框架的集合,以SpringBoot作為開發的基礎,通過SpringBoot可以簡單高效地集成服務發現注冊、負載均衡、斷路器[9]等其他Spring家族的分布式框架[10],相比于Dubbo框架,Spring Cloud最大的特色在于一站式的分布式系統架構.

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

1.2 服務網格

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

當一個系統采用服務網格化的微服務架構時,系統網絡拓撲圖如圖1所示.網絡代理作為服務治理的獨立組件會和每個業務服務部署在同一容器中,當業務服務需要調用其他服務時,業務服務只向同一容器下的網絡代理發送請求,實際的服務通訊和治理是在兩個網絡代理之間完成的,整個系統以網絡代理作為服務間通訊的專用基礎設施.

圖1 服務網格化的微服務系統網絡拓撲圖

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

圖2 服務網格化的微服務和傳統微服務服務調用方式

綜上所述克服傳統微服務的兩大問題的關鍵是實現一個獨立的、高可用的、具備服務治理、協議轉換等功能的網絡代理;另一方面,由于網絡代理的存在,每次服務調用會增加兩次從服務到網絡代理的網絡開銷,因此網絡代理還必須具備高并發、高吞吐量的性能要求.網絡代理功能、性能需求如下:

(1)良好的服務治理能力.網絡代理作為服務調用的基礎設施,服務治理是其最基礎的能力.

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

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

2 網絡代理實現

針對上文網絡代理功能和性能的需求,本文以圖3網絡代理的實現機制對網絡代理進行構建.其中consumer-agent和provider-agent是網絡代理對應于服務調用的消費者網絡代理和生產者網絡代理,圖中以Spring Cloud為技術框架的consumer去調用以Dubbo為技術框架的provider為例,服務調用的流程如下:

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

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

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

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

(5)Provider將請求解析并進行具體的業務處理,而后逆反上續步驟將處理結果返回給consumer,完成一次服務調用.

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

圖3 網絡代理實現機制

2.1 服務治理

服務治理包括服務注冊發現、負載均衡等,其中服務的注冊發現是最重要最基礎的服務治理能力,而負載均衡能力是一個穩定、高性能微服務系統不可缺少的能力,本文的網絡代理設計服務治理包括服務發現注冊和負載均衡.

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

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

2.2 網絡傳輸

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

除了網絡I/O模型外,網絡傳輸協議也是網絡傳輸性能的關鍵因素.TCP面向連接的傳輸協議相比于UDP無連接傳輸協議最大的特點在于可靠安全,這在本文的微服務場景下是非常重要的性能.在生產環境下,集群的網絡環境常常是不穩定的,網絡傳輸的可靠性是整個系統的一項重要指標.網絡代理之間的傳輸協議采用TCP協議,為了保證傳輸效率,不多次反復創建TCP連接,采用TCP長連接的方式.

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

2.3 協議轉換

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

3 實驗設計

3.1 實驗場景

實驗設計一個以Spring Cloud實現的consumer來消費三個性能不同的以Dubbo實現的provider的場景,并通過wrk壓測工具向consumer施壓,通過lua腳本獲取壓力測試結果,實驗場景并不復雜(如圖4),評測系統只涉及單接口評測,將壓力測試得到的QPS作為吞吐量的評價分數,以此來評價網絡代理的性能.

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

(1)以Spring Cloud為技術框架實現的consumer及其網絡代理agent,JVM參數為1536 M的堆內存分配.

(2)以Dubbo為技術框架實現的small-provider及其網絡代理agent,JVM參數為512 M的堆內存分配.

(3)以Dubbo為技術框架實現的medium-provider及其網絡代理agent,JVM參數為1536 M的堆內存分配.

圖4 實驗場景

(4)以Dubbo為技術框架實現的large-provider及其網絡代理agent,JVM參數為2560 M的堆內存分配.

(5)注冊中心Etcd.

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

表1 通訊環節與遠程通訊協議

3.2 實驗結果

實驗通過網絡代理實現以Dubbo為技術框架、DUBBO為傳輸協議建設的服務和以Spring Cloud為技術框架、HTTP為傳輸協議建設的服務之間的通訊,并且網絡代理和業務服務互相獨立,實現了網絡代理的功能要求.另一方面,實驗通過wrk壓測工具對實驗場景進行施壓,并將QPS作為網絡代理性能的評價分數.為了模擬不同的業務環境,并發數分別為128,256和512,單次實驗結果如圖5所示,為減少實驗環境的不穩定,進行10次不同壓測記錄,結果如圖6所示.

圖5 單次壓測128、256、512并發實驗結果

圖6 壓測10次實驗結果

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

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

圖7 不同負載均衡算法實驗結果

為了比較不同序列化方式對網絡傳輸性能的影響,實驗對Java原生序列化、JackSon、Hessian和protobuf進行了對比,通過10次256并發下的壓測結果分析不同序列化方式網絡傳輸的性能,實驗結果如圖7所示.實驗結果表明,基于protobuf序列化方式的系統QPS總是優于其他幾種序列化方式,更適合網絡代理的設計.

圖8 不同序列化方式的實驗結果

4 結論

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