Question

我们正在开发一个“中间层”来取代现有的业务逻辑/数据访问层。我们所面临的设计问题之一是，我们需要以允许多个客户的数据库和/或中间件作为托管产品的一部分存在于同一服务器上的方式进行设计。此时，托管环境的数据库架构和设置已经完全相同，因为它已经在生产中。实质上，在托管环境中的给定数据库服务器上，每个客户都有一个使用其唯一客户ID命名的SQL Server实例。

我们要确定的是，是否从客户端应用程序到Web服务，业务逻辑以及每个客户的数据库数据访问都有一个单独的路径，或者是否有一个单独的共享实例每个部分，其中数据访问层负责从正确的SQL Server实例获取数据，或者在这两者之间的某个地方。通过单一的共享路径，如果任何一件事情发生故障，所有访问它的客户都会死在水中。另一方面，对于每个客户而言，除了可能过于复杂之外，还有（看似）更多的维护？这是我们正在考虑的两个选项的可怕的ASCII艺术图片：

[Client]--|                                                             |--[DB]
[Client]--|                                                             |--[DB]
          |--> [Web Service] --> [Business Logic] --> [Data Access] ----|
[Client]--|                                                             |--[DB]
[Client]--|                                                             |--[DB]

或者这个：

[Client] --> [Web Service] --> [Business Logic] --> [Data Access] --> [DB]
[Client] --> [Web Service] --> [Business Logic] --> [Data Access] --> [DB]
[Client] --> [Web Service] --> [Business Logic] --> [Data Access] --> [DB]
[Client] --> [Web Service] --> [Business Logic] --> [Data Access] --> [DB]

这些中的哪一个（或中间选项）会更好，为什么？

Answer 1

这是一个相当笼统的问题，所以我会给出一个相当一般的答案。我过去在类似的原则上构建了平台，我可以给你的唯一建议是仔细考虑将架构分为两层：

处理所有常见通用操作的完全通用框架
可自定义的“客户”特定图层，您可以在其中包含任何不寻常的客户特定功能。

也许许多客户可以单独使用通用框架，但很好，但是当客户愿意为您付出一些代价时，您可以通过扩展，而不是修改通用层来容纳它们。

一般来说，我们通过非常标准的技术处理这种可扩展性和通用与专业行为的耦合 - 每个客户的配置文件，定义其处理'管道'，动态加载客户组件，大量使用接口，允许通用组件在运行时将操作委托给标准实现或客户特定实现，等等。

希望有所帮助。

多租户中层架构

1 个答案: