PowerDotNet平台化软件架构设计与实现系列（11）：日志平台

所有后端应用几乎都会记录日志，日志系统可以统一抽象出来提供服务。

最近被Log4j2的安全漏洞刷屏了，作为开发人员的我只能咩哈哈几次表示日志处理太难了，只有折腾过的人才知道这里面的艰辛啊。

在实现PowerDotNet日志系统之前，参考调研了Flume、ELK、Scribe和kafka的日志解决方案，对比后最终选择Facebook的日志系统Scribe作为目标，实现了基于thrift协议（当然也支持http协议）无锁且异步的更高性能简洁而稳定的可扩展日志系统Power.XLogger。

本文讲讲PowerDotNet内置的日志平台系统。

环境准备

1、（必须）.Net Framework4.5+

2、（必须）MySQL或SqlServer或PostgreSQL或MariaDB或MongoDB或ElasticSearch

3、（必须）PowerDotNet数据库管理平台，主要使用DBKey功能

4、（必须）PowerDotNet配置中心Power.ConfigCenter

5、（必须）PowerDotNet注册中心Power.RegistryCenter

6、（必须）PowerDotNet基础数据平台Power.BaseData

7、（必须）PowerDotNet缓存平台Power.Cache

8、（必须）PowerDotNet消息平台Power.Message

9、（必须）PowerDotNet人员管理平台Power.HCRM，后续文章详细介绍

一、Scribe简介

Scribe是Facebook开源的日志收集系统，它能够从各种日志源上收集日志，存储到一个中央存储系统（可以是NFS，分布式文件系统等）上，以便于进行集中统计分析处理。

Scribe为日志的“分布式收集，统一处理”提供了一个可扩展的高容错的方案。

Scribe从各种数据源上收集数据，放到一个共享队列上，然后push到后端的中央存储系统上。

当中央存储系统出现故障时，Scribe可以暂时把日志写到本地文件中，待中央存储系统恢复性能后，Scribe把本地日志续传到中央存储系统上。

Scribe主要包括三部分，分别为Scribe Agent， Scribe和存储系统。

1、 Scribe Agent

Scribe Agent实际上是一个thrift client。向Scribe发送数据的唯一方法是使用thrift client， Scribe内部定义了一个thrift接口，用户使用该接口将数据发送给server。

2、Scribe

Scribe接收到thrift client发送过来的数据，根据配置文件，将不同topic的数据发送给不同的对象。Scribe提供了各种各样的store，如 file， HDFS等，Scribe可将数据加载到这些store中。

3、Store

Scribe中的Store也就是我们所理解的存储系统，当前Scribe支持非常多的Store，包括：

file（文件）

buffer（双层存储，一个主储存，一个副存储）

network（另一个Scribe服务器）

bucket（包含多个 store，通过hash的将数据存到不同store中）

null(忽略数据)

thriftfile（写到一个Thrift TFileTransport文件中）

multi（把数据同时存放到不同store中）

二、日志存储

PowerDotNet的日志平台设计借鉴了Scribe，也支持从各种数据源上收集数据，放到一个共享队列上，然后push或pull到后端的中央存储系统上。

不过考虑到不同的应用场景，这个共享队列被设计成动态可配置的日志容器，容器可以是主流的几种消息队列（RabbitMQ、MSMQ、RocketMQ、Kafka等），redis，本地缓存等。

当存储系统出现故障时，PowerDotNet也会把日志“消息”暂时（序列化）写到本地文件中，待存储系统恢复性能后，再把本地日志（反序列化）续传到中央存储系统上。这种日志记录容错思想其实比较简单直白，非常容易理解。

PowerDotNet内置的日志存储媒介（也就是中央存储系统）包括MongoDB、MySQL、MariaDB、PostgreSQL、SQLServer和ElasticSearch，也给Exceptionless和ELK预留了接口，后续开发考虑把Hive也加进去，毕竟对于日志系统而言，大数据量处理和较为完善的分析工具链是极其重要的参考指标。

在创建后端应用的时候，配置中心会自动分配一个记录日志的DBKey，默认为PostgreSQL，但是个人在公司里碰到的更多的是使用MongoDB或者ElasticSearch或者ELK。