为业务实体的每次保存生成审计跟踪的可能方法

本文关键字：审计跟踪 方法 保存 业务 实体 | 更新日期: 2023-09-27 18:01:05

我们目前需要为我们的一些主要业务实体实现审计跟踪生成，在这些情况下，我们通常需要保留每个更改字段的新旧值，以及一些头数据，如时间戳、实体ID和保存用户。

我知道有不同的方法可以做到这一点，例如：

  1. 。NET代码端，使用反射
  2. SQL Server端触发器
  3. SQL Server CDC(更改数据捕获(

A。NET反射的方法可能需要更长的时间来编写，但如果操作得当，它将足够聪明，可以在不更改任何代码的情况下包含未来添加的新属性，而且它还可以扩展和比较所有子实体(就像添加到我们的主.NET实体中的其他子实体的集合(。

实际上，我们有一个使用这种方法的遗留应用程序。NET的审计跟踪生成，我们将整个审计跟踪保存为SQL数据库中的XML字段，多年来，该审计表现在大约有35GB的数据。

我在想，从的角度来看，这是一个基于触发的解决方案有多容易

  • 首次实施
  • 未来修改要审计的实体所需的每一项更改(添加/更改/删除字段等(
  • 审计数据的可读性如何？我们可以简单地使用一个查询来显示特定保存操作的旧值和新值吗

表演怎么样？

有没有人对这两种方法都有经验，可以提出或指出一些利弊？

为业务实体的每次保存生成审计跟踪的可能方法

过去，为了满足类似的需求，我转向了域事件和消息传递。它确实带来了一些复杂性，但可能是值得的。我建议至少考虑一下。

从本质上讲，您可以通过定义在对业务对象进行更改时触发的事件，使更改成为模型的一级公民。这些事件也是捕捉业务意图的好方法，而不仅仅是现场级别的更改。例如，名为OrderRefunded的业务事件通常是比OrderTotal field changed from 45.00 to 0.00更好的审计点。

通过使用发布/订阅的消息传递来触发这些域事件，允许许多订阅者处理该事件。其中一个订阅者可能是Audit订阅者。这消除了处理原始请求的域的所有性能影响(重建索引等(，并给Audit订阅者带来了负担。这也意味着您永远不会遇到审计代码中的错误导致业务事务处理中断的问题。

另一个好处是需要保存多少数据。这种方法的优点是，Audit订阅者只需保存其打算使用的数据量。关于保存或归档多少数据的规则也会本地化到处理审核的服务。因此，您可以确保您不会在没有必要的情况下存储任何数据。

我过去使用过的工具包括NServiceBus和RabbitMQ。每个人都有自己的利益和责任，这取决于问题。

每个组织对审计的要求都非常具体。在我的上一个项目中，我们被要求对发送到实时系统的消息进行审计跟踪。

音量很大。。有些天超过50GB的文本文件，而另一些天平均为10-15GB。

我们使用的第一个解决方案是将其持久化到SQL 中

  • 性能缓慢
  • 查询速度慢
  • 归档解决方案同样缓慢
  • 仅支持查询数据库记录

大约2年前

  • 我们转到了直接登录到文本文件。打开并附加
  • 我们每天都会对文本文件进行gzip处理，以减少占用的空间
  • 快速写入
  • 慢速读取(读取gzipped流和查询记录(

去年

  • 将文件大小限制为4Gb，并进行回滚以使用新文件(提高了gzip性能，减少了OOM(
  • 每天早上gzip任何文件
  • 快速写入
  • 可以执行并行读取，以便更好地读取(读取gzipped流和查询记录(

你的选择是基于你的需要。

如果将业务实体映射到视图，则可以使用INSTEAD OF触发器生成审核日志。

相关文章：