前端菜鳥讓接口提速60%的優化技巧案例

小編給大家分享一下前端菜鳥讓接口提速60%的優化技巧案例，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！

平均調用時間在3s以上

導致頁面出現嚴重的轉菊花

經過各種深度剖析與專業人士答疑

最后得出結論是：放棄醫療

魯迅在《狂人日記》里曾說過：“能打敗我的，只有女人和酒精，而不是bug”

每當身處黑暗之時

這句話總能讓我看到光

所以這次要硬起來

我決定做一個node代理層

用下面三個方法進行優化：

• 按需加載 -> graphQL

• 數據緩存 -> redis

• 輪詢更新 -> schedule

代碼地址：github

按需加載 -> graphQL

天秀老接口存在一個問題，我們每次請求1000條數據，返回的數組中，每一條數據都有上百個字段，其實我們前端只用到其中的10個字段而已。

如何從一百多個字段中，抽取任意n個字段，這就用到graphQL。

graphQL按需加載數據只需要三步：

• 定義數據池 root
• 描述數據池中數據結構 schema
• 自定義查詢數據 query

定義數據池

我們針對屌絲追求女神的場景，定義一個數據池，如下：

// 數據池var root = {    girls: [{        id: 1,        name: '女神一',        iphone: 12345678910,        weixin: 'xixixixi',        height: 175,        school: '劍橋大學',        wheel: [{ name: '備胎1號', money: '24萬元' }, { name: '備胎2號', money: '26萬元' }]
    },
    {        id: 2,        name: '女神二',        iphone: 12345678910,        weixin: 'hahahahah',        height: 168,        school: '哈佛大學',        wheel: [{ name: '備胎3號', money: '80萬元' }, { name: '備胎4號', money: '200萬元' }]
    }]
}復制代碼

里面有兩個女神的所有信息，包括女神的名字、手機、微信、身高、學校、備胎集合等信息。

接下來我們就要對這些數據結構進行描述。

描述數據池中數據結構

const { buildSchema } = require('graphql');// 描述數據結構 schemavar schema = buildSchema(`
    type Wheel {
        name: String,
        money: String
    }
    type Info {
        id: Int
        name: String
        iphone: Int
        weixin: String
        height: Int
        school: String
        wheel: [Wheel]
    }
    type Query {
        girls: [Info]
    }
`);復制代碼

上面這段代碼就是女神信息的schema。

首先我們用type Query定義了一個對女神信息的查詢，里面包含了很多女孩girls的信息Info，這些信息是一堆數組，所以是[Info]

我們在type Info中描述了一個女孩的所有信息的維度，包括了名字(name)、手機(iphone)、微信(weixin)、身高(height)、學校(school)、備胎集合(wheel)

定義查詢規則

得到女神的信息描述(schema)后，就可以自定義獲取女神的各種信息組合了。

比如我想和女神認識，只需要拿到她的名字(name)和微信號(weixin)。查詢規則代碼如下：

const { graphql } = require('graphql');// 定義查詢內容const query = `
    { 
        girls {
            name
            weixin
        }
    }
`;// 查詢數據const result = await graphql(schema, query, root)復制代碼

篩選結果如下：

又比如我想進一步和女神發展，我需要拿到她備胎信息，查詢一下她備胎們(wheel)的家產(money)分別是多少，分析一下自己能不能獲取優先擇偶權。查詢規則代碼如下：

const { graphql } = require('graphql');// 定義查詢內容const query = `
    { 
        girls {
            name
            wheel {
            	money
            }
        }
    }
