微保 Serverless 實踐之架構演進

背景

微保前端架構在業務發展中，根據業務、團隊、開發等實際情況，不斷進化調整。本文將具體介紹微保前端的架構演進過程，以及團隊最終選擇使用騰訊雲 Serverless 技術支撐前端架構的原因。

微保團隊使用 Serverless 技術的主要應用場景：

1. 前端開發同學，應用在BFF層，目前接入的有小程序，H5 頁面。
2. 數據組同學，面向的風控和推薦算法應用，做計算使用。

微保架構 v1

早期，團隊使用經典的前後分離架構，前端開發與後端開發通過接口進行合作。

合作流程如下圖所示：

毫無疑問，前後端分離的架構有比較顯著的優勢：

1. 前後端開發解耦

• 前端與後端開發並行，縮短需求整體開發周期

• 角色分工明確，線上問題定位與修復更加清晰

前後端分別設計與實現自己的錯誤監控和告警系統，前端對頁面腳本錯誤進行捕獲，上報至日誌平臺，經過日誌處理工具，設置告警機制，將錯誤信息推送至相應的開發人員。

• 利於前端組件化與後端微服務化架構

前後端分離後，前端可以使用更為便捷的框架以及基於這些框架的基礎UI組件，大大提升開發效率。另外，前端開發也會基於業務的特點，提取業務專屬的公共組件，所有組件化的沉澱，都是對生產效率的提升。

2. 部署解耦

• 前端靜態文件單獨部署 CDN

前端項目中有大量的靜態文件，包括 html、css、js、圖片、視頻等，將這些文件部署在 CDN 上，充分利用現有雲服務的CDN能力，既能提升資源訪問的速度又能保證資源訪問的穩定性，尤其是在高並發的場景下。

• 更加快捷的 CI/CD ，前端的編譯過程可以非常簡單地接入 CI/CD

在前後端耦合的時代，前後端的統一部署相互依賴，分開部署後，可以針對前端項目以gitlab的repo 級別來做相應的 CI/CD。

然而， 前後分離的架構對於業務早期的快速發展非常有效，而且在團隊規模較小的時候，前後端開發人員合作固定，彼此對於對方的開發習慣、性格較熟，因此跨角色溝通的問題並不突出。但隨著團隊規模和業務規模持續擴大，這個架構模式給團隊帶來的副作用慢慢浮出水面。實踐中，遇到的幾個比較明顯的問題，如下：

1. 前後端協作耦合慢慢成為開發效率提升的瓶頸。

如下圖所示：

團隊規模與業務規模的擴大，意味著合作的人員變多、接口的複雜度也會相應增加。

早期專人專項大家彼此的開發習慣也熟悉，對業務也都比較熟悉，因此業務接口參數的調整溝通成本較低。但隨著業務規模和團隊成員擴充，在各種跨業務合作時就會有人碰到不習慣閱讀proto，或有些複雜業務需要花費大量時間閱讀proto文檔，或前後端反覆溝通接口調用時參數的具體含義等問題。

2. 頁面渲染效率較差

如下圖所示

以產品詳情頁為例，頁面的渲染需要請求至少5個後端接口，然後再對數據進行組裝和處理。這不僅增加了小程序端的代碼體積，頁面渲染的速度也是被拉低了。

即使在前端頁面對接口進行並行訪問，但數據的整合邏輯依然會非常複雜。小程序作為微保主要的產品承載形態，代碼量巨大，幾近達到微信規定的代碼上限，這種對於代碼的增加隨著業務增長也是一個隱形的風險。

微保架構 v2

鑑於上述前後端合作模式中的痛點，團隊對架構再次進行優化，原則是業務「前」移、核心下沉。在前期的各種業務支撐中，團隊已經有了一些業務中臺的沉澱，比如投保服務、續保服務、保單服務等。

中間層的引入讓團隊的開發效率進一步得到提升，前端對於業務的把控力及頁面性能優化的操作空間也大大加強。不管是從團隊的敏捷性、還是應用的體驗，都有不錯的改善，比如以下幾個方面：

1. 前後端流程上的耦合大大減小，角色責任的專一性逐步形成

基於一部分後端服務能力的積累，比如保單相關的需求，在需求評審及開發過程中，只需要前端開發同學參加即可。前端開發同學與業務產品溝通業務邏輯，在api市場或服務文檔查詢相應的服務能力，完成業務開發。同時對於團隊逐步開展業務中臺化、前端組件化大有助益，整個架構對於豐富多變的業務需求的響應更敏捷。

2. 渲染層對後端的服務進行聚合，減少頁面請求

不管是H5網頁還是小程序頁面，均只需跟中間層打交道，前端開發人員根據業務的訴求，自行對接口進行聚合，端上只需要1個請求就可以開始渲染頁面。接口聚合之前，產品詳情頁面的顯示需要請求5個接口，平均的接口請求耗時為120ms左右，聚合後，通過中間層來請求5個內網接口，避免端與服務的多次連接耗時。

