電力項目規(guī)劃評審微服務平臺架構優(yōu)化設計

李海濱， 周潔， 劉麗， 張晉梅， 宋斌， 宋堃

(國網(wǎng)冀北電力有限公司 經(jīng)濟技術研究院， 北京 100038)

0 引言

隨著網(wǎng)絡技術在服務領域的廣泛應用。各種微服務平臺應運而生，評審微服務平臺的出現(xiàn)，構成了電力項目規(guī)劃評審新模式，同時對微服務平臺評審工作提出了新的要求[1-3]。針對評審過程中對項目規(guī)劃管理與控制結構為切入點，對微服務平臺架構中存在的評審模式、管理結構進行系統(tǒng)性架構層優(yōu)化，強化評審數(shù)據(jù)交互結構與數(shù)據(jù)庫規(guī)范資源配置，提升流程交互機制、規(guī)范評審管理模式與架構功能，統(tǒng)一評審過程中對部門數(shù)據(jù)間的關聯(lián)、授權及操作[4-5]。使電力項目規(guī)劃評審微平臺架構能夠融入到實際應用場景。

在傳統(tǒng)的電力項目規(guī)劃評審架構模型中，主要將電力項目的規(guī)劃評審流程劃分為項目設計、項目進展、項目審批與項目改進4個環(huán)節(jié)，根據(jù)環(huán)節(jié)的進展性與關聯(lián)性將其稱為DPAI評審架構模式[6]，它是由英文單詞Design、 Progress、 Approval、 Improvement的首字母組成。

通過對傳統(tǒng)電力項目規(guī)劃評審的DPAI評審架構模式分析不難發(fā)現(xiàn)，傳統(tǒng)的DPAI評審架構模式可歸屬于一種分散式管理架構，在各種變量的管理上存在一定的獨立性，導致架構功能關聯(lián)性一致，內(nèi)部變量關聯(lián)性卻缺乏邏輯性，無法形成整條完整邏輯鏈，同時在評審數(shù)據(jù)的審批上，需要依賴架構以外的數(shù)據(jù)庫支持，才能完成對相關規(guī)定數(shù)據(jù)的獲取。在此過程中增加了數(shù)據(jù)庫權限問題，降低了架構服務的完整性與一體性[7-8]。在邏輯變量上，傳統(tǒng)架構是以一個問題循環(huán)為一個周期，多個具有相關性的問題被分為多個獨立的問題周期來提供變量方案。在處理問題的效率上是有利的，但不利于評審問題的發(fā)現(xiàn)與解決。

1 微服務平臺結構的邏輯鏈轉換計算

基于上述對傳統(tǒng)電力項目規(guī)劃評審機構模型的分析，首先對邏輯鏈問題進行優(yōu)化。根據(jù)邏輯鏈是由多個規(guī)劃評審數(shù)據(jù)量之間關聯(lián)量所構成的特點，結合上述提到了審批數(shù)據(jù)庫問題，設計中采用挖掘算法對評審相關數(shù)據(jù)進行關聯(lián)，同時在架構中建立決策樹，實現(xiàn)對內(nèi)建數(shù)據(jù)口的支持[9]。為了保證設計決策樹下的每個關聯(lián)子集鍵值規(guī)劃的歸一，采用決策樹ID3算法來完成架構節(jié)點子集的挖掘歸一計算。通過決策樹ID3算法，對架構中審批數(shù)據(jù)子集的屬性進行最大化增益，通過對內(nèi)建數(shù)據(jù)文件內(nèi)容變量的檢索，獲得多個決策樹分支，由此構建起完整的數(shù)據(jù)關聯(lián)樹[10]。

決策樹ID3算法假設項目規(guī)劃評審過程中存在r個關聯(lián)數(shù)據(jù)變量d1,d2,…,dr>，且滿足同一個評審條件屬性D，r個變量反饋關聯(lián)信息k1,k2,…,kr>可根據(jù)評審條件屬性D完成對整個評審計算流程的K定義，K內(nèi)部所關聯(lián)的數(shù)據(jù)庫信息主要來源于Ky，其上述變量都在評審條件屬性D上存在一個對應的條件關聯(lián)鍵值dy，如果評審條件屬性設為D，對應架構上的數(shù)據(jù)節(jié)點集合為K，且滿足與決策樹上的對應子集分支相統(tǒng)一。令架構上的靜態(tài)子集對應數(shù)據(jù)庫Ky中數(shù)據(jù)類型為Px的構成總量為Px,y。式(1)代表關聯(lián)D所構成的決策樹的子集分支熵：

