隨著AI、大數(shu)據、云計算等技(ji)術的(de)興起，為了提供更良好的(de)企業(ye)個(ge)性(xing)化服務和個(ge)人(ren)定(ding)制化需求，數(shu)據存(cun)儲顯得尤(you)為重要(yao)，openapi的(de)穩定(ding)性(xing)使(shi)用(yong)是更重要(yao)的(de)一環(huan)。

云上數據庫(ku)為了(le)保證數據庫(ku)openapi的(de)(de)(de)高可用能力與自適應能力，往往是會存在openapi的(de)(de)(de)隱患問題，保證數據(ju)庫openapi系統的(de)(de)(de)穩(wen)定性高可用性成(cheng)了重中之(zhi)重。當前的(de)(de)(de)網關系統無法個性化的(de)(de)(de)針(zhen)對特定的(de)(de)(de)openapi進行熔斷(duan)監控(kong)(kong)，監控(kong)(kong)的(de)(de)(de)數據(ju)指標(biao)多是處理器、內存、硬盤等數據(ju)，缺少一套完(wan)整的(de)(de)(de)openapi熔斷(duan)監控(kong)(kong)方法。所(suo)以當大(da)規模調用openapi出現系統來(lai)不及響應，響應時(shi)間(jian)很(hen)慢或者出現服務器宕機等問題時(shi)，沒有(you)辦法做到用戶側(ce)及時(shi)感(gan)知，同時(shi)數據(ju)庫系統崩潰，極大(da)影響到用戶操(cao)作(zuo)。

基于以上問題(ti)，如何提供(gong)一種簡單部署、快速感(gan)知的openapi監(jian)控熔斷方案就成(cheng)了(le)亟需(xu)解決(jue)的問題(ti)。

三、發明(ming)創造的目的

本(ben)發明是針對現(xian)有(you)技術方案的(de)不(bu)足(zu)，基于(yu)sentinel和應用(yong)網(wang)關(guan)進行(xing)結合，通過sentinel進行(xing)對openapi某一時(shi)間采(cai)(cai)樣(yang)進行(xing)熔斷檢測(ce)，prometheus監控采(cai)(cai)集(ji)openapi調用(yong)數據(ju)Prometheus會根據(ju)進行(xing)監控數據(ju)計算，gafana然后可視(shi)化監(jian)控。

為(wei)實現基于應用(yong)網關和sentinel的熔斷(duan)以(yi)及(ji)gafana可視化監(jian)控能力,需要實現openapi的自(zi)適應(ying)熔斷監控，需要解決的技術難點(dian)主(zhu)要為以(yi)下兩(liang)點(dian)：

第一是自主(zhu)研發的應用網關，實現對(dui)于Prometheus的對openapi調用監控數據采集和sentinel的自定(ding)義的時間采樣(yang)熔斷規(gui)則(ze)。通過編(bian)寫(xie)熔斷規(gui)則(ze)綁(bang)定(ding)對應openapi，規(gui)則(ze)通過某一時間窗口采樣，對(dui)openapi超時(shi)響應比(bi)例和錯(cuo)誤比(bi)例來控制。

第二是實現應用網關自(zi)動化加載openapi能力和基于(yu)gafana的可視化監控。

五、發明創造的技術方(fang)案(an)

1. 本發明(ming)提供(gong)一種基于Prometheus，應用網關，sentinel的openapi的自適應的熔(rong)斷監控(kong)方案，并使用gafana作為可視化監控，其(qi)整體技術框架如(ru)附圖1：

附圖(tu)1.openapi熔(rong)斷(duan)監控整體(ti)流程(cheng)圖

通過應(ying)用(yong)網關(guan)web頁面斷路器的(de)熔斷規則(ze)如下，示例如下：

errorCondition: "$StatusCode == 500"  # 錯誤條件

errorThresholdByPercent: 20    # 用于控(kong)制(zhi)錯誤(wu)閾值的百分比

timeoutThresholdByPercent: 20   # 用于(yu)控(kong)制(zhi)后(hou)端超時請(qing)求的百分(fen)比

windowInSeconds: 30                   # 窗口時(shi)間

openTimeoutSeconds: 15              # 斷路器開的時間(jian)

downgradeBackend:               # 降級后的(de)后端配置

  type: mock

  statusCode: 403

3.通過ping-exporter組件的monitor模(mo)塊進行配(pei)置yaml文件來(lai)創建(jian)監測任務，負責(ze)監控(kong)機器實例。

附圖(tu)2.Prometheus拉取監控指標數(shu)據

2. 如附圖2所示，部(bu)署(shu)完(wan)ping-exporter之后(hou)，當用戶調用openapi時(shi)候，openapi監控(kong)指標數(shu)據(ju)(ju)會被拉(la)取到(dao)Prometheus，Prometheus會根據(ju)(ju)數(shu)據(ju)(ju)計算，然后(hou)gafana進(jin)行(xing)可視化監控(kong)處(chu)理。可以展(zhan)示對(dui)應openapi的(de)熔(rong)斷(duan)器的(de)開關狀(zhuang)態(tai)(tai)和(he)對應openapi返回(hui)的(de)狀(zhuang)態(tai)(tai)碼(ma)和(he)響應時間。

附圖3.熔斷器的狀(zhuang)態轉(zhuan)移(yi)

六、架構所(suo)具有的(de)優點和效(xiao)果。

利用本發(fa)明提供的(de)一種基于時間采樣應用網關openapi熔斷監控的方法，具(ju)有以(yi)下優(you)點：

本申請主要用于云計算數據庫openapi使用領域，由于傳(chuan)統(tong)的(de)網(wang)關監測并不(bu)(bu)能針對某個特定(ding)openapi進(jin)行熔斷降級處理(li)，不(bu)(bu)能滿足用戶自定(ding)義openapi后端處理(li)；基于Prometheus和(he)ping-exporter的(de)監控以及gafana可視化監控(kong)，使用的組件(jian)成熟，部署方式(shi)簡單，還可以(yi)及時讓用戶發現某個或者多個openapi熔(rong)斷(duan)狀態并及時做有(you)效處理，有(you)效的降(jiang)低了(le)經濟損失和(he)減少了(le)人力資源成(cheng)本。

七、實施例

1. 通(tong)過應用(yong)網關web頁面(mian)可以(yi)自(zi)定(ding)(ding)義斷(duan)路器規則。綁定(ding)(ding)經常(chang)報(bao)錯或者超(chao)時的openapi。

2. 將(jiang)ping-exporter二進制文件(jian)移至對(dui)應的源主(zhu)機，并修(xiu)改(gai)其為系統(tong)服務，設置開機自啟(qi)動。

3. 根據(ju)監控任務參數對ping-exporter配置文件(jian)動態修改。配置進(jin)行更新。

4. Prometheus拉(la)取(qu)實時的openapi調用數據(ju)。并在gafana進行可視化展示。