Multi-Tenancy 中间层架构

我们正在开发一个“中间层”来替换现有的业务逻辑/数据访问层。我们面临的设计问题之一是，我们需要以一种允许多个客户的数据库和/或中间层作为我们托管产品的一部分存在于同一服务器上的方式对其进行设计。托管环境的数据库架构和设置在这一点上相当固定，因为它已经在生产中。本质上，在托管环境中的给定数据库服务器上，每个客户都有一个使用其唯一客户 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]

其中哪一个(或介于两者之间的选项)会更好，为什么？

最佳答案

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

一个完全通用的框架，处理所有常见的通用操作

一个可定制的“客户”特定层，您可以在其中包含任何不寻常的客户特定功能。

也许您的许多客户可以单独在通用框架上操作，很好，但是当客户愿意为某些定制付费时，您可以通过扩展到通用层而不是修改通用层来容纳他们。

一般来说，我们通过非常标准的技术处理了这种可扩展性和泛型与特定行为的耦合——每个客户的配置文件定义了他们的处理“管道”、客户程序集的动态加载、接口(interface)的大量使用、允许通用组件委托(delegate)操作到运行时的标准实现或客户特定实现，等等。

希望有帮助。

关于 Multi-Tenancy 中间层架构，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/5022487/