微服务架构下EF Core 6跨库外键处理最佳实践咨询

你的场景属于典型的标准化参考数据跨服务引用问题，不用硬套零跨库访问的极端微服务规则，核心要平衡架构合规性、开发维护成本和数据一致性要求，结合你方.NET 6 + EF Core 6、所有库部署在同一SQL Server实例的现状，具体方案评估和落地建议如下：

现有调研方案的优劣势对比 #

• 方案2（松耦合公共地址服务+业务库仅存ID、无物理外键）：长期最优解，完全符合架构原则
  这个方案没有直接跨库耦合，所有公共地址数据的维护、校验逻辑全部收敛在独立的地址服务中，业务库完全自治，后续不管是公共地址库换存储介质、还是业务库拆分到独立实例，都不会互相影响。
  落地时不用完全放弃校验，注意几个实操细节即可：
  1. EF Core 6配置中直接将CityID、StreetID这类外键值字段映射为普通Guid类型属性，不要配置任何指向外部库的导航属性，从ORM层堵死意外生成跨库联表SQL的可能。
  2. 写入ID前做轻量校验：公共地址数据属于变更频率极低的参考数据（全球地址数据季度更新都属于高频场景），地址服务可以把全量有效ID+常用展示字段（城市名、街道名、邮编）做进程内内存缓存+分布式二级缓存，业务端写入ID前先查缓存判断有效性，性能损耗可以忽略不计。
  3. 兜底一致性保障：地址服务每次发布数据更新后，跑异步巡检任务扫描所有业务库中存储的地址ID，把已经失效（被合并、撤销）的ID扫出来告警人工修正即可，不需要做强实时一致性校验。
  4. 关联查询场景：需要展示地址关联文本时，把当前查询结果里的地址ID批量收集后，一次性调用地址服务拉取对应展示字段做内存匹配，性能比跨库联表更高。
• 方案1（SQL Server视图映射外部数据）：短期快速上线可选，长期维护成本高
  这个方案的优势是上线快，EF Core 6原生支持将视图映射为实体类型，开发人员几乎不用改现有查询习惯，甚至可以通过视图上的check约束间接实现ID有效性校验，但本质还是跨库强耦合，问题很明显：
  1. 公共地址库只要改表结构、调整字段权限，所有业务库的关联视图会直接报错，影响面极广。
  2. 跨库视图的查询性能不可控，开发人员很容易无意识写出视图和本地业务表的联表查询，缺索引的情况下会拖垮整个数据库实例。
  3. 后续如果做数据库拆分、多云部署，这套跨库视图逻辑全部要重构，扩展性很差。
• 方案3（触发器跨库数据复制）：完全不推荐
  触发器的隐式执行逻辑本来就是排错重灾区，跨库触发器还会引入强耦合的分布式事务问题：公共库更新一条地址数据，触发器就要同步写入N个业务库，只要其中一个业务库锁表、连接异常，公共库的写入操作就会被卡住甚至回滚，等于把公共库和所有业务库绑成了一个故障单点，后续出问题排查要跨N个库找隐式逻辑，维护成本极高。

平滑落地路线建议 #

结合你的技术栈现状，不用一步到位切架构，可以走两步走的平滑迁移路线：

1. 短期快速上线阶段：先给公共地址库创建专属只读账号，仅开放必要公共表的查询权限，业务库通过视图映射需要的公共地址字段，先满足新业务上线要求，同步启动公共地址服务的开发。
2. 长期架构迭代阶段：逐步把所有跨库视图的调用逻辑替换为公共地址服务调用，等所有逻辑迁移完成后下线全部跨库视图，最终实现完全的服务解耦。

不要为了追求物理外键的强一致性硬上跨库外键、分布式事务这类方案，公共参考数据的一致性要求远低于资金、订单这类交易类数据，软校验+异步巡检的方案完全能满足业务需求，实现复杂度低一个量级。

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