[Abp 源碼分析]十五、自動審計記錄

0.簡介

Abp 框架為我們自帶了審計日誌功能，審計日誌可以方便地查看每次請求介面所耗的時間，能夠幫助我們快速定位到某些性能有問題的介面。除此之外，審計日誌信息還包含有每次調用介面時客戶端請求的參數信息，客戶端的 IP 與客戶端使用的瀏覽器。有了這些數據之後，我們就可以很方便地復現介面產生 BUG 時的一些環境信息。

當然如果你腦洞更大的話，可以根據這些數據來開發一個可視化的圖形界面，方便開發與測試人員來快速定位問題。

PS:

如果使用了 Abp.Zero 模塊則自帶的審計記錄實現是存儲到資料庫當中的，但是在使用 EF Core + MySQL(EF Provider 為 Pomelo.EntityFrameworkCore.MySql) 在高併發的情況下會有資料庫連接超時的問題，這塊推薦是重寫實現，自己採用 Redis 或者其他存儲方式。

如果需要禁用審計日誌功能，則需要在任意模塊的預載入方法(PreInitialize()) 當中增加如下代碼關閉審計日誌功能。

public class XXXStartupModule
{
    public override PreInitialize()
    {
        // 禁用審計日誌
        Configuration.Auditing.IsEnabled = false;
    }
}

1.啟動流程

審計組件與參數校驗組件一樣，都是通過 MVC 過濾器與 Castle 攔截器來實現記錄的。也就是說，在每次調用介面/方法時都會進入 過濾器/攔截器 並將其寫入到資料庫表 AbpAuditLogs 當中。

其核心思想十分簡單，就是在執行具體介面方法的時候，先使用 StopWatch 對象來記錄執行完一個方法所需要的時間，並且還能夠通過 HttpContext 來獲取到一些客戶端的關鍵信息。

2.1 過濾器註入

同上一篇文章所講的一樣，過濾器是在 AddAbp() 方法內部的 ConfigureAspNetCore() 方法註入的。

private static void ConfigureAspNetCore(IServiceCollection services, IIocResolver iocResolver)
{
    // ... 其他代碼
    
    //Configure MVC
    services.Configure<MvcOptions>(mvcOptions =>
    {
        mvcOptions.AddAbp(services);
    });
    
    // ... 其他代碼
}

而下麵就是過濾器的註入方法：

internal static class AbpMvcOptionsExtensions
{
    public static void AddAbp(this MvcOptions options, IServiceCollection services)
    {
        // ... 其他代碼
        AddFilters(options);
        // ... 其他代碼
    }
    
    // ... 其他代碼

    private static void AddFilters(MvcOptions options)
    {
        // ... 其他過濾器註入
        
        // 註入審計日誌過濾器
        options.Filters.AddService(typeof(AbpAuditActionFilter));
        
        // ... 其他過濾器註入
    }
    
    // ... 其他代碼
}

2.2 攔截器註入

註入攔截器的地方與 DTO 自動驗證的攔截器的位置一樣，都是在 AbpBootstrapper 對象被構造的時候進行註冊。

public class AbpBootstrapper : IDisposable
{
    private AbpBootstrapper([NotNull] Type startupModule, [CanBeNull] Action<AbpBootstrapperOptions> optionsAction = null)
    {
        // ... 其他代碼

        if (!options.DisableAllInterceptors)
        {
            AddInterceptorRegistrars();
        }
    }

    // ... 其他代碼

    // 添加各種攔截器
    private void AddInterceptorRegistrars()
    {
        ValidationInterceptorRegistrar.Initialize(IocManager);
        AuditingInterceptorRegistrar.Initialize(IocManager);
        EntityHistoryInterceptorRegistrar.Initialize(IocManager);
        UnitOfWorkRegistrar.Initialize(IocManager);
        AuthorizationInterceptorRegistrar.Initialize(IocManager);
    }

    // ... 其他代碼
}

轉到 AuditingInterceptorRegistrar 的具體實現可以發現，他在內部針對於審計日誌攔截器的註入是區分了類型的。

