趙 昱

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

隨著云技術(shù)和通信網(wǎng)絡(luò)的快速發(fā)展,通信網(wǎng)絡(luò)管理系統(tǒng)一方面需要承載新開發(fā)的網(wǎng)絡(luò)運(yùn)維服務(wù),另一方面需要兼容原有的網(wǎng)絡(luò)管理服務(wù),將原有服務(wù)和新開發(fā)的服務(wù)統(tǒng)一管理[1].

在微服務(wù)平臺(tái)上實(shí)現(xiàn)已有網(wǎng)管功能的融合管理和新開發(fā)微服務(wù)架構(gòu)功能的發(fā)布和服務(wù)治理,如何將C/S 架構(gòu)的網(wǎng)管平臺(tái)中的C++服務(wù)發(fā)布到使用B/S 架構(gòu)開發(fā)的Java 語言平臺(tái)[2],是現(xiàn)有通信運(yùn)維管理平臺(tái)最關(guān)鍵的工作之一.目前對(duì)于通信網(wǎng)運(yùn)維平臺(tái)的研究主要是使用Java 或其他語言進(jìn)行單語言開發(fā)與維護(hù)[3],對(duì)多種語言微服務(wù)統(tǒng)一管控的研究較少.

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

1 ServiceComb 架構(gòu)

1.1 微服務(wù)架構(gòu)介紹

傳統(tǒng)軟件多使用單體架構(gòu)實(shí)現(xiàn),單體架構(gòu)也被稱為單體系統(tǒng)或者是單體應(yīng)用,就是一種系統(tǒng)中所有的功能、模塊耦合在一個(gè)應(yīng)用中的架構(gòu)方式.用簡(jiǎn)單的方式理解就是將整個(gè)應(yīng)用包括應(yīng)用、數(shù)據(jù)庫(kù)等都在同一個(gè)服務(wù)器上.而分布式從簡(jiǎn)單的角度上理解就是將應(yīng)用和數(shù)據(jù)等分開到不同的服務(wù)器上,就然后對(duì)于應(yīng)用和數(shù)據(jù)庫(kù)進(jìn)行不同方向上的性能優(yōu)化等等操作.單一架構(gòu)相比于微服務(wù)架構(gòu),具有測(cè)試成本高、可伸縮性差、可靠性差、迭代困難、跨語言程度差、團(tuán)隊(duì)協(xié)作難等缺點(diǎn).

微服務(wù)是一種架構(gòu)風(fēng)格,一個(gè)大型的復(fù)雜軟件應(yīng)用,由一個(gè)或者多個(gè)微服務(wù)組成,系統(tǒng)中的各個(gè)微服務(wù)可以被獨(dú)立部署,各個(gè)微服務(wù)之間是松耦合的,每個(gè)微服務(wù)僅僅關(guān)注于完成一件任務(wù)并很好的完成該任務(wù).將一個(gè)復(fù)雜的軟件系統(tǒng)進(jìn)行拆分,通過拆分之后,這個(gè)復(fù)雜的應(yīng)用系統(tǒng)變的更加的高效.

微服務(wù)架構(gòu)優(yōu)點(diǎn)可以概括為以下幾點(diǎn):

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

(2)可獨(dú)立部署:由于微服務(wù)具備獨(dú)立的運(yùn)行進(jìn)程,所以每個(gè)微服務(wù)可以獨(dú)立部署.當(dāng)業(yè)務(wù)迭代時(shí)只需要發(fā)布相關(guān)服務(wù)的迭代即可,降低了測(cè)試的工作量同時(shí)也降低了服務(wù)發(fā)布的風(fēng)險(xiǎn).

(3)容錯(cuò):在微服務(wù)架構(gòu)下,當(dāng)某一組件發(fā)生故障時(shí),故障會(huì)被隔離在單個(gè)服務(wù)中.通過限流、熔斷等方式降低錯(cuò)誤導(dǎo)致的危害,保障核心業(yè)務(wù)正常運(yùn)行.

