使用 Rust 加速前端監控

介紹

前陣子在公司內搭建了一個 Log Service，用來記錄前端的報錯信息，代碼一頓亂寫搞的七七八八之後實現了第一版的功能。

流程很簡單，前端將以下格式的信息用 get 發到 Log Service:

Log Service 接受到這個請求以後，將解析成 JSON : , 解析後的 stack 是這樣的 :

然後 Log service 會根據文件對應的 sourcemap (前端各項目 deploy 的時候已經上傳到私有 CDN 了) 解析出原始報錯位置。比如:

最後會將這些處理後的信息輸出到阿里雲的 LogHub。

version1.497dbf6bf941.png

做完第一個脆弱的版本後發現時間僅僅過去了一天半，所以開始考慮優化的事情了。

第一個版本有兩個問題，第一個問題是在後端處理 log 的流程太長導致性能消耗有點大，第二個問題是實時處理 Log 在後面用戶增多之後伺服器會不堪重負，而其實 Log Service 的實時性要求並沒有那麼高。

對於第一個問題，可以優化代碼性能(能優化才怪)，分拆步驟(這個靠譜)來解決，第二個問題也可以通過分拆數據處理步驟來解決。

而分拆處理步驟這個解決方案可以通過在 Log Service 中加入一個 queue 來解決。比如接受到前端請求後，直接將原始數據塞到 queue 中，然後有一個 consumer 按一個最大速率從 queue 中取出原始日誌，處理之後再放入 LogHub，這一部分的細節就不贅述了，要寫的話展開又是一個長篇大論。

而優化性能這方面，我本來沒有抱什麼希望，因為實在是看不出有啥可優化的。 --> --> 都用的是最底層的標準庫調用( 用的是 Mozilla 出品的 https://github.com/mozilla/source-map)

然而在上線的前夕，我突然想起了前不久學習 Rust 的時候看到的一個庫 neon-bindings

是不是可以用更快的語言來優化 Sourcemap 處理的過程呢，同時大部分主要的繁瑣的業務還是使用 TypeScript 編寫。

調研了一圈發現，已經有國內的公司在項目裡面用 neon 寫業務了。

並且大家熟悉的 sentry 在生產環境中也是使用來 parse Sourcemap ，雖然他們是 binding 到了 python 上，但他們已經把 Rust 代碼開源出來了。

也就是說我只需要把這部分的代碼通過 neon-bindgs 封裝成 NodeJS 可調用的模塊就行了，不像 sentry 還要 port 出 C API 再通過 python 調用 C 的代碼，美滋滋。

寫代碼的過程和原理就省略了，代碼可以在 sourcemap-decoder 看到，主要分享一些數據和踩的坑:

Benchmark

所以 Rust 比 JavaScript 代碼在處理同樣的 Sourcemap 時 parse 快多少呢？

我做了一個簡單的 benchmark, 測試結果如下:

Hardware Info:

Benchmark 代碼在這裡。

因為每次調用 Rust 的代碼會有一次 bootstrap 的過程以及 JavaScript 代碼在運行很多次後會被 JIT 優化，在一次性運行幾萬次的情況下差距可能縮小為十幾倍，有興趣大家可以自行嘗試。

CI/CD

剛寫完打算上線的時候，想讓 production 的鏡像盡量小一點(我們用的 Docker)，所以直接在 Production 的 Image 上用了 node:8-alpine 作為 base image，相應的，CI 的鏡像(我們使用的是 Gitlab runner 的 Docker executor )也是用同樣的 base image，然後花了三個多小時嘗試在 Alpine 上安裝 latest rust toolchains 後失敗了，最後不得不忍受 100 多 m 的體積差切換到了。最終的國內可以流暢 build 的 Dockerfile 在 Github 上可以找到。

Toolschains 安裝

由於眾所周知的原因，CI 在剛開始 build image 的時候異常的緩慢，直到超時被 Gitlab kill 掉，經過一個多小時頑強的抵抗後將所有可能撞牆的步驟全部替換成了 USTC 的 mirror。

主要是 dev 機器 rustup 安裝需要:

使用 USTC 的源安裝 Rustup

build 前需要:

讓 Cargo 也是用 UTSC 的源(CI 環境也需要執行同樣的命令)

在 CI 的 Docker Image build 的時候需要替換 Rust 下載源以及替換 Rustup源

詳情請參考 README

因為 Rust 在公司內成功應用，所以我們決定後面會盡量遷移一些 CPU 密集型的任務到上，比如用 https://github.com/nical/lyon 替代 puppeteer 做海報的後端渲染，如果你有興趣的話，歡迎聯繫我！

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！