基于云原生應用平臺實現應用服務可造性

劉 超 ，宋 健 ，崔 杰 ，馬 野 ，王宇軒

（1國網吉林省電力有限公司信息通信公司 吉林 長春 130000）

（2國網吉林省電力有限公司 吉林 長春 130000）

0 引言

云原生技術能夠充分發揮云平臺的彈性與分布式技術的優勢，從而實現快速部署任務細化項目結構的目的。但是該技術在享受快速部署新業務能力的同時，還需要承擔嚴重的業務風險承受能力，在出現錯誤與解決錯誤的過程中同樣會消耗大量工作時間，為企業帶來額外的業務勞動。對此，為提高云原生應用平臺在實際應用中的效率，本文將進一步對云原生平臺下數據接入管理問題進行研究，通過融合云原生相關技術對其進行改造，以期提高該技術在實際應用中的應用效率。

1 方案設計

1.1 系統架構設計

高效數據訪問層的組成結構主要包括：監控管理模塊、通信協議模塊、結果集處理模塊、路由解析模塊、SQL執行模塊以及數據庫鏈接模塊。各模塊間的信息流通見圖1。

其中，監控管理模塊主要承擔與高效數據訪問層的連接，并對內存資源等數據進行監控與管理，實現方式主要以管理命令為主，對輪詢事件以判斷是否需要釋放資源存儲空間。通信協議模塊主要負責系統底層的收發數據以及各任務線程的回調處理，使用Poractor模式實現提高效率的目的[1]。結果集處理模塊負責對各云端跨分片任務產生的結果進行收集和整理，因云原生數據具備跨云遷移的能力，所以需要對跨分片產生數據進行匯總管理。路由解析模塊承擔系統對SQL命令的解析，解析內容包括MySQL協議中引用到該模塊的SQL語句、類型以及關鍵字等，以此生成最優路徑結合路由計算單元進行計算。SQL執行模塊承擔連接池與對應目標的連接，在與目標連接之后完成信息同步，結合路由解析模塊的解析結果，將SQL命令語句下至對應節點執行。數據庫連接模塊承擔系統產生數據的存儲、維護和管理[2]。

1.2 總體的執行流程

數據訪問層的主要流程由結構下通信協議模塊開始，由回調線程對讀寫事件的具體內容進行讀寫處理，此時管理模塊會調動定時器對事件資源進行檢查并對判斷完成的事件進行資源釋放[3]。客戶端層面由用戶調用虛擬IP地址鏈接登錄到負載均衡器，由負載均衡器結合預制算法鏈接到事件對應的數據訪問層，此時數據訪問層的活動將交由NAS盤管理，并在事件鏈接到對應的數據庫后將結果返回給客戶端[4]，詳細流程見圖2。

該結構下后端數據庫的返回數據會通過相關協議解析后重新發送至回調模塊，若返回過程涵蓋多個節點數據，則返回的執行結果會先進行匯集和預排序，然后將數據經由通信協議模塊反饋至客戶端。

2 應用服務可造性

2.1 云原生應用流行度分析

雖然有關云原生相關技術的研究已經初具成果，但是從云原生發展角度來看，該項技術仍處于研究的初級階段，因此通過對云原生應用流行度的調查分析，可明確現階段云原生用戶的喜好，以此設計更加簡潔的數據訪問層結構框架，并為云原生應用平臺的能耗提供進行判斷依據。由此可認為云原生流行程度越高，各功能方向的用戶偏好性就越強，用戶訪問云原生應用平臺的次數便會增加[5]，所造成的數據訪問層功率負荷就越高。因此，在考慮云原生平臺應用可造性之前，應當引入應用流行度指標，以此使應用可造性結果能夠更加貼合云原生發展初期的微服務租用比例，進而提升其結構變化產生的收益。由此，可假設在某環境下存在N個不同應用，應用集合可用“A”表示，則第n個應用在時刻下的流行度可表示為“Dn”。因應用不同會使得不同時刻下存在不同的流行度，若云原生應用供應商的應用集可結合應用的流行度進行排列，則用戶對某項應用發送需求請求的概率為“DN”，且其服從Zipf分布[6]。考慮到云原生應用的發展時間，本文將在DN的計算中引入調節因子“θ”，以此方式平衡發展較早云原生應用對用戶產生的影響，進而穩定用戶偏好和訪問次數與頻率。DN的表達式為：