(4)擴(kuò)展:單塊架構(gòu)應(yīng)用也可以實(shí)現(xiàn)橫向擴(kuò)展,就是將整個(gè)應(yīng)用完整的復(fù)制到不同的節(jié)點(diǎn).當(dāng)應(yīng)用的不同組件在擴(kuò)展需求上存在差異時(shí),微服務(wù)架構(gòu)便體現(xiàn)出其靈活性,因?yàn)槊總€(gè)服務(wù)可以根據(jù)實(shí)際需求獨(dú)立進(jìn)行擴(kuò)展.

1.2 ServiceComb 架構(gòu)

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

ServiceComb 是華為云于2017年6月開源的微服務(wù)框架,并于2017年12月正式進(jìn)入Apache 軟件基金會(huì)孵化.其包括一站式的服務(wù)注冊(cè)、服務(wù)治理、動(dòng)態(tài)配置功能,具備服務(wù)化契約增強(qiáng)、多語言SDK 支持、多通信協(xié)議支持等優(yōu)勢(shì)特性,并提供SAGA 數(shù)據(jù)最終一致性方案解決微服務(wù)架構(gòu)數(shù)據(jù)一致性難題.ServiceComb兼容Spring Cloud 等業(yè)界流行微服務(wù)框架,互通業(yè)界生態(tài).

ServiceComb 相比與其他微服務(wù)架構(gòu)的主要優(yōu)點(diǎn)是解決了存量應(yīng)用和新開發(fā)應(yīng)用共存的問題,對(duì)于新開發(fā)的Java 應(yīng)用,使用Java-chassis (Java 底座)完成服務(wù)治理功能,而對(duì)于已經(jīng)存在的,使用其他語言開發(fā)的應(yīng)用,使用底座的方式實(shí)現(xiàn)業(yè)務(wù)代碼的0 侵入改造,從而完成混合部署,統(tǒng)一治理.ServiceComb 特性如圖1所示.

2 系統(tǒng)分析與架構(gòu)設(shè)計(jì)

2.1 系統(tǒng)需求分析

2018年5月中國(guó)移動(dòng)集團(tuán)發(fā)布了最新的《OMC系統(tǒng)通用技術(shù)規(guī)范》,將管控一體、微服務(wù)和云架構(gòu)的技術(shù)要求納入規(guī)范,規(guī)范的核心關(guān)鍵是OMC 的微服務(wù)架構(gòu).

隨著編程語言的發(fā)展,網(wǎng)絡(luò)管理和運(yùn)維軟件的開發(fā)環(huán)境越來越多樣,需要建立一個(gè)可以統(tǒng)一管理多種編程語言服務(wù)的微服務(wù)平臺(tái).多語言微服務(wù)平臺(tái)應(yīng)該滿足的需求:

(1)統(tǒng)一服務(wù)注冊(cè)中心,對(duì)平臺(tái)上的微服務(wù)提供統(tǒng)一的服務(wù)注冊(cè)與發(fā)現(xiàn)、以及服務(wù)治理能力的支撐.

(2)統(tǒng)一服務(wù)配置中心,為微服務(wù)提供集中式的服務(wù)配置存儲(chǔ)、以及客戶端服務(wù)配置的自動(dòng)拉取,實(shí)現(xiàn)服務(wù)配置的動(dòng)態(tài)更新支持.

(3)集中式的服務(wù)運(yùn)維監(jiān)管中心,實(shí)現(xiàn)服務(wù)健康檢查與運(yùn)行監(jiān)控、服務(wù)配置動(dòng)態(tài)變更與管理,對(duì)服務(wù)進(jìn)行可視化的監(jiān)管.

(4)多語言微服務(wù)底座,實(shí)現(xiàn)微服務(wù)的統(tǒng)一注冊(cè)和發(fā)現(xiàn)、配置動(dòng)態(tài)更新、健康檢查、服務(wù)RPC 通信.微服務(wù)的統(tǒng)一治理問題,如:負(fù)載、熔斷、容錯(cuò)、限流等.

圖1 ServiceComb 特性圖

2.2 系統(tǒng)模塊拆分

