多租户中间层架构

Question

多租户中间层架构

3

我们正在开发一个“中间层”来代替现有的业务逻辑/数据访问层。我们面临的设计问题之一是，我们需要以允许多个客户的数据库和/或中间件部件在同一服务器上作为我们托管方案的一部分的方式进行设计。托管环境的数据库架构和设置目前已经比较固定，因为它已经处于生产状态。基本上，在托管环境中的给定DB服务器上，每个客户都有一个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]

哪一种选项（或者中间的折中方案）更好，为什么？

- Zann Anderson

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- flesh · Accepted Answer

这是一个比较普遍的问题，所以我会给出一个比较通用的答案。我过去曾经在相似的原则上构建过平台，我能给你的唯一建议就是认真考虑将架构分成两层：

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

也许你的许多客户可以仅使用通用框架，这很好，但当客户愿意为某些定制付费时，您可以通过扩展而不是修改通用层来满足他们的需求。

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

希望能对你有所帮助。