internal static class AuditingInterceptorRegistrar
{
    public static void Initialize(IIocManager iocManager)
    {
        iocManager.IocContainer.Kernel.ComponentRegistered += (key, handler) =>
        {
            // 如果審計日誌配置類沒有被註入，則直接跳過
            if (!iocManager.IsRegistered<IAuditingConfiguration>())
            {
                return;
            }

            var auditingConfiguration = iocManager.Resolve<IAuditingConfiguration>();

            // 判斷當前 DI 所註入的類型是否應該為其綁定審計日誌攔截器
            if (ShouldIntercept(auditingConfiguration, handler.ComponentModel.Implementation))
            {
                handler.ComponentModel.Interceptors.Add(new InterceptorReference(typeof(AuditingInterceptor)));
            }
        };
    }
    
    // 本方法主要用於判斷當前類型是否符合綁定攔截器的條件
    private static bool ShouldIntercept(IAuditingConfiguration auditingConfiguration, Type type)
    {
        // 首先判斷當前類型是否在配置類的註冊類型之中，如果是，則進行攔截器綁定
        if (auditingConfiguration.Selectors.Any(selector => selector.Predicate(type)))
        {
            return true;
        }

        // 當前類型如果擁有 Audited 特性，則進行攔截器綁定
        if (type.GetTypeInfo().IsDefined(typeof(AuditedAttribute), true))
        {
            return true;
        }

        // 如果當前類型內部的所有方法當中有一個方法擁有 Audited 特性，則進行攔截器綁定
        if (type.GetMethods().Any(m => m.IsDefined(typeof(AuditedAttribute), true)))
        {
            return true;
        }

        // 都不滿足則返回 false,不對當前類型進行綁定
        return false;
    }
}

可以看到在判斷是否綁定攔截器的時候，Abp 使用了 auditingConfiguration.Selectors 的屬性來進行判斷，那麼預設 Abp 為我們添加了哪些類型是必定有審計日誌的呢？

通過代碼追蹤，我們來到了 AbpKernalModule 類的內部，在其預載入方法裡面有一個 AddAuditingSelectors() 的方法，該方法的作用就是添加了一個針對於應用服務類型的一個選擇器對象。

public sealed class AbpKernelModule : AbpModule
{
    public override void PreInitialize()
    {
        // ... 其他代碼

        AddAuditingSelectors();

        // ... 其他代碼
    }

    // ... 其他代碼

    private void AddAuditingSelectors()
    {
        Configuration.Auditing.Selectors.Add(
            new NamedTypeSelector(
                "Abp.ApplicationServices",
                type => typeof(IApplicationService).IsAssignableFrom(type)
            )
        );
    }

    // ... 其他代碼
}

我們先看一下 NamedTypeSelector 的一個作用是什麼，其基本類型定義由一個 string 和 Func<Type, bool> 組成，十分簡單，重點就出在這個斷言委托上面。

public class NamedTypeSelector
{
    // 選擇器名稱
    public string Name { get; set; }
    
    // 斷言委托
    public Func<Type, bool> Predicate { get; set; }

    public NamedTypeSelector(string name, Func<Type, bool> predicate)
    {
        Name = name;
        Predicate = predicate;
    }
}

回到最開始的地方，當 Abp 為 Selectors 添加了一個名字為 "Abp.ApplicationServices" 的類型選擇器。其斷言委托的大體意思就是傳入的 type 參數是繼承自 IApplicationService 介面的話，則返回 true,否則返回 false。

這樣在程式啟動的時候，首先註入類型的時候，會首先進入上文所述的攔截器綁定類當中，這個時候會使用 Selectors 內部的類型選擇器來調用這個集合內部的斷言委托，只要這些選擇器對象有一個返回 true,那麼就直接與當前註入的 type 綁定攔截器。

2.代碼分析

2.1 過濾器代碼分析

首先查看這個過濾器的整體類型結構，一個標準的過濾器，肯定要實現 IAsyncActionFilter 介面。從下麵的代碼我們可以看到其註入了 IAbpAspNetCoreConfiguration 和一個 IAuditingHelper 對象。這兩個對象的作用分別是判斷是否記錄日誌，另一個則是用來真正寫入日誌所使用的。

public class AbpAuditActionFilter : IAsyncActionFilter, ITransientDependency
{
    // 審計日誌組件配置對象
    private readonly IAbpAspNetCoreConfiguration _configuration;
    // 真正用來寫入審計日誌的工具類
    private readonly IAuditingHelper _auditingHelper;

    public AbpAuditActionFilter(IAbpAspNetCoreConfiguration configuration, IAuditingHelper auditingHelper)
    {
        _configuration = configuration;
        _auditingHelper = auditingHelper;
    }

