99%的程序都沒有考慮的網絡異常

HollisChuang 發布于2019-08-23 14:19 / 2047人閱讀

摘要：本文由云社區發表絕大多數程序只考慮了接口正常工作的場景，而用戶在使用我們的產品時遇到的各類異常，全都丟在看似的中。在面板，還可以對請求進行暫停延遲等網絡異常的模擬。小程序實現最后，留一道思考題。

本文由云+社區發表

絕大多數程序只考慮了接口正常工作的場景，而用戶在使用我們的產品時遇到的各類異常，全都丟在看似 ok 的 try catch 中。如果沒有做好異常的兼容和兜底處理，會極大的影響用戶體驗，嚴重的還會帶來安全和資損風險。

接口異常，通常可以分為以下三類：

CGI 邏輯出錯。如調用方入參缺失類業務邏輯報錯；

服務不穩定。如服務器不穩定導致 nginx 各類 500、502，cgi 路徑調整導致的 404

用戶網絡環境差。如，網絡不穩定、網速慢、運營商劫持等

那么，我們在寫代碼時，如何快速的模擬這些接口異常，做好程序的兼容處理呢？

今天向大家介紹網絡調試神器 whistle 的網絡異常調試方法，如果你還沒用過 whistle，請參考《8102 年的程序員不需要 Hosts 和 Fiddler》。

假設我們有以下前端頁面 index.html，放置在自己的本地路徑：

接下來，打開 whistle Rules 配置面板 http://127.0.0.1:8899/#rules ，配置模擬的 demo page 和 mock CGI：

*/mock file://({"code":0,"data":"success"}) # 配置 mock cgi 為模擬的 json 數據
example.com file:///Users/kaiye/Projects/Markdown/20181213/ # 配置任意域名到本地 demo 目錄，這里注意替換成自己的路徑

打開 http://example.com ，正常邏輯下頁面展示出了綠色的 success ，現在我們開始加入一些網絡異常。

1、業務邏輯異常處理

例如 CGI 沒有返回 data 字段，而是返回了一個錯誤碼 code 和對應的 message，針對這種業務邏輯異常我們只需在第二個 then 中做好 code 值的判斷即可（注意，這里的 code、message、data 只是示例，實際業務 CGI 中的 JSON 結構體的字段名很可能不同）：

fetch(`/mock?r=${Math.random()}`)
  .then(response => response.json())
  .then((v) => {
    // 業務邏輯異常處理
    if (v.code !== 0) {
      return Promise.reject(new Error(`ERROR_LOGIC_CODE:${v.code}`));
    }
    document.getElementById("success").innerHTML = v.data;
  })
  .catch((err) => {
    document.getElementById("fail").innerHTML = err.message;
  });

相應的 whistle 配置如下：

*/mock file://({"code":12345,"message":"some_logic_error"}) # 模擬業務邏輯異常

2、服務器異常處理

如果服務器直接拋出了 502 錯誤碼，我們希望代碼能給用戶提示的同時，再做一個異常上報。

fetch(`/mock?r=${Math.random()}`)
  .then((response) => {
    // 服務器異常處理
    if (response.ok) {
      return response.json();
    }
    return Promise.reject(new Error(`ERROR_STATUS_CODE:${response.status}`));
  })
  .then((v) => {
    // 業務邏輯異常處理
    if (v.code !== 0) {
      return Promise.reject(new Error(`ERROR_LOGIC_CODE:${v.code}`));
    }
    document.getElementById("success").innerHTML = v.data;
  })
  .catch((err) => {
    const [type, value] = err.message.split(":");
    // 異常類型上報
    console.log(type, value);
    document.getElementById("fail").innerHTML = err.message;
  });

通過 whistle 的模擬配置如下：

*/mock statusCode://502 # 模擬 HTTP 狀態碼異常

3、接口被劫持注入

如果 CGI 被運營商劫持注入，可能導致接口返回一個不合法的 JSON 結構，最前面的 response.json() 會拋異常，我們可以提前 catch 住：

fetch(`/mock?r=${Math.random()}`).then((response) => {
  // 服務器異常處理
  if (response.ok) {
    return (
      response
        .json()
        // 接口數據解碼異常處理
        .catch(err => Promise.reject(new Error("ERROR_DECODE_JSON")))
    );
  }
  return Promise.reject(new Error(`ERROR_STATUS_CODE:${response.status}`));
});

whistle 模擬配置如下：

*/mock file://(hijacking
{"code":0,"data":"success"}) # 模擬接口被劫持注入 1

借助 htmlAppend 和 values 配置，可以模擬更復雜的注入示例：

*/mock file://({"code":0,"data":"success"}) htmlAppend://{hijacking.html} # 模擬接口被劫持注入 2

