问题描述
背景
我们有非常严格的审核要求，并且希望能够将我们的系统代表用户采取的每项操作与特定的身份验证操作（登录）相关联。除了这些严格的审计要求，我们还有一些复杂的授权要求，无法通过简单的基于声明的授权来解决。
将这两者综合考虑让我想知道使用“信封”类型设计的可行性，在这种设计中，源自用户请求的消息被包裹在包含必要信息的信封中，例如他们的身份验证令牌和有关发送机。现在，将这个令牌的属性添加到每条消息是相当简单的，但这似乎很俗气，而且由于它是一个相当跨领域的问题，我宁愿它不会污染系统中的每个协议，这就是为什么我我认为信封的想法值得考虑。这种方法还需要系统中每个参与者的合作，我的目标是让不需要任何这些信息的参与者透明，但也让信息在参与者确实需要的情况下可用。演员有需要的，直接接受信封类型也可以。
想象中的解决方案
概述
讨论
为了使这一切透明，我最初的想法是“拦截”发送/接收操作。我对 akka.net 的了解足以实现自定义邮箱，我认为这将是采用这种方法的方法，但我对其他想法持开放态度。邮箱将执行解包，并在需要时向参与者提供上下文信息（99% 的情况下不需要，当需要明确时直接接受信封可能更好）。邮箱还将通过向审计服务发送带有所需信息的消息来满足审计要求，其中不仅包括来自请求的上下文信息，还包括本地机器信息，以了解在哪里/谁进行了处理。>
我第二次猜测自己的部分是拦截发送操作 (Tell)。由于 IActorRef 实例是通过配置的 IActorRefProvider 创建的，并且由于这个人处理 Tell 操作（通过它创建的 IActorRef 实例），我认为编写自定义IActorRefProvider 和自定义 IActorRef。两者都将包装配置的实现（装饰器模式），并且自定义 IActorRef 将在其 Tell 方法中提供所需的行为。对于 webapi 应用程序（仅为用户的入口点），它将从 HttpContext（一个自定义引用提供程序）中提取所需的上下文信息，对于后端应用程序（另一个自定义引用提供程序），它将从当前消息的上下文。我不确定如何将数据添加到演员的 Context 属性，但我认为这是可能的。
有了这两个部分，上下文信息将有效地传递，从演员到演员，从服务到服务。因此，即使一条消息有 20 个参与者，如果它最初是由用户通过 REST API 发起的，它仍然会有上下文信息，从而允许对我们的系统采取的每个操作进行全面和完整的审计和跟踪特定的登录。
我希望什么
我希望这篇文章的主要内容是验证这是一种合理的方法，如果不是，为什么不和替代建议以实现所需的行为。如果自定义邮箱/actor ref/actor ref 提供者和额外的 cookie 正在做类似于我在这里尝试完成的事情，那么也非常欢迎任何代码示例。另一个受欢迎的花絮是如何进行邮箱配置，这样我就不需要使用自定义邮箱实现手动更新我的所有 Props。 Akka.net 配置绝对是我的弱点，尤其是部署部分，因此非常感谢这里的任何核心知识/文章/建议！
感谢您花时间阅读本文！ 非常感谢您的任何帮助！
其他 StackOverflow 问题：
在这些问题中提供的答案需要每个参与者的合作。理想情况下，这一切都是透明的，不需要使用此上下文信息的参与者可以写成好像它不存在一样。
我查看了其他几个 [由于某种原因现在找不到它们]，但它们都需要合作或全局共享状态 [这不是 akka 避免的吗？ :p]
解决方法
Phobos,a proprietary observability library for Akka.NET，将所有消息包装在分布式跟踪上下文中 - 可以在支持 OpenTracing 的现成跟踪系统中再次聚合在一起，例如 Jaeger / Zipkin / Azure Application见解。
您可以通过任何参与者内部的 Context.GetInstrumentation() method 将自定义数据附加到参与者内部捕获的每个跟踪中 - 自定义数据可以包括标签，这些标签可能包括唯一的用户 ID、交易 ID 和很快。这是 OpenTracing 规范的全部内容。
披露：我为 Phobos 的制造商 Petabridge 工作。它是专有的，使用需要花钱，但它的目的是提供这种类型的去中心化，但开箱即用的完整跟踪。
或者，如果您不想使用 Phobos，您可以通过 Akka.Logger.Serilog 库使用自定义消息传递协议来实现上下文传播和结构化日志记录。