作者：十眠、水彧
可觀測介紹
彼得·德魯克曾經說過：“如果你無法量化它，你就無法管理它。” 可觀測性（Observability）是幫助微服務穩健執行的重要一環。“我們的系統是否還是正常的？”，“終端使用者的體驗是否符合預期？”，“我們如何在系統快要出問題之前主動發現系統的風險？”。如果說監控可以告訴我們系統出問題了，那麼可觀測就可以告訴我們系統哪裡出問題了，什麼原因導致的問題。可觀測不但可以判斷系統是否正常，還可以在系統出現問題之前，主動發現系統風險。
從系統的角度來講，監控以 Ops 為主，聚焦在發現，確保系統穩定性。可觀測性的目標是白盒化，注重 Recall+Precision，貫穿 Dev/Tester/Ops 等環節，通過多種觀測手段，確保找到根因，防患於未然。
雲原生下微服務應用可觀測的挑戰
目前，常見的微服務框架包括 Spring Cloud 和 Dubbo 等多語言微服務，並具備服務註冊發現、服務配置、負載均衡、API 閘道器、分散式微服務等基本能力。其中，服務治理包括無損下線，服務容錯，服務路由等能力。可觀測性包括應用監控，鏈路追蹤，日誌管理，應用診斷等。
隨著雲原生到來，微服務架構得到越來越多的應用。由最初以機器為核心的雲伺服器 ECS 上雲，到以容器為核心的容器化雲原生部署；為了更加敏捷，阿里雲開始以應用為核心的微服務化。如今，當微服務發展到一定應用規模，阿里雲開始圍繞業務核心，以提效穩定為目的的服務治理。
在雲原生下的微服務可觀測主要面臨三個挑戰：
• 發現難
從雲伺服器 ECS 到 Kubernetes，微服務架構複雜度提升，觀測物件複雜度提升，監測資料覆蓋不全。
• 定位難
隨著多種治理能力深入，可觀測要求高，服務框架複雜度增加，技術門檻提升，資料本身複雜度提升，資料關聯性差。
• 協作差
隨著組織角色變化，可觀測不只是運維工作。
應用實時監控服務 ARMS 作為阿里雲可觀測產品，支援自動檢測部分產品問題。目前已經覆蓋五十多個故障場景，包括應用變更、大請求、QPS 突增等，診斷報告認可率高達 80%。
如下圖所示，線上 7%的應用都在 Dubbo 的 RPC 上耗時，並由於埋點問題，無法定位出根因。
阿里雲在為客戶服務過程中，發現了很多問題。
• 服務發現
當前一些監測工具無法實現服務框架服務發現層面的問題診斷，導致遺留了許多服務呼叫問題難以排查，單看監控使得客戶根本無從下手。因此，我們希望通過提供以下方面服務發現監控診斷能力，幫助客戶及時排查服務發現領域出現問題導致的應用執行異常。
（1）監控客戶端出現 no provider 問題；
（2）微服務應用連線的是哪個註冊中心，服務發現鏈路呼叫示例圖，大塊內容有 Provider、Consumer、註冊中心，點選對應元件可以看到詳細相關地址；
（3）應用服務是否註冊成功；
（4）應用最近一次拉下來的地址數量 & 內容；
（5）應用與註冊中心的心跳是否健康；
（6）註冊中心狀態資訊，如 CPU、記憶體等執行硬體狀態資訊，註冊服務數目、訂閱服務數以及服務內容等資訊。
• 微服務生命週期
微服務啟動慢，一個伺服器花 3 分鐘，5 個伺服器花 30 分鐘。我們希望應用啟動過程中，從 Spring bean 載入、連結池連線的監測、微服務的服務註冊、Kubernetes 的監測檢查就緒；應用下線過程中，服務註冊、在途請求的停止、定時任務/MQ 等取消、服務停機；例如：Spring bean 初始化異常，卡在哪個 bean 的載入上，哪個 bean 初始化耗時特別長。幫助使用者分析啟動慢的原因，自動給出修復建議。然而，目前整體過程是缺少相關觀測能力。
• 呼叫鏈路
Consumer 呼叫超時、Provider 卻快速返回。
除此之外，還有微服務配置混亂，不好梳理；微服務應用上 Kubernetes 之後，出現執行緒池滿，卻找不到原因等一系列問題。
那麼，當站在微服務視角思考如何進行體系建設時，我們提出的微服務可觀測性增強解決方案。站在傳統監測方案之上還能再做哪些事情？
微服務場景下可觀測的探索與實踐
微服務可觀測增強解決了什麼問題
一句話概括就是：全面增強微服務場景下的可觀測能力。
讓一線運維人員具備微服務診斷基本能力，可以排查 80% 的微服務常見問題，快速進行效能分析診斷。
ARMS 微服務可觀測增強方案回答了以下問題：
• 為什麼服務啟動很慢
從 Pod 建立到應用初始化再到服務註冊應用啟動，端到端分析出應用啟動慢的根因，補齊應用啟動生命週期的可觀測能力；
• 依賴是否存在隱患
為 SpringCloud/Dubbo 依賴的 Jar 包進行分析，定位是否存在 Jar 包依賴衝突等問題；
• 配置分析
微服務場景下配置分散且冗餘，提供應用執行時配置可觀測能力以及配置優化的專家經驗；
• Dubbo 呼叫鏈增強
覆蓋定址，序列化，網路等階段的埋點，一眼看出 Dubbo 呼叫的時間都去哪兒了。
為什麼服務啟動慢？通過從 Pod 建立到應用初始化再到服務註冊應用啟動，端到端分析出應用啟動慢的根因，補齊應用啟動生命週期的可觀測能力。
通過將整個流程串聯，實時觀察到每個點的耗時，可觀測檢視把問題剖析出來。上圖是 ARMS 容器啟動分析功能。左邊是服務啟動，系統將啟動過程中的每一塊時間拆分出來，從而清晰看到微服務啟動慢在了哪一步，增強了其可觀測性。
微服務引擎提供了無損上線的能力。控制檯動態配置，實時無損上下線可觀測檢視，完整解決方案無需改一行程式碼。在微服務啟動的全流程進行各種方案的保護與治理：預建連線階段通過提前非同步建立連線保證不會阻塞在連線建立的過程中；服務註冊發現階段通過並行註冊與訂閱能力進一步提升應用的啟動速度；在小流量預熱階段通過調整客戶端的負載均衡能力保證新起的例項中流量緩慢增長。
由於微服務配置的覆蓋關係較為複雜，需要進行配置分析。
上圖為 Dubbo 官方提供的配置覆蓋關係，可以看到其具有一定順序先後性。很多時候很難判斷配置是否配錯地方，是否生效，是否被覆蓋。微服務場景下配置分散且冗餘，我們提供應用執行時配置可觀測能力以及配置優化的專家經驗。
我們提供了為 SpringCloud/Dubbo 依賴的 Jar 包進行分析的能力，幫助定位是否存在 Jar 包依賴衝突、依賴的 Jar 是否存在安全、效能風險等問題。
一次 RPC 呼叫時間到底去哪兒了？一次 RPC 呼叫有路由、限流降級、序列化、網路等各個環節。從客戶端來講，需要經過路由、filter、invoker、serialize、remote。從服務端來講，需要經過 serialize、Proxy Invoke、filter、impleme。
上圖是一次 RPC 呼叫流程圖。其中包括定址、負載均衡的建立連線時間，打包的序列化時間，解包的返印值反序列化時間，服務端處理時間和等待服務端處理返回的時間。
如上則是我們給出的答案，將呼叫鏈在 RPC 框架內進一步細分，一眼看出路由、序列化、網路、代理、服務端處理等耗時的細節。
總結
微服務可觀測增強方案站在傳統的可觀測性方案之上我們進一步從微服務的視角出發，擴充套件傳統可觀測覆蓋的 Tracing、Logging、Metrics 等資料，結合微服務專家的診斷經驗。
從前端、應用至底層機器，應用實時監控服務 ARMS 實時監測應用服務的每次執行、每個慢 SQL、每個異常。與此同時，提供完整資料大盤監控，展示請求量、響應時間、 FullGC 次數、慢 SQL 和異常次數、應用間呼叫次數與耗時等重要的關鍵指標，時刻了解應用程式的執行狀況，確保向使用者提供最優使用體驗。
阿里雲微服務引擎 MSE 全新升級，在治理中心 MSE 提升了微服務開發效率和穩定性。支援近 5 年 Spring Cloud 和 Dubbo 應用，及多語言異構微服務體系。提供無損上下線、全鏈路灰度、離群例項摘除、服務鑑權、等差異化能力。在註冊配置中心，MSE 擁有全託管 Zookeeper/Nacos/Eureka 服務。預設高可用：多可用區部署、自動探活。配置鑑權，加密和灰度釋出。在雲原生閘道器方面，MSE 整合監控告警、鏈路追蹤、限流降級、證書管理。流量閘道器於微服務閘道器二合一，成本下降 50%。
