.NET 7 MVC应用多客户多数据库管理方案咨询及实现方法

一、单实例+客户独立数据库方案的可行性 #

这个方案完全可行，是多租户场景中物理隔离性最强的选择，适合对数据安全、合规性要求极高的行业（比如金融、医疗）。但得权衡优缺点：

• 优势：
  • 客户数据完全物理隔离，不存在跨客户数据泄露风险，合规性拉满
  • 单个客户数据库出故障、做备份恢复，不会影响其他客户
  • 可以针对特定客户的业务需求，单独调整数据库配置（比如索引、读写分离）
• 劣势：
  • 运维成本高，客户数量多的话要维护几十上百个数据库，备份、升级、监控都很麻烦
  • 应用版本迭代时，需要同步更新所有客户的数据库结构，迁移工作量大
  • 数据库连接池管理容易出问题，频繁切换连接字符串可能导致连接泄漏，浪费服务器资源

二、更优替代方案 #

根据你的业务规模、客户对数据隔离的要求，还有几种更灵活的方案可选：

1. 共享数据库+独立Schema #

同一个数据库里，给每个客户创建独立的Schema（比如CustomerA_、CustomerB_前缀的表）。

• 优点：运维成本低，只需要管理一个数据库；结构升级只做一次；数据库连接池利用率高
• 缺点：数据隔离性是逻辑层面的，需要严格控制数据库权限；单个数据库故障会影响所有客户

2. 共享数据库+共享表（带租户ID） #

所有客户的数据存在同一套表中，每条数据都加一个TenantId字段做标识。

• 优点：运维成本最低，适合客户数量极大的SaaS场景；扩展性最好，新增客户不需要做数据库操作
• 缺点：数据隔离性最差，必须在所有查询、写入操作中强制加入TenantId过滤，不小心就会出现数据泄露；单表数据量过大后会影响查询性能

3. 混合方案 #

对数据安全要求高的大客户用独立数据库，中小客户用共享Schema或共享表。这种方案能兼顾隔离性和运维成本，很多SaaS厂商都在用。

三、.NET 7中实现单实例多数据库的管理与切换 #

如果确定要用独立数据库方案，按以下步骤实现：

1. 管理客户连接字符串 #

把所有客户的连接字符串存在appsettings.json里，或者专门建一个系统共享数据库来存储（推荐后者，新增客户时不用改配置文件）：

// appsettings.json示例
"CustomerConnections": {
  "Tenant001": "Server=.;Database=Tenant001DB;Trusted_Connection=True;TrustServerCertificate=True",
  "Tenant002": "Server=.;Database=Tenant002DB;Trusted_Connection=True;TrustServerCertificate=True"
}

2. 登录时绑定租户连接信息 #

用户登录时，根据账号所属的租户ID，从配置或系统库中取出对应的连接字符串，把它存到用户的Claims里（比Session更适合分布式部署场景）：

// 登录逻辑示例
var user = await _userManager.FindByNameAsync(model.UserName);
var tenantConn = await _tenantRepository.GetConnectionStringByTenantId(user.TenantId);

var claims = new List<Claim>
{
    new Claim(ClaimTypes.Name, user.UserName),
    new Claim("TenantId", user.TenantId.ToString()),
    new Claim("TenantConnection", tenantConn)
};

var identity = new ClaimsIdentity(claims, CookieAuthenticationDefaults.AuthenticationScheme);
await HttpContext.SignInAsync(new ClaimsPrincipal(identity));

3. 动态创建DbContext #

自定义一个DbContext工厂，每次请求时根据当前用户的Claims获取连接字符串，创建对应的DbContext实例：

public interface ITenantDbContextFactory
{
    AppDbContext Create();
}

public class TenantDbContextFactory : ITenantDbContextFactory
{
    private readonly IHttpContextAccessor _httpContextAccessor;

    public TenantDbContextFactory(IHttpContextAccessor httpContextAccessor)
    {
        _httpContextAccessor = httpContextAccessor;
    }

    public AppDbContext Create()
    {
        var connString = _httpContextAccessor.HttpContext?.User.FindFirstValue("TenantConnection");
        if (string.IsNullOrWhiteSpace(connString))
            throw new InvalidOperationException("无法获取当前租户的数据库连接字符串");

        var options = new DbContextOptionsBuilder<AppDbContext>()
            .UseSqlServer(connString)
            .Options;

        return new AppDbContext(options);
    }
}

然后在Program.cs里注册服务：

builder.Services.AddHttpContextAccessor();
builder.Services.AddScoped<ITenantDbContextFactory, TenantDbContextFactory>();
builder.Services.AddScoped<AppDbContext>(sp => 
    sp.GetRequiredService<ITenantDbContextFactory>().Create()
);

4. 数据库初始化与迁移 #

新增客户时，自动创建数据库并执行EF Core迁移：

// 初始化客户数据库的工具方法
public static void InitializeTenantDb(string connectionString)
{
    var options = new DbContextOptionsBuilder<AppDbContext>()
        .UseSqlServer(connectionString)
        .Options;

    using var context = new AppDbContext(options);
    // 自动创建数据库并执行所有未应用的迁移
    context.Database.Migrate();
}

可以把这个方法集成到客户注册的后台逻辑里，新增客户时自动调用。

5. 关键注意事项 #

• 连接字符串要加密存储，用.NET的配置保护功能加密appsettings.json里的敏感数据，或者在系统库中加密存储
• 监控数据库连接池状态，避免频繁切换导致连接泄漏，必要时可以针对每个租户维护独立的连接池
• 异常处理要隔离，某个租户数据库不可用时，返回专属错误提示，不要影响其他租户的请求

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