馬 永,李 明,曹彎彎,張 弛,王 靚,李 婕

1(國(guó)網(wǎng)安徽省電力有限公司 信息通信分公司,合肥 230061)

2(南京南瑞信息通信科技有限公司,南京 210009)

電網(wǎng)信息通信運(yùn)維系統(tǒng)是支撐電網(wǎng)安全穩(wěn)定運(yùn)行的基礎(chǔ)性資源,是電力系統(tǒng)的重要組成部分[1,2].隨著電網(wǎng)安全生產(chǎn)的可靠性要求不斷提高,現(xiàn)有系統(tǒng)保障系統(tǒng)安全穩(wěn)定運(yùn)行的難度也顯著增加,當(dāng)前運(yùn)維系統(tǒng)也存在了硬件平臺(tái)超期服役,性能難以應(yīng)對(duì)越來(lái)越繁重的信息處理任務(wù)等問(wèn)題[3,4].因此利用新興技術(shù)對(duì)現(xiàn)有系統(tǒng)進(jìn)行升級(jí)改造十分有必要.

目前云計(jì)算已經(jīng)是一種相當(dāng)成熟穩(wěn)定的技術(shù)[5,6],云平臺(tái)具有業(yè)務(wù)上線快、運(yùn)維高度自動(dòng)化、高可靠性、功能豐富、低成本等優(yōu)點(diǎn),已經(jīng)被廣泛應(yīng)用于信息運(yùn)維系統(tǒng)的構(gòu)建和改造.因此,將電網(wǎng)信息通信運(yùn)維系統(tǒng)遷移至云平臺(tái)是安全可靠且經(jīng)濟(jì)實(shí)惠的最優(yōu)方案,該方案也得到了許多行業(yè)的應(yīng)用證明,例如利用政務(wù)云平臺(tái)實(shí)現(xiàn)的政務(wù)信息系統(tǒng)上云[7,8]和利用阿里云平臺(tái)實(shí)現(xiàn)的企業(yè)信息系統(tǒng)上云[9,10]等.但是系統(tǒng)上云后,應(yīng)用服務(wù)從集中式應(yīng)用轉(zhuǎn)化為分布式系統(tǒng),分布式架構(gòu)中會(huì)存在系統(tǒng)各部分之間的可靠調(diào)用問(wèn)題,這會(huì)阻礙系統(tǒng)上云后的穩(wěn)定運(yùn)行[11].

因此,本文針對(duì)集中式系統(tǒng)遷移上云后轉(zhuǎn)變?yōu)榉植际较到y(tǒng)的管理問(wèn)題,提出一種基于SpringCould 框架的微服務(wù)應(yīng)用系統(tǒng)遷移上云改造模型,將系統(tǒng)服務(wù)全部遷入企業(yè)級(jí)分布式應(yīng)用服務(wù)(Enterprise Distributed Application Service,EDAS)體系,使系統(tǒng)能夠充分利用EDAS 的應(yīng)用部署管控能力和微服務(wù)治理能力,實(shí)現(xiàn)一鍵部署、彈性伸縮、灰度發(fā)布以及故障自愈.并針對(duì)系統(tǒng)上云過(guò)程中數(shù)據(jù)量龐大的一致性校驗(yàn)問(wèn)題,設(shè)計(jì)了一種基于吉布斯采樣的數(shù)據(jù)一致性采樣校驗(yàn)方法,提高了數(shù)據(jù)一致性校驗(yàn)的效率,減少了系統(tǒng)上云工作量.

1 系統(tǒng)檢測(cè)

1.1 SpringCould 框架