(1)

式中，第y個靜態(tài)子集對應的邏輯變量加權值為kx,y,…,kn,y/k，通過靜態(tài)子集分支內(nèi)部數(shù)據(jù)量除以K內(nèi)的數(shù)據(jù)總量獲得，同時可得到評審條件屬性D此維度下的閾值等于d。FD同靜態(tài)子集邏輯呈現(xiàn)出逆態(tài)形式。式(2)是對架構內(nèi)建數(shù)據(jù)庫Ky記性邏輯鏈轉換的描述：

(2)

式中，Ky內(nèi)數(shù)據(jù)類型隸屬于Px的可能性可通過概率函數(shù)的形式描述為Qx,y=Kx,y/Ky。式(3)代表符合評審條件屬性D具有相同關聯(lián)性的分支對應信息總量：

HD=Xk1,x,k2,x,…,kn,y-FD

(3)

式中，決策樹通過增強符合審批條件屬性D的鍵值完成對邏輯鏈的轉換，即決策樹總鍵值HD的定義。

2 電力項目規(guī)劃微服務架構內(nèi)建數(shù)據(jù)庫策略定義

數(shù)據(jù)庫作為評審內(nèi)容數(shù)據(jù)審定對比資源的來源，其內(nèi)部規(guī)范、標準相關數(shù)據(jù)的總量與服務權限決定著平臺架構完整度。針對微服務平臺的輕量化結構特征，設計優(yōu)化中對內(nèi)建數(shù)據(jù)庫進行了規(guī)范策略的定義，定義描述如下。

數(shù)據(jù)庫采用MySQL進行搭建，且對數(shù)據(jù)庫內(nèi)部數(shù)據(jù)及變量采用統(tǒng)一存儲管理。

對數(shù)據(jù)庫內(nèi)部數(shù)據(jù)進行命名格式管理，即相關評審數(shù)據(jù)表開頭一律為“s_”，規(guī)范、法律一律用“fg_”開頭，其余為數(shù)據(jù)用“j”開頭。圖像、閾值、存儲調(diào)度、時間日志等數(shù)據(jù)借用時間+文件變量屬性開頭。若數(shù)據(jù)文件涉及到多個關聯(lián)類型文件，采用文件+關聯(lián)控制文件的形式進行存儲。單個數(shù)據(jù)能夠同時關聯(lián)的文件的字符數(shù)量定義值為45個字符，大于45的字符數(shù)對應的文件采用壓縮字典的方式進行數(shù)據(jù)記錄。

數(shù)據(jù)庫文件必須采用全權限鍵值結構，且數(shù)據(jù)庫的鍵值能夠自動生成整數(shù)鍵值。

數(shù)據(jù)庫內(nèi)部數(shù)據(jù)注冊表內(nèi)字段結構必須有定義和注釋，便于數(shù)據(jù)后期變更維護操作。

數(shù)據(jù)庫內(nèi)部數(shù)據(jù)冗余值需設定為動態(tài)值，便于根據(jù)數(shù)據(jù)庫鏈接檢索速度，隨時調(diào)整冗余值，避免數(shù)據(jù)庫空間資源的浪費。

搭建好的數(shù)據(jù)內(nèi)部資源一旦定義完畢，不得隨意修正更改、刪除、替換，若必須修正，需數(shù)據(jù)庫高級權限用戶審批后，方可修正更新。

為了提升數(shù)據(jù)庫在評審服務中的檢索效率，設計架構優(yōu)化中采用超級索引方式，來提升數(shù)據(jù)庫資源查詢的效率，同時最大程度地降低資源更新帶來的數(shù)據(jù)交互延遲。

2.1 電力項目規(guī)劃架構策略注冊表定義

電力項目規(guī)劃微服務架構數(shù)據(jù)庫策略內(nèi)部設計架構定義注冊表信息如表1所示。

