劉一田,劉士進(jìn),郭 偉,何 翔

(南瑞集團(tuán)公司(國網(wǎng)電力科學(xué)研究院),南京 210003)

柔性微服務(wù)監(jiān)控框架①

劉一田,劉士進(jìn),郭 偉,何 翔

(南瑞集團(tuán)公司(國網(wǎng)電力科學(xué)研究院),南京 210003)

微服務(wù)細(xì)化了服務(wù)的粒度,針對微服務(wù)的監(jiān)控是微服務(wù)管理需要面對的核心問題,以可擴(kuò)展全鏈路應(yīng)用服務(wù)監(jiān)控為目標(biāo),在已有服務(wù)管理層之上設(shè)計(jì)實(shí)現(xiàn)了一種柔性微服務(wù)監(jiān)控框架,用于監(jiān)控微服務(wù)狀態(tài)和不斷變化的服務(wù)負(fù)載,與已有的分布式監(jiān)控架構(gòu)相比,這種監(jiān)控框架靈活度更高,對服務(wù)變化的感知能力更強(qiáng),使用Raft算法增強(qiáng)了數(shù)據(jù)一致性,避免了單點(diǎn)故障的情況,經(jīng)試驗(yàn)分析,代價(jià)更小,在實(shí)際項(xiàng)目中驗(yàn)證了框架及方法的有效性.

柔性; 微服務(wù)監(jiān)控; 智能分析告警

1 引言

微服務(wù)的特點(diǎn)決定了應(yīng)用功能模塊的部署是分布式的,以往在單體架構(gòu)應(yīng)用環(huán)境下,所有的業(yè)務(wù)都在同一個(gè)服務(wù)器上,服務(wù)器出現(xiàn)錯(cuò)誤和異常時(shí)可以快速定位和處理問題,但是在微服務(wù)的架構(gòu)下,大部分功能模塊都是單獨(dú)部署運(yùn)行的,彼此通過預(yù)先編排的無狀態(tài)服務(wù)交互,前后臺業(yè)務(wù)流會經(jīng)過多個(gè)微服務(wù)的處理和傳遞,因此,如何實(shí)時(shí)采集系統(tǒng)及應(yīng)用服務(wù)的訪問及異常信息,根據(jù)業(yè)務(wù)流的錯(cuò)誤和異常信息統(tǒng)計(jì)分析以輔助快速定位問題并告警,靈活可擴(kuò)展的配置告警,以及能及時(shí)跟蹤業(yè)務(wù)流的處理順序和結(jié)果等技術(shù)是微服務(wù)監(jiān)控的關(guān)鍵所在.

以Zabbix為代表的傳統(tǒng)分布式監(jiān)控技術(shù)更傾向于提供系統(tǒng)級的監(jiān)控點(diǎn)和指標(biāo)[1],不能快速定位到系統(tǒng)問題的根本原因.Google公司研發(fā)的Dapper[2]分布式跟蹤系統(tǒng)為服務(wù)器上每一次發(fā)送和接收動(dòng)作來收集跟蹤標(biāo)識符和時(shí)間戳事件,每次RPC服務(wù)調(diào)用被稱為一個(gè) Span,用戶的 URL 請求是根 Span A,如果根 Span調(diào)用了RPC服務(wù)B和C,則B、C為A的子Span,這樣整個(gè)請求就被建模為由A為根的Span樹,被稱為一個(gè) Trace.每個(gè) Span 由 trace_id,span_id,parent_id 組成,通過parentId和spanId就可以有序地把所有的關(guān)系串聯(lián)起來,達(dá)到記錄業(yè)務(wù)流的作用,從而實(shí)現(xiàn)端到端的追蹤能力,通過對 Span 計(jì)時(shí),可以統(tǒng)計(jì)性能數(shù)據(jù).但是Dapper只提供調(diào)用時(shí)間的追蹤,而不提供如錯(cuò)誤追蹤,業(yè)務(wù)監(jiān)控等功能,無法較好滿足業(yè)務(wù)系統(tǒng)日常業(yè)務(wù)應(yīng)用監(jiān)控的需求.淘寶鷹眼是基于網(wǎng)絡(luò)調(diào)用日志的分布式跟蹤系統(tǒng),它可以分析網(wǎng)絡(luò)請求在各個(gè)分布式系統(tǒng)之間的調(diào)用情況,從而得到處理請求的調(diào)用鏈上的入口URL、應(yīng)用服務(wù)的調(diào)用關(guān)系,從而找到請求處理瓶頸,定位錯(cuò)誤異常的根源位置.同時(shí),業(yè)務(wù)方可以在調(diào)用鏈上設(shè)置業(yè)務(wù)埋點(diǎn)日志,使各個(gè)系統(tǒng)的網(wǎng)絡(luò)調(diào)用與實(shí)際業(yè)務(wù)內(nèi)容得到關(guān)聯(lián).需要一定的代碼植入,且擴(kuò)展性略差.

