微服務治理與統計分析

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

引言：

微服務架構下，服務拆得越細，服務的粒度越小，可組裝性就越好；與之相對的服務之間的呼叫關係就會變複雜，為了保證服務更好的執行，需要對這些服務進行監控和管理。本文大家介紹下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 微服務平臺裡治理與統計分析，希望對大家有所幫助。不足之處，也請多多指正。

精選提問：

問1：配置生效要重啟應用嗎？日誌統計的實時性如何？

答：配置可以是熱更新的，不需要重啟應用；介面統計暫時不是基於日誌分析的，直接從每個例項中獲取統計資訊。

問2：EOS微服務平臺底層是基於哪些技術？這個系統我們公司購買， 需要多少錢？

答：主要用到的是 Spring Cloud，Apollo，SkyWalking，ELK。可以撥打400-820-5821進行產品諮詢、瞭解詳情。

問3：微服務治理的本質是什麼，除過熔斷、限流，微服務治理還包括哪些，特別是微服務的安全體現在哪些方面？

答：個人覺得治理還是為了保證業務系統正常平穩的執行。只是微服務架構下，程式更多，互動更多，管理複雜，異常錯誤會容易放大。除了熔斷、限流，比如例項上下線，統一配置，流量管理，應用分組(多版本)等。我們現在是在閘道器上做的鑑權，每個系統都有一個閘道器，系統對外的介面需要先在閘道器上釋出，並對介面進行授權指定哪些客戶端可以呼叫，發放授權碼。

問4：資料共享安全管控中如何對非結構化的資料資源進行安全控制，如影像地圖等，如何進行按地理區域來控制訪問的許可權及安全？

答：資料共享安全管控中對影像地圖類非結構化的資料資源很難從內容上去做控制，可以配置地理區域標識與服務的對應關係、地理區域IP與服務對關係，從服務訪問的角度來控制。

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

關於EAWorld：微服務，DevOps，資料治理，移動架構原創技術分享。