Log2Net的架构简介

　　在开始介绍源码之前，我们有必要了解下整个系统的大致需求，设计架构，观其大略，这样才能从总体上把握为何细节上要如此设计，不至于在代码的海洋中迷失，时不时吐槽为何要这么多代码。高屋建瓴地把控系统的全局，孜孜不倦地研读细节，是研读一个系统的好方法。

一、系统需求

　　本系统收集各信息化系统的日志，将其存储在数据库中，然后对日志进行查询和实时显示。

1.1 日志的类型
　　信息化系统的日志有以下几种情况：
　　(1)、用户行为日志：登录、数据库增删改操作；
　　(2)、业务变更日志：特定业务数据的变更记录；
　　(3)、系统级运行日志：启停、流量监控、调试日志、异常日志等；
　　(4)、页面访问日志：页面访问量、停止时间，某按钮的点击次数等。
　　根据这些日志类型，将日志分为两类进行监控和记录：操作轨迹类和系统访问运行类。
1.2 操作轨迹类
　　操作轨迹类包括：数据库增删改查、用户登录、业务操作/变更、系统调试/异常日志。
　　这些操作具有相同的结构，具有相同的字段：用户名（用户id）、操作类型、时间、记录内容、系统名称、服务器ip、服务器机器名、客户ip、客户机器名、数据库操作类有数据库名/表名，其他类（业务操作、系统相关）有模块名称。

1.3 系统访问运行类
　　系统访问运行主要以图形的方式展示服务器的运行情况：包括在线人数、历史访客、进程数、CPU使用率、内存使用率、页面访问人数等。
　　这些数据有当前时刻值和历史曲线图，每分钟主动刷新一次。

1.4 多平台需求
　　该日志系统可以应用在.NET4.5/.NET4.5.7/NET4.5.2/.NET4.6/.NET4.6.1/NET4.6.2/.NET4.7/.NET4.7.1/NET4.7.2框架的.NET平台上，也可以运行在.NetCore2.0/.NetCore2.1框架的.NetCore平台上。其他的框架由于版本较旧，性能功能不是很完善，使用较少，暂不支持。
1.5 多储存介质需求
　　系统的日志可以存储到文件中，可也以存储在数据库中。存储在数据库时，可以支持直接储存到数据库，也可以通过消息队列转存到数据库(适用于高并发的情况)。可以存储在Sql Server，Oracle，MySql等数据库中，可以方便扩展到其他数据库。

二、系统架构设计

　　日志管理系统是将各信息化系统的日志统一收集到本系统，在本系统进行统一管理、查询、监控。其架构方案为：开发一个日志收集组件，将运行日志、用户日志等存储到文件或数据库；各业务网站调用该组件，将日志记录到数据中；使用读写分离技术，将数据复制到读服务器，供日志查询监控服务查询调用数据，然后显示数据到用户端，并提供必要的告警显示。本架构以SQL为例说明：系统采用日志组件将日志记录到SQL数据库(先将日志发送到RabbitMQ消息队，日志消费存储任务再将其存储到数据库)，便于以后采用SQL发布订阅方式实现读写分离和数据查询。其系统架构如下图所示：

　　本系统要支持不特定的业务系统，需要支持.net和.netCore。为适应数据并发的现实需要，建议采用消息队列缓存数据。为减轻数据库压力，采用读写分离的方案，并且可以将操作数据和监控数据存在在不同的数据库中，实现分库分表的理念。

　　要支持多框架，使用VS2017的 TargetFrameworks 属性，在项目代码中使用 #if #else #endif条件编译指明各个平台下适用的代码。

　　要支持多种数据库，定义一组接口方法，然后每种数据库都实现这个接口即可。　　

　　该系统的业务流程为：各信息化系统调用调用日志收集存储组件Log2Net，将日志信息储存到数据库中。日志查询人员根据条件从该数据库中查询到日志数据，系统监控人员根据监控条件从该数据中查询得到监控数据。业务流程如下图：

　　这一篇中，我们知道了要干什么，知道了要怎么做，下一篇，我们将抽丝剥茧，详细介绍代码的实现。