電力項目規劃評審微服務平臺架構優化設計

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

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

0 引言

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

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

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

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

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

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

(1)

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

(2)

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

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

(3)

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

2 電力項目規劃微服務架構內建數據庫策略定義

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

數據庫采用MySQL進行搭建，且對數據庫內部數據及變量采用統一存儲管理。

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

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

數據庫內部數據注冊表內字段結構必須有定義和注釋，便于數據后期變更維護操作。

數據庫內部數據冗余值需設定為動態值，便于根據數據庫鏈接檢索速度，隨時調整冗余值，避免數據庫空間資源的浪費。

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

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

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

電力項目規劃微服務架構數據庫策略內部設計架構定義注冊表信息如表1所示。

表1 電力項目架構數據信息表

2.2 評審架構數據信息注冊表定義

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

2.3 服務架構的注冊

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

表2 評審架構數據信息表

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

3 評審服務優化架構設計

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

圖2 評審服務優化架構總體結構

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

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

4 實測數據選取

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

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

4.1 實測數據腳本開發

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

步驟1將實測樣本導入優化架構；

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

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

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

步驟5選擇測試模板；

步驟6點擊保存任務；

步驟7開始測試。

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

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

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

圖3 不同方法評審測試流增長狀態

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

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

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

(4)

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

圖4 不同方法優化后數據存儲量

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

5 總結

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