Azure Service Fabric工作角色对象共享问题及状态保持方案咨询

首先得明确问题根源：你的本地环境是单节点单实例，请求处理基本是串行的，共享的追踪对象不会被干扰；但Azure上的无状态服务是多实例+单实例多线程并发处理请求的，如果你的追踪值存在静态类成员、单例对象的共享字段里，多个请求线程同时读写肯定会互相覆盖。

下面给你几个针对性的解决方案，按推荐程度排序：

1. 使用AsyncLocal实现异步上下文隔离 #

这是.Net专门为异步调用链设计的上下文存储方式，能保证每个请求（包括异步流程）的上下文是独立的，不会被其他请求干扰。

举个简单的实现示例：

public static class TraceContext
{
    private static readonly AsyncLocal<TraceValues> _traceValues = new AsyncLocal<TraceValues>();

    public static TraceValues Current
    {
        get => _traceValues.Value ?? new TraceValues();
        set => _traceValues.Value = value;
    }
}

public class TraceValues
{
    public string RecordId { get; set; }
    public string OperationId { get; set; }
    // 其他需要追踪的字段
}

当你从数据库获取记录后，直接赋值：

TraceContext.Current = new TraceValues { RecordId = record.Id, OperationId = Guid.NewGuid().ToString() };

然后在日志框架里直接读取TraceContext.Current的值即可，每个请求的上下文都是隔离的，不会被覆盖。

2. 利用依赖注入的Scoped生命周期 #

如果你的服务是基于Asp.Net Core托管的Service Fabric无状态服务，完全可以把追踪对象注册为Scoped（每个请求一个实例）：

首先定义追踪类：

public class TraceValues
{
    public string RecordId { get; set; }
    public string OperationId { get; set; }
}

然后在Startup的DI容器里注册：

services.AddScoped<TraceValues>();

之后在处理数据库记录的服务类中注入TraceValues，赋值后，日志框架里同样注入这个TraceValues实例来获取值。因为Scoped生命周期会为每个请求创建独立的实例，所以完全不会出现值被覆盖的问题。

3. 显式传递追踪上下文（适合简单场景） #

如果不想用上面两种方式，也可以把追踪值封装成对象，在每个处理方法中显式传递，比如：

public async Task ProcessRecord(Record record, TraceValues traceValues)
{
    // 处理逻辑
    _logger.LogInformation($"Processing record {traceValues.RecordId}");
}

这种方式虽然直观，但会增加代码耦合度，适合处理流程比较简单的场景。

关于工作角色的Session类似机制 #

首先，Service Fabric的无状态服务本身没有内置类似Asp.Net Session的会话机制——因为无状态服务的设计理念就是不保存持久化的会话状态，如果是Http类型的无状态服务（Asp.Net Core托管），你可以启用Asp.Net Core的Session，但需要注意：

• Session是针对用户会话的，同一个用户的多次请求会共享Session，而你需要的是每个请求独立的追踪上下文，所以Session并不匹配你的场景。
• 如果要在多实例下使用Session，必须配置分布式缓存（比如Azure Redis），否则不同实例的Session数据不共享。

所以对你的场景来说，前面的AsyncLocal或者Scoped DI是更合适的选择，完全满足"处理完成前值不被修改"的需求。

内容的提问来源于stack exchange，提问作者alok_dida