Asp.net mvc 如何在不同的服务器上部署引用dll

我在一个解决方案中使用了BAL、DAL和模型以及asp.net mvc项目的分层体系结构。 我希望将它们部署在不同的层（不同的物理服务器）中，即一个服务器用于BAL，一个服务器用于DAL，一个服务器用于Web，而模型在它们之间共享。 我如何做到这一点？ 请注意，我的BAL和DAL是类库类型，而不是web api

---

谢谢。

这只能通过web服务实现，并将它们分别放在每台服务器上的web服务器上。

简单的答案是，将层分布在机器上会降低性能，我认为这是您不想要的（您的目标是可伸缩性，即提高/保持性能）

更多解释：

您有一个分层架构，您的目标是可伸缩性

层（逻辑分离）是关于代码分离和可重用性的

以及可伸缩性的定义

是一个描述其在工作量增加/扩大或范围的情况下处理和执行能力的系统

总之,

性能是可伸缩性的主要目标

现在，通过一个代表性/虚拟示例来简化它，假设您有一些场景：

场景1:Api、BAL、DAL和MSSQL服务器都在同一台机器上，您访问（从中获取数据）SQL服务器的请求处理是

Api

->

BAL

->

DAL

->

MSSQL

场景2:Api、BAL和DAL在同一台机器上

，但MSSQL服务器在另一台机器上

您访问SQL的请求处理是

Api
->
BAL
->
DAL
--->
MSSQL（请注意，BAL和DAL的箭头保持不变，但访问MSSQL服务器的箭头变长，这是因为网络（物理）通信时间成本

场景3：（您所考虑的）Api和BAL在同一台机器上，DAL在另一台机器上，MSSQL服务器在另一台机器上

您访问SQL的请求处理是

Api
->
BAL
-->
DAL
-->
MSSQL（注意，出于场景2物理机器分离的相同原因，箭头变得更长）

总而言之，在机器之间分布层会增加处理成本并降低性能，而可扩展性的目标是提高性能。因此，将BAL和DAL移动到不同的机器并不能满足您的目标

扩展的一个行之有效的替代方法是微服务（将monolith服务（BAL+DAL）划分为多个微服务，每个微服务可以有自己的（BAL+DAL），也可以没有自己的（BAL+DAL）

微服务体系结构的主要好处之一是可伸缩性
部署类库没有意义，因为它们只能作为DLL被应用程序引用。如果您想单独维护代码，可以为所述类库维护不同的存储库。
R阅读下面的文章，特别是当作者比较层与层的概念时，物理上分离层的主要原因是什么？这没有意义。将其分层的原因是为了获得可伸缩性。我们将来还会添加移动应用程序，因此将其分离允许我们重复使用相同的应用程序。我知道，通过api，我可以实现是的，但还有其他方法吗？我认为这个问题应该被标记，但我不确定它是否只是不够清晰，没有重点，或者关注的是错误的事情。最终，听起来你需要某种方法来将编译输出复制到不同的服务器上。这似乎不是一个关于编程的问题。我知道。我正在寻找其他建议性病。