作者 | 劉慕雨 中國工商銀行軟體開發中心雲計算實驗室
在資訊系統建設方面，工商銀行一直積極探索，以開放的姿态借鑒行業先進經驗，旨在為客戶提供更優質的金融服務和使用者體驗。随着分布式架構和雲計算平台在工行的廣泛應用，如何高效排查程式錯誤或性能瓶頸，是個棘手的問題。
為此，我們基于 Arthas 建設了線上診斷平台，在保護客戶資訊安全的原則基礎上，對相關能力做了剪裁和整合，通過 Web 方式支援更複雜的互動場景，在實際線上問題分析中發揮關鍵作用。
工行線上診斷平台：
下面對工行線上診斷平台的建設做個階段性總結，分享一下我們的建設經驗、實際效果以及未來展望，也希望能給社群提供一個參考。
傳統方式排查問題的痛點
對于後端工程師，一旦線上程式邏輯出錯，問題排查如同破案，在分析研判時，問題現場的第一手資訊是最珍貴的。開發人員很容易首先想到的就是閱讀日志，從海量的日志中尋找蛛絲馬迹，這就好比是對犯罪現場周邊的視訊監控錄像逐一回看，非常辛苦。如果問題現場的日志記錄缺失，就嘗試在本地重制問題并調試解決，本地難以重制的，隻能再加日志，再部署，再重制，然後再查日志，效率較低。對于複雜一些的比如程式性能問題，如何定位性能瓶頸，一不小心又要回到加日志、部署、查日志、再加日志的老路，不僅效率不高，也破壞了問題現場。
JDK 提供的工具如 jps、jmap、jstat、jstack、jconsole 等，可以為工程師提供一些幫助。Linux 作業系統的指令，如 top、free、pidstat、vmstat、iostat 等，也是排查問題尤其是性能調優必不可少的工具。但直接使用這些工具，對工程師的個人技術能力和經驗要求較高。而且對企業來說，在生産環境直接通過指令行操作，是很敏感的行為。是以，如何在保證安全的基礎上，又能像調試本地程式一樣更便捷的排查分析，是個棘手的問題。
Arthas 的解決方案
2018 年我們在參加一次 Dubbo Meetup 上，聽了關于使用開源的 Arthas 工具排查 Dubbo 問題的分享。研究發現，Arthas 通過 JVM 的 Attach 機制，在不影響服務連續性的情況下，實時連接配接到目标程序，便于工程師線上排查問題。此外，Arthas 的位元組碼增強架構，可以通過 Instrumentation 技術動态修改位元組碼（需要 Java 虛拟機實作支援 retransformClasses），替換成新的 class，這就為線上調試提供了可能。
Arthas 原理圖：
比如，使用 watch 指令，實時觀測方法的調用情況；使用 jad 指令，把位元組碼反編輯成 java 代碼；使用 redefine 指令，可以對代碼做熱更新，讓開發人員告别不停“加日志、部署、查日志、再加日志”的套娃時代。在 Arthas 剛推出沒多久，還提供了一個簡單的 Web Console 功能，實際是一個以 Websocket 通路 Arthas 程序的方式，這也為我們後面建設線上診斷平台提供了思路。
落地使用上的困難
直接使用 Arthas 的指令行互動方式，不能滿足金融級運維要求，在落地使用上存在一些實際的問題：
- 資訊安全問題：Arthas 可以通過指令行方式，直接觀測方法的入參、傳回值，這就涉及到一些客戶敏感資訊，直接在生産環境使用指令行操作顯然是不合适的。
- 學習成本問題：工具的安裝使用存在一定的學習成本，尤其是對于新員工來說。
- 多人協作問題：當多個開發者對同一個目标程序進行診斷時，可能存在沖突，例如，一個同學正在 watch 某個方法，另一個同學把這個方法 redefine 了，那麼第一個同學 watch 到的其實是别人替換後的代碼的運作情況，這就像一個多線程通路共享資源的線程安全問題。再比如兩個同學都在 attach 同一個程序，一個同學用完了，直接把 Arthas 程序 shutdown（關閉），而另一個還在使用的同學就突然不能用了。
- 資源占用問題：如果開發者忘記關閉 Arthas，Arthas 程序會占用一定的系統資源（如記憶體、CPU）。當然，Arthas 本身對資源開銷是有很多考慮的，比如 Arthas 使用自定義的類加載器加載自身的類，在關閉時将引用置空，這樣在下一次垃圾回收的時候，自定義類加載器加載的類就會被回收，進而避免對原有工程的影響。是以，我們認為 Arthas 應該在排查問題時使用，而不應該當作正常監控工具一直運作。
- 環境不統一問題：在不同的 Java 虛拟機實作安裝和使用 Arthas，可能會碰到一些奇怪的問題，比如用 Hotspot 虛拟機運作 Arthas 程序，而目标虛拟機是 J9 實作，attach 的時候可能會出錯。另一方面，生産環境雲上、雲下節點規模龐大，網絡通路權限是嚴格控制的，開發人員想遠端連接配接目标程序，涉及到權限開通、版本管理、安裝程式下發等問題。
技術方案
我們設計了一套輕巧的架構，讓開發人員以 Web UI 的方式，便捷、直覺的使用各類線上診斷能力。那麼我們是怎麼做的呢？
1. 整體架構
整體架構大緻分成線上診斷平台、線上診斷網關（後簡稱網關）、線上診斷程序三部分，通過一個網關叢集統一代理對雲上、雲下節點的通路，網關提供 Restful 接口給線上診斷平台（後簡稱平台）調用。一個接口可能組合了多個 Arthas 指令，也可能對指令的執行結果進行剪裁和修改，處理成 json 格式資料傳回給平台做展示。
整體架構圖：
1）線上診斷平台
線上診斷平台是開發人員進行線上診斷的入口，平台通過 Web UI 的方式提供一站式線上診斷能力，支援複雜的互動場景。除了提供出色的使用者體驗，平台還解決了安裝解除安裝、多人協作、使用者鑒權、連接配接保持、操作審計等問題。
- 安裝解除安裝：根據使用者在平台輸入目标節點和程序資訊，實作診斷程式的安裝和解除安裝，具體将在下一節介紹。
- 多人協作：當多個使用者同時診斷同一個程序時，對于存在沖突的功能，平台通過分布式鎖實作互斥，保障同一時刻隻有一個使用者能使用，當然這麼做的前提是平台在功能設計時考慮原子性。另外，當一個使用者試圖關閉一個其他使用者正在使用的連接配接時，也會被拒絕。
- 使用者鑒權：建立審批和黑白名單機制，基于 RBAC 模型，同時關聯 CMDB，對操作人員的權限進行嚴格管控，普通開發者需要被授權才可使用，各類診斷功能的使用權限也和使用者角色挂鈎，權限控制強度從生産環境到開發環境逐漸減弱。
- 連接配接保持：Arthas 一些指令比如 dashboard，提供了實時監控目标程序整體運作情況的功能，預設每 5 秒重新整理一次。對于這樣的功能，平台的前端通過 websocket 與後端保持連接配接，後端記憶體中維護了一個目标對象和已連接配接使用者的對照關系，如果多個使用者同時監控某個目标對象，後端每次隻會定時發送一次請求給網關。這麼做的好處，是在保證了實時監控的同時，節約連接配接資源，避免了多人通路時，到目标伺服器的不必要的重複連接配接。此外，為了防止使用者忘記解除安裝診斷程序，對照關系也會同步到配置中心，當記憶體中某個目标對象對應的使用者全部下線時，會觸發一次檢查，如果發現配置中心中的使用者也已經全部下線，平台會自動發送 shutdown 請求給網關，解除安裝診斷程序。
- 操作審計：通過切面的方式，對使用者的各類操作進行記錄和存儲，達到審計的目的。
2）線上診斷網關
網關的作用，一是統一打通了到行内雲上、雲下環境的火牆；二是由于我們當時使用的 Arthas 版本還不支援 Restful 接口（最新版本已支援），傳回封包都是文本的形式，網關側在這裡會對文本進行解析，處理成 json 格式的結構資料，友善平台側做展示。歸納起來，網關的主要目的是統一代理對目标節點的通路，同時封裝診斷能力，提供标準 json 結構資料的 Restful 接口給行内各平台通路。網關在封裝診斷能力時，還會進行參數校驗、逾時管理、資料脫敏、文本處理等工作。
- 參數校驗：網關需要對診斷指令的參數做合法性校驗，比如tt指令要控制最大觀測次數防止撐爆記憶體，保證使用安全。
- 逾時管理：一些監聽類的指令，比如watch指令，如果一直監聽不到調用，需要設定逾時時間，防止連接配接一直不被釋放。
- 資料脫敏：對于涉及客戶敏感資訊的指令，網關會做資料脫敏，保障客戶資訊安全，部分關鍵業務的敏感資料，網關側會做封閉禁止通路。
- 文本處理：網關向 Arthas 程序發送指令後，收到的封包是文本形式，為了便于平台側展示，網關将非結構資料處理成結構資料，并對文本中的一些非關鍵資料進行剪裁。這裡要注意因為 telnet 有個視窗大小的配置要适當調整，配置太小的話有可能導緻文本不全。
3）線上診斷程序
也就是 Arthas 程序，需要考慮安裝、啟停、版本管理、網絡隔離等問題，具體做法在下一節詳細介紹。
2. 診斷過程詳解
工程師第一次對目标伺服器進行診斷時，涉及安裝、啟動、使用、解除安裝等一系列步驟，如下圖所示：
1）診斷前準備
下圖是我們的安裝界面，當使用者授權通過後，即可填寫目标伺服器資訊開始安裝。如果是傳統虛拟機時，使用者需輸入虛拟機 ip 和目标程序關鍵字（如程序的 pid、程序的啟動類名、程序的 jar 名稱等）；如果是容器，還需提供容易 id：
2）開始安裝
使用者點選安裝後，會觸發一系列操作。首先線上診斷平台發送一個探活請求給網關，網關收到請求後相應的也發送一個空指令給目标節點。平台根據響應判斷，如果探活成功，則發送診斷請求開始診斷；否則發送安裝請求到行内指定的管理系統（傳統虛拟機/容器，後續簡稱通道）。
3）擷取安裝媒體
以傳統虛拟機為例（如果是容器則把安裝媒體下發到主控端），通道去目标伺服器指定目錄查找診斷程式的版本檔案，如果擷取成功且版本是最新的，則通道直接執行啟動腳本。否則，通道會通知目标伺服器從公共的檔案伺服器上，下載下傳最新版本的安裝媒體。
4）啟動診斷程式
安裝媒體實際是一個壓縮包，包括安裝腳本、jar、版本檔案等。安裝媒體首次下載下傳到目标伺服器後，通道對其解壓并執行啟動腳本。我們修改了 Arthas 的啟動腳本，根據使用者輸入的程序關鍵字，找到目标程序，然後使用和目标程序相同的 jdk 版本，啟動診斷程式。注意，啟動時 Arthas 的 target-ip 參數被設定為網關位址，以隔離其他管道通路，預設值 127.0.0.1 表示隻能本地通路。
5）使用和解除安裝
診斷程序接收使用者診斷指令，開始診斷。使用完使用者可手工點選解除安裝，銷毀診斷程序。
實際使用效果
這裡舉幾個例子，看一下平台的實際使用效果。
1. 控制台
基于 dashboard 指令，控制台實時展示目标程序的整體運作情況，包括線程、jvm、作業系統等，每隔 10s 重新整理一次，使用者也可選擇手動重新整理。線程按 CPU 使用率取 TOP10，jvm 主要展示記憶體分布和 GC 情況：
點選查詢更多可以檢視詳情，比如監控 jvm 的記憶體及垃圾回收情況：
2. 線程清單
線程清單頁面按 CPU 使用率分頁展示所有線程，支援按線程狀态（如 RUNNABLE、BLOCKED）過濾，在控制台頁面點選檢視更多，也可以直接跳到此頁面：
點選某條記錄，跳轉到線程詳情，展示線程堆棧，在堆棧中選中一個方法，則可以直接進行方法觀測、方法追蹤、方法追溯、方法監控、反編譯等操作：
3. 方法監測
方法監測指的是對方法運作情況的監控和觀測，具體包括下面幾個功能。
1）方法觀測
支援對選中的堆棧中的方法進行觀測，也就是 watch 指令，這裡以開發環境舉例（開發環境不做資料脫敏），可以實時捕獲方法的輸入、輸出、異常堆棧、執行耗時等，并且支援指定觀測次數、耗時限制等條件。比如我這裡對 UserServiceImpl 類的 findUser 方法的調用情況進行觀測：
當方法抛異常時展示堆棧：
2）方法追蹤
方法追蹤指的是追蹤方法的調用棧，列印每個方法的執行耗時，基于 trace 指令實作，在排查性能問題時非常有用。看一下方法追蹤的界面，直接高亮标記出調用棧上耗時最久的方法，也支援配置過濾規則，過濾一些不關心的方法（比如 java 底層代碼）。在這個方法調用棧界面，又可以選中其中某個方法，進行觀測、追溯、監控等操作，不同的診斷能力之間都是打通的：
3）方法追溯
有時需要追溯方法被誰調用了，則可以使用方法追溯。比如這裡通過方法追溯可以看到 Dubbo 的 Filter 處理鍊：
4）方法監控
有時我們需要對某個方法一段時間的執行情況進行觀測，這時可以使用方法監控功能。比如這裡每隔 10 秒統計一次方法的執行次數、成功失敗次數、平均耗時、失敗率等名額：
4. 反編譯
當我們需要确認 Java 虛拟機加載的代碼情況時，比如你修改的代碼是否生效，我們在本地經常使用一些反編譯工具以達目的。jad 指令提供了線上反編譯能力，我們基于 jad 以界面的形式展示 Java 虛拟機加載的實際代碼，同時也會展示類加載器樹、類的路徑。比如這裡對 findUser 方法的反編譯情況（不指定方法名的話，則對整個類反編譯），可以看到這個類屬于 springboot 項目，被 spring 的類加載器加載：
5. 其他能力
我們對其他的實用指令，也做了一些封裝和定制，比如 sc、sm、redefine、tt 等，這裡就不一一介紹。此外，我們也将實時診斷能力和内部監控運維系統相整合，在排查問題時，可以通過直接跳轉的方式申請線上診斷權限，對目标程序做實時診斷。下圖是行内全鍊路跟蹤産品截圖，支援直接對問題鍊路關聯的節點進行診斷：
回顧與展望
簡要回顧一下前面提到的幾個困難和我們的解決方案：
- 學習成本問題：我們通過 Web UI 的方式降低學習成本，也提供了更複雜的互動場景和出色的使用者體驗。通過網關統一提供 Resful 接口提供結構資料，也更便于內建到企業内部其他運維平台。
- 多人協作問題：通過會話管理、互斥通路、自動解除安裝等手段，解決多人協作問題。
- 資訊安全問題：通過使用者鑒權、資料脫敏、操作審計、網絡隔離等手段，解決資訊安全問題。
- 資源占用問題：通過自動解除安裝、減少連接配接、自定義類加載器（Arthas自帶）等手段，在充分性能測試基礎上，保障資源占用可控。
- 環境不統一問題：通過搭建網關叢集，統一代理對雲上、雲下環境的通路。采用一緻的政策，統一管理雲上、雲下環境媒體的版本、下發和安裝。
目前，工行線上診斷平台已在實際線上問題分析中持續發揮關鍵作用，Arthas 也越來越得到社群的關注和開發者的認可。Arthas 官方在新版本中已經支援了 Restful 接口，提供結構資料，也支援了更豐富的診斷指令，這跟我們的建設思路不謀而合。未來，我們将繼續積極參與社群建設，将工行的實踐經驗分享給大家。
Arthas 有獎征文正在進行中！
為了讓更多開發者開始用上 Arthas 這個 Java 診斷神器，今年 3 月 26 日，Arthas 社群聯合 JetBrains 推出
Arthas 有獎征文活動：聊聊這些年你和 Arthas 之間的那些事兒。活動已進行至第五期，點選連結即可參與：
http://alibabacloud.mikecrm.com/9khcRrs，歡迎大家踴躍投稿，參與即有可能獲獎！
“ 阿裡巴巴雲原生 關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的公衆号。”