Spring Cloud 是基于Spring Boot 框架的一系列微服務(wù)解決方案的有序集成[12].它將市面上各家公司開發(fā)的比較成熟的服務(wù)框架進(jìn)行集合,再利用Spring Boot 的開發(fā)風(fēng)格進(jìn)行再封裝,開發(fā)者無(wú)需再去了解各個(gè)服務(wù)框架的配置和實(shí)現(xiàn)原理,只需按照Spring Cloud所給出的分布式系統(tǒng)開發(fā)工具包就可以實(shí)現(xiàn)分布式系統(tǒng)基礎(chǔ)設(shè)施的開發(fā),簡(jiǎn)化了代碼量和工作量,這也是本模型選取該框架的原因.

Spring Cloud 可以實(shí)現(xiàn)微服務(wù)開發(fā)所需要的分布式/版本化設(shè)置,分布式消息傳遞,服務(wù)的注冊(cè)和發(fā)現(xiàn),服務(wù)之間的調(diào)用,負(fù)載均衡,集群狀態(tài)管理,智能路由和斷路器等功能[13],其組件架構(gòu)如圖1所示.

圖1 微服務(wù)框架

1.2 EDAS 體系

企業(yè)級(jí)分布式應(yīng)用服務(wù)是一個(gè)以阿里中間件團(tuán)隊(duì)的多個(gè)組件產(chǎn)品為核心基礎(chǔ)組建的應(yīng)用托管和微服務(wù)管理的PaaS 平臺(tái)[14].它利用阿里云現(xiàn)有的各種資源和服務(wù),引用整套分布式計(jì)算框架,提供應(yīng)用的開發(fā)、部署、運(yùn)行、監(jiān)控和維護(hù)等全棧式解決方案,同時(shí),它支持SpringCloud 在內(nèi)的三大主流微服務(wù)運(yùn)行框架,可以幫助企業(yè)級(jí)用戶實(shí)現(xiàn)各種云計(jì)算解決方案和應(yīng)用上云.

將系統(tǒng)服務(wù)全部遷入EDAS 體系可以使系統(tǒng)充分利用EDAS 的應(yīng)用部署管控能力和微服務(wù)治理能力,實(shí)現(xiàn)一鍵部署、彈性伸縮、灰度發(fā)布以及故障自愈等功能.同時(shí),通過(guò)服務(wù)接口可視化,服務(wù)綜合治理和配置推送集中管理,EDAS 十分適合作為分布式應(yīng)用服務(wù)的解決方案.

1.3 吉布斯采樣法

吉布斯采樣法(Gibbs sampling)是馬爾可夫鏈與蒙特卡洛算法(Markov Chain Monte Carlo,MCMC)中的一種,不同于均勻分布采樣和離散分布采樣,它能夠在無(wú)法直接采樣的情況下從多變量概率分布中抽取近似于其分布的隨機(jī)樣本序列.

由平穩(wěn)馬爾可夫過(guò)程的結(jié)論可知,只要馬爾科夫鏈?zhǔn)諗?第n次的抽樣概率p(xn)一定會(huì)收斂到預(yù)期分布p(x);如果非周期馬爾科夫鏈的狀態(tài)轉(zhuǎn)移矩陣P和概率分布π (x)對(duì)于所有的i,j滿足:

則稱概率分布π (x)是狀態(tài)轉(zhuǎn)移矩陣P的平穩(wěn)分布.因此構(gòu)造一個(gè)轉(zhuǎn)移矩陣為P的馬爾科夫鏈,那么從任一初始狀態(tài)x0出發(fā)沿馬爾科夫鏈轉(zhuǎn)移,如果馬爾科夫鏈在第n步已收斂,則達(dá)到了平穩(wěn)狀態(tài),以后的樣本必然都滿足p(x)分布,都可以用于生成待模擬分布的樣本[15].

為了使細(xì)致平穩(wěn)條件成立,MCMC 算法的最終轉(zhuǎn)移矩陣P為:

目標(biāo)矩陣P可以通過(guò)任意馬爾科夫鏈狀態(tài)轉(zhuǎn)移矩陣Q乘以 α(i,j)得 到,α (i,j)為接受率,其取值區(qū)間為[0,1].但在高維的情況下,α?xí)?dǎo)致算法效率不高,因此需要一個(gè)轉(zhuǎn)移矩陣Q使得α=1.在數(shù)據(jù)為二維時(shí),假設(shè)概率分布p(x,y),平面上存在x坐標(biāo)相同的兩個(gè)點(diǎn)A(x1,y1),B(x1,y2),則吉布斯采樣法按照式(3)～式(5)構(gòu)造兩點(diǎn)之間的轉(zhuǎn)移概率矩陣Q[15].

2 遷移上云改造模型

2.1 模型建立

微服務(wù)應(yīng)用系統(tǒng)框架主要包括服務(wù)注冊(cè)、統(tǒng)一配置服務(wù)、服務(wù)網(wǎng)關(guān)和微服務(wù)4 大模塊,需要將Spring Cloud 框架中的模塊適配改造為EDAS 體系中對(duì)應(yīng)組件,所提出的微服務(wù)應(yīng)用系統(tǒng)遷移改造模型如圖2所示.

圖2 微服務(wù)遷移改造模型

SpringCloud 架構(gòu)中服務(wù)注冊(cè)發(fā)現(xiàn)模塊Netflix Eureka 和統(tǒng)一配置服務(wù)模塊Config Server 遷移至EDAS后需進(jìn)行改造,而由于EDAS 體系兼容適配SpringCloud框架中服務(wù)網(wǎng)關(guān)和微服務(wù)所使用的Netflix Zuul 和Springboot 模塊,因此這兩個(gè)模塊只需要根據(jù)微服務(wù)應(yīng)用的實(shí)際情況,遷移至EDAS 中對(duì)應(yīng)的模塊即可.

EDAS 中微服務(wù)模塊并沒(méi)有直接部署在云主機(jī)ECS (Elastic Compute Service)上,而是部署于容器服務(wù)K8S 集群上.遷移后的微服務(wù)模塊包含工具應(yīng)用層和平臺(tái)組件服務(wù)層兩個(gè)層.工具應(yīng)用層由調(diào)運(yùn)檢運(yùn)維管理類微應(yīng)用、自動(dòng)化作業(yè)類微應(yīng)用和個(gè)性化自建微應(yīng)用構(gòu)成,平臺(tái)組件服務(wù)層由資源配置服務(wù)、資源檢測(cè)服務(wù)、作業(yè)管理服務(wù)等各種平臺(tái)所需的服務(wù)構(gòu)成,如圖3所示.

圖3 EDAS 微服務(wù)Springboot 框架

在EDAS 中,設(shè)有專門的應(yīng)用部署管控模塊和微服務(wù)治理模塊,它們負(fù)責(zé)對(duì)遷移的4 個(gè)模塊進(jìn)行治理和管控,并和遷移的4 個(gè)組件均受到業(yè)務(wù)實(shí)時(shí)監(jiān)控服務(wù)(ARMS)的統(tǒng)一監(jiān)控.

2.2 模型適配改造

EDAS 體系雖然兼容SpringCloud 框架,但是兩者在實(shí)際應(yīng)用中存在著些許不同,需要對(duì)服務(wù)注冊(cè)發(fā)現(xiàn)模塊和微服務(wù)模塊進(jìn)行適配性改造,使其對(duì)接EDAS體系中對(duì)應(yīng)組件,能夠融入EDAS 生命周期管理和應(yīng)用監(jiān)控體系,實(shí)現(xiàn)應(yīng)用的全鏈路監(jiān)控.

2.2.1 服務(wù)注冊(cè)發(fā)現(xiàn)模塊適配改造

服務(wù)注冊(cè)發(fā)現(xiàn)模塊Netflix Eureka,需適配改造使用ANS (Alibaba Naming Service)組件.ANS 支持Spring Cloud 應(yīng)用的服務(wù)注冊(cè)與發(fā)現(xiàn),同時(shí)默認(rèn)集成了負(fù)載均衡組件Ribbon,Eureka 用戶可以通過(guò)替換maven 項(xiàng)目中pom.xml 文件中的依賴實(shí)現(xiàn)無(wú)縫遷移.

