基于Service Comb的多語言微服務平臺①

趙 昱

(武漢郵電科學研究院,武漢 430074)

隨著云技術和通信網絡的快速發展,通信網絡管理系統一方面需要承載新開發的網絡運維服務,另一方面需要兼容原有的網絡管理服務,將原有服務和新開發的服務統一管理[1].

在微服務平臺上實現已有網管功能的融合管理和新開發微服務架構功能的發布和服務治理,如何將C/S 架構的網管平臺中的C++服務發布到使用B/S 架構開發的Java 語言平臺[2],是現有通信運維管理平臺最關鍵的工作之一.目前對于通信網運維平臺的研究主要是使用Java 或其他語言進行單語言開發與維護[3],對多種語言微服務統一管控的研究較少.

針對以上問題,本文在前有研究的基礎上,提出了使用ServiceComb 架構的微服務平臺,通過開發Java 底座和C++底座的模式,為現有兩種語言的共同治理提供共同的環境.而對于傳統網管服務較多、服務之間相互依賴的情況,使用邊車模式,將互相依賴的服務編入同一邊車內,從而使已有網管軟件的功能不受到影響.平臺面向通信提供商運維人員,將已有的通信網管軟件進行融合一體化,在滿足運營商要求的同時,減少運維人員的工作難度.

1 ServiceComb 架構

1.1 微服務架構介紹

傳統軟件多使用單體架構實現,單體架構也被稱為單體系統或者是單體應用,就是一種系統中所有的功能、模塊耦合在一個應用中的架構方式.用簡單的方式理解就是將整個應用包括應用、數據庫等都在同一個服務器上.而分布式從簡單的角度上理解就是將應用和數據等分開到不同的服務器上,就然后對于應用和數據庫進行不同方向上的性能優化等等操作.單一架構相比于微服務架構,具有測試成本高、可伸縮性差、可靠性差、迭代困難、跨語言程度差、團隊協作難等缺點.

微服務是一種架構風格,一個大型的復雜軟件應用,由一個或者多個微服務組成,系統中的各個微服務可以被獨立部署,各個微服務之間是松耦合的,每個微服務僅僅關注于完成一件任務并很好的完成該任務.將一個復雜的軟件系統進行拆分,通過拆分之后,這個復雜的應用系統變的更加的高效.

微服務架構優點可以概括為以下幾點:

(1)降低復雜度:將原來偶合在一起的復雜業務拆分為單個服務,規避了原本復雜度無止境的積累.每一個微服務專注于單一功能,并通過定義良好的接口清晰表述服務邊界.每個服務開發者只專注服務本身,通過使用緩存、DAL 等各種技術手段來提升系統的性能,而對于消費方來說完全透明.

(2)可獨立部署:由于微服務具備獨立的運行進程,所以每個微服務可以獨立部署.當業務迭代時只需要發布相關服務的迭代即可,降低了測試的工作量同時也降低了服務發布的風險.

(3)容錯:在微服務架構下,當某一組件發生故障時,故障會被隔離在單個服務中.通過限流、熔斷等方式降低錯誤導致的危害,保障核心業務正常運行.

(4)擴展:單塊架構應用也可以實現橫向擴展,就是將整個應用完整的復制到不同的節點.當應用的不同組件在擴展需求上存在差異時,微服務架構便體現出其靈活性,因為每個服務可以根據實際需求獨立進行擴展.

1.2 ServiceComb 架構

目前常見的微服務架構有SpringCloud 和Dubbo,Spring Cloud 是一系列框架的有序集合.它利用Spring Boot 的開發便利性巧妙地簡化了分布式系統基礎設施的開發,如服務發現注冊、配置中心、消息總線、負載均衡、斷路器、數據監控等,都可以用Spring Boot 的開發風格做到一鍵啟動和部署.Dubbo 是阿里巴巴公司開源的服務治理框架,使用人數眾多,提供了優秀的分布式解決方案.但是SpringCloud 和Dubbo在Java 之外的其他編程語言的支持較差,為了解決這一問題,本文采用ServiceComb 架構進行開發.

ServiceComb 是華為云于2017年6月開源的微服務框架,并于2017年12月正式進入Apache 軟件基金會孵化.其包括一站式的服務注冊、服務治理、動態配置功能,具備服務化契約增強、多語言SDK 支持、多通信協議支持等優勢特性,并提供SAGA 數據最終一致性方案解決微服務架構數據一致性難題.ServiceComb兼容Spring Cloud 等業界流行微服務框架,互通業界生態.

