连接多数据库的Entity Framework模型能否在多worker进程的web garden中运行？

我和身边几个做企业系统的团队，实际把绑定多数据库的Entity Framework模型部署在开了多worker的Web Garden环境下跑了挺久，没有本质的运行障碍，相关的注意点都是通用的多进程连库常识，不是EF或者Web Garden场景特有的问题：

• 从底层隔离性来说，DbContext本身就是按请求/操作生命周期创建的实例，每个Worker进程都会在自己的内存空间里独立初始化EF模型、构建各自的ADO.NET连接池，不存在跨Worker共享EF上下文的问题——只要你没在代码里违规把DbContext写成全局单例（这种写法不管是不是Web Garden场景本身就会触发线程安全问题），多Worker并发处理请求时每个进程内的EF操作都是完全独立的。
• 多数据库连接场景下，唯一需要提前评估的是连接池的整体开销：默认每个Worker进程会为每个配置的数据库单独维护一套ADO.NET连接池，如果你的Web Garden配置了N个Worker，那整个应用到单个数据库的最大空闲连接数会达到「N * 单进程默认连接池上限」的量级。如果数据库侧配置的最大连接数没把这个冗余算进去，很容易碰到连接耗尽的报错。这个是所有多进程应用连数据库的通用问题，只需要在数据库侧调整max connections配置，或者在每个数据库的连接字符串里调低Max Pool Size参数就可以解决，和EF的多库模型没有绑定关系。
• 实际踩过的典型坑是自动迁移的竞态：之前有团队在应用启动时自动跑EF迁移脚本，碰到多Worker进程同时启动时多个进程并发执行迁移、触发数据库表锁的问题。这个问题本质是多进程启动的竞态，和是否连接多数据库、是不是用EF都没关系——只要你是多入口启动应用，哪怕是单库部署，给迁移执行加个分布式锁、或者单独在发布流程里执行迁移脚本就可以规避。
• 从社区实际使用情况看，这种部署场景非常常见：不少做动态多租户的开源系统本身就是用EF维护多个租户库，生产环境不管是开Web Garden的IIS部署，还是多副本的容器化部署（本质和Web Garden是同模型的多进程隔离架构），跑多库EF连接的成熟方案已经被反复验证过，不是小众的试验性场景。

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