本文設(shè)計(jì)的柔性微服務(wù)監(jiān)控框架結(jié)合上述框架各自的典型優(yōu)勢技術(shù),分別從各方面進(jìn)行了改進(jìn)和提升.在數(shù)據(jù)采集上報(bào)組件技術(shù)方面,通過應(yīng)用服務(wù)器中間件代理組件,通過業(yè)務(wù)無侵入的方式提升了采集的定制化能力和可靠性; 在采集數(shù)據(jù)轉(zhuǎn)換和合并方面,采用Raft[3]一致性算法,將數(shù)據(jù)處理后分發(fā)到數(shù)據(jù)存儲和告警服務(wù),確保數(shù)據(jù)的一致性和準(zhǔn)確性; 在告警組件方面,基于配置下發(fā)的告警處理策略及可復(fù)用的告警策略模板,提高告警的定制化處理能力; 在統(tǒng)計(jì)分析組件方面,基于聚類分析算法,對實(shí)時(shí)和歷史數(shù)據(jù)進(jìn)行統(tǒng)計(jì)分析,將分析后數(shù)據(jù)發(fā)往消息總線對應(yīng)的訂閱主題,進(jìn)行智能告警判定裁決,提高告警準(zhǔn)確度; 在監(jiān)控展示方面,通過配置可視化定制告警參數(shù),支持用戶自定義監(jiān)控所需的服務(wù)指標(biāo)、JVM等指標(biāo),提高監(jiān)控的自主性.

2 監(jiān)控框架設(shè)計(jì)

本文設(shè)計(jì)的柔性微服務(wù)監(jiān)控框架結(jié)構(gòu)如圖1所示.其主要具備如下特征.

圖1 柔性微服務(wù)監(jiān)控框架結(jié)構(gòu)

(1)架構(gòu)設(shè)計(jì)高可用.整個(gè)系統(tǒng)無核心單點(diǎn),易運(yùn)維,易部署.

(2)低侵入性.盡可能少侵入或者無侵入其他業(yè)務(wù)系統(tǒng),對于使用方透明,減少開發(fā)人員的負(fù)擔(dān).

(3)告警策略靈活和自發(fā)現(xiàn).支持策略模板、模板繼承和覆蓋、多種告警方式、支持回調(diào)動(dòng)作,可以隨時(shí)決定所收集數(shù)據(jù)的范圍和粒度.

(4)支持最大告警次數(shù)、告警級別設(shè)置、告警恢復(fù)通知、告警暫停、不同時(shí)段不同閾值、支持維護(hù)周期,支持告警合并.

(5)時(shí)效性高、擴(kuò)展性好.從數(shù)據(jù)的收集和產(chǎn)生,到數(shù)據(jù)計(jì)算處理和最終展現(xiàn)都盡可能快; 生產(chǎn)環(huán)境每秒30萬次數(shù)據(jù)收集、告警、存儲、繪圖,可持續(xù)水平擴(kuò)展.

(6)決策支持.提煉分析數(shù)據(jù)從DevOps角度并提供決策支持服務(wù).

(7)自助分析儀表板.多維度的數(shù)據(jù)展示,用戶自定義儀表板等功能,提升更細(xì)粒度的用戶自助分析應(yīng)用體驗(yàn).

柔性微服務(wù)監(jiān)控框架的執(zhí)行流程分為八個(gè)步驟,分別介紹如下.

(1)統(tǒng)一配置管理中心統(tǒng)一維護(hù)監(jiān)控和告警策略配置,配置的變更自動(dòng)發(fā)布到消息總線的約定主題上,配置管理支持集群、負(fù)載均衡及高可用.