表1 電力項目架構數(shù)據(jù)信息表

2.2 評審架構數(shù)據(jù)信息注冊表定義

根據(jù)上述項目規(guī)劃策略注冊表定義，將評審架構中的評審策略量進行關聯(lián)邏輯的注冊，通過對注冊變量的配置定義，使評審流程以靜態(tài)策略的形式固定下來，保證評審架構的穩(wěn)定。具體評審架構數(shù)據(jù)信息注冊量定義如表2所示。

2.3 服務架構的注冊

根據(jù)表2注冊表設計定義量，對優(yōu)化機構對應服務進行設定，服務架構注冊執(zhí)行語言邏輯代碼如圖1所示。

表2 評審架構數(shù)據(jù)信息表

圖1 服務架構注冊執(zhí)行語言邏輯代碼

3 評審服務優(yōu)化架構設計

完成上述優(yōu)化設計后，對項目規(guī)劃評審服務架構進行針對性優(yōu)化設計。為了保留傳統(tǒng)平臺架構分散式管理的靈活性，設計采用MAster-Node的分布式架構，通過定義一個微服務節(jié)點來對多個評審節(jié)點進行管理，總體架構如圖2所示。

圖2 評審服務優(yōu)化架構總體結構

優(yōu)化設計中，將微服務平臺的主評審節(jié)點設置為K8 s主節(jié)點，通過主節(jié)點來完成對評審過程中子節(jié)點的分配管理，同時對數(shù)據(jù)的接入及Node節(jié)點的分布進行管理。在主節(jié)點的對外接口上，優(yōu)化設計針對架構特征，采用API Sever為主接口設計，配合Controller Manage管理策略，對結構中的所有服務進行權限管理；考慮到架構底層資源的動態(tài)配置是決定評審服務架構合理性的關鍵，因此優(yōu)化中采用Scheduie作為架構底層動態(tài)資源配置架構，同時為保證評審環(huán)節(jié)數(shù)據(jù)的永久性存儲，設計了Etcd架構的存儲配置量。

作為優(yōu)化架構中的子節(jié)點，主要對評審服務過程中的Pod架構層進行服務層支持，在架構服務集群層面上將子節(jié)點服務轉化為主節(jié)點服務操作，其中包括對Docker檢索組件、評審進程Kubelet與授權服務進程KUber-Proxy的調(diào)動。Node子節(jié)點在啟動前都會對單次服務所需的資源進行預配置，定時向架構主節(jié)點反饋自身相關資源信息與運行狀態(tài)數(shù)據(jù)，并根據(jù)主節(jié)點動態(tài)實時做出相應資源與參量的調(diào)整。

4 實測數(shù)據(jù)選取

設計架構的實際數(shù)據(jù)測試需要采用架構測試工具，為了保證架構測試的穩(wěn)定性，實驗測試采用HP公司發(fā)布的LoadRunner 13.0 測試工具來完成。根據(jù)設計架構在評審服務中主要針對規(guī)劃項目的評審數(shù)據(jù)流與數(shù)據(jù)庫實際標準指數(shù)的處理，因此可通過一個任務測試接口來完成并發(fā)數(shù)據(jù)流的測試。

首先，抽取實際評審數(shù)據(jù)處理包的基礎信息數(shù)據(jù)流導入優(yōu)化后的電力項目規(guī)劃微服務平臺架構，抽取實際數(shù)據(jù)樣本4500組，將抽取的實際數(shù)據(jù)樣本設計為雙節(jié)點并發(fā)的數(shù)據(jù)流模板，模板執(zhí)行服務標簽設定為“ps001”-“ps450”，共有450個節(jié)點測試流，每個并發(fā)節(jié)點測試流分別對應10個評審任務數(shù)據(jù)流，保存任務并導出。

4.1 實測數(shù)據(jù)腳本開發(fā)

實測數(shù)據(jù)腳本開發(fā)：通過LoadRunner 腳本編譯工具，在IE核心瀏覽器的配合下，對評審工作流并發(fā)數(shù)據(jù)樣本發(fā)起測試。實測步驟如下：

步驟1將實測樣本導入優(yōu)化架構；

