前端通訊：ajax設計方案（七）--- 增長請求錯誤監控、前端負載均衡以、請求宕機切換以及迭代問題修復

距離上個迭代過了很長時間，中間經歷了不少事情，也在每一個空餘時間構思了這個迭代的東西以及下個迭代要作的東西。時間週期稍微長了，望見諒。

並且，至今這個開源庫的start也已經到了165個了，會支持關注和研究的。

 

首先解決了上個迭代遇到的問題進行完善和修復：

1. 上個迭代作ajax timeout設置的時候，手抖將timeout不當心設置成timeoutEvent，這期作了修復

2. 解決全局配置中配置額外參數，批量檢查時會參數錯誤問題。

 

引入新的功能：

1. 增長瀏覽器發送請求的錯誤監控和蒐集

應用場景：

前端開發依賴的東西比較多，好比宿主環境（瀏覽器）、以及數據接口（本身服務器或者第三方Api等等），上個迭代進行了瀏覽器錯誤蒐集，能夠分析用戶在不一樣環境下宿主的使用率和差別以及問題。可是對於用戶的數據請求一直沒有作監控，由於用戶在不一樣的場景、網絡情況下乃至在開發或者發佈中將接口地址寫錯了，致使出現問題。

 

全局配置：

errStatus: { isOpenErr: true,    // 是否開啓錯誤蒐集
  errURL: 'http://localhost:8072',    // 錯誤蒐集地址
},

 

代碼以下：

    //監控ajax請求的錯誤日誌
    uploadAjaxError: function (obj) { // 過濾錯誤接口
      if (initParam.errStatus.isOpenErr) { if (obj.errUrl !== initParam.errStatus.errURL) { tempObj.post(initParam.errStatus.errURL, obj) } } // 記錄錯誤信息，以便策略作判斷
      if (selfData.errAjax[obj.errUrl] === undefined) { selfData.errAjax[obj.errUrl] = 1 } else { selfData.errAjax[obj.errUrl] += 1 } // 判斷是否開啓服務切換，以及驗證策略切換
      if (initParam.serviceSwitching.isOpen){ // 驗證策略
        selfData.isNeedSwitching = initParam.serviceSwitching.strategies(selfData.errAjax) } }

 

覆蓋面以及數據：

請求的錯誤蒐集，將覆蓋4xx、5xx、0、onerror以及timeout狀態

PS：在瀏覽器api中，只讀屬性 XMLHttpRequest.status 返回了XMLHttpRequest 響應中的數字狀態碼。status 的值是一個無符號短整型。在請求完成前，status的值爲0。值得注意的是，若是 XMLHttpRequest 出錯，瀏覽器返回的 status 也爲0。

連接：XMLHttpRequest.status

 

數據上傳格式：

  /* * 請求錯誤蒐集 * type：錯誤類型 * errInfo：錯誤的請求參數 * errLine：請求狀態 * Browser：宿主環境（瀏覽器） */ tool.uploadAjaxError({ type: 'request', errInfo: JSON.stringify(ajaxSetting.data), errLine: xhr.status, Browser: navigator.userAgent })

 

 

測試結果：

a. onerror錯誤：

 

 

b. 4XX錯誤、5XX錯誤、0錯誤

 

 

c. timeout錯誤

 

 2. 前端負載均衡（將請求均衡打到不一樣的服務器上）

 應用場景：

如今不少公司更多使用ngx作負載均衡，使用node第一層hold住全部流量，而後經過ngx進行分發到不一樣的服務器上作負載，避免在一臺服務器上讀寫形成資源競爭等等，結構以下圖：

可是，若是在超大流量的一種情況下，前端做爲請求的發出方，徹底有能力在發出階段就將請求打到不一樣的負載服務器上，而後再經過ngx再進行二次負載均衡，結構以下如：

全局配置：

// 負載均衡配置
loadBalancing: { isOpen: false,   // 是否開啓負載
  cluster: ['http://localhost:8076','http://localhost:8099']  // 配置地址
},

 

