我们有 1 个服务，它从数据库中选择一些 id，然后用一些业务逻辑按顺序处理它们。我们希望横向扩展并并行执行处理，而不创建大量内部线程。
我的问题是：
如果我想使用Distributor进行横向扩展，应该如何做？
解决方案一：该服务分为 2 部分：
- 原来的服务修改为只从数据库中选择id，然后将其发送给worker。这将是分发器 (RunDistributorWithNoWorkerOnItsEndpoint)。
- 一项新服务将保存业务逻辑并作为工作人员运行，处理每个传入的 ID。如果我想要更多的工人，我只需多次启动相同的过程即可。
解决方案2：该服务分为3部分：
- 原来的服务修改为只从数据库中选择ids，然后将其发送给分发者。
- 新服务分发器 (RunDistributorWithNoWorkerOnItsEndpoint) 仅处理工作线程的负载平衡。
- 一个新的服务，worker(s)，它将保存业务逻辑并处理每个传入的 id。
解决方案3：该服务分为 2 部分：
- 原来的服务修改为只从数据库中选择id然后发送。作为发送者运行。
- 一项新服务将保留业务逻辑并作为工作人员运行和经销商，处理每个传入的 ID 或分发它们。
解决方案 1 对我来说很有意义，但使用它意味着经销商将承担 2 项责任：
- 选择 ID。
- 将 id 分发给工人。
但当我查看 NSB 文档中的 ScaleOut 示例时，我不确定这是否可能，甚至可能是反模式。
在再次阅读文档和 ScaleOut 示例后，我相信我应该选择解决方案 3，但我还不太确定。
我试图通过与 NSB 分销商进行扩展来解决管道问题，我更愿意自己进行托管，而不是使用 NServiceBus.Host.exe，但这不是严格要求。
EDIT:我最终使用了解决方案 3，因为它的优点（在我看来）是，如果您使用默认队列命名，配置队列的任务比解决方案 2 中的要小。
亲切的问候
我们在过去的版本中使用解决方案 2 完成了此操作。原因是我们使分发服务器保持一致且高度可用。将来我们很可能会让分销商完成一些工作，否则它只会相对闲置。这个解决方案对我们很有帮助。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
