天天看點

如何支撐網際網路高并發場景可回溯架構?

“ 2020年10月1日 《關于規範網際網路保險銷售行為可回溯管理的通知》正式實施,标志着網際網路保險進入了“可回溯時代”。衆安科技關于網際網路可視化回溯項目的立項是在2018年11月,在銀保監做了征求意見稿後科技産品項目組對可回溯項目正式進行了立項。”

如何支撐網際網路高并發場景可回溯架構?

初步構型

基于自動化測試的構型方案

技術團隊第一時間對市場上的技術方案進行了調研,但整個Web 端還未有相關成型的技術。在充分調研後團隊确定了第一版的技術架構方案:基于自動化測試架構(selenium)的可回溯方案。

如何支撐網際網路高并發場景可回溯架構?

技術構型:

前端:JS 插件負責采集使用者操作事件:點選、輸入、拖拽、滑動,結合操作 Dom 節點的 xpath 組成消息事件傳遞給後端。

中間件層:在網關層統一抓取所有使用者的請求和響應做資料模拟備份。

後端:通過解析前端消息解析成使用者操作事件,對應到 selenium 的腳本中驅動 chrome 完成使用者行為的模拟,并同時錄制視訊。

這套方案很快完成了技術的可行性測試,并初步還原了使用者的操作行為,但是在對整體系統疊代了兩個月後,開始遇到了各種問題。

例如:

1、前端采集資料不準确,xpath 在不同的 web 載體中表現不一緻。例如在 App 中頁面可能多了頂部 Banner 或推廣位置,在浏覽器中就無此邏輯,是以後端基于 ChromeDriver 還原的方案不能很好的處理這種邏輯。

2、網關層抓取所有使用者的請求和響應做資料模拟對使用者,需要嵌入網關層面做lua 插件,對技術要求難度較高并且比較依賴運維人員的能力,很容易出現錯誤抓取資料并且導緻網關整體性能降低的問題。

3、ChromeDriver提供的 API 不能驅動對應的用操作,例如使用者在頁面上完成的拖拽月曆控件動作無法進行還原。

踩”坑“前行

繼續疊代還是更換方案

在一條路走不通的情況下,技術團隊拆分出兩個目标:

1、繼續嘗試優化基于Selenium 的自動化測試方案,既然原生的 ChromeDriver 的提供 API 能還原使用者的操作,就能通過注入定制回溯 JS 的方式進行操作還原。

2、尋找其他方案,嘗試不采用Selenium 進行使用者操作還原。

兩個目标同時研發開展一段時間之後,原方案的技術上也取得了突破,很多場景都可以進行還原,但還是沒有達到100%還原的操作效果。團隊在完成軟著申請和專利送出後就開始了攻克100%還原的方案。

另外一條線路尋找其他方案也有了結果。”既然都是JS 采集使用者操作,并且也由 JS 還原使用者操作完成頁面上的動作。為什麼不直接采集頁面互動及動畫,再通過頁面渲染互動及動畫,直接跳過 selenium 操作指令模拟部分“ 基于這種處理動畫渲染的思想,前端完成了可行性調試,并實作了相應的效果。這時我們才知道技術社群也有了相同思想的開源方案。通過研究相關的開源方案結合團隊之前踩坑的經驗,很快我們就掌握了如何100%實作還原的方法。

架構定型

沒有最好的架構隻有更符合業務的架構

結合新的方案,撇開了網關層的插件接入和自動化模拟層技術團隊對整體架構又進行了精簡。既然采集端和播放端都由前端掌控,那麼後端在整個體系中承擔的就是資料收集能力和資料編排能力。如何把采集的資料存下來,并在前端需要的時候快速的找出來。

參照公司内部的xflow 采集(資料埋點采集)通過 nginx 完成日志資料收集,使用解析器解析資料後通過 kafka 投遞到 ES 中,整體的架構對我們這個“小項目”無論是技術難度還是運維難度都是一個挑戰,是以我們放棄了此種方案。結合第一版架構下完成了架構的改進調整。

如何支撐網際網路高并發場景可回溯架構?

後端服務還是采用比對團隊能力的主流技術棧,Java語言、Springboot架構 。

收集服務:

同nginx 接收采集資料的能力對比,Springboot 應用的性能要孱弱很多,但是好在應用可維護性高并且友善團隊進行拓展。團隊在建構收集服務上充分發揮了其拓展能力,增加了時鐘校準、智能熔斷、前端數字指紋識别等功能。把資料采集的場景變成了後端配置化,做到了前端埋入一行 JS 即可完成資料采集的操作。

歸檔服務:

收集服務為了能更大的承載前端JS 采集到的資料,直接把資訊在按照日志的形式進行儲存,通過特殊定制的Logback Appender 完成資料高效的寫入并保留通用的可讀能力。再通過歸檔服務異步監聽日志檔案的建立和改變完成資料解析并索引投遞到 Mongodb 中。

編排服務:

對應一次使用者的投保流程中,從使用者進入到投保頁面即開始了頁面資料的采集,但是直到使用者生成訂單或保單完成投保後才需要對整個流程進行回溯。對應到後端服務上其實也就是一個時間差,并且由于網際網路場景使用者的浏覽量是遠遠大于成單量的。是以編排服務的承壓要遠遠低于收集服務,隻要内部能完成的資料消化就能對整體提供服務。

背景管理:

內建使用者權限控制系統和資料管理子產品對業務使用者提供嵌入式播放器頁面通過JS 頁面元件直接完成可視化回溯視訊的渲染播放,并提供各業務端接入回溯資料的能力。

視訊子產品:

在實際的回溯應用中,絕大多數場景都可以通過背景管理子產品體提供的播放器頁面完成業務處理,少部分需要導出視訊的場景的才需要進行MP4 視訊制作,是以獨立出單獨的視訊子產品僅在需要時才進行 MP4 視訊的生成。

模拟子產品:

對于前端采集到的靜态資源連結css、圖檔、PDF 等資源進行緩存,對應到實際業務場景中類似于爬蟲服務到處爬取頁面上的靜态資源并進行離線儲存和版本管理。

如何支撐網際網路高并發場景可回溯架構?

在雲服務越來越成為“新基建”的今天,可回溯架構在充分考慮了如何更好的适應雲服務。通過替換日志歸檔服務采用雲日志,例如:阿裡雲SLS 、騰訊雲 CLS 。在對應存儲能力的擴充上有了更一步的提升,同時采用對象存儲服務可以幫助企業和使用者更好的降低成本。

以上的技術構型可根據業務場景的資料量進行橫向拓展,在實際的壓測過程中無論是收集服務還是編排服務都能根據節點數量進行線性擴充。

作者:唐傳博

來源:微信公衆号:衆安科技技術團隊

出處:https://mp.weixin.qq.com/s/Oefqp64AigYrgaUB6P9H3Q

繼續閱讀