*作者：沈斌、右京*

## 業務場景與挑戰

友邦保險是香港聯合交易所上市的人壽保險集團，覆蓋 18 個市場。截至 2021 年 12 月 31 號，總資產 3400 億美元。

友邦保險於 1992 年在上海設立分公司，是改革開放後最早一批獲發個人人身保險業務營業執照的非本土保險機構之一，也是第一家將保險營銷員制度引進國內的保險公司。2020 年 6 月，友邦獲批將友邦保險有限公司上海分公司改建為友邦人壽保險有限公司。2020 年 7 月，友邦人壽正式成為中國內地首家外資獨資人壽保險公司。友邦友享 App 在 2021 年榮獲最佳保險科技平臺。

### 業務特點和架構

![1.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/23b4d57d0c8b499da61a13a5474c9711~tplv-k3u1fbpfcp-zoom-1.image "1.png")

為了踐行友邦健康長久好生活的 slogan ，上雲過程中我們對應用做了大量微服務化改造，以適應快速變化的業務要求和效能要求，並將此前在 AS400 裡的 core 包程式做了微服務化改造，提高了可用時間。此外，我們採用了容器化方案，使應用執行在 K8s 上以獲得彈性擴容能力和自愈能力。

上述改造導致了應用系統複雜度的提升，因此，觀測微服務和 K8s 的執行成為了一大挑戰。

與此同時，部分外採應用沒有原始碼，不適合做微服務化改造，但我們仍然對這部分應用進行了容器化改造，將它們部署進 K8s；還有一部分應用由於各種原因，不適合上雲改造，最終留在了 IDC 機房。因此，服務之間的呼叫會涉及雲上到雲下、雲下到雲上等複雜情況。

遷雲之後實實在在為我們帶來了 SLA 的提升，但也導致了訪問鏈路和部署複雜度的提升，如何更好地觀測應用成為了無法迴避的挑戰。

### 可觀測性建設痛點和挑戰

![2.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/d0dce5137bbd49148a3652d8238334b9~tplv-k3u1fbpfcp-zoom-1.image "2.png")

建設一個優秀的觀測系統，會面臨以下痛點：

-   **觀測複雜度提升**：雲原生微服務化雖然帶來了很高的 HA，但也提升了系統的複雜度，加大了可觀測的難度。核保透過率、交單成功率、使用者的日活/月活散落在各個業務模組裡，業務需要提供全域性視角，以觀察整個保單生命週期裡重要業務節點的執行情況，並獲取研發態的具體情況。

-   **技術選型困難**：由於歷史原因，友邦內部應用技術選型不一，版本各異，導致可觀測技術和呼叫鏈追蹤面臨很大的困難。

-   **統一觀測困難**：友邦是一家金融公司，開發系統和應用運維完全分開，日誌也完全分開儲存和維護，因此無法將以上資料在同一個大盤裡呈現。

-   **指標治理**：IaaS層、PaaS 層和應用層有很多指標，單資料庫方面就可能有超過 200 多個指標。如果希望指標達到比較容易理解與追蹤的數量，則需要不斷地進行回顧、刪減。

-   **快速故障定位**：在 IDC 機房時代，沒有直觀的方式讓應用檢視自己的資源是否足夠。雖然已經有商業 APM 工具，但其價格高昂，不屬於經濟有效的方式。問題發生時，因為只有少量應用安裝了 APM ，所以呼叫鏈不完整，無法實現快速故障定位。

### 可觀測性建設流程和規劃

![3.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/0095a923588243d2b4955cbdf4e22fad~tplv-k3u1fbpfcp-zoom-1.image "3.png")

可觀測系統的建設主要分為**調研分析**、**方案設計**、**改造實施**和**上線驗證**四個階段。

一個優秀的可觀測系統至少需要滿足五個要求：

-   **服務資源追蹤**：可以將服務執行節點上的 CPU 記憶體、網路磁碟、 IO 應用指標進行聚合。問題發生時，能夠輕鬆觀察到異常指標。

-   **提供服務 Top 檢視**：按照服務的呼叫量、請求耗時、熱點排名，應用可以很方便獲知哪些是熱點 API、哪些 API 請求量較高等，可以更好地規劃自身的服務資源。

-   **呼叫鏈追蹤**：關聯服務上下游，並且最好是無侵入式，可以很方面地從 Trace關聯到日誌，獲取到鏈路問題所在。

-   **呼叫時長分佈**：觀察服務的上游與下游，觀察非同步耗時，請求慢時可以很方便地判斷是服務資源耗時還是依賴服務資源耗時。

-   **資料庫關聯操作**：幫助應用觀察到 API 的關聯 SQL、慢 SQL、 Redis 的查詢存在慢 key 查詢 、Mongo 存在慢查詢等操作。

## 實踐與落地

### 可觀測性整體設計思路

![4.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/f0b66d9b9b5f46da93fd3dd2a9246dcb~tplv-k3u1fbpfcp-zoom-1.image "4.png")

友邦為了滿足業務發展需求，在技術層面需要做雲原生技術架構的升級和改造。因此阿里雲與友邦在應用容器化和可觀測性上展開了深度合作。結合業務情況和監控痛點，透過幾十次的討論和推演，我們最終明確了兩個重要建設思路：

首先，**根據業務價值自上而下設計可觀測體系**。從業務監控、應用監控和資源監控一直向下推進。如果使用自下而上的設計方式，出現問題時團隊會浪費大量時間和精力排查從來不會導致客戶受影響的問題，或客戶先於監控系統發現了問題。因此，需要最先關注和設計與使用者體驗、核心交易相關的業務監控。

