.Net微服务架构之运行日志分析系统

一、引言

　　.Net技术栈目前还没有像spring cloud相对完整一整微服务架构栈，随着业务发展系统架构演进，自行构建.Net技术体系的微服务架构，配套相关核心组件。因平台基于微服务架构方式研发，每个领域服务遵循平台统一标准，各自研发，独立部署运行，服务运行日志均通过记录本地文件方式进行记录。程序日志无法及时查阅，需登录服务器查看，同时不利于日志统一管理，因研发运行日志分析系统，进行日志统一分析管理，便于快速定位程序运行问题及时处理，保障平台运行稳定。虽然行业上也有一些日志架构，如较为有名的LEK（logstash, elasticsearch, kibana），因考虑到后续一些个性化的需求，还是自行研发运行日志分析系统。

二、设计原则

　　系统在总体微服务架构设计思想下，遵守平台标准，并结合实际解决问题的需要，进行设计和研发，系统严格按照如下设计原则设计：

　　1、模块化：根据职责和归属明确，进行拆分模块，模块功能高度内聚。

　　2、服务化：各模块通信，通过服务方式进行调用，服务之间通信，遵守平台的标准。

　　3、松耦合：系统模块之间通信，基于行业通用标准，按照“约定优于配置”思想，充分体现系统模块之间松耦合的关系。

　　4、高性能：采用异步的方式进行记录日志和分析，不影响平台总体性能。

　　5、易扩展：日志采用统一的接入方式，支持灵活扩展。

　　6、跨平台：支持不同技术语言、平台进行采集日志。

三、总体架构

图- 运行日志分析系统总体架构示意图

　　如图所示，系统基于上述设计原则，主要由五部分组成：日志记录、日志采集、日志接入、日志分析及存储、日志管理服务。每部分职责定位明确，相互支持、相互协作，共同构成运行日志分析系统。日志记录到本地文件，通过日志采集器将本地日志文件抽取后，发送至Kafka，同时由日志分析服务进行消费、分析及存储于elasticsearch，日志管理服务提供于用户查阅&分析日志信息。在平台统一通信协议下，扩展运行日志的内容，沿用Json报文格式，记录内容包括：IP、端口、服务ID、记录时间、日志内容。

1、日志报文

2、日志记录

　　日子记录，支持多种日志记录组件：Log4.net（本系统选用）、.Net core 自带的Nlog、微软企业库等，针对JAVA技术语言开发的服务，则选用log4j组件，只要按照约定规范进行打印日志即可。将日志信息记录到本地文件。

3、日志采集

　　日志采集，选用filebeat组件，filebeat是一个轻量级的日志传输组件，其可以通过提供一种轻量级的方式来转发和集中日志和文件，帮助你把简单采集和发送的事情简单化。本质上filebeat是一个日志信息搬运工，不进行日志过滤和分析工作。同时支持跨平台。

4、日志接入

　　日志接入，考虑日志量在某一故障情况，可能存在较大并发接入，所以选用Kafka组件作为日志信息接入分析的统一入口，kafka组件是一个高性能的MQ组件，具有高并发、高可用的特性。统一接入方案，为系统提供更为灵活的采集日志，不受限于某一平台、技术或者日志采集组件，均可将运行日志进行接入分析和存储。

5、日志分析及储存

　　日志分析，采用.Net Core研发，以后台服务的方式进行运行，订阅kafka的日志消息进行批量消费，分析程序支持横向扩展部署于多个程序，提升日志的消费能力，保障日志接收能力和分析能力相当。对日志分析后存储于Elasticsearch（以下简称：ES），ES是一个高可扩展的开源全文搜索和分析引擎，它允许存储、搜索和分析大量的数据。非常适合存储半结构化的日志数据，便于全文搜索日志信息。

6、日志管理服务

　　日志管理服务，实现查询ES中的运行日志数据，通过WebAPI方式提供界面功能调用。本系统采用“前后分离”应用开发技术，前端界面功能采用H5+JS，后端服务以restful方式提供API接口。

四、总结

　　根据不同应用场景和需求，选用不同的日志分析架构或者自行研发，最终目的就是为了快速、方便捕捉系统日志，有助于分析系统运行情况。尤其对于微服务架构大型平台，运行日志更为重要。本文主要是将系统设计原则、思想进行记录，同时对有需要的同学提供参考，可能再实际应用中，还有很多地方需要完善或者优化。

微信公众号：