大廠都在做的前端穩定性到底是啥呢?

語言: CN / TW / HK

引言

在一次公司的前端無法訪問的事故覆盤後,我們調查了關於應用穩定性前端可以做些什麼。對於前端穩定性其實在整個使用者訪問到頁面到請求都需要全鏈路的監控與追蹤,每一個環節都值得我們深入探究一下。本文就從應用伺服器、靜態資源、頁面渲染、介面請求4大方面來各個擊破,看看前端穩定性到底需要如何建設。

前端穩定性 (1).png

應用伺服器

應用伺服器在整個鏈路的最上游,從使用者在位址列輸入域名訪問後,流量通過閘道器(由於閘道器層的穩定性在大多數公司都不是由業務團隊負責,本文暫略去這一部分,具體要做的和應用伺服器相對也比較類似)進入到我們的應用伺服器,如果我們應用伺服器掛了,那麼沒有任何後續的穩定性可言了。

應用穩定性

應用穩定性指的是應用伺服器執行的服務程序的穩定性。

對於普通的頁面伺服器來說,在應用穩定性層面上可以補充的是頁面的訪問日誌(例如UA、IP等)。

而對於需要跑一個node服務的這種BFF的情形,應用穩定性可以做的事情就更多了,需要分等級的日誌記錄,異常丟擲的監控,請求的響應速度的監控等,一般通過對應中介軟體進行處理與上報。

容器穩定性

目前雲原生的環境下,應用伺服器一般採用容器方式部署,部署平臺一般會提供監控的基礎設施,來監控容器的執行狀態,如CPU、記憶體負載,內外網流量等。當這些資料出現異常值或者大幅波動時,就需要通過告警機制來通知到對應負責的同學,採取對應的措施,如重啟、擴縮容等。

在部署應用時,一般我們可以跑多個容器來保證就算有一個容器掛了,使用者還是可以訪問到應用。如果將多個容器部署在不同的區域,可以規避例如斷電、火災等某個區域伺服器集體宕機的風險,我們一般把這個措施叫做異地多活。

最後,我們的容器需要暴露埠從而讓使用者流量可以訪問,那麼我們就可以模擬使用者的行為對伺服器進行探活。如我們的容器就是作為一個頁面伺服器跑一個nginx,則定期輪詢該nginx容器暴露的埠就可以探測我們的容器是否正在正常執行。

資源CDN載入

CDN容災

美團在今年出了一套新的CDN容災方案:Phoenix

在這套方案中,我們可以看到美團將CDN容災分為5個部分:

  1. 等效CDN服務
  2. 端側的重試和上報
  3. 服務端側通過上報資訊動態計算CDN的優先順序
  4. 容災監控平臺
  5. 容災配置平臺

美團將CDN的重試切流放在了端側,因為端側才是CDN真正的使用者,擁有CDN狀態的第一手資訊,服務端側相對則更多負責對於端側上報的資料進行彙總與動態調整的工作。

我們將美團端側SDK的流程圖貼在了下方,可以為我們做CDN容災提供很多參考。

image.png

對於中小型的初創企業來說,建設一整套這樣的全鏈路CDN容災方案可能成本較高,能夠快速入手的就是在端側根據載入結果進行重試,重試失敗進行告警,以及儘量選擇穩定靠譜的CDN服務商。

畫面渲染

錯誤收集

在畫面渲染階段,首先要做的是對JS的錯誤進行收集。目前通用的方案是採用sentry在JS丟擲錯誤的時候進行上報。如果頁面採用類似ErrorBoundary的形式攔截了錯誤,或catch了異常的話,需要在ErrorBoundary或catch塊中人工進行上報。

同時,出於安全的考慮,在生產環境往往不會將sourcemap暴露給使用者,而在生成的程式碼中直接進行問題定位溯源往往比較困難。解決方案是在構建時仍然先打出sourcemap,上傳到sentry平臺上,之後再將sourcemap刪除。

需要注意的是,一些工具刪除sourcemap的時候會將生成的程式碼中新增的sourcemap的引用也刪除,這會導致程式碼變更,如果還在html的script標籤採用integrity屬性保證JS程式碼未被篡改的話integrity需要在sourcemap刪除後計算。

錯誤處理

在上一part中,我們也提到了有ErrorBoundary這種來做錯誤處理的方式,讓在有邏輯異常發生時使用者的頁面不至於白屏或者沒有反應。在應用中,我們也可以做404的自定義頁面,在使用者發生這種情況時提供更友好的說明與返回路徑。

介面

前端對於介面是消費方,如果只在後端進行介面問題日誌的記錄的話,會有幸存者偏差的可能。但是一般的超時或者500是不會觸發sentry的上報機制的,所以我們可以在框架層面單獨進行這些問題的告警,介面的報警的指定方可以設為後端同學。

而前端在請求不到後端的一些情況時來進行重試,是能提高使用者體驗的,類似超時或者伺服器繁忙時,但是這需要前後端有良好的介面定義規範:

  1. 遵循restful,post不是冪等,而get、put、delete等都為冪等,只對冪等請求進行重試
  2. 錯誤碼定義規範,規定什麼型別的錯誤碼可以重試,什麼型別的不可以

報警

上述所有的監控措施最後能夠被開發獲知的途徑就是通過報警。從一個角度來說,報警是本文中最容易的環節,對於研發側來說只需要在報警平臺上進行配置,用合適的方式將合適的錯誤通知到合適的開發/運維人員。然而,這一步其實又是最複雜的環節,需要各個應用根據自己的成熟度進行分析,對這三個“最合適”需要自己的度量。如果報警過於疏鬆,就可能會漏掉關鍵的錯誤導致線上問題未被發現;而如果報警過於密集,有許多誤報,又會導致負責人看到報警變得鬆懈,達不到報警的目的。

以上就是我們總結的前端穩定性建設需要關注的各個方面以及對應需要採取的手段。前端穩定性是一個需要長期建設的環節,願大家的應用都能夠線上無bug,安穩每一天。