根據(jù)系統(tǒng)需求分析,將平臺(tái)設(shè)計(jì)拆分為3 個(gè)功能模塊來完成開發(fā).分別是服務(wù)注冊(cè)和配置中心、運(yùn)維監(jiān)管中心、微服務(wù)底座.3 個(gè)模塊功能如下:

服務(wù)注冊(cè)和配置中心負(fù)責(zé)提供微服務(wù)的注冊(cè)和發(fā)現(xiàn)功能支撐,支持服務(wù)配置的動(dòng)態(tài)配置.

運(yùn)維監(jiān)管中心主要是對(duì)平臺(tái)和平臺(tái)上的微服務(wù)進(jìn)行監(jiān)控和管理,對(duì)系統(tǒng)運(yùn)維功能支持.

多語言微服務(wù)底座是核心模塊,提供對(duì)多種編程語言微服務(wù)的支持,實(shí)現(xiàn)服務(wù)治理、服務(wù)間通信、服務(wù)的注冊(cè)與發(fā)現(xiàn)等功能.目前提供了對(duì)Java 和C++的支持.

2.3 整體架構(gòu)設(shè)計(jì)

為了使多語言微服務(wù)平臺(tái)的每個(gè)服務(wù)之間的分工和開發(fā)界限清晰,提高開發(fā)的效率,將平臺(tái)分為應(yīng)用層、接口層、服務(wù)層、數(shù)據(jù)層和物理層,整體架構(gòu)設(shè)計(jì)圖如圖2 所示.

各層包含內(nèi)容如下:

(1)應(yīng)用層:包括對(duì)服務(wù)的監(jiān)控功能、配置的發(fā)布功能、服務(wù)的發(fā)布功能.

(2)接口層:接口層主要是API Gateway 實(shí)現(xiàn)的網(wǎng)關(guān)服務(wù),基于JWT 實(shí)現(xiàn)的權(quán)限管理功能和基于RocketMQ 實(shí)現(xiàn)的消息中間件服務(wù).