`;// 查詢數據const result = await graphql(schema, query, root)復制代碼

篩選結果如下：

我們通過女神的例子，展現了如何通過graphQL按需加載數據。

映射到我們業務具體場景中，天秀接口返回的每條數據都包含100個字段，我們配置schema，獲取其中的10個字段，這樣就避免了剩下90個不必要字段的傳輸。

graphQL還有另一個好處就是可以靈活配置，這個接口需要10個字段，另一個接口要5個字段，第n個接口需要另外x個字段

按照傳統的做法我們要做出n個接口才能滿足，現在只需要一個接口配置不同schema就能滿足所有情況了。

感悟

在生活中，咱們舔狗真的很缺少graphQL按需加載的思維

渣男渣女，各取所需

你的真情在名媛面前不值一提

我們要學會投其所好

上來就亮車鑰匙，沒有車就秀才藝

今晚我有一條祖傳的染色體想與您分享一下

行就行，不行就換下一個

直奔主題，簡單粗暴

緩存 -> redis

第二個優化手段，使用redis緩存

天秀老接口內部調用了另外三個老接口，而且是串行調用，極其耗時耗資源，秀到你頭皮發麻

我們用redis來緩存天秀接口的聚合數據，下次再調用天秀接口，直接從緩存中獲取數據即可，避免高耗時的復雜調用，簡化后代碼如下：

const redis = require("redis");const { promisify } = require("util");// 鏈接redis服務const client = redis.createClient(6379, '127.0.0.1');// promise化redis方法，以便用async/awaitconst getAsync = promisify(client.get).bind(client);const setAsync = promisify(client.set).bind(client);async function list() {	// 先獲取緩存中數據，沒有緩存就去拉取天秀接口
	let result = await getAsync("緩存");    if (!result) {    	  // 拉接口
    	  const data = await 天秀接口();
          result = data;          // 設置緩存數據
          await setAsync("緩存", data)
    }   	return result;
}

list(); 

復制代碼

先通過getAsync來讀取redis緩存中的數據，如果有數據，直接返回，繞過接口調用，如果沒有數據，就會調用天秀接口，然后setAsync更新到緩存中，以便下次調用。因為redis存儲的是字符串，所以在設置緩存的時候，需要加上JSON.stringify(data)，為了便于大家理解，我就不加了，會把具體細節代碼放在github中。

將數據放在redis緩存里有幾個好處

可以實現多接口復用、多機共享緩存

這就是傳說中的云備胎

追求一個女神的成功率是1%

同時追求100個女神，那你獲取到一個女神的概率就是100%

魯迅《狂人日記》里曾說過：“舔一個是舔狗，舔一百個你就是戰狼”

你是想當舔狗還是當戰狼？

來吧，緩存用起來，redis用起來

輪詢更新 -> schedule

最后一個優化手段：輪詢更新 -> schedule

女神的備胎用久了，會定時換一批備胎，讓新鮮血液進來，發現新的快樂

緩存也一樣，需要定時更新，保持與數據源的一致性，代碼如下：

const schedule = require('node-schedule');// 每個小時更新一次緩存schedule.scheduleJob('* * 0 * * *', async () => {    const data = await 天秀接口();    // 設置redis緩存數據
    await setAsync("緩存", data)
});復制代碼

天秀接口不是一個強實時性接口，數據源一周可能才會變一次

所以我們根據實際情況用輪詢來設置更新緩存頻率

我們用node-schedule這個庫來輪詢更新緩存，* * 0 * * *這個的意思就是設置每個小時的第0分鐘就開始執行緩存更新邏輯，將獲取到的數據更新到緩存中，這樣其他接口和機器在調用緩存的時候，就能獲取到最新數據，這就是共享緩存和輪詢更新的好處。

早年我在當舔狗的時候，就將輪詢機制發揮到淋漓盡致

每天向白名單里的女神，定時輪詢發消息

無限循環云跪舔三件套：

• “啊寶貝，最近有沒有想我”
• “啊寶貝早安安”
• “寶貝晚安，么么噠”

雖然女神依然看不上我

但仍然時刻準備著為女神服務

結尾

經過以上三個方法優化后

接口請求耗時從3s降到了860ms

這些代碼都是從業務中簡化后的邏輯

真實的業務場景遠比這要復雜：分段式數據存儲、主從同步 讀寫分離、高并發同步策略等等

每一個模塊都晦澀難懂

就好像每一個女神都高不可攀

屌絲戰勝了所有bug，唯獨戰勝不了她的心

受傷了只能在深夜里獨自買醉

但每當夢到女神打開我做的頁面

被極致流暢的體驗驚艷到

在精神高潮中享受靈魂升華

那一刻

我覺得我又行了

（完）

以上是前端菜鳥讓接口提速60%的優化技巧案例的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注億速云行業資訊頻道！