NServiceBus：Nitty-Gritty部署问题

Question

请在扩展出版商（使用数据库订阅存储）的多个出版物和使用扩展订阅者（使用分发服务器）的多个订阅的上下文中考虑以下问题，其中安装和卸载会定期进行初始部署，升级等。使用自动化MSI。

1. 使用数据库订阅存储，如果数据库出现故障会怎样？如果要发布消息需要访问Subscription DB，它将如何传递？它会迷路吗？调用Bus.Publish会抛出异常吗？
2. 假设您不需要没有停机时间部署：如果要将特定发布的订阅数据库移动到其他服务器，该怎么办？你如何管理这样的转变？
3. 同样的问题适用于订户方的分销商：如果您想移动分销商端点怎么办？我可以想到的一个场景是，如果您有多个使用单个分发服务器的订阅，如果您想将其中一部分移动到另一个分发服务器以减少负载，则可能很难。
4. 对于这样的设置（最初和持续升级），安装/卸载方案会是什么样的？您似乎希望有一些特殊的安装/卸载脚本来部署“逻辑发布”和订阅DB，以及“逻辑订阅”和分发者。发布者实例不需要任何特殊的安装/卸载逻辑（因为他们只是使用配置的订阅数据库开始发布消息，然后在卸载时停止）。除了分发器端点的正确配置之外，订户工作者节点在安装时不需要任何特殊的东西，但是需要卸载逻辑以确保它们从工作节点的分发器列表中删除。

Answer 1

1. 最终发布者将失败，消息将在内部队列中建立。您必须根据邮件大小以及等待DB出现的时间来规划处理此磁盘所需的磁盘大小。从那里可以了解您可以处理的停机时间。您可以使用数据库镜像或群集来使数据库停机时间更短。
2. 镜像和群集技术也可以帮助解决这个问题。取决于您是否要进行手动或自动故障转移以及您的操作（远程站点？）。
3. 群集MSMQ可以帮助您。如果你想放弃一个经销商并在一个集群中移动它你就可以了。另一种可能性是通过HTTP公开您的分销商，并在软件或硬件负载平衡解决方案之后对其进行负载平衡。在负载均衡器后面，您可以更自由地移动物体。
4. 听起来你已经很好地掌握了这个:)

Answer 2

关于订阅数据库的高可用性的第一个问题，您可以使用群集进行故障转移。如果数据库关闭，那么Bus.Publish将抛出异常，是的。建议将订阅数据库与应用程序数据库分开，以避免在升级应用程序时将其降低。这不必是单独的数据库服务器，同一个数据库服务器上的单独数据库也可以。

关于移动服务器，这通常在DNS级别进行管理，在这种情况下，您将同时运行一段时间，直到通信移动为止。

关于分销商的第三个问题 - 不要在不同的发布商或订阅者之间共享分销商。

根据经验，建议在进行此类维护活动时不要添加/删除订阅者。这通常会简化一些事情。