一、簡要說明
ABP vNext 當中的審計模塊早在 依賴注入與攔截器一文中有所提及，但沒有詳細的對其進行分析，
審計模塊是 ABP vNext 框架的一個基本組件，它能夠提供一些實用日志記錄，不過這里的日志不是說系統日志，而是說介面每次呼叫之后的執行情況（執行時間、傳入引數、例外資訊、請求 IP），
除了常規的日志功能以外，關于 物體 和 聚合 的審計欄位介面也是存放在審計模塊當中的，（創建人、創建時間、修改人、修改時間、洗掉人、洗掉時間）
二、原始碼分析
2.1. 審計日志攔截器
2.1.1 審計日志攔截器的注冊
Volo.Abp.Auditing 的模塊定義十分簡單，主要是提供了 審計日志攔截器 的注冊功能，下面代碼即在組件注冊的時候，會呼叫 AuditingInterceptorRegistrar.RegisterIfNeeded 方法來判定是否為實作型別(ImplementationType) 注入審計日志攔截器，
public class AbpAuditingModule : AbpModule
{
public override void PreConfigureServices(ServiceConfigurationContext context)
{
context.Services.OnRegistred(AuditingInterceptorRegistrar.RegisterIfNeeded);
}
}
跳轉到具體的實作，可以看到內部會結合三種型別進行判斷，分別是 AuditedAttribute 、IAuditingEnabled、DisableAuditingAttribute ，
前兩個作用是，只要型別標注了 AuditedAttribute 特性，或者是實作了 IAuditingEnable 介面，都會為該型別注入審計日志攔截器，
而 DisableAuditingAttribute 型別則相反，只要型別上標注了該特性，就不會啟用審計日志攔截器，某些介面需要 提升性能 的話，可以嘗試使用該特性禁用掉審計日志功能，
public static class AuditingInterceptorRegistrar
{
public static void RegisterIfNeeded(IOnServiceRegistredContext context)
{
// 滿足條件時，將會為該型別注入審計日志攔截器，
if (ShouldIntercept(context.ImplementationType))
{
context.Interceptors.TryAdd<AuditingInterceptor>();
}
}
private static bool ShouldIntercept(Type type)
{
// 首先判斷型別上面是否使用了輔助型別，
if (ShouldAuditTypeByDefault(type))
{
return true;
}
// 如果任意方法上面標注了 AuditedAttribute 特性，則仍然為該型別注入攔截器，
if (type.GetMethods().Any(m => m.IsDefined(typeof(AuditedAttribute), true)))
{
return true;
}
return false;
}
//TODO: Move to a better place
public static bool ShouldAuditTypeByDefault(Type type)
{
// 下面就是根據三種輔助型別進行判斷，是否為當前 type 注入審計日志攔截器，
if (type.IsDefined(typeof(AuditedAttribute), true))
{
return true;
}
if (type.IsDefined(typeof(DisableAuditingAttribute), true))
{
return false;
}
if (typeof(IAuditingEnabled).IsAssignableFrom(type))
{
return true;
}
return false;
}
}
2.1.2 審計日志攔截器的實作
審計日志攔截器的內部實作，主要使用了三個型別進行協同作業，它們分別是負責管理審計日志資訊的 IAuditingManager，負責創建審計日志資訊的 IAuditingHelper，還有統計介面執行時常的 Stopwatch ，
整個審計日志攔截器的大體流程如下：
- 首先是判定 MVC 審計日志過濾器是否進行處理，
- 再次根據特性，和型別進行二次驗證是否應該創建審計日志資訊，
- 根據呼叫資訊，創建
AuditLogInfo和AuditLogActionInfo審計日志資訊， - 呼叫
StopWatch的計時方法，如果出現了例外則將例外資訊添加到剛才構建的AuditLogInfo物件中， - 無論是否出現例外，都會進入
finally陳述句塊，這個時候會呼叫StopWatch實體的停止方法，并統計完成執行時間，
public override async Task InterceptAsync(IAbpMethodInvocation invocation)
{
if (!ShouldIntercept(invocation, out var auditLog, out var auditLogAction))
{
await invocation.ProceedAsync();
return;
}
// 開始進行計時操作，
var stopwatch = Stopwatch.StartNew();
try
{
await invocation.ProceedAsync();
}
catch (Exception ex)
{
// 如果出現了例外，一樣的將例外資訊添加到審計日志結果中，
auditLog.Exceptions.Add(ex);
throw;
}
finally
{
// 統計完成，并將資訊加入到審計日志結果中，
stopwatch.Stop();
auditLogAction.ExecutionDuration = Convert.ToInt32(stopwatch.Elapsed.TotalMilliseconds);
auditLog.Actions.Add(auditLogAction);
}
}
可以看到，只有當 ShouldIntercept() 方法回傳 true 的時候，下面的統計等操作才會被執行，
protected virtual bool ShouldIntercept(
IAbpMethodInvocation invocation,
out AuditLogInfo auditLog,
out AuditLogActionInfo auditLogAction)
{
auditLog = null;
auditLogAction = null;
if (AbpCrossCuttingConcerns.IsApplied(invocation.TargetObject, AbpCrossCuttingConcerns.Auditing))
{
return false;
}
// 如果沒有獲取到 Scop，則回傳 false，
var auditLogScope = _auditingManager.Current;
if (auditLogScope == null)
{
return false;
}
// 進行二次判斷是否需要存盤審計日志，
if (!_auditingHelper.ShouldSaveAudit(invocation.Method))
{
return false;
}
// 構建審計日志資訊，
auditLog = auditLogScope.Log;
auditLogAction = _auditingHelper.CreateAuditLogAction(
auditLog,
invocation.TargetObject.GetType(),
invocation.Method,
invocation.Arguments
);
return true;
}
2.2 審計日志的持久化
大體流程和我們上面說的一樣，不過好像缺少了重要的一步，那就是 持久化操作，你可以在 Volo.Abp.Auditing 模塊發現有 IAuditingStore 介面的定義，但是它的 SaveAsync() 方法卻沒有在攔截器內部被呼叫，同樣在 MVC 的審計日志過濾器實作，你也會發現沒有呼叫持久化方法，
那么我們的審計日志是在什么時候被持久化的呢？找到 SaveAsync() 被呼叫的地方，發現 ABP vNext 實作了一個審計日志的 ASP.NET Core 中間件，
在這個中間件內部的實作比較簡單，首先通過一個判定方法，決定是否為本次請求執行 IAuditingManager.BeginScope() 方法，如果判定通過，則執行，否則不僅行任何操作，
public async Task InvokeAsync(HttpContext context, RequestDelegate next)
{
if (!ShouldWriteAuditLog(context))
{
await next(context);
return;
}
using (var scope = _auditingManager.BeginScope())
{
try
{
await next(context);
}
finally
{
await scope.SaveAsync();
}
}
}
可以看到，在這里 ABP vNext 使用 IAuditingManager 構建，呼叫其 BeginScope() 構建了一個 IAuditLogSaveHandle 物件，并使用其提供的 SaveAsync() 方法進行持久化操作，
2.2.1 嵌套的持久化操作
在構造出來的 IAuditLogSaveHandle 物件里面，還是使用的 IAuditingManager 的默認實作 AuditingManager 所提供的 SaveAsync() 方法進行持久化，
閱讀原始碼之后，發現了下面兩個問題：
IAuditingManager沒有將持久化方法公開 出來，而是作為一個protected級別的方法，- 為什么還要借助
IAuditLogSaveHandle間接地呼叫 管理器的持久化方法，
這就要從中間件的代碼說起了，可以看到它是構造出了一個可以被釋放的 IAuditLogSaveHandle 物件，ABP vNext 這樣做的目的，就是可以嵌套多個 Scope，即 只在某個范圍內 才將審計日志記錄下來，這種特性類似于 作業單元 的用法，其底層實作是 之前文章 講過的 IAmbientScopeProvider 物件，
例如在某個應用服務內部，我可以這樣寫代碼：
using (var scope = _auditingManager.BeginScope())
{
await myAuditedObject1.DoItAsync(new InputObject { Value1 = "我是內部嵌套測驗方法1，", Value2 = 5000 });
using (var scope2 = _auditingManager.BeginScope())
{
await myAuditedObject1.DoItAsync(new InputObject {Value1 = "我是內部嵌套測驗方法2，", Value2 = 10000});
await scope2.SaveAsync();
}
await scope.SaveAsync();
}
想一下之前的代碼，在攔截器內部，我們是通過 IAuditingManager.Current 拿到當前可用的 IAuditLogScope ，而這個 Scope 就是在呼叫 IAuditingManager.BeginScope() 之后生成的，
2.2.3 最終的持久化代碼
通過上述的流程，我們得知最后的審計日志資訊會通過 IAuditingStore 進行持久化，ABP vNext 為我們提供了一個默認的 SimpleLogAuditingStore 實作，其內部就是呼叫 ILogger 將資訊輸出，如果需要將審計日志持久化到資料庫，你可以實作 IAUditingStore 介面，覆寫原有實作 ，或者使用 ABP vNext 提供的 Volo.Abp.AuditLogging 模塊，
2.3 審計日志的序列化
審計日志的序列化處理是在 IAuditingHelper 的默認實作內部被使用，可以看到構建審計日志的方法內部，通過自定義的序列化器來將 Action 的引數進行序列化處理，方便存盤，
public virtual AuditLogActionInfo CreateAuditLogAction(
AuditLogInfo auditLog,
Type type,
MethodInfo method,
IDictionary<string, object> arguments)
{
var actionInfo = new AuditLogActionInfo
{
ServiceName = type != null
? type.FullName
: "",
MethodName = method.Name,
// 序列化引數資訊，
Parameters = SerializeConvertArguments(arguments),
ExecutionTime = Clock.Now
};
//TODO Execute contributors
return actionInfo;
}
protected virtual string SerializeConvertArguments(IDictionary<string, object> arguments)
{
try
{
if (arguments.IsNullOrEmpty())
{
return "{}";
}
var dictionary = new Dictionary<string, object>();
foreach (var argument in arguments)
{
// 忽略的代碼，主要作用是構建引數字典，
}
// 呼叫序列化器，序列化 Action 的呼叫引數，
return AuditSerializer.Serialize(dictionary);
}
catch (Exception ex)
{
Logger.LogException(ex, LogLevel.Warning);
return "{}";
}
}
下面就是具體序列化器的代碼：
public class JsonNetAuditSerializer : IAuditSerializer, ITransientDependency
{
protected AbpAuditingOptions Options;
public JsonNetAuditSerializer(IOptions<AbpAuditingOptions> options)
{
Options = options.Value;
}
public string Serialize(object obj)
{
// 使用 JSON.NET 進行序列化操作，
return JsonConvert.SerializeObject(obj, GetSharedJsonSerializerSettings());
}
// ... 省略的代碼，
}
2.4 審計日志的配置引數
針對審計日志相關的配置引數的定義，都存放在 AbpAuditingOptions 當中，下面我會針對各個引數的用途，對其進行詳細的說明，
public class AbpAuditingOptions
{
//TODO: Consider to add an option to disable auditing for application service methods?
// 該引數目前版本暫未使用，為保留引數，
public bool HideErrors { get; set; }
// 是否啟用審計日志功能，默認值為 true，
public bool IsEnabled { get; set; }
// 審計日志的應用程式名稱，默認值為 null，主要在構建 AuditingInfo 被使用，
public string ApplicationName { get; set; }
// 是否為匿名請求記錄審計日志默認值 true，
public bool IsEnabledForAnonymousUsers { get; set; }
// 審計日志功能的協作者集合，默認添加了 AspNetCoreAuditLogContributor 實作，
public List<AuditLogContributor> Contributors { get; }
// 默認的忽略型別，主要在序列化時使用，
public List<Type> IgnoredTypes { get; }
// 物體型別選擇器，
public IEntityHistorySelectorList EntityHistorySelectors { get; }
//TODO: Move this to asp.net core layer or convert it to a more dynamic strategy?
// 是否為 Get 請求記錄審計日志，默認值 false，
public bool IsEnabledForGetRequests { get; set; }
public AbpAuditingOptions()
{
IsEnabled = true;
IsEnabledForAnonymousUsers = true;
HideErrors = true;
Contributors = new List<AuditLogContributor>();
IgnoredTypes = new List<Type>
{
typeof(Stream),
typeof(Expression)
};
EntityHistorySelectors = new EntityHistorySelectorList();
}
}
2.4 物體相關的審計資訊
在文章開始就談到，除了對 HTTP 請求有審計日志記錄以外，ABP vNext 還提供了物體審計資訊的記錄功能，所謂的物體的審計資訊，指的就是物體繼承了 ABP vNext 提供的介面之后，ABP vNext 會自動維護實作的介面欄位，不需要開發人員自己再進行處理，
這些介面包括創建物體操作的相關資訊 IHasCreationTime、IMayHaveCreator、ICreationAuditedObject 以及洗掉物體時，需要記錄的相關資訊介面 IHasDeletionTime、IDeletionAuditedObject 等，除了審計日志模塊定義的型別以外，在 Volo.Abp.Ddd.Domain 模塊的 Auditing 里面也有很多審計物體的默認實作，
我在這里就不再一一列舉，下面僅快速講解一下 ABP vNext 是如何通過這些介面，實作對審計欄位的自動維護的，
在審計日志模塊的內部，我們看到一個介面名字叫做 IAuditPropertySetter，它提供了三個方法，分別是：
public interface IAuditPropertySetter
{
void SetCreationProperties(object targetObject);
void SetModificationProperties(object targetObject);
void SetDeletionProperties(object targetObject);
}
所以，這幾個方法就是用于設定創建資訊、修改資訊、洗掉資訊的，現在跳轉到默認實作 AuditPropertySetter，隨便找一個 SetCreationTime() 方法，該方法內部首先是判斷傳入的 object 是否實作了 IHasCreationTime 介面，如果實作了對其進行強制型別轉換，然后賦值即可，
private void SetCreationTime(object targetObject)
{
if (!(targetObject is IHasCreationTime objectWithCreationTime))
{
return;
}
if (objectWithCreationTime.CreationTime == default)
{
objectWithCreationTime.CreationTime = Clock.Now;
}
}
其他幾個 Set 方法大同小異，那我們看一下有哪些地方使用到了上述三個方法，
可以看到使用者就包含有 EF Core 模塊和 MongoDB 模塊，這里我以 EF Core 模塊為例，猜測應該是傳入了物體物件過來，
果不其然...查看這個方法的呼叫鏈，發現是 DbContext 每次進行 SaveChanges/SaveChangesAsync 的時候，就會對物體進行審計欄位自動賦值操作，
三、總結
審計日志是 ABP vNext 為我們提供的一個可選組件，當開啟審計日志功能后，我們可以根據審計日志資訊快速定位問題，但審計日志的開啟，也會較大的影響性能，因為每次請求都會創建審計日志資訊，之后再進行持久化，因此在使用審計日志功能時，可以結合 DisableAuditingAttribute 特性和 IAuditingManager.BeginScope()，按需開啟審計日志功能，
四、點擊我跳轉到文章目錄
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/108784.html
標籤：.NET Core
上一篇：dotnetcore+vue+elementUI 前后端分離---支持前端、后臺業務代碼擴展的快速開發框架
下一篇：C# 資料型別