(2)監(jiān)控策略服務(wù)作為監(jiān)控代理的輔助工具,從消息總線訂閱監(jiān)控策略配置,監(jiān)控代理根據(jù)監(jiān)控配置收集微服務(wù)狀態(tài)信息; 微服務(wù)實(shí)例從消息總線指定主題訂閱監(jiān)控代理地址,作為數(shù)據(jù)上報(bào)的地址; 告警判定組件從消息總線訂閱告警策略配置,作為告警的判定依據(jù); 監(jiān)控策略包括監(jiān)控告警閾值、特殊定制的采集項(xiàng),IP白名單等,監(jiān)控代理將特殊采集項(xiàng)信息上報(bào)給監(jiān)控策略服務(wù).

(3)監(jiān)控策略服務(wù)根據(jù)統(tǒng)計(jì)信息發(fā)布不可用的微服務(wù)實(shí)例狀態(tài)到消息總線指定主題,統(tǒng)一配置管理中心訂閱相應(yīng)主題后及時(shí)更新監(jiān)控狀態(tài).客戶端代理庫作為微服務(wù)中間件代理,應(yīng)用通過代理將服務(wù)埋點(diǎn)、調(diào)試、異常等信息采集到監(jiān)控代理服務(wù)實(shí)例.

(4)監(jiān)控代理網(wǎng)關(guān)依據(jù)監(jiān)控策略對監(jiān)控信息進(jìn)行篩選,將篩選后的數(shù)據(jù)發(fā)布到消息總線指定告警主題.

(5)告警判斷組件和數(shù)據(jù)存儲和歸檔組件通過一致性哈希數(shù)據(jù)轉(zhuǎn)換合并工具將發(fā)布的消息通知訂閱到本地進(jìn)行存儲.

(6)告警判定組件從消息總線訂閱告警策略和微服務(wù)統(tǒng)計(jì)信息,并依據(jù)告警策略和服務(wù)統(tǒng)計(jì)信息等參數(shù),初步告警加權(quán)判定,根據(jù)判斷結(jié)果告警并以郵件等方式處理.

(7)監(jiān)控聚類分析組件定時(shí)從數(shù)據(jù)存儲中獲取歷史數(shù)據(jù),進(jìn)行聚類學(xué)習(xí)和訓(xùn)練,分析出服務(wù)調(diào)用的調(diào)用鏈等信息,并將分析結(jié)果提交給消息總線指定監(jiān)控主題分發(fā).重復(fù)告警判定流程.

(8)監(jiān)控展示組件支持指定的環(huán)境、應(yīng)用和服務(wù)指標(biāo)配置定制,根據(jù)定制參數(shù)實(shí)時(shí)展示監(jiān)控圖表,實(shí)現(xiàn)良好的自助分析效果.

3 監(jiān)控框架實(shí)現(xiàn)

柔性微服務(wù)監(jiān)控框架采用JSON格式的策略模板支持快速配置定義監(jiān)控和告警策略; 微服務(wù)實(shí)例的客戶端代理動(dòng)態(tài)獲取代理網(wǎng)關(guān)地址,將日志及埋點(diǎn)信息上報(bào)給監(jiān)控代理組件; 監(jiān)控代理組件根據(jù)監(jiān)控和告警策略,篩選過濾所需的監(jiān)控統(tǒng)計(jì)信息并發(fā)布到消息總線指定主題; 告警判定組件從消息總線訂閱告警策略及數(shù)據(jù)統(tǒng)計(jì)信息,形成初步判斷結(jié)果并發(fā)布到告警通知事件; 數(shù)據(jù)存儲歸檔組件訂閱的上報(bào)數(shù)據(jù)進(jìn)行聚類統(tǒng)計(jì)分析,聚合結(jié)果存儲歸檔并再次發(fā)布到消息總線作為告警判斷組件的輸入,同時(shí)用戶可通過監(jiān)控儀表板調(diào)用查詢組件監(jiān)控及自助分析統(tǒng)計(jì)指標(biāo).根據(jù)上述框架的設(shè)計(jì),需要實(shí)現(xiàn)五個(gè)主要關(guān)鍵技術(shù)組件:(1)高可用的統(tǒng)一配置管理中心.(2)無侵入的微服務(wù)實(shí)例客戶端代理.(3)高可用及高性能的消息總線.(4)靈活可復(fù)用的監(jiān)控及告警策略模板.(5)聚類分析的統(tǒng)計(jì)算法.

(1)高可用統(tǒng)一配置中心

