微服務應用系統遷移上云改造模型①

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

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

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

電網信息通信運維系統是支撐電網安全穩定運行的基礎性資源,是電力系統的重要組成部分[1,2].隨著電網安全生產的可靠性要求不斷提高,現有系統保障系統安全穩定運行的難度也顯著增加,當前運維系統也存在了硬件平臺超期服役,性能難以應對越來越繁重的信息處理任務等問題[3,4].因此利用新興技術對現有系統進行升級改造十分有必要.

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

因此,本文針對集中式系統遷移上云后轉變為分布式系統的管理問題,提出一種基于SpringCould 框架的微服務應用系統遷移上云改造模型,將系統服務全部遷入企業級分布式應用服務(Enterprise Distributed Application Service,EDAS)體系,使系統能夠充分利用EDAS 的應用部署管控能力和微服務治理能力,實現一鍵部署、彈性伸縮、灰度發布以及故障自愈.并針對系統上云過程中數據量龐大的一致性校驗問題,設計了一種基于吉布斯采樣的數據一致性采樣校驗方法,提高了數據一致性校驗的效率,減少了系統上云工作量.

1 系統檢測

1.1 SpringCould 框架

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

Spring Cloud 可以實現微服務開發所需要的分布式/版本化設置,分布式消息傳遞,服務的注冊和發現,服務之間的調用,負載均衡,集群狀態管理,智能路由和斷路器等功能[13],其組件架構如圖1所示.

圖1 微服務框架

1.2 EDAS 體系

企業級分布式應用服務是一個以阿里中間件團隊的多個組件產品為核心基礎組建的應用托管和微服務管理的PaaS 平臺[14].它利用阿里云現有的各種資源和服務,引用整套分布式計算框架,提供應用的開發、部署、運行、監控和維護等全棧式解決方案,同時,它支持SpringCloud 在內的三大主流微服務運行框架,可以幫助企業級用戶實現各種云計算解決方案和應用上云.

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

1.3 吉布斯采樣法

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

由平穩馬爾可夫過程的結論可知,只要馬爾科夫鏈收斂,第n次的抽樣概率p(xn)一定會收斂到預期分布p(x);如果非周期馬爾科夫鏈的狀態轉移矩陣P和概率分布π (x)對于所有的i,j滿足:

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

為了使細致平穩條件成立,MCMC 算法的最終轉移矩陣P為:

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

2 遷移上云改造模型

2.1 模型建立

微服務應用系統框架主要包括服務注冊、統一配置服務、服務網關和微服務4 大模塊,需要將Spring Cloud 框架中的模塊適配改造為EDAS 體系中對應組件,所提出的微服務應用系統遷移改造模型如圖2所示.

圖2 微服務遷移改造模型

SpringCloud 架構中服務注冊發現模塊Netflix Eureka 和統一配置服務模塊Config Server 遷移至EDAS后需進行改造,而由于EDAS 體系兼容適配SpringCloud框架中服務網關和微服務所使用的Netflix Zuul 和Springboot 模塊,因此這兩個模塊只需要根據微服務應用的實際情況,遷移至EDAS 中對應的模塊即可.

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

圖3 EDAS 微服務Springboot 框架

在EDAS 中,設有專門的應用部署管控模塊和微服務治理模塊,它們負責對遷移的4 個模塊進行治理和管控,并和遷移的4 個組件均受到業務實時監控服務(ARMS)的統一監控.

2.2 模型適配改造

EDAS 體系雖然兼容SpringCloud 框架,但是兩者在實際應用中存在著些許不同,需要對服務注冊發現模塊和微服務模塊進行適配性改造,使其對接EDAS體系中對應組件,能夠融入EDAS 生命周期管理和應用監控體系,實現應用的全鏈路監控.

2.2.1 服務注冊發現模塊適配改造

服務注冊發現模塊Netflix Eureka,需適配改造使用ANS (Alibaba Naming Service)組件.ANS 支持Spring Cloud 應用的服務注冊與發現,同時默認集成了負載均衡組件Ribbon,Eureka 用戶可以通過替換maven 項目中pom.xml 文件中的依賴實現無縫遷移.

服務注冊模塊需要服務提供者與服務消費者,服務提供者適配改造之后使用ANS 進行服務注冊發現的算法如算法1 所示.

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

服務消費者適配改造之后使用ANS 進行服務注冊發現的算法如算法2 所示.其中RestTemplate、AsyncRestTemplate 和FeignClient 為實際服務調用中最常使用的3 個客戶端.

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

2.2.2 統一配置服務模塊適配改造

圖4 ACM 配置管理

管理員只需在控制臺上進行配置更改,更改之后的配置信息就可以快速自動被推送到ACM 后端的服務器集群中,并在秒級延遲內在各個ACM 客戶端的應用中生效.利用ACM 可以在微服務中極大減輕配置管理的工作量,同時增強配置管理的服務能力.

適配改造完成后,系統各模塊均納入EDAS 的應用部署管控中,充分利用EDAS 的應用生命周期管理和微服務治理機制,實現云上應用的一鍵部署、彈性伸縮、灰度發布以及故障自愈等功能.

2.3 模型檢驗

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

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