    public async Task OnActionExecutionAsync(ActionExecutingContext context, ActionExecutionDelegate next)
    {
        // ... 代碼實現
    }
    
    // ... 其他代碼
}

接著看 AbpAuditActionFilter() 方法內部的實現，進入這個過濾器的時候，通過 ShouldSaveAudit() 方法來判斷是否要寫審計日誌。

之後呢與 DTO 自動驗證的過濾器一樣，通過 AbpCrossCuttingConcerns.Applying() 方法為當前的對象增加了一個標識，用來告訴攔截器說我已經處理過了，你就不要再重覆處理了。

再往下就是創建審計信息，執行具體介面方法，並且如果產生了異常的話，也會存放到審計信息當中。

最後介面無論是否執行成功，還是說出現了異常信息，都會將其性能計數信息同審計信息一起，通過 IAuditingHelper 存儲起來。

public async Task OnActionExecutionAsync(ActionExecutingContext context, ActionExecutionDelegate next)
{
    // 判斷是否寫日誌
    if (!ShouldSaveAudit(context))
    {
        await next();
        return;
    }

    // 為當前類型打上標識
    using (AbpCrossCuttingConcerns.Applying(context.Controller, AbpCrossCuttingConcerns.Auditing))
    {
        // 構造審計信息(AuditInfo)
        var auditInfo = _auditingHelper.CreateAuditInfo(
            context.ActionDescriptor.AsControllerActionDescriptor().ControllerTypeInfo.AsType(),
            context.ActionDescriptor.AsControllerActionDescriptor().MethodInfo,
            context.ActionArguments
        );

        // 開始性能計數
        var stopwatch = Stopwatch.StartNew();

        try
        {
            // 嘗試調用介面方法
            var result = await next();
            
            // 產生異常之後，將其異常信息存放在審計信息之中
            if (result.Exception != null && !result.ExceptionHandled)
            {
                auditInfo.Exception = result.Exception;
            }
        }
        catch (Exception ex)
        {
            // 產生異常之後，將其異常信息存放在審計信息之中
            auditInfo.Exception = ex;
            throw;
        }
        finally
        {
            // 停止計數，並且存儲審計信息
            stopwatch.Stop();
            auditInfo.ExecutionDuration = Convert.ToInt32(stopwatch.Elapsed.TotalMilliseconds);
            await _auditingHelper.SaveAsync(auditInfo);
        }
    }
}

2.2 攔截器代碼分析

攔截器處理時的總體思路與過濾器類似，其核心都是通過 IAuditingHelper 來創建審計信息和持久化審計信息的。只不過呢由於攔截器不僅僅是處理 MVC 介面，也會處理內部的一些類型的方法，所以針對同步方法與非同步方法的處理肯定會複雜一點。

攔截器呢，我們關心一下他的核心方法 Intercept() 就行了。

public void Intercept(IInvocation invocation)
{
    // 判斷過濾器是否已經處理了過了
    if (AbpCrossCuttingConcerns.IsApplied(invocation.InvocationTarget, AbpCrossCuttingConcerns.Auditing))
    {
        invocation.Proceed();
        return;
    }

    // 通過 IAuditingHelper 來判斷當前方法是否需要記錄審計日誌信息
    if (!_auditingHelper.ShouldSaveAudit(invocation.MethodInvocationTarget))
    {
        invocation.Proceed();
        return;
    }

    // 構造審計信息
    var auditInfo = _auditingHelper.CreateAuditInfo(invocation.TargetType, invocation.MethodInvocationTarget, invocation.Arguments);

    // 判斷方法的類型，同步方法與非同步方法的處理邏輯不一樣
    if (invocation.Method.IsAsync())
    {
        PerformAsyncAuditing(invocation, auditInfo);
    }
    else
    {
        PerformSyncAuditing(invocation, auditInfo);
    }
}

// 同步方法的處理邏輯與 MVC 過濾器邏輯相似
private void PerformSyncAuditing(IInvocation invocation, AuditInfo auditInfo)
{
    var stopwatch = Stopwatch.StartNew();

    try
    {
        invocation.Proceed();
    }
    catch (Exception ex)
    {
        auditInfo.Exception = ex;
        throw;
    }
    finally
    {
        stopwatch.Stop();
        auditInfo.ExecutionDuration = Convert.ToInt32(stopwatch.Elapsed.TotalMilliseconds);
        _auditingHelper.Save(auditInfo);
    }
}