代碼實現：

    /* * 判斷是否爲其餘域的請求 * * 改方法中處理負載均衡方案 * 1. 對於先後端分離，直接請求域名的方案 支持 * 2. 對於直接請求本服務器的請求，暫時不作處理，讓ngx作負載均衡 不支持 * * */ checkRealUrl: function (param, that) { var temp; if (/http:\/\/|https:\/\//.test(param.url)) { temp = param.url; // 針對請求，負載均衡到配置域名 PS:負載均衡優先級 > 宕機切換優先級
        if (param.errStatus.errURL !== temp){ // 錯誤蒐集接口都不走
          if (param.loadBalancing.isOpen){  // 負載打開確定走負載
            temp = param.url.replace(/^(http:\/\/|https:\/\/)/, '') .replace(/^.*?\//, param.loadBalancing.cluster[tool.random(param.loadBalancing.cluster.length - 1, 0)] + '/$`') }else{ // 若是負載沒開，宕機切換打開，則走介個
            if (param.serviceSwitching.isOpen && selfData.isNeedSwitching){ temp = param.url.replace(/^(http:\/\/|https:\/\/)/, '') .replace(/^.*?\//, param.serviceSwitching.backupUrl + '/$`') } } } } else { temp = param.baseURL + param.url if (param.errStatus.errURL !== temp){ if (param.loadBalancing.isOpen){ temp = param.loadBalancing.cluster[tool.random(param.loadBalancing.cluster.length - 1, 0)] + param.baseURL + param.url }else{ // 若是負載沒開，宕機切換打開，宕機策略成功則走介個
            if (param.serviceSwitching.isOpen && selfData.isNeedSwitching){ temp = param.serviceSwitching.backupUrl + param.baseURL + param.url } } } } that.currentUrl = temp return temp; },

 

隨機函數校驗：

由於前端須要經過一個僞隨機數隨機獲取一個數值，而後經過這個數值去取負載配置的域名，爲了保證隨機打點的均衡性，這裏將測試在指數級增加下隨機打點5次的情況

 

測試代碼：

// 僞隨機數函數
random(max, min) { return Math.floor(Math.random() * (max - min + 1) + min); },

 

案例：

a. 隨機5個，10次

b. 隨機5個，100次

c. 隨機5個，1000次

d. 隨機5個，10000次

e. 隨機5個，100000次

 

結果：在指數級增加的過程當中，打點愈來愈均衡，相對僞隨機數的分佈取值也愈來愈均衡

 

 

測試結果：

 

 3.  宕機切換（支持策略）

 應用場景：

在平常用戶使用請求接口的時候，用戶在點擊一個按鈕的時候，若是一次接口請求失敗，在人性角度去看，用戶確定會再一次去點擊觸發請求，屢次按了都沒效果，纔會確認這個功能是沒用的。若是，在這個時候，這個場景下，用一個正確的策略在用戶點擊時候，若是本地請求失敗，支持切換備用域名，這樣能夠有效的挽回流失用戶。

 

全局配置：

// 宕機切換
serviceSwitching:{ isOpen: false,    // 是否開啓
  // 宕機策略（data爲記錄的錯誤請求以及數量，若是達到策略返回true，不然false）
  strategies:function (data) { let num = 0
      for (var key in data){ num = data[key] } if (num === 5){ return true }else{ return false } }, backupUrl:'http://localhost:8033'     // 備用域名
},

 

代碼實現：

同負載均衡的那一大堆代碼，能夠向上看。

 

測試案例（在策略中我綁定了若是錯誤連續積累5次以後將切換備用接口）：

 

 

總結：這一期的迭代需求中已經將ajax所能涉及的應用場景所有挖掘的快消耗殆盡了，若是還有什麼使用場景，能夠去github提個issues。

github地址：https://github.com/GerryIsWarrior/ajax    能夠點個star，持續研究下去

 

號外：有一次的測試中，意外忽然發現，一個使用過的請求對象是能夠重複利用的，並且一套建立流程從2000多毫秒一會兒降級到200毫秒了，so，下一次迭代將所一個請求鏈接池，重複利用每次建立完成的對象，將每次的請求速度縮短到更快的一個層次，期待中...