(3)服務(wù)層:主要是平臺(tái)提供的核心服務(wù),如服務(wù)注冊(cè)和配置中心、運(yùn)維監(jiān)管中心、Java 微服務(wù)底座,C++微服務(wù)底座和邊車.還包括平臺(tái)微服務(wù)架構(gòu)的基礎(chǔ)服務(wù),由ServiceComb 對(duì)SpringCloud 有著良好的支持性,使用Consul 作為服務(wù)注冊(cè)和配置中心,自動(dòng)化配置服務(wù)SpringCloud Config.在微服務(wù)底座中,基于Hystrix 實(shí)現(xiàn)的容錯(cuò)處理器,實(shí)現(xiàn)了服務(wù)的容錯(cuò)處理和服務(wù)質(zhì)量信息上報(bào).基于Ribbon 實(shí)現(xiàn)的負(fù)載均衡處理器,有效提高服務(wù)的承載能力.通過RPC 調(diào)用鏈模式,將負(fù)載均衡、熔斷等服務(wù)治理功能通過實(shí)現(xiàn)單獨(dú)的處理器來實(shí)現(xiàn),自定義選擇處理器,形成鏈?zhǔn)秸{(diào)用,從而完成服務(wù)治理的功能,也為后期拓展提供了簡(jiǎn)單的模式.平臺(tái)的基礎(chǔ)服務(wù)使用Consul 作為服務(wù)注冊(cè)和配置中心,簡(jiǎn)化了設(shè)計(jì).使用SpringCloud Config 處理服務(wù)的配置動(dòng)態(tài)更新.

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

(2)物理層:包括服務(wù)器、網(wǎng)絡(luò)設(shè)備、安全組件等,支撐系統(tǒng)的物理組件.

3 微服務(wù)平臺(tái)的設(shè)計(jì)

3.1 注冊(cè)與配置中心

為構(gòu)建高效注冊(cè)和配置中心,微服務(wù)平臺(tái)采用HashiCorp 公司Consul 注冊(cè)配置中心組件[4],Consul 作為微服務(wù)組件能同時(shí)提供注冊(cè)中心和配置中心的功能.

圖2 系統(tǒng)架構(gòu)圖

注冊(cè)中心服務(wù)端實(shí)現(xiàn):

啟動(dòng)使用Consul 的應(yīng)用程序,在hashicorp 官網(wǎng)下載consul.exe,配置consul 到環(huán)境變量啟動(dòng)即可完成服務(wù)端.

注冊(cè)中心客戶端實(shí)現(xiàn):

ecwid 是Consul 客戶端的一種,在Pom 依賴中添加ecwid 的consul-api.通過ConsulClient 的newService 對(duì)象的構(gòu)造方法傳入注冊(cè)IP 和端口.然后設(shè)置newService對(duì)象的服務(wù)名、服務(wù)ID、服務(wù)標(biāo)簽和服務(wù)端口信息,最后調(diào)用ConsulClient.agent-ServiceRegister方法完成服務(wù)注冊(cè).

在分布式應(yīng)用場(chǎng)景中,微服務(wù)實(shí)例對(duì)于配置中心應(yīng)該具有弱依賴和稀疏變更特點(diǎn)[5],弱依賴性表示微服務(wù)與配置中心依賴性應(yīng)該降至最低,在配置中心發(fā)生故障情況下,提高系統(tǒng)容災(zāi)性.稀疏變更表示動(dòng)態(tài)配置在部署至微服務(wù)實(shí)例后,很少發(fā)生改變.而一旦發(fā)生變更,則需要配置客戶端從配置中心快速地同步和部署配置變更.

針對(duì)上述特點(diǎn),配置客戶端引入本地快照機(jī)制,將配置保存值本地文件中,提高微服務(wù)容災(zāi)性.引入本地緩存機(jī)制,將本地微服務(wù)最新配置保存至緩存中,提高微服務(wù)獲取實(shí)時(shí)配置的性能.

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

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

圖3 配置隔離示意圖

根節(jié)點(diǎn)“環(huán)境”(Environment)下包含了若干個(gè)服務(wù)組,它的配置對(duì)所有微服務(wù)共享;

節(jié)點(diǎn)“服務(wù)組”(ServiceGroup)對(duì)環(huán)境中服務(wù)按照功能特性進(jìn)行了分組,配置對(duì)組內(nèi)所有微服務(wù)及其實(shí)例共享,不同微服務(wù)組配置相互隔離;

節(jié)點(diǎn)“服務(wù)”(Service)中的配置對(duì)該服務(wù)所有實(shí)例共享,不同微服務(wù)間配置相互隔離;

節(jié)點(diǎn)“服務(wù)實(shí)例”(Instance)中存儲(chǔ)某個(gè)微服務(wù)實(shí)例配置,不同實(shí)例間配置相互隔離.

3.2 運(yùn)維監(jiān)控中心

運(yùn)維監(jiān)控中心與Java 底座中的Hystrix 組件進(jìn)行通信,獲取服務(wù)的服務(wù)質(zhì)量信息并在前端以圖表的形式顯示.

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

獲取到服務(wù)質(zhì)量數(shù)據(jù)后,對(duì)數(shù)據(jù)進(jìn)行處理,處理的內(nèi)容包括:整理數(shù)據(jù)、判斷告警狀態(tài)、生成或恢復(fù)服務(wù)質(zhì)量告警,處理完成后將服務(wù)質(zhì)量數(shù)據(jù)保存到緩存中,在每個(gè)獲取服務(wù)質(zhì)量性能數(shù)據(jù)的周期里都對(duì)此緩存進(jìn)行更新,此外,每隔5 分鐘將一次獲取到的服務(wù)質(zhì)量數(shù)據(jù)保存到數(shù)據(jù)庫(kù).當(dāng)查看指定服務(wù)實(shí)例的服務(wù)質(zhì)量數(shù)據(jù)時(shí),后臺(tái)根據(jù)用戶請(qǐng)求的參數(shù)從緩存中查找到對(duì)應(yīng)的服務(wù)質(zhì)量數(shù)據(jù)并返回給前端.

3.3 微服務(wù)底座

3.3.1 Java 微服務(wù)底座

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

服務(wù)的注冊(cè)和發(fā)現(xiàn)通過Consul 完成,考慮到服務(wù)間的通信是通過底座完成,所以需要對(duì)注冊(cè)發(fā)現(xiàn)進(jìn)行監(jiān)聽.

(1)服務(wù)注冊(cè)設(shè)計(jì)

服務(wù)需要通過根據(jù)配置文件,自動(dòng)將服務(wù)注冊(cè)到Consul.在獲取服務(wù)的時(shí)候,需要及時(shí)獲取到最新的服務(wù),在獲取服務(wù)的時(shí)候需要使用緩存,避免頻繁的和Consul 進(jìn)行調(diào)用.服務(wù)注冊(cè)和健康檢查流程如下:

1)Spring 容器啟動(dòng)的時(shí)候,讀取配置的spring.factories,對(duì)于配置的bean 進(jìn)行初始化,將Discovery AutoConfiguration 里的配置bean 進(jìn)行初始化.