框架采用動(dòng)態(tài)路由的高可用代理及分布式一致性Raft[3]算法作為統(tǒng)一配置中心集群環(huán)境下負(fù)載均衡、統(tǒng)一配置的一致性及高可用,實(shí)現(xiàn)配置管理集群實(shí)例在節(jié)點(diǎn)故障重啟時(shí)對請求透明化.如圖2所示.

圖2 高可用統(tǒng)一配置中心

統(tǒng)一配置管理集群由高可用代理節(jié)點(diǎn)對外統(tǒng)一暴露靜態(tài)固定端口,而高可用代理本身監(jiān)控配置管理節(jié)點(diǎn)的狀態(tài)變更信息,當(dāng)配置管理節(jié)點(diǎn)集群中出現(xiàn)節(jié)點(diǎn)不可用、動(dòng)態(tài)擴(kuò)充配置管理節(jié)點(diǎn)等狀況時(shí),高可用代理及時(shí)更新路由表.

配置信息的高可用技術(shù)基于Raft算法,集群中的節(jié)點(diǎn)分為 leader、follower、candidate 三種角色,由leader響應(yīng)客戶端請求并確保響應(yīng)結(jié)果的一致性.統(tǒng)一配置管理節(jié)點(diǎn)集群首先選舉一個(gè)leader節(jié)點(diǎn),由leader節(jié)點(diǎn)對外提供服務(wù),當(dāng)配置更新時(shí),leader節(jié)點(diǎn)發(fā)出命令,并在確保集群中多數(shù)節(jié)點(diǎn)都已完成命令操作后,返回正確響應(yīng)給請求對象.如果一個(gè)follower在選舉超時(shí)的時(shí)間周期里沒有收到leader的信息,就進(jìn)入新的選舉周期,自身轉(zhuǎn)成候選人candidate角色,給自己投票,發(fā)起選舉,并重寫產(chǎn)生leader以繼續(xù)提供高可用一致性服務(wù).

(2)無侵入的微服務(wù)實(shí)例客戶端代理

系統(tǒng)實(shí)施監(jiān)控的方式分為兩類:一類是內(nèi)嵌式,一類是伴隨式.對大型分布式系統(tǒng)來講,伴隨式是一種更加合適的結(jié)構(gòu)[4].

框架采用伴隨式的中間件劫持技術(shù)實(shí)現(xiàn)微服務(wù)實(shí)例的客戶端代理,業(yè)務(wù)系統(tǒng)應(yīng)用開發(fā)時(shí)只需關(guān)注業(yè)務(wù)功能實(shí)現(xiàn).中間件劫持就是將我們自己的代碼行為植入到中間件的各種行為中.實(shí)現(xiàn)劫持和監(jiān)控主要依靠四種關(guān)鍵行為:應(yīng)用啟動(dòng),停止,接收請求,響應(yīng)回復(fù).對JavaEE應(yīng)用服務(wù)器的劫持核心是根據(jù)classloader的加載時(shí)機(jī),在classloader的樹型層次上獲得優(yōu)先加載權(quán),從而可以改變這些行為.如圖3所示.

圖3 無侵入的微服務(wù)實(shí)例客戶端代理

通過中間件劫持技術(shù),全自動(dòng)的收集微應(yīng)用實(shí)例、微服務(wù)實(shí)例及服務(wù)接口的信息.這些信息包括應(yīng)用唯一標(biāo)識、服務(wù)名、服務(wù)實(shí)例的URI、服務(wù)接口的URI、服務(wù)接口的元數(shù)據(jù)(類,方法,入?yún)⒊鰠?注解,部署描述符)等統(tǒng)計(jì)信息.其中,服務(wù)類型和方法通過Java的反射方式提取信息; Annotation通過注解掃描工具提取具有相關(guān)注解的類,然后通過注解API提取注解信息; 部署描述符通過WebAppClassLoader獲取web.xml,spring-config.xml,log4j.xml等部署描述符文件路徑,然后使用文檔對象模型解析提取關(guān)注的標(biāo)簽信息.最后調(diào)用特定服務(wù)接口獲取服務(wù)實(shí)例的內(nèi)存、CPU等信息,并動(dòng)態(tài)獲取監(jiān)控代理網(wǎng)關(guān)的地址,將統(tǒng)計(jì)數(shù)據(jù)上報(bào)給代理網(wǎng)關(guān).

(3)靈活可復(fù)用的監(jiān)控及告警策略模板

框架采用靈活可復(fù)用的監(jiān)控及告警策略模板,以JSON格式描述,如表1所示.

表1 監(jiān)控策略模板描述

主機(jī)域是一組采用相同監(jiān)控策略機(jī)器的集群,監(jiān)控策略模板支持繼承和策略覆蓋,模板和主機(jī)域綁定后,主機(jī)下的機(jī)器會自動(dòng)應(yīng)用該模板的所有策略,節(jié)點(diǎn)進(jìn)出主機(jī)域時(shí),相關(guān)的模板會自動(dòng)關(guān)聯(lián)或者解除.服務(wù)上下線不需要手動(dòng)來變更監(jiān)控,從而在提高效率的同時(shí)降低了遺漏和誤報(bào)警.策略模板支持以表達(dá)式方式動(dòng)態(tài)添加監(jiān)控及告警策略,如圖4所示.

圖4 監(jiān)控及告警策略模板定義

(4)高可用及高性能的消息總線

為了實(shí)現(xiàn)在分布式環(huán)境下的即時(shí)消息通知,并保障消息的高性能傳輸,框架采用高性能分布式消息總線 Apache Kafka[5]組件實(shí)現(xiàn)消息的發(fā)布/訂閱功能,并使用多個(gè)節(jié)點(diǎn)組成集群以保障消息總線的高可用.通信模式采用發(fā)布/訂閱模式,使消息按照特定的主題甚至內(nèi)容進(jìn)行分發(fā),應(yīng)用程序可以根據(jù)主題接收到所需要的消息.發(fā)布/訂閱功能使得發(fā)送者和接收者之間的耦合關(guān)系變得更為松散,發(fā)送者和接收者不必關(guān)心消息的發(fā)送和接收地址,而只是根據(jù)消息的主題進(jìn)行消息的收發(fā).

(5)聚類分析的統(tǒng)計(jì)算法

統(tǒng)計(jì)分析采集日志的主要目標(biāo)包括分析服務(wù)調(diào)用全過程鏈、用戶在導(dǎo)航或?yàn)g覽網(wǎng)站時(shí)生成的點(diǎn)擊流或單擊路徑、發(fā)生系統(tǒng)宕機(jī)之前的事件的日志、用戶在系統(tǒng)關(guān)鍵操作順序的事務(wù)記錄、根據(jù)一段時(shí)間內(nèi)用戶的互動(dòng)來預(yù)測服務(wù)取消或其他不良結(jié)果的記錄.

框架算法綜合了順序分析、聚類分析方法和Markov鏈分析,以識別數(shù)據(jù)分類及其順序并進(jìn)行動(dòng)態(tài)信任決策[6].分析算法的特點(diǎn)之一是使用順序數(shù)據(jù),此數(shù)據(jù)通常表示數(shù)據(jù)集狀態(tài)之間的一系列事件或轉(zhuǎn)換,如圖5所示.

圖5 聚類分析的統(tǒng)計(jì)算法

4 案例分析與評估

為了對本文提出的柔性微服務(wù)監(jiān)控框架進(jìn)行驗(yàn)證,在一個(gè)真實(shí)的環(huán)境中進(jìn)行了案例的部署和研究.案例環(huán)境由16臺8核8 G內(nèi)存的PC服務(wù)器(HPDL 380 G4 378735-AA1)組成,其中數(shù)據(jù)庫、微服務(wù)實(shí)例、監(jiān)控代理節(jié)點(diǎn)、統(tǒng)一配置管理節(jié)點(diǎn)、消息總線節(jié)點(diǎn)、日志歸檔節(jié)點(diǎn)、告警節(jié)點(diǎn)比例為1:8:1:2:2:1:1,數(shù)據(jù)庫和應(yīng)用服務(wù)采用國家電網(wǎng)公司智能運(yùn)檢系統(tǒng)的測試數(shù)據(jù)庫和經(jīng)過拆分的微應(yīng)用服務(wù),微服務(wù)實(shí)例以Docker容器形式運(yùn)行.通過loadrunner模擬并發(fā)600用戶的微服務(wù)訪問,通過監(jiān)控策略和告警模板定制統(tǒng)計(jì)了服務(wù)響應(yīng)時(shí)間超過5秒的URL及異常信息,觀察柔性微服務(wù)監(jiān)控框架的效率和穩(wěn)定性,評估客戶端代理庫對應(yīng)用的性能影響,試驗(yàn)結(jié)果如表2所示.

