1. 程式人生 > 其它 >技術實踐第一期|友盟+開發者平臺Node.js重構之路

技術實踐第一期|友盟+開發者平臺Node.js重構之路

一、問題背景

該專案提供友盟+SDK下載、相關輔助工具、整合demo等相關功能。

因原有SDK版本升級配置檔案較複雜,需要在java端通過多個檔案查詢整合得到前端介面勾選內容資料,且升級SDK均需要手動拉取oss檔案到服務端本地快取,導致維護成本較高,且時間悠久無相關產品及開發文件說明,因此在本次業務升級中重構改應用。

二、改造目標

  • java端遷移到node,直連oss簡化配置檔案,節約”人工智慧“的升級維護成本。
  • 下載由後端轉到oss直連下載, 大大提高下載效率。
  • SDK端各原檔案統一格式為zip,檔案儲存與服務端分離,提高後續維護性。
  • 使用SSR服務端渲染,提高SEO優化。

三、下載方案

1. 原下載方案

由頁面勾選,到後端進行檔案的拷貝獲取(原始檔案已在後端快取),建立對應目錄,進行merge後壓縮為最終zip檔案,壓縮完成後端直接流式返回zip。下載速度緩慢。且快取的原始檔案需每次手動拉取。

缺點:後端下載速度較慢。服務端儲存過多過大檔案的合理性。

2. 新下載方案

將原始檔案在編譯部署時從OSS拉取到服務端,且保持快取檔案路徑層級與OSS一致。根據頁面勾選,先查詢OSS是否有快取,若無快取則在後端進行各個SDK壓縮包的原始檔案複製,複製到生成對應的各層級資料夾中,在各資料夾內解壓、merge、整合後形成最終資料夾,將最終資料夾壓縮為zip後上傳到OSS,得到OSS分享連結直接下載。

四、技術選型對比

1. 快取原始檔案方式對比

原始SDK儲存在OSS且統一zip格式,全部原始檔案壓縮包大約1.5G。根據頁面操作拉取整合各SDK到一個檔案中。

  • 不推薦!直連OSS拉取對應SDK。

OSS提供將讀取資料夾及內容api,可將該資料夾內遞迴全部檔案為二維列表,若要實現需把需要的原始各個zip解壓在讀取內容,解壓後原始檔案比zip格式大了約3倍,明顯降低整體速度。

  • 推薦!每次應用部署時,在app.js中拉取OSS原始檔案到服務端快取,當快取完成後則在快取複製,當無快取時則oss拉取兜底。

2. 資料夾壓縮/解壓zip工具對比

因原始檔案中有軟連結,在merge中需要注意!

2.1、
zlib 模組

  • 優勢:
  1. 可對資料進行壓縮和解壓處理,減小資料體積,加快傳輸速度。
  2. 對檔案進行壓縮/解壓。
  • 缺點:不可壓縮/解壓縮資料夾。

//如HTTP請求頭部設定 Accept-Encoding:gzip,deflate //壓縮/解壓縮檔案 letlib=require('zlib') letgzip=zlib.createGzip() letrs=fs.createReadStream('./a.js') letws=fs.createWriteStream('./a.js.gz') rs.pipe(gzip).pipe(ws)

2.2、 node-stream-zip

  • 優勢:zip檔案壓縮/解壓庫,使用方便,可操作檔案/資料夾。
  • 缺點:不識別解壓後文件中的軟連結,導致軟連結打不開錯誤。

//解壓zip檔案 constStreamZip=require('node-stream-zip'); constzip=newStreamZip.async({file:'./common.zip'}); awaitzip.extract(null,'./'); awaitzip.close();

2.3、 compressing

  • 優點:可同步/非同步壓縮或解壓檔案/資料夾,相關文件簡單清晰。
  • 缺點:不識別解壓後文件中的軟連結,導致軟連結打不開錯誤。

2.4、 adm-zip

  • 優勢:
  1. 將 zip 檔案直接解壓縮到磁碟或記憶體緩衝區中。
  2. 壓縮檔案並將它們以 .zip 格式或壓縮緩衝區儲存到磁碟。
  1. 從現有 .zip 更新/新增新檔案/刪除檔案的內容。
  • 缺點:只能針對當前zip包進行操作整理,或者將檔案逐一複製出來。但實際業務需求根據頁面勾選將多個SDK壓縮包解壓生成新的對應目錄層級後整合為一個壓縮包。

2.5、 archive

  • 缺點:較長時間未更新,且解壓後內部檔案有軟鏈會重複生成真實檔案。

五、關於SSR服務端渲染

為更好優化SEO,專案改造採用react ssr服務端渲染,框架結構 Node + Um-Egg + React + AndD + yk-cli。

適用於偏靜態的頁面展示應用。

5.1 SSR過程實現

5.2 initProps與state注意點

  • 頁面首屏渲染只會渲染Component.initProps資料。
  • 在state定義的資料首屏不會渲染,而在前端元件中渲染。

5.3 SSR優勢

  • 有利於SEO

瀏覽器爬蟲不會等待頁面非同步資料全部載入完成後再去抓取頁面資訊。而服務端渲染返回到前端頁面是獲取全部首屏資料並生成html,即訪問路由時獲取。

  • 有利於首屏渲染

通過路由請求node中html全部內容,減少載入js檔案過程耗時,提高使用者訪問頁面時間。

5.4 SSR缺點

  • 服務端壓力增大

原本是客戶端渲染,現改為node層處理生成html,當併發量較大時佔用服務端資源也更大。

  • 維護成本相對變大

如上文5.2.中介紹,

要格外注意首屏資料處理以及專案引用第三方庫處理資料情況!

【文章作者:友盟+技術團隊】


⭐️開發者中心重構將友盟SDK統一輸出,包含APP端、網頁端、小程式/小遊戲、H5各端,以及相關SDK下載和自動整合方式


重構前後下載效率提升數倍,使得使用者體驗感迅速提升。同時友盟+也會更加重視相關文件的輸出,從功能描述到技術實現以及使用者體驗等等維度,更好地幫助使用者快速準確地解決問題。