服務(wù)注冊(cè)模塊需要服務(wù)提供者與服務(wù)消費(fèi)者,服務(wù)提供者適配改造之后使用ANS 進(jìn)行服務(wù)注冊(cè)發(fā)現(xiàn)的算法如算法1 所示.

算法1.ANS 服務(wù)提供者算法1)創(chuàng)建SpringCloud 工程service-provider,在pom.xml 中引入需要的依賴內(nèi)容;2)編碼服務(wù)提供端的啟動(dòng)類(利用@Enable DiscoveryClient 注解表明此應(yīng)用需開啟服務(wù)注冊(cè)與發(fā)現(xiàn)功能);3)提供服務(wù);4)配置阿里云賬號(hào)的AccessKey、SecretKey,以及EDAS 的命名空間信息;5)啟動(dòng)service-provider 服務(wù),在EDAS 頁(yè)面查看服務(wù)注冊(cè)信息.

服務(wù)消費(fèi)者適配改造之后使用ANS 進(jìn)行服務(wù)注冊(cè)發(fā)現(xiàn)的算法如算法2 所示.其中RestTemplate、AsyncRestTemplate 和FeignClient 為實(shí)際服務(wù)調(diào)用中最常使用的3 個(gè)客戶端.

算法2.ANS 服務(wù)消費(fèi)者算法1)創(chuàng)建SpringCloud 工程service-consumer,在pom.xml 中引入需要的依賴內(nèi)容;2)配置RestTemplate、AsyncRestTemplate 和Feign Client;3)創(chuàng)建Controller,驗(yàn)證服務(wù)發(fā)現(xiàn)功能;4)添加應(yīng)用基本配置和阿里云AK、SK 以及EDAS 的namespace;5)啟動(dòng)服務(wù),查看EDAS 控制臺(tái),查詢服務(wù),查看服務(wù)注冊(cè)是否成功.

2.2.2 統(tǒng)一配置服務(wù)模塊適配改造

圖4 ACM 配置管理

管理員只需在控制臺(tái)上進(jìn)行配置更改,更改之后的配置信息就可以快速自動(dòng)被推送到ACM 后端的服務(wù)器集群中,并在秒級(jí)延遲內(nèi)在各個(gè)ACM 客戶端的應(yīng)用中生效.利用ACM 可以在微服務(wù)中極大減輕配置管理的工作量,同時(shí)增強(qiáng)配置管理的服務(wù)能力.

適配改造完成后,系統(tǒng)各模塊均納入EDAS 的應(yīng)用部署管控中,充分利用EDAS 的應(yīng)用生命周期管理和微服務(wù)治理機(jī)制,實(shí)現(xiàn)云上應(yīng)用的一鍵部署、彈性伸縮、灰度發(fā)布以及故障自愈等功能.

2.3 模型檢驗(yàn)

當(dāng)完成系統(tǒng)上云之后,為了保證系統(tǒng)數(shù)據(jù)的完整性和正確性,需要對(duì)數(shù)據(jù)進(jìn)行一致性檢驗(yàn),雖然可以利用數(shù)據(jù)庫(kù)遷移工具在遷移任務(wù)結(jié)束后進(jìn)行數(shù)據(jù)校驗(yàn),但由于系統(tǒng)數(shù)據(jù)量過(guò)大或會(huì)遇到增量遷移的情況,對(duì)全部遷移數(shù)據(jù)進(jìn)行校驗(yàn)會(huì)使工作總量十分巨大,因此需要對(duì)數(shù)據(jù)進(jìn)行采樣,通過(guò)采樣數(shù)據(jù)的校驗(yàn)結(jié)果判斷遷移數(shù)據(jù)的正確性.由于遷移數(shù)據(jù)為多維數(shù)據(jù),且數(shù)據(jù)之間存在關(guān)聯(lián),數(shù)據(jù)的期望和樣本概率也很難計(jì)算,本文采用吉布斯采樣方法對(duì)遷移數(shù)據(jù)進(jìn)行采樣,再對(duì)采樣數(shù)據(jù)進(jìn)行一致性校驗(yàn).

