Node.js躬行記（22）——Node環境升級日誌
- 2022 年 9 月 5 日
- 筆記
- Node.js躬行記
公司之前所有的 Node 項目，其環境都是 8.9.4 版本，發佈於 2018 年的一個比較古老的版本。
老版本有兩個比較明顯的問題：
- Node 高版本的特性和方法都無法使用。
- 有些第三方新版本的包無法安裝和升級，該包可能依賴比較高的 Node 版本。
之前在開發項目時就遇到第三方包自身的問題，必須升級或換個包才能解決，但因為 Node 版本的原因，無法替換，只能用其他方式來修補漏洞。
為了提升維護性和開發體驗，還是決定升級 Node 版本，2021年升級過一次，升級到 14 版本。
但是因為一些奇怪的問題加上業務繁重，沒有時間細究，就又回滾了，一直拖到今年的 7 月份，才繼續推進升級的事情，本次會升級到 16.15 版本。
目前總共有 4 個 Node 環境需要升級，測試資源緊張，在升級後，是沒有人力來驗證是否有問題發生，所以只能靠自己想辦法安全升級。
1）分項目階梯升級
在 4 個待升級的項目中，有 3 個是對外的項目，有 1 個是對內的項目。
那麼先升級對內項目的 Node 版本，這樣有兩個好處：
- 即使出問題了，影響範圍也能最小。
- 響應也能最及時，因為有問題的話，在公司內部能馬上回饋到我們組。
2）分環境階梯升級
我們每個項目都會有 3 套運行環境：測試、預發和生產。
首先將測試環境升級，測試環境都是開發人員使用，影響最小，回饋最快。
觀察一段時間後，再升級預發，預發環境與生產環境最為接近，資料庫採用的也是一套。
最後才是生產，給真實用戶使用，再獲取回饋。
3）邀請內部人員體驗
首先升級的是那個內部項目，所以在飛書上建了個群，將各個組的負責人拉進來。
邀請他們在預發環境體驗各自的業務，再給出回饋。
在驗收時發現了時區的問題，糾正後，再讓他們驗收。
4）部署自動錯誤告警
讓人來驗收，難免會有遺漏，所以讓運維給加了個自動錯誤告警。
每分鐘有 5 個 500 以上的錯誤，就自動在飛書上發告警資訊。
這類規則比較適合介面，而定時任務的規則比較特殊。
因為任務可能是 5 分鐘運行一次，那麼報錯的頻率不會那麼高。
因此改成 5 分鐘內有一個錯誤就告警，免得告警太多，也比較煩人。
5）增加單元測試流程
在將對內的項目升級完成後，公司員工在訪問一個服務時報錯。
讓運維查看後，發現是因為連接地址配置錯了。
為了避免這種問題的發生，就需要有地方可以測試服務連接是否異常。
手動測試比較繁瑣，最好的辦法是在發布程式碼的流程中，加一環服務連接。
若成功，那麼就繼續後面的流程，否則就中斷。
公司使用的是阿里雲提供的發布系統，裡面可以加一步單元測試。
服務連接是測試的一個場景，未來可以再加其他各類測試，保證項目品質。
從開始升級到全部項目升級完成，前前後後操作了 20 多天，因為在一個環境或項目升級後，就要觀察幾天，然後再升級另一個環境或項目。在升級完成後，還部署了阿里雲提供的一款 Node 監控系統。