表2 客戶端代理對應(yīng)用性能的影響

驗(yàn)證結(jié)果表明,柔性微服務(wù)監(jiān)控框架在大并發(fā)吞吐量時(shí)保證了高可用和高效,但也發(fā)現(xiàn)了一些問題,針對小規(guī)模的應(yīng)用現(xiàn)有框架的部署架構(gòu)略顯復(fù)雜,客戶端代理庫會在生產(chǎn)模式下會產(chǎn)生微小的性能損耗,尚有提升空間.目前,柔性微服務(wù)監(jiān)控框架已在國網(wǎng)智能運(yùn)檢系統(tǒng)中實(shí)現(xiàn)并應(yīng)用,取得了較好的應(yīng)用效果.

5 結(jié)束語

本文研究了傳統(tǒng)分布式系統(tǒng)監(jiān)控技術(shù)及基于服務(wù)調(diào)用鏈的分布式系統(tǒng)追蹤技術(shù),在此基礎(chǔ)上,設(shè)計(jì)了柔性微服務(wù)監(jiān)控框架,給出了高可用配置中心、無侵入的微服務(wù)實(shí)例客戶端代理、靈活可復(fù)用的監(jiān)控告警模板等創(chuàng)新點(diǎn),闡述了該框架的架構(gòu)設(shè)計(jì)及關(guān)鍵實(shí)現(xiàn)技術(shù).最后,以國網(wǎng)智能運(yùn)檢系統(tǒng)的微服務(wù)應(yīng)用案例為背景,給出了柔性微服務(wù)監(jiān)控框架的應(yīng)用驗(yàn)證評估,驗(yàn)證結(jié)果、效率評估及生產(chǎn)運(yùn)行實(shí)踐表明,該框架提升了分布式系統(tǒng)中微服務(wù)監(jiān)控管理的靈活度、效率和問題定位準(zhǔn)確度,提高了電網(wǎng)應(yīng)用信息系統(tǒng)的服務(wù)水平.后續(xù)將針對遺留問題持續(xù)改進(jìn)優(yōu)化該框架.

1Zabbix.Enterprise-class monitoring system.http://www.zabbix.com/functionality.

2Sigelman BH,Barroso LA,Burrows M,et al.Dapper,a largescale distributed systems tracing infrastructure.Google Technical Report dapper-2010-l,2010.

3Ongaro D,Ousterhout J.In search of an understandable consensus algorithm.Proc.of the 2014 USENIX Annual Technical Conference.Philadelphia,PA,USA.2014.305–319.

4劉東紅,郭長國,王懷民,等.監(jiān)控使能的分布式軟件系統(tǒng)構(gòu)造方法.軟件學(xué)報(bào),2011,22(11):2610–2624.

5Kafka Apache.A distributed streaming platform.http://kafka.apache.org/intro.

6李小勇,桂小林,毛倩,等.基于行為監(jiān)控的自適應(yīng)動(dòng)態(tài)信任度測模型.計(jì)算機(jī)學(xué)報(bào),2009,32(4):664–674.

Flexible Microservice Monitoring Framework

LIU Yi-Tian,LIU Shi-Jin,GUO Wei,HE Xiang

(NARI Group Corporation(State Grid Electric Power Research Institute),Nanjing 210003,China)

Microservices refine the granularity of services,and the monitoring of flexible microservices is the core of the microservices management.With the aim of extending the full-link application service monitoring,a flexible microservices monitoring framework is designed and implemented on the existing service management layer to monitor the microservices status and the changing service load.Compared with the existing distributed monitoring architecture,the framework is more flexible,more aware of service changes.The Raft algorithm is used to enhance data consistency and avoid single point failure.The experimental analysis shows that the cost is smaller,and the validity of the framework and the method is verified in the actual project.

flexible; microservices monitoring; intelligent analysis and alarm

劉一田,劉士進(jìn),郭偉,何翔.柔性微服務(wù)監(jiān)控框架.計(jì)算機(jī)系統(tǒng)應(yīng)用,2017,26(10):139–143.http://www.c-s-a.org.cn/1003-3254/6006.html

國網(wǎng)電力科學(xué)研究院科技項(xiàng)目(524606160150)

2017-01-19; 采用時(shí)間:2017-02-20