// 非同步方法處理
private void PerformAsyncAuditing(IInvocation invocation, AuditInfo auditInfo)
{
    var stopwatch = Stopwatch.StartNew();

    invocation.Proceed();

    if (invocation.Method.ReturnType == typeof(Task))
    {
        invocation.ReturnValue = InternalAsyncHelper.AwaitTaskWithFinally(
            (Task) invocation.ReturnValue,
            exception => SaveAuditInfo(auditInfo, stopwatch, exception)
        );
    }
    else //Task<TResult>
    {
        invocation.ReturnValue = InternalAsyncHelper.CallAwaitTaskWithFinallyAndGetResult(
            invocation.Method.ReturnType.GenericTypeArguments[0],
            invocation.ReturnValue,
            exception => SaveAuditInfo(auditInfo, stopwatch, exception)
        );
    }
}

private void SaveAuditInfo(AuditInfo auditInfo, Stopwatch stopwatch, Exception exception)
{
    stopwatch.Stop();
    auditInfo.Exception = exception;
    auditInfo.ExecutionDuration = Convert.ToInt32(stopwatch.Elapsed.TotalMilliseconds);

    _auditingHelper.Save(auditInfo);
}

這裡非同步方法的處理在很早之前的工作單元攔截器就有過講述，這裡就不再重覆說明瞭。

2.3 核心的 IAuditingHelper

從代碼上我們就可以看到，不論是攔截器還是過濾器都是最終都是通過 IAuditingHelper 對象來儲存審計日誌的。Abp 依舊為我們實現了一個預設的 AuditingHelper ，實現了其介面的所有方法。我們先查看一下這個介面的定義：

public interface IAuditingHelper
{
    // 判斷當前方法是否需要存儲審計日誌信息
    bool ShouldSaveAudit(MethodInfo methodInfo, bool defaultValue = false);

    // 根據參數集合創建一個審計信息，一般用於攔截器
    AuditInfo CreateAuditInfo(Type type, MethodInfo method, object[] arguments);

    // 根據一個參數字典類來創建一個審計信息，一般用於 MVC 過濾器
    AuditInfo CreateAuditInfo(Type type, MethodInfo method, IDictionary<string, object> arguments);

    // 同步保存審計信息
    void Save(AuditInfo auditInfo);

    // 非同步保存審計信息
    Task SaveAsync(AuditInfo auditInfo);
}

我們來到其預設實現 AuditingHelper 類型，先看一下其內部註入了哪些介面。

public class AuditingHelper : IAuditingHelper, ITransientDependency
{
    // 日誌記錄器，用於記錄日誌
    public ILogger Logger { get; set; }
    // 用於獲取當前登錄用戶的信息
    public IAbpSession AbpSession { get; set; }
    // 用於持久話審計日誌信息
    public IAuditingStore AuditingStore { get; set; }

    // 主要作用是填充審計信息的客戶端調用信息
    private readonly IAuditInfoProvider _auditInfoProvider;
    // 審計日誌組件的配置相關
    private readonly IAuditingConfiguration _configuration;
    // 在調用 AuditingStore 進行持久化的時候使用，創建一個工作單元
    private readonly IUnitOfWorkManager _unitOfWorkManager;
    // 用於序列化參數信息為 JSON 字元串
    private readonly IAuditSerializer _auditSerializer;

    public AuditingHelper(
        IAuditInfoProvider auditInfoProvider,
        IAuditingConfiguration configuration,
        IUnitOfWorkManager unitOfWorkManager,
        IAuditSerializer auditSerializer)
    {
        _auditInfoProvider = auditInfoProvider;
        _configuration = configuration;
        _unitOfWorkManager = unitOfWorkManager;
        _auditSerializer = auditSerializer;

        AbpSession = NullAbpSession.Instance;
        Logger = NullLogger.Instance;
        AuditingStore = SimpleLogAuditingStore.Instance;
    }

    // ... 其他實現的介面
}

2.3.1 判斷是否創建審計信息

首先分析一下其內部的 ShouldSaveAudit() 方法，整個方法的核心作用就是根據傳入的方法類型來判定是否為其創建審計信息。

