背景
應用性能管理（Application Performance Management）是一個比較新的網絡管理方向，主要指對企業的關鍵業務應用進行監測、優化，提升企業應用的可靠性和質量，保證用戶獲得良好的服務，下降IT總擁有成本(TCO)。使用全業務鏈的敏捷APM監控，可以使一個企業的關鍵業務應用的性能更強大，能夠提升競爭力，並取得商業成功，所以，增強應用性能管理（APM）能夠產生巨大商業利益。國內外的APM有Compuware、iMaster、博睿Bonree、聽雲、New Relic、雲智慧、OneAPM、AppDynamics等。spring
如今的互聯網公司都根據本身的業務特色，開發了各自的apm產品。zipkin(twitter)、鷹眼(阿里)、hydra(京東)、tracing(窩窩)、cat(點評)，在spring cloud中，採用Sleuth與zipkin實現無縫集成。數據庫
微服務性能監控
Zipkin 是一款開源的分佈式實時數據追蹤系統（Distributed Tracking System），基於 Google Dapper 的論文設計而來，由 Twitter公司開發貢獻。其主要功能是彙集來自各個異構系統的實時監控數據，用來追蹤微服務架構下的系統延時問題。應用系統須要進行裝備（instrument）以向 Zipkin 報告數據。Zipkin 的用戶界面能夠呈現一幅關聯圖表，以顯示有多少被追蹤的請求經過了每一層應用。Zipkin 以 Trace 結構表示對一次請求的追蹤，又把每一個 Trace 拆分爲若干個有依賴關係的 Span。json
在微服務架構中，一次用戶請求可能會由後臺若干個服務負責處理，那麼每一個處理請求的服務就能夠理解爲一個 Span（能夠包括 API 服務，緩存服務，數據庫服務以及報表服務等）。固然這個服務也可能繼續請求其餘的服務，所以 Span 是一個樹形結構，以體現服務之間的調用關係。Zipkin 的用戶界面除了能夠查看 Span 的依賴關係以外，還顯示了每一個 Span 的耗時狀況，能夠一目瞭然的看到各個服務的性能情況。後端
zipkin的架構模型
主要組件說明
instrument: 用於性能日誌數據的收集api
Reporter: 將採集的數據發送到zipkin服務端緩存
Transport: 收集被trace的services的spans，而且傳輸給zipkin的collector，有三個主要傳輸：HTTP，Kafka和Scribe。網絡
collector: 負責將各系統報告過來的追蹤數據進行接收架構
storage: 默認的存儲方式爲in-memory，即不會進行持久化操做。若是想進行收集數據的持久化，能夠存儲數據在Cassandra，由於Cassandra是可擴展的，有一個靈活的模式，而且在Twitter中被大量使用，咱們使這個組件可插入。除了Cassandra，咱們原生支持ElasticSearch和MySQL。其餘後端可能做爲第三方擴展提供。app
API: 查詢服務用來向其餘服務提供數據查詢的能力，是以json api格式提供分佈式
UI: Web服務是官方默認提供的一個圖形用戶界面