微服務治理與統計分析
引言：
微服務架構下，服務拆得越細，服務的粒度越小，可組裝性就越好;與之相對的服務之間的調用關系就會變復雜，為了保證服務更好的運行，需要對這些服務進行監控和管理。本文大家介紹下EOS微服務平臺如果對微服務進行日志查看、API調用統計、限流、熔斷、負載均衡的管理。
目錄：
1.EOS微服務平臺簡介
2.微服務監控統計
3.微服務治理
1.EOS微服務平臺簡介
（1）域是平臺中一組系統的統稱，通常為一組系統定義成有業務含義的域，比如信貸域。一個域有多個系統，一個系統只能屬于一個域。一個域下可以日志中心、注冊中心、配置中心、APM監控中心已經斷路器監控中心
（2）系統是平臺中一組應用的統稱，通常為一組應用定義成有業務含義的系統，比如信貸系統。一個系統有多個應用，一個應用只能屬于一個系統。
（3）應用(微服務應用)是平臺開發出的基本部署單元，一個應用只能屬于一個系統，一個應用有1到多個應用實例組。
（4）應用實例組是平臺中應用的實例分組，每個應用可以有1到多個應用實例分組，不同的應用實例組擁有獨立的應用配置與管理能力，不同的應用實例組之間可以通過流控策略，實現應用的灰度發布能力。應用實例組下面有多個應用實例。
（5）應用實例是平臺下實際部署應用的進程，應用實例屬于某一個應用實例組。
2.微服務監控統計
（1）應用監控
通過應用監控可以查看一個系統內應用之間的調用關系。單個應用的平均響應時間、平均吞吐以及慢的端點訪問。
（2）實例監控
通過實例監控可以查看一個實例的運行情況包括：平均吞吐、平均響應時間、CPU、內存以及SQL的執行。
（3）請求監控
通過請求監控可以查看一個請求是成功還是錯誤，它的響應時間，以及它的調用鏈路：經過了幾個微服務，在每個微服務內的耗時是什么情況。
（4）API調用統計
API調用統計可以按照應用、實例組、實例、API來統計匯總請求信息，包括：響應狀態碼，請求數，最小響應時間，最大響應時間，平均響應時間以及響應時間總和。支持按應用、實例組、實例、API、時間段等條件進行查詢以及按請求數和響應時間排序。
（5）應用日志查看
應用日志匯聚多個應用實例的日志，進行統一查看。查看時支持按實例以及時間段進行查詢過濾，應用日志自帶traceId, spanId這些請求追蹤號。
3.微服務治理
（1）實例上下線
通過設置實例的狀態，使得實例不會被其他應用調用。這個是在客戶端實現，客戶端是通過ribbon做負載均衡，ribbon會過濾掉狀態為OUT_OF_SERVICE的服務提供者實例。
（2）API上下線
通過設置API的狀態，使得API不會被其他應用調用。這個是在服務端實現，通過在服務端增加Filter攔截器，對已下線的API的請求訪問，返回403的狀態碼。
（3）熔斷
EOS的熔斷實現使用的是Hystrix，通過在頁面配置熔斷對象以及觸發條件來設置斷路器。熔斷對象對應的是Hystrix的CommandKey，觸發條件包括：
- 手工熔斷(強制打開熔斷器)
- 取消熔斷(強制關閉熔斷器)
- 自動熔斷(規定時間內請求數超過閾值并且失敗率達到閾值才會觸發熔斷, 熔斷后指定時間內嘗試取消熔斷)
這個配置通過寫入到配置中心及時下放到各個應用，實現動態配置能力。
（4）限流
EOS現在的限流是對于每個應用實例獨立計算，如設置每秒訪問10次，一個應用有3個實例，則這3個實例每個都允許每秒訪問10次。限流是通過在服務端的Filter里使用Guava的RateLimiter實現。
這個配置通過寫入到配置中心及時下放到各個應用，實現動態配置能力。
（5）負載均衡
EOS的負載均衡使用的是Ribbon實現，可以針對每個目標客戶端設置規則類型，支持：隨機、循環、自定義等;另外還支持容錯，容錯是指當對某個實例的調用超時后的補救措施：
- 快速失敗(Failfast)：什么也不做，直接拋出異常
- 失敗自動切換(Failover)：嘗試訪問新的實例，按指定次數嘗試
- 失敗原地重試(Failback)：嘗試訪問同一實例，按指定次數嘗試
這個配置通過寫入到配置中心及時下放到各個應用，實現動態配置能力。
以上向大家分享了普元EOS 8 微服務平臺里治理與統計分析，希望對大家有所幫助。不足之處，也請多多指正。
