将带有队列的单租户应用程序移动到多租户 Web 应用程序
Moving single tenant application with queue to multi tenants web application
我需要将单租户（.net 核心）Web 应用程序移动到多租户（大约 100 个租户）Web 应用程序。
租户将共享同一个应用程序，但每个租户将拥有自己的数据库（租户数据库）
我已经计划通过向缓存项键（前置租户模式）添加前缀（租户 ID），将我的进程内应用程序缓存移动到共享分布式缓存标识缓存项。
应用程序也依赖于 RabitMQ 来实现异步进程。其实我排队的人不多，就十来个exchange，不过我想以后排队和exchange的数量会越来越多。
现在，在转向多租户架构时，我对队列的最佳架构模式感到困惑。
选项：
1) 每个虚拟主机复制相同拓扑的多个虚拟主机（每个租户一个）
2) 具有相同队列、交换、ecc 在租户之间共享的单个虚拟主机。
第一个选择似乎更难管理，因为我应该为每个虚拟主机保持同步拓扑（假设 100 个租户意味着 100 个虚拟主机）
第二种选择更简单，我只需要在发送到队列的每条消息的上下文中传递租户标识符，这样消费者就知道谁是消息的所有者以及如何处理它。
我想知道一些关于第二选择的意见，因为在我看来它更实惠。
第二种选择更容易管理，纯粹是配置来吸引新客户（而不是基础设施 creation/management）。进一步推断，创建单个数据库并向所有 tables/queries 添加类似于 "customer id" 的内容会容易得多。这允许您对应用程序进行细分，并让新客户像在数据库中插入一行一样简单（而不是创建一个全新的数据库实例）。
多租户实施意味着您正在步入一个多维世界。 IMO，在不了解业务性质及其因素的情况下，很难给出多租户应用程序的配方。
我要查看的一个重要项目是每个租户将引入应用程序的负载。通常您希望负载相似的租户共享资源。如果一个负载是其他负载的 100 倍，那么体验就不会很好。
同时你又希望能够迈出一小步，承担不起基于10k个租户的实现，只服务于100个。但是，你也不希望丢掉你的应用，从头开始写当您的租户增长到 10k 时。
如您所见，这不是一个简单的决定。
在针对我当前的需求进行设计时，我总是会考虑我的下一步。重要的是您的设计要灵活且可扩展，至少对于您可以看到的下一阶段业务而言。
在您的情况下，您似乎可以看到下一步（多个虚拟主机 - 基本上是租户的专用资源），但您知道此时您不需要它。
我给你的建议是基于多虚拟主机设计，基于单主机实现。这样一来，如果发生一个租户的负载正在扼杀其他租户的情况，那么至少您可以用相对较小的努力将那个租户分开。
我需要将单租户（.net 核心）Web 应用程序移动到多租户（大约 100 个租户）Web 应用程序。 租户将共享同一个应用程序，但每个租户将拥有自己的数据库（租户数据库） 我已经计划通过向缓存项键（前置租户模式）添加前缀（租户 ID），将我的进程内应用程序缓存移动到共享分布式缓存标识缓存项。
应用程序也依赖于 RabitMQ 来实现异步进程。其实我排队的人不多，就十来个exchange，不过我想以后排队和exchange的数量会越来越多。
现在，在转向多租户架构时，我对队列的最佳架构模式感到困惑。
选项：
1) 每个虚拟主机复制相同拓扑的多个虚拟主机（每个租户一个）
2) 具有相同队列、交换、ecc 在租户之间共享的单个虚拟主机。
第一个选择似乎更难管理，因为我应该为每个虚拟主机保持同步拓扑（假设 100 个租户意味着 100 个虚拟主机） 第二种选择更简单，我只需要在发送到队列的每条消息的上下文中传递租户标识符，这样消费者就知道谁是消息的所有者以及如何处理它。
我想知道一些关于第二选择的意见，因为在我看来它更实惠。
第二种选择更容易管理，纯粹是配置来吸引新客户（而不是基础设施 creation/management）。进一步推断，创建单个数据库并向所有 tables/queries 添加类似于 "customer id" 的内容会容易得多。这允许您对应用程序进行细分，并让新客户像在数据库中插入一行一样简单（而不是创建一个全新的数据库实例）。
多租户实施意味着您正在步入一个多维世界。 IMO，在不了解业务性质及其因素的情况下，很难给出多租户应用程序的配方。
我要查看的一个重要项目是每个租户将引入应用程序的负载。通常您希望负载相似的租户共享资源。如果一个负载是其他负载的 100 倍，那么体验就不会很好。
同时你又希望能够迈出一小步，承担不起基于10k个租户的实现，只服务于100个。但是，你也不希望丢掉你的应用，从头开始写当您的租户增长到 10k 时。
如您所见，这不是一个简单的决定。
在针对我当前的需求进行设计时，我总是会考虑我的下一步。重要的是您的设计要灵活且可扩展，至少对于您可以看到的下一阶段业务而言。
在您的情况下，您似乎可以看到下一步（多个虚拟主机 - 基本上是租户的专用资源），但您知道此时您不需要它。
我给你的建议是基于多虚拟主机设计，基于单主机实现。这样一来，如果发生一个租户的负载正在扼杀其他租户的情况，那么至少您可以用相对较小的努力将那个租户分开。