微服務治理與統計分析

轉載本文需註明出處：微信公衆號EAWorld，違者必究。

引言：

微服務架構下，服務拆得越細，服務的粒度越小，可組裝性就越好；與之相對的服務之間的調用關係就會變複雜，爲了保證服務更好的運行，須要對這些服務進行監控和管理。本文你們介紹下EOS微服務平臺如何對微服務進行日誌查看、API調用統計、限流、熔斷、負載均衡的管理。

目錄：

1.EOS微服務平臺簡介
2.微服務監控統計
3.微服務治理

1.EOS微服務平臺簡介




一、域是平臺中一組系統的統稱，一般爲一組系統定義成有業務含義的域，好比信貸域。一個域有多個系統，一個系統只能屬於一個域。一個域下能夠日誌中心、註冊中心、配置中心、APM監控中心已經斷路器監控中心

二、系統是平臺中一組應用的統稱，一般爲一組應用定義成有業務含義的系統，好比信貸系統。一個系統有多個應用，一個應用只能屬於一個系統。

三、應用（微服務應用）是平臺開發出的基本部署單元，一個應用只能屬於一個系統，一個應用有1到多個應用實例組。

四、應用實例組是平臺中應用的實例分組，每一個應用能夠有1到多個應用實例分組，不一樣的應用實例組擁有獨立的應用配置與管理能力，不一樣的應用實例組之間能夠經過流控策略，實現應用的灰度發佈能力。應用實例組下面有多個應用實例。

五、應用實例是平臺下實際部署應用的進程，應用實例屬於某一個應用實例組。

2.微服務監控統計

一、應用監控



經過應用監控能夠查看一個系統內應用之間的調用關係。單個應用的平均響應時間、平均吞吐以及慢的端點訪問。

二、實例監控

 

經過實例監控能夠查看一個實例的運行狀況包括：平均吞吐、平均響應時間、CPU、內存以及SQL的執行。

三、請求監控




經過請求監控能夠查看一個請求是成功仍是錯誤，它的響應時間，以及它的調用鏈路：通過了幾個微服務，在每一個微服務內的耗時是什麼狀況。

四、API調用統計


API調用統計能夠按照應用、實例組、實例、API來統計彙總請求信息，包括：響應狀態碼，請求數，最小響應時間，最大響應時間，平均響應時間以及響應時間總和。支持按應用、實例組、實例、API、時間段等條件進行查詢以及按請求數和響應時間排序。

五、應用日誌查看


應用日誌匯聚多個應用實例的日誌，進行統一查看。查看時支持按實例以及時間段進行查詢過濾，應用日誌自帶traceId, spanId這些請求追蹤號。

3.微服務治理

一、實例上下線



經過設置實例的狀態，使得實例不會被其餘應用調用。這個是在客戶端實現，客戶端是經過ribbon作負載均衡，ribbon會過濾掉狀態爲OUT_OF_SERVICE的服務提供者實例。

二、API上下線



經過設置API的狀態，使得API不會被其餘應用調用。這個是在服務端實現，經過在服務端增長Filter攔截器，對已下線的API的請求訪問，返回403的狀態碼。

三、熔斷




EOS的熔斷實現使用的是Hystrix，經過在頁面配置熔斷對象以及觸發條件來設置斷路器。熔斷對象對應的是Hystrix的CommandKey，觸發條件包括：

手工熔斷（強制打開熔斷器）
取消熔斷（強制關閉熔斷器）
自動熔斷（規定時間內請求數超過閾值而且失敗率達到閾值纔會觸發熔斷, 熔斷後指定時間內嘗試取消熔斷）

這個配置經過寫入到配置中心及時下放到各個應用，實現動態配置能力。

四、限流



EOS如今的限流是對於每一個應用實例獨立計算，如設置每秒訪問10次，一個應用有3個實例，則這3個實例每一個都容許每秒訪問10次。限流是經過在服務端的Filter裏使用Guava的RateLimiter實現。

這個配置經過寫入到配置中心及時下放到各個應用，實現動態配置能力。

五、負載均衡



EOS的負載均衡使用的是Ribbon實現，能夠針對每一個目標客戶端設置規則類型，支持：隨機、循環、自定義等；另外還支持容錯，容錯是指當對某個實例的調用超時後的補救措施：

快速失敗（Failfast）：什麼也不作，直接拋出異常
失敗自動切換（Failover）：嘗試訪問新的實例，按指定次數嘗試
失敗原地重試（Failback）：嘗試訪問同一實例，按指定次數嘗試

這個配置經過寫入到配置中心及時下放到各個應用，實現動態配置能力。

以上向你們分享了普元EOS 8 微服務平臺裏治理與統計分析，但願對你們有所幫助。不足之處，也請多多指正。


關於做者：王文斌，普元高級軟件工程師，開源技術愛好者，容器技術專家，曾參與浦東發展銀行BPM項目、銀聯PAASV1等項目。


關於EAWorld：微服務，DevOps，數據治理，移動架構原創技術分享。長按二維碼關注！