ServiceComb 相比與其他微服務架構的主要優點是解決了存量應用和新開發應用共存的問題,對于新開發的Java 應用,使用Java-chassis (Java 底座)完成服務治理功能,而對于已經存在的,使用其他語言開發的應用,使用底座的方式實現業務代碼的0 侵入改造,從而完成混合部署,統一治理.ServiceComb 特性如圖1所示.

2 系統分析與架構設計

2.1 系統需求分析

2018年5月中國移動集團發布了最新的《OMC系統通用技術規范》,將管控一體、微服務和云架構的技術要求納入規范,規范的核心關鍵是OMC 的微服務架構.

隨著編程語言的發展,網絡管理和運維軟件的開發環境越來越多樣,需要建立一個可以統一管理多種編程語言服務的微服務平臺.多語言微服務平臺應該滿足的需求:

(1)統一服務注冊中心,對平臺上的微服務提供統一的服務注冊與發現、以及服務治理能力的支撐.

(2)統一服務配置中心,為微服務提供集中式的服務配置存儲、以及客戶端服務配置的自動拉取,實現服務配置的動態更新支持.

(3)集中式的服務運維監管中心,實現服務健康檢查與運行監控、服務配置動態變更與管理,對服務進行可視化的監管.

(4)多語言微服務底座,實現微服務的統一注冊和發現、配置動態更新、健康檢查、服務RPC 通信.微服務的統一治理問題,如:負載、熔斷、容錯、限流等.

圖1 ServiceComb 特性圖

2.2 系統模塊拆分

根據系統需求分析,將平臺設計拆分為3 個功能模塊來完成開發.分別是服務注冊和配置中心、運維監管中心、微服務底座.3 個模塊功能如下:

服務注冊和配置中心負責提供微服務的注冊和發現功能支撐,支持服務配置的動態配置.

運維監管中心主要是對平臺和平臺上的微服務進行監控和管理,對系統運維功能支持.

多語言微服務底座是核心模塊,提供對多種編程語言微服務的支持,實現服務治理、服務間通信、服務的注冊與發現等功能.目前提供了對Java 和C++的支持.

2.3 整體架構設計

為了使多語言微服務平臺的每個服務之間的分工和開發界限清晰,提高開發的效率,將平臺分為應用層、接口層、服務層、數據層和物理層,整體架構設計圖如圖2 所示.

各層包含內容如下:

(1)應用層:包括對服務的監控功能、配置的發布功能、服務的發布功能.

(2)接口層:接口層主要是API Gateway 實現的網關服務,基于JWT 實現的權限管理功能和基于RocketMQ 實現的消息中間件服務.

(3)服務層:主要是平臺提供的核心服務,如服務注冊和配置中心、運維監管中心、Java 微服務底座,C++微服務底座和邊車.還包括平臺微服務架構的基礎服務,由ServiceComb 對SpringCloud 有著良好的支持性,使用Consul 作為服務注冊和配置中心,自動化配置服務SpringCloud Config.在微服務底座中,基于Hystrix 實現的容錯處理器,實現了服務的容錯處理和服務質量信息上報.基于Ribbon 實現的負載均衡處理器,有效提高服務的承載能力.通過RPC 調用鏈模式,將負載均衡、熔斷等服務治理功能通過實現單獨的處理器來實現,自定義選擇處理器,形成鏈式調用,從而完成服務治理的功能,也為后期拓展提供了簡單的模式.平臺的基礎服務使用Consul 作為服務注冊和配置中心,簡化了設計.使用SpringCloud Config 處理服務的配置動態更新.

(1)數據層:數據層主要包括服務實例的數據、配置信息數據、配置緩存.

(2)物理層:包括服務器、網絡設備、安全組件等,支撐系統的物理組件.

3 微服務平臺的設計

3.1 注冊與配置中心

為構建高效注冊和配置中心,微服務平臺采用HashiCorp 公司Consul 注冊配置中心組件[4],Consul 作為微服務組件能同時提供注冊中心和配置中心的功能.

圖2 系統架構圖

注冊中心服務端實現:

啟動使用Consul 的應用程序,在hashicorp 官網下載consul.exe,配置consul 到環境變量啟動即可完成服務端.