算法3.數據采樣校驗算法1)對于源數據集X 隨機選擇維度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 )循環采樣得到采樣數據集,完成源數據集采樣.B={b1,···,bnum}A={a1,···,anum}3)在Y 中選取與采樣數據集A 所對應的采樣數據集,完成云上數據集采樣.4)flag=1 for i=1,···,num aibi if flag=0,記錄錯誤數據對應的位置;break;5)if flag=0數據遷移出現錯誤,檢查并修正錯誤數據所在數據表,之后轉至6).else 數據遷移數據無誤,一致性檢驗完成.6)再次執行1)～5)操作,直至flag=1.

3 實驗驗證

本文以國網安徽電力SG-I6000 微服務系統為例,系統遷移改造至阿里云,改造為EDAS 體系,系統數據通過一致性檢驗后,測試實驗上云系統的一鍵部署、彈性伸縮、灰度發布以及故障自愈能力.SG-I6000 微服務系統是在I6000 系統傳統構架版本基礎上,對平臺應用模塊進行微服務化改造后的版本.該系統采用主流的SpringCloud 框架,在開源K8S 環境中進行過運行檢測,具備遷移改造上云的基礎.

3.1 數據一致性檢驗

系統服務遷移至阿里云的過程中,采用吉布斯采樣方法對遷移數據進行采樣,減少校驗數據量,提高系統遷移速率.針對采樣得到的數據,進行數據一致性的檢驗.為驗證模型檢驗方法的可行性,對遷移數據中的一部分,使用MySQL 中的pt-table-checksum 命令進行完整的數據一致性檢驗作為對比實驗.測試數據庫大小分別為186.75 GB、293.72 GB 和483.6 GB,分別進行采樣一致性檢驗和完整一致性檢驗,并經過采樣檢驗糾錯后,在通過完整的數據一致性檢驗檢驗采樣檢驗的正確率,實驗結果如表1所示.

表1 數據一致性檢驗實驗

測試結果表明,模型采樣檢驗方法準確率很高,經糾錯后,數據準確高達99.97%以上,證明了模型檢驗方法的可行性.

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

3.2 一鍵部署驗證

一鍵部署功能的驗證主要包括兩個場景,一是使用EDAS 在K8S 集群中使用鏡像的方式來部署新應用,部署界面如圖5所示.

另一個是驗證EDAS 對應用版本更新的部署,部署方式包括單批發布和分批發布兩種方式,界面如圖6所示.

經過測試驗證,在上述兩個應用部署場景下,均能夠使用EDAS 控制臺部署應用程序和配置參數,實現一鍵部署功能.

3.3 彈性伸縮驗證

彈性伸縮功能的測試包括手動伸縮和自動伸縮功能測試.手動伸縮是通過EDAS 控制臺手動設置應用的實例數目,適用于提前預知業務量的場景,譬如在月初報表類業務驟增,可以手動調制報表類應用實例數目.自動伸縮通過設置容器服務K8S 的容器組水平伸縮器配置伸縮策略,實現自動調制應用實例數目.自動伸縮適合業務量不確定或者頻繁變動的應用場景,實現按需分配計算資源.

圖6 EDAS 部署應用版本更新

伸縮策略設置最大容器數量為8,最小容器數量為2,伸縮指標設置為50%的CPU 使用量.使用壓力測試工具Jmeter 對服務進行壓力測試,持續100 個并發.

壓力測試開始后,CPU 使用率持續上升,容器副本數量自動調節增加;壓力測試停止后,CPU 使用率下降,系統自動釋放擴容的容器副本.某實例中CPU 使用量在壓力測試前后的監控曲線如圖7所示.

圖7 CPU 監控曲線

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

3.4 基于容器服務的灰度發布驗證

通過容器服務對灰度發布能力進行驗證,在EDAS中發布應用的不同版本,使用容器服務中的路由規則設置灰度流量規則,根據Cookie 值控制流量路由.請求服務時,服務器根據Cookie 值將流量路由至對應版本的應用.灰度發布策略設置如圖8所示,設置v2 版本應用匹配Cookie 名稱為version,匹配值為v2.當Cookie 值匹配時,服務將被路由至v2 版本應用,否則將路由至v1 版本.

圖8 CPU EDAS 灰度發布設置

測試設置應用服務返回對應的版本號,測試結果如圖9所示.測試中請求服務都獲得了正確的應用版本號,驗證了系統的灰度發布功能.

圖9 EDAS 灰度發布測試

3.5 故障自愈能力驗證

當容器服務工作節點發生宕機,容器實例自動漂移至其他工作節點,實現故障自愈.通過強制關閉容器服務K8S 集群的一個工作節點來模擬節點宕機,驗證運行在該節點上的應用實例是否遷移至其他節點并正常運行,實驗結果如圖10所示.

圖10 實例漂移測試(方框中為節點ID)

運行于強制關閉節點中的應用實例成功漂移至其他工作節點并正常工作提供服務,驗證了EDAS 的故障自愈能力.

4 結論與展望

針對當前電網信息通信運維系統存在的種種問題,本文提出了一種基于SpringCould 框架的微服務應用系統遷移上云改造模型,將電網信息通信運維系統遷移至云平臺,將系統服務全部遷入EDAS 體系,使用吉布斯采樣法采樣檢驗數據一致性,實現一鍵部署、彈性伸縮、灰度發布以及故障自愈.之后,通過國網安徽電力SG-I6000 微服務系統上云的實際案例,證明了系統的成功上云和可靠運行.