微保 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 技術的整體架構

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

落地中的問題和解決辦法

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

例如，公司有自建 es 集羣，全部日誌都會放在es裏面，可是雲函數的日誌沒法直接放入咱們es裏面，只能存入騰訊雲的 cls，這個對於咱們後期日誌分析， 告警都很差處理。經過調研騰訊雲cls， 發現裏面有個挺好用的功能，能夠日誌投遞到 kafka，在經過監聽 kafka，咱們將日誌成功存入咱們的 es, 且時延保證在秒級。

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

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

One More Thing

當即體驗騰訊雲 Serverless Demo，領取 Serverless 新用戶禮包 👉 serverless/start

歡迎訪問： Serverless 中文網！