2)在Spring 容器初始化完成后,會(huì)發(fā)送Context RefreshedEvent,監(jiān)聽這個(gè)Event,可以啟動(dòng)服務(wù)端,如IceServer 或者RestServer.

3)啟動(dòng)服務(wù)以后發(fā)送事件,監(jiān)聽到服務(wù)啟動(dòng)成功以后,將服務(wù)注冊(cè)到Consul.

注冊(cè)的時(shí)候,默認(rèn)注冊(cè)地址為:"http://"+服務(wù)IP+"/actuator/health",通過Actuator 組件,consul 直接向該服務(wù)發(fā)起心跳,可以得到服務(wù)的健康狀態(tài).監(jiān)控通信通過讀取數(shù)據(jù),可以判斷服務(wù)是否存活.

(2)服務(wù)發(fā)現(xiàn)設(shè)計(jì)

1)客戶端調(diào)用通過實(shí)現(xiàn)負(fù)載均衡功能的處理器上獲取服務(wù)列表,當(dāng)處理器調(diào)用Consul 獲取服務(wù)列表的時(shí)候,首先去訪問緩存,獲取當(dāng)前的緩存狀態(tài),若緩存狀態(tài)為success,則返回服務(wù)列表,若緩存狀態(tài)為False,則去Consul 上獲取最新的服務(wù)列表,并更新緩存.

2)初始化的時(shí)候啟動(dòng)Consul 監(jiān)聽任務(wù)去Consul上監(jiān)聽是否有服務(wù)的變更.

3)當(dāng)Consul 的服務(wù)發(fā)生變更以后,向緩存發(fā)送緩存失效信息,DiscoveryCache(發(fā)現(xiàn)緩存)此時(shí)設(shè)置緩存可讀狀態(tài)為False.

4)當(dāng)下次請(qǐng)求訪問到,DiscoveryCache 的時(shí)候,獲取服務(wù)列表時(shí),首先去獲取緩存可讀的狀態(tài),當(dāng)為False 的時(shí)候,直接向Consul 獲取最新的服務(wù)列表.

(3)服務(wù)RPC 調(diào)用鏈設(shè)計(jì)

微服務(wù)底座的服務(wù)治理使用調(diào)用鏈方式進(jìn)行,調(diào)用鏈?zhǔn)穷愃芐erviceComb 的Chassis 組件中的Handler.將負(fù)載均衡、熔斷等服務(wù)治理功能通過實(shí)現(xiàn)單獨(dú)的處理器來實(shí)現(xiàn),自定義選擇處理器,形成鏈?zhǔn)秸{(diào)用,從而完成服務(wù)治理.

調(diào)用鏈采用分層設(shè)計(jì),分別為API 接入層、治理層、協(xié)議層.Spring 應(yīng)用或者是網(wǎng)管客戶端通過調(diào)用接入層的API 接口引入服務(wù)治理功能,服務(wù)治理的整體結(jié)構(gòu)采用鏈?zhǔn)椒?wù),方便以后的服務(wù)治理功能的拓展,協(xié)議層封裝了客戶端發(fā)送請(qǐng)求和接收請(qǐng)求的操作.

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

