中國人壽業務穩定性保障:“1+1+N” 落地生產全鏈路壓測

語言: CN / TW / HK

引言

保險業務的數字化轉型正如火如荼地進行,產品線上化、投保線上化、承保線上化、核保線上化等業務轉型,導致系統的應用範圍不斷擴大,使用者的高頻訪問也正在成為常態。同時,系統複雜性也呈指數上升,這些因素都增加了系統的穩定性風險。

中國人壽將無侵入線上壓測作為防禦穩定性風險的重要手段,作為保險行業首家落地生產全鏈路壓測的企業,其實踐經驗具有相當的借鑑意義。

 

作者介紹

中國人壽壽險研發中心高階工程師 熊軍軍

TakinTalks 穩定性社群專家團成員,畢業於中國科學院自動化所,就職於中國人壽保險股份有限公司研發中心,先後從事產品研發、架構設計、質量管理工作,熟悉保險銷售管理及銷售支援業務,具備資料治理和高可用架構設計經驗。現負責質量中心測試公共能力團隊,著力建設質量保障工具及平臺,助力提升資訊系統穩定性。

溫馨提醒:本文約 4800 字,預計花費 9 分鐘閱讀。

後臺回覆 “交流” 進入讀者交流群;回覆“0216”獲取課件資料;

背景

作為中國領先的人壽保險公司,中國人壽不斷探索新的銷售模式轉型、加速數字化轉型。在數字化應用加深的同時,中國人壽在業務場景、保障手段方面,也逐漸面臨較大挑戰:

● 從中國人壽壽險業務以往每年的長險出單、學平險的營銷活動效果來看,系統在面對高峰流量衝擊時的表現,仍有較大改善空間,尤其在容量規劃方面;

● 雖在研發流程中有效能測試環節,但更多聚焦在測試環境,而由於生產環境、測試環境的差異性,導致測試環境的壓測結果無法精準地還原真實業務狀況。生產環境出現效能瓶頸,進而引起使用者投訴的情況時有發生;

● 此前中國人壽壽險業務的穩定性保障方式有待加強,原線上壓測技術對程式碼有侵入,不易推廣;

針對以上問題,中國人壽壽險研發中心在穩定性保障上做了較多落地實踐,在穩定性測試層面,整體思路是在能力層建設 4 種能力——無侵入線上壓測能力、混沌工程故障演練能力、自動化測試能力、數字化測試管理能力,來實現保穩定、提質效、優效能的目標。

而其中,保證生產部門穩定是重中之重,無侵入線上壓測作為賦能生產部門最重要的手段,我將重點分享其在壽險研發中心落地的經驗。

一、無侵入線上壓測有哪些建設目標?

1.1 原有壓測技術的侷限性

在無侵入線上壓測落地之前,我們有兩類傳統的壓測手段——測試環境壓測、生產環境有侵入壓測,而這兩種壓測都有一定的侷限性。

1.1.1 測試環境壓測

測試環境壓測的主要的問題是測試環境和生產環境不一致,包括:

● 程式不一致

● 配置不一致

● 資料不一致

● 操作人員不一致

1.1.2 生產環境有侵入壓測

生產環境的有侵入壓測是指生產環境通過修改原始碼來識別壓測流量,進而正確地路由壓測流量,保證壓測順利進行,而不汙染生產環境。這個方法的主要影響有三點:

第一是不統一。各系統各自為戰,缺乏統一的標準,協作較困難。

第二是技術難共享。技術推廣的難度大,導致很難實現全鏈路線上壓測。想要真正瞭解業務流程的狀況,必須對其全鏈路做測試,否則風險隱患始終存在。隔三差五冒出問題來,這對整個技術團隊、業務團隊的影響都很大。

第三點是不安全。我們缺乏統一的壓測安全管控措施,比如,壓測開關一旦出了問題能不能統一關掉?白名單是不是可以控制鏈路走向?壓測前的檢查、壓測中的資源監控、壓縮後的資料檢查,都缺乏相應的機制來保障。

1.2 線上壓測工作目標:“1+1+N"

無侵入線上壓測的工作目標可以用"1+1+N"來概括——1 個平臺、1 個流程、N 個場景。

1 個平臺——即要建設一個無侵入線上壓測平臺,能夠支援壽險技術中心在對原始碼無侵入的前提下開展壓測。

1 個流程——由於無侵入線上壓測的影響面非常大,關聯團隊非常多,涉及到開發團隊、測試團隊、部署團隊、生產保障團隊、網路組、平臺組等等,如果缺乏統一的流程或是職責不清晰,輕則導致工作無法執行,重則將造成生產事故,所以建立統一流程非常必要。

