前言

作為Node語言的初學(xué)者去實(shí)踐后端開發(fā)時(shí)，不僅僅有見獵心喜，也有一些忐忑，好在大家都很open，給予了很多建議和分享，到目前為止，也成功建立了三個(gè)基于Node.js + TypeScript + IMServer   1   的工程，也是時(shí)候?qū)⒆约鹤罱膶W(xué)習(xí)過程進(jìn)行總結(jié)，下面就以一個(gè)小小的開發(fā)任務(wù)為載體分享下我的成長過程。

需求

在完成Node工程的搭建之后，我接受到第一個(gè)Node后臺開發(fā)任務(wù)：定時(shí)將企業(yè)微信的組織架構(gòu)信息拉取到業(yè)務(wù)數(shù)據(jù)庫系統(tǒng)中，并且提供手機(jī)號查詢用戶查詢接口。一開始對這個(gè)任務(wù)還是比較樂觀的，信心滿滿的去開發(fā)了。

初步方案

經(jīng)過方案設(shè)計(jì)之后形成了上述的方案：

1. 在服務(wù)器部署初始化時(shí)（init.ts初始啟動文件中）啟動node-schedule的定時(shí)任務(wù)，讀取數(shù)據(jù)庫中的企業(yè)微信的企業(yè)配置，然后并行啟動若干企業(yè)的組織架構(gòu)更新進(jìn)程。

2. 企業(yè)微信提供了獲取部門成員的詳情，因此只需并行更新每個(gè)部門的信息，并且寫入mysql數(shù)據(jù)庫中。

   

3. 當(dāng)查詢接口到達(dá)服務(wù)器后，首先從數(shù)據(jù)庫中查詢該手機(jī)號對應(yīng)的成員，若不存在則從企業(yè)微信側(cè)調(diào)用手機(jī)號獲取userid API，然后通過獲取用戶信息API獲取最新的用戶信息，避免定時(shí)更新帶來的更新時(shí)間gap；若存在則直接返回?cái)?shù)據(jù)庫中的信息。

   

開發(fā)過程中的踩雷

整體業(yè)務(wù)邏輯并不復(fù)雜，調(diào)試和部署的過程中遇到許多問題，這里給大家一一列舉下：

1. 訪問頻率受限

企業(yè)微信官方規(guī)定同一時(shí)間對同一份資源的請求數(shù)不可超過一定數(shù)值（60），由于部門詳情的請求接口采用的并行模式，因此超過了閾值，測試過程中被官方封禁了IP。

2. 過多進(jìn)程導(dǎo)致SQL慢查詢

沒有考慮多地部署（3地 * 5服務(wù)器 * 8 worker）導(dǎo)致同時(shí)存在了120個(gè)更新進(jìn)程，進(jìn)而導(dǎo)致數(shù)據(jù)庫mysql的讀寫混亂，也消耗了大量性能，導(dǎo)致數(shù)據(jù)庫讀寫壓力比較大時(shí)，出現(xiàn)了部分慢查詢的情況

3. 無效手機(jī)號不可調(diào)用企業(yè)微信api

企業(yè)微信對手機(jī)號獲取userid的接口，具有以下限制：當(dāng)查詢中出現(xiàn)一定數(shù)量的無效手機(jī)號時(shí)，會觸發(fā)企業(yè)微信官方IP封禁。但是業(yè)務(wù)系統(tǒng)中存在大量離職后的無效手機(jī)號，因此當(dāng)檢查到數(shù)據(jù)庫中不存在時(shí)，頻繁調(diào)用上述接口則會觸發(fā)封禁。

4. 數(shù)據(jù)庫讀寫沖突

由于存在多臺服務(wù)器同時(shí)讀寫數(shù)據(jù)庫，導(dǎo)致數(shù)據(jù)庫出現(xiàn)了部分重復(fù)、缺少的情況。

5. 網(wǎng)絡(luò)環(huán)境導(dǎo)致讀寫鎖的平衡性失效，產(chǎn)生衍生問題