步驟2通過測試工具用戶名登錄測試工具；

步驟3進入測試流程設置菜單；

步驟4設置菜單新建測試項目；

步驟5選擇測試模板；

步驟6點擊保存任務；

步驟7開始測試。

4.2 架構測試流的增長響應測試

實測數(shù)據(jù)樣本評審任務測試模板執(zhí)行服務標簽設定為“xs001”-“xs450”共發(fā)送150個工作測試流，分析不同方法下響應耗時，得到結果如圖3所示。

分析圖3可知，不同方法的評審測試流增長狀態(tài)不同。時間為50 s時，區(qū)塊鏈方法發(fā)送的工作測試流為70，流程驅(qū)動方法發(fā)送的工作測試流為55，本文方法發(fā)送的工作測試流為100。時間為80 s時，區(qū)塊鏈方法發(fā)送的工作測試流為105，流程驅(qū)動方法發(fā)送的工作測試流為85，本文方法發(fā)送的工作測試流為140。在相同時間內(nèi)，本文方法能夠發(fā)送更多的工作測試流，說明本文方法的評審測試流增長速度明顯較快。

圖3 不同方法評審測試流增長狀態(tài)

評審微服務平臺架構整體報告如表3所示。

表3 評審微服務平臺架構整體性能報告

按照評審平臺架構性能達標標準≥94.67%的要求，將報告1內(nèi)的數(shù)據(jù)導入架構性能計算式(4)：

(4)

式(4)中，設x=4 500，y=450，n=3，r=0.3；通過計算可得到優(yōu)化后的架構評審任務并發(fā)邏輯達標率達到了98.67%，超過了電力項目規(guī)劃平臺架構設計技術標準94.67%，證明優(yōu)化后的架構邏輯性更加合理，完全符合實際應用要求。同時通過溢出指標參數(shù)可以發(fā)現(xiàn)，架構在特定數(shù)據(jù)流的并發(fā)策略上還存在變數(shù)，后期可根據(jù)實際應用場景與用戶群體的不同進行相應的修正。通過寧夏電力公司對該架構的使用反饋證明，設計架構已能夠滿足實際評審場景的應用要求，為不同用戶群體，提供一站式評審服務。

圖4 不同方法優(yōu)化后數(shù)據(jù)存儲量

分析圖4可知，不同的方法優(yōu)化后數(shù)據(jù)存儲量不同。當用戶人數(shù)為5人時，區(qū)塊鏈方法優(yōu)化后數(shù)據(jù)存儲量為56 GB，流程驅(qū)動方法優(yōu)化后數(shù)據(jù)存儲量38 GB, 本文方法優(yōu)化后數(shù)據(jù)存儲量150 GB。當用戶人數(shù)為30人時，區(qū)塊鏈方法優(yōu)化后數(shù)據(jù)存儲量為87 GB，流程驅(qū)動方法優(yōu)化后數(shù)據(jù)存儲量64 GB,本文方法優(yōu)化后數(shù)據(jù)存儲量165 GB。本文方法的數(shù)據(jù)存儲量始終高于傳統(tǒng)方法，這是因為本文方法分析了評審微服務平臺底層數(shù)據(jù)量，并根據(jù)分析結果優(yōu)化電力項目規(guī)劃評審微服務平臺架構，挖掘電力項目規(guī)劃評審內(nèi)容，提升數(shù)據(jù)存儲量。

5 總結

區(qū)別于傳統(tǒng)評審模式，微服務平臺架構依托數(shù)字化辦公與大數(shù)據(jù)計算技術，通過數(shù)據(jù)云端分析、交互、反饋，完成對評審流程的送報、審批、評審反饋流程的操作。因此，架構邏輯的合理性，直接決定評審服務的體驗質(zhì)量。為此，結合對傳統(tǒng)平臺架構模型的分析，進行了電力項目規(guī)劃評審微服務平臺架構優(yōu)化設計。最后經(jīng)實測數(shù)據(jù)表明，優(yōu)化后的架構在操作流程切換、評審功能交互等操作邏輯上更加合理，提升了電力項目評審效率，簡化了電流項目規(guī)劃評審流程，對項目進程起到了推動作用。