N 個場景——有了平臺和流程後,就可以基於此來支援壽險業務 N 個場景的線上壓測,比如長險出單、短險出單、培訓學習、APP 登入、重大技改等等。比如信創對系統的改造等重大技改,大家非常樂意通過無侵入線上壓測的手段,在生產上驗證技改前後效能的變化情況,這也是比較重要的應用場景。

二、如何搭建無侵入線上壓測“1 個平臺”?

2.1 平臺簡介

無侵入線上壓測平臺主要包括兩個模組,壓測任務執行模組和壓測鏈路管理模組。

壓測任務執行模組可以理解為一個雲化的 JMeter,用來施加壓測流量。壓測鏈路管理模組是基於業務應用中的探針,管理被壓測的鏈路,來實現線上壓測。

工作原理及主要流程:

綠色箭頭所示的壓測流量,首先到達業務應用 A,業務應用 A 上的壓測探針識別壓測流量,然後把它寫入到影子庫、影子日誌、影子 topic(這些影子儲存用來儲存儲存壓測資料,並與正式業務資料隔離開),進而把它傳遞到業務應用 B,業務應用 B 進行業務處理後開始進入到影子庫,這樣就實現了整體壓測流量的路由。走著同樣的業務應用通道,但是不影響正式庫和正式業務資料,這樣就達到了驗證正式業務鏈路效能的目的。

2.2 壓測探針

2.2.1 基本原理

壓測探針是整個無侵入線上壓測的核心部分,其基本原理是基於 Java 位元組碼技術,它的核心是修改 JVM 中已載入的位元組碼,在其中加入壓測流量處理邏輯,來實現壓測流量路由到正確的鏈路、寫入到影子儲存。注意,這裡不是修改原始碼,而是修改 JVM 裡面已載入的原始碼,以此來實現對原始碼和開發人員的無侵入。既不會造成原始碼的互相混淆,也不會因為程式碼侵入造成更多新的問題。

2.2.2 操作物件

壓測的核心目的就是想把壓測流量進行路由,讓它進入到影子儲存,並和正式流量區分開,而流量的路由一般是通過特定的中介軟體來完成,比如 Tomcat, Redis, Kafka, Oracle 等,所以理論上需要且僅需要增強這些中介軟體即可,不需要去全面梳理所有業務程式碼,這就使無侵入線上壓測的可行性大幅增加。

下圖簡要介紹了位元組碼增強邏輯如何識別壓測流量並將該流量路由到壓測鏈路。

2.3 應用管理

業務鏈路的基本單元是應用,每一個安裝了壓測探針的應用,都需在壓測前做好相關的配置,包括:遠端呼叫的介面,影子庫/表,影子消費者,影子日誌、快取、擋板等。

為什麼需要做應用配置?舉個例子,遠端呼叫的介面,為什麼要配置白名單?假設這個應用要調下游的某一個介面,則需要把它配置在白名單裡,這是出於安全考慮。因為業務的形式是很複雜的,更換一個投保要素就會到另一條鏈路了,而另一條鏈路如果沒有安裝探針就會出現異常,所以我們通過白名單來確保不走到預期外的鏈路,進而保障業務安全。同理,配置影子庫、影子消費者、影子日誌和快取都有相關的技術考慮,主要是為了將正式資料和業務資料做隔離,擋板部分後面會繼續介紹。

2.4 鏈路管理

我們通常把一個完整的壓測鏈路逐層向下分解為業務流程、業務環節、業務活動、應用,即一個壓測鏈路包括一個或多個業務流程,一個業務流程包括多個業務環節,依此類推。

以中國人壽壽險業務為例,“長險投保”這個業務流程,包含登入、選擇產品、填寫客戶資訊、上傳投保單、核保、繳費等多個業務環節。其中,“登入”這個業務環節,又包括查詢使用者狀態、校驗密碼等業務活動。每一個業務活動其實就是一個 API 的呼叫,每一個 API 的呼叫對應著一個子鏈路,如下圖所示:

這個子鏈路涉及多個應用,即一個 API 呼叫可能涉及多個應用。上面我們已經配置好應用,包括應用相關的儲存,這樣逐層就能把整個鏈路串起來,接下來就可以開始進行壓測了。

2.5 壓測執行

在壓測執行的過程中,我們提供了類似阿里 PTS 的全自動化的線上壓測能力,可以線上編輯指令碼、設定執行緒組、設定壓測引數等。

