Multi-Tenancy 中间层架构

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

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

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

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

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

希望对您有所帮助。