前端通讯：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，下一次迭代将所一个请求链接池，重复利用每次建立完成的对象，将每次的请求速度缩短到更快的一个层次，期待中...