壓測過程中可實時檢視整體業務流程、單個業務活動的執行情況,包括 TPS、響應時間、成功率、資源利用率,以及告警和失敗請求資訊等等。TPS、響應時間、成功率等資料來自壓測引擎,資源利用率、告警和失敗請求資訊則通過壓測探針傳到監控模組。

測試執行、監控、報告均為自動完成,實現一鍵完成自動化效能測試。

三、如何設計壓測的 “1 個流程”?

3.1 流程簡介

首先需要提到的是設計流程的原則,“安全優先、嚴謹規範、統籌協作”。其中安全優先是第一位,我們在設計任何一個具體技術方案時,永遠是考慮安全優先,即使一個更安全的方案會導致工期延長一個月,我們也選擇這個方案。

線上壓測主要流程步驟包括:方案設計、鏈路梳理、環境準備、系統配置、鏈路除錯和壓測實施等 6 個環節。

3.2 實踐難點

3.2.1 難點 1:壓測目標設定

壓測目標會有什麼難度?其實還裡面會有一些小技巧。在下圖中,黃色的線可以作為歷史的峰值承載量,藍色的線作為本次壓測的期望承載能力,比如,某次設定壓測的期望峰值是歷史峰值的兩倍,在鏈路壓測結果出來後,最短板應用所能支撐的吞吐量在紅線的位置,它應該高於藍色的線(期望承載能力)。

那是不是這樣就可以保障整個鏈路沒有問題呢?事實並非如此,因為鏈路上的某個業務環節可能出現擁擠,比如有時登入環節會因為多種業務疊加(包括投保之外的業務)出現登入擁擠,一旦出現這種情況就沒有辦法開展後續操作了,針對這種情況,就需要單獨對登入環節做線上壓測,評估一個更高的值來滿足要求。所以線上壓測的目標有全流程的目標和單環節的目標。

3.2.2 難點 2:影子庫建立

在壓測過程中,有很大一部分工作量是在影子庫上,花費的時間遠超預期。主要有兩個問題,第一是如何建立影子庫,第二是準備多少鋪底資料。理想情況當然都是如上圖綠色部分,儘量符合實際業務情況,但在條件不具備的情況下,可以考慮用一些折中的辦法,比如可以新建一個數據庫例項,可以準備一定量級的資料,這個量級可以通過測試環境梯度壓測的方法來預先獲取。

3.2.3 難點 3:擋板 Mock

擋板有兩個作用,第一個作用是遮蔽不希望被執行的業務。比如不希望傳送簡訊,因為發簡訊這個環節出效能問題的風險較小,所以要把它遮蔽掉,這一塊就用入口擋板把它擋掉即可。

 第二個作用“執行希望被執行的業務”相對比較難理解,舉個例子,保險業務中的影像稽核,因為很難構造符合真實情況的影像資料,所以測試業務流轉到這個環節,影像稽核就會失敗,導致後面的環節就無法壓測了。此時,在“影像稽核”應用出口部分增加擋板,把稽核結果改成正確即可解決。這樣好處是真實的壓測到了影像稽核的業務邏輯,驗證了該應用模組的效能,同時又不阻斷整體壓測流程。此外,還需重點關注資料隔離,資料隔離是保障我們壓測安全的重要手段。

3.2.4 難點 4:風險預案制定

我們要保障安全壓測,必須要做相應的風險預案,例如,對生產系統過載、探針影響正常業務以及業務資料被汙染等情況,我們都制定了相應的應急預案,具體如下表。

四、重大業務“N 個場景”保障成效如何?

我認為主要有 3 個成效——

第一是能夠準確評估系統容量,做到重大業務活動心中有數。我們在線上實施了 9 次全鏈路壓測,涵蓋了長險投保、短險投保、使用者登入、簽到、學習等等眾多業務場景,完成了各場景在生產環境的容量評估。下圖,可以準確看到各個場景的最大容量,讓我們很有信心地開展重大業務活動。

第二是能夠提前發現線上環境問題,保障業務系統穩定執行。通過十多個子團隊(含部署)、技術處以及資料中心關聯團隊的協作,提前識別出生產壓測中的效能問題,避免了線上故障引發使用者投訴。

(部分鏈路中識別出的效能問題)

第三是可以真實地開展效能指標對比驗證,支援重大技改。下圖可以看到,測試前後以及優化前後,效能都有大幅的提升,幫助重大技改後快速度過不穩定期。

公眾號後臺回覆【0216】獲取資料

回覆【交流】進入讀者交流群

宣告:本文由公眾號「TakinTalks 穩定性社群」聯合社區專家撰寫,並已獲授權整理髮布,如需轉載,請公眾號後臺回覆“轉載”獲得授權。