多租户中间层架构

Question

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

我们试图决定的是，是为每个客户提供从客户端应用程序到 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

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

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

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

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

希望对您有所帮助。