為了優(yōu)化上述部分，引入的任務(wù)讀寫鎖，保證單一進(jìn)程更新。但是未考慮各地服務(wù)網(wǎng)絡(luò)情況，導(dǎo)致內(nèi)網(wǎng)服務(wù)器一直持有讀寫鎖，失去了均衡負(fù)載的設(shè)計(jì)有效性。也導(dǎo)致在配置預(yù)上線環(huán)境時(shí)，預(yù)上線環(huán)境由于網(wǎng)絡(luò)環(huán)境良好一直持有讀寫鎖，進(jìn)而影響線上的實(shí)時(shí)數(shù)據(jù)。

未考慮失敗情況進(jìn)行報(bào)警和恢復(fù)

深度優(yōu)化設(shè)計(jì)

下面介紹下如何解決這些問題和思路和方案。

1、訪問頻率受限

這里針對“部門成員信息API“的并行請求，改造成基于有效頻率值的串行發(fā)送機(jī)制，設(shè)計(jì)成10個(gè)/每秒的調(diào)用速度。

2、過多進(jìn)程導(dǎo)致SQL慢查詢

這個(gè)解決方案比較明確，就是減少啟動定時(shí)任務(wù)的進(jìn)程數(shù)。

由于后端服務(wù)一般分為測試環(huán)境、預(yù)上線環(huán)境、正式環(huán)境，不同的環(huán)境中是否需要啟動各個(gè)定時(shí)器腳本可以通過部署時(shí)（以SKTE為例）,設(shè)置環(huán)境變量 “SCHEDULE_ENV” 來管理。

每臺服務(wù)器會啟動8個(gè)worker進(jìn)程，每個(gè)worker使用 “ process.env.IMSERVER_WORKER_ID ” 變量進(jìn)行標(biāo)識，因此可以設(shè)計(jì)只有“worker1”進(jìn)程來進(jìn)行定時(shí)任務(wù)的啟動；

3、無效手機(jī)號不可調(diào)用企業(yè)微信api

這個(gè)是在技術(shù)調(diào)研中沒能發(fā)現(xiàn)的情況，發(fā)現(xiàn)前期技術(shù)調(diào)研的工作疏忽。

首先是業(yè)務(wù)調(diào)用方是無法得知手機(jī)號是否有效，且也不應(yīng)該去關(guān)心這個(gè)限制，因此原先為了解決部分新 紀(jì)錄更新不及時(shí)的問題，而引入的實(shí)時(shí)查詢機(jī)制是不合理的。

實(shí)時(shí)查詢機(jī)制：“對于數(shù)據(jù)庫中不存在的手機(jī)號，通過企業(yè)微信官方api進(jìn)行實(shí)時(shí)查詢來返回結(jié)果”

因此移除了這個(gè)機(jī)制，并且提供了一個(gè)基于企業(yè)微信官方API的實(shí)時(shí)查詢接口，每次業(yè)務(wù)方調(diào)用時(shí)，也將結(jié)果同步更新到組織架構(gòu)中。

4、數(shù)據(jù)庫讀寫沖突

引入redis任務(wù)鎖機(jī)制，保證同一時(shí)間內(nèi)只有一個(gè)進(jìn)程能夠進(jìn)行數(shù)據(jù)庫更新操作。

其次是企業(yè)之間的更新采用并行機(jī)制，由于相互之間是互不沖突的，因此不會引起同一條記錄的讀寫沖突，也可以提升其更新速度。

5、網(wǎng)絡(luò)環(huán)境導(dǎo)致讀寫鎖的平衡性失效，產(chǎn)生衍生問題

在最初的設(shè)計(jì)中，我希望服務(wù)器之間能夠根據(jù)自身的負(fù)載情況來進(jìn)行公平競爭任務(wù)鎖，但是實(shí)際情況是由于多地部署，其中穩(wěn)定的內(nèi)網(wǎng)環(huán)境可以一直優(yōu)先獲取到任務(wù)鎖，就是沒有所謂的公平性了。

