摘要

主要介紹分散式監控的基本概念及方法，java技術棧相關監控機制，性能監控、業務監控、異常監控、性能數據分析在融數微服務平台的實踐及應用。

微服務監控

微服務長什麼樣

微服務架構本質是帶自身特點的面向服務的分散式架構模式。

微服務架構特徵是有更細粒度服務邊界，倡導獨立開發、測試、部署、擴展等等，更細粒度帶來的敏捷提升，以及分散式系統固有的複雜性。

為什麼需要監控？

微服務是一個分散式的架構模式，它一直以來都會有一些自身的問題。

首先是問題的定位。當系統發從單個節點擴張到很多節點的時候，如果系統的某個點出現問題，對於我們的運維和開發人員來說，這時的問題定位可能就會變成一個挑戰。

其次是當新的業務進來以後，系統能否支持，系統運行的狀況又是怎樣？還有現在的一些電商要做促銷活動，容量規劃怎麼做？我們可以通過監控手段對系統進行衡量，或者做一個數據支撐。

其它還有就是要理解分散式系統是怎樣一個拓撲結構，如何部署，系統之間怎樣通信，系統目前是怎樣的性能狀況，以及出了問題我們要怎麼去發現它。

這些都可能是分散式系統需要面對的問題。出現這些問題後，監控就是一個比較常用、有效率的一個手段。

總的來說，監控主要解決的是感知系統的狀況。

怎麼監控？數據驅動

應用性能、拓撲第三方組件；資源使用；異常堆棧；數據聚合、分析報警；自定義業務。

常用監控手段

開源：Zabbix、ELK、Zipkin；

閉源：Prometheus、Pinpoint 、Newrelic；

或者「擼起袖子自己干」。

Java棧監控機制

命令行工具：Command line tools

代碼級工具：Log、SDK、AOP

採集數據並拿到真正關注的指標：Instrument+JMX

JMX機制獲取JVM、OS相關數據：

ManagementFactory.getXXXMXBean();

OperatingSystemMXBean

RuntimeMXBean

MemoryMXBean

ThreadMXBean

Collection<GarbageCollectorMXBean>

實踐及優化

微服務實踐

思路：圍繞微服務的開發、部署、調用、通信、業務處理過程。

在開發部署方面，我們構建了一個完整的工具鏈，通過插件機制把整個系統的初始化環境和代碼結構構建起來。

調用的時候對於普通用戶來說，並不想介入太多特定框架。最好是環境透明初始化，接近開箱即用的狀態。

分散式框架意味著有一個跨進程的調用和數據的傳輸等問題需要解決。如果每次調用都重新進行連接，從性能角度來說可能不太友好。長連接可以解決一部分問題，但假如通信數據很龐大，還會涉及到數據的壓縮以及事件非同步。

在使用過程中盡量做到框架透明，減少或消除依賴。

運維監控接入整合監控平台。

監控採集端實踐

思路：在有限資源內實現高效。

我們不希望為了監控而引入很多源碼，所以使用了Instrument和JMX機制。我們需要實時控制它，所以要讓它可配置化。

我們在高性能方面會做一個考量，比如限制它線程數量的大小等等。頻繁採集會對系統產生很嚴重的影響，我們選擇用採樣的方式來進行。

換個視角看性能優化

比優化更困難的是發現問題；

沒有條件或目標的優化都是耍流氓；

要追求對資源的高效利用。

Java性能優化：針對特定問題的常見代碼優化

文件io操作，IO操作使用buffer。動機：減少內核級調用、減少IO操作、可能減少CPU指令。

多線程環境，幵行、減少鎖競爭。動機：解放單線程限制、獲取CPU核數帶來的計算能力的擴展。

使用jdkcollection，數據結構指定大小。動機：減少擴容帶來的內存佔用、及其複製和老數據回收帶來的CPU指令。

調整演算法。動機：在執行每一次任務時，減少或優化CPU指令。

Java性能優化：jvm調優，時間空間運維的權衡

調整heap大小。動機：應用穩定狀態下新生代、老年代、方法區大小。大小的調整進而影響到gc的行為。

更換GC。動機：面向響應時間、吞吐量，終極目標針對CPU。

啟停其他特定參數。動機：針對特定場景，如對驗屍、逃逸分析、JIT支持。

Java性能優化：jvm調優步驟

根據gc日誌計算出應用長期存活對象(老年代、永久代)的大小。

建立heap基準大小（參考建議：基於長期存活對象大小，整堆如果限定為其大小的3-4x。那麼新生代為其1~1.5x，老年代為其2-3x，永久代為自身大小的1.5x）。

按目標是針對吞處理、響應時間來調整GC行為。啟用相應GC收集器，調整相應新生代、老年代、永久代大小。

按額外需求起停其他參數。

今天的分享就到這裡，謝謝大家！

推薦閱讀：