其次，**需要結合業務設計服務的鏈路追蹤、應用效能監控**。比如將某應用的 API 介面翻譯成業務可讀懂的語言，比如依靠保單生效的介面處理時間和處理數量以及介面還呼叫/依賴了其他哪些服務等來最終明確問題所在，最後結合應用診斷工具 Arthas、 JVM 的調優工具、應用日誌以及資源級別的監控來確認是程式碼問題還是底層資源的使用問題。透過從確定事故發生再到定位引起事故的原因，進而確認問題本身來提升故障發現和問題定位能力。

確認了自上而下的可觀測體系後，接下來需要明確可觀測的指標範圍。

### 全生命週期監控指標設計

![5.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/1866262f82a14d11a7c44550d5d8b939~tplv-k3u1fbpfcp-zoom-1.image "5.png")

可觀測指標不僅是執行態，還需要包含研發態，形成應用全生命週期的監控指標體系。

系統經過雲原生改造後，友邦的 CICD 流水線透過 Jenkins 進行自動化。為了提升軟體的研發效率，需要抽象出可衡量的指標，比如應用每天的構建次數、構建時長、構建成功率、部署頻率或部署成功率，以及形成這些指標的基礎後設資料資訊等。

執行態分為系統層監控、應用層監控和業務層監控三層，監控重要性等級依次升高。資源監控層主要聚焦在 K8s 叢集的 node 節點、磁碟網路、執行 Pod 監控、核心雲產品等監控指標；應用層主要聚焦於應用的健康度、狀態碼、效能監控、JVM、GC 等效能指標上；業務層主要監控業務的核心指標，如 PV、UV、投保人數、投保金額、簽單數等，它直接影響著監控系統設計的成敗，因為這是最能夠體現業務價值的部分。

### 可觀測性架構大圖

![6.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/3da0ab1aa77046fab02d451db25b52fc~tplv-k3u1fbpfcp-zoom-1.image "6.png")

上圖為友邦人壽可觀測性體系的架構，總體設計思路分為三層：

第一層為**採集層**。因為要符合友邦的技術架構和建設需求，我們選擇用 Java 編寫流水線的 CICD 資料採集器。研發人員在使用 Jenkins 進行應用的 build 或 deploy 時，該採集器能將應用構建的資料和部署的資料全部存到資料庫裡。另外，採集資料時加上了相關聯的 tag ，實現了後設資料的共享。比如流水線構建的應用名稱必須與 K8s 的服務名稱一致，構建失敗時即可快速找到出錯的應用。

此外，針對應用的 APM 探針，社群一般使用位元組碼增強的無侵入技術。但是由於友邦架構的複雜度，Skywalking 探針無法完全覆蓋友邦的場景。同時，友邦對於深度效能的診斷也有較高要求，希望能夠整合阿里開源的 Arthas、 Memory dump 等能力，APM 探針也會影響應用效能，因此我們最終選擇經過雙 11 大規模檢驗的 ARMS Agent。

各類雲產品中介軟體、叢集的監控指標採集主要透過 Prometheus；應用日誌主要使用 DaemonSet 的方式進行採集，相比於 Sidecar，其佔用資源更少，工程上也更為簡單。

第二層為**儲存層**。研發態的後設資料和 pipeline 的構建資料因其資料量不大，而且是結構化形態，因此儲存在 MySQL 裡。Metrics 監控指標的資料儲存在阿里雲的 Prometheus 產品上，日誌和呼叫鏈 Tracing 資料儲存在阿里雲的 SLS 產品上。考慮到業務的增長，未來會產生大量的資料，這兩款產品能夠保證監控系統的穩定性、可擴充套件性和高可用性。同時，兩款產品都是 Serverless 化持續按量付費，不存在磁碟或空間浪費。

第三層為**統一展示層**，透過 Grafana 進行匯聚和展示。當時阿里還未推出託管版的 Grafana，因此我們選擇自建，推薦使用 8.0 以上的版本。為了保證執行的高可用，需要多例項部署，並將配置的資料統一傳到資料庫裡，然後根據此前設計的監控指標，選擇對應的資料來源編寫查詢語句，最終結合 Grafana 豐富的圖表進行統一展示。

業務監控的實現是透過將採集到 SLS 裡的業務日誌和應用日誌做統計分析。SLS 的 SQL 查詢功能非常豐富，語句編寫也非常方便。再透過 SLS Grafana 外掛整合到 Grafana 裡，最終業務統計資料即可在 Grafana 大盤進行展示。

### 統一監控平臺

![7.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/11a8c7d8bff1499aa8ed4fbd26af2de7~tplv-k3u1fbpfcp-zoom-1.image "7.png")

上圖為建設成果。透過大屏、中屏和小屏的方式形成指揮決策、研發儀表盤&應用效能展示以及告警推送、多維度的監控能力。

其中左側大屏展示核心指標，比如容器叢集的資源利用率、service Pod 健康度以及聯通性等通用指標，為公司決策提供支援。

右上方中屏主要展示流水線的研發效率指標、應用效能的指標以及全域性呼叫鏈，幫助研發人員提升效率和問題定位的速度。

右下方小屏透過歷史資料的對比，設定了報警閥值。出現異常時，透過釘釘或簡訊報警的方式推送到電腦、手機終端，幫助運維人員及時發現和處理問題。

***

## 關於可觀測性諮詢服務

![8.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/06ac8769b27b4fc7b38242957d6d1b76~tplv-k3u1fbpfcp-zoom-1.image "8.png")

**點選**[**此處**](https://www.aliyun.com/product/arms) **，瞭解更多產品詳情！**

友邦人壽可觀測體系設計與落地

相關文章