治理層中業(yè)務(wù)的Handler 采取單例模式,保證每一個(gè)服務(wù)在調(diào)用鏈中的治理是獨(dú)立的.LoadBalancer 從注冊(cè)中心consul 上根據(jù)路由和負(fù)載均衡策略找出一個(gè)地址發(fā)起調(diào)用.HystrixHandler 對(duì)服務(wù)調(diào)用進(jìn)行相關(guān)統(tǒng)計(jì),然后根據(jù)統(tǒng)計(jì)數(shù)據(jù)判斷是否熔斷.熔斷指定時(shí)間后會(huì)嘗試恢復(fù).TransportClient-Handler 負(fù)責(zé)根據(jù)協(xié)議找到具體的client 然后發(fā)起調(diào)用,如BusClient.

協(xié)議層中TransportHandler 根據(jù)協(xié)議名稱選取protocol 實(shí)現(xiàn),在protocol 中通過相應(yīng)Client 發(fā)起遠(yuǎn)程調(diào)用并接收響應(yīng).

自定義容器管理ExtensionLoader,通過JavaSpi 機(jī)制實(shí)現(xiàn)一個(gè)自定義容器.同步調(diào)用方式中DefaultMethod Interceptor 將相關(guān)參數(shù)封裝為請(qǐng)求,經(jīng)過Handler 鏈處理,使用對(duì)應(yīng)Protocol 將請(qǐng)求發(fā)送出去,將當(dāng)前線程阻塞在控制器,服務(wù)端有響應(yīng)后通知解除阻塞.

3.3.2 C++微服務(wù)底座

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

CppChassis RPC 調(diào)用流程圖如圖4 所示.

圖4 RPC 調(diào)用流程圖

C++網(wǎng)管微服務(wù)調(diào)用其他C++網(wǎng)管服務(wù)時(shí),在CppChassis 里面會(huì)將調(diào)用過程分為3 個(gè)步驟:

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

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

(3)After Invoke:該調(diào)用是將調(diào)用結(jié)果通過Cpp-Chassis 反饋給SideCar,用于服務(wù)治理相關(guān)信息的收集.

3.3.3 邊車

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

邊車負(fù)責(zé)進(jìn)行控制,提供負(fù)載均衡,容錯(cuò)控制,熔斷控制,健康檢查等功能,服務(wù)間實(shí)際的遠(yuǎn)程調(diào)用由服務(wù)自己完成.

(1)邊車的注冊(cè)設(shè)計(jì)

項(xiàng)目啟動(dòng)的時(shí)候通過SPI 機(jī)制啟動(dòng)掃描類,掃描環(huán)境變量C++服務(wù)對(duì)應(yīng)的路徑下的yml,過濾出所有yml 格式的文件分別批量注冊(cè).注冊(cè)完畢后運(yùn)維監(jiān)控中心發(fā)送注冊(cè)通知,等待邊車返回健康檢查數(shù)據(jù).

(2)邊車的健康檢查設(shè)計(jì)

邊車的健康檢查通過調(diào)用C++微服務(wù)底座健康檢查接口實(shí)現(xiàn),consul 的心跳檢查會(huì)通過邊車調(diào)用C++接口完成數(shù)據(jù)采集.

(3)邊車的RPC 調(diào)用設(shè)計(jì)

邊車提供了兩個(gè)方法:BeforeInvoke,AfterInvoke;C++服務(wù)在發(fā)起遠(yuǎn)程調(diào)用前,先從BeforeInvoke 方法獲取服務(wù)實(shí)例,調(diào)用完成后再用AfterInvoke 方法通知邊車調(diào)用結(jié)束,以及調(diào)用的結(jié)果.

BeforeInvoke 方法中,邊車會(huì)創(chuàng)建一個(gè)Handler 鏈,與Java 底座實(shí)現(xiàn)類似.

