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

Posted 2023-03-27

【中文标题】为每次保存业务实体生成审计跟踪的可能方法

【英文标题】：Possible ways to generate audit trail for every save of business entities

【发布时间】：2013-02-11 21:49:24

【问题描述】：

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

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

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

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

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

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

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

...表演怎么样？

有没有人对这两种方法都有经验并且可以建议或指出一些优缺点？

【问题讨论】：

您希望哪些消费者使用这些原始数据？或者这只是为了调试而跟踪数据？

主要需要能够验证某个实体自创建以来的更改历史。不是为了调试，而是为了确保合规性，我们必须确保没有人可以更改此审计信息。

【参考方案1】：

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

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

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

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

大约两年前

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

去年

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

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

【讨论】：

感谢您的详细回答，我们无法保存文本文件，我们需要一个 UI 来解析审计跟踪并显示保存记录列表，以便展开它们并查看旧的和更改字段的新值，例如树视图，它必须在数据库中，以便我们可以轻松查询和创建此历史 UI，并且不应该在不受控制的情况下丢失或更改

这取决于您需要展示它们的频率和数量。我们必须提供一种查询和显示审计数据的方法。我们过去在糟糕的日子里生成 50GB 的审计数据，在好日子里生成大约 15GB 的审计数据。查询和显示从来不是问题

【参考方案2】：

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

【参考方案3】：

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

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

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

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

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