4

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

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

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

基于 .NET 反射的方法可能需要更长的时间来编写，但如果做得好，它将足够聪明，可以包含将来添加的新属性而无需更改任何代码，并且它还可以扩展和比较所有子实体（如添加到我们的主要 .NET 实体的其他子实体）。

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

我在想它在以下方面是多么容易成为基于触发器的解决方案：

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

……表演怎么样？

有没有人有这两种方法的经验，可以建议或指出一些利弊？

4

3 回答 3

4

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

体积很大。有时超过 50GB 的文本文件，有时平均为 10-15GB。

我们使用的第一个解决方案是在 SQL 中持久化它

  • 性能缓慢
  • 查询缓慢
  • 归档解决方案同样慢
  • 仅支持查询 db 记录

大约 2 年前

  • 我们转移到直接登录到文本文件。打开并附加
  • 我们每天 gzip 文本文件以减少占用的空间。
  • 快速写入
  • 慢读（读取压缩流和查询记录）

去年

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

您选择什么取决于您的需求。

于 2013-02-26T12:39:57.583 回答
4

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

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

使用发布/订阅通过消息传递来触发这些域事件允许许多订阅者处理事件。这些订阅者之一可能是审核订阅者。这将所有性能影响（重建索引等）从处理原始请求的域中移开，并将负担放在审计订阅者身上。这也意味着您永远不会遇到审计代码中的错误导致业务交易处理中断的问题。

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

我过去使用的工具包括NServiceBus和RabbitMQ。根据问题，每个都有其好处和责任。

于 2013-02-26T14:01:33.500 回答
1

如果您将业务实体映射到视图，那么您可以使用INSTEAD OF触发器来生成您的审计日志。

于 2013-02-26T12:52:03.810 回答