LoadBalanceHandler 負(fù)責(zé)負(fù)載均衡功能和容錯(cuò)功能,HystrixHandler 負(fù)載熔斷控制和服務(wù)質(zhì)量統(tǒng)計(jì),從而與Java 底座使用同樣方式實(shí)現(xiàn)服務(wù)治理.

AfterInvoke 方法會(huì)把遠(yuǎn)程調(diào)用結(jié)果通知給對(duì)應(yīng)的處理器Handler,從而完成服務(wù)調(diào)用監(jiān)控.

4 系統(tǒng)測(cè)試

4.1 系統(tǒng)功能測(cè)試

由于平臺(tái)設(shè)計(jì)中,主要功能是對(duì)服務(wù)的監(jiān)控和發(fā)布,通過查看對(duì)服務(wù)的監(jiān)控,可以測(cè)試平臺(tái)的監(jiān)控能力和底座的承載能力.

當(dāng)平臺(tái)檢查到服務(wù)時(shí),會(huì)在頁(yè)面上展示服務(wù)監(jiān)控?cái)?shù)據(jù),服務(wù)監(jiān)控情況如圖5 所示.需要了解異常服務(wù)詳情時(shí),使用監(jiān)控可以了解具體的服務(wù)IP 和端口以及健康檢查端口返回的元數(shù)據(jù),異常服務(wù)詳情如圖6 所示.

圖5 服務(wù)監(jiān)控圖

圖6 異常服務(wù)詳情

4.2 性能測(cè)試

系統(tǒng)性能測(cè)試主要分為兩個(gè)部分,第一部分為采用微服務(wù)架構(gòu)的服務(wù)較原有架構(gòu)服務(wù)的性能提升,另一部分為原有服務(wù)采用微服務(wù)底座承載之后性能劣化是否在20%以內(nèi).

本文采用Apache Bench 模擬100 個(gè)用戶對(duì)微服務(wù)發(fā)出訪問請(qǐng)求,分析內(nèi)存占用情況如圖7 所示,其中上方虛線表示傳統(tǒng)單架構(gòu)服務(wù)的內(nèi)存占用,下方實(shí)線表示采用本文微服務(wù)底座的服務(wù)內(nèi)存占用.橫軸表示請(qǐng)求發(fā)出后服務(wù)運(yùn)行時(shí)間(s),縱軸表示內(nèi)存占用大小(MB).

對(duì)于原有C++語言開發(fā)的服務(wù),由于RPC 操作通過邊車進(jìn)行,每次調(diào)用服務(wù)在原有調(diào)用邏輯上增加了BeforeInvoke 和AfterInvoke 操作,可能會(huì)造成性能劣化,通過模擬調(diào)用同一接口多次,得到調(diào)用時(shí)間如表1所示.

圖7 內(nèi)存占用對(duì)比圖

表1 多次調(diào)用C++接口響應(yīng)時(shí)間對(duì)比分析

可以看出,在高并發(fā)情況下,采用本文微服務(wù)架構(gòu)的服務(wù)內(nèi)存占用較傳統(tǒng)架構(gòu)服務(wù)有著明顯優(yōu)勢(shì),并且內(nèi)存占用變化更為平穩(wěn).

從表中可以看出,原有C++服務(wù)通過引入底座模塊后,RPC 調(diào)用耗時(shí)有所增加,但劣化范圍在12%左右,在期望范圍之內(nèi).

通過將不同語言語言開發(fā)的服務(wù)置于不同的底座之中,統(tǒng)一交由平臺(tái)監(jiān)控管理,對(duì)于微服務(wù)的并發(fā)環(huán)境下內(nèi)存占用,由于使用基于SpringCloud Robbin 的負(fù)載均衡組件,使得服務(wù)更加平穩(wěn)且內(nèi)存占用更小,對(duì)于C++服務(wù),在引入C++底座和邊車后被改造為微服務(wù),使其具有了服務(wù)治理的功能,在RPC 調(diào)用時(shí)性能略有下降但無明顯劣化.

5 結(jié)束語

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