Unity DI 在异步操作中表现不佳
Unity DI misbehaving on async operations
我们有一个基于 asp.net MVC 4 的遗留多租户（每个租户都有自己的数据库，但他们共享相同的代码和虚拟机）系统。由于一些性能问题，我们开始一点一点，一点一点地改。
我们做的一件事是使用 unity 与 DI/IoC 一起工作。到目前为止，唯一在容器上注册的是使用 PerRequestLifetimeManager 的 EF DbContext。到目前为止，没有其他项目被注册。每当服务或控制器被启动时，
我们做的另一件事是让一些操作异步...我们计划让它们全部异步，但我们会一个一个地进行。
我们的内部测试成功并部署到生产环境。
经过几个小时的实际流量后，我们开始注意到一些问题...莫名其妙的错误，系统报告了一堆事情，其根本原因是："Id does not exists"。对于特定租户而言，这些情况相差甚远（每个租户每天发生不到 10 次 - 每个租户每天平均使用 3k 次操作），但总的来说，这变得非常令人担忧。手动捕获和执行总是返回预期的结果。
一个开发人员在某个时候错误地记录了 EF 正在使用的完整连接字符串，令我们惊讶的是，错误的数据库被击中了！客户端 A 确实试图从客户端 B 的数据库中读取一些东西！
环顾四周，我们遍历了 TransactionScopeAsyncFlowOption.Enabled 和 <add key="aspnet:UseTaskFriendlySynchronizationContext" value="true" />，但错误仍在发生...
我们认为根本原因有两个可能的位置：要么我们在创建 DbContext 时搞砸了，要么 unity 在我们调用 Resolve.[=36 时放弃了错误的实例=]
因为创建逻辑根本没有改变，而且以前没有发生过，我们认为这里是 Unity 的错。
重要的是要注意，据我们所知，没有使用 DI 的同步操作（现在大约 95% 的系统，5% 是异步操作）曾经有过这样的问题。
有人知道会发生什么吗？
详情：
-托管在 Azure App Services，框架版本 4.6
-水平尺度。但即使只有 1 个实例可以处理负载，也会发生这种情况
预先解决所有问题（例如在构造函数上），一切都会好起来的...
我们有一个基于 asp.net MVC 4 的遗留多租户（每个租户都有自己的数据库，但他们共享相同的代码和虚拟机）系统。由于一些性能问题，我们开始一点一点，一点一点地改。
我们做的一件事是使用 unity 与 DI/IoC 一起工作。到目前为止，唯一在容器上注册的是使用 PerRequestLifetimeManager 的 EF DbContext。到目前为止，没有其他项目被注册。每当服务或控制器被启动时，
我们做的另一件事是让一些操作异步...我们计划让它们全部异步，但我们会一个一个地进行。
我们的内部测试成功并部署到生产环境。
经过几个小时的实际流量后，我们开始注意到一些问题...莫名其妙的错误，系统报告了一堆事情，其根本原因是："Id does not exists"。对于特定租户而言，这些情况相差甚远（每个租户每天发生不到 10 次 - 每个租户每天平均使用 3k 次操作），但总的来说，这变得非常令人担忧。手动捕获和执行总是返回预期的结果。
一个开发人员在某个时候错误地记录了 EF 正在使用的完整连接字符串，令我们惊讶的是，错误的数据库被击中了！客户端 A 确实试图从客户端 B 的数据库中读取一些东西！
环顾四周，我们遍历了 TransactionScopeAsyncFlowOption.Enabled 和 <add key="aspnet:UseTaskFriendlySynchronizationContext" value="true" />，但错误仍在发生...
我们认为根本原因有两个可能的位置：要么我们在创建 DbContext 时搞砸了，要么 unity 在我们调用 Resolve.[=36 时放弃了错误的实例=]
因为创建逻辑根本没有改变，而且以前没有发生过，我们认为这里是 Unity 的错。
重要的是要注意，据我们所知，没有使用 DI 的同步操作（现在大约 95% 的系统，5% 是异步操作）曾经有过这样的问题。
有人知道会发生什么吗？
详情：
-托管在 Azure App Services，框架版本 4.6
-水平尺度。但即使只有 1 个实例可以处理负载，也会发生这种情况
预先解决所有问题（例如在构造函数上），一切都会好起来的...