系統架構：前端監控系統草案（技術路線和用戶行爲分析類似）

年底了，公司在統計本身支付系統的訂單成功率，最後發現有不少訂單成功率問題是和用戶頁面操做相關，可是咱們目前有些頁面沒有打點作用戶行爲數據的採集，所以很難分析出用戶究竟是是什麼緣由沒有完成訂單，對此我寫了一個前端監控方案，下班時候和領導開會討論這個方案，很晚纔回家哦，會上仍是被批了一番，認爲這個和用戶行爲分析系統耦合，並且最關鍵的採集那些信息，怎麼分析信息沒有細化，公司有類似的技術方案，個人方案很難成型。領導說的沒錯，我這個方案是重複性勞動，不必大動干戈，可是至少我提出這個方案代表公司用戶行爲分析系統對相似前端頁面監控的方案可能支持不夠，這就讓我產生了新的思考了，其實不論是用戶行爲仍是前端監控，技術路線是相同的，可是採集的側重點有所不一樣，對於公司內部的用戶行爲分析系統，與公司業務耦合是有必定必要的，獲取第一手的用戶操做行爲數據而且從這些數據指導頁面的改進可能比知道pv和uv這樣的指標更加劇要。下面我把本身寫的草案的技術部分和你們分享下，但願你們能給我拍拍磚，多提些好意見。

 

 

實現監控的可行性技術方案

 

監控方案須要從四個基本問題着手考慮，這四個問題是：

 

1. 如何收集前端頁面的數據，收集那些數據？

 

2. 收集到的數據如何發送到服務端，數據到了服務端按什麼方式持久化？

 

3. 服務端處理監控數據的方式？

 

4. 監控方案是公司、部門內部的管理手段，並非用戶享受服務的一部分，那麼就有一個問題，監控方案如何能下降對頁面原有功能，頁面加載效率以及頁面穩定性的影響。

 

下文將一一論述這四個問題，詳情以下：

 

Ø 問題一：如何收集前端頁面的數據，收集那些數據？

 

收集前端頁面數據的手段就是使用javascript在須要收集數據的地方打點，綁定相應的事件，用戶觸發這個事件的時候，頁面就會自動將數據發送到服務端。該問題的重點和難點是收集那些數據，這個問題是一個業務的問題，須要業務的相關方參入進行討論，創建數據採集的業務模型。不過業務模型創建的基礎仍是經過技術手段能採集到那些數據，理清這些數據之間的邏輯關係，如何能從這些有邏輯關係的數據裏分析出咱們須要的結果等方面進行考慮。

 

Ø 問題二：收集到的數據如何發送到服務端，數據到了服務端按什麼方式持久化？

 

問題二看起來是兩個獨立的問題，可是在具體實現上這兩個問題密不可分，由於前端發送數據方式會致使服務端接收數據的方式的差別，從而致使數據持久化方案的不一樣。這裏要總結下前端向服務端發送數據的方式：第一種就是古老的頁面同步提交，這個方式確定不能用於監控；第二種是ajax方案，異步提交請求看起來很美其實它蘊含一個重大的隱患，由於ajax請求每每是同域下的請求，若是監控通信模型採用ajax方案會致使支付系統請求數的增長，這樣會擠佔支付系統的系統資源和系統帶寬，要是監控系統的粒度更細，那麼支付系統的負擔將會以幾何倍數增長；第三種方案是一種跨域請求的方案，跨域的方案使得監控系統的服務端成爲獨立的系統，監控系統要進行獨立部署，這樣的好處就是讓監控系統和支付系統在系統層級上解耦。對於前端實現跨域請求的方案有不少種，這裏只講一種最簡單易行的方案就是使用img標籤的src，每次觸發監控請求的時候改變一下img標籤下的src指向的地址，固然用來完成監控請求的img所承載的圖片最好是不可見的，這種方式還有個好處就是能夠充分利用瀏覽器的鏈接數，讓外域的圖片socket的鏈接和支付請求的socket的鏈接分開，這和網站優化裏將圖片，外部文件放到獨立的靜態服務器的原理同樣，這樣作不用佔用支付服務的帶寬，可是對頁面的性能有必定影響，固然影響程度是很低的，所以它是本方案提出者推薦的方式。

 

服務端持久數據的可行方式有以下三種：第一個是用日誌存儲，日誌存儲方式還能夠分爲靜態日誌存儲方式，例如用apache，nginx等靜態資源服務器存儲日誌，靜態服務器的日誌和使用img的src發送請求的方式配合最好，並且日誌存儲方式不會牽涉程序開發，每每只須要配置下靜態資源服務器就好了，另一種是使用動態語言存儲日誌，例如使用java語言裏的log4j技術存儲日誌，那麼這就須要用java寫一套接收程序，這種方案也可能致使img的跨域方式的性能降低，或者須要採用其餘跨域的替代方案。第二個是將收集的信息寫入到文件，這個方案持久化的效果和日誌存儲效果差很少，不過文件存儲實現會讓服務端開發難度增長。這裏不推薦使用；第三個也是最後一個就是直接將日誌存儲到數據庫，既然要存儲數據庫，那麼數據到了服務端最好是預處理下，存到數據庫的好處是分析起來很便利，可是效率和性能是比較低的。

 

Ø 問題三：服務端處理監控數據的方式？

 

問題三就是一個數據挖掘的問題，在業務層面上該問題能夠和咱們須要採集那些數據的業務問題一塊兒討論，而技術層面上這個就和持久化數據的方式息息相關了，目前主要是究竟是處理文件仍是處理數據庫的區別了。此外，咱們對這些監控數據重視程度也會影響到服務端處理監控數據的系統複雜度，不過只要能採集到有用的數據，這些問題均可以慢慢解決。

 

Ø 問題四：監控方案是公司、部門內部的管理手段，並非用戶享受服務的一部分，那麼就有一個問題，監控方案如何能下降對頁面原有功能，頁面加載效率以及頁面穩定性的影響。

 

這個問題是全部問題最核心的問題，監控的目的是提高支付頁面的可用性、效率和穩定性的手段，可是這個手段的介入必定會對原支付頁面產生性能損失，所以好的監控方案必定要對原系統侵入性很低，同時自身效率很高，對頁面影響最低。該問題須要在具體實踐中進行細化，同時前面問題的討論中也要時刻考慮到這個問題所帶來的影響。