假設(shè)源數(shù)據(jù)庫(kù)中的遷移數(shù)據(jù)為X={X1,X2,···,Xm},Xi={xi1,xi2,···,xin},遷移完成后云上的數(shù)據(jù)為Y={Y1,Y2,···,Ym},Yi={Yi1,Yi2,···,Yin},偽代碼如算法3 所示.

算法3.數(shù)據(jù)采樣校驗(yàn)算法1)對(duì)于源數(shù)據(jù)集X 隨機(jī)選擇維度i(i=1,···,m).2)for t=1,···,T for j=1,···,n X(t+1)j ～p(Xj|X(t+1)1,···,X(t+1)j?1,X(t)j+1,···,X(t)m )循環(huán)采樣得到采樣數(shù)據(jù)集,完成源數(shù)據(jù)集采樣.B={b1,···,bnum}A={a1,···,anum}3)在Y 中選取與采樣數(shù)據(jù)集A 所對(duì)應(yīng)的采樣數(shù)據(jù)集,完成云上數(shù)據(jù)集采樣.4)flag=1 for i=1,···,num aibi if flag=0,記錄錯(cuò)誤數(shù)據(jù)對(duì)應(yīng)的位置;break;5)if flag=0數(shù)據(jù)遷移出現(xiàn)錯(cuò)誤,檢查并修正錯(cuò)誤數(shù)據(jù)所在數(shù)據(jù)表,之后轉(zhuǎn)至6).else 數(shù)據(jù)遷移數(shù)據(jù)無(wú)誤,一致性檢驗(yàn)完成.6)再次執(zhí)行1)～5)操作,直至flag=1.

3 實(shí)驗(yàn)驗(yàn)證

本文以國(guó)網(wǎng)安徽電力SG-I6000 微服務(wù)系統(tǒng)為例,系統(tǒng)遷移改造至阿里云,改造為EDAS 體系,系統(tǒng)數(shù)據(jù)通過(guò)一致性檢驗(yàn)后,測(cè)試實(shí)驗(yàn)上云系統(tǒng)的一鍵部署、彈性伸縮、灰度發(fā)布以及故障自愈能力.SG-I6000 微服務(wù)系統(tǒng)是在I6000 系統(tǒng)傳統(tǒng)構(gòu)架版本基礎(chǔ)上,對(duì)平臺(tái)應(yīng)用模塊進(jìn)行微服務(wù)化改造后的版本.該系統(tǒng)采用主流的SpringCloud 框架,在開源K8S 環(huán)境中進(jìn)行過(guò)運(yùn)行檢測(cè),具備遷移改造上云的基礎(chǔ).

3.1 數(shù)據(jù)一致性檢驗(yàn)

系統(tǒng)服務(wù)遷移至阿里云的過(guò)程中,采用吉布斯采樣方法對(duì)遷移數(shù)據(jù)進(jìn)行采樣,減少校驗(yàn)數(shù)據(jù)量,提高系統(tǒng)遷移速率.針對(duì)采樣得到的數(shù)據(jù),進(jìn)行數(shù)據(jù)一致性的檢驗(yàn).為驗(yàn)證模型檢驗(yàn)方法的可行性,對(duì)遷移數(shù)據(jù)中的一部分,使用MySQL 中的pt-table-checksum 命令進(jìn)行完整的數(shù)據(jù)一致性檢驗(yàn)作為對(duì)比實(shí)驗(yàn).測(cè)試數(shù)據(jù)庫(kù)大小分別為186.75 GB、293.72 GB 和483.6 GB,分別進(jìn)行采樣一致性檢驗(yàn)和完整一致性檢驗(yàn),并經(jīng)過(guò)采樣檢驗(yàn)糾錯(cuò)后,在通過(guò)完整的數(shù)據(jù)一致性檢驗(yàn)檢驗(yàn)采樣檢驗(yàn)的正確率,實(shí)驗(yàn)結(jié)果如表1所示.