注冊中心客戶端實現:

ecwid 是Consul 客戶端的一種,在Pom 依賴中添加ecwid 的consul-api.通過ConsulClient 的newService 對象的構造方法傳入注冊IP 和端口.然后設置newService對象的服務名、服務ID、服務標簽和服務端口信息,最后調用ConsulClient.agent-ServiceRegister方法完成服務注冊.

在分布式應用場景中,微服務實例對于配置中心應該具有弱依賴和稀疏變更特點[5],弱依賴性表示微服務與配置中心依賴性應該降至最低,在配置中心發生故障情況下,提高系統容災性.稀疏變更表示動態配置在部署至微服務實例后,很少發生改變.而一旦發生變更,則需要配置客戶端從配置中心快速地同步和部署配置變更.

針對上述特點,配置客戶端引入本地快照機制,將配置保存值本地文件中,提高微服務容災性.引入本地緩存機制,將本地微服務最新配置保存至緩存中,提高微服務獲取實時配置的性能.

配置中心客戶端變更流程:用戶在監控中心發布配置變更后,變更被同步至配置中心,客戶端與的配置中心之間以長輪詢方式維持著心跳,在獲取到變更通知后,重新從配置中心拉取配置,更新本地緩存和快照文件.

Consul 配置中心以鍵值K/V 方式存儲配置信息,key 值以文件夾路徑表示.為實現配置管理與共享,配置數據按照微服務隔離層次(環境---服務組---服務---服務實例)來存儲,形成樹型多層級文件夾結構,結構中子節點能夠訪問父節點中的配置,同層級節點中配置相互隔離,如圖3 所示.

圖3 配置隔離示意圖

根節點“環境”(Environment)下包含了若干個服務組,它的配置對所有微服務共享;

節點“服務組”(ServiceGroup)對環境中服務按照功能特性進行了分組,配置對組內所有微服務及其實例共享,不同微服務組配置相互隔離;

節點“服務”(Service)中的配置對該服務所有實例共享,不同微服務間配置相互隔離;

節點“服務實例”(Instance)中存儲某個微服務實例配置,不同實例間配置相互隔離.

3.2 運維監控中心

運維監控中心與Java 底座中的Hystrix 組件進行通信,獲取服務的服務質量信息并在前端以圖表的形式顯示.

運維監管中心在啟動后就按5 s 的周期對全部的服務實例進行性能監控,與服務實例進行通信獲取服務質量數據,如果是java 微服務,則建立和該服務實例的hystrix.stream 流的連接,讀取服務質量數據,如果是網管微服務,則建立和該服務實例所在邊車的hystrix.stream 流的連接,讀取服務質量數據.讀取到的服務質量數據包含了該服務實例上應用了hystrix 的所有方法的服務質量數據,對每一個服務提供者提供的每一個方法均記錄該方法的請求流量(qps)、請求的失敗/異常數[6]、請求的錯誤比例、請求的平均響應時間、服務熔斷狀態等服務質量參數[7].

獲取到服務質量數據后,對數據進行處理,處理的內容包括:整理數據、判斷告警狀態、生成或恢復服務質量告警,處理完成后將服務質量數據保存到緩存中,在每個獲取服務質量性能數據的周期里都對此緩存進行更新,此外,每隔5 分鐘將一次獲取到的服務質量數據保存到數據庫.當查看指定服務實例的服務質量數據時,后臺根據用戶請求的參數從緩存中查找到對應的服務質量數據并返回給前端.

3.3 微服務底座

3.3.1 Java 微服務底座

Java 微服務底座的提供的負載均衡、熔斷、容錯、限流等功能使用目前已有的SpringCloud 組件即可完成.

服務的注冊和發現通過Consul 完成,考慮到服務間的通信是通過底座完成,所以需要對注冊發現進行監聽.

(1)服務注冊設計

服務需要通過根據配置文件,自動將服務注冊到Consul.在獲取服務的時候,需要及時獲取到最新的服務,在獲取服務的時候需要使用緩存,避免頻繁的和Consul 進行調用.服務注冊和健康檢查流程如下:

1)Spring 容器啟動的時候,讀取配置的spring.factories,對于配置的bean 進行初始化,將Discovery AutoConfiguration 里的配置bean 進行初始化.

2)在Spring 容器初始化完成后,會發送Context RefreshedEvent,監聽這個Event,可以啟動服務端,如IceServer 或者RestServer.