其實在這一串 if 當中，你可以發現有一句代碼對方法是否標註了 DisableAuditingAttribute 特性進行了判斷，如果標註了該特性，則不為該方法創建審計信息。所以我們就可以通過該特性來控制自己應用服務類，控制裡面的的介面是否要創建審計信息。同理，我們也可以通過顯式標註 AuditedAttribute 特性來讓攔截器為這個方法創建審計信息。

public bool ShouldSaveAudit(MethodInfo methodInfo, bool defaultValue = false)
{
    if (!_configuration.IsEnabled)
    {
        return false;
    }

    if (!_configuration.IsEnabledForAnonymousUsers && (AbpSession?.UserId == null))
    {
        return false;
    }

    if (methodInfo == null)
    {
        return false;
    }

    if (!methodInfo.IsPublic)
    {
        return false;
    }

    if (methodInfo.IsDefined(typeof(AuditedAttribute), true))
    {
        return true;
    }

    if (methodInfo.IsDefined(typeof(DisableAuditingAttribute), true))
    {
        return false;
    }

    var classType = methodInfo.DeclaringType;
    if (classType != null)
    {
        if (classType.GetTypeInfo().IsDefined(typeof(AuditedAttribute), true))
        {
            return true;
        }

        if (classType.GetTypeInfo().IsDefined(typeof(DisableAuditingAttribute), true))
        {
            return false;
        }

        if (_configuration.Selectors.Any(selector => selector.Predicate(classType)))
        {
            return true;
        }
    }

    return defaultValue;
}

2.3.2 創建審計信息

審計信息在創建的時候，就為我們將當前調用介面時的用戶信息存放在了審計信息當中，之後通過 IAuditInfoProvider 的 Fill() 方法填充了客戶端 IP 與瀏覽器信息。

public AuditInfo CreateAuditInfo(Type type, MethodInfo method, IDictionary<string, object> arguments)
{
    // 構建一個審計信息對象
    var auditInfo = new AuditInfo
    {
        TenantId = AbpSession.TenantId,
        UserId = AbpSession.UserId,
        ImpersonatorUserId = AbpSession.ImpersonatorUserId,
        ImpersonatorTenantId = AbpSession.ImpersonatorTenantId,
        ServiceName = type != null
            ? type.FullName
            : "",
        MethodName = method.Name,
        // 將參數轉換為 JSON 字元串
        Parameters = ConvertArgumentsToJson(arguments),
        ExecutionTime = Clock.Now
    };

    try
    {
        // 填充客戶 IP 與瀏覽器信息等
        _auditInfoProvider.Fill(auditInfo);
    }
    catch (Exception ex)
    {
        Logger.Warn(ex.ToString(), ex);
    }

    return auditInfo;
}

2.4 審計信息持久化

通過上一小節我們知道了在調用審計信息保存介面的時候，實際上是調用的 IAuditingStore 所提供的 SaveAsync(AuditInfo auditInfo) 方法來持久化這些審計日誌信息的。

如果你沒有集成 Abp.Zero 項目的話，則使用的是預設的實現，就是簡單通過 ILogger 輸出審計信息到日誌當中。

預設有這兩種實現，至於第一種是 Abp 的單元測試項目所使用的。

這裡我們就簡單將一下 AuditingStore 這個實現吧，其實很簡單的，就是註入了一個倉儲，在保存的時候往審計日誌表插入一條數據即可。

這裡使用了 AuditLog.CreateFromAuditInfo() 方法將 AuditInfo 類型的審計信息轉換為資料庫實體，用於倉儲進行插入操作。

public class AuditingStore : IAuditingStore, ITransientDependency
{
    private readonly IRepository<AuditLog, long> _auditLogRepository;

    public AuditingStore(IRepository<AuditLog, long> auditLogRepository)
    {
        _auditLogRepository = auditLogRepository;
    }

    public virtual Task SaveAsync(AuditInfo auditInfo)
    {
        // 向表中插入數據
        return _auditLogRepository.InsertAsync(AuditLog.CreateFromAuditInfo(auditInfo));
    }
}

同樣，這裡建議重新實現一個 AuditingStore，存儲在 Redis 或者其他地方。

3. 後記

前幾天發現 Abp 的團隊有開了一個新坑，叫做 Abp vNext 框架，該框架全部基於 .NET Core 進行開發，而且會針對微服務項目進行專門的設計，有興趣的朋友可以持續關註。

其 GitHub 地址為：https://github.com/abpframework/abp/

官方地址為：https://abp.io/

4.點此跳轉到總目錄