特別是當(dāng)壓測需要部署預(yù)上線環(huán)境時(shí)，如果沒有設(shè)置只讀db賬號并且沒有設(shè)置啟動定時(shí)任務(wù)環(huán)境變量，這兩個(gè)失誤會導(dǎo)致某一次的組織架構(gòu)更新邏輯調(diào)整的代碼更新到線上時(shí)，線上一直是舊的邏輯在執(zhí)行，經(jīng)過一系列排查我們發(fā)現(xiàn)預(yù)上線環(huán)境一直獲取了讀寫鎖，使用舊的邏輯更新數(shù)據(jù)庫。

因此增加環(huán)境變量來控制定時(shí)任務(wù)啟動、對于壓測的環(huán)境的中的數(shù)據(jù)庫權(quán)限進(jìn)行了區(qū)分，增加了只讀模式。

6、報(bào)警和錯(cuò)誤恢復(fù)

這里有一點(diǎn)前端思維定勢的影響了，這一部分是同樣重要的。

報(bào)警方面

則是接入IMLog的Node SDK，通過 Kibana 和 Grafana 的系統(tǒng)配置，可以有效監(jiān)控組織架構(gòu)的更新情況。

錯(cuò)誤恢復(fù)方面

這里的錯(cuò)誤主要是發(fā)生在企業(yè)微信API的access_token過期的情況，常發(fā)生于以下兩種情況：

1. 企業(yè)微信官方主動使access_token過期

2. 在組織架構(gòu)更新過程中，access_token剛好失效情況，也就是http傳輸?shù)狡髽I(yè)微信剛好失效的情況

以上的情況是無法避免的。這里使用中間件對node.fetch進(jìn)行封裝，增加對response的返回值的校驗(yàn)，如果企業(yè)微信api的返回值是  “ WX_CODE.INVALIDE_TOKEN ”  則進(jìn)行預(yù)警和重置accessToken。

export default (app) => { 
  const { utils: { imlogHelper } } = app; 
  const wrapperLogFetch = (originFetch, { 
    traceId, 
    header, 
    client_ip, 
  }) => async (...args) => { 
    const res = await originFetch(...args); 
    if (res.errcode === WX_CODE.INVALIDE_TOKEN) { 
      // 進(jìn)行更新邏輯 
      wxService.clearAllRedisKey(); 
      imlogHelper({ 
        cmd: url, 
        message: 'accessToken_update_warning', 
        body: JSON.stringify(res), 
        trace_id: traceId, 
        retcode, 
        headers: header, 
      }); 
    } 
    return res; 
  }; 
    // 覆蓋context.fetch方法 
  return async (ctx, next) => { 
    if (!ctx.logFetch) { 
      const originFetch = ctx.fetch; 
      const { traceId, ip: client_ip } = ctx.request; 
      const header = JSON.stringify(ctx.request.header); 
      const logFetch = wrapperLogFetch(originFetch, { 
        traceId, 
        header, 
        client_ip, 
      }); 
      ctx.logFetch = logFetch; 
    } 
    if (ctx.fetch !== ctx.logFetch) { 
      ctx.fetch = ctx.logFetch; 
    } 
    await next(); 
  }; 
} 

總結(jié)

經(jīng)過重新設(shè)計(jì)和驗(yàn)證后形成以上的設(shè)計(jì)方案，具有以下優(yōu)化點(diǎn)：

1. 首先通過基于redis setnx實(shí)現(xiàn)的任務(wù)鎖，來實(shí)現(xiàn)同一時(shí)間單進(jìn)程更新數(shù)據(jù)庫；

2. 通過部署時(shí)設(shè)置定時(shí)任務(wù)啟動環(huán)境變量和數(shù)據(jù)庫讀寫賬號設(shè)置，來保證不同環(huán)境的分離；

3. 通過企業(yè)并行，部門數(shù)據(jù)拉取接口串行的模式，最大化性能和避免API調(diào)用封禁；

4. 完善錯(cuò)誤恢復(fù)機(jī)制和報(bào)警，實(shí)時(shí)查看運(yùn)行狀況。