EF Core多租户架构实战：单库与分库实现全解析

多租户（Multi-Tenancy）是现代SaaS和企业级应用中不可回避的架构挑战。如何用EF Core优雅地实现多租户支持？本文带你一步步拆解核心思路与实现细节！🚀

引言：多租户，SaaS的必经之路

在SaaS或企业级B2B应用开发过程中，多租户架构几乎成了标配：一个应用服务多个客户（租户），数据又要绝对隔离安全。这不仅考验业务理解，更是对数据库设计和ORM能力的深度挑战。

.NET生态下，Entity Framework Core（简称EF Core）是最常用的数据访问层框架。那么，如何用EF Core高效、安全地实现多租户支持？让我们从实际需求出发，一步步拆解常见方案，并给出落地实现建议！

单数据库多租户：Query Filter玩转隔离

方案解析

对于大多数轻量级SaaS应用，**单数据库+租户标识字段（TenantId）**是一种高性价比方案。所有租户数据共存于一套表结构，通过TenantId字段区分，实现逻辑隔离。

核心技术点：

• 每张表增加TenantId字段
• 查询时全局过滤TenantId
• 通过EF Core的全局Query Filter自动注入过滤条件，防止漏查/越权

实现代码示例

在OnModelCreating里配置全局过滤：

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.Entity<Order>().HasQueryFilter(o => o.TenantId == TenantProvider.CurrentTenantId);
}

TenantProvider负责从当前HTTP请求头、JWT Claim或API Key中获取TenantId。推荐JWT或API Key方式，更安全可靠。

TenantProvider示意：

public class TenantProvider
{
    public static Guid CurrentTenantId => // 从请求上下文解析
}

场景适用

• 适合中小型应用，租户数量可控
• 性能损耗小，易于维护
• 需注意索引优化，避免表数据过大导致查询慢

分库多租户：极致隔离，安全加分

某些行业如医疗、金融等，对数据隔离有极致要求。此时推荐每个租户独立数据库（Database-per-Tenant）方案。

方案要点

• 每个租户独享一套数据库
• 应用层动态根据租户选择对应连接串
• 彻底物理隔离，无需Query Filter

实现步骤

1. 维护租户信息及数据库连接串：
   • 可用配置文件、数据库、或安全服务（如Azure Key Vault）集中管理
2. 动态DbContext连接切换：

public class TenantProvider
{
    public string GetConnectionString(Guid tenantId) => // 返回对应连接串
}

// 每次请求创建DbContext时，注入当前租户的连接串

3. 安全存储连接串：
   • 强烈建议不要明文存储在代码或配置文件，优先选用加密服务

场景适用

• 大型客户、数据敏感型行业
• 法规要求强隔离（如GDPR、HIPAA等）
• 对资源消耗和成本有更高预算

两种方案对比与延伸思考

建议：初期可采用单库模式，待业务规模扩大、隔离要求提升时，再迁移到分库架构。两种模式均可通过良好的抽象实现平滑切换。

结语：打好基础，才能优雅扩展

通过Query Filter实现单库多租户，是EF Core下“优雅而简单”的最佳实践。而分库架构则为更高安全场景提供了坚实后盾。无论哪种方案，核心思想是**“数据隔离”+“开发便捷”**的平衡。

多租户开发难不难？其实理解了原理，一切都水到渠成！希望这篇实战总结能为你的.NET多租户开发之路提供一些启发和帮助。

🗨️ 你更倾向于哪种多租户实现？有没有遇到过实际开发中的坑？欢迎在评论区留言交流！也别忘了分享给有需要的小伙伴！

📚 想了解更多.NET架构与实战干货？关注我，每周与你分享一线开发经验！