微保團隊使用 serverless 技術的主要應用場景：
前端開發同學，應用在bff層，目前接入的有小程式，h5 頁面。
資料組同學，面向的風控和推薦演算法應用，做計算使用。
早期，團隊使用經典的前後分離架構，前端開發與後端開發通過介面進行合作。
合作流程如下圖所示：
毫無疑問，前後端分離的架構有比較顯著的優勢：
1. 前後端開發解耦
前後端分別設計與實現自己的錯誤監控和告警系統，前端對頁面指令碼錯誤進行捕獲，上報至日誌平台，經過日誌處理工具，設定告警機制，將錯誤資訊推送至相應的開發人員。
前後端分離後，前端可以使用更為便捷的框架以及基於這些框架的基礎ui元件，大大提公升開發效率。另外，前端開發也會基於業務的特點，提取業務專屬的公共元件，所有元件化的沉澱，都是對生產效率的提公升。
2. 部署解耦
在前後端耦合的時代，前後端的統一部署相互依賴，分開部署後，可以針對前端專案以gitlab的repo 級別來做相應的 ci/cd。
然而，前後分離的架構對於業務早期的快速發展非常有效，而且在團隊規模較小的時候，前後端開發人員合作固定，彼此對於對方的開發習慣、性格較熟，因此跨角色溝通的問題並不突出。但隨著團隊規模和業務規模持續擴大，這個架構模式給團隊帶來的***慢慢浮出水面。實踐中，遇到的幾個比較明顯的問題，如下：
1. 前後端協作耦合慢慢成為開發效率提公升的瓶頸。
如下圖所示：
團隊規模與業務規模的擴大，意味著合作的人員變多、介面的複雜度也會相應增加。
早期專人專項大家彼此的開發習慣也熟悉，對業務也都比較熟悉，因此業務介面引數的調整溝通成本較低。但隨著業務規模和團隊成員擴充，在各種跨業務合作時就會有人碰到不習慣閱讀proto，或有些複雜業務需要花費大量時間閱讀proto文件，或前後端反覆溝通介面呼叫時引數的具體含義等問題。
2. 頁面渲染效率較差
如下圖所示
以產品詳情頁為例，頁面的渲染需要請求至少5個後端介面，然後再對資料進行組裝和處理。這不僅增加了小程式端的**體積，頁面渲染的速度也是被拉低了。
鑑於上述前後端合作模式中的痛點，團隊對架構再次進行優化，原則是業務「前」移、核心下沉。在前期的各種業務支撐中，團隊已經有了一些業務中颱的沉澱，比如投保服務、續保服務、保單服務等。
中間層的引入讓團隊的開發效率進一步得到提公升，前端對於業務的把控力及頁面效能優化的操作空間也大大加強。不管是從團隊的敏捷性、還是應用的體驗，都有不錯的改善，比如以下幾個方面：
1. 前後端流程上的耦合大大減小，角色責任的專一性逐步形成
基於一部分後端服務能力的積累，比如保單相關的需求，在需求評審及開發過程中，只需要前端開發同學參加即可。前端開發同學與業務產品溝通業務邏輯，在api市場或服務文件查詢相應的服務能力，完成業務開發。同時對於團隊逐步開展業務中颱化、前端元件化大有助益，整個架構對於豐富多變的業務需求的響應更敏捷。
2. 渲染層對後端的服務進行聚合，減少頁面請求
不管是h5網頁還是小程式頁面，均只需跟中間層打交道，前端開發人員根據業務的訴求，自行對介面進行聚合，端上只需要1個請求就可以開始渲染頁面。介面聚合之前，產品詳情頁面的顯示需要請求5個介面，平均的介面請求耗時為120ms左右，聚合後，通過中間層來請求5個內網介面，避免端與服務的多次連線耗時。
3. 中間層對資料進行加工，大大減少小程式端的邏輯**量
之前在小程式端的資料整合**，有些複雜的邏輯，可以交給中間層處理，這些**的節省對於業務持續增長時會越來越體現出價值。以年金產品詳情頁為例，資料在中間層聚合能夠節省10kb的體積。
1. 應對尖峰流量的衝擊能力差
微保經常會有一些運營和投放需求，這些事件都會導致瞬間的大流量打入，cvm的擴容相對滯後。
中間層不斷積累業務**，整個應用線性增長，每次部署與發布都是巨石應用的發布，部署效率低、風險高。
3. 前端開發人員在開發、測試環境中需要自己在機器上查閱日誌和服務操作，提高了普及的門檻。
1. 自動擴縮容
開發者不需要專門去配置，雲函式可以自己根據請求量在函式層級水平擴充套件，正常情況下，乙個空的雲函式（執行時間 50 ms），300 個併發，壓測可以達到 6000+ 的 qps，應對日常的高併發需求基本沒什麼問題。
2. 函式級別的開發與部署
乙個雲函式對應乙個 gitlab 的專案，函式開發與發布都是圍繞單個專案進行 ci/cd，高效、安全。
3. 按需收費
對於金融模式下的流量特點，大部分情況下請求量較少，雲函式的使用可以避免穩定的資源投入，空閒情況下費用大大減少。
4. 簡單的運維管理
開發者不需要在伺服器上自己維護服務和查閱日誌，通過雲函式的配套工具輕鬆管理函式、查閱日誌，也可以根據自己的訴求設定告警機制。
另乙個日誌規範問題, 日誌的規範關乎後期日誌分析、告警， 但是實際處理中發現日誌的元資料資訊較少， 比如我們有版本 tag，雲函式繫結了 cmdb 相關資訊，這些都希望在日誌中列印出來, 後面我們發現雲函式有個別名字段。我們在雲函式中發現乙個別名字段, 通過擴充套件了一下這個字段，填入了更多資訊， 例如版本、cmdb 相關資訊，這樣在日誌裡面相關資訊也會體現出來。
AI 事件驅動場景 Serverless 實踐
事件驅動是指事件在持續事務管理過程中，進行決策的一種策略。可以通過調動可用資源執行相關任務，從而解決不斷出現的問題。通俗地說是當使用者觸發使用行為時對使用者行為的響應。在 serverless 場景下，事件驅動完美符合其設計初衷之一 按需付費。圖 knative 模型 knative 主要包括兩大部...
android程序保活實踐
前言 程序保活的關鍵點有兩個，乙個是程序優先順序的理解，優先順序越高存活機率越大。二是弄清楚哪些場景會導致程序會kill，然後採取下面的策略對各種場景進行優化 提高程序的優先順序 在程序被kill之後能夠喚醒 程序優先順序 android一般的程序優先順序劃分 1.前台程序 foreground p...
react 微前端實踐
最近花時間實踐了一下阿里 qiankun 微前端框架 主應用和子應用都使用react 實現，主應用伺服器使用golang語言 go chi框架實現，子應用實現簡單的對接，主應用配置好路由就可以訪問 專案還在持續完善中,專案實現目標 主應用只負責選單，使用者，路由，許可權管理等 子應用各司其責，熱插拔...