.Net微服務架構之運行日誌分析系統

1、引言

　　.Net技術棧目前尚未像spring cloud相對完整一整微服務架構棧，隨着業務發展系統架構演進，自行構建.Net技術體系的微服務架構，配套相關核心組件。因平臺基於微服務架構方式研發，每一個領域服務遵循平臺統一標準，各自研發，獨立部署運行，服務運行日誌均經過記錄本地文件方式進行記錄。程序日誌沒法及時查閱，需登陸服務器查看，同時不利於日誌統一管理，因研發運行日誌分析系統，進行日誌統一分析管理，便於快速定位程序運行問題及時處理，保障平臺運行穩定。雖然行業上也有一些日誌架構，如較爲有名的LEK（logstash, elasticsearch, kibana），因考慮到後續一些個性化的需求，仍是自行研發運行日誌分析系統。

 

2、設計原則

　　系統在整體微服務架構設計思想下，遵照平臺標準，並結合實際解決問題的須要，進行設計和研發，系統嚴格按照以下設計原則設計：

　　一、模塊化：根據職責和歸屬明確，進行拆分模塊，模塊功能高度內聚。

　　二、服務化：各模塊通訊，經過服務方式進行調用，服務之間通訊，遵照平臺的標準。

　　三、鬆耦合：系統模塊之間通訊，基於行業通用標準，按照「約定優於配置」思想，充分體現系統模塊之間鬆耦合的關係。

　　四、高性能：採用異步的方式進行記錄日誌和分析，不影響平臺整體性能。

　　五、易擴展：日誌採用統一的接入方式，支持靈活擴展。

　　六、跨平臺：支持不一樣技術語言、平臺進行採集日誌。

 

3、整體架構

圖- 運行日誌分析系統整體架構示意圖

　　如圖所示，系統基於上述設計原則，主要由五部分組成：日誌記錄、日誌採集、日誌接入、日誌分析及存儲、日誌管理服務。每部分職責定位明確，相互支持、相互協做，共同構成運行日誌分析系統。日誌記錄到本地文件，經過日誌採集器將本地日誌文件抽取後，發送至Kafka，同時由日誌分析服務進行消費、分析及存儲於elasticsearch，日誌管理服務提供於用戶查閱&分析日誌信息。在平臺統一通訊協議下，擴展運行日誌的內容，沿用Json報文格式，記錄內容包括：IP、端口、服務ID、記錄時間、日誌內容。

 

一、日誌報文

  

二、日誌記錄

　　日子記錄，支持多種日誌記錄組件：Log4.net（本系統選用）、.Net core 自帶的Nlog、微軟企業庫等，針對JAVA技術語言開發的服務，則選用log4j組件，只要按照約定規範進行打印日誌便可。將日誌信息記錄到本地文件。

三、日誌採集

　　日誌採集，選用filebeat組件，filebeat是一個輕量級的日誌傳輸組件，其能夠經過提供一種輕量級的方式來轉發和集中日誌和文件，幫助你把簡單採集和發送的事情簡單化。本質上filebeat是一個日誌信息搬運工，不進行日誌過濾和分析工做。同時支持跨平臺。

四、日誌接入

　　日誌接入，考慮日誌量在某一故障狀況，可能存在較大併發接入，因此選用Kafka組件做爲日誌信息接入分析的統一入口，kafka組件是一個高性能的MQ組件，具備高併發、高可用的特性。統一接入方案，爲系統提供更爲靈活的採集日誌，不受限於某一平臺、技術或者日誌採集組件，都可將運行日誌進行接入分析和存儲。

五、日誌分析及儲存

　　日誌分析，採用.Net Core研發，之後臺服務的方式進行運行，訂閱kafka的日誌消息進行批量消費，分析程序支持橫向擴展部署於多個程序，提高日誌的消費能力，保障日誌接收能力和分析能力至關。對日誌分析後存儲於Elasticsearch（如下簡稱：ES），ES是一個高可擴展的開源全文搜索和分析引擎，它容許存儲、搜索和分析大量的數據。很是適合存儲半結構化的日誌數據，便於全文搜索日誌信息。

六、日誌管理服務

 　　日誌管理服務，實現查詢ES中的運行日誌數據，經過WebAPI方式提供界面功能調用。本系統採用「先後分離」應用開發技術，前端界面功能採用H5+JS，後端服務以restful方式提供API接口。

4、總結

 　　根據不一樣應用場景和需求，選用不一樣的日誌分析架構或者自行研發，最終目的就是爲了快速、方便捕捉系統日誌，有助於分析系統運行狀況。尤爲對於微服務架構大型平臺，運行日誌更爲重要。本文主要是將系統設計原則、思想進行記錄，同時對有須要的同窗提供參考，可能再實際應用中，還有不少地方須要完善或者優化。

 

 微信公衆號：