背景
微保前端架構在業務發展中，根據業務、團隊、開發等實際情況，不斷進化調整，本文將具體介紹微保前端的架構演程序序，以及團隊最終選擇使用騰訊云 Serverless 技術支撐前端架構的原因，
微保團隊使用 Serverless 技術的主要應用場景：
- 前端開發同學，應用在BFF層，目前接入的有小程式，H5 頁面，
- 資料組同學，面向的風控和推薦演算法應用，做計算使用，
微保架構 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 技術在風控和推薦演算法應用的介紹會在之后的文章為大家詳細展開，敬請期待！
One More Thing
立即體驗騰訊云 Serverless Demo，領取 Serverless 新用戶禮包 ?? serverless/start
歡迎訪問：Serverless 中文網！
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/192864.html
標籤：其他