4、用戶網絡不穩定

如果我們要模擬請求發出 10 秒后斷網或網絡不通的情況，可以通過 whistle 這樣配置：

*/mock reqDelay://10000 enable://abort # 模擬 10 秒超時后網絡不通

讓用戶苦苦等待 10 秒，再報錯的體驗太糟糕。我們可以封裝一個能配置超時時間的請求發送函數，同時把上面提到的錯誤異常都一起配置進來。

這樣，自定義的 myFetch 只需關注業務具體邏輯，針對不同的 catch error 做對應的處理。

除以上提到的協議命令字外，whistle 還支持 resSpeed 用于模擬低網速傳輸（單位：kb/s），tpl 協議則可以根據請求傳入參數來動態模擬不同的數據。在 Frames 面板，還可以對 WebSocket/Socket 請求進行暫停、延遲等網絡異常的模擬。

小程序 fetch API 實現

最后，留一道思考題。

近來微信小程序開發非常火，小程序原生提供的 wx.request API 能用于發送 HTTPS 請求，請在它的基礎之上進行封裝，支持 promise 調用和 timeout 超時時間定義（小程序默認的請求超時定義在 app.json 中，不夠靈活），并針對以上提到的 HTTP 狀態碼異常、接口劫持注入、慢網絡、無網絡狀態等各種網絡異常進行兼容處理。

歡迎留言分享你的代碼實現

此文已由作者授權騰訊云+社區發布

GPU云服務器云服務器沒有備案的小程序需要考慮的因素有有沒有免費的小程序沒有網絡的云服務器

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/100424.html

99%的程序都沒有考慮的網絡異常？使用Fundebug.notify()主動上報

摘要：而且官方也給出了示例在回調函數中上報異常為了確保完全掌握小程序的運行狀況，我們將異常上報。的微信小程序插件除了可以自動捕獲異常外，還支持通過接口主動上報異常。近日看到一篇文章99%的程序都沒有考慮的網絡異常，開篇提到：絕大多數程序只考慮了接口正常工作的場景，而用戶在使用我們的產品時遇到的各類異常，全都丟在看似 ok 的 try catch 中。如果沒有做好異常的兼容和兜底處理，會極...

ChanceWong 2019-08-23 18:32 評論0 收藏0
道路千萬條，安全第一條——一次服務器被入侵的處理經過

摘要：為了進一步確認，再次到威脅情報平臺進行查詢。再結合我部署的容器停止時間進行分析，應該是在我部署完成后幾小時內服務器被入侵的。要從根本上解決問題需要進行溯源分析，避免服務器再次被入侵。結合以上線索以及個人經驗分析，很可能利用的漏洞進行入侵的。容器為何自動停止？服務器為何操作卡頓？進程的神秘連接到底指向何處？發現——自動停止的容器某日發現部署在服務器上的一個容器被停掉了，開始以為...

aaron 2019-06-28 17:19 評論0 收藏0
rancher的使用感受以及與k8s的對比

摘要：但的數據存在，而的數據存儲暫未了解但肯定是存在內存中。測試對比物理機進程。當然，使用對容器進行編排的時候，可以指定任何想要的網絡方式如采用的方式，，。簡介： rancher 自帶了一套網絡方案，可以實現跨機器的docker容器互聯。其原理大致是：在每個機器上通過docker啟動一個路由容器，將docker容器啟動時的ip定義為10.42網段，并在iptables中將10.42網段的請...

dingda 2019-07-01 17:26 評論0 收藏0
rancher的使用感受以及與k8s的對比

摘要：但的數據存在，而的數據存儲暫未了解但肯定是存在內存中。測試對比物理機進程。當然，使用對容器進行編排的時候，可以指定任何想要的網絡方式如采用的方式，，。簡介： rancher 自帶了一套網絡方案，可以實現跨機器的docker容器互聯。其原理大致是：在每個機器上通過docker啟動一個路由容器，將docker容器啟動時的ip定義為10.42網段，并在iptables中將10.42網段的請...

_ang 2019-06-28 15:08 評論0 收藏0
一文梳理 RedHat 和 CentOS 運維中的網絡知識

摘要：一系統運維中網絡方面的規劃與思考在很多公司，崗位職責都是很明確的，專職轉崗，每人或者每組負責一塊業務。二系統運維中網絡方面操作梳理在系統運維中，經常涉及的網絡方面的操作，一般由以下幾個方面組成。初步意見，交換機上線這臺機器所連端口。運維是一門藝術，也是一門苦差事，每個人對此均有不同的理解，正所謂一千個人眼中有一千個哈姆雷特。干一行就要愛一行，既然選擇了這個行業，較好是能把它做到較好，發揮自己...

Olivia 2019-04-25 17:24 評論0 收藏0