3. 中間層對數據進行加工，大大減少小程序端的邏輯代碼量

之前在小程序端的數據整合代碼，有些複雜的邏輯，可以交給中間層處理，這些代碼的節省對於業務持續增長時會越來越體現出價值。以年金產品詳情頁為例，數據在中間層聚合能夠節省10KB的體積。

中間層的引入是對生產力的進一步解放，但基於一個巨型 app 的 node 中間層，在後期的運維中也暴露出一些問題。中間層的應用部署在2臺CVM機器上，有其先天的一些不足：

1. 應對尖峰流量的衝擊能力差

微保經常會有一些運營和投放需求，這些事件都會導致瞬間的大流量打入，CVM的擴容相對滯後。

2. App級別的部署與發布

中間層不斷積累業務代碼，整個應用線性增長，每次部署與發布都是巨石應用的發布，部署效率低、風險高。

3. 前端開發人員在開發、測試環境中需要自己在機器上查閱日誌和服務操作，提高了普及的門檻。

微保架構 v3

基於上面的這些限制，團隊開始關注新的技術，加州大學伯克利分校計算機科學 Riselab 團隊的實驗室研究室提出：Serverless 是雲計算的下一個浪潮。國內各大廠商也都開始布局 Serverless ，騰訊雲 Serverless 團隊是國內比較早在這方面進行部署的團隊，技術已經非常成熟，在新東方、蘑菇街、嗶哩嗶哩、TP-link 等數百家企業成功落地實踐。

通過調研了解到騰訊雲 Serverless 雲函數的優勢：

• 強大的擴所容能力，特別適合應對流量洪峰，且性能穩定。
• 每個函數都是單獨運行、單獨部署、單獨伸縮的，用戶上傳代碼後即可自動部署，提升了獨立開發和迭代的速度。
• 雲函數提供精細的日誌記錄，可方便地查看函數的運行狀況，並對代碼進行調試、測試和審計；支持相關的監控指標上報，能快速了解函數的整體運行概況，也可自定義雲函數的監控指標。
• 精確到 1ms 計費規則，只對正在運行的函數計費。

綜上，基本解決了架構 v2 中面臨的問題，可以說是省時省力。經過團隊整體評估，我們決定使用騰訊雲 Serverless 雲函數進行架構的進一步調整。調整後的角色合作流程示意圖，如下：

C 端的請求發至雲函數 API 網關，網關轉發請求至相應的雲函數實例，雲函數再向後請求服務的網關。整個鏈條上最大的變化是將雲函數取代了node app，成為中間層的技術形態。

使用雲函數替換掉 node app，背後的考量有以下幾方面，也基本是針對 node app 實踐中遇到的一些問題去加以解決：

1. 自動擴縮容

開發者不需要專門去配置，雲函數可以自己根據請求量在函數層級水平擴展，正常情況下，一個空的雲函數（運行時間 50 ms），300 個並發，壓測可以達到 6000+ 的 qps，應對日常的高並發需求基本沒什麼問題。

2. 函數級別的開發與部署

一個雲函數對應一個 gitlab 的項目，函數開發與發布都是圍繞單個項目進行 CI/CD，高效、安全。

3. 按需收費

對於金融模式下的流量特點，大部分情況下請求量較少，雲函數的使用可以避免穩定的資源投入，空閒情況下費用大大減少。

4. 簡單的運維管理

開發者不需要在伺服器上自己維護服務和查閱日誌，通過雲函數的配套工具輕鬆管理函數、查閱日誌，也可以根據自己的訴求設置告警機制

微保使用 Serverless 技術的總體架構

微保每一次架構的調整，都致力於讓各種研發角色的職責更為單一、內聚，角色間更加解耦。但這種調整也需要有配套的工具，其中的 trade-off 需要根據短期成本和長期利益來衡量。騰訊雲Servelrss 雲函數很好地支持了本次架構的重新調整。

落地中的問題和解決辦法

使用騰訊雲 Serverless 過程中也不免遇到問題。

例如，公司有自建 es 集群，所有日誌都會放在es裡面，但是雲函數的日誌無法直接放入我們es裡面，只能存入騰訊雲的 cls，這個對於我們後期日誌分析， 告警都不好處理。通過調研騰訊雲cls， 發現裡面有個挺好用的功能，可以日誌投遞到 kafka，在通過監聽 kafka，我們將日誌成功存入我們的 es, 且時延保證在秒級。

另一個日誌規範問題, 日誌的規範關乎後期日誌分析、告警， 但是實際處理中發現日誌的元數據信息較少， 比如我們有版本 tag，雲函數綁定了 cmdb 相關信息，這些都希望在日誌中列印出來, 後面我們發現雲函數有個別名欄位。我們在雲函數中發現一個別名欄位, 通過擴展了一下這個欄位，填入了更多信息， 例如版本、cmdb 相關信息，這樣在日誌裡面相關信息也會體現出來。

關於使用騰訊雲 Serverless 技術在風控和推薦算法應用的介紹會在之後的文章為大家詳細展開，敬請期待！