[發(fā)明專利]分散數(shù)據(jù)微服務(wù)自動化運維體系

有效

• 申請?zhí)枺?/td>: 202110365528.9
• 申請日: 2021-04-06
• 公開（公告）號: CN112804362B
• 公開（公告）日: 2021-06-22
• 發(fā)明（設(shè)計）人: 張錦;唐杰;黃逸奇;李希;徐大宏
• 申請（專利權(quán)）人: 湖南師范大學(xué)
• 主分類號: H04L29/08
• 分類號: H04L29/08
• 代理公司: 長沙市護航專利代理事務(wù)所(特殊普通合伙) 43220
• 代理人: 謝新苗

本發(fā)明提供了分散數(shù)據(jù)微服務(wù)自動化運維體系，包括自動運維系統(tǒng)及邊緣網(wǎng)關(guān)，所述自動運維系統(tǒng)與kubernetes貼合使用，能夠控制pod伸縮貼合微服務(wù)，實時對kubernetes做出資源調(diào)配動作，多個所述微服務(wù)通過所述邊緣網(wǎng)關(guān)與外部連網(wǎng)，所述邊緣網(wǎng)關(guān)為統(tǒng)一管理處理微服務(wù)的路由網(wǎng)關(guān)。本發(fā)明既能解決Pod動態(tài)伸縮提高資源利用率的問題，也能解決微服務(wù)本身高并發(fā)在更換部署環(huán)境后所面臨的問題，同時也要簡化運維配置，提高工作效率。

技術(shù)領(lǐng)域

本發(fā)明涉及微服務(wù)資源配置技術(shù)領(lǐng)域，特別涉及基于kubernetes（一個開源的，用于管理云平臺中多個主機上的容器化的應(yīng)用，Kubernetes的目標(biāo)是讓部署容器化的應(yīng)用簡單并且高效，Kubernetes提供了應(yīng)用部署，規(guī)劃，更新，維護的一種機制）的分散數(shù)據(jù)微服務(wù)自動化運維體系。

背景技術(shù)

在當(dāng)今社會，各行各業(yè)的應(yīng)用“互聯(lián)網(wǎng)+”的規(guī)模越來越大，很多行業(yè)應(yīng)用產(chǎn)生的數(shù)據(jù)已經(jīng)遠(yuǎn)遠(yuǎn)超出傳統(tǒng)企業(yè)的數(shù)據(jù)處理能力，傳統(tǒng)的單體架構(gòu)無法承受大量用戶的訪問使用，微服務(wù)應(yīng)運而生。微服務(wù)作為一套新的架構(gòu)風(fēng)格，將單個應(yīng)用程序開發(fā)劃為一組細(xì)粒的服務(wù)，每個服務(wù)運行在自己的進程中，服務(wù)間有著約定的輕量級通信機制進行交互，一般是HTTP（超文本傳輸協(xié)議，HyperText Transfer Protocol）資源API（應(yīng)用程序接口，Application Programming Interface）作為通信機制，圍繞業(yè)務(wù)功能構(gòu)建服務(wù)并且獨立部署，從而組成一個完整的系統(tǒng)平臺為用戶提供服務(wù)。微服務(wù)有著業(yè)務(wù)粒度小、職責(zé)單一、隔離性強、去中心化管理、易管理等特點，但在構(gòu)建、部署和運維上出現(xiàn)不少難題，就部署而言，微服務(wù)的單一應(yīng)用實例數(shù)量過多，相應(yīng)的部署配置和監(jiān)控的體量也就更大，并且一個應(yīng)用的修改會引起與之關(guān)聯(lián)的其他應(yīng)用的改動，從而造成部署復(fù)雜的情況。

從現(xiàn)有研究可以看出，針對kubernetes現(xiàn)有的問題很多學(xué)者提出了各自不同的解決方案，但總的來說，在有效的控制Pod（是一種簡單而易用的標(biāo)記型語言）伸縮、應(yīng)對實際應(yīng)用中遇到的多樣化數(shù)據(jù)以及針對高并發(fā)的分散數(shù)據(jù)微服務(wù)容器化部署kubernetes進行容器編排這樣業(yè)務(wù)需求等方面還可以有更大的改動空間。

當(dāng)前kubernetes認(rèn)為Pod是無狀態(tài)的，即同一Pod的副本完全一樣，這是實現(xiàn)Pod跨節(jié)點調(diào)度及Pod副本自動伸縮的前提。但是分散數(shù)據(jù)微服務(wù)破壞了這一前提，其Pod副本并不完全一致，以kubernetes設(shè)計理念推論，同一業(yè)務(wù)數(shù)據(jù)不同將被視為不同應(yīng)用，那么維護Pod工作量取決于業(yè)務(wù)數(shù)據(jù)量，當(dāng)需要修改業(yè)務(wù)部署配置時，要對相應(yīng)的多個Pod進行修改，即存在腳本同步更新問題，也需要大量的YAML（一種直觀的能夠被電腦識別的數(shù)據(jù)序列化格式，是一個可讀性高并且容易被人類閱讀，容易和腳本語言交互，用來表達(dá)資料序列的編程語言）配置文件和指令操作，因此運維過程復(fù)雜、效率低下。

HPA（HorizontalPodAutoscaling，水平自動伸縮）的方式是在kubernetes內(nèi)部運行，外部無法對其監(jiān)測控制，所以對運維人員來說是不可控的，這使得以后的運維工作增加了難度，從而運維人員不能更好地合理化利用資源。另外，當(dāng)微服務(wù)應(yīng)用部署在kubernetes時，kubernetes通過設(shè)置Ingress[一組路由規(guī)則的集合，Ingress是kubernetes API的標(biāo)準(zhǔn)資源類型之一，它其實就是一組基于DNS名稱（host）或URL路徑把請求轉(zhuǎn)發(fā)至指定的Service資源的規(guī)則，用于將集群外部的請求流量轉(zhuǎn)發(fā)至集群內(nèi)部完成服務(wù)發(fā)布]資源清單來暴露內(nèi)部的應(yīng)用服務(wù)，按照這種方式進行暴露，每個微服務(wù)的應(yīng)用都需要對外暴露，沒有統(tǒng)一的網(wǎng)關(guān)處理，就會導(dǎo)致所有接口向外開放，對系統(tǒng)的安全性能產(chǎn)生極大的威脅。

Kubernetes定義Pod為無狀態(tài)，所以分散數(shù)據(jù)架構(gòu)的微服務(wù)在Kubernetes中的Pod副本數(shù)據(jù)并不完全一致，同一業(yè)務(wù)數(shù)據(jù)不同被視為不同應(yīng)用，就存在運維過程復(fù)雜、效率低、不可控、不能更好地資源合理化利用、應(yīng)用安全性低等問題。

發(fā)明內(nèi)容