上式中：α表示云原生應用在時段下的流行度指數。

2.2 用戶偏好性

結合上述分析可得到該地區云原生應用的用戶偏好性，用戶偏好性的大小可直接影響云原生結構所發揮的效益，即若用戶對某項應用的偏好性較低，則該地區云原生應用所產生的收益便會不斷下降，由此會造成偏好性較低應用閑置占用系統內存，而偏好性較高的應用存在系統負荷工作的情況[7]。因此，為提高云原生應用的服務質量，本文將融合當地用戶偏好性指標作為可造性評價的衡量標準，為降低系統能耗并提高數據訪問層數據調用效率奠定基礎。用戶偏好性受用戶體驗水平、應用時延、能耗以及滿足需求程度等多方面因素影響。對此，若設每個獨立應用均存在M個評價指標，且所有評價指標皆存在R個離散取值，由此可構建應用所對應的偏好矩陣“G”：

上式中：gmr代表用戶對某個應用特性m的偏好程度，gmr∈ [0，1]。

若用0表示用戶對某項特性的反感，1表用戶喜歡某項特性，則m∈｛1,2，…,M｝，r∈｛1,2…,R｝。W=[W1W2…WM]，表示評價指標M的權重值矩陣，則用戶對云原生下第n個應用的偏好性為：

上式中：ε表示用戶的偏好性影響因子；λ表示云原生應用商對某項微服務給出的租用比例。

若設“Q”為評價指標的取值數量，且Q能夠自行設定，則結合大數定律可認為當Q趨于無窮大時，存在收斂常數值“Bn”，即：

2.3 云原生應用能耗

用能耗表示云原生應用平臺在應用中可造性的取舍值，即取舍值越大表示改造后的云原生應用平臺仍存在數據資源訪問不均的問題，需要重新進行改進，取舍值越小表示改造后云原生應用平臺數據訪問均勻，數據調用響應率高。從云原生應用平臺的開發角度來看，開發方向主要以微服務開發為主，并以維持云原生應用平臺穩定運行為工作方向，推進該技術的發展。由此，可將云原生應用平臺的能耗用運行能耗Er和微服務開發能耗Ed進行代替，則云原生應用平臺的能耗總量為：

上式中：emr表示單位時間內微服務運行產生的能耗；etr表示單位時間內傳統應用運行產生的能耗；tdev表示微服務開發的時間；trun表示應用運行的時間；eidle表示系統空閑時應用待機所帶來的能耗；Ttotal表示云原生平臺應用開發與運行的總耗時。

2.4 應用無狀態化

無狀態應用（Stateless Application）指不會在會話中保存下次會話中需要的客戶端數據，每個會話都像首次執行一樣，不會依賴之前的數據響應，其使分布式水平擴展成為可能。應用無狀態化的優勢在于能在應用平臺出現故障時輕松部署，并且能自由的水平擴展來適應負載，在組建之間也可通過API進行通信。云原生應用平臺中微服務是重要組成元素之一，無狀態應用可以很好地結合微服務來完成各項服務[8]。

2.5 熱數據緩存

根據數據的使用頻度可分為熱數據、溫數據、冷數據，熱數據一般指半年以內的數據，此類數據經常會被用戶查詢，適合放在數據庫中存儲。在實際的應用中，傳統的方式是在程序啟動時調用熱數據，從而提高數據的訪問速度，但由于數據的量不受控制，若數據量過大，可能就會導致程序啟動過慢，影響程序的使用感。基于此，云原生應用平臺將熱數據放到緩存中，一方面減少了數據庫的存儲量，另一方面能提高程序的啟動速度，使程序的可用性提高。

2.6 網絡梳理