3)啟動服務以后發送事件,監聽到服務啟動成功以后,將服務注冊到Consul.

注冊的時候,默認注冊地址為:"http://"+服務IP+"/actuator/health",通過Actuator 組件,consul 直接向該服務發起心跳,可以得到服務的健康狀態.監控通信通過讀取數據,可以判斷服務是否存活.

(2)服務發現設計

1)客戶端調用通過實現負載均衡功能的處理器上獲取服務列表,當處理器調用Consul 獲取服務列表的時候,首先去訪問緩存,獲取當前的緩存狀態,若緩存狀態為success,則返回服務列表,若緩存狀態為False,則去Consul 上獲取最新的服務列表,并更新緩存.

2)初始化的時候啟動Consul 監聽任務去Consul上監聽是否有服務的變更.

3)當Consul 的服務發生變更以后,向緩存發送緩存失效信息,DiscoveryCache(發現緩存)此時設置緩存可讀狀態為False.

4)當下次請求訪問到,DiscoveryCache 的時候,獲取服務列表時,首先去獲取緩存可讀的狀態,當為False 的時候,直接向Consul 獲取最新的服務列表.

(3)服務RPC 調用鏈設計

微服務底座的服務治理使用調用鏈方式進行,調用鏈是類似ServiceComb 的Chassis 組件中的Handler.將負載均衡、熔斷等服務治理功能通過實現單獨的處理器來實現,自定義選擇處理器,形成鏈式調用,從而完成服務治理.

調用鏈采用分層設計,分別為API 接入層、治理層、協議層.Spring 應用或者是網管客戶端通過調用接入層的API 接口引入服務治理功能,服務治理的整體結構采用鏈式服務,方便以后的服務治理功能的拓展,協議層封裝了客戶端發送請求和接收請求的操作.

Spring-support 提供Spring 注解,注解名稱@Reference,便于上層透明調用遠程端口,注解屬性serviceName(服務名稱),identity(訪問),protocol(協議類型).Spring 容器掃描到@Reference 注解后針對接口生成代理,并交由spring 容器進行管理.代理的核心實現在攔截器DefaultMethod-Interceptor 中,將所有參數封裝為Invocation,傳給服務治理模塊.

治理層中業務的Handler 采取單例模式,保證每一個服務在調用鏈中的治理是獨立的.LoadBalancer 從注冊中心consul 上根據路由和負載均衡策略找出一個地址發起調用.HystrixHandler 對服務調用進行相關統計,然后根據統計數據判斷是否熔斷.熔斷指定時間后會嘗試恢復.TransportClient-Handler 負責根據協議找到具體的client 然后發起調用,如BusClient.

協議層中TransportHandler 根據協議名稱選取protocol 實現,在protocol 中通過相應Client 發起遠程調用并接收響應.

自定義容器管理ExtensionLoader,通過JavaSpi 機制實現一個自定義容器.同步調用方式中DefaultMethod Interceptor 將相關參數封裝為請求,經過Handler 鏈處理,使用對應Protocol 將請求發送出去,將當前線程阻塞在控制器,服務端有響應后通知解除阻塞.

3.3.2 C++微服務底座

C++微服務底座(CppChassis)負責承載C++微服務,并負責與SideCar 之間的微服務發現的通信、服務治理的通信、配置獲取的通信與配置變化消息的處理和心跳的發送.

CppChassis RPC 調用流程圖如圖4 所示.

圖4 RPC 調用流程圖

C++網管微服務調用其他C++網管服務時,在CppChassis 里面會將調用過程分為3 個步驟:

(1)Before Invoke:該調用是通過CppChassis 從SideCar 獲取C++Provider 服務的IP 端口等定位信息;

(2)Ice Invoke:該調用通過指定的IP 端口直接發起向其他C++Provider 服務的Ice 調用;

(3)After Invoke:該調用是將調用結果通過Cpp-Chassis 反饋給SideCar,用于服務治理相關信息的收集.

3.3.3 邊車

對于C++服務,平臺使用邊車模式支持服務治理功能,Sidecar 模式是一種將應用功能從應用本身剝離出來作為單獨進程的方式.該模式允許我們向應用無侵入添加多種功能,避免了為滿足第三方組件需求而向應用添加額外的配置代碼.