表1 數(shù)據(jù)一致性檢驗(yàn)實(shí)驗(yàn)

測(cè)試結(jié)果表明,模型采樣檢驗(yàn)方法準(zhǔn)確率很高,經(jīng)糾錯(cuò)后,數(shù)據(jù)準(zhǔn)確高達(dá)99.97%以上,證明了模型檢驗(yàn)方法的可行性.

“中文屋”論證比盧卡斯等人的論證所展示的內(nèi)容要深刻得多，它揭示了純粹的形式系統(tǒng)之所以不完全的原因，也就是它的形式符號(hào)操作之于理解而言并不充分，究其原因是句法和語(yǔ)義彼此完全獨(dú)立且語(yǔ)義并非句法的固有屬性，語(yǔ)義只能被賦予，這就使得任何基于規(guī)則的純粹形式符號(hào)操作都不可能產(chǎn)生理解，這也就是人類心智優(yōu)于機(jī)器的根本原因。

3.2 一鍵部署驗(yàn)證

一鍵部署功能的驗(yàn)證主要包括兩個(gè)場(chǎng)景,一是使用EDAS 在K8S 集群中使用鏡像的方式來(lái)部署新應(yīng)用,部署界面如圖5所示.

另一個(gè)是驗(yàn)證EDAS 對(duì)應(yīng)用版本更新的部署,部署方式包括單批發(fā)布和分批發(fā)布兩種方式,界面如圖6所示.

經(jīng)過(guò)測(cè)試驗(yàn)證,在上述兩個(gè)應(yīng)用部署場(chǎng)景下,均能夠使用EDAS 控制臺(tái)部署應(yīng)用程序和配置參數(shù),實(shí)現(xiàn)一鍵部署功能.

3.3 彈性伸縮驗(yàn)證

彈性伸縮功能的測(cè)試包括手動(dòng)伸縮和自動(dòng)伸縮功能測(cè)試.手動(dòng)伸縮是通過(guò)EDAS 控制臺(tái)手動(dòng)設(shè)置應(yīng)用的實(shí)例數(shù)目,適用于提前預(yù)知業(yè)務(wù)量的場(chǎng)景,譬如在月初報(bào)表類業(yè)務(wù)驟增,可以手動(dòng)調(diào)制報(bào)表類應(yīng)用實(shí)例數(shù)目.自動(dòng)伸縮通過(guò)設(shè)置容器服務(wù)K8S 的容器組水平伸縮器配置伸縮策略,實(shí)現(xiàn)自動(dòng)調(diào)制應(yīng)用實(shí)例數(shù)目.自動(dòng)伸縮適合業(yè)務(wù)量不確定或者頻繁變動(dòng)的應(yīng)用場(chǎng)景,實(shí)現(xiàn)按需分配計(jì)算資源.

圖6 EDAS 部署應(yīng)用版本更新

伸縮策略設(shè)置最大容器數(shù)量為8,最小容器數(shù)量為2,伸縮指標(biāo)設(shè)置為50%的CPU 使用量.使用壓力測(cè)試工具Jmeter 對(duì)服務(wù)進(jìn)行壓力測(cè)試,持續(xù)100 個(gè)并發(fā).

壓力測(cè)試開始后,CPU 使用率持續(xù)上升,容器副本數(shù)量自動(dòng)調(diào)節(jié)增加;壓力測(cè)試停止后,CPU 使用率下降,系統(tǒng)自動(dòng)釋放擴(kuò)容的容器副本.某實(shí)例中CPU 使用量在壓力測(cè)試前后的監(jiān)控曲線如圖7所示.