應用容器化之后需進行相應的網絡梳理和規劃，用以保證其正常運行。在進行網絡梳理時，首先應根據容器平臺的情況將其進行分類，通常可分為管理集群master、計算集群slave、系統服務集群（包括各種日志、監控、鏡像倉庫等），根據網絡的使用，可將管理集群和系統服務集群劃入管理IP網段，將計算機群劃入業務IP網段，通過區分不同集群所處的IP網段，對各組件的端口進行規劃，從而保證網絡運行通暢。同時，針對不同應用的特性，應選擇不同的網絡模式，從而使其能提供更好的服務。

2.7 docker的改進優化

云原生下docker容器服務器集群的響應性能可影響其平臺的延時波動，可通過動態負載容器服務器算法給予優化。該方法以WRR負載算法為基礎，通過融合實時權值理念彌補WRR算法權值給定上的缺失。通過優化容器連接數、CPU、內存、網絡IO以及平均相應的方式得出docker的實時權值，由此得到docker容器服務器的最優ID，以此承擔云原生應用活動的負載。通過分攤流量的方式均衡訪問造成數據流的過載問題，利用容器服務器和算法的彈性優勢吸納服務器集群并發產生的訪問壓力。由此，可在用戶偏好集中在某一活動，且無法通過上述方法給予分量時，維持云原生平臺應用的響應效率。

2.8 確定域名、端口、TCP和HTTP協議

考慮到云原生平臺的特殊性，在平臺下各應用容器化之后應當保證每個服務只承擔一個服務內容。避免采用IP的方式，因服務與其他目標服務進行通訊會受到容器IP不固定因素影響而出現無法通訊的情況。對此，本文建議應當在程序中通過使用域名的方式代替IP地址，并借助Kubernetes的負債均衡給予優化。在系統的監聽固定端口方面，對于一個標準的服務應當只為其提供一個對外的端口，因部分服務在運行時會自主產生一些對外的端口，并且產生概率具有較高的隨機性，會對之后的平臺管理造成極大地困擾。在通信協議方面應當盡量采用TCP和HTTP協議進行交互，而避免使用EJB調用t3協議，進而避免無法借助負載均衡器的方式進行有效的負載均衡。對此，本文建議使用TCP或HTTP協議的方式進行通信，以此提高使用負載均衡器的有效負載均衡效果。

3 實驗驗證

為驗證上述改造架構的可行性與實用性，將構建仿真地域云原生應用平臺的實驗環境，主體架構使用當地原有結構框架，選取某階段下用戶實際需求作為評價參數。測試實驗主要以端到端形式為主，通過仿真模擬外圍環境發起的需求相應數據調用測試環境，驗證改造后訪問層的解析效率，進而判斷改造后數據訪問層的實際能力。為彰顯本文所提方法的優化效果，本文將以普通數據庫作為實驗對照，將兩種方法置于相同實驗環境下進行測試，以需求響應時間為判斷標準，測試結果見表1和表2。

表1 本文所提方法的性能測試結果

表2 普通數據庫的性能測試結果

由上表1和表2中數據可知，云原生平臺應用數據訪問層改造后響應效率較高，當并發數增加值90時，平均請求反應時間仍未超過95 ms，而普通數據庫的需求命令數據調用效率在并發數處于40時便超過95 ms。將測試數據轉化為折線圖見圖3。

由上圖數據可看出，兩種方法在并發數增加至60時整體性能處于相對穩定狀態，改造后的數據訪問層需求響應速率性能是普通數據庫性能的1.3倍。由此可證明本文所提方法具有較高的實用性，可應用于云原生應用平臺的優化項目當中。

4 結語

綜上所述，本文通過對云原生平臺應用可造性的研究，提高其數據訪問層的響應速率。結合現階段云原生應用現狀引入應用流行度、用戶偏好性和應用能耗等改造指標，通過對任務需求效率分析，明確空間下云原生平臺應用數據調用效率的影響因素，以此分析解決改造后云原生平臺出現的異常情況。從實驗結果可看出，本文所提方法能夠有效提高系統數據調用的響應效率，證明所提方法具有較高的可行性與實用性，能夠為相關人員或單位提供參考。