邊車負責進行控制,提供負載均衡,容錯控制,熔斷控制,健康檢查等功能,服務間實際的遠程調用由服務自己完成.

(1)邊車的注冊設計

項目啟動的時候通過SPI 機制啟動掃描類,掃描環境變量C++服務對應的路徑下的yml,過濾出所有yml 格式的文件分別批量注冊.注冊完畢后運維監控中心發送注冊通知,等待邊車返回健康檢查數據.

(2)邊車的健康檢查設計

邊車的健康檢查通過調用C++微服務底座健康檢查接口實現,consul 的心跳檢查會通過邊車調用C++接口完成數據采集.

(3)邊車的RPC 調用設計

邊車提供了兩個方法:BeforeInvoke,AfterInvoke;C++服務在發起遠程調用前,先從BeforeInvoke 方法獲取服務實例,調用完成后再用AfterInvoke 方法通知邊車調用結束,以及調用的結果.

BeforeInvoke 方法中,邊車會創建一個Handler 鏈,與Java 底座實現類似.

LoadBalanceHandler 負責負載均衡功能和容錯功能,HystrixHandler 負載熔斷控制和服務質量統計,從而與Java 底座使用同樣方式實現服務治理.

AfterInvoke 方法會把遠程調用結果通知給對應的處理器Handler,從而完成服務調用監控.

4 系統測試

4.1 系統功能測試

由于平臺設計中,主要功能是對服務的監控和發布,通過查看對服務的監控,可以測試平臺的監控能力和底座的承載能力.

當平臺檢查到服務時,會在頁面上展示服務監控數據,服務監控情況如圖5 所示.需要了解異常服務詳情時,使用監控可以了解具體的服務IP 和端口以及健康檢查端口返回的元數據,異常服務詳情如圖6 所示.

圖5 服務監控圖

圖6 異常服務詳情

4.2 性能測試

系統性能測試主要分為兩個部分,第一部分為采用微服務架構的服務較原有架構服務的性能提升,另一部分為原有服務采用微服務底座承載之后性能劣化是否在20%以內.

本文采用Apache Bench 模擬100 個用戶對微服務發出訪問請求,分析內存占用情況如圖7 所示,其中上方虛線表示傳統單架構服務的內存占用,下方實線表示采用本文微服務底座的服務內存占用.橫軸表示請求發出后服務運行時間(s),縱軸表示內存占用大小(MB).

對于原有C++語言開發的服務,由于RPC 操作通過邊車進行,每次調用服務在原有調用邏輯上增加了BeforeInvoke 和AfterInvoke 操作,可能會造成性能劣化,通過模擬調用同一接口多次,得到調用時間如表1所示.

圖7 內存占用對比圖

表1 多次調用C++接口響應時間對比分析

可以看出,在高并發情況下,采用本文微服務架構的服務內存占用較傳統架構服務有著明顯優勢,并且內存占用變化更為平穩.

從表中可以看出,原有C++服務通過引入底座模塊后,RPC 調用耗時有所增加,但劣化范圍在12%左右,在期望范圍之內.

通過將不同語言語言開發的服務置于不同的底座之中,統一交由平臺監控管理,對于微服務的并發環境下內存占用,由于使用基于SpringCloud Robbin 的負載均衡組件,使得服務更加平穩且內存占用更小,對于C++服務,在引入C++底座和邊車后被改造為微服務,使其具有了服務治理的功能,在RPC 調用時性能略有下降但無明顯劣化.

5 結束語

通信業務的快速發展,網絡管理軟件和運維系統也在不斷更新,但統一管理的難度卻越來越大,運維人員需要統一的管理控制平臺應對愈發復雜的網絡情況.多語言微服務平臺作為承載EMS 系統和SDN 控制器的拓展融合平臺,實現了微服務的注冊與發現、質量監控、服務定制化發布、多種語言微服務共同治理的一體化集成.該平臺能幫助新開發的Java 微服務發布到管控平臺進行發布與管理,也能將傳統的C++服務通過底座發布到平臺中并實現統一管控.為網絡方案供應商解決滿足中國移動OMC 技術規范中的要求提供了新的思路和示范性的系統,為傳統網絡管理軟件實現服務治理和應用監控起到了關鍵性作用,同時也保證了已有功能再利用,減少了資源浪費.但是對于其他編程語言的融入沒有進行相應測試,下一步將以承載Golang、Scala 微服務作為研究目標.