圖7 CPU 監(jiān)控曲線

在壓力測(cè)試初期,CPU 使用量提高,副本容器擴(kuò)容至4 個(gè).隨著CPU 使用量逐漸提高至滿載,副本容量擴(kuò)容至上限數(shù)量8 個(gè).等到壓力測(cè)試結(jié)束,CPU 使用量大幅度下降,副本容器被釋放至數(shù)量下限2 個(gè).

3.4 基于容器服務(wù)的灰度發(fā)布驗(yàn)證

通過(guò)容器服務(wù)對(duì)灰度發(fā)布能力進(jìn)行驗(yàn)證,在EDAS中發(fā)布應(yīng)用的不同版本,使用容器服務(wù)中的路由規(guī)則設(shè)置灰度流量規(guī)則,根據(jù)Cookie 值控制流量路由.請(qǐng)求服務(wù)時(shí),服務(wù)器根據(jù)Cookie 值將流量路由至對(duì)應(yīng)版本的應(yīng)用.灰度發(fā)布策略設(shè)置如圖8所示,設(shè)置v2 版本應(yīng)用匹配Cookie 名稱為version,匹配值為v2.當(dāng)Cookie 值匹配時(shí),服務(wù)將被路由至v2 版本應(yīng)用,否則將路由至v1 版本.

圖8 CPU EDAS 灰度發(fā)布設(shè)置

測(cè)試設(shè)置應(yīng)用服務(wù)返回對(duì)應(yīng)的版本號(hào),測(cè)試結(jié)果如圖9所示.測(cè)試中請(qǐng)求服務(wù)都獲得了正確的應(yīng)用版本號(hào),驗(yàn)證了系統(tǒng)的灰度發(fā)布功能.

圖9 EDAS 灰度發(fā)布測(cè)試

3.5 故障自愈能力驗(yàn)證

當(dāng)容器服務(wù)工作節(jié)點(diǎn)發(fā)生宕機(jī),容器實(shí)例自動(dòng)漂移至其他工作節(jié)點(diǎn),實(shí)現(xiàn)故障自愈.通過(guò)強(qiáng)制關(guān)閉容器服務(wù)K8S 集群的一個(gè)工作節(jié)點(diǎn)來(lái)模擬節(jié)點(diǎn)宕機(jī),驗(yàn)證運(yùn)行在該節(jié)點(diǎn)上的應(yīng)用實(shí)例是否遷移至其他節(jié)點(diǎn)并正常運(yùn)行,實(shí)驗(yàn)結(jié)果如圖10所示.

圖10 實(shí)例漂移測(cè)試(方框中為節(jié)點(diǎn)ID)

運(yùn)行于強(qiáng)制關(guān)閉節(jié)點(diǎn)中的應(yīng)用實(shí)例成功漂移至其他工作節(jié)點(diǎn)并正常工作提供服務(wù),驗(yàn)證了EDAS 的故障自愈能力.

4 結(jié)論與展望

針對(duì)當(dāng)前電網(wǎng)信息通信運(yùn)維系統(tǒng)存在的種種問(wèn)題,本文提出了一種基于SpringCould 框架的微服務(wù)應(yīng)用系統(tǒng)遷移上云改造模型,將電網(wǎng)信息通信運(yùn)維系統(tǒng)遷移至云平臺(tái),將系統(tǒng)服務(wù)全部遷入EDAS 體系,使用吉布斯采樣法采樣檢驗(yàn)數(shù)據(jù)一致性,實(shí)現(xiàn)一鍵部署、彈性伸縮、灰度發(fā)布以及故障自愈.之后,通過(guò)國(guó)網(wǎng)安徽電力SG-I6000 微服務(wù)系統(tǒng)上云的實(shí)際案例,證明了系統(tǒng)的成功上云和可靠運(yùn)行.